ACOS 4.1.1-P11 Application Delivery and Server Load Balancing Guide

ACOS 4.1.
1-P11
Application Delivery and Server Load
Balancing Guide
for A10 Thunder® Series and AX™ Series
29 May 2019
© 2019 A10 NETWORKS, INC. CONFIDENTIAL AND PROPRIETARY- ALL RIGHTS RESERVED
Information in this document is subject to change without notice.
PATENT PROTECTION
A10 Networks products are protected by patents in the U.S. and elsewhere. The following website is provided to satisfy the virtual pat-
ent marking provisions of various jurisdictions including the virtual patent marking provisions of the America Invents Act. A10 Net-
works' products, including all Thunder Series products, are protected by one or more of U.S. patents and patents pending listed at:
https://www.a10networks.com/company/legal-notices/a10-virtual-patent-marking
TRADEMARKS
A10 Networks trademarks are listed at:
https://www.a10networks.com/company/legal-notices/a10-trademarks
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 Net-
works, Inc.
A10 NETWORKS INC. SOFTWARE LICENSE AND END USER AGREEMENT

Software for all A10 Networks products contains trade secrets of A10 Networks and its subsidiaries and Customer agrees to treat Soft-
ware as confidential information.
Anyone who uses the Software does so only in compliance with the terms of the End User License Agreement (EULA), provided later in
this document or available separately. Customer shall not:
1. Reverse engineer, reverse compile, reverse de-assemble, or otherwise translate the Software by any
means.
2. Sub-license, rent, or lease the Software.
DISCLAIMER
This document does not create any express or implied warranty about A10 Networks or about its products or services, including but not
limited to fitness for a particular use and non-infringement. A10 Networks has made reasonable efforts to verify that the information
contained herein is accurate, but A10 Networks assumes no responsibility for its use. All information is provided "as-is." The product
specifications and features described in this publication are based on the latest information available; however, specifications are sub-
ject to change without notice, and certain features may not be available upon initial product release. Contact A10 Networks for current
information regarding its products or services. A10 Networks’ products and services are subject to A10 Networks’ standard terms and
conditions.
ENVIRONMENTAL CONSIDERATIONS
Some electronic components may possibly contain dangerous substances. For information on specific component types, please con-
tact the manufacturer of that component. Always consult local authorities for regulations regarding proper disposal of electronic com-
ponents in your area.
FURTHER INFORMATION
For additional information about A10 products, terms and conditions of delivery, and pricing, contact your nearest A10 Networks loca-
tion, which can be found by visiting www.a10networks.com.
Table of Contents
DEPLOYMENT ........................................................................................................................19
Server Load Balancing Concepts and Terminology .................................................................... 21

Load Balancing Terminology ...............................................................................................21
Real Server .................................................................................................................................................. 21
Virtual Server and Virtual IP (VIP) ........................................................................................................... 22
Service Group ............................................................................................................................................. 23
Wildcard VIPs, Ports, and Virtual Ports ................................................................................................. 25
Source Network Address Translation (NAT) ........................................................................................ 25
Hardware Blocking VIP traffic to Unconfigured Virtual Ports ........................................................... 25
Clearing Unused Real Server Ports ........................................................................................................ 26
Networking Modes ...............................................................................................................27
Transparent (Switch) Mode ..................................................................................................................... 27
Gateway (Router) Mode ........................................................................................................................... 27
Deployment Modes ..............................................................................................................28
Inline Mode .................................................................................................................................................. 28
One-Arm Mode ........................................................................................................................................... 28
Transparent Mode Deployment .................................................................................................. 29

Transparent Inline Mode ......................................................................................................29
Transparent Inline Mode Topology Overview ...................................................................................... 29
Transparent Inline Mode Configuration ................................................................................................ 30
Transparent Mode in a Multinetted Environment...............................................................37
Transparent Multinetted Deployment Topology Overview ............................................................... 37
Transparent Multinetted Deployment Configuration ......................................................................... 38
Gateway Mode Deployment ........................................................................................................ 47

Gateway Inline Deployment Example ..................................................................................47
Gateway Inline Deployment Topology Overview ................................................................................. 48
Gateway Inline Deployment Configuration Example .......................................................................... 49
Gateway One-Arm Deployment Example ............................................................................56
Gateway One-Arm Deployment Topology Overview ........................................................................... 56
Traffic Flow .......................................................................................................................................... 57
ACOS Interface Configuration .......................................................................................................... 57
Traffic Blocking Between VLANs ..................................................................................................... 58
Network Address Translation ........................................................................................................... 58
Gateway One-Arm Deployment Configuration .................................................................................... 58
Direct Server Return (DSR) SLB Deployment .............................................................................. 69
page 3
ACOS 4.1.1-P11 Application Delivery and Server Load Balancing Guide
Contents
Direct Server Return in Transparent Mode .........................................................................69

Overview of DSR in Transparent Mode ................................................................................................. 70
Requirements for DSR in Transparent Mode Deployment ......................................................... 70
DSR Health Checking ......................................................................................................................... 71
DSR in Transparent Mode Configuration Example ............................................................................. 71
Direct Server Return in Route Mode ....................................................................................75
Overview and Topology of DSR in Route Mode ................................................................................... 75
Configuring DSR in Route Mode ............................................................................................................. 76
Direct Server Return in Mixed Layer 2/Layer 3 Environment .............................................78
Configuring DSR Return in Mixed L2/L3 Environment ....................................................................... 79
Layer 3 Direct Server Return (IP Tunneling)........................................................................81
Overview of Layer 3 DSR .......................................................................................................................... 81
Methods to Display the ACOS VIP as the Source Address ......................................................... 81
IP-in-IP Tunneling for L3 DSR Routing ............................................................................................ 81
DSR Health Checking ......................................................................................................................... 83
IP-in-IP Tunneling for L3 DSR Routing Requirements ................................................................. 84
Layer 3 DSR Configuration Example ...................................................................................................... 84
ADDITIONAL DEPLOYMENT .....................................................................................................87
Network Address Translation for SLB ........................................................................................ 89

Network Address Translation for SLB Overview.................................................................89
SLB Destination NAT ................................................................................................................................. 89
SLB Source NAT ......................................................................................................................................... 90
Connection Reuse ............................................................................................................................... 90
Source NAT for Servers in Other Subnets ...................................................................................... 93
Direct Server Return .............................................................................................................95
IP NAT Support for VIPs.......................................................................................................96
VIP Source NAT .......................................................................................................................................... 97
Using IP Pool Default Gateways To Forward Traffic from Real Servers ...........................98
Smart NAT for Virtual Ports .................................................................................................98
Virtual-port TCP Maximum Segment Life for NATted Sessions ..................................... 101
Dynamic Real Server Creation Using DNS ................................................................................ 103

Dynamic Real Server Implementation.............................................................................. 103
Creating and Maintaining Dynamic Servers .......................................................................................103
Dynamic Server Aging .............................................................................................................................103
Template Options for Dynamically Created Real Servers ............................................... 104
Server Template Options for Hostname Real Servers .....................................................................104
Server Port Template Options for Dynamic Service-Group Members ..........................................105
Configuring Dynamic Real Server Creation...................................................................... 105
Virtual IP Creation Based on Subnet ........................................................................................ 111
page 4
Contents
Virtual Port Ranges .................................................................................................................. 113

Supported Virtual Port Types............................................................................................ 113
Adding A Virtual Port Range to a Virtual Server .............................................................. 114
Mapping Virtual IP Addresses and Real Ports .......................................................................... 117

Deterministic Mapping ...................................................................................................... 117
Mapping VIP to Real Ports: Supported Virtual Port ..........................................................................118
Mapping VIP to Real Ports: Requirements .........................................................................................119
Configuring VIP to Real Port Mapping ............................................................................. 119
PROTOCOL LOAD BALANCING ...............................................................................................123
IPv4 Load Balancing ................................................................................................................. 125

IPv4 Load Balancing Overview ......................................................................................... 125
IPv4 Load Balancing – SLB NAT ..........................................................................................................127
IPv4 Load Balancing – Template Support ..........................................................................................127
IPv4 Load Balancing – Direct Server Return ......................................................................................127
Configuring IPv4 Load Balancing ..................................................................................... 128
IPv6 Load Balancing ................................................................................................................. 131

IPv6 Load Balancing Configuration Examples................................................................. 131
Layer 4 TCP/UDP Load Balancing ............................................................................................ 135

Layer 4 Load Balancing Overview..................................................................................... 135
Layer 4 Load Balancing Data Structures.......................................................................... 136
Configuring Layer 4 Load Balancing ................................................................................ 138
SLB Protocol Translation ......................................................................................................... 145
APPLICATION LOAD BALANCING ............................................................................................153
FTP Load Balancing ................................................................................................................. 155

FTP Load Balancing Overview .......................................................................................... 155
Configuring FTP Load Balancing ...................................................................................... 157
HTTP Load Balancing ............................................................................................................... 173

HTTP Load Balancing Overview ....................................................................................... 173
HTTP Load Balancing Configuration Components.......................................................... 174
Service Groups .........................................................................................................................................175
Virtual Server ............................................................................................................................................175
Templates .................................................................................................................................................175
Service Templates ...................................................................................................................................176
Server and Port Templates ....................................................................................................................176
Health Monitors .......................................................................................................................................177
page 5
Contents
Configuring HTTP Load Balancing ................................................................................... 177
HTTP Options for SLB .............................................................................................................. 187

HTTP Options for SLB Overview ....................................................................................... 187
HTTP Options Summary ........................................................................................................................ 187
Options for Server and Service Group Selection ........................................................................187
Performance Enhancing Options ...................................................................................................188
Options that Modify HTTP Requests ............................................................................................188
Options that Modify Server Replies ............................................................................................... 188
Configuring an HTTP Template ............................................................................................................189
Inserting HTTP Client Port Numbers in the HTTP Header ..............................................................190
URL Hash Switching.......................................................................................................... 191
Hash Options ............................................................................................................................................192
Offset ...................................................................................................................................................192
URL Hash Switching with Server Load Awareness ...................................................................192
URL Hashing Configuration ...................................................................................................................195
URL / Host Switching ........................................................................................................ 196
URL / Host Switching Description ........................................................................................................196
Match Options ...................................................................................................................................197
Configuring URL / Host Switching .......................................................................................................198
Using URL / Host Switching along with Cookie Persistence ..........................................................199
URL / Host Switching with Cookie Persistence Overview ........................................................199
Configuring URL / Host Switching with Cookie Persistence ...................................................202
Using URL / Host Switching along with Source IP Persistence .....................................................202
URL Failover....................................................................................................................... 203
URL Failover Overview ............................................................................................................................203
Configuring URL Failover .......................................................................................................................204
5xx Retry and Reassignment ............................................................................................ 204
Non-HTTP Bypass ............................................................................................................. 205
HTTP Packet Flow Modes................................................................................................. 206
High-speed HTTP Content Replacement ......................................................................... 208
HTTP Content Format ............................................................................................................................208
Configuring High-Speed HTTP Content Replacement .....................................................................208
Content Compression........................................................................................................ 209
Content Compression Overview ...........................................................................................................209
Accept-Encoding Field .....................................................................................................................209
Compression Level ...........................................................................................................................210
Hardware-Based Compression .............................................................................................................210
How ACOS Determines Whether to Compress a File .......................................................................211
Decompression for HTML Tag Insertion ............................................................................................212
Configuring Content Compression .......................................................................................................213
Temporary Compression Disable During High CPU Utilization ......................................................215
Client IP Insertion / Replacement..................................................................................... 216
Client IP Insertion / Replacement Overview .......................................................................................216
Replace Option ..................................................................................................................................217
page 6
Contents
Configuring Client IP Insertion / Replacement ..................................................................................217

Header Insertion / Erasure ................................................................................................ 218
Header Insertion / Erasure Overview ...................................................................................................218
Configuring Header Insertion / Replacement ....................................................................................219
Effects of the Insert / Replace Options ........................................................................................219
Effect When insert-always Is Used ................................................................................................219
Effect When insert-if-not-exist Is Used .........................................................................................220
Effect When Default Behavior (Neither Option Above) Is Used ...............................................220
Configuring Header Erasure ..................................................................................................................221
URL Redirect Rewrite ........................................................................................................ 222
URL Redirect Rewrite Overview ............................................................................................................222
Redirect-Rewrite Rule Matching ....................................................................................................222
Configuring URL Redirect Rewrite ........................................................................................................223
Strict Transaction Switching ............................................................................................ 224
Strict Transaction Switching Overview ...............................................................................................224
Enabling Strict Transaction Switching ................................................................................................224
HTTP Status Code Statistics ............................................................................................ 224
Client-IP Insertion Extensive Support............................................................................... 225
Configuring Client-IP Insertion ..............................................................................................................226
HTTP Load Balancing to Proxy Servers .................................................................................... 229

HTTP Load Balancing to Proxy Servers Overview ........................................................... 229
Configuring HTTP Load Balancing to Proxy Servers....................................................... 230
Increasing the HTTP Header Processing Capacity ..........................................................................230
Configuring HTTP Headers to Forward to Proxy Servers ................................................................230
Sending a TCP Reset After Server Selection Failure ................................................................. 231
SPDY Load Balancing ............................................................................................................... 235

Overview............................................................................................................................. 235
SPDY Protocol Limitations ..............................................................................................................238
Configuring SPDY Load Balancing ................................................................................... 238
SIP Load Balancing .................................................................................................................. 245

Load Balancing for SIP over UDP ..................................................................................... 245
Load Balancing for SIP over UDP Overview .......................................................................................245
Application Layer Gateway Support ..............................................................................................246
Configuring Load Balancing for SIP over UDP ...................................................................................246
Load Balancing for SIP over TCP/TLS.............................................................................. 254
SIP Multiplexing .......................................................................................................................................254
ACOS Requirements for SIP Multiplexing ....................................................................................256
Client and Server Requirements for SIP Multiplexing ...............................................................256
Client Keepalive and Server Keepalive .................................................................................................256
ACOS Actions if Selection of a Client or SIP Server Fails ................................................................257
SLB Network Address Translation for SIP over TCP / TLS .............................................................258
page 7
Contents
Configuring SIP over TCP / TLS for SIP Multiplexing .......................................................................258

Disabling Reverse NAT Based on Destination IP Address.............................................. 267
IP NAT for SIP .................................................................................................................... 269
Database Load Balancing ......................................................................................................... 271

Overview of Database Load Balancing............................................................................. 271
Configure Database Load Balancing................................................................................ 271
Use the GUI to Configure Database Load Balancing ........................................................................272
Create a Class List ............................................................................................................................272
Create the DBLB Template ..............................................................................................................273
(Optional) Create an aFleX Script for Server Selection ..............................................................273
Configure Network Resources .......................................................................................................274
Create a Virtual Server: ....................................................................................................................275
Use the CLI to Configure Database Load Balancing .........................................................................275
Create a Class List ............................................................................................................................276
Create the DBLB Template ..............................................................................................................276
Display SHA1-Encrypted Passwords ............................................................................................ 276
(optional) Create an aFleX Script for Server Selection ..............................................................276
Configure Servers .............................................................................................................................277
Configure the Service Group ...........................................................................................................277
Configure the Virtual Server ............................................................................................................277
Monitor DBLB .....................................................................................................................................277
Configuration Example – Basic DBLB ..........................................................................................277
Financial Information eXchange Load Balancing ..................................................................... 281

Overview of FIX Load Balancing ....................................................................................... 281
Tag-based Service Group Selection .....................................................................................................281
Client IP Address Insertion .....................................................................................................................281
FIX Load Balancing Example .................................................................................................................282
Configure FIX Load Balancing .......................................................................................... 282
Use the GUI to Configure FIX Load Balancing ...................................................................................283
Configure a FIX Template ...............................................................................................................284
Configure a Virtual Server for the FIX Proxy ................................................................................285
Use the CLI to Configure FIX Load Balancing ....................................................................................285
Configure a FIX Template ...............................................................................................................286
Configure a Virtual Server for the FIX Proxy ................................................................................286
CLI Configuration Example .............................................................................................................287
View FIX Traffic Statistics ................................................................................................ 288
Use the CLI to View FIX Traffic Statistics ...........................................................................................288
Short Message Peer-to-Peer Load Balancing ........................................................................... 289

Overview............................................................................................................................. 289
Configure SMPP Load Balancing (General) ..................................................................... 290
page 8
Contents
Configure SMPP Load Balancing (GUI Procedure) ...........................................................................291

Configure SMPP Load Balancing (CLI Procedure) ............................................................................294
Configure SMPP Load Balancing (CLI Example) ...............................................................................295
Display SMPP Load Balancing Statistics ............................................................................................ 298
APPLICATION OFFLOAD AND OPTIMIZATION ...........................................................................303
SSL Certificate Management and Options ................................................................................ 305

Overview of SSL Certificate Management ....................................................................... 305
The SSL Process ......................................................................................................................................306
Certificate Chain ................................................................................................................................307
Certificate Warning from Client Browser .....................................................................................309
CA-Signed and Self-Signed Certificates .......................................................................................309
SSL Templates .........................................................................................................................................310
Client-SSL Template Configuration and Usage Guidelines .............................................................310
Server-SSL Template Configuration and Usage Guidelines ............................................................312
Cipher Template Configuration and Usage Guidelines ....................................................................314
Support for TLS Server Name Indication ............................................................................................315
TLS Server Name Indication Support on vThunder ...................................................................316
Importing a Certificate and Key ........................................................................................ 317
Importing Individual Files .......................................................................................................................317
Bulk Import/Export of SSL Certificate and Key Files ........................................................................319
Generating CAs and CSRs................................................................................................. 319
Generating an SSL Cert - Private Key File with a CSR ......................................................................319
Generating a CSR .....................................................................................................................................323
Generating a Self-Signed Certificate and Key ....................................................................................324
Certificate Installation Process .............................................................................................................325
Requesting and Installing a CA-Signed Certificate ....................................................................326
Installing a Self-Signed Certificate ................................................................................................327
Creating a Client-SSL or Server-SSL Template and Binding it to a VIP ......................................... 328
Multiple CA Certificate Support in Server-SSL Templates ........................................................ 329
Support for Binding Server-SSL Templates to Individual Real Ports .....................................331
Configuring Email Notification for SSL Certificate Expiration ........................................ 332
SSL Certificate Notification via System Log Warnings ................................................... 333
Converting Certificates and CRLs to PEM Format .......................................................... 333
Converting SSL Certificates to PEM Format ...............................................................................333
Converting CRLs from DER to PEM Format ................................................................................334
Importing a CRL ................................................................................................................. 335
SSL File Delete................................................................................................................... 335
Exporting Certificates, Keys, and CRLs ............................................................................ 336
Exporting a Certificate and Key ......................................................................................................336
Exporting a CRL .................................................................................................................................337
Example of Importing a CA Cert and Private Key for SSLi .............................................. 337
Forward Proxy Alternate Signing Cert and Key................................................................ 338
Example Configuration of Forward Proxy Alternate Signing Cert and Key .................................. 338
page 9
Contents
Simple Control Enrollment Protocol (SCEP) .................................................................... 339

SCEP Certificate Enrollment and Renewal Process .........................................................................339
Configuration Using the CLI ...................................................................................................................340
Copying SCEP Files .................................................................................................................................340
Displaying SCEP Information ................................................................................................................341
Configuration Example ...........................................................................................................................341
SSL Offload and SSL Proxy ...................................................................................................... 345

Overview of SSL Offload and SSL Proxy .......................................................................... 345
Configuration Instructions for the Client SSL Template ................................................. 346
Configuration Instructions for SSL Offload ..................................................................... 347
Configuration Instructions for SSL Proxy ........................................................................ 350
SSL Ciphers........................................................................................................................ 353
Overview of SSL Cipher Support ...........................................................................................................353
Configuration Instructions for the SSL Ciphers .................................................................................353
Examples of SSL Cipher Configurations .............................................................................................354
Related Information........................................................................................................... 355
Secure FTP Proxy ..................................................................................................................... 357

Configuring SSL Offload for Secure FTPS Traffic ......................................................................359
ALG Protocol FWLB Support for FTP and SIP ........................................................................... 363
Overview of FTP and SIP................................................................................................... 363
Topologies for ALG Protocols FTP and SIP ..................................................................... 365
Persistent Sessions for ALG Protocol FWLB .....................................................................................367
FTP Persistent Sessions .................................................................................................................368
SIP Persistent Sessions ...................................................................................................................369
Configuration Parameters for ALG Protocol FWLB ..........................................................................370
Wildcard VIP .......................................................................................................................................370
Session Persistence for FTP and SIP ...........................................................................................373
Health Monitoring for FWLB Paths ...............................................................................................374
Configuration ..................................................................................................................... 375
CLI Examples for SIP ........................................................................................................................380
DNS Optimization ..................................................................................................................... 389

Global DNS Optimization .................................................................................................. 389
DNS Optimization per VIP ................................................................................................. 390
Class-List Parameters for DNS Caching .............................................................................................391
DNS Template Parameters ....................................................................................................................392
DNS Caching LID / GLID Policy Parameters ................................................................................392
DNS Cache Logging ................................................................................................................................394
Configuration ............................................................................................................................................394
Configure a Class List ...................................................................................................................... 394
Configure the GLIDs ......................................................................................................................... 395
Configure a DNS Template .............................................................................................................396
page 10
Contents
Enable DNS Caching on a VIP ........................................................................................................ 397

Display DNS Caching Information .................................................................................................397
Authentication for DNS Requests .................................................................................................398
Configuration Examples – DNS Optimization ...................................................................................398
Control Caching on Per-VIP Basis .................................................................................................398
Control Caching on Per-Record Basis ..........................................................................................399
Rate-Based DNS Caching with Rate Limiting .............................................................................401
DNS Record Weighting for Selective Cache Entry Aging ..........................................................402
Throttling Based on Domain Name ...............................................................................................403
CLI Example – Logging ....................................................................................................................404
CLI Example – Show Commands ..................................................................................................404
Authentication for DNS Requests (Example) ..............................................................................406
Load Balancing with the “DNSSEC OK” (DO) Bit.............................................................. 408
RAM Caching ........................................................................................................................... 411

Overview of RAM Caching................................................................................................. 411
RFC 2616 Support ...................................................................................................................................411
If-Modified-Since Header Support ........................................................................................................412
Support for no-cache and max-age=0 Cache-Control Headers .....................................................412
Insertion of Age and Via Headers into Cached Responses ............................................................413
Cacheability Behavior of ACOS RAM Cache .................................................................... 413
Dynamic Caching............................................................................................................... 414
Host Verification................................................................................................................ 415
Configuring RAM Caching................................................................................................. 415
CLI Configuration Examples ..................................................................................................................415
Basic Configuration ..........................................................................................................................416
Dynamic Caching Configuration ....................................................................................................419
Configuration To Flush Specific Cache Entries ..........................................................................419
Transparent Cache Switching .................................................................................................. 421

Overview............................................................................................................................. 422
Granularity of TCS ...................................................................................................................................423
Optimizing When Using Multiple Cache Servers ...............................................................................423
Application Templates ............................................................................................................................423
Support for Spoofing Caches ................................................................................................................424
High Availability Support ........................................................................................................................424
Configuring Layer 4 TCS ................................................................................................... 424
Configuring Layer 7 TCS ................................................................................................... 428
Service Type HTTP Without URL Switching Rules ...........................................................................430
Service Type HTTP with URL Switching Rules ..................................................................................431
Optimizing TCS with Multiple Cache Servers .....................................................................................433
Enabling Support for Cache Spoofing .................................................................................................434
Configuring IPv4 TCS in VRRP-A High Availability Layer 3 Inline Mode ........................ 435
ACOS-1 Configuration .............................................................................................................................438
page 11
Contents
Configuring IPv6 TCS in VRRP-A Layer 3 Inline Mode..................................................... 443

Configuring TCS for FTP ................................................................................................... 450
Configuration ............................................................................................................................................451
Configuring Bandwidth Limits Per Server or Port............................................................ 453
Configuring the Bandwidth Rate Limit for Servers and Ports ........................................................454
Configuring the Bandwidth Rate Limit Accounting ..........................................................................455
Destination Hash-Based TCS ................................................................................................... 457
STARTTLS for Secure SMTP .................................................................................................... 459

Overview of STARTTLS ..................................................................................................... 459
Additional SMTP Security Options .......................................................................................................460
Domain Switching ....................................................................................................................................461
Configuring STARTTLS ..................................................................................................... 461
Use the GUI to Configure STARTTLS ...................................................................................................462
Use the CLI to Configure STARTTLS ...................................................................................................465
STARTTLS for Server-Side Connections ......................................................................................466
STARTTLS Statistics ...............................................................................................................................467
STARTTLS for IMAP and POP3......................................................................................... 467
Diameter AAA Load Balancing ................................................................................................. 469

Overview............................................................................................................................. 469
Diameter Parameters ........................................................................................................ 471
Diameter Attribute-Value Pairs .............................................................................................................471
Load Balancing for Specific Message Codes .....................................................................................473
Timers ........................................................................................................................................................473
Accounting-Request Message Duplication ........................................................................................474
Configuring Diameter Load Balancing ............................................................................. 474
RADIUS Message Load Balancing ............................................................................................ 479

Overview of RADIUS Message Load Balancing ............................................................... 479
RADIUS Message Load Balancing Example ......................................................................................479
Server Traffic Flow for RADIUS Message Load Balancing ..............................................................480
Protocol Port Numbers Supported with Stateless RADIUS Load Balancing ...............................481
Load Balancing Across Data CPUs for the RADIUS Virtual Port Type ..........................................481
Hardware-Based Load-Balancing Methods .................................................................................481
RADIUS Session Aging ...........................................................................................................................482
Configuration RADIUS Message Load Balancing............................................................ 482
SNMP-Based Load Balancing ................................................................................................... 487

Overview of SNMP-Based Load Balancing ...................................................................... 487
Requirements ...........................................................................................................................................487
Weight-based Load Balancing ..............................................................................................................488
page 12
Contents
Sample External Health Monitor Script for SNMP-based Load Balancing ..................................489
Configuring SNMP-Based Load Balancing ...................................................................... 490
Use the GUI to Configure SNMP-Based Load Balancing .................................................................491
Use the CLI to Configure SNMP-Based Load Balancing ..................................................................491
Advanced Traffic Replication ................................................................................................... 493

Packet Header Changes .........................................................................................................................495
Traffic Replication Modes ......................................................................................................................496
Use Case Scenarios for Traffic Replication ........................................................................................497
Implementation Details ..........................................................................................................................497
Configuration ............................................................................................................................................498
Outbound Next Hop Load Distributor ....................................................................................... 499

Configuring Next Hop Load Distributor ...............................................................................................500
HTTP Proxy .............................................................................................................................. 505

Explicit and Transparent HTTP Proxy Overview .............................................................. 505
Configuration Resources for HTTP Proxy ........................................................................ 507
Configuring Transparent HTTP Proxy .................................................................................................510
Configuring Explicit HTTP Proxy ..........................................................................................................513
Basic Explicit Proxy Configuration ................................................................................................513
Advanced Explicit Proxy Configuration ........................................................................................521
Explicit Proxy Permission with AAM Policy ........................................................................................532
Explicit Proxy URL Filtering .............................................................................................................538
Logging ...............................................................................................................................................541
Log Message Format .......................................................................................................................541
Displaying HTTP Explicit Proxy Statistics ....................................................................................542
Displaying Statistics for Forward Policy ......................................................................................543
Displaying or Clearing Learned Cache Entries ............................................................................544
Displaying HTTP Explicit Proxy Web-Category Category-Lists Counters ..............................544
Proxy Chaining Overview................................................................................................... 545
Configuring Proxy Chaining ...................................................................................................................547
Explicit HTTP Proxy Configuration with Upstream Proxy Server (Proxy Chaining) ............547
Explicit Proxy and Secure Sockets Layer Insight Integration ......................................... 549
Explicit Proxy Authentication Support ............................................................................. 549
Explicit FTP Proxy .................................................................................................................... 551

Explicit FTP Proxy Overview ............................................................................................. 551
Configuration Resources for Explicit FTP Proxy ............................................................. 552
Configuring Explicit FTP Proxy ......................................................................................... 554
Displaying and Clearing SLB FTP Proxy Statistics .....................................................................560
Redirection of Traffic to ICAP Servers ...................................................................................... 563

ICAP Support Overview ..................................................................................................... 563
Configuring ICAP ............................................................................................................... 563
page 13
Contents
Redirection of Traffic to Thales HSM Devices .......................................................................... 565

Thales HSM Device Support Overview ............................................................................. 565
Installing the Thales HSM SDK .............................................................................................................566
Generate a Certificate and Key on a Thales Client .....................................................................566
Import Files and Back up the ACOS Device .................................................................................567
Install Thales HSM SDK on a x86_64 Linux Machine ................................................................567
Install Thales HSM SDK into the Current Backup System File ................................................567
Restore from the Backup on the ACOS Device ...........................................................................568
Configuring Thales HSM ........................................................................................................................568
LOGGING .............................................................................................................................571
Web Logging for HTTP and RAM Caching ................................................................................ 573

Log Message Format ........................................................................................................ 573
Configuration ..................................................................................................................... 573
Log String Customization ................................................................................................. 578
W3C Log Message Format ....................................................................................................................578
Configure the Web Logging Format .....................................................................................................580
Real-Time Logging for Failed Server Selection ......................................................................... 583

Overview............................................................................................................................. 583
Using the GUI to Configuring Real-Time Logging ............................................................ 583
Configure Logging ...................................................................................................................................584
Configure SNMP Traps ...........................................................................................................................585
Using the CLI to Configure Real-Time Logging................................................................ 586
ACOS PERFORMANCE OPTIMIZATION ....................................................................................589
Stateless Server Load Balancing .............................................................................................. 591

Overview of Stateless Server Load Balancing ................................................................. 591
Stateless Load-Balancing Methods ................................................................................. 591
Stateless Load Balancing Limitations ............................................................................. 592
Configuring Stateless Load Balancing ............................................................................. 593
Use the GUI to Configure Stateless Load Balancing ........................................................................593
Use the CLI to Configure Stateless Load Balancing ......................................................................... 593
Stateful Hash-Based Server Load Balancing ............................................................................ 595

Overview of Stateful Hash-Based Load Balancing .......................................................... 595
Stateful Hash-Based Load Balancing Methods .................................................................................595
How Hashing Works ................................................................................................................................595
Configuring Stateful Hash-Based Load Balancing .......................................................... 596
Use the GUI to Configure Stateful Hash-Based Load Balancing ....................................................596
Use the CLI to Configure Stateful Hash-Based Load Balancing ....................................................596
page 14
Contents
Auto-Switch to Stateless SLB Based on Traffic ........................................................................ 597
Generic TCP-Proxy ................................................................................................................... 601
ADDITIONAL FEATURES ........................................................................................................603
Server and Port Templates ....................................................................................................... 605

Overview............................................................................................................................. 605
Default Server and Port Templates ......................................................................................................606
Parameters That Can Be Configured Using Server and Port Templates .....................................607
Configuring Server and Port Templates ........................................................................... 610
Applying a Server or Service Port Template .................................................................... 612
Binding a Server Template to a Real Server .......................................................................................612
Binding a Server Port Template to a Real Server Port .....................................................................613
Binding a Virtual Server Template to a Virtual Server ......................................................................613
Binding a Virtual Server Port Template to a Virtual Service Port ...................................................614
Binding a Server Port Template to a Service Group .........................................................................614
Connection Limiting .......................................................................................................... 615
Setting a Connection Limit ..............................................................................................................616
Connection Rate Limiting.................................................................................................. 616
Slow-Start .......................................................................................................................... 618
Request Rate Limiting....................................................................................................... 621
Graceful Shutdown............................................................................................................ 621
Gratuitous ARPs for Subnet VIPs ..................................................................................... 622
aFlow Request Queuing .................................................................................................... 623
aFlow Control Operation ........................................................................................................................623
TCP Reset Option for Session Mismatch......................................................................... 624
Client Port Preservation .................................................................................................... 626
Health Monitoring .................................................................................................................... 627

Health Check Overview ..................................................................................................... 627
Default Health Checks ............................................................................................................................627
Health-Check Guidelines ........................................................................................................................628
Health Method Timers ............................................................................................................................628
Health Check Operation ..........................................................................................................................629
Example When Server or Port Is Unresponsive ..........................................................................629
Example When Server or Port Is Responsive ..............................................................................631
Health Method Types ........................................................................................................ 632
Protocol Port Numbers Tested by Health Checks ............................................................................638
Configuring and Applying a Health Method ..................................................................... 638
Configuring and Applying a Health Method Using the GUI ......................................................638
Configuring and Applying a Health Method Using the CLI ....................................................... 641
Configuring Health Monitoring of Virtual IP Addresses in DSR Deployments ............................641
Using the GUI .....................................................................................................................................642
page 15
Contents
Using the CLI ......................................................................................................................................643

Using Send and Receive Strings in TCP Health Checks .................................................................. 643
Certificate and Key Support in HTTPS Health Monitors ...........................................................645
Configuring POST Requests in HTTP/HTTPS Health Monitors .....................................................646
Automatic Interval Adjust Based on HTTP Status Code .................................................................648
Passive Health-monitoring Parameters .......................................................................................648
Passive Health-monitoring Activation ..........................................................................................649
Customizing DNS Health Monitors ......................................................................................................652
DNS Health Monitoring over TCP ..................................................................................................654
Overriding the Target IP Address or Protocol Port Number ........................................................... 655
Basing a Port’s Health Status on Another Port’s Health Status .....................................................657
Service Group Health Checks ........................................................................................... 658
Disable Following Failed Health Check ............................................................................ 662
In-Band Health Monitoring ................................................................................................ 662
Configuring In-Band Health Monitoring ..............................................................................................664
Consecutive Health Checks Within a Health Check Period ............................................ 665
Maintenance Health Status for Servers in Persistence Configurations ........................ 666
On-Demand Health Checks ............................................................................................... 667
Enabling Strict Retries....................................................................................................... 667
Globally Changing Health Monitor Parameters ............................................................... 668
Globally Disabling Layer 3 Health Checks .......................................................................................... 669
Health-Check Rate Limiting .............................................................................................. 669
Health-check Threshold .........................................................................................................................670
Health-Check Interval and Timeout .....................................................................................................670
Using the CLI .............................................................................................................................................670
Changing the Threshold ..................................................................................................................671
Multi-CPU Support for Health Monitoring ........................................................................ 671
Use the GUI to Configure Multi-CPU Support ....................................................................................671
Use the CLI to Configure Multi-CPU Support .....................................................................................672
Database Health Monitors ................................................................................................ 672
Database Health Monitor Parameters .................................................................................................672
Required Parameters .......................................................................................................................672
Optional Parameters ........................................................................................................................673
Using the GUI ............................................................................................................................................673
Using the CLI .............................................................................................................................................673
Kerberos Health Monitors ................................................................................................. 674
Using the GUI ............................................................................................................................................674
Using the CLI .............................................................................................................................................675
Compound Health Monitors.............................................................................................. 676
Compound Health Monitor syntax .......................................................................................................676
Considerations ..................................................................................................................................677
Using the GUI ............................................................................................................................................678
Using the CLI .............................................................................................................................................678
NOT Operator .....................................................................................................................................679
Timeout Configuration ..................................................................................................................... 679
page 16
Contents
Configurable Response Codes for RADIUS Health Monitors.......................................... 680

Displaying Health Status................................................................................................... 680
Use The GUI to View Health Status .....................................................................................................681
Use the GUI to View the Health of Virtual Servers and Service Ports ....................................681
Use the GUI to View the Health of Real Servers and Service Ports ........................................ 681
Use the CLI to View Health Status .......................................................................................................681
Use the CLI to View the Health of Virtual Servers and Service Ports .....................................682
Use the CLI to View the Health of Real Servers and Service Ports .........................................682
Use the CLI to View Health Monitoring Statistics ......................................................................683
Using External Health Methods ........................................................................................ 684
Securing External Health Monitors ......................................................................................................684
Restricting Extended Health Monitor Activity .............................................................................685
Monitoring Extended Health Monitor Activity .............................................................................685
Reviewing Extended Health Monitor Configuration ...................................................................685
Configuring External Health Monitors .................................................................................................686
Health Monitor Script Examples ...........................................................................................................688
TCL Script Example ..........................................................................................................................689
Perl Script Example ..........................................................................................................................690
Shell Script Example .........................................................................................................................691
Python Script Example ..................................................................................................................... 691
Database Health Monitoring Using a Script .......................................................................................691
Example Script—Microsoft SQL ..................................................................................................... 692
Example Script—MySQL ..................................................................................................................693
Example Script—PostgreSQL .........................................................................................................694
Example Script—Oracle ...................................................................................................................695
Alternate Real Servers and Ports for Individual Backup ........................................................... 697
Alternate Servers ............................................................................................................... 697
Configuration .....................................................................................................................................698
Alternate Ports................................................................................................................... 701
Configuration .....................................................................................................................................702
Alternate Virtual Ports for Backup ........................................................................................... 707

Overview of Alternate Virtual Ports for Backup ............................................................... 707
Supported Alternate Virtual Port Service Types ................................................................................707
Virtual Port Switchover Options ............................................................................................................707
Configure Alternate Virtual Ports for Backup .................................................................. 708
Configure Alternate Virtual Ports Using the GUI ...............................................................................708
Configure Alternate Virtual Ports Using the CLI ................................................................................709
Priority Affinity ......................................................................................................................... 711

Priority Affinity Overview................................................................................................... 711
Default Behavior (Priority Affinity Disabled) .......................................................................................711
Default Behavior (Priority Affinity Enabled) ........................................................................................712
Priority Affinity Example .........................................................................................................................712
page 17
Contents
Priority Affinity Options..................................................................................................... 714

Priority Affinity Actions ...........................................................................................................................714
Priority Affinity Triggers ..........................................................................................................................715
Actions Tied to Exceeded Limits ..........................................................................................................715
Simple Scenario – Service Group with Two Priorities ...............................................................716
More Complex Scenario – Multiple Members with Same Priority ..........................................716
Different Actions for Different Priority Levels ..............................................................................717
Configure Priority Affinity.................................................................................................. 718
Configure Priority Affinity Using the GUI ......................................................................................718
Configure Priority Affinity Using the CLI .......................................................................................718
Source-IP Persistence Override and Reselect .......................................................................... 721

Overview of Source IP Persistence Override.................................................................... 721
Default Behavior .......................................................................................................................................721
Behavior With Source-IP Persistence Override and Reselect .........................................................722
Simplified Example ..................................................................................................................................722
Use Case Scenario ...................................................................................................................................722
Configure Source IP Persistence Override ....................................................................... 723
Configure Source-IP Persistence Override Using the GUI ........................................................723
Configure Source-IP Persistence Override Using the CLI ......................................................... 723
Policy Template Binding at the Service-Group Level ................................................................ 725
Scan-All-Members Option in Persistence Templates ............................................................... 729

Configure Scan-All-Members Using the GUI ...............................................................................730
Configure Scan-All-Members Using the CLI ................................................................................732
Quality of Service Marking for TCP Traffic ............................................................................... 735
Preventing Reset of SLB and Ethernet Statistics ..................................................................... 737
Web Category ........................................................................................................................... 739
page 18
Part I Part I
Deployment
This section describes common application delivery and server load balancing deployment options.
The following topics are covered:
• “Server Load Balancing Concepts and Terminology” on page 21

• “Transparent Mode Deployment” on page 29
• “Gateway Mode Deployment” on page 47
• “Direct Server Return (DSR) SLB Deployment” on page 69
Server Load Balancing Concepts and Terminology
The primary goals of server load balancing are to:
• Share and distribute the load among multiple servers, thus improving throughput and perfor-
mance beyond the capabilities of any single server.
• Provide fault tolerance and redundancy. Distributing the load among multiple devices enables
more network reliability in the event that one server becomes unavailable.
This chapter provides an overview of server load balancing concepts, using example topologies to illus-
trate how an ACOS device can be deployed and covers these topics.
• Load Balancing Terminology
• Networking Modes
• Deployment Modes
Load Balancing Terminology

This section defines common load balancing terms that are used throughout this and other docu-
ments. Topics covered in this section include:
• Real Server
• Virtual Server and Virtual IP (VIP)
• Service Group
• Wildcard VIPs, Ports, and Virtual Ports
• Source Network Address Translation (NAT)
• Hardware Blocking VIP traffic to Unconfigured Virtual Ports
• Clearing Unused Real Server Ports
Real Server
A real server is the physical servers (either individual servers, or servers in a server farm) connected to
the ACOS device, or to another switch in the network. Figure 1 displays real servers in a basic SLB
deployment.
page 21
To configure a real server, use the slb server command from the CLI. The minimum configuration for
a real server includes the following:
• Name (for example, rs1)
• IP address (for example, 192.168.1.1) or DNS name
• Ports (for example, port 80 for TCP)
FIGURE 1 Real Servers
The following is an example of a real server configuration.
ACOS(config)# slb server rs1 192.168.1.1

ACOS(config-real server)# port 80 tcp
ACOS(config-real server-node port)#
Virtual Server and Virtual IP (VIP)

A virtual server is the combination of the real servers and ACOS device, which together appear as a sin-
gle server to the client
A virtual IP (VIP) is the virtual server IP address. Clients use this IP address to access the virtual server
and is configured on the ACOS device. To the client, the VIP represents the individual real server or
server farm.
Virtual servers and VIPs are configured by using the slb virtual-server command from the CLI. The
minimum configuration for a virtual server include the following:
• Name (for example, vs1)
• IP address (for example, 192.168.4.4)
• Ports (for example, port 80 for TCP)
page 22
FIGURE 2 Virtual Server and VIP
These commands are an example of this minimum configuration:
ACOS(config)# slb virtual-server vs1 192.168.4.4

ACOS(config-slb vserver)# port 80 tcp
ACOS(config-slb vserver-vport)#
Service Group
A service group is a group of servers that fulfill a service. Service groups are where load balancing algo-
rithms are applied. Figure 3 displays a topology that utilizes two service groups.
Service groups are configured by using the slb service-group command from the CLI. The minimum
configuration for a service group include the following:
• Name (for example, sg1)
• Type (for example, TCP)
• Load balancing algorithm (for example, round robin)
• At least one member real server and port (for example, rs1 and port 80)
page 23
FIGURE 3 Service Groups
Below is an example of this minimum configuration. First, configure two real servers “rs1” and “rs2”.
The servers will use port 80 for TCP and port 53 for UDP:

ACOS(config-real server-node port)# port 53 udp
ACOS(config-real server-node port)# exit
ACOS(config-real server)# exit
Then, configure the service group “SG_TCP” and add the servers (port 80 only) as members in the
group. Because round robin load balancing is the default algorithm; the method command is not neces-
sary.
ACOS(config)# slb service-group SG_TCP tcp

ACOS(config-slb svc group)# member rs1 80
ACOS(config-slb svc group-member:80)# exit
ACOS(config-slb svc group)# exit
Similarly, configure the service group “SG_UDP” to group the UDP servers. This service group also uses
round robin load balancing.
ACOS(config)# slb service-group SG_UDP udp

page 24

Wildcard VIPs, Ports, and Virtual Ports

A wildcard VIP is a VIP that does not have a specific IP address. Instead, wildcard VIPs have IP address
0.0.0.0 (for IPv4) or :: (for IPv6). Client requests sent to any IP address will be accepted when they
are received at a wildcard VIP. Below is an example configuration for a wildcard VIP that will accept
TCP requests on port 80:
ACOS(config)# slb virtual-server wildcard-vs1 0.0.0.0

ACOS(config-slb vserver-vport)# exit
ACOS(config-slb vserver)# exit
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 a feature applies, you can use an Access Control List (ACL). ACLs also can specify the subset of
clients allowed to access the VIPs, thus ensuring that only legitimate requests are allowed through to
the real servers.
Wildcard VIPs can be used for any type of load balancing. Port 0 is used as a wildcard port to match on
any port number.
Source Network Address Translation (NAT)

When load balancing traffic from the client to real servers, if the ACOS device changes the client’s
source IP address in the packets along with destination IP address translation (VIP to real server IP
address), then it is referred to as source NAT. For traffic from servers to client, the ACOS device
replaces the destination IP to be the actual client IP address.
Source NAT is required in the following cases:
• When the ACOS device is deployed in transparent mode in a multi-netted environment, for health
checking of real servers and their application ports located in other subnets.
• When the ACOS device is deployed in either transparent one-arm mode or gateway one-arm
mode.
Hardware Blocking VIP traffic to Unconfigured Virtual Ports

By default, traffic for undefined VIP ports flow through the device and are eventually dropped when pro-
cessed by a device CPU. When Hardware blocking is enabled, packets in excess of a configured thresh-
page 25
old to a specified unconfigured port are dropped before reaching the ACOS device. This feature is
available on A10 Thunder Series SPE devices.
This example enables hardware blocking of VIP traffic in excess of 1000 packets per second for TCP
traffic and 500 packets per second for UDP traffic.
ACOS(config)# slb common

ACOS(config-common)# ddos-protection packets-per-second tcp 1000
ACOS(config-common)# ddos-protection packets-per-second udp 500
ACOS(config-common)# ddos-protection enable
Clearing Unused Real Server Ports

Ports configured on real servers must be assigned to a service group to be referenced by a VIP. Ports
that are not assigned to a service group are unused and can be removed from the configuration with-
out affecting device operation.
The clear slb unused-server-ports command deletes real server ports that are not assigned to at
least one service group by removing the corresponding port statements from slb real server configura-
tions. The command removes unused ports from all real servers on the device. See the “Command Line
Interface Reference for ADC” for information about the clear slb unused-server-ports command.
This example displays the effect of the command on a real server configuration.
ACOS(config)# show running-config slb

!Section configuration: 378 bytes
!
slb server s1 10.0.0.15
port 78 tcp
port 88 tcp
port 88 udp
port 98 udp
port 98 tcp
!
slb service-group sg1 tcp
member s1 88
member s1 98
!
slb service-group sg2 udp
member s1 88
!
ACOS(config)# clear slb unused-server-ports
ACOS(config)# show running-config slb server
!
page 26
Networking Modes

port 88 tcp
port 88 udp
port 98 tcp
!
ACOS(config)#
Networking Modes
The ACOS device can be deployed on the following networking modes for server load balancing:
• Transparent (Switch) Mode
• Gateway (Router) Mode
Transparent (Switch) Mode

In transparent (switch) mode, the ACOS device behaves as a Layer 2 switch to provide support for
switching functions such as MAC forwarding, ARP, Virtual LANs (VLANs), tagged and untagged inter-
faces, static and dynamic link aggregation (trunks), and multi-netted environments. In transparent
mode, the ACOS device depends on a Layer 3 device to perform its routing.
In transparent mode, the ACOS device has a single IP interface. For multi-netted environments, you can
configure multiple VLANs. IP Source NAT will be required, to allow health checking of servers and their
application ports in other subnets. “Transparent Mode Deployment” on page 29 provides deployment
examples.
ACOS devices deployed in transparent mode do not support VRRP-A high availability.
Gateway (Router) Mode

Gateway (router) mode provides same Layer 2 functionality as transparent mode and performs Layer 3
features, such as IP NAT, Access-lists, static routes, RIP, OSPF, IS-IS, PBR, and BGP. Layer 3 features
provide flexibility when integrating the ACOS device into the network. ACOS devices in route mode sup-
ports separate IP addresses on each data interface. “Gateway Mode Deployment” on page 47
describes gateway mode and provides deployment examples.
page 27
Deployment Modes
Deployment Modes
The ACOS device can be deployed in the following modes for both networking modes.
• Inline Mode
• One-Arm Mode
Inline Mode
In-line topology is a physical topology where an ACOS device has at least two physical connections in
the network; one data Ethernet port is connected to an “upstream” router or switch and another data
Ethernet port is connected to a “downstream” switch or servers. In this topology, all traffic passes
through the ACOS device, which can increase the load on the ACOS device.
One-Arm Mode
In one-arm mode, the ACOS device is connected to a switch or router like an extended arm. All real serv-
ers and applications configured for load balancing are assigned private IP addresses; all other servers
and applications can be assigned public IP addresses with the default gateway pointing to the switch
or router. Only traffic that is destined for the VIP will go to the ACOS device. Because not all traffic is
passed through the ACOS device, one-arm topologies are often used for better performance or server
throughput.
page 28
Transparent Mode Deployment
This chapter provides examples of Layer 2 transparent mode SLB deployment.
• Transparent Inline Mode
• Transparent Mode in a Multinetted Environment
Transparent Inline Mode

This section contains the following:
• Transparent Inline Mode Topology Overview
• Transparent Inline Mode Configuration
Transparent Inline Mode Topology Overview

In this example, the ACOS device is inserted directly between the gateway router and the real servers.
the ACOS device and real servers are all in the same subnet and all use the router as their default gate-
way.
page 29
FIGURE 4 Example Transparent Inline Mode Topology
This example does not use Layer 3 Network Address Translation (NAT) but does use the default SLB
NAT settings. (For a description, see Network Address Translation for SLB.)
The arrows illustrate the flow of traffic in this topology. Requests from clients for virtual server
192.168.1.99 are routed by the Layer 3 router to the ACOS device, which then selects a real server and
sends the request to that server. The server reply passes back through the ACOS device to client.
Transparent Inline Mode Configuration

This section describes how to configure the example topology in Figure 4.
• Transparent Inline Mode Configuration (GUI Example)
• Transparent Inline Mode Configuration (CLI Example)
Transparent Inline Mode Configuration (GUI Example)
To use the GUI to configure the topology shown in Figure 4, perform the following tasks:
• Interface Configuration
• SLB Configuration - Real Servers
• SLB Configuration – Service Group
• SLB Configuration - Virtual Server
• View Services Map
page 30
Interface Configuration
To configure the IP address and default gateway:
1. Navigate to Network >> Interfaces >> Transparent.

2. Enter 192.168.1.2 in the IP Address field
3. Enter 255.255.255.0 in the IP Mask field.
4. Enter 192.168.1.1 in the Default Gateway field.
5. Click Configure.
To enable the interfaces,
1. Navigate to Network >> Interfaces > LAN.

2. Click Edit in the Actions column for interface e1.
3. On the Update Ethernet page, select Enable in the Status field.
4. Click Update.
5. Repeat this procedure for the other interfaces (e2 and e3).
SLB Configuration - Real Servers
The following screen examples show the GUI pages for basic SLB configuration.
Configure the real servers:
1. Navigate to ADC >> SLB >> Servers.

2. Click Create.
3. Enter rs1 in the Name field.
4. Enter 192.168.1.10 in the Host field.
page 31
5. In the Port section, click Create. In the Update Port page:

a. Enter 80 in the Port Number field.
b. Select TCP from the drop-down list in the Protocol field (should be the default value).
c. Click Create.
d. Repeat this procedure to create a second port, number 53 for UDP.
6. Click Update.
7. Repeat this procedure to create server rs2 with the IP address 192.168.1.20.
SLB Configuration – Service Group
Configure the service groups.
1. Navigate to ADC >> SLB >> Service Groups.

2. Click Create.
3. Enter SG_TCP in the Name field.
4. Verify that “TCP” is the protocol shown in the Protocol field (should be the default value).
5. Verify that “Round Robin” is shown in the Algorithm field (should be the default value).
6. Click Create in the Member pane. On the Create Member page:
a. Select server rs1 from the drop-down list in the Server field.
b. Enter 80 in the port field.
c. Click Create.
d. Repeat to add port server rs2, port 80 as a member to the group.
page 32
7. Click Update.
8. Repeat this procedure to create a second service group called SG_UDP, with port 53 of both serv-
ers rs1 and rs2 as members of the group.
SLB Configuration - Virtual Server
Configure the virtual servers.
1. Navigate to ADC >> SLB >> Virtual Servers.

2. Click Create.
3. Enter vip1 in the Name field.
4. Enter 192.168.1.99 in the IP Address field.
5. Click Create in the Virtual Port pane. On the next page:
a. Verify TCP is selected in the Protocol field.
b. Enter 80 in the Port field.
c. Select SG_TCP from the drop-down list in the Service Group field.
d. Click Create.
e. Repeat this procedure to add service group SG_UDP to the virtual server; be sure to select port
53 and UDP as the protocol.
6. Click Update.
page 33
View Services Map
View the services map to verify that the configuration is correct.
1. Navigate to Dashboard >> Services Map.

2. Select or search for vip1 in the left-side column.
3. Your services map should look similar to the following:
page 34
Transparent Inline Mode Configuration (CLI Example)
To use the CLI to configure the topology shown in Figure 4, perform the following tasks:
More information about any of these CLI commands can be found in the “Command Line Interface Refer-
ence for ADC”.
• Configure the Default Route and Enable Interfaces
• SLB Configuration – Real Servers
• SLB Configuration – Service Groups
• SLB Configuration – Virtual Server
Configure the Default Route and Enable Interfaces
The following commands configure the default gateway and interfaces:
ACOS(config)# ip address 192.168.1.2 /24

ACOS(config)# ip default-gateway 192.168.1.1
ACOS(config)# interface ethernet 1
ACOS(config-if:ethernet:1)# enable
ACOS(config-if:ethernet:1)# interface ethernet 2
ACOS(config-if:ethernet:2)# interface ethernet 3
ACOS(config-if:ethernet:3)# exit
SLB Configuration – Real Servers
The following commands configure the real servers and ports (80 for TCP traffic, and 53 for UDP):

SLB Configuration – Service Groups
The following commands configure the service groups, one for TCP and a second for UDP. Round-robin
will be the load balancing algorithm used for both service groups.
page 35
ACOS(config)# slb service-group SG_TCP tcp

ACOS(config-slb svc group)# method round-robin
ACOS(config-slb svc group-member:80)# member rs2 80
ACOS(config)# slb service-group SG_UDP udp
ACOS(config-slb svc group)# method round-robin
ACOS(config-slb svc group-member:80)# member rs2 53
SLB Configuration – Virtual Server
The following commands configure the virtual server and VIP, and add service groups to the VIP:
ACOS(config)# slb virtual-server vip1 192.168.1.99

ACOS(config-slb vserver-vport)# service-group SG_TCP
ACOS(config-slb vserver)# port 53 udp
ACOS(config-slb vserver-vport)# service-group SG_UDP
page 36
Transparent Mode in a Multinetted Environment

• Transparent Multinetted Deployment Topology Overview
• Transparent Multinetted Deployment Configuration
Transparent Multinetted Deployment Topology Overview

Figure 5 displays an ACOS device deployed in transparent mode in a multinetted environment.
FIGURE 5 ACOS Deployment Example – Transparent Mode in Multinetted Environment
This example is similar to the example in Figure 4, except the real servers are in separate subnets. Each
server uses the router as its default gateway, but at a different subnet address.
The arrows show the traffic flow for client-server traffic; in this example, between clients and server
192.168.1.10.
To enable the ACOS device to pass traffic for multiple subnets, the device is configured with multiple
VLANs. The interfaces in subnet 192.168.1.x are in VLAN 1. The interfaces in the 192.168.2.x subnet
are in VLAN 2.
NOTE: In this example, each ACOS interface is in only one VLAN and can there-
fore be untagged. the ACOS device could be connected to the router by a
single link, in which case the ACOS link with the router would be in two
VLANs and would need to tagged in at least one of the VLANs. (If an
page 37
interface is in multiple VLANs, the interface can be untagged in only one

of the VLANs.)
Layer 3 IP Source NAT
The default SLB NAT settings allow client traffic to reach the server in the 192.168.2.x subnet, even
though this is not the subnet that contains the ACOS device’s IP address.
However, in a multinetted environment where the ACOS device is deployed in transparent mode, source
NAT is required, to allow health checking of server 192.168.2.10 and its application port.
In this example, an address pool containing a range of addresses in the 192.168.2.x subnet is config-
ured. The pool configuration includes the default gateway for the 192.168.2.x subnet (192.168.2.1).
Without a gateway specified for the NAT pool, the ACOS device would attempt to send reply traffic
using its own gateway (192.168.1.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.
The ACOS device initiates health checks using the last (highest numbered) IP address in the pool as the
source IP address. In addition, the ACOS device will only respond to control traffic (for example, man-
agement and ICMP traffic) from the NATted subnet if the control traffic is sent to the last IP address in
the pool.
Transparent Multinetted Deployment Configuration

This section shows GUI screens and CLI commands that implement the configuration shown in
Figure 5.
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 Inline
Mode” on page 29.
• Transparent Multinetted Deployment Configuration (GUI Example)
• Transparent Multinetted Deployment Configuration (CLI Example)
Transparent Multinetted Deployment Configuration (GUI Example)
• Create the VLAN
• Create the Source NAT Pool
page 38
Create the VLAN
To create the VLAN:
1. Navigate to Network > VLAN.

2. Click Create.
3. Enter 2 in the VLAN ID field.
4. In the Untagged Ethernet field, select 2 and 4.
5. Click Create VLAN.
Create the Source NAT Pool
To create the source NAT pool:
1. Navigate to ADC >> IP Source NAT.
page 39
2. Click Create.
3. Enter pool1 in the Name field.
4. Enter 192.168.2.100 in the Start Address field.
5. Enter 192.168.2.101 in the End Address field.
6. Enter 255.255.255.0 in the Netmask field.
7. Click Create.

2. Enter 192.168.1.2 in the IP Address field
5. Click Configure.
page 40
To enable the interfaces,
1. Navigate to Network >> Interfaces > LAN.

3. On the Update Ethernet page, select Enable in the Status field.
4. Click Update.
5. Repeat this procedure for the other interfaces (e2, e3, and e4).
The following screen examples show the GUI pages for basic SLB configuration.

2. Click Create.
c. Click Create.
6. Click Update.
page 41

2. Click Create.
3. Enter sg-web in the Name field.
4. Verify that “TCP” is the protocol shown in the Protocol field (should be the default value).
c. Click Create.
d. Repeat to add port server rs2, port 80 as a member to the group.
6. Click Update.
page 42

2. Click Create.
c. Select sg-web from the drop-down list in the Service Group field.
d. Click Create.
6. Click Update.
page 43
View Services Map

page 44
Transparent Multinetted Deployment Configuration (CLI Example)
More information about any of these CLI commands can be found in the Command Line Interface Reference.
• Configure the Network Settings
• Enable the Interfaces
• Configure the VLANs
• Configure the Source NAT Pool
Configure the Network Settings
The following commands configure the global IP address and default gateway:

Enable the Interfaces
The following commands enable the Ethernet interfaces used in the example:

Configure the VLANs
The following commands configure the VLANs. By default, all ACOS Ethernet data ports are in VLAN 1,
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.
page 45
ACOS(config)# vlan 2
ACOS(config-vlan:2)# untagged ethernet 2
ACOS(config-vlan:2)# untagged ethernet 4
ACOS(config-vlan:2)# exit
Configure the Source NAT Pool
The following command configures a pool of IP addresses for use by source NAT. The pool is in the
same subnet as real server 192.168.2.10.
ACOS(config)# ip nat pool pool1 192.168.2.100 192.168.2.101 netmask /24 gateway 192.168.2.1
The following commands configure the real servers:

The following commands configure the service group.
ACOS(config)# slb service-group sg-web tcp

The following commands configure the virtual server. The source-nat command enables the IP
address pool configured above to be used for NATting health check traffic between the ACOS device
and the real server.

ACOS(config-slb vserver)# port 80 fast-http
ACOS(config-slb vserver-vport)# source-nat pool pool1
ACOS(config-slb vserver-vport)# service-group sg-web
page 46
Gateway Mode Deployment
This chapter provides examples of Layer 3 gateway mode SLB deployment.
• Gateway Inline Deployment Example
• Gateway One-Arm Deployment Example
Gateway Inline Deployment Example

This section contains the following topics:
• Gateway Inline Deployment Topology Overview
• Gateway Inline Deployment Configuration Example
page 47
Gateway Inline Deployment Topology Overview

Figure 6 displays an ACOS device deployed in gateway mode.
FIGURE 6 ACOS Deployment Example – Gateway Mode
The arrows display client-server traffic flow; in this example, between clients and server 192.168.4.101.
Real servers can reach the database server through the ACOS device just as they would through any
other router. Replies to clients still travel from the real servers through the ACOS device back to the cli-
ent.
In this example, the ACOS device has separate IP interfaces in different subnets on each interface con-
nected to the network. The ACOS device can be configured with static IP routes and enabled to run
routing protocols such as OSPF and IS-IS. The example configures a static route as the default route
through 192.0.2.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 ACOS device is a router in this deployment, downstream devices can use the ACOS device as
their 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 ACOS devices in a VRRP-A configuration is used, the downstream devices would use a float-
ing IP address shared by the two ACOS devices as their default gateway. (For more on VRRP-A, see the
Configuring VRRP-A High Availability guide.)
page 48
Source NAT is not required for this configuration. The ACOS device can send health checks to the real
servers and receive the replies without NAT.
Gateway Inline Deployment Configuration Example

This section describes how to implement the configuration shown in Figure 6.
• Configure the Gateway Inline Deployment (GUI Example)
• Configure the Gateway Inline Deployment (CLI Example)
Configure the Gateway Inline Deployment (GUI Example)
• Default Route Configuration
• SLB Configuration - Service Group
To configure the interfaces:
1. Navigate to Network >> Interfaces >> LAN.

3. Click Enable in the Status field.
4. Expand the IP pane.
5. Enter 192.0.2.10 in the “IPv4 Address” column of the table in the IP Address field.
6. Enter 255.255.255.0 in the “Netmask” column of the table in the IP Address field.
7. Click Update. (not shown in the figure).
8. Repeat the procedure to configure the other interfaces and IP addresses.
page 49
Default Route Configuration
To configure the static route:
1. Navigate to Network >> Routes >> Static IPv4 Routes.

2. Click Create.
3. Enter 0.0.0.0 in the IP Dest Address field.
4. Enter /0 in the IP Mask field.
5. Enter 192.0.2.1 in the “Next Hop IP” column of the IP Next Hop field, and click Add.
6. Click Create Route.
page 50

2. Click Create.
c. Click Create.
6. Click Update.
page 51
SLB Configuration - Service Group

2. Click Create.
4. Verify that TCP is the protocol shown in the Protocol field (should be the default value).
c. Click Create.
d. Repeat to add server rs2 as a member to the group.
6. Click Update.
page 52

2. Click Create.
c. Select sg-web from the drop-down list in the Service Group field.
d. Click Create.
6. Click Update.
page 53
View Services Map

Configure the Gateway Inline Deployment (CLI Example)
page 54
These commands enable the Ethernet interfaces used in the example and configure IP addresses on
them:

ACOS(config-if:ethernet:1)# ip address 192.0.2.10 /24
The following command configures the default route through 192.0.2.1:
ACOS(config)# ip route 0.0.0.0 /0 192.0.2.1



ACOS(config-slb vserver)# port 80 http
page 55
Gateway One-Arm Deployment Example


This section describes a one-arm deployment in gateway mode. The following topics are covered:
• Gateway One-Arm Deployment Topology Overview
• Gateway One-Arm Deployment Configuration
Gateway One-Arm Deployment Topology Overview

One-arm deployment allows the ACOS device to be added to the network without inserting the device
directly into the traffic path between clients and servers. Figure 7 shows an example of an ACOS device
deployed in route mode in a one-arm topology.
This example includes use of Access Control Lists (ACLs) to add a layer of security on top of the basic
deployment. An alternative is to use L3V partitions, which allow the ACOS device to be partitioned into
multiple logical devices with their own independent network resources. For more information, see the
Configuring Application Delivery Partitions Guide.
page 56
FIGURE 7 ACOS Deployment Example – Route Mode One-Arm Deployment
Traffic Flow
The arrows display client-server traffic flow between clients and server 192.168.10.51.
1. A client sends a request to 192.168.10.100:80.

2. The Layer 3 router forwards the request to the ACOS device.
3. The ACOS device selects a server within the VIP’s service group, and forwards the request to the
server.
4. The server reply is routed back to the ACOS device, which then forwards the reply to the client.
ACOS Interface Configuration

The ACOS device has a single physical connection to the network, through the Layer 2 switch. Two
VIPs are configured on the ACOS device:
• 192.0.2.10:80 – The ACOS device load balances requests to this VIP to the servers in DMZ1, on
subnet 192.0.2.0 /24.
• 192.168.10.100:80 – The ACOS device load balances requests to this VIP to the servers in DMZ2,
on subnet 192.168.10.0 /24.
page 57
The Layer 3 router routes requests to either VIP to the ACOS device. The ACOS physical interface
(Ethernet port 1) connected to the Layer 2 switch is configured with a separate IP interface to each real
server subnet:
• 192.0.2.2 – This IP interface is configured on Virtual Ethernet (VE) interface 10, on VLAN 10.
• 192.168.10.2 – This IP interface is configured on VE interface 20, on VLAN 20.
A default route on the ACOS device routes server reply traffic through the Layer 3 router to clients.
Traffic Blocking Between VLANs

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

The ACOS device uses source NAT to communicate with the servers. A separate pool is configured for
each server subnet. Source NAT ensures that server replies pass back through the ACOS device before
being forwarded to clients.
Gateway One-Arm Deployment Configuration

This section describes how to implement the configuration shown in Figure 7:
• Gateway One-Arm Deployment Configuration (GUI Example)
• Gateway One-Arm Deployment Configuration (CLI Example)
Gateway One-Arm Deployment Configuration (GUI Example)
Configuring the topology in Figure 7 involves the following high-level tasks:
• ACL Configuration
• Interface and VLAN Configuration
page 58
• Source NAT Pool Configuration
• SLB Configuration – Service Groups
• SLB Configuration – Virtual Servers
ACL Configuration
The ACL blocks Layer 3 traffic between VLANs. The Log option enables generation of log messages
when traffic matches the ACL and is dropped.
The log option enables logging for this ACL, but logging still must be enabled on the system level. Log-
ging is disabled by default. To configure logging, see the “Basic Setup” chapter in the System Configura-
tion and Administration Guide.
This procedure configures an ACL to block traffic from 192.0.2.x (source IP address) to 192.168.10.x
(destination IP address):
1. Navigate to Security >> Access List >> Extended.

2. Click Create.
3. Enter 101 in the ID field.
4. Click the Entry radio button in the Remark field.
5. Select IP in the Service field.
6. Select Source Address and Subnet in the Source Address field.
a. Enter 192.0.2.0 in the Address field.
b. Enter 0.0.0.255 in the Mask field.
7. Select Destination Address and Subnet in the Destination Address field.
a. Enter 192.168.10.0 in the Address field.
b. Enter 0.0.0.255 in the Mask field.
8. Select the checkbox in the Log field.
9. Click Create.
10.Repeat the procedure to configure a second ACL that will deny traffic from 192.168.10.x (source IP
address) to 192.0.2.x (destination IP address).
page 59
Interface and VLAN Configuration
To enable the physical interface:

2. Click Edit in the Actions columns for interface e1.
3. In the Status field, click Enable.
4. Click Update.
To create the VLAN:
1. Navigate to Network >> VLAN.

2. Click Create.
3. Enter 10 in the VLAN ID field.
4. Click the checkbox in the Create Virtual Interface field.
page 60
5. Select 1 from the list of interfaces in the Tagged Ethernet field.

6. Click Create VLAN.
7. Repeat the procedure to create VLAN 20.
The following GUI page configures the default route.
1. Navigate to Network >> Routes >> Static IPv4 Routes.

2. Click Create.
3. Enter 0.0.0.0 in the IP Dest Address field.
4. Enter /0 in the IP Mask field.
5. Enter 192.0.2.1 in the “Next Hop IP” column of the IP Next Hop field, and click Add.
Source NAT Pool Configuration
The following GUI pages configure the IP source NAT pools.
1. Navigate to ADC >> IP Source NAT >> IPv4 Pools.

2. Click Create.
3. Enter dmz1 in the Name field.
4. Enter 192.0.2.200 in the Start Address field.
5. Enter 192.0.2.200 in the End Address field.
page 61
6. Enter 255.255.255.0 in the Netmask field.

7. Click Create.
8. Repeat the procedure to create the pool for DMZ2 servers.
The following GUI pages configure the real servers.

2. Click Create.
3. Enter s1 in the Name field.
c. Click Create.
6. Click Update.
7. Repeat this procedure to create the other servers and ports.
page 62
SLB Configuration – Service Groups
The following GUI pages configure the service groups.

2. Click Create.
3. Enter wbgroup1 in the Name field.
4. Verify that TCP is the protocol shown in the Protocol field (should be the default value).
a. Select server s1 from the drop-down list in the Server field.
c. Click Create.
d. Repeat to add server s2 as a member to the group.
6. Click Update.
7. Repeat this procedure to create service group wbgroup2 with servers s21 and s22 as members.
page 63
SLB Configuration – Virtual Servers
The following GUI pages configure the virtual servers.

2. Click Create.
3. Enter webvip1 in the Name field.
c. Select wbgroup1 from the drop-down list in the Service Group field.
d. Expand the General Fields section, then select dmz1 from the drop-down list in the Source NAT
Pool field.
e. Click Create.
6. Click Update.
7. Repeat the procedure to create webvip2, with 192.168.10.100 as the IP address, wbgroup2 as the
service group and dmz2 as the source NAT pool.
page 64
View Services Map

2. Select or search for webvip1 and webvip2 and select both in the left-side column.
Gateway One-Arm Deployment Configuration (CLI Example)
Configuring the topology in Figure 7 involves the following high-level tasks:
• ACL Configuration
• Network Configuration
• SLB Configuration
ACL Configuration
The following commands configure ACL 101:
ACOS(config)# access-list 101 deny ip 192.0.2.10 0.0.0.255 192.168.10.100 0.0.0.255 log

ACOS(config)# access-list 102 deny ip 192.168.10.100 0.0.0.255 192.0.2.10 0.0.0.255 log
page 65
The ACL blocks Layer 3 traffic between VLANs. The log option enables generation of log messages
when traffic matches the ACL and is dropped.
The log option enables logging for this ACL, but logging still must be enabled on the system level. Log-
ging is disabled by default. To configure logging, see the “Basic Setup” chapter in the System Configura-
tion and Administration Guide.
Network Configuration
The following commands enable Ethernet interface 1:

The following commands configure VLANs 10 and 20:
ACOS(config-vlan:10)# tagged ethernet 1
ACOS(config-vlan:10)# router-interface ve 10
These commands configure IP interfaces on the VLAN’s VEs. The access-list commands bind ACL
101 to the inbound traffic direction on the interfaces. The ACL does not take effect until it is bound to
the interfaces.
ACOS(config)# interface ve 10
ACOS(config-if:ve:10)# ip address 192.0.2.2 /24
ACOS(config-if:ve:10)# access-list 101 in
ACOS(config-if:ve:10)# exit
ACOS(config-if:ve:20)# ip address 192.168.10.2 /24
ACOS(config-if:ve:20)# access-list 102 in
The following command configures the default route:
SLB Configuration
The following commands configure the source NAT pools:
ACOS(config)# ip nat pool dmz1 192.0.2.200 192.0.2.200 netmask /24

ACOS(config)# ip nat pool dmz2 192.168.10.200 192.168.10.200 netmask /24
page 66
ACOS(config)# slb server s1 192.0.2.50

The following commands configure the service groups:
ACOS(config)# slb service-group wbgroup1 tcp

ACOS(config-slb svc group)# member s1 80
ACOS(config)# slb service-group wbgroup2 tcp
The following commands configure the virtual servers:
ACOS(config)# slb virtual-server webvip1 192.0.2.10

ACOS(config-slb vserver-vport)# source-nat pool dmz1
ACOS(config-slb vserver-vport)# service-group wbgroup1
ACOS(config)# slb virtual-server webvip2 192.168.10.100
ACOS(config-slb vserver-vport)# source-nat pool dmz2
ACOS(config-slb vserver-vport)# service-group wbgroup2
page 67
page 68
Direct Server Return (DSR) SLB Deployment
This chapter provides additional deployment examples for Server Load Balancing (SLB). The following
types of deployment are shown:
• Direct Server Return in Transparent Mode
• Direct Server Return in Route Mode
• Direct Server Return in Mixed Layer 2/Layer 3 Environment
• Layer 3 Direct Server Return (IP Tunneling)
Direct Server Return in Transparent Mode

Figure 8 displays an ACOS device deployed in transparent mode, in a Direct Server Return (DSR) config-
uration. In a DSR configuration, replies from real servers do not necessarily pass through the ACOS
device.
page 69
FIGURE 8 ACOS Deployment Example – DSR in Transparent Mode
• Overview of DSR in Transparent Mode
• DSR in Transparent Mode Configuration Example
Overview of DSR in Transparent Mode

In this example, an ACOS device attaches to the network in a “one-arm” configuration. A single link con-
nects the device to the network. The link can be on a single Ethernet port or a trunk. This example uses
a single Ethernet port.
Arrows indicate client-server traffic flow. Client request traffic for virtual server IP address 192.0.2.99 is
routed to the ACOS device. Server reply traffic does not pass back through the ACOS device.
Requirements for DSR in Transparent Mode Deployment

This configuration has certain requirements:
• Requirements on the ACOS device:
• The ACOS device, virtual server, and the real servers all must be in the same subnet.
page 70
• 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
ACOS device.)
• DSR must be enabled on the virtual service ports. (Enabling DSR is equivalent to disabling desti-
nation NAT on the return traffic. This allows real servers to respond directly to clients, bypass-
ing the ACOS device and retaining the IP address of the real server in the response to the client.)
For IPv4 VIPs, DSR is supported on virtual port types (service types) TCP, UDP, FTP, and RTSP.
For IPv6 VIPs, DSR is supported on virtual port types TCP, UDP, and RTSP.
• Requirements on the real server:
• A loopback interface must be configured with the virtual server IP address.

• ARP replies from the loopback interfaces must be disabled. (This applies to the loopback inter-
faces that have the virtual server IP address.)
DSR Health Checking

Layer 3 and Layer 4-7 health checks are supported in DSR configurations.
The target of the Layer 3 health checks can be the real IP addresses of the servers, or the virtual IP
address.
• To send Layer 3 health checks to real server IP addresses, use the default Layer 3 health method
(ICMP).
• To send Layer 3 health checks to a virtual IP address:
• 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 Layer 3 health checks, then addressed to
the specific protocol port. You can use the default TCP and UDP health monitors or configure new
health monitors. The example uses the default TCP health monitor.
DSR in Transparent Mode Configuration Example

This section shows how to use the GUI to configure the topology shown in Figure 8:
• Configure DSR in Transparent Mode (GUI)
• Configuring DSR in Transparent Mode (CLI)
Configure DSR in Transparent Mode (GUI)
Configuring the topology shown in Figure 8 using the GUI involves the following steps:
• Configure the IP Address and Default Gateway
page 71
• Enable Ethernet Interfaces
• SLB Configuration - Virtual Port and Enabling DSR
This example does not include configuration of the real servers, or configuration of the virtual server,
other than the steps need to enable DSR.
Configure the IP Address and Default Gateway

5. Click Configure.
Enable Ethernet Interfaces
To enable the interfaces:

2. On the menu bar, select the LAN tab, if not already displayed.
3. Select the checkbox in the row for e1, then click Enable.
To configure the real servers:

2. Click Create.
4. Enter 192.0.2.3 in the Host field
5. In the Port section, click Create.
b. Click Create.
6. Click Update.
page 72
Repeat this procedure to create server rs2, with the IP address 192.0.2.4.
To configure the service group:

2. Click Create.
4. In the Member section, click Create.
a. Select rs1 from the drop-down list in the Server field.
c. Click Create.
d. Repeat to add server rs2 as a member.
5. Click Update.
SLB Configuration - Virtual Port and Enabling DSR

2. Click Create.
5. In the Virtual Port section, click Create.
a. Enter 80 in the Port field.
b. Expand the General section, then click the checkbox in the No Dest NAT field.
c. Click Create.
6. Click Update.
Configuring DSR in Transparent Mode (CLI)
This section shows how to use the CLI to configure the topology shown in Figure 8:
• Configuring the IP Address and Default Gateway
• Enabling the Ethernet Interfaces
page 73
• SLB Configuration - Virtual Server and Enabling DSR
• Configuration on the Real Servers
Configuring the IP Address and Default Gateway
The following commands configure the global IP address and default gateway:

Enabling the Ethernet Interfaces
The following commands enable the Ethernet interface connected to the clients and server:

To configure real servers rs1 and rs2:

To configure the service group sg-web with port 80 on rs1 and rs2 as members:

SLB Configuration - Virtual Server and Enabling DSR
To configure the virtual server vip1 and enable DSR:

page 74
Direct Server Return in Route Mode

ACOS(config-slb vserver-vport)# 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.
For example, on a Unix/Linux server:
ifconfig lo:0 192.0.2.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

• Overview and Topology of DSR in Route Mode
• Configuring DSR in Route Mode
Overview and Topology of DSR in Route Mode

Figure 9 shows an example of an ACOS device deployed in a DSR configuration in route mode.
page 75
FIGURE 9 ACOS Deployment Example – DSR in Route Mode
The configuration is similar to the DSR in transparent mode, except the ACOS device uses an IP inter-
face configured on an individual Ethernet port instead of a global IP address.
The requirements for the ACOS device and real servers are the same as those for DSR in transparent
mode. (“Direct Server Return in Transparent Mode” on page 69)
Configuring DSR in Route Mode

This section implements the Figure 9 configuration. Only the configuration that differs from deploy-
ment of DSR in transparent mode are shown. For the remainder of the configuration, see “Configure
DSR in Transparent Mode (GUI)” on page 71 or “Configuring DSR in Transparent Mode (CLI)” on
page 73.
• Configure DSR in Route Mode (GUI)
• Configure DSR in Route Mode (CLI)
Configure DSR in Route Mode (GUI)
The following configuration procedures differ from the instructions provided in “Configure DSR in
Transparent Mode (GUI)” on page 71:
• Configure an IP Address on the Ethernet Port
• Configure a Default Route
page 76
Configure an IP Address on the Ethernet Port
To configure an IP Address in the Ethernet interface:
1. Navigate to Network > Interfaces >> LAN.

2. In the Actions column, click on the Edit link for interface e3.
3. Select the Enabled radio button in the Status field.
4. Expand the IP section.
a. Enter 192.0.2.2 in the IPv4 Address column of the IP Address field.
b. Enter 255.255.255.0 in the Netmask column of the IP Address field.
c. Click Add.
5. Click Update.
Configure a Default Route
To configure a default route:

2. Enter 0.0.0.0 in the IP Address and IP Mask fields.
4. Click Configure.
Configure DSR in Route Mode (CLI)
The following configuration procedures differ from the instructions provided in “Configuring DSR in
Transparent Mode (CLI)” on page 73. These commands enable the Ethernet interface used in the exam-
ple and configure an IP address on it:

The following command configures the default route through 192.0.2.1:
page 77
Direct Server Return in Mixed Layer 2/Layer 3 Environment

The ACOS device can use servers as backups in a DSR deployment. Backup servers are not required to
be connected to the ACOS device at Layer 2 or in the same IP subnet. Figure 10 displays a topology
that includes a backup server in a different subnet. This backup server is used only when primary serv-
ers are unavailable.
In this example, two real servers are primary servers for VIP 10.10.10.99:80. They are in the same IP
subnet as the ACOS device. Each of them is configured for DSR: destination NAT is disabled on the vir-
tual 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 ACOS device
can be configured to use the server as a backup to a DSR server farm, without changing the network
topology.
FIGURE 10 Backup Server in DSR Configuration
To deploy the backup server:
• In the service group, assign a higher priority to members for the primary servers, so that the
member for the backup server has lower priority. By default, the ACOS device does not use the
lower-priority (backup) server unless all primary servers are down. Use the same priority for all
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.
page 78
Enabling destination NAT for the backup server allows the server to remain on a different subnet
from the ACOS 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 ACOS device and the server’s IP
address does not need to be changed. It can remain on a different subnet from the ACOS 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.
• Templates bound directly to a port are applied to the port in all service groups using the port.
• When binding the template to a service group member, the template applies to ports only in the
service group. The template does not apply to the same port when used in other service groups.
Configuring DSR Return in Mixed L2/L3 Environment

Configuring DSR Return in Mixed L2/L3 Environment (GUI)
This section provides GUI configuration instructions.
Configure a Port Template to Enable Destination NAT on the Backup Server’s Port
1. Navigate to ADC >> Templates >> SLB.

2. Click Create and select Port from the drop-down list.
3. Enter a name for the template in the Name field.
4. To enable destination NAT, click the checkbox in the Destination NAT field.
5. Click Create.
Configure the Service Group

2. Click Create to add a new service group.
3. Enter the service group name.
4. Add the primary servers to the service group:
a. In the Member area of the window, click Create. The Create Member window appears.
b. Select a primary server from the Server drop-down list.
c. Enter the protocol port number in the Port field.
d. Enter 16 in the Priority field.
e. Click Create.
page 79
f. Repeat for the other primary server.

5. Add the backup server to the service group:
a. In the Member area of the service group window, click Create.
b. Select the backup server from the Server drop-down list.
c. Enter the protocol port number in the Port field.
d. Enter 1 in the Priority field.
e. Select the port template for the backup server from the Server Port Template drop-down list.
This is the template configured earlier.
f. Click Create.
6. Click Update.
To set the priority values of the primary servers to a higher value than the backup server, re-add the
members for the primary servers’ ports, and use the priority option. Set the priority to a value higher
than 1 (the default). Use the same priority value on each of the primary server’s member ports.
To enable destination NAT on a service port within a service group, use the dest-nat option in a server
port template, then bind that template to the server port in the service group.
Configuring DSR Return in Mixed L2/L3 Environment (CLI)
The following commands configure a server port template for the backup server:
ACOS(config)# slb template port dsrbackup

ACOS(config-rport)# dest-nat
ACOS(config-rport)# exit
These commands add members to the service group. (Configuration commands for component mem-
bers are not included):
ACOS(config)# slb service-group sg-dsr tcp

ACOS(config-slb svc group)# member primarys1 80
ACOS(config-slb svc group-member:80)# priority 16
ACOS(config-slb svc group)# member primarys2 80
ACOS(config-slb svc group)# member secondarys1 80
ACOS(config-slb svc group-member:80)# template dsrbackup
page 80
Layer 3 Direct Server Return (IP Tunneling)

ACOS supports IP-in-IP Tunneling. You can use this capability to deploy Layer 3 Direct Server Return
(L3 DSR). When configuring DSR, the real server members in the Service Group must be listening on the
same port. Port translation is not supported in Direct Server Return topologies.
• Overview of Layer 3 DSR
• Layer 3 DSR Configuration Example
Overview of Layer 3 DSR

When DSR is enabled, the ACOS device sends client requests to back-end servers in an IP-in-IP tunnel.
These servers respond directly to clients, bypassing the ACOS device. (With L2 DSR, the ACOS device
must be on the same subnet as the real servers. With L3 DSR, the device and real servers can be sepa-
rated by a router.)
The packets from the real servers must appear as though they are actually coming from the ACOS VIP
and not from the real servers. Using IP-in-IP Tunneling helps make this happen.
Methods to Display the ACOS VIP as the Source Address

In previous releases, the ACOS device supports L3 DSR by using the Differentiated Services Code Point
(DSCP) field. This field is not used to support QoS (as per its original intention), but is instead used to
create a mapping between the DSCP value and the VIPs on the ACOS device. This information is then
stored in a table on the real server, and the server uses the table as a reference when it needs to know
which VIP to include as the Source Address in the packet it sends back to the client.
Using the DSCP value to encode VIP-mappings may not work in all network environments. For example,
the feature is not supported on Windows-based servers.
This release introduces a new mechanism that can be used to get the VIP to appear as the Source
Address in the packet that the real server sends back to the client. This new approach is called IP-in-IP
Tunneling, and it provides a helpful alternative for L3 DSR deployments in which DSCP is not sup-
ported.
IP-in-IP Tunneling for L3 DSR Routing

IP-in-IP Tunneling, or just “IP tunneling”, is commonly used to connect networks that use incompatible
protocols. When traffic from a source network arrives at a network that uses an incompatible protocol
(such as IPv4 and IPv6), the IP tunneling protocol can be used to add an outer header to the original
packet, thus encapsulating the original packet in another packet.
page 81
Through this process of encapsulating the original packet, traffic can be reliably carried from the
source network, across a dissimilar transit network, and back to a network that uses the same protocol
as the source network. When the packet reaches the far side of the IP tunnel, the outer header is
stripped off (decapsulated), and the original packet arrives intact.
When IP Tunneling for L3 DSR is enabled on the ACOS device, an extra IP header is added to the client
packet before it is forwarded over the IP tunnel to a real server. These real servers are configured to
strip off the extra IP encapsulation layer, yielding the original packet sent by the client. This packet is
intact and otherwise unaffected by the encapsulation process.
By removing the outer header, the real server now has a packet with the source address of the client
and the destination address of the ACOS VIP. (This would not have been true if the ACOS device had
used standard Source NAT and Destination NAT to process the packet.) When the real server responds
to the client, it crafts its response based upon a “pristine” packet that has not had its source and desti-
nation addresses modified by the NAT process.
When the real server responds to the client, source and destination addresses are reversed:
• The packet’s source address (originally the client IP) is changed to become the ACOS VIP.
• The packet’s destination address (originally the ACOS VIP) is changed to become the client’s IP.
IP-in-IP Tunneling for L3 DSR Routing Details include:
• Both IPv4 and IPv6 IP in IP are supported.
• Whereas using the DSCP value was only supported on Linux servers, IP tunneling for L3 DSR can
be set up on most popular brands of web servers, such as Linux, Unix, or Windows.
• IP tunneling must be configured on each real server for which IP Tunneling for L3 DSR is enabled.
Further, each real server must be configured to decapsulate the packets it receives and send
those packets to the client that originated the request.
• In Direct Server Return (DSR) configurations, member servers in a Service Group must be listen-
ing on the same port. Port translation is not supported in DSR topologies.
• For more information about IP in IP (or "ipencap"), refer to RFC 2003.
Figure 11 shows an ACOS device deployed in an L3 Direct Server Return (DSR) configuration. In DSR
configurations, replies from real servers do not pass through the ACOS device, returning directly to the
client.
In this example, the ACOS device is attached to the network in a “one-armed” configuration, through an
Ethernet port or a trunk. (Our configuration sample shown later in this section uses Ethernet port 3.)
The green arrows show the traffic flow for the traffic from the client at 3.3.3.50 and the real server at
7.7.7.50. Client requests go to the virtual server IP address at 4.4.4.118 (port 80). The ACOS device
encapsulates the packets in an IP Tunnel and then forwards them to real server. The real server de-cap-
sulates the traffic and processes the client’s original packet. However, instead of sending the traffic
page 82
back to the ACOS device, the real server sends the traffic directly to the client, bypassing the ACOS
device.
FIGURE 11 ACOS Deployment Example – IP Tunneling for DSR
DSR Health Checking

It is recommended that you configure Layer 3 or Layer 4-7 health checks, both of which are supported
in DSR configurations. When using DSR health checking, a separate service group is required for each
individual virtual server.
Layer 3 DSR Health Checks
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 transparent option enabled and alias address set to the
virtual IP address.
Layer 4-7 DSR Health Checking
Layer 4-7 health checks are sent to the same IP address as the Layer 3 health checks, and then
addressed to the specific protocol port. You can use the default TCP and UDP health monitors or con-
figure new health monitors. This example uses the default TCP health monitor.
page 83
When IP tunneling is enabled, health check packets sent to the server are encapsulated when sent
through the IP tunnel.
IP-in-IP Tunneling for L3 DSR Routing Requirements

This IP-in-IP Tunneling for L3 DSR configuration has certain requirements:
• Requirements on the ACOS device:
• In order to preserve the original client IP address, (which will be used as the destination address
for packets sent from the real server to the client), make sure not to enable Source NAT under
the virtual port where the ipinip command is used.
L3 DSR is supported on the following virtual port types (service types): TCP, UDP, FTP, TFTP,
and RTSP for both IPv4 and IPv6 protocols.
• Requirements on the real server:
• A loopback interface must be configured with the virtual server IP address. (If this does not
work on your real server, it may be helpful to configure the real server end of the IP Tunnel with
the ACOS VIP address.)
• ARP replies from the loopback interfaces must be disabled. (This applies to the loopback inter-
faces that have the virtual server IP address.)
• The real server must be configured with an IP Tunnel, and it must be configured to decapsulate
traffic received from the ACOS device over that tunnel.
Layer 3 DSR Configuration Example

This section shows how to implement the configuration shown in Figure 11.
Layer 3 DSR Configuration Example (CLI)
The following commands enable an Ethernet interface on the ACOS device:

Configure the Health Checks

ACOS(config)# health monitor hm-http
ACOS(config-health:monitor)# method http
ACOS(config-health:monitor)# exit
Globally Enable DSR Health Checking of VIPs

page 84
ACOS(config-common)# dsr-health-check-enable
ACOS(config-common)# exit
Configure the Real Servers

For this configuration, the health monitor must be configured at the service group configuration level. If
you try to apply the health monitor at the server port configuration level, the port may not come up.
ACOS(config)# slb service-group sg1 tcp

ACOS(config-slb svc group)# health-check hm-http
Configure the Virtual Server with ‘ipinip’ Option

ACOS(config)# slb virtual-server vipipinip 4.4.4.118
ACOS(config-slb vserver-vport)# service-group sg1
ACOS(config-slb vserver-vport)# ipinip
Configuration on the Real Servers
For the IP-in-IP Tunneling for L3 DSR feature to work correctly, the following configurations must be
performed on each real server that will be process traffic from the IP tunnel:
• Configure a VIP on the real server and disable ARP for it. This VIP is typically configured as a
loopback interface.
• Configure an IP-in-IP tunnel on each real server.
When properly configured, the real server decapsulates packets received from the IP tunnel, processes
requests in the client’s original packet, and sends responses directly to the client bypassing the ACOS
device.
page 85
page 86
Part II Part II
Additional Deployment
This section contains additional deployment options for application delivery and server load balancing.
• “Network Address Translation for SLB” on page 89

• “Dynamic Real Server Creation Using DNS” on page 103
• “Virtual IP Creation Based on Subnet” on page 111
• “Virtual Port Ranges” on page 113
• “Mapping Virtual IP Addresses and Real Ports” on page 117
Network Address Translation for SLB
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.
ACOS uses NAT to perform SLB.
NOTE: This chapter does not include information about Carrier Grade NAT
(CGN) or other NAT features for IPv6 migration.
Network Address Translation for SLB Overview

ACOS devices can perform source and destination NAT on client-VIP SLB traffic.
SLB Destination NAT

ACOS devices automatically perform destination NAT for client-VIP SLB traffic. Figure 12 shows an
example.
Destination NAT is disabled for virtual ports on which Direct Server Return (DSR) is enabled.
FIGURE 12 SLB NAT
page 89
By default, SLB NAT works as follows.
• Before forwarding a client packet to a real server, the ACOS device translates the destination IP
address from the virtual server IP address (VIP) to the IP address of the real server.
• ACOS 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 90.)
• The VIP and real servers are in different subnets. In cases where real servers are in a different
subnet than the VIP, source NAT ensures that reply traffic from a server will pass back through
the ACOS device. (See “Source NAT for Servers in Other Subnets” on page 93.)
Connection Reuse
Connection reuse enables you to reuse TCP connections between the ACOS device and real servers for
multiple client sessions. When you enable this feature, the ACOS device does not tear down a TCP con-
nection with the real server each time a client ends its session. Instead, the ACOS device leaves the
TCP connection established, and reuses the connection for the next client that uses the real server.
Connection reuse requires SLB source NAT. Since the TCP connection with the real server needs to
remain established after a client’s session ends, the client’s IP address cannot be used as the source
address for the connection, Instead, the source address must be an IP address from a NAT pool or pool
group configured on the ACOS device.
Configuring Connection Reuse (Procedure)

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 in an individual pool must be contiguous, but you can have gaps between ending
address in one pool and starting address in another pool. You also can use pools in different
subnets.
2. Configure a connection reuse template.
page 90
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.
These steps apply specifically to configuration of connection reuse. A complete SLB configuration
also requires standard SLB configuration steps, including configuration of the real servers and ser-
vice group.
Configuring Connection Reuse (GUI Procedure)

1. To configure a pool of addresses:
a. Select ADC > IP Source NAT.
b. Click Create. The Create IPv4 Pool window appears.
c. Enter a name for the pool.
d. Enter the start and end addresses.
e. Enter the netmask.
f. If the ACOS device is in transparent mode, enter the default gateway to use for NATted traffic.
g. To use session synchronization for NAT translations, enter the VRRP-A VRID number.
h. Click Create.
2. To configure a connection reuse template:
a. Select ADC > Templates.
b. Select Application from the menu bar.
c. Click Create, and from the drop-down menu that appears, select Connection Re-Use.
The Create Connection Re-Use Template appears.
d. Enter a name for the template.
e. Edit the other parameters or leave them at their default settings.
f. Click Create. The template appears in the connection reuse template table.
3. To enable source NAT on the virtual port:
a. Select ADC > SLB.
b. Select the Virtual Servers tab from the menu bar.
c. Select a virtual server name to edit an existing server, or click Create to add a new virtual
server.
page 91
d. If you are adding a new virtual server, enter the general server settings.
e. In the Virtual Port section, click Create.
The Create Virtual Port window appears.
f. Enter or select the port settings, if the port is new.
g. Do one of the following:
• To use a single pool or pool group for all source addresses, select the Source NAT checkbox.
• Click the pool drop-down list and select the desired pool.
• To use separate pools based on source address, use ACL binding fields to bind each ACL to
a pool.
For each binding, select the ACL ID/Name from the Access List drop-down list, select the pool
from the Source NAT Pool drop-down list, and select the desired sequence number from the
ACL Sequence Number drop-down list, and then click Add.
4. Under the Templates section (near bottom of Virtual Port window), select the “Click here to bind!”
link.
5. From the window that appears, click the Template Type drop-down menu and select Connection
reuse.
6. From the Templates menu, select the name of the conn-reuse template to be bound to the virtual
port.
7. Click Bind.
8. Click Create Virtual Port.
Configuring Connection Reuse (CLI Procedure)
Use the access-list command to configure standard ACLs that match on different client addresses:
ACOS(config)# access-list 30 permit 192.168.1.1 /24

ACOS(config)# access-list 50 permit 192.168.20.69 /24
Use the ip nat pool command to configure source NAT pools:
ACOS(config)# ip nat pool pool1 10.10.10.100 10.10.10.100 netmask /16

These commands configure a real server “s1” and a service group “group80” with server “s1” as a mem-
ber:

ACOS(config)# slb service-group group80 tcp
page 92
ACOS(config-slb svc group)# method weighted-rr

These commands configure policy-based source NAT, by binding ACLs to NAT pools on the virtual
port.

ACOS(config-slb vserver-vport)# access-list 30 source-nat-pool pool1
Source NAT for Servers in Other Subnets

ACOS allows source NAT to be enabled on a virtual port. In cases where real servers are in a different
subnet than the VIP, source NAT ensures that reply traffic from a server will pass back through the
ACOS device.
You can enable source NAT on a virtual port in either of the following ways:
• Use 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 ACOS 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 13 on page 94 shows an
example.
page 93
FIGURE 13 Multiple NAT Pools Bound to a Virtual Port
In this example, a service group has real servers that are located in two different subnets. The VIP is not
in either of the subnets. To ensure that reply traffic from a server will pass back through the ACOS
device, the ACOS 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.
For example, if SLB selects a real server in the 10.10.10.x subnet, then the source IP address is trans-
lated 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. ACOS automatically translates
the VIP address into a real server address before forwarding a request to the server.
CLI Example
The following commands implement the source NAT configuration shown in Figure 13 on page 94.
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.
page 94
Direct Server Return
ACOS(config)# access-list 100 permit ip any 10.10.10.0 /24

ACOS(config)# access-list 110 permit ip any 10.10.20.0 /24
The following commands configure the IP address pools. Each pool contains addresses in one of the
real server subnets.

The following commands bind the ACLs and IP address pools to a virtual port on the VIP:

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 ACOS device. The ACOS 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.
When DSR is enabled, only the destination MAC address is translated from the VIP’s MAC address to
the real server’s MAC address. The destination IP address is still the VIP.
To use DSR, the ACOS 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 the following method(s).
The current release does not support external health monitoring for DSR deployments. To configure
health checking for DSR, see “Configuring Health Monitoring of Virtual IP Addresses in DSR Deploy-
ments” on page 641.
For examples of DSR configurations, see “Direct Server Return (DSR) SLB Deployment” on page 69.
Configuring Direct Server Return (GUI Procedure)

1. Select ADC > SLB.
2. Make sure the Virtual Servers tab is selected on the menu bar.
3. Select the virtual server name of an existing virtual server, or click Create to add a new virtual
server.
page 95
IP NAT Support for VIPs
4. If you are adding a new virtual server, enter the basic settings, such as name and address.
5. In the Virtual Port section of the window, click Create.
The Create Virtual Port window appears.
6. Enter a name for the virtual port, select the desired protocol (UDP or TCP), and enter the port num-
ber.
7. Click on General Fields to display them.
8. Select Enabled next to No Dest NAT.
9. Click Create.
10.Click Update to complete the virtual server configuration.
Configuring Direct Server Return (CLI Procedure)
Enter the no-dest-nat command at the configuration level for the virtual port:

ACOS supports IP NAT for VIPs. This feature allows clients in a private network to connect to outside
VIP servers, without revealing the client IP addresses to the servers. Dynamic NAT and static NAT are
both supported.
The current release does not support this feature for FTP or RTSP traffic.
Priority for Source IP NAT Configurations on Individual Virtual Ports
Source IP NAT can be configured on a virtual port in the following ways:
1. ACL-based source NAT (access-list command at virtual port level)

2. VIP source NAT (slb snat-on-vip command at global configuration level)
3. aFleX policy (aflex command at virtual port level)
4. Non-ACL source NAT (source-nat command at virtual port level)
These methods are used in the order shown above for Layer 4 traffic. For Layer 7 traffic, VIP source
NAT has priority over ACL-based source NAT.
For example (Layer 4 traffic), if IP source NAT is configured using an ACL on the virtual port, and the slb
snat-on-vip command is also used, then a pool assigned by the ACL is used for traffic that is permitted
by the ACL. For traffic that is not permitted by the ACL, VIP source NAT can be used instead.
page 96
VIP Source NAT

VIP Source NAT is an SLB feature that configures VIP ports to utilize global and interface SNAT data
structures.
FIGURE 14 Non-ACL NAT – NAT Pool and Smart NAT
To configure VIP Source NAT:
1. Configure a pool, range list, or static inside source NAT mapping that includes real IP addresses 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.
4. Enable SNAT on VIP – either globally or on individual ports.
The snat-on-vip command is available in global configuration level and in virtual port configuration
level. When SNAT on VIP is globally configured, the feature is available on all ports. When SNAT on
VIP is not globally enabled, it can be enabled on individual ports.
VIP Source NAT Configuration Example (CLI Example)
The following commands configure the elements that SNAT on VIP require.
• Configure NAT on the inside and outside interfaces:

interface ve 300
ip address 1.0.0.100 255.255.255.0
ip nat inside
interface ve 400
ip address 2.0.0.100 255.255.255.0
ip nat outside
page 97
Using IP Pool Default Gateways To Forward Traffic from Real Servers
• Configure the access list and NAT pool.

access-list 1 permit any
ip nat pool natpool1 2.0.0.150 2.0.0.150 netmask /24
ip nat inside source list 1 pool natpool1
• Enable SNAT on VIP (globally).

slb common
snat-on-vip
Using IP Pool Default Gateways To Forward Traffic from

Real Servers
ACOS 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 ACOS 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
ACOS device forwards the server traffic through the pool’s default gateway.
This feature is disabled by default. To enable it, use the following commands:

ACOS(config-common)# snat-gwy-for-l3
Smart NAT for Virtual Ports

Smart NAT provides source NAT for virtual ports. The IP addresses that Smart NAT uses to create the
mappings depend on whether VRRP-A high availability is enabled and floating-IP addresses are config-
ured:
• With VRRP-A high availability – If VRRP-A high availability is configured, Smart NAT uses config-
ured floating IP addresses as NAT addresses.
• Without VRRP-A high availability – If VRRP-A high availability is not configured, then Smart NAT
uses IP address(es) on the ACOS interface connected to the real server.
In VRRP-A high availability deployments, if session synchronization is enabled, sessions created by

Smart NAT are synchronized to the backup device.
• If you use VRRP-A high availability, it is recommended to bind a given service group to only a sin-
gle virtual port. If you do bind a service group to multiple virtual ports, it is highly recommended to
assign all the virtual servers to the same VRRP-A VRID.
page 98
• When a service group is bound to a virtual port, the Smart NAT resources are created for all the
servers belonging to that service group. port. If the selected server does not have Smart NAT
resources, then they are dynamically created. In this case, some initial connections may be
dropped.
• Smart NAT applies only to ACOS devices deployed in route mode (also called “gateway” mode).
The feature is not applicable to devices deployed in transparent mode.
• Smart NAT uses protocol ports 20032-65535.
• Smart NAT is not supported on SIP, SIP-TCP, or SIPS virtual ports.
• You can configure a virtual port to use both Smart NAT and a configured NAT pool. By default,
configured pool addresses are used first and Smart NAT is used only when no more mappings
are available in the configured pool.
Optionally, you can configure Smart NAT to take precedence over the configured NAT pool. In this
case, the configured pool is used only when there are no more available mappings using Smart
NAT.
• If you do not use VRRP-A, real server IP addresses are used for the Smart NAT mappings. Up to
45 K mappings per real server port are supported. ACOS can use the same ACOS interface IP
address and port for more than one server connection. The combination of ACOS IP address and
port number (source) and server IP address and port (destination) uniquely identifies each map-
ping. Smart NAT uses only the primary IP address on an interface, even if multiple addresses are
configured on the interface.
Configure Smart NAT (GUI Procedure)
Assuming you have an existing virtual server named vs1::
1. Navigate to the ADC >> SLB >> Virtual Servers >> vs1 >> Virtual Port >> Create page.
2. Expand the General Fields section.
3. Select the checkbox in the Source NAT Auto field.
4. If you want Smart NAT to be used before a pool is used, also select the Precedence checkbox.
5. Click Create to save your changes.
Configure Smart NAT (CLI Example)
The commands in this example configure two virtual ports. Smart NAT is enabled on each virtual port.
To begin, the following commands configure the data interfaces:
page 99
ACOS(config-if:ethernet:3)# ip address 20.20.20.1 255.255.255.0
ACOS(config-if:ve10)# ip address 110.110.110.1 255.255.255.0
ACOS(config-if:ve10)# exit
ACOS(config-if:ve20)# ip address 160.160.160.1 255.255.255.0
ACOS(config-if:ve20)# exit
The following commands configure a source NAT pool, then return to the global configuration level:
ACOS(config)# ip nat pool snat-pool1 160.160.160.200 160.160.160.200 netmask /24
These commands configure real server “s1” with two TCP ports (80 and 21) and a service group for
each port:

ACOS(config)# slb service-group sg1-http tcp
ACOS(config)# slb service-group sg2-ftp tcp
The following commands configure the VIP. Smart NAT is enabled on each virtual port.

ACOS(config-slb vserver-vport)# source-nat auto precedence
ACOS(config-slb vserver-vport)# source-nat pool snat-pool1
ACOS(config-slb vserver)# port 21 ftp
ACOS(config-slb vserver-vport)# source-nat auto
ACOS(config-slb vserver-vport)# source-nat pool snat-pool1
page 100
Virtual-port TCP Maximum Segment Life for NATted Sessions
On the TCP virtual port, the precedence option is used with Smart NAT. This means Smart NAT is used
first, and the NAT pool is used only if all Smart NAT mappings are in use.
On the FTP virtual port, the precedence option is omitted. In this case, the source NAT pool is used first.
Smart NAT is used only if no more mappings are available using the pool.
The following command shows Smart NAT statistics:
ACOS(config-slb vserver-vport)# show slb server auto-nat-stats

Service VRID Nat Address Port Usage Total Used Total Freed Failed
---------------------------------------------------------------------------------------
s1:80/tcp 0 160.160.160.1 5 1513 1508 0
s1:21/ftp 0 160.160.160.1 0 0 0 0
In this example, both virtual ports use Smart NAT. The Nat Address, Port Usage, Total Used, Total
Freed, and Failed columns display the same information as the show ip nat pool statistics output.
(See the Command Line Interface Reference.)
The Service column lists the server, protocol port, and Layer 4 protocol. The VRID column lists the
VRRP-A VRID, if applicable. In this example, the ACOS device is deployed as a standalone device, so “0”
is shown in this column.
Virtual-port TCP Maximum Segment Life for NATted

Sessions
You can customize the maximum Segment Life (MSL) for source-NAT connections virtual ports. The
MSL is the maximum number of seconds a TCP segment (packet) is allowed to remain in the network.
When one of the endpoints in a TCP connection sends a FIN to close the connection, that endpoint
then enters the TIME-WAIT state.
During the TIME-WAIT state, the endpoint is not allowed to accept any new TCP connections. This
behavior is meant to ensure that the TCP endpoint does not receive a segment belonging to a previous
connection after the endpoint enters a new connection.
The TIME-WAIT state lasts up to twice the MSL. On some older TCP/IP stacks, this can result in a wait
of up to 240 seconds (4 minutes) after a FIN before the endpoint can enter a new connection.
To reduce the time between connections for these endpoints, set the MSL for individual virtual ports, to
1-1800 seconds.
Configuring Virtual-port TCP Maximum Segment Life (Procedure)
On the virtual port template configuration page, enter the desired value in the SNAT MSL field. Apply the
template to the virtual port.
page 101
Virtual-port TCP Maximum Segment Life for NATted Sessions
Configuring Virtual-port TCP Maximum Segment Life (CLI Example)
Use the snat-msl command to configure a custom MSL value for a virtual port. This example config-
ures a source-NAT MSL of 18 seconds (Configuration commands do not include for the component
service group):
ACOS(config)# ip nat pool natintf 192.168.20.48 192.168.20.48 netmask /24

ACOS(config)# slb template virtual-port ronvport
ACOS(config-vport)# snat-msl 18
ACOS(config-vport)# exit
ACOS(config)# slb virtual-server ronvip2 192.168.20.103
ACOS(config-slb vserver-vport)# service-group web
ACOS(config-slb vserver-vport)# source-nat pool natintf
ACOS(config-slb vserver-vport)# template virtual-port ronvport
page 102
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 ACOS 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. ACOS also creates a ser-
vice-group member for the server, in each service group that contains the server.
Dynamic Real Server Implementation
Creating and Maintaining Dynamic Servers

To create and maintain dynamic real servers, the ACOS 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 ACOS device
creates the server or, if the server is already created, the ACOS device refreshes its TTL. ACOS
also creates service-group members for the server and its ports.
• If the DNS server replies with a CNAME record, the ACOS device also sends a DNS query for the
CNAME.
ACOS supports multiple servers with the same hostname. For example, if the DNS server replies with a
different IP address for a hostname real server that has already been created, the ACOS device creates
a second real server with the same hostname and the new IP address.
When 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 age out based on TTL values returned by the DNS server. ACOS sets a
server’s initial TTL when the server is created. The initial TTL value is the greater of:
• TTL value in the DNS reply
• DNS query interval multiplied by the min-ttl-ratio (described in “Template Options for Dynamically
Created Real Servers” on page 104)
page 103
Template Options for Dynamically Created Real Servers
The server’s TTL is decremented by 60 every minute. The TTL is refreshed each time the DNS server
replies with the address. When 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.
• Dynamically created real servers have higher priority than statically created real servers, by
default. If your configuration uses a combination of dynamically created real servers and stati-
cally created real servers, the dynamically created real servers are used more. This is true even if
you leave the default load-balancing method, round robin, enabled. (To use round robin, see
“Combining Dynamic and Static Real Servers (CLI Example)” on page 109)
• 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 ACOS 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.
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 dynami-
cally created real server. Dynamically created servers are named using the following format:
prefix-ipaddr-hostname
• The prefix is the string added by the ACOS 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 63 bytes. If the name becomes longer than
63 characters, the ACOS device truncates the name to 63 bytes.
• dns-query-interval – Specifies the interval which the ACOS device sends DNS queries for IP
addresses of the dynamic real servers. You can specify 1-1440 minutes (one day). The default is
10 minutes.
page 104
Configuring Dynamic Real Server Creation
• max-dynamic-server – Specifies maximum number of real servers that can be dynamically cre-
ated for a specified hostname. You can specify 1-1023; default is 255. After the maximum num-
ber of servers is created, the oldest servers are deleted, determined by their creation time, 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 minimum TTL value for a dynamic real server, the ACOS device multiplies dns-query-
interval by min-ttl-ratio. For example, if min-ttl-ratio is 2 and dns-query-interval is 10 minutes (600
seconds), the minimum TTL for dynamic real servers is 1200. The min-ttl-ratio can be 1-15. The
default is 2.
Server Port Template Options for Dynamic Service-Group Members

• dynamic-member-priority and decrement-delta – Sets the initial priority of dynamic service-group
members, and specifies how much to decrement from the priority after each DNS query.
Within a service group, member priority determine which members can service client requests.
Normally, only the highest priority members can be used. Decrementing priorities of dynamic
members is a method to ensure the service group uses newer dynamically created members
instead of older ones.
The initial priority can be 1-16, and the default is 16. The delta can be 0-8, and the default is 0.
Priority value decrements 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 ACOS 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 pri-
ority of 1.1.1.1 is decremented by the delta value. If a later DNS query returns 1.1.1.1, 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.
Settings that apply to static servers and ports, such as connection and rate limits, apply individu-
ally to dynamically created servers or ports. 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.

You can configure dynamic real servers using the GUI or CLI.
Configuring Dynamic Real Server Creation (GUI Procedure)

1. Configure the server template:
page 105
a. Hover over ADC in the navigation bar, and select Templates from the drop-down menu.
b. Select ADC on the menu bar.
c. Click the green New Template button. A drop-down menu appears.
d. Select Server. The Create Server Template dialog appears.
e. Enter a name for the template.
f. Configure these options. (“Template Options for Dynamically Created Real Servers” on
page 104.)
• DNS Query Interval
• Dynamic Server Prefix
• Min TTL Ratio
• Max Dynamic Server
g. Click Create.
2. Create the real servers:
b. On the menu bar, select the Servers tab.
c. Click Create.
d. In the Name field, enter a name for the real server.
e. Select the address Type radio button: IPv4, IPv6, or FQDN.
f. Enter the IP Address or FQDN hostname that is known to DNS.
g. Expand the Advanced Fields, and select the template from the Template Server drop-down
menu.
h. Configure additional options for the real server and add ports, as applicable to your deployment.
i. When finished, click Create.
3. Configure a template for the server port:
a. In the Port section of the page, click Create.
b. Enter number in the Port Number field.
c. Click Advanced Fields to expand and configure the advanced options for this server port.
d. To the far-right of Template Port, click the Add+ link. The Create Port Template appears.
e. Enter a name for the port template in the Name field.
f. Configure these options. (“Template Options for Dynamically Created Real Servers” on
page 104.)
page 106
• Dynamic Member Priority

• Decrement Value
g. Click Create.
4. Configure the service group:
b. On the menu bar, select the Service Groups tab.
c. Click Create.
d. Enter a name for the service group in the Name field.
e. Click Advanced Fields to expand and configure the advanced options for this service group.
f. Select the Port template from the Template Port drop-down menu.
g. In the Member section, click Create.
h. Select the Existing Server radio button, and then select the Server from the drop-down
menu.
i. Enter the number in the Port field.
j. Click Create.
k. Click Update to complete the service group configuration.
Configuring Dynamic Real Server Creation (CLI Example)
These commands configure hostname server parameters in a server port template and a server tem-
plate:
ACOS(config)# slb template port temp-port

ACOS(config-rport)# dynamic-member-priority 12
ACOS(config)# slb template server temp-server
ACOS(config-rserver)# dns-query-interval 5
ACOS(config-rserver)# min-ttl-ratio 3
ACOS(config-rserver)# max-dynamic-server 16
ACOS(config-rserver)# exit
The following commands configure a hostname server, add a port to it, and bind the server template to
it:
ACOS(config)# slb server s-test1 s1.test.com

ACOS(config-real server)# template server temp-server
page 107
The following commands configure a static real server:
ACOS(config)# slb server s-test2 10.4.2.1

The following commands configure a service group and add the hostname server and static server to
it. The port template is bound to the member for the hostname server and port.
ACOS(config)# slb service-group sg-test tcp

ACOS(config-slb svc group)# member s-test1 80
ACOS(config-slb svc group-member:80)# template temp-port
ACOS(config-slb svc group)# member s-test2 80
This command adds the DNS server to use for resolving the real server hostname into server IP
addresses:
ACOS(config)# ip dns primary 10.10.10.10
The show slb server detail command displays detailed information for the hostname server. The
command displays configuration details, followed by details for the dynamically created servers. See
the Command Line Interface Reference for ADC for a description and examples of the command.
The following command displays service-group information. A separate row of information appears for
each dynamically created member.
ACOS# show slb service-group

Total Number of Service Groups configured: 40
Current = Current Connections, Total = Total Connections
Fwd-p = Forward packets, Rev-p = Reverse packets
Peak-c = Peak connections
Service Group Name
Service Current Total Fwd-p Rev-p Peak-c
------------------------------------------------------------------------------
*sg-test State: All Up
DRS-10.4.2.6-s2.test.com:80 0 0 0 0 0
DRS-10.4.2.5-s1.test.com:80 36 1919 5714 5631 55
s-test2:80 0 53 265 212 311
The following command displays detailed statistics for the dynamically created service-group mem-
bers:
ACOS# show slb service-group sg-test

Service group name: sg-test State: All Up
page 108
Service selection fail drop: 0

Service selection fail reset: 0
Service peak connection: 0
Service: DRS-10.4.2.6-s2.test.com:80 UP
Forward packets: 0 Reverse packets: 0
Forward bytes: 0 Reverse bytes: 0
Current connections: 0 Persistent connections: 0
Current requests: 0 Total requests: 0
Total connections: 0 Response time: 0.00 msec
Total requests succ: 0
Peak conn: 0
Service: DRS-10.4.2.5-s1.test.com:80 UP
Peak conn: 0
Service: s-test1:80 UP
Peak conn: 0
The following command displays configuration information for the service group. In this example, the
service group has dynamic members and a static member.
ACOS# show slb service-group sg-test config

Service group name: sg-test
Type: tcp Distribution: Round Robin
Health Check: None
Member Count:4
Member4: DRS-10.4.2.6-s2.test.com:80 Priority: 1
Member3: DRS-10.4.2.5-s1.test.com:80 Priority: 16
Member1: DRS-10.4.2.5-s-test2:80 Priority: 1
Member2: s-test1:80 Priority: 1
Combining Dynamic and Static Real Servers (CLI Example)
By default, dynamically created servers have the highest priority.
page 109
The following configuration contains a dynamically created server (s1) and a statically created server
(s2). The default load-balancing method (round robin) is used, but s1 is used more than s2. To config-
ure equal use of s1 and s2, the priority values for each server are explicitly set to the same value:
slb template port porttemp

dynamic-member-priority 5
!
slb server s1 s1.com
port 22 tcp
!
port 22 tcp
!
member s1 22
priority 5
template porttemp
member s2 22
!
slb virtual-server vs1 1.1.1.1
port 22 tcp
service-group sg1
Priority settings for dynamically created servers are set only using a port template, as shown in the
example.
page 110
Virtual IP Creation Based on Subnet
ACOS provides a method to configure a range of virtual IP addresses (VIPs), based on IP subnet. Using
this method, you can create a set of virtual servers that have contiguous IP addresses 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 ACOS device.
• The largest supported subnet length is /16.
• Statistics are aggregated for all VIPs in the subnet virtual server.
• In the GUI, only the first VIP in the range is visible.
Creating Subnet-based Virtual IP Addresses (GUI Procedure)

2. Click Create.
3. In the Name field, enter a name for the virtual server.
4. Select the Address Type radio button: IPv4 or IPv6.
5. Enter the address in the IP Address field.
The IP address you specify here is the starting host address in the range and must be a valid host
address. (For example, entering 192.168.1.0/24 is not valid.)
6. In the Netmask field, enter the Subnet mask. Do not use a space before or after the forward slash.
7. Click the Advanced Fields, and configure additional VIP options as required for your deployment.
8. When finished, click Create. The VIP appears in the VIP table.
page 111
Creating Subnet-based Virtual IP Addresses (CLI Example)
The following command configures a set of VIPs for IP addresses 1.1.1.5-1.1.1.255:
ACOS(config)# slb virtual-server vs1 1.1.1.5 /24
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.
page 112
Virtual Port Ranges
ACOS enables easier configuration for large ranges of virtual ports within a virtual-server configuration.
This feature may be helpful in deployments where it is desirable to have a VIP with a large number of
different virtual ports. The ability to specify a port range under a single VIP simplifies network configu-
ration, and it can be helpful within data centers or web-hosting companies that use port numbers to
identify their specific customers.
Although similar performance can be achieved using wildcard VIPs, this approach does not scale well
because wildcard VIPs limit the ACOS device to no more than 99 ACLs.
The virtual port range feature uses the range CLI option within a VIP configuration. A standard port
number is specified within the VIP, and the range option is used to create an additional number of vir-
tual ports, which will be added upon this base port.
For example, the base virtual port could be set to 80 and the range could be set to any value from 0-
254. So if the range were set to the maximum of 254, then the virtual port range could start at 80 and
go all the way up to 334 (80 + 254).
Supported Virtual Port Types

This feature is supported on the following virtual port types:
• TCP
• HTTP
• TCP-proxy
• SSL-proxy
• HTTPS
• fast-HTTP
Details:
• Statistics and configurations are applied to the virtual port as a whole and not to the individual
ports within the specified range.
• The virtual port is internally identified as the port type and the base port. When using the show
command to view statistics, you can only specify the base port. If you use the show command to
page 113
Adding A Virtual Port Range to a Virtual Server
try to view statistics for one of the auto-created virtual ports, a consolidated set of data and sta-
tistics will be provided for all virtual ports, starting from the base port and including all ports spec-
ified in the range.

Use either of the following methods to add a virtual port range to a virtual server.
NOTE: Real server and service group configuration is also required. (See “Add-
ing A Virtual Port Range to a Virtual Server (CLI Example)” on page 114.)
Adding A Virtual Port Range to a Virtual Server (GUI Procedure)
To specify a virtual port range within a VIP configuration:
1. Hover over ADC in the navigation bar, and select SLB from the drop-down menu.
2. Select Virtual Server on the menu bar.
3. Click the green Create button.
4. Enter a name for the virtual server.
5. Enter the base virtual port number in the Port field.
6. Enter the range (number of ports) in the Range field.
7. Click Update to complete the virtual server configuration.
Adding A Virtual Port Range to a Virtual Server (CLI Procedure)
To specify a virtual port range within a VIP configuration, use the range option of the port command
when configuring a port within a virtual-server configuration.
The vport-range-num option specifies the range of virtual ports you want to create within the virtual-
server configuration.
Adding A Virtual Port Range to a Virtual Server (CLI Example)
The following commands create real servers “s1” and “s2”, binds them to a service group “sg1”, and
then creates a VIP (“vip3”) at 40.40.40.4. TCP port 80 is created within the VIP configuration, and it has
a range value of “9”, meaning that 9 virtual ports will be created from port 80-89, with port 80 as the
base port. A secondary set of HTTP ports will be configured with a range of 5, meaning that the base
port will be 90, and an additional five ports will be created from 91-95.
page 114

ACOS(config-slb vserver)# port 80 tcp range 9
ACOS(config-slb vserver-vport)# template virtual-port vport1
ACOS(config-slb vserver)# port 90 http range 5
Note that the ports created with the range option must not overlap. If the TCP port range was set to 20
instead of 9 in the example above, then this would have caused a configuration error, because the TCP
port range (80+20 = 100) would have overlapped with the HTTP port range (90-95).
In this example, if a client request were to come in at vip3, port 89, it would be sent to server port 80.
However, if the port included in the destination address of the client request falls beyond the configured
range (97, for example), then there would be no match and the packet would be discarded.
page 115
page 116
Mapping Virtual IP Addresses and Real Ports
ACOS supports the ability to auto-create mappings between a VIP and a real port on a real server.
ACOS examines the IP address in a client’s request, identifies the host portion, and then adds that num-
ber to the real port for a group of servers. In this way, the ACOS device can have many ports associated
with a single VIP, and can deterministically control where incoming client requests are directed.
This feature is similar to “Virtual Port Ranges” on page 113, in that it also leverages the range CLI com-
mand option. The range option allows you to specify the number of real ports that can be auto-mapped
at the real server level. However, despite the use of this common CLI option, the two features are differ-
ent.
While the “VIP to Real Port Mapping” feature creates a range of real ports on a real server and is used to
map incoming requests to real ports on backend servers, the “Virtual Port Range” feature specifies a
range of virtual ports within the VIP configuration and makes it faster and easier to configure large
ranges of virtual ports within a virtual server configuration.
Deterministic Mapping
ACOS can be configured as a subnet VIP, with “0” for the host portion of the address. For example, the
VIP can be configured with an IP address such as 40.40.40.0 /24.
• The value of the last octet configured as the ACOS device’s VIP depends on the netmask length.
The value can be “0”, but the following additional examples are equally valid:
20.20.20.0 /24
20.20.20.240 /28
20.20.0.0 /16
20.20.20.252 /30
Configuring the ACOS device with a subnet VIP enables a single VIP to accept client requests from a
large range of VIP addresses. Instead of requiring all client requests to go to 40.40.40.1, the host por-
tion (last octet) can range from 0 – 254.
This feature creates a deterministic mapping between the host address in the client request and the
real port on the backend servers. This mapping is achieved through a simple algorithm that adds the
last octet in the destination VIP to the base port on the real server.
page 117
Deterministic Mapping
The host portion that appears in the client’s request is added to the base port configured on the real
servers. So, for example, if the client sends a packet to the VIP 10.10.10.3, then this last integer in the
address (“3”) is added to the base port configured on the backend servers (for example, 16000). The cli-
ent’s request will be mapped and forwarded to port “16000 + 3”, or real port 16003. This is shown in
Figure 15 on page 118.
FIGURE 15 VIP to real port mapping
Additional examples of how the feature works
Example #1: A client request is sent to VIP 40.40.40.111 port 80, and it must be load balanced between
three real servers having a port range from 16500–16550. (16500 is the base port in this example.)
Each one of the real servers in the service group has the same range of real ports.
ACOS adds the last octet of the VIP address (“111” for the VIP in this example) to the base port number
on the real server (16500) to arrive at 16500 + 111, or 16611.
Example #2: A client request is sent to the VIP at 216.69.188.4 port 80, and the packet must be load bal-
anced between two real servers. Although each real server has a unique IP address, each server has
the same range of ports. The base port is 16528 and the range is configured on the real server to be
254, so the range is from 16528–16782.
The last octet of the client’s destination address (“4” for this VIP) is added to the base port number on
the real server (16528 + 4) to get a mapped real port of 16532.
Mapping VIP to Real Ports: Supported Virtual Port

This feature is supported on the following virtual port types:
• TCP
page 118
Configuring VIP to Real Port Mapping
• HTTP
• HTTPS
Mapping VIP to Real Ports: Requirements

• IPv6 is not supported
• The VIP’s prefix length must be less than 32.
• The host portion of the VIP address (last octet), can not be greater than the range value.
• If the client request has a large host portion (“100”), and the range configured on the real server is
small (“5”), then there will be no mapping.

Use either of the following methods for configuration.
Configuring VIP – Real Port Mapping (GUI Procedure)
Although similar to the “vport range” feature, the “VIP to real port mapping” feature configures the range
option at the real server level, instead of at the VIP level. The “vport range” feature configures a range of
virtual ports, whereas the “VIP to real port mapping” feature configures a range of real ports.
Setting the Port Range for a Real Server
1. Access the configuration page for the server ports:

a. Hover over ADC in the navigation bar, and select SLB from the drop-down menu.
b. Select Server on the menu bar.
c. Click Create.
d. Enter the name and IP address of the server, in the Name and Host fields, respectively.
e. Click the Create button in the Port section.
2. Configure the port range:
a. Enter the base number for the range in the Port field.
b. In the Range field, enter the range of real ports you want to create within the real server config-
uration. This value can range from 0-254.
c. Click the green Create button.
3. Click Update to complete the server configuration.
page 119
Adding the Real Servers to a Service Group
1. Access the configuration page for the service group:

b. Select Service Group on the menu bar.
d. Enter a name for the service group.
e. Click the Create button in the Member section.
f. Select the server from the Server drop-down list.
g. Enter the base port number in the Port field.
h. Click Create Member.
2. Click Update to complete the service group configuration.
Enabling the VIP to Real Port Mapping within an SLB Virtual-port template
1. Access the configuration page for a virtual-port template:

a. Hover over ADC in the navigation bar, and select Templates from the drop-down menu.
b. Select ADC on the menu bar.
c. Click the green New Template button. A drop-down menu appears.
d. Select Virtual Port. The Create Virtual Port Template dialog appears.
e. Enter a name for the template.
f. Select the Allow VIP To Real Port Mapping checkbox.
g. Click Create.
2. Click Update to complete the service group configuration.
Binding the Service Group and Template to the VIP
The virtual port template containing this option must be bound to the VIP, and the VIP itself must use a
subnet for the last octet (e.g. 10.10.10.0 /24), or the feature will not work.
1. Access the configuration page for the virtual service (virtual port):
b. Select Virtual Service on the menu bar.
d. Enter a name for the virtual server. You can do either of the following:
page 120
• Create a new virtual server using the Virtual Server Name field.
• Click Use Existing Virtual Server and enter the existing virtual server’s name in the Server
Name field.
e. Enter the virtual port number in the Port field.
f. Select the service group from the Service Group drop-down list.
2. Bind the virtual-port template to the virtual port.:
a. Click the bind link under Templates.
b. Select Virtual Port from the drop-down list.
c. Select the template from the Templates drop-down list.
d. Click Bind.
3. Click Update to complete the virtual service configuration.
Configuring VIP – Real Port Mapping (CLI Example)
Although similar to the “vport range” feature, the “VIP to real port mapping” feature configures the range
option at the real server level, instead of at the VIP level. The “vport range” feature configures a range of
virtual ports, whereas the “VIP to real port mapping” feature configures a range of real ports.
The following commands create real servers “s1” at 5.5.5.1 (with a real port range of 10), real server “s2”
at 5.5.5.2 (with a range of 25), and real server “s3” at 5.5.5.3 (which does not have a range configured
and will not be used for this feature).
Include the range option for each real server to be included in the service group, but only if you want
that real server to be included in the mapping feature. The service group can be “mixed”. That is, some
real servers within a service group can have the range option set, but it is not mandatory for all servers
in a service group to be configured for “VIP to real port mapping”.

ACOS(config-real server)# port 80 tcp range 10
ACOS(config-real server)# port 80 tcp range 25
The following commands create service group “sg1” and bind the real servers to the service group:
page 121

The allow-vip-to-rport-map command enables the VIP to Real Port Mapping feature for a subnet VIP.
The virtual port template containing this option must be bound to the VIP, and the VIP itself must use a
subnet for the last octet (e.g. 10.10.10.0 /24), or the feature will not work (Configuration commands for
the vport1 virtual-port template are not included).
ACOS(config)# slb template virtual-port vport1

ACOS(config-vport)# allow-vip-to-rport-map
ACOS(config)# slb virtual-server vip3 10.10.10.0 /24
page 122
Part III Part III

Protocol Load Balancing
This section contains topics pertaining to protocol load balancing.
• “IPv4 Load Balancing” on page 125

• “IPv6 Load Balancing” on page 131
• “Layer 4 TCP/UDP Load Balancing” on page 135
• “SLB Protocol Translation” on page 145
IPv4 Load Balancing
This chapter describes load balancing of traffic based solely on transport protocol (TCP, UDP, or others
such as ICMP), without the need to specify the protocol port numbers to be load balanced.
• IPv4 Load Balancing Overview
• Configuring IPv4 Load Balancing
IPv4 Load Balancing Overview

IP protocol load balancing enables you to easily load balance traffic based solely on whether the traffic
is TCP, UDP, or others such as ICMP (not UDP or TCP), without the need to specify the protocol port
numbers to be load balanced.
You can combine IP protocol load balancing with other load balancing 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 16 shows a hypothetical example of an IP protocol load balancing deployment.
NOTE: For a real-world example, see the following document: A10 Microsoft
Exchange Server 2010 Deployment Guide. This deployment guide is avail-
able for download from the A10 Networks website.
page 125
FIGURE 16 IP Protocol Load Balancing
This example uses separate service groups for each of the following types of traffic:
• HTTP traffic addressed to TCP port 80 is sent to service group http-grp.
• All TCP traffic addressed to any TCP port except port 80 is sent to service group tcp-grp.
• All UDP traffic, addressed to any UDP port, is sent to service group udp-grp.
• All other traffic (all non TCP/UDP traffic) is sent to service group others-grp.
Although this example shows separate service groups for each type of traffic, you can use the same
service group for multiple traffic types.
In IP protocol load-balancing configurations, port 0 (zero) is used as a wildcard port and matches on
any port number. In configurations where some protocol port numbers are explicitly specified, SLB for
those ports takes precedence over SLB for the wildcard port (0). In the example above, the service
group configured for TCP port 80 is always used for client requests addressed to that port, instead of a
service group configured for the wildcard port.
page 126
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.
IPv4 Load Balancing – SLB NAT

For client request traffic to which IP protocol load balancing applies, the ACOS device translates only
the destination IP address, not the protocol port number. ACOS translates the destination IP address in
the request from the VIP address to a real server’s IP address. ACOS then sends the request to the
same protocol port number as the one requested by the client. (Likewise, the ACOS device does not
translate the port number to “0”.)
In configurations where some protocol port numbers are explicitly specified, auto port translation is still
supported for the explicitly specified port numbers. In the example above, SLB NAT can translate TCP
port 80 into another TCP port number if required by the configuration.
IPv4 Load Balancing – Template Support

For TCP or UDP, a TCP or UDP template is applied, as in other types of SLB. Optionally, you also can use
a source-IP persistence template.
For non-TCP/UDP traffic, the TCP template is used.
IPv4 Load Balancing – Direct Server Return

For either of the following types of applications, IP protocol load balancing is supported only when
Direct Server Return (DSR) is enabled on the virtual port.
• Application Layer Gateway (ALG) applications, such as FTP. For an ALG application, either enable
DSR or configure SLB explicitly for the ALG service port.
• Any application that requires inspection of any part of the client request packet other than the
destination IP address
NOTE: In the CLI, DSR is enabled by the no-dest-nat command.
Comparison of IP Protocol Load Balancing to Layer 4 TCP/UDP Load Balancing
IP protocol load balancing is similar to Layer 4 load balancing, except IP protocol load balancing
enables you to load balance non-TCP/UDP traffic. Layer 4 load balancing applies only to TCP or UDP
traffic. In addition, IP protocol load balancing uses a wildcard port number that matches on any TCP
port, UDP port, or any non-TCP/UDP port, depending on the configuration. Layer 4 load balancing
requires you to explicitly specify the protocol port numbers to load balance.
page 127
Configuring IPv4 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-bal-
anced traffic, add service port 0 (the wildcard port).
Disable health checking of port 0. Health checking does not apply to the wildcard port.
2. Configure the service group(s). To add members (real servers) for traffic to which IP protocol load
balancing will apply, specify 0 as the protocol port for the member.
3. Configure the virtual server. Bind virtual port 0 to the service group(s) that have members for port
0. Specify one of the following as the service type:
• TCP
• UDP
• Others
NOTE: For load balancing of non-TCP/UDP traffic such as ICMP, you can spec-
ify TCP or UDP as the transport protocol, in the configurations of the real
server ports and service groups. If the port number is 0 and the service
type on the virtual port is “others”, the ACOS device will load balance the
traffic as non-TCP/UDP traffic.
Configuring IPv4 Load Balancing (GUI Procedure)
Configuration of IP protocol SLB is similar to configuration of TCP/UDP SLB, with the following differ-
ences.
1. Real Server Port section (ADC > SLB > Servers > Port), enter 0 in the Port field.
2. Service Groups section (ADC > SLB > Service Groups > Member > Port), enter 0 as the port number.
3. Virtual Port section (ADC > SLB > Virtual Servers > Virtual Port), select TCP, UDP, or Others from the
Protocol drop-down list.
Configuring IPv4 Load Balancing (CLI Example)
The following commands configure the real servers shown in Figure 16 on page 126.
For simplicity, the example assumes that only the default TCP health check is used for port 80. Health
checking does not apply to the wildcard port number and is therefore disabled. Health checking of
other, explicitly specified port numbers is still supported as in previous releases.
ACOS(config)# slb server RS1 10.10.10.21

page 128

ACOS(config-real server-node port)# health-check-disable
ACOS(config-real server)# port 0 udp
The following commands configure the service groups.
ACOS(config)# slb service-group http-grp tcp

ACOS(config-slb svc group)# member RS1 80
ACOS(config)# slb service-group tcp-grp tcp
page 129

ACOS(config)# slb service-group udp-grp udp
ACOS(config)# slb service-group others-grp tcp
The following commands configure the virtual server.

ACOS(config-slb vserver-vport)# service-group http-grp
ACOS(config-slb vserver-vport)# service-group tcp-grp
ACOS(config-slb vserver-vport)# service-group udp-grp
ACOS(config-slb vserver)# port 0 others
ACOS(config-slb vserver-vport)# service-group others-grp
To display configuration information and statistics, use the show commands used for other types of
SLB:
ACOS(config)# show slb virtual

ACOS(config)# show slb server
ACOS(config)# show slb service-group
ACOS(config)# show session
page 130
IPv6 Load Balancing
This chapter describes how to configure IPv6 IP load balancing on virtual servers and wildcard VIPs.
IPv6 IP load balancing for ICMP and tunnel protocols such as IPIP6 also is supported.
IPv4 to IPv6 and IPv6 to IPv4 port wildcard load balancing is not supported in the current release.
Support for IPv6 IP load balancing is end to end as shown in the following graphic:
FIGURE 17 IPv6 Load Balancing End to End
IPv6 Load Balancing Configuration Examples

IPv6 Load Balancing Configuration (CLI Example 1)
For IPv6 load balancing with a regular VIP (including an ICMP echo request/reply), follow these steps:
1. On the ACOS device, issue the following commands (configuration commands for the v6tcp ser-
vice group are not included):
ACOS(config)# slb virtual-server v6 2011::3
ACOS(config-slb vserver-vport)# name _v6_2011_3_others_65535
ACOS(config-slb vserver-vport)# service-group v6tcp
2. On a client, issue the ping ipv6 2011::3 command.

3. On the ACOS device, issue a show session command. You may repeat the steps 2 and 3 on multi-
ple clients using the same ACOS VIP.
page 131
With the configuration on the ACOS device, the ping command will function normally and an ICMP ses-
sion will be created on the ACOS device.
For IPv6 load balancing with a regular VIP, and with an IPIP6 tunnel configured on both the client and
the server, issue the following commands:
1. On the ACOS device, issue the following commands (configuration commands for the v6tcp ser-
ACOS(config)# slb virtual-server v6 2011::3
ACOS(config-slb vserver-vport)# name _v6_2011_3_others_65535
ACOS(config-slb vserver-vport)# service-group v6tcp
2. On a client and a server, configure an ipip6 tunnel.

3. Run traffic on this tunnel.
4. On the ACOS, issue a show session command. You may repeat the steps 2 and 3 on multiple cli-
ents using the same ACOS VIP.
With this configuration, tunnel traffic works correctly with an IP session created on the ACOS device.
For IPv6 load balancing with a wildcard VIP and an ICMP echo request/reply, running-config looks like
this:
slb virtual-server wv6 ::

port 0 others
name _wildcard_v6_v6_Others_0
service-group gw
no-dest-nat
With this configuration on the ACOS device, the ping command will function normally and an ICMP ses-
sion will be created on the ACOS device.
1. Configure device using the following configuration steps (configuration commands for the gw ser-
ACOS(config)# slb virtual-server wv6 ::
ACOS(config-slb vserver-vport)# name _wildcard_v6_v6_Others_0
ACOS(config-slb vserver-vport)# service-group gw
2. On the client, execute ping ipv6 2011::10.

3. On the ACOS device, execute the show session command.
4. Repeat step 2 and 3 from multiple clients on the same ACOS VIP.
page 132
5. On another client, issue the ping ipv6 2011::11 command.

6. On the ACOS device, execute CLI show session command.
For IPv6 load balancing with a wildcard VIP in a L3V partition, and with an IPIP6 tunnel configured on
both the client and the server, your running configuration will look like the following:
slb virtual-server wv6 ::

port 0 others
name _wildcard_v6_v6_Others_0
service-group gw
no-dest-nat
With this configuration, traffic on the tunnel works correctly with an IP session created on the ACOS
device.
1. Configure the ACOS device using the following configuration commands (configuration com-
mands for the gw service group are not included):
ACOS(config)# slb virtual-server wv6 ::
ACOS(config-slb vserver-vport)# name _wildcard_v6_v6_Others_0
ACOS(config-slb vserver-vport)# service-group gw
2. On the client and server, configure the ipip6 tunnel.

3. Run traffic on this tunnel.
4. On the ACOS device, execute the show session command.
5. While the session with the current partition exists, repeat steps 2, 3, and 4 in a different partition.
page 133
page 134
Layer 4 TCP/UDP Load Balancing
This chapter describes Layer 4 load balancing of TCP and UDP traffic and how to configure it.
Layer 4 load balancing requires specifying the protocol port numbers to be load balanced. To load bal-
ance traffic based solely on transport protocol (TCP, UDP, or other), see “IPv4 Load Balancing” on
page 125.
Layer 4 Load Balancing Overview

In addition to load balancing for well-known and widely used types of services such as HTTP, HTTPS,
and FTP, ACOS devices also support Layer 4 load balancing for custom applications. If a service you
need to load balance is not one of the well-known service types recognized by the ACOS device, you still
can configure Layer 4 TCP or UDP load balancing for the service.
Figure 18 shows an example of a Layer 4 load balancing implementation.
FIGURE 18 Layer 4 SLB
page 135
Layer 4 Load Balancing Data Structures
Layer 4 load balancing balances traffic based on the transport protocol (TCP or UDP) and the protocol
port number. The payload of the UDP or TCP packets is not examined.
In this example, a custom application is running on a server farm consisting of three real servers. Cli-
ents navigate to the VIP to use the custom application.

Service Groups
This example uses a single service group that contains all the real servers. The service group uses the
default load balancing method (round robin).
Virtual Server
The custom application on the real servers is accessed at TCP port 1020 by clients through virtual IP
address 192.168.55.55.
Templates
ACOS has default TCP and UDP templates. You can use the default template or configure another TCP
or UDP template and use that one instead. If your Layer 4 load balancing configuration is for a TCP
application and you do not bind a TCP template to the virtual port, the default TCP template is used. For
a UDP application, the default UDP template is used unless you bind another UDP template to the vir-
tual port.
Idle Timeouts
One of the parameters you can configure in TCP and UDP templates is the idle time. Depending on the
requirements of your application, you can reduce or increase the amount of time the ACOS 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 immedi-
ately terminating connections that are no longer needed.
• For more information about TCP template parameters, see the slb template tcp command in
the Command Line Interface Reference.
• For more information about UDP template parameters, see the slb template udp command in
page 136
Configurable TCP Half-Open Timer
This feature is a user configurable TCP half-open timeout that is independent of TCP idle-timeout. The
default timer for half-open connections was 60 seconds. Configurable half-open timeout values range
between 1 and 60 seconds in one-second increments. Half-open connections are visible in the show
session command output.
Using the GUI: The menu path to the TCP half-open timeout option is ADC > Templates > L4 Protocols >
Create > TCP > Template Name. You can access the option both in a configured TCP or TCP-Proxy tem-
plate.
Using the CLI: The half-open-idle-timeout command enables aging of half-open TCP sessions. A half-
open TCP session is one in which the client receives a SYN-ACK, but does not reply with an ACK. You
can set the timeout value to 1-60 seconds. The default value is 60.
Source-IP Persistence
Optionally, you also can configure a source-IP persistence template and bind it to the virtual port. The
example in this chapter uses a source-IP 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.
For more information about the source-IP persistence template parameters, see the slb template
persist source-ip command in the Command Line Interface Reference..
To configure a custom TCP or UDP template
1. Select ADC > Templates.

2. Select the L4 Protocols tab from the menu bar.
3. Click the Create button, and from the drop-down that appears, select TCP or UDP.
page 137
Configuring Layer 4 Load Balancing
The Create TCP Template window appears.

4. Enter a Name for the template.
5. Edit template settings as needed for your application.
6. Click OK.
Layer 4 Load Balancing Health Monitors
The example uses default Layer 3 and Layer 4 health monitors. The Layer 3 monitor (Ping) and applica-
ble Layer 4 monitor (TCP or UDP) are enabled by default when you configure real server and real service
ports.
You can create an external health monitor using a script and import the monitor onto the ACOS device.
For information, see “Health Monitoring” on page 627.

To configure Layer 4 load balancing:
1. Configure the real servers. Add the custom application’s TCP or UDP port number, with the applica-
ble service type (TCP or UDP).
2. Configure a service group. Add the real servers, service port, and any custom templates to the
group.
3. If applicable, configure a custom TCP or UDP template.
4. If applicable, configure a source-IP persistence template.
5. Configure the virtual server. Bind the virtual service port on the virtual server to the service group
and custom templates, if configured.
Configuring Layer 4 Load Balancing (GUI Procedure)
The example consists of the following steps:
• Configuring the Real Servers (GUI)
• Configuring the service group (GUI)
• Configuring a source-IP persistence template (GUI)
• Configuring the virtual server (GUI)
Configuring the Real Servers (GUI)
page 138
2. Select the Servers tab from the menu bar.

3. Click Create.
4. Configure basic settings for the server, such as Name and IP address Type (IPv4 or IPv6).
6. In the Port Number field, enter the protocol port number for the application.
7. Click the Protocol drop-down menu and select the transport protocol for the application, TCP or
UDP.
8. Configure other required port settings, then click Create. The application port appears in the Port
list.
9. Click Create (or Update, if modifying an existing server). The real server appears in the real server
table.
Configuring the service group (GUI)

2. Select the Service Groups tab from the menu bar.
page 139
3. Click Create.
4. Enter a Name for the service group.
5. Click the Protocol drop-down menu and select the transport protocol for the application, TCP or
UDP.
6. Click Create.
7. In the Member section of the window, click the Create button. The Create Member page appears.
8. Select the Choose Creation Type radio button:
• Existing Server – if you wish to modify an existing server.
• New Server – if you wish to create a new server for this service group (requires entering name
and IP).
9. Enter the protocol port number in the Port field.
10.Click Create.
11.Repeat step 7 through step 10 for each server and port.
12.Click Update. The service group appears in the Service Groups table.
Configuring a source-IP persistence template (GUI)

2. Select the Persistence tab from the menu bar.
3. Click Create and from the drop-down menu that appears, select Persist Source IP.
4. Enter a name for the template.
5. Edit template settings as needed for your application.
6. Click OK.
page 140
• For more information about source-IP persistence template parameters, see the slb template
persist source-ip command in the Command Line Interface Reference.
• For more information about UDP template parameters, see the slb template udp command in
Configuring the virtual server (GUI)

2. Select Virtual Servers from the menu bar, if not already selected.
3. Click Create. The Create Virtual Server page appears.
5. For the Address Type radio button, select either IPv4 or IPv6.
6. In the IP Address field, enter the virtual IP address to which clients will send requests.
7. Configure other general settings as needed for your deployment.
8. In the Virtual Port section, click Create. The Create Virtual Port window appears.
9. Enter a name for the virtual port in the Name field.
10.In the Protocol drop-down list, select the transport protocol for the application, TCP or UDP.
11.Enter the application port number in the Port field.
12.If you configured any custom templates, select them from the drop-down lists for each template
type.
13.Enter or select other values as needed.
14.Click Create. The new virtual port appears in the table.
page 141
15.Click Update. The virtual server appears in the virtual server table.
page 142
Configuring Layer 4 Load Balancing (CLI Example)
The example configures Layer 4 Load Balancing:
1. The following commands configure the real servers:

ACOS(config)# slb server tcp-2 10.10.50.2
2. The following commands configure the service group “tcp-sg” and adds the real servers as mem-
bers:
ACOS(config)# slb service-group tcp-sg tcp
ACOS(config-slb svc group)# member tcp-2 1020
3. The following commands configure a source-IP persistence template:

ACOS(config)# slb template persist source-ip app1020persist
ACOS(config-source ip persistence template)# match-type server
ACOS(config-source ip persistence template)# exit
4. The following commands configure the virtual server:

ACOS(config)# slb virtual-server web-vip 192.168.55.55
ACOS(config-slb vserver-vport)# service-group tcp-sg
ACOS(config-slb vserver-vport)# template persist source-ip app1020persist
page 143
page 144
SLB Protocol Translation
SLB Protocol Translation (SLB-PT) enables IPv4 servers to be used for serving content to IPv6 clients.
Likewise, SLB-PT enables IPv6 servers to be used for serving content to IPv4 clients. Server farms can
contain both IPv4 and IPv6 servers.
SLB-PT is supported for the following virtual port types:
• FTP
• UDP
• TCP
• HTTP
• HTTPS
• SSL-proxy
• SMTP
Figure 19 shows an example of a SLB-PT deployment that uses a mixed server farm of IPv4 and IPv6
servers to serve IPv6 clients.
FIGURE 19 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. ACOS then selects an IPv6 or IPv4 server and for-
page 145
wards the client’s request to the selected server. If the server is an IPv4 server, the ACOS device trans-
lates the IP protocol of the client’s request from IPv6 to IPv4 before forwarding it to the IPv4 server.
Likewise, when the ACOS device receives the servers’s reply, the ACOS 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.
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 ACOS 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 “Exam-
ples Using Multiple Source NAT Pools” on page 149 section describes how to use multiple pools.
CLI Example
The following commands configure the SLB-PT deployment shown in Figure 19 on page 145. All of the
CLI commands are also present in ACOS 2.2.x releases. Unlike previous releases, the ACOS 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:

ACOS(config-if:ethernet:1)# ipv6 address 2001:558:ff4e:2::100/64
ACOS(config-if:ethernet:2)# ipv6 address 2001:32::2020:2001/64
The following command configures an IPv4 source NAT pool.
ACOS(config)# ip nat pool v4natpool-1 192.168.217.200 192.168.217.202 netmask /24
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 149. Also
see the “Network Address Translation” chapter in the System Configuration and Administration Guide.)
These commands configure the IPv4 real servers. The IPv4 and IPv6 servers use the same real ports.
page 146
ACOS(config)# slb server v4server-1 192.168.217.10

ACOS(config)# slb server v4server-2 192.168.217.11
The following commands configure the IPv6 real servers:
ACOS(config)# slb server v6server-1 2001:558:ff4e:2::1

ACOS(config)# slb server v6server-2 2001:558:ff4e:2::2
page 147
The following commands configure the service groups. A separate service group is configured for each
application (real port):
ACOS(config)# slb service-group sgv4v6-http tcp

ACOS(config-slb svc group)# member v4server-1 80
ACOS(config)# slb service-group sgv4v6-dns udp
ACOS(config)# slb service-group sgv4v6-https tcp
ACOS(config)# slb service-group sgv4v6-smtp tcp
ACOS(config)# exit
page 148
The following commands import an SSL certificate and key, and configure a client-SSL template to use
them. ACOS will use the certificate and key to terminate SSL sessions between clients and the VIP.
ACOS# import cert sslcert.pem scp:

Address or name of remote host []?10.10.10.2
User name []?ACOSadmin
Password []?*********
File name [/]?sslcert.pem
ACOS# import key certkey.pem scp:
Password []?*********
File name [/]?certkey.pem
ACOS# config
ACOS(config)# slb template client-ssl cssl
ACOS(config-client SSL template)# cert sslcert.pem
ACOS(config-client SSL template)# key certkey.pem
ACOS(config-client SSL template)# exit
The following commands configure the VIP:
ACOS(config)# slb virtual-server v6vip 2001:32::2020:2000

ACOS(config-slb vserver-vport)# source-nat pool v4natpool-1
ACOS(config-slb vserver-vport)# service-group sgv4v6-http
ACOS(config-slb vserver-vport)# service-group sgv4v6-dns
ACOS(config-slb vserver)# port 443 https
ACOS(config-slb vserver-vport)# template client-ssl cssl
ACOS(config-slb vserver-vport)# service-group sgv4v6-https
ACOS(config-slb vserver)# port 25 smtp
ACOS(config-slb vserver-vport)# service-group sgv4v6-smtp
Examples Using Multiple Source NAT Pools
The example shown above uses only a single NAT pool, for access to the IPv4 servers. If multiple pools
are used, then different CLI syntax is required.
page 149
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.
ACOS(config)# ipv6 access-list v6acl-1

ACOS(config-access-list:v6acl-1)# permit ipv6 2001:32::/96 any
ACOS(config-access-list:v6acl-1)# exit
ACOS(config)# ipv6 access-list v6acl-2
ACOS(config-access-list:v6acl-2)# permit ipv6 2001:64::/96 any
ACOS(config-access-list:v6acl-2)# exit
The following commands configure the IPv4 NAT pools:

These commands access the configuration level for a virtual port on the VIP and configure the port to
use the IPv4 pools:

ACOS(config-slb vserver-vport)# access-list name v6acl-1 source-nat-pool v4natpool-3
Each access-list command 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 ACOS device receives a request for
the VIP, the ACOS device matches the client address against the source addresses in the ACLs. ACOS
then uses the IPv4 NAT pool bound to the first matching ACL.
ACOS translates the client’s request from an IPv6 packet into an IPv4 packet. ACOS replaces the cli-
ent’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.
NOTE: This is different from the behavior if a single NAT pool is used. If only one
NAT pool is bound to the virtual port, the pool is used if the client’s IP
type (IPv4 or IPv6) is not the same as the IP type of the selected server.
Otherwise, if the IP type of the client and the selected server is the same,
SLB-PT is not required for the request. The request is sent to the server
with the client’s original IP address.
page 150
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 serv-
ers. When multiple pools are bound to a virtual port, the client’s IP address must match the source
address in at least one of the ACLs associated with the pools. Otherwise, the client’s traffic is dropped.
NOTE: In the case of IPv4, IPv4 pools are still required if the VIP and the real
servers are in different IPv4 subnets. For more information, see the
“Source NAT for Servers in Other Subnets” section in the “Network
Address Translation” chapter of the System Configuration and Administra-
tion Guide.
This example builds on the example in “Multiple IPv4 Pools” on page 150. 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:
ACOS(config)# ipv6 nat pool v6natpool-1 2001:32::2020:2010 2001:32::2020:2010 netmask 64

ACOS(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:

page 151
page 152
Part IV Part IV
Application Load Balancing
This section contains topics pertaining to application load balancing.
• “FTP Load Balancing” on page 155

• “HTTP Load Balancing” on page 173
• “HTTP Options for SLB” on page 187
• “HTTP Load Balancing to Proxy Servers” on page 229
• “Sending a TCP Reset After Server Selection Failure” on page 231
• “SPDY Load Balancing” on page 235
• “SIP Load Balancing” on page 245
• “Database Load Balancing” on page 271
• “Financial Information eXchange Load Balancing” on page 281
• “Short Message Peer-to-Peer Load Balancing” on page 289
FTP Load Balancing
This chapter describes how to configure SLB for FTP services.
FTP Load Balancing Overview

FTP load balancing optimizes the download experience for clients by balancing FTP traffic across serv-
ers 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 20 shows an example of an FTP load balancing
solution.
FIGURE 20 FTP Load Balancing
In this example, FTP files are served by three real servers. Each server has the same set of files avail-
able for download. One of the servers also provides the HTML pages for the download site.
ACOS devices support both the passive and active (port) FTP modes.
The example uses the weighted-round-robin load balancing method. The ACOS device is configured to
send all HTTP requests to server ftp-2. FTP requests will be load balanced among servers ftp-2, ftp-3,
and ftp-4.
page 155
FTP Load Balancing Overview
By assigning a weight to a real server and using a weighted load-balancing metric, you can bias load-
balancing decisions to favor that server. This example assumes that the servers have equivalent
capacity and performance. The differing weights compensate for the greater load to be placed on the
server that is handling the HTTP requests.
Service Groups
This example uses two service groups. One service group contains all three FTP servers and the other
service group contains a single HTTP server. To provide the weighted load balancing described above,
the load balancing method is changed from the default (round robin) to weighted round robin for the
FTP service group.
Templates
In this example, two TCP templates are required.
• For HTTP, the default TCP template is used. You do not need to explicitly bind this template to
the HTTP port on the virtual server. ACOS automatically binds this template to a virtual TCP port
on a virtual server when you create the port, unless you explicitly bind another TCP template to
the virtual port instead.
• For FTP, a custom TCP template is required, with the idle time set to a high value, to prevent FTP
download sessions from timing out if they pause for a while. This custom TCP template must be
explicitly bound to the virtual FTP port on the virtual server. In this case, the custom template is
used instead of the default TCP template.
The default HTTP template is assigned to the virtual HTTP port by default. However, the parameters in
the default HTTP template are unset by default. For this configuration, you do not need to configure a
different HTTP template or change settings in the default one.
This example does not include configuration of server or port templates, so the default templates and
their settings are applied.
For more information server and port templates, see “Server and Port Templates” on page 605.
Health Monitors
This example uses the following health monitors to check the real servers:
• Ping – Tests Layer 3 connectivity to the servers.
• 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 ACOS device sends an HTTP Get request for the
index.html page.
• FTP – Tests the FTP port by sending a login request to the port. In this example, the default set-
tings are used: Every 30 seconds, the ACOS device sends an anonymous FTP login request to
port 21.
The Ping health monitor is configured by default and enabled by default when the real server is added.
page 156
Configuring FTP Load Balancing
The HTTP and FTP monitors must be configured and applied to the real server ports.
ACOS has default Layer 4 health checks it uses to test the TCP and UDP transport layers. This configu-
ration also uses those health checks. (For information, see “Default Health Checks” on page 627.)

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.
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 ACOS device to select the HTTP/
FTP server for FTP only 80% as often as each of the other servers.
3. Configure a TCP template and set the idle time in the template to a high value.
4. Configure a service group for HTTP and add the HTTP server to it.
5. Configure another service group for FTP and add the FTP servers to it.
6. Configure the virtual server:
a. Add TCP ports for HTTP and FTP.
b. Bind the HTTP port to the HTTP service group.
c. Bind the FTP port to the FTP service group and to the TCP template.
These sections provide GUI and CLI instructions on configuring FTP Load Balancing:
• “Configuring FTP Load Balancing (GUI Procedure)” on page 157
• “Configuring FTP Load Balancing (CLI Example)” on page 171
Configuring FTP Load Balancing (GUI Procedure)
This procedure includes the following GUI Configuration steps:
1. “To configure the health monitors” on page 158
page 157
2. “To configure the real servers” on page 160

3. “To configure the weight of the real servers” on page 161
4. “To configure the TCP template for FTP” on page 163
5. “To configure a service group for HTTP” on page 163
6. “To configure a service group member for HTTP” on page 163
7. “To configure a service group for FTP” on page 166
8. “To configure the virtual server” on page 167
9. “To configure the virtual server port” on page 167
To configure the health monitors
1. Select ADC > Health Monitors.

2. Click Create.
3. In the Name field, enter a name for the monitor.
4. Click Method Type drop-down menu and select HTTP.
5. Click Create Monitor. The new health monitor appears in the health monitor table.
6. Repeat step 2 through step 5 to configure the FTP health monitor. In step 4 select FTP instead of
HTTP.
page 158
page 159
To configure the real servers

3. Click Create.
4. Enter a name for the server in the Name field.
5. Select the Type radio button (IPv4, IPv6, FQDN).
6. Enter the IP address of the server in the Host field.
page 160
To configure the weight of the real servers
1. Still from within the Create Server page, click Advanced Fields to display additional configuration
options.
2. In this example, change the value in the Weight field to 80.
4. In the Port Number field, enter the number corresponding to HTTP (or FTP).
5. Leave the Protocol set to TCP.
6. In the Health Check radio button, click the Monitor radio button, and from the Health Monitor
drop-down menu that appears, select the HTTP or FTP health monitor you just configured. (Select
the appropriate health monitor that matches the port type you configured, either HTTP or FTP.)
7. Click Create. The new port appears in the port list.
Repeat the process to configure the real servers and the weight of the real servers for each of the other
real servers you wish to add.
page 161
page 162
NOTE: The Health Monitor column shows the Layer 3 (ICMP ping) health moni-
tors for the real servers, not the Layer4-7 health monitors for individual
server ports. Click on + to view the ports associated with the server.
To configure the TCP template for FTP

2. Select the L4 Protocols tab from the menu bar at the top of the page.
3. Click Create and select TCP from the drop-down menu.
5. In the Idle Timeout field, enter 15000.
6. Click OK. The new template appears in the SLB template table.
To configure a service group for HTTP

2. Select the Service Groups tab from the menu bar at the top of the page.
3. Click Create.
4. Enter a name in the Name field.
5. Leave the transport Protocol set to TCP.
6. In the Algorithm field, select the load balancing method. For this example, select Weighted
Round Robin.
To configure a service group member for HTTP
1. While still in the Create Service Group page, from the Member section, click the Create button to
add a member to this service group.
page 163
2. In the Choose Creation Type area, select the appropriate radio button (Existing Server or New
Server).
• If adding an existing server to this service group, select the Server drop-down and select the
existing server.
• If adding a new server to this service group, enter the real server’s name and IP address.
3. Enter the port number for this protocol in the Port field.
4. Click Create. The server and port appear in the member list.
5. Click Update to update this service group. The new service group appears in the service group
table.
Repeat this process of adding a service group and service group member for each combination of
server and port. The following example shows adding member 10.10.10.2 for port 80 to service group
http-grp.
page 164
page 165
To configure a service group for FTP
Repeat the procedure in “To configure a service group for HTTP” on page 163, with the following differ-
ences:
• 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.)
• The following example shows adding members 10.10.10.2-4 for port 21.
page 166
To configure the virtual server

2. Select Virtual Servers from the menu bar at the top of the page, if not already selected.
3. Click Create.
4. 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.
To configure the virtual server port
1. While still in the Create Virtual Server page, In the Virtual Port section, click Create. The Virtual
Server Port section appears.
2. Enter a name in the Name field. This is optional.
3. In the Protocol 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.
4. Edit the number in the Port field to match the protocol port that clients will request at the virtual IP
address.
5. Select the service group that you configured in “To configure a service group for HTTP” on
page 163 from the Service Group drop-down list.
6. Click Create. The port and service group appear in the virtual port list.
7. Repeat this process to configure the virtual server port for the FTP service.
The following example shows creating the virtual server, creating the virtual port, and assigning the ser-
vice groups.
page 167
page 168
page 169
page 170
Configuring FTP Load Balancing (CLI Example)
The following commands configure the HTTP and FTP health monitors:
ACOS(config)# health monitor http-monitor

ACOS(config)# health monitor ftp-monitor
ACOS(config-health:monitor)# method ftp
ACOS(config)# slb server ftp-2 10.10.10.2

ACOS(config-real server)# weight 80
ACOS(config-real server-node port)# health-check http-monitor
ACOS(config-real server-node port)# health-check ftp-monitor
The following commands configure the TCP template for use with FTP:
ACOS(config)# slb template tcp ftp-longidletime

ACOS(config-l4 tcp)# idle-timeout 15000
ACOS(config-l4 tcp)# exit
The following commands configure the service group for HTTP:
ACOS(config)# slb service-group HTTP-SG tcp

ACOS(config-slb service group)# member FTP-2 80
ACOS(config-slb service group-member:80)# exit
ACOS(config-slb service group)# exit
page 171
The following commands configure the service group for FTP:
ACOS(config)# slb service-group FTP-SG tcp

ACOS(config-slb service group)# method weighted-rr
ACOS(config-slb service group)# exit
The following commands configure the virtual server:
ACOS(config)# slb virtual-server FTP-VIP 192.168.10.21

ACOS(config-slb vserver-vport)# service-group HTTP-SG
ACOS(config-slb vserver-vport)# service-group FTP-SG
ACOS(config-slb vserver-vport)# template tcp ftp-longidletime
page 172
HTTP Load Balancing
This chapter describes HTTP load balancing and how to configure it.
• This chapter and other SLB configuration chapters walk through individual GUI configuration
pages. The GUI also provides smart templates for easy configuration. For information, see the
GUI online help.
• Fast-HTTP is optimized for high performance data transfer compared to regular HTTP. Due to
this optimization, fast-HTTP does not support all comprehensive HTTP capabilities such as
header insertion and manipulation. Do not use fast-HTTP for applications that require complete
data transfer integrity.
HTTP Load Balancing Overview

HTTP load balancing manages HTTP traffic across a Web server farm. Figure 21 displays an HTTP
load balancing deployment.
• Network topologies in application examples such as this one are simplified to focus on the appli-
cation. For example, the Internet router connecting the clients to an ACOS device is not shown
here. Likewise, a single ACOS device is shown. Your configuration might use an ACOS pair for
VRRP-A high availability.
page 173
HTTP Load Balancing Configuration Components
FIGURE 21 HTTP Load Balancing
In this example, a server farm consisting of three servers provides content for Web site www.exam-
ple.com. Clients access the site through its virtual IP address, 192.168.10.11. When the ACOS device
receives a client request for the HTTP port (80) on 192.168.10.11, the ACOS 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 actu-
ally consists of multiple servers. After selecting a real server, the ACOS 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.

An HTTP load balancing configuration requires the following components:
page 174
Service Groups
A service group contains a set of real servers from which the ACOS 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.
ACOS selects a server based on the load balancing method used by the service group, and on addi-
tional 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. ACOS supports the following service types for HTTP ports:
• HTTP – Complete TCP stack. Use this service type if you plan to customize 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 the port command in the CLI Reference.)
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 informa-
tion in this section is for reference but is not required reading to continue with this example.
For some of types of templates, the ACOS configuration has a “default” template that is automatically
applied to a service port unless you apply another template of the same type instead.
page 175
Service Templates
For HTTP, the ACOS configuration applies “default” templates of each of the following template types
to HTTP service ports:
• TCP-Proxy – TCP-proxy templates control TCP stack settings, including the idle timeout for TCP
connections. Unless you need to change the setting for a TCP/IP stack parameter, you can safely
allow the ACOS device to apply the default TCP-proxy template to the service types that use it.
• HTTP – HTTP templates provide many options, including options to change information in the
HTTP header, enable compression, and select a service group based on the URL requested by the
client. By default, all the options in this template are disabled or not set, so you can safely allow
the ACOS device to apply the default for this template type too.
• Connection Reuse – Allows TCP connections between the ACOS 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 90.)
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 vir-
tual 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 ACOS 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 ACOS device. The granularity of the persistence
can be set to always use the same real server port, the same real server, or the same service
group.
(For an example that uses a source-IP persistence template, see “Layer 4 TCP/UDP Load Balancing” on
page 135.)
Server and Port Templates

ACOS 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 service ports
• Default virtual-server template – Contains configuration parameters for virtual servers
page 176
Configuring HTTP Load Balancing
• 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 605
• “Config Commands: SLB Templates” chapter in the CLI Reference
Health Monitors
This example uses the following types of health monitors to check the real servers:
• Ping – A Layer 3 health method that sends an ICMP echo request to the real server’s IP address.
The server passes the health check if the ACOS device receives a ping reply.
• TCP – By default, every 30 seconds the ACOS device sends a connection request (TCP SYN) to
each load balanced TCP port on each server, in this case ports 80 and 443. A TCP port passes
the health check if the server replies to the ACOS device by sending a TCP SYN ACK. By default,
the ACOS device completes the TCP handshake.
In addition to these default health checks, you can configure health monitors for specific service types.
This example uses an HTTP health monitor, with the following default settings.
• Every 30 seconds, the ACOS device sends an HTTP GET request for the default index page.
• The HTTP service port passes the health check if the requested page is present on the server and
the server replies with an OK message (200).
(For more information about health monitors and their configurable options, see “Health Monitoring” on
page 627.)

To configure the HTTP load balancing solution described in “HTTP Load Balancing Overview” on
page 173, perform the following tasks on the ACOS 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.
page 177

• Add the HTTP service port, with service type Fast-HTTP.
• Bind the service group to the virtual port.
These sections provide GUI and CLI instructions on configuring HTTP Load Balancing:
• “Use the GUI to Configure HTTP Load Balancing” on page 178
• “Use the CLI to Configure HTTP Load Balancing” on page 185
Use the GUI to Configure HTTP Load Balancing
This procedure includes the following GUI Configuration steps:
1. “To configure an HTTP health method” on page 179

2. “To configure the real servers” on page 179
3. “To configure the real server port” on page 180
4. “To configure the service group” on page 181
5. “To configure the service group member” on page 182
6. “To create the virtual server” on page 182
7. “To configure the virtual server” on page 183
page 178
To configure an HTTP health method

2. Select the Health Monitors tab from the menu bar at the top of the page, if not already selected.
3. Click Create.
4. In the Name field in the General Fields section, enter a name for the monitor.
5. Click the Method Type drop-down menu and select HTTP from the list.
The configuration fields change to those that apply to HTTP health monitors.
6. Optionally, select or enter additional options for the health monitor. (See “Health Monitoring” on
page 627.)
In this example, you can use the default settings.
7. Click Create Monitor. The new monitor appears in the health monitor table.
Perform the following procedure separately for each real server.
page 179

2. Select Servers from the menu bar at the top of the page.
3. Click Create.
4. Enter a name for the server in the Name field.
5. Select the Type radio button (IPv4, IPv6, or FQDN), and then enter the address in the field below.
Enter the server’s real address, not the virtual server IP address.
6. Click the Health Monitor drop-down menu and select a monitor, if one exists, or leave the moni-
tor unset.
If you leave the monitor unset, the Layer 3 health monitor that comes in the ACOS configuration by
default is used. (See “Default Health Checks” on page 627.)
To configure the real server port
1. While still within the Create Server window, in the Port section, click Create.
2. Enter the service port number on the real server in the Port Number field. In this example, enter
“80”.
3. For the Health Check radio button, select Monitor.
4. In the Health Monitor drop-down menu, select the HTTP health monitor configured in “To config-
ure an HTTP health method” on page 179.
5. Click Create. The port appears in the port list.
This example displays the server with the port created, followed by the list of all servers that were cre-
ated.
page 180
ACOS begins sending health checks to a real server’s IP address and service ports as soon as you fin-
ish configuring the server. The overall health status for the server is shown in the Health column. If the
status is Down, verify 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 ADC> SLB.

3. Click Create.
4. Enter a name for the service group in the Name field.
5. Select the load-balancing method from the Algorithm drop-down list.
page 181
For this example, you can leave the default selected: Round Robin
6. Click Create to create the service group. The new group appears in the service group table.
To configure the service group member
1. Click the Edit link for the service group you just created.
2. In the Member section, click Create.
3. Select the desired Choose Creation Type radio button:
• Select Existing Server, and then click the Server drop-down and select the desired server, OR
• Select New Server, and then enter the Name, address Type, and Host for the new real server.
4. In the Port field, enter the service port number.
5. Click Create.
6. Click Update. The new group appears in the service group table.
Repeat the process to configure the service group and service group members for each server and
port.
The following example shows the service group with members created.
To create the virtual server

2. Select the Virtual Servers tab, if not already selected.
3. Click Create. The Create Virtual Server window appears.
4. Enter a name for the virtual server in the Name field.
page 182
5. Select the Address Type radio button (IPv4 or IPv6) and enter the address in the IP Address
field. (This is the IP address that clients will request.)
6. Click Create to create the VIP. The new VIP appears in the list of virtual servers.
1. Click Edit to add a virtual port to this VIP.

2. In the Virtual Port section, click Create. The Create Virtual Port section appears.
3. Enter a name in the Name field. Naming the virtual port is optional.
4. Click the Protocol drop-down menu and select the service type. In this example, select Fast-
HTTP.
5. In the Port field, enter the service port number. In this example, enter “80”.
6. Click the Service Group drop-down menu, and select the service group.
7. Click Create. The port appears in the Virtual Port list.
The following example shows creating the virtual server, followed by creating the virtual server ports.
page 183
page 184
Use the CLI to Configure HTTP Load Balancing
This section configures the HTTP Load Balancing topology depicted in Figure 21.
1. The following commands configure the HTTP health monitor.

ACOS(config)# health monitor http-monitor

ACOS(config)# slb server web-2 10.10.10.2
3. The following commands configure the service group:

ACOS(config)# slb service-group http-sg tcp
ACOS(config-slb svc group)# member web-2 80

ACOS(config-slb vserver)# port 80 fast-http
ACOS(config-slb vserver-vport)# service-group http-sg
page 185
page 186
HTTP Options for SLB
This chapter describes HTTP options available in HTTP templates and provides examples of their use.
HTTP Options for SLB 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 support all the comprehensive capabilities of HTTP such
as header insertion and manipulation. It is recommended not to use fast-HTTP for applications that
require complete data transfer integrity.
HTTP Options Summary

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 ACOS device uses the load-bal-
ancing method set for the service group to select a real server.
• URL hash switching – Selects a real server based on a hash value calculated from part of the
URL string. (See “URL Hash Switching” on page 191.)
• 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 196.)
• Failover URL – If the URL in GET request cannot be reached due to server unavailability, the
ACOS device sends a 302 Redirect to the client. (See “URL Failover” on page 203.)
page 187
• 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 204.)
• 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 224.)
• Non-HTTP bypass – Redirects non-HTTP traffic to a specific service group. This feature helps
prevent non-HTTP traffic from being dropped by the ACOS device. (See “Non-HTTP Bypass” on
page 205.)
Performance Enhancing Options

• HTTP Packet Flow Modes – ACOS devices define two HTTP/HTTPS proxy packet flow modes
that specify the device method of managing multi-request data transfers. (See “HTTP Packet
Flow Modes” on page 206.)
• High-speed HTTP Content Replacement – Allows quick configuration of content replacement in
HTTP replies from load-balanced servers. (See “High-speed HTTP Content Replacement” on
page 208.)
• Content Compression – You can configure the ACOS device to offload content compression
from real servers. Enabling content compression on the ACOS device can help increase overall
website performance by freeing real server resources from CPU-intensive compression tasks.
(See “Content Compression” on page 209.)
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 216.)
• Header insertion / erasure – Inserts a field:value pair into requests or responses, or deletes a
header. (See “Header Insertion / Erasure” on page 218.)
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 222.)
page 188
Configuring an HTTP Template

To use the options in an HTTP template, you must configure the template, then bind the template to vir-
tual 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 one of these methods:
• Configuring an HTTP Template (GUI Procedure)
• Configuring an HTTP Template (CLI Example)
Configuring an HTTP Template (GUI Procedure)
To configure an HTTP template:

3. Click the + Create and select HTTP from the drop-down menu.
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.
6. When finished, click OK. The template appears in the ADC template list.
To bind a template to a virtual service port:

2. Select the Virtual Servers tab from the menu bar, if not already selected.
3. Click Create to create a new virtual server, and enter the name and IP information in the fields that
appear.
4. In the Virtual Port section, click Create. The Create Virtual Port window appears.
5. Click the Protocol drop-down and select one of the following: HTTP, Fast-HTTP, or HTTPS
6. Enter the port associated with this protocol.
7. Scroll down to the Templates section, and select the “Click here to bind” link.
8. From the pop-up menu that appears, select HTTP from the Template Type drop-down menu,
select the desired HTTP template from the Templates drop-down, and click the Bind button.
page 189
9. Configure other options if needed. (For example, if you are configuring a new port, make sure to
select the service group.)
10.Click the Create Virtual Port button. The port appears in the Port list.
11.Click Update. The virtual server list reappears.
Configuring an HTTP Template (CLI Example)
To configure an HTTP template, enter the slb template http command at the global configuration
level. This command changes the CLI to the template configuration level. The remaining sections in
this chapter describe commands for configuring each option. The following example configures the
HTTP template:
ACOS(config)# slb template http HTTP-TMP-1

ACOS(config-http)# exit
To bind a template to a virtual service port, enter template http at the port configuration level. The fol-
lowing example binds the HTTP template to virtual port 80:

ACOS(config-slb vserver-vport)# template http HTTP-TMP-1
Inserting HTTP Client Port Numbers in the HTTP Header

Inserting HTTP Client Port Numbers in the HTTP Header (CLI Procedure)
When an ACOS device forwards an HTTP packet to the server, you can add the client port number to
the HTTP header by adding the insert-client-port command in an HTTP template and binding the
template to the HTTP virtual port. The command includes a replace option that replaces the content
of an existing header that matches the configured name with the client’s port number. If no header
name is specified, X-ClientPort is used as the default header name.
Refer to the Command Line Interface Reference for ADC for information about the command.
Inserting HTTP Client Port Numbers in the HTTP Header (CLI Procedure)
The following example configures the HTTP template:
ACOS(config)# slb template http insertclientport

ACOS(config-http)# insert-client-port MY_HEADER_NAME
The following example binds the HTTP template to virtual port 80:

page 190
URL Hash Switching
ACOS(config-slb vserver-vport)# template http insertclientport
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 con-
tent 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. ACOS sends subsequent requests for the content to the same
real server.
Figure 22 shows an example of URL hashing.
FIGURE 22 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. ACOS is configured to calculate a hash value based on the last 3 bytes
of the URL string in the client request, and assign the hash value to a server.
After assigning a hash value to a server, the ACOS 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 ACOS 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.
page 191
URL Hash Switching
Hash Options
You can specify the following hash options:
• Offset – Specifies how far into the string to begin hash calculation.
• Bytes – Specifies how many bytes of the URL string to use to calculate the hash value.
• First or last – Specifies which end of the URL string to use to calculate the hash value.
• Server load awareness – Allows servers to act as backups to other servers, based on load.
The example in Figure 22 calculates hash values based on the last 3 bytes of the URL strings.
Offset
You can specify an offset at which to begin when calculating a hash value. By default, there is no offset.
Figure 23 displays an example of calculating a hash value starting with the fifth character in the URL
string.
FIGURE 23 URL Hashing Offset Example
URL Hash Switching with Server Load Awareness

You can configure URL hash switching to be aware of server load. Server load awareness allows serv-
ers to act as backups to other servers, based on load.
Normally, URL hashing selects a server for the first request for a given URL, then uses the same server
for all subsequent requests for the same URL. In cases where a given URL becomes wildly popular (for
example, a viral video), the server for that URL can become overwhelmed.
page 192
URL Hash Switching
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 ACOS device, the ACOS device can learn a server’s load
status from the server.
Configuring Hash Switching with Server Load Awareness (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 bal-
anced as listed in Table 1.
TABLE 1 Server-Status Load-Balancing Example

Load Status
Reported by
Server Server ACOS Action
S1 0 New requests for /article-new1 are sent only to server S1.
S2 0
S3 0
S1 2 New requests for /article-new1 are distributed between S1 and S2, using round
S2 0 robin.
S3 0
S1 2 New requests for /article-new1 are distributed between S1 and S3, using round
S2 1 or 2 robin.
S3 0
Configuring Hash Switching with Server Load Awareness (Server Procedure)
This feature requires 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 these val-
ues: 0, 1, or 2.
Server-Status: load=N
The value of N can be 0, 1, or 2.
page 193
URL Hash Switching
ACOS manages requests to the server based on the Server-Status code. Table 2 describes the valid
load status codes that can be reported by a server.
TABLE 2 Server-Status Load Value

Load
Status
Reported
by Server Description ACOS Action
0 Server is able to handle all of ACOS device continues using the server for the URLs hashed to
its own requests. the server.
Server also can handle If necessary, ACOS device also uses the server to help with
requests for other servers if URLs hashed to servers that have load status 2.
necessary.
1 Server is able to handle its ACOS device continues using the server for the URLs hashed to
own requests. the server.
However, server can not han- ACOS device does not use the server to help handle requests
dle requests for other servers. for other servers.
2 Server is overloaded and ACOS device uses servers that have load status 0 to help han-
needs help handling its own dle the overloaded server’s requests.
requests. Requests are dis-
tributed among this server If no other servers are able to help, all servers in the service
and at least one other server group are pulled in to help. Requests will be sent round-robin
(with load status 0), in round among the busy servers. For example, if there are 3 servers,
robin fashion. 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 CPU utilization,
memory utilization, I/O utilization, and so on.
For a CPU-intensive application, you could calculate the Server-Status code based on CPU utilization.
For an I/O-intensive application, you could calculate the Server-Status code based on I/O utilization.
Configuring Hash Switching with Server Load Awareness (ACOS Configuration)
On the ACOS 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.
page 194
URL Hash Switching
URL Hashing Configuration

The following sections show how to configure URL hashing.
Configuring URL Hashing (GUI Procedure)

1. Access the configuration sections for the template. (See “Configuring an HTTP Template” on
page 189.)
2. By default, the URL Hash Persist radio button is set to Disabled. To activate the configuration
fields, select one of the following radio buttons:
• First – creates hash using first N characters of the URL. You must specify N in URL Hash First
field.
• Last – creates hash using last N characters of the URL. You must specify N in URL Hash Last
field.
• Offset – Enables Offset option. You must specify the number of characters in URL Hash Off-
set field.
3. If you plan to use the server load awareness option, select the Enable radio button for Use Server
Status.
4. Click Create.
Configuring URL Hashing (CLI Example)
The following commands implement the URL hashing configuration shown in Figure 22 on page 191.
The configuration of the sg1 service group referenced in the example is not included.
ACOS(config)# slb template http hash

ACOS(config-http)# url-hash-persist last 6
ACOS(config-http)# url-switching ends-with .htm service-group sg1
ACOS(config-slb vserver-vport)# template http hash
The following commands configure an HTTP template for URL hash switching with server load aware-
ness:
ACOS(config)# slb template http url-hash

ACOS(config-http)# url-hash-persist last 12 use-server-status
The following commands configure an HTTP template to perform URL hashing with the offset shown
in Figure 23 on page 192:
ACOS(config)# slb template http url_hash1

ACOS(config-http)# url-hash-persist offset 5 first 7
page 195
URL / Host Switching
URL / Host Switching Description

ACOS supports multiple service groups. URL / host switching enables an ACOS device to select a ser-
vice group based on the URL or domain name in a client’s GET request. The selection overrides the ser-
vice group configured on the virtual port.
You can configure an HTTP template with one of the following service-group switching options:
• URL switching – Selects a service group based on the URL path in the GET line of the HTTP
request’s header.
• Host switching – Selects a service group based on the domain name in the Host field of the
HTTP request’s header
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 199.)
Figure 24 shows an example of URL switching.
FIGURE 24 URL Switching
In this example, the ACOS 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.exam-
ple.com/abc. The real servers in service group sg-123 provide content for www.example.com/123.
page 196
URL switching rules configured on the ACOS device select a service group based on the beginning of
the URL on the GET line of client requests. Requests for URLs that begin with “/abc” are sent to service
group sg-abc. Likewise, requests for URLs that begin with “/123” are sent to service group sg-123.
An HTTP template can be configured with only one type of service-group switching, URL switching or
host switching. However, if you need to use both types of switching, you can do so with an aFleX script.
Match Options
URL / host switching selects a service group based on rules that map part of the URL string or host
(domain name) to the service group. You can use the following match options in URL / host switching
rules:
• Starts-with string – matches only if the URL or host name starts with the specified string.
• Contains string – matches if the specified string appears anywhere within the URL or host name.
• Ends-with string – matches only if the URL or host name ends with the specified string.
These match options are always applied in the following order, regardless of the order in which the
rules appear in the configuration. The service group for the first match is used.
• Equals
• Starts-with
• Contains
• Ends-with
If a template has more than one rule with the same option (starts-with, 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
page 197
Configuring URL / Host Switching

The following sections show how to configure URL / host switching.
Configuring URL / Host Switching (GUI Procedure)

page 189.)
2. The configuration fields for Host Switching and URL Switching are present at the bottom of the
template window. You can configure either option (but not both), since they are mutually exclusive.
3. For Host Switching:
a. Click the Switching Type drop-down and select Starts With, Ends With, Contains, Equals or
Host Hits Enable.
b. In the Match String field, enter the host name to search upon.
c. Click the Service Group drop-down list, select the service group to which to send client
requests.
d. Click Add.
4. For URL Switching:
a. Click the Switching Type drop-down and select Starts With, Ends With, Contains, Equals, URL
Case insensitive, or Enables URL Hits.
b. In the Match String field, enter the URL to search upon.
c. In the Service Group drop-down list, select the service group to which to send client requests.
d. Click Add.
5. Click OK. The HTTP template list appears.
Configuring URL / Host Switching (CLI Example)
The following commands implement the URL switching configuration shown in Figure 24 on page 196.
The following commands configure the HTTP template:
ACOS(config)# slb template http urlswitch

ACOS(config-http)# url-switching starts-with /abc service-group sg-abc
ACOS(config-http)# url-switching starts-with /123 service-group sg-123
The following commands bind the HTTP template and service group sg-abc to virtual port 80:

page 198
ACOS(config-slb vserver-vport)# template http urlswitch

ACOS(config-slb vserver-vport)# service-group sg-abc
The following commands bind the HTTP template and service group sg-123 to virtual port 80:

ACOS(config-slb vserver-vport)# template http urlswitch
ACOS(config-slb vserver-vport)# service-group sg-123
Using URL / Host Switching along with Cookie Persistence
URL / Host Switching with Cookie Persistence Overview

ACOS supports URL / host switching with cookie persistence in the same SLB configuration. To enable
this support, you must enable the match-type service-group option in the cookie persistence template.
By default, the service-group option is disabled in cookie persistence templates. In this case, URL
switching or host switching is used only for the initial request from a client. After the initial request, the
same service group is always used for subsequent requests from the same client.
To continue using URL or host switching to select a service group for each request, enable service-
group option in the cookie persistence template. For each request from the client, the ACOS device first
selects a service group, then uses information in the cookie to select the real server and port within the
service group.
Figure 25 on page 200 shows an example.
page 199
FIGURE 25 URL Switching with Cookie Persistence
In this example, URL switching and cookie persistence are both configured, and the service-group
option is enabled in the cookie persistence template. For each client request, URL switching selects a
service group first. Then, after a service group is selected, a real server and port are selected within the
service group.
• If the client’s request does not have a persistence cookie that includes the selected service
group, the ACOS 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.
Note: If the server selection is done by a policy template, any configured persist cookie template
will not add cookies based on the service group. This occurs because the policy-based server load
balancing selection has already occurred on the receiving client SYN and the L7 backend will not
make a selection based on cookies again.
• If the client’s request already has a persistence cookie containing the name of the selected ser-
vice group, the ACOS 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 ACOS 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 ACOS 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.
page 200
Cookie Persistence Match-Type Options
When cookie persistence is configured, the ACOS 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 ACOS 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.
NOTE: The port option is shown in parentheses because the CLI does not have
a “port” keyword. If you do not set the match type to server (see below),
the match type is automatically “port”.
• match-type server – Subsequent requests from the client for the same VIP will be sent to the
same real server, provided that all virtual ports of the VIP use the same cookie persistence tem-
plate with match-type set to server. URL switching or host switching is used only for the first
request.
Set-Cookie: cookiename=rserverIP
• match-type (port) service-group – Subsequent requests from the client will be sent to the same
real port on the same real server, within the service group selected by URL switching or host
switching. URL switching or host switching is still used for every request.
Set-Cookie: cookiename-vport-servicegroupname=rserverIP_rport
• match-type server service-group – Subsequent requests from the client for the same VIP will be
sent to the same real server, within the service group selected by URL switching or host switch-
ing. URL switching or host switching is still used for every request.
Set-Cookie: cookiename-servicegroupname=rserverIP
NOTE: For security, address information in the persistence cookies is

encrypted.
page 201
Cookie Persistence Match-Type Option in Pass-Thru Mode
ACOS can also forward the cookie in pass-thru mode, so no information is modified, and the set-cookie
header is not parsed from the server packet response or from subsequent client responses. In this
case, the server is the one that sends the persist cookie. If the Set-Cookie header contains additional
attributes, then the ACOS configuration should match those. Any mismatch between the ACOS config-
uration and the server persist cookie will break the persistence behavior.
To use pass-thru mode, there needs to be an httpd.conf file on the server. In the CLI, you can generate
the pass-thru cookie that needs to be added to the server’s configuration file. This cookie is generated
based on match type and parameters that you specify.
NOTE: Pass-thru mode cannot be enabled in conjunction with standard ACOS

persist cookie configurations.
Configuring URL / Host Switching with Cookie Persistence
Configuring URL / Host Switching with Cookie Persistence (CLI Example)
The following commands configure a cookie persistence template named “persist-cookie-sg” and
enable port-level persistence with support for URL switching or host switching:
ACOS(config)# slb template persist cookie persist-cookie-sg

ACOS(config-cookie persist)# name SGCookie
ACOS(config-cookie persist)# match-type service-group
ACOS(config-cookie persist)# exit
ACOS(config)# exit
The following commands create the SLB persist cookie template and names it “passive-persist.” This
temple enables pass-thru mode for passive cookie persistence.
ACOS# gen-server-persist-cookie passive-persist match-type service-group sg1 32 64

192.168.100.100
Server Persist Cookie-Value (edit Expires/Path): "passive-persist-8192-sg1=GEGEKI-
MAEAAA;Expires=Fri, 15-May-2026 22:50:04 GMT;Path=/;"
ACOS# config
ACOS(config)# slb template persist cookie passive-persist
ACOS(config-cookie persist)# pass-thru
ACOS(config-cookie persist)# exit
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 service-
group option in the source IP persistence template.
page 202
URL Failover
For more information, see the description of the slb template persist source-ip command in the
“Config Commands: SLB Templates” chapter of the Command Line Interface Reference.
URL Failover
URL Failover Overview

ACOS can send an HTTP 302 Redirect message to a client when the real servers for the URL requested
by the client are unavailable. Figure 26 shows an example.
FIGURE 26 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. ACOS is
configured to send an HTTP 302 Redirect message if the VIP is down, redirecting clients to www.exam-
ple2.com.
By default, URL failover is not configured. To configure it, you specify the URL to which to redirect cli-
ents. 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.
The URL failover option does not affect redirect messages sent by real servers. To alter redirect mes-
sages from real servers, use the URL redirect-rewrite option instead. (See “URL Redirect Rewrite” on
page 222.)
page 203
5xx Retry and Reassignment
Configuring URL Failover

The following sections show how to configure URL failover.
Configuring URL Failover (GUI Procedure)

page 189.)
2. In the Failover URL field (at the top of the HTTP Template page), enter the URL where clients are
to be redirected.
3. Click OK. The template is listed with other HTTP templates.
Configuring URL Failover (CLI Example)
The following commands implement the URL failover configuration shown in Figure 26 on page 203.
ACOS(config)# slb template http urlfailover

ACOS(config-HTTP template)# failover-url www.example2.com
ACOS(config-HTTP template)# exit
The following commands bind the HTTP template to virtual port 80:

ACOS(config-slb vserver-vport)# template http urlfailover
5xx Retry and Reassignment

By default, if a real server replies to a request with a 5xx status code (such as, HTTP 503 – Service
Unavailable), the ACOS device forwards the error to the client. HTTP templates can override this behav-
ior. by configuring the ACOS 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. ACOS can reassign the request up to the configured number of retries.
For example, assume a service group has three members (s1, s2, s3), and the retry is set to 1. Then, if
s1 replies with a 5xx status code, the ACOS device reassigns the request to s2. If s2 also responds with
a 5xx status code, the ACOS device cannot reassign the request to s3, because the maximum number
of retries has been used.
page 204
Non-HTTP Bypass
Depending on the configured 5xx retry option, either the service port and server remain eligible for more
client requests, or the ACOS device stops sending client requests to the service port and server for 30
seconds.
• Server re-selection is not performed if Layer 3 features such as PBSLB, source-IP persistence, or
cookie persistence are configured on the virtual port. These features override the server re-selec-
tion.
• Use of this HTTP template option also requires the strict-transaction-switch option to be used in
the same HTTP template. (See “Strict Transaction Switching” on page 224.)
• This option is supported only for virtual port types HTTP and HTTPS. It is not supported for fast-
HTTP or any other virtual port type.
Configuring 5XX Retry and Reassignment (CLI Example)
These commands configure an HTTP template to reselect a server when the initially selected server
responds 4 times to a client’s request with a 5xx code. ACOS stops using the service port and server for
30 seconds after reassignment.
ACOS(config)# slb template http 5xxretry

ACOS(config-http)# strict-transaction-switch
ACOS(config-http)# retry-on-5xx
Non-HTTP Bypass
Non-HTTP bypass redirects non-HTTP traffic to a specific service group. This feature helps prevent
non-HTTP traffic from being dropped by the ACOS device.
Configuring Non-HTTP Bypass (GUI Procedure)

3. Click + Create and select HTTP from the drop-down menu.
5. Click the Bypass Non-HTTP traffic checkbox and choose the server group in the Bypass Ser-
vice Group field. This is the server to which non-HTTP traffic will be redirected.
6. 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.
7. Click OK. The template appears in the ADC template list.
page 205
HTTP Packet Flow Modes
Configuring Non-HTTP Bypass (CLI Example)
To redirect non-HTTP traffic to a specific service group use the non-http-bypass service-group com-
mand (HTTP template configuration level). By default, ACOS drops non-HTTP requests sent to an HTTP
port:
To configure, view, or remove this feature, follow these steps:
1. On an ACOS, configure the HTTP template and indicate the service group (in this case sg1) to
which all non-HTTP traffic should be sent:
ACOS(config)# slb template http http
ACOS(config-http)# non-http-bypass service-group sg1
2. To view the existing configuration, use the show slb template command:
ACOS(config-http)# show slb template | section sg1
priority 10 drop
priority 5 reset
non-http-bypass service-group sg1
3. Bind the HTTP template to the virtual port 80:

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

ACOS devices define two HTTP/HTTPS proxy packet flow modes: Request-response and pipeline.
These modes specifies the device method of managing multi-request data transfers. Figure 27 dis-
plays data flow diagrams for the two modes.
• Request-response mode: The ACOS device does not send subsequence requests until it receives
a response to previous requests.
page 206
• Pipeline mode: The ACOS device can send multiple requests that define a data transfer to the
same server without waiting for responses to previous requests.
FIGURE 27 HTTP and HTTPS Data Packet Flow Modes
Pipeline is the default HTTP and HTTPS packet flow mode. The are no commands that explicit specify
the mode that a device uses. The only method to manually specify a packet mode is to configure a con-
dition that enables Request-Response mode.
Request-response mode is enabled when the device is performing per-request load balancing. Enabling
any of the following features also enables request-response mode and subsequently disables pipeline
mode.
• Strict translation switch (implemented through an SLB HTTP template)
• URL hast persist (implemented through an SLB HTTP template)
• Compression is enabled (implemented through an SLB HTTP template)
• Failover is enabled (implemented through an SLB HTTP template)
• Redirect response is enabled (implemented through an SLB HTTP template)
• Non-HTTP bypass is enabled (implemented through an SLB HTTP template)
• Retry is enabled (implemented through an SLB HTTP template)
• Connection reuse is enabled (implemented through an SLB connection-reuse template)
• Persistence is configured on virtual port (implemented through an SLB persist template)
• RAM cache is enabled on virtual port (implemented through an SLB cache template)
page 207
High-speed HTTP Content Replacement
• External service is enabled on virtual port (implemented through an SLB external-service tem-
plate)
• Flex includes retry
High-speed HTTP Content Replacement

ACOS provides an HTTP template option for quick configuration of content replacement in HTTP
replies from load-balanced servers. When the ACOS device detects the specified data pattern in a
server reply, the ACOS device replaces the matching content with the content you specify.
A maximum of 8 content-replacement rules are supported in a given HTTP template. If you need more
rules, aFleX supports up to 32.
HTTP Content Format

ACOS uses either a Content-Length header or a Transfer-Encoding: chunked header for the new con-
tent.
• If the replacement pattern is the same length as the original pattern, ACOS uses the same header
type used by the server.
• If the replacement pattern length is different from the length of the original pattern, the ACOS
device uses a Transfer-Encoding: chunked header and chunk-encodes the content.
Configuring High-Speed HTTP Content Replacement

Configuring High-Speed HTTP Content Replacement (GUI Procedure)
Navigate to the configuration page to create a new HTTP template:

4. Enter a name for the HTTP template.
5. Scroll down and click Response Content Replace to expand.
a. In the Content String field, enter the content to look for in server responses. This is the text to
be replaced.
b. In the New String field, enter the content that will be used to replace the original content.
page 208
Content Compression
Quotation marks are not required, even if either or both strings contains blank spaces.
c. Click Add.
6. Select or enter values for any additional template options you want to use. The remaining sections
in this chapter describe the fields for configuring each option.
7. Click OK. The template appears in the ADC template list.
Configuring High-Speed HTTP Content Replacement (CLI Example)
These commands configures replacement of “Welcome to A10” with “Greetings from A10!”:
ACOS(config)# slb template http http1

ACOS(config-http)# response-content-replace "Welcome to A10" "Greetings from A10!"
Content Compression
Content Compression Overview

Most types of real servers are able to compress media (content) before sending it to clients. Compres-
sion reduces the amount of bandwidth required to send content to clients. Although compression opti-
mizes bandwidth, compression also can sometimes actually hinder overall website performance, if the
real servers spend a lot of their CPU resources performing the compression.
To maximize the benefits of content compression, you can enable the ACOS device to perform com-
pression for the real servers.
Compression is disabled by default. When it is enabled, the ACOS device compresses media of types
“text” and “application” by default. The ACOS device can be configured to compress additional media
types. The device can also be configured to exclude specific media types and even specific URIs from
compression.
Compression is supported only for HTTP and HTTPS virtual ports. Compression is not supported for
fast-HTTP virtual ports.
Accept-Encoding Field
An HTTP request from clients usually contains an Accept-Encoding field in the header. This field indi-
cates 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.
page 209
Content Compression
By default, when you enable compression on the ACOS 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. ACOS 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 ACOS device to leave the
Accept-Request field unchanged. In this case, compression is performed by the real server instead of
the ACOS device, if the server is configured to perform the compression. ACOS can still compress con-
tent that the real server does not compress.
Compression Level
ACOS supports compression level 1-9. Each level provides a higher compression ratio, beginning with
level 1, which provides the lowest compression ratio. A higher compression ratio results in a smaller file
size after compression. However, higher compression levels also require more CPU processing than
lower compression levels, so performance can be affected.
The default compression level is 1, which provides the fastest compression speed but with the lowest
compression ratio.
NOTE: The actual performance impact of a given compression level depends on

the content being compressed. For example, if the content has a lot of
repeated string patterns (for example, XML files), compression is faster
than it is for content with few repeated string patterns (for example,
graphics).
Hardware-Based Compression
Hardware-based compression is available using an optional hardware module. To confirm a device
supports hardware-based compression, enter show hardware and look for the highlighted line in the out-
put:
ACOS# show hardware

AX Series Advanced Traffic Manager AX3400
Serial No : AX34051112300079
CPU : Intel(R) Xeon(R) CPU
12 cores
2 stepping
Storage : Single 74G drive
Memory : Total System Memory 24738 Mbyte, Free Memory 10163 Mbyte
SMBIOS : Build Version: 080016
Release Date: 06/15/2012
SSL Cards : 1 device(s) present
1 Nitrox PX
page 210
Content Compression
GZIP : 1 compression device(s) present

FPGA : 4 instance(s) present
Date : 12172013
L2/3 ASIC : 1 device(s) present
Ports : 28
NOTE: Installation of the compression module into ACOS devices in the field is
not supported. Contact A10 Networks for information on obtaining an
ACOS device that includes the module.
This example shows that a “GZIP” module is installed for hardware-based compression support. This
field will not appear if there is no GZIP module installed on the device.
Hardware-based compression is disabled by default. When you enable it, all compression settings con-
figured in HTTP templates, except the compression level, are used.
Hardware-based compression is automatically set on the module and cannot be set using a template.
The module always uses the same compression level regardless of the level configured in an HTTP
template.
How ACOS Determines Whether to Compress a File

ACOS uses the following process to determine whether to compress a file before sending it to a client.
FIGURE 28 Content Compression
page 211
Content Compression
If the ACOS device is configured to leave the Accept-Encoding field unchanged, and the real server has
already compressed the file, the ACOS device forwards the compressed file without recompressing it.
Decompression for HTML Tag Insertion

For Over-the-top (OTT) services, proxy server was deployed inline to insert HTML codes in HTTP pay-
load in server responses., ACOS devices support this feature with aFlex for non-compressed traffic.
This feature is extended to support HTML tag insertion for HTTP compressed traffic (response) in TCS.
Running with aFlex, the compressed traffic is decompressed and an HTML tag is added to the
response. The response is then recompressed and sent back to the client.
As an example, on receiving the responses of HTTP traffic, the load balancer can insert a reference to
JavaScript. If the traffic is compressed, then ACOS device decompresses the traffic, adds a reference
to JavaScript, recompresses the response, and sends it back to the client.
page 212
Content Compression
Configuring Content Compression

The following sections show how to configure content compression.
Configuring Content Compression (GUI Procedure)
Navigate to the configuration page to create a new HTTP template:
1. Select ADC > Templates, and select the L7 Protocols tab from the menu bar.
4. Scroll to Compression and click to expand and display a set of additional fields.
a. Auto Disable On High CPU – Specify a value from 1-100 percent to configure an automatic
disable of HTTP compression based on CPU utilization.
b. Keep Accept Encoding – This option configures ACOS to leave the Accept-Encoding header
in HTTP requests from clients instead of removing the header. When this option is enabled,
compression is performed by the real server instead of the ACOS device when the server is con-
figured to perform compression. The ACOS device compresses content that the real server
does not compress.
c. Level – Click the drop-down menu and select a value ranging from 1-9. Each level provides a
higher compression ratio, beginning with level 1, which provides the lowest compression ratio.
A higher compression ratio results in a smaller file size after compression. However, higher
compression levels also require more CPU processing than lower compression levels, so per-
formance can be affected.
d. Minimum Content Length – Specify the minimum number of bytes the content must be in
order to be eligible for compression. The range is 1- 2147483647 and the default is 120.
5. To add more content types to be compressed:
a. In the Compression Content Type field, enter the string for a content type to compress.
b. Click Add.
c. Repeat step a and step b for each type of content to compress.
6. Click OK.
7. If your ACOS device supports hardware-based compression, enable the feature:
b. On the menu bar, select Global.
c. Click the checkbox next to Hardware Compression.
d. Click Update.
page 213
Content Compression
Hardware Compression is not available when the ACOS device does not contain a compression mod-
ule.
Configuring Content Compression (CLI Example)
These 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.
ACOS(config)# slb template http http-compress

ACOS(config-http)# compression enable
ACOS(config-http)# compression level 5
ACOS(config-http)# compression content-type image
ACOS(config-http)# compression exclude-content-type application/zip
This command displays HTTP compression statistics. The counters are in bytes and apply to all HTTP
compression configured in all HTTP templates on the ACOS device.
ACOS(config)# show slb http-proxy

Total
------------------------------------------------------------------
Curr Proxy Conns 58
Total Proxy Conns 49
HTTP requests 306
HTTP requests(succ) 269
No proxy error 0
Client RST 17
Server RST 0
No tuple error 0
Parse req fail 0
Server selection fail 0
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:
page 214
Content Compression
ACOS(config-common)# hw-compression
ACOS(config-common)# exit
ACOS(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
Temporary Compression Disable During High CPU Utilization

ACOS can temporarily disable HTTP compression when CPU utilization reaches a specified threshold.
After CPU utilization returns below the threshold, ACOS re-enables HTTP compression. This feature
can help overall system performance by temporarily freeing CPU resources used for compression to
perform other tasks.
This option is disabled by default. You can enable it in individual HTTP templates.
• The feature operates on individual CPUs. For example, if the utilization on CPUs 1 and 3 is above
the configured threshold but the utilization on other CPUs is below the threshold, HTTP compres-
sion is disabled only on CPUs 1 and 3. Compression remains enabled on the other CPUs.
• This feature applies to software-based compression. If hardware-based compression is enabled,
this feature is inapplicable and has no effect.
Configuring Temporary Compression Disabling (GUI Procedure)
Navigate to the configuration page to create an HTTP template:
4. Scroll to Compression and click to expand and display a set of additional fields.
5. In the Auto Disable On High CPU field, specify a value from 1-100 percent to configure an auto-
matic disable of HTTP compression based on CPU utilization.
6. Click OK.
page 215
Client IP Insertion / Replacement
Configuring Temporary Compression Disabling (CLI Example)
To configure automatic disable of HTTP compression based on CPU utilization, use the compression
auto-disable-on-high-cpu command at the configuration level for the HTTP template. The following
commands disable HTTP compression when CPU utilization is greater than 50%.
ACOS(config)# slb template http HTTP-TMP-1

ACOS(config-http)# compression auto-disable-on-high-cpu 50
To display statistics for software-based compression, use the show slb compression command:
Client IP Insertion / Replacement Overview

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 ACOS
device continues to be the source IP address when the ACOS 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 12 on
page 89.)
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 ACOS device translates the client’s IP address.
To add the client’s IP address back to the request, you do not need to change the network configuration
or NAT settings. Instead, you can simply enable the ACOS 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 29 shows an example of client IP insertion.
page 216
FIGURE 29 Client IP Insertion
In this example, SLB source NAT changes the source address of the client’s GET request from
192.168.100.3 to 10.20.20.11. However, the client’s source IP address is preserved within the HTTP
header of the request, by inserting the address into the X-ClientIP field.
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 / Era-
sure” on page 218.
Replace Option
By default, the client IP address is appended to addresses already in the target header field. You can
configure the ACOS 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.
page 217
Header Insertion / Erasure
Configuring Client IP Insertion / Replacement (GUI Procedure)

4. Scroll to Client IP Header Insert and click on the checkbox to enable the option and display the
name of the header field to which the client IP address will be added.
5. To change the name of the field, edit the name. Otherwise, leave the field name set to the default
(X-ClientIP).
6. Optionally, to replace any client addresses that are already in the header, click on the Replace
Existing header checkbox. Without this option, the client IP address is appended to the lists of cli-
ent IP addresses already in the header.
7. Click OK. The HTTP template appears in the SLB template list.
Configuring Client IP Insertion / Replacement (CLI Example)
The following commands implement the client IP insertion configuration shown in Figure 29 on
page 217.
ACOS(config)# slb template http insertclientip

ACOS(config-http)# insert-client-ip

ACOS(config-slb vserver-vport)# template http insertclientip
Header Insertion / Erasure Overview

You can configure the ACOS 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.
page 218
• The header insert, replace, and erase options described in this section are not supported with the
fast-http service type. ACOS does not allow an HTTP template with any of these header options
to be bound to a fast-http virtual port. Likewise, ACOS 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.
• To configure ACOS to insert the client’s IP address, see “Client IP Insertion / Replacement” on
page 216.
• Header insertion is not supported on fast-HTTP virtual ports.
Configuring Header Insertion / Replacement

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

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

If you configure an HTTP template to insert “Cookie: c=3”, and you use the insert-always option, the cli-
ent’s header is changed as follows:
page 219
GET / HTTP/1.1
Cookie: a=1
Cookie: b=2
Cookie: c=3
...
Effect When insert-if-not-exist Is Used

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

If you configure an HTTP template to insert “Cookie: c=3”, but you do not use either the insert-always or
insert-if-not-exist option, the header is always inserted into the request. If the packet already contains a
“Cookie” header, the header is replaced. If the packet contains multiple “Cookie” headers, the last one is
replaced. Here is the result:
GET / HTTP/1.1
Cookie: a=1
Cookie: c=3
...
Configuring Header Insertion / Replacement (GUI Procedure)

4. Scroll to Header Insert and click to expand and display a set of additional fields.
5. To insert a request header:
a. In the Request Header Insert 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. Optionally, to change this behavior, select one of the follow-
ing options from the drop-down list next to the Name field:
page 220
• Insert Always – ACOS 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 – ACOS inserts the header only if the packet does not already contain a
header with the same field name.
c. Click Add.
6. To insert a response header, follow the same steps as those for inserting a request header, but use
the “Response Header Insert” section.
Configuring Header Insertion / Replacement (CLI Examples)
To insert a header, use the request-header-insert command. See the “Command Line Interface Refer-
ence for ADC” for information about the command.
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.
ACOS(config)# slb template http replace-cookie

ACOS(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.
ACOS(config)# slb template http add-cookie

ACOS(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.
ACOS(config)# slb template http add-cookie-unless-present

ACOS(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.
Configuring Header Erasure (GUI Procedure)

4. Scroll to Header Erase and click to expand and display a set of additional fields.
page 221
URL Redirect Rewrite
5. To erase a request header:

a. In the Request Header Erase section, enter the field name (the name portion of the name:value
pair) in the Name field.
b. Click Add.
6. To erase a response header, follow the same steps as those for erasing a request header, but use
the “Response Header Erase” section.
Configuring Header Erasure (CLI Example)
Use the response-header-erase command to remove the Set-Cookie header from HTTP responses:
ACOS(config)# slb template http http-erase-header

ACOS(config-http)# response-header-erase Set-Cookie
URL Redirect Rewrite Overview

ACOS 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 ACOS 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 ACOS
device will use the last rule because it is the most specific match to the URL:
page 222
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

Configuring URL Redirect Rewrite (GUI Procedure)
4. Scroll to Redirect Rewrite and click to expand and display a set of additional fields.
5. To change “http://” to “https://”:
a. Click Use HTTPS checkbox.
b. To change the SSL port number, edit the number in the Port field. (The default is 443.)
6. To change the URL:
a. In the Match List section, enter the URL string to be changed in the URL Match field.
b. In the Rewrite To field, enter the new URL.
7. Click Add.
Configuring URL Redirect Rewrite (CLI Examples)
The following commands configure the ACOS device to change unsecure URLs to secure URLs in redi-
rect 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.
ACOS(config)# slb template http secureredirect

ACOS(config-HTTP template)# redirect-rewrite secure

ACOS(config-slb vserver-vport)# template http secureredirect
page 223
Strict Transaction Switching
Strict Transaction Switching
Strict Transaction Switching Overview

By default, the ACOS device performs server selection once for a client session. After the initial selec-
tion, 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 ACOS device to perform server
selection for each request within every session.
NOTE: Use this option only if needed, and disable the option once the server
load is rebalanced. This option makes server selection much more gran-
ular but also uses more ACOS system resources.
Enabling Strict Transaction Switching

The following sections show how to enable strict transaction switching.
Enabling Strict Transaction Switching (GUI Procedure)

2. Click the + Create and select HTTP from the drop-down menu.
4. Click on the Strict Transaction Switch checkbox.
5. Click Create. The HTTP template appears in the SLB template list.
Enabling Strict Transaction Switching (CLI Procedure)
To enable strict transaction switching, enter the strict-transaction-switch command at the configu-
ration level for the HTTP template.
HTTP Status Code Statistics

ACOS provides real-time monitoring capabilities to various HTTP response codes for the HTTP, HTTPS,
and Fast-HTTP ports of a virtual server. These new statistics communicate whether 5xx HTTP
page 224
Client-IP Insertion Extensive Support
response codes originated from the real server or ACOS. An immediate display for the event cause
allows you to quickly and effectively respond to HTTP events.
NOTE: In the current release, HTTP response codes are not written to event
logs.
Viewing HTTP Status Code Statistics (CLI Example)
Enter the show slb http-proxy command to display counters for HTTP response codes. See the “Com-
mand Line Interface Reference for ADC” for information about the command.
For example:
ACOS-Active(config)# show slb http-proxy vs800-http 80

Total
------------------------------------------------------------------
status code 1XX 3
status code 2XX 1
status code 3XX 12
status code 4XX 8
status code 5XX 2
status code 6XX 3
.
.
.
Rsp time < 200m 0
Rsp time < 500m 1
Rsp time < 1s 3
Rsp time < 2s 7
Rsp time < 5s 13
Rsp time >= 5s 22

ACOS provides expanded support for inserting the client’s IP address into the TCP header. All modes of
TCP, including Layer 4 TCP virtual ports, Layer 7 virtual ports, and fast-http are supported. Additionally,
the client-IP can be inserted in the TCP header for IPv4 to IPv6, IPv6 to IPv6, and IPv6 to IPv4 traffic.
When client-IP Insertion is configured, the client’s IP address is inserted into the TCP options. The
options field is a maximum of 40 bytes. Other options may take priority over inserting the client’s IP
address, causing the client-IP to be omitted due to lack of room in the TCP header. This is most likely to
occur in IPv6 to IPv6 or IPv6 to IPv4 traffic because the option length for an IPv6 address is longer.
page 225
There is a counter that tracks the number of times the client-IP insertion is skipped due to lack of room
in the TCP header.
Configuring Client-IP Insertion

Inserting the client-IP in to the TCP options header is configurable using an SLB TCP template.
1. Create an SLB TCP template and enable “insert-client-ip” on the template.

For Layer 4 virtual ports and Fast-HTTP, configure an SLB TCP template. For Layer 7 virtual ports,
configure an SLB TCP-Proxy template.
2. Apply the template to the virtual ports for which you want to insert the client-IP into the traffic
headers.
Configuring Client-IP Insertion (GUI Procedure)
Perform the following steps to configure client-IP insertion:
1. If you want to configure client-IP insertion for Layer 4 or Fast-HTTP:

Navigate to ADC > Templates > L4 Protocols. Click + Create and select TCP from the drop-
down menu, or the name of an existing template.
If you want to configure client-IP insertion for Layer 7:
Navigate to ADC > Templates > L7 Protocols. Click + Create and select TCP Proxy from the
drop-down menu, or the name of an existing template.
2. Select the “Enable” radio button for the “Insert Client IP” option at the bottom of the template con-
figuration section.
3. Click OK or Update.
Configuring Client-IP Insertion (CLI Example)
The following example configures an SLB TCP template and binds it to a port 80 TCP on the “proxy-
server.”
The commands below create an SLB TCP template named “proxy-header” and configure it to insert the
client-IP in the headers of forwarded traffic.
ACOS(config)# slb template tcp proxy-header

ACOS(config-l4 tcp)# insert-client-ip
The following commands apply the “proxy-header” template to the virtual server “proxy-server,” on port
80 TCP. All traffic coming through port 80 on “proxy-server” will have the client-IP inserted into the
header when they are forwarded on.
ACOS(config)# slb virtual-server proxy-server 1.1.1.100
page 226

ACOS(config-slb vserver-vport)# template tcp proxy-header
page 227
page 228
HTTP Load Balancing to Proxy Servers
HTTP Load Balancing to Proxy Servers Overview

The ACOS external service module has fixed headers for URL filtering when it forwards requests to
proxy servers. Besides these fixed headers, you also can specify a set of HTTP request-headers when
forwarding HTTP packets from the client to the proxy servers. If there are multiple headers with the
same name from the client, then only the first header instance will be forwarded.
The URL Filter server’s HTTP module parses the client request and saves the results in the correspond-
ing data structure. ACOS inserts the configured header when it forwards the HTTP request to the proxy
server. If the response from the proxy server is good, then ACOS connects to the destination server. If
the response from the proxy server is bad, then ACOS closes the connection.
To specify the HTTP request-headers to be sent to the proxy server, use an SLB “external-service” tem-
plate.
• Only GET and POST methods are forwarded by the SLB “external-service” template, so only these
methods will forward the configured request-headers to the proxy servers.
• A maximum of 16 HTTP headers can be forwarded. One HTTP header only can be 1036 bytes,
including the HTTP header name and HTTP header element. Anything longer than that will be
truncated at 1036 bytes.
• If there are multiple headers with the same name from the client, then only the first header
instance will be forwarded.
page 229
Configuring HTTP Load Balancing to Proxy Servers
Configuring HTTP Load Balancing to Proxy Servers
Increasing the HTTP Header Processing Capacity

The number of HTTP headers that ACOS can process can be increased up to 255 by entering the max-
http-header-count command from SLB common configuration mode.
The default value is 90, and a value between 90 and 255 can be entered.
Increasing the HTTP Header Processing Capacity (CLI Example)
This example increases the number of HTTP headers that ACOS can process to 255.

ACOS(config-common)# max-http-header-count 255
Configuring HTTP Headers to Forward to Proxy Servers

To configure HTTP headers to forward to proxy servers, you need to:
1. Create an SLB External-service template.

2. Specify, in the template, the request-headers that you want forwarded.
Configuring HTTP Headers to Forward to Proxy Servers (CLI Example)
The following example enables header request forwarding within an SLB External-service template
named “header-forwarding” for the headers “user-agent,” “date,” and “cookie.”
ACOS(config)# slb template external-service header-forwarding

ACOS(config-external-service)# request-header-forward cookie
ACOS(config-external-service)# request-header-forward DATE
ACOS(config-external-service)# request-header-forward User-Agent
page 230
Sending a TCP Reset After Server Selection Failure
ACOS provides an option to send a TCP reset (RST) to clients if server selection fails. Server selection
failure can occur as the result of any of the following conditions:
• Server or port connection limit is reached
• Server or port connection rate limit is reached
• Client in a PBSLB black/white list reaches its connection limit
• The def-selection-if-pref-failed option is disabled and SLB is unable to select a server for
any reason
• All servers are down
The reset-on-server-selection-fail option can be enabled at either of the 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 30 on page 232 shows an example of a Policy-Based SLB
(PBSLB) solution that uses the reset-on-server-selection-fail option.
The TCP template reset-rev option also can be used to send a RST to clients. In ACOS releases prior to
2.2.2, the reset-rev option would send a RST in response to a server selection failure. In ACOS Release
2.2.2 and later, the new reset-on-server-selection-fail option must be used instead.
When "reset-rev" is configured in a tcp or tcp-proxy template that is bound to a virtual port when the
server is disabled or down, RST is not always immediately sent to the client:
• If there is an active session (ACOS is processing traffic and detects that the server for the ses-
sion the traffic matches, is disabled or goes down), the RST is sent to client immediately.
• If the server is detected as disabled or down while the session is idle, RST is sent to the client
after a 30 to 90 second delay. However, if “del-session-on-server-down” was configured in the
SLB port template, RST is sent immediately.
page 231
FIGURE 30 PBSLB Used With reset-on-server-selection-fail Option
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
ACOS device sends a RST to the client. However, if a grey-list or black-list client exceeds its connection
limit, the ACOS 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.
page 232
To configure the ACOS device to send a RST to white-list clients upon server selection failure, but not to
grey-list or black-list clients, the reset-on-server-selection-fail option is used in the white-list service
group only. The default PBSLB action, drop, is used for the other service groups.
The virtual port to which clients will send mail traffic is bound to all three service groups. In addition, the
def-selection-if-pref-failed option is disabled. This option must be disabled so that the ACOS 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 use a separate service group for each client
category, enabling of the reset-on-server-selection-fail option in the white-list service group, and dis-
abling of the def-selection-if-pref-failed option on the virtual port.
Using the CLI
The reset-on-server-selection-fail option is disabled by default. To enable the option, use the
reset-on-server-selection-fail command as follows:
• To enable the option in a service group, issue the command at the configuration level for the
group:
• To enable the option on a virtual port, issue the command at the configuration level for the port:
CLI Example
The commands below implement the solution shown in Figure 30 on page 232.
ACOS(config)# slb server ms1 10.10.10.11

page 233
ACOS(config)# slb service-group white-list tcp

ACOS(config-slb svc group)# member ms1 25
ACOS(config-slb svc group)# reset-on-server-selection-fail
ACOS(config)# slb service-group grey-list tcp
ACOS(config)# slb service-group black-list tcp
The following commands import black/white list “bw-list-1.txt” onto the ACOS device:
ACOS(config)# import bw-list bw-list-1.txt tftp://myhost/TFTP-Root/ACOS_bwlists/bw-list-

1.txt
ACOS(config)# show bw-list
Name Url Size(Byte) Date
------------------------------------------------------------------------------
bw-list-1.txt tftp://myhost/TFTP-Root/ACOS_ N/A N/A
bwlists/bw-list-1.txt
Total: 1
The following commands configure the policy template:
ACOS(config)# slb template policy pbslb1

ACOS(config-policy)# bw-list name bw-list-1
ACOS(config-policy)# bw-list id 1 service-group white-list
ACOS(config-policy)# bw-list id 2 service-group grey-list
ACOS(config-policy)# bw-list id 3 service-group black-list
ACOS(config-policy)# exit
ACOS(config)# slb virtual-server mail-vip 10.10.10.10

ACOS(config-slb vserver-vport)# service-group white-list
ACOS(config-slb vserver-vport)# service-group grey-list
ACOS(config-slb vserver-vport)# service-group black-list
ACOS(config-slb vserver-vport)# template policy pbslb1
ACOS(config-slb vserver-vport)# def-selection-if-pref-failed
page 234
SPDY Load Balancing
This chapter describes SPDY load balancing and how to configure it.
This chapter and other SLB configuration chapters walk through the individual GUI pages used for con-
figuration. The GUI also provides smart templates for easy configuration. For information, see the GUI
online help
Overview
SPDY load-balancing manages SPDY traffic across a Web server farm. Figure 31 displays a SPDY load
balancing deployment. 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 ACOS device is
not shown here. Likewise, a single ACOS is shown. Your configuration might use an ACOS pair for
VRRP-A high availability.
FIGURE 31 SPDY Load Balancing
In this example, a server farm consisting of three servers provides content for Web site www.exam-
ple.com. Clients access the site through its virtual IP address, 192.168.10.11. When the ACOS device
page 235
Overview
receives a client request using the SPDY protocol on 192.168.10.11, the ACOS device converts to
HTTP, 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 and that the site consists of multiple serv-
ers. After selecting a real server, the ACOS device automatically performs necessary Network Address
Translation (NAT) to send the client request to the server, receive the reply from the server, and send
the reply to the client. From the client’s perspective, the Web session is between the client and port 80
on 192.168.10.11.
Service Groups
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. In
this example, the default load-balancing method, round robin, is used.
Virtual Server
The virtual server in this example has IP address 192.168.10.11 and virtual service port 80. When con-
figuring a virtual service port, you specify the protocol port number for the port. You also specify the
service type. Although 6121 is the default port number for SPDY, most web browsers use port 80 for
web traffic, so the SPDY service port must be configured to port 80.
SPDY/SPDYS load balancing works only when source NAT is configured on the virtual server.
Templates
For SPDY, the ACOS configuration applies “default” templates of each of the following template types
to SPDY service ports:
• TCP-Proxy
• HTTP (only the idle time-out option is supported at this time.)
The following types of templates also can be used with SPDY service ports. However, these types of
templates do not have “default” templates that are applied automatically.
• Source-IP Persistence
• RAM Caching - can only be configured through the CLI.
• Connection reuse
(For an example using a source-IP persistence template, see “Layer 4 TCP/UDP Load Balancing” on
page 135.)
The following types of templates are not supported for use with SPDY service ports at this time:
page 236
Overview
• Cookie persistence
• WAF
• External Service
• Authentication
ACOS 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 service 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:
• “Config Commands: SLB Templates” chapter in the CLI Reference
Health Monitors
This example uses the following health monitors to check the real servers, both of which are configured
and enabled by default when you add the real servers:
• Ping – A Layer 3 health method that sends an ICMP echo request to the real server’s IP address.
The server passes the health check if the ACOS device receives a ping reply.
• TCP – By default, every 30 seconds, the ACOS device sends a connection request (TCP SYN) to
each load balanced TCP port on each server, in this case ports 80 and 443. A TCP port passes
the health check if the server replies to the ACOS device by sending a TCP SYN ACK. By default,
the ACOS device completes the TCP handshake.
In addition to these default health checks, you can configure health monitors for specific service types.
This example uses an HTTP health monitor, with the following default settings:
• Every 30 seconds, the ACOS device sends an HTTP GET request for the default index page.
• The SPDY service port passes the health check if the requested page is present on the server and
the server replies with an OK message (200).
For information about health monitors and their configurable options, see “Health Monitoring” on
page 627.
page 237
Configuring SPDY Load Balancing
SPDY Protocol Limitations

At this time, ACOS does not support all aspects of the SPDY protocol. The following limitations apply:
• Unidirectional streams or frames are not supported.
• Stream priority is not supported.
• The only supported options for SETTING frames are MAX CONCURRENT STREAMS and INITIAL
WINDOW SIZE. The following options are not supported:
• UPLOAD BANDWIDTH
• DOWNLOAD BANDWIDTH
• ROUND TRIP TIME
• CURRENT TCP CWND
• DOWNLOAD RETRANS RATE
• CLIENT CERTIFICATE VECTOR SIZE
• Only HTTP Name/Value pairs are supported; others are considered HTTP and cause an HTTP
parse error.
• AX only supports receiving, not sending, window update messages. Window update messages
will be received per session, not per stream.
• CREDENTIAL is not supported
• Hardware compression is not supported. Only software compression is supported.
• NPN with hardware SSL is not supported.
• Use of aFleX scripts is not supported.
• Policy-Based Server Load Balancing for HTTP is not supported.
• WAF templates are not supported.
• Authentication is not supported.

Configuring SPDY Load Balancing (Procedure)
To configure the SPDY load balancing solution described in “Overview” on page 235, perform the fol-
lowing tasks on the ACOS device:
page 238
1. Configure an HTTP health monitor.

2. Configure the real servers. On each real server:
• Add the TCP service port.
• Enable the HTTP health monitor.
3. Configure the service group. Add the real servers and service ports to the group.
4. Configure an IPv4 source NAT pool.
• Add the SPDY service port.
• Bind the service group to the virtual port.
Configuring SPDY Load Balancing (GUI Procedure)
To configure an HTTP health method

2. Click Create. The Create Health Monitors page appears.
4. Click the Method type drop-down menu and select HTTP.
The other configuration fields change to those that apply to HTTP health monitors.
5. (Optional) Select or enter additional options for the health monitor. (See “Health Monitoring” on
page 627.)
In this example, you can use all the default settings.
6. Click the Create Monitor button at the lower right-most corner. The new monitor appears in the
Health Monitors table.
The following example shows creating the health monitor.
page 239
Perform the following procedure separately for each real server.

3. Click Create. The Create Server page appears.
4. Configure basic settings for the server, such as Name and IP address Type (IPv4 or IPv6).
5. Click the Health Monitor drop-down menu and select ping, or leave the monitor unset.
If you leave the monitor unset, the Layer 3 health monitor that comes in the ACOS configuration by
default is used. (See “Default Health Checks” on page 627.)
7. In the Port Number field, enter the service port number on the real server. In this example, enter
“80”.
8. In the Health Check radio button, select Monitor, and then click the Health Monitor and select
the health monitor you configured in “To configure an HTTP health method” on page 239.
9. Configure other port settings, if needed, then click Create. The application port appears in the Port
list.
10.Click Create (or Update, if modifying an existing server). The real server appears in the real server
table.
page 240
ACOS 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 Status col-
umn. If the status is Down, verify 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

3. Click Create. The Create Service Group page appears.
4. Enter a Name for the service group.
5. Click the Algorithm drop-down list and select the load-balancing method.
For this example, you can leave the default selected: Round Robin
page 241
6. In the Member section, click Create, and select a real server from the Server drop-down, enter the
service port number, and click Create to add the member to this service group.
7. Repeat step 6 for each real server.
8. Click Update. The new service group appears in the service group table.
To configure source NAT
1. Select ADC > IP Source NAT.

2. Select the IPv4 Pools tab from the menu bar, if not already selected.
3. Click Create.
4. In the Name field, enter a name for the source NAT pool.
5. Enter the Start Address and End Address in the fields.
6. Enter the Netmask for the source NAT pool.
7. Click Create.

5. Select the Address Type radio button (IPv4 or IPv6), and then enter the address in the IP
Address field.
6. In the Virtual Port section, click Create. The Create Virtual Port page appears.
7. Enter a name for the virtual port in the Name field.
8. In the Protocol drop-down list, select the service type. In this example, select SPDY.
page 242
9. In the Port field, enter the service port number. In this example, enter “80”.
10.Click the Service Group drop-down menu and select the desired service group.
11.Click the General Fields section, click the Source NAT Pool drop-down menu, and select the
source NAT pool you configured earlier.
12.Click Create. The virtual port appears in the table.
13.Click Update. The virtual server appears in the virtual server table.
Configuring SPDY Load Balancing (CLI Example)
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 CLI Reference.
The following commands configure the HTTP health monitor:
ACOS(config)# health monitor http-hmonitor


ACOS(config-real server-node port)# health-check http-hmonitor
page 243
The following commands configure the service group:

The following command builds the source NAT pool:
ACOS(config)# ip nat pool nat1 10.10.2.15 10.10.2.16 netmask /24

ACOS(config-slb vserver)# port 80 spdy
ACOS(config-slb vserver-vport)# source-nat pool nat1
page 244
SIP Load Balancing
This chapter describes Session Initiation Protocol (SIP) load balancing and how to configure it. You can
configure load balancing for SIP over UDP or SIP over TCP/TLS.
Load Balancing for SIP over UDP
Load Balancing for SIP over UDP Overview

ACOS devices support SIP load balancing. SIP load balancing balances SIP registration messages from
clients across a service group of SIP Registrar servers. SIP load balancing enables you to offload regis-
tration processing from other SIP servers so those servers can more efficiently process other SIP traf-
fic.
Figure 32 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 246.
FIGURE 32 SIP Load Balancing
page 245
Application Layer Gateway Support

In releases earlier than 2.6.0 that support SIP load balancing, ALG support is automatically enabled for
SIP load balancing. In 2.6.1-P1 and later, SIP ALG support is available only if you enable it.
The status of ALG support does not affect address translation at the IP layer. Address translation at the
IP layer is still performed, if applicable, even if ALG support is disabled.
Configuring Load Balancing for SIP over UDP

Configuring Load Balancing for SIP over UDP (Procedure)
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 reg-
istration messages. Add the SIP port to each server. The SIP port can be the same on the Registrar
servers and these proxy servers. The ACOS selects a service group based on the message type.
4. Configure a service group for the Registrar servers and add them to the group.
5. Configure a service group for the other SIP servers and add them to the group. This is the SIP
proxy group.
6. Configure a SIP template to redirect all SIP registration messages to the SIP Registrar service
group.
7. Configure a virtual server containing the SIP port and bind the port to the SIP proxy group. Add the
SIP proxy service group and the SIP template to the port.
Configuring Load Balancing for SIP over UDP (GUI Procedure)
To configure a SIP health monitor for the Registrar servers

2. Select the Health Monitors tab from the menu bar, if not already selected.
3. Click Create.
4. In the Name field, enter a name for the health monitor.
5. Click the Method type drop-down menu and select SIP.
6. 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 SIP Port field.
page 246
7. Select the Register checkbox to send a REGISTER request. (By default, an OPTION request is sent
instead.)
8. For SIP over TCP, select the Use TCP checkbox.
9. To check the reply for specific response codes, enter them in the Expect Response Code field.
10.Click Create Monitor. The new SIP health monitor appears in the Health Monitor table.
The following example shows creating the health monitor.
Configure a real server for the SIP Registrar server

4. In the Name field, enter a name for the Registrar server.
5. Click the Type radio button, and then enter the IP address of the server in the field below.
6. In the Port section, click the Create button.
7. In the Port field, enter “5060” for the SIP port number.
8. Click the Protocol drop-down list, and then select UDP.
9. For the Health Check radio button, select Monitor, and in the health monitor drop-down menu
that appears below, select the SIP health monitor you just created.
10.Click Create. The port appears in the Port list.
page 247
Use the same steps to configure a real server as a proxy for each SIP server that handles SIP mes-
sages other than registration messages. The following GUI panel shows servers added.
To configure a service group for the Registrar servers and add them to the group

3. In the Name field, enter a name for the service group.
4. In the Protocol drop-down list, select UDP.
5. In the Port section, click Create then click the Server drop-down list and select the SIP Registrar
server.
6. In the Port field, enter the SIP port number “5060”.
7. Click Create.
8. Repeat this process to add each Registrar server to the group.
9. Click Update. The service group appears in the service group table.
10.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.
The following example shows adding the service group, followed by the list of all service groups added.
page 248
To configure a SIP template to redirect all SIP registration messages to the SIP Registrar service group

3. Click Create, and then select SIP from the drop-down menu that appears.
5. Optionally, erase, insert, or replace text in the SIP header.
6. Click the Registrar Service Group drop-down menu, and select the registrar service group.
7. Click OK. The new SIP template appears in the SIP template table.
The following example shows creating the template, followed by the list of all templates added.
page 249
To configure a virtual server for the SIP proxy:

2. Select the Virtual Servers tab from the menu bar.
3. Click Create.
5. Select the Address Type radio button (IPv4 or IPv6), and then enter the IP address to which cli-
ents will send SIP Registration messages.
7. From the page that appears, click the Protocol drop-down menu and select SIP.
8. In the Port field, enter the SIP port number, “5060”.
page 250
9. Click the Service Group drop-down menu and select the SIP service group you created above for
non-registration traffic.
10.Click Templates to expand the template configuration options.
11.Click the Template SIP drop-down menu, and select the SIP template you just created.
12.Click Create. The port appears in the Port list for the virtual server.
13.Click Update. The virtual port appears in the virtual server table.
The following example shows creating the virtual port.
Configuring Load Balancing for SIP over UDP (CLI Example)
This example implements the SIP load balancing configuration shown in Figure 32 on page 245.
1. The following commands configure the SIP health monitors:

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

ACOS(config)# slb server Registrar1 10.10.10.56
page 251

ACOS(config-real server-node port)# health-check sipreg_monitor
ACOS(config)# slb server Registrar2 10.10.10.57
ACOS(config-real server-node port)# health-check sipreg_monitor
3. The following commands configure the SIP proxy servers:

ACOS(config)# slb server Proxy3 10.10.20.11
ACOS(config-real server-node port)# health-check sip_monitor
ACOS(config)# slb server Proxy4 10.10.20.12
ACOS(config-real server-node port)# health-check sip_monitor
4. The following commands configure the service groups:

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

ACOS(config)# slb template sip Registrar_template
ACOS(config-sip)# registrar service-group Registrar_gp
ACOS(config-sip)# client-request-header insert max-Forwards:22
ACOS(config-sip)# client-request-header erase Contact
ACOS(config-sip)# exit
6. The following commands configure the VIP for the SIP registrar:
ACOS(config)# slb virtual-server sip1 192.168.20.1
ACOS(config-slb vserver)# port 5060 sip
page 252
ACOS(config-slb vserver-vport)# service-group sip5060

ACOS(config-slb vserver-vport)# template sip Registrar_template
page 253
Load Balancing for SIP over TCP/TLS

SIP over TCP/TLS enables an ACOS device as a secure SIP proxy for SIP servers. Figure 33 displays an
example.
FIGURE 33 SIP over TCP / TLS
SIP clients send secure SIP requests over TLS. Requests are addressed to a VIP configured on the
ACOS device. The ACOS device forwards the requests to the SIP servers over TCP. Likewise, when the
ACOS device receives SIP traffic from the SIP servers, the ACOS device forwards the traffic to the
appropriate clients over TLS.
SIP Multiplexing
You can use the ACOS device to multiplex SIP connections. This is useful in cases where the SIP serv-
ers do not have enough capacity to maintain separate connections for each SIP client. Figure 34 shows
an example.
page 254
FIGURE 34 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 connection-reuse feature is configured
on the ACOS device. The ACOS device is allowed to open a maximum of 100 connections to each
server, but uses each connection for multiple clients.
While the ACOS device is sending a client request on a connection, the connection is in use. However,
as soon as the request has been sent, the ACOS device frees the connection to be used again. The con-
nection can be used for the same client or another client. The ACOS device does not wait for a reply to
the client’s request before freeing the connection. Figure 35 shows an example.
FIGURE 35 SIP Connection Reuse
page 255
In this example, the ACOS 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 ACOS device examines the X-For-
warded-For header in the reply.
The operation of connection reuse for SIP over TCP is different from the operation of connection reuse
for HTTP. For HTTP, the ACOS device does not free a connection after sending a client’s request.
Instead, the ACOS device frees the connection only after receiving a response to the request.
ACOS Requirements for SIP Multiplexing

In addition to the requirements for any SIP over TCP / TLS configuration (described in the configuration
section), the following items are required for SIP multiplexing:
• Connection-reuse template – Connection-reuse templates have the following 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 34,
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 ACOS device inserts an X-For-
warded-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. ACOS 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 256)
Client and Server Requirements for SIP Multiplexing

To use the ACOS device as a multiplexer for SIP over TCP/TLS, the clients and SIP servers must meet
certain requirements:
• The SIP clients must be able to send SIP pings.
• The SIP server must be able to reply to SIP pings, with SIP pongs.
• The SIP server must be able to include the X-Forward-For header added to the client’s request by
the ACOS device, in replies to the client.
Client Keepalive and Server Keepalive

ACOS can send and receive SIP keepalive messages:
• Ping – A SIP ping is a 4-byte message containing a double carriage return line feed (CRLF).
page 256
• 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 ACOS 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 ACOS device to
multiplex SIP connections.
Server keepalive enables the ACOS device to generate SIP pings and send them to the server. ACOS
uses server keepalive to prevent the reusable connections to the server from aging out. If the ACOS
device does not receive a pong before the connection-reuse timeout expires, the ACOS device closes
the connection. Server keepalives apply only to configurations that include connection reuse, such as a
configuration that uses the ACOS device as a SIP multiplexer.
If connection reuse is configured, even with client keepalive disabled, ACOS devices respond to client
SIP pings with pongs.
Figure 36 shows an example of a configuration that uses both SIP keepalive features.
FIGURE 36 SIP Keepalive
ACOS Actions if Selection of a Client or SIP Server Fails

You can configure the action the ACOS 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.
page 257
• Example message sent to client when server can not be reached: “504 Server Time-out”
• Example message sent to server when client cannot be reached: “480 Temporarily Unavailable”
SLB Network Address Translation for SIP over TCP / TLS

SLB Network Address Translation (NAT) is used for SIP over TCP / TLS load balancing in much the
same way SLB NAT is used for load balancing other types of traffic.
When a client sends a SIP request, the request is addressed to the virtual IP address (VIP) and protocol
port number configured on the ACOS device for the SIP servers. ACOS translates the destination IP
address and port of the request from the VIP to the real IP address and port of a SIP server. ACOS does
not change the client IP address or source protocol port number.
Likewise, when the ACOS device receives a SIP packet from a SIP server, the ACOS 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 ACOS 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 ACOS 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
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 ACOS device must not translate the virtual IP address
and port into a real server address and port in the Authorization header. Otherwise, authentication will
fail.
Configuring SIP over TCP / TLS for SIP Multiplexing

Configuring SIP over TCP / TLS for SIP Multiplexing (Procedure)
To configure an ACOS device for secure SIP multiplexing:
• Optionally, configure a health monitor for SIP over TCP.
page 258
• Configure a real server for each SIP server. Use the SIP protocol port number on the server (for
example, 5060) as the port number.
Use TCP as the protocol type. Use a Layer 4 TCP health monitor. When you add the TCP port, the
default TCP health monitor is automatically applied to the port and enabled.
• Configure a service group containing the real servers.
• Configure a SIP template with at least the following options enabled:
• Client IP insertion
• Client keepalive
• Server keepalive
• Configure a connection-reuse template. Set the limit-per-server option to the maximum number
of SIP connections to allow on each SIP server.
• If clients will use SIP over TLS, import the certificates and keys the SIP server would use to
authenticate clients. Configure a client-SSL template and add the certificates and keys to the
template.
• Configure a virtual server with the IP address to which clients will send SIP requests. For SIP over
TLS Clients, add a protocol port with service type “sips”. For SIP over TCP Clients, add a protocol
port with service type “sip-tcp”. Bind the port to the service group, and to the SIP and connection-
reuse templates. If a client-SSL template is used, bind the port to the client-SSL template too.
Configuring SIP over TCP / TLS for SIP Multiplexing (GUI Procedure)
The following shows how to configure the SIP multiplexing as described in Figure 34 on page 255.
Configure a real server for the SIP multiplexing

4. In the Name field, enter a name for the server.
5. Click the Type radio button, and then enter the IP address of the server in the field below.
6. In the Port section, click the Create button.
7. In the Port field, enter “5060” for the SIP port number.
8. Click the Protocol drop-down list, and then select TCP.
Repeat for each server. The following example shows the real server and port configuration.
page 259
To configure a service group for the SIP servers and add the servers to the group

3. In the Name field, enter a name for the service group.
4. In the Protocol drop-down list, select TCP.
5. In the Algorithm drop-down list, select Round Robin.
6. In the Member section, click Create, and then click the Server drop-down list to select the existing
server that you just configured.
7. In the Port field, enter the SIP port number “5060”.
8. Click Create.
Repeat for each member. The following example shows the service group and members.
page 260
To configure a SIP template for connection reuse

2. Select the Application tab from the menu bar.
3. Click Create, and then select Connection Re-Use from the drop-down menu that appears.
5. Configure limits.
6. Click OK. The Connection Re-Use template appears in the Application template table.
This example shows creating the template, followed by a configuration of the connection re-use tem-
plate.
page 261
To import a certificate for SSL
1. Select ADC > SSL Management.

2. Select the SSL Certificates tab from the menu bar, if not already selected.
3. Click Import.
4. Click the Certificate and Key radio button for import, then the Local radio button to import the
certificate from a local system.
5. Choose the certificate/key source file location and click Import.
The following example shows importing the certificate.
To add client SSL template

2. Select the SSL tab from the menu bar, and click on Client SSL.
3. In the CA Certs drop-down menu, select the imported certificates and keys.
4. Click OK.
page 262
To add a virtual server and port
1. Select ADC > SLB

3. Click Create.
4. Enter a name in the Name field and an IP address in the IP Address field.
5. From the Virtual Port section, click Create.
6. In the protocol drop-down menu, select SIPS.
7. In the port field, enter the SIPS port number, “5061”.
8. In the Service Group drop-down menu, select the service group.
9. Expand General Fields.
10.From the Source NAT Pool drop-down menu, select your Source NAT Pool.
11.From the ACL drop-down menu, select your access list and click Add.
12.Expand Templates.
13.In the Template Connection Reuse drop-down menu, select the Connection Re-Use template.
14.In the Template SIP drop-down menu, select the SIP template.
15.In the Template Client SSL drop-down menu, select the client SSL template.
16.Click Create.
17.Click Update.
The following example shows creating the virtual port.
page 263
Configuring SIP over TCP / TLS for SIP Multiplexing (CLI Example)
This example implements the SIP multiplexing configuration (Figure 34 on page 255).
1. These commands access the configuration level of the CLI and configure a SIP over TCP health
monitor:
ACOS(config)# health monitor sip-over-tcp
ACOS(config-health:monitor)# method sip tcp

ACOS(config)# slb server siptls-rs1 10.4.2.1
ACOS(config-real server-node port)# health-check sip-over-tcp
ACOS(config)# slb server siptls-rs2 10.4.2.2
page 264
ACOS(config-real server-node port)# health-check sip-over-tcp

3. The following commands configure the service group:

ACOS(config)# slb service-group siptls-sg tcp
ACOS(config-slb svc group)# member siptls-rs1 5060 10.4.2.1
ACOS(config-slb svc group)# member siptls-rs2 5060 10.4.2.2
4. The following commands configure the SIP template:

ACOS(config)# slb template sip siptls-tmplt
ACOS(config-sip)# insert-client-ip
ACOS(config-sip)# client-keep-alive
ACOS(config-sip)# failed-client-selection "480 Temporarily Unavailable"
ACOS(config-sip)# failed-server-selection "504 Server Time-out"
ACOS(config-sip)# exclude-translation header Authentication
5. The following commands configure the NAT pool and connection-reuse template:
ACOS(config)# slb template connection-reuse siptls-tmplt
ACOS(config-conn reuse)# limit-per-server 100
ACOS(config-conn reuse)# keep-alive-conn 64
ACOS(config-conn reuse)# exit
ACOS(config)# exit
6. The following commands import the certificates and keys to use for authenticating SIP clients:
ACOS# import cert ca-cert.pem scp:
User name []?admin
Password []?*********
File name [/]?ca-cert.pem
ACOS# import key ca-certkey.pem scp:
User name []?admin
Password []?*********
File name [/]?ca-certkey.pem
ACOS# import cert cert.pem scp:
User name []?admin
Password []?*********
File name [/]?cert.pem
ACOS# import key certkey.pem scp:
page 265

User name []?admin
Password []?*********
File name [/]?certkey.pem
7. The following commands configure the client-SSL template:

ACOS(config)# slb template client-ssl siptls-tmplt
ACOS(config-client ssl)# ca-cert ca-cert.pem
ACOS(config-client ssl)# cert cert.pem
ACOS(config-client ssl)# key certkey.pem
ACOS(config-client ssl)# exit

ACOS(config)# slb virtual-server siptls-vip 10.1.54.4
ACOS(config-slb vserver)# port 5061 sips
ACOS(config-slb vserver-vport)# service-group siptls-sg
ACOS(config-slb vserver-vport)# source-nat pool pool1
ACOS(config-slb vserver-vport)# template sip siptls-tmplt
ACOS(config-slb vserver-vport)# template connection-reuse siptls-tmplt
ACOS(config-slb vserver-vport)# template client-ssl siptls-tmplt
Displaying SIP SLB Statistics (CLI Procedure)
To display SIP SLB statistics, use the show slb sip command. Use the detail option to display statis-
tics separately for each CPU; otherwise, the command displays aggregate statistics for all CPUs.
page 266
Disabling Reverse NAT Based on Destination IP Address

You can use a SIP template to disable reverse NAT for traffic from servers, based on IP address. This
option is useful in cases where a SIP server needs to reach another server, and the traffic must pass
through the ACOS device. Figure 37 shows an example.
FIGURE 37 Reverse NAT Disabled for Traffic from a SIP Server
By default, the ACOS device performs reverse NAT on 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. If SIP server traffic must reach another server
and pass through the ACOS device, the destination server receive the traffic from the VIP address
instead of the SIP server address.
Disabling Reverse NAT Based on Destination IP Address Configuration (Procedure)
To disable reverse NAT in this type of situation:
1. Configure an extended ACL that matches on the SIP server IP address or subnet as the source
address, and matches on the destination server’s IP address or subnet as the destination address.
2. Configure a SIP template that disables reverse NAT based on the ACL.
3. Bind the SIP template to the SIP virtual port.
Disabling Reverse NAT Based on Destination IP Address Configuration (GUI Procedure)
Configure the extended ACL that matches on the SIP server’s subnet and on the database server’s sub-
net.
1. Select Security > Access List
page 267
2. From the menu bar, select Extended.

3. Click Create.
4. In the ID field, enter an ID for the extended access list.
5. Click Entry.
6. In the Action drop-down menu, click Permit.
7. In the Service field, click IP.
8. For Source Address and Destination Address, click on Subnet.
9. Enter the Address and Mask for both the Source Address and Destination Address.
10.Click Create.
Configure the SIP template to disable reverse NAT for traffic that matches the ACL.

2. From the menu bar, select L7 Protocols.
3. Click Create, and then select SIP from the drop-down menu that appears.
4. Select the Keep Server IP If Match ACL checkbox.
5. From the drop-down menu, select the ACL ID or ACL Name radio button, then select the ID or
name.
6. Click OK to save your changes.
Bind the SIP template to the SIP virtual port.

2. In the Virtual Servers, tab, click Create.
3. Enter the name of the virtual server in the Name field.
4. Enter the IP address of the virtual server in the IP Address field.
5. In Virtual Port, click Create.
6. In the Protocol drop-down menu, click SIP.
7. In the port field, enter the SIP port number, “5060”.
8. Expand Templates.
9. In the Template SIP drop-down menu, select the created SIP template.
10.Click Create.
11.Click Update.
page 268
IP NAT for SIP
Disabling Reverse NAT Based on Destination IP Address Configuration (CLI Example)
The commands in this section are applicable to Figure 37.
This command configures an extended ACL that matches the SIP server and database server subnets:
ACOS(config)# access-list 101 permit ip 10.10.10.0 /24 10.20.20.0 /24
The keep-real-server-ip-if-match-acl command configures the SIP template to disable reverse NAT
for traffic that matches the ACL:
ACOS(config)# slb template sip sip1

ACOS(config-sip)# keep-server-ip-if-match-acl 101
The following commands bind the SIP template to the SIP virtual port:
ACOS(config)# slb virtual-server sip-vip 192.168.11.51

ACOS(config-slb vserver)# port 5060 sip
ACOS(config-slb vserver-vport)# template sip sip1
IP NAT for SIP

ACOS supports IP NAT for SIP. This feature allows clients in a private network to make SIP calls to out-
side SIP servers without revealing client IP addresses to the servers. Dynamic NAT and static NAT are
both supported.
Only the SIP signaling packets are NATted. The media packets are not NATted.
To configure IP NAT for SIP:
1. Configure a pool, range list, or static inside source NAT mapping that includes real IP addresses of
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.
Configuring IP NAT for SIP (CLI Example)
The following configuration excerpt uses dynamic NAT.
ACOS(config)# access-list 1 permit any

ACOS(config-if:ethernet:2)# ip nat inside
page 269
IP NAT for SIP

ACOS(config-if:ethernet:3)# ip nat outside
ACOS(config)# ip nat pool xin 2.2.2.100 2.2.2.100 netmask /32
ACOS(config)# ip nat inside source list 1 pool xin
ACOS(config)# exit
page 270
Database Load Balancing
This chapter describes how to configure database load balancing (DBLB).
• Overview of Database Load Balancing
• Configure Database Load Balancing
Overview of Database Load Balancing

The database load balancing (DBLB) feature balances database queries across multiple servers. With
DBLB you can direct which servers process sets of queries based on the database system (MySQL or
MS-SQL) and query type.
ACOS secures database requests by applying SSL and TLS protocols on the front- and back-end serv-
ers to mask sensitive user credentials and validate client credentials against username-password
pairs. In addition, the ACOS can screen requests against aFleX scripts to parse SQL queries and intelli-
gently direct queries among servers.
Configure Database Load Balancing

To configure DBLB perform the following steps:
1. Create a string class-list that stores the username-password pairs.

2. Create a DBLB template and apply the string class-list to the template.
3. Configure a service group and add the database servers that will process database queries.
4. Optionally, create an aFleX script to direct how SQL requests are load balanced among the data-
base servers.
5. Configure a virtual server to proxy the MySQL or MS-SQL connections.
6. Apply the templates, service group, and aFleX policy configured in step 2 to step 4 to the virtual
server.
page 271
If you skip step 4 and no aFleX script is applied, the load-balance algorithm falls back to the gen-
eral Layer 4 server selection.
For MS-SQL database queries, SSL encryption occurs for the login packet only, not for the full ses-
sion.
Use the GUI to Configure Database Load Balancing

Configuring database load balancing consists of the following tasks:
1. Create a Class List

2. Create the DBLB Template
3. (Optional) Create an aFleX Script for Server Selection
4. Configure Network Resources
5. Create a Virtual Server:
Create a Class List

Perform the following steps to create a string class-list for username-password pairs.
1. Navigate to ADC > SLB.

2. Click the Class Lists tab from the menu bar, then select Configuration from the drop-down list.
3. Click Create.
a. In the Name field, enter a name for the class list which will house the username-password
pairs.
b. Click the Type drop-down menu and String. The String configuration section displays.
c. In the String section, enter the SHA1-encoded passwords for client verification. Enter encrypted
passwords as lower- or upper-case alphabetical characters a-f or A-F and numerical characters
0-9.
d. Click Add to include this string entry in the class list.
Passwords in the class list are stored as SHA1-encoded strings that must be exactly 40 bytes.
To translate a clear-text password to SHA1-encryption use the calc-sha1 command from the
DBLB template configuration level of the CLI. (See “Display SHA1-Encrypted Passwords” on
page 276.)
4. When finished with the class list configuration, click Create.
If the class list contains 100 or more entries, select the Store as File checkbox.
A class list can only be exported if you use the Store as File option.
page 272
Create the DBLB Template

1. Navigate to ADC > Templates.
2. Click the Application tab from the menu bar.
3. Click Create and select DBLB. The Create DBLB Template configuration page appears.
4. In the Name field, enter a name for the DBLB template.
5. Click the Server Version drop-down and select the SQL database (MSSQL 2008, MSSQL 2012, or
MySQL).
6. Click the Class List drop-down and select the name of the string class-list configured in “Create a
Class List” on page 272.
(Optional) Create an aFleX Script for Server Selection

You can create an aFleX script to select servers based on MySQL or MS-SQL traffic. The following
script checks to see if the query is a select statement (read) or an insert statement (write):
when DB_COMMAND {
set ret [ DB::command ]
log "aflex script got command number $ret"
pool mysql_read
}
when DB_QUERY {
set ret [ DB::query ]
log "aflex script got query $ret"
if { ($ret contains "select" ) or ( $ret contains "show" ) or ($ret contains "SELECT" ) }
{
log "It is a select!"
pool mysql_read
} else {
log "It is an insert!"
pool mysql_write }
}
This example checks to see if the admin is making a query:
when DB_COMMAND {
set ret [ DB::command ]
log "aflex script got command number $ret"
pool w_pool
}
when DB_QUERY {
set ret [ DB::query ]
log "aflex script got query $ret"
page 273
if { ($ret contains "admin" ) or ( $ret contains "ADMIN" ) or ($ret contains "Admin" ) } {

log "It is an admin send to server 1!"
pool w_pool-1
} else {
log "It is not an admin send to server 2!"
pool w_pool-2 }
}
If you do not apply an aFleX script for server selection, servers are selected by the default selection
algorithm. To learn more about aFleX commands for database query events, see the aFleX Reference.
Configure Network Resources

1. Configure servers:
a. Navigate to ADC > SLB.
b. Select the Servers tab from the menu bar.
c. Click Create. The Create Server page appears.
d. In the Name field, enter the name for the database server.
e. Select the Type radio button (IPv4, IPv6, or FQDN), and enter the IP address or FQDN in the
address field below.
f. Next, in the Port section, click the Create button to display the Port Configuration page.
g. In the Port Number field, enter a port number ranging from 1 to 65535.
h. Click the Protocol drop-down and select TCP or UDP.
i. Click Create to add the port to this server.
Repeat these steps for each database server.
2. Create the service group:
b. Select the Service Group tab from the menu bar.
c. Click Create. The Create Service Group page appears.
d. In the Name field, enter the name of the service group.
e. From the Protocol drop-down list, select TCP or UDP.
f. Next, in the Member section, click Create.
g. Select the Existing Server radio button, and then click the Server drop-down menu and select
the name of the server(s) configured above.
h. In the Port field, enter a port number between 1 to 65535.
page 274
i. Click Create to add this member to the service group.
Create a Virtual Server:

1. Navigate to ADC > SLB.
4. Enter a Name for this virtual server.
5. Select the IPv4 or IPv6 radio button and enter an IP address.
6. Configure a virtual port:
a. From the Virtual Port section, click the Create button. The Create Virtual Port page appears.
b. From the Protocol drop-down list, select MYSQL or MSSQL.
c. In the Port field, enter a number between 1 to 65535. The default port number for these proto-
col are as follows:
• MYSQL – 3306
• MSSQL – 1433
d. Click the Service Group drop-down menu and select the name of the service group configured
in step 2.
e. Optionally, expand the General Fields and select one or more aFleX Scripts from the aFleX
checkboxes.
This will apply an aFleX script to direct queries among the database servers.
f. Click Templates to expand the template configuration options, and from the Template DBLB
drop-down list, select the name of the DBLB template configured in step 1 to step 6.
g. Click Create to finish creating the virtual port. The Virtual Server configuration page appears.
h. Click Update to finish creating the virtual server.
Use the CLI to Configure Database Load Balancing

To configure DBLB using the CLI, perforom the following tasks:
1. Create a Class List

2. Create the DBLB Template
3. Display SHA1-Encrypted Passwords
4. (optional) Create an aFleX Script for Server Selection
page 275
5. Configure Servers
6. Configure the Service Group
7. Configure the Virtual Server
8. Monitor DBLB
A complete CLI example is provided in “Configuration Example – Basic DBLB” on page 277.
Create a Class List

Use the class-list command to create a class-list for username-password pairs. Use the str com-
mand to add a username and SHA1-encrypted password to the class-list:
For a SHA1-password, enter the SHA1-encrypted version of the user’s password. The password must be
exactly 40 bytes in length. To translate a clear-text password to SHA1-encryption use the calc-sha1
command from the DBLB template configuration level of the CLI.
Deleting a class list from a file system is the same as saving the configuration changes to the file sys-
tem. The write mem command is required.
Create the DBLB Template

Use the slb template dblb command to enter DBLB template configuration. Enter the class-list
command to apply a string class-list to the DBLB template to use for username-password pairs.
Display SHA1-Encrypted Passwords

DBLB template configuration level can translate clear text passwords as SHA1-encoded. The calc-sha1
command translates clear text passwords for configuring class-lists. The command accepts the user’s
clear text password; the output is usd to string class-lists to save the encrypted version of username
passwords.
This example enters DBLB template configuration mode and translates “1234” into its encrypted equiv-
alent.
ACOS(config)# slb template dblb abcd

ACOS (config-dblb)# calc-sha1 1234
Sha1 password is 7110eda4d09e062aa5e4a390b0a572ac0d2c0220
ACOS(config-dblb)# exit
(optional) Create an aFleX Script for Server Selection

You can create an aFleX script to select servers based on MySQL or MS-SQL traffic. To learn about
aFleX commands for database query events, see the aFleX Reference. If an aFleX script for server selection
is not applied, servers are selected by default server selection algorithm.
page 276
Configure Servers
Enter the slb server command to configure a server to process the database queries, then use the
port command to add a port to the server. Optionally apply SSL templates to direct the ACOS to use
SSL encryption on back-end servers which process the requests with the template server-ssl com-
mand.

Use the slb service-group and member commands to create a service group and its members:
Configure the Virtual Server

Enter the slb virtual-server and port commands to configure a virtual server, its port, and apply the
DBLB template. This command takes you to the configuration level of the virtual port where you can
enter the service-group and template DBLB commands to add the DBLB template and service-group
which includes the database servers:
Optionally, direct database queries across different servers with an aFleX policy (aflex command).
Optionally, apply SSL templates to direct the ACOS to use SSL encryption for client requests (template
client-ssl command).
Monitor DBLB
Enter the show slb template dblb command to display a list of DBLB templates: To view DBLB count-
ers by query type, enter show slb mssql or show slb mysql commands.
Configuration Example – Basic DBLB

The following example shows a basic deployment of DBLB for MySQL and MS-SQL connections. The
example does not include the configuration of aFlex scripts referenced by the example.
1. The following commands create two string class-lists: the first for My-SQL requests (processed
with the “DBUsers” class list) and the second for MS-SQL requests (processed with the “MSSQLD-
BUsers” class list):
ACOS(config)# class-list DBUsers string
ACOS(config-class list)# str 91dfd9ddb4198affc5c194cd8ce6d338fde470e2
ACOS(config-class list)# exit
ACOS(config)# class-list MSSQLDBUsers string
ACOS(config-class list)# str b48cf0140bea12734db05ebcdb012f1d265bed84
2. These commands create a server SSL template to be applied to the virtual port. This step is
optional.
ACOS(config)# slb template server-ssl SRV08
page 277
ACOS(config-server ssl)# ca-cert SRV08_ca

ACOS(config-server ssl)# cert SRV08_cert
ACOS(config-server ssl)# key SRV08_key
ACOS(config-server ssl)# exit
3. The following commands configure the servers to process database queries:

ACOS(config)# slb server Server07 110.20.20.20
ACOS(config)# slb server Server08 110.13.13.20
ACOS(config-real server-node port)# template server-ssl SRV08
ACOS(config)# slb server MSSQLServer02 110.13.13.21
ACOS(config-real server-node port)# template server-ssl SRV08
4. These commands create a service group and add previously configured servers as members.
ACOS(config)# slb service-group mysqlgroup tcp
ACOS(config-slb svc group)# member Server07 3306
ACOS(config-slb svc group)# member Server08 3306
ACOS(config)# slb service-group mssqlgroup tcp
ACOS(config-slb svc group)# member MSSQLServer02 1433
ACOS(config)# slb template client-ssl SSL
ACOS(config-client ssl)# cert MSSQL-cert
ACOS(config-client ssl)# key MSSQL-key
5. These commands create two separate DBLB templates to process the My-SQL and MS-SQL que-
ries:
ACOS(config)# slb template dblb DBTemplate
ACOS(config-dblb)# class-list DBUsers
ACOS(config)# slb template dblb MSDBTemplate
ACOS(config-dblb)# class-list MSSQLDBUsers
6. The configuration from step 1 to step 5 are on a single virtual port. These commands create a vir-
tual server and add the service group, templates, and aFleX policy to a virtual port of the virtual
server:
page 278
ACOS(config)# slb virtual-server vic-virt 110.10.10.3

ACOS(config-slb vserver)# port 3306 mysql
ACOS(config-slb vserver-vport)# service-group mysqlgroup
ACOS(config-slb vserver-vport)# template client-ssl SSL
ACOS(config-slb vserver-vport)# aflex DB
ACOS(config-slb vserver-vport)# template dblb DBTemplate
ACOS(config-slb vserver)# port 1433 mssql
ACOS(config-slb vserver-vport)# aflex DB_mssql
ACOS(config-slb vserver-vport)# template dblb MSDBTemplate
page 279
page 280
Financial Information eXchange Load Balancing
ACOS supports Financial Information eXchange (FIX) message load balancing. These sections
describe how to configure FIX load-balancing and customize a FIX template to direct FIX traffic.
Overview of FIX Load Balancing

You can configure FIX load-balancing through the GUI or CLI to direct FIX traffic based on the ID tags of
the financial institutions receiving or sending FIX messages. In addition, you can configure the ACOS
device to insert the client’s IP address into the FIX message header before sending the client request to
a FIX server.
Tag-based Service Group Selection

You can configure FIX load balancing to use a default service group and direct a section of client
requests to a different service group when the TargetCompID (tag 56) or SenderCompID (tag 49) of the
FIX message matches exactly with a specified keyword.
In the following FIX message the TargetCompID is “CUSTOMER6” and the SenderCompID is “FIRM1”:
8=FIX.4.1 9=112 35=0 49=FIRM1 56=CUSTOMER6 34=240 52=43483994-08:01:54 112=68981704-

08:01:36 10=190
An FIX template can direct ACOS to use a different service group for server selection when TargetCom-
pID or SenderCompID of a FIX message matches a keyword. In this example, the keyword “FIRM1”
switches service groups based on the SenderCompID, or “CUSTOMER6” to switch service groups
based TargetCompID.
Client IP Address Insertion

The Insert Client IP option appends the client’s IP address to the FIX message, using the tag 11447.
For example, given the following FIX message:

08:01:36 10=190
If client IP insertion is enabled in the FIX template and the client’s original IP address is 192.168.13.37,
then the FIX message header is revised with the 11447 tag, as shown below in bold:
page 281
Configure FIX Load Balancing

08:01:36 10=190 11447=192.168.13.37
FIX Load Balancing Example

Figure 38 illustrates an example deployment of FIX load balancing. In this example, a FIX template is
applied to the virtual IP address (VIP) 40.40.40.96 and is configured for target switching based on the
SenderCompID tag. The ACOS device directs a client request to the “sg7” service group if the Sender-
CompID tag in the FIX message matches the string “CLIENT1”.
The SenderCompID tag in the FIX message from Client 1 equals “CLIENT1” and is sent to the service
group “sg7” for server selection. Neither the SenderCompID tags nor TargetCompID tags for Client 2
and Client 3 match a target switching keyword in the FIX template. As a result, the requests from Client
2 and Client 3 are directed to the default “fix-sg” service group, bound to the FIX virtual port.
See “CLI Configuration Example” on page 287 for the configuration procedure of this example.
FIGURE 38 FIX Load-balancing – Deployment Example

To configure FIX load balancing:
page 282
1. Configure the real servers that will handle FIX traffic and add the TCP port to each server.
2. Configure a service group for the FIX servers and add the servers to the group.
This is the FIX service group.
3. Create a FIX template to redirect all FIX traffic to the FIX service group.
4. Configure a virtual server that contains the FIX port and bind the port to the FIX service group. Add
the FIX service group and the FIX template to the port.
Use the GUI to Configure FIX Load Balancing

To configure FIX load balancing from the GUI, perform the following tasks:
• Configure Network Resources
• Configure a FIX Template
• Configure a Virtual Server for the FIX Proxy

1. Configure Servers:
b. Select the Servers tab from the menu bar.
c. Click Create. The Create Server page appears.
d. In the Name field, enter a name for the server.
e. Select the Type radio button (IPv4, IPv6, or FQDN) and enter the IP address of the FIX server.
f. In the Port section, click the Create button.
g. In the Port Number field, enter a number between 1-65535.
h. Click the Protocol drop-down menu and select TCP.
i. For the Health Check radio button, select Monitor.
j. From the Health Monitor drop-down menu, select a health monitor to be applied to this port.
k. Click Create. The port appears in the Port list.
l. Click Create again. The server appears in the real server table.
m. Repeat step a to step l for each real server that will process FIX messages.
2. Configure a Service Group:
page 283

b. Select the Service Groups tab from the menu bar.
c. Click Create. The Create Service Group page appears.
d. In the Name field, enter a name for the service group.
e. Click the Protocol drop-down menu and select TCP.
f. In the Member section, click the Create button to add a server to this service group.
g. Select the Existing Server radio button.
h. Click the Server drop-down menu and select the name of a real server from the drop-down
menu.
i. In the Port field, enter the port number.
j. Click Create.
k. Repeat step a to step j for each server.
l. Click Create. The new service group appears in the service group table.
Configure a FIX Template

3. Click Create and from the drop-down menu that appears, select FIX. The Create FIX Template
appears.
4. Enter a Name for the template.
5. Select the Insert Client IP radio button to append the client’s IP address to the FIX message header
before forwarding the message. (Client IP insertion is disabled by default.)
6. For Tag Switching Type, click the drop-down menu and select one of the following options:
• Sender Comp ID – The ACOS device selects a service group for FIX requests based on the value
of the SenderCompID tag. This tag identifies the financial institution that is sending the request.
• Target Comp ID – The ACOS device selects a service group for FIX requests based on the value
of the TargetCompID tag. This tag identifies the financial institution to which the request is
being sent.
7. Click the drop-down menu from the right-most column and select the desired service group. By
default, ACOS uses the service group that is bound to the virtual port.
8. If you select the Sender Comp ID or Target Comp ID, these options can be entered in the center
field:
page 284
• Equals – Specifies the keyword which the ACOS device will match against the TargetCompID or
SenderCompID tag. Enter a 1-63 character string. The keyword is case sensitive and must
match exactly with the SendCompID tag or TargetCompID tag. For example, “ABC” is different
from “Abc”.
• Service Group – Specifies a service-group to use for client requests that match the tag value.
9. Click OK to save your changes.
Configure a Virtual Server for the FIX Proxy

3. Click Create.
5. Select the IPv4 or IPv6 radio button and enter the IP address which will receive clients’ FIX mes-
sages.
6. In the Virtual Port section, click the Create button.
a. Click the Protocol drop-down menu and select FIX.
b. In the Port field, enter the FIX port number. This can be a value between 1-65535.
c. Click Templates to expand the template configuration options, and click the Template FIX
drop-down menu and select the FIX template configured above.
d. Click Create. The virtual port appears in the Virtual Port list for the virtual server.
7. Click Update. The virtual server appears in the virtual server table.
Use the CLI to Configure FIX Load Balancing

To configure FIX load balancing from the CLI, perform the following tasks:
1. Configure Network Resources

2. Configure a FIX Template
3. Configure a Virtual Server for the FIX Proxy
A complete CLI example is provided in “CLI Configuration Example” on page 287.
page 285

a. To configure a real server for each FIX server and add the TCP port, use the following com-
mands:
Enter the slb server command at the global configuration level.
Enter the port command at the configuration level of the real server.
Enter the health-check command at the configuration level of the port.
b. Repeat for each real server that processes FIX messages.
a. To configure a service group for the FIX servers and add servers to the group:
Enter the slb service-group command at the global configuration level:
Enter the member command at the configuration level for the service group:
b. Repeat for each server.
Configure a FIX Template

1. To create a FIX template, use the slb template fix command, which changes the CLI to the con-
figuration level for the template, where the following insert-client-ip is available.
This command inserts the client IP address into tag 11447, and recalculates the checksum of the
request packet, before sending the request to a FIX server.
2. Optionally, use one of the following commands to configure Tag Switching. If you do not specify
this option, ACOS selects the default service group that is bound to the virtual port.
The tag-switching sender-comp-id equals command selects a service group for FIX requests
based on the SenderCompID tag value. This tag identifies the financial institution that is sending
the request.
The tag-switching target-comp-id equals command selects a service group for FIX requests
based on the TargetCompID tag value, which identifies the financial institution wheer the request
is sent.
Configure a Virtual Server for the FIX Proxy

Use the following commands to configure a virtual server:
1. Use the slb virtual-server command at the global configuration level. Specify an IP address to
receive FIX traffic. This command changes the CLI to the configuration level for the virtual server.
2. Enter the port command to create a port for FIX traffic:
page 286
3. Use the service-group command to bind the FIX group to the virtual port.
4. Enter the template fix command to bind a FIX template to the virtual port:
CLI Configuration Example

This example describes how to configure FIX load balancing and bind a FIX template to a virtual port
(vport). These steps are described with respect to the deployment example in Figure 38 on page 282.
Configure the real servers that will handle FIX messages:

ACOS(config)# slb server fix-server1 40.40.40.3
5. Create a service group and add the servers configured in step to the group:
ACOS(config)# slb service-group fix-sg tcp
ACOS(config-slb svc group)# member fix-server1 333
6. (Not shown) Configure an additional service group to use for FIX messages that contain an ID tag
which matches the tag switching keyword:
7. Create a FIX template with tag switching based on the SenderCompID or TargetCompID. In this
example, if the client sends a FIX request with tag “49=CLIENT1”, the ACOS device uses the alter-
native service group “sg7” for server selection.
ACOS(config)# slb template fix fix-exmpl
ACOS(config-fix)# insert-client-ip
ACOS(config-fix)# tag-switching sender-comp-id equals CLIENT1 service-group sg7
ACOS(config-fix)# exit
8. Create a virtual server and adds the FIX service groups:

ACOS(config)# slb virtual-server v6 40.40.40.96
ACOS(config-slb vserver)# port 5001 fix
ACOS(config-slb vserver-vport)# service-group fix-sg
page 287
View FIX Traffic Statistics
ACOS(config-slb vserver-vport)# template fix fix-exmpl

View FIX Traffic Statistics

This section describes how to view FIX load balancing counters from the ACOS CLI.
Use the CLI to View FIX Traffic Statistics

To display FIX SLB statistics, use the show slb fix command.
page 288
Short Message Peer-to-Peer Load Balancing
ACOS supports server load balancing for Short Message Peer-to-Peer (SMPP 3.3) data communication.
This chapter describes the feature and how to configure it.
Overview
The SMPP 3.3 protocol uses a long-lived TCP connection to exchange a high number of messages
between an External Short Message Entity (ESME) and Short Message Service Center (SMCC). In this
section, the ESME is referred to as the SMPP client and the SMCC are the SMPP servers which process
client requests.
The ACOS device serves as a secure SMPP proxy to the SMCC and load balances SMPP communica-
tion from the ESME across a collection of SMPP servers. You can configure SMPP load-balancing to
process messages when the SMPP client is a receiver and load-balancing incoming client requests
among servers in the SMCC.
SMPP load balancing can be achieved under different layers of complexity:
• General (Basic) – SMPP load balancing is configured by creating an SMPP-TCP virtual port and
directing client traffic to the port.
• General (Advanced) – SMPP load balancing uses a SMPP-TCP virtual port and includes an SMPP
template for additional configuration options (such as keepalive messages). Optionally, a con-
nection-reuse template is applied to the VIP for connection persistence to the SMPP servers.
• Advanced with Client Authentication – This configuration includes an SMPP template, connec-
tion-reuse template, and authenticates clients with a shared username-password pair, applied to
the clients and SMPP servers. If the ESME is a collection of clients that can all equally receive
SMS messages and the SMPP servers carry the same database information, this is a circum-
stance that requires the advanced configuration procedure with client authentication.
page 289
Configure SMPP Load Balancing (General)
SMPP Multiplexing
You can configure the ACOS device to consistently route client requests to a single SMPP server. This
option is especially useful in cases where the number of SMPP clients is unknown and the ACOS
device must consistently maintain an open connection between SMPP clients and SMPP processing
center. To direct multiple SMPP client requests to the same SMPP server, configure a connection-
reuse template with pre-open enabled, and apply the template to the SMPP service group.
The ACOS device will authenticate the initial connection to the SMPP server with the clients’ shared
user-name password pair (configured within the SMPP template). All subsequent requests from the
SMPP clients are then sent directly to the same SMPP server, using the pre-opened connection.
SMPP Client and Server Keepalive
SMPP services often require client-to-server connections to remain persistently open. ACOS provides
configuration options with the SMPP template to send keepalive messages (sent as
ENQUIRE_LINK_RESP and ENQUIRE_LINK packets) to the SMPP clients and servers. To send
keepalive messages for connections which process SMPP traffic, enable one or both of the following
options within the SMPP template:
• Client Enquire Link – When this option is enabled, the ACOS device replies to clients directly with
an ENQUIRE_LINK_RESP message. This feature is applicable regardless of whether you use the
ACOS device to multiplex SMPP connections.
• Server Enquire Link – When this option is enabled, ACOS regularly sends an ENQUIRE_LINK mes-
sage to the SMPP server to maintain the ACOS-to-server connection. Enable the Server Enquire
Link option to prevent reusable connections to the server from aging out. The Server Enquire Link
option applies only to configurations that include a connection reuse template.
You must include a connection-reuse template to use the Server Enquire Link template option.

To configure load balancing for SMPP traffic:
1. Configure a real server for each SMPP server that handles SMPP messages. Add a TCP port to
each server.
2. Create a service group for the SMPP servers. Add the servers to the group. This is the SMPP ser-
vice group.
3. (Optional) Configure a SMPP template to enforce additional SMPP configuration options (such as
keepalive messages, server selection method, and so on).
4. (Optional) Configure a connection-reuse template.
page 290
5. Configure a virtual server that contains the SMPP-TCP port and bind the port to the SMPP service
group. Add the SMPP service group and the SMPP template to the port.
Configure SMPP Load Balancing (GUI Procedure)

The following section describes how to configure SMPP load-balancing from the ACOS GUI.
b. From the menu bar, select the Servers tab, and then click Create.
c. In the Name field, enter a name for the server.
d. In the Type section, select the IPv4, IPv6, or FQDN radio button, and then enter the IP address
or Hostname for the SMPP server.
e. In the Port section, click the Create button.
f. In the window that appears, enter the SMPP port number in the Port field. (SMPP typically uses
port number 2775.)
g. Click the Protocol drop-down menu and select TCP.
h. In the Health Check option, select the desired radio button. Choices include: Default, Disable,
Monitor, Follow Port
If selecting Monitor, then click the Health Monitor drop-down menu and desired monitor.
If selecting Follow Port, then select TCP from the drop-down menu and enter the number in the
Follow Port field.
Even when the SMPP server is up, some SMPP servers may not always send the correct response
message to a TCP health check. To avoid setting the SMPP server’s state to CLOSE_WAIT, enable
the half-open option for the health check.
i. Click Create. The port appears in the Port list.
j. Click Update. The new SMPP server appears in the real server table.
k. Repeat step a to step j for each real SMPP server that will process SMPP messages.
b. From the menu bar, select the Service Groups tab and click Create.
c. In the Name field, enter a name for the service group.
page 291
d. Click the Protocol drop-down menu and select TCP.

e. In the Member section, click the Create button.
f. From the window that appears, click the Server drop-down menu and select the name of the
real SMPP server.
g. In the Port field, enter the SMPP port number. (SMPP typically uses port number 2775.)
h. Click Create.
i. Repeat step a to step h for each SMPP server.
j. Click Update. The new group appears in the service group table.
(Optional) Configure an SMPP Template
Optionally, you can include an SMPP template to configure additional aspects of SMPP load-
balancing. Perform the following steps to configure an SMPP template:

2. Click the L7 Protocols tab from the menu bar.
3. Click the Create button and select SMPP.
4. In the Create SMPP Template window that appears, enter a name for the SMPP template.
5. Configure the following template options by selecting the Enable radio button for each:
• Client Enquire Link – When this option is enabled, ACOS replies to clients directly with an
ENQUIRE_LINK_RESP message. The Client Enquire Link option prevents the client connection
from timing out and serves the same purpose as a keepalive message.
• Server Enquire Link – Enable the Server Enquire Link option to prevent reusable connections to
the SMPP server from aging out. When this option is enabled, ACOS regularly sends an
ENQUIRE_LINK message to the SMPP server to maintain the client-to-server connection. You
can specify an interval of 5-300 seconds at which the keepalive message is sent. The default is
30 seconds.
You must include a connection-reuse template to use the Server Enquire Link option.
• Server Selection Per Request – Optionally, enable this option to force the ACOS to perform the
server selection process for every SMPP request. Without this option, the ACOS device rese-
lects the same server for subsequent requests (assuming the same server group is used),
unless overridden by other template options.
The Server Selection Per Request option works only in conjunction with connection-reuse. In
addition, this option requires that a username-password pair is used the SMPP template, so
that ACOS can immediately authenticate SMPP clients for every instance of server selection.
6. Enter a User name and Password which the ACOS device will use to authenticate SMPP clients.
All clients must use a shared username-password pair.
7. Click Create. The new template appears in the SMPP template table.
page 292
(Optional) Configure a Connection Reuse Template
From the CLI only you can enable the keep-alive-conn preopen option for the connection-reuse tem-
plate. The preopen command is required if the username-password pair, server-enquire-link, or server-
selection-per-request option is enabled in the SMPP template.
Optionally, you can include a connection reuse template for SMPP multiplexing. Perform the following
steps to configure a Connection-reuse template:
1. Navigate to ADC > Templates.

2. Select the Application tab from the menu bar.
3. Click the New Template button and select Connection Re-Use.
4. In the window that appears, enter a name for the Connection Re-Use template.
5. Configure the following template options:
• Limit Per Server – Limits the maximum number of reusable connections per server port. You
can specify 0 (unlimited) to 65535. The default is 1000.
• Timeout – Sets the length of time a reusable connection can remain idle before the ACOS
device closes the connection. You can specify 1 to 3600 seconds. The default is 2400 seconds.
• Keep Alive Connections – Specifies the number of new reusable connections to open before
beginning to reuse the existing connections. In the Connections per Server Port field, spec-
ify 1 to 1024 connections. This option is disabled by default. When enabled, the default is 100
connections. Select the Enable radio button for Pre-open.
6. Click Create.
Configure a Virtual Server for the SMPP Proxy

2. From the menu bar, select the Virtual Servers tab, and then click Create.
4. For Address Type, select the IPv4 or IPv6 radio button.
5. Enter the IP address which will receive clients’ SMPP messages.
a. From the window that opens, click the Protocol drop-down menu and select SMPP-TCP.
b. In the Port field, enter the SMPP-TCP port number. This can be a value between 1-65535. The
default port number is 2775.
c. (Optional) Click Templates to expand these options. Click the Template SMPP and then select
the pre-configured SMPP template from the drop-down menu.
d. Click Create. The port appears in the Virtual Port list for the virtual server.
page 293
7. Click Update. The virtual server appears in the Virtual Server table.
Configure SMPP Load Balancing (CLI Procedure)

This section describes how to configure SMPP load-balancing from the global configuration level of the
CLI:
a. To configure a real server for each SMPP server and add the TCP port, use the following com-
mands:
Enter the slb server command at the global configuration level:
Enter the port command at the configuration level of the real server:
Enter the health-check command at the configuration level of the TCP port:
Even when the SMPP server is up, some SMPP servers may not always send the correct
response message to a TCP health check. To avoid setting the SMPP server’s state to
CLOSE_WAIT, enable the half-open option for the health check.
b. Repeat for each real SMPP server that processes SMPP messages.
a. To configure a service group for SMPP servers and add servers to the group, use these com-
mands:
Enter the slb service-group command at the global configuration level:
Enter the member command at the configuration level for the service group:
b. Repeat for each SMPP server.
(optional) Configure an SMPP Template
1. Use the slb template smpp command to create an SMPP template.

2. Enter one of these commands to configure the SMPP template options:
• client-enquire-link – When this option is enabled, ACOS replies to clients directly with an
ENQUIRE_LINK_RESP message. Enabling this option prevents client connections from timing
out.
• server-enquire-link – Enable the Server Enquire Link option to prevent reusable SMPP server
connections from aging out. When this option is enabled, ACOS regularly sends ENQUIRE_LINK
messages to the SMPP server to maintain the client-to-server connection.
• server-selection-per-request – Optionally, enable this option to force ACOS to perform
server selection process for every SMPP request. Without this option, the ACOS device rese-
page 294
lects the same server for subsequent requests (assuming the same server group is used),
unless overridden by other template options. The server-selection-per-request option only
works in conjunction with connection-reuse. In addition, this option requires that a username-
password pair is used the SMPP template, so that ACOS can immediately authenticate SMPP
clients for every instance of server selection.
3. Use the user command to create a username and password for client authentication:
(Optional) Configure a Connection Reuse Template
1. Optionally, use the slb template connection-reuse command at the global configuration level of
the CLI to create a connection-reuse template for SMPP multiplexing. This command changes the
CLI to the configuration level of the template, where the following commands are available:
This timeout command specifies the maximum period a connection can remain idle before the
connection times out.
This limit-per-server command specifies the maximum number of reusable connections per
port.
This keep-alive-conn command specifies the number of new reusable connections to open
before beginning to reuse the existing connections.
Configure a Virtual Server for the SMPP Proxy
Use the following commands to configure a virtual server:
1. Use the slb virtual-server command at the global configuration level of the CLI.
2. Enter the port command to create a TCP port for SMPP traffic:
3. Use the service-group command to bind the SMPP group to the virtual port.
4. Use the template smpp or template connection-reuse commands to bind templates to the vport.
Configure SMPP Load Balancing (CLI Example)

This example describes how to configure SMPP load balancing when a collection of clients (the ESME)
can equally receive responses from SMPP servers and the servers contain the same database informa-
tion.
To configure advanced load balancing of SMPP traffic with client authentication, perform these steps:
1. Configure a real server for each SMPP server that will handle SMPP messages and add TCP port to
each.
2. Create a service group for the SMPP servers; add the servers to the group. This is the SMPP ser-
vice group.
3. Configure an SMPP template with a username-password pair and enable server selection per
request.
page 295
4. Configure a connection-reuse template and enable the keepalive option for pre-opened connec-
tions.
Step 4 can be achieved from the CLI only.
5. Configure a virtual server that contains the SMPP-TCP port and bind the port to the SMPP service
group. Add the SMPP service group and the templates to the port.
Figure 39 shows an example deployment of advanced SMPP load balancing, using shared password
authentication for a collection of SMPP clients.
FIGURE 39 SMPP LB – Advanced
Using the CLI
Perform the following steps from the ACOS CLI:
1. Configure the real SMPP servers that will process client requests:
ACOS(config)# slb server SMPP-Server 16.20.23.10
ACOS(config-real server-node port)# health-check ping
ACOS(config)# slb server SMPP-Server2 16.20.23.2
page 296

ACOS(config)# slb server SMPP-Server3 16.20.23.6
page 297
2. Create an SMPP service group and add the SMPP servers configured in step 1 to the group:
ACOS(config)# slb service-group SMPP-group tcp
ACOS(config-slb svc group)# member SMPP-Server 4354
ACOS(config-slb svc group)# member SMPP-Server2 4441
ACOS(config-slb svc group)# member SMPP-Server3 2331
3. (Not shown) Create a SNAT IP address pool for the collection of SMPP servers. In this example, the
SNAT pool is named “SMPPpool” and contains servers within the IP address range 16.20.23.5-20.
4. Create an SMPP template and configure the template with a username-password pair and server-
selection-per-request. Optionally, enable client-enquire-link and server-enquire-link to
send keepalive messages to the SMPP clients and servers:
ACOS(config)# slb template smpp SMPP-Template
ACOS(config-smpp)# client-enquire-link
ACOS(config-smpp)# server-enquire-link 145
ACOS(config-smpp)# user net-admin password maplebar
ACOS(config-smpp)# server-selection-per-request
ACOS(config-smpp)# exit
5. Configure a connection-reuse template for SMPP service group and enable keep-alive-conn pre-
open.
ACOS(config)# slb template connection-reuse SMPP-connreuse
ACOS(config-conn reuse)# keep-alive-conn preopen 50
ACOS(config-conn reuse)# exit
6. Create an SMPP virtual server, add the SMPP-TCP port and apply the SMPP service group, SMPP
template, and connection-reuse templates to the virtual server:
ACOS(config)# slb virtual-server SMPP-virt 100.10.100.4
ACOS(config-slb vserver)# port 6874 SMPP-TCP
ACOS(config-slb vserver-vport)# source-nat pool SMPP-pool
ACOS(config-slb vserver-vport)# service-group SMPP-group
ACOS(config-slb vserver-vport)# template smpp SMPP-Template
ACOS(config-slb vserver-vport)# template connection-reuse SMPP-connreuse
Display SMPP Load Balancing Statistics

To display SMPP SLB statistics, use the show slb smpp command. The detail option shows statistics
separately for each CPU. Without this option, aggregate statistics are shown for all CPUs. For information
about the counters in this command’s display, see Table 3.
page 298
Table 3 describes the fields for SMPP traffic counters.
TABLE 3 SLB > Application > Proxy > SMPP

Field Description
SMPP msg mem allocated Statistics used by A10 Technical Support.
SMPP msg mem cached
SMPP msg mem freed
SMPP msg payload allocated
SMPP msg payload freed
Curr SMPP Proxy Number of currently active connections using the SMPP proxy.
Total SMPP Proxy Total number of connections that have used the SMPP proxy.
Client message rcvd Total number of SMPP messages received from clients.
• Sent to server – Number of SMPP messages received by the client

and forwarded to the server.
• Incomplete – Number of packets which contain incomplete mes-
sages.
• ACOS responds directly – Number of times the ACOS device
responded directly to a client’s request.
• Drop – Number of packets dropped due to configured SMP resource
limit.
• Connecting server – Number of times the ACOS device forwarded a
client’s request to the SMPP server.
• Failed – The following counters display the number of failed connec-
tions, listed by the cause:
• Failed to parse
• Failed to process
• Failed to SNAT
• Exceeded buff
• Failed to send
• Server conn start failed
Server message rcvd Total number of SMPP messages received from servers.
• Sent to client – Number of SMPP messages received by the server

and forwarded to the client.
• Incomplete – Number of packets which contain incomplete mes-
sages.
• Drop – Number of packets dropped due to configured SMP resource
limit.
• Failed – Number of SMPP messages the server received that were not
forwarded to the client. These counters display the number of failed
connections, listed by cause:
• Failed to parse
• Failed to process
• Failed to sel client conn
• Failed to SNAT
• Exceeded buff
• Failed to send
page 299

Field Description
Server conn created • Created successfully – Number of server connections created suc-
cessfully.
• Failed – Number of failed server connection attempts, listed by cause:
• Failed to SNAT
• Failed to construct
• Failed to reserve
• Failed to start
• Server conn already exists
• Failed to insert
Message parsing failed Number of SMPP messages that the ACOS failed to parse. The following
sub-counters describe the cause:
• The packet size too small – Number of SMPP messages that were not
parsed because the message size was less than 4 bytes.
• Invalid sequence number – SMPP messages are incremented by +1.
This counter indicates the total number of SMPP messages that were
not parsed because of an incorrect sequence number.
Message processing failed Number of times the ACOS could not process the SMPP message. The
following sub-counters describe the cause:
• No vport – There was no virtual port that matched the destination of

the SMPP message.
• Failed to select server – Server selection failure to forward the SMPP
request.
Client conn selection The following counters apply to SMPP client selection:
• Select by request – Number of client connections, selected by the

type of request message.
• Select by roundbin – Number of client connection selected by the
Round Robin algorithm.
• Select by conn – Number of client connections, selected by the con-
nection type.
• Select failed – Number of times the ACOS failed to select a client for
the SMPP connection.
Server conn selection The following counters apply to SMPP server selection:
• Select by request – Number of server connections, selected by the

type of request message.
• Select by roundbin – Number of server connection selected by the
Round Robin algorithm.
• Select by conn – Number of server connections, selected by connec-
tion type.
• Select failed – Number of times the ACOS failed to select a server for
the SMPP connection.
Bind client and server Number of times the ACOS successfully forwarded the initial BIND mes-
sage from a client an SMPP server.
Unbind client and server Number of times the ACOS disconnected the client to an SMPP server.
page 300

Field Description
Receive enquire_link Total number of ENQUIRE_LINK messages that the ACOS received from
the SMPP client or server.
Receive enquire_link_resp Total number of ENQUIRE_LINK_RESP messages that the ACOS
received from the SMPP client or server.
Send enquire_link Total number of ENQUIRE_LINK messages that the ACOS device has
sent.
Send enquire_link_resp Total number of ENQUIRE_LINK_RES messages the ACOS device sent.
Put client conn in list Statistics used by A10 Technical Support.
Get client conn from list
Put server conn in list
Get server conn from list
Fail to bind server
Single message
Transfer msg from L4 to L7 CPU
Fetch msg from L7 CPU
Transfer msg from proxy to conn
CPU
Fetch msg from conn CPU
Transfer msg from L7 to L4 CPU
Transfer msg from conn to proxy
CPU
Fail to dcmsg
Conn is deprecated during dcmsg
Alloc mem failed
Unexpected error
Identify L7 CPU failed
ACOS holds msg
Splited packet
Message in pipeline
Client RST Number of times TCP connections with clients were reset.
Server RST Number of times TCP connections with servers were reset.
page 301
page 302
Part V Part V
Application Offload and Optimization
This section contains topics pertaining to application offload and optimization.
The following topics are included:
• “SSL Certificate Management and Options” on page 305

• “SSL Offload and SSL Proxy” on page 345
• “Secure FTP Proxy” on page 357
• “ALG Protocol FWLB Support for FTP and SIP” on page 363
• “DNS Optimization” on page 389
• “RAM Caching” on page 411
• “Transparent Cache Switching” on page 421
• “Destination Hash-Based TCS” on page 457
• “STARTTLS for Secure SMTP” on page 459
• “Diameter AAA Load Balancing” on page 469
• “RADIUS Message Load Balancing” on page 479
• “SNMP-Based Load Balancing” on page 487
• “Advanced Traffic Replication” on page 493
• “Outbound Next Hop Load Distributor” on page 499
• “HTTP Proxy” on page 505
• “Redirection of Traffic to ICAP Servers” on page 563
SSL Certificate Management and Options
The following topics are covered in this chapter:
• Overview of SSL Certificate Management
• Importing a Certificate and Key
• Generating CAs and CSRs
• Configuring Email Notification for SSL Certificate Expiration
• SSL Certificate Notification via System Log Warnings
• Converting Certificates and CRLs to PEM Format
• Importing a CRL
• SSL File Delete
• Exporting Certificates, Keys, and CRLs
• Example of Importing a CA Cert and Private Key for SSLi
• Forward Proxy Alternate Signing Cert and Key
• Simple Control Enrollment Protocol (SCEP)
This chapter describes how to manage SSL certificates, private keys, and Certificate Revocation Lists
(CRLs) on the ACOS device. Installing these SSL resources on the ACOS device enables the ACOS
device to provide SSL services on behalf of real servers.
You can use the ACOS device to offload SSL processing from servers or, for some types of traffic, you
can use the ACOS device as an SSL proxy. (For more information about SSL offload and SSL proxy, see
“SSL Offload and SSL Proxy” on page 345.)
Overview of SSL Certificate Management

Some types of client-server traffic need to be encrypted for security. For example, traffic for online
shopping must be encrypted to secure sensitive account information from being stolen.
Commonly, clients and servers use Secure Sockets Layer (SSL) or Transport Layer Security (TLS) to
secure traffic. For example, a client that is using a shopping application on a server will encrypt data
before sending it to the server. The server will decrypt the client’s data, then send an encrypted reply to
the client. The client will decrypt the server reply, and so on.
page 305
Notes
• SSL is an older version of TLS. The ACOS device supports the following SSL and TLS versions:
• SSL v3.0
• TLS v1.0
• TLS v1.1
• TLS v1.2 (the default)
• ACOS supports RFC 3268, AES Ciphersuites for TLS. For simplicity, elsewhere this document and
other ACOS user documents use the term “SSL” to mean both SSL and TLS.
• ACOS supports secure renegotiation of client-server TLS connections, as described in RFC 5746,
Transport Layer Security (TLS) Renegotiation Indication Extension. Support for the renegotia-
tion_info TLS extension is included. Secure TLS renegotiation allows ACOS to securely renegoti-
ate TLS connections with clients, using existing secure connections. RFC 5746 support is
automatically enabled for client-server TLS sessions.
• ACOS supports Privacy Enhanced Mail (PEM) format for certificate files and CRLs. ACOS SSL
processing supports PEM format and RSA encryption.
The 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 ACOS 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 ACOS device.
Figure 40 shows a simplified example of an SSL handshake. In this example, the ACOS device is acting
as an SSL proxy for backend servers.
page 306
FIGURE 40 Typical SSL Handshake (simplified)
To begin, the client sends an HTTPS request. The request includes some encryption details such as the
cipher suites supported by the client.
The ACOS 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 ACOS 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 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.
page 307
If the CA that signed the certificate is a root CA, the client browser needs a copy of the root CA’s certifi-
cate. 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 41 shows an example of a certificate
chain containing three certificates:
FIGURE 41 SSL Certificate Chain Example
-----BEGIN CERTIFICATE-----
ZS9naWYwITAfMAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRw
Oi8vbG9nby52ZXJpc2lnbi5jb20vdnNsb2dvMS5naWYwDQYJKoZIhvcNAQEFBQAD
gYEAheIVEe8vArUOZxKkUIGjaYymzJAh8Ty0uUPrikLpQ0IGezByVdbDUJ+HQLGp
2eruTPZpBNADaEfymstIPIxrsuCRhyr3Ymsa2rgzwy9kSXeG83H7E7HxRnpxDNZ8
l+uzpU/rk4j3bO/JVxPZMnwzMWriPSYgL1EKYcOSKyReACOSQ=
-----END CERTIFICATE-----
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 signa-
ture authority that was signed the root CA.
A certificate chain in an SSL template must begin at the top with the root CA’s certificate, followed in
order by the intermediary certificates. If the certificate authority that signs the server certificate does
not provide the 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 41.
page 308
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 ACOS 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 42 shows an example of a certificate warning displayed by
Internet Explorer.
FIGURE 42 Example of Certificate Warning
NOTE: It is normal for the ACOS device to display a certificate warning when an
admin accesses the ACOS management GUI. Certificates used for SLB
are not used by the management GUI.
CA-Signed and Self-Signed Certificates

Typically, clients have a certificate store that includes certificates signed by the various root CAs. The
certificate store may also have some non-CA 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 CA-signed certificate, an admin creates a key and a Certifi-
cate Signing Request (CSR), and sends the CSR to the CA.The CSR includes the key.
The CA then creates and signs a certificate. The admin installs the certificate on the ACOS device.
When a client sends an HTTPS request, the ACOS device sends a copy of the certificate to the cli-
ent, to verify the identity of the server (ACOS device).
page 309
To ensure that clients receive the required chain of certificates, you also can send clients a certifi-
cate chain in addition to the server certificate. (See “Certificate Chain” on page 307.)
The example in Figure 40 on page 307 uses a CA-signed certificate.
• Self-signed – A self-signed certificate is a certificate that is created and signed by the ACOS
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 CA-signed certificate than a self-signed certificate. If you config-
ure the ACOS device to present a self-signed certificate to clients, the client’s browser may display a
certificate warning. This can be alarming or confusing to end users. Users can select the option to trust
a self-signed certificate, in which case the warning will not re-appear.
SSL Templates
You can install more than one key-certificate pair on the ACOS device. The ACOS device selects the cer-
tificate(s) to send a client or server based on the SSL template bound to the VIP. You can bind the fol-
lowing types of SSL templates to VIPs:
• Client-SSL template – Contains keys and certificates for SSL-encrypted traffic between clients
and the ACOS device. A client-SSL template can also contain a certificate chain.
• Server-SSL template – Contains CA certificates for SSL-encrypted traffic between servers and
the ACOS device.
NOTE: If you replace a certificate and key in a client-SSL or server-SSL template,

you must unbind the template from the virtual ports that use it, then
rebind the template to the virtual ports, to place the change into effect.
Client-SSL Template Configuration and Usage Guidelines

Use client-SSL templates for deployments in which traffic between clients and the ACOS device will be
SSL-encrypted. Client-SSL templates have the following options.
For the simple deployment example in Figure 40 on page 307, only the first option (Certificate) needs to
be configured. You may also need to configure the Certificate chain option.
A client-SSL template can contain up to 128 certificates or certificate chains.
• Certificate – Specifies the server certificate that the VIP will send to a client when configured for
SSL proxy, SSL offload, or SSLi operation. The client uses this certificate to validate the server’s
identity. The certificate can be generated on the ACOS device (self-signed) or can be signed by
another entity and imported onto the ACOS device.
page 310
Only one certificate can be associated with the client-SSL template. Use the show pki cert com-
mand to show the list of certificates and private keys stored on the ACOS device.
• Key – Specifies the name of a private key for a server certificate. If the CSR used to request the
server certificate is generated on the ACOS device, the private key is automatically generated by
the ACOS device, and then the private key is used to create the public key sent to the CA in the
CSR. Otherwise, the key must be imported.
Only one key can be associated with the client-SSL template. Use the show pki cert command to
show the list of certificates and private keys stored on the ACOS device.
• Certificate chain – Specifies a named set of server certificates beginning with a root CA certifi-
cate, 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 307.)
• CA-Certificate – Specifies a CA certificate that the ACOS device can use to authenticate the iden-
tity of a client the requesting to connect to the ACOS device. If CA certificates are required, they
must be imported onto the ACOS device. The ACOS device is not configured at the factory to con-
tain a certificate store.
Multiple CA-certificate can be associated with the client-SSL template. Use the show pki ca-cert
command to show the list of ca-certificates.
• 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 ACOS device will be required to val-
idate the identities of clients.
NOTE: The CRL should be signed by the same issuer as the CA certificate. Oth-
erwise, the client and ACOS device will not be able to establish a connec-
tion.
• SSLv2 bypass – Redirects clients who request SSLv2 sessions to the specified service group.
• Client connection-request response – Specifies the ACOS response to connection requests from
clients. This option is applicable only if the ACOS device will be required to validate the identities
of clients. The response can be one of the following:
• ignore (default) – The ACOS device does not request the client to send its certificate.
• request – The ACOS 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 ACOS 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.
page 311
• Session cache size – Specifies the maximum number of cached sessions for SSL session ID
reuse.
• Session cache timeout – Sets the maximum number of seconds a cache entry can remain
unused before being removed from the cache. Cache entries age according to the ticket age
time. The age time is not reset when a cache entry is used.
• Session ticket lifetime – Sets the lifetime for stateless SSL session ticketing. After a client’s SSL
ticket expires, they must complete an SSL handshake in order to set up the next secure session
with ACOS.
• Close-notify – Specifies whether the ACOS device sends a close_notify message when an SSL
transaction ends, before sending a FIN. This behavior is required by certain types of applications,
including PHP cgi.
• SSL False Start – Specifies whether SSL False Start is enabled. SSL False Start is an SSL modifi-
cation used by the Google Chrome browser for web optimization.
NOTE: The following ciphers are not supported with SSL False Start:
SSL3_RSA_DES_64_CBC_SHA
SSL3_RSA_RC4_40_MD5
TLS1_RSA_EXPORT1024_RC4_56_MD5
If no other ciphers but these are enabled in the client-SSL template, SSL
False Start handshakes will fail.
• Cipher – Name of a cipher template containing a set of ciphers to use with clients. By default, the
client-SSL template’s own set of ciphers is used. (See “Cipher Template Configuration and Usage
Guidelines” on page 314.)
• Forward proxy options – Options that are used for SSL Insight.
• Authentication username attribute – Specifies the field to check in SSL certificates from clients,
to find the client name.
• Cipher Template – Specifies the cipher suites supported by the ACOS device. When the client
sends its connection request, it also sends a list of the cipher suites it can support. The ACOS
device selects the strongest cipher suite supported by the client that is also enabled in the tem-
plate, and uses that cipher suite for traffic with the client. For a list of supported ciphers, refer to
the slb template cipher command in the Command Line Interface Reference.
Server-SSL Template Configuration and Usage Guidelines

A server-SSL template is needed only if traffic between the ACOS device and real servers will be
encrypted using SSL. In this case, the ACOS device will be required to validate the identities of the serv-
ers.
page 312
• CA-Certificate – Specifies a CA certificate that the ACOS device can use to authenticate the iden-
tity of a server the ACOS device is connecting to. If CA certificates are required, they must be
imported onto the ACOS device. The ACOS device is not configured at the factory to contain a
certificate store.
Multiple CA-certificate can be associated with the client-SSL template. Use the show pki ca-cert
command to show the list of ca-certificates. If you need to use multiple CA certificates in a server-
SSL template, see “Multiple CA Certificate Support in Server-SSL Templates” on page 329.)
• Certificate – Specifies a client certificate that the ACOS device will send to a server when
requested for client authentication. In SSL proxy and SSL Insight, when a server requests a cli-
ent’s digital certificate, the ACOS device responds on behalf of the client. Following successful
authentication, the server and ACOS device communicates over an SSL-encrypted session.
In SSL Proxy, the client and ACOS device communicate over a non-encrypted session. From the
server’s perspective, the server has an encrypted session with the client.
In SSL Insight, the client and ACOS device communicate over an encrypted session. From the cli-
ent’s and the server’s perspective, the SSL session is fully encrypted.
• Key – Specifies a private key for the client certificate.
• SSL version – Highest (most secure) version of SSL/TLS to use. The ACOS device supports the
following SSL/TLS versions:
• SSL v3.0
• TLS v1.0 (the default)
• TLS v1.1
• TLS v1.2
• Close notification – Specifies whether the ACOS device sends a close_notify message when an
SSL transaction ends, before sending a FIN. This behavior is required by certain types of applica-
tions, including PHP cgi.
NOTE: The close notification option may not work if connection reuse is also
configured on the same virtual port. In this case, when the server sends a
FIN to the ACOS device, the ACOS device will not send a FIN followed by
a close notification. Instead, the ACOS device will send a RST.
• Cipher template – Name of a cipher template containing a set of ciphers to use with servers. By
default, the server-SSL template’s own set of ciphers is used. (See “Cipher Template Configura-
tion and Usage Guidelines” on page 314.)
• Forward proxy – Enables support for capabilities required for SSL Intercept.
• Session cache size – Specifies the maximum number of cached sessions for SSL session ID
reuse.
page 313
• Session cache timeout – Sets the maximum number of seconds a cache entry can remain
unused before being removed from the cache. Cache entries age according to the ticket age
time. The age time is not reset when a cache entry is used.
• Session ticket lifetime – Sets the lifetime for stateless SSL session ticketing. After an SSL ticket
expires, the SSL handshake must be performed again in order to set up the next secure session
with ACOS.
• Cipher list – Specifies the cipher suites supported by the ACOS device. When the server sends its
connection request, it also sends a list of the cipher suites it can support. The ACOS device
selects the strongest cipher suite supported by the server that is also enabled in the template
and uses that cipher suite for traffic with the server. The same cipher suites supported in client-
SSL templates are supported in server-SSL templates, for CA certificates. Support for all of them
is enabled by default.
NOTE: For client certificates, the key length for SSL3_RSA_DES_40_CBC_SHA

and SSL3_RSA_RC4_40_MD5 must be 512 bits or less. The TLS1_RSA_-
EXPORT1024_RC4_56_MD5 and TLS1_RSA_EXPORT1024_RC4_56_-
SHA ciphers are not supported.
Cipher Template Configuration and Usage Guidelines

A cipher template contains a list of ciphers. A client or server who connects to a virtual port that uses
the cipher template can use only the ciphers that are listed in the template.
Optionally, you can assign a priority value to each cipher in the template. In this case, the ACOS device
tries to use the ciphers based on priority. If the client supports the cipher that has the highest priority,
that cipher is used. If the client does not support the highest-priority cipher, the ACOS device attempts
to use the cipher that has the second-highest priority, and so on.
Cipher priority can be 1-100. The highest priority (most favored) is 100. By default, each cipher has pri-
ority 1. More than one cipher can have the same priority. In this case, the strongest (most secure)
cipher is used.
Notes
• An SSL cipher template takes effect only when applied to a client-SSL template or server-SSL
template.
• When you apply (bind) a cipher template to a client-SSL or server-SSL template, the settings in
the cipher template override any cipher settings in that client-SSL or server-SSL template.
• Priority values are supported only for client-SSL templates. If a cipher template is used by a
server-SSL template, the priority values in the cipher template are ignored.
page 314
Support for TLS Server Name Indication

The ACOS device support for the Server Name Indication (SNI) extension for Transport Layer Security
(TLS). The SNI extension enables servers that manage content for multiple domains at the same IP
address to use a separate server certificate for each domain.
NOTE: One use for this feature is as part of an SSL Insight deployment.
To support the SNI extension, the ACOS device allows you to add multiple certificates to a single client-
SSL template, and map individual certificates to their domain names.
In the current release, you can configure up to 1024 certificate-to-domain mappings in a client-SSL
template.
Default Certificate and Key
The client-SSL template must contain one certificate and private key pair that is not mapped to a
domain. The unmapped certificate and key are the default certificate and key for the template. The
ACOS device uses the default template for negotiating the SSL session with the client.
If the client includes the SNI extension in its hello message, the ACOS device uses the certificate that is
mapped to the domain requested by the client. Otherwise, the ACOS device uses the default certificate.
Partition Support
This feature is supported in both the shared partition and L3V private partitions.
Using the GUI
Before creating the certificate-domain mappings, import the server certificates onto the ACOS device.
The configuration page for client-SSL templates has a Server Name Indication section. In this section,
to create a certificate-domain mapping:
1. Enter the domain name in the Server Name field.

2. Select the certificate from the Server Certificate drop-down list.
3. Select the certificate’s private key from the Server Private Key drop-down list.
4. Click Add.
5. Repeat for each mapping.
Using the CLI
To map a certificate to a domain, use the server-name command at the configuration level for the cli-
ent-SSL template:
page 315
TLS Server Name Indication Support on vThunder

ACOS provides support for the Server Name Indication (SNI) extension to vThunder models. The SNI is
an extension to Transport Layer Security (TLS) that allows a single IP address to host multiple domain
names, with a separate certificate for each domain.
The client-SSL template bound to the virtual port can contain multiple certificates. When you add a cer-
tificate and key to a client-SSL template, you can specify the domain name (“server name”) that the cer-
tificate and key belong to. When a client sends an SSL session setup request to the VIP, ACOS sends
the server certificate for the requested domain name, based on the configuration in the client-SSL tem-
plate.
In addition to certificates and keys for individual domain names, a client-SSL template also can contain
one “default” certificate and key. If the template does not have a certificate for the domain name
requested by the client, ACOS sends the default certificate instead.
Notes
• ACOS 2.7.2 adds SNI support to vThunder models. Previous releases support the feature on
hardware models but not on vThunder models.
• The ACOS configuration does not contain any SLB server certificates by default. The “default”
certificate and key in a client-SSL template must be imported or generated in ACOS, then added
to the template. If you add them to the template without associating them with a domain name,
then they become the default certificate and key for the template.
• SSL Intercept, a feature on certain hardware models that uses SNI support, is not supported on
vThunder devices. This enhancement does not provide SSL Intercept support on vThunder mod-
els.
CLI Example
The commands in this section configure an SSL VIP that serves the following domains:
• www.example.com
• www.example2.com
• mail.example.com
This configuration allows the ACOS device to set up secure SSL sessions with a client who sends
requests to 192.168.2.69:443. ACOS selects a server certificate to send to the client based on the
domain name requested by the client.
This example assumes that the certificates and keys have already been imported into or generated in
ACOS.
The slb template client-ssl cssl command configures the client-SSL template and places the CLI in
template configuration mode where the following commands are available:
page 316
Importing a Certificate and Key
• The cert and key commands add the default certificate and key.
• The server-name commands add the certificates and keys for specific domain names.
The “cert2” and “cert3” certificates are used for SSL session setup requests to domains
www.example2.com and mail.example.com, respectively.
The “def_cert” certificate is used for requests to any other domain name, such as www.exam-
ple.com.
These commands bind the client-SSL template to the SSL virtual port:
ACOS(config)# slb virtual-server example 192.168.2.69

ACOS(config-slb vserver)# port 443 ssli
ACOS(config-slb vserver-vport)# template client-ssl cssl

To import certificate and key files, place them on the PC that is running the ACOS GUI or CLI session, or
onto a PC or file server that ACOS can reach and fetch the files.
NOTE: To import a zip archive of multiple files, see “Bulk Import/Export of SSL
Certificate and Key Files” on page 319.
Importing Individual Files

To individually import an SSL certificate CA certificate, certificate chain, or private key follow these
instructions.
CA Certificate Verses SSL Certificate
Although both terms, CA certificate and SSL certificate, refer to a certificates used in the SSL protocol,
ACOS reserves the term SSL certificate for self-signed certificates that are used to create proxied certif-
icates for SSL handshaking with clients in the SSLi, SSL Proxy or SSL offload applications. SSL certifi-
cates require a private key to be proxied
CA certificates are issued by publicly recognized certificate authorities. These certificates are used for
other purposes.
page 317
Using the GUI

1. Navigate to ADC >> SSL Management >> SSL Certificates.
2. Click Import to import a certificate or certificate chain.
a. In the File Name field, enter a name for the certificate.
b. In the Import field, select the item you want to import
c. In the Import Certificate from field, select Local to import from a local drive on your man-
agement PC, Remote to import from a remote location, or Text to import from the text box that
appears
d. In the SSL or CA Certificate field, select either SSL Certificate or CA Certificate.
NOTE: If you are importing a CA-signed certificate for which you used ACOS to generate the
CSR, you do not need to import the key. The key is automatically generated by ACOS when you
generate the CSR.
e. In the Certificate Format field, select the file format of the certificate you are importing. Certif-
icate and private keys in a single file use the PFX format which is automatically chosen.
f. The Certificate Source field provides the location and other fields you need to import the
selected item.
g. Decide whether to enable or disable the Overwrite Existing File option.
3. Click Import.
Using the CLI

• Use the import cert command to import a certificate or certificate chain that you will be using
with its private key to create proxied certificates for SSL handshaking with clients in the SSLi, SSL
Proxy or SSL offload applications. If you import the cert and its key in a single file use the PFX for-
mat.
An example of importing a cert for SSLi is found in “Example of Importing a CA Cert and Private
Key for SSLi” on page 337.
• Use the import ca-cert command to import a certificate or a certificate chain for certificates for
verifying SSL servers and authenticating clients and other purposes. However the CA cert cannot
be used for creating proxied signed certificates for handshaking with clients.
NOTE: If you are importing a CA-signed certificate for which you used ACOS to generate the CSR,
you do not need to import the key. The key is automatically generated by ACOS when you generate
the CSR.
• Use the import cert-key command to import a private key.
page 318
Generating CAs and CSRs
Bulk Import/Export of SSL Certificate and Key Files

You can import or export SSL files in bulk, as .tgz archives.
Using the GUI
The steps for importing or exporting SSL files are the same for individual files and for bulk archives.
(For information, see “Importing Individual Files” on page 317, the GUI online help.)
Using the CLI
To import a .tgz archive of SSL certificate files, key files, or CRL files, use the following commands:
• import cert – The archive contains only certificate files.
• import cert-key bulk – The archive contains both certificate and key files.
• import crl – The archive contains only CRL files.
• import key – The archive contains only key files.
Generating an SSL Cert - Private Key File with a CSR

The following procedures generates an SSL self-signed cert with private key and also generates a CSR
that you can send to a publicly recognized CA to register you self-signed SSL cert.
This process also creates a public key - private key pair. The public key is sent in the CSR. The private
key is used to encrypt the CSR and also to create the SSL proxied certificate used in the ACOS SSLi,
SSL-Offload, and SSL-Proxy applications.
Using the GUI

2. Click +Create. The Create SSL Certificates dialog window appears.
a. In the Create As field, select Certificate.
b. In the File Name field, type the name you certificate that will be generated.
c. Click the CSR Generate box to enable the creation of a CSR.
d. In the Cert Type field, select RSA or ECDSA depending on which cryptography standard you
want.
page 319
e. The Common Name field is required.

NOTE: If you need to create a request for a wildcard certificate, use an asterisk as the first part
of the common name. For example, to request a wildcard certificate for domain example.com
and it sub-domains, enter the following common name: *.example.com
f. The Division, Organization, Locality, State or Province, and Email fields are optional.
g. Enter a number the Valid Days (how many days the key will remain valid) and Key Size, or
accept the defaults 730 days and 1024 bytes.
3. Click OK.
4. Verify the newly created SSL cert appears in the ADC >> SSL Management >> SSL Certifi-
cates page. Check the matching Name and Common Name fields. The Type should be certifi-
cate/key, and the expiration should match the number of days the cert remains valid. See RFC
6125 for help in reading the Issuer field. The GUI does not display the CSR separately
Using the CLI

1. Use the pki create cert command in the global configuration mode to generate an self-signed
SSL certificate and a corresponding CSR. In the following example, the CSR file name is csr, the
CSR renewal file name is Cert-CSR-both, the file transport protocol is FTP, and the URL specifying
where the CSR is sent is 192.168.1.10.
ACOS(config)# pki create cert Cert-CSR-both certtype rsa csr-generate

input key bits(1024,2048,4096) default 1024:
input Common Name, 1~64:Cert-CSR-both
input Division, 0~31:
input Organization, 0~63:
input Locality, 0~31:
input State or Province, 0~31:
input Country, 2 characters:US
input email address, 0~64:[email protected]
• In the above example, the CSR is generated without the root CA extensions. The syntax for the
command that creates a CSR with root CA extensions follows:
ACOS(config)# pki create cert Cert-CSR-both certtype rsa rootca
• 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
2. Use show pki csr Cert-CSR-both detail to show the cert created.
3. Use show pki certificate Cert-CSR-both detail to show the CSR created.
ACOS(config)# show pki cert Cert-CSR-both detail

Certificate:
page 320
Data:
Version: 3 (0x2)
Serial Number: 13866059162969540330 (0xc06e2357db5986ea)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=AF, CN=Cert-CSR-both
Validity
Not Before: Jan 31 05:20:36 2017 GMT
Not After : Jan 31 05:20:36 2019 GMT
Subject: C=AF, CN=Cert-CSR-both
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (1024 bit)
Modulus:
00:96:fc:1d:cc:63:ea:c1:a9:c7:1d:dd:c5:9c:72:
08:61:27:b7:67:1a:27:c7:f7:39:ca:9c:81:ac:f0:
f8:05:89:1a:66:25:cf:0b:1e:55:cc:cf:8b:89:91:
58:c5:e9:8c:b8:44:f1:d5:42:94:b1:e9:5a:a6:10:
05:28:0d:a2:84:a6:73:a8:64:66:e4:72:cc:c8:1b:
39:c9:4a:9c:a6:b3:67:e1:4a:d8:9d:a3:fa:bd:7c:
0e:ad:c1:35:6c:6f:54:68:0a:5f:54:67:61:fd:6a:
e2:55:2f:85:11:76:f3:96:c0:5c:55:11:63:a6:21:
41:65:6f:da:67:d5:e8:7e:ff
Exponent: 65537 (0x10001)
7d:ac:29:e8:a9:b5:2f:69:43:d2:a1:8b:7c:6d:8e:b5:21:f8:
30:cc:7a:4f:61:71:23:87:51:2c:da:ce:89:14:29:55:f3:81:
97:c0:2f:a7:e3:8a:4b:7d:d2:f7:cb:00:14:ce:91:db:1f:3a:
db:a0:a0:a9:90:b8:a1:b0:7a:16:e3:54:23:94:e2:48:fb:92:
36:0c:6d:c4:be:fd:79:77:41:6c:3a:19:3f:72:29:c6:95:f1:
c5:41:d8:a8:ed:18:2e:ca:66:1a:af:39:16:79:10:03:d6:f0:
95:10:93:1f:13:c8:96:70:c5:3f:97:8b:96:e1:d5:78:8d:b7:
c7:0c
SHA1 Fingerprint=D5:9A:B6:96:66:5D:B9:77:FE:1F:28:B4:BC:A9:3A:43:5D:2D:C7:98
MIIBxjCCAS+gAwIBAgIJAMBuI1fbWYbqMA0GCSqGSIb3DQEBBQUAMCUxCzAJBgNV
BAYTAkFGMRYwFAYDVQQDEw1DZXJ0LUNTUi1ib3RoMB4XDTE3MDEzMTA1MjAzNloX
DTE5MDEzMTA1MjAzNlowJTELMAkGA1UEBhMCQUYxFjAUBgNVBAMTDUNlcnQtQ1NS
LWJvdGgwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJb8Hcxj6sGpxx3dxZxy
CGEnt2caJ8f3Ocqcgazw+AWJGmYlzwseVczPi4mRWMXpjLhE8dVClLHpWqYQBSgN
ooSmc6hkZuRyzMgbOclKnKazZ+FK2J2j+r18Dq3BNWxvVGgKX1RnYf1q4lUvhRF2
85bAXFURY6YhQWVv2mfV6H7/AgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAfawp6Km1
L2lD0qGLfG2OtSH4MMx6T2FxI4dRLNrOiRQpVfOBl8Avp+OKS33S98sAFM6R2x86
26CgqZC4obB6FuNUI5TiSPuSNgxtxL79eXdBbDoZP3IpxpXxxUHYqO0YLspmGq85
FnkQA9bwlRCTHxPIlnDFP5eLluHVeI23xww=
page 321
key size: 1024

ACOS(config)# show pki csr Cert-CSR-both detail
Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=AF, CN=Cert-CSR-both
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (1024 bit)
Modulus:
00:96:fc:1d:cc:63:ea:c1:a9:c7:1d:dd:c5:9c:72:
08:61:27:b7:67:1a:27:c7:f7:39:ca:9c:81:ac:f0:
f8:05:89:1a:66:25:cf:0b:1e:55:cc:cf:8b:89:91:
58:c5:e9:8c:b8:44:f1:d5:42:94:b1:e9:5a:a6:10:
05:28:0d:a2:84:a6:73:a8:64:66:e4:72:cc:c8:1b:
39:c9:4a:9c:a6:b3:67:e1:4a:d8:9d:a3:fa:bd:7c:
0e:ad:c1:35:6c:6f:54:68:0a:5f:54:67:61:fd:6a:
e2:55:2f:85:11:76:f3:96:c0:5c:55:11:63:a6:21:
41:65:6f:da:67:d5:e8:7e:ff
Exponent: 65537 (0x10001)
Attributes:
a0:00
7f:2e:82:ef:b8:ed:5d:bc:78:4a:8c:25:5e:df:46:69:11:21:
74:7e:1e:fa:29:08:d0:ea:27:1a:25:fa:4b:ae:e2:78:08:2a:
63:ed:c9:0b:8d:0b:f6:d7:1e:07:10:dc:12:2b:ff:b0:0f:4a:
d6:68:a0:e1:ac:80:8b:d7:bb:f2:a3:6e:e2:74:c6:31:6c:44:
cc:45:c3:f8:2c:85:58:cb:a9:dc:28:bb:3b:72:0f:38:95:68:
1d:f4:09:9b:08:0f:f4:49:a5:9d:4d:91:d1:df:82:6c:63:60:
b8:74:d6:13:67:dd:81:c1:a6:af:ee:fa:22:7b:b2:a4:1e:e3:
b6:3d
-----BEGIN CERTIFICATE REQUEST-----
MIIBZDCBzgIBADAlMQswCQYDVQQGEwJBRjEWMBQGA1UEAxMNQ2VydC1DU1ItYm90
aDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAlvwdzGPqwanHHd3FnHIIYSe3
Zxonx/c5ypyBrPD4BYkaZiXPCx5VzM+LiZFYxemMuETx1UKUselaphAFKA2ihKZz
qGRm5HLMyBs5yUqcprNn4UrYnaP6vXwOrcE1bG9UaApfVGdh/WriVS+FEXbzlsBc
VRFjpiFBZW/aZ9Xofv8CAwEAAaAAMA0GCSqGSIb3DQEBBQUAA4GBAH8ugu+47V28
eEqMJV7fRmkRIXR+HvopCNDqJxol+kuu4ngIKmPtyQuNC/bXHgcQ3BIr/7APStZo
oOGsgIvXu/KjbuJ0xjFsRMxFw/gshVjLqdwouztyDziVaB30CZsID/RJpZ1NkdHf
gmxjYLh01hNn3YHBpq/u+iJ7sqQe47Y9
-----END CERTIFICATE REQUEST-----
page 322
Generating a CSR
The following procedures generates a CSR that you can send to a server, so that the server can send
the CSR to a CA to request a new CA-signed certificate or renew an existing one.
This process also creates a public key - private key pair. The public key is sent in the CSR. The private
key used to encrypt the CSR.
Using the GUI

a. In the Create As field, select CSR.
b. In the File Name field, type the name you certificate that will be provided by the CA.
c. In the Digest field, select the hashing algorithm used. The default is sha1.
want.
To create a wildcard certificate request, use an asterisk for the first part of the common name.
For example, to request a wildcard certificate for domain example.com and it sub-domains,
enter *.example.com as the common name.
3. Click OK.
cates page. Check the matching Name and Common Name fields. The Type should be key, and
the expiration should match the number of days the cert remains valid. See RFC 6125 for help in
reading the Issuer field.
Using the CLI

1. Use pki create csr command in global configuration mode to generate an RSA type of certificate
signing request (CSR). In this example, the CSR name is CSR1.
ACOS(config)# pki create csr CSR1 generate certtype rsa
input Common Name, 1~64:CSR1
page 323
input State or Province, 0~31:

input email address, 0~64:[email protected]
ACOS(config)#
To create wildcard certificates, use an asterisk as the first part of the common name. For exam-
ple, to create a wildcard certificate for domain example.com and it sub-domains, enter the fol-
lowing common name: *.example.com
2. Use show pki certificate csr1 detail to show the CSR created.
Generating a Self-Signed Certificate and Key

In the following procedure the certificate file also includes the corresponding private key.
See RFC 6125 for help in filling out some of the following fields.
Using the GUI

a. In the Create As field, select Certificate.
b. In the File Name field, type the name you certificate that will be generated.
c. Do not enable CSR Generate. This checkbox enable the creation of a CSR.
want.
NOTE: If you need to create a request for a wildcard certificate, use an asterisk as the first part
of the common name. For example, to request a wildcard certificate for domain example.com
and it sub-domains, enter the following common name: *.example.com
3. Click OK.
cates page. Check matching Name and Common Name fields. The Type should be certificate/
key, and the expiration should match the number of days the cert remains valid. See RFC 6125 for
help in reading the Issuer field.
page 324
Using the CLI
To generate a self-signed certificate, use the following command at the global configuration level of the
CLI:
The pki create certificate command generates and initializes a self-signed certificate and key.
When creating a self-signed certificate it must be pushed out to inside clients (clients on the internal
network). If the certificate is not pushed, the internal hosts get an SSL “untrusted root” error whenever
they try to connect.
The key length, common name, and number of days the certificate is valid are required. The other infor-
mation is optional. The default key length is 1024 bits. The default number of days the certificate is
valid is 730.
ACOS(config)# pki create certificate enterpriseABC-selfsignd certtype rsa

input Common Name, 1~64: enterpriseABC-selfsignd
input State or Province, 0~31:US
input email address, 0~64:
input valid days, 30~3650, default 730:
ACOS(config)#
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 com-
mon name: *.example.com
Certificate Installation Process

To configure an ACOS device to perform SSL processing on behalf of real servers, you must install a
certificate on the ACOS device. This certificate is the one that the ACOS 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 309).
This section gives an overview of the process for each type of certificate. Detailed procedures are pro-
vided later in this chapter.
page 325
Requesting and Installing a CA-Signed Certificate

To request and install a CA-signed certificate, use the following process. For detailed steps, see “Gener-
ating CAs and CSRs” on page 319 and “Importing a Certificate and Key” on page 317.
1. Create an encryption key.

2. Create a Certificate Signing Request (CSR).
The CSR includes the public portion of the key, as well as information you enter when creating the
CSR.
You can create the key and CSR on an ACOS device or a server running openssl or a similar appli-
cation.
3. Submit the CSR to the CA.
If the CSR was created on the ACOS device, do one of the following:
• Copy and paste the CSR from the ACOS 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 ACOS CLI or GUI.
Email the CSR to the CA, or copy-and-paste it onto the CSR submission page of the CA server.
If the CSR was created on another device, email the CSR to the CA, or copy-and-paste it onto the
CSR submission page of the CA server.
4. After receiving the signed certificate and the CA’s public key from the CA, import them onto the
ACOS 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 ACOS device. In this
case, the key is already on the ACOS 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 ACOS 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 ACOS device, you
need to import the key also.
See “Converting SSL Certificates to PEM Format” on page 333.
5. If applicable, import the certificate chain onto the ACOS device. The certificate chain must be a sin-
gle text file, beginning with a root CA’s certificate at the top, followed in order by each intermediate
signing authority’s certificate. (See “Certificate Chain” on page 307.)
Figure 43 shows the most common way to obtain and install a CA-signed certificate onto the ACOS
device. You also may need to install a certificate chain file.
page 326
FIGURE 43 Obtaining and Installing Signed Certificate from CA
NOTE: As an alternative to using a CA, you can use an application such as

openssl to create a certificate, then use that certificate as a CA-signed
certificate to sign another certificate. However, in this case, a client’s
browser is still likely to display a certificate warning to the end user.
Installing a Self-Signed Certificate

To install a self-signed certificate instead of a CA-signed certificate:
1. Create an encryption key.

2. Create the certificate.
See “Generating a Self-Signed Certificate and Key” on page 324.
page 327
Creating a Client-SSL or Server-SSL Template and Binding it to a VIP

After creating or importing certificates and keys on the ACOS 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 (GUI Procedure)

1. Navigate to ADC >> Templates >> SSL.
2. Click Create, and:
• Select Client SSL to create a template for SSL traffic between the ACOS device (VIP) and cli-
ents.
• Select Server SSL to create a template for SSL traffic between the ACOS device and servers.
3. Enter or select the configuration options; refer to the online help for information about the fields on
this GUI page.
4. When finished, click OK.
Creating an SSL Template (CLI Procedure)
Use one of the following commands at the global configuration level of the CLI:
• slb template client-ssl – creates template for SSL traffic between ACOS device (VIP) and cli-
ents.
ACOS(config)# slb template client-ssl TMPLT-C
• slb template server-ssl – creates template for SSL traffic between ACOS device and servers.
ACOS(config)# slb template server-ssl TMPLT-S
The command creates the template and changes the CLI to the configuration level for it. Use the com-
mands at the template configuration level to configure template parameters. (For information, see “SSL
Templates” on page 310 or the CLI Reference.)
Binding an SSL Template to a VIP (GUI Example)

1. Navigate to ADC >> SLB > Virtual Servers.
2. Click Create to create a new virtual server.
3. Enter the VIP name and IP address.
4. In the Port section, click Create. The Virtual Server Port page appears.
5. Click on “Templates” to expand the Templates section.
6. Select the template from the Client-SSL Template or Server-SSL Template drop-down list.
page 328
Binding an SSL Template to a VIP (CLI Example)
Use one of the following commands at the configuration level for the virtual port on the VIP:
• template client-ssl – binds client SSL template to the VIP.

ACOS(config)# slb virtual-server VIP-1 10.10.1.1
ACOS(config-slb vserver)# port 80 ssl-proxy
ACOS(config-slb vserver-vport)# template client-ssl TMPLT-C
• template server-ssl – binds server SSL template to the VIP.

ACOS(config-slb vserver-vport)# template server-ssl TMPLT-S
Use the same command on each port for which SSL will be used.
Multiple CA Certificate Support in Server-SSL Templates

If you need to add multiple certificates to a server-SSL template, this section describes how to config-
ure it. A server-SSL template can have multiple CA-signed certificates.
You can add the CA certificates to the server-SSL template in either of the following ways:
• As separate files (one for each certificate)
• As a single file containing multiple certificates
Adding multiple certificates in a single file can simplify configuration. For example, you can export the
CA certificates from a web browser into a single file, then import that file onto the ACOS device and add
it to a server-SSL template.
Previous releases allow a server-SSL template to have only a single CA-signed certificate.
NOTE: A CA-signed certificate is a certificate signed by a Certificate Authority

(CA).
Multiple Certificates in Single File – Preparing the File
You can create the multiple certificate file by exporting the certificates from a browser or you can
assemble the file by hand.
page 329
To export the certificates from Internet Explorer (IE) version 9:
1. Select Tools > Internet Options.

2. Click on the Content tab.
3. Click Certificates.
4. Click on the Trusted Root Certification Authorities tab.
5. Select all the certificates.
6. Click Export.
7. Click Next.
8. Select PKCS #12 format (PFX), if not already selected.
9. Click Next.
10.When prompted for a file password, enter a password to secure the certificate file, and click Next.
11.When prompted for a filename:
a. Click Browse to navigate to the save location for the file.
b. Enter the filename and click Save.
12.Click Next.
13.Click Finish.
14.On the ACOS device:
a. Import the certificate file as a PFX file.
b. Use the GUI or CLI to add the certificate file to a server-SSL certificate.
c. Bind the server-SSL certificate to the virtual port.
To create the file manually:
1. Copy and paste each certificate to a text file. Make sure to include the "-----BEGIN CERTIFICATE-----
" and "-----END CERTIFICATE----- " lines for each certificate. For example:
MIIE0zCCA7ugAwIBAgIQGNr
RniZ96LtKIVjNzGs7SjANBg
kqhkiG9w0BAQUFADCB
U2lnbiwgSW5jLiAtIEZvciBhd
XRob3JpemVkIHVzZSBvbmx
5MUUwQwYDVQQDEzxW
page 330
2. Save the text file.

3. On the ACOS device:
a. Import the certificate file as a PEM file.
b. Use the GUI or CLI to add the certificate file to a server-SSL certificate.
c. Bind the server-SSL certificate to the virtual port.
Support for Binding Server-SSL Templates to Individual Real Ports

For additional flexibility, the ACOS device supports binding of server-SSL templates to individual real
ports. This configuration option is useful in cases where the real servers load balanced by a VIP have
different SSL settings.
If a server-SSL template is be bound to the virtual port instead, all the real servers load balanced by the
VIP must use the same SSL settings.
Template Priority
You can bind a server-SSL template to a real port and also to a virtual port that uses that real port. In
this case, the server-SSL template bound to the real port is used for traffic sent to that real port. If you
remove the server-SSL template from the real port, the template bound to the virtual port is used
instead.
Using the GUI
On the configuration page for the real server, in the Port section, select the template from the Server-
SSL Template drop-down list.
Using the CLI
To bind a server-SSL template to a real port, use the template server-ssl command at the configura-
tion level for the real port:
CLI Example
The following commands import a CA-signed certificate and key:
ACOS(config)# import ca-cert CACert88.pem tftp:

File name [/]?CACert88.pem
.0 minutes 1 seconds
ACOS(config)# import key CAkey tftp:
File name [/]?CAkey88
.0 minutes 1 seconds
page 331
Configuring Email Notification for SSL Certificate Expiration
The following commands create a server-SSL template and add the certificate and key to the template:
ACOS(config)# slb template server-ssl server-ssl1

ACOS(config-server ssl)# ca-cert CACert88.pem
ACOS(config-server ssl)# key CAkey88
The following commands bind the server-SSL template directly to a port on a real server:

ACOS(config-real server-node port)# template server-ssl server-ssl1
Configuring Email Notification for SSL Certificate

Expiration
The ACOS device can send email notification when an SSL certificate is about to expire. This feature
sends a daily email listing the certificates that are about to expire or that have recently expired.
By default, this feature is not configured. To configure email notification for certificate expiration, use
either of the following methods.
Using the GUI

1. Navigate to ADC >> SSL Management >> Expiration Mail.
2. In the SSL Expire Email Address, enter the email address (twice; both address must match) where
you want the notifications to be sent.
3. Configure the other fields on this screen as desired; refer to the GUI online help for more informa-
tion about the fields on this page.
4. Click Update.
Using the CLI
To configure email notification for certificate expiration, use the slb ssl-expire-check command.
The following example enables certificate notifications to be sent to email address “admin1@exam-
ple.com”. Expiration notifications are sent beginning 4 days before expiration and continue for 3 days
after expiration.
ACOS(config)# slb ssl-expire-check email-address [email protected] before 4 interval 3
page 332
SSL Certificate Notification via System Log Warnings
SSL Certificate Notification via System Log Warnings

When an SSL certificate expires or is near expiration, the ACOS device will automatically send a system
log warning, rather than a system log notice.
NOTE: For information on enabling SNMP traps for SSL certificate events, refer
to the System Configuration and Administration Guide.
Converting Certificates and CRLs to PEM Format

The ACOS device supports Privacy Enhanced Mail (PEM) format for certificate files and CRLs.
If a certificate or CRL you plan to import onto the ACOS device is not in PEM format, it must be con-
verted to PEM format.
NOTE: 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 ACOS device automatically converts the imported certificate into
PEM format. (See “Importing a Certificate and Key” on page 317.)
If you prefer to convert a certificate before importing it, see the following sections.
Converting SSL Certificates to PEM Format

If you have certificates that are in Windows format, use the procedure in this section to convert them to
PEM format. For example, you can use this procedure to export SSL certificates that were created
under a Windows IIS environment, for use on servers that are running Apache.
This procedure requires a Windows PC and a Unix/Linux workstation. 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.
page 333
Converting Certificates and CRLs to PEM Format
d. Click Add.
A dialog appears with the following choices: My user account, Service account, and Computer
account.
e. Select Computer Account and click Next. The Select Computer dialog appears.
f. Select Local Computer and click Finish.
g. Click Close.
h. Click OK. The Certificates snap-in appears in the Console Root list.
3. Expand the Certificate folders and navigate to the certificate you want to convert.
4. Select Action > All Tasks > Export.
The Export wizard guides you with instructions. Make sure to export the private key too. The wiz-
ard will ask you to enter a passphrase to use to encrypt the key.
Steps to perform on the Unix/Linux workstation:
5. Copy the PFX-format file that was created by the Export wizard to a UNIX machine.
6. Use OpenSSL to convert the PFX file into a PKCS12 format:
$ openssl pkcs12 -in filename.pfx -out pfxoutput.txt
This command creates a PKCS12 output file, which contains a concatenation of the private key
and the certificate.
7. Use the vi editor to divide the PKCS12 file into two files, one for the certificate (.crt) and the other
for the private key.
8. To remove the passphrase from the key, use the following command:
$ openssl rsa -in encrypted.key -out unencrypted.key
NOTE: Although removing the passphrase is optional, A10 Networks recom-

mends that you remove the passphrase for production environments
where Apache must start unattended.
Converting CRLs from DER to PEM Format

If you plan to use a Certificate Revocation List (CRL), the CRL must be in PEM format.
To convert Distinguished Encoding Rules (DER) format to PEM format, use the following command on
a Unix/Linux machine where the file is located:
openssl crl -in filename.der –inform der -outform pem -out filename.pem
page 334
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. Navigate to ADC >> SSL Management >> Cert Revocation List.
2. Click Import.
3. Complete the fields on this page to navigate to the location of the CRL.
4. Click Import.
Using the CLI
To import a CRL, use the import crl command at the Privileged EXEC or global Config level of the CLI:
Refer to the Command Line Interface Reference for detailed information about this command.
SSL File Delete

To delete SSL files, use either of the following methods.
Using the GUI

1. Navigate to one of the following:
• ADC >> SSL Management > SSL Certificates
• ADC >> SSL Management > Cert Revocation List
2. Select the files to delete.
3. Click Delete.
Using the CLI
Using the CLI, you can delete specific SSL files by name.
Use the pki delete command at the global configuration level of the CLI to delete SSL files.
page 335
Exporting Certificates, Keys, and CRLs
Exporting Certificates, Keys, and CRLs

This section describes how to export SSL resources from the ACOS device to other devices.
NOTE: Due to a limitation in Windows, it is recommended to use names shorter

than 255 characters. Windows allows a maximum of 256 characters for
both the file name and the directory path. If the combination of directory
path and file name is too long, Windows will not recognize the file. This
limitation is not present on machines running Linux/Unix.
Exporting a Certificate and Key
Using the GUI

2. To export a certificate:
a. Select the certificate. (Click the checkbox next to the certificate name.)
b. Click Export.
NOTE: If the browser security settings normally block downloads, you may need
to override the setting. For example, in Internet Explorer, hold the Ctrl key
while clicking Export.
c. Click Save.
d. Navigate to the save location.
e. Click Save again.
3. 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:
page 336
Example of Importing a CA Cert and Private Key for SSLi
• export cert
• export cert-key
Refer to the Command Line Interface Reference for detailed information about these commands.
Exporting a CRL
Using the CLI
To export a CRL, use the export crl command at the Privileged EXEC or global Config level of the CLI:
Using the GUI

1. Navigate to ADC >> SSL Management >> Cert Revocation List.
2. Select the CRL. (Click the checkbox next to the CRL name.)
3. Click Export.
NOTE: If the browser security settings normally block downloads, you may need
to override the setting. For example, in IE, hold the Ctrl key while clicking
Export.
4. Click Save.
5. Navigate to the save location.
6. Click Save again.
Example of Importing a CA Cert and Private Key for SSLi

The following commands import a self-signed CA certificate trusted by the clients, and the certificate’s
private key:
ACOS-Inside(config)# import cert enterpiseABC-selfsignd scp:

User name []?admin
Password []?*********
File name [/]?enterpiseABC-selfsignd.pem
ACOS-Inside(config)# import key enterpiseABC-key scp:
User name []?admin
Password []?*********
File name [/]?enterpiseABC-key.pem
page 337
Forward Proxy Alternate Signing Cert and Key
The following commands configure the client-SSL template to enable SSLi (forward-proxy). It also
specifies the certificate and private key that the inside ACOS device uses to dynamically create (and
cache) forged server certificates as clients request SSL sessions with external servers.
ACOS-Inside(config)# slb template client-ssl SSLInsight_ClientSide

ACOS-Inside(config-client ssl)# forward-proxy-ca-cert enterpiseABC-selfsignd
ACOS-Inside(config-client ssl)# forward-proxy-ca-key enterpiseABC-key
ACOS-Inside(config-client ssl)# forward-proxy-enable
Forward Proxy Alternate Signing Cert and Key

In the following example, the inside ACOS device is configured with a trusted CA list and an alternate
signing key.
When a client requests connection to an external SSL server, the inside ACOS device determines
whether the certificate of SSL site is signed by a trusted CA. If it is not in the trusted list, the inside
ACOS device signs the certificate with the alternate signing key. Because the alternate signing key is
not trusted, the client will be warned that the site is insecure.
Example Configuration of Forward Proxy Alternate Signing Cert and

Key
1. Import the list of trusted list of CAs:
ACOS-Inside(config)# import cert ca-cert enterpiseABC-trusted-CAs scp:
...
2. Import the list of alternate certificate and signing key:

ACOS-Inside(config)# import cert alt-cert scp:
...
ACOS-Inside(config)# import key alt-key scp:
...
3. Bind the list of trusted CAs and the alternate signing key to the Client SSL template (which in turn
is bound to the SSLi virtual port of the inside ACOS device.)
ACOS-Inside(config)# slb template client-ssl SSLInsight_ClientSide
ACOS-Inside(config-client ssl)# forward-proxy-ca-cert enterpiseABC-selfsignd
ACOS-Inside(config-client ssl)# forward-proxy-ca-key enterpiseABC-key
ACOS-Inside(config-client ssl)# forward-proxy-enable
ACOS-Inside(config-client ssl)# forward-proxy-trusted-ca-list enterpiseABC-trusted-CAs
ACOS-Inside(config-client ssl)# forward-proxy-alt-sign cert alt-cert key alt-key
page 338
Simple Control Enrollment Protocol (SCEP)

Simple Control Enrollment Protocol is a part of the Public key infrastructure (PKI); it simplifies manage-
ment of security certificates by providing simplified installation and automated renewal of x.509 certifi-
cates. You can use SCEP certificates with the same ACOS features that support manually imported
certificates. For example, SCEP certificates are supported with SSL Insight (SSLi).
NOTE: This feature is not supported for HSM platforms, including Thunder
5630.
To configure a SCEP certificate, you need to specify the certificate name, a password, and the location
(URL) of the ES. ACOS handles the rest. Then, to use the certificate, add it to an SSL template and bind
the template to the virtual port in your application. There is no GUI support for configuring this feature.
SCEP Certificate Enrollment and Renewal Process

After you configure a SCEP certificate for enrollment, ACOS performs the following steps:
1. Generate a private key. In this step, an RSA key with the specified key length is generated for the
certificate.
2. Fetch CA certificates. ACOS queries the ES for its certificates. In this step, three certificates are
returned: 1 CA certificate and 2 ES certificates, and ES-encryption certificate and an ES-signature
certificate.
3. Generate Certificate Signing Request (CSR). The CSR includes the SCEP password you assign to
the SCEP certificate, and other parameters needed for the certificate.
4. Fetch the certificate. The CSR is encrypted using the public key of the ES-encryption certificate,
and forwarded to the ES.
The ES validates the CSR and forwards the request to the CA. The CA then returns the signed cer-
tificate. The certificate is signed using the ES-signature certificate.
5. Store the certificate. After successful verification of the response from the CA, ACOS accepts the
certificate and stores it in the following locations:
/a10data/cert/
/a10data/key/
SCEP certificates are stored in DER format. SCEP keys are stored in PEM format.
6. Schedule renewal. ACOS handles automatic renewal of the certificate when its about to expire.
ACOS checks the expiration dates of both the enrolled certificate and the issuing CA’s certificate.
ACOS then schedules renewal of the certificate, to occur at a specific time or periodically, depend-
ing on configuration. ACOS bases the new expiration date on the later of the expiration dates of the
enrolled certificate and the CA certificate.
page 339
7. Rotate and store files. After certificate renewal, the old certificate and key files are still stored for
any future reference. Old files are rotated and the new file replace the existing files. For example, a
certificate named “acos-cert” initially is stored in the following location: /a10data/cert/acos-cert.
After the certificate is renewed, it is moved to the following location: /a10data/cert/acos-cert#1.
The newly renewed certificate is moved to /a10data/cert/acos-cert. This step ensures that there is
no need to change the configuration for applications that use the SCEP certificates, because a
valid certificate with the correct name is always stored in the same location. The same applies for
private keys as well. ACOS stores up to 4 old certificate and key files for each SCEP certificate.
Configuration Using the CLI

To configure SCEP using the CLI:
1. Use the pki scep-cert command to create the certificate and change the CLI to edit it.
2. Use the url command to specify the location of the ES. The user is the admin name required by the
ES to accept the request.
Use this command to specify the location of the ES. The user is the admin name required by the ES
to accept the request. The host is the ES IP address or hostname. The file is the path and filename
for the SCEP process on the ES. Example:
url http://192.168.230.101/certsrv/mscep/mscep.dll
3. Specify the password for the certificate. ACOS includes this password in enrollment and renewal
requests for the certificate.
4. (Optional) Configure additional parameters.
SCEP certificates have the following default settings:
• Interval – 5 seconds
• Log level – 1
• Maximum poll time – 180 seconds
• Method – GET
The other parameters are not set by default.
5. Use the enroll command to begin the enrollment process for the certificate.
Copying SCEP Files

You can copy SCEP certificates and keys using the pki copy-cert and pki copy-key commands.
Refer to the Command Line Interface Reference for details.
page 340
Displaying SCEP Information

To display SCEP information, use the show pki scep-cert command.
Refer to the Command Line Interface Reference for details.
Configuration Example
The following commands configure an ACOS device as the inside device in an SSLi deployment. The
wildcard VIP on this device receives SSL-encrypted traffic from inside users, and decrypts the traffic
before sending it to the traffic inspector.
The deployment uses a certificate administered by an SCEP ES. Based on the configuration, ACOS
automatically renews the certificate on a monthly basis.
NOTE: For brevity, this example shows only the inside device, where the SCEP
configuration occurs, and uses only one certificate. The certificate is
used both as the root certificate and as a forward-proxy certificate,
which uses SNI support.
On the outside device, the only required command related to SSLi is forward-proxy-enable, to enable
support for the SSLi feature on the device.
The following command enrolls the certificate. You need to enroll each certificate only once. After a
certificate is enrolled, ACOS uses SCEP to administer the certificate. This includes renewing the certifi-
cate before it expires. You do not need to manually administer the certificates after you enroll them.
ACOS(config)# pki scep-cert mycert

ACOS(config-scep cert:mycert)# url http://192.168.230.101/certsrv/mscep/mscep.dll
ACOS(config-scep cert:mycert)# password sample_password
ACOS(config-scep cert:mycert)# renew-every month 1
The following commands configure the client-SSL template:
ACOS(config)# slb template client-ssl ssl_int

ACOS(config-client ssl)# cert mycert
ACOS(config-client ssl)# key mycert
ACOS(config-client ssl)# forward-proxy-enable
ACOS(config-client ssl)# forward-proxy-ca-cert mycert
ACOS(config-client ssl)# forward-proxy-ca-key mycert
The following shows the configuration the wildcard VIP. This includes configuration of the other
resources, in addition to the client-SSL template, that are required by the wildcard VIP: an ACL that
matches on the inside clients, the real server configuration, and the service group.
access-list 101 permit ip any 10.2.2.0 0.0.0.255 log
page 341
!
slb server rs1 10.3.3.1
health-check-disable
port 443 tcp
health-check-disable
!
slb service-group sg1-tcp tcp
member rs1:443
!
slb virtual-server vs1-v4 0.0.0.0 acl 101
extended-stats
port 8080 http
service-group sg1-tcp
template client-ssl ssl_int
no-dest-nat port-translation
!
The following commands show information about the certificate:
ACOS(config)# show pki cert

Name: mycert Type: certificate/key Expiration: Dec 8 22:23:48 2014 GMT [Expired, Bound]
SCEP Enrolled
ACOS(config)# show pki cert mycert

Certificate:
Data:
Version: 3 (0x2)
Serial Number:
1d:5b:42:30:00:00:00:00:24:8f
Issuer: DC=com, DC=a10lab, CN=AD03-CA
Validity
Not Before: Dec 8 18:23:48 2014 GMT
Not After : Dec 8 22:23:48 2014 GMT
Subject: C=CH, O=Linux strongSwan, CN=AX1030
X509v3 extensions:
X509v3 Subject Key Identifier:
DA:53:59:9C:EC:52:E3:58:6C:E5:84:11:E7:5C:F4:C9:FC:59:6B:A3
X509v3 Authority Key Identifier:
keyid:06:18:97:1C:58:B4:E4:95:5F:61:61:5D:DB:9C:1B:85:39:48:87:37
X509v3 CRL Distribution Points:

URI:ldap:///CN=AD03-
CA,CN=AD03,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=a10lab,DC=com
?certificateRevocationList?base?objectClass=cRLDistributionPoint
page 342
Authority Information Access:

CA Issuers - URI:ldap:///CN=AD03-
CA,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=a10lab,DC=com?cACerti
ficate?base?objectClass=certificationAuthority
OCSP - URI:http://ad03.a10lab.com/ocsp
X509v3 Key Usage: critical

Digital Signature, Key Encipherment
1.3.6.1.4.1.311.21.7:
0-.%+.....7.....E......+.......Ks...M......d...
X509v3 Extended Key Usage:
1.3.6.1.5.5.8.2.2
1.3.6.1.4.1.311.21.10:
0.0
page 343
page 344
SSL Offload and SSL Proxy
This chapter describes how to configure optimization of Secure Sockets Layer (SSL) and covers these
topics.
• Overview of SSL Offload and SSL Proxy
• Configuration Instructions for the Client SSL Template
• Configuration Instructions for SSL Offload
• Configuration Instructions for SSL Proxy
• SSL Ciphers
• Overview of SSL Cipher Support

• Configuration Instructions for the SSL Ciphers
• Examples of SSL Cipher Configurations
• Related Information
Overview of SSL Offload and SSL Proxy

SSL Offload
In SSL offload, HTTPS load balancing (Layer 7 SLB) can be combined with optional HTTP packet inspec-
tion and header manipulation.
SSL offload configures the HTTPS virtual port type to enable the SSL handshake and optionally config-
ures the HTTP template to enable packet inspection and header manipulation.
FIGURE 44 SSL Offload (Load Balancing HTTPS Traffic)
page 345
Configuration Instructions for the Client SSL Template
SSL Proxy
In SSL proxy, the ACOS device acts as a Layer 4 SSL proxy for TCP services such as POPS, SMTPS,
IMAPS, and LDAPS. It combines TCP load balancing (Layer 4 SLB) with these proxy services.
What SSL Proxy Have in Common
Both types of SSL optimization perform SSL handshakes, as well as encryption / decryption. SSL certif-
icates and keys are required. You can import the certificates and keys or create them on the ACOS
device. Additionally, ACOS also provides support for ECDHE/DHE ciphers, including ECDHE-RSA
ciphers, DHE-RSA ciphers, ECDHE-ECDSA ciphers, and GCM & SHA384. This feature also allows for the
configuration of EC and DH parameters, EC Curve selection, the importing/verification of EC Keys for
ECDSA ciphers, and support for TLS1.0/TLS1.1.
Configuration Instructions for the Client SSL Template

NOTE: The procedures importing or creating certificates is the same whether
they are used in an SSL proxy deployment or an SSL offload deployment.
Similarly, the procedure for configuring a client SSL template is the same
for SSL proxy and SSL offload.
Using the CLI

1. Import or create a certificate and its key to use for TLS sessions with clients. The configuration
example in this chapter uses an imported SSL certificate and private key.
ACOS# import cert sslcert1.crt ftp:
User name []?Admin-15
Password []?*********
File name [/]?sslcert1.crt
ACOS# import key sslcertkey.pem ftp:
User name []?Admin-15
Password []?*********
File name [/]?sslcertkey.pem
2. Configure a client SSL template and bind the SSL certificate and private key to it.
ACOS uses SSL certificates with a private key to create proxied signed certificates for handshaking
with SSL clients. SSL clients are configured to use a private CA that verifies the proxied certificate’s
validity.
ACOS(config)# slb template client-ssl sslcert-tmplt
ACOS(config-client ssl)# cert sslcert.crt
ACOS(config-client ssl)# key sslcertkey.pem
page 346
Configuration Instructions for SSL Offload
Using the GUI

a. To import the SSL certificate:
• Select ADC>>SSL Management>> SSL Certificates>> Import
• Enter the file name, the category of the import (Certificate), the location of the import (Local,
Remote, or Text; if Remote or Text is selected the appropriate fields will pop up to indicate IP
or text content), certificate format, and the certificate source for file search.
• Click Import.
b. To import the SSL key:
• Select ADC>>SSL Management>> SSL Certificates>> Import
• Enter the file name, the category of the import (Key), the location of the import (Local,
Remote, or Text), and the key source for file search.
• Click Import.
c. To create the client SSL template using the imported certificate and key:
• Select ADC>> Templates>> SSL.
• Select Create to pull the drop-down menu, and click Client SSL.
• In the Name field, specify a name for the Client SSL template.
• In the Server Certificate field, select an imported or configured SSL certificate, and in the
Server Private Key field, select an imported or configured key. ACOS uses the SSL certifi-
cates with the private key to create proxied signed certificates for handshaking with SSL cli-
ents. The SSL clients are configured to use a private CA that verifies the proxied certificate’s
validity.
• Click OK to finish.

Using the CLI
1. Configure the client SSL template using the procedure described in “Configuration Instructions for
the Client SSL Template” on page 346.
2. Configure the real servers for the TCP service:
ACOS(config)# slb server HTTPS1 10.5.5.2
ACOS(config)# slb server HTTPS2 10.5.5.3
page 347
3. The following configures a service group for the HTTPS servers:

ACOS(config)# slb service-group HTTPS_servers tcp
ACOS(config-slb svc group)# member HTTPS1 80
ACOS(config-slb svc group)# member HTTPS2 80
4. 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.
The SSL offload feature is enabled by the https option of the port command.
ACOS(config-slb vserver-vport)# service-group HTTPS_servers
ACOS(config-slb vserver-vport)# template client-ssl sslcert-tmplt
5. In this example, traffic between the servers and ACOS is not encrypted.
If traffic between the servers and ACOS also is 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.
If you configure server-SSL without client-SSL, the service type of the virtual port must be HTTP,
not HTTPS.
6. For configuring HTTP packet and inspection, see the “HTTP Options for SLB” chapter of the Appli-
cation Delivery and Server Load Balancing Guide.
Using the GUI

a. Select ADC >> SLB.
c. Click Create.
f. Enter the IP Address or FQDN hostname.
page 348
g. In the Port section, click the Create button.

h. In the Port Number field, enter the port number.
i. Click the Protocol drop-down list, and select TCP, if not already selected.
j. If your configuration will use a health check, select the Default radio button to use the default
health check, or select the Monitor radio button and select the desired health monitor from the
menu.
l. Click Update. The server appears in the real server table.
m. Repeat for each real server.
3. The following configures a service group for the HTTPS servers:
a. Select the Service Groups tab from the menu bar.
b. Click Create. The Create Service Group page appears.
d. In the Protocol drop-down list, select TCP, if not already selected.
e. In the Member section, click Create, and then click the Server drop-down list and select a
server.
f. In the Port field, enter the service port number.
g. Click Create. The member server appears in the list.
h. Repeat step e through step g for each server that will be added to the service group.
i. Click Create. The new service group appears in the service group table.
4. 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 Template HTTP (if configured) and Template Client-SSL.
c. Click Create.
d. In the Name field, enter a name for the virtual server.
e. Select the Address Type radio button (IPv4 or IPv6), and then enter the VIP address. This is the
IP address to which client requests will be sent.
f. In the Virtual Port section, click Create.
g. From the page that appears, click the Protocol drop-down menu and select HTTPS.
The SSL offload feature is enabled by the HTTPS option.
page 349
Configuration Instructions for SSL Proxy
h. In the Port field, enter the service port number.

i. Click the Service Group drop-down menu and select the service group.
j. Click Templates to expand the template configuration options.
k. Click the Template HTTP drop-down list, select the template you configured earlier.
l. Click the Template Client-SSL drop-down list, select the desired template.
m. Click Create. The port appears in the Port list for the virtual server.
n. Click Update. The virtual server appears in the virtual server table.
5. In this example, traffic between the servers and ACOS is not encrypted.
If traffic between the servers and ACOS also is 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.
If you configure server-SSL without client-SSL, the service type of the virtual port must be HTTP,
not HTTPS.
6. For configuring HTTP packet and inspection, see the “HTTP Options for SLB” chapter of the Appli-
cation Delivery and Server Load Balancing Guide.)

Using the CLI
The following commands configure proxy SSL for POPS. The same commands can be used to
configure SSL proxy for other TCP services. In each case, the feature is enabled by the ssl-proxy
option of the port command at the virtual server configuration level of the CLI.
ACOS(config)# slb server POP1 10.5.5.2
ACOS(config)# slb server POP2 10.5.5.3
page 350
3. The following commands configure a service group for the POP servers:
ACOS(config)# slb service-group POP_servers tcp
ACOS(config-slb svc group)# member POP1 110
ACOS(config-slb svc group)# member POP2 110
4. These commands configure a virtual server (VIP) which proxies for the service POP server (port
110):
5. The following commands configure the VIP to which clients will send POPS traffic (that is, port
110):
ACOS(config-slb vserver-vport)# service-group POP_servers
NOTE: Consider using the use-client-sni command in configurations where

the SSL server hosts multiple services.
Using the GUI
c. Click Create.
h. In the Port Number field, enter the port number.
j. If your configuration will use a health check, select the Default radio button to use the default
health check, or select the Monitor radio button and select the desired health monitor from the
menu.
page 351

m. Repeat for each real server.
3. The following steps configure a service group for the service corresponding the Port Number:
d. Click the Protocol drop-down list and select TCP, if not already selected.
e. Select the Health Monitor from the drop-down, if your configuration will use one.
f. In the Member section, click Create, and then click the Server drop-down list and select a
server.
g. In the Port field, enter the service port number for this server.
h. Click Create. The server appears in the list.
i. Repeat for each server.
j. Click Update. The service group appears in the service group table.
4. The following steps configure a virtual server (VIP) which proxies for the service corresponding the
Port Number:
c. Click Create.
IP address where client requests will be sent.
f. In the Virtual Port section, click Create. The Create Virtual Port page appears.
g. Click the Protocol drop-down menu and select SSL-Proxy.
h. In the Port field, enter the service port number.
k. Click the Template Client-SSL drop-down list, and select the desired template.
l. Click Create. The SSL proxy port appears in the port list for the virtual server.
m. Click Update. The virtual server appears in the virtual server table.
page 352
SSL Ciphers
SSL Ciphers
Overview of SSL Cipher Support

Both types of SSL optimization perform SSL handshakes, as well as encryption / decryption. SSL certif-
icates and keys are required. You can import the certificates and keys or create them on the ACOS
device. Additionally, ACOS also provides support for ECDHE/DHE ciphers, including ECDHE-RSA
ciphers, DHE-RSA ciphers, ECDHE-ECDSA ciphers, and GCM & SHA384. This feature also allows for the
configuration of EC and DH parameters, EC Curve selection, the importing/verification of EC Keys for
ECDSA ciphers, and support for TLS1.0/TLS1.1.
When configuring the client or server SSL template, users will also have the option to configure ECDHE/
DHE ciphers for enhanced encryption and SSL processing. In releases prior to 4.1.0, ECDHE/DHE
ciphers are only supported in hardware platforms having a second generation SSL card or third genera-
tion SSL card. Beginning in 4.1.0, software-based SSL processing also supports ECDHE/DHE ciphers
for all vThunder platforms.
Additionally, ACOS features enhanced selection of cipher support based on priorities assigned to
ECDHE and DHE cipher templates configured on the ACOS device:
• When processing an SSL handshake, if the user has configured a template for both ECDHE and
DHE with the same priority levels, the priority is given to ECDHE over DHE to optimize CPU usage
on the ACOS device. DHE ciphers will be considered as the lowest priority if there are other sup-
ported ciphers in the client-hello message. But if the user configured the highest priority for a
DHE cipher, the ACOS device will honor that.
• If the customer has a cipher template where no priority is specified, the ACOS device will give
ECDHE a higher priority by default. However, it is strongly recommended the customer does not
leave the priority unspecified.
• PFS ciphers on FIPS platform will not be supported. Currently PFS ciphers for server-side SSL are
only supported in software.
Configuration Instructions for the SSL Ciphers

Using the CLI
ECDHE/DHE ciphers can be supported in TLS1.0/TLS1.1. GCM related ciphers are only supported in
TLS1.2 For a list of supported ciphers, refer to theA10 SSL Cipher Suites List file located on the A10
Networks Support Portal: https://www.a10networks.com/support/axseries/appnotes
1. To use GCM related ciphers in Server SSL templates, you will need to specify TLS version 1.2:
ACOS(config)# slb template server-ssl SERVER-1
ACOS(config-server ssl)# version ?
<30-33> TLS/SSL version: 30-SSLv3.0, 31-TLSv1.0, 32-TLSv1.1 and 33-TLSv1.2
page 353
SSL Ciphers
2. You can now specify the Elliptic Curve Name in Client SSL templates:
ACOS(config)# slb template client-ssl CLIENT-1
ACOS(config-client ssl)# ec-name ?
secp256r1 X9_62_prime256v1
secp384r1 secp384r1
If no EC name is specified, ACOS will pick the first one that can be supported in ACOS from the cli-
ent EC list. If an EC name(s) is specified, ACOS will pick the first one that can be supported by the
client.
3. You can now specify DH parameters in Client SSL templates:
ACOS(config-client ssl)# dh-param ?
1024
1024-dsa
2048
512
The command shown above allows you to specify the DH key length. By default, the length is
1024. ACOS does not have configurable DH parameters in Server SSL templates as the client will
use the real server’s DH parameters.
4. You can now specify the EC name in Server SSL templates. The command is the same as when
you specify the EC name in Client SSL templates:
ACOS(config-server ssl)# ec-name ?
secp256r1 X9_62_prime256v1
secp384r1 secp384r1
By default, if no EC name is specified, ACOS will send all supported EC names to the server. If an
EC name(s) is selected, ACOS will send the specified EC name(s) to the server.
Examples of SSL Cipher Configurations

The following examples show recommended client or server SSL templates that can be configured to
avoid potential issues in hardware support for cipher usage.
For PX Card
Below is an example for ACOS devices with a PX card:
slb template client-ssl clientssl

cert cert
key key
cipher SSL3_RSA_DES_192_CBC3_SHA
page 354
Related Information
For Second Generation or Third Generation SSL Cards
Below is an example for ACOS devices with a second generation or third generation SSL card:
slb template client-ssl clientssl

cert cert
key key
ec-name secp384r1
cipher TLS1_ECDHE_RSA_AES_128_SHA256
For a server-SSL template, do not include the cipher if end-to-end SSL offload is deployed. For devices
with a second generation SSL card, third generation SSL card, or PX card, the default template can be
used.
slb template server-ssl serverssl
Related Information
For detailed information on the load-balancing servers that enable SSLi and other applications, see the
Application Delivery and Server Load Balancing Guide.
For more information about certificate options, see “SSL Certificate Management and Options” on
page 305.
For information on configuring HTTP template options, see the “HTTP Options for SLB” chapter of the
Application Delivery and Server Load Balancing Guide.)
ACOS supports STARTTLS acceleration and encryption. See the “STARTTLS for Secure SMTP” chapter
of the Application Delivery and Server Load Balancing Guide.
ACOS SSL Insight (SSLi) provides SSL security services through its transparent forward proxy traffic
inspection application. See the SSL Insight Configuration Guide for detailed information.
page 355
Related Information
page 356
Secure FTP Proxy
ACOS provides a virtual port type, FTP-proxy. You can use an FTP-proxy virtual port to load balance
secure SSL/TLS traffic or clear-text FTP traffic for clients.
While previous releases supported SSL offload for HTTPS traffic, this release supports similar function-
ality for encrypted FTPS traffic. Explicit FTPS traffic is an extension to the FTP protocol which allows
the FTP client to request that the session be encrypted with SSL/TLS.
Since the connection between client and ACOS device is secure, the ACOS device provides SSL proxy
services for the FTP traffic during negotiation of the secured session and acts as a proxy for backend
FTP servers.
By encrypting / decrypting traffic to and from the FTP servers, the ACOS device handles this CPU-inten-
sive task, thus sparing the FTP servers and enabling them to respond more quickly to client requests.
FIGURE 45 Secure FTP Proxy
Traffic Walkthrough
1. A client sends an encrypted Explicit FTPS request to the ACOS VIP.

2. The ACOS VIP acts as a proxy for the backend FTP real server, and performs SSL offload by remov-
ing the TLS encryption.
3. The client’s unencrypted FTP request is load balanced among the FTP servers using a standard
load balancing algorithm.
page 357
4. The FTP server receives the file request and responds by sending the requested file back to the
ACOS device “in the clear”. The ACOS device re-encrypts the FTP traffic from the server, creating
FTPS traffic, and sends the encrypted FTPS file to the client.
Details:
• In the current release, Secure FTP is only supported for Explicit FTPS transactions.
• In passive FTP mode, the server specifies which server-side port the client should connect to and
the client initiates the connection. This is in contrast to active FTP mode, where the client speci-
fies which port it has opened up for the data channel, and the server initiates the connection.
• After receiving the AUTH TLS command from the FTP client, ACOS expects to receive an SSL
handshake for the control channel, and expects the rest of the traffic from client to be encrypted.
• ACOS supports the FTP clear command channel (CCC) command. Meaning that after ACOS
receives the CCC command from the FTP client, the encryption is removed and packets are sent
as clear text.
• The data channel may or may not be encrypted, depending on which PROT command is sent
from the FTP client. The PROT P command indicates that the data is encrypted, whereas PROT C
indicates the data is not encrypted.
• For more information about SSL offload, refer to “SSL Offload and SSL Proxy” on page 345.
Example of explicit passive FTP proxy session
Figure 46 shows a sample of an explicit passive FTP proxy session.
The diagram shows traffic flowing back and forth between a client and an FTP server with an ACOS
device in the middle acting as a proxy.
• A standard 3-way TCP handshake occurs on both sides of the ACOS device, and this traffic is
unencrypted, which is represented in the diagram with blue lines.
• Next, an SSL handshake occurs between the client and the ACOS device. Once the SSL hand-
shake is finished, the rest of the FTP control traffic is encrypted between the client and the
ACOS device (as shown with the green lines).
• The PROT P command can indicate the data channel will be encrypted, as shown with the red
lines.
• Communication between the ACOS device and the FTP server is never encrypted in this exam-
ple.
page 358
FIGURE 46 Detailed example of an explicit passive FTP proxy session
Configuring SSL Offload for Secure FTPS Traffic

To configure ACOS to perform load balancing for FTPS traffic:
1. Configure client SSL. (See “Configuration Instructions for the Client SSL Template” on page 346).
2. Configure the real FTP servers.
3. Configure a service group for the servers and add them to the group.
4. Configure client-SSL template options.
5. Configure a virtual server and add a virtual port that has the service type ftp-proxy. Bind the service-
group to the virtual port and to the client-SSL template.
Since traffic between FTP servers and ACOS device is not encrypted, a server-SSL template is not
required.
page 359
Using the GUI
To configure Secure FTP Proxy:
1. Configure the real FTP server(s):

c. Click Create.
h. In the Port Number field, enter the port number (for example, Port 21).
j. If your configuration requires health checks, select the Default radio button to use the default
health check or select the Monitor radio button and select a desired health monitor from the
menu.
k. Click Create to add this port to the real FTP server.
m. Repeat for each FTP server.
2. Configure a service group and add the real servers.
d. In the Protocol drop-down list, select TCP, if not already selected.
e. Select the Health Monitor from the drop-down menu, if your configuration will use one.
f. In the Member section, click Create, and then click the Server drop-down list and select an
FTP server.
g. In the Port field, enter the service port number.
h. Click Create. The server appears in the list.
i. Repeat these steps for each FTP server that will be added to the service group.
j. Click Create. The new service group appears in the service group table.
page 360
3. To configure a virtual server for SSL offload for FTP traffic:

c. Click Create.
IP address where client requests are sent.
f. In the Virtual Port section, click Create.
g. From the page that appears, click the Protocol drop-down menu and select FTP-Proxy.
h. In the Port field, enter the service port number (default port number for FTP is 21).
k. Click the Template Client-SSL drop-down list, select the desired template.
l. Click Create. The FTP-Proxy port appears in the port list for the virtual server.
m. Click Update. The virtual server appears in the virtual server table.
Using the CLI

1. To configure a real FTP server, use the slb server command, then enter the port command at the
configuration level for the real server.
ACOS(config)# slb template client-ssl CLIENT-1
ACOS(config)# slb server SERVER-1 10.1.1.1
2. To configure a service group for real FTP servers and add them to the group, use the slb service-
group command, then enter the member command at the configuration level for the service group.
ACOS(config)# slb service-group GROUP-1 tcp
ACOS(config-slb svc group)# member SERVER-1 80
3. To configure a virtual server and FTP-Proxy virtual port, use the slb virtual-server command
and enter service-group and template client-ssl commands at the configuration level for the
virtual port to bind the port to the service group and the application templates. See Configuration
Instructions for the Client SSL Template for instructions on configuring a client-ssl template
ACOS(config-slb vserver)# port 80 ftp-proxy
ACOS(config-slb vserver-vport)# service-group GROUP-1
page 361

Show and Clear SLB FTP-Proxy Commands
The show slb ftp-proxy command displays ftp proxy output.
The clear slb ftp-proxy command clears the counters that appear in show slb ftp-proxy output.
page 362
ALG Protocol FWLB Support for FTP and SIP
In simple FWLB deployments, the ACOS device does not support the ability to load balance Application
Layer Gateway (ALG) protocols, which have multiple connections that can originate from either side of
the firewall deployment. This lack of predictability that occurs with ALG protocols can result in the pro-
tocol’s control connection and data connection being sent to different firewalls, which can cause the
application to stop working.
To handle some of the more complex ALG protocols, you can configure the ACOS device to load bal-
ance ALG protocols, such as FTP and SIP, through a firewall deployment consisting of paired firewalls
through the use of persistent session templates.
Overview of FTP and SIP

When dealing with ALG protocols such as FTP and SIP, sessions can originate from either side of the
firewalls. This unpredictable quality can pose a challenge to the load balancer(s) inside the FWLB
deployment when they are tasked with setting up the persistent sessions that these protocols require.
This ALG protocol FWLB feature resolves such issues with session persistence across a firewall
deployment for FTP and SIP traffic.
FTP Support
Figure 47 on page 364 shows FTP traffic passing back and forth between a client and an FTP server.
ACOS uses standard SLB server selection methods to choose a firewall that will handle the client’s traf-
fic.
The FTP protocol requires two separate sessions, or connections, which are represented in Figure 47
with red and green arrows:
• The red arrow represents the control connection.
• The green arrows represent the data connections (or “out of band” connections).
page 363
Overview of FTP and SIP
FIGURE 47 FTP Traffic Flows
The control connection (red arrow) is usually initiated by the client, while the data connections (green
arrows) can be initiated from either side of the FWLB deployment and can be initiated by either the cli-
ent or the FTP server.
If the client initiates the data connection, then the FTP transaction is said to be in “passive” mode. This
is because the FTP server remains passive. However, if the data connection is initiated by the FTP
server, then the FTP connection is said to be in “active” mode because the FTP server is taking action.
SIP Support
As is the case with FTP, Session Initiation Protocol (SIP) poses unique challenges for the ACOS load
balancers that are attempting to create persistent sessions across a pair of firewalls in an FWLB
deployment.
Figure 48 on page 365 shows two separate SIP transactions side by side. Both scenarios involve a SIP
server and two or more SIP clients.
The SIP protocol requires two separate sessions, which the figure represents with red and green
arrows:
• The green arrow represents the Communication Session.
• The red arrows represent the SIP Sessions.
page 364
Topologies for ALG Protocols FTP and SIP
FIGURE 48 SIP traffic originating from both sides of FWLB deployment
Communication Session
Communication Session
The initial communication session is launched from a SIP client (as opposed to the SIP server). This
communication session can be launched from either side of the FWLB deployment.
In the leftmost scenario shown in Figure 48, the communication session originates from SIP client 1,
while the scenario on the right shows the communication session originating from SIP client 2, (in
which case SIP client 2 is on the same side of the firewall as the SIP server).
Once the communication session is established between the SIP server and client, then the SIP clients
can communicate through a separate SIP session.
The load balancers in the FWLB deployment must be able to handle the SIP sessions, regardless of
which side of the FWLB deployment those sessions might originate from.
When the communication session and SIP session are launched from different sides of an FWLB
Deployment, the ACOS device can load balance sessions through the same firewall by using a per-
sistent session template.

With a brief overview of FTP and SIP protocols out of the way, this next section provides a more in-
depth illustration of sample network topologies. These topologies provide the foundation for configura-
tion examples that appear toward the end of this chapter.
page 365
FTP Network Diagram
Figure 49 shows an example of a network topology for FTP FWLB.
FIGURE 49 Topology for FTP FWLB
The network diagram has the following characteristics:
• A client is located at the top of a firewall deployment and an FTP server is located at the bottom.
The firewalls are located at the center of the topology.
• The firewall deployment uses one external ACOS device (“Ex-AX”) on the public side of the fire-
walls and an internal ACOS device (“In-AX”) to handle traffic from the private side of the firewalls.
NOTE: Real-world scenarios often use two ACOS devices in VRRP-A high avail-
ability mode. However, for the sake of simplicity, the topology discussed
in this chapter shows a single ACOS device on each side of the firewalls.
NOTE: Stateless load-balancing methods like Stateless Source IP Hash and

Stateless Per-Packet Round Robin, are not supported for ALG protocols
FWLB.
page 366
SIP Network Diagram
Figure 50 shows another example of a network topology, but this illustration shows the network ele-
ments that would appear in a situation in which SIP traffic is being load balanced across a firewall
deployment.
FIGURE 50 Topology for SIP FWLB
The network diagram has the following characteristics:
• A SIP client is located at the top of the firewall deployment.
• A SIP client and a SIP server are located at the bottom of the firewall deployment.
• The firewall deployment uses one external ACOS device (“Ex-AX”) on the public side of the fire-
walls and an internal ACOS device (“In-AX”) to handle traffic from the private side of the firewalls.
Persistent Sessions for ALG Protocol FWLB

This section shows persistent session information for FTP and SIP. The persistent session information
shown in the tables below correlates to the network topologies shown for FTP in Figure 49 on
page 366, and for SIP in Figure 50 on page 367.
page 367
FTP Persistent Sessions

The two session tables below show persistent sessions for FTP FWLB.
• Table 4 on page 368 displays persistent sessions for the client-side session, from the perspective
of the external-facing ACOS device.
• Table 5 on page 368 displays persistent sessions for the server-side session, from the perspec-
tive of the internal-facing ACOS device.
External-facing ACOS Device (client-side)
Session information in Table 4 represents the control connection of an FTP transaction in passive FTP
mode. The session (initiated from the client) is shown from the perspective of the external-facing
device, “Ex-AX”.
TABLE 4 ‘show session persist’ output for persistent FTP session through FWLB (“Ex-AX”)
Forward Source Forward Dest Reverse Source
10.1.1.2 10.4.1.2:65535 10.2.1.2:65535
• Forward Src – This leftmost column in the table above shows the IP address of the client
(10.1.1.2). As with standard SLB scenarios, the Forward Source is the IP address of the client.
• Forward Dest – The Forward Destination, (middle column above), is the real server’s IP address
(10.4.1.2). Note that this is different from standard SLB situations, in which the Forward Destina-
tion would usually be a VIP on the ACOS device instead of a real server.
• Reverse Source – The Reverse Source, (rightmost column above), represents the IP address
(10.2.1.2) for the firewall interface connected to the external-facing ACOS device, “Ex-AX”. The
fact that the firewall’s IP address is the Reverse Source is different from standard SLB scenarios
where the Reverse Source would typically be the IP address of the VIP on the ACOS device.
Internal-facing ACOS Device (server-side)
The control connection for the server-side session, from the client to the server, opens a persistent ses-
sion through the firewall. Subsequent TCP traffic, such as the data connection, has the same source IP
and destination IP as the control connection, so it follows the same path and selects the same firewall
as the persistent session selected by the control session.
Table 5 below displays output from the show session persist command for the persistent sessions for
passive FTP from the perspective of the internal-facing ACOS device (“In-AX”)
TABLE 5 show session persist’ output for persistent FTP sessions through FWLB (“In-AX”)
10.1.1.2 10.4.1.2:65535 10.4.1.2:65535
10.4.1.2 10.1.1.2:65535 10.3.1.2:65535
page 368
The first session in the table is for the control session, and the second session is for the data session.
The session output has the following noteworthy properties:
• (Prot) Forward Src – This is the IP address of the client (10.1.1.2). As with standard SLB scenar-
ios, the Forward Source is also the IP address of the client.
• Forward Dest – The Forward Destination is the real server’s IP address (10.4.1.2). This is differ-
ent from a standard SLB situation, in which the Forward Destination would usually be a VIP on
the ACOS device.
• Reverse Source – This is the IP address of the real FTP server (10.4.1.2).
The second session in the table can be disregarded because it belongs to the data connection; the
data connection is following the control connection that was opened up by the first persistent ses-
sion.
SIP Persistent Sessions

The two session tables below show persistent sessions for SIP firewall load balancing, as shown in the
topology diagram in Figure 50 on page 367.
• Table 6 on page 369 displays persistent sessions for the server-side session, from the perspec-
tive of the internal-facing ACOS device.
• Table 7 on page 370 displays persistent sessions for the client-side session, from the perspec-
tive of the external-facing ACOS device.
Internal-facing ACOS Device (server-side)
The session tables below show persistent sessions for SIP FWLB. The server-side sessions are seen
from the perspective of the internal-facing “In-AX” (AX5100A).
TABLE 6 show session persist’ output for persistent SIP session through FWLB (“In-AX”)
N/A 1.0.7.2:65535 1.0.1.2:65535
• Forward Src – This is a destination-IP persistent session. Therefore, there is no "Forward Source"
port.
• Forward Dest – The Forward Destination, (middle column above), is the SIP client 1 in the public
network (1.0.7.2). (See Figure 48 on page 365.)
• Reverse Source – The Reverse Source, (rightmost column above), represents the IP address
(1.0.1.2), which is the IP of the firewall interface connected to the internal-facing ACOS device,
“ACOS5100A”.
External-facing ACOS Device (client-side)
page 369
The session information shown below represents the communication connection for a SIP transaction.
The session (initiated from the client) is shown from the perspective of the external-facing device, “Ex-
AX”.
When configuring SIP for FWLB, the source-IP persistence template and the destination-IP persistence
template should be configured with the netmask option (with the value set to “/24”), in order to make the
SIP server and SIP client 2 traffic follow the same persistent session. The netmask option is needed
because the two sessions have different IP addresses but are located within the same subnet.
TABLE 7 ‘show session persist’ output for persistent SIP sessions through FWLB (“Ex-AX” - ACOS5100B)
1.0.7.2 1.0.9.3:65535 1.0.2.2:65535
1.0.7.2 1.0.9.2:65535 1.0.2.2:65535
The output for the two persistent sessions (from the perspective of the external-facing ACOS device,
“ACOS5100B”) has the following noteworthy properties:
• (Prot) Forward Src – The Forward Source is the IP address (1.0.7.2) associated with SIP client 1
on the public network.
• Forward Dest – The Forward Source is the IP address (1.0.9.3), which is associated with the SIP
server in Figure 50 on page 367. (The second session in the table has an IP of 1.0.9.2, which is
associated with SIP client 2.)
• Reverse Source – This address represents the IP (1.0.2.2) for the firewall interface connected to
the external-facing ACOS device, “ACOS5100B”.
Configuration Parameters for ALG Protocol FWLB

Regardless of whether you are configuring FWLB for FTP or SIP, the following items must be config-
ured:
• Wildcard VIP – See “Wildcard VIP” on page 370
• Session persistence – See “Session Persistence for FTP and SIP” on page 373
• Health Monitoring – See “Health Monitoring for FWLB Paths” on page 374
Wildcard VIP
A wildcard VIP is a VIP that does not have a specific IP address. Instead, wildcard VIPs have IP address
0.0.0.0 (for IPv4) or “ :: ” (for IPv6). Client requests sent to any IP address will be accepted when they are
received at a a wildcard VIP.
Wildcard VIPs use Access Control Lists (ACLs) to filter client requests, thus preventing potential mis-
creants from causing damage to network resources located behind the wildcard VIP.
page 370
To load balance ALG protocols through the firewalls, wildcard VIPs are necessary to handle traffic
heading in each direction (ingress and egress). A pair of wildcard VIPs is needed for each ACOS device.
One wildcard VIP is needed for traffic coming to the firewall and another is needed to handle traffic
going from the firewall.
ACLs for Identifying Valid Traffic
To specify the source and destination IP addresses that a wildcard VIP will accept from clients, a pair
of ACLs must be configured. Extended ACLs, which can filter based on destination address, IP protocol,
and TCP/UDP port numbers, should be used to provide more granular control. The goal is to permit
traffic along the path from a specific client subnet to the IP addresses of the real servers.
• Each ACL has an implicit “deny any” rule at the end. Any traffic that is not explicitly permitted by
another rule in the ACL is denied by the implicit “deny any” rule.
• ACOS can have only one wildcard VIP that is not bound to an ACL. This unbound wildcard VIP is
known as the default, and it is used to process traffic that does not create a positive match on
any of the other ACLs that are bound to other wildcard VIPs.
From External ACOS Perspective (Client-Side Session):
• An ACL is configured to permit traffic from the client subnet (10.1.1.x/24) to pass to the server’s
subnet (10.4.1.x/24). This ACL is bound to the service group associated with the firewalls. (In the
sample configuration that follows, this ACL is called “ACL 100”.)
• An ACL is configured to permit traffic from the server subnet (10.4.1.x/24) to pass to the client’s
subnet (10.1.1.x/24). This ACL is bound to the service group associated with the client. (In the
From Internal ACOS Perspective (Server-Side Session):
• An ACL is configured to permit traffic from the client subnet (10.1.1.x/24) to pass to the server’s
subnet (10.4.1.x/24). This ACL is bound to the service group associated with the servers. (In the
• An ACL is configured to permit traffic from the server subnet (10.4.1.x/24) to pass to the client’s
subnet (10.1.1.x/24). This ACL is bound to the service group associated with the firewalls. (In the
Wildcard Protocol Ports on the Wildcard
Each VIP on the ACOS devices in an ALG protocol FWLB deployment (“Ex-AX” and “In-AX”) requires a
wildcard TCP port (port 0). This wildcard port 0 is required because the data session destination port is
unknown when dealing with ALG scenarios. Thus, simply configuring well-known FTP ports 20 and 21
will not work and a wildcard port must be used instead.
These parameters (enabled by default) must be disabled for ALG protocol FWLB to work:
• Layer 4 health check – Layer 4 health checks are typically used to test the TCP ports on a real
server. The health check consists of a TCP SYN request being sent to the TCP port on an ACOS
page 371
device. If the TCP port responds with a TCP SYN ACK, then it is determined that the TCP port is
healthy. If no response is received, then it is determined that the TCP port is down.
The Layer 4 health check must be disabled in ALG protocol FWLB scenarios. If not disabled, then
the default Layer 4 health check method will be used, causing the SYN packet to be sent to the
default port (“port 65535”) of the real server. The SYN packet will not be received on port 0, the SYN
ACK response will not be sent, and the health check will fail (because it will appear as though the
real server status is down).
• Destination NAT – With destination NAT enabled, the ACOS device swaps the destination
address in the packet from the client with the VIP on the ACOS device. However, destination NAT
must be disabled at the wildcard port level to prevent this swap or else the traffic from the client
will have its destination IP changed to the IP address of the service-group member. This would be
the IP address of the firewall, which would present problems because the firewall can not handle
the traffic.
Server and Service-group Requirements
On the external-facing ACOS device (“Ex-AX”), a service group is required for the firewalls, and another
service group is required for the client. However, in most deployments, the service group would be con-
figured for the next-hop router(s) instead of an actual client.
On the internal ACOS device (“In-AX”), a service group is required for the firewalls, and another service
group is required for the real server(s).
When configuring the service groups, keep in mind that stateless load balancing algorithms, such as
Stateless Source IP Hash, are not supported.
• All real servers in the service groups must use wildcard ports, such as “port 0 tcp”. If this is not
done, persistent FWLB for FTP will not work correctly. The FTP protocol uses well-known ports
20 and 21, so specifying just one of these ports would result in traffic from the other port being
denied.
• Layer 4 health checks on the wildcard ports must be disabled. If this is not done, the configura-
tion will fail because the Layer 4 health check traffic will be sent to default port 65535 instead of
port 0. No response will be generated, and it will appear as though the port is down.
Promiscuous Mode
Promiscuous mode can be enabled on ACOS data interfaces. By default, the option is disabled, but it
must be enabled on the data interfaces that are connected to the firewalls in an ALG FWLB configura-
tion.
When using a Virtual Ethernet (VE) interface to connect to the firewalls, you must enable promiscuous
mode only on the VE itself. ACOS automatically enables promiscuous mode on each of the Ethernet
ports in the VLAN that belongs to that VE.
page 372
Session Persistence for FTP and SIP

Load balancing ALG protocols across a firewall requires session persistence. For a given session, the
same firewall must be used for traffic in both directions. For example, if the ACOS device selects FW1
(see Figure 49 on page 366) for a client’s FTP request, the ACOS device must continue to use FW1 for
all subsequent traffic on that control session.
FTP-Specific Configurations
FWLB for FTP requires the following configuration options for persistence:
• Source-IP persistence template – Within the source-IP persistence template, the include destina-
tion-IP option is used to enable persistence of the destination IP address. When the include desti-
nation-IP option is enabled in a source-IP persistence template, the ACOS device uses the same
firewall for a given source-destination pair of IP addresses for the entire session. This option is
disabled by default.
The internal ACOS device (“In-AX”), which is connected to the FTP servers, must have the per-
sistence template configured on both wildcard VIPs. However, the external ACOS device (“Ex-AX”),
which is connected to the clients, only needs to have the persistence template configured on the
wildcard VIP that is bound to the firewalls, but not on the wildcard VIP that is bound to the client.
• Use-rcv-hop-for-resp – This option is configurable on individual virtual ports. When enabled, it
forces the ACOS device to send a reply back through the last hop from which the request was
received.
• On the ACOS device connected to clients, FWLB ALG for FTP requires this option on the wild-
card virtual port for the server-to-client direction. This is the virtual port on the wildcard VIP that
uses that ACL that matches on the client subnet.
• On the ACOS device connected to the servers, the use-rcv-hop-for-resp option is required on the
wildcard virtual port for the client-to-server direction. In this case, the src-dst-ip-swap-persist
suboption also is required. The src-dst-ip-swap-persist suboption “swaps” the source and desti-
nation addresses in the persistent session.
The use-rcv-hop-for-resp option has several sub-options that can be used with the SIP protocol that
can use more than two sessions.
SIP-Specific Configuration
FWLB for SIP requires the following configuration options for persistence:
• Destination-IP session persistence should be configured on the ACOS device that is connected to
the SIP server and SIP client 2. (See Figure 50 on page 367.)
• Source-IP session persistence should be configured (using the incl-dst-ip command) on the
ACOS device that is connected to SIP client 1. (See Figure 50 on page 367.)
In order to get both sessions (originating from different sides of the FWLB) to go through the same fire-
wall node, a special persistent session must be configured on the ACOS device at the side of the SIP
server and SIP client 2. (See Figure 50 on page 367.)
page 373
The options: use-src-ip-for-dst-persist and use-date-ip-for-src-persist, have the same operation mode
as src-dst-ip-swap-persist.
Health Monitoring for FWLB Paths

Optionally, you can configure each ACOS device to regularly test the paths through the firewalls to the
other ACOS device. To test the paths, configure a Layer 3 health monitor (ICMP ping) and enable the
“transparent” option.
The transparent option includes a special payload in the health-check packets that is recognized by the
other ACOS device. For example, in Figure 51, a health-check packet from “Ex-AX” travels through FW1
to “In-AX”. “In-AX” recognizes the payload and replies to the health check.
The red arrow in Figure 51 below shows the path of this ICMP packet.
FIGURE 51 Health monitoring for Firewall
In response, the external-facing ACOS device (“Ex-AX”) checks whether the ICMP echo request packet
has a special payload. If the special payload is present, then “Ex-AX” sends an ICMP echo response
packet to the source MAC address of “FW1”, which was contained in the original echo request packet.
This ICMP echo response packet is represented by the blue arrow.
The health check (ICMP ping) occurs at Layer 3. The health checks at Layer 4 do not apply to FWLB
ALG and must be disabled.
page 374
Configuration
Configuration
This section shows how to configure an ACOS device for ALG FWLB using wildcard VIPs. Separate
instructions are provided for FTP and SIP, and configuration instructions are provided for the ACOS GUI
and CLI.
The process of configuring a pair of ACOS devices to handle AGL traffic, such as FTP and SIP, consists
of the following high-level steps:
1. Create ACLs that are bound to the wildcard VIPs in order to permit traffic from specific clients or
subnets. It is recommended that you use an extended ACL for greater granularity instead of a stan-
dard ACL.
2. Enable promiscuous mode on Ethernet interfaces connected to the firewalls, real servers, and cli-
ents.
3. Configure a Layer 3 ICMP health monitor with transparent mode enabled.
4. Configure the firewall nodes and real servers, and then add wildcard ports to the firewall nodes and
disable the Layer 4 health checks on those ports.
5. Create separate service groups for the firewall nodes, real servers, and SIP or FTP clients.
6. Configure a source-IP persistence template and enable destination persistence.
7. Configure the wildcard VIPs:
• Create a wildcard VIP for traffic in each direction.
• Bind the ACL that matches traffic from the servers to the wildcard VIP for the servers.
• Bind the ACL that matches traffic from the clients to the wildcard VIP for the firewalls.
• Disable destination NAT.
Using the CLI
Configuring Use-rcv-hop-for-resp
The use-rcv-hop-for-resp command is used at the virtual port level to enable the ACOS device to sup-
port persistent sessions of ALG traffic across a firewall deployment.
Configuring Src-dst-ip-swap-persist
The use-rcv-hop-for-resp command, with the src-dst-ip-swap-persist option, creates a persistent

session after the source IP and destination IP are swapped. The new persistent session that is created
should match both the source IP and the destination IP. This option should be used with the incl-dst-
ip option.
This option cannot be used for the SIP protocol, because a SIP transaction may involve three or more
parties.
page 375
Configuration
Configuring Use-src-ip-for-dst-persist
The use-rcv-hop-for-resp command, with the use-src-ip-for-dst-persist option, at the virtual port
level, creates a destination persistent session based on the source IP.
Configuring Use-dst-ip-for-src-persist
The use-rcv-hop-for-resp command, with the use-dst-ip-for-src-persist option, is used at the vir-
tual port level. When this option is enabled, the ACOS device uses the destination IP to create source-IP
persistent sessions for SIP or FTP sessions; the response packet goes through the same firewall as the
client’s request packet, and the SIP session and communication sessions is load balanced through the
same firewall node.
Configuring Include destination IP on Persistence
The incl-dst-ip command is used within the source-IP persistence template for ALG protocols, such
as FTP. A special persistent session is used for this feature, and this option helps ensure that the ses-
sion will be matched on both the source IP and destination IP addresses.
This option is not applicable to destination-IP persistence templates.
CLI Example for FTP
The CLI example below is based on the network topology for FTP FWLB shown in Figure 49 on
page 366.
Configure ACLs
It is recommended that you use extended ACLs, rather than standard ACLs, in order to achieve greater
granularity. Extended ACLs allow you to specify both the source and destination IP, so you have explicit
control over which traffic is permitted and where it is allowed to go.
(From Perspective of External ACOS Device)
This command creates extended “ACL 100”, which permits traffic from clients on subnet 10.1.1.0 and
to FTP servers on subnet 10.4.1.0. (This ACL is later bound to the service group associated with the
firewalls.)
ACOS(config)# access-list 100 permit tcp 10.1.1.0 0.0.0.255 10.4.1.0 0.0.0.255
This command creates extended “ACL 101”, which permits traffic from FTP servers on subnet 10.4.1.0
and to clients on subnet 10.1.1.0. (This ACL is later bound to the service group associated with the cli-
ents.)
(From Perspective of Internal ACOS Device)
page 376
Configuration
This command creates extended “ACL 150”, which permits traffic from clients on subnet 10.1.1.0 and
to FTP servers on subnet 10.4.1.0. (This ACL is later bound to the service group associated with the
FTP servers.)
This command creates extended “ACL 151”, which permits traffic from FTP servers on subnet 10.4.1.0
and to clients on subnet 10.1.1.0. (This ACL is later bound to the service group associated with the fire-
walls.)
Configure Ethernet Interfaces and Enable Promiscuity
The following commands create the Ethernet interfaces connected to the firewalls and the real servers
or clients, and then enable promiscuous mode:

ACOS(config-if:ethernet:1)# ip allow-promiscuous-vip
Health Monitor for Internal ACOS device
These commands create health monitor “FW-HC”, which contains the method ICMP transparent. The
method performs a transparent health check and sends a ping through the firewall to the IP address of
the external-facing ACOS device (“Ex-AX”) at 10.2.1.1.
ACOS(config)# health monitor FW-HC

ACOS(config-health:monitor)# method icmp transparent 10.2.1.1
Configure Firewall Nodes and Real Server
Next, create a server configuration for the firewall node “FW1” (at IP address 10.3.1.2) and another fire-
wall node “FW2” (at IP address 10.3.1.3), and assign the “FW-HC” health check. Then, add wildcard
ports (port 0) to the firewall nodes.
Create a server configuration for the FTP server, “SRV”, at IP address 10.4.1.2, and add wildcard ports
(port 0) to the server while disabling the Layer 4 health checks, which are enabled by default.
While it may seem unusual to do so, create a server configuration for the client, “CL” (at IP address
10.1.1.2). This ensures the FTP sessions are correctly routed across the firewall while maintaining ses-
sion persistence. As with the other servers, you must add wildcard ports (port 0) while disabling the
Layer 4 health checks.
page 377
Configuration
ACOS(config)# slb server FW1 10.3.1.2

ACOS(config-real server)# health-check FW-HC
ACOS(config)# slb server FW2 10.3.1.3
ACOS(config-real server)# health-check FW-HC
ACOS(config)# slb server SRV 10.4.1.2
ACOS(config-real server)# health-check-disable
ACOS(config)# slb server CL 10.1.1.2
Create Service Groups for Firewalls, Real Server, and Clients
These commands create the service group, “FW-SG”, which will be used to manage the two firewall
nodes. Then, add the two firewall nodes, “FW1” and “FW2”, as service group members, on port 0. Simi-
larly, create a separate service group “SRV-SG” to manage the FTP server, and then add the server
“SRV” on port 0. Lastly, create a separate service group “CL-SG” to manage the clients, and then add the
client “CL” on port 0.
ACOS(config)# slb service-group FW-SG tcp

ACOS(config-slb svc group)# member FW1 0
ACOS(config-slb svc group)# member FW2 0
ACOS(config)# slb service-group SRV-SG tcp
ACOS(config-slb svc group)# member SRV 0
ACOS(config)# slb service-group CL-SG tcp
ACOS(config-slb svc group)# member CL 0
page 378
Configuration

Configure a Source IP Persistence Template
Create a source-IP persistence template “AAA” and use the incl-dst-ip command to enable destina-
tion persistence.
ACOS(config)# slb template persist source-ip aaa

ACOS(config-source ip persist)# incl-dst-ip
ACOS(config-source ip persist)# exit
Configure Wildcard VIPs
Use the following commands to create the wildcard VIPs at IP address 0.0.0.0, which will be used to
handle FTP traffic coming to the external-facing ACOS device from the client on the public network. The
previously-created ACL (“ACL 100”) is bound to the wildcard VIP, port 0 is associated with service group
“FW-SG”, destination NAT is disabled, and persistence is enabled.
ACOS(config)# slb virtual-server toFW 0.0.0.0 acl 100

ACOS(config-slb vserver-vport)# name _wildcard_v4_100_TCP_65535
ACOS(config-slb vserver-vport)# service-group FW-SG
ACOS(config-slb vserver-vport)# template persist source-ip aaa
These commands create the wildcard VIPs at IP address 0.0.0.0 to handle FTP traffic from the exter-
nal-facing ACOS device to real servers on the private network. “ACL 101” is bound to the wildcard VIP;
port 0 is associated with service group “SRV-SG”; destination NAT is disabled; and persistence is
enabled.
ACOS(config)# slb virtual-server fromFW 0.0.0.0 acl 101

ACOS(config-slb vserver-vport)# name _wildcard_v4_101_TCP_65535
ACOS(config-slb vserver-vport)# service-group SRV-SG
ACOS(config-slb vserver-vport)# use-rcv-hop-for-resp src-dst-ip-swap-persist
ACOS(config-slb vserver-vport)# template persist source-ip aaa
Verifying FTP Configurations with Show Command
When finished with these configurations, you can use the “show session” command to verify that an
FTP control connection could create a src-dst-ip-swap-persist session.
page 379
Configuration
Internal-ACOS(config)# show session

Port Forward Source Forward Dest Reverse Source
--------------------------------------------------------------------
src 10.4.1.2 10.1.1.2:65535 10.3.1.3:65535
Total Sessions: 1
When FTP control connection is established, data connections select the right firewall using the estab-
lished persistent session.
CLI Examples for SIP

The CLI example below shows the commands required to configure the ACOS device to perform SIP
FWLB.
Internal-facing Device
The configurations below are based on the network topology shown in Figure 50 on page 367 and rep-
resent the configuration that must be made on the internal-facing ACOS device (ACOS5100A).
Configure ACLs
The following commands create a standard ACL, which will be applied to the internal-facing ACOS
device (“ACOS5100A”), and will permit traffic from “SIP client 1”, which is located on the public subnet
(1.0.7.0). At the same time, this ACL will deny all other traffic.
Internal-ACOS(config)# access-list 2 10 permit 1.0.7.0 0.0.0.255 log
The following commands create standard ACL, which will be applied to the internal-facing ACOS device
(“ACOS5100A”), and will permit traffic from the SIP client and SIP server on the internal subnet (1.0.9.0)
while denying all other traffic.
Internal-ACOS(config)# access-list 3 10 permit 1.0.9.0 0.0.0.255 log
The following commands create the Ethernet interfaces on the internal-facing ACOS device that is con-
nected to the firewalls and to the real servers or clients. Then, commands are used to enable promiscu-
ous mode on those interfaces:
Internal-ACOS(config)# interface ethernet 1

Internal-ACOS(config-if:ethernet:1)# ip address 1.0.9.1 255.255.255.0
Internal-ACOS(config-if:ethernet:1)# ip allow-promiscuous-vip
Internal-ACOS(config-if:ethernet:1)# exit
Internal-ACOS(config)# interface ethernet 2
Internal-ACOS(config-if:ethernet:1)# ip address 1.0.1.1 255.255.255.0
Internal-ACOS(config-if:ethernet:1)# ip allow-promiscuous-vip
page 380
Configuration
Configure Health Monitor on Internal ACOS device
The following command creates the health monitor “fw-hc1”, which contains the method ICMP trans-
parent. The method is used to perform a transparent health check, and it will send a ping through the
firewall to the ACOS interface on the far side of the firewall at IP 1.0.2.1:
Internal-ACOS(config)# health monitor fw-hc1

Internal-ACOS(config-health:monitor)# method icmp transparent 1.0.2.1
Configure SIP Clients, Firewall Nodes, and SIP Servers
Next, create a server configuration for the SIP client, “sip-client2”, which is at IP address 1.0.9.2. This is
necessary to ensure the SIP sessions can be correctly routed across the firewall while maintaining ses-
sion persistence. Add wildcard ports at port 0 for both TCP and UDP, both of which are necessary for
SIP. In addition, disable Layer 4 health checks on both wildcard ports.
Internal-ACOS(config)# slb server sip-client2 1.0.9.2

Internal-ACOS(config-real server)# port 0 tcp
Internal-ACOS(config-real server-node port)# health-check-disable
Internal-ACOS(config-real server-node port)# exit
Internal-ACOS(config-real server)# port 0 udp
Internal-ACOS(config-real server)# exit
Create a server configuration for the firewall node “fw1” (at IP address 1.0.1.2) and firewall node “fw2”
(at IP address 1.0.1.3), and assign the “fw-hc1” health check to both firewall nodes. Add wildcard ports
(port 0) to the firewall nodes for TCP and UDP, and disable the Layer 4 health checks for these wildcard
ports.
Internal-ACOS(config)# slb server fw1 1.0.1.2

Internal-ACOS(config-real server)# health-check fw-hc1
Internal-ACOS(config)# slb server fw2 1.0.1.3
Internal-ACOS(config-real server)# health-check fw-hc1
page 381
Configuration
Next, create a server configuration for the SIP server “sip-srv” (at IP address 1.0.9.3), and add wildcard
ports (port 0) for TCP and UDP, while disabling the Layer 4 health checks on port 0, which are enabled
by default.
Internal-ACOS(config)# slb server sip-srv 1.0.9.3

Internal-ACOS(config-real server)# health-check-disable
Create the Service Groups for Clients, Firewalls, and Server
Create two service group “sg-sip-client2-tcp” and “sg-sip-client2-udp” to manage the clients, and then
add the client “sip-client2” to each service group at port 0.
Internal-ACOS(config)# slb service-group sg-sip-client2-tcp tcp

Internal-ACOS(config-slb svc group)# member sip-client2 0
Internal-ACOS(config-slb svc group-member:0)# exit
Internal-ACOS(config-slb svc group)# exit
Internal-ACOS(config)# slb service-group sg-sip-client2-udp udp
Internal-ACOS(config-slb svc group)# member sip-client2 0
Use these commands to create service groups “sg-fw-tcp1” (TCP) and “sg-fw-udp2” (UDP). These ser-
vice groups manage the firewall nodes. Add two firewall nodes, “fw1” and “fw2”, on port 0 to each ser-
vice group.
Internal-ACOS(config)# slb service-group sg-fw-tcp1 tcp

Internal-ACOS(config-slb svc group)# member fw1 0
Internal-ACOS(config)# slb service-group sg-fw-udp2 udp
page 382
Configuration
Similarly, create two separate service groups to manage the SIP server. Create service group “sg-sip-
srv1” for TCP traffic and create “sg-sip-srv2”. Then, add “sip-srv” as a member of each service group on
port 0.
Internal-ACOS(config)# slb service-group sg-sip-srv1 tcp

Internal-ACOS(config-slb svc group)# member sip-srv 0
Internal-ACOS(config)# slb service-group sg-sip-srv2 udp
Internal-ACOS(config-slb svc group)# member sip-srv 0
Configure a Destination IP Persistence Template
Create a destination-IP persistence template “dtemp1”:
Internal-ACOS(config)# slb template persist destination-ip dtemp1

Internal-ACOS(config-destination ip persist)# exit
Configure Wildcard VIPs on the Internal-facing ACOS Device
Use the following commands to create the wildcard VIPs at IP address 0.0.0.0. This wildcard VIP will be
assigned to the internal-facing ACOS device (ACOS5100A), and will be used to handle SIP traffic com-
ing from the firewall (and from the SIP client on the public network), and going to the internal-facing
ACOS device.
The previously-created ACL is bound to the wildcard VIP, thus allowing traffic from SIP client 1, while
denying all other traffic.
Port 0 is associated with service groups “sg-sip-client2-tcp” and “sg-sip-client2-udp”. Destination NAT is
disabled.
The use-rcv-hop-for-resp use-src-ip-for-dst-persist option is applied to wildcards ports for both TCP and
UDP to create a destination persistent session based on source IP. The no-dest-nat option is applied to
TCP and UDP service groups to help ensure the session is matched on both the source IP and destina-
tion IP addresses.
Internal-ACOS(config)# slb virtual-server fromFW 0.0.0.0 acl 2

Internal-ACOS(config-slb vserver)# port 0 tcp
Internal-ACOS(config-slb vserver-vport)# service-group sg-sip-client2-tcp
Internal-ACOS(config-slb vserver-vport)# use-rcv-hop-for-resp use-src-ip-for-dst-persist
Internal-ACOS(config-slb vserver-vport)# no-dest-nat
Internal-ACOS(config-slb vserver-vport)# exit
Internal-ACOS(config-slb vserver)# port 0 udp
Internal-ACOS(config-slb vserver-vport)# service-group sg-sip-client2-udp
Internal-ACOS(config-slb vserver-vport)# use-rcv-hop-for-resp use-src-ip-for-dst-persist
page 383
Configuration

Internal-ACOS(config-slb vserver)# exit
Use these commands to create the wildcard VIPs at IP address 0.0.0.0. This wildcard VIP is assigned
to the internal-facing ACOS device (ACOS5100A) and used to handle SIP traffic going to the firewall
from the internal-facing ACOS device (and originally from the SIP client and SIP server on the private/
internal network).
The previously-created ACL is bound to the wildcard VIP, thus allowing traffic from internal subnet (that
is, SIP client 2 and the SIP server), while denying all other traffic. In addition, port 0 is associated with
service group “sg-fw-tcp1” and “sg-fw-udp2”. Destination NAT is disabled.
Also, the no-dest-nat option is applied to the TCP and UDP service groups to help ensure the session
will be matched on both the source IP and destination IP addresses.
Internal-ACOS(config)# slb virtual-server toFW 0.0.0.0 acl 3

Internal-ACOS(config-slb vserver)# port 0 tcp
Internal-ACOS(config-slb vserver-vport)# service-group sg-fw-tcp1
Internal-ACOS(config-slb vserver-vport)# template persist destination-ip dtemp1
Internal-ACOS(config-slb vserver)# port 0 udp
Internal-ACOS(config-slb vserver-vport)# service-group sg-fw-udp2
Internal-ACOS(config-slb vserver-vport)# template persist destination-ip dtemp1
Internal-ACOS(config-slb vserver)# exit
Verifying Internal-ACOS SIP Configurations with Show Command
When finished with these configurations, you can use the “show session” command to verify that a SIP
control connection could create a dst-ip-persistent session, as shown below:

Prot Forward Dest Reverse Source Age
--------------------------------------------------------
dst 1.0.7.2:65535 1.0.1.2:65535 300
Total Sessions: 1
External-facing Device
The configurations below are based on the network topology shown in Figure 50 on page 367 and rep-
resent the configurations that must be made on the external-facing ACOS device (ACOS5100B).
page 384
Configuration
Configure ACLs
This command creates a standard ACL, which is applied to the external-facing ACOS device
(“ACOS5100B”), and permits traffic from “SIP client 2” located on the private subnet (1.0.9.0). This ACL
denies all other traffic.
External-ACOS(config)# access-list 4 10 permit 1.0.9.0 0.0.0.255 log
This command creates a standard ACL, which is applied to the external-facing ACOS device
(“ACOS5100B”), and permits traffic from SIP client 1 on the public subnet (1.0.7.0) while denying all
other traffic.
External-ACOS(config)# access-list 5 10 permit 1.0.7.0 0.0.0.255 log
The following commands create the Ethernet interfaces on the external-facing ACOS device that is con-
nected to the firewalls and to the SIP client. Promiscuous mode is then enabled on those same inter-
faces:
External-ACOS(config)# interface ethernet 1

External-ACOS(config-if:ethernet:1)# ip address 1.0.2.1 255.255.255.0
External-ACOS(config-if:ethernet:1)# ip allow-promiscuous-vip
External-ACOS(config-if:ethernet:1)# exit
External-ACOS(config)# interface ethernet 2
External-ACOS(config-if:ethernet:1)# ip address 1.0.7.1 255.255.255.0
External-ACOS(config-if:ethernet:1)# ip allow-promiscuous-vip
External-ACOS(config-if:ethernet:1)# exit
Configure health monitor on External ACOS device
The following command creates the health monitor “fw-hc2”, which contains the method ICMP trans-
parent. The method is used to perform a transparent health check by sending a ping through the fire-
wall to the ACOS interface on the far side of the firewall at IP 1.0.1.1:
External-ACOS(config)# health monitor fw-hc2

External-ACOS(config-health:monitor)# method icmp transparent 1.0.1.1
External-ACOS(config-health:monitor)# exit
Configure SIP Clients, Firewall Nodes, and SIP Servers
A server configuration is created for the SIP client, “sip-client1” (at IP 1.0.7.2). This is necessary to
ensure the SIP sessions can be correctly routed across the firewall while maintaining session per-
sistence. Add wildcard ports (port 0) for both TCP and UDP, both of which are necessary for SIP. In
addition, disable the Layer 4 health checks these wildcard ports.
External-ACOS(config)# slb server sip-client1 1.0.7.2

External-ACOS(config-real server)# port 0 tcp
External-ACOS(config-real server-node port)# exit
page 385
Configuration
External-ACOS(config-real server)# port 0 udp

External-ACOS(config-real server)# exit
Create a server configuration for the firewall node “fw1” (at IP 1.0.2.2) and firewall node “fw2” (at IP
1.0.2.3). Assign the health check created earlier (“fw-hc2”). Then, add wildcard ports (port 0) to the fire-
wall nodes for TCP and UDP, while disabling the default layer 4 health checks.
External-ACOS(config)# slb server fw1 1.0.2.2

External-ACOS(config-real server)# health-check fw-hc2
External-ACOS(config-real server-node port)# health-check-disable
External-ACOS(config)# slb server fw2 1.0.2.3
External-ACOS(config-real server)# health-check fw-hc2
There is no server configuration required for the SIP server because that device is connected to the
ACOS5100A, the internal-facing ACOS device.
Create the Service Groups for Clients, Firewalls, and Server
Create a service group, “sg-sip-client1-tcp” to manage the TCP portion of the SIP transaction on the cli-
ent, and then add “sip-client1” on port 0 of the service group.
External-ACOS(config)# slb service-group sg-sip-client1-tcp tcp

External-ACOS(config-slb svc group)# member sip-client1 0
External-ACOS(config-slb svc group-member:0)# exit
External-ACOS(config-slb svc group)# exit
Repeat the process above for UDP. Create a service group, “sg-sip-client1-udp” to manage the UDP por-
tion of the SIP transaction on the client, and then add “sip-client1” on port 0 of the service group.
External-ACOS(config)# slb service-group sg-sip-client1-udp udp

External-ACOS(config-slb svc group)# member sip-client1 0
page 386
Configuration
These commands create service groups “sg-fw-tcp3” (TCP) and “sg-fw-udp4” (UDP), which are used to
manage firewall nodes. The firewall nodes, members “fw1” and “fw2”, are added to port 0 of each ser-
vice group.
External-ACOS(config)# slb service-group sg-fw-tcp3 tcp

External-ACOS(config-slb svc group)# member fw1 0
External-ACOS(config)# slb service-group sg-fw-udp4 udp
There is no service group required for the SIP server because that device is connected to the internal-
facing ACOS device (ACOS5100A).
Configure a Destination IP Persistence Template
Use these commands to create a source-IP persistence template “stemp1” with incl-dst-ip option
enabled:
External-ACOS(config)# slb template persist source-ip stemp1

External-ACOS(config-source ip persist)# incl-dst-ip
External-ACOS(config-source ip persist)# exit
Configure Wildcard VIPs on the External-facing ACOS Device
Use these commands to create the wildcard VIPs at IP address 0.0.0.0. This wildcard VIP will be
assigned to the external-facing ACOS device (ACOS5100B), and will be used to handle SIP traffic com-
ing from the firewall, (and from the SIP client on the private network), and going to the external-facing
ACOS device.
The previously-created ACL is applied to the wildcard VIP, thus allowing traffic from SIP client 2, while
denying all other traffic.
In addition, port 0 is associated with service group “sg-sip-client1-tcp” and “sg-sip-client1-udp”, and des-
tination NAT is disabled. Also, the use-rcv-hop-for-resp use-dst-ip-for-src-persist command is applied to
the wildcard ports (port 0), which will cause the response packets to go through the same firewall as
the client’s request packets. The communication and SIP sessions will be load balanced through the
same firewall node.
External-ACOS(config)# slb virtual-server fromFW 0.0.0.0 acl 4

External-ACOS(config-slb vserver)# port 0 tcp
External-ACOS(config-slb vserver-vport)# service-group sg-sip-client1-tcp
page 387
Configuration
External-ACOS(config-slb vserver-vport)# use-rcv-hop-for-resp use-dst-ip-for-src-persist

External-ACOS(config-slb vserver-vport)# no-dest-nat
External-ACOS(config-slb vserver-vport)# exit
External-ACOS(config-slb vserver)# port 0 udp
External-ACOS(config-slb vserver-vport)# service-group sg-sip-client1-udp
External-ACOS(config-slb vserver-vport)# use-rcv-hop-for-resp use-dst-ip-for-src-persist
External-ACOS(config-slb vserver)# exit
Use the following commands to create the wildcard VIPs at IP address 0.0.0.0. This wildcard VIP will be
assigned to the external-facing ACOS device (ACOS5100B), and will be used to handle SIP traffic com-
ing to the external-facing ACOS device from the SIP client. The previously-created ACL is bound to the
wildcard VIP, thus allowing traffic from public network (that is, SIP client 1), while denying all other traf-
fic. In addition, port 0 is associated with service group “sg-fw-tcp” and “sg-fw-udp”. Destination NAT is
disabled.
External-ACOS(config)# slb virtual-server toFW 0.0.0.0 acl 5

External-ACOS(config-slb vserver)# port 0 tcp
External-ACOS(config-slb vserver-vport)# service-group sg-fw-tcp3
External-ACOS(config-slb vserver-vport)# template persist source-ip stemp1
External-ACOS(config-slb vserver)# port 0 udp
External-ACOS(config-slb vserver-vport)# service-group sg-fw-udp4
External-ACOS(config-slb vserver-vport)# template persist source-ip stemp1
External-ACOS(config-slb vserver)# exit
Verifying ACOS5100B SIP Configurations with Show Command
When finished with these configurations, you can use the “show session” command to see that a SIP
session could create the following source-IP persistent sessions, as shown below:

Prot Forward Source Forward Dest Reverse Source Age
------------------------------------------------------------------------------
src 1.0.7.2 1.0.9.3:65535 1.0.2.2:65535 300
src 1.0.7.2 1.0.9.2:65535 1.0.2.2:65535 300
Internal-ACOS(config)#
Note that the two sessions in the table are the same. This is because the SIP session is following the
persistent session that has already been established by the communication session.
page 388
DNS Optimization
ACOS can locally cache DNS replies and serve cached replies in response to DNS requests from clients.
DNS caching offloads DNS servers, by caching replies to DNS queries and serving the cached replies in
response to subsequent queries. This chapter describes the DNS optimization features supported by
the ACOS device.
You can enable DNS caching globally or on individual VIPs. See the following sections:
• “Global DNS Optimization” on page 389
• “DNS Optimization per VIP” on page 390
• “Load Balancing with the “DNSSEC OK” (DO) Bit” on page 408
These features are supported only in software releases that support SLB. For information about DNS
security features, see the Application Access Management and DDoS Mitigation Guide.
Global DNS Optimization

When DNS caching is enabled, the ACOS device sends the first request for a given name (hostname,
fully-qualified domain name, and so on) to the DNS server. ACOS caches the reply from the DNS server,
and sends the cached reply in response to the next request for the same name.
ACOS continues to use the cached DNS reply until the reply times out. After the reply times out, ACOS
sends the next request for the hostname to the DNS server, and caches the reply, and so on.
DNS caching is disabled by default. When you enable it, replies are cached for 300 seconds by default.
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.
The maximum size for DNS cache entries can be 1-4096 bytes. The default is 256 bytes.
Global DNS caching applies to DNS requests sent to a VIP with virtual-port type udp (on port 53) or dns-
udp (on port 53). DNS caching is not supported for DNS requests sent to other UDP port numbers or
over TCP.
Configure Global DNS Optimization Using the GUI

1. Hover over ADC in the menu bar, then select SLB.
2. Select the Global tab.
page 389
DNS Optimization per VIP
3. Select the checkbox in the DNS Cache Enable field.

After selecting this checkbox, you can configure the Response Type and TTL Threshold.
4. Optionally, you can also configure the following global cache parameters:
• DNS Cache Age
• DNS Cache Entry Size
5. Click Update to save your settings.
Configure Global DNS Optimization Using the CLI
To enable DNS caching, use the following commands:

ACOS(config-common)# dns-cache-enable
The default cache timeout is 300 seconds. To change the cache timeout to 500 seconds, use this com-
mand:
ACOS(config-common)# dns-cache-age 500
The default maximum cache entry size is 256 bytes. This command changes the maximum size to 128
bytes.
ACOS(config-common)# dns-cache-entry-size 128
To display global DNS caching statistical information, use the following command:
ACOS# show dns cache statistics

DNS caching per-VIP DNS provides finer control over DNS caching. You can configure caching policies
to tightly control caching behavior.
• DNS caching on per-VIP basis
• DNS caching on per-record basis
• Rate-based DNS caching
• DNS record weighting for selective cache entry aging
• Throttling based on domain name
• Logging of DNS cache hits
Parameters for DNS caching per VIP are configured in the following places:
page 390
• Class list
• DNS template
Per-VIP DNS caching applies to DNS requests sent to a VIP with virtual-port type dns-udp, on any port
number. DNS caching is not supported for DNS requests sent to virtual-port type dns, or requests sent
over TCP.
Class-List Parameters for DNS Caching

To control DNS caching based on domain name, you can use a class list. A class list used for DNS
caching has entries in the following format:
match-option domain-string {glid | lid} num
Each entry consists of the following:
• match-option – Specifies the match criteria for the domain-string. The match-option can be one of
the following:
• dns contains – The entry matches if the DNS request is for a domain name that contains the
domain-string anywhere within the requested domain name.
• dns starts-with – The entry matches if the DNS request is for a domain name that begins with
the domain-string.
• dns ends-with – The entry matches if the DNS request is for a domain name that ends with the
domain-string.
• domain-string – Specifies all or part of the domain name on which to match.
For wildcard matching on more than one character, you can use the dns contains, dns starts-with,
and dns ends-with options. For example, “dns ends-with example.com” matches on both
“abc.example.com” and “www.example.com”.
• {glid | lid} num – Specifies a global limit ID (GLID) or a local limit ID (LID). Limit IDs contain poli-
cies. GLIDs can be used by more than one DNS template. LIDs are configured within an individual
DNS template. GLIDs / LIDs contain DNS caching policies. ACOS applies the DNS caching policy
in the specified GLID or LID to the domain-string.
Each class list can contain a maximum of 1000 entries or 5000 domain-string characters.
Example Class List for DNS Caching
dns contains a10networks.com lid 1

dns starts-with www.example1.com lid 2
dns ends-with www.example2.com lid 3
dns contains example3 lid 4
Each class-list entry selects a DNS caching policy, contained in the LIDs, based on the matching host-
name. For example, queries for hostnames that contain “a10networks.com” are processed using the
page 391
policy in LID 1. The LIDs are configured in a DNS template that is applied to the DNS virtual port. (See
“DNS Template Parameters” on page 392.)
DNS Template Parameters

You can configure the following DNS caching parameters in DNS templates:
• DNS caching state (DNS template enabled or disabled) – DNS caching is enabled by default. You
can easily disable it by setting this parameter, without changing the configuration of other cach-
ing parameters or changing the configuration settings on the DNS virtual ports that use the tem-
plate.
• Default caching policy – Specifies the cache action (cache or nocache) for requests that do not
match any domain-string in the class list. The default is nocache. By default, replies for domain
names that do not match the class list are not cached.
• Maximum cache size per ACOS device – Specifies the maximum number of DNS replies that can
be cached on the ACOS device. You can specify from 1 to the maximum allowed on your ACOS
model. The default is the maximum allowed on your ACOS model.
This is based on the amount of RAM installed in each ACOS device. For details, contact A10 Net-
works.
• Maximum cache entry size – Specifies the maximum number of bytes a DNS cache entry can
have. You can specify 1-4096 bytes. The default is 256 bytes.
• Maximum query length – Specifies the maximum number of bytes a DNS query can received by
the DNS virtual port can contain. You can specify 1-4096 bytes. By default, this parameter is
unset.
• Logging – You can enable logging of DNS caching events. (See “DNS Cache Logging” on
page 394.) Logging is disabled by default. When you enable it, you can specify the number of
minutes between generation of log messages, 1-10000 minutes.
• Class-list LID – Specifies the DNS policy (DNS caching settings) for domain-strings in the class
list.
DNS Caching LID / GLID Policy Parameters

You can configure the following DNS caching policy settings either in a GLID or in a LID within the DNS
template. Settings configured in a GLID can be used by multiple DNS templates. Settings within the LID
in a DNS template can be used only by that template.
• Caching state – Enabled or disabled
• Connection rate limit – maximum DNS connection rate allowed before the over-limit action is
applied. (See below.) You can specify 1-4294967295 DNS connections per 1-65535 100-millisec-
ond (ms) intervals. There is no default.
page 392
• Over-limit action – Action to take when the DNS connection or request limit or rate is exceeded.
The default action is to drop the traffic. Optionally, you can specify one of the following actions
instead:
• Enable caching
• Disable caching
• Forward the traffic anyway
• Lock out further traffic from the sender for the specified number of minutes, 1-1023. You also
can specify a lockout time for any of the other over-limit actions listed above.
By default, logs are not generated by an over-limit action. You can enable logging of over-limit
actions. Over-limit messages are sent immediately. They are not queued based on DNS cache log-
ging settings.
• Time-To-Live (TTL) – Period an entry remains in the cache before it is removed. By default, the
global DNS cache age is used. The default global DNS cache age is 300 seconds (5 minutes).
• Weight – Numeric value used when cache entries need to be removed to make room for new
entries. You can assign a weight of 1-7. Lower-weighted objects are removed before higher
weighted objects.
• Cache more than 60% full, entries with weight 1 are eligible to be removed.
• Cache more than 70% full, entries with weight 1 or 2 are eligible to be removed.
• Cache more than 80% full, entries with weights 1-4 are eligible to be removed.
• Cache more than 90% full, entries with weights 1-6 are eligible to be removed.
The default weight is 1.
Additional Options (available only in GLIDs)
• Connection limit – maximum active DNS connections allowed before the over-limit action is
applied. You can specify 1-1048575 DNS connections. There is no default.
• Request limit – maximum number of DNS requests before the over-limit action is applied. You
can specify 1-1048575. There is no default.
• Request rate limit – maximum rate of DNS requests before the over-limit action is applied. You
can specify 1-4294967295 DNS requests every 1-65535 100-millisecond (ms) interval(s). There is
no default.
• Use NAT pool – Binds a NAT pool to the GLID. The pool is used to provide reverse NAT for class-
list members that are mapped to this GLID.
page 393
DNS Cache Logging

Logging for DNS caching is disabled by default. When you enable it, the following information is logged:
• Number of DNS cache hits between log intervals or before aging time
• ACOS management IP address, severity level (6, informational) and domain name requested
The hits counter is reset to 0 after the messages are sent. The counter is not cumulative.
Here are some examples:
Aug 22 04:05:14 192.168.20.164 a10logd: [DNS-Cache]<6> dns=example.com hits=6 for the last
1 minute interval
Aug 22 04:05:16 192.168.20.164 a10logd: [DNS-Cache]<6> dns=example5.nl hits=5 for the last
1 minute interval
Configuration
To configure per-VIP DNS caching:
• Configure a class list that maps domain-strings to GLIDs or LIDs.
• If using GLIDs to specify the DNS caching policies, configure the GLIDs.
• Configure a DNS template. Specify the name of the class list. Bind the class list to the GLIDs, or
configure the LIDs under the class list.
• Configure a real server for the DNS server. Add UDP port 53 to the real server.
• Configure a UDP service group and add the real server to it.
• Configure a VIP using a virtual port with service type dns-udp. Bind the DNS template and the ser-
vice group to the virtual port.
In the service group, stateless load-balancing methods are not supported with DNS features described
in this chapter.
Configure a Class List

You can configure a class list in either of the following ways:
• Use a text editor on a PC or other device to create the list, then import it onto the ACOS device.
• Use CLI commands to create the list entries.
For class-list syntax information, see “Class-List Parameters for DNS Caching” on page 391.
page 394
Using the CLI
Importing a Class List onto the ACOS device
After the class list is configured, import it onto the ACOS device using the import class-list com-
mand at the Privileged EXEC or global configuration level. The command specifies the name the class
list will have on the ACOS device along with the file transfer protocol, username (when required), and
directory path.
You can enter the entire URL on the command line or press Enter to display a prompt for each part of
the URL. If you enter the entire URL and a password is required, you will still be prompted for the pass-
word. To enter the entire URL:
• tftp://host/file
• ftp://[user@]host[:port]/file
• scp://[user@]host/file
• sftp://[user@]host/file
You also can export class lists to a remote server, using the export class-list command.
Deleting a class list from a file system is the same as saving the configuration changes to the file sys-
tem. The write mem command is required.
Configuring a Class List in the CLI
To configure a class list in the CLI, use the class-list commands. You can either save the class list as
a separate file or save it to the startup-config. If the class list contains 100 or more entries, it is recom-
mended to save the list to a file. 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, where the dns command is available. Use the command to configure
match rules to map DNS traffic to LIDs or GLIDs. (See “Class-List Parameters for DNS Caching” on
page 391.)
Configure the GLIDs

To configure DNS caching policies in GLIDs, use the following methods to configure each GLID. To use
LIDs configured within the DNS template, go to “Configure a DNS Template” on page 396.
Using the CLI
Use the glid command at the global configuration level. This command creates the GLID and changes
the CLI to the configuration level for it, where the following commands are available.
• The conn-limit command specifies the maximum number of concurrent connections on the
DNS virtual port before the over-limit action is applied.
page 395
• The conn-rate-limit command specifies the maximum DNS connection rate before over-limit
action is applied.
• The over-limit-action command specifies the action when the DNS connection, request limit,
or rate is exceeded.
• Th request-limit command specifies the maximum number of DNS requests before over-limit
action is applied.
• The request-rate-limit command specifies the maximum DNS request rate before over-limit
action is applied.
• The dns command disables or enables DNS caching.
• The dns ttl command specifies the number of seconds to keep an entry in the cache before
removing it.
• The dns weight command specifies the numeric value used when cache entries need to be
removed to make room for new entries.
Configure a DNS Template

To configure a DNS template for DNS caching, use either of the following methods.
Using the CLI
To configure a DNS template for DNS caching, enter the slb template dns command at the global con-
figuration level of the CLI. The command creates the template and changes the CLI to the configuration
level for it, where the following commands are available.
For configurable ranges and default values, see “DNS Template Parameters” on page 392.
• The default-policy command specifies the default action for DNS queries for domain names
that do not match a class list entry.
• The dns-log-enable period command enables logging and specifies how often to generate logs.
• The max-cache-size command specifies the maximum number of replies to cache per DNS vir-
tual port.
• The class-list name command specifies the name of the class list to use.
• The class-list lid command creates a LID and changes the CLI to configure it. LID numbers
are from 1 to 1023.
• To disable the DNS template without removing the template from the configuration, use the dis-
able-dns-template command:
page 396
LID Commands for DNS Caching
The following commands are available at the configuration level for DNS caching LIDs.
• The conn-rate-limit command specifies the maximum DNS connection rate before over-limit
action is applied.
• The over-limit-action command specifies the action when DNS connection, request limit, or
rate is exceeded.
• The dns cache-disable command disables DNS caching. The dns cache-enable command
enables caching.
• The dns ttl command specifies the number of seconds to keep an entry in the cache before
removing it.
• The dns weight command specifies the value used when cache entries are removed for space
for new entries.
Enable DNS Caching on a VIP
Using the CLI
To enable DNS caching on a VIP, use the following commands.
• At the configuration level for the virtual server, the port command adds a dns-udp port to the vir-
tual server. The service type must be dns-udp, not dns. DNS caching per VIP is supported only on
dns-udp virtual ports. The command changes the CLI to the configuration level for the virtual
port. At this level, use the template dns command to bind the DNS template to the virtual port:
Make sure to also bind a UDP service group to the virtual port. The commands for real server and ser-
vice group configuration are the same as those for other types of virtual ports and are not covered in
this chapter.
Display DNS Caching Information

This section describes how to access DNS caching configuration information and statistics.
Using the CLI
To display DNS cache entries, use the show dns cache entry command:
To display the requested domain names and their IP addresses, as well as limit, rate, and lockout statis-
tics, use the show dns cache client command:
To display DNS caching statistics, use the show dns cache statistics command.
page 397
Authentication for DNS Requests

ACOS can authenticate DNS requests received over UDP by directing the client to re-send the DNS
request over TCP.
When authentication of DNS-over-UDP is enabled, ACOS drops DNS requests from the client if they are
sent over UDP and sends the client a DNS Truncate message. This action essentially informs the client
that it must re-send the DNS request over TCP in order to pass the DNS authentication.
DNS cache sharing for TCP and UDP
This feature gives the user the ability to cache TCP based DNS queries and is interchangeable with que-
ries made to UDP and TCP based VIPs. This feature has been implemented in tandem with caching so
that the initial request is not only redirected to TCP, but is then cached so that a second request is not
made to the DNS server.
Using the CLI
By default, DNS requests from clients are not authenticated. To enable ACOS to authenticate client
requests by directing the client to retry the connection over TCP (instead of UDP), use the redirect-to-
tcp-port command at the slb template dns config level.
By default, DNS cache sharing is disabled. To enable DNS Cache Sharing, use the enable-cache-shar-
ing command at the slb template dns config level:
Configuration Examples – DNS Optimization

The following subsections show how to configure the types of DNS caching policies listed at the begin-
ning of this section. Most of these examples use LIDs configured within the DNS template, instead of
GLIDs. For an example that uses a GLID, see “Rate-Based DNS Caching with Rate Limiting” on
page 401.
Control Caching on Per-VIP Basis

To implement this type of DNS caching policy:
• Configure a DNS caching policy in which the default action is to cache, and bind it to the DNS vir-
tual port for which you want to cache DNS replies.
• Configure another DNS caching policy, in which the default action is not to cache, and bind it to
the DNS virtual port for which you do not want to cache DNS replies.
In this example, default settings are used for all DNS caching parameters except the default cache
action.
The following commands configure the DNS caching templates:
page 398
ACOS(config)# slb template dns dns-enable-template

ACOS(config-dns)# default-policy cache
ACOS(config-dns)# exit
ACOS(config)# slb template dns dns-disable-template
ACOS(config-dns)# default-policy nocache
The following commands configure the real server and service group:
ACOS(config)# slb server dns-opt 10.10.10.88

ACOS(config)# slb service-group group53 udp
ACOS(config-slb svc group)# member dns-opt 53
The following commands bind the dns-enable-template to a VIP:
ACOS(config)# slb virtual-server vip-cache 192.168.10.10

ACOS(config-slb vserver)# port 53 dns-udp
ACOS(config-slb vserver-vport)# service-group group53
ACOS(config-slb vserver-vport)# template dns dns-enable-template
The following commands bind the dns-disable-template to a different VIP:
ACOS(config)# slb virtual-server vip-nocache 192.168.10.11

ACOS(config-slb vserver-vport)# template dns dns-disable-template
Since the default action is nocache, dns-disable-template is not needed for vip-nocache.
Control Caching on Per-Record Basis

• Create a class list that contains match rules for domain names to perform DNS caching. In this
example:
• Allow caching of all entries for “example.com”; for example, “mail.example.com”, “ftp.exam-
ple.com”, and so on.
page 399
• Deny caching of entries for “www.example.com”.

Associate each domain name string with an LID. In DNS templates, LIDs contain specific caching
policies.
• Configure a DNS template with default action nocache, add the class list to the template, and
configure these LIDs:
• LID 1 – DNS cache-enable
• LID 2 – DNS cache-disable
• Bind the DNS template to the DNS virtual port.
The following commands configure the class list:
ACOS(config)# class-list dns-record

ACOS(config-class list)# dns ends-with example.com lid 1
ACOS(config-class list)# dns contains www.example.com lid 2
The following commands configure the DNS template:
ACOS(config)# slb template dns dns-template

ACOS(config-dns)# class-list dns-record
ACOS(config-dns-class-list:dns-record)# lid 1
ACOS(config-dns-class-list:dns-record-li...)# dns cache-enable
ACOS(config-dns-class-list:dns-record-li...)# exit
ACOS(config-dns-class-list:dns-record-li...)# dns cache-disable
ACOS(config-dns-class-list:dns-record)# exit

The following commands bind the DNS template to the DNS virtual port:

page 400

ACOS(config-slb vserver-vport)# template dns dns-template
Rate-Based DNS Caching with Rate Limiting

• Create a class list that contains match rules for the domain names for which to perform DNS
caching. Associate the URL string with an LID.
• Configure a GLID that enables caching when a specified connection rate is reached.
• Configure a DNS template that specifies the default action (in this example, nocache).
Although this example uses a GLID, you can use a LID within the DNS template instead.

ACOS(config-class list)# dns contains .example2.com glid 1
The following commands configure the GLID:
ACOS(config)# glid 1
ACOS(config-global lid)# dns cache-disable
ACOS(config-global lid)# conn-rate-limit 1000 per 10
ACOS(config-global lid)# over-limit-action dns-cache-enable
ACOS(config-global lid)# exit


page 401


DNS Record Weighting for Selective Cache Entry Aging

• Create a class list that contains match rules for the domain names for which to perform DNS
caching. Associate each URL string with an LID.
• Configure a DNS template with default action nocache, add the class list to the template, and
configure these LIDs:
• LID 1 – DNS cache-enable, weight 1
• LID 2 – DNS cache-enable, weight 2

ACOS(config-class list)# dns contains example-corp1.com lid 1
ACOS(config-class list)# dns contains example-corp2.com lid 2

ACOS(config-dns-class-list:dns-record-li...)# dns weight 1
page 402
ACOS(config-dns-class-list:dns-record-li...)# dns weight 2



Throttling Based on Domain Name

• Create a class list that contains match rules for domain names to throttle. Associate each URL
string with an LID.
• Assign a very low connection or request rate (for example, 1).
• Optionally, enable lockout.
ACOS(config)# class-list dns-throttle-cl

ACOS(config-class list)# dns contains example.com lid 1
ACOS(config)# slb template dns dns-throttle

ACOS(config-dns)# class-list dns-throttle-cl
ACOS(config-dns-class-list:dns-throttle-cl)# lid 1
ACOS(config-dns-class-list:dns-throttle-c...)# conn-rate-limit 1 per 65535
page 403
ACOS(config-dns-class-list:dns-throttle-c...)# over-limit-action lockout 1023

ACOS(config-dns-class-list:dns-throttle-c...)# exit
ACOS(config-dns-class-list:dns-throttle-cl)# exit


ACOS(config-slb vserver-vport)# template dns dns-throttle
CLI Example – Logging

This example enables logging for DNS caching.

ACOS(config-dns)# dns-log-enable period 300
Logging for DNS caching will be enabled for each virtual DNS port that uses this template. Logs will be
generated every 5 minutes.
CLI Example – Show Commands

The following commands show DNS caching information.
ACOS# show dns cache entry

T = Type, C = Class, W = weight
Qlen = Query length, Rlen = Response length
Domain T C Qlen Rlen TTL Age W Hit
-----------------------------------+---+---+-----+-----+-------+-------+--+-------
ad.example.com 1 1 19 127 666 300 2 100
example.com 1 1 16 68 300 240 1 0
page 404
www.examplelive.com 1 1 24 142 666 360 2 257

.example2.com 1 1 16 89 666 420 2 0
example-corp1.com 1 1 21 74 666 420 2 11
example-corp2.com 1 1 17 104 666 420 2 12
Notes
• The T (Type) column lists the DNS record type. For a list, see the following: http://en.wikipe-
dia.org/wiki/List_of_DNS_record_types
• If logging is enabled, the Hit counter is reset after each log entry is created. (See “DNS Cache Log-
ging” on page 394 and “CLI Example – Logging” on page 404.)
• The counter in the Age column is always a multiple of 60. This is because the age is rounded up
to the next 60-second cache refresh interval. ACOS refreshes the cache every 60 seconds. An
entry that has aged out is removed at some point during the 60-second cache refresh.
ACOS# show dns cache client
Client class list statistics:
F = Flag (C-Connection, R-Request), Over-RL = Over rate limit
Domain Destination F Rate Over-RL lock lock-time
-------------------------+---------------------+-+---------+---------+----------+------
ad.example.com 192.22.35.90:53 C 0 0 0 0
example.com 192.22.35.90:53 C 0 0 0 0
www.examplelive.com 192.22.35.90:53 C 0 30 0 0
.example2.com 192.22.35.90:53 C 0 0 0 0
example-corp1.com 192.22.35.90:53 C 0 0 0 0
example-corp2.com 192.22.35.90:53 C 0 0 0 0
ACOS# show dns cache statistics

Total allocated: 266
Total freed: 96
Total query: 1720
Total server response: 485
Total cache hit: 1218
Query not passed: 0
Response not passed: 0
Response answer not passed: 0
Query encoded: 0
Response encoded: 0
Query with multiple questions: 0
Response with multiple questions: 0
Response with multiple answers: 0
Response with short TTL: 0
Total aged out: 97
Total aged for lower weight: 0
Total stats log sent: 69
page 405
Current allocate: 170

Current data allocate: 23
Authentication for DNS Requests (Example)

The following example creates the DNS template “temp_dns1” and applies it to two virtual ports so that
the enable-cache-sharing and/or redirect-to-tcp port options can take effect.
This example uses the following components without providing their configuration: wild (class list), sg-
dns (service group), and svg_v6_0 (service group).
ACOS(config)# slb template dns temp_dns1

ACOS(config-dns)# max-cache-size 60000
ACOS(config-dns)# max-cache-entry-size 4096
ACOS(config-dns)# dns-log-enable period 1
ACOS(config-dns)# enable-cache-sharing
ACOS(config-dns)# class-list wild
ACOS(config-dns-class-list:wild)# lid 1
ACOS(config-dns-class-list:wild-lid:1)# dns cache-enable
ACOS(config-dns-class-list:wild-lid:1)# dns weight 7
ACOS(config-dns-class-list:wild-lid:1)# dns ttl 65535
ACOS(config-dns-class-list:wild-lid:1)# exit
ACOS(config-dns-class-list:wild)# exit
ACOS(config-slb vserver-vport)# service-group sg-dns
ACOS(config-slb vserver-vport)# template dns temp_dns1
ACOS(config-slb vserver)# port 53 dns-tcp
ACOS(config-slb vserver-vport)# service-group svg_v6_0
ACOS(config-slb vserver-vport)# service-group sg-dns
ACOS(config-slb vserver)# port 5353 dns-tcp
ACOS(config-slb vserver-vport)# service-group svg_v6_0
page 406
In the example above, the DNS template “temp_dns1” is applied to two virtual ports, port 53 and port
5353. With the enable-cache-sharing command enabled, those ports will share the DNS cache, which
will save memory costs.
The following example shows you how to disable cache sharing in your configured DNS template:
ACOS(config)# slb template dns temp_dns1

ACOS(config-dns)# no enable-cache-sharing
page 407
Load Balancing with the “DNSSEC OK” (DO) Bit

This feature enables the ACOS device to load balance DNS requests from clients supporting DNS Secu-
rity Extensions (DNSSEC) to servers supporting the same (Figure 52). This feature is also supported
using aFleX scripts (DNS::header).
FIGURE 52 Load Balancing with the “DNSSEC OK” (DO) Bit
The ACOS device checks the header of the UDP or TCP packet for an OPT field, and checks the OPT
field for the “DNSSEC OK” or DO bit. If not found, the DNS request is load-balanced to a service group
for DNS servers not supporting DNSSEC. If found, the request is sent to a service group for servers pro-
viding DNSSEC support.
This configuration implements the topology in Figure 52. This example uses UDP, but TCP can also be
used.
1. Configure the SG-DNSSEC service group for servers supporting DNSSEC:

ACOS(config)$ slb server RS1 10.0.0.1
ACOS(config-real server)$ exit
ACOS(config)$ slb service-group SG-DNSSEC udp
ACOS(config-slb svc group)$ member RS1 53001
ACOS(config-slb svc group-member:53001)$ exit
page 408
2. Configure the SG-NON-DNSSEC service group for servers not supporting DNSSEC:
ACOS(config)$ slb service-group SG-NON-DNSSEC udp
ACOS(config-slb svc group)$ exit
3. Create the DNS SLB template TMP-DNSSEC and apply it to the SG-DNSSEC service group.
ACOS(config)$ slb template dns TMP-DNSSEC
ACOS(config-dns)$ dnssec-service-group SG-DNSSEC
ACOS(config-dns)$ exit
4. Configure the virtual server and port on the ACOS device, and associate them with the proper ser-
vice group and template.
ACOS(config)$ slb virtual-server VS-DNS 10.10.10.10
ACOS(config-slb vserver)$ port 53 dns-udp
ACOS(config-slb vserver-vport)$ service-group SG-NON-DNSSEC
ACOS(config-slb vserver-vport)$ template dns TMP-DNSSEC
ACOS(config-slb vserver-vport)$ exit
ACOS(config-slb vserver)$ exit
5. View the new Layer 4 statistics counter related to this feature:

ACOS(config)$ show slb l4
The “DNSSEC switch” field displays the number of DNSSEC packets switch to the service group
supporting DNSSEC.
page 409
page 410
RAM Caching
This chapter describes usage of an ACOS device as a transparent cache server. These topics are cov-
ered:
• Overview of RAM Caching
• Cacheability Behavior of ACOS RAM Cache
• Dynamic Caching
• Host Verification
• Configuring RAM Caching
Overview of RAM Caching

The RAM Cache is a high-performance, in-memory Web cache that by default caches HTTP responses
(RFC 2616 compliant). The RAM Cache can store a variety of static and dynamic content and serve this
content instantly and efficiently to a large number of users.
Caching HTTP content reduces Web server transactions and hence the server loads. Caching dynamic
content reduces latency and computation cost of generating dynamic pages by application servers
and database servers. Caching also reduces page download time and bandwidth utilization.
RAM caching is useful for high-demand objects on a website, for static content such as images, and
when used in conjunction with compression to store compressed responses, eliminating unnecessary
overhead.
RFC 2616 Support

In general, ACOS RAM caching conforms with the cache requirements described in RFC 2616, “Hyper-
text Transfer Protocol -- HTTP/1.1”, in sections 13 and 14.
ACOS RAM caching considers HTTP responses with the following status codes to be cacheable:
• 200 – OK
• 203 – Non-Authoritative Response
• 300 – Multiple Choices
page 411
Overview of RAM Caching
• 301 – Moved Permanently
• 302 – Found (only if Expires header is also present)
• 410 – Gone
However, if there is no Content-Length header, the response will not be cached.
Warning headers are not supported.
If-Modified-Since Header Support

ACOS supports If-Modified-Since (IMS) headers in GET requests from clients.
Optionally, a client can include the following header in a GET request:
If-Modified-Since: date-time
This header instructs the content server (or cache server) to send the requested page only if the page
has been modified subsequent to the date and time specified in the IMS header.
ACOS 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 ACOS 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 ACOS 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 ACOS device
deletes the IMS header from the request. This forces the server to send a 200 OK response,
which is then immediately cached.
Support for no-cache and max-age=0 Cache-Control Headers

According to RFC 2616, either of the following Cache-Control headers in a request should make the
cache (the ACOS device) reload the cached object from the origin server:
• Cache-Control: no-cache
• Cache-Control: max-age=0
However, for security, support for these headers is disabled by default. These headers can make the
ACOS device vulnerable to Denial of Service (DoS) attacks.
To enforce strict RFC compliance, you can enable support for the headers.
page 412
Cacheability Behavior of ACOS RAM Cache
Insertion of Age and Via Headers into Cached Responses

RAM caching supports Age and Via header insertion into cached server replies before they are sent to
clients.
• Age header – indicates the age of the cached response, measured in seconds
• Via header – indicates the ACOS software version, in the following format:
ACOS-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: ACOS-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: ACOS-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 ACOS RAM Cache

This section summarizes the behavior of ACOS RAM caching when this feature is enabled:
When Processing the Request:
• If a cache policy is configured, ACOS checks if the URI in the request matches any of the URIs
configured for the cache policy. If there is a match, the configured action (invalidate, cache,
nocache) is remembered for that request.
• If there is no URI match, ACOS checks to see if default-policy-nocache is configured; if it is con-

figured, the request is marked as not cacheable.
When Processing the Response to a Request Received from the Server:
• ACOS checks to see if response should be cached based on request processing results.
• If the response is cacheable, ACOS ignore the Cache-Control from server response.
In summary, the server’s cache-control header in the HTTP response can override the cache policy. The
default-policy-nocache only applies when there is a cache policy configured but there is no URI
match.
page 413
Dynamic Caching
Some additional implementation details are provided below:
• A response for a request that uses any method other than GET is not cached.
• A response for a GET request that contains a body is not cached.
• A request that contains an Authorization or a Proxy-Authorization header is not cacheable. The

authorization header contains security-related information and should not be cached.
• A response for a request that contains an If-Match header or an If-Unmodified-Since header is
not cached.
• An HTTP response which has a Vary header with a value of anything other than Accept-Encoding
is not cached. (The compression module inserts the Vary: Accept-Encoding header.)
• A response with a Cache-Control header with 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-Reval-
idate, max-Age, S-maxage it is cached.
• Responses that contain a Pragma header are not cached.
• Responses that contain a Set-Cookie or a Set-Cookie2 header are not cached. (Responses with
Cookie headers often contain information that is specific to the user and so should not be
cached.)
• If the response type is FIN terminated, or the response does not have one of the following attri-
butes: Content-Length, or Transfer-Encoding: Chunked, it is not cached.
ACOS 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
ACOS device to remove cookies from server replies, so that the replies can be cached.
Image files are an exception; RAM caching can cache images that have cookies.
Dynamic Caching
You can enhance RAM caching performance with dynamic RAM caching. Dynamic RAM caching is
useful in situations where the response to a client request can be used multiple times before the
response expires. Here are some examples where dynamic RAM caching is beneficial:
• The same response is usable by multiple users within a certain period of time. In this case,
dynamic RAM caching is useful even if the cache expiration period is very small, if enough users
access the response within that period. For example, dynamic RAM caching is beneficial for a
hierarchical directory that is generated dynamically but presents the same view to all users that
request it.
page 414
Host Verification
• The response is usable by only a single user but the user accesses it multiple times. For example,
if the response generated in one session can be used unchanged in a second session.
Host Verification
RAM caching has an optional host verification feature. Host verification supports multiple name-based
virtual hosts. Name-based virtual hosts are host names that share the same IP address. For example,
the real server IP address 192.168.209.34 could be shared by the following virtual hosts:
• www.abc.com
• www.xyz.com
By default, host verification is disabled. When the ACOS device receives the server response for cache-
able content, the ACOS device caches the content along with the URI, but not the host name. For exam-
ple, if a client requests http://www.abc.com/index.html, the ACOS 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 ACOS device serves the same content.
If you enable host verification, the ACOS device caches the host name along with the URI. For example,
for http://www.abc.com/index.html, the ACOS device caches the content, “/index.html”, and “abc.com”.
If a new request is received, for http://www.xyz.com/index.html, the ACOS device checks the cache for
content indexed by both “/index.html” and “xyz.com”. ACOS 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.
CLI Configuration Examples

The following examples are provided:
page 415
• Basic Configuration
• Dynamic Caching Configuration
• Configuration To Flush Specific Cache Entries
Basic Configuration
The commands in this example enable RAM caching for virtual service port TCP 80 on VIP “cached-
vip”.
These commands add a RAM caching template using default template settings.
ACOS(config)# slb template cache ramcache

ACOS(config-ram caching)# exit
The following commands configure the real servers.

The following commands configure the service group.
ACOS(config)# slb service-group cached-group tcp

The following commands configure the virtual server and bind the RAM caching template and the ser-
vice group to virtual HTTP service port 80.
ACOS(config)# slb virtual-server cached-vip 10.10.10.101
page 416

ACOS(config-slb vserver-vport)# service-group cached-group
ACOS(config-slb vserver-vport)# template cache ramcache
The following command shows client sessions. Asterisks ( * ) in the Reverse Source and Reverse Dest
fields indicate that the ACOS device directly served the requested content to the client from the ACOS
RAM cache. In this case, the session is actually between the client and the ACOS device rather than the
real server.
ACOS(config)# show session

Traffic Type Total
--------------------------------------------
TCP Established 4328
TCP Half Open 39026
UDP 0
Non TCP/UDP IP sessions 0
Other 0
Reverse NAT TCP 0
Reverse NAT UDP 0
Free Buff Count 0
Curr Free Conn 1923655
Conn Count 5287134
Conn Freed 5113720
tcp syn half open 0
Prot Forward Source Forward Dest Reverse Source Reverse Dest Age
---------------------------------------------------------------------------------------
Tcp 10.10.10.61:25058 10.10.10.10:80 * * 600
Tcp 10.10.10.60:9239 10.10.10.11:80 * * 600
Tcp 10.10.10.61:1838 10.10.10.10:80 * * 600
Tcp 10.10.10.65:47834 10.10.10.11:80 * * 600
Tcp 10.10.10.62:55613 10.10.10.11:80 * * 600
Tcp 10.10.10.57:9233 10.10.10.11:80 * * 600
The following command shows RAM caching statistics.
ACOS(config)# show slb cache
Total
---------------------------------------------------------------
Cache Hits 0
Cache Misses 6
Memory Used 27648
Bytes Served 0
page 417
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
The following command shows cached objects.
ACOS# 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 informa-
tion, see the Command Line Interface Reference.
page 418
Dynamic Caching Configuration

Here is an example application of dynamic RAM caching. Web site x.y.com displays a frequently
requested list page and serves private pages to individual clients based on additional requests from cli-
ents. Clients also can add or delete content on the list page.
http://x.y.com/list
http://x.y.com/private?user=u1
http://x.y.com/add?a=p1&b=p2
http://x.y.com/del?c=p3
Dynamic RAM caching policies can be used to effectively manage caching for this site.
The /list URI is visited by many users and therefore should be cached, so long as the content is current.
However, the /private URI contain private data for a specific user, and should not be cached.
The /add and /del URLs modify the content of the list page. When either type of URI is observed by the
ACOS 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.
ACOS(config)# slb template cache ram-cache

ACOS(config-ram caching)# policy uri /list cache 3000
ACOS(config-ram caching)# policy uri /private nocache
ACOS(config-ram caching)# policy uri /add invalidate /list
ACOS(config-ram caching)# policy uri /del invalidate /list
ACOS(config)# exit
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” con-
tent.
Configuration To Flush Specific Cache Entries

To flush specific entries from the RAM cache, use an invalidate policy as shown by this example:
ACOS(config)# slb template cache ram-cache

ACOS(config-ram caching)# policy uri /story cache 3600
ACOS(config-ram caching)# 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”.
page 419
page 420
Transparent Cache Switching
This chapter contains the following topics:
• Overview
• Configuring Layer 4 TCS
• Configuring Layer 7 TCS
• Configuring IPv4 TCS in VRRP-A High Availability Layer 3 Inline Mode
• Configuring IPv6 TCS in VRRP-A Layer 3 Inline Mode
• Configuring TCS for FTP
• Configuring Bandwidth Limits Per Server or Port
page 421
Overview
Overview
ACOS supports Transparent Cache Switching (TCS). TCS enables you to improve server response
times by redirecting client requests for content to cache servers containing the content. Figure 53
shows an example topology.
FIGURE 53 Transparent Cache Switching
In this example, a client sends a request for content that is hosted by the content server. ACOS redi-
rects the client’s request to the cache server. If the cache server has the requested content, the cache
server sends the content to the ACOS 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 ACOS device, which sends the content to the client.
page 422
Overview
Granularity of TCS
You can configure Layer 4 TCS or Layer 7 TCS.
• Layer 4 TCS – Sends all TCP or UDP traffic addressed to the content server to the cache server
instead
• Layer 7 TCS – You can configure Layer 7 TCS with either of the following 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; sends other requests to the con-
tent server
Optimizing When Using Multiple Cache Servers

If your network uses multiple cache servers, you can configure destination-IP persistence, to always
select the same cache server for content from a given destination IP address. This technique reduces
cache misses, by ensuring that requests for a given site IP address always go to the same cache
server.
For even greater control, you can configure the ACOS device to select from among multiple cache ser-
vice 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 ACOS 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 switching rule, the ACOS 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 Layer 7 TCS configurations using URL switching, a separate real server is required for the gate-
way router, and the real server must be placed in its own service group. The gateway router’s ser-
vice group is 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.
page 423
Configuring Layer 4 TCS
• 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. ACOS 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 subse-
quent 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 per-
sistence 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 ACOS device itself, you can use a
RAM caching template. In this case, the ACOS device directly serves content that is cached on
the ACOS device, and only sends requests to the cache server for content that is not cached on
the ACOS device.
• Connection reuse template – You can use a connection reuse template to reuse TCP connec-
tions. When a client’s session ends, the TCP connection is not terminated. Instead, the connec-
tion is reused for a new client session.
Support for Spoofing Caches

Some cache servers can use the client’s IP address instead of the cache server’s IP address as the
source address when obtaining content requested by the client. A cache server operating in this mode
is a spoofing cache server. Configuration for a spoofing cache server includes a couple of additional
steps. (See “Enabling Support for Cache Spoofing” on page 434.)
High Availability Support

You can deploy TCS in VRRP-A high availability configurations. For an example of TCS deployed in
Layer 3 inline mode of HA, see “Configuring IPv4 TCS in VRRP-A High Availability Layer 3 Inline Mode”
on page 435.

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 ACOS interface(s) connected to the clients.
2. Configure an extended ACL that uses the permit action and that matches on client addresses as
the source address, and on the content server address as the destination address.
3. Configure a real server for the cache server. Add the TCP or UDP port; for example, TCP port 80.
page 424
If the cache server spoofs client IP addresses when requesting content from content servers,
enable cache spoofing support.
4. Configure a service group for the cache server and add the cache server to it.
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 spoofs client IP addresses when requesting content from content servers,
enable cache spoofing on the ACOS interface connected to the cache server and on the real
(cache) server.
page 425
CLI Example
The commands in this section implement the TCS configuration shown in Figure 54.
FIGURE 54 Layer 4 TCS
These commands configure the ACOS interface to the client. Promiscuous VIP is enabled on the inter-
face.
ACOS(config-if:ve:4)# ip address 192.168.19.1 255.255.255.0
ACOS(config-if:ve:4)# ip allow-promiscuous-vip
The following commands configure the ACOS interface to the content server.
page 426

ACOS(config-if:ve:2)# ip address 10.10.10.1 255.255.0.0
The following commands configure the interface to the cache server:

This command configures an extended ACL to match clients and 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.
ACOS(config)# access-list 198 permit ip any host 20.20.20.10 log
The following commands configure a real server for the cache server. TCP port 80 is added to the real
server.
ACOS(config)# slb server cache-rs 110.110.110.10

The following commands configures a service group for the cache server:
ACOS(config)# slb service-group sg-tcs tcp

ACOS(config-slb svc group)# member cache-rs 80
The following commands configure a wildcard VIP and bind it to the ACL:
ACOS(config)# slb virtual-server wildcard 0.0.0.0 acl 198

ACOS(config-slb vserver-vport)# service-group sg-tcs
page 427

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 redirects all HTTP traffic to the
cache server. The configuration steps are very similar to those for Layer 4 TCS. The only differ-
ence is use of HTTP instead of TCP or UDP as the service type of the virtual port.
• Service type HTTP with URL switching rules – This method uses an HTTP template containing
URL switching rules. Traffic that matches a URL switching rule is redirected to the cache server.
Other traffic is sent to the gateway router.
This method requires configuration of a separate real server and service group for the gateway
router.
Figure 55 on page 429 shows an example of the first method, which does not use URL switching rules.
Figure 56 on page 430 shows an example of the second method, which does use URL switching rules.
page 428
FIGURE 55 Layer 7 TCS Without URL Switching Rules
page 429
FIGURE 56 Layer 7 TCS Using URL Switching Rules
Service Type HTTP Without URL Switching Rules

To configure this type of Layer 7 TCS:
3. Configure a real server for the cache server. Add the TCP port; for example, TCP port 80.
the ACL.
page 430
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 55 on page 429. 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.

ACOS(config-slb vserver-vport)# service-group sg-tcs
Service Type HTTP with URL Switching Rules

To configure this type of Layer 7 TCS:
3. Configure a real server for the cache server. Add the TCP or UDP port; for example, TCP port 80.
4. Configure a real server for the next-hop router through which the ACOS device will reach the con-
tent servers. Add the same TCP port number as the one on the cache server (for example, TCP port
80). Disable health checking on the port.
The configuration requires health checking to be disabled on the router port. The router will not
respond to the health check. If you leave health checking enabled, the ACOS device will mark the
port down and TCS will not work.
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.
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.
page 431
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 56 on page 430. The
commands for configuring the interfaces and ACL, and the real server and service group for the cache
server, are the same as those used in the Layer 4 TCS example, and are therefore not shown.
The following commands configure a real server for the gateway router:
ACOS(config)# slb server router 10.10.10.20

The following commands configure a service group for the router:
ACOS(config)# slb service-group sg-router tcp

ACOS(config-slb svc group)# member router 80
The following commands configure an HTTP template containing URL switching rules. Client requests
for any URL that contains “.examplecorp/” or “.mycorp/” will be redirected to the service group for the
cache server. Requests for any other URL will instead be sent to the service group for the router.
ACOS(config)# slb template http http1

ACOS(config-HTTP template)# url-switching contains .examplecorp/ service-group sg-tcs
ACOS(config-HTTP template)# url-switching contains .mycorp/ service-group sg-tcs

ACOS(config-slb vserver-vport)# service-group sg-router
ACOS(config-slb vserver-vport)# template http http1
page 432
Optimizing TCS with Multiple Cache Servers

To optimize TCS in deployments that use multiple cache servers, use a destination-IP persistence tem-
plate.
Commands in this section implement the TCS configuration shown in Figure 57. Only commands spe-
cific to destination-IP persistence are shown. The other commands are the same as those in the previ-
ous sections.
FIGURE 57 TCS with Multiple Cache Servers
The following commands configure the destination-IP persistence template:
ACOS(config)# slb template persist destination-ip d-sticky

ACOS(config-dest ip persistence template)# match-type service-group
ACOS(config-dest ip persistence template)# exit
page 433
The match-type service-group command is required to enable URL switching and persistence in the
same configuration.
The following commands configure the VIP. The commands are the same as those used for Layer 7
TCS, with the addition of a command to bind the destination-IP persistence template to the virtual port.

ACOS(config-slb vserver-vport)# template http http1
ACOS(config-slb vserver-vport)# service-group sg-router
ACOS(config-slb vserver-vport)# template persist destination-ip d-sticky
Enabling Support for Cache Spoofing

If the cache server spoofs client IP addresses when requesting content from servers, the following
additional configuration is required:
1. Enable cache spoofing support on the ACOS interface connected to the spoofing cache server.
Use the ip cache-spoofing-port command at the interface configuration level.
2. In the real server configuration for the cache server, enable spoof caching support. Use the spoof-
ing-cache command at the real server configuration level.
The commands in this section enable cache spoofing support for the TCS configuration shown in
Figure 57.

ACOS(config-if:ethernet:5)# ip cache-spoofing-port
ACOS(config)# slb server cache-rs 110.110.110.10
ACOS(config-real server)# spoofing-cache
page 434
Configuring IPv4 TCS in VRRP-A High Availability Layer 3 Inline Mode
Configuring IPv4 TCS in VRRP-A High Availability Layer 3

Inline Mode
You can use VRRP-A high availability to provide redundancy and failover for TCS. This section shows
an example for IPv4 Layer 3 inline mode VRRP-A high availability. Layer 3 high availability for inline
mode is beneficial in network topologies where the ACOS interfaces with the clients and cache servers
are in the same subnet. Figure 58 shows an example.
FIGURE 58 TCS in VRRP-A high availability Layer 3 Inline Mode
page 435
Interface Parameters
In this configuration, each ACOS device connects to the client, cache servers, and content server on a
single IP interface:
• ACOS-1 – Connected on IP interface 10.10.10.1, which is assigned to VE 1 on VLAN 1 containing

Ethernet data ports 3-11
• ACOS-2 – Connected on IP interface 10.10.10.2, which is assigned to VE 1 on VLAN 1 containing
Ethernet data ports 3-11
The following interface parameters are required:
• Promiscuous VIP – Must be enabled on the interface connected to clients and the IP interface
assigned to the VE on the VLAN containing the interfaces to the clients, content servers, and
cache servers.
• Cache spoofing – If the cache server will spoof client IP addresses when requesting content
from content servers, enable cache spoofing support on the ACOS interface connected to the
cache server.
VRRP-A High Availability Parameters
This configuration uses the following VRRP-A high availability parameters. The last two in this list apply
specifically to inline mode. The other parameters apply to all types of VRRP-A configurations.
• Device ID – ACOS-1 uses Device ID 1. ACOS-2 uses Device ID 2.
• VRID and priority – A single VRID is configured, with a higher priority on ACOS-1.
• Pre-emption – Pre-emption is enabled, to force initial failover to the ACOS device with the higher
priority.
• VRRP-A interfaces – Ethernet interfaces 1, 3, and 6 are configured as VRRP-A interfaces. Inter-
faces 1 and 3 are the lead interfaces in trunks, so all the interfaces in these trunks are VRRP-A
interfaces.
• Session synchronization (connection mirroring) – Each ACOS device is enabled, when in Active
role, to synchronize its sessions onto the other ACOS device.
• Floating IP address – Both ACOS devices share floating IP address 10.10.10.250 for the VRID.
• L3-inline mode – This must be enabled on each ACOS device.
• Restart port list – Interfaces 1 to 5 and interface 9 are designated as inline-mode restart ports.
This includes the ACOS interfaces with the client, cache servers, and content server. Interface 6
is the dedicated HA link between the ACOS devices and is not included in the restart list.
SLB Parameters
Real server parameters:
page 436
• Port type – A Layer 4 port type, such as TCP, should be used. HA session synchronization is sup-
ported only for Layer 4 sessions.
• Cache spoofing – If the cache server will spoof client IP addresses when requesting content
from content servers, enable cache spoofing support on the real server configuration for the
cache server.
Service group parameters:
• Type – Typically, the type should be TCP.
• Members – Add the real servers configured for the cache servers.
In a Layer 7 TCS configuration that uses URL switching, a separate real server is required for the gate-
way router, and the real server is required to be placed in its own service group. (See “Configuring Layer
7 TCS” on page 428.) The example in Figure 58 on page 435 does not use Layer 7 switching.
Virtual server parameters:
• VIP – The VIP address must be 0.0.0.0 (a wildcard VIP). The ACL associated with the VIP must
be an extended ACL that uses the permit action and that matches on client addresses as the
source address, and on the content server address as the destination address:
• Service type – The service type of the TCS virtual port must be a Layer 4 service type (TCP).
• VRID – Add the virtual server to the VRID.
• Destination NAT – Destination NAT must be disabled.
• Session synchronization – Enable this feature so that customer sessions are synchronized from
the Active ACOS device to the standby ACOS device.
NOTE: If spoof-caching is enabled, the ACOS device creates a transparent ses-

sion 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.
NOTE: Client sessions will be reset if a failover occurs. In most cases, the reset
will not be noticeable. However, if a client is downloading a large file, the
reset may be noticeable, because the download progress is not retained
after the session is reset.
Templates
For simplicity, the sample configuration in this section does not use any custom templates. For infor-
mation about the templates that can be used with TCS, see “Application Templates” on page 423.
The following CLI examples show how to implement the configuration shown in Figure 58 on page 435.
page 437
ACOS-1 Configuration
The following commands configure the links:
ACOS-1(config)# interface ethernet 1

ACOS-1(config-if:ethernet:1)# enable
ACOS-1(config-if:ethernet:1)# trunk-group 1
ACOS-1(config-if:ethernet:1-trunk-group:1)# exit
ACOS-1(config-if:ethernet:1)# exit
ACOS-1(config-if:ethernet:3)# ip allow-promiscuous-vip
ACOS-1(config)# vlan 11
ACOS-1(config-vlan:11)# untagged trunk 3
ACOS-1(config-vlan:11)# tagged trunk 1
ACOS-1(config-vlan:11)# router-interface ve 11
ACOS-1(config-vlan:11)# exit
ACOS-1(config-if:ethernet:5)# ip cache-spoofing-port
ACOS-1(config)# interface ve 11
ACOS-1(config-if:ve11)# ip address 10.10.10.1 255.255.255.0
ACOS-1(config-if:ve11)# ip allow-promiscuous-vip
ACOS-1(config-if:ve11)# exit
page 438
The following commands configure static routes. One of the routes goes to the subnet on the other
side of the router that connects the ACOS device to the content servers. The other static route goes to
the subnet on the other side of the router that connects the ACOS device to the client.
ACOS-1(config)# ip route 20.20.20.0 /24 10.10.10.20

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:
ACOS-1(config)# access-list 198 permit ip any host 20.20.20.11 log
The following commands configure the global VRRP-A parameters:
ACOS-1(config)# vrrp-a common

ACOS-1(config-common)# device-id 1
ACOS-1(config-common)# set-id 1
ACOS-1(config-common)# enable
ACOS-1(config-common)# disable-default-vrid
ACOS-1(config-common)# exit
ACOS-1(config)# vrrp-a l3-inline-mode
ACOS-1(config)# vrrp-a vrid 1
ACOS-1(config-vrid:1)# floating-ip 10.10.10.250
ACOS-1(config-vrid:1)# blade-parameters
ACOS-1(config-vrid:1-blade-parameters)# priority 200
ACOS-1(config-vrid:1-blade-parameters)# exit
ACOS-1(config-vrid:1)# exit
ACOS-1(config)# vrrp-a interface ethernet 6
ACOS-1(config-ethernet:6)# vlan 11
ACOS-1(config-ethernet:6)# exit
ACOS-1(config)# vrrp-a restart-port-list
ACOS-1(config-restart-port-list)# ethernet 1 to 5
ACOS-1(config-restart-port-list)# ethernet 9
ACOS-1(config-restart-port-list)# exit
The following commands configure real servers for the cache servers:
ACOS-1(config)# slb server cache1 10.10.10.10

ACOS-1(config-real server)# spoofing-cache
ACOS-1(config-real server)# port 80 tcp
ACOS-1(config-real server-node port)# exit
ACOS-1(config-real server)# exit
page 439
The following commands configure a service group for the real servers:
ACOS-1(config)# slb service-group sg-cache-80 tcp

ACOS-1(config-slb svc group)# member cache1 80
ACOS-1(config-slb svc group-member:80)# exit
ACOS-1(config)# slb virtual-server wildcard 0.0.0.0 acl 198

ACOS-1(config-slb vserver)# vrid 1
ACOS-1(config-slb vserver)# port 80 tcp
ACOS-1(config-slb vserver-vport)# service-group sg-cache-80
ACOS-1(config-slb vserver-vport)# no-dest-nat
ACOS-1(config-slb vserver-vport)# ha-conn-mirror
ACOS-1(config-slb vserver-vport)# exit
ACOS-1(config-slb vserver)# exit
The commands on ACOS-2 are the same as the ones on ACOS-1, with the following exceptions:
• The ip address command on the VE adds a unique IP address (not the address of the other
ACOS device).
• The vrid command assigns VIRD 2 instead of VRID 1.
• The priority command assigns a lower priority to the group.

page 440
ACOS-2(config-if:ethernet:3)# ip allow-promiscuous-vip
ACOS-2(config-vlan:11)# untagged ethernet 3 to 6
ACOS-2(config-vlan:11)# tagged ethernet 1 to 2
ACOS-2(config)# access-list 198 permit ip any host 20.20.20.11 log
ACOS-2(config-vrid:1)# floating-ip 10.10.10.250
ACOS-2(config-ethernet:6)# vlan 11
ACOS-2(config-restart-port-list)# ethernet 1 to 5
page 441
ACOS-2(config)# slb service-group sg-cache-80 tcp
ACOS-2(config-slb svc group)# exit
ACOS-2(config)# slb virtual-server wildcard 0.0.0.0 acl 198
ACOS-2(config-slb vserver-vport)# service-group sg-cache-80
page 442
Configuring IPv6 TCS in VRRP-A Layer 3 Inline Mode

Figure 59 shows an example of a TCS deployment in VRRP-A Layer 3 Inline mode.
FIGURE 59 TCS – VRRP-A 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.
page 443
The following commands configure the links.

ACOS-1(config-vlan:21)# untagged ethernet 1
ACOS-1(config-if:ve21)# ipv6 address 2309:e90::2/64
ACOS-1(config-if:ve22)# ipv6 address 2409:c90::1/64
These commands configure static routes. One of the routes goes to the subnet on the other side of the
router that connects the ACOS device to the content servers. The other static route goes to the subnet
page 444
on the other side of the router that connects the ACOS device to the client. CPU processing is also
enabled on the routes.
ACOS-1(config)# ipv6 route 2309:d90::/32 2309:e90::1

ACOS-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:
ACOS-1(config)# ipv6 access-list ipv6-101

ACOS-1(config-access-list:ipv6-101)# permit ipv6 any host 2309:f90::10 log
ACOS-1(config-access-list:ipv6-101)# exit
The following commands configure the VRRP-A parameters:

ACOS-1(config-vrid:1)# floating-ip 2409:c90::100
ACOS-1(config-vrid:1)# floating-ip 2309:e90::100
ACOS-1(config-ethernet:1)# server-interface
ACOS-1(config-ethernet:1)# no-heartbeat
ACOS-1(config-ethernet:1)# router-interface
The following commands configure a custom ICMP health monitor with very short interval and timeout
values. In Layer 3 inline VRRP-A configurations, the short interval and timeout values help eliminate
traffic disruption following a failover.
ACOS-1(config)# health monitor icmp
page 445
ACOS-1(config-health:monitor)# interval 1 timeout 1

ACOS-1(config-health:monitor)# exit
The following commands configure ICMP health checking for the upstream and downstream routers.
The health checks help ensure rapid VRRP-A failover. (See the Configuring VRRP-A High Availability
guide.) The custom ICMP health monitor configured above is also used.
ACOS-1(config)# slb server up-router 2309:e90::1

ACOS-1(config-real server)# health-check icmp
ACOS-1(config)# slb server down-router 2309:e90::3
The following commands configure real servers for the cache servers:
ACOS-1(config)# slb server cache1-ipv6 2409:c90::5

The following commands configure a service group for the real servers (cache servers):
ACOS-1(config)# slb service-group cache-ipv6 tcp

ACOS-1(config-slb svc group)# member cache1-ipv6 80
ACOS-1(config-slb svc group-member:80)# member cache2-ipv6 80
ACOS-1(config-slb svc group)# exit
ACOS-1(config)# slb virtual-server wildcard-ipv6 :: ipv6-acl ipv6-101

ACOS-1(config-slb vserver-vport)# service-group cache-ipv6
ACOS-1(config-slb vserver-vport)# exit
ACOS-1(config-slb vserver)# exit
page 446
Here are the configuration commands for ACOS-2. Most of the commands are exactly the same as on
ACOS-1. Only the following values differ:
• IP addresses of the VEs
• VRID priority
• IP address for session synchronization (ha conn-mirror)

ACOS-2(config-if:ve21)# ipv6 address 2309:e90::3/64
page 447

ACOS-2(config)# ipv6 route 2309:d90::/32 2309:e90::1
ACOS-2(config)# ipv6 route 2309:f90::/32 2309:e90::3
ACOS-2(config)# ipv6 access-list ipv6-101
ACOS-2(config-access-list:ipv6-101)# permit ipv6 any host 2309:f90::10 log
ACOS-2(config-access-list:ipv6-101)# exit
ACOS-2(config-vrid:1)# floating-ip 2409:c90::100
ACOS-2(config-vrid:1)# floating-ip 2309:e90::100
ACOS-2(config-ethernet:1)# server-interface
ACOS-2(config-ethernet:1)# router-interface
ACOS-2(config)# health monitor icmp
ACOS-2(config-health:monitor)# interval 1 timeout 1
ACOS-2(config-health:monitor)# exit
ACOS-2(config)# health monitor icmp interval 1 timeout 1
ACOS-2(config)# slb server up-router 2309:e90::1
ACOS-2(config)# slb server down-router 2309:e90::3
page 448

ACOS-2(config)# slb service-group cache-ipv6 tcp
ACOS-2(config-slb svc group)# member cache1-ipv6 80
ACOS-2(config-slb svc group-member:80)# member cache2-ipv6 80
ACOS-2(config)# slb virtual-server wildcard-ipv6 :: ipv6-acl ipv6-101
ACOS-2(config-slb vserver-vport)# service-group cache-ipv6
page 449
Configuring TCS for FTP

You can configure the ACOS device to use cache servers for FTP traffic. Figure 60 shows an example.
FIGURE 60 Transparent Cache Switching for FTP
When a client sends a request to the FTP server, the ACOS device intercepts the request and forwards
it to the FTP cache server. The cache server then forwards the requested content to the ACOS device, if
the content is cached. ACOS forwards the content to the client.
If the requested content is not already cached, the cache server obtains the content from the FTP
server and caches it. ACOS 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 ACOS device. The other interface communicates with the FTP server, and
forwards cached content to the ACOS device. Only the interfaces that receive client requests from the
ACOS device need to be configured as real servers.
page 450
NOTE: In this example, the content transferred by FTP is cached on the cache
servers. However, this feature also can be used if the device is a firewall
instead of an FTP cache server. In that case, the firewall is used to exam-
ine the traffic that is transferred to or from the FTP server by the client.
Configuration
To configure TCS for FTP:
• Enable promiscuous VIP on the ACOS interface(s) connected to the clients.
• Enable cache spoofing on the interface(s) connected to the cache server.
3. Configure a real server for the cache server. Add an FTP port to the server.
If the cache server will spoof client IP addresses when requesting content from content servers,
enable cache spoofing support.
If the cache server has multiple interfaces, configure a separate real server for each one.
4. Configure a real server for the next-hop router through which the ACOS device will reach the con-
tent servers. Add the same FTP port number as the one on the cache server (for example, port 21).
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 ACOS 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.
the ACL.
Add an FTP virtual port and bind it to the service group containing the cache server, and to the ser-
vice group containing the router. Disable destination NAT on the virtual port.
CLI Example
These commands configure the ACOS interfaces to the FTP server, the FTP client, and the cache serv-
ers.

page 451
This command configures an extended ACL to match clients and 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.
ACOS(config)# access-list 198 permit ip any host 20.20.20.11 log
The following commands configure real servers for FTP on each of the cache servers. Cache spoofing
is enabled and TCP port 21 is added to each real server.
ACOS(config)# slb server ftps1 11.11.11.10

ACOS(config)# slb server ftps2 11.11.11.11
The following commands configure an FTP service group for the cache server:
ACOS(config)# slb service-group sg-ftps tcp

ACOS(config-slb svc group)# member ftps1 21
ACOS(config-slb svc group)# member ftps2 21
page 452
Configuring Bandwidth Limits Per Server or Port
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.

ACOS(config-slb vserver-vport)# service-group sg-ftps

You can create templates for monitoring and limiting the overall traffic load being handled by a real
server or port. Once the threshold is reached, the server or port can avoid selection for newer sessions
until the traffic load has subsided. It is also possible to enable accounting of traffic to and from the
server, and logging if the traffic limits are exceeded.
This feature can be deployed for either Server Load Balancing (SLB) or Transparent Cache Switching
(TCS) topology. In the TCS deployment considered in Figure 61, there is SLB and TCS traffic flow:
FIGURE 61 SLB and TCS Traffic Flow
To calculate the bandwidth for a real server or real port given both SLB traffic and TCS traffic flows
through ACOS, the traffic rate is computed by counting the total bytes processed, corresponding to
actual packets sent to and received from the real server (cache server) within a one second interval.
1. Client request packets are sent to the cache server (SLB session in orange).
2. Request packets are received from the cache server destined to the Internet (TCS session in blue).
3. Internet server response packets are sent to the cache server (TCS session in blue).
4. Response packets received from the cache server to be sent to the client (SLB session in orange).
page 453
Upon receiving a client request packet, ACOS will create an SLB session and then forward that packet
to the cache server. The bytes in this request packet sent by ACOS to the cache server will count
towards the traffic rate seen by the cache server.
Similarly when the cache server sends a request to the Internet server, ACOS will create a transparent
session and subsequently such packets will be counted for the bandwidth computation.
Next when the Internet server response is received, it will be transmitted to the cache server and this
packet length will count towards the cache server bandwidth computation.
Lastly when the cache server sends a response, the packet length will be counted towards the cache
server bandwidth computation.
When the load exceeds the configured limit and duration interval, that cache server will no longer be
included as part of the server selection process for newer flows. However, existing sessions continue
to be processed and forwarded to the cache server.
If a persist template is configured with dont-honor-conn-rules, the real server/port will continue to be
selected for new sessions, regardless of the threshold limit.
Configuring the Bandwidth Rate Limit for Servers and Ports

To configure the bandwidth rate limit for a server or port, configure the bw-rate-limit in an SLB server
or port template and apply the template to a real server or real port.
The following example shows how to configure the bandwidth rate limit of 1000 Kbps to exclude a real
server from receiving new traffic flows when the threshold is exceeded for a duration of 5 seconds. The
server will resume accepting new traffic flows after the bandwidth drops below 800 Kbps for a duration
of 5 seconds. The rate limit messages will not be logged.
ACOS(config)# slb template server rate-limit-1

ACOS(config-rserver)# bw-rate-limit 1000 resume 800 duration 5 no-logging
To apply the template to a real server:

ACOS(config-real server)# template server rate-limit-1
If the measured traffic rate is greater than the configured bw-rate-limit consistently for the specified
duration, it will be considered in 'exceed' state. Once it is in 'exceed' state, the measured traffic rate
needs to fall below the resume threshold consistently for the specified duration to be considered in
'resume' state. Exceed and resume state transition is then logged (once per state change per real port
or real server within a 60 second interval). Logging is enabled by default.
If this feature is enabled along with a feature, such as system resource template, that tracks bandwidth
usage on a partition or resource and then takes action to drop packets exceeding the resource tem-
page 454
plate threshold, inconsistent computation of the underlying bandwidth rate for traffic from the real
server may result.
For more information, see “slb template server” in the Command Line Interface Reference.
Configuring the Bandwidth Rate Limit Accounting

By default, all traffic sent by or received from real servers is factored in to bandwidth rate limit account-
ing. It is possible to configure the template so that only sent or received traffic is factored in to the
accounting.
To configure the accounting for bw-rate-limit, use the bw-rate-limit-acct command. This command
is only available for SLB server template configuration, and not for SLB port templates. Upon binding a
server template under a real server with this option, all real ports under the real server will automatically
be subject to the same accounting method.
The following example shows how to configure the bandwidth rate limit accounting only for traffic
received from the real server.
ACOS(config)# slb template server s1

ACOS(config-rserver)# bw-rate-limit-acct from-server-only
For more information, see “slb template server” in the ADC-CLI Command Line Interface Reference.
page 455
page 456
Destination Hash-Based TCS
ACOS provides a more optimal Transparent Cache Switching (TCS) solution that is based on hash of
the destination IP address for persistence instead of session persistence based on destination IP
address. With this feature, ACOS does not create a persistent session. Instead, ACOS device uses a
hash based on the available number of servers that are in an “UP” state in the service group.
Destination persistence templates can be attached only to wildcard VIPs.
Example of How this Feature Works
1. Three cache servers (cache server 1, cache server 2, and cache server 3) are configured with desti-
nation IP hash persistence and bound to a virtual port.
2. Cache server 1 temporarily goes down.
3. Traffic that was persisting to cache server 1 will be distributed between the remaining two cache
servers, cache server 2 and cache server 3 (with a hash base of 2, since only 2 servers are opera-
tional and available to calculate persistence).
4. Traffic sent to cache server 2 and cache server 3 will continue to be sent to the servers. This traffic
will not be recalculated. Only traffic that is configured to “persist” to cache server 1 gets recalcu-
lated. Redistribution is resumed and traffic is distributed among the total number of functional
servers.
Using the GUI
To configure destination IP address hash persistence using the GUI, do the following:
1. Navigate to ADC >> Templates >> Persistence.

2. Click Create, then select Persist Destination IP from the drop-down list.
4. Select the checkbox in the Hash Persist field.
5. Configure the other fields as desired; refer to the GUI online help for detailed information about
each of the fields on this screen.
6. Click OK.
page 457
Using the CLI
From the destination-ip persist template, configure TCS destination IP address hash persistence.
1. To ensure that the destination IP address hash calculation will persist even after a server fails,
enter the following commands, where “dhash” is the name of the template that you are creating for
destination IP hash persistence:
ACOS-Active(config)# slb template persist destination-ip dhash
ACOS-Active(config-destination ip persist)# hash-persist
ACOS-Active(config-destination ip persist)# exit
2. To view the existing configuration:

ACOS-Active(config)# show running | section dhash
slb template persist destination-ip dhash
hash-persist
3. To remove IP address hash persistence, issue the following command:

ACOS-Active(config)# no slb template persist destination-ip dhash
page 458
STARTTLS for Secure SMTP
This chapter describes how to configure the ACOS device to secure Simple Mail Transfer Protocol
(SMTP) mail using STARTTLS.
• Overview of STARTTLS
• Configuring STARTTLS
• STARTTLS for IMAP and POP3
Overview of STARTTLS
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 ACOS device is configured to perform STARTTLS, the ACOS acts as a proxy between SMTP
clients and servers. In client-side SSL, mail traffic to and from clients is encrypted by the ACOS,
whereas traffic between the ACOS and the SMTP servers is clear (not encrypted). With the server-side
option, the traffic between the ACOS and the SMTP server is encrypted, but traffic to and from clients is
not encrypted. It is possible to configure the encryption for client, server, or both.
Figure 62 shows an example of the STARTTLS client-side feature.
FIGURE 62 STARTTLS Client
Figure 63 shows an example of the STARTTLS server-side feature.
page 459
Overview of STARTTLS
FIGURE 63 STARTTLS Server
Figure 64 shows an example of the STARTTLS client-side and server-side feature.
FIGURE 64 STARTTLS Client and Server
Additional SMTP Security Options

In addition to providing encryption of mail traffic for clients, the ACOS STARTTLS feature has additional
security options:
• Require STARTTLS – By default, use of STARTTLS is optional. You can configure the ACOS to
require STARTTLS. In this case, before any mail transactions are allowed, the client must issue
the STARTTLS command to establish a secured session.
Client-side - if the client does not issue the STARTTLS command, the ACOS sends the following
message to the client: "530 - Must issue a STARTTLS command first”
Server-side - if a server responds without 250-STARTTLS, this will result in an error.
• Disable SMTP commands – By default, the VRFY, EXPN, and TURN commands are allowed. You
can disable support of any of these commands. In this case, if the client tries to issue a disabled
SMTP command, the ACOS sends the following message to the client: “502 - Command not
implemented”
page 460
Configuring STARTTLS
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 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 65 STARTTLS Domain Switching
Below is an overview of the steps required 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.
page 461
4. Configure a service group for the SMTP servers and add them to the group.
5. Configure an SMTP template. Within the template:
a. Specify the email server domain. The default is “mail-server-domain”.
b. Optionally, modify the service ready message. The default message text is "ESMTP mail service
ready". The complete message sent to the client is constructed as follows:
200 - smtp-domain service-ready-string
c. Optionally, disable one or more of the following SMTP commands: VRFY, EXPN, or TURN. If a
client sends an SMTP command that is disabled on the ACOS, the ACOS 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.
Use the GUI to Configure STARTTLS

This section describes how to configure the topology shown in Figure 62.
To import the SSL certificate:

2. Click Import.
3. Enter the name of the file in the File Name field.
4. Select Certificate in the Import field.
5. Select the location of the import (Local, Remote, or Text; if Remote or Text is selected the appropri-
ate fields will pop up to indicate IP or text content), certificate format, and the certificate source for
file search.
6. Click Import.
To import the SSL key:

2. Enter the name of the key in the File Name field.
3. Select Key in the Import field.
4. Specify the location of the import (Local, Remote, or Text), and the key source for file search.
5. Click Import.
page 462
Configure a client SSL template and add the certificate and key to the template:
1. Navigate to ADC >> Templates >> SSL.

2. Click Create and select Client SSL from the drop-down me nu.
3. Specify a name for the Client SSL server, and select the configured certificate and key from the
drop-down menus under the fields Server Certificate and Server Private Key.
4. Click OK.

2. Click Create.
3. Enter SMTP1 in the Name field.
5. Click Create in the Port section.
b. Select TCP from the drop-down list in the Protocol field.
c. Click Create.
6. Click Update.
7. Repeat this procedure to add real server SMTP2, IP address 192.168.1.3, port 25 TCP.
Configure the service group:

2. Click Create.
3. Enter SMTP_servers in the Name field
4. Click Create in the Member section.
a. Select SMTP1 from the drop-down list in the Server field.
c. Click Create.
d. Repeat to add port 25 of server SMTP2 as a member.
5. Click Update.
To configure an SMTP template for STARTTLS (step 5 above):
page 463
1. Navigate to ADC >> Templates >> L7.

2. Click Create, then select SMTP from the drop-down list.
3. Specify a name for the template.
4. In the STARTTLS Client field, select Enforced from the drop-down list.
5. Configure additional fields on this screen as desired; refer to the GUI online help for more informa-
tion.
6. Click OK.
To configure a virtual server for STARTTLS (step 6 above):

2. Click Create.
4. Enter the IP address of the virtual server in the IP Address field.
5. In the Virtual Port section, click Create to configure a virtual port:
a. Select SMTP from the drop-down list in the Protocol field.
b. Specify a port number in the Port field.
c. Click Create.
6. Click Update.
page 464
Use the CLI to Configure STARTTLS

The following commands implement the STARTTLS configuration shown in Figure 62.
To begin, the following commands import an SSL certificate and key:
ACOS# import cert starttls.crt ftp:

Password []?*********
File name [/]?starttls.crt
ACOS# import key tlscertkey.pem ftp:
Password []?*********
File name [/]?tlscertkey.pem
The following commands configure a client SSL template to use the certificate and key:
ACOS(config)# slb template client-ssl mailcert-tmplt

ACOS(config-client SSL template)# cert starttls.crt
ACOS(config-client SSL template)# key tlscertkey.pem
ACOS(config-client SSL template)# exit
The following commands configure the SMTP real servers:
ACOS(config)# slb server SMTP1 192.168.1.2

ACOS(config)# slb server SMTP2 192.168.1.3
The following commands configure a service group for the SMTP servers:
ACOS(config)# slb service-group SMTP_servers tcp

ACOS(config-slb svc group)# member SMTP1 25
ACOS(config-slb svc group)# member SMTP2 25
page 465
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.
ACOS(config)# slb template smtp starttls-tmplt

ACOS(config-slb template)# server-domain “mycorp.com”
ACOS(config-slb template)# service-ready-msg “MyCorp ESMTP mail service is ready”
ACOS(config-slb template)# starttls client esernforced
ACOS(config-slb template)# command-disable vrfy
ACOS(config-slb template)# command-disable expn
ACOS(config-slb template)# command-disable turn
ACOS(config-slb template)# exit
The following commands configure the VIP to which mail clients will send SMTP traffic:

ACOS(config-slb vserver-vport)# service-group SMTP_servers
ACOS(config-slb vserver-vport)# template client-ssl mailcert-tmplt
ACOS(config-slb vserver-vport)# template smtp starttls-tmplt
STARTTLS for Server-Side Connections

Use server-side STARTTLS to enable communication between the ACOS device and a server (such as a
mail server on the Internet) as SMTP over TLS (STARTTLS).
The following commands configure the SMTP template to enforce the use of server-side STARTTLS:
ACOS(config)# slb template smtp smtp

ACOS(config-smtp)# starttls server enforced
ACOS(config-smtp)# exit
This command configures the server template to ensure that the connection to the server is over SSL:
ACOS(config)# slb template server-ssl svssl

These commands configure the SMTP service group for TCP:
ACOS(config)# slb service-group nexthop tcp

These commands configure the VIP for encrypting traffic to and from the Internet mail servers.

ACOS(config-slb vserver-vport)# service-group nexthop
page 466
STARTTLS for IMAP and POP3
ACOS(config-slb vserver-vport)# template smtp smtp

ACOS(config-slb vserver-vport)# template server-ssl svssl
STARTTLS Statistics
To display STARTTLS statistics, use the show slb smtp command at the Privileged EXEC level or any
configuration level of the CLI.
For more information, see “show slb smtp” in the Command Line Interface Reference for ADC.

IMAP and POP3 STARTTLS extension from the servers can be offloaded, as specified in RFC 2595. The
ACOS device will take care of STARTTLS and the associated SSL handshakes. After this, communica-
tion between the client and ACOS device will be encrypted and device to server communication will be
clear text.
The current IMAP specification allows for the Login command to come in clear text. With the START-
TLS support, the servers have the ability to specify whether the Login is supported in clear text or not.
The LOGINDISABLED has to be sent as part of the capability response by server to indicate that the
server expects the Login to be supported only in encrypted format. Within the ACOS device, this can be
enabled/disabled by configuring an IMAP template. If the ACOS device sends the LOGINDISABLED
command, then it expects the Login to come only after the STARTTLS is done. If the login is issued by
the client before STARTTLS, the ACOS device will send no response.
As per the RFC, STARTTLS is valid only in the non-authenticated state. In this version of the release,
since the ACOS device is only supporting offload and there is no requirement yet to conform to the pro-
tocol (most of the protocol compliance is handled by the server), the device will not track when the
STARTTLS is sent. From the point of view of the ACOS device, when the client sends STARTTLS, it
expects the SSL handshake to occur. To configure IMAP for STARTTLS, assign it to a virtual port and
include this port within an SLB virtual server. The following shows an example CLI configuration for
enabling this.
ACOS(config)# slb template imap-pop3 imap-temp

ACOS(config-imap-pop3)# logindisabled
ACOS(config-imap-pop3)# starttls enforced
ACOS(config-imap-pop3)# exit
ACOS(config)# slb virtual-server imap-vserver 10.10.31.10
ACOS(config-slb vserver)# port 143 imap
ACOS(config-slb vserver-vport)# template imap-pop3 imap-temp
page 467
page 468
Diameter AAA Load Balancing
This chapter describes SLB for the Diameter AAA protocol. Diameter is a successor to RADIUS that pro-
vides security and other enhancements not supported in RADIUS.
Overview
Diameter load balancing enables the ACOS device to act as a proxy between Diameter clients and serv-
ers. Figure 66 shows an example.
FIGURE 66 Diameter Load Balancing
page 469
Overview
Diameter operates over TCP or SCTP. the ACOS device terminates the client’s Diameter connection,
and opens another Diameter connection with the selected server.
NOTE: The current release supports Diameter over TCP only.
Clients send Diameter messages, such as authentication requests, to the VIP configured on the ACOS
device. ACOS uses SLB to select a Diameter server and forwards the client’s request to the server.
ACOS then forwards the server’s reply to the client.
The clients and real servers can be connected to the ACOS device on Layer 2 or Layer 3.
Source NAT
Source NAT is required for traffic between the ACOS device and the Diameter servers. ACOS estab-
lishes a separate connection to each Diameter server before any client requests arrive. The NAT
address(es), consisting of source IP address and source TCP port, uniquely identify the connections.
Load-Balancing
Diameter load balancing requires the strict round-robin load balancing method.
Session-ID persistence is automatically enabled for Diameter virtual ports. After a server is selected for
a given client session, all requests for that session go to the same real server.
NOTE: You do not need to configure a session-ID persistence template. Session

persistence is enabled automatically for Diameter virtual ports.
Optionally, you can configure multiple sets of service-group members (server:port pairs) that differ
based on member priority. In this case, the ACOS device uses only the members with the highest prior-
ity as long as they are available, and uses lower-priority members only if the high-priority members
become unavailable.
An additional option allows lower-priority members to temporarily be elevated to high priority to com-
pensate for high-priority members that are unavailable.
Health Monitoring
You can use the Layer 3 health method (ICMP ping) to test the IP reachability of each server. Layer 3
health monitoring is enabled by default.
You do not need to configure any Layer 4 or Layer 7 health monitors on the ACOS device for Diameter
load balancing. The Diameter protocol includes its own Layer 7 health method, the Device-Watchdog-
Request message. ACOS periodically sends Device-Watchdog-Request messages to each Diameter
real server. Each server must respond to its message within a configurable number of seconds or the
server is marked Down.
page 470
Diameter Parameters
NOTE: You will need to disable Layer 4 health monitoring, which is enabled by
default. You can disable it individually in each server’s configuration, or
create a real port template for Diameter, disable the Layer 4 health moni-
tor in the template, and assign the template to the TCP port in each real
server configuration.
Application Templates
The following types of application templates are applicable to Diameter load balancing:
• TCP – Contains settings used for TCP connections between the ACOS device and Diameter cli-
ents and servers.
• Diameter – Contains the Diameter settings. (See “Diameter Parameters” on page 471.)
Accounting Message Duplication
Optionally, you can configure the ACOS device to duplicate Accounting-Request messages and send
them to a separate service group. This option is useful for logging, accounting, and so on.
Session-ID persistence is used to send all duplicate messages for a given client’s session to the same
server in the service group.
ACOS does not send Accounting-Answer messages in response to duplicate Accounting-Request mes-
sages sent to the duplication service group.
High Availability
You can use a set of ACOS devices configured for High Availability (HA) to provide redundancy for
Diameter load balancing. Make sure to enable session synchronization (also called “connection mirror-
ing”) on the Diameter virtual port, to ensure that session-ID persistence is maintained across failovers.
NOTE: The Diameter template parameter origin-host-id is not included in HA

configuration synchronization. The other Diameter template parameters
are included in HA configuration synchronization.
Diameter Parameters
The following parameters are configurable in Diameter templates.
Diameter Attribute-Value Pairs

You can configure the following Diameter Attribute-Value Pair (AVP) options:
page 471
Diameter Parameters
• Origin-host – Sets the value of Diameter AVP 264. This AVP can be a character string and speci-
fies the identity of the originating host for Diameter messages. Since the ACOS device acts as a
proxy for Diameter, this AVP refers to the ACOS device itself, not to the actual clients. From the
Diameter server’s standpoint, the ACOS device is the Diameter client.
Specify the origin-host in the following format: host.realm
The host is a string unique to the client (ACOS device). The realm is the Diameter realm, specified
by the origin-realm option (described below). There is no default.
• Multiple-origin-host – Prepends the ACOS CPU ID onto the origin-host string to identify the CPU
used for a given Diameter peer connection. By default, this option is disabled and the CPU ID is
not prepended onto the origin-host string.
ACOS establishes a separate peer connection with each Diameter server on each CPU. The multi-
ple-origin-host option does not enable or disable this behavior. The option simply shows or hides
the CPU ID in the origin-host string.
• Origin-realm – Sets the value of Diameter AVP 296. This AVP can be a character string and spec-
ifies the Diameter realm from which Diameter messages, including requests, are originated.
There is no default.
• Product-name – Sets the value of Diameter AVP 269. This AVP can be a character string and
specifies the product; for example, “a10dra”. There is no default.
• terminate-on-cca-t - Removes Diameter sessions when receiving the Server CCA-Termination
message, rather than waiting for the Client Session-Terminate-Request (STR).
• Vendor-ID – Sets the value of Diameter AVP 266. This AVP can be a numeric value and specifies
the vendor; for example, “156”. Make sure to use a non-zero value. Zero is reserved by the Diame-
ter protocol. There is no default.
• AVP insertion – Specifies custom AVP values to insert into Capabilities-Exchange-Request mes-
sages sent by the ACOS device to Diameter servers. For each custom AVP value to insert, you
must specify the following information:
avp-num [mandatory] {int32 | int64 | string} value
• avp-num – Diameter AVP number.
• mandatory – Sets the AVP mandatory flag on. By default, this flag is off (not set).
• int32 | int64 | string – Specifies the data format of the value to insert.
• value – Specifies the value to insert.
You can configure up to 6 custom AVP values.
• Customize-CEA – Replaces the AVPs in Capabilities-Exchange-Answer (CEA) messages with the
custom AVP values you configure before forwarding the messages. By default, this option is dis-
abled.
page 472
Diameter Parameters
Load Balancing for Specific Message Codes

By default, Diameter load balancing applies only to these message codes (also called “command
codes”):
• Accounting-Request (code 271)
• Accounting-Answer (code 271)
• Credit-Control-Request (code 272)
• Credit-Control-Answer (code 272)
• Capabilities-Exchange-Request (code 257)
• Capabilities-Exchange-Answer (code 257)
• Device-Watchdog-Request (code 280)
• Device-Watchdog-Answer (code 280)
• Session-Termination-Request (code 275)
• Session-Termination-Answer (code 275)
• Abort-Session-Request (code 274)
• Abort-Session-Answer (code 274)
• Disconnect-Peer-Request/Disconnect-Peer-Answer (code 282)
ACOS drops all other Diameter message codes by default.
Optionally, use the message-code option to enable load balancing of additional Diameter message
codes, on an individual message-code basis. You can enable load balancing of up to 10 additional mes-
sage codes.
Timers
You can configure the following Diameter timers:
• Idle timeout – Specifies the number of minutes a Diameter session can remain idle before the
session is deleted. You can specify 1-65535 minutes. The default is 5 minutes.
• Session-age – Specifies the absolute limit for Diameter sessions. Any Diameter session that is
still in effect when the session age is reached is removed from the ACOS session table. You can
specify 1-65535 minutes. The default is 10 minutes.
• DWR-time – Specifies the maximum number of seconds the ACOS device will wait for the reply
to a device-watch-dog message sent to a Diameter server before marking the server Down. You
can specify 0-2147483647 milliseconds (ms), in 100-ms increments. The default is 10 seconds.
page 473
Configuring Diameter Load Balancing
• DWR-up-retry – Specifies the number of Device Watchdog Request and Device Watchdog
Answer messages required to mark a server port as up. You can specify 1-7. The default is 3.
Accounting-Request Message Duplication

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

To configure Diameter load balancing:
1. Configure a source NAT pool containing addresses in the same subnet as the Diameter servers.
2. Configure the real servers.
3. Configure the service group.
4. (Optional) Configure the real servers and service group for Accounting-Request message duplica-
tion.
5. Configure the Diameter template.
6. Configure the virtual server.
page 474
Diameter Load Balancing Configuration (CLI Procedure)

1. To configure the source NAT pool, use the ip nat pool command at the global configuration level
of the CLI:
For information about the command, see the CLI Reference or System Configuration and Administra-
tion Guide.
2. To configure the real servers, use the slb server command to change to the configuration level for
the real server, where you can use the port command to add the TCP port to the server. The
default Diameter protocol port is 3868.
The port command adds the port and changes the CLI to the configuration level for the port. At
this level, use the health-check-disable command to disable the Layer 4 health monitor:
Instead, the ACOS device uses Diameter Device-Watchdog-Request messages to test the health of
the Diameter protocol on the servers.
3. To configure the service group, use the slb service-group command.
This command changes the CLI to the configuration level for the service group, where you can use
the method round-robin-strict command to add the real servers and service ports to the group:
The member command sets the load-balancing method required for Diameter load balancing. The
command specifies the protocol port number of the service to be load balanced. Use the same
port number specified in the server configuration in step 2. Repeat the command for each real
server.
The priority option specifies the preference for using this server and port. You can specify 1-16.
The highest priority value is 16 and the lowest is 1. The default is 1.
Normally, only the highest-priority members are used. Lower-priority members backups and are
used only if the active members become unavailable. Optionally, you can use the min-active-mem-
ber command to specify a minimum number of active members that are required. In this case, the
ACOS device uses lower-priority servers even if some primary servers are still up.
4. To configure Accounting-Request message duplication, use the slb server and slb service-
group commands to configure the real servers and service group.
For information, see the following:

• “Accounting Message Duplication” on page 471
• “Diameter Parameters” on page 471
5. To configure the Diameter template, use the slb template diameter command.
This command changes the CLI to the configuration level for the template, where Diameter Param-
eters are available.
6. To configure the virtual server and virtual port, use the slb virtual-server command. This com-
mand changes the CLI to the configuration level for the virtual server, where you can use the port
command to add the virtual port to the server.
page 475
The port command changes the CLI to the configuration level for the virtual port.
Use the source-nat pool command to bind the virtual port to the source NAT pool:
Use the template diameter command to bind the virtual port to the Diameter template:
Use the service-group command to bind the virtual port to the service group:
7. To verify and monitor Diameter load balancing operation, use the show slb diameter and show slb
server commands.
Configuring Basic Diameter Load Balancing – Single ACOS Device (CLI Example)
This example configure the Diameter load-balancing deployment shown in Figure 66 on page 469.
This command configures the source NAT pool:
ACOS(config)# ip nat pool snat.1 20.20.20.251 20.20.20.251 netmask /24
ACOS(config)# slb server diameter-rs1 20.20.20.1

The following commands configure the service group. In this example, diameter-rs3 is a backup.
ACOS(config)# slb service-group sg-tcp3868 tcp

ACOS(config-slb svc group)# method round-robin-strict
ACOS(config-slb svc group)# member diameter-rs1 3868
page 476

The following commands configure the Diameter template:
ACOS(config)# slb template diameter diameter1

ACOS(config-diameter template)# origin-host 2diameter.a10com
ACOS(config-diameter template)# origin-realm a10com
ACOS(config-diameter template)# product-name a10dra
ACOS(config-diameter template)# vendor-id 156
ACOS(config-diameter template)# exit
ACOS(config)# slb virtual-server vip-diameter.1 10.10.10.101

ACOS(config-slb vserver)# port 3868 diameter
ACOS(config-slb vserver-vport)# source-nat pool snat.1
ACOS(config-slb vserver-vport)# template diameter diameter1
ACOS(config-slb vserver-vport)# service-group sg-tcp3868
Accounting-Request Message Duplication (CLI Example)
These commands configure an additional set of real servers and a service group for duplicate Account-
ing-Request messages:
ACOS(config)# slb server diameter-acr-dup1 20.20.20.4

ACOS(config)# slb server diameter-acr-dup2 20.20.20.5
ACOS(config)# slb service-group diameter-duplicate-group tcp
ACOS(config-slb svc group)# method round-robin-strict
ACOS(config-slb svc group)# member diameter-acr-dup1 3868
ACOS(config-slb svc group)# member diameter-acr-dup2 3868
The following commands add the duplicate option to the Diameter template:
page 477
ACOS(config)# slb template diameter diameter1

ACOS(config-diameter template)# duplicate 30 “acct” diameter-duplicate-group
ACOS(config-diameter template)# exit
This option duplicates Accounting-Request messages with AVP 30 that contain the string “acct”, and
sends the duplicate messages to service group “diameter-duplicate-group”.
The duplicate service group does not need to be bound to the Diameter virtual port. Instead, the dupli-
cate option in the Diameter template takes care of this.
page 478
RADIUS Message Load Balancing
This chapter describes RADIUS message load balancing and how to configure it. These topics are cov-
ered:
• Overview of RADIUS Message Load Balancing
• Configuration RADIUS Message Load Balancing
Overview of RADIUS Message Load Balancing

This section includes the following topics:
• RADIUS Message Load Balancing Example
• Server Traffic Flow for RADIUS Message Load Balancing
• Protocol Port Numbers Supported with Stateless RADIUS Load Balancing
• Hardware-Based Load-Balancing Methods
• RADIUS Session Aging
RADIUS Message Load Balancing Example

ACOS supports load balancing of RADIUS messages in a topology such as the one shown in Figure 67.
FIGURE 67 RADIUS message load balancing
page 479
In this example, all RADIUS requests received by the ACOS device have the same source and destina-
tion IP addresses. The source address is the address of a Broadband Remote Access Server (BRAS),
10.11.11.50. The destination IP address is a RADIUS VIP on the ACOS device, 10.11.11.90.
In this type of topology, wherein RADIUS requests for multiple clients arrive at the ACOS device with the
same source and destination addresses, using a UDP virtual port does not provide load balancing. This
is because the ACOS device uses the same session for all the requests.
Normally, the ACOS device sends all traffic on a given session to the same server. If a UDP virtual port
is used, the ACOS device uses the configured load balancing method to select a server for the first
request, then uses the same server (and data CPU) for all subsequent requests.
Server Traffic Flow for RADIUS Message Load Balancing

The first time the ACOS device receives a RADIUS request with a given Identifier value, the ACOS device
uses the load balancing method to select a RADIUS server. Subsequent RADIUS requests with the
same Identifier value go to the same server. However, when the ACOS device receives a request with a
different Identifier value, the ACOS device uses the configured load balancing method to select a server
for requests that contain that Identifier value.
Figure 68 shows the traffic flow for RADIUS message load balancing.
FIGURE 68 RADIUS message load balancing - traffic flow
1. Client sends RADIUS request.

2. Request is forwarded by BRAS.
3. RADIUS VIP on ACOS device receives the request. ACOS device selects a server and sends the
request to the server. Subsequent requests with the same Identifier go to the same server.
4. RADIUS server replies to request.
page 480
Protocol Port Numbers Supported with Stateless RADIUS Load

Balancing
Stateless load balancing for RADIUS is supported for the following protocol port numbers and ranges:
• 1645
• 1646
• 1812
• 1813
• 12,000 – 28,000
• 42,000 – 58,000
Both the virtual port number and real port numbers must be in the list to support stateless load balanc-
ing.
Notes
• Stateless load balancing for RADIUS is supported only for the listed real and virtual port numbers.
• On ACOS models that use FTAs, using stateful and stateless load-balancing methods simultane-
ously is not supported for the listed protocol ports if the same port number is used for real and
virtual ports.
Load Balancing Across Data CPUs for the RADIUS Virtual Port Type
To optimize performance, traffic for the RADIUS virtual port type is load balanced across multiple data
CPUs. All requests that have a given Identifier value go to the same server and are processed by the
same data CPU.
If the virtual port uses source NAT, all traffic for the virtual port is processed by the same data CPU,
without further load balancing across CPUs. Depending on the traffic volume, this can affect perfor-
mance.
Stateless RADIUS load balancing supports only IP Map list static NAT. Source NAT is not supported in
stateless RADIUS mode.
Hardware-Based Load-Balancing Methods

CPU packet distribution method varies by device platform. Models either support hardware-based or
software-based packet distribution. Software-based distribution is based on RADIUS request ID.
page 481
Configuration RADIUS Message Load Balancing
Enable hardware-based per-packet CPU distribution, device supporting that method, by using Stateless
Per-packet Round-robin load balancing method. This method is called “Stateless Per-Packet Round
Robin” in the GUI, and stateless-per-pkt-round-robin in the CLI.
RADIUS Session Aging

Aging of RADIUS sessions is based on the idle-timeout in the UDP template used by the RADIUS virtual
port. The default is 120 seconds.
You also can use the aging option in the UDP template. For example, setting aging to “immediate” ter-
minates a session as soon as the server responds to the client.

Configuration of RADIUS message load balancing is similar to configuration of other service types:
1. (Optional) To configure connection-rate limiting or request-rate limiting for the RADIUS ports, con-
figure a real-port template and set the rate within the template.
2. Create a real server configuration for each RADIUS server.
• Make sure the port number(s) you assign to the RADIUS port(s) are among those listed in “Pro-
tocol Port Numbers Supported with Stateless RADIUS Load Balancing” on page 481.
• If you configure a real-port template (step 1 above), bind the template to each of the RADIUS
ports in each real-server configuration.
3. Add the real servers to a service group. Configure the group to use the Stateless Per-packet
Round-robin load-balancing method.
4. Create a VIP configuration that has the IP address that will receive the RADIUS requests. Add a
RADIUS virtual port to the VIP. Bind the service group created in step 3 to the virtual port.
The RADIUS port number on each real server must be the same. Using mixed port numbers in a
service group is not supported. The virtual port number does not need to be the same as the real
port number.
Using the CLI
At the configuration level for the virtual server, use the port command. To view RADIUS sessions, use
the show session radius command.
CLI Example
The commands in this example implement the RADIUS load balancing configuration shown in
Figure 67 on page 479 and Figure 68 on page 480.
page 482
To begin, the following commands create server configurations for the RADIUS servers:
ACOS(config)# slb server radius1 10.11.11.11

The following commands add the servers to a service group:
ACOS(config)# slb service-group sg-rad udp

ACOS(config-slb svc group)# member radius1 1812
The following commands configure the RADIUS VIP:
ACOS(config)# slb virtual-server rad-msg-lb 10.11.11.90

ACOS(config-slb vserver)# port 1812 radius
ACOS(config-slb vserver-vport)# service-group sg-rad
page 483
The following command shows active RADIUS sessions:
ACOS# show session radius

Traffic Type Total
--------------------------------------------
TCP Established 0
TCP Half Open 0
UDP 30
...
Prot Forward Source Forward Dest Reverse Source Reverse Dest

Age Hash Flags Radius ID
------------------------------------------------------------------------------------------
--------------------------------
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.15:1812 10.11.11.50:32836
120 1 NSe0 104
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.12:1812 10.11.11.50:32836
120 1 NSe0 111
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.15:1812 10.11.11.50:32836
120 1 NSe0 167
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.14:1812 10.11.11.50:32836
120 1 NSe0 118
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.11:1812 10.11.11.50:32836
120 2 NSe0 70
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.14:1812 10.11.11.50:32836
120 2 NSe0 91
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.15:1812 10.11.11.50:32836
120 2 NSe0 84
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.14:1812 10.11.11.50:32836
120 2 NSe0 77
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.15:1812 10.11.11.50:32836
120 2 NSe0 56
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.12:1812 10.11.11.50:32836
120 2 NSe0 119
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.13:1812 10.11.11.50:32836
120 2 NSe0 168
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.13:1812 10.11.11.50:32836
120 3 NSe0 162
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.13:1812 10.11.11.50:32836
120 3 NSe0 176
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.12:1812 10.11.11.50:32836
120 3 NSe0 239
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.13:1812 10.11.11.50:32836
120 3 NSe0 15
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.11:1812 10.11.11.50:32836
120 3 NSe0 134
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.11:1812 10.11.11.50:32836
120 3 NSe0 169
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.13:1812 10.11.11.50:32836
120 3 NSe0 204
page 484
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.11:1812 10.11.11.50:32836

120 4 NSe0 233
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.15:1812 10.11.11.50:32836
120 4 NSe0 107
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.12:1812 10.11.11.50:32836
120 5 NSe0 171
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.14:1812 10.11.11.50:32836
120 5 NSe0 66
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.11:1812 10.11.11.50:32836
120 5 NSe0 199
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.12:1812 10.11.11.50:32836
120 6 NSe0 221
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.15:1812 10.11.11.50:32836
120 6 NSe0 172
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.13:1812 10.11.11.50:32836
120 6 NSe0 151
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.14:1812 10.11.11.50:32836
120 6 NSe0 25
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.12:1812 10.11.11.50:32836
120 6 NSe0 179
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.14:1812 10.11.11.50:32836
120 7 NSe0 103
Udp 10.11.11.50:32836 10.11.11.90:1812 10.11.11.11:1812 10.11.11.50:32836
120 7 NSe0 222
Total Sessions: 30
The session table contains a separate session for each RADIUS Identifier value. The following address
information is shown for each session:
• Forward Source – The sender of the RADIUS message. In Figure 67 on page 479, this is the IP
address of the BRAS.
• Forward Dest – The RADIUS VIP on the ACOS device.
• Reverse Source – The RADIUS server to which the ACOS device sends requests that have the
Identifier listed in the RADIUS ID field.
• Reverse Dest – The destination of the RADIUS server reply forwarded by the ACOS device. (This
is the sender of the initial RADIUS message that started the session, the BRAS in the example
above.)
page 485
page 486
SNMP-Based Load Balancing
This chapter describes SNMP-based load balancing.
• Overview of SNMP-Based Load Balancing
• Configuring SNMP-Based Load Balancing
Overview of SNMP-Based Load Balancing

You can use the results of SNMP queries to real servers to dynamically set the weight values of the
servers. When used along with a a load-balancing method that includes server weight in the selection
process, this option allows servers to be selected based on metrics such as the following:
• CPU utilization
• System memory utilization
• Connection capacity
• Hard drive utilization
Requirements
• External health monitor – SNMP-based load balancing uses an external health monitor (a script)
to periodically send SNMP queries to each of the real servers. The script must return a numeric
value. The following values are valid for SNMP-based load balancing:
• 0-124 – Server is up. The server’s weight value (1-100) is dynamically changed to the value
returned by the script. If the script returns 0, the value is set to 1. If the script returns value 101-
124, the value is set to 100.
• -1 – Server is down.
• 125 or higher – Server is down.
Exit codes 1 and 2 are reserved. Please make sure the script does not have general errors.
When configuring the external health monitor on the ACOS device, make sure to use the prefer-
ence option. This option enables the server weight values to be dynamically set based on the val-
ues returned by the health monitor’s script.
page 487
• Weighted load-balancing method – The server weight is used for server selection only if the ser-
vice group uses either of the following load-balancing methods:
• Weighted-least-connection
• Weighted-rr (weighted round robin)
Weight-based Load Balancing

When a weight-based load-balancing method is used, the ACOS device selects servers with higher
weight values more often than servers with lower weight values.
For example, assume the SNMP-based health check of a group of 4 real servers results in the following
dynamically assigned weight values:
• Server1 – weight 1
ACOS selects the servers s for new connections as follows:
• Server1 – 1 connection
• Server1 – 0 connections
page 488
...
The pattern of selection repeats until the server weight values are changed based on the next health
check.
Sample External Health Monitor Script for SNMP-based Load

Balancing
Here is an example of a Shell script for SNMP-based load balancing. This script uses the results from
queries to an example MIB module from ExampleCorp:
#!/bin/sh
dst="$HM_SRV_IPADDR"
#dst="$HM_SRV_IPADDR:$HM_SRV_PORT"
# Community String
community="public"
page 489
Configuring SNMP-Based Load Balancing
# EXAMPLECORP-SNMP-MIB::extResult.1
oid=".1.3.6.1.4.1.2021.8.1.100.1"
function check_value {
echo "$output"
value=`echo $output | sed 's/INTEGER: //'`
echo "value" = "$value"
if [[ "$value" =~ "^[[:digit:]]*$" ]]; then
# echo "digit string"
if [ $value -ge 0 -a $value -lt 125 ]; then
echo "Good"
exit $value
fi
fi
}
echo "/usr/bin/snmpget -v2c -c \"$community\" -Ov \"$dst\" $oid"

output=$(/usr/bin/snmpget -v2c -c "$community" -Ov "$dst" $oid)
if [ 0 != $? ]; then
exit -1
fi
check_value
# success
echo "Mark server down"
exit -1

To configure SNMP-based load balancing:
1. Create a script such as the one shown above.

2. Import the script onto the ACOS device.
3. Configure an external health monitor to use the script. Make sure to use the preference option.
4. Configure the service group to use a weighted load-balancing method.
NOTE: These steps apply specifically to SNMP-based load balancing. The other
configuration steps standard to all types of load balancing are also
required: configure the real servers and add them to a service group, con-
page 490
figure the virtual server (VIP), bind the service group to a virtual port on
the VIP, and so on.
Use the GUI to Configure SNMP-Based Load Balancing

The section provides an example of how to configure SNMP-based load balancing using the GUI.
1. Import the script into the GUI:

a. Navigate to ACDC >> Health Monitors >> External Programs.
b. Click Create.
c. Provide a name, then copy and paste the external script into the GUI.
d. Click Create.
2. Create the health monitor that will use the script.
a. Navigate to ADC >> Health Monitors.
b. Click Create.
c. In the General Fields section, specify a name, then select External from the drop-down list in the
Method type field.
d. In the External section, select the name of the script you just created from the drop-down list in
the Program field.
e. Select the checkbox in the Preference field.
f. Click Create Monitor.
3. Configure the service group to use a weighted load-balancing method.
a. Navigate to ADC >> SLB >> Service Groups.
b. Specify a service group name and protocol.
c. In the Algorithm field, select a weight load-balancing method (for example, Weighted Round
Robin).
d. Complete any other fields are needed (refer to the GUI online help for more information about
any field on this screen).
e. Click Create.
Use the CLI to Configure SNMP-Based Load Balancing

This section provides an example of SNMP-based load balancing using the CLI.
page 491
1. Import an external health monitor script onto the ACOS device using the import health-external
command at the global configuration level of the CLI. For example, to import a script named snmp-
hm.sh:
ACOS(config)# import health-external snmp-hm.sh scp://[email protected]/
scripts/
2. Configure an external health monitor that will use the script. For example:
ACOS(config)# health monitor hm-ext-snmp
This command changes the CLI to the configuration level for the monitor, where you use the
method command to have the health monitor use the external script:
ACOS(config-health:monitor)# method external program snmp-hm.sh preference
3. Set the service group to use a load-balancing method based on server weight:
ACOS(config)# slb service-group snmp-sg1 tcp
ACOS(config-slb svc group)# method weighted-rr
To verify that all servers are up, use the show health stat command:
To display the current weight values of the servers, use the show running-config | sec slb server
command.
page 492
Advanced Traffic Replication
ACOS includes a traffic replication feature that intercepts traffic feeds, such as SNMP or Syslog pack-
ets, copies them to a buffer, and forwards the duplicated packet to multiple collector servers, where the
data can be used to track users and devices.
The new feature can be helpful for organizations that need Network Monitoring feeds to be replicated
to multiple destinations. It represents a significant improvement over alternative method that rely on
servers processing feeds and then forwarding them to other groups in an organization.
Figure 69 shows the topology used to discuss this traffic replication feature.
FIGURE 69 Topology for Traffic Replication
The figure shows an ACOS device connected to multiple real “collector” servers. The servers can be
connected directly to the ACOS device (Server 5), or they can be connected through a Layer 2 switch
(Servers 1 and 2), or they can be connected through a Layer 3 router (Servers 3 and 4).
Figure 70 shows how the traffic replication feature works.
page 493
FIGURE 70 Topology for Traffic Replication
1. The Network Monitoring device (NM-1) sends traffic to the ACOS VIP.
2. As traffic passes through the ACOS device, it is vetted to see if it belongs to one of the target NM
traffic types, such as SNMP or Syslog. If the traffic does belong to one of the NM traffic types, then
duplicates are made for each collector server and are stored locally on the ACOS device.
3. The original traffic from NM-1 is load balanced using standard SLB algorithms and is sent to its
original target destination (RS-1). This is represented by the solid blue line in Figure 70.
4. ACOS applies one of the traffic replication options to the duplicated packets. This customization of
the duplicated packet changes the MAC or IP in the packet’s header. These changes are needed to
forward the packets to multiple destinations (RS-2, RS-3, and RS-4). Forwarded packets are repre-
sented by the dotted blue lines.
While previous releases supported a port mirroring feature, it operated at the port level and did not dis-
criminate between different types of traffic. This new approach to traffic replication provides better
granularity by enabling you to specify which parts of the source and destination addresses will be
replaced.
The feature allows you to bind a traffic replication mode to a normal VIP or to a wildcard VIP, and that
wildcard VIP can be associated with an ACL.
Separate VIPs can be created on the ACOS device to handle specific types of traffic. For example, a VIP
could be dedicated to receiving SNMP traffic. When traffic is received on that VIP, (and assuming one
of the replication modes has been enabled), the SNMP traffic stream will be replicated to the collector
servers designated within the associated service group.
Both TCP and UDP traffic types are supported, as long as the feature is enabled at the service group
level.
page 494
Packet Header Changes

In general, most of the traffic replication options modify the headers of the duplicated packets at Layer
2 by changing the MAC address. As Figure 71 shows, the traffic replication feature mainly affects the
packet addressing at Layer 2 and Layer 3.
Only one of the Traffic Replication modes, mirror IP-replacement, alters the packets’ IP address and
makes changes to the Layer 4 source and destination ports in the duplicated packets.
FIGURE 71 Changes to Packet Header
Details:
• When using the mirror IP-replacement option, the destination port can be changed under the fol-
lowing circumstances:
• If the virtual port is set to wildcard port 0, and if the service group members have different real
ports configured, then the Layer 4 destination port on the duplicated packets will be changed.
• If the virtual port is set to wildcard port 0, and if a service group member is configured with port
80, then the Layer 4 destination port on the duplicated packets will be changed to port 80.
NOTE: If the virtual port is set to wildcard port 0, and if a service group member
is configured with real port 0, then the Layer 4 destination port will not be
changed.
• If the virtual port is not set to wildcard port 0 but is instead set to port 80, and if a service group
member is configured with real port 81, then the Layer 4 destination port will be changed to port
81.
• When using the mirror IP-replacement option, the source port can be changed under the following
circumstances:
page 495
• The Layer 4 source port will only be changed if the original packet being load balanced and rep-
licated is changed. The reasons for this change to the source port of the original packet, (and in
the duplicated packets) are unrelated to the Advanced Traffic Replication feature.
• Source NAT can be used with the mirror IP-replacement option. In this case, the Layer 4 source-
port might be replaced for packets that have been load balanced, but all of the replicated pack-
ets will have the same source port as the packet that was load balanced.
Traffic Replication Modes

Traffic can be replicated or “mirrored” to the collector servers that are specified within a service group
using one of the following traffic replication modes:
• Mirror: This mode does not change the packet header at all. The original Layer 2 Destination
Address (DA) or Source Address (SA) and Layer 3 IP addresses are left intact. ACOS simply sends
the packets “as is” to the collector server(s), and the forwarding is based on the IP address in the
original packet. Unlike other replication modes, mirror mode replicates traffic to the client, in addi-
tion to replicating traffic to the server. Only lower priority servers are used, so it is recommended
to define the collector servers as lower priority to ensure they receive the replicated traffic.
• Mirror Destination MAC Address replacement: This mode uses Layer 2 forwarding, with the ACOS
device replacing the destination MAC address on the incoming packet with the destination MAC
for each of the collector servers within the designated service group.
• Mirror IP-replacement: This mode replaces the incoming packet’s IP address with the IP address
of the collector server(s) and then forwards the duplicated packet to those servers. This is the
only mirroring option that affects the packet at Layer 4, with minor changes being made to the
Layer 4 source and destination ports. This option is recommended for scenarios in which collec-
tor servers are not directly connected to the ACOS device.
• Mirror Source MAC Address and Destination MAC Address replacement: This mode replaces
both the source and destination MAC addresses at Layer 2 but does not change the Layer 3 IP
addressing information.
• Mirror Source MAC Address replacement: This mode replaces the source MAC address on the
incoming packet with the MAC address corresponding to virtual server on the ACOS device. This
option is recommended for scenarios where not changing the source MAC can cause a loop.
page 496
Use Case Scenarios for Traffic Replication

Table 8 lists replication modes and associated use case scenarios for each
TABLE 8 Traffic Replication Options and Use Cases

Traffic Replication
Option CLI Description Use Case Scenario
mirror Mirror Bi-directional If UDP Network Management traffic collectors operate in
Packet promiscuous mode, then this mirror option can be used to
replicate traffic to collectors that are directly connected to
ACOS.
mirror-da-repl Replace Destination MAC When the collector server is connected through a Layer 2
network, or if the collector server is not operating in promis-
cuous mode, this option can be used to require the destina-
tion MAC to be set with the collector server's MAC.
mirror-ip-repl Replaces IP with server-IP If UDP Network Management traffic collectors are not
capable of operating in promiscuous mode, then this “mir-
ror-ip-rep” option can be used to replicate traffic to collec-
tors that are not directly connected to the ACOS device and
which are on a different subnet.
This can be particularly useful with event management

applications (such as netcool), which employ an active/
standby architecture and replicate traffic between the serv-
ers. This application can be offloaded from the servers and
onto the ACOS device, thus improving performance.
mirror-sa-da-repl Replace Source MAC and This option is similar to the “mirror-da-repl” option because
Destination MAC the destination MAC is replaced. However, in addition to the
destination MAC being replaced, the source MAC will also
be changed to the ACOS device's MAC address, in order to
prevent network loops from occurring.
mirror-sa-repl Replace Source MAC This option is similar to the "mirror" option because the
source MAC address is changed in order to provide addi-
tional protection and for identification purposes.
Implementation Details
Implementing the Traffic Replication feature is almost the same set of configuration steps as required
for a standard SLB. To configure this feature, the following configurations are necessary:
1. Define a normal VIP (or a wildcard VIP) within the service group. If a wildcard VIP is used, then cre-
ate an ACL to identify the subnet of the network monitoring devices from which traffic will be
accepted.
2. Configure the real collector servers.
page 497
3. Configure a service group for the collector servers, add the real collector servers to the service
group, and define which traffic replication modes are used with the traffic-replication-type
command.
Configuration
Using the CLI
To configure a traffic replication mode, use the traffic-replication-type command at the service-
group level.
CLI Example
1. The following commands define a VIP on the ACOS device.

ACOS(config)# slb virtual-server NM-VIP 10.10.10.99
2. The following commands configure the real collector servers.

ACOS(config)# slb server RS-1 10.10.20.1
3. The following commands configure a service group for the collector servers and add the real col-
lector servers to the service group. The traffic-replication-type command then specifies traffic
replication mode used to forward duplicated network monitoring traffic to the collector servers.
ACOS(config)# slb service-group SG-RS tcp
ACOS(config-slb svc group)# member RS-1 0
ACOS(config-slb svc group)# traffic-replication-type mirror-da-repl
page 498
Outbound Next Hop Load Distributor
ACOS supports outbound Next Hop Load Distributor (NHLD). Outbound NHLD enables you to balance
client-server traffic across a set of WAN links. In outbound NHLD, the clients are located on the internal
side of the network. The servers are located on the external side of the network.
Figure 72 shows an example of outbound NHLD.
FIGURE 72 Next Hop Load Distributor
In this example, the ACOS 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 ACOS device receives a request from a client, the ACOS device uses SLB load balancing to
select one of the WAN links. ACOS 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.
page 499
When the ACOS device receives the server’s reply to a client request, the ACOS device translates the
destination IP address from the NAT address to the client’s private IP address, then forwards the reply
to the client.
Load Balancing Methods
Use one of the following load balancing methods to load balance traffic across the WAN links:
• Round-robin – Selects link in simple rotation. This results in each link being selected an equal
number of times. The default method is round-robin.
• Least-connections – Selects the link that has the least current client connections on it. The con-
nection count is based on client connections initiated on the link by the ACOS device.
Network Address Translation Requirements
In an outbound NHLD topology, the next-hop routers for the WAN links must be able to send the server
reply traffic back to the ACOS device. To ensure that the server reply traffic passes back through the
ACOS device, use an IP source NAT pool for each WAN link.
The pools do not need to contain more than a few addresses. ACOS 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 NHLD.
Configuring Next Hop Load Distributor

To configure NHLD:
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 ACOS device.
Configure a pool group and add the pools to it.
2. Configure ACOS interfaces connected to the clients. Enable promiscuous VIP support on the inter-
faces.
3. Configure the ACOS 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 load balanced link. Add wildcard ports (TCP, UDP, or both) to the
servers.
Use Layer 3 health checking (ICMP ping) to check router’s IP interface health. When testing a path
through a device between the ACOS device and router, use the ICMP health monitor transparent
option.
page 500
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 ACOS device will mark the ports down and NHLD will not work.
5. Configure a service group for the links (real servers). If the real server configurations for the links
have both TCP and UDP ports, configure a service group for TCP and another service group for
UDP.
6. Configure a virtual server with virtual IP address 0.0.0.0 (the wildcard VIP address). Using the wild-
card VIP address enables the configuration to work for any destination IP address requested by cli-
ents.
Add the wildcard TCP port (TCP 0) and bind it to the TCP service group. Likewise, add the wildcard
UDP port and bind it to the 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.
CLI Example
Commands in this example implement the NHLD configuration shown in Figure 72 on page 499. 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.
1. The following commands configure the IP source NAT pools and pool group:
ACOS(config)# ip nat pool-group outbound-nat-group
ACOS(config-pool-group:outbound-nat-gro)# member nat10
ACOS(config-pool-group:outbound-nat-gro)# member nat20
ACOS(config-pool-group:outbound-nat-gro)# exit
2. The following commands enable promiscuous VIP support on the ACOS interfaces connected to
clients.
3. These commands configure the ACOS interfaces to the next-hop routers for the load-balanced
links:
page 501

4. The following commands configure a real server for each link to be load balanced:
ACOS(config)# slb server link-101 192.168.10.1
ACOS(config)# slb server link-201 192.168.20.1
5. The following commands configure service groups for the links:

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

ACOS(config)# slb virtual-server wildcard-vip 0.0.0.0
ACOS(config-slb vserver-vport)# service-group outbound-tcp-links
ACOS(config-slb vserver-vport)# source-nat pool outbound-nat-group
ACOS(config-slb vserver-vport)# service-group outbound-udp-links
ACOS(config-slb vserver-vport)# source-nat pool outbound-nat-group
page 502

page 503
page 504
HTTP Proxy
This chapter provides an overview of HTTP proxy, configuration resources that are available and how
to configure it.
• Explicit and Transparent HTTP Proxy Overview
• Configuration Resources for HTTP Proxy
• Configuring Transparent HTTP Proxy
• Configuring Explicit HTTP Proxy
• Explicit Proxy Permission with AAM Policy
• Proxy Chaining Overview
• Configuring Proxy Chaining
• Explicit Proxy and Secure Sockets Layer Insight Integration
• Explicit Proxy Authentication Support
Explicit and Transparent HTTP Proxy Overview

A proxy is an agent that acts in place of the original requester. For a transparent proxy, the client is not
aware of the use of a proxy (proxy server). In the case of an explicit proxy, client browsers are config-
ured to send requests to a proxy server, hence the name explicit proxy as the proxy service is known.
When configuring a proxy, the main configuration difference between an explicit proxy and transparent
proxy is that for an explicit proxy, the virtual ip address (VIP) is specified for the slb virtual-server tem-
plate configured with an HTTP virtual port, whereas for a transparent proxy, the virtual server VIP is set
as a wildcard (0.0.0.0) and must have a vport for HTTP and another for HTTPs traffic, and a separate
policy-template for HTTP and HTTPs. Separate service-groups for HTTP and HTTPs are also needed to
correctly route the two types of traffic.
Example of an explicit proxy virtual server template configuration:
slb virtual-server vip 192.0.2.2

port 80 http
service-group sg
template policy https
template dynamic-service ds
page 505
Explicit and Transparent HTTP Proxy Overview
Example of a transparent proxy virtual server template configuration:
slb virtual-server wildcard 0.0.0.0

port 80 http
service-group HTTP
template policy HTTP-policy
template dynamic-service DNS
port 443 https
service-group SSL_8080
template policy SSL-policy
template dynamic-service DNS
template client-ssl SSL
The main configuration element of an HTTP proxy is the policy template where the source rules and
actions are defined in the forward-policy sub-configuration. The template is then binded to an slb vir-
tual-server template with an HTTP virtual port for explicit proxy and transparent proxy, and also an
HTTPs virtual port for transparent proxy.
Explicit and transparent HTTP proxy services can be configured to operate separately, or in parallel.
Proxy services also work in an SSLi configuration (refer to the SSL Configuration Guide for proxy config-
urations related to SSL and SSLi).
You can use the ACOS device as an HTTP proxy to control client access to hosts based on lists of
allowed traffic sources (clients) and destinations (Web servers). In the case of explicit proxies, client
applications, which are typically Web browsers, must explicitly configure the proxy's IP address and
port such that all HTTP requests will be sent to the explicit proxy.
When this feature is enabled, an HTTP virtual port on the ACOS device intercepts HTTP requests from
clients, validates both the sources and the destinations, and forwards only those requests that come
from valid sources and that are sent to approved destinations. Destinations are validated based on
layer 3 IP addresses, HTTP URL/hostname strings or web-category. The policy template specifies the
action to take to handle requests.
The destinations requested by clients can be filtered based on the URL of the request or the hostname
in the Host header of the request.
• If both the source and destination are allowed, ACOS translates the client address into a NAT
address, if applicable, and forwards the request to the destination.
• If either the source or the destination is not explicitly allowed by the applicable source or destina-
tion list, the request is dropped.
There are three mechanisms by which explicit HTTP proxy can forward traffic: traffic may be forwarded
to the Internet, to a specified service group, or to another HTTP proxy server. These configuration sce-
narios are highlighted in this document.
The following differences between an explicit proxy vs. a transparent proxy are:
page 506
Configuration Resources for HTTP Proxy
• An explicit proxy requires that clients are configured to point to the explicit proxy, whereas a
transparent proxy requires no configuration in this regard.
• An explicit proxy offers more flexibility for managing traffic, although at a cost of additional con-
figuration and resources, as you can create multiple VIPs, but can only have one wildcard VIP.
• For a typical transparent proxy configuration, a vport is required for HTTP and another for HTTPs
traffic, configured under an slb virtual-server template. This also means a separate policy
and service-group are needed to handle each type of traffic.
FIGURE 73 Explicit HTTP Proxy Mechanisms: Forward to Service Group and Forward to Internet

To provide precise control, a forward policy defined within the SLB policy template is used to identify
the sources, destinations, and actions for matching traffic. Table 9 describes these resources and how
they are related. For further clarification, see the configuration examples.
page 507
TABLE 9 Configuration Resources for Explicit HTTP Proxy

Resource Purpose Description
Policy Applies actions to Set of rules that define permitted traffic sources and destinations, and
template client-to-server actions to apply to permitted traffic. This is defined within the SLB com-
traffic based on mand.
source and desti-
nation The explicit HTTP proxy relies only on the forward policy to define the
source and destination match criteria, and corresponding actions to
apply. For more information, see the forward policy description.
Forward Specifies permit- Collection of source and destination match rules based on source IP
Policy ted traffic destina- addresses, destination host/URLs of client requests, and actions to
tions and sources apply. Forward policy is a required component when configuring explicit
HTTP proxy. Through this module, you can define the type and scope of
the action desired for outbound traffic.
Source Specify sources (or Source list specifies an IPv4 and/or IPv6 class list used to match a set of
Match Rule clients) IP clients. Each entry in a source class list specifies an IPv4 or IPv6
addresses used to address. Use the match-class-list command to assign one or more
match a forward class lists. To match all source IP addresses, use the match-any com-
policy rule mand.
NOTE: If no source is present, match-any matches all sources, other-

wise it will only be applied if the source does not fall under any other
sources.
Destination Specifies a desti- Matches the destination URL or HOST string present in the HTTP
Match Rule nation match rule, request. The destination class list is of AC string type or IP type and may
corresponding be part of a URL, HOST, or IP address.
action to apply
when there is a If the destination rule matches, the action specified in the rule is applied.
match, and the pri-
ority of the rule The priority of the rule is used to break ties when multiple destination
rules are matched. The higher priority value takes precedence.
NOTE1: Use destination any to match all destinations if no other

destination rule is present or if the destination does not fall under other
rules.
NOTE2: IP type class lists allows import and utilization of Threatstop

files.
page 508
TABLE 9 Configuration Resources for Explicit HTTP Proxy (Continued)

Action Defines the action Actions define what to do with the request and whether to log the
to take corre- event. The scope of the action object is within the forward policy.
sponding to the
matching rule The action can be one of the following: forward-to-internet,
forward-to-service-group, forward-to-proxy, log, or drop.
Source NAT is an optional action that may be applied. In the case
of an upstream proxy server and an SSLi configuration, forward-
to-proxy is used instead of forward-to-internet or forward-to-ser-
vice-group (please refer to proxy chaining in this guide and the SSL
Configuration Guide for more information).
Explicit Intercepts HTTP Virtual port that receives HTTP requests from traffic sources.
HTTP- requests from cli-
proxy port ents This configuration resource consists of a real server configuration, a ser-
vice group, a virtual server, and an HTTP virtual port.
NOTE: If using forward-to-internet as a forwarding mechanism, you

must configure an “Internet” real server and service-group. This can be
thought of as a placeholder configuration which represents the “Internet”
rather than an actual real device. This is an essential component to
ensure feature functionality. Every allowed server port to the Internet
must be configured in the real server and service group. For example,
typically both port 80 and 443 are used for HTTP and HTTPS traffic. Both
ports must be configured in the service group along with a real server
representing the Internet.
Dynamic Provides DNS res- Forward to Internet traffic requires DNS resolution. When the forward-
Service olution when for- to-internet command is used, you must define one or more DNS serv-
Template warding to Internet ers in a dynamic service template to resolve host names to IP addresses.
Fallback Service Group
Optionally, for any approved destinations which the ACOS device cannot resolve, you can serve requests
locally by configuring the following resources:
Real Locally serves con- Standard SLB configuration with real servers and service group, to be
Server(s) tent if called in Forward Policy
and service destination can-
group not be reached
VIP with Receives requests
HTTP vPort to be served locally
NAT Resources
The following resources are required only if sources (clients) require source NAT.
NAT pool Assigns outside Range of public (externally routable) IP addresses to assign to clients
addresses to before forwarding the client traffic to the Internet.
inside clients
Basic network resources, including network interface connections to the sources and destinations, and
DNS servers, also are required.
page 509
Configuring Transparent HTTP Proxy

Basic Transparent Proxy Configuration
A basic transparent proxy configuration requires a configuration to handle HTTP and HTTPs traffic
separately, as HTTPS traffic differs from HTTP traffic in that the traffic is encrypted and requires certif-
icates and keys to handle the back and forth communication. For more information on SSLi configura-
tion, see the SSL Insight Configuration Guide.
The following configuration example shows the basic elements needed to configure a transparent
proxy for the inside device and outside device. This example assumes a basic network has been set up.
Inside Device Configuration
1. A NAT pool is configured for source network address translation (SNAT)

ACOS(config)# ip nat pool NAT 203.0.113.5 203.0.113.5 netmask /32
2. An slb template is configured for DNS resolution so the traffic knows where to go to.
ACOS(config)# slb template dynamic-service DNS
ACOS(config-dynamic-service)# dns server 168.95.1.1
ACOS(config-dynamic-service)# exit
3. Now, the server to handle HTTP and HTTPs (SSL) traffic is configured as well as the service-
groups which we bind the slb server to, through the two separate ports, 80 for HTTP traffic, and
8080 for HTTPs traffic.
ACOS(config)# slb server SSL 192.168.90.142
ACOS(config)# slb service-group HTTP tcp
ACOS(config-slb svc group)# health-check-disable
ACOS(config-slb svc group)# member SSL 80
ACOS(config)# slb service-group SSL_8080 tcp
ACOS(config-slb svc group)# member SSL 8080
4. Import the certificate and key, if they do not already reside on the device.
ACOS(config)# import cert ROOTCA.crt use-mgmt-port tftp://192.168.1.25/ROOT-CA.crt
page 510
Done.
ACOS(config)# import key ROOTCA.key use-mgmt-port tftp://192.168.1.25/ROOT-CA.key
Done
5. Next, a client-ssl template is configured to handle the certificate and key exchange for SSL
(HTTPs) connections for transparent proxy. Note that forward-proxy-enable is only necessary for
SSL Insight configuration to allow inspection through a man-in-the-middle inspection device.
ACOS(config)# slb template client-ssl SSL
ACOS(config-client ssl)# forward-proxy-ca-cert ROOTCA.crt
ACOS(config-client ssl)# forward-proxy-ca-key ROOTCA.key
ACOS(config-client ssl)# forward-proxy-enable
6. The HTTP policy (HTTP-policy) and HTTPs (SSL-policy) are configured where we simply take the
appropriate traffic to its destination through the source and action sub-configurations. The source
network address translation (SNAT), as an action, is an optional component.
ACOS(config)# slb template policy HTTP-POLICY
ACOS(config-policy)# forward-policy
ACOS(config-policy-forward-policy)# action A1
ACOS(config-policy-forward-policy-action)# forward-to-internet HTTP snat NAT
ACOS(config-policy-forward-policy-action)# log
ACOS(config-policy-forward-policy-action)# exit
ACOS(config-policy-forward-policy)# source ANY
ACOS(config-policy-forward-policy-source)# match-any
ACOS(config-policy-forward-policy-source)# destination any action A1
ACOS(config-policy-forward-policy-source)# exit
ACOS(config-policy-forward-policy)# exit
ACOS(config)# slb template policy SSL-POLICY

ACOS(config-policy-forward-policy)# action A1
ACOS(config-policy-forward-policy-action)# forward-to-internet SSL_8080 snat NAT
ACOS(config-policy-forward-policy-source)# destination any action A1
7. Finally, we bind all these elements together in an slb virtual-server template using the wildcard VIP
0.0.0.0, with the HTTP and HTTPs traffic through the 80 and 443 virtual ports respectively.
ACOS(config)# slb virtual-server IN_VIP 0.0.0.0
ACOS(config-slb vserver-vport)# service-group HTTP
ACOS(config-slb vserver-vport)# template policy HTTP-POLICY
ACOS(config-slb vserver-vport)# template dynamic-service DNS
page 511

ACOS(config-slb vserver-vport)# service-group SSL_8080
ACOS(config-slb vserver-vport)# template policy SSL-POLICY
ACOS(config-slb vserver-vport)# template client-ssl SSL
Outside Device Configuration
The configuration for the outside device (or partition), we need the following elements:
1. The slb server and service group are configured to receive HTTP and HTTPs traffic.
ACOS(config)# slb server DEFAULT_GATEWAY 20.1.1.10
ACOS(config)# slb service-group DG_SSL_SG tcp

ACOS(config-slb svc group)# member DEFAULT_GATEWAY 443
ACOS(config)# slb service-group DG_TCP_SG tcp
ACOS(config-slb svc group)# member DEFAULT_GATEWAY 0
The slb template server-ssl is configured for SSL Insight.

ACOS(config)# slb template server-ssl SSLINSIGHT_SERVERSIDE
ACOS(config-server ssl)# forward-proxy-enable
2. The virtual-server binds these components together for the HTTP and HTTPs traffic. The use-rcv-
hop-for-resp is used to ensure correct direction of traffic.
ACOS(config)# slb virtual-server OUTSIDE_VIP 0.0.0.0
ACOS(config-slb vserver-vport)# no-dest-nat port-translation
ACOS(config-slb vserver-vport)# service-group DG_SSL_SG
ACOS(config-slb vserver-vport)# template server-ssl SSLINSIGHT_SERVERSIDE
ACOS(config-slb vserver-vport)# use-rcv-hop-for-resp
page 512
ACOS(config-slb vserver-vport)# service-group DG_TCP_SG

ACOS(config-slb vserver-vport)# use-rcv-hop-for-resp
Configuring Explicit HTTP Proxy
Basic Explicit Proxy Configuration

FIGURE 74 Explicit HTTP Proxy Configuration
The basic configuration is to forward all traffic via Explicit Proxy to the Internet and log each request.
From the CLI

1. Configure network settings such as Ethernet data interfaces, VLANs, and routing so that there is
connectivity between the traffic sources or clients, the destinations (Internet servers and internal
real servers), and DNS servers, as shown in Figure 74.
page 513
2. Create a placeholder internal server and service group.

ACOS(config)# slb server Internet_Server 1.1.1.1
ACOS(config)# slb service-group To_Internet tcp
ACOS(config-slb svc group)# member Internet_Server 80
3. Create a dynamic service template and specify Internet DNS resolvers.

ACOS(config)# slb template dynamic-service DNS
4. Create a Source NAT Pool to use for Internet-bound traffic.

ACOS(config)# ip nat pool Internet_Pool 203.0.113.5 203.0.113.5 netmask /32
5. Create a Forward Policy.

ACOS(config)# slb template policy Explicit_Proxy
6. Create an action for Internet-bound traffic to use the source NAT pool and log the request.
ACOS(config-policy-forward-policy)# action Permit_to_Internet
ACOS(config-policy-forward-policy-action)# forward-to-internet To_Internet snat
Internet_Pool
7. Create match-any source and destination rules.

ACOS(config-policy-forward-policy)# source Any_Source
page 514
ACOS(config-policy-forward-policy-source)# destination any action Permit_to_Internet
8. Create the explicit proxy virtual server to list on port 8080.

ACOS(config)# slb virtual-server EP_VIP 172.16.10.10
ACOS(config-slb vserver-vport)# service-group To_Internet
ACOS(config-slb vserver-vport)# template policy Explicit_Proxy
To make the basic explicit proxy configuration resilient, add a fallback service group to handle cases
when a domain name cannot be resolved. All requests are then forwarded to the configured fallback
service group.
9. Define fallback servers and a fallback service group.

ACOS(config)# slb server Fallback_Server1 10.10.1.20
ACOS(config)# slb server Fallback_Server2 10.10.1.21
ACOS(config)# slb service-group Fallback tcp
ACOS(config-slb svc group)# member Fallback_Server1 80
ACOS(config-slb svc group)# member Fallback_Server2 80
10.Add a different source NAT pool for forwarded requests to the fallback service group.
ACOS(config)# ip nat pool Fallback_Pool 10.10.1.120 10.10.1.120 netmask /24
11.Add fallback service group to the action in the existing SLB template policy, Explicit_Proxy using
step 5 first then the following commands:
Internet_Pool fallback Fallback snat Fallback_Pool
page 515
From the GUI
Configure network settings such as Ethernet data interfaces, VLANs, and routing so that there is con-
nectivity between the traffic sources or clients, the destinations (Internet servers and internal real serv-
ers), and DNS servers, as shown in Figure 74. This example assumes three ethernet interface
connections have been established.
Define ethernet interface settings.
1. Navigate to Network>> Interfaces

2. Click Edit for e1 Interface.
3. Click + in the IP section.
4. In the IP Address field, enter “10.10.1.254”.
5. In the Netmask field, enter “255.255.255.0”.
6. Click Add.
7. Click Update.
8. Click Edit for e2 Interface.
9. Click + in the IP section.
10.In the IP Address field, enter “203.0.113.254”.
11.In the Netmask field, enter “255.255.255.0”.
12.Click Add.
13.Click Update.
14.Click Edit for e3 Interface.
15.Click + in the IP section.
16.In the IP Address field, enter “172.168.0.254”.
17.In the Netmask field, enter “255.255.255.0”.
18.Click Add.
19.Click Update.
Establish IP Routes.
1. Navigate to Network>> Routes
page 516
2. Click + Create.
3. In the IP Dest Address field, enter “0.0.0.0”.
4. In the IP Mask field, enter “/0”.
5. In the IP Next Hop field, enter “203.0.113.1”.
6. Click Add.
8. Click + Create.
9. In the IP Dest Address field, enter “192.168.0.0”.
10.In the IP Mask field, enter “/16”.
11.In the IP Next Hop field, enter “172.16.160.1”.
12.Click Add.
13.Click Create Route.
Create a placeholder internal server.
1. Navigate to Security>> Forward Proxy.

2. Click the Servers tab.
3. Click + Create.
4. In the Name field, enter “Internet_Server”.
5. In the Host field, enter “1.1.1.1”.
6. Click + Add Port.
7. In the Port field, enter “80” and click Apply.
10.Click OK.
Create our virtual server to list on port 8080.
1. Navigate to Security>> Forward Proxy. This should take you to the Services tab.
2. Click + Create.
3. In the Name field, enter “EP_VIP”.
4. In the IPv4 Address field, enter “172.16.10.10”.
page 517
6. In the Port field, enter “8080”.

7. In the Protocol field, select HTTP from the drop-down menu.
Define our Service Group and our server as a member for ports 80 and 443.
1. Click + in the Service Group section.

2. In the Name field, enter “To_Internet”.
3. Click + Add Member.
4. In the Name field, click on the drop-down menu and click on Internet_Server.
7. In the Name field, click on the drop-down menu and click on Internet_Server.
9. Click OK.
Create our internet DNS resolvers by creating a dynamic service template.
1. Click + in the Dynamic Service section.

2. In the Name field, enter “dynamic_service”
3. In the IPv4 DNS Server 1 field, enter “10.10.1.253”.
4. In the IPv4 DNS Server 2 field, enter “10.10.1.254”.
5. Click OK.
Create a Source NAT Pool to use for Internet-bound traffic.
1. Click + in the SNAT Pool section.

2. In the Name field, enter “Internet_Pool”.
3. In the Start Address field, enter “203.0.113.5”.
4. In the End Address field, enter “203.0.113.5”.
5. In the Netmask field, enter “/32”.
6. Click OK.
Create a Forward Policy, and the action policy and source policy to be followed.
1. Click + in the Policy Template section.

2. In the Name field, enter “Explicit_Proxy”.
page 518
3. Click on the Action Policies tab.

4. Click + Add.
5. In the Name field, enter “Permit_to_Internet”.
6. In the Action field, click on the drop-down menu, select Forward Request to Internet and click.
7. In the Service Group field, click on the drop-down menu, and click on To_Internet.
8. In the IPv4 Pool field, click on the drop-down menu, and click on Internet_Pool.
9. Click on the check box next to the Log field to enable logging.
10.Click OK.
11.Click on the Source Policies tab.
12.Click + Add.
13.In the Name field, enter “Any_Source”.
14.In the Match Type field, click on the drop-down menu and click Any.
15.Click + Add.
16.Under Destination Rules, in Match Type, click on the drop-down menu and click Any,
17.In the Action field, click on the drop-down menu and click Permit_to_Internet.
18.Click Apply.
19.Click OK.
20.Click Add Template.
Now, we’ll make our configuration more resilient, by creating a fallback service group to handle cases
when a domain name cannot be resolved. All requests will then be forwarded to the configured fallback
service group. Take the following steps:

2. Click the Servers tab.
3. Click + Create.
4. In the Name field, enter “Fallback_Server1”.
8. Click OK.
9. Click + Create.
page 519
10.In the Name field, enter “Fallback_Server2”.

11.In the Host field, enter “10.10.1.21”.
12.Click + Add Port.
13.In the Port field, enter “80” and click Apply.
14.Click OK.
15.Click on Service Groups tab.
16.Click + Create.
17.In the Name field, enter Fallback.
18.Click + Add Member.
19.In the Name field, click on the drop-down menu and click on Fallback_Server1.
21.Click + Add Member.
22.In the Name field, click on the drop-down menu and click on Fallback_Server1.
24.Click OK.
After creating the fallback servers and service group, edit our existing forward policy.
1. Click on the Templates tab.

2. Click Edit for Explicit_Proxy.
3. Click Action Policies tab if not already there.
4. Click Edit for Permit_to_Internet.
5. In the Fallback SG field, click on the drop-down menu and click on Fallback.
6. In the Fallback IPv4 Pool field, click on +.
7. In the Name field, enter “Fallback_Pool”.
8. In the Start Address field, enter “10.10.1.120”.
9. In the End Address field, enter “10.10.1.139”.
10.In the Netmask field, enter “/24”.
11.Click OK.
12.Click Update.
page 520
Advanced Explicit Proxy Configuration

This configuration example demonstrates the use of specific allowed sources and target destinations
accessing the Internet. An internal service group for providing a software update service is configured,
and denies access to others. This configuration builds upon the basic explicit proxy configuration in the
previous section and follows the topology from Figure 74.
Advanced Explicit Proxy Configuration (CLI)

1. Create a source class list of IPv4 type. Source class lists may be of IPv4 or IPv6 types and are
defined as a list of IP subnets and network masks.
ACOS(config)# class-list Corporate_Clients ipv4
ACOS(config-class list)# 192.168.1.0/24
ACOS(config)# class-list Corporate_Servers ipv4
2. Create destination class lists of Aho-Corasick string type or IP type. For Aho-Corasick string type,
destinations specified may be partial strings matching the HOST field or URL field of an HTTP
request. String match is not case-sensitive.
ACOS(config)# class-list Allowed_Destinations ac
ACOS(config-class list)# contains yahoo
ACOS(config-class list)# contains google
ACOS(config-class list)# contains facebook
ACOS(config-class list)# contains cnn
ACOS(config-class list)# contains disney
ACOS(config-class list)# contains ebay
ACOS(config-class list)# contains bankofamerica
ACOS(config)# class-list Restricted_Destinations ac
ACOS(config-class list)# contains youtube
ACOS(config-class list)# contains netflix
ACOS(config-class list)# contains hulu
ACOS(config)# class-list Internal_Destinations ac
ACOS(config-class list)# contains acme-inc
ACOS(config)# class-list Allowed_Client-urls ac
ACOS(config-class list)# contains news
ACOS(config-class list)# contains finance
page 521
ACOS(config-class list)# contains sports

ACOS(config-class list)# contains entertainment
ACOS(config)# class-list Update_Destinations ac
ACOS(config-class list)# contains update.microsoft
ACOS(config-class list)# contains download.microsoft
ACOS(config-class list)# contains windowsupdate
ACOS(config-class list)# contains archive.linux
ACOS(config-class list)# contains archive.ubuntu
ACOS(config-class list)# contains mirror.ubuntu
ACOS(config-class list)# starts-with 10.10.10.200
ACOS(config)# class-list Forbidden_Destination ipv4
3. Configure software update servers, service groups, and NAT pool to handle forward-to-service-
group and permit-to-internet requests.
ACOS(config)# slb server Update_Server1 10.10.1.31
ACOS(config)# slb server Update_Server2 10.10.1.32
ACOS(config)# slb server Internet_Server 1.1.1.1
ACOS(config)# slb service-group Updates tcp
ACOS(config-slb svc group)# member Update_Server1 80
ACOS(config-slb svc group)# member Update_Server2 80
ACOS(config)# slb service-group To_Internet tcp
page 522
4. Configure forward-to-service-group, Permit-to-Internet, and drop actions.

ACOS(config-policy-forward-policy)# action Default_Deny
ACOS(config-policy-forward-policy-action)# drop
ACOS(config-policy-forward-policy-action)# drop-message "Access is restricted."
ACOS(config-policy-forward-policy)# action Permit_Software-Updates
ACOS(config-policy-forward-policy-action)# forward-to-service-group Updates
ACOS(config-policy-forward-policy)# action Permit_To_Internet
Internet_Pool
5. Modify the source rule to match-any and configure destination to match any for dropping and log-
ging.
ACOS(config-policy-forward-policy)# source Any_Source
ACOS(config-policy-forward-policy-source)# destination any action Default_Deny
6. Configure a source rule and add up to two source class lists as a single match rule to a forward
policy. Multiple source match rules may be configured per forward policy using the OR clause.
ACOS(config-policy-forward-policy)# source Allowed_Clients
ACOS(config-policy-forward-policy-source)# match-class-list Corporate_Clients
ACOS(config-policy-forward-policy)# source Allowed_Servers
ACOS(config-policy-forward-policy-source)# match-class-list Corporate_Servers
7. Add one or more destination class lists as matching rules for a specific source class rule. Up to
1024 destination rules may be added to a single source match rule. The default action for non-
matching destination match rules is to drop the request.
ACOS(config-policy-forward-policy-source)# destination class-list Allowed_Destinations
action Permit_To_Internet host priority 100
ACOS(config-policy-forward-policy-source)# destination class-list Internal_Destinations
action Permit_Software-Updates host priority 200
ACOS(config-policy-forward-policy-source)# destination class-list Allowed_Client-urls
page 523
action Permit_To_Internet url priority 300

ACOS(config-policy-forward-policy-source)# destination class-list Update_Destinations
ACOS(config-policy-forward-policy-source)# destination class-list
Restricted_Destinations action Default_Deny host priority 500
ACOS(config-policy-forward-policy-source)# destination class-list Forbidden_Destination
action Default_Deny ip priority 600
For creating a forward policy, go to the forward-policy sub-command for configuration of the various
types of templates. Templates and parameters are elaborated upon here.
Source Rule (source) – Defines the match rule for the traffic sources. The source sub-command
within forward policy names the source rule. Multiple source rules may be defined in a forward policy.
But only a single source rule of match-any may be defined for a forward policy. IP addresses in multiple
configured source class-lists configured for a forward policy cannot overlap.
• match-class-list – IPv4 or IPv6 class list that specifies hosts or subnets for matching source
rules.
• match-any - default match rule if no other specific class list is matched.
Destination Rule (destination)– The destination rule is associated with a source rule and defines
either a specific class-list or default match-any. A unique destination class for a particular source rule.
• Destination Class-List (class-list) – Class list that contains the URL or hostname strings or
IP range for destinations that clients are allowed to access.
• Destination Web-Category-List (web-category-list) - Category list that contains predefined web-
site URLs for destinations that clients are allowed to access.
• priority – This is used to break ties when there are multiple destination rules that match the
traffic such that only a single destination rule’s action is applied to the traffic. The higher value
takes priority over the lower value. The priority value is unique per source rule.
• action – Defines where to forward the packet upon receipt of request and whether to log the
event.
• Action type – Defines how traffic will be forwarded, can be drop, forward-to-internet, for-
ward-to-service-group or forward-to-proxy. Note that these are mutually exclusive
actions. Multiple actions may be configured under a single policy. Forward-to-proxy should
be used in the case of an upstream proxy server to ensure proper proxy information is not
lost during communication.
page 524
• Drop message (drop-message) - When a request is dropped, a message is displayed. A default

“Access to this site is blocked by administrator” message appears if no text is provided.
• Drop and redirect url (drop-redirect-url) - When a request is dropped, the client request is redi-
rected to another specified URL. For the http-status-code, the default is 302 Found.
• Source NAT (snat) – Previously configured NAT pool. This is an optional component.
• Fallback (fallback) – Forwards traffic to a fallback service group if the ACOS device is unable
to reach the destination and relies on a previously configured service group.
• Log (log) – HTTP requests forwarded or dropped can be logged to the external and/or internal
syslog servers using this command.
No Client Connection Reuse (no-client-conn-reuse) – Configure this option only when the HTTP/
HTTPS client will not send multiple requests to different destinations over the same TCP connection
between the client and the ACOS device. Most modern web browsers have connection reuse enabled
by default thus this setting typically doesn’t apply when clients are web browsers. In this mode, the
explicit proxy inspects only the first HTTP request after a TCP connection is established and applies
the forward policy. All subsequent requests on that TCP connection are not inspected and are tunneled
directly to the same destination. This mode is designed for higher performance.
NOTE
• The web-category license file must be imported and then enable must be invoked prior to the use
of category-list within the web-category sub-configuration.
• Commands drop-message and drop-redirect-url are mutually exclusive actions. If both are
entered, the prior command will be overwritten by the more recent one.
Advanced Explicit Proxy Configuration (GUI)
This configuration builds upon the basic explicit proxy configuration in the previous section and follows
the topology from Figure 74. Take the following steps:
Create a source class list of IPv4 type. Source class lists may be of IPv4 or IPv6 types and are defined
as a list of IP subnets and network masks.

2. Click on Class List tab, and click Configuration.
3. Click + Create.
4. In the Name field, enter “Corporate_Clients”.
5. In the IPv4 Address field, enter “192.168.1.0/24” and click Add.
6. Go back to IPv4 Address field, enter “192.168.2.0/24” and click Add.
7. Go back to IPv4 Address field, enter “172.16.0.0/16” and click Add.
8. Click OK.
page 525
9. Click + Create.
10.In the Name field, enter “Corporate_Servers”.
11.In the IPv4 Address field, enter “10.10.1.10/32” and click Add.
12.Go back to IPv4 Address field, enter “10.10.1.11/32” and click Add.
13.Go back to IPv4 Address field, enter “10.10.1.12/32” and click Add.
14.Click OK.
Create destination class lists of Aho-Corasick string type. Destinations specified may be partial strings
matching the HOST field or URL field of an HTTP request. String match is not case-sensitive.
1. Ensure you are in Security>> Forward Proxy>> Class Lists. If not, follow steps 1 and 2 in the prior
section.
2. Click + Create.
3. In the Name field, enter “Allowed_Destinations”.
4. In the Type field, click the Aho Corasick button.
5. In AC (Aho Corasick) empty field, enter “yahoo” and click Add.
6. Go back to this field, enter “google” and click Add.
7. Go back to this field, enter “facebook” and click Add.
8. Go back to this field, enter “cnn” and click Add.
9. Go back to this field, enter “disney” and click Add.
10.Go back to this field, enter “ebay” and click Add.
11.Go back to this field, enter “bankofamerica” and click Add.
12.Click OK.
13.Click + Create.
14.In the Name field, enter “Restricted_Destinations”.
15.In the Type field, click the Aho Corasick button.
16.In AC (Aho Corasick) empty field, enter “youtube” and click Add.
17.Go back to this field, enter “netflix” and click Add.
18.Go back to this field, enter “hulu” and click Add.
19.Go back to this field, enter “cnn” and click Add.
20.Go back to this field, enter “disney” and click Add.
21.Go back to this field, enter “ebay” and click Add.
page 526
22.Go back to this field, enter “bankofamerica” and click Add.

23.Click OK.
24.Click + Create.
25.In the Name field, enter “Internal_Destinations”.
27.In AC (Aho Corasick) empty field, enter “acme-inc” and click Add.
28.Click OK.
29.Click + Create.
30.In the Name field, enter “Allowed_Client-urls”.
32.In AC (Aho Corasick) empty field, enter “news” and click Add.
33.Go back to this field, enter “finance” and click Add.
34.Go back to this field, enter “sports” and click Add.
35.Go back to this field, enter “entertainment” and click Add.
36.Click OK.
37.Click + Create.
38.In the Name field, enter “Update_Destinations”.
40.In AC (Aho Corasick) empty field, enter “update.microsoft” and click Add.
41.Go back to this field, enter “download.microsoft” and click Add.
42.Go back to this field, enter “windowsupdate” and click Add.
43.Go back to this field, enter “archive.linux” and click Add.
44.Go back to this field, enter “archive.ubuntu” and click Add.
45.Go back to this field, enter “mirror.ubuntu” and click Add.
46.Click on the Type drop-down menu, and click Starts With.
47.In AC (Aho Corasick) empty field, enter “10.10.10.200” and click Add.
48.Click OK.
Create a destination IP type class list for use.
1. Click + Create.
page 527
2. In the Name field, enter “Forbidden_Destinations”.

3. In the Type field, click the IPv4 button.
4. In the IPv4 Address field, enter “198.51.100.0/24” and click Add.
5. Click OK.
Configure software update servers and service group to handle forward-to-service-group requests.
1. Click on Servers tab.

2. Click + Create.
3. In the Name field, enter “Update_Server1”.
7. Click OK.
8. Click + Create.
9. In the Name field, enter “Update_Server2”.
13.Click OK.
Create our service group for the update servers we created.
1. Click on Service Groups tab.

2. Click + Create.
3. In the Name field, enter “Updates”.
5. Click on the Name drop-down menu and click Update_Server1.
8. Click on the Name drop-down menu and click Update_Server2.
10.Click OK.
page 528
Edit our Explicit_Proxy policy with new actions.
1. Click on Templates tab.

2. Click Edit for our existing Explicit_Proxy policy.
3. Under the Action Policies tab, click + Add.
4. In the Name field, enter “Default-Deny”.
5. Click on the Action drop-down menu, and click on Drop.
6. In the Drop Message field, enter “Access is restricted.”
7. Click the check box for Logging.
8. Click OK.
9. Click Update.
10.Click Edit for our existing Explicit_Proxy policy.
11.Click + Add to create another action.
12.In the Name field, enter “Permit_Software-Updates”.
13.Click on the Action drop-down menu, and click on Forward Request to Service Group.
14.Click on the Service Group drop-down menu, and click Updates.
15.Click the check box for Logging.
16.Click OK.
17.Click Update.
Next, modify our existing source policy to add our new action policy, Default_Deny.
1. Click on Source Policies tab.

2. Click Edit for Any_Source.
3. Click Edit for our Destination Rules Any.
4. Click on the Action drop-down menu, click on Default_Deny, and click Apply.
5. Click Update.
Next, create destination rules under a new source policy for our created Corporate_Clients.
1. Click on + Add.
2. In the Name field, enter “Allowed_Clients”.
3. Click on the Match Type drop-down menu and click on Class List.
4. Click on the Class List drop-down menu and click on Corporate_Clients.
page 529
5. In Destination Rules, click + Add.

6. Click on the Destination Rules Match Type drop-down menu, and click on Class List.
7. Click on the Value drop-down menu, and click on Allowed_Destinations.
8. Click on the Action drop-down menu, and click on Permit_to_Internet.
9. Click on the Match drop-down menu, and click on Host.
10.In the Priority field, enter “100”.
11.Click Apply.
12.In Destination Rules, click + Add.
13.Click on the Destination Rules Match Type drop-down menu, and click on Class List.
14.Click on the Value drop-down menu, and click on Internal_Destinations.
15.Click on the Action drop-down menu, and click on Permit_Software-Updates.
16.Click on the Match drop-down menu, and click on Host.
18.Click Apply.
21.Click on the Value drop-down menu, and click on Allowed_Clients-urls.
22.Click on the Action drop-down menu, and click on Permit_to_Internet.
23.Click on the Match drop-down menu, and click on URL.
25.Click Apply.
28.Click on the Value drop-down menu, and click on Update_Destinations.
29.Click on the Action drop-down menu, and click on Permit_to_Internet.
32.Click Apply.
page 530
35.Click on the Value drop-down menu, and click on Restricted_Destinations.
36.Click on the Action drop-down menu, and click on Default-Deny.
39.Click Apply.
40.Click Update.
43.Click on the Value drop-down menu, and click on Forbidden_Destinations.
44.Click on the Action drop-down menu, and click on Default-Deny.
45.Click on the Match drop-down menu, and click on IP.
47.Click Apply.
48.Click Update.
Next, we create a source policy for our Corporate_Servers and add a destination rule.
1. Click on + Add.
2. In the Name field, enter “Allowed_Servers”.
3. Click on the Match Type drop-down menu and click on Class List.
4. Click on the Class List drop-down menu and click on Corporate_Servers.
5. In Destination Rules, click + Add.
6. Click on the Destination Rules Match Type drop-down menu, and click on Class List.
7. Click on the Value drop-down menu, and click on Update_Destinations.
8. Click on the Action drop-down menu, and click on Permit_to_Internet.
9. Click on the Match drop-down menu, and click on Host.
11.Click Apply.
12.Click OK.
page 531
Explicit Proxy Permission with AAM Policy

An explicit proxy can be configured to use aam authorization policy to determine user and group mem-
bership. Configuration is done at the source level of a forward-policy, where a source rule can have an
aam authorization policy bound to it through the match-authorize-policy command. Use the priority
command to determine the order of which configured match-authorize-policy should be checked within
an slb template policy. For more information about the CLI commands, refer to “forward-policy” in the
SLB Policy Template section of the Command Line Interface Reference for ADC.
For explicit proxy client authentication using form-based-logon in an SSLi set up in conjunction with
this feature, to ensure the explicit proxy client authentication occurs, configure “match-any” or “match-
class-list” in the source rule so it matches the first request in the slb policy template.
AAM must initially be configured. If configuring AAM with an explicit proxy or AAM with an explicit
proxy + SSLi configuration, the authentication logon methods supported are: HTTP basic, NTLM, Ker-
beros and Form Based. SAML is not supported. For more information about AAM configuration, see the
Application Access Management Guide.
The following is an example of Windows Integrated Authentication (WIA), using Kerberos and NTLM for
authentication and Lightweight Directory Access Protocol (LDAP) for authorization.
Note: This example assumes a PC has been set up as a WIA user-agent.
Configuration Example
1. Configure a NAT pool, EP_NAT, for use with explicit proxy.

ACOS(config)# ip nat pool EP_NAT 192.168.92.111 192.168.92.111 netmask /32
2. To set up an explicit proxy, a service group is needed as a stub. So a dummy server and service-
group are created, EP_DUMMY, in addition to the real server and service group.
ACOS(config)# slb server EP_DUMMY 10.0.0.1
ACOS(config)# slb service-group EP_DUMMY tcp
ACOS(config-slb svc group)# member EP_DUMMY 80
ACOS(config)# slb server HTTP_PROXY 192.168.98.199
ACOS(config)# slb service-group PROXY_GROUP tcp
ACOS(config-slb svc group)# member HTTP_PROXY 80
page 532
3. A basic forward policy, using the stub EP_DUMMY and the NAT pool are configured.
ACOS(config)# slb template policy EP_FORWARD_1
ACOS(config-policy-forward-policy)# action TO_INET
ACOS(config-policy-forward-policy-action)# forward-to-internet EP_DUMMY snat EP_NAT
ACOS(config-policy-forward-policy-source)# destination any action TO_INET
4. Set up the explicit proxy, using the service-group and our policy.
ACOS(config)# slb virtual-server EP 192.168.91.110
ACOS(config-slb vserver-vport)# service-group EP_DUMMY
ACOS(config-slb vserver-vport)# template policy EP_FORWARD_1
5. AAM is set up for Kerberos authentication, by configuring an aam authentication server along with
the appropriate supporting aam templates and policies.
For WIA Kerberos, the logon type must use http-authenticate, and auth-method must be config-
ured as negotiate.
ACOS(config)# aam authentication logon http-authenticate NEGO
ACOS(config-http-authenticate auth logon:...)# auth-method negotiate enable
ACOS(config-http-authenticate auth logon:...)# exit
6. For WIA Kerberos, the user-agent that will access our vport must be a member of the realm.
ACOS(config)# aam authentication server windows KDC
ACOS(config-windows auth server:KDC)# host 192.168.221.50
ACOS(config-windows auth server:KDC)# auth-protocol ntlm-disable
ACOS(config-windows auth server:KDC)# realm EXAMPLEREALM.COM
ACOS(config-windows auth server:KDC)# exit
7. For WIA Kerberos, a service principal name (SPN), is needed for the key distribution center (KDC),
and requires the following: the KDC realm, account of the SPN owner, and the SPN name. So, if we
define the SPN as axproxy.examplerealm.com, the user-agent must use axproxy.example-
realm.com as the name of the explicit proxy.
ACOS(config)# aam authentication account kerberos-spn SPN
ACOS(config-kerberos-spn:SPN)# realm EXAMPLEREALM.COM
ACOS(config-kerberos-spn:SPN)# account Owner
ACOS(config-kerberos-spn:SPN)# service-principal-name HTTP/axproxy.examplerealm.com
ACOS(config-kerberos-spn:SPN)# password PASSWORD
page 533
ACOS(config-kerberos-spn:SPN)# exit
8. We configure an aam authentication template for WIA Kerberos. An additional template is config-
ured specifically for tracking session use, using auth-sess-mode.
ACOS(config)# aam authentication template NEGO_KRB_C
ACOS(config-auth template:NEGO_KRB_C)# logon NEGO
ACOS(config-auth template:NEGO_KRB_C)# server KDC
ACOS(config-auth template:NEGO_KRB_C)# account SPN
ACOS(config-auth template:NEGO_KRB_C)# exit
ACOS(config)# aam authentication template NEGO_KRB_I
ACOS(config-auth template:NEGO_KRB_I)# auth-sess-mode ip-based
ACOS(config-auth template:NEGO_KRB_I)# logon NEGO
ACOS(config-auth template:NEGO_KRB_I)# server KDC
ACOS(config-auth template:NEGO_KRB_I)# account SPN
ACOS(config-auth template:NEGO_KRB_I)# exit
9. Next, we configure LDAP, starting with configuring aam authentication server.

ACOS(config)# aam authentication server ldap AD_LDAP
ACOS(config-ldap auth server:AD_LDAP)# host 192.168.230.101
ACOS(config-ldap auth server:AD_LDAP)# base cn=Users,dc=examplerealm,dc=com
ACOS(config-ldap auth server:AD_LDAP)# admin-dn cn=Administrator,cn=Users,dc=example-
realm,dc=com
ACOS(config-ldap auth server:AD_LDAP)# admin-secret PASSWORD
ACOS(config-ldap auth server:AD_LDAP)# exit
10.We create our authorization server configuration that is added to the aam aaa-policy
NEGO_KRB_authen (step 11) and NTLM_NTLM_authen (step 19) with aam authorization policy
SERVER_PROVIDER. To set the aam authorization policy as a server provider, the
forward-policy-authorize-only configuration is added.
ACOS(config)# aam authorization policy SERVER_PROVIDER
ACOS(config-authorization policy:SERVER_P...)# server AD_LDAP
ACOS(config-authorization policy:SERVER_P...)# forward-policy-authorize-only
ACOS(config-authorization policy:SERVER_P...)# exit
11.The aam template is then bound to the aaa-policy and configured to provide the authorization
server, SERVER_PROVIDER, for our forward-policy through the authorize-policy command. This
policy is added to the explicit proxy.
ACOS(config)# aam aaa-policy NEGO_KRB_authen
ACOS(config-aaa policy:NEGO_KRB_authen)# aaa-rule 10
ACOS(config-aaa policy:NEGO_KRB_authen-aa...)# authentication-template NEGO_KRB_I
ACOS(config-aaa policy:NEGO_KRB_authen-aa...)# authorize-policy SERVER_PROVIDER
ACOS(config-aaa policy:NEGO_KRB_authen-aa...)# exit
ACOS(config-aaa policy:NEGO_KRB_authen)# exit
ACOS(config-slb vserver-vport)# aaa-policy NEGO_KRB_authen
page 534
12.We configure two authorization policies, each with their own attribute values for use with AAM
check for the explicit proxy’s forward policy.
ACOS(config)# aam authorization policy GROUP_INET
ACOS(config-authorization policy:GROUP_I...)# attribute-rule 1
ACOS(config-authorization policy:GROUP_I...)# server AD_LDAP
ACOS(config-authorization policy:GROUP_I...)# attribute 1 memberOf attr-type string sub-
string CN=INET
ACOS(config-authorization policy:GROUP_I...)# exit
ACOS(config)# aam authorization policy GROUP_PROXY_NEED
ACOS(config-authorization policy:GROUP_PR...)# attribute-rule 1
ACOS(config-authorization policy:GROUP_PR...)# server AD_LDAP
ACOS(config-authorization policy:GROUP_PR...)# attribute 1 memberOf attr-type string
sub-string CN=PROXY_NEED
ACOS(config-authorization policy:GROUP_PR...)# exit
13.Now, the forward policy is configured. The default source drops all requests, while our defined
source GROUP_INET and GROUP_PROXY are routed through the use of the match-authorize-pol-
icy. The command priority is used to determine the order for authorization checking and can-
not be the same value, unless it is the default value of zero.
Checks are determined through the sequence:
Check class-list
Sources that have a specific class-list, but no match are removed.
Check remaining sources that have an authorize-policy. Use priority to determine authorization
checking.
If source passes authorization, the source is selected.
If using the GUI for configuration, during policy template creation (navigate to Security>>Forward
Proxy>>Templates, click Create and select Policy), when creating a source policy, in the Authoriza-
tion Policy field, select an existing authorization policy, and enter a priority value in the Priority field.
ACOS(config)# slb template policy EP_FORWARD_3
ACOS(config-policy-forward-policy)# action DROP
ACOS(config-policy-forward-policy)# action TO_INET
ACOS(config-policy-forward-policy-action)# forward-to-internet EP_DUMMY snat EP_NAT
ACOS(config-policy-forward-policy)# action TO_PROXY
ACOS(config-policy-forward-policy-action)# forward-to-proxy PROXY_GROUP
page 535

ACOS(config-policy-forward-policy-source)# destination any action DROP
ACOS(config-policy-forward-policy)# source GROUP_INET
ACOS(config-policy-forward-policy-source)# match-authorize-policy GROUP_INET
ACOS(config-policy-forward-policy-source)# priority 1000
ACOS(config-policy-forward-policy-source)# destination any action TO_INET
ACOS(config-policy-forward-policy)# source GROUP_PROXY_NEED
ACOS(config-policy-forward-policy-source)# match-authorize-policy GROUP_PROXY_NEED
ACOS(config-policy-forward-policy-source)# priority 999
ACOS(config-policy-forward-policy-source)# destination any action TO_PROXY
14.The policy is added to our explicit proxy.

ACOS(config-slb vserver-vport)# aaa-policy NEGO_KRB_authen
15.LDAP authorization needs to be configured through an aaa-policy, using the configured authenti-
cation-template and authorize-policy configured under aaa-rule. This policy is then added to the
explicit proxy.
ACOS(config)# aam aaa-policy NEGO_KRB_authen_LDAP_authz
ACOS(config-aaa policy:NEGO_KRB_authen_)# aaa-rule 10
ACOS(config-aaa policy:NEGO_KRB_authen_-a...)# authentication-template NEGO_KRB_I
ACOS(config-aaa policy:NEGO_KRB_authen_-a...)# authorize-policy GROUP_INET
ACOS(config-aaa policy:NEGO_KRB_authen_-a...)# exit
ACOS(config-aaa policy:NEGO_KRB_authen_)# aaa-rule 256
ACOS(config-aaa policy:NEGO_KRB_authen_-a...)# action deny
ACOS(config-aaa policy:NEGO_KRB_authen_-a...)# exit
ACOS(config-aaa policy:NEGO_KRB_authen_)# exit
ACOS(config-slb vserver-vport)# aaa-policy NEGO_KRB_authen_LDAP_authz
16.AAM is set up for NTLM authentication, by configuring an aam authentication server along with
the appropriate supporting aam templates and policies.
page 536
For WIA NTLM, the logon type must use http-authenticate, and auth-method must be ntlm.
ACOS(config)# aam authentication logon http-authenticate NTLM
ACOS(config-http-authenticate auth logon:...)# auth-method ntlm enable
ACOS(config-http-authenticate auth logon:...)# exit
17.The authentication server windows is configured.

ACOS(config)# aam authentication server windows NTLM
ACOS(config-windows auth server:NTLM)# host 192.168.230.101
ACOS(config-windows auth server:NTLM)# auth-protocol kerberos-disable
ACOS(config-windows auth server:NTLM)# exit
18.We configure an aam authentication template. An additional template is configured specifically for
tracking session use, using auth-sess-mode.
ACOS(config)# aam authentication template NTLM_NTLM_C
ACOS(config-auth template:NTLM_NTLM_C)# logon NTLM
ACOS(config-auth template:NTLM_NTLM_C)# server NTLM
ACOS(config-auth template:NTLM_NTLM_C)# exit
ACOS(config)# aam authentication template NTLM_NTLM_I
ACOS(config-auth template:NTLM_NTLM_I)# auth-sess-mode ip-based
ACOS(config-auth template:NTLM_NTLM_I)# logon NTLM
ACOS(config-auth template:NTLM_NTLM_I)# server NTLM
ACOS(config-auth template:NTLM_NTLM_I)# exit
19.The aaa policy is configured for NTLM authentication and NTLM-LDAP authorization. The
NTLM_NTLM_authen aam aaa-policy is also configured to provide the authorization server for the
forward-policy by using authorize-policy SERVER_PROVIDER, just as it was done for Kerberos
(step 11).
ACOS(config)# aam aaa-policy NTLM_NTLM_authen
ACOS(config-aaa policy:NTLM_NTLM_authen)# aaa-rule 10
ACOS(config-aaa policy:NTLM_NTLM_authen-a...)# authentication-template NTLM_NTLM_I
ACOS(config-aaa policy:NTLM_NTLM_authen-a...)# authorize-policy SERVER_PROVIDER
ACOS(config-aaa policy:NTLM_NTLM_authen-a...)# exit
ACOS(config-aaa policy:NTLM_NTLM_authen)# v
ACOS(config)# aam aaa-policy NTLM_NTLM_authen_LDAP_authz
ACOS(config-aaa policy:NTLM_NTLM_authen)# aaa-rule 10
ACOS(config-aaa policy:NTLM_NTLM_authen-a...)# authentication-template NTLM_NTLM_I
ACOS(config-aaa policy:NTLM_NTLM_authen-a...)# authorize-policy GROUP_INET
ACOS(config-aaa policy:NTLM_NTLM_authen-a...)# exit
ACOS(config-aaa policy:NTLM_NTLM_authen)# exit
20.The aaa policies are added to the explicit proxy.

ACOS(config-slb vserver-vport)# aaa-policy NTLM_NTLM_authen
page 537

ACOS(config-slb vserver-vport)# aaa-policy NTLM_NTLM_authen_LDAP_authz
Optionally, in the aam authorization policy, the command forward-policy-authorize-only may be

included as part of the configuration so that the authorization policy provides only server information
for configured forward policies, as shown in step 10 of the example.
Using the GUI, to allow only server information for forward policies, when creating an authorization pol-
icy (navigate to AAM>>Policies and Templates, select Authorization Policies, and click Create), select
the Forward Policy Authorize Only checkbox.
Limitations
• Only LDAP and RADIUS servers can be used to obtain membership information.
• Authorization policies can be configured at a global level under an aaa-policy or at a source level
under a forward-policy.
• Only one server or service group is allowed per template policy to obtain membership informa-
tion.
• Any server or service-group configuration in an authorization policy template that is linked to a
forward-policy template at a source level is ignored.
• SAML authentication logon is not supported.
Explicit Proxy URL Filtering

In addition to using a destination class-list, an object called category-list is available through the web-
category configuration/feature. This allows control over an entire web category rather than having to
enter every website or URL. Defined category-lists and updated policies are provided below to illustrate
the use of url filtering. This example builds upon the advanced explicit proxy configuration in the initial
section and assumes the library for web-category has been enabled.
Explicit Proxy URL Filtering Configuration (CLI)

1. Create a category-list from the web-category configuration for use as, in addition to, or as a
replacement for destination class lists. This supplements or replaces step 2 in Advanced Explicit
Proxy Configuration (CLI).
ACOS(config)# web-category
ACOS(config-web-category)# category-list Finance_Sites
ACOS(config-web-category-category-list)# financial-services
ACOS(config-web-category-category-list)# business-and-economy
ACOS(config-web-category-category-list)# exit
ACOS(config-web-category)# category-list Search_Sites
ACOS(config-web-category-category-list)# search-engines
page 538
ACOS(config-web-category-category-list)# internet-portals
ACOS(config-web-category)# exit
Display the web-category-list configurations with the show runnning-config web-category command:
ACOS(config)# show running-config web-category

!
web-category
category-list Finance_Sites
financial-services
business-and-economy
category-list Search_Sites
search-engines
internet-portals
2. Similar to destination class lists, destination web-category-lists can be used in the source class
rule, either supplementing or replacing them. Below is a modified version that replaces the source
configuration in step 7 of theAdvanced Explicit Proxy Configuration (CLI) example where we
replace the destination class-list rules with the destination web-category-list rules.
ACOS(config-policy-forward-policy-source)# destination web-category-list Finance_Sites
ACOS(config-policy-forward-policy-source)# destination class-list Internal_Destinations
action Permit_Software-Updates host priority 200
ACOS(config-policy-forward-policy-source)# destination class-list Allowed_Client-urls
action Permit_To_Internet url priority 300
ACOS(config-policy-forward-policy-source)# destination web-category-list Search_Sites
action Default_Deny host priority 500
ACOS(config-policy-forward-policy-source)# destination class-list Forbidden_Destination
action Default_Deny ip priority 600
page 539
Explicit Proxy URL Filtering Configuration (GUI)
Create a category list from pre-existing lists under web-category. These lists can be used in addition to,
or as a replacement for destination class lists shown in the Advanced Explicit Proxy Configuration
(GUI). A valid webroot license is required, and web categories must be enabled for this feature to work.
An example for creating two category lists follow. Take the following steps:
1. Navigate to Security>> Web Categories.

2. In the Category List section, click + Create.
3. In the Name field, enter “Finance_Sites”.
4. In the Categories section, click on the business-and-economy and financial-services check boxes.
5. Click OK.
6. Click Update.
7. In the Category List section, click + Create.
8. In the Name field, enter “Search_Sites”.
9. In the Categories section, click on the internet-portals and search-engines check boxes.
10.Click OK.
11.Click Update.
Similar to destination class lists, category-lists from Web Categories can be used in the source class
rule, either supplementing or replacing them. For a source policy destination rule, to use a category list
from web category, choose Web Category for the Destination Rules Match Type instead of Class List.
Below is an example showing the steps to modify the destination rules for source policy Allowed_Cli-
ents in the Advanced Explicit Configuration GUI example of existing destination class lists with cate-
gory lists.

3. Click Edit for Explicit_Proxy policy.
4. Click on Source Policies tab.
5. Click Edit for Allowed_Clients.
6. Click on Edit for the Destination Rules with a Priority of 100.
7. Click on the Destination Rules Match Type drop-down menu, and click on Web Category.
8. Click on the Value drop-down menu and click on Finance_Sites.
9. Click Apply.
page 540
10.Click on Edit for the Destination Rules with a Priority of 500.

11.Click on the Destination Rules Match Type drop-down menu, and click on Web Category.
12.Click on the Value drop-down menu and click on Search_Sites.
13.Click Apply.
14.Click Update.
Logging
HTTP requests handled by this feature can be logged based on the outcome of the request:
• Permitted
• Denied (dropped)
• DNS failure or SNAT failure
Message Examples
Here are some examples of log messages for the explicit HTTP-proxy feature. Each of them shows
information about an HTTP request intercepted by the HTTP virtual port.
The following requests are from source (client) 31.31.31.15. The client IP address is translated to NAT
address 41.41.41.99. ACOS replaces the source IP address of requests with this NAT address before
forwarding them to the destinations. The three cases shown below for drop, forward to service group,
and forward to Internet.
Drop:
Apr 01 2015 14:16:47 Info [ACOS]:Proxy GET [drop- (s1 priority#1)]:www.a4.com url http:/
/31.31.31.15 from 31.31.31.10:14993, to 0.0.0.0:0
Forward to service-group:
Apr 01 2015 14:16:44 Info [ACOS]:Proxy GET [server- (s1 priority#500)]:www.a3.com url
http://31.31.31.15 from 31.31.31.10:65518, snat 41.41.41.99:2194 to 41.41.41.20:80
Apr 01 2015 14:16:44 Info [ACOS]:Proxy GET [select-server- (s1 priority#500)]:www.a3.com
url http://31.31.31.15 from 31.31.31.10:65518, to 0.0.0.0:0
Forward to internet:
Apr 01 2015 14:16:40 Info [ACOS]:Proxy GET [internet- (s1 priority#1024)]:www.a1.com url
http://31.31.31.15 from 31.31.31.10:59605, snat 41.41.41.99:2185 to 20.20.20.22:80
In the case when a web category is found, it will also appear in the log message.
Log Message Format

Log messages for the explicit HTTP-proxy feature show the following fields:
timestamp severity [module]:feature method [action -(filter)]:host url url_text from

source_ip:source_port, snat snat_ip:snat_port to destination_ip:destination_port
page 541
Table 10 describes the fields from the Log Message Format.
TABLE 10Log Message Field Descriptions

Field Description
timestamp System time on the ACOS device when the message was generated.
severity Message severity level.
module/feature System module and feature.
method HTTP method, typically get, post, connect.
action Action performed on the request: internet (forward to Internet), or drop.
filter Source rule name, priority (rule) number within that group that matched the request.
Category web-category listed if applicable. A “-1” is returned if nothing is found.
host Destination host or domain name of the request.
url url_text URL of the request.
from source_ip:source_port Source IP address and protocol port of the request.
snat snat_ip:snat_port If source NAT was provided, the NAT IP address and pool that ACOS assigned to the
source before forwarding the request. (If no source NAT was provided, this field shows
“snat 0.0.0.0:0 to 0.0.0.0:0”.)
to destination_ip:destina- Destination IP address and protocol port of the request.
tion_port
Displaying HTTP Explicit Proxy Statistics

Statistics for HTTP explicit proxy can be displayed using the CLI or GUI.
From the CLI
To display statistics for HTTP explicit proxy, use the show slb http-proxy command. The following
shows a sample output for show slb http-proxy.
ACOS(config)# show slb http-proxy

Total
------------------------------------------------------------------
Curr Proxy Conns 0
Total Proxy Conns 7
HTTP requests 7
HTTP requests(succ) 7
HTTP requests(CONNECT) 0
HTTP requests enter SSLi 0
HTTP req (cache succ) 0
No proxy error 0
Client RST 0
Server RST 0
No tuple error 0
Parse req fail 0
Server selection fail 0
Fwd req fail 0
Fwd req data fail 0
page 542
Req retransmit 0
Req pkt out-of-order 0
Server reselection 0
Server premature close 0
Server conn made 7
Source NAT failure 0
Tot data before compress 0
Tot data after compress 0
Request over limit 0
Request rate over limit 0
Close on DDoS 0
From the GUI
To display statistics for HTTP explicit proxy, take the following steps:

2. Click on the Statistics tab.
3. Click on HTTP Proxy tab, if not already selected.
Displaying Statistics for Forward Policy

Statistics for Forward Policy can be displayed using the CLI or GUI.
From the CLI
To display forward policy statistics, use the show slb template policy forward-policy-stats com-
mand:
The statistics display the following fields:
• Requests dropped
• Source NAT failure
• Unresolved DNS requests
• Outstanding DNS requests
The following shows a sample output for show slb template policy forward-policy-stats.
ACOS(config)# show slb template policy forward-policy-stats
slb template policy name: explicit-proxy-fwd-policy

Source NAT failure: 0
Unresolved DNS requests: 329
Outstanding DNS requests: 369
page 543
From the GUI
To display the statistics for the forward policy from the GUI, take the following steps:

3. Click on the Policy tab.
4. In the Policy Template field, use the search function to locate your forward policy template.
5. The statistics for your policy template is displayed. Click Refresh to update or Clear to clear out the
existing statistics.
Displaying or Clearing Learned Cache Entries

To display learned DNS cache entries, use the show dns-cache command. The following is a sample
output.
ACOS(config)# show dns-cache
Record Name A/CNAME Record DNS Server TTL
www.a10networks.com 50.112.95.73 192.168.1.50 15

ajax.googleapis.com 216.58.192.42 192.168.1.50 125
netapp.com 137.135.69.133 192.168.1.50 280
www.ietf.org 104.20.0.85 192.168.1.50 298
www.netapp.com 172.231.39.203 192.168.1.50 1
api.demandbase.com 54.201.118.54 192.168.1.50 45
www.google.com 74.125.239.113 192.168.1.50 207
cloud.typography.com 23.205.66.110 192.168.1.50 5
ietf.org 4.31.198.44 192.168.1.50 1787
assets.adobedtm.com 23.205.61.17 192.168.1.50 5
To clear learned cache entries, use the clear dns-cache command:
Displaying HTTP Explicit Proxy Web-Category Category-Lists Counters

Counters for HTTP Web Category Lists can be displayed using the CLI or GUI.
From the CLI
To display HTTP Explicit Proxy web-category counters, use the command show counters web-category
category-list. The number of hits is displayed for all the various categories.
The following is a partial sample output using category-list search that contains the social network cat-
egory configured in Explicit Proxy URL Filtering Configuration (CLI):
page 544
Proxy Chaining Overview
ACOS(config)# show counters web-category category-list Search-Sites

uncategorized category hits 0
real estate category hits 0
computer and internet security category hits 0
financial services category hits 0
business and economy category hits 0
computer and internet info category hits 0
auctions category hits 0
shopping category hits 0
cult and occult category hits 0
travel category hits 0
drugs category hits 0
adult and pornography category hits 0
home and garden category hits 0
military category hits 0
social network category hits 3
dead sites category hits 0
stock advice and tools category hits 0
training and tools category hits 0
dating category hits 0
sex education category hits 0
religion category hits 0
entertainment and arts category hits 0
...
From the GUI
Take the following steps:
1. Navigate to Security>> Web Categories.

3. Click Category Hits tab if not already there.
4. Use the search function to locate your category list.
5. Click Refresh, and all the web categories from your category list is displayed with the number of
hits.

Proxy chaining is the involvement of two or more proxy servers where requests go from one proxy
server to another proxy server, hence the term proxy chaining. When a configuration involves the ACOS
device as an explicit proxy, the HTTP header is modified. This is problematic for requests going to
another upstream explicit proxy server, as the packet is then dropped. This is resolved from the for-
ward-policy configuration in a policy template, using the forward-to-proxy command to keep the origi-
nal HTTP header intact. The ACOS device requires a configuration that specifies proxy chaining in an
page 545
SLB server policy template as an action as well as an SLB template that specifies the upstream proxy
server’s ip address and port for handling traffic.
Proxy chaining can also be applied to an upstream explicit proxy in an SSLi configuration. Information
on this configuration can be found in the SSL Configuration Guide.
page 546
Configuring Proxy Chaining
Explicit HTTP Proxy Configuration with Upstream Proxy Server (Proxy Chaining)
FIGURE 75 Explicit HTTP Proxy Configuration with Upstream Proxy Server (Proxy Chaining)
The following configuration steps are necessary to set up a proxy-chaining environment, using the
“Basic Explicit Proxy Configuration” on page 513 and “Advanced Explicit Proxy Configuration” on
page 521 set up as our initial template.
From the CLI

1. Create an SLB template to define your upstream proxy server and service group. In our case, here,
the upstream proxy-server has been configured with the ip address of 192.168.111.10 and port
3128.
page 547
ACOS(config)# slb server proxy-server 192.168.111.10

ACOS(config)# slb service-group psg-3128 tcp
ACOS(config-slb svc group)# member proxy-server 3128
2. Our forward-policy would change to go to the proxy server by using service group psg-3128 in the
forward-to-proxy command, replacing forward-to-internet To_Internet snat Internet_Pool in
step 6 in “Basic Explicit Proxy Configuration” on page 513.
ACOS(config-policy-forward-policy-action)# forward-to-proxy psg-3128 snat Internet_Pool
From the GUI
The upstream proxy-server is configured with IP address of 192.168.111.10 and port 3128. Edit the
existing Explicit_Proxy policy template with the proxy server information and service group. by taking
these steps:

3. Click Edit for Explicit_Proxy policy.
4. Click Edit for Permit_to_Internet action policy.
5. Click on Action drop-down menu, and click Forward Request to Proxy.
6. In the Service Group field, click +.
7. In the Name field, enter “psg-3128”.
9. In the Name field, click + to add a server.
10.In the Name field, enter “proxy-server”.
13.In the Port field, enter “3128”. click Apply, then click OK.
page 548
Explicit Proxy and Secure Sockets Layer Insight Integration
14.In the Port field for Service Group, enter “3128”. click Apply, then click OK.
15.In the IPv4 Pool field, select Internet_Pool.
16.Click the Logging check box to enable logging.
17.Click Update.
Explicit Proxy and Secure Sockets Layer Insight

Integration
Explicit Proxy with Secure Sockets Layer Insight (SSLi) has been integrated to function together as one
logical entity. Information on this can be found in the “Static-Port SSLi with Explicit and Transparent
Proxy” in the SSL Configuration Guide.
Explicit Proxy Authentication Support

Application Access Management can be applied to an explicit proxy server. Information on this can be
found in “Tracking Sessions” in the Application Access Management Guide.
page 549
Explicit Proxy Authentication Support
page 550
Explicit FTP Proxy
This chapter provides an overview of explicit FTP proxy, configuration resources that are available, and
how to configure it.
• Explicit FTP Proxy Overview
• Configuration Resources for Explicit FTP Proxy
• Configuring Explicit FTP Proxy
Explicit FTP Proxy Overview

An ACOS device can be configured to provide explicit FTP proxy services. It operates similar to Explicit
HTTP Proxy (page 505). Through a policy template, it manages client access to hosts based on lists of
allowed traffic sources (clients) and destinations (FTP servers). It also provides these services in an
SSLi configuration (See SSL Configuration Guide for SSL and SSLi configuration). An aaa-policy can be
configured for authentication, but is not required.
When this feature is enabled, an FTP virtual port on the ACOS device intercepts FTP requests from cli-
ents, validates both the sources and the destinations, and forwards only those requests that come
from valid sources and that are sent to approved destinations. Destinations are validated based on
layer 3 IP address, and hostname strings. For approved destinations, the ACOS device performs DNS
lookups to obtain the IP addresses.
The destinations requested by clients can be filtered based on the hostname in the request’s Host
header.
• If both the source and destination are allowed, ACOS translates the client address into a NAT
address, if applicable, and forward the request to the destination.
• If either the source or the destination is not explicitly allowed by the applicable source or destina-
tion list, the request is dropped.
There are three mechanisms by which explicit FTP proxy can forward traffic: traffic may be forwarded
to the Internet, to a specified service group, or to another explicit proxy server.
Known Limitations
ACOS can be configured as an FTP load balancer (see “FTP Load Balancing” on page 155) or as an
explicit FTP proxy. It cannot function as both. Explicit SSL/TLS FTP only works with passive mode.
page 551
Configuration Resources for Explicit FTP Proxy
Explicit FTP Proxy Feature Differentiation
Explicit FTP Proxy differs from Secure FTP proxy (see “Secure FTP Proxy” on page 357) in the following
ways:
Secure FTP proxy
• FTP client provides only one pair of username/password for the FTP server.
• FTP client does not provide real FTP server address through FTP command
Explicit FTP Proxy
• FTP client can provide two username/password pairs, one for the FTP proxy and one for the FTP
server.
• FTP client provides the real FTP server address with FTP commands (SITE/OPEN/USER...)
• Works with web-category-list
• Active FTP support

To provide precise control, a forward policy defined in the SLB policy template is used to identify the
sources, destinations, and actions for matching traffic. Table 11 describes these resources and how
they are related.
TABLE 11Configuration Resources for Explicit FTP Proxy

Policy Applies actions to Set of rules that define permitted traffic sources and destinations, and
template client-to-server actions to apply to permitted traffic. This is defined within the SLB com-
traffic based on mand.
source and desti-
nation The explicit ftp proxy relies only on the forward policy to define the
source and destination match criteria, and corresponding actions to
apply. For more information, see the forward policy description.
Forward Specifies permit- Collection of source and destination match rules based on source IP
Policy ted traffic destina- addresses, destination hosts of client requests, and actions to apply. For-
tions and sources ward policy is a required component when configuring explicit FTP
proxy. Through this module, you can define the type and scope of the
action desired for outbound traffic. The no-client-reuse command is
ignored by explicit FTP proxy.
page 552
TABLE 11Configuration Resources for Explicit FTP Proxy (Continued)

Source Specify sources (or Source list specifies an IPv4 and/or IPv6 class list used to match a set of
Match Rule clients) IP clients. Each entry in a source class list specifies an IPv4 or IPv6
addresses used to address. Use the
match a forward match-class-list command to match the source IP.
policy rule
The match-any command is ignored if configured under ftp-proxy.
Destination Specifies a desti- When specifying a class-list or web-category-list for destination match-
Match Rule nation match rule, ing, the following parameters are available:
corresponding
action to apply host - ftp proxy will check the real FTP server’s hostname
when there is a
match, and the pri- URL - ftp proxy ignores this parameter as URL is not applicable.
ority of the rule
IP - If a class-list is specified, the IP parameter option is available.
If the destination rule matches, the action specified in the rule is applied.
The priority of the rule is used to break ties when multiple destination
rules are matched. The higher priority value takes precedence.
Action Defines the action Actions define what to do with the request and whether to log the event.
to take corre- The scope of the action object is within the forward policy.
sponding to the
matching rule The action can be one of the following: forward-to-internet,
forward-to-service-group, forward-to-proxy, log, or drop.
Source NAT is an optional action that may be applied. In the case of an
upstream proxy server and an SSLi configuration, forward-to-proxy is
used instead of forward-to-internet or forward-to-service-group.
Explicit Intercepts FTP Virtual port that receives FTP requests from traffic sources.
FTP-proxy requests from cli-
port ents This configuration resource consists of a real server configuration, a ser-
vice group, a virtual server, and an FTP-proxy virtual port.
If using forward-to-internet as a forwarding mechanism, configure an

“Internet” real server and service-group. This can act as a placeholder
configuration which represents the “Internet” rather than an actual real
device. This is an essential component to ensure feature functionality.
Every allowed server port to the Internet must be configured in the real
server and service group. For example, typically port 21 is used for FTP
traffic. Ports must be configured in the service group along with a real
server representing the Internet.
Dynamic Provides DNS res- Forward to Internet traffic requires DNS resolution. When the forward-
Service olution when for- to-internet command is used, you must define one or more DNS serv-
Template warding to Internet ers in a dynamic service template to resolve host names to IP addresses.
page 553
Configuring Explicit FTP Proxy
TABLE 11Configuration Resources for Explicit FTP Proxy (Continued)

Real Locally serves con- Standard SLB configuration with real servers and service group, to be
Server(s) tent if destination called in Forward Policy
and service cannot be reached
group
VIP with Receives requests
FTP vPort to be served locally
NAT Resources
The following resources are required only if sources (clients) require source NAT.
NAT pool Assigns outside Range of public (externally routable) IP addresses to assign to clients
addresses to before forwarding the client traffic to the Internet.
inside clients
AAM Resources
The following resources are required only for authentication through aaa-policy.
AAA-policy Authenticates the Supports LDAP, RADIUS, and WINDOWS (NTLM/KERBEROS). Bind the
user through use aaa-policy at the virtual port configuration level. Explicit FTP proxy only
of aam authentica- checks the
tion server bound aaa-policy for authentication server configuration information.
to authentication-
template. If an aaa-policy is assigned in the virtual port, the explicit FTP proxy
expects the client to provide the username/password for the proxy. If
aaa-policy is not configured, the explicit FTP proxy waits for the SITE/
OPEN/USER command, then connects to the FTP server.
Basic network resources, including network interface connections to the sources and destinations and
DNS servers, are also required.

Basic FTP Proxy Configuration
• Configure a real FTP server
• Configure port with port number and service type as TCP
• Configure service-group for real FTP server(s) and add to the group as members
• Configure virtual server
• Configure virtual port with port number and service type as ftp-proxy
• For SSL Offload, bind the client-ssl template at the virtual port configuration level.
page 554
Explicit FTP Proxy
• Configure policy template
• Configure AAA-policy
• Configure dynamic service template
• Bind the policy, dynamic-service templates and aaa-policy at the virtual port sub-configuration
level.
Example Configuration (CLI)
1. Create an access list to use as part of an aaa-rule in aam aaa-policy my-aaa-policy.

ACOS(config)# access-list 2 permit 192.0.2.0 0.0.0.0
2. Create a source class list of IPv4 type. Source class lists may be of IPv4 or IPv6 types and are
defined as a list of IP subnets and network masks.
ACOS(config)# class-list cl-internet ipv4
3. Create a web-category-list to apply as part of source-destination configuration for policy.

ACOS(config)# web-category
ACOS(config-web-category)# category-list Wrong
ACOS(config-web-category-category-list)# hacking
ACOS(config-web-category-category-list)# illegal
ACOS(config-web-category)# exit
4. Configure the FTP server and service group to handle requests.

ACOS(config)# slb server ftp-server 198.51.100.0
ACOS(config)# slb service-group sg tcp
ACOS(config-slb svc group)# member ftp-server 21
5. Configure actions for source matching.

ACOS(config)# slb template policy policy-template
ACOS(config-policy-forward-policy)# action drop
ACOS(config-policy-forward-policy)# action act-internet
ACOS(config-policy-forward-policy-action)# forward-to-internet sg snat NAT
ACOS(config-policy-forward-policy)# action act-sg
page 555
ACOS(config-policy-forward-policy-action)# forward-to-service-group sg snat NAT
6. Configure the source match rules and actions to apply based on the match and priority.
ACOS(config-policy-forward-policy)# source src-internet
ACOS(config-policy-forward-policy-source)# match-class-list cl-internet
ACOS(config-policy-forward-policy-source)# destination any action act-internet
ACOS(config-policy-forward-policy)# source bad-dest
ACOS(config-policy-forward-policy-source)# destination web-category-list Wrong action
drop host priority 100
ACOS(config-policy-forward-policy)# source src-sg
ACOS(config-policy-forward-policy-source)# destination any action act-sg
7. Configure the aam authentication servers. An LDAP and RADIUS server are configured in this
example.
ACOS(config)# aam authentication server ldap ldap
ACOS(config-ldap auth server:ldap)# host 203.0.113.72
ACOS(config-ldap auth server:ldap)# base ou=People,dc=mdept,dc=com
ACOS(config-ldap auth server:ldap)# dn-attribute uid
ACOS(config-ldap auth server:ldap)# exit
ACOS(config)# aam authentication template ldap-ex
ACOS(config-auth template:ldap-ex)# server ldap
ACOS(config-auth template:ldap-ex)# exit
ACOS(config)# aam authentication server radius rad-svr2
ACOS(config-radius auth server:rad-svr2)# host 203.0.113.71
ACOS(config-radius auth server:rad-svr2)# secret example
ACOS(config-radius auth server:rad-svr2)# exit
ACOS(config)# aam authentication template rad-ex
ACOS(config-auth template:rad-ex)# server rad-svr2
ACOS(config-auth template:rad-ex)# exit
8. Create a dynamic service template and specify Internet DNS resolver.

ACOS(config)# slb template dynamic-service ds
9. Create the aam aaa-policy which contains the authentication servers that were created.
ACOS(config)# aam aaa-policy my-aaa-policy
ACOS(config-aaa policy:my-aaa-policy)# aaa-rule 1
ACOS(config-aaa policy:my-aaa-policy-aaa ...)# access-list 2
ACOS(config-aaa policy:my-aaa-policy-aaa ...)# authentication-template ldap-ex
ACOS(config-aaa policy:my-aaa-policy-aaa ...)# exit
page 556
ACOS(config-aaa policy:my-aaa-policy)# aaa-rule 2

ACOS(config-aaa policy:my-aaa-policy-aaa ...)# authentication-template rad-ex
ACOS(config-aaa policy:my-aaa-policy-aaa ...)# exit
ACOS(config-aaa policy:my-aaa-policy)# exit
10.Ensure the aaa-policy, template policy and dynamic service templates are bound under the ftp-
proxy virtual port.
ACOS(config)# slb virtual-server ftp-vip 192.168.91.105
ACOS(config-slb vserver)# port 21 ftp-proxy
ACOS(config-slb vserver-vport)# service-group sg
ACOS(config-slb vserver-vport)# aaa-policy my-aaa-policy
ACOS(config-slb vserver-vport)# template policy policy-template
ACOS(config-slb vserver-vport)# template dynamic-service ds
Basic FTP Proxy Configuration through the GUI:
1. Configure a real FTP server

a. Navigate to ADC>>SLB.
b. Click on the Servers tab.
c. Click Create.
d. Enter the name “ftp-server” in the Name field.
e. Enter host “198.51.100.0” in the Host field.
2. Configure port with port number and service type as ftp
a. In the Port section, click Create.
b. In the Port Number field, enter the port number “21”.
c. In the Protocol drop-down list, select TCP.
d. Click Create.
e. Click Update (to complete server creation process).
3. Configure service-group for real FTP server(s) and add to the group as members
a. From ADC>>SLB>>, click on the Service Groups tab.
b. Click Create
c. Enter the name “sg” in the Name field.
d. In the Member section, click Create.
e. In the Server drop-down list, select the ftp-server “ftp-server”.
page 557
f. In the port field, enter the port number “21”.

g. Click Create.
4. Configure virtual server
a. From ADC>>SLB>>, click on the Virtual Servers tab.
b. Click Create.
c. Enter the name “ftp-vip” for the virtual server in the Name field.
d. Enter the IP address “192.168.91.105” for the virtual server in the IP Address field.
5. Configure virtual port with port number and service type as ftp-proxy.
a. In the Virtual Port section, click Create.
b. In the Protocol drop-down list, select FTP Proxy.
c. In the Port field, enter the port “21”.
d. In the Service Group field, select the service group “sg”.
e. Click Create.
6. For SSL Offload, bind the client-ssl template at the virtual port configuration level.
See the SSL Insight Configuration Guide for information about SSL configuration.
a. Click Edit for the newly created Virtual Port.
b. Expand the Templates section by clicking on +.
c. In the Template Client SSL drop-down list, select an existing client-SSL template, or click + to
create a new one.
d. Click Update when configuration is done.
e. Click Update to finish configuring the virtual server.
Explicit FTP Proxy Template Configuration and Binding
1. Configure policy template

a. Navigate to Security>>Forward Proxy>> and click on the Templates tab.
b. Click on Create and select Policy.
c. In the Name field, enter the name “policy-template” for the policy template.
d. With the Action Policies tab selected, click Add.
e. In the Name field, enter the name of the Action.
f. In the Action drop-down list, select the Action to take when source policies are applied.
page 558
g. When configuration is done, click OK.

h. Click the Source Policies tab.
i. Click Add.
j. In the Name field, enter the name of the Source Policy.
k. Click Add to configure Destination Rules.
l. After configuration is complete, click OK.
2. Configure AAA-policy
a. Navigate to AAM>>Policies and Templates.
b. Click on the Authentication Templates tab.
c. Click Create
d. In the Name field, enter the name “ldap-ex” for the authentication template.
e. Click on New Authentication Server.
f. Select the Authentication Server type “LDAP” from the Type drop-down list and click Next.
g. In the Name field, enter the name “ldap” for the authentication server.
h. Configure any additional settings and click Create.
i. Click Update.
j. Click on the AAA Policies tab.
k. Click Create
l. In the Name field, enter the name “my-aaa-policy” for the AAA policy.
m. In the Virtual Port Bindings list, select the virtual server/virtual port, “ftp-vip 21+ftp-proxy”.
n. Click Create.
o. In the AAA Rules section, click Create to add AAA rules to the AAA policy.
Note: To create access lists for use with AAA Rules, Navigate to Security>>Access List.
p. Click Create when done with configuring AAA rules.
q. Click Update.
3. Configure dynamic service template
a. Navigate to Security>>Forward Proxy, and click on the Templates tab.
b. Click on Create and select Dynamic Service.
c. In the Name field, enter the name “dynamic-service” for the dynamic service template.
page 559
d. In the IPv4 DNS Server 1 field, enter “203.0.113.50” for the DNS server.
e. Click OK.
4. Bind the policy template and dynamic service template to the virtual port.
a. Navigate to ADC>>SLB and click on the Virtual Servers tab.
b. Click Edit for “vip-ftp”, our virtual server.
c. In the Virtual Port section, click Edit on the configured virtual port.
d. Expand the Templates section by clicking on +.
e. In the Template Policy list, select the policy template “policy-template” to bind to the virtual port.
f. In the Dynamic Service list, select the dynamic service template “dynamic-service” to bind to the
virtual port.
g. Click Update to complete configuration update to virtual port.
h. Click Update to complete configuration update to virtual server.
Displaying and Clearing SLB FTP Proxy Statistics

The following shows steps from the CLI and GUI to show ftp-proxy statistics and clear the counters.
From the CLI
The following example shows output from the show slb ftp-proxy command.
ACOS# show slb ftp-proxy

Total
------------------------------------------------------------------
Current proxy conns 0
Total proxy conns 0
Current Data Proxy 0
Total Data Proxy 0
Total FTP Request 0
Server selection failure 0
no route failure 0
source nat failure 0
feat packet 0
clear ctrl port packet 0
data ssl force 0
request line freed 0
invalid start line 0
auth tls cmd 0
prot cmd 0
pbsz cmd 0
page 560
open cmd 0
site cmd 0
user cmd 0
pass cmd 0
quit cmd 0
port cmd 0
cant find port 0
eprt commnad 0
cant find eprt 0
other cmd 0
line too long 0
client auth tls 0
pasv cmd 0
cant find pasv 0
psv addr != svr 0
smp create fail 0
data svr conn fail 0
data send fail 0
epsv command 0
cant find epsv 0
Unsupported auth 0
adat cmd 0
Unsupported PBSZ 0
Unsupported PROT 0
Umsupported cmd 0
Control chn clear txt 0
Control chn ssl 0
Bad Sequence 0
Serv Sel Persist fail 0
Serv Sel SMPv6 fail 0
Serv Sel SMPv4 fail 0
Serv Sel ins tpl fail 0
Client EST state erro 0
Serv CTNG state erro 0
Serv RESP state erro 0
Client RQ state erro 0
Data Start state erro 0
Data Serv CTNG erro 0
Data Serv CTED erro 0
Auth Request 0
Auth Success 0
Auth Failure 0
Forward to Internet 0
Forward to Service-group 0
page 561
Drop 0
Resolved Host Name 0
Unresolved Host Name 0
The clear slb ftp-proxy command clears the counters that appear in the show slb ftp-proxy output
From the GUI:
To view FTP Proxy statistics, take the following steps:
1. Navigate to Security>>Forward Proxy, and click the Statistics tab.

2. Next, click on the FTP Proxy tab.
To clear the FTP proxy statistics, click on Clear.
page 562
Redirection of Traffic to ICAP Servers
• ICAP Support Overview

• Configuring ICAP
ICAP Support Overview

ACOS supports Internet Content Adaptation Protocol (ICAP) services on HTTP and HTTPS sessions. In
other words, ACOS supports configuring ACOS devices to conform to ICAP client recommendations in
RFC 3507.
Figure 76 below shows a sample ICAP topology. On traffic from the client to the Web server, ICAP typi-
cally serves to provide data loss prevention (DLP). Whereas, on traffic from the Web server to the client,
ICAP typically provides anti-virus (AV) services.
FIGURE 76 ICAP Support Network Topology
Configuring ICAP
Before you can configure your network for ICAP, you must select where to provision your network with
ACOS devices acting as forward proxy servers. That is, in order to intercept HTTP and HTTPS sessions
as the man-in-the-middle and use ICAP services, forward proxy is a prerequisite.
page 563
Configuring ICAP
• Deployment overviews and configuration instructions for the ACOS man-in-the-middle SSL
Insight (SSLi) application are provided in the SSL Insight Configuration Guide.
• For detailed information on configuring ICAP in an SSLi deployment, see the “Redirection of SSLi
Sessions to ICAP Servers” chapter of the SSL Insight Configuration Guide.
page 564
Redirection of Traffic to Thales HSM Devices
• Thales HSM Device Support Overview

• Installing the Thales HSM SDK
• Configuring Thales HSM
Thales HSM Device Support Overview

ACOS supports the use of Thales Hardware Security Module devices for HTTPS acceleration.
Figure 77 below shows a sample Thales HSM topology. On traffic from the client to the Web server, the
ACOS device is proxy for SSL offloading. Then the ACOS device communicates with the Thales HSM
during the SSL handshake to use information stored in the Thales HSM Device.
FIGURE 77 Thales HSM Device Support Network Topology
page 565
Installing the Thales HSM SDK

Before you can begin configuring Thales HSM Device Support, you must install the Thales HSM SDK on
the ACOS device. To do so, you can do the following:
• Generate a Certificate and Key on a Thales Client
• Import Files and Back up the ACOS Device
• Install Thales HSM SDK on a x86_64 Linux Machine
• Install Thales HSM SDK into the Current Backup System File
• Restore from the Backup on the ACOS Device
Generate a Certificate and Key on a Thales Client

Complete these steps on a Thales client, such as the RFS device if it is also configured as a Thales cli-
ent.
1. Generate a certificate and key

# /opt/nfast/bin/generatekey embed
protect: Protected by? (token, module) [token] > module
size: Key size? (bits, minimum 1024) [1024] > 2048
OPTIONAL: pubexp: Public exponent for RSA key (hex)? []
>
embedsavefile: Filename to write key to? []
> thalesssl
plainname: Key name? [] > thalesssl
x509country: Country code? [] > JP
x509province: State or province? [] > Tokyo
x509locality: City or locality? [] > Minato-ku
x509org: Organisation? [] > Example Org
x509orgunit: Organisation unit? [] > Example Org
x509dnscommon: Domain name? [] > exampleorg.local
x509email: Email address? [] > [email protected]
nvram: Blob in NVRAM (needs ACS)? (yes/no) [no] > no
digest: Digest to sign cert req with? (md5, sha1, sha256, sha384, sha512)
[default sha1] > sha256
key generation parameters:
operation Operation to perform generate
....
Key successfully generated.
Path to key: /opt/nfast/kmdata/local/key_embed_3bc9163a04389defc9bd4db0675149e03368250
2. Run rfs-sync.
# /opt/nfast/bin/rfs-sync --update
3. List the ssl certificates and keys:
page 566
# ls thalesssl*
thalesssl thalesssl_req thalesssl_selfcert
# key file : thalesssl cert file : thalesssl_selfcert
Import Files and Back up the ACOS Device

Complete the following steps on the ACOS device.
1. Import the Thales certificate and key that have been generated by a Thales client into the ACOS
device (where 192.168.213.78 is a Thales client):
ACOS# import cert thalesssl_selfcert use-mgmt-port scp://192.168.213.78/opt/nfast/
kmdata/local/thalesssl_selfcert
ACOS# import key thalesssl use-mgmt-port scp://192.168.213.78/opt/nfast/kmdata/local/
thalesssl
2. Use the backup system command to save a backup file to a x86_64 Linux machine (where
10.6.12.201 is the Linux machine).
ACOS# backup system use-mgmt-port scp://10.6.12.201/tmp/acos_backup.tar
Install Thales HSM SDK on a x86_64 Linux Machine

Complete the following steps on the Linux machine.
1. Change directories to the tmp directory (where tmp is the directory where the backup file is saved)
# cd /tmp
2. Extract the Thales SDK files from the mounted media to the current directory.
# tar -xvf /media/iso/linux/libc6_11/amd64/nfast/ctls/agg.tar -C ./
# tar -xvf /media/iso/linux/libc6_11/amd64/nfast/hwcrhk/user.tar -C ./ <== For SSL
# tar -xvf /media/iso/linux/libc6_11/amd64/nfast/hwsp/agg.tar -C ./
# tar -xvf /media/iso/linux/libc6_11/amd64/nfast/pkcs11/user.tar -C ./ <== For DNSSEC
3. Create a directory named a10data/partner.

# mkdir -p a10data/partner
4. Copy the extracted SDK files into a10data/partner.

# cp -rf opt/nfast a10data/partner/
5. Touch a file with the name a10data/partner/install.

# touch a10data/partner/install
Install Thales HSM SDK into the Current Backup System File
Complete the following steps on the Linux machine.
1. Install THales HSM SDK into current backup system file (file size increases after issuing the com-
mand):
# tar cvf acos_backup.tar a10data -C /
page 567
Restore from the Backup on the ACOS Device

Complete the following steps on the ACOS device.
1. Restore backup system file including Thales HSM SDK.

ACOS(config)# restore use-mgmt-port scp://10.6.12.201/tmp/acos_backup.tar
2. Reboot.
ACOS# reboot
Configuring Thales HSM

Configure the HSM template to include the IP addresses of the hardware security module and the
remote file system, and the protection type to match the HSM settings.
ACOS(config)# hsm template example_name thalesHSM

ACOS(config-template:example_name)# hsm-ip 192.168.213.130
ACOS(config-template:example_name)# rfs-ip 192.168.213.78
ACOS(config-template:example_name)# protection ocs
ACOS(config-template:example_name)# exit
Configure the SLB server to communicate on port 80 tcp.
ACOS(config)# slb server web-server 10.10.101.88

Configure the SLB service group and add the web server as a member.
ACOS(config-real server)# slb service-group web-server tcp

ACOS(config-slb svc group)# member web-server 80
Configure the client SSL template and bind the HSM template and cert/key for TLS sessions with cli-
ents. Only client-side SSL is supported.
ACOS(config)# slb template client-ssl ssl-ct

ACOS(config-client ssl)# template hsm example_name
ACOS(config-client ssl)# cert thalesssl_selfcert
ACOS(config-client ssl)# key thalesssl
Configure the SLB virtual server IP. Both IPv4 and IPv6 addresses are supported. Only HTTPS and SSL-
proxy virtual port type are supported. Bind the service group and client SSL template to the virtual port.
ACOS(config)# slb virtual-server ssl 10.10.100.180
page 568

ACOS(config-slb vserver-vport)# service-group web-server
ACOS(config-slb vserver-vport)# template client-ssl ssl-ct
ACOS(config-slb vserver-vport)# end
A reboot is necessary to use the imported Thales certificate and key:
ACOS# reboot
Depending on the number of keys stored on the RFS, it will take several minutes to synchronize infor-
mation between the ACOS device and the Thales RFS and to be ready to handle SSL traffic after a
reboot.
page 569
page 570
Part VI Part VI
Logging
This section contains topics pertaining to logging server load balancing activities.
• “Web Logging for HTTP and RAM Caching” on page 573

• “Real-Time Logging for Failed Server Selection” on page 583
Web Logging for HTTP and RAM Caching
This chapter describes the ACOS support for logging to external servers over TCP.
ACOS supports web logging for HTTP virtual ports, which can be used with HTTP load balancing or
RAM caching. Web logging for load-balanced HTTP servers provides data about client access to serv-
ers. Web logging for RAM caching provides information about client access to content cached on the
ACOS device.
Web logging to external log servers is supported over TCP and UDP. Logging over TCP is applicable to
web logging for HTTP virtual ports. The rest of this chapter describes this use of the feature.
Log Message Format

Web logs generated by the ACOS device use the following format:
Client-Src-IP -- Timestamp-on-ACOS-device Request-info Payload-length

Referer-info User-agent Virtual-server-name:Virtual-port
Here is an example:
20.20.20.23 - - Mon Apr 23 23:38:13 2012 "GET / HTTP/1.0" 177

"-" "Wget/1.12 (linux-gnu)" vs:80
This example uses a default log string. See “Log String Customization” on page 578 for instructions on
configuring custom log strings.
Configuration
To configure web logging:
1. Create a server configuration for each log server. On each server, add a TCP port with the port
number on which the log server listens for log messages.
2. Add the log servers to a service group. Make sure to use the round-robin load-balancing method.
(This is the default method.)
3. (Optional) Configure a TCP-proxy template to customize TCP settings for connections between the
ACOS device and log servers. For example, keepalive probes can be enabled to ensure TCP con-
page 573
Configuration
nections with log servers remain established during idle periods between logs. (See CLI example
below.)
4. Configure a logging template. Add the service group containing the log servers to the logging tem-
plate. If you configure a custom TCP-proxy template, also add that template to the logging tem-
plate.
5. To log web traffic sent to load-balanced HTTP servers, create a custom HTTP template and add
the logging template to it.
6. To log web traffic served from the ACOS device’s local RAM cache, create a custom RAM Caching
template and add the logging template to it.
7. On the VIP, add the HTTP or RAM Caching template (or both) to the HTTP virtual port.
Using the GUI
This section describes the GUI steps related to logging templates. The configuration steps for the real
servers, service groups, and VIPs are the same as without use of logging templates.
Configuring a Logging Template
1. Hover over ADC in the menu bar, then select Template.

2. Click the General tab.
3. Click Create and select Logging from the drop-down menu.
5. Select the service group that contains the log servers.
6. If a custom TCP-proxy template for logging is configured, select it from the TCP Proxy list.
7. Click OK.
Applying a Logging Template to an HTTP Template

2. Click the L7 Protocols tab.
3. Click Create and select HTTP from the drop-down menu.
5. Select the logging template from the drop-down list in the Logging Template field.
6. Click OK.
Applying a Logging Template to a RAM Caching Template
page 574
Configuration
2. Click the Applications tab.

3. Click Create and select RAM Caching from the drop-down menu.
5. Select the logging template from the drop-down list in the Logging Template field.
6. Click OK.
Using the CLI
Configuring a Logging Template
To configure a logging template, use the slb template logging command to change the CLI to the
configuration level for the template, where the service-group command is available to specify the
name of the service group that contains the log servers.
This template tcp-proxy command specifies the name of the TCP-proxy template to use for managing
TCP sessions between the ACOS device and the log servers.
Applying a Log Template to an HTTP Template
Use the template logging command at the configuration level for the HTTP template:
Applying a Log Template to a RAM Caching Template
Use the template logging command at the configuration level for the RAM Caching template:
CLI Example
The following commands configure web logging for an IPv4 virtual port and an IPv6 virtual port. On
each virtual port, web logging is enabled both for HTTP load-balanced client-server traffic and for client
access to content that is cached in the ACOS device's RAM cache.
In this example, two real servers are used as HTTP content servers and as logging servers. Clients send
requests for HTTP content to port 80. ACOS either serves the requested from the local RAM cache, if
available, or sends the request to one of the servers.
In this example, the ACOS device uses the same servers as the content servers and as the logging serv-
ers. Client requests for HTTP content are sent to port 80. Log traffic is sent to one of the following
ports:
• 4999 – TCP port listening for log traffic sent over IPv4.
• 5999 – TCP port listening for log traffic sent over IPv6.
To begin, the following commands configure the servers:
ACOS(config)# slb server rs 10.10.10.11

page 575
Configuration

ACOS(config)# slb server rs6 3030::3011
The following commands configure the service groups for the applications clients will access:
ACOS(config)# slb service-group logsg tcp

ACOS(config-slb svc group)# member rs 80
ACOS(config)# slb service-group udpsg udp
ACOS(config-slb svc group)# member rs 5140
ACOS(config)# slb service-group v6logsg tcp
ACOS(config)# slb service-group udpsg6 udp
The following commands configure the TCP-proxy template, to enable keepalive probes:
ACOS(config)# slb template tcp-proxy logtcp

ACOS(config-TCP proxy template)# keepalive-probes 4
ACOS(config-TCP proxy template)# exit
The following commands configure the logging templates:
ACOS(config)# slb template logging logtemp

ACOS(config-logging)# service-group logsg
ACOS(config-logging)# template tcp-proxy logtcp
ACOS(config-logging)# exit
page 576
Configuration
ACOS(config)# slb template logging udplog

ACOS(config-logging)# service-group udpsg
ACOS(config)# slb template logging logtemp6
ACOS(config-logging)# service-group v6logsg
ACOS(config-logging)# template tcp-proxy logtcp
ACOS(config)# slb template logging udplog6
ACOS(config-logging)# service-group udpsg6
The following commands configure the RAM caching templates:
ACOS(config)# slb template cache logcache

ACOS(config-ram caching)# min-content-size 20
ACOS(config-ram caching)# template logging udplog
ACOS(config)# slb template cache logcache6
ACOS(config-ram caching)# min-content-size 20
ACOS(config-ram caching)# template logging udplog6
The following commands configure the HTTP templates:
ACOS(config)# slb template http loghttp

ACOS(config-http)# template logging logtemp
ACOS(config)# slb template http loghttp6
ACOS(config-http)# template logging logtemp6
These commands configure the VIPs. The configuration of the snat and snat6 NAT pool referenced in
the example is not included.
ACOS(config)# slb virtual-server vs 20.20.20.25

ACOS(config-slb vserver-vport)# source-nat pool snat
ACOS(config-slb vserver-vport)# service-group logsg
ACOS(config-slb vserver-vport)# template http loghttp
ACOS(config-slb vserver-vport)# template cache logcache
ACOS(config)# slb virtual-server vs6 2020::2025
ACOS(config-slb vserver-vport)# source-nat pool snat6
ACOS(config-slb vserver-vport)# service-group v6logsg
page 577
Log String Customization
ACOS(config-slb vserver-vport)# template http loghttp6

ACOS(config-slb vserver-vport)# template cache logcache6

You can customize the structure and content of web log messages for requests sent to HTTP or
HTTPS virtual ports. This capability customizes ACOS to efficiently log only the information that you
require.
W3C Log Message Format

The CLI can modify web logging formats with the format command at the logging template configura-
tion level. The logging template bound to the virtual server constructs log messages for HTTP/HTTPS
requests according to the specified format.
For example, if the log message format is defined as shown below:
%{%Y-%m-%d %H:%M:%S}t %a %u %A %p %r %m %U %q %s "%{USER-AGENT}i" "%{REFERER}i" %H %v %b
Then the log message for an HTTP request is constructed as follows:
Feb 1 19:30:53 11.0.0.40 2013-02-01 15:31:08 11.0.0.1 - 10.1.2.198 80 s1 GET /aa/

cookie.htm - 200 "Wget/1.12 (linux-gnu)" "OK" HTTP/1.0 vip1 32494
In this log message, Feb 1 19:30:53 is the timestamp of when the log was received. The IP address of
the server that received the log is 11.0.0.40. The remaining content of the log message is constructed
according to the format string (defined by the format command that is configured within the logging
template).
Table 12 describes W3C format characters supported on the ACOS device and references content in
the example log message above.
TABLE 12W3C – Format Characters

Format Character Description Log Message Example
%% Percent symbol N/A
%a Client IP address 11.0.0.1
%A Local IP address 10.1.2.198
%p Port number that is used by the server for a 80
request
%r Name of the real server s1
%m HTTP request method GET
page 578
TABLE 12W3C – Format Characters (Continued)

Format Character Description Log Message Example
%U Requested URL path requested /aa/cookie.htm
The log message does not include any query

strings
%q Query string in a request The second “-”
%u For authenticated requests, the %u format charac- The first “-”
ter logs the remote user
ACOS does not authenticate HTTP requests.

Therefore, %u format character always return a null
(-) value.
%s HTTP status code for the request 200
In RAM Caching deployments, the status code is

not included in log messages; the %s format char-
acter returns a null (-) value in web logging mes-
sages.
%{time}t Timestamp for when the request is processed 2013-02-01 15:31:08
For time you can specify the following:
• %Y – year
• %m – month
• %d – day
• %H – hour
• %M – minute
• %S – seconds
%{USER-AGENT}i User-agent sending the request “Wget/1.12 (linux-gnu)”
%{REFERER}i Referer of a request “OK”
%H HTTP request protocol HTTP/1.0
%v Name of the virtual server that processed the Vip1
request
Content for this value differs for virtual servers

defined on shared or private partitions. For exam-
ple, if the virtual server “vipv6” is defined in a parti-
tion named “l3v”, then %v is parsed as “?l3v?vipv6”
in the web log message.
%b Number of bytes in the response 32494
Control Characters
In addition to the format characters described in Table 12, ACOS supports the following control
characters:
• \\n – New line
page 579
• \\t – Carriage return (reset to the line beginning)
• \\r – Tab
Format Consideration
If the format of a string includes an unsupported character, the log message will contain only the first
section of valid information leading up to the unsupported character. Even if the log message contains
supported content after the unsupported character, the latter section of supported content is not
included in the log message. For example, given the structure below:
<supported “A”><unsupported “B”><supported “C”>
The log message breaks at <unsupported “B”>, displaying only content associated with <supported
“A”>.
For example, given the logging format “%P%A%a%p”, “%P” is not supported and as a result nothing is
parsed into a log message.
For the logging format “%p%P%a%A”, the content after the unsupported “%P” format character is not
included in the log message and the information for “%p” is the only content parsed into a log message.
To view which characters are parsed in a format string, use the show slb template logging command.
NOTE: Do not use the question mark (?) as a literal character for log messages.
Configure the Web Logging Format

Perform the following commands to customize Web log messages.
Using the GUI

2. Click the General tab.
3. Click Create and select Logging from the drop-down menu.
4. In the Format field enter the series of up to 250 supported format characters. See Table 12 for
information about format characters.
5. Click OK.
Using the CLI
This example shows how to use the format command to create a log format, then use the show slb
template logging command to verify the configuration:
ACOS(config)# slb template logging v-log
page 580
ACOS(config-logging)# format %a \n "%a"

ACOS(config-logging)# show slb template logging
slb template logging v-log
format %a \n "%a"
ACOS(config-logging)#
page 581
page 582
Real-Time Logging for Failed Server Selection
• Overview
• Using the GUI to Configuring Real-Time Logging
• Using the CLI to Configure Real-Time Logging
Overview
ACOS provides real-time notifications for when the system has detected a failed server selection. Log
entries include the cause of the event and users are immediately notified of the instance. In addition to
the system log entry, you can configure alerts using SNMP traps, enabling you to immediately respond
to server selection failure.
To implement this feature, perform the following steps:
1. Within a server template, enable alerts for failed server selection and apply to the SLB server.
2. Apply the template to one or more real servers.
3. Add these servers to a service group, and apply the service group to a virtual server.
4. Configure SNMP traps for immediate event notifications of failed server selection. The SNMP trap
notification will include information such as the server name, IP address, server port, partition
name, and known cause for server selection failure.
Using the GUI to Configuring Real-Time Logging

Perform the following procedures to configure real-time alerts with the GUI:
• Configure Logging
• Configure SNMP Traps
page 583
Configure Logging
To configure logging:
1. Hover over ADC (menu bar) and select Templates. Select the SLB tab (should be selected by
default).
2. Click Create and select Server from the drop-down menu.
3. Enter a name and other information for the template. (See online help for details on mandatory
fields.)
4. Select checkbox in the Log Selection Failure field.
This option enables real-time logging for the server selection failure event.
5. Optionally, modify the template configuration.

6. Click OK, or click Update if you are modifying an existing template.
page 584
Configure SNMP Traps

To configure SNMP traps:
1. Hover over System in the menu bar, then select Getting Started.
2. In the SNMP section, click the Edit (Pencil) button.
3. For System SNMP Service, select the Enable radio button.
4. In the Trap List section, select the Server Selection Failure trap in the “SLB Group” section.
page 585
Using the CLI to Configure Real-Time Logging

Enter the following command to send SNMP traps if server selection fails:
ACOS(config)# snmp-server enable traps slb server-selection-failure
The following example shows the configuration of a server with enabled logging of failed server selec-
tion and SNMP notification alerts.
ACOS(config)# slb template server svtemp1

ACOS(config-rserver)# conn-rate-limit 1
ACOS(config-rserver)# log-selection-failure
Create a server and apply the template with logging enabled for failed server selection.
ACOS(config)# slb server srv266 10.10.100.10

ACOS(config-real server)# template server svtemp1
Create a service group and add the srv266 server.
ACOS(config)# slb service-group fail-servers tcp

ACOS(config-slb svc group)# member srv266 80
Create a virtual server:
ACOS(config)# slb virtual-server fail-233 1.1.1.1

ACOS(config-slb vserver-vport)# name _1.1.1.1_HTTP_80
ACOS(config-slb vserver-vport)# service-group fail-servers
Enable SNMP notifications for failed server selection:
ACOS(config)# snmp-server enable traps slb server-selection-failure

ACOS(config)# snmp-server host 192.168.3.67 version v2c public udp-port 162
The following is an example of show command output after an instance of failed server selection:
ACOS# show log

Log Buffer: 30000
Dec 28 2012 07:09:15 Warning [ACOS]:Server srv266(port:80) selection failure(exceeded_re-
al_server_connection_rate_limit)
page 586
Dec 28 2012 07:09:15 Warning [ACOS]:Server srv266(port:80) selection failure(exceeded_re-

al_server_connection_rate_limit)
page 587
page 588
Part VII Part VII

ACOS Performance Optimization
This section contains topics pertaining the optimizing the performance of your ACOS device.
• “Stateless Server Load Balancing” on page 591

• “Stateful Hash-Based Server Load Balancing” on page 595
• “Auto-Switch to Stateless SLB Based on Traffic” on page 597
• “Generic TCP-Proxy” on page 601
Stateless Server Load Balancing
This chapter describes stateless server load balancing.
• Overview of Stateless Server Load Balancing
• Stateless Load-Balancing Methods
• Stateless Load Balancing Limitations
• Configuring Stateless Load Balancing
Overview of Stateless Server Load Balancing

Stateless SLB conserves system resources by operating without session table entries on the ACOS
device. Session table entries contain information about sessions, including client, VIP, and real server
IP addresses and protocol ports. Session table entries also may contain additional state information
for specific features.
If the ACOS 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 “Stateless
Load Balancing Limitations” on page 592.)
You can enable stateless SLB on an individual service-group basis, by selecting a stateless SLB load-
balancing method for the group. (See “Use the CLI to Configure Stateless Load Balancing” on
page 593.)
Stateless Load-Balancing Methods

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

Stateless SLB is not valid for the following features or traffic types:
• Rate limiting
• ACLs
• IP source NAT
• Session synchronization
• Application Layer Gateway (ALG)
• Layer 3 DSR
• SLB-PT
• aFleX
A given real server can be used in only one stateless SLB service group. The ACOS will assume any traf-
fic coming from a real server in a stateless SLB service group is response traffic and needs to be pro-
cessed through the virtual IP address. A real server that is in a stateless SLB service group cannot be
used in any other stateless service groups.
DNS templates are not supported with stateless load-balancing methods.
Adding or removing a member of the service group will cause the ACOS device to recalculate the distri-
bution hash, potentially causing existing connections to be sent to different servers.
When a health check marks a member of the service group down, there is a pre-calculated backup hash
that allows the connections associated with the failed server to be evenly redistributed to other servers.
page 592
Configuring Stateless Load Balancing
When the failed member is marked back up by the health check, the redistributed connections will
immediately be sent back to the original server based on the primary hash.
If the virtual port is on a wildcard VIP, destination NAT must be disabled on the virtual port.
Graceful transitions between stateful and stateless SLB in a service group are not supported.
Mega-proxies may interfere with equal balancing of traffic load among the multiple data CPUs. In this
case, for DNS traffic only, try using the stateless-per-pkt-round-robin method.
The stateless-per-pkt-round-robin method is applicable only for traffic that uses a single packet for
a request. Examples include DNS queries or RADIUS requests without a Challenge-request/Response
message used for EAP.

• Use the GUI to Configure Stateless Load Balancing
• Use the CLI to Configure Stateless Load Balancing
Use the GUI to Configure Stateless Load Balancing

To use the GUI to configure stateless load balancing:

2. Click Create or Edit in the Actions column for an existing service group.
3. In the Algorithm field, select a stateless load balancing methods (for example, Stateless SRC
DST IP Hash).
4. Click Update.
Use the CLI to Configure Stateless Load Balancing

To enable stateless SLB for a service group, use the method command at the configuration level for the
service group and specify one of the stateless server load balancing algorithms. The following example
configure a stateless SLB service group for UDP traffic. Traffic that is load balanced based on a hash
value of the source and destination IP addresses.
ACOS(config)# slb service-group dns-stateless udp

ACOS(config-slb svc group)# method stateless-src-dst-ip-hash
page 593
ACOS(config-slb svc group)# member dns1 53

ACOS(config-slb svc group)# member dns2 53
page 594
Stateful Hash-Based Server Load Balancing
This chapter describes stateful hash-based load balancing. The following topics are covered:
• Overview of Stateful Hash-Based Load Balancing
• Configuring Stateful Hash-Based Load Balancing
Overview of Stateful Hash-Based Load Balancing

Stateful hash-based load balancing provides the persistence and performance benefits of hash-based
load balancing, while allowing use of advanced SLB features that require stateful load balancing. For
example, rate limiting is an advanced SLB feature that requires stateful load balancing.
One difference between stateless load balancing and stateful load balancing is that stateful load bal-
ancing uses the ACOS session table to manage sessions. Stateless load balancing does not use the
session table.
Stateful Hash-Based Load Balancing Methods

The following stateful hash-based load balancing methods are available:
• src-ip-hash – Hash value based on source IP address and protocol port of client request.
• src-ip-only-hash – Hash value based on only the source IP address of the client request.
• dest-ip-hash – Hash value based on destination IP address and protocol port of client request.
• dest-ip-only-hash – Hash value based on destination IP address of client request.
• odd-even-hash – Two-value hash based on even-odd result of the sum of the source IP address
octets.
How Hashing Works

ACOS assigns each available real server in the service group to a hash bucket. Each hash bucket con-
sists of a unique set of possible hash values.
page 595
Configuring Stateful Hash-Based Load Balancing
When a client initiates a session by sending a request, the ACOS device calculates a hash value based
on address information in the request. The ACOS device then sends the request to the server to which
the calculated hash value belongs. All subsequent traffic for that session is sent to the same server.
If the server used by the client session goes down (for example, fails a health check), the ACOS device
recalculates the hash buckets, and sends the client to one of the available servers. For persistence, the
ACOS device continues to use the new server for the client, even when the down server comes back up.
The hash calculation always results in the same hash value, on any ACOS device running this software
version. This consistency is important in cases where a client’s session traffic might pass through dif-
ferent ACOS devices. For example, the consistent hash values hash are important in Equal Cost Mul-
tipath (ECMP) topologies in which multiple ACOS devices are deployed.
Configuring Stateful Hash-Based Load Balancing

• Use the GUI to Configure Stateful Hash-Based Load Balancing
• Use the CLI to Configure Stateful Hash-Based Load Balancing
Use the GUI to Configure Stateful Hash-Based Load Balancing

To use the GUI to configure stateful hash-based load balancing:

2. Click Create or Edit in the Actions column for an existing service group.
3. In the Algorithm field, select a stateful load balancing methods (for example, Source IP Only
Hash).
4. Click Update.
Use the CLI to Configure Stateful Hash-Based Load Balancing

To use a stateful hash-based load-balancing method, use the method command at the configuration
level for the service group and specify a stateful load-balancing method. The following commands con-
figure a service group to use stateful hashing based only on source IP address:
ACOS(config)# slb service-group stateful-IP-LB tcp

ACOS(config-slb svc group)# method src-ip-only-hash
page 596
Auto-Switch to Stateless SLB Based on Traffic
ACOS has a service-group option that begins using stateless load balancing instead of stateful load
balancing, based on traffic. You can configure the change from stateful to stateless load balancing to
be triggered based on connection rate or Layer 4 session use.
This feature supports only a single virtual port per service group. If you configure this feature on a ser-
vice group, you can use that service group with only one virtual port.
Options for this Feature
You can configure the following options for this feature. Although only some of these options must be
specified when you configure the feature, none of the options has a default value.
• Trigger – The trigger can be one of the following:
• Connection rate – Rate of new connection requests per second at which the load balancing
method is changed. The rate applies collectively to all servers in the service group. The thresh-
old can be 1-1000000 connection requests per second.
• Layer 4 session use – Percentage of the system-wide Layer 4 session capacity that is currently
in use. The threshold can be 1-100 percent.
• Trigger duration – Number of seconds during which the specified trigger must continue to occur
before the service group changes to stateless load balancing. Value ranges from 1 to 600 sec-
onds.
• (Optional) Revert trigger – Connection rate or Layer 4 session use percentage at which the ser-
vice group can revert to using stateful load balancing.
• For connection rate, the threshold can be 1-1000000 connection requests per second.
• For Layer 4 session use, the threshold can be 1-100 percent.
• (Optional) Revert duration – Number of seconds when the specified revert trigger must continue
to occur before the service group changes to stateful load balancing again. Value ranges from 1
to 600.
• (Optional) Grace period – Interval (seconds) where ACOS device uses current load balancing
method for active sessions, before changing to the other load balancing method. Value ranges
from 1 to 600.
The grace period applies only to sessions that are active when the load balancing change is trig-
gered. The change applies immediately to new sessions that begin after the change is triggered.
• Logging – Logs changes between stateful and stateless load balancing that occur due to this
feature. Logging is disabled by default.
page 597
Using the GUI

1. Navigate to the configuration page for the service group (ADC >> SLB >> Service Groups).
• If configuring a new service group, select Create.
• If modifying an existing service group, click the Edit link in the Actions column for the service
group.
2. Expand the Advanced Fields category.
3. Select the Stateless Auto Switch checkbox to display a drop-down list of available stateless
methods.
4. Select the stateless method from the drop-down list. This displays configuration fields for the
options described in “Options for this Feature” on page 597.
5. To specify the trigger type, select one of the following (See “Options for this Feature” on page 597.):
• Connection Rate
• Session Usage
6. Add the servers, if they are not already added.
7. Click Update.
CLI Example 1
These commands configure a service group that uses the stateless-per-pkt-round-robin stateless load-
balancing method. This method is used if the rate of new connection requests to the virtual port bound
to the service group reaches 80,000 connections per second, and remains at least this high for 300
seconds.
ACOS(config)# slb service-group auto-stateless tcp

ACOS(config-slb svc group)# method weighted-rr auto-switch stateless-per-pkt-round-robin
conn-rate 80000 300 60000 300 grace-period 15 log
To return to using the stateful load-balancing method (weighted round-robin in this example), the rate
of new connection requests to the virtual port must drop to 60,000 per second and remain that low for
at least 300 seconds. Once this occurs, the ACOS device waits an additional 15 seconds (the grace
period) before returning to use of stateful load balancing. Logging is enabled.
To manually reset the service group to stateful SLB, use the reset auto-switch command at the con-
figuration level for the service group.
CLI Example 2
In the following configuration, if Layer 4 session usage reaches 2 percent and stays at least this high
for 5 seconds, both service-group members begin using the stateless-dst-ip-hash method. ACOS
reverts back to stateful load balancing when 1 percent or less is reached for 5 seconds.
page 598
slb service-group sg-auto1 tcp

method dst-ip-hash auto-switch stateless-dst-ip-hash l4-session-usage 2 5 1 5
member s1 80
member s2 80
slb service-group sg-auto tcp
method dst-ip-hash auto-switch stateless-dst-ip-hash l4-session-usage 2 5 1 5
member s3 80
member s4 80
page 599
page 600
Generic TCP-Proxy
The generic TCP-proxy service type provides full TCP-stack service for load-balanced Layer 7 applica-
tions.
The TCP-proxy service type is useful in cases where the standard service type for an application does
not provide a superior user experience. For example, in a Real Time Streaming Protocol (RTSP) deploy-
ment where performance is slow because the server or client enables a large TCP window size, ACKs
are delayed, and so on, using the TCP-proxy service type instead of the RTSP service type can improve
performance.
Using the GUI

1. Hover over ADC on the menu bar, then select SLB.
2. Select the Virtual Servers tab.
3. Click Create to create a new virtual server, or click Edit in the Actions column of an existing virtual
server.
4. If you are creating a virtual server, you must specify a name and IP address for your new virtual
server. If you are editing an existing server, you can skip this step.
5. In the Virtual Port section of the page, click Create.
6. In the Protocol field, select TCP-PROXY from the drop-down list.
7. Specify the port number.
8. Click Create.
Using the CLI
To assign the TCP-proxy service type to a virtual port, use the port num tcp-proxy command at the
configuration level for the virtual server.
The following commands configure the real servers, service groups, and VIPs for an IPv4/IPv6 RTSP
application using the tcp-proxy service type.
These commands configure the real servers:

page 601

ACOS(config)# slb server ipv6 2001::1113
These commands configure the service groups:
ACOS(config)# slb service-group http tcp

ACOS(config)# slb service-group rtsp tcp
ACOS(config)# slb service-group ipv6http tcp
ACOS(config-slb svc group)# member ipv6 80
ACOS(config)# slb service-group ipv6rtsp tcp
ACOS(config-slb svc group)# member ipv6 554
These commands configure the VIPs:
ACOS(config)# slb virtual-server vip-1 10.153.60.200

ACOS(config-slb vserver)# port 554 tcp-proxy
ACOS(config-slb vserver-vport)# service-group rtsp
ACOS(config)# slb virtual-server vipipv6 2001::9999
ACOS(config-slb vserver)# port 554 tcp-proxy
ACOS(config-slb vserver-vport)# service-group ipv6rtsp
page 602
Part VIII Part VIII

Additional Features

• “Health Monitoring” on page 627
• “Alternate Real Servers and Ports for Individual Backup” on page 697
• “Alternate Virtual Ports for Backup” on page 707
• “Priority Affinity” on page 711
• “Source-IP Persistence Override and Reselect” on page 721
• “Policy Template Binding at the Service-Group Level” on page 725
• “Scan-All-Members Option in Persistence Templates” on page 729
• “Quality of Service Marking for TCP Traffic” on page 735
• “Preventing Reset of SLB and Ethernet Statistics” on page 737
• “Web Category” on page 739
This chapter describes how to configure parameters for multiple servers and service ports using server
and port templates.
• Overview
• Configuring Server and Port Templates
• Applying a Server or Service Port Template
• Connection Limiting
• Connection Rate Limiting
• Slow-Start
• Request Rate Limiting
• Graceful Shutdown
• Gratuitous ARPs for Subnet VIPs
• aFlow Request Queuing
• TCP Reset Option for Session Mismatch
• Client Port Preservation
Overview
ACOS supports the following types of templates for configuration of SLB servers and ports:
• Server – Contains configuration parameters for real servers
• Port – Contains configuration parameters for real service ports
• Virtual-server – Contains configuration parameters for virtual servers
• Virtual-port – Contains configuration parameters for virtual service ports
These template types provide the same benefit as other template types. They allow you to configure a
set of parameter values and apply the set of values to multiple configuration items. In this case, you
page 605
Overview
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.
Default Server and Port Templates

ACOS 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 ACOS 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 con-
figuration. 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 overrid-
den by parameter settings on the individual servers and ports.
Modifying a Default Template
You can modify a default template by creating a new one named “default” and modifying the settings
you want to change. The new template replaces the previous one.
In addition to configuring custom server, port, virtual-server, or virtual-port templates, you can modify
the default templates. Before changing a default template, make sure the changes you plan to make
are applicable to all servers or ports that use the template.
page 606
Overview
Parameters That Can Be Configured Using Server and Port Templates

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

Template Type Parameter Description
Real Server Health monitor Assigns a configured Layer 3 health monitor to all servers
that use the template. (See “Configuring and Applying a
Health Method” on page 638.)
Connection limit Specifies the maximum number of connections allowed on
any server that uses the template. (See “Connection Limit-
ing” on page 615.)
Connection rate Limits the rate of new connections the ACOS is allowed to
limiting send to any server that uses the template. (See “Connection
Rate Limiting” on page 616.)
Slow start Provides time for servers that use the template to ramp-up
after TCP/UDP service is enabled, by temporarily limiting the
number of new connections on the server. (See “Slow-Start”
on page 618.)
Load-balancing Biases load-balancing selection of this server. A higher
weight weight gives more favor to the server relative to the other
servers.
For an example of weighted SLB, see “FTP Load Balancing”

on page 155. (The example configures weights directly on
the real service ports rather than using templates, but still
illustrates how the weight option works.)
Note: This option option applies only to the service-weighted-

least-connection load-balancing method. This option does
not apply to the weighted-least-connection or weighted-
round-robin load-balancing methods.
Statistics collection Enables or disables collection of statistical data for the
server.
Extended statistics Enables collection of peak connection statistics.
Spoofing cache sup- Enables support for a spoofing cache server. A spoofing
port cache server uses the client’s IP address instead of its own
as the source address when obtaining content requested by
the client.
This option applies to the Transparent Cache Switching

(TCS) feature. (See “Transparent Cache Switching” on
page 421.)
page 607
Overview
TABLE 13SLB Port and Server Template Parameters (Continued)

Real Server Logging for server- Generates log messages to indicate server selection failures.
selection failures (See “Real-Time Logging for Failed Server Selection” on
(cont.) page 583.)
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 103.)
DNS query interval Specifies how often the ACOS 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.
Real Server Port Health monitor Assigns a configured Layer 4-7 health monitor to all service
ports that use the template. (See “Configuring and Applying a
Health Method” on page 638.)
In-band health moni- Provides rapid server status change and reassignment
tor based on client-server traffic.
This is an enhanced health check mechanism that works

independently of the standard out-of-band health mecha-
nism. See “In-Band Health Monitoring” on page 662.
Connection limit Specifies the maximum number of connections allowed on
any real port that uses the template. (See “Connection Limit-
ing” on page 615.)
limiting send to any real port that uses the template. (See “Connec-
tion Rate Limiting” on page 616.)
Destination NAT Enables destination Network Address Translation (NAT).
Destination NAT is enabled by default, but is disabled in

Direct Server Return (DSR) configurations.
You can re-enable destination NAT on individual ports for

deployment of mixed DSR configurations. See “Direct Server
Return in Mixed Layer 2/Layer 3 Environment” on page 78.
Member priority for Sets the initial TTL for dynamically created service-group
dynamically created members. (See “Dynamic Real Server Creation Using DNS”
servers on page 103.)
page 608
Overview

Real Server Port Source NAT Specifies the IP NAT pool to use for assigning a source IP
address to client traffic addressed to the port. For informa-
(cont.) tion about NAT, see the “Network Address Translation” chap-
ter in the System Configuration and Administration Guide. Also
see “Network Address Translation for SLB” on page 89.
Slow start Provides time for real ports that use the template to ramp-up
after TCP/UDP service is enabled, by temporarily limiting the
number of new connections on the ports. (See “Slow-Start”
on page 618.)
Down grace period Specifies the number of seconds the ACOS device will con-
tinue to forward packets to a Down port. This option is useful
for taking servers down for maintenance without immedi-
ately impacting existing sessions on the servers. (See
“Graceful Shutdown” on page 621.)
Weight Biases load-balancing selection of this port. A higher weight
gives more favor to the server and port relative to the other
servers and ports.
SSL support Disables SSL for server-side connections. This option is use-
ful if a server-SSL template is bound to the virtual port that
uses this real port, and you want to disable encryption on
this real port.
DSCP Sets the differentiated services code point (DSCP) value in
the IP header of a client request before sending the request
to a server.
Request rate limit Limits the number of new requests that can be received by
the virtual port. (See “Request Rate Limiting” on page 621.)
Statistics collection Enables or disables collection of statistical data for the
server.
Extended statistics Enables collection of peak connection statistics.
Virtual Server Connection limit Specifies the maximum number of connections allowed on
any VIP that uses the template. (See “Connection Limiting”
on page 615.)
limiting send to any VIP that uses the template. (See “Connection
Rate Limiting” on page 616.)
ICMP/ICMPv6 rate Limits the rate at which ICMP packets can be sent to the VIP.
limiting (See the DDoS Mitigation Guide (for ADC).)
Gratuitous ARPs for Enables gratuitous ARPs for all VIPs in a subnet VIP. (See
subnet VIPs “Gratuitous ARPs for Subnet VIPs” on page 622.)
page 609
Configuring Server and Port Templates

Virtual Server Port Connection limit Specifies the maximum number of connections allowed on
any virtual service port that uses the template. (See “Connec-
tion Limiting” on page 615.)
limiting send to any virtual service port that uses the template. (See
“Connection Rate Limiting” on page 616.)
aFlow request queu- Avoids packet drops and retransmissions when a real server
ing port reaches its configured connection limit.
(See “aFlow Request Queuing” on page 623.)

Reset unknown Enables sending of a TCP Reset (RST) in response to a ses-
connections sion mismatch. (See “TCP Reset Option for Session Mis-
match” on page 624.)
Ignore TCP MSL Immediately reuses TCP sockets after session termination,
without waiting for the SLB maximum Session Life (MSL)
time to expire.
Source-NAT MSL Sets the TCP MSL for virtual port NAT sessions. (See “Vir-
tual-port TCP Maximum Segment Life for NATted Sessions”
on page 101.)
DSCP Sets the Differentiated Services Code Point (DSCP) value in
client requests before forwarding them to the server.
Client port preserva- Preserves the client’s source port for the traffic destined to
tion for source NAT the virtual port. (See “Client Port Preservation” on page 626.)
Layer 7 reset upon Sends a reset to the Layer 7 client and the server upon a
failover. failover.
Allow other flags in Allows initial SYN packets to contain other flags.
TCP-SYN packets.
Allow VIP-to-real-port Allows mapping the VIP-to-real-port mapping. (See “Mapping
mapping Virtual IP Addresses and Real Ports” on page 117.)

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

2. Click Create, then select one of the following from the drop-down menu:
page 610
• Port
• Server
• Virtual Port
• Virtual Server
3. The configuration page for the specified template appears. Enter a name for the template (if the
template is new).
4. Enter or edit the other settings. (See the descriptions in the sections below for information.)
5. When finished, click OK to create a new template for the port, server, virtual port, or virtual server.
6. Click the Save icon at the upper right-most corner of the GUI window.
Using the CLI
To configure server and service-port templates, use these commands at the global configuration level.
slb template server

slb template port
slb template virtual-server
slb template virtual-port
These commands change the CLI to the configuration level for the template. To modify the default tem-
plate, specify the name “default” (without the quotation marks).
To display the settings in a template, use these commands:
show slb template server

show slb template port
show slb template virtual-server
show slb template virtual-port
CLI Example
The following commands configure a new real server template and bind the template to two real serv-
ers:
ACOS(config)# slb template server rs-tmplt1

ACOS(config-rserver)# health-check ping2
ACOS(config-rserver)# conn-limit 500000
ACOS(config-real server)# template server rs-tmplt1
page 611
Applying a Server or Service Port Template
This example includes the commands to bind the template to real servers. For information about bind-
ing the templates, see “Applying a Server or Service Port Template” on page 612.

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 tem-
plate, the template takes effect only after you bind it to servers or ports.
Table 14 lists the types of bindings that are supported for server and port templates.
TABLE 14Server and Port Template Bindings

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

Using the GUI
2. Click on the Servers tab.
3. Click the Edit link in the Action column for a configured real server.
4. Expand the Advanced Fields section.
5. In the Template Server field, select the server template from the drop-down list. You can also click
the Add link to create a new server template.
6. Click Update.
page 612
Using the CLI
The following example shows how to bind the server template sv_template1 to a real server:
ACOS(config)# slb server rs1

ACOS(config-real server)# template server sv_template1
Binding a Server Port Template to a Real Server Port

Using the GUI
2. Click on the Servers tab.
3. Click the Edit link in the Action column for a configured real server.
4. In the Port section, click on the Edit link for a configured port.
6. In the Template Port field, select the server port template from the drop-down list.
7. Click Update.
Using the CLI
The following example shows how to bind the port template pt_template1 to a real server port:

ACOS(config-real server-node port)# template port pt_template1
Binding a Virtual Server Template to a Virtual Server

Using the GUI
2. Click on the Virtual Servers tab.
3. Click the Edit link in the Action column for a configured virtual server.
5. In the Virtual Server Template field, select the virtual server template from the drop-down list. You
can also click the Add link to create a new template.
6. Click Update.
page 613
Using the CLI
The following example shows how to bind the virtual server template vs_template1 to a virtual server:
ACOS(config)# slb virtual-server vs1

ACOS(config-slb vserver)# template virtual-server vs_template1
Binding a Virtual Server Port Template to a Virtual Service Port

Using the GUI
2. Click on the Virtual Services tab.
3. Click the Edit link in the Action column for a configured virtual server.
4. Expand the Templates section at the bottom of the page.
5. In the Template Virtual Port field, select the virtual server port template from the drop-down list.
6. Click Update.
Using the CLI
The following example shows how to bind the default virtual port template to a virtual service port:
ACOS(config)# slb virtual-server vs1

ACOS(config-slb vserver-vport)# template virtual-port default
Binding a Server Port Template to a Service Group

Using the GUI
2. Select the Service Groups tab.
3. Click the Edit link in the Action column for a configured service group.
4. In the Member pane, select the Edit link for the configured real server.
5. In the Template field, select the server port template from the drop-down list.
6. Click Update.
page 614
Connection Limiting
Using the CLI
The following commands bind the server port template rsp_template to rs1 in service group sg1:

ACOS(config-slb svc group-member:80)# template rsp_template
Connection Limiting
By default, the ACOS device does not limit the number of concurrent connections on a server or service
port. To prevent servers or services from becoming oversaturated, you can set a connection limit. The
ACOS 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
Connection limiting can be set in real server templates, real port templates, virtual server templates,
and virtual port templates.
To configure connection limits, you can set the following parameters:
• Connection limit – Specifies the maximum number of concurrent connections 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 ACOS device resumes use of the server or
port. You can specify 1-1048575 connections.
• Reset or Drop (virtual servers or virtual server ports only) – Specifies the action to take for con-
nections 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 ACOS device generates log messages when the connection limit is
exceeded.
If you change the connection limiting configuration on a virtual port or virtual server with active ses-
sions, 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. Avoid this by not changing connection limiting configuration when the server or port has
active connections.
page 615
Connection Rate Limiting
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 one of the following:

• ADC >> Templates, click Create and select Server.
• ADC >> Templates, click Create and select Port.
2. In the Connection Limit field, enter the maximum number of concurrent connections for the server
or port.
3. In the Resume field, enter the maximum number of connections the server or port can have before
the ACOS device resumes use of the server or port.
4. Click OK.
Using the CLI
The following commands set the connection limit to 500,000 concurrent connections in a real server
template, then bind the template to real servers:

ACOS(config-rserver)# conn-limit 500000

You can limit the rate at which the ACOS device is allowed to send new connections to servers or ser-
vice ports. Connection rate limiting is different from slow-start, which temporarily limits the number of
new connections per second when TCP/UDP service comes up on a service port. See “Slow-Start” on
page 618.
page 616
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. By default, the connection rate limit is not set.
• Interval – The interval specifies whether the connection rate limit applies to one-second intervals
or 100-ms intervals. The default is one-second intervals.
• Action for excess connections (virtual servers or virtual server ports only) – The action specifies
how the ACOS 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 ACOS device generates log messages when the rate limit is exceeded.
A server or service port that reaches its connection limit is no longer used by the ACOS device.
Using the GUI
In the configuration section for the template:

2. In the Connection Rate Limit field, enter the desired connection rate limit.
3. In the Per field, select the sampling interval: 100ms or 1 second.
4. Click OK.
Using the CLI
This section displays the method of configuring connection rate limiting in a real server template, then
binding the template to real servers.
The commands below configure a connection rate limit of 50000 per 100ms:

ACOS(config-rserver)# conn-rate-limit 50000 per 100ms
If you configure a limit for a server and also for an individual port, the ACOS device uses the lower limit.
For example, if you limit new TCP connections to a real server to 5000 per second and also limit new
HTTP connections to 1200 per second, the ACOS device limits connections to TCP port HTTP to 1200
per second.
The commands below bind this template with the configured rate limit to real servers rs1 and rs2:
page 617
Slow-Start

Slow-Start
The slow-start feature allows time for a server or real service port to ramp up after TCP/UDP service on
a server is enabled, by temporarily limiting the total concurrent connections on the server or port. You
can configure slow-start parameters described in this section in real server templates and real port
templates.
The slow-start feature is not used for a port if the real-port template is applied to the port as part of the
member configuration in a service group. In this case, if slow-start is configured in the port template,
the slow-start settings are ignored for that service-group member.
Ramp-Up Parameters
By default, slow-start allows a maximum of 128 new connections during the first interval (anywhere
between 0 and 10 seconds). During each subsequent 10-second interval, the total number of concur-
rent 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 15 shows the default ramp-up.
TABLE 15Default Slow-Start Ramp-Up

Number of Seconds Total maximum Concurrent Connections
After Server Restart Allowed After Server Restart
0-9 128
10-19 256
20-29 512
30-39 1024
40-49 2048
50-59 4096
60+ Slow-start ends – No limit
The initial ramp-up interval can be any duration from 0 up to the configured interval (10 seconds by
default). After the initial ramp up, each subsequent ramp-up occurs at the end of the configured inter-
val.
You can configure the following ramp-up parameters:
page 618
Slow-Start
• Starting connection limit – The starting connection limit is the maximum 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 – Connection increment specifies the amount by which to increase the
maximum number of concurrent connections allowed. Use one of these methods to specify the
increment:
• Scale factor (This is the default.) – The scale factor is the number by which to multiply the start-
ing connection limit. For example, if the scale factor is 2 and the starting connection limit is 128,
the ACOS 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 seconds 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.
For the connection increment, you can specify a scale factor or a connection addition. The ending con-
nection limit must be higher than the starting connection limit.
If a runtime connection limit is also configured on the server or port (for example, by “Connection Limit-
ing” on page 615), and the normal connection limit is smaller than the slow-start ending connection
limit, the ACOS 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
You can enable slow-start on individual real servers. However, ramp-up settings on individual servers
are not configurable. The settings are the same as default ramp-up settings in server and port tem-
plates. It is recommended to configure slow start only in a server template or port template, not on the
real server.
If you do configure slow-start both on the real server itself and in a real server template or real port tem-
plate, 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 template, 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 con-
nections allowed by either of the configurations at a given interval is used.
page 619
Slow-Start
Using the GUI
In the configuration section for the real server template or real port template:

2. Select the Slow Start checkbox to activate the configuration fields.
3. In the From field, enter the starting connection limit.
4. In the Choose Operator field, select either Add or Times from the drop-down list, then enter the
value you want to add or multiply by in the Add or Times field, respectively.
5. Enter the connection increment in the field next to the increment method you selected.
6. In the Every field, enter the desired ramp-up interval.
7. In the Till field, enter the ending connection limit.
8. Click OK.
Using the CLI
To configure slow-start, use the slow-start command at the configuration level for a real server or real
service port. The following commands enable slow start in a real server template, using the default set-
tings, and bind the template to real servers.

ACOS(config-rserver)# slow-start
page 620
Request Rate Limiting
Request Rate Limiting

You can limit the number of new requests that can be received by a real port. This option applies only to
configurations that use an external-service template.
Using the GUI
On the configuration page for the real port template:
1. Hover over ADC in the menu bar, then select Templates.

3. In the Request Rate Limit field, enter the number of requests.
4. In the Request Rate Per field, select the sampling interval (per 100ms, or per second).
5. Click OK.
Using the CLI
To configure request rate limiting for real ports, use the request-rate-limit command at the configu-
ration level for the real port template.
This example configures a request rate limit of 5000 requests per 100 milliseconds and programs the
device to send an RST to a client that sends a new request during an interval when the request rate is
exceeded. By default, requests that are received after the limit is exceeded are dropped with no RST.
ACOS(config)# slb template port default

ACOS(config-rport)# request-rate-limit 500 per 100ms reset
Graceful Shutdown
You can configure a grace period for Down servers. ACOS will continue to forward packets to Down
ports for the duration of the grace period.
This option is useful for taking servers down for maintenance without immediately impacting existing
sessions on the servers. The grace period can be 1-86400 seconds.
Notes:
• The service group must contain 2 or more servers for this feature to work.
• This feature supports stateless and stateful load balancing. However, the feature is not sup-
ported for stateful hash load-balancing methods, such as source-IP-based or destination-IP-
based hashing.
page 621
Gratuitous ARPs for Subnet VIPs
Using the GUI

3. Enter the desired grace period in the Down Grace Period field.
4. Click OK.
Using the CLI
To configure the grace period, use the down-grace-period command at the configuration level for the
real port template. For example:
ACOS(config)# slb template port default

ACOS(config-rport)# down-grace-period 5000
Gratuitous ARPs for Subnet VIPs

Virtual server templates have an option to enable gratuitous ARPs for all VIPs in a subnet VIP. (A sub-
net VIP is a range of VIPs created from a range of IP addresses within a subnet.)
By default, the ACOS device sends gratuitous ARPs for only the first IP address in a subnet VIP. You
can enable the ACOS device to send gratuitous ARPs for all the IP addresses within a subnet VIP.
This option applies only to VIPs that are created using a range of subnet IP addresses. The option has
no effect on VIPs created with a single IP address.
Using the GUI

2. Click Create and select Virtual Server from the drop-down list.
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 subnet-gratuitous-arp command at the
configuration level for the virtual server template used to configure the VIPs.
The following commands modify the default virtual server template to enable gratuitous ARPs for sub-
net VIPs. The change applies to all subnet VIPs that use the default template for virtual server configu-
ration.
page 622
aFlow Request Queuing
ACOS(config)# slb template virtual-server default

ACOS(config-vserver)# subnet-gratuitous-arp
aFlow Request Queuing

aFlow helps avoid packet drops and retransmissions when a real server port reaches its configured
connection limit.
When aFlow is enabled, the ACOS device queues HTTP/HTTPS packets from clients when a server port
reaches a configured connection limit, instead of dropping them. ACOS then monitors the port, and
begins forwarding the queued packets when connections become available again. To prevent flooding
of the port, the ACOS device forwards the queued packets at a steady rate.
aFlow applies to HTTP and HTTPS virtual ports.
Earlier releases provide this capability with the SmartFlow option in connection-reuse templates. The
aFlow feature in ACOS Release 2.6 does not require use of a connection-reuse template. You can
enable aFlow in a virtual port template instead.
For backwards compatibility, you can enable aFlow using a connection-reuse template. However, only
one implementation, either in a virtual server template or in a connection-reuse template, is supported.
If you change from one implementation to the other, a reload or reboot is required to place the change
into effect.
aFlow Control Operation

aFlow control is triggered when either of the following occurs:
• If connection limit is configured on the real server or real port – The backend real server or real
port reaches its configured connection limit.
• If connection limit is not configured on the real server or real port – Response time of the back-
end real server or real port increases dramatically. Response time is the time between when the
ACOS device forwards a request to the server, when the ACOS device receives the first reply
packet from the server.
When aFlow control is triggered, the ACOS device queues request packets instead of forwarding them
to the server. After the response time returns to normal, the ACOS device sends the queued packets to
the server.
In the current release, it is recommended to use the first method for triggering aFlow, by configuring
connection limits on the real servers or real ports. The second method of triggering aFlow is still being
refined and is considered to be in Beta status.
page 623
TCP Reset Option for Session Mismatch
If you change the aFlow setting for a virtual port, or the connection limit or connection rate limit of a
real server or port used by the virtual port, you must reload the ACOS device to place the change into
effect. Otherwise, the changed setting might not work correctly.
Using the GUI

1. Hover over ADC in the menu bar, the select Templates.
2. Select the SLB tab from the menu bar, if not already displayed.
3. Click Create, then select Virtual Port from the drop-down list.
4. Click the checkbox in the aFlow field.
5. Click Create.
6. If the template is not already bound to the virtual port, select the template from the Template Type
drop-down list on the configuration page for the virtual port. Click Bind when finished.
Using the CLI
The following commands enable aFlow control for an HTTP virtual port:
ACOS(config)# slb template virtual-port afc

ACOS(config-vport)# aflow
The following commands bind the virtual-port template to the HTTP or HTTPS virtual port:

ACOS(config-slb vserver-vport)# template virtual-port afc

Virtual port templates have an option that enables sending of a TCP Reset (RST) in response to a ses-
sion mismatch. A session mismatch occurs when the ACOS device receives a TCP packet for a TCP
session that is not in the active session table on the ACOS device.
This option is useful in cases where a session ages out or is deleted on the ACOS device, but the client
does not receive a RST or FIN for the session. In this case, without a RST, the session could remain
page 624
open on the client until the session ages out. When this option is enabled, TCP RSTs are sent in the
cases listed in Table 16.
TABLE 16Processing When Session Is To Be Deleted

Packet Type Sent by Client or
Session Termination Server After Session
Method Termination ACOS Response
Session is terminated by Any packet type other than SYN Maintain connection as long as there is traffic.
FINs from client and When there is no traffic, remove the connection
server one second later.
Session ages out Any packet type other than SYN Move session from delete queue back into
active session table.
The option is disabled by default, which means the ACOS 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 ACOS device receives a
packet for a session that has been moved to the delete queue, the ACOS device does not send a TCP
RST. Instead, the ACOS device reactivates the session and allows it to age out normally.
Using the GUI

4. Click the checkbox in the Reset Unknown Connection field.
5. Click Create.
Using the CLI
To enable sending of TCP RSTs in response to a session mismatch, use the following command at the
configuration level for a virtual port template:
ACOS(config)# slb template virtual-port default

ACOS(config-vport)# reset-unknown-conn
page 625
Client Port Preservation
Client Port Preservation

Virtual-port templates have an option that attempts to preserve the client’s source port for the traffic
destined to the virtual port. This option is disabled by default.
Notes
• Port preservation is not always guaranteed and is performed on a best-effort basis.
• Port preservation does not work for FTP active mode sessions.
• Port preservation works only if source NAT is enabled for the virtual port.
Using the GUI

4. Select the checkbox in the SNAT Port Preserve field.
5. Click Create.
Using the CLI
The following command configures a NAT pool:
ACOS(config)# ip nat pool mypool 30.30.30.40 30.30.30.42 netmask 255.255.255.0
The following commands configure the virtual-port template:
ACOS(config)# slb template virtual-port vport

ACOS(config-vport)# snat-port-preserve
The following commands configure the virtual port:
ACOS(config-vport)# slb virtual-server vip1 192.168.25.25

ACOS(config-slb vserver-vport)# source-nat pool mypool
ACOS(config-slb vserver-vport)# service-group sg1-http
ACOS(config-slb vserver-vport)# template virtual-port vport
page 626
Health Monitoring
ACOS 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 ACOS 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 ACOS device.
For information about health monitoring of the ACOS device’s nexthop gateways, see the “Gateway
Health Monitoring” chapter in the System Configuration and Administration Guide.
Health Check Overview

• Default Health Checks
• Health-Check Guidelines
• Health Method Timers
• Health Check Operation
Default Health Checks

ACOS performs the following types of health checks by default:
• Layer 3 ping – Every 5 seconds, the ACOS device sends an ICMP echo request (ping) addressed
to the real server’s IP address. The server passes the health check if it sends an echo reply to the
ACOS device. If the server does not reply after the fourth attempt (the first attempt followed by 3
retries), the ACOS device sets the server state to DOWN.
• Layer 4 TCP – Every 5 seconds, the ACOS device sends a connection request (TCP SYN) to the
specified TCP port on the server. The port passes a health check if it replies to the ACOS device
by sending TCP SYN ACK. If the port does not reply after four attempts, the ACOS device sets the
port state to DOWN.
page 627
• Layer 4 UDP – Every 5 seconds, the ACOS device sends a packet with a valid UDP header and a
garbage payload to the UDP port. The port passes the health check if it either does not reply, or
replies with any type of packet except an ICMP Error message. If the port replies with an ICMP
Error message, the ACOS device sets the port state to DOWN.
The default ICMP, TCP, or UDP monitor is not used if you disable it on the server or port, or you apply a
different monitor to the server or port.
• In the GUI, on the server configuration page, the default health monitors appear as “(default)” in
the Health Monitor drop-down lists for the server itself and for the individual TCP or UDP ports.
• For the server itself, “(default)” means the Layer 3 ping described above. For TCP ports, “(default)”
means the Layer 4 TCP health monitor described above. Likewise, for UDP ports, “(default)”
means the Layer 4 UDP health monitor described above.
• On new ACOS devices, the Health Monitor list contains one health monitor (ping), which is the
same as the “default” server health monitor. The list does not contain default TCP or UDP health
monitors.
Health-Check Guidelines
By default, Layer 3 health checking of real server IP addresses is enabled. Likewise, Layer 4 (TCP and
UDP) health checking of server ports is enabled by default.
Layer 3 health checking can be CPU-intensive. To help reduce unnecessary processing overhead, if you
are using Layer 4 or Layer 7 health checking of a real server’s ports, it is recommended to disable Layer
3 health checking of that server’s IP address.
For large deployments (1000 or more servers), A10 Networks recommends disabling default Layer 3
health check and using only Layer 4-7 health checks. (See “Globally Disabling Layer 3 Health Checks”
on page 669.)
Health Method Timers

Health methods operate based on the following timers:
• Interval – Number of seconds between health check attempts. Determination of server or port
health is not made during the interval. Instead, health determination is made after the server or
port passes or fails one attempt (interval), or the number of retries is exhausted.
Default interval is 5 seconds. You can change it to a value from 1-180 seconds.
• Timeout – Number of seconds the ACOS device waits for a reply to a health check. If the ACOS
device does not receive the expected reply by the end of the timeout, the ACOS device either
sends the health check again (if there are retries left) or marks the server or service down. You
can specify 1-180 seconds. The default is 5 seconds.
page 628
The type of reply expected by the ACOS device depends on the monitor type. (See “Health Method
Types” on page 632.)
• Retries – maximum number of times the ACOS device sends the same health check to an unre-
sponsive server or service before marking that server or service as down. You can specify 1-5.
The default is 3.
• Up-Retry – Number of consecutive times the device must pass the same periodic health check,
in order to be marked Up. You can specify 1-10. The default is 1. (See “Consecutive Health
Checks Within a Health Check Period” on page 665).
The default interval and timeout can be adjusted automatically by health-check rate limiting. (See
“Health-Check Rate Limiting” on page 669). The timeout does not apply to externally configured health
monitors.
Health Check Operation

The figures in this section show how health checking operates:
• Example When Server or Port Is Unresponsive
• Example When Server or Port Is Responsive
Example When Server or Port Is Unresponsive

Figure 78 shows how health checking operates when the server or port is unresponsive.
After each interval, ACOS 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.
page 629
FIGURE 78 Health Checks Using Default Settings – Server or Port Is Unresponsive
page 630
Example When Server or Port Is Responsive

Figure 79 shows health checking operation when the server or port is responsive. ACOS begins the next
health check when the next interval begins which, using the default interval value, the next interval
begins within 5 seconds.
FIGURE 79 Health Checks Using Default Settings – Server or Port Responds
page 631
Health Method Types
Health Method Types

Table 17 lists the internal health method types supported by the ACOS 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 parame-
ters. 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.
To configure a health monitor for Direct Server Return (DSR), see “Configuring Health Monitoring of Vir-
tual IP Addresses in DSR Deployments” on page 641.
TABLE 17Internal Health Method Types

Configuration Required on
Type Description Successful If... Target Server
Data- ACOS device sends a query to Server sends a reply with the Database must contain the
base the database. The database expected query results. queried data.
can be one of the following
types: For replies that consist of multiple Requested user name and
results, the results are in a table. password must be valid on
• Oracle You can specify the row and col- the server.
• MSSQL umn location within the results
• MySQL table to use as the receive string.
• PostgreSQL
(For more information, see “Data-
base Health Monitors” on
page 672.)
page 632
Health Method Types
TABLE 17Internal Health Method Types (Continued)

DNS ACOS device sends a lookup Server sends a reply with the Domain name in the lookup
request for the specified expected status code (0 by default) request must be in the
domain name or server IP and record type (A by default). server’s database.
address.
You can configure the response
By default, recursion is code(s) and record type required
allowed. The tested DNS for a successful health check.
server is allowed to send the
health check’s request to You can require the server to reply
another DNS server if the with specific status codes within
tested server can not fulfill the the range 0-15.
request using its own data-
base. Optionally, you can dis- For health checks sent to a domain
able recursion. name, you can require the server to
reply with one of the following
record types:
• A – IPv4 address record (the

default)
• CNAME – Canonical name
record for a DNS alias
• SOA – Start of authority record
• PTR – Pointer record for a
domain name
• MX – Mail Exchanger record
• TXT – Text string
• AAAA – IPv6 address record
(For more information, see “Cus-

tomizing DNS Health Monitors” on
page 652.)
FTP ACOS device sends an FTP Server replies with FTP OK mes- Requested user name and
login request to the specified sage or Password message. password must be valid on
port. the server.
If the server sends the Password
If anonymous login is not message, the ACOS device sends
used, the username also must the password specified in the
be specified in the health health check configuration. In this
check configuration. case, the ACOS device expects the
server to reply with another OK
message.
page 633
Health Method Types

HTTP / ACOS device sends an HTTP Server replies with OK message Requested page (URL)
HTTPS GET, HEAD, or POST request (200), by default. You can config- must be present on the
to the specified TCP port and ure the response code(s) and server.
URL. record type required for a success-
ful health check. For GET requests, the
• GET requests the entire string specified as the
page. For GET requests, the server also expected reply must be
• HEAD requests only meta- must reply with the requested con- present.
information in the header. tent or meta-information in the
• POST attempts to write page header. The response must For POST operations, the
information to the server. include the string specified in the field names specified in the
For POST requests, you
must specify the target field Expect field on the ACOS device. health check must be pres-
names and the values to ent on the requested page.
post. (For more informa- For HEAD requests, the ACOS
tion, see “Configuring POST device ignores the Expect field and For HTTPS health checks,
Requests in HTTP/HTTPS only checks for the server reply SSL support must be
Health Monitors” on
page 646.) message. enabled on the server.
If a user name and password For POST operations, the data A certificate does not need
are required to access the must be posted without error. to be installed on the ACOS
page, they also must be speci- device. ACOS always
fied in the health check con- accepts the server certifi-
figuration. cate 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.
The following types of authen-

tication are supported: basic,
digest and NT LAN Manager
(NTLM) authentication. If you
specify a username and pass-
word, the health monitor will
try to use basic authentication
first. If this try succeeds, the
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 authentica-
tion method.
For HTTPS health checks, the

ACOS device encapsulates
SSLv3, TLSv1, TLSv1.1, or
TLSv1.2 hello messages
within the SSLv2 hello mes- page 634
sages by default. You can dis-
able this encapsulation.
Health Method Types

ICMP ACOS device sends an ICMP Server replies with an ICMP echo Server must be configured
echo request (ping) to the reply message. to reply to ICMP echo
server. requests.
The transparent option is

applicable for testing the path
from an ACOS device to a tar-
get device through an interme-
diate device.
This is a Layer 3 health check

only. Use the other method
types to check the health of a
specific application.
IMAP ACOS device sends an IMAP Server replies with an OK message. Requested user name and
user login request with the password must be valid on
specified user parameter. The ACOS device then sends the the server.
password specified in the health
check configuration. The ACOS
device expects the server to reply
with another OK message.
Ker- Depending on the method Kerberos server responds and Valid administrator and
beros options used, a Kerberos allows access. end-user accounts.
health monitor can check
accessibility to each of the
following:
• Key Distribution Center

(KDC) Ticket Granting
Ticket (TGT) service –
Tests ability to access the
Kerberos server as a new
client requesting a TGT.
• Kerberos administrative
system – Tests ability to
access the Kerberos server
as a user account adminis-
trator.
• Kerberos password change
system – Tests ability to
access the Kerberos server
as a user attempting to
change their password.
page 635
Health Method Types

LDAP ACOS sends an LDAP request Server sends a reply containing If a Distinguished Name
to the LDAP port. result code 0. and password are sent in
the health check, they must
Optionally, the request can be match these values on the
directed to a specific Distin- LDAP server.
guished Name.
A certificate does not need
SSL can be enabled for the to be installed on the ACOS
health check. device. The ACOS device
always accepts the server
The ACOS also must send a certificate presented by the
valid password, if one is server.
required by the server.
NTP ACOS device sends an NTP Server sends a standard NTP 48- NTP service must be run-
client message to UDP port byte reply packet. ning.
123.
POP3 ACOS device sends a POP3 Server replies with an OK message. Requested user name and
user login request with the password must be valid on
specified user parameter. The ACOS device then sends the the server.
password specified in the health
check configuration. The ACOS
device expects the server to reply
with another OK message.
RADIUS ACOS device sends a Pass- Server sends Access-Accepted Requested user name and
word Authentication Protocol message (reply code 2). password must be config-
(PAP) request to authenticate ured in the server’s user
the user name and password You can specify response code(s) database.
specified in the health check that ACOS accepts as valid
configuration. responses. For example you can Likewise, the shared secret
configure a health monitor to sent in the health check
accept an Access-Reject response must be valid on the server.
(code 3) as a valid response from a
healthy RADIUS server.
RTSP ACOS device sends a request Server replies with information The file must be present on
for information about the file about the specified file. the RTSP server.
specified in the health check
configuration.
SIP ACOS device sends a SIP Server replies with 200 - OK. None.
OPTION request or REGIS-
TER request.
SMTP ACOS device sends an SMTP Server sends an OK message (reply Server recognizes and
Hello message. code 250). accepts the domain of
sender. If SMTP service is
running and can reply to
Hello messages, the server
can pass the health check.
page 636
Health Method Types

SNMP ACOS device sends an SNMP Server replies with the value of the Requested OID and the
Get or Get Next request to the OID. SNMP community must
specified OID, from the speci- both be valid on the server.
fied community.
TCP ACOS device sends a connec- Server replies with a TCP SYN ACK. Destination TCP port of the
tion request (TCP SYN) to the health check must be valid
specified TCP port on the By default, the ACOS device com- on the server.
server. pletes the TCP handshake with the
server:
ACOS -> Server
SYN ->
<- SYN-ACK
ACK ->
FIN ->
<- FIN-ACK
ACK ->
To configure the ACOS 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 fol-
lows:
SYN ->
<- SYN-ACK
RST ->
UDP ACOS device sends a packet Server does either of the following: Destination UDP port of the
with a valid UDP header and a health check must be valid
garbage payload to the speci- • Replies from the specified UDP on the server.
fied UDP port on the server. port with any type of packet.
• Does not reply at all.
The server fails the health check

only if the server replies with an
ICMP Error message.
page 637
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 on-demand health check to a server without specifying the
protocol port. (See “On-Demand Health Checks” on page 667.)
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 configura-
tion. In this case, you can override the IP address or port using the override options described in “Over-
riding the Target IP Address or Protocol Port Number” on page 655.

1. Create a new health monitor and configure its settings for the type of service you are monitoring
and the ciphers for the monitor to use. If you created the monitor externally with a script, import
the script.
The GUI does not support selecting the SSL ciphers ACOS uses. To select SSL ciphers for the
health monitor feature, use the CLI.
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.
Configuring and Applying a Health Method Using the GUI

Configure an Internal Monitor
This example creates TCP a health monitor called “hm1:”

2. Click Create.
3. In the Name field under the General Fields section, enter hm1.
4. Click the Method type drop-down menu, and select TCP.
The rest of the configuration fields change depending on which type of health monitor you select.
(See “Health Method Types” on page 632.)
5. Click Create Monitor. The new monitor appears in the Health Monitor table.
page 638
Import an Externally Configured Monitor
This example imports an external monitor called “ext-hm:”
1. Create a script for the monitor. (For an example, see “Using External Health Methods” on
page 684.)
2. In the GUI, select ADC > Health Monitors.
3. From the menu bar, select the External Programs tab.
4. Click Create.
5. In the Name and Description fields, enter a name and description for the external health method.
6. Copy and paste the script into the Definition field.
7. Click Create. The method appears in the External Program Name table.
Apply a Layer 3 Health Monitor to a Real Server Template
This example shows how to apply the health monitor “hm1” to a new real server template named “rs-
template.”

2. Select the SLB tab from the menu bar, if not already selected.
3. Create a real server template, and apply the health monitor to the template:
a. Click Create to create the template, and select Server from the drop-down list.
b. In the Name field, enter rs-template.
c. In the Health Monitor field, select hm1 from the drop-down list or available health monitors.
d. Click OK.
Apply a Layer 3 Health Monitor to a Real Service Port Template
This example shows how to apply the health monitor “hm1” to a new real service port template named
“rsp-template.”

2. Select the SLB tab from the menu bar, if not already selected.
3. Create a real server port template, and apply the health monitor to the template:
a. Click Create to create the template, and select Port from the drop-down list.
b. In the Name field, enter rsp-template.
c. In the Health Monitor field, select hm1 from the drop-down list or available health monitors.
page 639
d. Click OK.
Apply a Layer 3 Health Monitor to an Individual Real Server or Service Port
Layer 3 health checking can be CPU-intensive. To help reduce unnecessary processing overhead, if you
are using Layer 4 or Layer 7 health checking of a real server’s ports, it is recommended to disable Layer
3 health checking of that server’s IP address.

2. From the menu bar, select the Servers tab.
3. Select the server or click Create to create a new one.
4. To apply a Layer 3 health monitor to the server, select the health monitor from the Health Moni-
tor drop-down list.
5. To apply a health monitor to a service port:
a. In the Port section, click Create.
b. In the Port Number field, enter the port number.
c. Click the Protocol drop-down menu and select TCP or UDP.
d. Next to the Health Check, select the desired radio button from these choices:
Default, Disable, Monitor, or Follow Port
e. If you select the Monitor radio button, the Health Monitor drop-down menu appears. Click
the menu and select the desired health monitor from the list.
6. Enter or change other settings if needed, such as Connection Limit or No Logging.
7. Click Create.
To apply a Layer 3 health monitor to a service group

2. On the menu bar, select the Service Groups tab.
3. Select one of the existing service groups that appear, or click Create to add a new one.
4. Click the Health Monitor drop-down list and select the desired health monitor.
5. Enter or change other settings if needed.
6. Click Create or Update.
(For more information about how health monitors are used when applied to service groups, see “Ser-
vice Group Health Checks” on page 658.)
page 640
Configuring and Applying a Health Method Using the CLI
Configure an Internal Monitor
The following example configures an internal TCP health monitor named “hm1:”
ACOS(config)# health monitor hm1

ACOS(config-health:monitor)# method tcp port 80
The method-name can be one of the types listed in “Health Method Types” on page 632. Also see that
section for additional options you can specify. For syntax information, see the “Config Commands: SLB
Health Monitors” chapter in the Command Line Interface Reference.
Import an Externally Configured Monitor
Create an external Tcl script for the monitor. (For an example, see “Using External Health Methods” on
page 684.)
The following example shows how to import the external health monitor named “ext-hm” using ftp:
ACOS(config)# import health-external ext-hm ftp://examplehost/script/ext-hm
After the external monitor script is imported, create a new health monitor named “hm2” to use the
script:

ACOS(config-health:monitor)# method external program ext-hm
Apply the Health Monitor to a Real Server Template or Real Service Port Template
The following example applies the health monitor “hm1” to real server template “svr-template:”
ACOS(config)# slb template server svr-template

ACOS(config-rserver)# health-check hm1
Apply the Monitor to an Individual Real Server or Service Port
The following example applies the health monitor “hm1” to a service port on real server “rs1:”

ACOS(config-real server-node port)# health-check hm1
Configuring Health Monitoring of Virtual IP Addresses in DSR

Deployments
Layer 3 and Layer 4-7 health checks are supported in DSR configurations.
page 641
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.
Layer 4-7 health checks are sent to the same IP address as the Layer 3 health checks, and then
addressed to the specific protocol port. You can use the default TCP and UDP health monitors or con-
figure new health monitors. This example uses the default TCP health monitor.
The following sections show how to configure Layer 3 health checking of virtual IP addresses and how
to globally enable DSR health checking of virtual IP addresses. A complete DSR deployment requires
additional configuration. See the examples in “Direct Server Return (DSR) SLB Deployment” on page 69.
External health monitoring is not currently supported for DSR deployments.
Using the GUI

To configure a Layer 3 health method targeted to a virtual IP address:
4. Click the Method Type drop-down list and select ICMP. The ICMP section appears in the pane in
the right.
a. Select the Transparent checkbox in the ICMP section below.
b. Select the desired address type, IPv4 or IPv6, and enter the loopback address.
5. Click Create Monitor.
To globally enable DSR health checking of virtual IP addresses:

2. From the menu bar, select the Global tab.
3. Select the DSR Health Check Enable checkbox.
4. Click Update.
page 642
Using the CLI
To configure a Layer 3 health method targeted to a virtual IP address:
Use the following commands to configure a health method target to VIP 192.168.4.4:

ACOS(config-health:monitor)# method icmp transparent 192.168.4.4
To globally enable DSR health checking of virtual IP addresses:
Use the following commands:

ACOS(config-common)# dsr-health-check-enable
(Enter the slb common command from the global configuration level to access the configuration level
for system-wide SLB parameters.)
Using Send and Receive Strings in TCP Health Checks

ACOS supports use of send and receive text strings in TCP health checks. Send and receive string allow
you to add additional intelligence to TCP health monitors. ACOS sends the specified send string to the
target TCP port, and watches for the specified reply.
For example, you can configure a send string that is an HTTP GET request, and specify the response
string the server must send in reply to the GET request. (See the CLI example below.)
TCP health monitors that include send and receive strings work as follows:
1. ACOS performs the TCP three-way handshake with the TCP port on the server:
ACOS Server
SYN ->
<- SYN-ACK
ACK ->
2. If the three-way handshake is successful, ACOS sends the entire send string to the TCP port.
ACOS Server
ACK ->
3. If the port’s reply contains the specified receive string anywhere within the reply, the port passes
the health check.
ACOS Server
<- ACK
4. ACOS and server complete the handshake.

ACOS Server
page 643
FIN ->
<- FIN-ACK
ACK ->
Using the GUI
The following example configures a TCP health monitor named “tcp-with-http-get” that sends an HTTP
GET request to TCP port 80, and expects the string “200” to be present in the reply:

3. In the Name field, enter tcp-with-http-get.
4. Click the Method Type drop-down list and select TCP. The TCP section appears.
a. In the Send field, enter the following:
GET / HTTP/1.1\r\nHost: 22.1.2.2\r\nUser-Agent: a10\r\nAccept: */*\r\n\r\n
b. In the Response Contains field, enter 200.

page 644
Using the CLI
The following example configures a TCP health monitor named “tcp-with-http-get” that sends an HTTP
GET request to TCP port 80, and expects the string “200” to be present in the reply:
ACOS(config)# health monitor tcp-with-http-get

ACOS(config-health:monitor)# method tcp port 80 send "GET / HTTP/1.1\r\nHost:
22.1.2.2\r\nUser-Agent: a10\r\nAccept: */*\r\n\r\n" response contains 200
This health monitor sends an HTTP GET request to TCP port 80 on the target server. This particular
request uses the following header fields:
• Host – Specifies the host (server) to which the request is being sent.
• User-Agent – Identifies the entity (user agent) that is sending the request. In this example, the
sending entity is “a10”.
• Accept – Specifies the types of media that are allowed in the response. This example uses wild-
cards (*/*) to indicate that any valid media type and range are acceptable.
If the string “200” is present anywhere in the reply from the port, the port passes the health check.
Certificate and Key Support in HTTPS Health Monitors

You can add an SSL certificate and key to an HTTPS health monitor. When you use this option, the
ACOS device uses the certificate and key during the SSL handshake with the HTTPS port on the server.
The certificate you plan to use with the health monitor must be present on the ACOS device before you
configure the health monitor.
Using the GUI

3. In the Name field, enter the health monitor name.
4. Click the Method Type drop-down list and select HTTPS. The HTTPS section appears.
a. In the Client certificate field, select the certificate from the drop-down list.
b. In the Client Private Key field, select the key from the drop-down list.
c. If applicable, enter the pass phrase in the Key Password Phrase field.
Using the CLI
To add a certificate and key to an HTTPS health monitor, use the cert and key options with the method
https command.
page 645
The following commands configure an HTTPS health monitor that uses a certificate:
ACOS(config)# health monitor https-with-key

ACOS(config-health:monitor)# method https cert cert-for-health-checks key key1
Configuring POST Requests in HTTP/HTTPS Health Monitors

You can specify a POST operation in an HTTP or HTTPS health monitor. A POST operation attempts to
post data into fields on the requested page.
Using the GUI
The following example configures an HTTP health method names “http1” that uses a POST operation
to post firstname=abc and lastname=xyz to /postdata.asp on the tested server.

3. In the Name field, enter http1.
4. In the Method Type section, select HTTP from the drop-down list. Configuration fields for HTTP
health monitoring options appear.
5. Configure an HTTP POST operation:
a. Select the checkbox in the URL Type field.
b. In the URL Type field, select POST from the drop-down list.
c. In the Post Path field, enter /postdata.asp.
d. In the Post Type field, select POST Data.
e. In the Post Data field, enter firstname=fname&lastname=lname.
Use “=” between a field name and the value you are posting to it. If you post to multiple fields,
use “&” between the fields. The string can be up to 255 bytes long.
page 646
Using the CLI
The following commands configure an HTTP health method names “http1” that uses a POST operation
to post firstname=abc and lastname=xyz to /postdata.asp on the tested server.
ACOS(config)# health monitor http1

ACOS(config-health:monitor)# method http url POST /postdata.asp postdata first-
name=fname&lastname=lname
In the postdata string, use “=” between a field name and the value you are posting to it. If you post to
multiple fields, use “&” between the fields. For example: postdata fieldname1=value&fieldname2=value.
The string can be up to 255 bytes long.
To use POST data longer than 255 bytes, you must import a POST data file and use the POST / postfile
filename option. To import POST data file up to 2 Kbytes long, use the following command at the global
configuration level of the CLI:
page 647
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:
ACOS(config)# import health-postfile long-post scp://[email protected]/scripts/

...
ACOS(config)# health monitor http1
ACOS(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.
Automatic Interval Adjust Based on HTTP Status Code

Passive health monitoring optimizes health monitoring by increasing the health-check interval when
the servers are Up.
Passive health monitoring checks the HTTP status code in the initial server reply to a client request. If
the server sends enough replies that contain a status code indicating normal operational status, ACOS
increases the health-check interval for that server. By increasing the health-check interval, ACOS
reduces network overhead.
If a server’s healthy response codes fall below a configured threshold, the health monitor’s configured
interval is used again, to more frequently check server health.
Passive Health-monitoring Parameters

Passive health monitoring is activated and deactivated based on the following parameters. You can
configure these parameters in individual HTTP health monitors.
This feature has the following configurable parameters:
• Healthy status code numbers – The set of status codes that indicate the HTTP service is healthy.
You can specify one of the following:
• Any 2xx status code
• Any status code other than a 5xx code
You must specify the set of status codes to use when you configure the monitor. There is no
default.
• Passive interval – The health-monitor interval that is used when passive health monitoring is
activated. For proper operation of the feature, the passive interval should be longer than the
health monitor’s interval. You can specify 1-180 seconds. The default is 10 seconds.
• Sample threshold – Minimum number of server replies that must contain one of the specified
status codes, within a given one-second interval, before passive health monitoring is enabled.
The sample threshold helps prevent passive health monitoring from taking effect after only a
page 648
small total number of samples are taken. You can specify 1-10000 samples per second. The
default is 50.
• Threshold – Minimum percentage of server replies that must contain a healthy status code,
within a given one-second interval, before passive health monitoring is activated. You can specify
0-100 percent. The default is 75 percent. If you specify 0, this parameter is disabled, in which
case there is no minimum threshold.
Passive Health-monitoring Activation

Once per second, these parameters evaluate server responses to initial client requests. Within that
interval:
• If the threshold is exceeded after the sample threshold is exceeded, passive interval becomes
active.
• If sample threshold and threshold are not exceeded, health monitor interval setting remains in
effect.
Response statistics are reevaluated each second. Generally, once a server is up and healthy, the pas-
sive interval remains in effect for that server. Health-check traffic overhead for the server is reduced by
half.
Figure 80 shows an example of how passive health monitoring is activated.
page 649
FIGURE 80 Activation for passive health monitoring
In this example, the health monitor interval and each of the passive health-monitoring parameters
described above are left at their default values.
When the server first comes up, the health-check interval is set to 5 seconds, which is the interval set-
ting on the health monitor. The server's responses quickly exceed the sample threshold and threshold,
so passive health-monitoring mode is activated. this results in the health-check interval being reset t 10
seconds.
The longer interval remains in effect as long as the server responses exceed the thresholds.
Notes
• This feature applies only to TCP virtual ports, and only to the ICMP and HTTP health methods.
• Only the first packet in the reverse direction of a TCP session flow is inspected.
• If connection-reuse is enabled on the virtual port, only the response packet for the initial session
is examined.
Using the GUI

1. Navigate to ADC > Health Monitors.
2. Click Create or click the Edit link next to the name of a configured ICMP or HTTP health monitor.
3. If configuring a new monitor, enter a name and select the Method Type, ICMP or HTTP.
page 650
4. Select the Passive checkbox.

5. Customize any other settings as desired.
For information about the options, see “Passive Health-monitoring Parameters” on page 648.
6. If configuring an HTTP health monitor, configure HTTP settings as applicable to your deployment.
7. Click Create Monitor or Update Monitor.
Using the CLI
To configure inband health monitoring based on HTTP status code, use the passive command at the
HTTP health monitor configuration level. See “Passive Health-monitoring Parameters” on page 648.
The following commands create a new health monitor, and enable passive health-monitoring mode:
ACOS(config)# health monitor http-passive

ACOS(config-health:monitor)# passive status-code-2xx
The following command sets the method to HTTP:

The following commands configure a real server, service group, and virtual server. The HTTP health
monitor configured above is applied to the TCP port on the real server.
ACOS(config)# slb server ser1 172.168.1.107

ACOS(config-real server-node port)# health-check http-passive
ACOS(config-slb svc group)# member ser1 80
page 651
Customizing DNS Health Monitors

ACOS provides the following configurable options for DNS health monitors
• Expected response codes – You can specify a list of response codes, in the range 0-15, that are
valid responses to a health check. If the tested DNS server responds with any of the expected
response codes, the server passes the health check. By default, the expect list is empty, in which
case the ACOS 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 ful-
fill the request using its own database. Recursion is enabled by default.
• Record type expected from the server – You can specify one of the following record types:
• A – IPv4 address record

• CNAME – Canonical name record for a DNS alias
• SOA – Start of authority record
• PTR – Pointer record for a domain name
• MX – Mail Exchanger record
• TXT – Text string
• AAAA – IPv6 address record
By default, the ACOS device expects the DNS server to respond to the health check with an A
record.
Using the GUI

2. Click Create.
3. In the General Fields section, enter a name for the monitor in the Name field.
4. In the Method Type section, select DNS from the 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 Override Port field.
6. To test a specific server, enter the address in the IPv4 Address field. Otherwise, to test based on a
domain name sent in the health check, select Domain and enter the domain name in the Domain
field.
7. If you select Domain, select the record type the server is expected to send in reply to health checks.
Select the record type from the Domain Type drop-down list.
8. If you do not want to allows recursion, select Disabled in the IPv4 Recurse drop-down menu.
page 652
9. To specify the response codes that are valid for passing a health check, enter the codes in the
Domain Response Code field. To specify a range, use a dash. Separate the codes (and code
ranges) with commas.
10.Click Create Monitor.
Using the CLI
To configure a DNS health monitor, use the health monitor and method dns commands.
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:
ACOS(config)# health monitor dnshm1

ACOS(config-health:monitor)# method dns domain www.example.com expect response-code 0-3,5
page 653
DNS Health Monitoring over TCP

ACOS also supports use of DNS health monitoring over TCP.
Using the GUI
On the configuration page for the DNS health monitor, select the IPv4, IPv6, or Domain TCP option,
depending on which DNS type you select.
Using the CLI
To enable TCP instead of UDP for a DNS health monitor, use the tcp option with the method dns com-
mand.
The following example configures a health monitor for DNS over TCP:
ACOS(config)# health monitor dns-tcp

ACOS(config-health:monitor)# method dns domain www.example.com tcp
page 654
Overriding the Target IP Address or Protocol Port Number

ACOS provides options to override the real server IP address or protocol port number to which health
checks are addressed.
By default, the ACOS device sends a Layer 3 health check to the IP address used in the real server con-
figuration. Likewise, the ACOS device sends Layer 4-7 health checks to the real port number in the real
server’s configuration. For GSLB service IPs, the ACOS 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 ACOS 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
ACOS device always addresses the health check to the override address or port. This option is particu-
larly useful for testing the health of a remote link, as in the following example.
FIGURE 81 Example of Health-check Address Override
In this example, the real servers managed by the site ACOS are configured as service IPs
192.168.100.100-102 on the GSLB ACOS. The health-check metric is enabled in the GSLB policy, so
page 655
health checks are needed to verify that the service IPs are healthy. One way to do so is to check the
health of the ISP link connected to the site ACOS device.
Because the GSLB ACOS device is deployed in route mode instead of transparent mode, the transpar-
ent 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 ACOS device in this example uses the
health monitor to check the health of a service IP, the device addresses the health check to
192.168.1.1, the override address, instead of addressing the health check to the service IP addresses.
Override Parameters
You can independently configure any of the following override parameters for a health monitor:
• Target IPv4 address
• Target IPv6 address
• Target Layer 4 protocol port number
The override is used only if applicable to the method (health check type) and the target. An IP address
override is applicable only if the target has the same address type (IPv4 or IPv6) as the override
address.
A protocol port override is applicable to all health methods except ICMP. If the protocol port number is
explicitly configured for the method, the override port number is still used instead.
Using The GUI

2. Click edit next to the health monitor name or click Create to create a new one.
3. For an ICMP health monitor:
a. Leave ICMP selected in the Method 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 Over-
ride Port field.
5. Click Create Monitor or Update Monitor. The health monitor list re-appears.
Using The CLI
Use the override-ipv4, override-ipv6, or override-port commands at the configuration level for the
health monitor.
The following example configures a health monitor for the service IPs shown in Figure 81 on page 655,
and apply the monitor to the service IPs.
page 656
ACOS(config)# health monitor site1-hm

ACOS(config-health:monitor)# method icmp
ACOS(config-health:monitor)# override-ipv4 192.168.1.1
ACOS(config)# gslb service-ip gslb-srvc1 192.168.100.100
ACOS(config-service-ip:gslb-srvc1)# health-check site1-hm
ACOS(config-service-ip:gslb-svrc1)# exit
ACOS(config-service-ip:gslb-srvc2)# exit
ACOS(config-service-ip:gslb-srvc3)# exit
Basing a Port’s Health Status on Another Port’s Health Status

You can configure the ACOS device to base a real port’s health status on the health status of another
port number. The real port and the port to use for the real port’s health status must be the same type,
TCP or UDP.
Using the GUI

1. Navigate to the real server configuration page (ADC >> SLB >> Servers > server_name >> Port >>
Create).
2. Select Follow Port in the Health Check field.
a. Select TCP or UDP from the drop-down list in the Follow Port Protocol field.
b. In the Follow Port field, enter the port number where you want to base the health of the real
port.
3. Click Create.
page 657
Service Group Health Checks
Using the CLI
Use the health-check-follow-port command at the configuration level for the real port.
The following example configures the real port (80) to follow TCP port 8081:

ACOS(config-real server-node port)# health-check-follow-port 8081 tcp

You can assign a health monitor to a service group. This is useful in cases where the same server pro-
vides content for multiple, independent sites. When using the feature, if a site is unavailable (for exam-
ple, taken down for maintenance), the server fails the health check for that site, and clients are not sent
to the site. However, other sites on the same server pass their health checks, and clients of those sites
are sent to the server.
Figure 82 shows an example.
page 658
FIGURE 82 Service Group Health Checks
In this example, a single server provides content for the following sites:
• www.media-rts.com
• www.media-tuv.com
• www.media-wxyz.com
All sites can be reached on HTTP port 80 on the server. The health check configured on the port in the
real server configuration results in the same health status for all three sites. All of them either are up or
are down.
In this case, if one of the sites is taken down for maintenance, the health 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 ACOS device to separately test the health of each site, by assigning each site to
a separate service group, and assigning a separate Layer 7 health monitor to each of the service
groups. In this case, if a site is taken down for maintenance, that site fails its health check while the
other sites still pass their health checks, on the same real port.
In this example, a separate HTTP health method is configured for each of the services. The health mon-
itors 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.
page 659
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 ser-
vice group members are marked Down. However, if a health check on the service group level (3) fails,
only that service group member in that service group is marked Down.
To assign a health monitor to a service group, use either of the following methods.
Using the GUI
In the Service Group configuration page (ADC >> SLB >> Service Groups >> Update), select the
monitor from the drop-down list in the Health Monitor field.
Using the CLI
The commands in this section implement the configuration shown in Figure 82.
The following commands configure the health monitors for each site on the server:
ACOS(config)# health monitor qrs

ACOS(config-health:monitor)# method http url GET /media-qrs/index.html
ACOS(config)# health monitor tuv
ACOS(config-health:monitor)# method http url GET /media-tuv/index.html
ACOS(config)# health monitor wxyz
ACOS(config-health:monitor)# method http url GET /media-wxyz/index.html
The following commands configure the real server:
page 660
ACOS(config)# slb server media-rs 10.10.10.88

ACOS(config)# slb service-group qrs tcp

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

ACOS(config-slb vserver-vport)# service-group qrs
ACOS(config)# slb virtual-server media-tuv 192.168.1.11
ACOS(config-slb vserver-vport)# service-group tuv
ACOS(config)# slb virtual-server media-wxyz 192.168.1.12
ACOS(config-slb vserver-vport)# service-group wxyz
To clear a port protocol session immediately if a member of a real service group level fails, enter the del-session-on-
server-down command when configuring the port of that member. For the above example, the configuration of the
media-rs real server would be as follows:
ACOS(config)# slb server media-rs 10.10.10.88

page 661
Disable Following Failed Health Check
ACOS(config-real server-node port)# del-session-on-server-down

Disable Following Failed Health Check

You can configure the ACOS device to disable a server, port, or service group if the server, port, or ser-
vice 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.
ACOS 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 CLI
Use the following commands:

ACOS(config-helath:monitor)# 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 cli-
ent’s traffic to another server and port if necessary. An in-band health check can also mark a port down.
In-band health monitoring is supported for the following service types:
• TCP
• HTTP
• HTTPS
page 662
Relationship To Standard Layer 4 Health Monitoring
The in-band health check works independently of and supplements the standard Layer 4 health check.
For example, for TCP, the standard health check works as follows by default:
Every 30 seconds, the ACOS device sends a connection request (TCP SYN) to the specified TCP port on
the server. The port passes the health check if the server replies to the ACOS device by sending a TCP
SYN ACK.
This is the same Layer 4 health check available in previous releases and has the same defaults.
In-band health monitoring works as described below.
It is recommended that you continue to use standard Layer 4 health monitoring even if you enable in-
band health monitoring. Without standard health monitoring, a server port marked down by an in-band
health check remains down.
How In-Band Layer 4 Health Monitoring Works
In-band health monitoring for services on TCP watches client-server SYN handshake traffic, and incre-
ments 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 ACOS device incre-
ments a session’s retry counter each time a SYN ACK is late. If the retry counter exceeds the con-
figured maximum number of retries allowed, the ACOS device sends the next SYN for the session
to a different server. ACOS 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 ACOS device increments the reassign counter for the server port. If
the reassign counter exceeds the configured maximum number of reassignments allowed, the
ACOS device marks the port DOWN.
In this case, the port remains DOWN until the next time the port successfully passes a standard
health check. Once the port passes a standard health check, the ACOS device starts using the port
again and resets the reassign counter to 0.
You can set the reassign counter to 0-255 reassignments. The default is 25 reassignments.
In-band health monitoring is disabled by default.
Logging and Traps
When the ACOS device marks a server port down, the device generates a log message and an SNMP
trap, if logging or SNMP traps are enabled. The message and trap are the same as those generated
when a server port fails a standard health check. However, you can discern whether the port was
marked down due to a failed in-band health check or standard health check, based on the process
name listed in the message.
page 663
• A10lb – The port was marked down by an in-band health check.
• A10hm – The port was marked down by a standard health check.
Here is an example of a log message generated from each process:
Sep 08 2014 17:15:04 Info A10LB SLB server s-3-2-1 (10.3.2.1) port 80 is down.
Sep 08 2014 17:15:04 Info A10HM SLB server s-3-2-1 (10.3.2.1) port 80 is down.
In-band health monitoring does not mark ports up. Only standard health monitoring marks ports up. So
messages and traps for server ports coming up are generated only by the A10hm process.
Configuring In-Band Health Monitoring

To configure in-band health monitoring:
1. Enable the feature in a server port template.

2. Bind the port template to real server ports, either directly or in a service group.
Using The GUI
To configure in-band health monitoring in server port template:
1. Select ADC > Template.

2. Click the Edit link in the Actions column for an existing tempalte, or click Create and select Port
from the drop-down list to create a new port template.
3. Select the checkbox in the Inband Health Check field.
4. Enter other parameters as needed (for example, the template name, if you are creating a new tem-
plate).
5. Click OK or Update.
To bind the template to a server port, see “Binding a Server Port Template to a Real Server Port” on
page 613.
Using The CLI
To configure in-band health monitoring, use the inband-health-check command at the configuration
level for the server port template:
The following example enables in-band health monitoring in a server port template called rp-tmplt2 and
binds this template to real ports 80 on server rs1, and real port 80 on server rs2:
ACOS(config)# slb template port rp-tmplt2

ACOS(config-rport)# inband-health-check
page 664
Consecutive Health Checks Within a Health Check Period

ACOS(config-real server-node port)# template port rp-tmplt2
ACOS(config-real server-node port)# template port rp-tmplt2
Consecutive Health Checks Within a Health Check Period

You can configure the number of times the target device must consecutively reply to the same periodic
health check in order to pass the health check.
By default, a server or port needs to successfully reply to a given health check only one time in order to
pass the health check. The server or port is then considered to be up until the next periodic health
check. You can set the required number of consecutive passes to 1-10.
You can configure this parameter on an individual health monitor basis. The setting applies to all health
checks that are performed using the health monitor.
Using the GUI

2. Click on the Edit button next to the monitor name or click Create to add a new one.
3. If new, in the General Fields section, enter a name for the monitor.
4. If new, in the Method Type section, select the monitor type from the drop-down list, and enter or
select settings for the monitor.
5. Select the checkbox in the Passive field.
6. In the Passive Interval field, enter the number of consecutive times the target must pass the same
periodic health check.
7. Click Create Monitor or Update Monitor.
Using the CLI
To configure consecutive health checks using the CLI, use the up-retry command. For example:

ACOS(config-health:monitor)# up-retry 3
page 665
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 “Mainte-
nance”. 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 ACOS 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 maintenance code. In this case,
the server’s health status changes to Up.
• Fail a health check. In this case, the server’s status changes to Down.
The Maintenance health status applies to server ports and service-group members. When a port’s sta-
tus changes to Maintenance, this change applies to all service-group members that use the port.
NOTE: This feature applies only to servers in cookie-persistence or source-IP

persistence configurations, and can be used only for HTTP and HTTPS
ports.
Using the 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 503:

ACOS(config-health:monitor)# method http maintenance-code 503
In this example, if the server replies with status 503, the server goes into maintenance mode and stays
there until server replies with status code 200 (UP).
In this example, if the server replies with code 503, the server goes into maintenance mode, and stays
there until the server either fails a health check (Down) or replies with code 200 (Up).
page 666
On-Demand Health Checks
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 CLI
To test the health of a server, use the health-test command at the EXEC, Privileged EXEC, or global
configuration level of the CLI:
If an override IP address and protocol port are set in the health monitor configuration, the ACOS device
uses the override address and port, even when an address and port is specified when the on-demand
health check is sent.
CLI Example
The following command tests port 80 on server 192.168.1.66, using configured health monitor hm80:
ACOS# health-test 192.168.1.66 monitorname hm80

node status UP.
Enabling Strict Retries

Some types of health monitors do not use the retry parameter by default. For these health monitors,
the ACOS 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 ACOS device
immediately marks the port Down.
To force the ACOS 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 CLI
The following example configures an HTTP health monitor that checks for the presence of “test-
page.html”, and enable strict retries for the monitor.
ACOS(config)# health monitor http-exhaust

ACOS(config-health:monitor)# method http url GET /testpage.html
ACOS(config-health:monitor)# strict-retry-on-server-err-resp
page 667
Globally Changing Health Monitor Parameters
Globally Changing Health Monitor Parameters

You can globally adjust health monitor parameters, including the following:
• Interval – Number of seconds between health check attempts.
• Timeout – Number of seconds the ACOS device waits for a reply to a health check.
• Retries – maximum number of times the ACOS device will send the same health check to an
unresponsive server or service before marking that server or service as down.
• Up-Retry – Number of consecutive times the device must pass the same periodic health check,
in order to be marked Up.
Globally changing a health monitor parameter changes the default for that parameter. For example, if
you globally change the interval from 5 seconds to 10 seconds, the default interval becomes 10 sec-
onds.
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 con-
figured before the change, you must reboot the ACOS device.
When auto-adjust mode for health-check rate limiting is enabled and the global interval or timeout set-
ting differs from the setting on an individual health monitor, actual interval and timeout values used
depend on the number of health checks performed by the ACOS device. See “Health-Check Rate Limit-
ing” on page 669.
To globally change health monitor parameters, use the health global command.
CLI Example
The following commands globally changes the default number of retries to 5:
ACOS(config)# health global

ACOS(config-health:global)# retry 5
The following commands globally changes the interval and timeout to 10 seconds and default number
of retries to 4:

ACOS(config-health:global)# interval 10 timeout 10
ACOS(config-health:global)# retry 4
ACOS(config-health:global)# exit
page 668
Health-Check Rate Limiting
Globally Disabling Layer 3 Health Checks

Layer 3 health checks (ICMP pings) are enabled by default. For large deployments (1000 or more serv-
ers), 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 tem-
plate is used.
If a custom Layer 3 health monitor is enabled on an individual server, the health monitor is still used.
Using the CLI
Use the health-check-disable command to disable Layer 3 health monitoring in the template:
ACOS(config)# slb template server default

ACOS(config-rserver)# health-check-disable

Health-check rate limiting helps ensure health checks in large SLB deployments can be processed suc-
cessfully. In previous releases, without health-check rate limiting, it is possible for a server or port to fail
its health check because the ACOS device is unable to complete processing of the health check before
it times out.
Health-check rate limiting is enabled by default. Generally, you do not need to configure it. However,
you still may want to see the following section: “Health-Check Guidelines” on page 628.
Health-check rate limiting uses a threshold to limit the number of health-check packets the ACOS
device will send within a given 500-millisecond (ms) period. If additional health-check packets need to
be sent, the ACOS device waits until the next 500-ms period. Within any 500-ms period, the ACOS
device never sends more health-check packets than are allowed by the threshold.
Health-check rate limiting has an auto-adjust mode, which is enabled by default. When necessary, the
auto-adjust mode dynamically increases the default interval and timeout for health checks. By increas-
ing these timers, health-check rate limiting provides more time for health-check processing.
Health-check rate limiting is always enabled, and its auto-adjust mode is enabled by default.
page 669
Health-check Threshold
When auto-adjust mode is enabled, the health-check threshold is one of the following:
• ACOS models with 64-bit ACOS – 1600 health-check packets per 500-ms period
When auto-adjust mode is enabled, you can not manually change the threshold. To change the thresh-
old, you first must disable auto-adjust mode. Then you can set the threshold to a value within one of
the following ranges:
• ACOS models with 64-bit ACOS – 1-5000 health-check packets per 500-ms period
• ACOS models with 32-bit ACOS – 1-2000 health-check packets per 500-ms period
When you disable auto-adjust mode, the default threshold is changed to one of the following:
NOTE: It is recommended not to set the threshold to a very high value. Doing so
may result in health-check timeouts due to resource constraints.
Health-Check Interval and Timeout

When the auto-adjust mode for health-check rate limiting is enabled, and the global interval or timeout
setting differs from the setting on an individual health monitor, the actual interval and timeout values
that are used depend on the number of health checks performed by the ACOS device:
• More than 1000 health checks (64-bit models) or more than 400 health checks (32-bit models) –
Setting with the longer value is used. For example, if the global interval is 10 seconds but the
interval configured on an individual health monitor is 5 seconds, 10 seconds is used.
• Fewer than 1000 health checks (64-bit models) or fewer than 400 health checks (32-bit models)
– Setting on the individual health monitor is used.
Using the CLI

To display the current settings for health-check rate limiting, use the show health stat command. Here
is an example:
ACOS# show health stat

Health monitor statistics
Total run time: : 21 hours 31 minutes 31 seconds
page 670
Multi-CPU Support for Health Monitoring
Number of burst: : 0
...
Configured health-check rate (/500ms) : Auto configured
Current health-check rate (/500ms): : 5
...
The Configured health-check rate field and Current health-check rate show the health-check rate limit-
ing settings.
• If auto-adjust is enabled:
• Configured health-check rate – Shows “Auto configured”

• Current health-check rate – Shows the total number of health monitors divided by the global
health-check timeout:
total-monitors / global-timeout
• If auto-adjust is disabled:
• Configured health-check rate – Shows the manually configured threshold

• Current health-check rate – Shows the manually configured threshold
Changing the Threshold

To change the health-check rate limiting threshold:

ACOS(config-health:global)# disable-auto-adjust
ACOS(config-health:global)# check-rate 2000
Multi-CPU Support for Health Monitoring

ACOS includes a scalability feature that enables use of multiple CPUs for health-monitor processing.
Ensure that the health-monitor process number does not exceed the current number of control CPUs.
The maximum value for the health check-rate is 50000000.
Use the GUI to Configure Multi-CPU Support

To configure multi-CPU support from the GUI:
1. Navigate to ADC >> Health Monitors >> Global.

2. Select the number of CPUs from the drop-down list in the Multi Process field.
3. Click Update.
page 671
Database Health Monitors
Use the CLI to Configure Multi-CPU Support

Use the following commands to specify 2 processes to start health monitoring.

ACOS(config-health:global)# multi-process 2
You can monitor up to 20 processes, with the default value being 1.
It is recommend that you use this feature with multiple control CPUs. ACOS should be configured to
run multiple control CPUs before issuing the health multi-process command. For example:
ACOS(config)# multi-ctrl-cpu 2
This will modify your boot profile for multiple control CPUs.
It will take effect after the next reboot.
Please confirm: You want to configure multiple control CPUs (N/Y)?: y

You can configure database health monitors using the CLI or GUI, without the need to configure and
import scripts. Previous releases support database health monitors only with imported scripts. Simpli-
fied database health monitor configuration applies to the following database types:
• Oracle
• MSSQL
• MySQL
• PostgreSQL
Database Health Monitor Parameters

To configure a database health monitor, specify the following parameters.
Required Parameters
• Database type – Oracle, MSSQL, MySQL, or PostgreSQL
• Database name – Name of the database to query
• Username and password – Account information required for access to the database
page 672
Optional Parameters
• Send string – SQL query to send to the database.
• Receive string – Query result expected from the database in order to pass the health check.
• Receive row and column – For replies that consist of multiple results, the results are in a table.
You can specify the row and column location within the results table to use as the receive string.
If you do not specify the row and column, row 1 and column 1 are queried by default.
To use the receive string option, you also must use the send string option. If you do not use the send
option, the ACOS device does not send a query.
Using the GUI

To create a new database health monitor:
1. Hover over ADC in the menu bar, then select Health Monitors.
2. Select Create.
3. In the Name field, specify a name for your health monitor.
4. In the Method type field, select Database from the drop-down list.
5. Configure the desired values in the General Fields pane.
6. In the Database pane, select the database type from the Database Type field, then complete the
other parameters.
Using the CLI

The example in this section shows how to create an Oracle database health monitor:
ACOS(config)# health monitor dbhm1

ACOS(config-health:monitor)# method database oracle db-name orcl1 username admin password
welcome1
For additional information, see “Database Health Monitor Parameters” on page 672.
page 673
Kerberos Health Monitors

ACOS provides health monitoring for Kerberos AAA servers. A Kerberos health monitor can contain
separate methods for checking accessibility to each of the following:
• Key Distribution Center (KDC) Ticket Granting Ticket (TGT) service – Tests ability to access the
Kerberos server as a new client requesting a TGT.
• Kerberos administrative system – Tests ability to access the Kerberos server as a user account
administrator.
• Kerberos password change system – Tests ability to access the Kerberos server as a user
attempting to change their password.
These services can be on the same server (hostname or IP address) or different servers.
You can use these health checks in AAA SLB deployments and in Authentication Proxy deployments.
Health checks for access to the Kerberos administrative system are not supported with Windows
Server Domain Controllers (DCs).
Using the GUI

1. Navigate to ADC >> Health Monitors.
2. Click Create.
3. Specify kerb-hm1 in the Name field.
4. Select “Kerberos KDC” from the drop-down list in the Method type field.
5. Complete the necessary fields in the Kerberos KDC field
6. .Click Create Monitor.
page 674
Using the CLI

To configure a Kerberos health monitor, use the commands described in this section.
The following commands create a Kerberos health check method to check accessibility of the KDC for
obtaining a TGT (“acos-1” is the name of the ACOS device:
ACOS(config)# health monitor kerb-hm1

ACOS(config-health:monitor)# method kerberos-kdc kinit acos-1 examplepassword examplekd-
chost
The following command configures a Kerberos health check method to check accessibility of the Ker-
beros server for user account administration (“acos-1” is the name of the ACOS device):
ACOS(config-health:monitor)# method kerberos-kdc kadmin examplerealm acos-1 examplepass-

word examplekdchost exampleadminhost
The following example configures a Kerberos health method to check accessibility of the Kerberos
server for user password changes (“acos-1” is the name of the ACOS device):
ACOS(config-health:monitor)# method kerberos-kdc kpasswd acos-1 examplepassword examplekd-

chost examplepwdhost
page 675
Compound Health Monitors

Compound health monitors enable you to combine the status of multiple health checks into a single
result. ACOS uses the combined results of individual health checks to determine the health of the real
server, port, or service group to which the compound health monitor is applied.
• The compound server health status may report as Down due to incorrect timeout or interval
parameters. (See “Considerations” on page 677.)
• Compound health monitoring increases the workload of the health monitoring subsystem. For
example, using a compound monitor with many sub monitors against a service group with many
members can affect system performance. This increased workload could significantly delay the
response time for compound health checks.
Compound Health Monitor syntax

A compound health monitor consists of a set of health monitors joined in a Boolean expression (AND /
OR / NOT). The CLI Boolean expression syntax is Reverse Polish Notation (also called Postfix Notation),
a notation method that places an operator (AND, OR, NOT) after all of its operands (in this case, health
monitors).
After listing the health monitors, add the Boolean operator(s). The following operators are supported:
• AND – Both the ANDed health checks must be successful for the health status to be Up. If either
of the health checks is unsuccessful, the health status is Down.
• OR – Either of the ORed health checks must be successful for the result to be Up. Even if one of
the health checks is unsuccessful, the health status is still Up if the other health check is suc-
cessful. If both of the health checks are unsuccessful, the health status is Down.
• NOT – The health status is the opposite of the health check result. For example, if a health check
is unsuccessful, the resulting health status is Up. Likewise, if the health check is successful, the
resulting health status is Down. You can use NOT with a single health method, or with multiple
health methods for more complex expressions. (See below.)
For example, to construct a health monitor that ANDs two health monitors, use the following syntax:
method compound sub hm1 sub hm2 and
This is logically equivalent to the following expression: hm1 & hm2
• 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.
• The equivalent expressions are shown for clarity but are not valid syntax on the ACOS device.
Similarly, to construct a health monitor that ORs two health monitors, use the following syntax:
page 676
method compound sub hm1 sub hm2 or
This is logically equivalent to the following expression: hm1 | hm2
To construct a health monitor that results in an Up health status if the health check is unsuccessful, use
the following syntax:
method compound sub hm1 NOT
This is logically equivalent to the following expression: ! hm1
To construct more complex expressions, you can enter multiple sets of health monitors and operators.
Here is a quite complex expression:
(! (hm1 | (hm2 & (hm3 | (! hm4))))) | hm5
To configure this expression, use the following syntax:
method compound sub hm1 sub hm2 sub hm3 sub hm4 not or and or not sub hm5 or
Considerations
• A maximum of 8 sub monitors are supported in a compound monitor. To use more sub monitors,
you can nest compound monitors. (See below.)
• The total number of sub monitors plus the number of Boolean operators supported in a com-
pound monitor is 16.
• You can nest compound monitors. To nest compound monitors, configure a compound monitor,
then use that compound monitor as a sub monitor in another compound monitor. The maximum
nesting depth is 8.
Nesting loops are not allowed.
• The timeout and interval parameters of a compound monitor must be set to values that allow
each of the sub monitors to complete their health checks. If any of the sub monitors is unable to
complete its health check, the compound monitor’s result is always Down.
For example, if monitor1 gives a result after 2 seconds, but a compound monitor that uses moni-
tor1 times out in 1 second, the resulting health status will always be Down, regardless of the Bool-
ean expression. (See “Timeout Configuration” on page 679.)
If you encounter this problem, A10 Networks recommends you increase the timeout parameter for
the compound monitor to ensure the health check can cycle through all sub monitors. (See “Con-
figuring and Applying a Health Method” on page 638.) You alternatively can decrease the number
of retry attempts for sub monitor health checks to 1. (See “Consecutive Health Checks Within a
Health Check Period” on page 665.)
page 677
Using the GUI

1. Configure the sub monitors first.
2. Click Create on the health monitor list to begin configuration of a new monitor.
3. In the Method Type section, select Compound from the drop-down list. The Compound configura-
tion controls appear.
4. Construct the Boolean expression:
Use Reverse Polish Notation. (See “Compound Health Monitor syntax” on page 676.) Otherwise,
the GUI displays an error message when you click OK to complete the health monitor configura-
tion.
5. Click Create Monitor to complete the configuration of the compound monitor.
Using the CLI

To configure a compound health monitor, use the method compound command to add a Boolean expres-
sion at the configuration level for the monitor:
Use Reverse Polish Notation. (See “Compound Health Monitor syntax” on page 676.)
page 678
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:
ACOS(config)# health monitor hm-compoundAND

ACOS(config-health:monitor)# method compound sub hm1 sub hm2 and
The following commands apply the health monitor to a service group:

ACOS(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:
ACOS(config)# health monitor hm-compoundOR

ACOS(config-health:monitor)# method compound sub hm1 sub hm2 sub hm3 or or
The following commands apply the health monitor to a service group:

ACOS(config-slb svc group)# health-check hm-compoundOR
NOT Operator
The following commands configure a compound health monitor that results in an Up status only if the
server fails the ICMP health check:
ACOS(config)# health monitor icmp

ACOS(config-health:monitor)# retry 1
ACOS(config)# health monitor not-ping
ACOS(config-health:monitor)# interval 11 timeout 11
ACOS(config-health:monitor)# method compound sub icmp not
Timeout Configuration
For a compound health check configured as follows:
ACOS(config)# health monitor monitor1

ACOS(config)# health monitor monitor2
page 679
Configurable Response Codes for RADIUS Health Monitors
ACOS(config)# health monitor compound-monitor

ACOS(config-health-monitor)# method compound sub monitor1 sub monitor2 and
The amount of time allowed to perform health checks for monitor1 and monitor2 is calculated by the
retry and timeout values.
For this example, a compound health check requires a minimum of 10 seconds. If the timeout value for
the compound health check is set to 6, then the result is always Down. In order to ensure a complete
compound health check, set the compound health check timeout to 10 seconds or greater.
Configurable Response Codes for RADIUS Health

Monitors
By default, ACOS requires a RADIUS server to reply to RADIUS health checks with an Access-Accept
message (response code 2, by default).
In previous releases, code 2 was the only code the server is allowed to respond with, in order to be
marked UP, but beginning in ACOS 2.7.2, you can specify the response code(s) that ACOS can accept
as valid responses. So, for example, you can configure a health monitor to accept an Access-Reject
response (code 3) as a valid response from a healthy RADIUS server.
To specify the response code(s) a RADIUS server is allowed to send back in response to a RADIUS
health check, use the expect response-code option with the method command.
The following commands configure a RADIUS health monitor that accepts response code 2 or 3 as
passing (healthy) responses from a server:
ACOS(config)# health monitor rad1

ACOS(config-health:monitor)# method radius username admin1 password examplepassword secret
a10rad port 1812 expect response-code 2,3
Displaying Health Status

ACOS begins sending health checks to a real server’s IP address and service ports as soon as you fin-
ish 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 the following methods.
page 680
Use The GUI to View Health Status

• Use the GUI to View the Health of Virtual Servers and Service Ports
• Use the GUI to View the Health of Real Servers and Service Ports
Use the GUI to View the Health of Virtual Servers and Service Ports
To do this:

The virtual servers are listed at the top of the page. An icon appears next to each virtual server to
indicate the health status.
2. To display specific health information for a virtual server’s service ports, click on the virtual server
name.
Use the GUI to View the Health of Real Servers and Service Ports
To do this:

2. On the menu bar, select the Servers tab.
An icon appears next to each real server to indicate the health status.
3. To display more specific health status information for a real server’s service ports, click on the
server name.
For information about the real server health state icons, see the online help or GUI Reference.
Use the CLI to View Health Status

• Use the CLI to View the Health of Virtual Servers and Service Ports
• Use the CLI to View the Health of Real Servers and Service Ports
• Use the CLI to View Health Monitoring Statistics
page 681
Use the CLI to View the Health of Virtual Servers and Service Ports
Use the show slb virtual-server command to view the health of virtual servers and service ports. The
health status is shown in the State field; for additional information about this command and the fields
in the output, see the CLI Reference.
ACOS# show slb virtual-server "vs 1"

Virtual server: vs 1(A) State: Down IP: 1.1.1.201
Port Curr-conn Total-conn Rev-Pkt Fwd-Pkt Peak-conn
-------------------------------------------------------------------------------------
Virtual Port:80 / service:svcgrp 1 / state:Down

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

port 1 tcp
Persist Source IP:tmpl persist srcip 1

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

port 3 tcp
Template tcp tmpl tcp 1
...
Use the CLI to View the Health of Real Servers and Service Ports
Use the show slb server command to view the health of real servers and service ports. The health sta-
tus is shown in the State column; for additional information about this command and the fields in the
output, see the Command Line Interface Reference.
ACOS# show slb server

Total Number of Services configured: 5
Current = Current Connections, Total = Total Connections
Fwd-pkt = Forward packets, Rev-pkt = Reverse packets
Service Current Total Fwd-pkt Rev-pkt Peak-conn State
---------------------------------------------------------------------------------------
s1:80/tcp 0 0 0 0 0 Down
s1:53/udp 0 0 0 0 0 Down
s1:85/udp 0 0 0 0 0 Down
s1: Total 0 0 0 0 0 Down
...
page 682
Use the CLI to View Health Monitoring Statistics

Use the show health stat command to view health monitoring statistics. For additional information
about this command and the fields in the output, see the Command Line Interface Reference:
ACOS# show health stat

Health monitor statistics
Total run time: : 2 hours 1345 seconds
Number of burst: : 0
max scan jiffie: : 326
min scan jiffie: : 1
average scan jiffie: : 1
Opened socket: : 1140
Open socket failed: : 0
Close socket: : 1136
Send packet: : 0
Send packet failed: : 259379
Receive packet: : 0
Receive packet failed : 0
Retry times: : 4270
Timeout: : 0
Unexpected error: : 0
Conn Immediate Success: : 0
Socket closed before l7: : 0
Socket closed without fd notify: : 0
Get retry send: : 0
Get retry recv: : 0
Configured health-check rate (/500ms) : Auto configured
Current health-check rate (/500ms): : 1600
External health-check max rate(/200ms) : 2
Total number: : 8009
Status UP: : 8009
Status DOWN: : 0
Status UNKN: : 0
Status OTHER: : 0
IP address Port Health monitor Status Cause(Up/Down) Retry PIN

--------------------------------------------------------------------------------
10.0.0.11 80 http UP 11 /0 @0 0 0 /0 0
10.0.0.12 80 http UP 10 /0 @0 0 0 /0 0
page 683
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 supported:
• Perl
• Shell
• Tcl
• Python
Utility commands such as ping, ping6, wget, and dig are supported. ACOS supports the Perl IO::Socket
module and the Tcl UDP extension.
NOTE: External health methods are not supported in Direct Server Return (DSR)
deployments.
Securing External Health Monitors

Inherent in the External Health Monitor feature is the addition of programmatic code, in the form of
scripts, by the customer to the closed, system-level, run-time environment within ACOS. Running at ele-
vated processing privilege, this code will have intimate access throughout the ACOS system and broad
connectivity to the deployed networking environment.
Well behaved scripts contain trusted code solely for performing their functions to monitor the health of
real servers and applications in the customers network. It is the customer’s responsibility to
ensure the integrity and content of these scripts – that the code is trusted and the scripts are
free of code that can compromise the security of the ACOS system or systems in connected networks.
Malicious code in External Health Monitor scripts, whether intentional by disaffected ACOS admins or
unintentional by compromised ACOS admins or their systems, can expose the ACOS system and con-
nected environment to a range of exploits, such as, but not limited to, the following:
• Denial of Service (DoS), Distributed Denial of Service (DDoS)
• Remote Code Execution (RCE), Buffer Overflow, Brute Force
• Side-channel, exfiltration of Sensitive Information
• Man-in-the-Middle
• Spyware, Ransomware
• Trojan Horses, Network Worms
page 684
To secure External Health Monitors and keep them secure, ACOS administration can restrict access to
these services, monitor access activity, and review the content of these scripts.
Restricting Extended Health Monitor Activity

All ACOS admins, except for the ACOS root admin, are not permitted to import, create, edit/modify, or
delete External Health Monitor scripts as a default. Selected ACOS admins sufficiently trusted to
access these scripts can be allowed to perform these operations by provisioning the administrative
configuration with the health monitor (hm) privilege.
Only ACOS, system-level admins with Read-Write (R/W) privilege and specifically assigned this new
privilege will be permitted to perform these operations for External Health Monitor scripts. As these
monitoring scripts have access throughout the ACOS system, this privilege is not available to partition
constrained ACOS admins.
Best Practice: To minimize the threat surface of this feature, provision this privilege for the fewest
users necessary.
For more information on configuring administrative users, refer to the Management Access and Security
Guide or “Configuring External Health Monitors” on page 686.
Monitoring Extended Health Monitor Activity

External health monitor activity can be monitored via the ACOS Audit Log. This log can be configured to
log events to an external server through the logging auditlog host CLI command.
Script access operations can be detected on the logging server by filtering for the following strings and
reporting match events for administrative review.
• import health-external
• health external create
• health external edit
• health external delete
Reviewing Extended Health Monitor Configuration

External health monitor scripts can be reviewed and audited periodically or upon detecting audit log
activity to ensure their integrity and intended use in the ACOS system.
Instantiated scripts can be listed by the show health external ACOS CLI command and inspected indi-
vidually using the show health external file.ext ACOS CLI command, where file.ext is one of the
indicated script files listed.
page 685
Configuring External Health Monitors

Configuring An Administrator to Manage External Health Methods
HM privilege enables an administrator to access and manage External Health Monitor files. An account
with write privilege that does not include HM access cannot import, edit, create, or delete External
Health Monitor files.
To configure an admin account to manage external health methods (CLI Procedure):
1. Specify the admin username using the admin command: A password is required when configuring
a new admin account
ACOS(config)# admin adminuser1
2. To authorize external health monitor privileges, in addition to all read/write access, enter the priv-
ilege hm command.
ACOS(config-admin:adminuser1)# privilege hm
Modify Admin User successful!
3. Verify the modified admin1:

ACOS(config-admin:adminuser1)# show admin
UserName Status Privilege Access UserType Partition
--------------------------------------------------------------------
admin Enabled R/W/HM C/W/A Local
adminuser1 Enabled R/W/HM C/A Local
To configure an admin account to manage external health methods (CLI Procedure):
1. Navigate to the admin user update page.

System >> Admin >> Users >> Update
2. Enter the account name to be modified in the username field.

3. Verify that Privilege type is set to Global.
4. For Privilege, select Read/Write/HM
5. Save changes by clicking the Update button.
Configuring External Health Methods (GUI Procedure)
To use an external health method:
1. Configure a health monitor script.

page 686
3. Configure a health monitor that uses external as the method.

4. In the server configuration, set the health check to use the method.
NOTE: The filename of the imported script should be less than 32 characters in
length, including the extension.
To import an external health-check script onto the ACOS device (GUI Procedure):

2. On the menu bar, select External Programs.
3. Click Create.
4. Enter a name and description for the script.
5. Copy-and-paste the script into the Definition field.
6. Click Create.
To configure an external health monitor (GUI Procedure):

2. Click Create.
4. In the Method Type section, select External from the drop-down menu.
5. Click the Program drop-down menu and select the desired script.
6. In the Port field, enter the protocol port number.
7. Enter any arguments in the Arguments field.
To configure a server to use the external health method (GUI Procedure):

2. On the menu bar, select the Servers tab.
3. Click on the server name or click Create to create a new one.
4. If configuring a new server, enter the name and IP address, and other general parameters as appli-
cable.
5. In the Port section:
page 687
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 Create or Update.
Configuring External Health Methods (CLI Example)
External health-check scripts can be created, modified, and imported through CLI commands.
• Use the health external create to save a new heatlh check script, then open an editor to modify
that file.
• Use the health external edit command to open the editor to modify an existing script.
• Other CLI commands that manage health monitor scripts include health external copy, health
external delete, and health external rename.
See the Command Line Interface for ADC for more information.
Use the import health-external command at the global configuration level to import an external
health-check script onto your ACOS device. The following example imports a script called example-
health.py
ACOS(config)# import health-external example-health.py ftp://examplehost/scripts/hc
The following example shows how to configure the external health monitor:

ACOS(config-health:monitor)# method external program example-health.py
After the health monitor is configured, you can configure a server to use the external health method:

ACOS(config-real server)# health-check hm1
Health Monitor Script Examples

This section contains the following script examples:
• TCL Script Example
• Perl Script Example
• Shell Script Example
• Python Script Example
page 688
TCL Script Example

For Tcl scripts, the health check parameters are transmitted to the script through the predefined TCL
array ACOS_env. The array variable ax_env(ServerHost) is the server IP address and ax_env(ServerPort)
is the server port number. Set ax_env(Result) 0 as pass and set the others as fail. TCL script filenames
must use the “.tcl” extension.
To use the external method, you must import the program onto the ACOS 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:
ACOS(config)# health external import "checking HTTP server" ftp://192.168.0.1/ext.tcl

ACOS(config-health:monitor)# method external program ext.tcl port 80
Here is the ext.tcl file:
set sock -1
set ax_connected -1
set ax_result -1
set ax_server $ax_env(ServerHost)
set ax_port $ax_env(ServerPort)
proc recv_response { args } {

global sock ax_result ax_server ax_port
puts "recv_response"
set line [read $sock]
puts $line
if { [ regexp "HTTP/1.. (\[0-9\]+) " $line match status] } {
puts "server $ax_server:$ax_port response: $status"
# Check the status code
if { $status == 200 } {
# Set server to be "UP"
set ax_result 0
} else {
set ax_result 1
}
} else {
puts "not match"
set ax_result 1
}
# clear the read event
fileevent $sock readable {}
page 689
proc send_request { args } {

global sock ax_result ax_connected
puts "send_request"
puts $sock "GET / HTTP/1.0\r\n"
puts $sock "User-Agent: A10 HMON\r\n\r\n"
set ax_connected 1
# clear the write event
fileevent $sock writable {}
}
# setup timer, 1000ms

after 1000 {
set ax_connected 0
set ax_result 1
puts "timeout"
}
if {[catch {socket -async $ax_server $ax_port} sock]} {

puts "$ax_server: $sock"
} else {
fconfigure $sock -buffering none -blocking 0 -eofchar {}
fileevent $sock writable { send_request 0 }

puts "waiting"
vwait ax_connected
if {1 == $ax_connected} {
fileevent $sock readable { recv_response 0 }
vwait ax_result
}
set ax_env(Result) $ax_result
close $sock
}
Perl Script Example

For other external scripts (non-Tcl), environment variables are used to pass the server IP address
(HM_SRV_IPADDR) and the port number (HM_SRV_PORT). The script returns 0 as pass and returns
others as fail. For Perl scripts, use #! /usr/bin/perl at the beginning of the script.
Here is an example using the Perl scripting language:
#!/usr/bin/perl -w
# Sample script for checking Web server
page 690
my $host = $ENV{'HM_SRV_IPADDR'};
my $port = 80;
if (defined($ENV{'HM_SRV_PORT'})) {
$port = $ENV{'HM_SRV_PORT'};
}
# Use wget, exit code is zero if wget was successful.

my @args = qw(-O /dev/null -o /dev/null);
exec "wget", "http://$host:$port", @args;
# vim: tw=78:sw=3:tabstop=3:autoindent:expandtab
Shell Script Example

For Shell scripts, use #! /bin/bash at the beginning of the script.
Here is an example using the Shell scripting language:
#! /bin/bash
if test "$HM_SRV_IPADDR" == "" ; then
echo "Please check ENV Var 'HM_SRV_IPADDR'"
exit 1
fi
echo -n "Test $HM_SRV_IPADDR ...."

wget $HM_SRV_IPADDR --delete-after --timeout=2 --tries=1 > /dev/null 2>&1
ret=$?
if test $ret == 0 ; then
echo "OK"
exit 0
else
echo "Fail"
exit 1
fi
Python Script Example

See “Database Health Monitoring Using a Script” on page 691.
Database Health Monitoring Using a Script

ACOS supports Open Database Connectivity (ODBC). With this support, you can use a Python script to
perform Layer 7 health checking based on information in a database on the server.
page 691
The following types of databases are supported:
• Microsoft SQL (see “Example Script—Microsoft SQL” on page 692)
• MySQL (see “Example Script—MySQL” on page 693)
• PostgreSQL (see “Example Script—PostgreSQL” on page 694)
• Oracle (see “Example Script—Oracle” on page 695)
NOTE: ACOS also provides a database heath method. See “Database Health
Monitors” on page 672.
To configure database health monitoring:
1. Configure a Python script to check the database. (See the examples below.)
3. Configure an external health monitor that uses the script.
4. Bind the external health monitor to the target (real server, real port, or service group).
The steps performed on the ACOS device are the same as those for any other type of external health
monitor.
Example Script—Microsoft SQL

#!/usr/bin/python
import sys
import os
import pyodb
# MsSQL connection string format:

#Driver=FreeTDSDriver;Server=<ip>;Port=<port>;TDS_version=7.0;Database=<data-
base>;UID=<username>;PWD=<password>
# by a10hm convention get host and/or port from environment

host = os.environ['HM_SRV_IPADDR']
if os.environ.has_key('HM_SRV_PORT'):
port = int(os.environ['HM_SRV_PORT'])
if 0 >= port or 65536 <= port:
port = 0
else:
port = 0
if 0 != port:
conn_str = ("Driver=FreeTDSDriver;Server=%s;Port=%d;TDS_version=7.0;Database=Data-
page 692
base;UID=User;PWD=Password" % (host, port))

else:
conn_str = ("Driver=FreeTDSDriver;Server=%s;TDS_version=7.0;Database=Data-
base;UID=User;PWD=Password" % (host))
sql_stmt = "select * from Table"

try:
rv = 0
print "Connecting %s" % (conn_str)
conn = pyodb.Connect(conn = conn_str)
print "Doing SQL query '%s'" % (sql_stmt)
conn.execute(sql_stmt)
print "Fetching query results"
rows = conn.fetch()
print "Verifying results are OK"
if (0 == len(rows)):
rv = -1;
print "Cleaning up the database connection"
conn.disconnect()
del(conn)
except:
print "Something went wrong"
# by a10hm convention must exit with something other than 0
rv = -1
sys.exit(rv)
Example Script—MySQL
#!/usr/bin/python
import sys
import os
import pyodb
# MySQL connection string format:

#Driver=MySQLDriver;Server=<ip>;Port=<port>;Database=<database>;UID=<username>;PWD=<pass-
word>

port = 0
else:
page 693
port = 0
if 0 != port:
conn_str = ("Driver=MySQLDriver;Server=%s;Port=%d;Database=Database;UID=User;PWD=Pass-
word" % (host, port))
else:
conn_str = ("Driver=MySQLDriver;Server=%s;Database=Database;UID=User;PWD=Password" %
(host))

try:
rv = 0
rows = conn.fetch()
if (0 == len(rows)):
rv = -1;
conn.disconnect()
del(conn)
except:
rv = -1
sys.exit(rv)
Example Script—PostgreSQL
#!/usr/bin/python
import sys
import os
import pyodb
# PostgreSQL connection string format:

# Driver=PostgreSQLDriver;Server=<ip>;Port=<port>;Database=<database>;UID=<user-
name>;PWD=<password>

page 694

port = 0
else:
port = 0
if 0 != port:
conn_str = ("Driver=PostgreSQLDriver;Server=%s;Port=%d;Database=Data-
base;UID=User;PWD=Password" % (host, port))
else:
conn_str = ("Driver=PostgreSQLDriver;Server=%s;Database=Database;UID=User;PWD=Password"
% (host))

try:
rv = 0
rows = conn.fetch()
if ( 0 == len(rows)):
rv = -1;
conn.disconnect()
del(conn)
except:
rv = -1
sys.exit(rv)
Example Script—Oracle
#!/usr/bin/python
import sys
import os
import pyodb
# Oracle connection string format:

#Driver=OracleODBCDriver;DBQ=<Oracle-DBQ>;UID=<username>;PWD=<password>
page 695
port = 0
else:
port = 0
if 0 != port:
conn_str = ("Driver=OracleODBCDriver;DBQ=//%s:%d/XE;UID=User;PWD=Password" % (host,
port))
else:
conn_str = ("Driver=OracleODBCDriver;DBQ=//%s/XE;UID=User;PWD=Password" % (host))

try:
rv = 0
rows = conn.fetch()
if ( 0 == len(rows)):
rv = -1;
conn.disconnect()
del(conn)
except:
rv = -1
# by a10hm convention must exit with 0

sys.exit(rv)
page 696
Alternate Real Servers and Ports for Individual

Backup
You can assign one or more backup servers as alternates for a given primary server. If that specific pri-
mary server goes down, one of its alternate servers takes over. Likewise, you also can assign alternates
for backing up individual ports.
These features are described in the following sections:
• “Alternate Servers” on page 697
• “Alternate Ports” on page 701
Alternate Servers
You can assign up to 16 alternate servers to a primary server. Only 1 alternate server for a given pri-
mary server can be active at a time.
NOTE: This feature places an alternate server into service only if the primary
server goes down. Other features such as connection limiting or connec-
tion-rate limiting can not cause an alternate server to be used.
Sequence Numbering of Alternate Servers
Each alternate server must have a sequence number, 1-16. You specify the sequence number of an
alternate server when you assign it to its primary server.
For example, the following set of servers consists of one primary server and 3 alternate servers:
• rs1 – Primary server
• rs1-a1 – Alternate server with sequence number 1
The alternate servers are used according to their sequence numbers, beginning with the lowest
sequence number. For example, if all servers are up, then rs1 goes down, rs1-a1 takes over. If rs1-a1
also goes down, rs1-a2 takes over, and so on.
page 697
Alternate Servers
The sequence numbering of alternate servers is different from server priority. You do not need to
change the priority values of the primary server or its alternate servers.
Re-Activation of Down Servers
When a down server comes back up, the server is placed back into service. New sessions can be sent
to the server. The alternate server is gracefully removed from service. Existing sessions on the alter-
nate server are allowed to continue until they are terminated or they time out.
Configuration
To configure alternate servers for backup:
1. Add each of the alternate servers to the configuration.

2. Add the primary servers to the configuration. During configuration of each of the primary servers,
specify the alternate servers to use as the primary server’s backups.
3. Configure a service group. Add only the primary servers to the group. Do not add the alternate serv-
ers to the group.
4. Configure the virtual server. Bind the service group to a virtual port on the server.
The configuration options for the alternate servers are the same as those for primary servers. Likewise,
the configuration options for the service group and virtual server are the same as those for configura-
tions that do not use alternate servers.
The only server configuration that is unique to use of alternate servers is specification of those servers
in the configuration of the primary servers.
Configure Alternate Servers Using the GUI
To configure alternate servers for backup using the GUI:

2. Select the Servers tab.
3. Click on the Edit link in the Actions column on the right side of the page for a primary server.
4. On the Update Server page, expand the Advanced Fields section.
5. In the Alternate Server field:
a. Enter the sequence number in the Server ID field.
b. Select an alternate server from the Server Name drop-down list.
c. Click Add.
d. Repeat for each alternate server to be used by the primary server as a backup.
page 698
Alternate Servers
6. Click Update.
Configure Alternate Servers Using the CLI
To assign an alternate server as a dedicated backup for a primary server, use the alternate command
at the configuration level for the primary server:
The following commands configure some real servers to be used as alternate servers for backup:
ACOS(config)# slb server rs1-a1 10.10.10.51

page 699
Alternate Servers

The following commands configure 2 primary servers, and assign alternate servers to each of them:

ACOS(config-real server)# alternate 1 rs1-a1
The following commands configure a service group. Only the primary servers are added to the group.
The alternate servers are not added to the group.
ACOS(config)# slb service-group http1 tcp

The following commands configure a virtual server that uses the service group configured above:
ACOS(config)# slb virtual-server http-with-alternates 192.168.10.10

ACOS(config-slb vserver-vport)# service-group http1
The following command indicates whether alternate servers are in use:
ACOS# show slb virtual-server bind

Total Number of Virtual Services configured: 1
---------------------------------------------------------------------------------
page 700
Alternate Ports
*Virtual Server : http-with-alternates(A) 192.168.10.10 Functional Up
+port 80 http ====>http1 State :Functional Up

+rs1:80 10.10.10.10 State : Up
Alternate: rs1-a1, rs1-a2, rs1-a3
+rs2:80 10.10.10.20 State : Down
Alternate: rs2-a1*, rs2-a2, rs2-a3
The primary servers are listed under the virtual port. Under each primary server, that server’s alternate
servers are listed.
If an asterisk is shown at the end of an alternate server name, the primary server is down and the alter-
nate server is active instead. In the example above, rs2 is down, so alternate rs2-a1 is being used
instead.
Alternate Ports
For more granularity, you can specify alternates for individual ports. In this case, if a primary port that
has an alternate goes down, the ACOS device uses the alternate for that port, but continues to use the
primary server for other ports, if those other ports are still up. Figure 83 shows an example.
FIGURE 83 Alternate Server Ports
This deployment uses two primary servers, “linux-01” and “linux-02”. An alternate server is configured
for each of the primary servers. The server “windows-01” is an alternate server for “linux-01”. Likewise,
“windows-02” is an alternate server for “linux-02”.
page 701
Alternate Ports
Each primary server, and each of its alternate servers, has the following ports:
• TCP port 80 (or 8080)
• TCP port 443
• UDP port 53
As shown in this example, the port numbers on the primary and alternate servers are not required to be
the same. TCP port 8080 on the alternate servers provides the backup for port 80 on the primary serv-
ers.
Although port 80 has its own alternate port, the deployment in this example does not use alternate
ports for 443 or 53. If port 443 or 53 on a primary server goes down, the ACOS device starts using the
alternate server, for all the primary server’s ports (443 and 53).
However, if only port 80 goes down, the ACOS device begins using port 8080 on the alternate server,
but continues using the primary server for ports 443 and 53. This is because port 80 has its own alter-
nate port.
NOTE: For simplicity, this example shows only a single alternate server for each
primary server. In fact, a primary server can have up to 16 alternate serv-
ers. In either case, for a given primary server, only one alternate server
can be in use at a time. Likewise, a port can have up to 16 alternate ports
but only one of those ports can be in use at any given time. Priority
ranges from highest (1) to lowest (16).
NOTE: For more information about how the alternate-server feature works, see
“Alternate Servers” on page 697.
Configuration
To configure alternate ports:
1. Configure an alternate server.

2. Configure the primary server.
a. Add the alternate server to the primary server.
b. Add the protocol ports. On each port for which you want to provide an individual backup, add
the alternate server and port.
Use the same sequence number for the alternate server and the alternate port. This is required.
3. Configure the service group.
Within the service group configuration, there is no specific configuration required for the alternate
servers and ports. Add only the primary server and ports as members of the group. Do not add the
page 702
Alternate Ports
alternate servers or ports to the service group. No service group is required for the alternate serv-
ers and ports.
4. Configure the virtual server. Bind the primary server’s service group to the virtual port. Within the
virtual server configuration, there is no specific configuration required for the alternate servers and
ports.
Notes
• The sequence number of an alternate port must be identical to the alternate server sequence
number.
• A given alternate server can be used by only one primary server within the same service group.
Configure Alternate Ports Using the GUI
To configure alternate ports for backup using the GUI:

2. Select the Servers tab.
3. Click on the Edit link in the Actions column on the right side of the page for a primary server.
4. In the Port section on the Update Server page, click on the Edit link for a primary port.
5. On the Update Port page, expand the Advanced Fields section.
6. In the Alternate Port field:
a. Select the alternate server from the Server ID/Name drop-down list.
b. Select an alternate port from the Server Port drop-down list.
c. Click Add.
d. Repeat for each alternate port to be used by the primary port as a backup.
7. Click Update.
page 703
Alternate Ports
Configuring Alternate Ports Using the CLI
To configure alternate ports, use the alternate command at the configuration level for the real server.
The commands in this example configure the deployment shown in Figure 83 on page 701.
To begin, the following commands configure the alternate servers:
ACOS(config)# slb server windows-01 172.16.119.176

ACOS(config)# slb server windows-02 172.16.119.171
The following commands configure the primary servers:
ACOS(config)# slb server linux-01 172.16.119.216

ACOS(config-real server)# alternate 1 windows-01
page 704
Alternate Ports

ACOS(config-real server-node port)# alternate 1 windows-01 port 8080
ACOS(config)# slb server linux-02 172.16.119.217
ACOS(config-real server)# alternate 2 windows-02
ACOS(config-real server-node port)# alternate 2 windows-02 port 8080
The fact that these servers are not used as alternates for other servers makes these “primary servers”.
These commands configure the service groups. A separate service group is configured for each ser-
vice:
ACOS(config)# slb service-group linux-http tcp

ACOS(config-slb svc group)# member linux-01 80
ACOS(config)# slb service-group linux-ssl tcp
ACOS(config)# slb service-group linux-dns udp
page 705
Alternate Ports

ACOS(config-slb vserver-vport)# service-group linux-http
ACOS(config-slb vserver-vport)# service-group linux-ssl
ACOS(config-slb vserver-vport)# service-group linux-dns
The following command displays binding information for the virtual server. This information includes
the status of the primary and alternate servers and ports, for the service-group members bound to the
virtual port.
ACOS# show slb virtual-server bind

Total Number of Virtual Services configured: 3
------------------------------------------------------------------------------
*Virtual Server : vip1(A) 192.168.19.120 Functionally Up
+port 80 http ====>linux-http State : Functionally Up

+linux-01:80 172.16.119.216 State : Down
+linux-02:80 172.16.119.217 State : Up
+port 443 https ====>linux-ssl State :Up
+linux-01:443 172.16.119.216 State : Up
Alternate: windows-01
+linux-02:443 172.16.119.217 State : Up
+port 53 dns-udp ====>linux-dns State :Up
+linux-01:53 172.16.119.216 State : Up
+linux-02:53 172.16.119.217 State : Up
The output indicates that port 80 on “linux-80” is Down. Therefore, alternate port 8080 on server “win-
dows-01” is used instead.
page 706
Alternate Virtual Ports for Backup
ACOS supports use of backup virtual ports to provide backup for other virtual ports. With this feature
enabled, ACOS can switch over to a different virtual port under certain events. In this way, the feature is
similar to the Alternate Ports feature (see “Alternate Real Servers and Ports for Individual Backup” on
page 697.)
• Overview of Alternate Virtual Ports for Backup
• Configure Alternate Virtual Ports for Backup
Overview of Alternate Virtual Ports for Backup

• Supported Alternate Virtual Port Service Types
• Virtual Port Switchover Options
Supported Alternate Virtual Port Service Types

The alternate virtual port feature applies to the following service types:
• TCP
• HTTP
The feature offers the ability to take advantage of ACOS’ high performance Layer 4 load balancing while
offering the option to allow different service groups to handle different types of traffic, to add an alter-
nate service group for backup purposes, or to simply return an error message to clients. For example,
the alternate virtual port feature could be used to send clients an error message, such as “page not
found”, using an aFleX script, or it could be used to trigger a backup service group to handle this
request.
Virtual Port Switchover Options

The following events could cause the primary virtual port to switchover to an alternate virtual port:
page 707
Configure Alternate Virtual Ports for Backup
• when-down – This option applies to Layer 4 or Layer 7 virtual ports. You can configure an alter-
nate virtual port for use as a backup, and client requests will be re-directed if the primary virtual
port is down.
• serv-sel-fail – This option applies to only Layer 4 primary virtual ports. The server selection swi-
tchover could occur for any number of reasons that could cause server selection to fail, such as if
the service group configured on the primary virtual port reaches a configured connection limit.
• req-fail – This option only applies if the primary virtual port is HTTP. If a non-HTTP TCP request is
sent to an HTTP virtual port, then the client request will switchover to an alternate virtual port
with service type TCP. For example, in some cases it may be desirable to have the ACOS device
load balancing non-HTTP traffic using a Layer 4 service group.
This req-fail option only works for the first request in the connection.

To configure the alternate virtual ports for backup feature:
1. Set up the real servers and service groups.

2. When setting up the virtual server (VIP), configure a primary virtual port with TCP or HTTP.
3. Add an alternate virtual port. The alternate virtual port and primary virtual port must be of different
service types. For example:
• An HTTP alternate virtual port must be configured with a TCP primary virtual port
or
• An TCP alternate virtual port must be configured with an HTTP primary virtual port.
Configure Alternate Virtual Ports Using the GUI

This example configures virtual server vs1 with TCP port 80 as the primary virtual port, and HTTP port
81 as the alternate virtual port.

2. Select the Virtual Services tab.
3. On the Create Virtual Service page:
a. Enter vs1 in the Virtual Server Name field.
b. Enter 10.10.10.1 in the Address field.
c. Select TCP from the drop-down list in the Protocol field.
page 708
d. Enter 80 in the Port field.

4. Expand the General Fields section of the page.
5. Select the checkbox in the Use Alternate Port field.
a. Enter 81 in the Alternate Port field.
b. Select HTTP in the Alternate Protocol field.
c. Select the desired condition in the Alternate Condition field.
d. Click Create.
Configure Alternate Virtual Ports Using the CLI

This example assumes the real servers have already been configured, and that two service groups
have been configured: one for the primary virtual port and another for the alternate virtual port.
The VIP is configured with an HTTP primary virtual port and a TCP alternate virtual port, and the event
trigger used in this example is ‘req-fail’.
ACOS(config)# slb virtual-server altvip1 5.5.5.7
page 709
ACOS(config-slb vserver)# port 80 tcp alternate

ACOS(config-slb vserver-vport)# service-group sg-80-tcp-alt
ACOS(config-slb vserver-vport)# alternate port 80 tcp req-fail
ACOS(config-slb vserver-vport)# service-group sg-80-tcp-prim
Upon sending non-HTTP TCP traffic to the HTTP virtual port, the traffic should trigger a failed client
request (based on the inconsistent client request and service type of the virtual port). This triggers a
failover (or switchover) to the TCP alternate port, and this virtual port belonging to service group “sg-80-
tcp-alt” should be able to accommodate the TCP traffic.
page 710
Priority Affinity
Priority affinity is a service-group option that allows the ACOS device to continue using backup servers
(servers with lower priority) even when the primary (high priority) servers come back up.
• Priority Affinity Overview
• Priority Affinity Options
• Configure Priority Affinity
Priority Affinity Overview

• Default Behavior (Priority Affinity Disabled)
• Default Behavior (Priority Affinity Enabled)
• Priority Affinity Example
Default Behavior (Priority Affinity Disabled)

By default, the priority affinity feature is disabled when a service group is created. With priority affinity
disabled, the ACOS device’s default behavior is such that:
1. ACOS sends traffic to the service-group members with the highest priority.
2. If these high-priority servers go down, then the ACOS device selects the service-group members
with the next-highest priority.
3. However, if one or more of the high-priority servers return to service, ACOS stops sending traffic to
the low-priority servers and reselects the high-priority servers.
page 711
Default Behavior (Priority Affinity Enabled)

If the priority affinity feature is enabled for the service group, the behavior of the ACOS device continues
sending clients to lower-priority servers, even after the higher-priority servers have come back online.
Previous releases provided an option (min-active-member) that enables the ACOS to continue using
backup servers. This approach can ensure availability of a configured minimum number of active serv-
ers but, unlike priority affinity, the min-active-member option lacks a way to ensure traffic is only sent to
backup servers.
If the ACOS device stops using the primary servers due to other features (for example, exceeding con-
nection limits), then the priority affinity feature will take effect just as if the switchover were triggered
by a change in the status of the primary servers. If the higher-priority servers subsequently become
available due to the number of connections dropping below the configured threshold, then the ACOS
device will not use them, but will instead continue using the lower-priority backup servers.
Priority Affinity Example

The following example helps illustrate how priority affinity works.
Assume a service group contains five members, as shown below:
• Server s1, port 80, priority 10
All five members of this service group (servers s1-s5) are up and available. However, the ACOS device
uses only members s1 and s2, because they have a priority of 10. Members s3 and s4 are used only if
both s1 and s2 go down. Member s5 is a last-resort member that is used only if all other members are
down.
If server s1 goes down, as shown in Figure 84, the ACOS device continues sending traffic to the other
highest-priority server, s2.
page 712
FIGURE 84 Priority Affinity – First Server Fails
Next, assume server s2 also goes down, as shown in Figure 85 below. Because s1 and s2 are both
down, the ACOS device begins using the backup servers (s3 and s4).
FIGURE 85 Priority Affinity – Second Server Fails
page 713
Priority Affinity Options
By default, without priority affinity, if s1 or s2 returns to an available state, the ACOS device stops using
s3 and s4 and shifts back to s1 and s2. However, with priority affinity enabled, the ACOS device contin-
ues to use s3 and s4 and does not start using s1 or s2 again, despite their availability.
If the ACOS continues to use the lower-priority servers and you wish to force the ACOS to use the
higher-priority servers again, you must administratively reset the priority affinity.

Within the priority affinity feature, there are sub-options that enable you to define specific actions that
will occur if the higher-priority service-group members fail.
This ability to specify a particular action to occur during a failover may be helpful because it allows you
to prevent your lower-priority secondary servers, (which are presumably less robust than your higher-
priority servers), from being overwhelmed by a flood of traffic that could occur during failover.
Actions (drop, reset, and others) can be tied to a general failure (such as disabled service-group mem-
bers or a failed health check) or to traffic exceeding configured connection-limits or connection-rate-
limits.
Priority Affinity Actions

You can configure the ACOS device to respond to service-group member failures by taking one of the
following actions:
• Reset: Sends a reset to the client if all nodes with this same priority fail for any reason
• Reset-if-exceed-limit: Sends a reset to the client if all nodes with this same priority fail, and if fail-
ure is due to one or more nodes exceeding the configured connection-limit or connection-rate-
limit
• Drop: Drops the request if all nodes with this same priority fail for any reason
• Drop-if-exceed-limit: Drops the request if all nodes with this same priority fail, and if one or more
nodes exceed the configured connection-limit or connection-rate-limit
• Proceed: the ACOS device uses the node(s) with the next-highest priority if all nodes with the cur-
rently-selected priority fail (this is the default behavior)
Actions are tied to a certain priority levels and are not tied to individual servers. Therefore, an action is
only triggered when all service-group members of a given priority become unavailable.
page 714
Priority Affinity Triggers

The reset or drop actions can be triggered for the following reasons:
• If a health check fails
• If a user disables a server or port
• If another Load Balancing feature causes the currently-used priority to become unavailable (for
example, min-active-member)
• If a connection-limit or connection-rate-limit is exceeded
Actions Tied to Exceeded Limits

The following examples show scenarios in which the ACOS device performs a certain action based on
general failures or exceeded connection limits or exceeded connection rate limits:
• Simple Scenario – Service Group with Two Priorities
• More Complex Scenario – Multiple Members with Same Priority
• Different Actions for Different Priority Levels
page 715
Simple Scenario – Service Group with Two Priorities

Consider the service-group below, which has two priorities (10 and 5). The reset-if-exceed-limit or
drop-if-exceed-limit command can be applied to the higher priority level in order to reset the connec-
tion if the connection limit is exceeded.

ACOS(config-slb svc group)# priority 10 reset-if-exceed-limit
ACOS(config-slb svc group)# member A 80
ACOS(config-slb svc group)# member B 80
With this configuration, if member A (priority 10) exceeds the configured connection-limit, the ACOS
device responds by sending a reset to the client.
This reset only happens if the connection limit is exceeded. If member A goes down for a different rea-
son, such as failing a health check, then the ACOS device will not perform the specified action. Instead,
the ACOS device will act according to its default behavior, meaning it will reselect the server within the
service-group that has the next-highest priority. In this example, this means member B (priority of 5),
would be used.
More Complex Scenario – Multiple Members with Same Priority

This example is more complex. Assume the service-group has several members with the same priority
level.

ACOS(config-slb svc group)# member C 80
ACOS(config-slb svc group)# member D 80
page 716
In this case, members A, B, and C all have a priority of 10. The specified action (reset-if-exceed-limit)
only occurs if all three high-priority members fail and one or more of the failures is caused by exceeded
connection limit. If members A, B , and C go down for any other reason, such as a failed health check,
then the ACOS device would follow its default behavior and send traffic to the lower-priority service-
group member D.
Different Actions for Different Priority Levels

You can define different actions for different priority levels. Members A, B, C, and D in the next example
each have different priority levels. Different actions are associated with each of the different priority lev-
els.

ACOS(config-slb svc group)# priority 8 drop-if-exceed-limit
ACOS(config-slb svc group)# member C 80
ACOS(config-slb svc group)# member D 80
Details:
• The Priority Options feature operates at Layer 4 feature and thus will not work if applied to virtual-
ports, such as HTTP and SMTP, which are Layer 7. A10 suggests you use L4 virtual-ports.
• The Priority Options feature is only supported for the default service-group binding under the vir-
tual-port. If the service-group has been configured under aFleX, or a black/white list, or a class
list, then the specified action (e.g. drop, reset, proceed) will not take effect.
• Rate limiting and priority are not supported with stateless load balancing. Therefore, the Priority
Options feature is also not supported in stateless load balancing implementations.
page 717
Configure Priority Affinity

• Configure Priority Affinity Using the GUI
• Configure Priority Affinity Using the CLI
Configure Priority Affinity Using the GUI

To enable priority affinity in a service group:

2. Select the Service Group tab.
3. Click the Edit link in the Actions column for the service group you want to modify.
5. Click the checkbox in the Priority Affinity field.
6. Click Update.
Configure Priority Affinity Using the CLI

This section contains the following CLI examples:
• CLI Example – Basic Priority Affinity
• CLI Example – Associating Actions with Priority Levels
CLI Example – Basic Priority Affinity
The following commands add members to a service group. Members s1 and s2 have the highest prior-
ity value within the group, so they will be used as the primary members. Members s3 and s4 will be
used only if both s1 and s2 become unavailable. Member s5 will be used only if all the other members
are unavailable.

page 718

ACOS(config-slb svc group)# priority-affinity
The priority-affinity command enables priority affinity; if the primary members both become
unavailable, the secondary members (s3 and s4) will continue to be used even if s1 or s2 becomes
available again.
In this example, primary members (the ones with highest priority within the service group) are active, so
the priority affinity value is the priority of those members. However, if the primary members are down
and the secondary members are active, the priority affinity value changes to the priority of the second-
ary members.
ACOS(config-slb svc group)# show slb service-group sg1

Service group name: sg1 State: All Up
Priority affinity: 5
...
If the output indicates that the priority affinity value is 0, this indicates that none of the service group’s
members have ever had any active SLB sessions. Typically, 0 appears when the service group is new
and has not yet received any SLB traffic.
CLI Example – Associating Actions with Priority Levels
These commands create the TCP service-group “http” and defines the reset-if-exceed-limit action
for members with priority 10. They also define the drop-if-exceed-limit action for members with pri-
ority 8.
ACOS(config)# slb service-group http tcp

ACOS(config-slb svc group)# priority 8 drop-if-exceed-limit
ACOS(config-slb svc group)# member no30 80
page 719

Use the show slb service-group command to display information about the service-group “http” cre-
ated above. Output shows there were 23 packets dropped and 41 connections reset:
ACOS(config)# show slb service-group http

Service group name: http State: Functional Up
Service: no30:80 DOWN
Total connections: 0 Response time: 0 tick
Peak conn: 0
page 720
Source-IP Persistence Override and Reselect
This chapter describes the source-IP persistence override and reselect feature.
• Overview of Source IP Persistence Override
• Configure Source IP Persistence Override
Overview of Source IP Persistence Override

When the Source-IP Persistence Override and Reselect feature is enabled, the ACOS device checks for
higher-priority servers even if persistent sessions are already established between client and server.
• Default Behavior
• Behavior With Source-IP Persistence Override and Reselect
• Simplified Example
• Use Case Scenario
Default Behavior
Without this feature, if source-IP persistence is enabled and if a persistent session has already been
established between a client and a server, then the ACOS device will send traffic to that same node until
the node goes down or the timeout period expires.
This “sticky” behavior (or persistence) is helpful in situations where it is important to maintain a consis-
tent connection between a client and a server, such as with online shopping, where it may be desirable
to track the client’s interaction with the website.
ACOS typically uses the priority metric to select the highest priority server from a service group, and it
establishes a persistent session between the client and the selected server. Once the session is estab-
lished, the server selection process is complete, and the priority of one server over another becomes
irrelevant. Even if a higher-priority server becomes available, the ACOS device will “ignore” it and con-
tinue to honor the persistent session that has already been established.
page 721
Overview of Source IP Persistence Override
Behavior With Source-IP Persistence Override and Reselect

If the Source-IP Persistence Override and Reselect feature is enabled, then the ACOS device no longer
honors the source-IP persistence, and it continually checks for higher-priority servers, even after per-
sistent sessions have been established between client and server.
Simplified Example
For example, assume a service group has two servers and traffic is load balanced across the two serv-
ers with persistence:
• Server A with priority = 10
• Server B with priority = 5
If Server A goes down, then the traffic is balanced to Server B, which has a lower priority. A persistent
connection is established with Server B.
However, because the Source-IP Persistence Override and Reselect feature is enabled, when Server A
comes back up, the persistence with Server B is broken and a new persistent session is re-established
with Server A.
Use Case Scenario

The behavior described above might be desirable if you want to send clients to higher-priority servers
as they become available. For example, this feature might be helpful if you have a large service group
containing your newest and most robust servers, as well as a smaller service group containing a few
older and weaker backup servers that have a lower-priority.
If you are doing off-hours maintenance on the high-priority servers, you must take them offline. Traffic
will be sent to the low-priority servers in the other service-group.
However, once the maintenance is complete and you bring the high-priority servers back online, you
might want to interrupt the persistent sessions that clients have established with your inferior backup
servers. These persistent sessions will be broken in order to re-establish persistent sessions with your
more robust, high-priority servers.
page 722
Configure Source IP Persistence Override

• Configure Source-IP Persistence Override Using the GUI
• Configure Source-IP Persistence Override Using the CLI
Configure Source-IP Persistence Override Using the GUI

To configure source-IP persistence override using the GUI:

2. Click the Persistence tab.
3. Click Create, then select Persist Source IP from the pop-up menu.
5. Select the checkbox in the Enforce Higher Priority field.
6. Click OK.
Configure Source-IP Persistence Override Using the CLI

To enable source-IP persistence override and reselect, configure an SLB template for source-IP per-
sistence and then use the enforce-higher-priority command. This example shows commands
required to configure this feature and does not represent a complete SLB configuration.
The following command creates a source-IP persistence template named “SIP” and enables source-IP
persistence override and reselect:
ACOS(config)# slb template persist source-ip sip

ACOS(config-source ip persist)# enforce-higher-priority
ACOS(config-source ip persist)# exit
The following commands create a virtual-server named “VIP1” at IP address 1.2.3.4 on TCP port 80.
The service-group “HTTP” and source-IP persistence template “SIP” are then bound to this virtual
server.

ACOS(config-slb vserver-vport)# service-group http
ACOS(config-slb vserver-vport)# template persist source-ip sip
page 723
Use the show slb persist command to display information about the status of the source-IP per-
sistence override and reselect. The very last line in the output below shows that the ACOS “broke” 30
persistent sessions between a client and a low-priority node. This means server reselection occurred
and new persistent sessions were established with higher-priority nodes.
ACOS(config)# show slb persist

Total
------------------------------------------------------------------
URL hash persist (pri) 0
URL hash persist (sec) 0
...
Cookie persist ok 0
Cookie persist fail 0
Persist cookie not found 0
Persist cookie Pass-thru 0
Enforce higher priority 30
page 724
Policy Template Binding at the Service-Group Level
You can configure ACOS to allow some types of client requests to be directed to one service group,
using restrictive traffic control policies, while sending all other requests to a separate service group.
In this hypothetical use case scenario, the enhancement could be used to throttle client requests des-
tined for a specific URL while allowing the other requests to flow through the ACOS device unimpeded.
This could be done with the following high-level configurations:
• Create two overlapping service groups (SG1 and SG2) containing the same real servers.
• SG1 could have a policy that limits the number of user requests to no more than 100 requests
per second.
• SG2 could have no rate limiting policy.
• Create a policy template that uses URL switching. This template could direct requests starting
with “/auth” (authentication requests) to the first service group (SG1), while all other requests
would be sent to the default service group (SG2).
• Bind the policy template to the VIP.
The outcome of these configurations is that it would effectively throttle just the client requests starting
with “/auth”, but all other traffic would be able to reach the default service group, which would not
impose any rate limits on that traffic.
Using the GUI
This section describes how to bind a policy template at the service group level using the GUI.
First, create a new policy template:

2. Select the L7 Protocols tab.
3. Click Create, then select Policy from the pop-up menu.
4. Enter a name for the policy template.
5. Expand the Class List section.
a. Select a previously created class list from the Class List field.
b. Enter the desired rate limiting parameters for this class list, and then click Add.
When binding a policy template at the service-group level, only class lists are supported; black/
white lists are not supported.
page 725
6. When finished adding class lists, click OK.
After the policy template is created, bind the policy template to the desired service group.

2. Select the Service Groups tab.
3. Click the Edit link in the Action column for the service group you want to modify.
4. On the Update Service Group page, expand the Advanced Fields section.
5. In the Template Policy field, select the policy to bind to this service group from the drop-down list.
6. Click Update.
page 726
Using the CLI
The following commands configure a class list called “test1” with multiple LIDs defined:
ACOS(config)# class-list test1

ACOS(config-class list)# 192.168.0.200/32 lid 1
These commands configure a policy template containing a class list “test1” and performs request and
connection limiting:
ACOS(config)# slb template policy req-limit

ACOS(config-policy)# class-list test1
ACOS(config-policy-class-list:test1)# lid 1
ACOS(config-policy-class-list:test1-...)# conn-limit 2
ACOS(config-policy-class-list:test1-...)# request-limit 3
ACOS(config-policy-class-list:test1-...)# over-limit-action log
ACOS(config-policy-class-list:test1-...)# exit
page 727
ACOS(config-policy-class-list:test1)# exit
To bind a policy template to a service group, use the template policy CLI command at the service
group level. The following commands bind the req-limit policy template to the service group called
“sg801”:

ACOS(config-slb svc group)# template policy req-limit
ACOS(config-slb svc group)# member rs801_1 80
ACOS(config-slb svc group)# member rs801_2 80
ACOS(config-slb svc group-member:80)# end
page 728
Scan-All-Members Option in Persistence Templates
In cookie, source-IP, and destination-IP persistence templates, the match-type server option has a sub-
option called scan-all-members. This option allows a persistent session to continue when the real
server port that the session is on becomes unavailable. This chapter describes the scan-all-members
option in detail.
The match-type server option changes the granularity of persistence, from server+port, to simply
server. If the match-type is set to server+port (the default), a persistent session is always sent to the
same real port on the same real server. However, if the match-type is set to server, a persistent session
is always sent to the same real server, but not necessarily to the same real port.
The match-type server option is used 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 86 shows
an example.
FIGURE 86 Scan-all-members
VIP 192.168.10.11 uses 3 real servers to provide HTTP service. Two of the servers have a single proto-
col port for HTTP. However, one of the servers has HTTP service on multiple service ports.
page 729
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, subse-
quent 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 ACOS 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 ACOS 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.
In this example, if the load-balancing method happens to choose port 80 on server s3 for the first
request, subsequent connections also are sent to port 80 on s3, since port 80 is in the first member
(server+port) for s3 listed in the service-group configuration. Because the match-type is set to match-
type server, if port 80 goes down, the next request for the persistent session is still sent to s3, but to a
different port on s3.
If the load-balancing method selects 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.
However, if the member (port 80 on s3) is set to a lower priority or is administratively disabled, the
ACOS device again will use the load-balancing method to select a server and port for the next request.
Any of the available service-group members can be selected, even if they are different servers.
It is possible that a different server will be selected for the next request. For example, if an admin needs
to perform some maintenance on port 80, and disables that port in order to prevent it from being used
for 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 administratively disabled or is set to a lower priority, use the scan-all-members option. In
this case, the ACOS 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 ACOS device selects the next mem-
ber 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.
Configure Scan-All-Members Using the GUI

This procedure configures the source-IP persistence template and service group in Figure 86 on
page 729.
Configure the Source-IP Persistence template:
page 730
2. Click the Persistence tab.

3. Click Create, and select Persist Source IP from the drop-down list.
4. Enter persist-source in the Name field.
5. In the Match Type field, select Server from the drop-down list.
6. Select the checkbox in the Scan All Members field.
7. Click OK.
Configure the service group:

2. Click the Service Groups tab.
3. Click Create.
4. Enter sg-1 in the Name field.
5. In the Member pane, click Create.
a. Add the server s1, port 80 to the service group.
b. Repeat to add servers s2 (port 80), s3 (port 80), s3 (port 8080), and s3 (port 8081)
6. Click Create to create the service group.
Configure the virtual server:
page 731
2. The Virtual Servers tab should be selected by default; if not, click the Virtual Servers tab.
3. Click Create.
6. In the Virtual Port field, click Create.
a. In the Protocol field, select TCP.
b. In the Port field, enter 80.
c. In the Service Group field, select sg-1 from the drop-down list.
d. Expand the Templates pane further down on the screen.
e. In the Template Persist Source IP field, select persist-source from the drop-down list.
f. Click Create.
7. Click Create.
Configure Scan-All-Members Using the CLI

These commands configure the source-IP persistence template and service group in Figure 86 on
page 729.
The following commands configure the source-IP persistence template:
ACOS(config)# slb template persist source-ip persist-source

ACOS(config-source ip persistence template)# match-type server scan-all-members
ACOS(config-source ip persistence template)# exit
The following commands configure the service group:
ACOS(config)# slb service-group sg-1 tcp

page 732

ACOS(config-slb vserver-vport)# service-group sg-1
ACOS(config-slb vserver-vport)# template persist source-ip persist-source
page 733
page 734
Quality of Service Marking for TCP Traffic
ACOS provides an option to mark QoS for SLB traffic. The option marks the DSCP (Layer 3) and 802.1p
priority (Layer 2) values in client-server SLB traffic. When this feature is configured, ACOS marks traffic
in both directions, ACOS-to-client traffic and ACOS-to-server traffic.
The QoS option is disabled by default. You can configure the option in TCP, TCP-proxy, and UDP tem-
plates.
When you configure the QoS option, you set a value in the range 1-63. Based on the value you specify,
ACOS marks the traffic as follows:
• Layer 3 marking – ACOS sets DiffServ Control Point (DSCP) value in the IP header to a specified
value.
• Layer 2 marking – ACOS sets 802.1p value in the MAC header to a specified value divided by 9:
dscp-value / 9 = 802.1p-value
Table 18 lists the 802.1p values ACOS uses based on the configured DSCP value.
TABLE 18SLB QoS Marking Based on DSCP Value

Configured DSCP Value Marked 802.1p Value
1-7 0
8-15 1
16-23 2
24-31 3
32-39 4
40-47 5
48-55 6
56-63 7
To configure the QoS option, use either of the following methods.
Configure QoS Using the GUI
On the configuration page for the TCP, TCP-proxy, or UDP template, enter the value in the QoS field.
Below is an example on the TCP template configuration page (ADC >> Templates >> L4):
page 735
Configure QoS Using the CLI
At the configuration level for the TCP, TCP-proxy, or UDP template, use the qos command. The follow-
ing example shows an example in a TCP template:
ACOS(config)# slb template tcp tcp-template

ACOS(config-l4 tcp)# qos 55
page 736
Preventing Reset of SLB and Ethernet Statistics
ACOS provides an option to prevent resetting (clearing) of statistics for the following resources: SLB
servers, service groups, virtual servers, and Ethernet interfaces. By default, statistics counters for these
types of resources can be reset by ACOS admins.
This option applies to statistics counters in the output of the following:
• GUI pages:
• ADC >> Statistics >> L4

• ADC >> Statistics >> L7 and corresponding sub-pages
• ADC >> Statistics >> Application and corresponding sub-pages
• ADC >> Statistics >> System and corresponding sub-pages
• CLI commands:
• show slb virtual-server
• show slb service-group
• show slb server
• show interfaces
By default, clearing statistics is allowed. You can disable reset of SLB and Ethernet statistics, on a
global basis.
Using the GUI
This functionality is not supported in the GUI for release 4.x.
Using the CLI
To disable reset of SLB and Ethernet statistics, use the disable reset statistics command at the
global configuration level.
To enable statistics reset, use the enable reset statistics command at the global configuration level.
The following commands attempt to clear SLB and Ethernet statistics but are not allowed:
ACOS(config)# disable reset statistics

ACOS(config)# clear slb server all
Reset statistics disabled
ACOS(config)# clear statistics
Reset statistics disabled
page 737
page 738
Web Category
“Web Category” is now a topic in the SSL Insight Configuration Guide.
page 739
page 740
page 741
CONTACT US
7 a10networks.com/contact
ACOS 4.1.1-P11 APPLICATION DELIVERY AND SERVER LOAD BALANCING GUIDE 29 MAY 2019

ACOS 4.1.1-P11 Application Delivery and Server Load Balancing Guide

Uploaded by

Copyright:

Available Formats

ACOS 4.1.1-P11 Application Delivery and Server Load Balancing Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ACOS 4.1.1-P11 Application Delivery and Server Load Balancing Guide

Uploaded by

Copyright:

Available Formats

ACOS 4.1.

A10 NETWORKS INC. SOFTWARE LICENSE AND END USER AGREEMENT

Server Load Balancing Concepts and Terminology .................................................................... 21

Transparent Mode Deployment .................................................................................................. 29

Gateway Mode Deployment ........................................................................................................ 47

Direct Server Return (DSR) SLB Deployment .............................................................................. 69

Direct Server Return in Transparent Mode .........................................................................69

ADDITIONAL DEPLOYMENT .....................................................................................................87

Network Address Translation for SLB ........................................................................................ 89

Dynamic Real Server Creation Using DNS ................................................................................ 103

Virtual IP Creation Based on Subnet ........................................................................................ 111

Virtual Port Ranges .................................................................................................................. 113

Mapping Virtual IP Addresses and Real Ports .......................................................................... 117

PROTOCOL LOAD BALANCING ...............................................................................................123

IPv4 Load Balancing ................................................................................................................. 125

IPv6 Load Balancing ................................................................................................................. 131

Layer 4 TCP/UDP Load Balancing ............................................................................................ 135

SLB Protocol Translation ......................................................................................................... 145

APPLICATION LOAD BALANCING ............................................................................................153

FTP Load Balancing ................................................................................................................. 155

HTTP Load Balancing ............................................................................................................... 173

Configuring HTTP Load Balancing ................................................................................... 177

HTTP Options for SLB .............................................................................................................. 187

Configuring Client IP Insertion / Replacement ..................................................................................217

HTTP Load Balancing to Proxy Servers .................................................................................... 229

Sending a TCP Reset After Server Selection Failure ................................................................. 231

SPDY Load Balancing ............................................................................................................... 235

SIP Load Balancing .................................................................................................................. 245

Configuring SIP over TCP / TLS for SIP Multiplexing .......................................................................258

Database Load Balancing ......................................................................................................... 271

Financial Information eXchange Load Balancing ..................................................................... 281

Short Message Peer-to-Peer Load Balancing ........................................................................... 289

Configure SMPP Load Balancing (GUI Procedure) ...........................................................................291

APPLICATION OFFLOAD AND OPTIMIZATION ...........................................................................303

SSL Certificate Management and Options ................................................................................ 305

Simple Control Enrollment Protocol (SCEP) .................................................................... 339

SSL Offload and SSL Proxy ...................................................................................................... 345

Secure FTP Proxy ..................................................................................................................... 357

DNS Optimization ..................................................................................................................... 389

Enable DNS Caching on a VIP ........................................................................................................ 397

RAM Caching ........................................................................................................................... 411

Transparent Cache Switching .................................................................................................. 421

Configuring IPv6 TCS in VRRP-A Layer 3 Inline Mode..................................................... 443

Destination Hash-Based TCS ................................................................................................... 457

STARTTLS for Secure SMTP .................................................................................................... 459

Diameter AAA Load Balancing ................................................................................................. 469

RADIUS Message Load Balancing ............................................................................................ 479

SNMP-Based Load Balancing ................................................................................................... 487

Advanced Traffic Replication ................................................................................................... 493

Outbound Next Hop Load Distributor ....................................................................................... 499

HTTP Proxy .............................................................................................................................. 505

Explicit FTP Proxy .................................................................................................................... 551

Redirection of Traffic to ICAP Servers ...................................................................................... 563

Redirection of Traffic to Thales HSM Devices .......................................................................... 565

Web Logging for HTTP and RAM Caching ................................................................................ 573

Real-Time Logging for Failed Server Selection ......................................................................... 583

ACOS PERFORMANCE OPTIMIZATION ....................................................................................589

Stateless Server Load Balancing .............................................................................................. 591

Stateful Hash-Based Server Load Balancing ............................................................................ 595