AppDirector User Guide Version 2.14

AppDirector User Guide
Software Version 2.14.03

Document ID: RDWR-AD-V021403-UG0211
February, 2011
Important Notice
This guide is delivered subject to the following conditions and restrictions:
Copyright Radware Ltd. 2008 2009. All rights reserved.
The copyright and all other intellectual property rights and trade secrets included in this guide are
owned by Radware Ltd.
The guide is provided to Radware customers for the sole purpose of obtaining information with
respect to the installation and use of the AppDirector, and may not be used for any other purpose.
The information contained in this guide is proprietary to Radware and must be kept in strict
confidence.
It is strictly forbidden to copy, duplicate, reproduce or disclose this guide or any part thereof without
the prior written consent of Radware.
The OnDemand Switch may use software components licensed under the GNU General Public
License Agreement Version 2 (GPL v.2) including LinuxBios and Filo open source projects. The
source code of the LinuxBios and Filo is available from Radware upon request. A copy of the license
can be viewed at:
http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
Copyright Notices
This product contains code developed by the OpenSSL Project
This product includes software developed by the OpenSSL Project. For use in the OpenSSL Toolkit. (http:/
/www.openssl.org/).
Copyright (c) 1998-2005 The OpenSSL Project. All rights reserved.
This product contains the Rijndael cipher

The Rijndael implementation by Vincent Rijmen, Antoon Bosselaers and Paulo Barreto is in the public
domain and distributed with the following license:
@version 3.0 (December 2000)
Optimized ANSI C code for the Rijndael cipher (now AES)
@author Vincent Rijmen <vincent.rijmen@esat.kuleuven.ac.be>
@author Antoon Bosselaers <antoon.bosselaers@esat.kuleuven.ac.be>
@author Paulo Barreto <paulo.barreto@terra.com.br>
The OnDemand Switch may use software components licensed under the GNU General Public
License Agreement Version 2 (GPL v.2) including LinuxBios and Filo open source projects. The
source code of the LinuxBios and Filo is available from Radware upon request. A copy of the license
can be viewed at:
http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
This code is hereby placed in the public domain.
THIS SOFTWARE IS PROVIDED BY THE AUTHORS ''AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE*
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR

OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
This product contains code developed by the OpenBSD Project

Copyright (c) 1983, 1990, 1992, 1993, 1995
The Regents of the University of California. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided
that the following conditions are met:
1.
Redistributions of source code must retain the above copyright notice, this list of conditions and
the following disclaimer.
2.
Redistributions in binary form must reproduce the above copyright notice, this list of conditions
and the following disclaimer in the documentation and/or other materials provided with the
distribution.
3.
Neither the name of the University nor the names of its contributors may be used to endorse or
promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS AS IS AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
This product includes software developed by Markus Friedl
This product includes software developed by Theo de Raadt
This product includes software developed by Niels Provos
This product includes software developed by Dug Song
This product includes software developed by Aaron Campbell
This product includes software developed by Damien Miller
This product includes software developed by Kevin Steves
This product includes software developed by Daniel Kouril
This product includes software developed by Wesley Griffin
This product includes software developed by Per Allansson
This product includes software developed by Nils Nordman
This product includes software developed by Simon Wilkinson
Redistribution and use in source and binary forms, with or without modification, are permitted provided
that the following conditions are met:
1.
Redistributions of source code must retain the above copyright notice, this list of conditions and
the following disclaimer.
2.
Redistributions in binary form must reproduce the above copyright notice, this list of conditions
and the following disclaimer in the documentation and/or other materials provided with the
distribution.
THIS SOFTWARE IS PROVIDED BY THE AUTHOR AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Safety Instructions
CAUTION
Due to the risks of electrical shock, and energy, mechanical, and fire hazards, any procedures that
involve opening panels or changing components must be performed by qualified service personnel
only.
To reduce the risk of fire and electrical shock, disconnect the device from the power line before
removing cover or panels.
SERVICING
Do not perform any servicing other than that contained in the operating instructions unless you are
qualified to do so. There are no serviceable parts inside the unit.
HIGH VOLTAGE
Any adjustment, maintenance, and repair of the opened instrument under voltage must be avoided
as much as possible and, when inevitable, must be carried out only by a skilled person who is aware
of the hazard involved.
Capacitors inside the instrument may still be charged even if the instrument has been disconnected
from its source of supply.
GROUNDING
Before connecting this device to the power line, the protective earth terminal screws of this device
must be connected to the protective earth in the building installation.
LASER
This equipment is a Class 1 Laser Product in accordance with IEC60825 - 1: 1993 + A1:1997 +
A2:2001 Standard.
FUSES
Make sure that only fuses with the required rated current and of the specified type are used for
replacement. The use of repaired fuses and the short-circuiting of fuse holders must be avoided.
Whenever it is likely that the protection offered by fuses has been impaired, the instrument must be
made inoperative and be secured against any unintended operation.
LINE VOLTAGE
Before connecting this instrument to the power line, make sure the voltage of the power source
matches the requirements of the instrument. Refer to the Specifications for information about the
correct power rating for the device.
SPECIFICATION CHANGES
Specifications are subject to change without notice.
Note: This equipment has been tested and found to comply with the limits for a Class A digital
device pursuant to Part 15 of the FCC Rules and EN55022 Class A, EN 55024; EN 610003-2; EN 61000-3-3 For CE MARK Compliance. These limits are designed to provide
reasonable protection against harmful interference when the equipment is operated in a
commercial environment. This equipment generates, uses and can radiate radio
frequency energy and, if not installed and used in accordance with the instruction
manual, may cause harmful interference to radio communications. Operation of this
equipment in a residential area is likely to cause harmful interference in which case the
user is required to correct the interference at his own expense.
Special Notice for North American Users:
For North American power connection, select a power supply cord that is UL Listed and CSA Certified
3 - conductor, [18 AWG], terminated in a molded on plug cap rated 125 V, [5 A], with a minimum
length of 1.5m [six feet] but no longer than 4.5m...For European connection, select a power supply
cord that is internationally harmonized and marked <HAR>, 3 - conductor, 0,75 mm2 minimum
mm2 wire, rated 300 V, with a PVC insulated jacket. The cord must have a molded on plug cap rated
250 V, 3 A..
RESTRICT AREA ACCESS
The DC powered equipment should only be installed in a Restricted Access Area.
INSTALLATION CODES
This device must be installed according to country national electrical codes. For North America,
equipment must be installed in accordance with the US National Electrical Code, Articles 110 - 16,
110 -17, and 110 -18 and the Canadian Electrical Code, Section 12.
INTERCONNECTION OF UNITS
Cables for connecting to the unit RS232 and Ethernet Interfaces must be UL certified type DP-1 or
DP-2. (Note- when residing in non LPS circuit)
OVERCURRENT PROTECTION
A readily accessible listed branch-circuit over current protective device rated 15 A must be
incorporated in the building wiring for each power input.
REPLACEABLE BATTERIES
If equipment is provided with a replaceable battery, and is replaced by an incorrect battery type,
then an explosion may occur. This is the case for some Lithium batteries and the following is
applicable:
If the battery is placed in an Operator Access Area, there is a marking close to the battery or
a statement in both the operating and service instructions.
If the battery is placed elsewhere in the equipment, there is a marking close to the battery or a
statement in the service instructions.
This marking or statement includes the following text warning:

CAUTION
RISK OF EXPLOSION IF BATTERY IS REPLACED BY AN INCORRECT BATTERY TYPE.
DISPOSE OF USED BATTERIES ACCORDING TO THE INSTRUCTIONS.
Caution To Reduce the Risk of Electrical Shock and Fire
1.
This equipment is designed to permit connection between the earthed conductor of the DC
supply circuit and the earthing conductor equipment. See Installation Instructions.
2.
All servicing must be undertaken only by qualified service personnel. There are not user
serviceable parts inside the unit.
3.
DO NOT plug in, turn on or attempt to operate an obviously damaged unit.
4. Ensure that the chassis ventilation openings in the unit are NOT BLOCKED.
5. Replace a blown fuse ONLY with the same type and rating as is marked on the safety label
adjacent to the power inlet, housing the fuse.
6. Do not operate the device in a location where the maximum ambient temperature exceeds
40C/104F.
7. Be sure to unplug the power supply cord from the wall socket BEFORE attempting to remove
and/or check the main power fuse.
CLASS 1 LASER PRODUCT AND REFERENCE TO THE MOST RECENT LASER STANDARDS IEC 60
825-1:1993 + A1:1997 + A2:2001 AND EN 60825-1:1994+A1:1996+ A2:2001
AC units for Denmark, Finland, Norway, Sweden (marked on product):
Denmark - Unit is class I - unit to be used with an AC cord set suitable with Denmark
deviations. The cord includes an earthing conductor. The Unit is to be plugged into a wall socket
outlet which is connected to a protective earth. Socket outlets which are not connected to earth
are not to be used!
Finland - (Marking label and in manual) - Laite on liitettv suojamaadoituskoskettimilla

varustettuun pistorasiaan
Norway (Marking label and in manual) - Apparatet m tilkoples jordet stikkontakt
Unit is intended for connection to IT power systems for Norway only.
Sweden (Marking label and in manual) - Apparaten skall anslutas till jordat uttag.
To connect the power connection:

1. Connect the power cable to the main socket, located on the rear panel of the device.
2. Connect the power cable to the grounded AC outlet.
CAUTION
Risk of electric shock and energy hazard. Disconnecting one power supply disconnects only one
power supply module. To isolate the unit completely, disconnect all power supplies.
ACHTUNG
Gafahr des elektrischen Schoks. Entfernen des Netzteckers elnes Netzeils spanningsfrei Um alle
Einheiten spannengsfrei zu chen, sind die Netzstecker aller Netzeile zu entfernen.
ATTENTION
Risque de choc et de danger electriques. Le debranchement dune seule alimentation stabilise ne
debranche uniquement quun module Alimentation Stabilisee. Pour Isoler completement le
module en cause, il faut, debrancher toutes les alimentations stabilisees
Attention: Pour Reduire Les Risques d'Electrocution et d'Incendie
1. Toutes les operations d'entretien seront effectuees UNIQUEMENT par du personnel d'entretien
qualifie. Aucun composant ne peut etre entretenu ou remplace par l'utilisateur.
2. NE PAS connecter, mettre sous tension ou essayer d'utiliser une unite visiblement defectueuse.
3. Assurez vous que les ouvertures de ventilation du chassis NE SONT PAS OBSTRUEES.
4. Remplacez un fusible qui a saute SEULEMENT par un fusible du meme type et de meme
capacite, comme indique sur l'etiquette de securite proche de l'entree de l'alimentation qui
contient le fusible.
5. NE PAS UTILISER l'equipement dans des locaux dont la temperature maximale depasse 40C.
6. Assurez vous que le cordon d'alimentation a ete deconnecte AVANT d'essayer de l'enlever et / ou
verifier le fusible de l'alimentation generale.
Manahmen zum Schutz vor elektrischem Schock und Feuer
Alle Wartungsarbeiten sollten ausschlielich von geschultem Wartungspersonal durchgefhrt

werden. Keine im Gert befindlichen Teile drfen vom Benutzer gewartet werden.
Offensichtlich defekte oder beschdigte Gerte drfen nicht angeschlossen, eingeschaltet oder
in Betrieb genommen werden.
Stellen Sie sicher, dass die Belftungsschlitze am Gert nicht blockiert sind.
Ersetzen Sie eine defekte Sicherung ausschlielich mit Sicherungen laut Sicherheitsbeschriftung.
Betreiben Sie das Gert nicht in Rumen mit Temperaturen ber 40C.
Trennen Sie das Netzkabel von der Steckdose bevor Sie die Hauptsicherung prfen oder
austauschen.
Document Conventions
This guide uses the following conventions and symbols:
Item
Description
Additional information
Note:
A suggestion or workaround
Tip:
A statement and instructions
To
An example scenario
Example
Possible damage to equipment, software, or data
Caution:
Possible physical harm to the operator
Warning:
This feature only operates when application
acceleration is disabled
Standard Acceleration
This feature only works operates when application
acceleration is enabled
Enhanced Acceleration

Table of Contents
Table of Contents
Important Notice ............................................................................................................ 3
Copyright Notices .......................................................................................................... 3
Safety Instructions ......................................................................................................... 5
Document Conventions ................................................................................................. 8
Chapter 1 Introducing AppDirector .................................................................... 17

AppDirector Modules ........................................................................................................... 18
Management Tools .............................................................................................................. 20
Licenses ............................................................................................................................... 20
Configuration and Workflows for AppDirector ............................................................. 22

Before Installation and Configuration ................................................................................... 22
Configuration for all AppDirectors ........................................................................................ 24
AppDirector Modes Workflow .............................................................................................. 25
Chapter 2 Administering and Monitoring AppDirector..................................... 27

Supported Management Interfaces for AppDirector .................................................... 27
Web Based Management ....................................................................................................
Web Services .......................................................................................................................
Command Line Interface .....................................................................................................
Configuring Telnet ...............................................................................................................
Configuring FTP Server .......................................................................................................
Configuring SNMP ...............................................................................................................
28
29
31
33
35
35
Version and Configuration Management ..................................................................... 46

Upgrades .............................................................................................................................
Software Versions ................................................................................................................
Configuration File Management ...........................................................................................
Licensing and Upgrading Licenses ......................................................................................
Managed Devices ................................................................................................................
Resetting Devices ................................................................................................................
Device Shutdown .................................................................................................................
46
47
48
53
56
57
57
Tuning AppDirector ...................................................................................................... 58

Device Tuning ......................................................................................................................
Device Global Parameters ...................................................................................................
Main Device Tuning Parameters .........................................................................................
Bandwidth Management Settings Tuning ............................................................................
Client Table Settings Tuning ................................................................................................
DNS Settings Tuning ...........................................................................................................
NAT Settings Tuning ............................................................................................................
Security Tuning ....................................................................................................................
Session Table Tuning ..........................................................................................................
Tuning Memory Check .........................................................................................................
58
61
62
64
65
65
65
66
67
67

Table of Contents
Tuning Statistics ..................................................................................................................

Bandwidth Management Tuning (ODS Devices Only) ........................................................
Classifier Tuning .................................................................................................................
SYN Protection Tuning ........................................................................................................
Application Security Tuning .................................................................................................
Behavioral DoS Tuning Parameters ....................................................................................
68
68
69
71
72
73
Monitoring AppDirector ............................................................................................... 75

Device Information ..............................................................................................................
Device Monitoring ...............................................................................................................
Notifications .........................................................................................................................
Configuration Auditing .........................................................................................................
AppDirector Thresholds .......................................................................................................
75
77
77
82
83
Basic Switching (Layer 2 Capability) .......................................................................... 88

AppDirector Physical Interface Configuration ...................................................................... 88
Layer 2 Interface Table ....................................................................................................... 89
Virtual LAN .......................................................................................................................... 91
VLAN Tagging ..................................................................................................................... 96
Spanning Tree Protocol ...................................................................................................... 98
Link Aggregation (Port Trunking) ...................................................................................... 101
Port Mirroring .................................................................................................................... 104
IP Addressing and Routing ....................................................................................... 105

Interface IP Addresses ......................................................................................................
Routing ..............................................................................................................................
Routing Table ....................................................................................................................
ARP Table .........................................................................................................................
NHRs .................................................................................................................................
VIP NHR ............................................................................................................................
Routing Information Protocol .............................................................................................
Open Shortest Path First (OSPF) ......................................................................................
Border Gateway Protocol ..................................................................................................
106
107
109
110
110
111
112
114
119
Redundancy ............................................................................................................. 123

Network Configurations .....................................................................................................
Configuration Guidelines ...................................................................................................
Global Redundancy Configuration ....................................................................................
Failover Decision ...............................................................................................................
Stateful Failover (Mirroring) ...............................................................................................
Physical IP Addresses versus Virtual IP Addresses Redundancy ....................................
Virtual Router Redundancy Protocol .................................................................................
Proprietary Redundancy ...................................................................................................
Configuration Synchronization ..........................................................................................
125
128
134
136
140
142
142
147
148
Chapter 3 Traffic Management and Application Acceleration....................... 157

Configuring Farms .................................................................................................... 159
Farm Parameters .............................................................................................................. 159
Additional HTTP Connectivity Checks Parameters ........................................................... 167
10

Table of Contents
No HTTP Service Page .................................................................................................... 168
Configuring Servers .................................................................................................. 170

Physical Servers ...............................................................................................................
Application/Farm Servers .................................................................................................
Dispatch Methods .............................................................................................................
Local Triangulation ...........................................................................................................
170
172
177
181
Traffic Management Policies .................................................................................... 183

Layer 4 Policies ................................................................................................................
Layer 4 Policies Lookup Mechanism ................................................................................
Layer 4 Policy Statistics ....................................................................................................
HTTP Policies ...................................................................................................................
TCP Policies .....................................................................................................................
183
186
187
188
192
SSL Offloading and Authentication .......................................................................... 194

SSL Policies ......................................................................................................................
Authentication Policies Overview ......................................................................................
Client Authentication Policies ...........................................................................................
Trust-service Status List (TSL) Authentication Policies ....................................................
Certificate Validation Policies ...........................................................................................
195
199
199
203
211
Application Acceleration ........................................................................................... 217

Benefits of Application Acceleration ................................................................................. 217
Enabling Application Acceleration .................................................................................... 218
Acceleration Policies ......................................................................................................... 219
Layer 7 Traffic Management ..................................................................................... 228

Layer 7 Methods ...............................................................................................................
Layer 7 Farm Selection .....................................................................................................
Layer 7 Modification ..........................................................................................................
Layer 7 Server Persistency ...............................................................................................
228
234
238
252
Client Table Management ........................................................................................ 264

Types of Client Table Entries ............................................................................................
Static Client Table .............................................................................................................
View Filtered Clients .........................................................................................................
Client Table Views ............................................................................................................
Reset Client on Server Failure ..........................................................................................
Close Session At Aging ....................................................................................................
Client Table Sessions Modes ...........................................................................................
264
265
266
266
268
268
268
Network Address Translation (NAT) ......................................................................... 274

Client NAT ........................................................................................................................ 275
Server NAT ....................................................................................................................... 279
Outbound NAT .................................................................................................................. 284
Configuring AppDirector Advanced Global Parameters ........................................... 289
Chapter 4 Configuring Global Load Balancing ............................................... 293

Global Traffic Management ...................................................................................... 293
IP Traffic Management ..................................................................................................... 293
11

Table of Contents
Global Solution Configuration Guidelines .......................................................................... 296
Proximity ................................................................................................................... 297

Proximity Parameters ........................................................................................................
Proximity Checks ...............................................................................................................
Proximity Report Protocol (PRP) .......................................................................................
Static Proximity Database .................................................................................................
298
299
300
301
Configuring Local Report Protocol ............................................................................ 303

Introducing the Load Report Protocol (LRP) ..................................................................... 303
LRP in Multi-Homed Environments ................................................................................... 307
Local Load Report Protocol (Local LRP) ........................................................................... 309
Domain Name System (DNS) ................................................................................... 311

Host Names ......................................................................................................................
DNS Server Parameters ....................................................................................................
DNS Persistency ...............................................................................................................
DNS Statistics ...................................................................................................................
311
315
315
319
Redirection ............................................................................................................... 319

DNS Redirection ...............................................................................................................
HTTP Redirection ..............................................................................................................
HTTP to HTTPS Protocol Redirection ...............................................................................
RTSP Redirection .............................................................................................................
SIP Redirection .................................................................................................................
Proxy Redirection ..............................................................................................................
Global Triangulation Redirection .......................................................................................
Setting Redirection Parameters ........................................................................................
Anycast Advertise .............................................................................................................
320
320
321
323
323
323
324
326
328
Chapter 5 Configuring Health Monitoring ....................................................... 331

Checked Element .............................................................................................................. 331
Health Check ..................................................................................................................... 331
Health Monitoring Global Parameters ............................................................................... 331
Health Checks .......................................................................................................... 332

Group Health Checks ........................................................................................................
Single Health Checks ........................................................................................................
Health Checks Per Farm ...................................................................................................
Health Monitoring Check Table .........................................................................................
Binding ..............................................................................................................................
Packet Sequence Table ....................................................................................................
Server Table ......................................................................................................................
Diameter Argument List and Additional Method Arguments .............................................
Uploading, Downloading and Deleting the Diameter File using Binary File Transfer ........
User Defined Methods ......................................................................................................
333
333
333
333
347
348
349
350
352
352
AppDirector Farm Connectivity Checks .................................................................... 353

Ping Connectivity Method ................................................................................................. 353
TCP Port Connectivity Method .......................................................................................... 354
UDP Port Connectivity Method .......................................................................................... 354
12

Table of Contents
HTTP Page Connectivity Method ..................................................................................... 354

Long URL Checks ............................................................................................................. 355
Disabled Connectivity Method .......................................................................................... 355
Chapter 6 Classes and Bandwidth Management ............................................ 357

Bandwidth Management Introduction ....................................................................... 357
Radware Implementation of Bandwidth Management ...................................................... 358
Bandwidth Management and Classifier Settings ...................................................... 361

Bandwidth Management Rules ......................................................................................... 362
Configuring Bandwidth Management ....................................................................... 364

Bandwidth Management and Classes Update Policies .................................................... 372
Configuring Networks ....................................................................................................... 372
Services .................................................................................................................... 374

Basic Filters ......................................................................................................................
Application Port Groups ....................................................................................................
Physical Port Groups ........................................................................................................
VLAN Tag Groups ............................................................................................................
MAC Groups .....................................................................................................................
Protocol Discovery ............................................................................................................
Interface Classification ......................................................................................................
376
380
382
382
383
383
384
Chapter 7 Advanced Capabilities ..................................................................... 389

Diameter and LDAP Load Balancing ........................................................................ 389
Application Server TCP Splitting ....................................................................................... 390
TCP Splitting Table ........................................................................................................... 391
Multihoming .............................................................................................................. 392

Default Router Per Virtual IP ............................................................................................ 393
Using Redirect to Self in Multi-Homed Environments ....................................................... 396
Segmentation ........................................................................................................... 398

Segmentation Overview .................................................................................................... 398
Implementing Segmentation with AppDirector .................................................................. 400
Session Initiation Protocol (SIP) ............................................................................... 404

SIP Load Balancing with AppDirector ...............................................................................
Farm Selection Based on SIP Parameters .......................................................................
Load Balancing SIP Servers .............................................................................................
Outbound SIP Sessions ....................................................................................................
405
405
405
406
Stream Control Transmission Protocol (SCTP) ........................................................ 406

Performance Statistics .............................................................................................. 408
Acceleration Engine Statistics ..........................................................................................
Bandwidth Management Statistics ....................................................................................
Element Statistics .............................................................................................................
IP Interface Statistics ........................................................................................................
Servers .............................................................................................................................
409
422
424
428
430
13

Table of Contents
AppDirector Statistics ........................................................................................................

TCP Splitting Statistics ......................................................................................................
Protocol Statistics ..............................................................................................................
Statistics Monitor ...............................................................................................................
432
433
435
437
Utilities ...................................................................................................................... 439

DNS Client ........................................................................................................................ 439
Time Settings .................................................................................................................... 440
Event Scheduler ................................................................................................................ 442
Chapter 8 Security ............................................................................................. 445

AppDirector Device Security ..................................................................................... 445
Management Ports (Setting Physical Management Ports Restrictions) ............................ 445
Ports Access ..................................................................................................................... 446
User Table and Authentication .......................................................................................... 446
Keys and Certificates ................................................................................................ 450

Certificates ........................................................................................................................
Keys ..................................................................................................................................
Certificates Workflows .......................................................................................................
Configuration of Keys and Certificates ..............................................................................
450
450
450
452
Application Security .................................................................................................. 456

SYN Flood Protection ........................................................................................................
Session Table and Session Table Lookup Mode ..............................................................
Working in Application Acceleration Disabled Mode .........................................................
Signature Protection ..........................................................................................................
Behavioral DoS .................................................................................................................
Connection Limit ...............................................................................................................
Global Suspend Table .......................................................................................................
Security Reporting .............................................................................................................
Attack Database ................................................................................................................
457
462
465
465
487
499
503
504
509
Appendix A Radware Technical Glossary ....................................................... 519

Appendix B Regular Expressions .................................................................... 559
Appendix C Troubleshooting............................................................................ 561
Diagnostic Tools ....................................................................................................... 561
Diagnostics Trace-Log ......................................................................................................
Traffic Capture ..................................................................................................................
Diagnostics Tools Policies .................................................................................................
Diagnostics Tools File Management .................................................................................
Diagnostics Tools Tuning ..................................................................................................
System Diagnostics ...........................................................................................................
561
564
569
571
572
572
Acceleration-Engine Logs ......................................................................................... 576

Downloading the Technical Support File .................................................................. 578
14

Table of Contents
Appendix D Optimizing AppDirector with AppXcel Application Accelerator 581

Appendix E SSL Encryption,Certificates and Ciphers .................................. 583
SSL Encryption ......................................................................................................... 583
Encryption Protects Data During Transmission ................................................................ 583
Credentials Establish Identity Online ................................................................................ 584
Authentication Generates Trust in Credentials ................................................................. 584
Certificates ............................................................................................................... 584

Online Certificate Status Protocol (OSCP) ....................................................................... 587
Certificate Signing Request (CSR) ................................................................................... 588
Certificate Authority .......................................................................................................... 588
Ciphers and Cipher Suites ........................................................................................ 590

Ciphers .............................................................................................................................
Cipher Suites ....................................................................................................................
Cipher Suites Used by AppDirector ..................................................................................
Securing a Connection - the SSL Handshake ..................................................................
590
591
592
599
15

Table of Contents
16

Introducing AppDirector
Chapter 1 Introducing AppDirector

This chapter introduces AppDirector capabilities and provides a brief description of its main
characteristics in the following sections:
AppDirector Modules, page 18
Configuration and Workflows for AppDirector, page 22
AppDirector by Radware is an Application Delivery Controller (ADC) that provides Layer 4-7 local and
global application delivery and acceleration across Web applications and Database server farms,
ensuring application uptime, global redundancy, and user experience optimization. AppDirector
provides full availability, high performance, and complete security for mission critical applications.
AppDirector is intended for organizations that conduct their business using networked applications,
the Internet, or a private intranet to communicate between offices that are geographically dispersed
or between business partners and end users, as in e-commerce or online banking.
As a result of the reliance on networked/Web applications like ERP, CRM, or Citrix applications, there
has been significant growth in the volume of transactions and in the processing power required to
execute them efficiently. AppDirector relies on a successful combination of a powerful hardware
platform and an application smart service to achieve a high level of availability, performance, and
security. AppDirector is based on Radwares Intelligent Application Switching Architecture, which
provides high speed hardware processing power, along with APSolute OS Application Smart Service.
Throughout this AppDirector User Guide, AppDirectors main capabilities have been delineated into
two non-mutually exclusive options where necessary. They are:
For Application acceleration, including SSL offloading, Web compression, caching and TCP
optimization, that provides best Quality of Experience (QoE)
For Optimized Server Utilization and Application Performance
Look out for these labels throughout this User Guide, they are here to help you get the maximum
benefit from AppDirector.
The AppDirector Application Smart Service modules offer these capabilities:
24/7 Network Health Monitoring
Intelligent Load Balancing
Fault Management
Traffic Shaping
17

AppDirector Modules
AppDirector successfully combines various functional modules. AppDirectors advanced Health
Monitoring module verifies the availability of the entire transaction path and resources. The Traffic
Redirection module works closely with the Health Monitoring module and performs Layer 4-7
switching based on resource availability. Traffic Redirection optimizes server usage by applying
intelligent dispatch load balancing algorithms. If network elements fail (e.g; routers, switches, or
other resources in path to servers, or back-end servers), Traffic Management allows the traffic to
bypass any faulty elements.
The network path can be further optimized by utilizing the Bandwidth Management (BWM) features.
The BWM can be utilized to enforce business priorities and resource utilization across the network.
You can assign a higher priority and guaranteed bandwidth to mission critical applications such as
SAP, ORACLE, etc., while assigning a best effort policy with lowered priorities for bulk traffic such as
FTP, e-mail, and any other non-critical applications.
Numerous application level attacks through firewalls expose an organization's network and
applications to various threats. If left unchecked, these can result in severe damage, either to
intellectual property and/or confidential data theft, or to disruptions of services resulting in lost
revenue. The advanced security module is an integral part of the AppDirector intelligent application
switching process, providing protection against various attacks, worms, and viruses.
Health Monitoring
The Health Monitoring module constantly checks the health of the entire transaction path. This
ensures the availability of all the network elements required for the completion of a successful
transaction, including routers, backend servers and applications. This module enables you to create
any type of Layer 2 - Layer 7 Health Check on any network element. The wide variety of predefined
Health Checks allows you to meet the specific requirements of your network. For more information
on Health Monitoring, see Configuring Health Monitoring, page 331.
Traffic Redirection
The Traffic Redirection module provides Layer 4 - Layer 7 switching capability. This module performs
server selection in a Farm, based on availability, load, and content considerations. For more
information on Traffic Redirection, see Traffic Management and Application Acceleration, page 157.
To select a server within a Farm, AppDirector uses various dispatch algorithms based on the traffic
load of the servers and available server resources. You can also define server persistency, where all
sessions with same predefined characteristics are forwarded to the same server. Traffic Redirection
can be configured with many dispatch methods and settings ensuring optimum utilization of server
resources while monitoring network conditions.
When content is distributed among multiple sites, AppDirector applies a global Traffic Redirection
solution combining advanced load and proximity-based decisions with different redirection methods
optimizing resource usage and providing accelerated content delivery. This enables you to add
network elements without service interruption in a geographically dispersed global context.
Global Traffic Redirection

AppDirector-Global provides global and local internet traffic management services. It redirects the
user to the best available site, before a server is selected within the local site. AppDirector-Global
performs load balancing for distributed sites, according to proximity, load and availability
considerations.
18

Acceleration Engine
AppDirector assists acceleration with the following attributes:
Reduces web-application latency across the WAN and decreases application response time.
Offload servers from handling SSL decryption and encryption.
Reduce "chattiness" of TCP and HTTP protocols.
Improves response time by offloading TCP connection handling. It accelerates repetitive content
fetching time by using a cache.
Using compression, reduces WAN bandwidth consumption and accelerates web-pages on low
bandwidth (dial-up, wireless) WAN connections.
Secure Socket Layer (SSL) Offload
AppDirector can accelerate SSL traffic and offload servers. AppDirector handles the SSL key
negotiation with the client and encrypting and decrypting of communication. AppDirector serves as a
proxy, terminating the SSL client sessions and opening a separate session to the backend servers.
Trust-Service Status List (TSL)
AppDirector is the only ADC solution that provides full support of the TSL standard allowing:
Automatic retrieval and updates of the client authentication configuration according to the TSL
standard.
OCSP Caching to minimize authenticating infrastructure overload of Advance Clients Certificates

Field.
Verification capabilities for granular control over allowed certificate holders access at network
level.
TCP Optimization
AppDirector reorders TCP packets that arrive out of order. This offloads this task from the backend
server.
19

Web Compression
AppDirector compresses HTTP traffic to reduce the latency for clients that access web applications
over WAN. Compression reduces the size of the objects and therefore the objects take less time to
download over the WAN. Latency is high for instance, when clients are located a large number of
network hops away from the server, over satellite links, or when bandwidth (and thus transfer rate)
is low. AppDirector supports Compression in software by default. An optional Hardware Compression
module enables AppDirector to handle higher throughput from the web application server.
Web Caching
AppDirector improves response time by caching web objects from the server and offloading them to
save resources. AppDirector caches server content according to their cache settings as they appear
in the HTTP headers
Management Tools
The following management tools can be used to manage a single AppDirector device.
Web Based Management (WBM), using HTTP and/or HTTPS.
Command Line Interface (CLI), using Telnet, SSH, or Serial Console access.
Please consult the latest accompanying Release Notes for this AppDirector version for detailed
management tool support information.
Licenses
The licensing mechanism is used to provide an easy path for adding product capabilities after initial
product purchase. There are several types of license available.
Note: Please also see the Radware Licensing Model for further information.
Capabilities License
This is available on all platforms and allows you to add product specific capabilities (such as Global
Load Balancing) and APSolute OS capabilities (BWM and IPS, DoS). This license is accumulative it
can both enable a product specific capability and APSolute OS capability for example.
For more information on AppDirector and AppDirector Global capabilities, see Radware Devices Used
in Global Solution, page 295.
20

Compression Throughput License
This defines the HTTP compression capacity level and enables capacity upgrade (compression
throughput in Mbps) for AppDirector (version 2.0 and up). HTTP Compression license upgrade does
not require device rebooting.
SSL TPS License
AppDirector comes bundled with basic SSL capabilities (maximum number of transactions per
second - TPS) which can be upgraded by license. This license defines the SSL offload capacity level
and enables capacity upgrade (SSL TPS) for AppDirector (version 2.0 and up). The SSL TPS license
upgrade does not require device rebooting.
TSL License
This allows you to handle situations where one organization is responsible for the creation,
distribution and management of Digital ID cards (e.g. Government), and other organizations need to
authenticate users based on the Digital IDs (e.g. Tax management, Health Insurance, Financial
institutes, employers, etc.).
Management Interfaces
The following Management interfaces are supported for AppDirector.
Command Line Interface - over Telnet, SSH or RS232
Web-based GUI - over HTTP & HTTPS
SNMP
Web Services - SOAP API over HTTP & HTTPS
FTP server
21

Configuration and Workflows for AppDirector

This section describes the step-by-step configuration for AppDirector. It is common to many
scenarios and you can adjust it to meet your specific needs using your own network's IP addresses.
Before Installation and Configuration, page 22
Configuration for all AppDirectors, page 24
AppDirector Modes Workflow, page 25
Before Installation and Configuration

Before installation, Radware recommends you take into consideration the following:
Radware Platforms Supported, page 22
Physical Connectivity Concerns, page 22
IP Allocation Concerns, page 22
Management Concerns, page 23
Technical Support, page 23
Technical Support, page 23
Radware Platforms Supported

AppDirector 2.14 supports the following Radware platforms (XL and non-XL models):
OnDemand Switch 1, OnDemand Switch 2, OnDemand Switch 3 v2,OnDemand Switch VL
For further information, see the Radware Installation and Maintenance Guide.
Physical Connectivity Concerns

A Radware device acts as a switch. Crossed cables should be used between switches and straight
cables should be used for connecting other network hosts. Make sure you use the right type of cable
as stated. Some platforms support the Auto sensing feature (MDIX) and can operate with any type
of cable, however this feature is disabled once you disable Auto negotiation.
Only GBICs that have been tested and approved by Radware can be used. For an updated list, refer
to: http://www.radware.com/content/support/faq/gigabitethernetandgibcsupport.asp.
Auto negotiation is activated by default. In most cases, this is the preferred option. Verify that it is
activated on the other side as well.
Note: Disabling Auto negotiation also disables the cable type Auto sensing feature (MDIX).
Optical cables are not provided by Radware and need to be purchased separately. Some devices use
SC connectivity and LC. Make sure you have the appropriate cable.
The copper cables that Radware provides are intended for management only and should not be used
for other types of traffic. CAT5 certified copper cables must be used.
When connecting to network switches and working with Radware's proprietary redundancy protocol,
ensure that you disable Spanning Tree or at least enable Port Fast on the relevant ports (on the
switch). You can also set the Spanning Tree to operate in fast learning mode on the relevant ports.
IP Allocation Concerns
Ensure that you have the IP addresses allocated and defined in your network for the AppDirector's
interfaces, new servers, NAT IP addresses (if activated on the AppDirector), DNS IP addresses (if
activated on the AppDirector) and for the redundant AppDirector as well.
22

Pay particular attention to the Local Triangulation implementation and VLANs (explained in this
document) where the IP addresses of the servers should be public routable IP addresses.
Management Concerns
Radware management uses SNMP communication running on UDP port 161. Ensure that this
communication port is not blocked by your firewall.
Configuration upload/download action uses TFTP protocol. Ensure that TFTP is not blocked by your
firewall and the management station is not NATed toward the Radware device. As TFTP traffic is
initiated from the Radware device to the management station, a relevant firewall rule should be
configured. UDP ports 162 and 69 are used for TFTP.
Radware devices can also use HTTP, HTTPS, Telnet, and SSH for management. If you choose to
activate one of the above, verify that they are not blocked by your firewall. Traffic direction is from
the management system to the Radware device. Radware devices have a console port for terminal
communication. This uses an RS232 cable (provided by Radware).
Technical Support
Radware offers its Certainty Support Program, a suite of technical support packages in various
levels. You can view all programs at: http://www.radware.com/content/support/default.asp.
Once you purchased the relevant Certainty Support package you can either contact Radware via
email (support@radware.com) or via the phone using our worldwide toll free numbers. An updated
list is available at: http://www.radware.com/content/support/support program/contact.asp.
Additional information about the Radware Certainty Support program is available at: http://
www.radware.com/content/document.asp?_v=about&document=2774.
23

Configuration for all AppDirectors

The following general workflow with mappings to appropriate chapters is shown here to help you
configure your AppDirector devices.
24

AppDirector Modes Workflow

For AppDirector version 2.14, this diagram helps you to distinguish between Enhanced Application
Acceleration and Standard Application Acceleration Modes and their capabilities.
25

26

Administering and Monitoring AppDirector
Chapter 2 Administering and Monitoring

AppDirector
This chapter provides information on the AppDirector management and maintenance processes. For
information on installing and configuring AppDirector, see the Radware Installation and Maintenance
Guide. This chapter includes the following sections:
Supported Management Interfaces for AppDirector, page 27
Version and Configuration Management, page 46
Tuning AppDirector, page 58
Monitoring AppDirector, page 75
Basic Switching (Layer 2 Capability), page 88
IP Addressing and Routing, page 105
Redundancy, page 123
Supported Management Interfaces for AppDirector

This section discusses management interfaces supported by AppDirector and includes these topics:
Web Based Management, page 28
Web Services, page 29
Command Line Interface, page 31
Configuring Telnet, page 33
Configuring FTP Server, page 35
Configuring SNMP, page 35
Web Based Management (WBM) is the main management interface for Radware products.
Additionally, you can manage your AppDirector with Command Line Interface (CLI).You can connect
AppDirector devices to management interfaces through network physical interfaces or serial ports.
These port types are supported:
For network connection: SNMP, HTTP, HTTPS, Telnet, SSH.
For serial port connection: RS-232 up to 115 Kbps (default is 19,200 Kbps).
This table lists the AppDirector physical interfaces and the supporting management interfaces:
Port
Web Based Management Command Line Interface
SNMP V1, V3
HTTP
Secure Web
Telnet
SSH
RS-232
27

Web Based Management

The WBM (Web Based Management) graphical user interface (GUI) does not require client
installation, and is designed for easy and fast single device management via HTTP or HTTPS (for
secure access).
When using WBM, on-line help is available (by clicking the? icon that appears on every screen) from
the Radware corporate website. However, you can specify a custom location for the help files.
Web
You can use Web Server Parameters to enable and define to which port the WBM should be assigned.
To configure the Web Based Management

1.
From the Services menu, select Management Interfaces > Web Server > Web. The Web
Server Parameters window appears.
2.
Set the parameters.
Parameter
Description
Web Server Port
Port to which the Web Based Management is assigned.
Web Server Status
Enables or disables the status of the web server.
Web Help Location
Location (path) of the web help files.
Web Access Level
Values: Read Write (default) or Read Only. This setting affects both
WBM and Secure WBM.
When WBM Access Level is set to Read Only, users using WBM or
Secure WBM experience the following limitations:
Cannot change the configuration of the device
Cannot view the Community Table or User Table
Have no access to SSH Public Key Table
SSL keys and certificates cannot be viewed
Configuration File cannot be sent to or received from the device
Software update to the device is not allowed
Cannot reset the device
Note: Setting this requires restarting the device.
3.
28
Click Set. Your configuration is set.

Secure Web
You can define the parameters for obtaining secure HTTP requests.
To define secure web parameters

1. From the Services menu, select Management Interfaces > Web Server > Secure Web. The
Secure Web Parameters window appears
2. Set the parameters.
Parameter
Description
Secure Web Port
Port through which HTTPS gets requests.
Secure Web Status
Enables or disables (default) the status of the web server.
Secure Web Private Key File
Private Key file used by secure web for encryption.
Secure Web Certificate File
Certificate file used by secure web for encryption.
3. Click Set. Your configuration is set.
Supported Browsers
WBM is supported with the following Internet browsers:
Microsoft Internet Explorer version 6 (when using Windows operating systems)
Microsoft Internet Explorer version 7
Microsoft Internet Explorer version 8
Mozilla (when using Linux operating systems)
Firefox
Web Services
To provide customers with the capability to develop enhanced application monitoring, customized
application delivery network management applications and advanced automation tools, Radware
provides a web services interface on AppDirector via APSolute API, an open standards-based SOAP
(XML) API.
AppDirector Web Services operate via HTTP or HTTPS requests, like a regular web browser and
default disabled. They can be enabled via:
CLI: manage web-services status
WBM: Services/Web/Web Services window
Note: Web Services can only be enabled if either web or secure web management interface are
enabled on the device. Changing the Web Services status requires a device reset.
29

To enable Web Services

1.
From the Services menu, select Management Interfaces > Web Server > Web Services.
The Web Services window appears.
2.
Set the parameter.
3.
Parameter
Description
Web Services Status
Enables Web Services
APSolute API Overview

APSolute API is an advanced network Application Programming Interface that enables the
development of software applications to remotely monitor and control Radware products. This Webservices interface to all Radware application switches and appliances providing for native software
access from any external application or development tool environment.
Integration with APSolute API gives you a comprehensive view of the AppDirector devices
performance including historical data analysis and trending, performance diagnostics, availability
reports, and automation of maintenance operations and fine-tuning of AppDirector for optimal
application delivery based on parameters external to AppDirector.
The APSolute API is a SOAP/XML interface providing full access to Radware devices for third-party
applications and utilizing common development languages including Java, Visual Basic/C#, and Perl.
APSolute API offers two approaches to interact with Radware devices:
1.
Issuing CLI commands and receiving output via a generic SOAP method.
Note: This interface will not provide support for:

>> Non- configuration commands or monitoring, such as ping, telnet, or trace-route.
>> Asynchronous output commands (e.g. accelerator related CLI commands).
2.
Ability to configure and monitor the devices via SOAP commands that mirror Radware's SNMP
MIB. Commands include:
a.
b.
For scalar MIB parameter: retrieve (get) the value and change (set) the value
For a MIB table entry: create an entry, delete an entry, update one or more parameters of
an entry, retrieve (get) an entry, retrieve (get) the entire table, walk through the table (get
first entry then get next).
APSolute API Software Development Kit (SDK)

The APSolute API SDK provided for each AppDirector version, contains components and
documentation to enable development of control and monitoring capabilities in custom-developed
applications. This includes:
WSDL files for all interfaces and modules.
API Reference.
Product overview.
Sample code for basic device configuration/monitoring functions.
30

The APSolute API SDK requires a SOAP client tool kit (supporting SOAP version 1.1 and above) and
the development environment for the tool kit must be installed on the workstation used. The SDK
was verified and tested for compatibility with the following:
Development Environments
Languages
Microsoft Visual Studio .NET 2005
Visual Basic & C#
Axis 1.3
Java 1.50
Active Perl 5.8.8
Perl
Command Line Interface

The Command Line Interface (CLI) is a built-in, text-based menu system for access via local
terminal or remote Telnet or SSH session. The main CLI menu is displayed in the following table:
CLI Command
Explanation
appDirector
AppDirector parameters
classes
Configures traffic attributes used for classification
device
Device Settings
health-monitoring
Advanced Health Monitoring
help
Displays help for the specified command
login
Login into the device
logout
Logout of the device
manage
Device management configuration
net
Network configuration
nslookup
Queries the DNS server
performance
AD performance
ping
Sends echo requests
reboot
Reboot the device
redundancy
Redundancy settings
security
Security settings
services
General networking services
shutdown
Shutdown
ssh
SSH to a remote host
statistics
Device statistics configuration
system
System parameters
telnet
Telnets to a remote host
trace-route
Measures hops and latency to a given destination
31

CLI Supported Capabilities

Radware's Command Line Interface provides the following capabilities:
Consistent, logically structured, and intuitive command syntax.
A system config command to view the current configuration of the device, formatted as CLI
command lines.
Pasting the output of system config, or part of it, to the CLI of another device, using the
system config set command. This option can be used for easy configuration replication.
Help and command completion keys.
Command line editing keys.
Command history.
Configurable prompt.
Configurable banner for Telnet and SSH.
Ping: Ping other hosts on the network to test availability of those hosts.
Traceroute: Use command trace-route <destination IP addr>.

Output format:
AppDirector#trace-route www.radware.com
trace-route to host 209.218.228.203:
1:
50ms
50ms
50ms 212.150.43.130
2:
50ms
50ms
50ms 80.74.101.129
3:
50ms
50ms
50ms 192.116.214.2
4:
5:
50ms
*
50ms
*
50ms 80.74.96.40
Telnet client: To initiate a Telnet session to remote hosts, use CLI command telnet <IP
address>.
SSH client: To initiate a SSH session to remote hosts, use CLI command ssh <IP address>.
DNS Lookup: Uses configured DNS servers to query IP addresses of a host name. This requires
that DNS client is enabled and DNS servers configured. The DNS client also enables using host
names rather than IP addresses in commands such as trace-route, ping, telnet, etc. Use the
command nslookup <hostname>.
CLI Session Time-Out

You can define a period of time during which the connection with the device via the console is kept
despite the sessions inactivity. This period is defined by the Session Time-Out parameters. If at the
end of the predefined time-out the session is still inactive, it is automatically terminated.
To configure the Console Time-Out
Manage terminal session-timeout to configure the Console Time-Out
Manage ssh session-timeout
Manage telnet session-timeout
Manage ssh auth-timeout
Manage telnet auth-timeout
32

Configuring Telnet
A Telnet connection offers the convenience of accessing the device from any workstation connected
to the network. To establish a Telnet connection with the device, run the Telnet program on your
workstation and issue the Telnet command, followed by the device IP address:
telnet <IP address>.
To configure Telnet access

1. In the main window of WBM, select Management Interfaces > Telnet. The Telnet window
appears.
Parameter
Description
Telnet Port
The TCP port used by the Telnet.
Telnet Status
Enables and disables the Telnet access to the device.
Telnet Session
Timeout
Time-out (in minutes) required for device to maintain connection during

periods of inactivity.
When you enter a user name and password, if you make three incorrect
login attempts, the terminal is locked for 10 minutes and no further
logins are accepted from that IP address.
Default: 5 minutes.
Values: 1 120 minutes.
Notes:
To avoid affecting device performance, time-out is automatically
checked every 10 seconds. This means that the actual time-out can
be up to 10 seconds longer.
If you want to set your session to never expire then set the timeout
to 0 (= unlimited).
Telnet
Authentication
Timeout
Time-out (in seconds) required to complete authentication process.

Values: 10 60 seconds.
Default: 30 seconds.
3. Click Ok. Your configuration is set.
Configuring SSH
Secure Shell or SSH is a network protocol that allows data to be exchanged over a secure channel
between two computers. Encryption provides confidentiality and integrity of data. SSH uses publickey cryptography to authenticate the remote computer and allow the remote computer to
authenticate the user, if necessary. As a secure alternative to using Telnet to manage device
configuration, SSH ensures that all data sent over the network is encrypted and secure.
SSH Public Keys

In addition to normal password authentication, the device also supports SSH public key
authentication. For this method the user has to generate an SSH key pair (public key and private
key).
33

Note: When both password and public key are configured for a user, the Authentication Method
configured in the client software will dictate which authentication is selected for this
user.
To configure an SSH public key

1.
From the Security menu select Certificates > Import. The Import PKI Components window
appears.
2.
Import the user SSH public key (Entry Type=Key). See Importing Certificates, page 453 for
details.
3.
From the Security menu select Users. The Users Table and Authentication window appears.
4.
Double-click on the existing user or click Create to add a new user. The User Table Update/
Create window appears.
5.
In the SSH public key name drop-down select the relevant key configured in step 2 and click
Set. The SSH public key is configured for this user.
Configuring the SSH Connection

There are two versions of SSH: SSH1 and SSH2. AppDirector supports only SSH2.
To set the SSH server connection parameters

1.
From the Services menu select Management Interfaces > SSH > Server. The Secure Shell
Parameters window appears.
2.
Set the parameters.
Parameter
Description
SSH Port
Source port for the SSH server connection.
SSH Status
Enables or disables (default) SSH access to the device.
SSH Session Timeout
Timeout (minutes) for device to maintain connection while inactive.

Values: 1 120 minutes. Default: 5 minutes
Note: To avoid affecting device performance, time-out is
automatically checked every 10 seconds. This means that the
actual time-out can be up to 10 seconds longer
SSH Authentication
Timeout
Timeout (seconds) for completing authentication process. Available for

Telnet / SSH only.
When you enter a user name and password, if you make three
incorrect login attempts, the terminal is locked for 10 minutes and no
further logins are accepted from that IP address.
Values: 10 60 seconds.
3.
Enter the SSH Port and set the SSH Status to Enable.
4.
34

Configuring FTP Server

The FTP Server allows you to connect to the device using FTP and transfer files to/from the device
flash memory.
To configure FTP Service

1. From the Services menu, select Management Interfaces > FTP Server. The FTP Server
window appears, which contains the following parameter:
Parameter
Description
FTP Server Port
Application port to use to access the FTP server on the device.
FTP Server Status
Enable/Disable the FTP Server on the Device.
Note: To access the device via a FTP service, the FTP server must be enabled prior to access
Configuring SNMP
The Simple Network Management Protocol (SNMP) is an application layer protocol that facilitates the
exchange of management information between network devices. SNMP is a part of the Transmission
Control Protocol/Internet Protocol (TCP/IP) protocol suite. Radware devices work with the following
versions of SNMP: SNMPv1, SNMPv2, and SNMPv3.
Network management systems contain two primary elements: Managers and Agents. The Manager
is the console through which the network administrator performs network management functions.
Agents are entities that interface with the device being managed, allowing you to change or retrieve
objects. These objects are arranged in what is referred to as Management Information Base (MIB).
SNMP is the protocol that allows managers and agents to communicate to access these objects.
SNMPv3
SNMPv3 contains two communication layers between manager and agent:
User Security Model (USM), which provides secure communication, including message
integrity and privacy.
View-Based Access Control Model (VACM), which provides access permissions.
Parameter
Description
User Name
User name, up to 18 characters.
Use Authentication
Check this box to use authentication.
Authentication
Protocol
Select authentication protocol for the authentication process.
Authentication
Password
Password required for authentication.
Use Privacy
Check this box to use privacy.
Privacy Password
Enter the privacy password.
Values: MD5, SHA1,SHA2.
35

To set the SNMP Global parameters

1.
From the Security menu, select SNMP > Global Parameters. The SNMP Global Parameters
window appears.
2.
Set the parameters.
3.
Parameter
Description
Supported SNMP Versions
SNMP versions currently supported by the SNMP.
Supported SNMP Versions

After Reset
SNMP versions supported by the SNMP agent after resetting the

device. Check the SNMP version you wish to support. Un-check
the versions not supported.
SNMP Port
UDP port where the agent is listening for SNMP requests.
SNMP Status
Status of the SNMP agent. Default: Enable
Defining SNMP Users

With SNMPv3 user-based management, each user can have different permissions based on the user
name and connection method. You can create a new user by cloning the definitions an existing user.
In the User Based Security Model window, you can define users who can connect to the device and
store the access for each SNMP user.
You can define users that can connect to the device and store the access parameters for each SNMP
user in the User Based Security Model window.
To define a new user

1.
From the Security menu select SNMP > User Table. The User Table window appears.
2.
Click Create. The User Table Create window appears.
3.
Set the parameters.
Parameter
Description
User Name
Type name of the new user, up to 18 characters.
Authentication Protocol
Protocol used during authentication process. meaning using clear

text during the session.
Values: None, (default), MD5, SHA1, SHA2.
4.
36
Authentication Password
Enter an authentication password.
Privacy Protocol
Algorithm to be used for encryption. Default: None, which means

that the data is not encrypted. Possible value is DES.
Privacy Password
Enter a user privacy password.

SNMP VACM Edit Security to Group

SNMPv3 permissions are defined for groups of users. If, based on the connection method, there is a
need to grant different permissions to the same user, you can associate a user to more than one
group. For example, if user A connects to a Radware device using SNMPv3 with authentication and
privacy, the user gets Read-Write permissions; if the same user A connects to a Radware device with
authentication and without privacy (data is not encrypted), then the same user gets Read-Only
permissions. You can associate users with groups listed in the VACM Edit Security to Group window.
Access rights are defined for groups of users.
VACM MIB View

The View table defines subnets of the MIB tree. These views are used to allow Read-Write access
based on the MIB tree. The same Family View name can be used for multiple entries to allow
maximum flexibility. Each entry can include or exclude parts of the entire MIB tree.
SNMP Access
The Access table binds the groups, views, and security models. It grants permissions to the groups,
based on the SNMP version. You can define the access rights for each group and security model in
the VACM Group Access window. Objects can be accessed for a read, write, or notify action based on
the Read View Name, Write View Name, and Notify View Name parameters.
These parameters depend on the specified security model. The Read, Write, and Notify permissions
are configured for Family View names, which are defined in the VACM MIB View window, (see VACM
MIB View, page 37).
To configure the SNMP Access Table

1. From the Security menu, select SNMP >Access Table. The SNMP Community Table window
appears.
2. Click Create. The SNMP Access Table Create window appears.
Parameter
Description
Group Name
The name of your group.
Security Model
Select SNMP version that represents the required Security Model.

Security models are predefined sets of permissions that can be used by
the groups.
These sets are defined according to the SNMP versions. By selecting the
SNMP version for this parameter, you determine the permissions set to be
used.
Values: Any, SNMPv1 (Default), or User Based (SNMPv3).
Security Level
Select one of the relevant Security Levels:

NoAuthNoPriv (Default): No authentication or privacy are required
AuthNoPriv: Authentication is required, but Privacy is not required
AuthPriv: Both authentication and privacy are required
ReadView Name
Name of one or more entries in View Tree Family Table. Specifies which
objects in the MIB tree are readable by this group.
37

4.
Parameter
Description
WriteView Name
objects in the MIB tree are writable by this group.
NotifyView Name
objects in MIB tree can be accessed in notifications (traps) by this group.
SNMP Target Address

In SNMP v3, this table contains transport addresses to be used in the generation of traps. If the tag
list of an entry contains a tag from the SNMP Notify Table, this target is selected for reception of
notifications. For SNMP version 1 and 2 this table is used to restrict the range of addresses from
which SNMP requests are accepted and to which SNMP traps may be sent. If the Transport Tag of an
entry in the community table is not empty it must be included in one or more entries in the Target
Address Table window.
The Target Address Table window allows you to set and update the SNMP Target Parameters.
To configure the SNMP Target Address Table

1.
From the Security menu, select SNMP > Target Address Table. The SNMP Target Address
Table window appears.
2.
Click Create. The SNMP Target Address Table Create window appears.
3.
Set the parameters.
Parameter
Description
Name
Name of this entry.
Address-Port
Number of the Target Port. (TCP port to be used).

Values: 161 for SNMP Access, 162 for SNMP Traps (Default).
Address-Port must be a hex string ([1...255] bytes)
E.g. 0.0.0.0-162
Tag List
A list of tags separated by spaces. The tags contained in the list can
may be either tags from the Notify table or Transport tags from the
Community table.
Parameters
Name of entry in Parameters Table to be used when sending the SNMP

Traps
Mask
Mask address of the subnet.

Default: 0.0.0.0
Tip: The SNMP Target Address window also allows you to access the SNMP Target parameters
window (see SNMP Target, page 39).
38

SNMP Target
The Target Parameters Table window contains parameters to be used in generating a message.
Entries in this table are referenced in the Target Address Table window.
To configure the SNMP Target Parameters Table

1. From the Security menu, select SNMP > Target Parameters Table. The SNMP Target
Parameters Table window appears.
2. Click Create. The SNMP Target Parameters Table Create window appears.
Parameter
Description
Name
Name of this entry.
Message Processing Select one of the following:

SNMPv1 (Default)
SNMPv3
Security Model
Select the SNMP version that represents the required Security Model.
Security models are predefined sets of permissions that can be used by
the groups. These sets are defined according to the SNMP versions. By
selecting the SNMP version for this parameter, you determine the
permissions set to be used.
Values: Any, SNMPv1 (Default), or User Based (SNMPv3).
Security Name
The name of the user.
Security Level
Select one of the relevant Security Levels:

NoAuthNoPriv (Default): No authentication or privacy are required
AuthNoPriv: Authentication is required, but Privacy is not required
AuthPriv: Both authentication and privacy are required
SNMP Community Table (SNMPv1 and SNMPv2 Only)

The Community table allows backwards compatibility with SNMPv1 and SNMPv2 mapping
community strings to users. Once a user is connected to a device with SNMPv1 or SNMPv2, the
device checks the Community String sent in the SNMP packet. Based on a specific community string,
the device maps the community string to a predefined user, which belongs to a group with certain
access rights. Therefore, when working with SNMPv1 or SNMPv2, users, groups, and access must be
defined.
You can map community strings into user names and vice versa using the SNMP Community Table
window. This table restricts the range of addresses from which SNMP requests are accepted and to
which traps can be sent. The SNMP Community Table is used only for SNMP versions 1 and 2.
To configure the SNMP Community Table

1. From the Security menu, select SNMP > Community Table. The SNMP Community Table
window appears.
2. Click Create. The SNMP Community Table Create window appears.
39

3.
4.
Set the parameters.
Parameter
Description
Index
A descriptive name for this entry.
Community Name
The community string.
Security Name
User name associated with community string.
Transport Tag
Specifies a set of target addresses from which the SNMP accepts SNMP
requests and to which traps can be sent. Target addresses identified by
this tag are defined in the target address table. If this string is empty,
addresses are not checked when an SNMP request is received or when
a trap is sent. If this string is not empty, the transport tag must be
contained in the value of the tag list of at least one entry in the
target address table.
SNMP Notify Table

Using the SNMP Notify table, you can select management targets that receive notifications and the
type of notification to be sent to each selected management target. The Tag parameters contains a
string that is used to select entries in the Target Address table (see SNMP Target Address, page 38).
An entry in the Target Address table whose tag list contains the tag of one or more notification table
entries is selected for receipt of notifications.
To configure the SNMP Notify Table

1.
From the Security menu, select SNMP >Notify Table. The SNMP Notify Table window appears.
2.
Click Create. The SNMP Notify Table Create window appears.
3.
Set the parameters.
Parameter
Description
Name
A descriptive name for this entry.
Tag
This string selects one or more entries in the Target Address table. All
entries whose tag list contains this tag are selected for reception of
notifications.
Example SNMPv3 Access to the Device with Authentication and Privacy

The following example shows how to configure a Radware device to allow access using only SNMPv3,
MD5 as the authentication protocol and DES as the privacy protocol. Since the user with limited
access privileges cannot create a user with unlimited access, the first user must be created via the
CLI or via Web Based Management (WBM).
40

To configure SNMPv3 access with Authentication and Privacy

1. From a browser window enter the IP address of the AppDirector device. Web Based Management
(WBM) for the device window opens.
2. In WBM, select Security > SNMP > User Table. The User Table window appears.
3. Click Create. The User Table Create window appears. Set the following parameters according to
the explanations provided:
Parameter
Description
User Name
administrator
Authentication Protocol
MD5
password
Privacy Protocol
DES
Privacy Password
password
4. Click Set. The user is added to the User Table.

5. Open APSolute Insite.
6. From the Device menu select Add Radware Device > AppDirector. The AppDirector icon
appears in Site Explorer and/or on the map.
7. Double-click the AppDirector icon. The Connect AppDirector Device window appears.
8. Enter the Device IP Address, and select the SNMPv3 checkbox. The SNMPv3 pane appears.
9. In the User Name field, enter radware. When connecting using this user name, neither
authentication nor privacy is required.
10. Click OK. APSolute Insite is connected to the device through SNMPv3.
11. From the Device menu select Device Permissions. The Device Permissions window appears.
12. Click SNMP. The SNMP pane appears.
13. Click Access. The VACM Group Access window appears.
14. Click Add, then set the following parameters according to the explanations provided:
Parameter
Description
Group Name
admin
Security Model
USM
Security Level
AuthPrivate
Read View Name
iso
Write View Name
iso
Notify View Name
iso
15. Click OK twice.

16. To associate the user administrator with the admin group, in the SNMP pane, click Add. The
VACM - Edit Security To Group window appears.
41

17. Set the following parameters according to the values provided:
Parameter
Description
Security Model
USM
Security Name
administrator
Group Name
admin
18. Click OK twice to close all the windows.

19. Reconnect to the device using SNMPv3, User Name "admin," and Password "password," both for
authentication and privacy protocols.
a.
b.
c.
To create additional users with the same access rights, open the Users window, and add a
new user. The new user can be cloned from the existing logged in user or from a different
user (see Defining SNMP Users, page 36).
To associate a new user with a group, from the SNMP window, click Add and associate the
new user with a group.
To restrict SNMPv1 and SNMPv2 access to the device, remove the "public" community entry
from the Community window (see page 39).
Example Sending Secured SNMP Traps to Specific Users

The following example shows how to configure a Radware device to send SNMP traps using a secure
channel over SNMPv3. This example is based on the example. See page 40.
To configure Sending Secure SNMP traps to Specific Users

1.
From the main APSolute Insite window, select Device >Add Radware Device > AppDirector.
The AppDirector icon appears in Site Explorer and/or on the map (depending on the view
selected).
2.
Double-click the AppDirector device icon. The Connect AppDirector Device window appears.
3.
Enter the Device IP Address, and select the SNMPv3 checkbox. The SNMPv3 pane appears.
4.
In the User Name text box, enter administrator.
5.
Click OK. The device is connected using SNMPv3.
6.
From the Device menu, select Device Permissions. The Device Permissions window appears.
7.
Click SNMP. The SNMP pane appears containing the following configuration options: Targets,
Views, Users, Community, Access.
8.
Click Target. The Target Address window appears.
9.
Click Parameters. The Target Parameters window appears.
10. Click Add. The Edit Target parameters window appears.

42
Parameter
Description
Name
Secure Traps
Message Processing
Model
SNMP Ver 3
Security Model
User Based

Parameter
Description
Security Name
Administrator
Security Level
Auth Private
12. Click OK twice to return to the Target Address window.

13. Click Add, and set the following parameters according to values provided:
Parameter
Description
Name
Admins_NMS
Target Address
10.204.100.18
Target Port
162
Target Mask
A subnet mask of the management station.
Tag List
V3Traps
Parameters
Secure Traps
14. Click OK to apply the setup, and OK again to close all windows.
15. From the Options menu select Events & Traps. The Events & Traps window appears.
SNMP Groups Table

You can associate users with groups in the Groups Table window. Access rights are defined for
groups of users.
To configure the SNMP Groups Table

1. From the Security menu, select SNMP > Groups Table. The SNMP Groups Table window
appears.
2. Click Create. The SNMP Groups Table Create window appears.
Parameter
Description
Security Model
Select SNMP version for association with this group.

Values: SNMPv1, User Based (SNMPv3).
Security Name
Select relevant security name, (name as defined in the Users Table.)
Group Name
Select name from list of all available group names.
SNMP View Table

An SNMP view filters objects from the entire MIB and defines a subset of MIB objects. Every SNMP
access group has views for read and write access which either allow or limit that group's access to
MIB objects. If you want a group to access just a subset of MIB information, you will have to create
a new view that describes those MIB object identifiers (OIDs) that should be included or excluded.
The View Table window allows you to define these subsets of the MIB tree for use in the Access
Table. Different entries may have the same name. The union of all entries with the same name
defines the subset of the MIB tree and can be referenced in the Access Table through its name.
43

To configure the SNMP View Table

1.
From the Security menu, select SNMP > View Table. The SNMP View Table window appears.
2.
Click Create. The SNMP View Table Create window appears.
3.
Set the parameters.
Parameter
View Name
Description
Name of this entry.
The MIB view is a sub-set of MIB. You can bind a community name/
username with a MIB view when configuring an agent, to control the
MIB objects that NMS can access.
You can configure the objects in the MIB view as excluded or included;
excluded indicates that not all the nodes on the subtree are included in
the current MIB view, and included indicates that the current MIB
includes all the nodes on the subtree.
Subtree
The Object ID of a subtree of the MIB. When combined with the

corresponding instance of MASK, defines a family of view subtrees.
MIB stores data using a tree structure. A node of the tree is a managed
object and can be uniquely identified by a path starting from the root
node. The managed object system can be uniquely identified by a
string of numbers {1.3.6.1.2.1.1}. This string of numbers is the OID of
the managed object system.
A subtree can be identified by the OID of its root node. For example,
the OID of the subtree with the root node being private is the OID of
node private {1.3.6.1.4}.
Subtree Mask
A subtree OID used with a subtree mask defines a view subtree. A

subtree mask is in hexadecimal format. The mask indicates which subidentifiers of the associated subtree OID are significant to a particular
MIB view instance. After it is converted to binary bits, each bit
corresponds to a node of the OID, where:
1 means full match, that is, the OID of the MIB object to be
accessed must be identical to the subtree OID.
0 means wildcard match, that is, the OID of the MIB object to be
accessed can be different from the subtree OID.
For example, provided the subtree mask 0xDB (11011011 in binary)
and the subtree OID 1.3.6.1.6.1.2.1, their relationship is as shown
below. The view determined by them includes all the nodes under the
subtree whose OID is 1.3.*.1.6.*.2.1, where * represents any number.
Type
Defines whether object defined in entry is included/excluded in MIB

view.
Values: Included (Default) or Excluded,
4.
44

Notes:
>> If the number of bits in the subtree mask is greater than the number of nodes of the
OID, the excessive bits of the subtree mask will be ignored during subtree mask-OID
matching.
>> If the number of bits in the subtree mask is smaller than the number of nodes of the
OID, the short bits of the subtree mask will be set to 1 during subtree mask-OID
matching.
>> If no subtree mask is specified, the default subtree mask (all ones) will be used for
mask-OID matching.
Create SNMP User

You can define users that can connect to the device and store the access parameters for each SNMP
user in the User Based Security Model window.
To define a new user

1. From the Security menu select SNMP > Create SNMP User. The Create SNMP User window
appears.
2. Click Create. The User Table Create window appears.
Parameter
Description
SNMP Version
SNMPv3, SNMPv1, SNMPv2c
User/Community Name
User name or community string name.
Passwords
Use Authentication
Checkmark this box to use authentication.
Enter an authentication password.
Use Privacy
Checkmark this box to use privacy.
Privacy Password
Enter a user privacy password.
Permissions
Read
Values: ReadOnlyView/iso (default)
Write
Values: ReadOnlyView/iso/none (default)
Notify
Values: ReadOnlyView/iso/none (default)
4. Click Create User. The new SNMP user is created.
Note: The Configuration file of the device, that contains SNMPv3 users with authentication,
can only be used by the specific device that the users configured. When exporting the
configuration file to another device, passwords need to be re-entered, since passwords
(of SNMPv3 users) cannot be exported from one device to another. Therefore there must
be at least one user in the user table (to change the password) in case the configuration
file is uploaded to another device. Note that this is according to SNMPv3 RFC.
45

Version and Configuration Management

This section includes the following topics:
Upgrades, page 46
Software Versions, page 47
Configuration File Management, page 48
Licensing and Upgrading Licenses, page 53
Resetting Devices, page 57
Device Shutdown, page 57
Upgrades
You can upgrade all Radware devices to newer versions with a straightforward FLASH process.
Depending on the maintenance contract, you are either eligible for new versions with new features,
or for maintenance versions only.
Performing an AppDirector device upgrade involves two steps:
Saving the current device configuration.
Upgrading the device software.
Radware releases updated versions of AppDirector software that can be uploaded. You can upgrade
a device using one of these methods:
WBM
CLI
APSolute Insite
A device upgrade enables new features and functions without altering the existing configuration.
New software versions require a password. This can be obtained from the Radware corporate
website. You must obtain this password before you load the upgrade file onto the device. If you do
not supply the correct password during upgrade, you cannot proceed. A maintenance-only upgrade
does not require a password. The password is based on the software version file and on the Base
MAC Address of the AppDirector unit.
Notes:
>> Before upgrading, save the existing configuration file.
>> Before upgrading, refer to the appropriate Release Notes.
>> When downgrading to a software version not supporting the current device license, the
license is lost. Contact Radware for more information.
46

Software Versions
To display a list of software versions loaded on the device
In WBM, click File > Software List.
In the Command Line Interface, use the command:
system file-system software.
To change active software version
In WBM, click File > Software List. Select the inactive version (Inactive Field has value False),
and change the Active parameters to True. Click Set to record your preferences. You are
prompted to reboot the device.
In the Command Line Interface, use the command:
system file-system config act-appl set X,

where X is the application index as previously displayed.
Notes:
>> Each software version has its own configuration file
>> You can download a new software version by using WBM. For versions using the File
System, the software file is in TAR format and for previous versions, it appears in binary
(BIN) format.
Updating Device Software
To upgrade the software version

1. Download the AppDirector software update zip file from Radwares Software Status Matrix
(http://www.radware.com/content/support/software/statusmatrix/default.asp). Write down the
software version - you will need it later.
2. Unzip the file. You will see a file named: appdirector_[platform]_[major version]_[minor
version]_[bugfix version].tar. This is the software update file.
3. If you are upgrading or downgrading to a different major version, use the Password Generator
(http://www.radware.com/content/support/pwordgen/default.asp) to generate a password.
4. From browser window, enter IP address of your AppDirector. Web Based Management opens.
5. From the File menu, select Software Upgrade. The Update Device Software window appears.
6. Parameters are as follows:
Password
Software version
File
Enable New Version Checkbox
7. If you are upgrading or downgrading to a different major version, enter your case-sensitive
password in the Password field. For instructions on obtaining a password, see step 3 above.
47

8.
In the Software version field, enter the software version that you wrote down in step 1. Note:
the software version also appears in the name of the software update file; for example,
appdirector-ods1-2_00_01.tar is the file for version 2.00.01.
9.
In the File field, click Browse and navigate to the software update file that you downloaded and
unzipped. You are looking for a file named: appdirector_[platform]_[major version]_[minor
version]_[bugfix version].tar.
10. Check Enable New Version to apply the upgrade.

11. Click Set. You are prompted to reset the device.
12. In the Device menu, select Reset Device. The Reset the Device window appears.
13. Click Set to reset AppDirector.
Backup Version Update

To manually update the backup application version or install it, use the CLI command: system
file-system files copy-to-flash x, where x is the index of the new application you want to use
(existing applications and their indexes are displayed by: system file-system config act-appl
command).
Configuration File Management

The configuration file format is based on the CLI (system config format) and is the default format
for all operations. Radware recommends saving existing configurations on each Radware device. If a
change to the configuration results in problems, administrators can restore a previous configuration.
Files are stored locally on the desktop or laptop.
Caution: Configuration changes cannot be performed until any pending reboot has completed.
The configuration file can be received from the device in the following ways:
1.
Displayed within the CLI (Console, Telnet, SSH) by entering:

system config immediate
2.
Copying the output to a text editor.
3.
Downloaded from the device using WBM or the terminal command:
system config download [File] [Server IP].

The configuration file output in the CLI or within the configuration file itself (downloaded from the
device) is divided into two sections:
Note: Commands which require rebooting the device, including BWM Application Classification
Mode, Application Security status etc. Copying and pasting a command from this section
takes effect only after the device is rebooted.
48

Commands not requiring device reboot

Copying and pasting a command takes effect immediately after the paste.Commands are printed
within each section, in the order of implementation; for example, server related commands are
printed after the farm related commands. At the end of the file, the device prints the signature of
the configuration file. This is used to verify the authenticity of the file and that it has not been
corrupted. The signature is validated each time the configuration file is uploaded to the device, and
if the validity check fails, then the device accepts the configuration, but a notification is sent to the
user that the configuration file has been tampered with and there is no guarantee that it works.
Note: The signature is validated only when sending a complete configuration to the device in
Replace mode.
Device Configuration Update

The configuration can be updated in one of the following methods:
1. Append - You can add parts of a configuration into a device. For example, you can add a specific
farm and its servers into an AppDirector's configuration. It also allows simple multi device
management, pushing the same BWM Policy to multiple devices at once. It is configured:
a.
By pasting the configuration into the terminal using the command
system config paste start

Once all the data is pasted, the following command must be issued
system config paste stop

b.
c.
By uploading the file using WBM and selecting the option - Append Commands to
Configuration File in the Upload Configuration File to Device window.
By performing the terminal command
system config upload append

Using the Append method you can only append commands which do not require rebooting
the device for the commands to take effect. If a command which requires reboot is pasted/
uploaded to the device using the Append method, then the command is not implemented.
To log the command outputs in the terminal, enter
system config upload append

with option -v. The output to the terminal displays each command and its result.
2. Append and Reboot - You can add parts of a configuration into a device. The difference
between this option and the Append option is that it also supports commands that require
rebooting the device for the commands to take effect.
The flow of commands using the Append and Reboot option is as follows:
All commands requiring the reboot of the device are implemented first.
The device is rebooted.
All commands not requiring reboot of the device are implemented.
The Append and Reboot method is supported using the following options:
a.
By performing the terminal command:
system config upload append-reboot

b.
By uploading the file using WBM and selecting the option - Append Commands to
Configuration File with Reboot in the Upload Configuration File to Device window.
To log the command outputs in the terminal, enter
system config upload append-reboot

with option -v. The output to the terminal displays each command and its result.
49

3.
Replace - You can replace the complete configuration file with a new configuration file. This
requires rebooting the device. You can upload the configuration file to the device as follows:
a.
By pasting the configuration into the terminal using the command:
system config paste-replace

Once all the data is pasted CTRL+C must be performed.
b.
By performing the terminal command
system config upload replace

c.
By uploading the file using WBM and selecting the option - Replace Configuration File in
the Upload Configuration File to Device window. When using this option, you can upload a
configuration file to the device in CLI format.
Note: system config upload replace does not support configuration from previous
versions.
Automatic Rollback to Last Known Good Configuration

The device also supports an automatic rollback to the last good known configuration (in case of a
fatal error after a configuration upload). The rollback is performed automatically if a problem occurs
during the reboot and initialization process performed after a configuration file is sent to the device
in Replace mode. Once the rollback occurs, the device reboots (again) and loads the configuration
which existed prior to the 1st reboot.
Configuration Management Log File

The Configuration Management log file logs every error printout which occurs when uploading text
files. The log file is accessed via the following management options:
1.
WBM - The log file is managed via the following menus:
The user can clear the file via the following menu:
File > Configuration > Log File > Clear.
The user can download the file via the following menu:
File > Configuration > Log File > Download.
The user can display the file via the following menu:
File > Configuration > Log File > Show.
2.
CLI - The following command is used to view the Configuration Management logfile:
system config logfile <get/reset>.
Note:
>> If there is no room on the device's compact flash to store the file, the device does not
log any information within the log file.
>> Each event is also sent via Email, Syslog, SNMP traps and console trap.
50

Uploading a Configuration File
To upload a configuration file to the device

1. From the File menu, select Configuration File > Send To Device. The Upload Configuration
File to Device window appears.
2. Select the Upload mode from one of the following:
Parameter
Description
Replace
Configuration File
Existing configuration file is replaced by the uploaded one, and the

device is rebooted.
Append Commands Used when a new configuration file is a text file containing CLI
to Configuration File configuration commands and you want to execute only those commands.
The CLI commands are appended to the device's existing configuration
file and executed.
Append Commands Similar to above except that the device is rebooted after the commands
to Configuration File have been appended to the configuration file.
with Reboot
3. Enter the name of the file you want to send. Alternatively, click Browse to search the directory
tree for the file.
4. Click Set. The file is uploaded to the device.
Downloading a Configuration File (Saving and Restoring)

This section discusses the saving and restoring of Configuration Files by downloading.
To download the configuration file from the device

1. From the File menu, select Configuration > Receive from Device. The Download
Configuration File window appears.
3. In the Configuration Type field, select one of the following:
Parameter
Description
Regular
Download the device configuration
Peer (Active-Active)
Download configuration created for peer device synchronization in an

Active-Active environment. This configuration must be uploaded to the
peer device.
To enable this device to create such a configuration you need to provide
the IP for the same interface in the peer device for each IP Interface that
you configured on this device,.
Note: Configuration file for Active-Active synchronization is supported
for proprietary redundancy only.
51

Parameter
Description
Backup (ActiveBackup)
Download configuration created for backup device synchronization in an

Active-Backup environment. This configuration must be then uploaded to
the backup device.
To enable this device to create such a configuration you need to provide
the IP for the same interface in the peer device for each IP Interface that
you configured on this device.
4.
Mark the checkbox if you want to include Private Keys.
5.
Click Set. The file is downloaded to the device
Log Files
A server log is a log file (or several files) automatically created and maintained by a server of
activity performed by it.
A typical example is a web server log which maintains a history of page requests. More recent
entries are appended to the end of the file. Information about the request, including client IP
address, request date/time, page requested, HTTP code, bytes served, user agent, and referer are
added. These data can be combined into a single file, or separated into distinct logs, such as an
access log, error log, or referer log. However, server logs do not collect user-specific information.
These files are usually not accessible to general Internet users, only to the webmaster or other
administrative person.
Show Log File

The Configuration Error Log window allows you to view the configuration errors. The report of
configuration errors presented in this log file is automatically generated by the device.
To view the Log File

From the File menu, select Configuration > LogFile > Show. The Configuration Error Log window
appears displaying the configuration errors.
Logfile Clear
The Clear Error Log window allows you to clear data contained in the configuration log file.
To clear the Error Log

1.
From the File menu, select Logfile > Clear. The Clear Error Log window appears.
2.
Click Set. The log file is cleared.
Logfile Download
The Download Error Log window allows you to download the log file that contains configuration
errors. Once the file is downloaded, you can view it.
52

To download the Error Log

1. From the File menu, select Logfile > Download. The Download Error Log window appears.
2. To download the latest error log file, click Set. The file is downloaded and now you can view it.
Licensing and Upgrading Licenses

You can upgrade the software capabilities of AppDirector via the licensing procedure; for example,
adding BWM and IPS support, (when Acceleration Application is disabled).
To change licenses, you need to insert a new license code. The license provided to you, is a one-time
license. Once this is changed, the old license code cannot be re-used. For example, if a license that
includes BWM and IPS activation keys was given to you on a trial basis but not purchased, Radware
will provide you with another license, but without these activation keys. The old license cannot be
reused.
Each license is based on the devices MAC address and on a license ID that is changed every time a
new license is inserted. To obtain a license upgrade, you need to send the MAC address and the
current license ID of the device. To perform a license downgrade, you have to send the MAC address
and the current license ID of the device. Once you receive and insert the new license, a screen
capture of the License Upgrade window or the output of system license get CLI command
must be sent to Radware to prove that you are using the new license. Radware ensures that the old
license cannot be reused. The following procedures enable you to upgrade your software and
throughput licenses using WBM and the Command Line Interface (CLI).
Note: For users of Radwares APSolute Insite, you can also upgrade your AppDirector device
licence. For further details, see the APSolute Insite User Guide.
Upgrading Licenses Using WBM

You can upgrade the software capabilities of AppDirector Director via the licensing procedure and
increasing product capacity (throughput). For more information about obtaining licenses, please
contact Radware Technical Support. To change licenses, you need to insert a new license code. The
license provided to you, is a one-time license. Once this is changed, the old license code cannot be
re-used.
Each license is based on the devices MAC address and on a license ID that is changed every time a
new license is inserted. To obtain a license upgrade, you need to send the MAC address and the
current license ID of the device. To perform a license downgrade, you have to send the MAC address
and the current license ID of the device. Once you receive and insert the new license, a screen
capture of the License Upgrade window or the output of system license get CLI command must be
sent to Radware to prove that you are using the new license. Radware then ensures that the old
license cannot be reused.
The following procedure enables you to upgrade your license using WBM.
53

To upgrade a license
1.
From the Device menu, select License Upgrade. The License Upgrade window appears.
2.
Set the configurable parameters.
Parameter
Description
Base MAC Address
The MAC address of the first port on the device.
License ID
Reports the device software license ID and must be provided to the

Radware ordering department when a new license is required.
Insert your License

Code
The device software license allows you to activate advanced software

functionality.
Throughput License ID Manages the device throughput license ID and must be provided to the
Radware ordering department when a new throughput license is
required.
Insert your
Throughput License
Code
Manages the device throughput level license.
SSL CPS License ID
Sets or displays AppDirector's SSL Connections Per Second license as

follows:
appdirector-ssl-500
appdirector-ssl-2000
appdirector-ssl-unlimited
Insert your SSL CPS

License Code
54
Manages the device SSL CPS license ID and must be provided to

Radware ordering department when a new throughput license is
required.

Parameter
Description
Compression on
server's side License
ID
Sets or displays AppDirector's Compression on the server's side license

as follows:
appdirector-compression-100
appdirector-compression-unlimited
Insert your
Compression on
server's side License
Code
Manages the device Compression on server's side license ID and must

be provided to Radware ordering department when a new throughput
license is required.
3. Enter your new license code, located on your CD case (or downloaded from www.radware.com),
in the License Code field.
Note: The license code is case sensitive.

4. Enter your new License ID in the License ID field.
Note: The license ID is case sensitive.

5. Click Set to perform the reset. The reset may take a few minutes. A success message is
displayed on completion.
Upgrading Licenses Using the CLI

You can upgrade your software and hardware licenses using the Command Line Interface (CLI).
To upgrade a software license using the CLI

1. In the CLI, type system license.
2. Press Enter. The current license code is displayed.
3. Type system license set <new license code>.
4. Click Enter. A license updated message is displayed in the command line.
Note: To implement the upgrade, the device must be reset.

5. Type reboot to reset the device, and then type yes to confirm the reset.
55

To upgrade a hardware license using the CLI

1.
In the CLI, type system hw-license.
2.
Click Enter. The current license code is displayed.
3.
Type system hw-license.
4.
Click Enter. A message is displayed in the command line indicating the license has been
updated.
Note: To upgrade, you must be using Port =10G. The device must be reset.
5.
Type reboot to reset the device, and then type yes to confirm the reset.
Managed Devices
When in Acceleration disabled mode, and using AppXcel devices managed by AppDirector with TCP
splitting, the configuration must be configured in the Managed Devices Table. AppDirector opens a
SSH/Telnet connection to the management IP of each AppXcel configured in its Managed Devices
Table and sends it relevant information regrading the availability and load of backend servers.
To configure AppXcels managed by the AppDirector device

1.
From the Device menu, select Manage Devices. The Manage Devices Table window appears.
2.
Set the parameters.
Parameter
Description
Device Name
Name of the managed AppXcel device.
Description
Description of the managed AppXcel device.
Management IP
IP address by which the managed devices can be accessed.
Management
Application
The application that is used to manage the remote device.

SSH (default)
Telnet
Management Port
The layer 4 destination port of the application that is used to manage

the AppXcel device.
Default: 22
Admin Status
Controls the status of the managed device.

Disable: The connection is closed.
Enable: The connection remains open.
Username
56
User name to be used for authentication during communication with

the managed device.

Parameter
Description
Password
Password used for authentication during communication with the

managed device.
Connection Status
(Read Only)
Displays the status of the connection to the managed devices as

follows:
Connecting - Trying to establish an SSH/Telnet connection with
AppXcel.
Open - Connection is established but managed device is not in
sync yet.
In Sync - Managed device is in sync.
Terminating - Connection was closed by AppXcel.
Closed - Connection is closed.
#Sent Messages
(Read Only)
Counts the number of messages sent from AppDirector to the managed

device since the connection was established. Displays 0 when a
connection is not present.
#Received Messages
(Read Only)
Counts the number of messages received by AppDirector from the

managed device since the connection was established. Displays 0 when
a connection is not present.
3. Click Set. Your preferences are recorded.
Resetting Devices
You may have made various changes to configurations and settings and need to reset the device for
these changes to take effect. You can reboot the device at any given time.
To reset an AppDirector device

1. In the Device window, select Reset Device.
2. The device is reset.
Device Shutdown
If you need to shutdown the device (assuming you have the required administrator privileges), use
this procedure.
To shutdown the device

1. Click Shutdown. The following user dialog message appears.
2. Click OK to confirm, the device begins shutdown.
57

Tuning AppDirector
This section describes interfaces and methods for tuning AppDirector. Use Tuning to determine the
maximum number of entries allowed in the various tables listed. This section includes:
Device Tuning, page 58
Device Global Parameters, page 61
Main Device Tuning Parameters, page 62
Client Table Settings Tuning, page 65
DNS Settings Tuning, page 65
NAT Settings Tuning, page 65
Session Table Tuning, page 67
Tuning Memory Check, page 67
Tuning Statistics, page 68
Bandwidth Management Tuning (ODS Devices Only), page 68
Classifier Tuning, page 69
SYN Protection Tuning, page 71
Application Security Tuning, page 72
Behavioral DoS Tuning Parameters, page 73
Device Tuning
The Device Tuning window allows you to tune the AppDirector device. The values in the fields are
synchronized and any changes are implemented after the device reset.
To tune the AppDirector device tables

1.
From the Services menu, select Tuning > Device. The Device Tuning window appears.
2.
Set the parameters.
58
Parameter
Description
Bridge Forwarding Table

(Read Only)
Limit on number of local station addresses. Read-only

parameter.

(After Reset)
After reset, the limit on number of local station addresses.
IP Forwarding Table
(Read Only)
Displays limit on the number of IP destinations.
IP Forwarding Table (After

Reset)
After reset, displays the limit on the number of IP destinations.
ARP Forwarding Table (Read

Only)
Contains Destination MAC Address per Destination IP.
ARP Forwarding Table (After

Reset)
After reset, the limit on the number of entries in the ARP table.
Client Table (Read Only)
Client Table (After Reset)
After reset, the limit on the number of entries in the client table.
Hosts Table (Read Only)
Limited number of entries for the Hosts Table.

Parameter
Description
Hosts Table (After Reset)
After reset, the limited number of entries for the Hosts Table.
Request Table (Read Only)
Limit on number of entries in the Request Table, used by all

delayed binding based mechanisms, for example, SSL ID
tracking, Layer 4 Policies etc.
Request Table (After Reset)
After reset, the limit on number of entries in the Request Table,

used by all delayed binding based mechanisms, for example,
SSL ID tracking, Layer 4 Policies etc.
Routing Table (Read Only)
Limit on the number of entries in the Routing Table.
Routing Table (After Reset)
Limit on the number of entries in the Routing Table after reset.
Client NAT Addresses (Read

Only)
Specifies the number of IP addresses to be used for NAT. The

default is 0, the maximum value is 128.
Client NAT Addresses (After

Reset)
After reset, specifies the number of IP addresses to be used for

NAT. The default is 0, the maximum value is 128.
Client NAT Ports Per Address

(Read Only)
Specifies number of ports to be used with each IP address, the

maximum value is 63K.
Note: Before enabling Client NAT this must be set to value > 0.
Client NAT Ports Per Address

(After Reset)
After reset, specifies the number of ports to be used with each

IP address, the maximum value is 63K.
Note: Before enabling Client NAT this must be set to value > 0.
Outbound NAT Addresses

(Read Only)
Limited number of entries in this table.

(After Reset)
Limited number of entries in this table, after reset.
Outbound NAT Ports Per

Address (Read Only)
Outbound NAT Ports Per

Address (After Reset)
Outbound NAT Intercept

Ranges (Read Only)
Outbound NAT Intercept

Ranges (After Reset)
Proximity Subnets (Read

Only)
Proximity Subnets (After

Reset)
Session IDs (Read Only)
Specifies size of table in which association of Session ID values

to servers is kept. Default table size is 16,384, maximum is
256,000.
Session IDs (After Reset)
Specifies size of table in which association of Session ID values

to servers is kept, after reset. Default table size is 16,384,
maximum is 256,000.
Layer3 Client Table After

Reset (Read Only)
Size of Layer 3 Client Table can be configured and defined as

percent of the Client Table size, default is 20%
Layer3 Client Table After

Reset [% of the client table]
Size of Layer 3 Client Table after reset can be configured and

defined as a percent of the Client Table size, default is 20%.
Network Segments (Read

Only)
Displays the number of Network Segments supported when the

device uses the segmentation feature.
59

Parameter
Description
Network Segments After

Reset
Displays the number of Network Segments after reset supported

when the device uses the segmentation feature.
Layer 4 Policies (Read Only)
Number of Layer 4 policies that can be defined on the device.
Layer 4 Policies After Reset
Number of Layer 4 policies that can be defined on the device

after reset.
Static DNS Persistency

Entries (Read Only)
Displays the number of DNS entries used in static DNS

persistency.

Entries After Reset
Displays the number of DNS entries used in static DNS

persistency after reset.
Dynamic DNS Persistency

Entries (Read Only)
Displays the number of DNS entries used in dynamic DNS

persistency.

Entries After Reset
Displays the number of DNS entries used in dynamic DNS

persistency after reset.
Session Table (Read Only)
Displays the number of entries the session table can hold.
Session Table After Reset
Displays the number of entries the session the table can hold
after a reset.
Session Passive Protocols

Table (Read Only)
Displays the number of session passive protocols entered in the

table.
Session Passive Protocols

Table After Reset
Displays the number of session passive protocols entered in the

table after reset.
Session Resets Table (Read

Only)
Current amount of sessions that the device tracks to send

RESET in case "Send Rest To Server" is enabled in the Session
Table.
Session Resets Table After

Reset
New amount of sessions that device tracks to send RESET in

case "Send Rest To Server" is enabled in the Session Table after
reset.
Acceleration Engine RAM
Percentage For Cache
Percentage of Accel-engine RAM allocated for cache. Also see

Caching Policies, page 220.
Default: 20

Percentage For Cache After
Change
3.
Percentage of Accel-engine RAM allocated for cache after

change.
Also see Caching Policies, page 220.
You can determine the maximum number of entries allowed in the various tables in the following
Device Tuning Table tabs:
AppDirector
BWM
Security Settings
60

Note: Most of the parameters in the BWM and Security Settings tabs described above only
exist in devices with BWM and IPS activated.
You can also define the security parameters for your previously defined security policy. The values in
the fields are synchronized, and any changes are implemented after the device is reset.
Caution: Device Tuning should only be performed after consulting Radware Technical
Support.
Device Global Parameters

This feature defines the Hardware version of the product.
To view Device Global Parameters

1. In the Device menu, select Device Global Parameters. The Device Global Parameters window
appears.
Parameter
Description
Description (Read
Only)
A textual description of the entity.
Name
Administratively-assigned name for this managed AppDirector device/

node.
This value includes the full name and version identification of the system's
hardware type, software operating-system, and networking software.
By convention, this is the node's fully-qualified domain name. If the name

is unknown, the value is the zero-length string. This value is optional.
Location
Physical location of this AppDirector device/node (e.g., telephone closet,

3rd floor). Setting this value is optional.
System Up Time
(Read Only)
Reports the time elapsed since the device last reboot.
Contact
The contact information of the person responsible for AppDirector. Setting

this value is optional.
Bootp Server
Address
Sets the IP address of the BootP server.
Bootp Threshold
Sets the BootP threshold. (The number of seconds that the device will
wait before relaying requests to the BootP server).
The device forwards BootP requests to the BootP server and acts as a
Bootp relay.
This delay allows local BootP Servers to answer first.

Serial Number
(Read Only)
Sets or returns the device serial number.
Software Version
(Read Only)
Reports the device's software version, e.g. 2.10.00
61

3.
Parameter
Description
Hardware Version
(Read Only)
Reports the devices hardware version, e.g. 3.1.
Main Device Tuning Parameters

Main device tuning parameters are described here:
Parameter
Description

(Read Only)
Used when regular VLAN is defined. AppDirector learns the MAC

addresses of frames arriving from each physical interface, and
maintains a list of MAC addresses per interface. The table that stores
this list is the Bridge Forwarding table.
IP Forwarding Table
(Read Only)
Contains the destination MAC address and Port per Destination IP

address. A MAC address is searched in this table before searched in the
ARP table. A larger tuning value implies more different IP addresses
can be recorded in this table, improving performance.
ARP Forwarding Table

(Read Only)
Routing Table
(Read Only)
Stores information about destinations and how they can be reached.

By default, all networks directly attached to AppDirector are registered
in this table. Other entries can either be statically configured or
dynamically created through the routing protocol.
Hosts Table
(Read Only)
Defines the relationship between host names and Layer 4 Policy entry.
Request Table
(Read Only)
Contains Layer 7 information saved during delayed binding.
Client NAT Addresses

(Read Only)
Specifies NAT Addresses used to hide IP addresses of clients accessing

this farm. For each farm you can select a single NAT Addresses range.
Note: When no Client NAT Address Range is selected for a farm,
AppDirector uses any configured Client NAT Address Ranges
when performing Client NAT for servers in this farm.
Client NAT Ports Per

Address (Read Only)
Specifies number of ports used with each IP address.
Proximity Subnets (Read

Only)
Defines limit on the number of Proximity subnets.
Session IDs (Read Only)
Using Session ID Persistency, a server's reply contains a Session ID.

This is saved in this table.
Network Segments (Read

Only)
Segments supported when device uses segmentation.
Layer 4 Policies (Read

Only)
Maximum number of Layer 4 policies defined on device.
Session Resets Table

(Read Only)
Current amount of sessions that the device tracks to send RESET in

case "Send Rest To Server" is enabled in the Session Table.
62
Note: Before enabling Client NAT this parameter must be set to a

value higher than zero.

Parameter
Description

Percentage For Cache
(Read Only)
Percentage of Accel-engine RAM allocated for cache. Also see Caching

Policies, page 220.
SNMP Communities
The SNMP community table allows backwards compatibility with

SNMPv1 and SNMPv2. The Community Table maps community strings
to users. Once a user is connected to Radware device with SNMPv1 or
SNMPv2, the device checks the Community String sent in the SNMP
packet. Based on the Community String, the device maps the
Community Sting to a pre-defined user, which belongs to a group, with
certain access rights. Therefore, when working with SNMPv1 or
SNMPv2, users, groups, and access must be defined as well.
Logical Servers
AppDirector works with server farms rather than with individual

servers. An AppDirector farm is a group of networked servers that
provide the same service. Utilizing multiple servers organized in a farm
accelerates the service response time and improves overall
performance including:
Default: 20
maximum number of application server connections.

Weight of the server in a farm
the Response Threshold parameter defines the number of
milliseconds in which the server may reply to the GET command.
maximum amount of bandwidth in Kbps allowed for this
application server.
Physical Servers
You can configure the physical servers you have included in your server
farm including:
maximum number of application server connections.
maximum number of frames per second dispatched to the server
since the last reset
number of currently active users attached to server
number of frames per second dispatched to server
number of frames sent to server
Servers per Farm
Average of servers per farm.
Farms
Default number of farms configurable on one device.
NHRs
A Next Hop Router (NHR) is a network element used for outbound

traffic in AppDirector Multi Homing configurations. NAT addresses can
be associated with NHRs, similar to the way VIPs are associated with
NHRs. This provides a backup NHR for NAT Addresses, or for the
simultaneous use of two NHRs with Hashing for the outbound traffic.
VIP NHR
The VIP NHR Table enables you to associate a next hop router, that is
configured in the NHR Table, to a virtual IP address configured on the
device, for example a Server Farm.
Static Proximity Entries
Number of proximity subnets are configurable per farm. Static

Proximity is configurable through the farm parameters.
63

Bandwidth Management Settings Tuning

You can tune the Bandwidth Management Settings tables according to your needs. The following
table shows descriptions of the Bandwidth Management tables and provides their tuning
parameters.
Parameter
Description
Policy Table
Maximum number of bandwidth management policy entries in the

table. A policy classifies traffic passing through the device, and
enforces bandwidth management, and enables access control.
Network Table
Maximum number of network ranges entered in the table. A network is

a logical entity that consists of a group of IP addresses linked together
by a network IP and subnet mask or a range of IP addresses (from-to)
that is identified by a unique name.
Destination Table
Maximum number of Destination Address entries in the table. A

Destination Address can be a specific IP address, a range of IP
addresses, or an IP Subnet address. Each address in the table contains
an optimized list of policies. This improves classification time for the
specific Destination addresses. The number of entries implies the
number of concurrent Destinations which the device supports.
Regular Service Table
Maximum number of regular (basic) service entries in the table. A

regular service is a set of traffic parameters that define a packet.
Advanced Service Table
Maximum number of advanced service entries in the table. An

advanced class is a group of regular classes with a logical AND relation
between them.
Grouped Service Table
Maximum number of service group entries in table. A grouped service

is a group of regular services and/or grouped filters with logical OR
relation between them.
Content Table
The device uses content searches in the Layer 7 policies that can be
defined for BWM.
Discreet IP Address Per

Network
Maximum number of individual IP addresses in a single dynamic

network. Relevant for CID only.
Subnets Per Network
Maximum number of subnets sharing the same network name in a

single network entry.
MAC Groups
Maximum number of MAC group entries in the table. A MAC group

classifies applications and protocols present in the traffic, and sent to or
from a transparent network device like a firewall or router.
BW Per Traffic Flow
Maximum number of traffic flows for a single policy. Used only for
bandwidth management per traffic flow.
Protocol Discovery
Reports
Maximum number of ports to be monitored by the Protocol Discovery

module.
Application Port Group
Group of Layer 4 ports for UDP and TCP traffic only. Each group is
identified by its unique name. Each group name can be associated with
a number of entries in the Application Port Groups table.
64

Client Table Settings Tuning

You can tune the Client Table Settings according to your needs. This table shows descriptions of the
Client Tables and their tuning parameters.
Parameter
Description
Client Table
Keeps track of which clients are connected to which servers for each of
the Local Farms.
Layer 3 Client Table
Contains information about the server selected for each client (Source IP
address) in each farm, defined as a percent of the Client Table size. While
setting Layer 3 Client Table entries, note the number of entries in the
Client Table opened for each new session. For example, if for each
session there are 5 Client Table entries, set the size of the table to 20%.
DNS Settings Tuning

You can tune the DNS Settings according to your needs. Descriptions of the DNS Settings Tables and
their tuning parameters. are shown here.
Parameter
Description
Static DNS Table
Maximum number of DNS entries used in static DNS Persistency. See

Static DNS Persistency, page 317.
Dynamic DNS Table
Maximum number of DNS entries used in dynamic DNS Persistency. See

DNS Persistency, page 315.
NAT Settings Tuning

You can tune the NAT Settings according to your needs. This table shows descriptions of the NAT
Settings Tables and provides their tuning parameters.
Parameter
Description
NAT Ports Table
Specifies number of ports used with each IP address. AppDirector uses

port range starting at 1024 that ends according to NAT Ports per Address
value.
NAT Addresses Table
Specifies number of IP addresses used for NAT.
Outbound NAT
Addresses
Note: Defines number of IP addresses to be used by Outbound NAT.

Before enabling Outbound NAT, this must be set to > 0.
Outbound NAT Ports per Defines number of ports used with each NAT IP address.
Address
Note: Before enabling Outbound NAT, this parameter must be set to a
value higher than zero.
Outbound NAT
Intercept Addresses
Defines number of IP ranges intercepted and NATed by Outbound NAT.

Note: Before enabling Outbound NAT, this must be set to > 0.
65

Security Tuning
Security tables store information about sessions passing through the device and their sizes, which
are correlated to the number of sessions. Some of the tables store Layer 3 information for every
Source-Destination address pair of traffic going through the device. These pairs require an entry for
each combination. Some of the tables need to keep information about Layer-4 sessions, which
means that every combination of Source Address, Source Port, Destination Address and Destination
Port requires its own entry in the table.
Note: Layer-4 tables are usually larger than Layer-3 tables. For example, a typical TCP client,
using HTTP, opens several TCP sessions to the same destination address.
Each Security table has its own Free-Up process, which is responsible for clearing the tables of old
entries that are no longer required, and ensuring that all detected attacks are reported and logged
properly. The Free-Up Frequency for each table determines how often the device clears unnecessary
entries from the table and stores information about newly detected security events in a dedicated
internal alerts buffer. The alerts are then distributed to the logfile, SNMP management station, and
Syslog server, as required by the configuration. The alerts buffer ensures that the device is not
overloaded with alerts distribution.
You can tune the Security tables according to your needs. Descriptions of the Security tables and
their tuning parameters are shown here.
Parameter
Description
Log File Polling Time

(ms)
Configures how often alerts are read from the internal alerts buffer
and sent to the Log File. If the device is busy, change this value to
1,000 ms. to ensure that all alerts are logged on time.
Target Table
Contains an attack detection system that is based on the Destination

addresses of the incoming traffic. If number of packets sent to same
destination is above the predefined limit, it is identified as an attack.
The Target Table tuning parameters define how often per session to
check the Destination Address.
Source Table
Contains attack detection system based on source addresses of the

incoming traffic. If the number of packets sent from the same source
is above the predefined limit, it is identified as an attack. The Source
Table parameters define how often per session to check the source
address.
Source & Target Table
Contains an attack detection system that is based on the Source and

Destination addresses of the incoming traffic. Each entry in this table
contains Source and Destination addresses. If the number of packets
sent from the same Source to the same Destination is above the
predefined limit, it is identified as an attack. The Source & Target
Table tuning parameters define how often per session to check the
source address.
Security Tracking Tables

Free-Up Frequency (ms)
Determines how often device clears unnecessary entries from the

table, and stores information about newly detected security events.
DHCP Discover
Contains an attack detection system based on counting the IP

requests for each MAC address. Requests are made using the
Dynamic Host Configuration Protocol. When the number of IP
requests for a particular MAC address is above the predefined limit, it
is identified as an attack. The DHCP Discover tuning parameters
determines how many MAC addresses to check.
66

Parameter
Description
IP Reassembly buffers
pool size (MB)
Defines memory size allocated for the IP reassembly process. To

perform reassembly for more packets, you need to increase the
memory size.
Session Table Tuning

This shows Session Table tuning parameters.
Parameter
Description
Session Table Size
Keeps track of sessions.
Session Passive
Protocol
Records passive protocol port commands, so that all related sessions can
be linked together.
Tuning Memory Check

AppDirector pre-checks the feasibility of values in the configured tables. This eliminates the chance
of causing a memory allocation problem. Each time you update a value for a certain table, you can
check whether there is enough free memory for the requested value. However, following tuning
changes, you can perform a manual check using WBM or CLI.
Caution: Perform tuning only after consulting Radware Technical Support.
Note: In CLI, use the command: system tune test-after-reset-values.
To perform the device tuning memory check

1. Perform Device Tuning.
2. From the Services menu, select Tuning > Memory Check. The Tuning Memory Check window
appears, which lists all the changes that have been made in Device Tuning windows.
3. Click Perform Test. The memory check is performed to verify whether the device contains
sufficient memory to allocate the changes. The following messages may be displayed:
a.
b.
Sufficient memory available for the pending table size updates. Reboot to update the table
sizes: Click Reboot to reboot the device and apply the changes.
# Kbytes are missing for the pending table size updates. Reduce the size of the tables using
dispensable memory to accommodate the required updates: Click tables to access the
Device Tuning windows and adjust the tables according to the amount of memory required.
67

Tuning Statistics
In the Tuning Statistics window you can view and edit the statistics tuning parameters. The changes
take effect after the reset.
To tune the Statistics

1.
From the Services menu select Tuning > Statistics. The Statistics Tuning window appears.
2.
Set the parameters.
3.
Parameter
Description
Protocol Discovery Policies
Current size of the table for Protocol Discovery Policies entries.

Read-only parameter.

After Reset
Size of table for Protocol Discovery Policies entries that you

define. Settings are applied after reset.
Protocol Discovery Report

Entries
Total number of discovered protocols that can be recorded by

the device. (Read-only).
Protocol Discovery Report

Entries After Reset
Total number of the discovered protocols that can be recorded

by the device after reset.
Bandwidth Management Tuning (ODS Devices Only)
The BWM Tuning window allows you to tune and view the Bandwidth Management tables.
To tune Bandwidth Management tables

1.
From the Services menu, select Tuning > BWM. The BWM Tuning window appears.
2.
Set the parameters
68
Parameter
Description
Policy Table
Displays number of policy entries in the table.
Policy Table (After Reset)
Displays number of policy entries in the table after reset.

BW per Traffic Flow
sessions tracking
Number of traffic flows for which the device can provide bandwidth
or limit the number of sessions.
Maximum value: 100,000
BW per Traffic Flow

sessions tracking (After
Reset)
Number of traffic flows for which the device can provide bandwidth
or limit the number of sessions after reset.
Destination Table
Displays number of entries in the Destination table after reset.
Destination Table (After

Reset)
Displays number of entries in the Destination table.
Classifier Tuning
A Classifier packet first flows into the system through the classifier. Its the classifiers duty to decide
what to do with the packet. How the classifier treats packets passing through is governed by the
Bandwidth Management policy that best matches the packet and by these tuning parameters.
From the Classifier Tuning window you can view and edit the Classifier tuning parameters. The
changes take effect after the reset.
To tune AppDirector Classifier tables

1. From the Services menu, select Tuning > Classifiers. The Classifiers Tuning window appears.
Parameter
Description
Network Table
Displays number of ranges entered in the table.

Default: 32
Network Table After Reset Displays number of ranges entered in the table after reset.
Default: 32
Discrete IP Addresses Per
Network
Displays number of entries in the table for IP addresses that are

allocated to a network.
Default: 32
Discrete IP Addresses Per

Network After Reset
Displays number of entries in the table for IP addresses allocated

to a network after reset.
Default: 32
Subnets Per Network
Displays number entries in the table for network subnets.

Default: 32
Subnets Per Network After Displays number entries in table for network subnets after reset.
Reset
Default: 32
MAC groups Table
Displays number of MAC groups entries in the table.

Default: 2
MAC groups Table After

Reset
Displays number of MAC groups entries in the table after reset.

Default: 2
69

Parameter
Filter Table
Description
Displays number of basic filter entries in table.
Default: 32
Filter Table After Reset
Displays number of basic filter entries in the table after reset.

Default: 32
AND Group Table
Displays maximum number of AND group services that can be

currently configured.
Default: 16
AND Group Table After

Reset
Displays maximum number of AND group services that can be

currently configured after reset.
Default: 16
OR Group Table
Displays maximum number of OR group services that can be

currently configured.
Default: 16
OR Group Table After

Reset
Displays maximum number of OR group services that can be

currently configured after reset.
Default: 16
Application port groups
Displays number of application port group entries in the table.

Default: 32
Application port groups

After Reset
Displays number of application port group entries in the table after

reset.
Default: 32
Content Table
Displays number of content entries in the table.

Default: 512
Content Table After Reset
Displays number of content entries in the table after reset.

Default: 512
3.
70

SYN Protection Tuning

From the SYN Protection Tuning window you can view and edit the SYN protection tuning
parameters. The changes take effect after the reset.
To tune Global Security tables

1. From the Services menu, select Tuning > SYN Protection. The Syn Flood Protection Tuning
window appears.
Parameter
Description
SYN Protection Table
Stores data regarding the delayed binding process. An entry

in the table exists from the time the client starts the 3-way
handshake until the handshake is complete.
Current number of entries in SYN Protection Table.
SYN Protection Table (After

Reset)
Number of entries in SYN Protection Table after reset.
SYN Protection Requests Table
Sets number of entries in the SYN Protection requests table
SYN Protection Requests Table

After Reset
Number of entries in SYN Protection Table after reset.
SYN Protection Triggers Table
Sets number of entries in the SYN Protection triggers table,

which holds the destination IP addresses that should be
protected.
SYN Protection Triggers Table

After Reset
Number of entries in SYN Protection Triggers Table after

reset.
SYN Protection Policies Table
Sets number of entries in the SYN Protection policies table.
SYN Protection Policies Table

After Reset
Number of entries in the SYN Protection Policies Table after

reset.
ACK reflection IPs Table
Sets number of entries in the SYN ACK reflection IPs table.
ACK reflection IPs Table After

Reset
Number of entries in the ACK reflection IPs Table after reset.
SYN Protection Attack Detection Sets number of entries for counting new TCP sessions for
Entries
detecting syn attacks and creating triggers.
SYN Protection Attack Detection Number of entries in the SYN Flood Attack Detection Entries
Entries After Reset
after reset.
SYN Statistics Entries
Sets number of entries in the SYN protection statistics table.
SYN Statistics Entries After

Reset
Number of entries in the SYN Flood Statistics Entries after

reset.
71

Application Security Tuning

From the Application Security Tuning Parameters window you can view and edit the application
security tuning parameters. The changes take effect after device reset.
To tune AppDirector Application Security tables

1.
From the Services menu, select Tuning > Security > Application Security. The Application
Security Tuning window appears.
2.
Set the parameters.
Parameter
Description
Source Table
The current number of entries in the Source Table that contains

attacks detection mechanism, which is based on the source addresses
of the incoming traffic. If the number of packets sent from the same
source is above the predefined limit, this is identified as an attack.
The Source Table tuning parameter defines in how many sessions to
check the source address.
Source Table After

Reset
The number of entries in the Source Table after reset.
Target Table
Represents the current size of the table for destination entries. This
table contains attacks detection mechanism, which is based on the
destination addresses of the incoming traffic. If the number of packets
sent to the same destination is above the predefined limit, this is
identified as an attack. The Target Table tuning parameter defines in
how many sessions to check the destination address.
Target Table After

Reset
The size of the table for destination entries that you define. The
settings are applied after reset.
Represents the current size of the table for both source and
destination entries, which are counted as one.

After Reset
The size of the table for both source and destination entries that you
define. The settings are applied after reset.
DHCP Table
The current number of entries in the DHCP Table that contains attacks
detection mechanism based on counting of IP requests for each MAC
address. The requests are made using the Dynamic Host
Configuration Protocol. When the number of IP requests for a
particular MAC address is above the predefined limit, an attack is
identified. The DHCP Discover tuning parameter determines for how
many MAC addresses to check the number of IP requests.
DHCP Table After Reset The number of entries in the DHCP Table after reset.
Maximal number of
Maximum number of user defined groups that can be defined on the
groups to be defined by device.
user
Maximal number of
groups to be defined by device after reset.
user after reset
72

Parameter
Description
Maximal number of
attacks to be defined
by user
Maximum number of user defined attacks that can be defined on the

device.
Maximal number of
by user after reset

device after reset.
pool size [MB]
The current allotted memory, in MB, of the IP Reassembly buffers

pool.
pool size after reset
[MB]
The allotted memory, in MB, of the IP Reassembly buffers pool after

reset.
Maximal number of
entries in NCPF table
Maximum number of entries that can be defined in the NPCF table.
Maximal number of
after reset
Maximum number of entries that can be defined in the NPCF table

after reset.
Maximal number of
Maximum number of entries that can be defined in the Suspend table.
srcIPs in Suspend Table
Maximal number of
Maximum number of entries that can be defined in the Suspend table
srcIPs in Suspend Table after reset.
after reset
Maximal number of
Anti-Scanning IP pairs
Table
Maximum number of entries that can be defined in the Anti-Scanning

IP pairs table.
Maximal number of
Anti-Scanning IP pairs
Table after reset
Maximum number of entries that can be defined in the Anti-Scanning

IP pairs table after reset.
Behavioral DoS Tuning Parameters
Behavioral DoS Tuning Parameters enable you to set the maximal number of Behavioral DoS
policies. The default number of policies for Behavioral DoS is 10. If you wish to configure more, you
must reset the number of policies allowed.
Note: When you update a value for a Behavioral DoS, you can check whether there is enough
free memory for the requested value.
73

To set maximum number of Behavioral DoS policies

1.
From the Services menu, select Tuning > Security > Behavioral DoS. The Behavioral DoS
Tuning Parameters window appears.
2.
Set the parameters.
3.
74
Parameter
Description
Maximal number of
Behavioral DoS
policies
Maximum number of Behavioral DoS policies that can be defined on

the device.
Maximal number of
Behavioral DoS
policies after reset
Maximum number of Behavioral DoS policies that can be defined on

the device after reset.
Click Set. Your preferences are recorded.

Monitoring AppDirector
This section includes notifications features and threshold settings. It includes these topics:
Device Information, page 75
Device Monitoring, page 77
Notifications, page 77
Configuration Auditing, page 82
AppDirector Thresholds, page 83
Device Information
This feature helps you to understand the fundamentals of your installed Radware device and
accompanying software.
Note: Please quote this information when you seek assistance from Radware Technical
Support.
To view Device information

1. In the Device menu, select Device Information. The Device Information window appears.
2. View the parameters.
Parameter
Description
Name
Designated device name.
System Up Time
Reports the time elapsed since the device last reboot.
Base MAC Address
The MAC address of the first port on the device.
Type
Type of Radware device installed, for example, AppDirector with Global

with Persistency.
Platform
Type of processor/ platform for this device. For example, OnDemand

Switch 1.
Ports
Number of Ports
Quantity of ports on this device.
Ports Config
Type and configuration of ports on this device.
License Information
Throughput
Maximum accelerated throughput in Mbps (Megabits per second).
SSL CPS
Secure Socket Layer Connections per second (CPS) where acceleration

mode is used. Also listed is Peak usage (CPS).
Compression
Level of compression where acceleration mode is used. Also listed is

Peak usage (Mbps).
75

Parameter
Description
Version Information
Hardware Version
The hardware version.
Software Version
The software version of AppDirector installed, for example 2.00.
Build
Date and time stamp with the build number of the software.
Version State
State of this software version. Open/Closed.
APSolute OS
Version
Versions of Bandwidth Management and Application Security modules

for this software, for example, 10.31-03.01:2.06.08.
Network Driver
Version of network driver used.
Platform Information
RAM Size (MB)
Amount of RAM, in megabytes.
Flash Size (MB)
Size of flash (permanent) memory, in megabytes.
Hard Disk(s)
Number of hard disks configured.
Serial Number
Serial number of the device.
Date
Date logged in.
Time
Time logged in.
Active Boot
Time (in days) since active boot commenced.
Secondary Boot
Time (in days) since secondary (redundant) boot commenced.
Power Supply
Single or double and its status.
Compression Card
Status
Displays the Compression card status.
SSL Card Status
Displays the SSL Card status.
Values: In service, Not in Service.
Values: In service, Not in Service.
76
Number of Cores
Number of CPU cores on the device
Number of CPUs
Number of CPUs on the device

Device Monitoring
Device Monitoring provides an overview of the devices configuration from a single window. From the
Device Monitoring window the following information can be viewed and accessed.
To view the Device Monitoring information

1. From the Device Menu, select Device Monitoring. The Device Monitoring window appears.
Parameter
Description
Farms
A table is displayed containing the following columns:

Farm: Names of the farms configured on this device. Clicking the
Farm's name displays the Farm Table Update window which enables you
to view and update all the parameters of the selected farm.
Users (read only): Displays the amount of users connected to the
configured farms.
Servers: Displays the amount of servers and their status in the form of
the following icons:
Each icon is also a link and clicking on a specific icon displays the
relevant Application Server Table Update window for the selected
server.
Refresh Interval
[sec]
This field defines the rate at which the Device Monitoring window is
refreshed and updated.
2. To change the Refresh Rate, enter the required value in the field and click Update.
Notifications
Radware devices provide a choice of event notification methods including:
CLI Traps
Device Log
SNMP Traps
Syslog
Emails
CLI Traps
When connected to any Radware product through a serial cable, the device generates traps when
events occur. For example, if a Next Hop Router fails, AppDirector generates the following error:
10-01-2003 08:35:42 WARNING NextHopRouter 10.10.10.10 Is Not Responding to

Ping.
You can configure if traps are sent only to the serial terminal and also to SSH and Telnet clients. or if
they are not sent at all, via the CLI command:
manage terminal traps-outputs set.
77

The available values are:
normal - traps are only sent to serial terminal
on - traps are sent via all CLI access protocols (serial, Telnet, SSH)
off - no traps are sent
For console only:
manage terminal traps-outputs set normal.
Event Log
All the events are logged on the device and can be viewed.
To view the event log

1.
From the Services menu, select Logging > Event Log. The Event Log window appears showing
an Event Number and an accompanying description.
Parameter
Description
Event Number
Index of this table.
Event Description
This text will include time and severity.
2.
Click Event Number to select the event that you wish to display.
3.
To configure the number of results per page, choose from the accompanying dropdown for
50,(default), 25,10 or 100 results per page.
4.
Now, click Reset Filter. The Results per page is reset.
To clear the event log

From the Event Log window, in the Clear Event Log field, click Set. The AppDirector Event log is
cleared.
78

SysLog
Any event traps generated by AppDirector can be mirrored to a specified Syslog server, (a device
running the syslog service - syslogd). AppDirector supports sending events to up to 5 Syslog
servers.
To enable Syslog Messages

1. From the Services menu, select Logging > Syslog Reporting. The Syslog Reporting window
appears.
2. Set Syslog Operation to Enable.
3. To add a Syslog server click Create. The Syslog Reporting Create window is displayed.
Parameter
Description
Syslog Server
Address Or
Hostname
The URL/IP Address of the syslog station, the device running syslog
service.
Syslog Server
Operational Status
Enables or disables syslog message sending to remote station.
Syslog Server
Source Port
Configures the source port with which Syslog packets will be sent.
Syslog Server
Destination Port
Configures the destination port with which Syslog packets will be sent.
Syslog Facility
User-defined value is used when the device sends Syslog messages.

Values include:
Kernel Messages
UUCP
User Level Messages
Clock Daemon
Mail System
Security messages
System Daemons
FTP Daemon
Authorization Messages
NTP Daemon
Syslogd Messages
Log Audit
Line Printer Subsystem
Log Alert
Network News Subsystem
Clock Daemon2
Local Use 0, 1, 2, 3, 4, 5, 6
(default), 7
4. Click Set. The Syslog server is configured.
79

SNMP Traps
This enables you to set the size of the traps log by entries.
To enable SNMP Traps

1.
From the Services menu, select Logging > SNMP Traps. The Traps Logging window appears.
2.
Set the parameters.
3.
Parameter
Description
Trap Logging
Enables/Disables the Trap Logging
Minimum Severity for Trap

Logging
Sets the minimum severity value for the trap.
Traps Log File Size
Sets the size of the traps log, as a number of entries.
Power supply trap status
Enable/disable the ability to measure power supply trap status
Values: Info, Error, Warning
Click Set. Trap Logging is enabled.
E-mail Notification
The device can send notifications on events to administrators via email. For each user you can
configure whether it should receive notifications via email (by defining an email address for the
user) and the minimal event severity reported via SNMP traps and email. The user will receive traps
of configured severity and higher. The severity levels are: Info, Warning, Error and Fatal. For email
address and notification severity configuration per user see - Users (link to users configuration).
Note: AppDirector optimizes the mailing process by gathering reports and sending them in a
single notification message once the buffer is full or once a timeout of 60 seconds
expires.
To configure E-mail Notifications

1.
From the Services menu, select Logging > Email Reporting. The Email Error Reporting
window appears.
2.
Set the parameters.
3.
80
Parameter
Description
Send Emails on
Errors
Whether to send notifications via email or not.
To Field Text
Text to use in the sent email "To" field.
Values: Enabled or Disabled (Default).

Configurable SMTP To Field

Message logging is disabled by default. You must enable logging if you wish to send messages to
one or more output locations. When enabled, log messages are sent to a logging process, which logs
messages to designated locations asynchronously to the processes that generated the messages.
You must set a logging output location to view any logs.
The SMTP Client window enables AppDirector to send information messages via email to
predetermined users. This feature can be used for sending trap information via email. In the User
Table each user is assigned a trap severity level, Info, Warning, Error or Fatal and receives emails
according to that severity level. For example, a user assigned the severity level Error, receives
emails for events with the severity level Error and Fatal.
To optimize AppDirector configuration and resource utilization, AppDirector can indicate and alert
usage of various tables and other parameters.
To allow AppDirector to send event notifications via email, the SMTP client must be configured on the
device.
To configure the SMTP Client

1. From the Services menu, select Logging > SMTP. The SMTP Client window appears.
Parameter
Description
SMTP Server
IP address of the SMTP Server.
Alternate SMTP
Server Address
An IP address of an alternative SMTP Server. The alternate SMTP server

is used when SMTP connection cannot be established successfully with
the main SMTP server, or when main SMTP server closed the connection.
The device tries to establish connection to the main SMTP server, and
starts re-using it when available.
Backup Device Email Sets the email of the Backup AppDirector device. This is used when the
Address
device is configured as an SMTP client.
You can configure AppDirector as an SMTP client, allowing it to send
email messages to specified users. This feature can be used for sending
trap messages. In the User Table, each user is assigned a trap severity
level (Info, Warning, Error, or Fatal) and receives emails according to that
severity level.
For example, a user assigned the severity level Error, receives emails for
events with the severity level Error and Fatal.
Own Email Address
Mail address of the device, for example myname@domain.com.
SMTP Client Status
Enables / Disables the SMTP client. Status must be set to Enabled to

support features that are related to sending email messages.
Default: Disable
3. Click Set. The SMTP Client is configured.
Note: To receive emails about errors, you need to enable features related to mail sending,
such as Send Emails on Errors and for each user set email address and Severity level in
the Users Table.
81

Configuration Auditing
Configuration Auditing is the process of logging every configuration change and activity. When
Configuration Auditing is enabled, the device keeps track of all changes made to the configuration.
When a user creates a new configuration object, the device reports the action, e.g. user created a
new farm or added a server to a farm. The device sends an event in CLI format (if the user created
the object via Web Based Management). If the user modifies the existing entry, the device also
reports the old and new values of the changed parameter. Deletions of objects are reported in the
same CLI format.
Where there is no CLI equivalent to a Web Based Management, the device reports the parameters
MIB Name.
The notification message contains these details:
Name of the MIB variable that was changed.
New value of the variable.
Time of configuration change.
Configuration tool that was used (APSolute, Telnet, SSH, WBM).
User name, when applicable.
Configuration Auditing is enabled or disabled per device and it affects all users and all management
interfaces. The default is disabled.
To enable configuration auditing

1.
Select Services > Auditing. The Auditing Status window appears.
2.
Select enable.
3.
Click Set. The auditing status is set to enable.
To disable configuration auditing

1.
Select Services > Auditing. The Auditing Status window appears.
2.
Select disable.
3.
Click Set. The auditing status is set to disable.
82

AppDirector Thresholds
To optimize AppDirector configuration and resource thresholds, AppDirector can indicate and alert
usage of various tables and other parameters. AppDirector continuously monitors this usage and can
notify you when usage thresholds are exceeded. Threshold warnings are available for the following
tables and parameters.
To view and set Threshold Settings

1. From the Services menu select AppDirector Thresholds > Settings. The AppDirector
Thresholds Settings window appears
Parameter
Description
Send Threshold
Warnings
Enables or disables (default) the threshold warning traps mechanism.
Min. Time Between

Warnings (sec)
Minimum time, in seconds, between consecutive warnings AppDirector

sends about the same resource.
Default: 60
Value of 0 means traps are sent continuously.
Client Table
Threshold Level
Defines the percentage of Client Table usage where a trap is sent.

Statistics are kept as follows:
Current number of entries
Average value for last 5 seconds
Average value for the last 60 seconds
Default: 85

Threshold Level
Defines percentage of Client Table usage where a trap is sent.
Application Servers
Connection Limit
Threshold Level
Defines the percentage of Application Servers Connection Limit usage

where a trap is sent.
Default: 85
Default: 85
When the number of sessions to an application server exceeds 85% of
the Connection Limit configured for that server, a trap is sent.
Physical Servers
Connection Limit
Threshold Level
Defines the percentage of Physical Servers Connection Limit usage where

a trap is sent.
Default: 85
When the number of sessions to a physical server exceeds 85% of the
Connection Limit configured for that server, a trap is sent.
Farms Capacity
Threshold Level
Defines the percentage of farm capacity used where a trap is sent.

Default: 85
When the number of sessions to a farm exceeds 85% of the Capacity
Threshold configured for that farm, a trap is sent.
Client NAT
Threshold Level
Percentage of Client NAT ports usage above which a trap is sent. Default:
85
When 85% of Client NAT ports for any Client NAT address are used, a
trap is sent.
83

Parameter
Description
Outbound NAT
Threshold Level
Percentage of Outbound NAT ports usage above which a trap is sent.

Default: 85
When 85% of Outbound NAT ports of the Outbound NAT addresses are
used, a trap is sent.
Session ID
Threshold Level
Percentage of the Session ID table usage above which a trap is sent.

When 85% of Session ID table is used, a trap is sent.
Values: 1 - 99
Default: 85
Requests Threshold
Level
Percentage of the Request table usage above which a trap is sent.

Default: 85
When 85% of the Request table is used, a trap is sent.
CPU Utilization
Threshold Level
High CPU on the device is caused by many reasons. A device should

actively notify its status, if this status is suspected to be a non-valid
status. To do this, a trap can be sent if for a period of 30 seconds the
average CPU utilization in the device is higher than a specified threshold.
Another trap can be sent if the device had 30 seconds of CPU utilization
lower than the specified threshold.
Threshold is configurable with CLI or WBM and SNMP.
Traps are sent only if threshold warning sending has been enabled
(similar to other threshold traps).
Default: 95
Throughput
Supports configurable overflow alert threshold for licensed throughput
Utilization Threshold utilization. The default for the threshold level is 90%.
Level
(Mbps)
SSL CPS Utilization
Threshold Level
Supports configurable overflow alert threshold for licensed SSL CPS

utilization. The default for the threshold level is 90%.
Compression
Supports configurable overflow alert threshold for licensed compression
Utilization Threshold utilization. The default for the threshold level is 90%.
Level (Mbps)
3.
AppDirector Thresholds Statistics

AppDirector Thresholds statistics contains various tables where you can view averages, configured
maximums and minimums.
Tunable Tables
The Tunable Tables Usage Statistics window provides you with information regarding the utilization
of various tables in AppDirector.
84

To view the Tunable Tables Usage Statistics parameters

From the Services menu, select AppDirector Thresholds > Statistics > Tuning Tables. The
Tunable Tables Usage Statistics window appears, which contains these read-only parameters:
Parameter
Description
Table Name
The name of the table in the Tunable Table.
Current Entries
The number of entries in the Tunable Table.
5 sec Average
Average resources utilization in the last 5 seconds.
60 sec Average
Max Num of Entries
Maximum configured table size.
Client NAT Level

The Client Table Threshold Level defines the percentage of Client Table usage where a trap is sent.
The default is 85. The Client NAT Level window allows you to view the client table's threshold data.
To view the Client NAT Level parameters

From the Services menu, select AppDirector Threshold > Statistics > Client NAT Level. The
Client NAT Level window appears, which contains the following read-only parameters:
Parameter
Description
NAT Address
Specifies the IP address to be used for NAT.
Current
Current port usage for the Client NAT address.
Average
Average port usage for the Client NAT address.
Outbound NAT Level

Outbound NAT Port Threshold Level defines the percentage of Outbound NAT Ports usage where a
trap is sent. The default is 85. When 85% of Outbound NAT ports for the Outbound NAT addresses,
a trap is sent. The Outbound NAT Level window allows you to view outbound NAT level information.
To view the Outbound NAT Level parameters

From the Services menu, select AppDirector Threshold > Statistics > Outbound NAT Level.
The Outbound NAT Level window appears, which contains these read-only parameters:
Parameter
Description
NAT Address
Specifies the IP address to be used for NAT.
Current
Current port usage for the Outbound NAT address.
Average
Average port usage for the Outbound NAT address.
85

Application Servers Level

Application Servers Connection Limit Threshold Level defines the percentage of Application Servers
Connection Limit usage where a trap is sent. Default is 85. When the number of sessions to an
application server exceeds 85% of the Connection Limit configured for that server, a trap is sent.
Application Servers Connection Limit defines the maximum number of allowed sessions open at any
given time on this application server. When the limit is reached, new sessions are no longer
forwarded to this application server. The Application Servers Connection Level window allows you to
view the application server's Connection Level information.
To view the Application Servers Connection Level parameters

From the Services menu, select AppDirector Threshold > Statistics > Application Servers
Level. The Application Servers Connection Level window appears containing these read-only
parameters:
Parameter
Description
Farm Name
The name of the farm.
Server Address
IP address of the required server.
Current
Number of currently active users attached to this server.
Average
Average attached users for the Application Servers address.
Server Port
Displays active connections per server statistics
RTSP Redirect (last

second)
Number of RTSP sessions redirected to this Server during the last

second.
Physical Servers Level

Physical Servers Connection Limit defines the maximum number of allowed sessions open at any
given time on this physical server, meaning to application servers in any AppDirector farm that share
the same name. When the limit is reached, new sessions are no longer forwarded to this physical
server.
Physical Servers Connection Limit Threshold Level defines the percentage of Physical Servers
Connection Limit usage where a trap is sent. The default is 85. When the number of sessions to a
physical server exceeds 85% of the Connection Limit configured for that server, a trap is sent.
The Physical Servers Connection Level window allows you to view the physical server's connection
level information.
To view the Physical Servers Connection Level parameters

From the Services menu, select AppDirector Threshold > Statistics > Physical Servers Level.
The Physical Servers Connection Level window appears, which contains these read-only parameters:
Parameter
Description
Server Name
Defines name of group of farm servers associated with this physical

server. Adding a new server to a farm using a Server Name already
defined in another farm, implies that it is the same physical server.
Current
Current attached users for the Physical Servers address.
Average
Average attached users for the Physical Servers address.
86

Farms Capacity Level

Farm Capacity Threshold is used for a farm that is part of a distributed environment. When the
farms Capacity Threshold is met, AppDirector reports to remote devices that it is no longer
accepting further distributed sessions to this farm.
The Farm Capacity Threshold Level is the percentage of farm capacity used, above which a trap is
sent. The default is 85. When the number of sessions to a farm exceeds 85% of the capacity
threshold configured for that farm, a trap is sent. The Farm Capacity Level window lets you view
information about the Farm's Capacity Level.
To view the Farm Capacity Level parameters

1. From the Services menu, select AppDirector Threshold > Statistics > Farm Capacity
Level. The Farm Capacity Level window appears, which contains these read-only parameters:
Parameter
Description
Farm Name
The address of the server farm.
Current Connections
Number
Current number of connection to the farm.
Average Connections
Number
Average number of connections to the farm.
2. Select the desired farm name. The Farm Capacity Level Update window appears, which contains
the following read-only parameters.
Parameter
Description
Farm Name
User-defined name of the farm.
Attached Users
Number of currently active users attached to this server.
Peak Load
Maximum number of frames per second dispatched to the server since

the last reset.
Frame Rate
Number of frames dispatched to server
Frame Rate (bytes)
Number of frames per second dispatched to server.
Backup Server Used
Indicates that the farm used a backup server.
Distribution Threshold
Reached
Indicates the number of times this threshold is reached.
Capacity Threshold
Reached
Indicates that the farm has reached its full capacity.
DNS Reply Redirect

(last second)
Number of DNS queries resolved to other SIPDirectors in the last

second.
Redirected HTTP (last

second)
Number of HTTP sessions which arrived for this farm and were
redirected to remote/distributed servers.
Redirected Triangle
(last second)
Indicates the rate at which clients were redirected by triangulation

service in the last second.
Redirected RTSP (last

second)
Number of RTSP sessions which arrived during the last second for this
farm and were redirected to remote/distributed servers.
Current Connections
Number
Number of directed attached clients to this farm.
Average Connections
Number
Average number of directed attached clients to this farm.
87

Parameter
Description
Redirected SIP (last

second)
Total number of SIP sessions which arrived for this Farm during the last
second.
Local Proxy (local

second)
Total number of proxy sessions handled by local servers.
Basic Switching (Layer 2 Capability)

This section discusses how to configure Layer 1-2 switching functions and includes these topics:
AppDirector Physical Interface Configuration, page 88
Layer 2 Interface Table, page 89
Virtual LAN, page 91
Spanning Tree Protocol, page 98
VLAN Tagging, page 96
Link Aggregation (Port Trunking), page 101
Port Mirroring, page 104
This table summarizes Layer 2 capability for Radwares OnDemand switches.
Layer 2 Feature
ODS1 and
ODS1 XL
ODS2 and ODS3 v2 and ODS VL and

ODS2XL
ODS3XL
ODS VL XL
Radware Segmentation (physical Port

and VLAN)
Yes
Yes
Yes
Yes
Regular VLAN (bridging)
Yes
Yes
Yes
Yes
Switch VLAN
No
Yes
Yes
No
VLAN tagging 802.1q
Yes
Yes
Yes
Yes
Link aggregation 802.3ad
Yes
Yes
Yes
Yes
Port mirroring (Copy port)
No
Yes
Yes
No
STP 802.1d
No
Yes
Yes
No
AppDirector Physical Interface Configuration

AppDirector enables you to change physical attributes of each port such as speed and duplex mode.
To update the ports physical attributes

1.
From the Device menu, select Physical Interface. The Physical Interface window appears.
2.
Set the parameters.
88
Parameter
Description
Port Index
Index number of the port

Parameter
Description
Speed
Traffic speed of the port.

Values: Ethernet, Fast Ethernet, Giga Ethernet, or XG Ethernet.
Note: According to standards, this parameter can be changed only
for copper ports. Once this parameter is changed the Auto
Negotiate parameter is set to Off.
Duplex
Whether the port allows both inbound and outbound traffic (Full Duplex)
or one way only (Half Duplex).
Note: According to standards, this parameter can be changed only
for copper ports with a speed lower than Giga Ethernet. Once
this parameter is changed the Auto Negotiate parameter is
set to Off.
Auto Negotiate
Automatically detects and configures the speed and duplex required for
the interface.
3. Select the required port. The Physical Interface Table Update window appears.
4. Update the required fields and click Set. Your configuration is set.
Layer 2 Interface Table

Layer 2 takes the bits from higher layers and creates network specific frames which are then
transmitted to another endpoint on the LAN. It provides an address space on the LAN and some
addressing modes like point-to-point (unicast), point-to-multipoint (multicast) and broadcast.
In the TCP/IP model, the TCP/IP protocol defines the first step in the abstraction from the physical
network. The Address Resolution Protocol (ARP) and its counterpart Reverse ARP (RARP) provide the
conversion functions from IP to LAN address and visa versa respectively. ARP and RARP are usually
placed on this level, because each LAN has its own method of addressing hosts connected to it.
Another property of this layer is that it defines some capabilities or services for the Internet Layer to
use: Frame size, addressing capabilities (unicast, multicast, broadcast), Quality of Service (QoS)
parameters, etc.
A Layer 2 Interface is defined as any interface that has its own MAC address - physical port, trunk,
VLAN. You are able to configure the administrative status of each interface and monitor status and
interface statistics.
To view/edit the Layer 2 Interface Table

1. From the Device menu, select Layer 2 Interface. The Layer 2 Interface Table window appears.
2. Select the Interface Index number to edit, and the Layer 2 Interface Table Update window
appears with read-only parameters.
Read Only Parameter Description

Interface Index
The Interface index number.
Interface Description
A textual string containing information about the interface. This string

should include the name of the manufacturer, the product name and
the version of the interface hardware/software.
89

Read Only Parameter Description

Interface Type
Type of interface. Additional values are assigned by the Internet

Assigned Numbers Authority (IANA), through updating the syntax of
the textual convention.
Interface Speed
An estimate of the interface's current bandwidth in bits per second.
MAC Address
The MAC Address of the interface.
Interface Admin Status Controls interface administrative status.

Values: Up/Down.
Operational Status
Specifies the operational status of the router.

Values: Up/Down.
4.
90
Interface Last Change
Value of sysUpTime at the time the interface entered its current

operational state. If the current state was entered prior to the last reinitialization of the local network management subsystem, then this
object contains a zero value.
ifINOctets
Number of incoming octets (bytes) through the interface including

framing characters.
InUcastPkt
Number of packets delivered by this sub-layer to a higher (sub-) layer,

which were not addressed to a multicast or broadcast address at this
sub-layer.
InNUcastPkt
Number of packets delivered by this sub-layer to a higher (sub-) layer,

which were addressed to a multicast or broadcast address at this sublayer.
ifINDiscards
Number of inbound packets chosen to be discarded even though no

errors had been detected to prevent their being deliverable to a
higher-layer protocol. One possible reason for discarding such a packet
could be to free up buffer space.
ifINErrors
For packet-oriented interfaces, the number of inbound packets that

contained errors preventing them from being deliverable to a higherlayer protocol. For character-oriented or fixed-length interfaces, the
number of inbound transmission units that contained errors preventing
them from being deliverable to a higher-layer protocol.
ifOutOctets
Total number of octets (bytes) transmitted out of the interface,

including framing characters.
OutUcastPkt
Total number of packets that higher-level protocols requested be

transmitted, and which were not addressed to a multicast or broadcast
address at this sub-layer, including those that were discarded or not
sent.
OutNUcastPkt
Total number of packets that higher-level protocols requested be

transmitted, and which were addressed to a multicast or broadcast
address at this sub-layer, including those discarded or not sent.
ifOutDiscards
Number of outbound packets which were chosen to be discarded even

though no errors had been detected to prevent their being
transmitted. One possible reason for discarding such a packet could be
to free up buffer space.
ifOutErrors
For packet-oriented interfaces, the number of outbound packets that

could not be transmitted because of errors. For character-oriented or
fixed-length interfaces, the number of outbound transmission units
that could not be transmitted because of errors.

Virtual LAN
A Virtual LAN (VLAN) is a group of devices on different physical LAN segments or on a single LAN
segment, which can interact with each other as if they were all on the same physical LAN segment.
In other words, a VLAN is a group of PCs, servers and other network resources that behave as if
they were connected to a single, network segment even though they are not, physically. They are
able to share resources and bandwidth as if they were connected to the same section.
Some switches are configured to support single or multiple VLANs. When a switch supports multiple
VLANs, the broadcast domains are not shared between the VLANs.
The device learns the Layer 2 addresses on every VLAN port.
Known unicast frames are forwarded to the relevant port.
Unknown unicast frames and broadcast frames are forwarded to all ports.
AppDirector VLAN Types

AppDirector VLANs provide bridging and switching functionality among ports assigned to the same
VLAN. AppDirector supports both Regular VLAN and Switch VLAN.
Note: AppDirector devices support up to 64 regular or switched VLANs and up to 2048 VLAN
IDs.
Regular VLAN
A Regular VLAN can be described as an IP Bridge (a software bridge) between multiple ports that
incorporates all the traffic redirection of passing traffic at all layers (Layer 2-Layer 7). Two protocols
can be used with Regular VLANs:
IP Protocol: The VLAN must be assigned an IP address. All of the traffic between ports is
intercepted transparently by AppDirector. Packets that need intelligent intervention are checked
and modified by AppDirector and then forwarded to the relevant port. Other packets are simply
bridged by AppDirector as if they were on the same wire.
Other Protocol: An Other protocol VLAN cannot be assigned an IP address. This type of VLAN is
used to bridge non-IP traffic through AppDirector. To handle both packets that need intelligent
intervention and non-IP traffic, you can configure IP VLAN and Other VLAN on the same ports.
Note: Switch VLAN can be standalone or part of a Regular VLAN.
Switch VLAN
Switch VLAN provides wire-speed VLAN capabilities implemented through the hardware switch fabric
of the AppDirector device. Depending on the protocol defined for the Switch VLAN, frames are
treated accordingly.
Switch VLAN Protocol: Frames arriving at the VLAN port are switched according to Layer 2
information. AppDirector does not intercept this traffic.
IP Protocol: Frames reaching the VLAN port are switched according to Layer 2 information,
except those whose Layer 2 address is the same as the AppDirector port Layer 2 address.
Frames with AppDirector Layer 2 destination are processed by AppDirector and then forwarded.
91

VLAN Configuration
A VLAN configuration procedure involves:
1.
Creating a VLAN
2.
Adding ports and/or trunks to that VLAN.
In addition you can change the Ethernet type and mask used by all VLANs.
VLAN Parameters
Here you can configure the VLAN Ethernet type and mask per the device.
To configure the VLAN Parameters window

1.
From the Device menu, select VLAN Parameters. The VLAN Parameters window appears.
2.
Set the parameters.
3.
Parameter
Description
VLAN Ethernet Type
Defines the Ethernet type for user defined VLANs.
VLAN Ethernet Type

Mask
Defines the mask on Ethernet type for user defined VLANs
Creating and Editing VLANs and VLAN Ports

This shows you how to create and edit VLANs and VLAN ports.
To view/create a VLAN
1.
From the Device menu, select VLAN Table. The Virtual LAN Table window appears. The Virtual
LAN Table window appears.
2.
Set the parameters.
Parameter
Description
Interface Number
Interface number of VLAN automatically assigned by management

station.
Type
Required VLAN type:

Regular (Default): The VLAN acts as a bridge.
Switch: Switch VLAN can be part of a Regular VLAN.
Protocol
92
Required VLAN protocol. You can choose IP or Switch VLAN only when
the VLAN type is Switch. Otherwise, the protocol is IP or Other
(default).

Parameter
Description
Up Criterion
Defines conditions under which a VLAN interface is considered Up.

Default by Type (Default):
For Regular VLAN, all ports in the VLAN are up.
Note: This is true when interface grouping is enabled, otherwise
ports behave the same as Switch VLAN.
For Switch VLAN, at least one of the ports in the VLAN is up.
All Ports: The VLAN is considered down when all the ports
participating in the VLAN are down and it is considered up when
all the ports, participating in the VLAN are up.
Note: After reboot the VLAN status is "up" even though the port is
still down, therefore VLAN status should be "down".
One Port: The VLAN is considered down when at least one port
participating in the VLAN is down and it is considered up when at
least one port, participating in the VLAN is up
Down Criterion
Defines conditions under which a VLAN interface is considered Down.

Default by Type (Default):
For Regular VLAN, at least one of the ports in the VLAN is down.
Note: This is true when interface grouping is enabled, otherwise
ports behave the same as Switch VLAN.
For Switch VLAN, all ports in the VLAN are down.
All Ports: The VLAN is considered down when all the ports
participating in the VLAN are down and it is considered up when
all the ports, participating in the VLAN are up.
One Port: The VLAN is considered down when at least one port
participating in the VLAN is down and it is considered up when at
least one port, participating in the VLAN is up.
3. To create a new VLAN, click Create. The Virtual LAN Table Create window appears.
4. For editing, in the Virtual LAN Table window, select a VLAN to update.
5. Click Edit. The Virtual LAN Update window appears.
93

Adding Physical Ports to a VLAN

This procedure explains how to add physical ports to a VLAN.
To add physical ports to the VLAN

1.
In the Virtual LAN Table window, in the VLAN Port Table section, click Create. The VLAN Port
Create window appears.
2.
Set the parameters.
Parameter
Description
VLAN Interface Index
Select VLAN for which you require to add a port.
VLAN Port Index
The Layer 2 interface you want to attach to the VLAN. Can be port
index, trunk index, or Switch VLAN.
Port Type
Values:
Static: configured by the user.
Dynamic: autoconfigured by the remote server.
Port Interface
Grouping State
Defines whether the status of this L2 interface should be taken into

consideration when calculating VLAN status for Interface Grouping
(relevant in redundant configurations only - see Redundancy,
page 123) Select from:
Included: Allows interfaces to initiate Interface Grouping if it is
down.
Excluded: Does not allow interfaces to initiate Interface
Grouping if it is down.
3.
Bridging
Once a regular VLAN is defined, AppDirector performs bridging among interfaces assigned to the
same VLAN. Bridging within a VLAN means that AppDirector learns the MAC addresses of frames
arriving from each physical interface, and maintains a list of MAC addresses per interface.
AppDirector enables you to statically add MAC addresses to the interface list.
When a frame arrives from one interface, AppDirector looks for the frame Destination addresses
within its address list according to the following conditions:
If the Destination address is listed in the same interface as the Source address, AppDirector
discards the frame.
If the Destination address is listed in another interface, AppDirector forwards the frame to the
relevant interface.
If the Destination address is not listed in any interface, AppDirector broadcasts the frame to all
interfaces participating in the VLAN.
94

Bridge Operating Parameters

To configure Bridge operating parameters, perform he procedure shown here.
To configure Bridge Operating Parameters

1. From the Bridge menu, select Operating Parameters. The Bridge Operating Parameters
window appears.
2. Set the parameters
Parameter
Description
Bridge Address
(Read Only)
The MAC Address used by the device.
Bridge Type (Read

Only)
Types of bridging the device can perform.
Forwarding Table
Aging Time
How many seconds learned entries remain in the Forwarding Table. The
counter is reset each time the entry is used. After this time, entries are
deleted from the table.
Minimum: 10 seconds.
3. Change the Forwarding Table Aging Time value.

Bridge Global Forwarding Table

The Bridge Global Forwarding Table is used to monitor bridge forwarding nodes.
To access the Global Forwarding Table

From the Bridge menu, select Global Forwarding Table. The Global Forwarding Table window
appears with these read-only parameters:
Parameter
Description
MAC Address
The node's MAC address
Port
Port through which node has been learned. Port through which frames are
received from this entry.
Status
Describes how node entry was added to the list, and indicates status
Learned: The entry was automatically learned.
Self: The entry is a device port.
Mgmt: The entry is a static node manually entered using the Edit
button.
Other: Node status cannot be described by above.
95

Static Forwarding Table

This table is used to monitor, create and edit static bridge forwarding nodes.
To create/edit the Static Forwarding Table

1.
From the Bridge menu, select Static Forwarding Table. The Static Forwarding Table window
appears.
2.
Click Create. The Static Bridge Forwarding Table Create window appears.
3.
Set the parameters.
Parameter
Description
Static MAC Address
The static node's MAC address.
Static Receive Port
Port through which frames are received from this entry.
Status
Describes how node entry behaves upon device reset:

Permanent: Entry remains after device reset.
DeleteOnReset: Entry is deleted by a device reset.
4.
VLAN Tagging
VLAN Tagging is an IEEE standard (802.1q) for supporting multiple VLANs associated with the same
switch port. Each VLAN is tagged with a unique identifier to allow the identification of different VLAN
traffic on the same physical port. This protocol allows individual VLANs to communicate with one
another with the use of a Layer 3 router.
AppDirector can rewrite VLAN Tags or retain the tags on packets that pass through it. For
AppDirector to support VLAN Tags, by either forwarding or overwriting them, support for a 802.1q
environment must be enabled. By default VLAN Tags are not supported on AppDirector. When the
status of VLAN Tag support is changed, you need to reboot the device.
Note: If you want 8021q information, you need to capture what is being sent to the
AppDirector on the neighboring switch. Therefore 8021q header information cannot be
displayed in the packet capture.
Retaining VLAN Tags

AppDirector enables you to preserve existing VLAN Tags on incoming traffic passing through the
device.
Rewriting VLAN Tags

VLAN Tagging can be used with AppDirector, where AppDirector is connected to multiple VLANs on
the same switch, and different servers are assigned to different VLANs.
VLAN Tagging support is based on the local subnet to which the traffic is sent or on the destination
MAC of the packet. Therefore, AppDirector cannot tag packets by the destination subnet if it is not
local to the AppDirector. The switch connected to the AppDirector must be configured consistently
with the AppDirector tagging configuration.
96

Each IP interface can have a VLAN tag associated with it.
AppDirector recognizes an IP interface as a L2 interface/IP address combination.
When using AppDirector with VLAN Tagging, all packets sent to a Destination MAC address of a Next
Hop Router (with an IP address on a local subnet that is associated with a tag-configured IP
interface), carry the VLAN tag, regardless of the Destination IP address of the packet.
In addition, all packets sent to any Destination host on a tag-configured IP interface carry the VLAN
tag. This includes:
All Health Check packets from AppDirector to Next Hop Routers, including Full Path Health
Monitoring.
ARP requests and responses from AppDirector to the Next Hop Routers.
Unicast ARPs between redundant AppDirectors.
Gratuitous ARPs, as part of the redundancy feature.
If an IP interface does not have a VLAN tag configured, then the packets are sent without a tag
(standard Layer 2 MAC header).
Configurable VLAN ID values range from 0 to 4095. AppDirector automatically sets the 802.1p
portion of the tag (the first three bits) to 000. If a packet arrives without a VLAN tag, to a
Destination interface of AppDirector with VLAN tag, AppDirector sets a tag on the packet according
to the Destination local subnet, even if its in retain mode and behaves as in overwrite.
Note: 802.1p is a specification for giving Layer 2 switches the ability to prioritize traffic (and
perform dynamic multicast filtering).
VLAN Tagging Configuration

The VLAN Tagging window allows you to enable and disable VLAN tagging. AppDirector can rewrite
VLAN Tags on packets that pass through it.Configurable VLAN ID values range from 0 to 4095.
AppDirector automatically sets the 802.1p portion of the tag (the first three bits) to 000. If a packet
arrives without a VLAN tag, to a Destination interface of AppDirector with VLAN tag, AppDirector
sets a tag on the packet according to the Destination local subnet, even if its in retain mode and
behaves as in overwrite.
To enable VLAN Tagging

1. From the Device menu, select VLAN Tagging. The VLAN Tagging window appears.
2. From the 802.1q Environment drop-down box, select Enable.
3. Set the VLAN Tag Handling using these parameters.
Parameter
Description
Retain
The device preserves existing VLAN tags on the incoming traffic that
passes through the device.
Traffic generated by the device is tagged according to IP Interface
configuration.
97

Parameter
Description
Overwrite (Default) The device performs VLAN Tagging of outgoing traffic in accordance with
IP Interface configurations. AppDirector sets tags for packets according to
the following parameters:
Destination IP of the packet if it is on the same local subnet with
AppDirector OR
MAC address of the firewall that is configured on AppDirector and
through which the packet is sent.
4.
Spanning Tree Protocol

The Spanning Tree Protocol (STP) is a protocol that prevents loops in networks and environments
where there is more than one path that the traffic may pass through. If a packet has numerous
links, it can choose which path to use, which may cause loops in the network. The STP algorithm
makes a calculation based on various parameters including the preferred path and logically blocks all
other paths. AppDirector supports the Rapid Spanning Tree Protocol (backwards compatible with
STP), allowing you to configure Spanning Tree on each VLAN of the device. Different VLANs may
have different STP settings.
Notes:
>> STP is NOT supported on OnDemand Switch 1 Platforms.
>> Spanning Tree is supported only for IP-Regular and IP-Switch VLANs.
>> When working with STP in redundant configuration, VRRP redundancy mechanism must
be used and the primary device must have the lowest Bridge ID.
Spanning Tree Global Parameters/Settings

The Spanning Tree Global Parameters/Settings window enables you to configure the global
parameters of the Spanning Tree, affecting all the Spanning Tree instances running on the device.
To configure the STP Global Settings

1.
From the Bridge menu, select STP > Global Parameters. The STP Global Parameters window
appears.
2.
Set the parameters.
Parameter
Spanning Tree Mode
Description
Disables Spanning Tree support per VLAN.
Values: Disabled (Default) or Per-VLAN (enabled).
Default Bridge Priority Value represents default priority of bridge.

Values: 0 - 61440 in multiples of 4096. The lower the value, the higher
the priority
Default: 32768
98

Parameter
Description
Default Hello Time

[sec.]
Value represents interval in seconds, between 2 BPDU packets sent by

device.
Values: 1 - 10 seconds.
Default: 2 seconds.
Default Max Aging

Time [sec.]
Value represents the maximum time, in seconds, the device waits for a
BPDU packet before it tries to re-configure.
Default Forward Delay Time that the device waits before changing the port`s state.
Time [sec.]
Default Port Priority
Value represents port priority. When 2 (or more) ports have same
value, device uses port with lowest MAC address.
Default value: 128 seconds.
Note: Default values will take effect only after a reboot, or when creating new instances.
Spanning Tree Instances

When there is more than one VLAN on the device, each VLAN can run its own instance of a Spanning
Tree with different parameters for each VLAN. When there are multiple VLANs on the device, you can
enable and disable the Spanning Tree for each VLAN.
Notes:
>> Spanning Tree per VLAN is supported only when the VLANs do not share any physical
ports (each VLAN has its own physical ports).
>> Regular VLAN defaults UP/Down criterion are set to Down: 1 port Up: All Ports. To work
affectively with STP redundancy it should be set to Down:All ports Up: 1 Port
To configure Spanning Tree Instances

1. From the Bridge menu, select STP > Instances. The STP Instances window appears.
2. Select the relevant VLAN ID that you wish to edit and select it. The Spanning Tree Instances Run
on this Bridge Update window appears.
99

3.
Set the parameters.
Parameter
Description
VLAN ID
VLAN to apply these settings to, alternatively you may apply the
settings to multiple VLANs.
Bridge Priority
Default priority of the bridge.

Values: 0 - 61440 in multiples of 4096. Default: 32768
Maximum Aging Time Maximum time, in seconds, that the device waits for a BPDU packet
[sec.]
before it tries to re-configure.
Values: 6 - 40 seconds. Default: 20 seconds.
Hello Time [sec.]
Interval, in seconds, between two BPDU packets sent by device.

Values: 1 - 10 seconds. Default: 2 seconds.
4.
Forward Delay Time

[sec.]
Time, in seconds, the device waits before changing port's state.
STP Status
Allows you to enable and disable the STP status.
Values: 4 - 30 seconds. Default:15 seconds.
Spanning Tree Ports

Within each VLAN, you can configure individual physical port behavior. Ports connected directly to
servers do not need to wait for the forward delay timer to expire before they start forwarding traffic.
You can enable ModeFast, enabling the device to forward traffic as quickly as possible. You can also
exclude any physical port from participating in the STP algorithm.
To configure Spanning Tree Ports

1.
From the Bridge menu, select STP > Ports. The STP Port Information window appears.
2.
Select the relevant port from the table. The STP Port Information Update window reappears.
3.
Set the parameters.
Parameter
Description
Port ID (Read Only)
Number of the selected port from the table.
VLAN ID (Read Only)
Specifies the VLAN the physical port belongs to.
Priority
Represents port priority. When two (or more) ports have the same
value, the device uses the port with the lowest MAC address.
Values: 0 - 240 in multiples of 16.
Default: 128
Path Cost
This sets the spanning tree path cost for this port.
Values: 1 - 65535, defined automatically according to port speed. You
can also change this value.
Note: Default values for costs on the devices ports are influenced by
the port speed.
Port Speed versus Path Cost
100
10Mbps /100
100Mbps /19
1Gbps /4
10Gbps/ 2

Parameter
Mode Fast
Description
When enabled, this port will change its status to forwarding state.
Values: Enabled / Disabled (default).
STP Status
Enables STP support on the selected port. When disabled, the physical
port does not participate in STP.
Values: Enabled (default)/ Disabled
Link Aggregation (Port Trunking)

Link Aggregation, or Port Trunking, is a method of combining physical network links into a single
logical link for increased bandwidth. With Link Aggregation you can increase the capacity and
availability of the communications channel between devices (both switches and end stations) using
existing Fast Ethernet and Gigabit Ethernet technology. This is performed by using a set of multiple
parallel physical links between two devices grouped together to form a single logical link. Link
Aggregation includes the following topics:
Link Aggregation Global Configuration, page 102
Link Aggregation Trunk Table, page 103
Link Aggregation Trunk Port Table, page 103
Trunk Management, page 104
The port trunking feature allows you to define up to seven trunks, (on OnDemand Switch 1, 2 , 3, VL
and XL platforms. Up to eight physical links can be aggregated into one trunk. All trunk
configurations are static. To provide optimal distribution for different scenarios the load sharing
algorithm allows decisions based on source or destination (or both) Layer 2 address (MAC), Layer 3
address (IP), and Layer 4 address (TCP/UDP port numbers). These parameters are used as input for
a hashing function
Link aggregation also provides load balancing where the processing and communications activity is
distributed across several links in a trunk ensuring that no single link is overwhelmed. By taking
multiple LAN connections and treating them as a unified, aggregated link, you can achieve higher
link availability and increased link capacity
Port Trunking is supported according to the IEEE 802.3ad standard for Link Aggregation as follows:
Link Aggregation is supported only on links using the IEEE 802.3 MAC
Link Aggregation is supported only on point-to-point links
Link Aggregation is supported only on links operating in full duplex mode
Link Aggregation is permitted only among links with the same speed and direction. On the
device bandwidth increments are provided in units of 100Mbps and 1Gbps respectively
The failure or replacement of a single link within a Link Aggregation Group will not cause failure
from the perspective of a MAC client.
Note: AppDirector does not support the Link Aggregation Control Protocol (LACP), only a static
trunks configuration.
MAC Client traffic can be distributed across multiple links. To guarantee the correct ordering of
frames at the receiving-end station, all frames belonging to one conversation must be transmitted
through the same physical link. The algorithm for assigning frames to a conversation depends on the
application environment. Radware devices can define conversations upon Layer 2, 3, or 4
information, or on combined layers.
101

Link Aggregation Global Configuration

To perform port trunking on a global AppDirector configuration, you need to follow this procedure.
To configure Link Aggregation Global Configuration

1.
From the Device menu, select Link Aggregation > Global Configuration. The Distribution
Method window appears.
2.
Set the parameters.
Parameter
Description
Layer 2
Defines if the MAC address is to be used in traffic distribution

algorithm. Select:
Ignore: Do not use MAC address
Source Address: Use source MAC address
Destination Address: Use destination MAC address
Both Addresses (Default): Use source and destination MAC
addresses
Layer 3
Defines if the IP address is to be used in traffic distribution algorithm.

Select:
Ignore: Do not use IP address
Source Address: Use source IP address
Destination Address: Use destination IP address
Both Addresses (Default): Use source and destination IP
addresses
Layer 4
Defines if application port is used in the traffic distribution algorithm.

Select:
Ignore: Do not use application port
Source Port: Use source application port
Destination Port: Use destination application port
Both Ports (Default): Use source and destination application
ports
3.
102

Link Aggregation Trunk Table

You can define up to seven trunks with up to eight physical links being aggregated into one trunk. All
trunk configurations are static. The Trunk Table window allows you to view the Trunk Index settings
that were defined in the Port Table.
To view the Link Aggregation Trunk Table

From the Device menu, select Link Aggregation >Trunk Table. The Link Aggregation Trunk Table
window appears, which contains the following read-only parameters:
Parameter
Description
Trunk Index
Displays the trunk index.
Trunk MAC Address
Displays the MAC Address assigned to the trunk.
Trunk Status
Individual: (False) No ports attached to this trunk.

Aggregated: (True) Ports attached to this trunk.
Link Aggregation Trunk Port Table

The Trunk Port Table window allows you to attach ports to a trunk but only connected ports (Link Up)
operating in full duplex mode can be attached to a trunk.
To set the Link Aggregation Trunk Port Table parameters

1. From the Device menu, select Link Aggregation > Port Table. The Link Aggregation Port
2. Select the Port Index to edit and Ports Table Update window appears.
Parameter
Description
Port Index (Read only)
The physical port index
Port MAC Address (Read

only)
The MAC address assigned to the port.
Trunk Index
Trunk to which the port is attached. Select from:

1-7
Unattached (Default)
Port Status (Read only)
Individual: (False) Port is not attached to any trunk.

Aggregated: (True) The Port is attached to a trunk.
4. Select the Trunk to which you wish to attach the port.

103

Notes:
>> The same algorithm must be applied on the other switch in the trunk.
>> OnDemand Switch 1 and VL implement link aggregation via software and not at the
switch level, (these platforms do not include a Layer 2 switch hardware component).
Therefore, you cannot define trunks as participants in port mirroring, on these
platforms.
Trunk Management
You can define a management trunk (T-MNG) that only includes the management ports (MNG-1 and
MNG-2). The management ports cannot be a part of any other trunk. Using the management trunk
provides redundancy at the physical level for connectivity to the management network.
One link is active while the other is in backup mode. Failure of the active link seamlessly activates
the backup.
Port Mirroring
Port Mirroring enables the AppDirector device to duplicate traffic from one physical port on the
device to another physical port on the same device. This is useful, for example, when an Intrusion
Detection System (IDS) device is connected to one of the ports on the AppDirector device.
You can configure port mirroring for received traffic only, for transmitted traffic only, or for both. You
can also decide whether to mirror the received broadcast packets.
To set the Port Mirroring parameters

1.
From the Device menu select Port Mirroring. The Port Mirroring Table window appears.
2.
Click Create. The Port Mirroring Table Create window appears.
3.
Set the parameters.I
Parameter
Description
Input Port
The port from which the traffic is mirrored
Output Port
The port to which traffic is mirrored.
Receive\Transmit
Select the direction of traffic to be mirrored.

Transmit & Receive (default)
Receive Only
Transmit Only
104

Parameter
Description
Promiscuous Mode
You can either copy all traffic from the input port to the output port or
to copy only traffic destined for the input port. Select either:
Enabled (default): All traffic is copied to the Output Port.
Disabled: Only traffic destined to the Input port is copied.
Note: The difference between enable / disable status is the ARP
packet. If you set Promiscuous mode to enable, you can
receive ARP packets with MAC address FF-FF-FF-FF-FF-FF or
you can receive ARP packets without the MAC address FFFF-FF-FF-FF-FF.
Notes:
>> Device Port mirroring is not supported with VLAN or OnDemand Switch 1.
>> OnDemand Switch 2 supports port mirroring of up to 4 ports.
>> For OnDemand Switches 2 and 3, the trunk cannot be a port mirroring destination but
can be a source. For OnDemand Switches VL and 1, trunks cannot participate at all in
port mirroring.
>> When mirroring traffic from a port which is part of a Switch VLAN, since traffic between
hosts on this VLAN is switched by the ASICs of the device, this traffic is not mirrored.
>> When mirroring traffic is received on a physical port, which is part of a Switch VLAN, and
if the mirrored port is configured to mirror Received Broadcast packets then these
packets are mirrored from all ports on the Switch VLAN.
>> Traffic generated by the device itself, such as Connectivity Checks or management
traffic, is not mirrored by Port Mirroring.
>> Using Regular VLAN, traffic with destination multicast MAC is not always mirrored.
>> You can copy traffic from one Input Port to up to two Output Ports, or from many Input
Ports into one Output Port.
IP Addressing and Routing

This section discusses configuration of IP addressing and includes the following topics:
Interface IP Addresses, page 106
Routing, page 107
Routing Information Protocol, page 112
Open Shortest Path First (OSPF), page 114
Border Gateway Protocol, page 119
Routing Table, page 109
ARP Table, page 110
NHRs, page 110
VIP NHR, page 111
105

Interface IP Addresses
IP addresses can have up to 32-bit binary numbers with each 32-bit IP address consisting of two
sub-addresses; one identifying the network, and the other identifying the host of the network, with
an imaginary boundary separating the two. The location of the boundary between the network and
host portions of an IP address is determined through the use of a subnet mask. A subnet mask is
another 32-bit binary number that acts like a filter when it is applied to the 32-bit IP address. By
comparing a subnet mask with an IP address, systems determine which portion of the IP address
relates to the network and which to the host. Anywhere the subnet mask has a bit set to "1", the
underlying bit in the IP address is part of the network address. Anywhere the subnet mask is set to
"0", the related bit in the IP address is part of the host address.
AppDirector performs routing between all IP interfaces defined on its Layer 2 interfaces (ports,
trunks, VLANs).
IP Interface Parameters
The IP Interface Parameters window allows you to configure the Interface and ICMP Interface
parameters.
To set the Interface Parameters

1.
From the Router menu select IP Router > Interface Parameters. The IP Interface
2.
Select the IP Address, the IP Interface Parameters Update window appears.
3.
Set the parameters.
4.
106
Parameter
Description
IP Address
IP address of the interface.
IF Number
Interface Number of the interface. If the interface is a VLAN, the

included interfaces are listed in the box in the Edit window.
Network Mask
Associated subnet mask.
FWD Broadcast
Formerly known as Free World Dialup or Voice over IP. This parameter
decides whether the device forwards incoming broadcasts to this
interface.
Broadcast Addr
Fill the host ID in the broadcast address with ones or zeros.
VLAN Tag
When multiple VLANs are associated with the same switch port, the
switch needs to identify to which VLAN to direct incoming traffic from
that specific port. VLAN tagging provides an indication in the Layer 2
header, which enables the switch to make the correct decision. Enter
the Tag to be associated with this IP Interface.
Peer Address
The IP address for the same layer 2 interface on the redundancy peer
device. This is mandatory if you want to synchronize configuration
between main and backup devices.

To set the ICMP Interface Parameters

1. From the Router menu select IP Router > Interface Parameters. The IP Interface
2. Double-click on an IP address from the ICMP Interface parameters section. The ICMP Interface
Parameters Update window appears.
Parameter
Description
IP Address
IP address of the interface.
Advert Address
IP destination address for multicast Router Advertisements sent from

the interface. Values are:
all-systems multicast address, 224.0.0.1
limited-broadcast address, 255.255.255.255
Max Advert.
Interval
Maximum time in seconds between multicast Router Advertisements

from the interface. Values are between the Minimum Advert Interval
defined below and 1800 seconds.
Min Advert.
Interval
Minimum time (seconds) between sending unsolicited multicast Router

Advertisements from the interface. Values are between 3 seconds and
the maximum interval defined above.
Default: 0.75 of the Maximum Interval.
Advert. Lifetime
Maximum time (seconds) that the advertised addresses are considered

valid. This must be no less than Maximum Interval as defined above,
and no greater than 9000 seconds.
Default: 3 times the Maximum Advert Interval.
Advertise
Enables you to advertise the device IP using ICMP Router Advertise.
Preference Level
Preferability of address as default router address, relative to other

router addresses on same subnet.
Reset to Defaults
Resets ICMP interface parameters to default values.
Routing
Routing is the ability to forward IP packets to their Destination using an IP Routing Table. This table
stores information about the Destinations and how they can be reached. By default, all networks
directly attached to AppDirector are registered in the IP Routing Table. Other entries can either be
statically configured or dynamically created through the routing protocol.
AppDirector forwards IP packets to their destination using an IP Routing Table. This table stores
information about the destinations and how they can be reached. By default, all networks directly
attached to AppDirector are registered in the IP Routing Table. Other entries can either be statically
configured or dynamically created through the routing protocol.
When AppDirector forwards an IP packet, the IP Routing Table is used to determine the NextHop IP address and the Next-Hop interface.
107

For a direct delivery (the Destination is a neighboring node), the Next-Hop MAC address is the
Destination MAC address for the IP packet.
For indirect delivery (Destination is not a neighboring node), the Next-Hop MAC address is the IP
router address according to the IP Routing Table.
The Destination IP address does not change from Source to Destination. The Destination MAC
(Layer 2 information) is manipulated to move a packet across networks.
The MAC of the Destination host is applied once the packet arrives on the Destination network.
IP Router Operating Parameters

The IP Router Parameters window allows you to monitor, add and edit router settings.
To access the IP Router Parameters window

1.
From the Router menu, select IP Router > Operating Parameters. The Adjusting Operating
2.
Set the parameters.
Parameter
Description
Inactive ARP Timeout
If an ARP cache entry is not refreshed within a specified period, it is

assumed that there is a problem with that address and the cache
entry is deleted. Using the Inactive ARP timeout command enables
you to set the amount of time an ARP entry can remain in an ARP
table before being cleared. You can reset the timeout period to the
default.
Values: 1 - 9999999 seconds
ARP Proxy
Here, a network host answers ARP queries for the network address
that it does not have configured on the receiving interface. Proxying
ARP requests on behalf of another host effectively directs all LAN
traffic destined for that host to the proxying host. The "captured"
traffic is then routed to the destination host via another interface.
Values: Enable (Default), Disable
ICMP Error Messages
The Internet Control Message Protocol (ICMP) is one of the core

protocols of the Internet Protocol Suite and is used by networked
computers' operating systems to send error messages indicating, for
instance, that a requested service is not available or that a host or
router could not be reached.
Values: Enable (Default), Disable
3.
108

Routing Table
AppDirector supports IP routing. Dynamic addition and deletion of IP interfaces is supported. This
ensures that extremely low latency is maintained. The IP router supports RIP 1, RIP 2, and OSPF
routing protocols OSPF and its MIB are supported as specified in RFC 1583 and RFC 1850, with some
limitations. The Routing Table allows you to configure static routing and define the default gateway.
To configure routing
1. From the Router menu, select Routing Table. The Routing Table window appears.
Parameter
Description
Destination IP
Address
Destination network to which the route is defined.
Network Mask
Network mask of the Destination subnet.
Next Hop
IP address of next hop towards Destination subnet. Next hop must

reside on subnet local to the device.
Interface Index
Interface Index number for local interface or VLAN through which the
next hop of this route is reached.
Metric
Number of hops to the Destination network.
Type
Type of route. Each routing table can contain an arbitrary number of

route entries. Aside from the local routing table, which is maintained by
the kernel, and the main routing table which is partially maintained by
the kernel, all routing tables are controlled by the administrator or
routing software. All routes on a machine can be changed or removed.
Each route type causes a particular sort of behavior, which is identified
in the textual description.
Values:
Other types of routes including:
unicast, broadcast, prohibit, blackhole, throw
Remote (Forwards packets) - refers to a route for which the next
hop is not the final destination. Routes which do not result in traffic
forwarding or rejection should not be displayed even if the
implementation keeps them stored internally
Reject (Discards packets) - refers to a route which, if matched,
discards the message as unreachable. This is used in some
protocols as a means of correctly aggregating routes
Local (Read-only) - refers to a route for which the next hop is the
final destination
109

ARP Table
The ARP table contains the IP address and corresponding MAC address (physical address) of each
network element connected to the device. Through the ARP Table, you can monitor, set and edit ARP
addresses on the local router.
To access the ARP Table from WBM

1.
From the Router menu, select ARP Table. The ARP Table window appears.
2.
Set the parameters.
Parameter
Description
Interface Index
The interface number where the station resides.
IP Address
The station's IP address.
MAC Address
The station's MAC address.
Type
Entry type:
Other: Not Dynamic or Static
Invalid: Invalidates ARP entry and effectively deletes it.
Dynamic: Entry is learned from ARP protocol. If the entry is not
active for a predetermined time, the node is deleted from the
table.
Static: Entry has been configured by the network management
station and is permanent.
3.
NHRs
Each host or router handling a packet examines the Destination Address in the IP header, computes
the next hop that will bring the packet one step closer to its destination, and delivers the packet to
the next hop, where the process is repeated. A Next Hop Router (NHR) is a network element used
for outbound traffic in AppDirector Multi Homing configurations. NAT addresses can be associated
with Next Hop Routers (NHRs), similar to the way VIPs are associated with NHRs. The NHR Table
window enables you to list the device's next hop routers.
To access the NHR Table from WBM

1.
From the Router menu, select NHR Table. The NHR Table window appears.
2.
Set the parameters.
110
Parameter
Description
NHR IP Address
IP address of required NHR (next hop router).
NHR MAC Address
MAC address of the NHR.
Device MAC Address
MAC address of the device.

Parameter
Description
Admin Status
Administration status of the NHR, Enable or Disable.
Port Number
Displays the number of the selected management port.
Oper Status
In Service/ Not In Service
Path Health Check IP
IP address of network element to be checked via this NHR to

establish the health status of this router.
Check Method
Method that device uses to verify the NHR's health via the Health
Monitoring Module, Ping or Disable.
Check Interval
Interval, in seconds, between checks.
Check Retries
Amount of checks that the device should perform without reply

before it acknowledges that router is off line.
3. For creating new NHR Table entries, click Create. The NHR Table Create window appears as
above without NHR MAC Address, Device MAC Address, Port Number and Oper Status.
Setting Up Default Router Per VIP

All Next-Hop Routers connected to the AppDirector are defined in the NHR table. NHRs are
associated with the Virtual IP addresses of the device using the VIP NHR table.
The VIP NHR table is enabled only when the packet is destined for the default gateway of the box.
Due to the static route, the packet was not destined for the default gateway so in these instances
the VIP NHR table is not enabled. The NHR per VIP feature works only for traffic that matches the
device's default gateway.
Before defining the VIP NHR table, add a new NHR to the network and set up the general NHR
parameters
VIP NHR
The VIP NHR Table window enables you to associate a next hop router, configured in the NHR Table,
to a virtual IP address configured on the device.
To access the Virtual IP Table

1. From the Router menu, select VIP NHR Table. The VIP NHR Table window appears,.
Parameter
Description
Virtual IP Address
Required Virtual IP address.
NHR IP Address
IP address of the required next hop router.
No Route Action
Determines action if both primary and backup next hop routers are
offline. Values:
Discard: The packets are discarded.
Use Regular Routing: Packets are forwarded using Routing Table.
111

Parameter
Description
NHR Weight
Determines relative amount of total traffic forwarded to the primary

router when Load Sharing is enabled.
Backup NHR
Weight
Determines relative amount of total traffic forwarded to backup router

when Load Sharing enabled.
Backup NHR IP
Address
IP address of the backup next hop router.
NHR Load Sharing
Enable/disable load sharing between primary and backup next hop

routers, based on relative weights.
Layer 3 Hashing: Traffic sent through both configured and backup
NHR. Load sharing is based on Layer 3 information (IP address).
Layer 4 Hashing: Traffic sent through both configured and backup
NHR. Load sharing is based on Layer 4 information (IP address and
port).
Disabled (Default): Traffic sent via configured NHR only.
3.
Click Set. The Virtual IP address is associated with the relevant NHR.
Routing Information Protocol

Routing Information Protocol (RIP) is a commonly-used protocol for managing router information
within a self-contained network, such as a corporate Local Area Network (LAN) or an interconnected
group of such LANs. RIP is classified by the Internet Engineering Task Force (IETF) as one of several
internal gateway protocols (Interior Gateway Protocol). RIP is intended for small homogeneous
networks.
Using RIP, a gateway host (with a router) sends its entire Routing Table, which lists all the other
hosts that it recognizes, to its closest neighbor host every 30 seconds. The neighbor host then
passes the information on to its next available neighbor until all hosts within the network have the
same knowledge of the routing paths. This is known as Network Convergence.
RIP uses a hop count as a means to determine network distance. Each host with a router in the
network uses the Routing Table information to determine the next host to route a packet to a
specified destination. AppDirector supports RIP version 1 and RIP version 2. The RIP protocol is
configured from the RIP Parameters window.
VIP Advertising via Dynamic Routing enables you to achieve a redundant solution by using a single
AppDirector on each site, or by using a single AppDirector and a remote backup server within the
RIP or OSPF environment.
To configure the RIP Parameters

1.
From the Router menu, select RIP > Parameters. The RIP Parameters window appears.
2.
Set the parameters.
112
Parameter
Description
Administrative
Status
Administrative status of RIP in the router.

Disabled (default) means the process is not active on any interfaces.

Parameter
Description
Leak OSPF Routes
This controls leaking (redistribution) of routes from OSPF to RIP. If

enabled, all routes learned via OSPF are advertised into RIP.
Default: Enable
RIP Advertisement
Interval [seconds]
RIP Advertisement interval where AppDirector sends static routes

advertisements via RIP.
Leak Static Routes
Controls redistribution of routes from static routes to RIP. When

enabled, all static routes learned via static are advertised into RIP.
Default: Disable
3. Click Set. Your configuration is set
RIP Interface Parameters

This table window allows you to set and edit RIP interface parameters.
To Update the RIP Interface

1. From the Router menu, select RIP > Interface Parameters. The RIP Interface Parameters
window appears.
Parameter
IP Address
Description
The IP Address of this system on the indicated subnet.
(Read Only when updating)
Incoming RIP
Define type of RIP to be received.

RIP 1: Accepting RIP 1.
RIP 2: Accepting RIP 2.
Do Not Receive: No RIP updates are accepted.
Status
on/off
Outgoing RIP
Define type of RIP to be sent.

RIP version 1: Sending RIP updates compliant with RFC 1058.
RIP version 2: Multicasting RIP-2 updates.
Do Not Send: No RIP updates are sent.
Default Metric
Metric for default route entry in RIP updates originated on this interface.
0 (Zero) indicates that no default route can be originated; here, a
default route through another router is propagated.
Virtual Distance
Virtual number of hops assigned to the interface. This enables finetuning of the RIP routing algorithm.
113

Parameter
Description
Auto Send
Enable to minimize traffic when AppDirector is the only router on the

network.
Note: When enabled, the device advertises RIP messages with the
default metric only. This allows some stations to learn the
default router address. If the device detects another RIP
message, Auto Send is disabled.
3.
Click Set. The changes are reflected in the RIP Interface Table list.
Open Shortest Path First (OSPF)

Open Shortest Path First (OSPF) is an interior gateway routing protocol developed for IP networks
and based on the shortest path first or linkstate algorithm. Routers use link-state algorithms to send
routing information to all nodes in a network by calculating the shortest path to each node based on
a topography of the Internet constructed by each node. After sending the routing information, each
router sends the portion of the routing table (keeping track of routers to particular network
destinations) that describes the state of its own links, and sending the complete routing structure
(topography).Shortest path first algorithms allow you to perform more frequent updates.
With OSPF you can build a more stable network, as fast convergence prevents routing loops and
Count-to-Infinity (when routers continuously increment the hop count to a particular network).
OSPF Operating Parameters
To set the OSPF Operating Parameters

1.
From the Router menu select OSPF > Operating Parameters. The OSPF Operating
2.
Set the parameters.
Parameter
Description
Administrative
Status
OSPF administrative status in the router.

Enabled: OSPF process is active on at least one interface.
Disabled: OSPF process is not active on any interfaces.
3.
114
Router ID
ID number of router. To ensure uniqueness the router ID should equal

one of the router IP addresses.
Leak RIP Routes
Controls the redistribution of routes from RIP into OSPF. When this
parameter is enabled, all routes inserted into the IP routing table via
SNMP are advertised into OSPF as external routes.
Leak Static Routes
Controls redistribution of routes from static routes to RIP. When

enabled, all static routes learned via static are advertised into RIP.
Leak External Direct

Routes
Controls redistribution of direct routes external to OSPF into OSPF. If

enabled, all external routes are advertised into OSPF as external.

OSPF Interface Parameters

The OSPF Interface Parameters window allows you to update the OSPF Parameters and Interface
Metrics.
To update the OSPF Interface Parameters

1. From the Router menu select OSPF > Interface Parameters. The OSPF Interface Parameters
window appears.
2. Select the IP Interface. The OSPF Interface Table Update window appears.
Parameter
Description
IP Address
IP Address of this OSPF interface.
Interface Type
OSPF interface type. Broadcast LANs are broadcast type, x.25 and
Frame Relay are NBMA type, and point-to-point LANs are Point to Point
type.
Administrative
Status
Administrative status of the OSPF in the router. Enabled means that the
OSPF process is active on at least one interface. Disabled means the
process is not active on any interfaces.
IfRtrPriority
Priority of this interface. Value 0 means that this router is not eligible to
become the designated router on the current network. If more than one
router has the same priority then router ID is used.
Hello Interval
Number of seconds between Hello packets. All routers attached to a

common network must have the same Hello Interval.
RtrDeadInterval
Number of seconds router's Hello packets have not been seen before
router's neighbors declare the router down. The Time Before Declare
Router Dead value must be a multiple of the Hello Interval. All routers
attached to a common network must have a Time Before Declare
Router Dead value.
Interface State
The interface state of the OSPF interface:

Down: OSPF interface is down.
Waiting: OSPF interface is currently waiting.
Point to Point: OSPF interface is in point to point state.
Designated Router: OSPF interface is the designated router.
Backup Designated Router: OSPF interface is the backup
designated router.
Designated Route
Address of designated router, if Interface state is Designated Router.
Backup Designated
Router
Address of the backup designated router, in case Interface state is

Backup Designated Router.
IfAuthKey
Authentication key for the interface.
AuthType
Type of authentication key for the interface.
115

OSPF Interface Metrics Table Update

If you wish to update the metrics for the OSPf interface, use this feature.
To update the OSPF Interface Metrics

1.
Select the OSPF interfaceIP Interface. The OSPF Interface Metrics Table Update window
appears.
2.
Set the parameters.
3.
Parameter
Description
IP Address
Metric
The metric of using this type of service on this interface. The default
value of the TOS 0 Metric is 10.
Reset the Metric value.
Parameter
Description
IP Address
Interface Type
OSPF interface type. Broadcast LANs are broadcast type, x.25 and
Frame Relay are NBMA type, and point-to-point LANs are Point to
Point type.
Administrative
Status
Administrative status of the OSPF in the router. Enabled means that

the OSPF process is active on at least one interface. Disabled means
the process is not active on any interfaces.
IfRtrPriority
Priority of this interface. Value 0 means that this router is not eligible
to become the designated router on the current network. If more
than one router has the same priority then router ID is used.
Hello Interval
Number of seconds between Hello packets. All routers attached to a

common network must have the same Hello Interval.
RtrDeadInterval
Number of seconds router's Hello packets have not been seen before
router's neighbors declare the router down. The Time Before Declare
Router Dead value must be a multiple of the Hello Interval. All
routers attached to a common network must have a Time Before
Declare Router Dead value.
Interface State
The interface state of the OSPF interface:

Down: OSPF interface is down.
Waiting: OSPF interface is currently waiting.
Point to Point: OSPF interface is in point to point state.
Designated Router: OSPF interface is the designated router.
Backup Designated Router: OSPF interface is the backup
designated router.
116
Designated Route
Address of designated router, if Interface state is Designated Router.
Backup Designated
Router
Address of the backup designated router, in case Interface state is

Backup Designated Router.

Parameter
Description
IfAuthKey
Authentication key for the interface.
AuthType
Type of authentication key for the interface.
4. Click Set. Your configuration is recorded.
OSPF Area Parameters

An OSPF network is divided into areas, which have 32-bit area identifiers commonly, but not always,
written in the dotted decimal format of an IP address. Area identifiers are not IP addresses and may
duplicate, without conflict, any IP address. The OSPF Area Parameters window allows you to access,
create and update OSPF area parameters.
To access OSPF Area Parameters

1. From the Router menu, select OSPF > Area Parameters. The OSPF Area Parameters Table
window appears.
Parameter
Description
Area ID
IP address of the area.
Import AS Extern
Ability to import autonomous system external link advertisements.

Values:
importExternal, importNoteExternal
Number of AS
Border Routers
Total number of Autonomous System border routers reachable within

this area. This is initially 0 and calculated in each SPF pass.
(Update mode
only)
Area LSA Count
Number of internal link-state advertisements in the link-state database.
(Update mode
only)
Area LSA
Checksum Sum
(Update mode
only)
Sum of LS checksums of internal LS advertisements contained in the LS

database. Use this sum to determine if there has been a change in a
router's LS database, and to compare the LS database of two routers.
3. When updating Area Parameters, in the OSPF Area Parameters Table window, select the Area
ID.
4. When creating Area Parameters, in the OSPF Area Parameters Table window, select Create.
5. Click Set. Your changes are recorded.
117

OSPF Link State Database

OSPF uses both unicast and multicast to send Hello packets and link state updates. The OSPF Link
State Database window allows you to access, create and update the OSPF Link State Database.
OSPF detects changes in the topology, such as link failures, very quickly and converges on a new
loop-free routing structure within seconds. For this, each OSPF router collects link-state information
to construct the entire network topology of so-called "areas" from which it computes the shortest
path tree for each route. The link-state information is maintained on each router as a link-state
database (LSDB) which is a tree-image of the network topology. Identical copies of the LSDB are
periodically updated through flooding on all routers in each OSPF-aware area.
To access OSPF Link State Database

1.
From the Router menu, select OSPF > Link State Database. The OSPF Link State Database
window appears.
2.
Set the parameters.
Parameter
Description
Area ID
IP address of the area.
Type
Each link state advertisement has a specific format. The link can be a
Router Link, Network Link, External Link, Summary Link or Stub Link.
Link State ID
Identifies a piece of routing domain described by the advertisement.

It can be a router ID or an IP address.
Router ID
Identifies the originating router in autonomous system.
Sequence
Number for link. Use this to detect old and duplicate link state
advertisements. The larger the sequence number the more recent the
advertisement.
3.
When updating Link State Database, in the OSPF Link State Database window, select the Area
ID.
4.
When creating Link State Database, in the OSPF Link State Database window, select Create.
5.
OSPF Neighbor Table

As a link state routing protocol, OSPF establishes and maintains neighbor relationships to exchange
routing updates with other routers. The neighbor relationship table is called an adjacency database
in OSPF. If OSPF is configured correctly, it forms neighbor relationships only with directly connected
routers. These routers must be in the same area as the interface to form a neighbor relationship. An
interface can only belong to a single area. This table allows you to access, create and update OSPF
Neighbor parameters.
118

To access OSPF Neighbor Table

1. From the Router menu, select OSPF > Neighbor Table. The OSPF Neighbor Table window
appears.
2. You can view the following parameters.
Parameter
Description
Neighbor's
Address
The IP address that this neighbor is using in its IP Source Address.
Address Less
Index
If interface is without an IP address, index appears in this field. If there

is an IP address, 0 appears.
Router ID
Unique identifier for neighboring router in the autonomous system.
Options
A bit mask corresponding to the neighbor's options.
Priority
Priority of this neighbor. Priority of 0 means neighbor cannot become

designated router on the network.
Note: On addressless links, this will not be 0.0.0.0, but the address
of another of the neighbor's interfaces.
3. When updating OSPF Neighbor Table, in the OSPF Neighbor Table window, select the
Neighbors Address.
4. When creating OSPF Neighbor Table, in the OSPF Neighbor Table window, select Create.
Border Gateway Protocol

The Border Gateway Protocol (BGP) is the core routing protocol of the Internet. It works by
maintaining a table of IP networks or 'prefixes' which designate network reachability among
autonomous systems (AS). It is described as a path vector protocol. BGP does not use traditional
Interior Gateway Protocol (IGP) metrics, but makes routing decisions based on path, network
policies and/or rulesets.
Most Internet users do not use BGP directly. However, since most Internet service providers must
use BGP to establish routing between one another (especially if they are multihomed), it is one of
the most important protocols of the Internet. Very large private IP networks use BGP internally. An
example would be the joining of a number of large Open Shortest Path First (OSPF) networks where
OSPF by itself would not scale to size. Another reason to use BGP is Multihoming, (page 392),a
network for better redundancy either to multiple access points of a single ISP or to multiple ISPs.
BGP Router Parameters

Dynamic routing protocols, such as Border Gateway Protocol, announce and distribute routing
information between routers. AppDirector provides a redundant solution by using AppDirector and a
remote backup server that participate in the BGP environment. AppDirector works as a BGP peer,
supporting a single BGP instance (local AS), and does not route traffic based on BGP information.
From the BGP Route Injection Parameters window the BGP Router Parameters can be set.
119

To set BGP Router Parameters

1.
From the Router menu select BGP Route Injection > Router BGP Parameters. The Router
BGP Parameters window appears.
2.
Set the parameters.
Parameter
Description
BGP Admin Status
Allows administrators to enable or disable the BGP.
Local Autonomous
System Number
Defines AppDirector's Autonomous System number.
Initial Connection Delay

Time
Time to wait (in seconds) at device startup before establishing

BGP connections.
Values: 15 - 120 seconds
3.
BGP Peer Groups

The major benefit you achieve when you specify a BGP peer group is that a BGP peer group reduces
the amount of system resources (CPU and memory) necessary in an update generation. In addition,
a BGP peer group also simplifies the BGP configuration. A BGP peer group reduces the load on
system resources by allowing the routing table to be checked only once, and updates to be
replicated to all peer group members instead of being done individually for each peer in the peer
group. Based on the number of peer group members, the number of prefixes in the table, and the
number of prefixes advertised, this can significantly reduce the load. It is recommended that you
group together peers with identical outbound announcement policies.
You can group BGP neighbors who share the same outbound policies together in what is called a BGP
peer group. Instead of configuring each neighbor with the same policy individually, a peer group
allows you to group the policies which can be applied to individual peers thus making efficient
update calculation along with simplified configuration.
Peer groups have these requirements:
All members of a peer group must share identical outbound announcement policies (such as
distribute-list, filter-list, and route-map), except for default-originate, which is handled on a perpeer basis even for peer group members.
You can customize the inbound update policy for any member of a peer group.
A peer group must be either internal (with internal BGP (iBGP) members) or external (with
external BGP (eBGP) members). Members of an external peer group have different autonomous
system (AS) numbers.
Notes:
The total number of BGP peers and the configurable limit and the maximum number of
established BGP peers that are supported on a router depends on many variables, such as:
>> Total number of routes in the BGP table
>> Level of stability of the routes
>> Number of routes sent to each peer
>> Similarity between routes sent to different neighbors
120

>> Devices available memory and processor power
Peer Table
BGP neighbors, or peers, are established by manual configuration between routers to create a TCP
session on port 179. A BGP speaker will periodically send 19-byte keep-alive messages to maintain
the connection (every 60 seconds by default). Among routing protocols, BGP is unique in using TCP
as its transport protocol.
The BGP Peer Table reflects information about BGP peer connections, such as their status and
current activity.
To create/edit a BGP Peer Table

1. From the Router menu, select BGP Route Injection > Peer Table. The Peer Table window
appears.
2. For updating a BGP Peer, in the Peer Table window, select the Peer IP Address.
3. For creating a BGP Peer, click Create. The BGP Peer Table Create window.
Parameter
Description
Peer IP Address
IP address of the remote peer.
Admin Status
Allows administrators to enable or disable the peer.
Connect Retry
Interval
Interval where AppDirector will try to re-establish a BGP connection

with remote peer after TCP failure event.
Hold Time (sec)
Defines hold time offered by AppDirector during BGP connection

establishment.
During hold time, a peer must receive a keepalive or an update
message from the remote peer to consider the BGP connection active.
Zero (0) indicates that keepalive will not be sent by AppDirector and
AppDirector will not expect keepalive messages from remote peer.
Keep Alive Time

(sec)
Time interval used by AppDirector for sending keepalive messages to

the remote peer. Zero (0) indicates that keepalive messages are not
sent.
Peer Statistics
The routing tables managed by a BGP implementation are adjusted continually to reflect changes in
the network, such as links breaking and being restored or routers going down and coming back up.
In the network as a whole it is normal for these changes to happen almost continuously, but for any
particular router or link changes are supposed to be relatively infrequent. Therefore AppDirector
users need to monitor the BGP statistics from the BGP Peer table.
121

To access the Peer Table statistics

1.
From the Router menu select BGP Route Injection > Statistics. The Statistics window
appears.
2.
Select the Peer IP Address. The BGP Peer Table Statistics Update window appears.
3.
Set the parameters.
Parameter
Description
Peer IP Address
IP address of the remote peer.
Admin Status
Allows administrators to enable or disable the peer.
Connection State
Idle: The Peer is stopped.

Connect: AppDirector initiated a TCP connection to remote peer.
Active: Peer is waiting during a connect retry interval, after
failing to establish TCP connection to a remote peer. In this state,
AppDirector also listens on port 179 for potential incoming
connections from the remote peer.
OpenSent: A TCP connection is established with the remote
peer. AppDirector sent a BGP OPEN message to the remote peer
and expects to receive an OPEN message from it.
OpenConfirm: AppDirector received an OPEN message from the
remote peer. AppDirector responds with a KEEPALIVE message
and expects a KEEPALIVE message from the remote peer.
Established: BGP connection is established with remote peer.
AppDirector can now exchange UPDATE messages with it.
122
Remote AS
Remote autonomous system number.
Peer Identifier
IP address identifies remote peer for current BGP connection.
Local Address
AppDirector IP interface address used as source IP for BGP

connection.
Local Port
TCP source port number used by AppDirector for BGP connection to

remote peer.
In/Out Updates
The number of BGP UPDATE messages transmitted on this

connection. This object should be initialized to zero (0) when the
connection is established.
In/Out Total
Messages
The total number of messages received from/transmitted to the

remote peer on this connection. This should be initialized to zero
when the connection is established.
Last Error
The last error code and subcode seen by this peer on this connection.
If no error has occurred, this field is zero. Otherwise, the first byte of
this two byte OCTET STRING contains the error code, and the second
byte contains the subcode.
FSM Established
Transitions
The total number of times the BGP FSM transitioned into the
established state.

Parameter
Description
FSM Established
Time
This timer indicates how long (in seconds) this peer has been in the
established state or how long since this peer was last in the
established state. It is set to zero when a new peer is configured or
the router is booted.
Connect Retry
Interval (sec)
Interval in which AppDirector tries to re-establish BGP connection

with remote peer after TCP failure event.
Hold Time (sec)
Defines hold time offered by AppDirector during a BGP connection

establishment. During this time, a peer must receive a keepalive or
an update message from the remote peer to consider the BGP
connection active. Zero (0) indicates that keepalive messages will not
be sent by AppDirector and AppDirector will not expect keepalive
messages from the remote peer.
Keep Alive Time

(sec)
Time interval used by AppDirector for sending keepalive messages to

the remote peer. Zero (0) indicates that keep alive messages are not
sent.
Hold Time
Configured
Time interval in seconds for the Hold Time configured for this BGP
speaker with this peer. This value is placed in an OPEN message sent
to this peer by this BGP speaker, and is compared with the Hold Time
field in an OPEN message received from the peer when determining
the Hold Time (bgpPeerHoldTime) with the peer. This value must not
be less than three seconds if it is not zero (0) in which case the Hold
Time is NOT to be established with the peer. The suggested value for
this timer is 90 seconds
Keep Alive
Configured
Time interval in seconds for the KeepAlive timer configured for this
BGP speaker with this peer. The value of this object will only
determine the KEEPALIVE messages' frequency relative to the value
specified in bgpPeerHoldTimeConfigured; the actual time interval for
the KEEPALIVE messages is indicated by bgpPeerKeepAlive. A
reasonable maximum value for this timer would be configured to be
one third of that of bgpPeerHoldTimeConfigured. If the value of this
object is zero (0), no periodical KEEPALIVE messages are sent to the
peer after the BGP connection has been established. The suggested
value for this timer is 30 seconds.
In Update Elapsed
Time (sec.)
Elapsed time in seconds since the last BGP UPDATE message was
received from the peer. Each time bgpPeerInUpdates is incremented,
the value of this object is set to zero (0)
Redundancy
This section introduces AppDirector redundancy capabilities and includes the following topics:
Network Configurations, page 125.
Configuration Guidelines, page 128.
Global Redundancy Configuration, page 134
Proprietary Redundancy, page 147.
Failover Decision, page 136.
Stateful Failover (Mirroring), page 140.
123

Physical IP Addresses versus Virtual IP Addresses Redundancy, page 142.
Virtual Router Redundancy Protocol, page 142.
Proprietary Redundancy, page 147.
Configuration Synchronization, page 148

Internet
Router
Users
Network A
Port 1
MAC A
virtual IP 1
AppDirector 1
Port 2
MAC B
Port 1
MAC C
IP A 1
IP B 1
IP A 2
virtual IP
AppDirector 2
Port 2
MAC D
IP B 2
Network B
Server 1
Server 2
Radware recommends installing AppDirector devices in pairs to provide fault tolerance in the case of
a single device failure. Each pair of AppDirectors can function in an active/backup setup or active/
active setup.
To achieve redundancy between pairs of AppDirector devices, the following methods are supported:
VRRP: Working with Virtual Router Redundancy Protocol enables dynamic redundancy to be
maintained using a logical entity called a virtual router. (VRRP was initially developed to provide
high availability for routers, hence the name virtual router. However, this protocol can be
supported by a wide range of devices that are not routers as it is not a routing protocol - it does
not advertise IP routes or affect the routing table in any way). With VRRP, IP addresses are
associated with the Virtual MAC addresses that are owned by the main device, and are taken
over by the backup device at fail-over time.
Proprietary ARP: Working with Address Resolution Protocol enables monitoring of the other
device in a pair and checking its availability. Using Proprietary ARP redundancy, at the failover
time, the IP addresses of the main device are managed by the backup device and are associated
with the backup devices MAC address.
Note: Radware recommends using VRRP as described above for AppDirector redundancy.
124

Network Configurations
The network configuration affects the redundancy configuration. The following network
configurations are supported by AppDirector.
Routing
Client side and server side (as shown here) are on different networks.
Figure 1: Routing network configuration
125

Bridging
Client side and server side (as shown here) are on the same network. The physical port connected to
the client side and the physical port connected to the server side must belong to the same Regular
VLAN to achieve bridge configuration.
Figure 2: Bridge network configuration
Fully Redundant Network Configuration

In certain cases, full redundancy of all network elements is required to ensure that the configuration
supports failures of multiple network elements. This is also to ensure that the configuration can
handle failures without needing to failover between AppDirector devices, as long as primary
AppDirector is available.
Notes:
>> This type of configuration can be supported only when using VRRP redundancy
mechanism.
>> RSTP (Rapid Spanning Tree Protocol) should be configured on AppDirector devices to
prevent loops. (This type of configuration requires using a Switch VLAN on the
AppDirector devices).
>> These types of configurations are not supported on OnDemand Switches VL and 1
platforms.
Here, the servers are either directly connected to both AppDirector devices (dual-NIC servers) or to
two switches that are connected to both AppDirector devices. On the client side, full redundancy is
achieved by either connecting each AppDirector to a different upstream router or connecting each
AppDirector to the two upstream routers (or Layer 3 switches) that run STP.
For these types of configurations, AppDirector needs the following routing configuration
126
The two AppDirectors must be connected via two separate links.

One of the physical ports used for inter-AppDirector connectivity and the physical port to which
the client side is connected are attached to an IP Switch VLAN (shown in Figure 3 - Fully
redundant routing network configuration, page 127). This allows the primary AppDirector to
continue to be active and receive client traffic even when its direct connection to the router (or
the router itself) fails.
One of the physical ports used for inter-AppDirector connectivity and the physical port to which
the server side is connected are attached to another IP Switch VLAN (blue marking on Figure 3).
This allows the primary AppDirector to continue to be active and see the servers even when its
direct connection to the servers or their switch (or the switch itself) fails.
Figure 3: Fully redundant routing network configuration
Bridge Configuration
The two AppDirectors must be connected via one link
The physical port used for inter-AppDirector connectivity and the physical port to which the
server side is connected are attached to an IP Switch VLAN (blue marking on Figure 4). This
allows the primary AppDirector to continue to be active and see the servers even when its direct
connection to the servers or their switch (or the switch itself) fails.
The physical port to which the client side is connected and the server side Switch VLAN are
attached to a Regular VLAN (green marking on Figure 4).
127

Figure 4: Fully redundant Bridge network configuration
Configuration Guidelines
The configuration needed in redundant environments depends on the following factors:
Redundancy configuration: Active-Backup or Active-Active
Network configuration: Routing or Bridging
VRRP Preemption state: enabled or disabled
Note: A fully redundant network environment only affects the required inter-AppDirector
connectivity and Layer 2 configuration as described in Fully redundant network
configuration section. The rest of the redundancy configuration parameters are affected
by the factors mentioned above.
This chapter provides configuration guidelines for the different cases above.
Active-Backup Routing Configuration

In an Active/Backup configuration, the primary AppDirector device is configured with the primary
Virtual IP addresses. This device performs the regular AppDirector operations, handling all the
inbound sessions to the Virtual IP addresses and distributing traffic among the servers in the farm
linked to the Virtual IP address (via Layer 4 Policy).
The backup AppDirector device is configured with identical Virtual IP addresses that contain the
exact same Layer 4 Policies, servers and farm settings. This device acts as a hot standby and does
not perform load balancing as long as the primary device is active. When the backup AppDirector
detects that the primary AppDirector has failed, the backup device takes over the IP addresses of its
primary partner, informing all devices on the network that the backup device is now responsible for
the services of the primary device.
128

When the primary device is back online, the backup device releases the services if VRRP preemption
is enabled (default) or if a proprietary redundancy protocol is used. If VRRP preemption is disabled,
the backup device will remain active as long as it is online.
Figure 5: Active Backup
Parameters
Global Parameters
Primary
Secondary
Redundancy Admin
Status
VRRP
Same as primary
Interface Grouping
Enable
Same as primary
Backup Interface
Grouping
Enable
Same as primary
Backup in VLAN
N/R - use default
Same as primary
Force Port Down
N/R - use default
Same as primary
129

Parameters
VRID Internet Side
Primary
Secondary
VRID
Same as primary
If Index
Same as primary
Primary IP
100.1.1.10
Same as primary
Priority
200
100
Preempt Mode
Same for all VRIDs
Same as primary
Associated IPs
100.1.1.100,
Same as primary
100.1.1.10
Outbound NAT
addresses, if relevant
VRID Server Side
VRID
Same as primary
If Index
Same as primary
Primary IP
20.1.1.10
Same as primary
Priority
200
100
Preempt Mode
Same for all VRIDs
Same as primary
Associated IPs
20.1.1.10
Same as primary
Client NAT addresses, if

relevant
Mirroring
Mirroring Status
Disabled (if
preemption is
enabled).
Enabled
Enabled (if
preemption is
disabled).
Mirror Device IP
1.1.1.12
Default
Mirrored Tables
Client Table
Same as Primary
Session ID Table
Proximity and DNS
Persistency for
geographically
distributed solution
Active-Active Routing configuration

AppDirector devices can also be configured to function in an Active/Active mode where each
AppDirector is the primary provider of some services and a backup for the services provided by the
other AppDirector in the pair. In this case, both devices are set up as primary AppDirector for one or
more Virtual IPs and as backup AppDirector for the Virtual IPs for which the other unit is primary.
130

When one of the devices fails, the other continues to handle traffic to its own Virtual IPs while
assuming responsibility for the backup devices Virtual IPs.
Note: Using the Active/Active setup, each server can provide service to Virtual IPs that are
active on one device. A server cannot provide service to multiple Virtual IPs where one
Virtual IP is active on one device, while another Virtual IP is active on another device.
Figure 6: Active-Active Routing Configuration
Parameters
Global Parameters
AppDirector 1
AppDirector 2
Redundancy Admin
Status
VRRP
Same as AppDirector 1
Interface Grouping
Enable
Backup Interface
Grouping
Enable
Backup in VLAN
N/R - use default
Same as primary
Force Port Down
N/R - use default
Same as primary
131

Parameters
VRID Internet Side
for VIP active on
AppDirector 1
AppDirector 1
AppDirector 2
VRID
If Index
Primary IP
100.1.1.10
Priority
200
100
Preempt Mode
Same for all VRIDs
Associated IPs
100.1.1.100,
100.1.1.10
Outbound NAT addresses
(if relevant)
VRID Server Side
for VIP active on
AppDirector 1
VRID
If Index
Primary IP
20.1.1.10
Priority
200
100
Preempt Mode
Same for all VRIDs
Associated IPs
20.1.1.10
Client NAT addresses (if

relevant)
VRID Server Side
for VIP active on
AppDirector 2
VRID
If Index
Primary IP
30.1.1.10
Priority
100
200
Preempt Mode
Same for all VRIDs
Associated IPs
30.1.1.10
Client NAT addresses (if

relevant)
Mirroring
Mirroring Status
Disabled (if
preemption is
enabled).
Enabled
Enabled (if
preemption is
disabled).
Mirror Device IP
1.1.1.12
Default
Mirrored Tables
Client Table
Session ID Table
Proximity and DNS
Persistency for
geographically
distributed solution
132

Active-Backup Bridging configuration

Figure 7: Active-Backup Bridging Configuration
Parameters
Global Parameters
VRID
Primary
Secondary
Redundancy Admin
Status
VRRP
Same as primary
Interface Grouping
Enable
Same as primary
Backup Interface
Grouping
Enable
Same as primary
Backup in VLAN
Block Broadcast
Same as primary
Force Port Down
Enable
Same as primary
VRID
Same as primary
If Index
1001
Same as primary
Primary IP
100.1.1.10
Same as primary
Priority
200
100
Preempt Mode
Same for all VRIDs
Same as primary
Associated IPs
100.1.1.100,
Same as primary
100.1.1.10
133

Parameters
Mirroring
Mirroring Status
Primary
Secondary
Disabled (if
preemption is
enabled).
Enabled
Enabled (if
preemption is
disabled).
Mirror Device IP
1.1.1.12
Default
Mirrored Tables
Client Table
Same as Primary
Session ID Table
Global Redundancy Configuration

You can configure more than one AppDirector device on a network so that they back up one another.
If there is a failure of any network interface, AppDirector will fail the whole device, and the backup
device, previously handling its own farms, will take over all activity. The Global Configuration
window allows you to enable a backup device.
Before starting redundancy configuration, the role of each AppDirector must be set via CLI
command.
To access AppDirector Global Redundancy

Go to AppDirector > Redundancy > Global Configuration. The Global Redundancy
Configuration window appears.
134

To configure global redundancy parameters

1. From the AppDirector menu, select Redundancy > Global Configuration. The Global
Redundancy Configuration window appears.
Parameter
Description
IP Redundancy Admin Each pair of AppDirectors can function in an active/backup setup or

Status
active/active setup. To achieve redundancy between pairs of
AppDirector devices, these methods are used:
Disable (default)
VRRP: Working with Virtual Router Redundancy Protocol enables
dynamic redundancy to be maintained using a logical entity called
a virtual router.
Proprietary [ARP]: Working with ARP enables you to monitor the
other device in a pair and check its availability. Using Proprietary
ARP redundancy, at failover time, the main device IP addresses are
managed by the backup device and are associated with the backup
devices MAC address.
Interface Grouping
Ensures that if one port fails, the others are also taken down. When it
is enabled, the backup device takes over only when all the interfaces of
the main device are down.
Default: Disabled
ARP with Interface

Grouping
Defines whether device can send ARP requests (when device is the
backup device) with active interface grouping.
Send (Default)
Avoid
Backup Device in
VLAN
When AppDirector is installed in a bridge configuration, this defines

how the device behaves when its redundancy state is set to backup.
Values:
Forward Traffic - Forward all traffic. This is the default value, but
should be used only when the device is in routing configuration.
Block Broadcast -When the device is in backup state broadcast
traffic is blocked in order to prevent loops.
Block All - When the device is in backup state, all traffic is blocked
in order to prevent loops. This cannot be used in a fully redundant
network configuration.
Backup Fake ARP
Backup Fake ARP: Enables the backup device to perform a fake ARP.
Default: Enabled
Note: In networks with layer 3 switches, the Fake ARP will confuse the
switch during the redundancy process. In this case, disable this option.
Backup Interface
Grouping
When it is enabled the backup will take over only when IP interfaces
defined in its Redundancy Table fail.
Respectively, it will release those interfaces only when all the main's
interfaces are up.
135

Parameter
Description
VRRP Advertise
Interval [msec.]
Interval that the main device sends active messages.

Values: 100 - 25,000
Default: 0 msec.
Note: Configuring the specific advertisement interval value for a
VRRP entry is only possible when the global value is set to 0.
When the global value is not 0, the specific values for VRRP
entries are discarded and the global value is used. See Virtual
Router Redundancy Protocol, page 142.
VRRP Automated
AppDirector can automatically add a new Virtual IP configured on the
Configuration Updates device to the VRRP Associated IP Addresses table.
When the Automated VVRP Configuration feature is enabled and a layer
4 policy is configured that uses a new Virtual IP, this IP is automatically
associated with the VRID defined for the AppDirector interface that
belongs to the same subnet as the Virtual IP.
Messages are sent to the device log announcing that a Virtual IP was
automatically associated to a specific VRID and interface.
Values: Enabled or Disabled (Default).
Force Down Ports
Time
The period of time for which the port must be down.

Values: 0 (the feature is disabled) or 5 - 60 seconds.
When enabled, the value depends on how long it takes the switch to
clear its MAC tables.
Failure Action
This defines when Proxy related failures will induce failover in an

active-backup configuration.
Accel-engine Fail: Acceleration engine failure.
SSL or Accel-engine Fail: SSL accelerator or Acceleration engine
failure.
Compression or Accel-engine Fail: Hardware Compression Card or
Acceleration engine failure.
SSL or Compression or Accel-engine Fail: SSL Accelerator,
Hardware Compression Card or Acceleration engine failure.
Ignore (default): Ignore failures and do not perform failover.
3.
Ensure that IP Redundancy Admin Status is enabled, unless the network is a one-legged
configuration.
4.
Ensure that Interface Grouping is disabled.
5.
Failover Decision
Failover is a backup operational mode in which the functions of a system component (such as a
processor, server, network, or database, for example) are assumed by secondary system
components when the primary component becomes unavailable through either failure or scheduled
136

down time. Used to make systems more fault-tolerant, failover is an integral part of mission-critical
systems that must be constantly available. The procedure involves automatically offloading tasks to
a standby system component so that the procedure is as seamless as possible to the end user.
Failover decision is taken by a backup AppDirector when:
The active device fails
One or more interfaces fail on the active device.
Application Acceleration modules fail on active device
Interface Grouping
When AppDirector notices that one of its physical ports is down, if Interface Grouping is enabled, it
intentionally brings all other active ports down.
When an interface (physical port, trunk or VLAN) on AppDirector goes down, due to a cable failure,
switch port failure, hub failure, or other problems, AppDirector performs the following:
1. AppDirector examines the configuration to see if any IP addresses were configured on the
interface that went down.
2. If there were IP addresses configured on the interface, AppDirector deactivates all other active
interfaces.
3. If no IP addresses were configured on the interface, nothing occurs and normal operation
continues.
Notes:
>> You can configure per physical port whether it triggers Interface Grouping or not
(Selective Interface Grouping).
>> A trunk or VLAN failure always triggers Interface Grouping, but for each VLAN you can
configure per physical port whether it affects VLAN status for Interface Grouping or not
(see Adding Physical Ports to a VLAN).
>> The dedicated management ports failure will not trigger Interface Grouping.
Backup Interface Grouping

To prevent cases where partial failover can occur the backup device should take control only if ALL
the relevant interfaces of the main device are out of service, and releases those interfaces only
when all the main device interfaces are back up.
The backup device takes control only if ALL the interfaces of the primary device are out of service.
This solves the problem of an active and a backup device, each connected to a switch, where the
switches are cross-connected.
When the cable that cross-connects the switches fails, this is not communicated to the primary
device. As a result, Interface Grouping is not triggered, but since the backup device cannot
communicate with the primary device, the backup device takes over. This causes downtime in the
service.
When the Backup Interface Grouping parameter is enabled, the backup device takes over only when
all IP interfaces defined in its Redundancy Table (or VRID Table) fail, and releases those interfaces
only when all the primary device interfaces are back up.
When Backup Interface Grouping is not activated, the backup device takes control for each interface
of the main device if it is out of service. Once the respective interface of the main device is available,
the backup device releases this interface.
137

ARP in Interface Grouping

Determines whether the device can send ARP requests (to servers for example) while interface
grouping is active; also see the parameter in Global Redundancy Configuration, page 134.
Backup Device and Interface Grouping Behavior in VLAN

Using redundancy in bridging environment (Regular VLAN), the backup device must remain
completely silent on the network to prevent broadcast storms. This behavior should be enabled
using the Backup Device in VLAN parameter in Global Redundancy Configuration, page 134.
The VLAN status sets the Interface Grouping behavior (a VLAN that goes down triggers Interface
Grouping), but the Selective Interface Grouping settings of specific ports within the VLAN are
ignored.
However, VLAN behavior based ports status can be controlled via the following configurations:
Up/Down Criterion: Per VLAN you can configure when the VLAN is considered up/down based
on the number of its ports that are up/down.
Port Interface Grouping State: For each port that is attached to a VLAN you can configure
whether its status will be included or excluded from Up/Down Criterion calculations.
138

Selective Interface Grouping

In AppDirector redundancy installations, primary and redundant AppDirectors can have separate
interfaces solely for management purposes and not for handling the traffic. When one of the
management ports is down and Interface Grouping is enabled, the backup device takes over.
To avoid this, you can use Selective Interface Grouping, where AppDirector defines which interfaces
initiate Interface Grouping and which do not. In the Selective Interface Grouping table, you can
define whether each interface initiates Interface Grouping if the management port is down. All the
interfaces for which VRs are defined are included in Selective Interface Grouping. This feature allows
you to enable interface grouping on a selected port.
To enable interface grouping on a selected port

1. From the AppDirector menu, select Redundancy > Selective Interface Grouping. The
Selective Interface Grouping window appears.
2. Select the desired Port Number. The Selective Interface Grouping Update window appears.
Parameter
Description
Port Number
Select the relevant port number.
Port Status
Define for each interface whether to be included.

Included (default): port status can determine the VLAN status.
Excluded: port status cannot determine the VLAN status.
Notes:
when a port has an IP address, and a VRID assigned to it and is set
to excluded, and then disconnected, it will still initiate a failover.
when a port has an IP address assigned to it, but no VRID, and is
set to include, and that disconnected, it does not initiate a
failover.
Application Acceleration Module Failover
AppDirector can also initiate failover on Application Acceleration capability failure, either Application
Acceleration Engine or hardware SSL Acceleration card or hardware Compression card.
When such a failure occurs on the active AppDirector, the device enters the same mode as Interface
Grouping and failover occurs.
139

Stateful Failover (Mirroring)

Stateful failover allows a backup device to take over when a primary device fails, without dropping
existing sessions or breaking persistency. Stateful failover is provided by mirroring the content of
the tables that define a session.
There are 3 Mirroring procedures that you can perform, they are:
Active Device Mirroring, page 140
Backup Device Mirroring, page 141
Mirroring Device Parameters, page 141
For effective and reliable mirroring you need to:
Provide a direct connection between the two devices.
Configure an IP interface on each device for the direct connection port and address used as the
Mirroring Device Address for the other device.
Exclude physical port used for inter-device communication from Interface grouping.
Use a trunk (link aggregation) for direct connection between two devices.
Notes:
>> Mirroring is not supported when delayed binding is used with L7 Persistent Switching
Mode and configured to either overwrite or maintain.
>> Mirroring is supported for the Layer 7 Persistent Switching Mode named First.
>> Client entries that are not mirrored are RADIUS client entries.
Mirroring can handle long and short sessions and support HTTP traffic. The following are mirrored:
Dynamic Session ID Table
DNS Persistency Table (AppDirector Global Only)
Proximity table
Active Device Mirroring
To set up device mirroring

1.
From the AppDirector menu, select Redundancy > Mirroring > Active Device Parameters.
The Mirroring: Active Device Parameters window appears.
2.
Set the parameters.
Parameter
Description
Proximity Table Mirroring
Enable or Disable (Default) Proximity Table Mirroring.

Table Mirroring
Enable or Disable (Default) Dynamic DNS Persistency Table

Mirroring.
Client Table Mirroring
Enable or Disable (Default) Client table Mirroring.

Note: Client entries that are not mirrored are RADIUS client
entries. They are not supposed to be mirrored.
Session Id Table Mirroring Enable or Disable (Default) Session Id Table Mirroring.

3.
140
Click Set. Your changes are recorded.

Backup Device Mirroring
To set up backup device mirroring

1. From the AppDirector menu, select Redundancy >Mirroring > Backup Device Parameters.
The Mirroring: Backup Device Parameters window appears.
2. Set the parameter.
Parameter
Description
Mirroring Status
Enable or Disable (Default)
Mirroring Device Parameters
To set up mirror device parameters

1. From the AppDirector menu, select Redundancy >Mirroring > Mirror Device Parameters.
The Mirror Device Parameters window appears.
Parameter
Active Device IP
Description
IP address of the device to mirror from.
Notes:
>> When setting up Mirroring, Radware recommends using the same AppDirector software
version for the main and backup devices.
>> Setting up Mirroring affects the general device performance.
>> Radware recommends that mirroring is used for Stateful Failover with the VRRP
redundancy mechanism.
To fail the main AppDirector, use one of the following:

Using a Web Based Management window: AppDirector > Redundancy >VRRP > Virtual
Routers, using the All VRIDs Up or All VRIDs Down options.
OR by CLI command: redundancy vrrp global-admin-status
141

Force Port Down

When operating in VRRP configuration, this capability allows to force down electrically, for a short
period, physical ports belonging to a VLAN when the VLAN is disabled due to Interface Grouping
activation. This allows the switches to which these ports are connected to clear their MAC tables and
prevents them from continuing to send traffic to the wrong AppDirector device.
This capability can be configured (AppDirector -> Redundancy -> Global Configuration) or CLI
(redundancy force-down-ports-time command) via the following parameter.
Parameter
Description
Force Down Ports Time
The period of time for which the port must be down. The values can be
either 0 (the feature is disabled), or between 2 and 60 seconds. When
enabled, the value to be used depends on how long it takes the switch
to clear its MAC tables.
Notes:
>> Upon failovers, printouts displayed for ports down and up have extra 2 seconds delay (in
addition to the value set in force-port-down-time).
>> This capability is supported only for one VLAN per device.
>> This capability will not function when VRRP is not enabled and there is no VLAN
configured as part of the VRRP interfaces.
Physical IP Addresses versus Virtual IP Addresses Redundancy

In redundancy configurations, both primary and backup AppDirectors must be configured to work
with virtual and physical addresses. The primary device ensures that the backup AppDirector
supports virtual addresses. These addresses are defined on the backup AppDirector just like the
primary AppDirector. Different physical IP addresses are used for the primary and backup devices,
and often, another configuration is required on the redundant AppDirector to support backup for
physical IP addresses of the primary device.
When a physical interface of the primary AppDirector device is set as the default gateway of a
server, and the backup AppDirector takes over, the server works using the backup device as a Next
Hop Router. However, in this situation the server cannot ping its default gateway IP address because
the primary device is down. To avoid this, you can use Virtual IP addresses as the default gateways
of servers and other devices around AppDirector. To use Virtual IP addresses, you need to create a
Virtual IP Interface address for each local subnet of AppDirector, and use this address in the relevant
routing tables for hosts on that subnet. Ensure that the same Virtual IP Interface addresses are set
as backup on the redundant device.
Virtual Router Redundancy Protocol

The Virtual Router Redundancy Protocol (VRRP) eliminates the single point of failure inherent in the
static default routed environment. VRRP specifies an election protocol that dynamically assigns
responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling
the IP addresses associated with a virtual router is called the Master, and forwards packets sent to
these IP addresses. The election process provides dynamic fail-over in the forwarding responsibility
should the Master become unavailable. Any of the virtual router's IP addresses on a LAN can then be
used as the default first hops router by end-hosts.
To achieve redundancy between pairs of devices, Radware recommends using Virtual Router
Redundancy Protocol (VRRP). VRRP enables you to maintain dynamic redundancy using a logical
entity called virtual router (VRRP was initially developed to provide high availability for routers).
142

A VR (virtual router), has a Virtual Router Identifier (VRID) with one or more associated IP
addresses. Each VR has a VRMAC, which is a MAC address associated with the VR. This saves the
need for a MAC address update in case of a failover. The VRMAC address is determined by the VRID
and does not need to be configured manually.
The same VR needs to be configured on multiple devices to achieve redundancy between them for
the VR. Each device has a priority for a VR, and the primary device for the VR is the device with the
highest priority. Using VRRP, the primary device constantly sends advertisements to other VRRP
devices to indicate that it is online. When the advertisements stop, the primary device is assumed to
be inactive. A new primary device is then selected for this VR; that is, the device with the next
highest priority for that VR. However this protocol can be supported by a wide range of devices that
are not routers as it is not a routing protocol - it does not advertise IP routes or affect the routing
table in any way. With VRRP, IP Addresses are associated with the Virtual MAC Addresses that are
owned by the primary device, and are taken over by the backup device at failover time.
To set up the VRRP Table

1. From the AppDirector menu, select Redundancy > Global Configuration. The Global
Redundancy Configuration window appears.
2. Ensure that IP Redundancy Admin Status is VRRP.
3. From the AppDirector menu, select Redundancy >VRRP > Virtual Routers. The Virtual
Router Table window appears.
4. Click Create. The Virtual Router Table Create window appears.
Parameter
Description
If Index
Interface number.
Default: F-1
VR ID
Virtual routers identification number.

Values: 1 - 255
VR MAC
State
The virtual MAC address of the virtual router. Although this object can
be derived from the 'vrrpOperVrId' object, it is defined so that it is
easily obtainable by a management application and can be included in
VRRP-related SNMP traps.
The current state of the virtual router.
Values:
Initialize: indicates that virtual router is waiting for a startup event.
Master: virtual router is forwarding packets for IP addresses that
are associated with this router.
Backup: virtual router is monitoring the availability of the master
router.
143

Parameter
Description
Admin Status
Displays the status of the administration, Up or Down.

Values: Up, Down (Default).
This parameter will enable/disable the virtual router function. Setting
the value to ùp', will transition the state of the virtual router from
ìnitialize' to `backup' or `master', depending on the value of Priority.
Setting the value to `down', will transition the router from `master' or
`backup' to ìnitialize'.
State transitions may not be immediate; they sometimes depend on
other factors, such as the interface (IF) state.
Priority
The highest priority (255) must be assigned to the VR associated with a

devices physical IP address (IP address that the device owns).
Values: 1 - 255
Default: 100
Notes:
When 2 devices are configured with VRRP and the master device
has a priority of 255 set for its virtual routers, shutting down all
virtual routers causes the backup state to move to master but
causes the client connections to cease. This is because when you
down Virtual Routers, you DO NOT down the port. This port will
continue functioning and as soon as you down the virtual router,
the port will broadcast its MAC as the owner of the device interface
IP. It will continue sending health checks with source IP and
interface IP and ARPs for IPs on the directly connected networks.
These ARPs will poison the ARP cache of all machines on this
network and they will record the interface MAC of the primary box
as the holder of the interface IP that the backup device tried to
take over via VRRP.
Therefore, all traffic sent to the primary device interface IP as a
gateway (reply traffic from the servers) reaches the primary device
and is routed straight to the default gateway of the device. This is
not where this traffic should be heading because traffic sent to a
VIP which was taken over by the backup device (the primary device
will not fix the IP headers) will route the packet as it stands which
will break the session.
When you use VR priority of 255 on the primary device, you must
manually add its interface IP in the associated IP table.
When you do not use VR priority of 255 on the primary device, you
cannot place its interface IP in the associated IP table. This means
that the default gateway will be a different IP which has no
problems being poisoned but with the interface activities of the
primary device.
144
Address Count
Number of IP addresses that are associated with this virtual router.
Master IP
The master router's real (primary) IP address. This is the IP address

listed as the source in VRRP advertisement last received by this virtual
router.

Parameter
Description
Primary IP
Used internally only, as the source IP of VRRP messages sent by the

device. It is recommended to leave the default. The device adds a
default unless the user defines one.
When there is more than one IP address for a given If Index, this
parameter is used to specify the IP address that will become the VRRP
Master IP Address should the virtual router transition from backup to
master. If this object is set to 0.0.0.0, the IP address which is
numerically lowest will be selected.
Auth Type
Authentication type used for VRRP protocol exchanges between virtual

routers. The value of this parameter is the same for a given If Index.
Values: No Authentication (default), Text Authentication
Auth Key
The Authentication Key. This parameter is set according to the value of

the AuthType parameter.
If the length of the value is less than 16 octets, the agent will left adjust
and zero fill to 16 octets. The value of this parameter is the same for a
given If Index.
Advertise Interval
Interval at which packets are checked in seconds.

Default: 1 second.
Note: Configuring the specific advertisement interval value for a
VRRP entry is only possible when the global value is set to 0.
When the global value is not 0, the specific values for VRRP
entries are discarded and the global value is used. See Global
Redundancy Configuration, page 134.
Preempt Mode
Defines takeover procedure for VR when a device fails and then

resumes functioning. When a device with a certain priority fails, the
device with the next highest priority takes control of the VR. Then,
when the device with the higher priority for this VR resumes
functioning, Preemption Mode decides whether to retake control of VR
from the device with the lower priority.
Values:
True (Default) - the higher priority device takes over the VR
False - the device with lower priority maintains control of the VR.
This is only applicable when two or more devices share a VR.
Note: The router owning the IP address associated with the VR is an
exception as it always preempts independently of parameter setting.
Up Time
This is the value of the `sysUpTime' object when this virtual router (i.e.,
the `vrrpOperState') transitioned out of ìnitialized'.
Preferred State
The preferred state of the virtual router. This field affects the
configuration of the peer device's parallel VRRP entry.
Values:
Backup - indicates that the peer's VRRP entry should have a higher
priority.
Master - which indicates that the peer's VRRP entry should have a
lower priority.
Peer Admin Status
Values: Up / Down (default)
145

To activate or shut down the devices

1.
In the VRIDs Up/Down drop-down list, set the desired parameter.
Parameter
Description
VRIDs Up/Down
All Down: Sets Admin Status for all VRIDs to Down. This shuts
down the main device.
All Up: Sets the Admin status of all VRIDs to Up. So that the main
AppDirector is immediately activated and takes control from the
backup device.
No Change (Default): There is no change in the Admin Status.
2.
Associated IP Addresses
The Virtual Router Redundancy Protocol (VRRP) eliminates the single point of failure inherent in the
static default routed environment. VRRP specifies an election protocol that dynamically assigns
responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling
the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to
these IP addresses. The election process provides dynamic fail-over in the forwarding responsibility
should the Master become unavailable. Any of the virtual router's IP addresses on a LAN can then be
used as the default first hops router by end-hosts.
You use the Associated IP Addresses window to configure the VRRP.
To set up the Associated IP Addresses

1.
From the AppDirector menu, select Redundancy > VRRP > Associated IP Addresses. The
Associated IP Addresses window appears.
2.
Click Create. The Associated IP Addresses Create window appears.
3.
Set the parameters.
Parameter
Description
If Index
Displays the interface number.
VR ID
Displays the virtual routers identification number.

Note: VR ID must be Disabled to add Associated IP addresses and then
subsequently Enabled. It is set in the Virtual Routers table.
Associated IP
Displays the IP address associated with this VR ID.

Note: Up to 255 IP Addresses can be associated with a single VR ID.
4.
146

Proprietary Redundancy
Radware proprietary redundancy mechanism uses ARP (Address Resolution Protocol) to ensure that
the backup AppDirector is available and that the network connections between the main and backup
devices are up and that failover is achieved when primary device fails.
The backup device manages the polling process by continuously polling the main device, using the
ARP protocol. If the main device fails, the teaching process is realized when the backup device sends
broadcast ARPs informing its network neighbors that the IP addresses of the main device are now
associated with its own MAC addresses. This ensures that all traffic destined to the IP addresses of
the main device arrives to the backup device.
Backup Fake ARP

When the backup device takes over it sends gratuitous ARPs to all local stations informing that the
main device IP addresses now
correspond to the MAC addresses of the backup device.
When the main device is operational again, it uses the same technique. It sends gratuitous ARP to
all local stations informing them that the main device IP addresses now correspond to the MAC
addresses of the main device. To speed up this process, the backup device publishes a message.
This is fake ARP, as one device (the backup) publishes the other device (the main).
The fake ARP might confuse some Layer 3 switches, as they update their ARP tables by the source
MAC of the packet, rather than by the MAC in the information part of the packet.
The backup fake ARP option is enabled by default and can be disabled if necessary.
IP Redundancy
In redundancy configurations both AppDirectors, the main and the backup, must be defined to work
with virtual and physical addresses. The virtual IP addresses are defined on the backup AppDirector
in the same manner as on the main AppDirector and the main device makes sure that the backup
AppDirector supports virtual addresses. Different physical IP addresses are used for the main and
backup devices, and an additional configuration is required on the redundant AppDirector to support
backup for the physical IP addresses of the main device.
The IP Redundancy Table window allows you to setup IP router redundancy: The IP Redundancy
Table is relevant for proprietary redundancy only.
To setup IP router redundancy

1. From the AppDirector menu, select Redundancy > IP Redundancy Table. The IP Redundancy
window appears.
2. Click Create. The IP Redundancy Table Create window appears.
Parameter
Description
Interface IP Address
The IP address of the IP interface on which the redundancy feature is

operational.
Main Router Address
IP address on the main AppDirector interface, which this AppDirector is

backing up.
Operating Status
The redundancy status. If active, the main AppDirector is considered

inoperational and the IP interface operates as its backup
Active: The backup AppDirector is now active on this interface.
Inactive: The backup AppDirector is not active.
147

Parameter
Description
Poll Interval [sec]
Polling interval for the main AppDirector interfaces, in seconds. If the

interval is 0, the AppDirector is not polled.
Default: 3 seconds
Time Out [sec]
Interval, in seconds, during which the AppDirector must respond. If the

main AppDirector does not respond within this interval, it is considered
inoperative. If Time Out is 0, the backup AppDirector ignores the row.
Default: 12 seconds
4.
Click Set. Your changes are recorded. This procedure must be repeated for every back-up
interface.
Note: To allow the backup device to poll the main device, it must be aware of the main device
IP interfaces that its IP interfaces are backing up.
Configuration Synchronization
In a redundant configuration, master and slave devices require consistent configuration. Online
configuration synchronization helps to prevent a tedious error-prone manual process to ensure that
the configuration is synchronized between a pair of redundant devices.
This feature provides a mechanism where the configuration created on one device is updated
automatically and synchronously on its redundancy peer. This way, the device configurations are
guaranteed to be always synchronized, without requiring manual intervention.
This capability operates in a master/slave mode where the master device is the only one that can be
configured by the administrator and the slave device is configured by the master device only.
Automatic configuration synchronization is achieved by providing an online update of the slave
device for all configuration operations performed on the master device.
Notes:
>> The redundancy configuration is updated on the slave device according to the
recommended configuration in the Configuration Guidelines section.
>> This capability is only supported for a pair of devices using VRRP in an Active-backup
scenario.
Master/Slave Roles
The roles of the devices are set manually and never change dynamically in contrast to the VRRP
active ownership.
The configuration synchronization roles are independent of the device redundancy operation
mode (Active/Backup). You need to set the primary device as configuration master.
The configuration synchronization will consider the VRRP status when rebooting the slave device
(after configuration changes that require reboot). If the configuration slave is the VRRP active
device, then reboot is suppressed to avoid unnecessary failover that will cause connection
disruption. The master will wait for the VRRP role to switch over and only then issue a reboot.
148

Activating Configuration Synchronization

Pre-requisites
For auto-configuration synchronization, master and slave devices must match the following criteria:
1. Hardware platform type - master and slave devices must use the same hardware platform.
2. Memory size.
3. License - (license upgrading needs to be performed manually on both devices, as each license is
bound to a specific machine).
4. Software version - Any software upgrade is performed manually on each device. During this
process, the configuration synchronization must be disabled.
5. Network topology (parallel ports connected to the same subnets and the same IP addresses
matching crosswise).
6. Before the configuration is synchronized for the first time, there must be at least one matching
IP interface (same subnet, same interface) on the two devices.
Example
A
Master
IP: 1.1.1.1, Subnetmask: 255.0.0.0, Port: G-1, PeerAddress: 1.1.1.2
Slave
IP: 1.1.1.2, Subnetmask: 255.0.0.0, Port: G-1, PeerAddress: 1.1.1.1
Notes:
>> Verify that all above steps before enabling configuration synchronization on your
devices.
>> The master device checks all the above conditions (except number 5 which is the
administrators responsibility) and will not start synchronization if one of these
conditions is not satisfied.
Starting to Configure
To start configuration synchronization

1. On the master device, set the Device Role to Master and configure the Synchronization Session
Password with the same value that you used on the slave device. In a few seconds the devices
will start to synchronize with each other. This process will trigger a reboot of the slave device.
2. Next, on the slave device, set the Device Role to Slave and configure a new value for the
Synchronization Session Password (for security purposes the initial password is randomly
generated).
3. When the slave device comes up from reboot, the devices will finish the synchronization process
and their configuration will be matched. Subsequently, each configuration change now made on
the master device is synchronized on the slave device.
149

Notes:
>> For each IP interface configured on the master device a Peer IP address must be
configured (to be used as IP interface on the slave device).
>> You can monitor synchronization state on the Master device. The state should show InSync. See Configuration Synchronization Monitoring, page 153.
>> Configurations requiring reboot will only take effect on the slave after you have rebooted
the Master device (and it will then automatically reboot the slave).
There are additional configuration synchronization parameters that can be modified, see
Configuration Synchronization Settings, page 150.
The configuration synchronization status and statistics can be constantly monitored, see
Configuration Synchronization Monitoring, page 153.
Slave Device Behavior

While the online configuration synchronization is enabled, the slave device cannot be directly
configured by user, with the exception of a few parameters that are not synchronized and can then
be configured directly on the slave device. These parameters are marked in both master and slave
devices.
Examples of parameters that are not synchronized: Device Name, VRRP Global Admin Status, OSPF
Router ID, Layer 2 Interface parameters.
You can also perform software and license upgrade on a slave device, reset statistics and clear table,
perform any non-configuration commands (such as ping, telnet, etc.), perform troubleshooting
operations (filter client table view, configure diagnostics and retrieve support file) as well as CLI
terminal configuration.
Configuration Synchronization Settings
To configure Configuration Synchronization Settings

1.
From the main menu, select Redundancy > Configuration Synchronization > Settings. The
Configuration Synchronization Settings window appears.
2.
Set the parameters.
Parameter
Device Role
Description
The role that this device plays in configuration synchronization:
None (default): the device does not participate in configuration
synchronization
Master: only this device is configurable and it synchronizes the slave
device
Slave: this device receives its configuration from the Master device,
only change of its role in configuration synchronization and reboot
can be performed on a device in Slave mode
Synchronization
Session Password
The password used to establish an SSH session between the devices for
configuration synchronization.
The same value must be configured in both devices (master and slave) to
allow session establishment.
150

Parameter
Description
Connection
Preference
The IP Interface through which configuration synchronization

communication with peer device should be established.
Values:
Any: The device will try to establish connectivity via any of the
device IP Interfaces.
Any MNG IP: The device will try to establish connectivity via any of
the device IP Interfaces configured on dedicated MNG ports.
Select a specific device IP Interfaces. Only IP Interfaces for which a
Peer IP Address is configured are eligible.
Note: If the Connection Preference is changed while the configuration
synchronization communication between the devices is active,
Reconnect Slave command must be performed in order to cause
the devices to connect via the new preferred interface.
Alternate
Connection
Preference
Alternate Connection PreferenceThe IP Interface through which

configuration synchronization communication with peer device should be
established in case the IP Interface defined for first Connection
Preference is not available.
Values:
None: No alternate connection
Any: The device will try to establish connectivity via any of the
device IP Interfaces.
Any MNG IP: The device will try to establish connectivity via any of
the device IP Interfaces configured on dedicated MNG ports.
Select a specific device IP Interfaces. Only IP Interfaces for which a Peer
IP Address is configured are eligible.
Allow Active Slave

Reboot (When
device has Master
role)
You can decide whether to allow the slave device to be rebooted. Due to
configuration changes requiring reboot, the slave device is in active state
(redundancy wise).
Default: Disabled.
Peer Connectivity Timers (sec)

Slave Connect
Interval (When
device has Master
role)
The interval at which a master device tries to establish connectivity to a

disconnected slave.
Keep Alive Interval

(When device has
Master role)
The interval at which a master device sends keep alive messages to slave
to maintain connectivity.
Slave Response
Timeout (When
device has Master
role)
If the slave device does not answer either connection attempt or keep
alive message within this timeout, it is considered to be disconnected.
Slave Reboot
Timeout (When
device has Master
role)
If the slave device does not answer connection attempt after it was
rebooted within this timeout, it is considered to be disconnected.
Default: 15 sec.
Default: 120 sec.
Default: 20 sec.
Default: 240 sec.
151

Parameter
Description
Peer Disconnect
Alert Delay (When
device has either
Master or Slave
role)
A trap that alerts on a slave disconnection will be sent only after the slave
has been disconnected for this period (to avert flip-flops).
Master
Communication
Timeout (When
device has Slave
role)
If the slave device does not receive communication from a master for this
timeout, the master is considered disconnected.
Default: 60 sec.
Default: 180 sec.
Exclude from Synchronization
3.
152
Exclude
Management IP
(When device has
Master role)
IP interfaces defined on the management ports: MNG-1 and MNG-2. You

can decide whether to synchronize management interfaces.
Exclude Secured
Management
Settings (When
device has Master
role)
You can decide whether to synchronize the secure management interface

settings and the certificates that they use. These include the secure Webbased management and SSH.
Values: Enabled (default)/disabled

Configuration Synchronization Monitoring

This feature includes monitoring values related to the configuration synchronization feature. They
apply to both master and slave devices
To view Configuration Synchronization Monitoring

From the main menu, select Redundancy > Configuration Synchronization > Monitoring. The
Configuration Synchronization Monitoring window appears displaying the following states and
counters.
Parameter
Description
Synchronization State
The current state of the configuration synchronization.

Values for Master devices:
Sync-off - Disabled
Disconnected - indicates that config-sync feature is enabled on
your device, but synchronization did not yet occur
Master-connected - Master and slave are In Synchronization, and
everything you configure on master will be configured automatically
on the slave.
No-master - No master connected.
Synchronizing - both devices are synchronizing for the first time
and this state will take a few minutes until they get into In-Sync
state, (until all configuration will be sent to the slave, and the slave
reboots).
In-Sync - Slave and Master devices are synchronized.
Incompatible - the devices are not compatible. True master-slave
matching has not occurred or the slave's device-role is not
configured as a slave. To find the problem, first check the
monitoring scalar of "incompatibility". It will give you a reason why
the devices are not incompatible due to a hardware, software or
configuration problem.
Cannot-Sync- this usually indicates a configuration problem. For
example, a master device tried to configure the slave, but a
command failed. Check the logs and after the fix, you need to set
the master's mode to disabled, and then back to "Master".
Pending-VRRP-switch - pending failover
Out-Of-Sync - this state is useful when you have a single farm
failure in the In-Sync state. Normally, Full sync triggers
immediately, and may result in reconfiguring the device. Out-ofSync allows you to carry on configuring other farms until the
timeout expires.
Values for Slave devices:
Disabled
Disconnected (for explanation, see above)
Master-Connected (for explanation, see above)
153

Parameter
Description
Incompatibility Status
The reason the master and slave are incompatible. Applies only to
master device and only if current state is incompatible or disconnected.
Values:
Hardware platform
Memory size
License
Software version
Initial configuration (applies to disconnected state - the slave will
refuse to connect in this case)
Slave compatibility is not established
Notes:
If there is more than one reason, then the first reason detected is
displayed.
Slave compatibility is not established when configuration
synchronization is not activated.
Synchronization IP
Interface
The current IP interface used for the communication with the peer
device. If the devices are disconnected - null=0.0.0.0
Peer IP
Displays the synchronization peer IP.

For synchronization master devices, the slave IP is displayed.
For synchronization slave devices, the master IP is displayed.
Peer Base MAC
The base MAC of the configuration synchronized peer device that is

currently logged in or has last logged in. Used as the unique identifier of
the peer device. Set to null, if the peer was never connected.
Configuration Timestamp
The last time the configuration was successfully propagated from the
master to the slave.
Availability Status
Availability for receiving configuration changes. When AppDirector is

unavailable, and when it acts as a slave, it will refuse to accept a
configuration change.
Values:
Available
axDown (meaning unavailable because the acceleration engine is
down)
Unavailable
Device Should Reboot
Indicates whether changes were made to the configuration that require

the device to be rebooted.
Values: True/False
For Master Devices Only

Last Configuration
Synchronization
The last time that the configuration was successfully propagated from
the master to the slave.
The configuration synchronization can be either individual or full
synchronization.
Default: 0
Last Full Configuration

Synchronization
154
The last time that a full synchronization was successfully performed.

Default: 0

Parameter
Description
Discrete Synchronization
Attempts
The number of successful individual synchronization operations since

last full synchronization.
Default: 0
Full Synchronization
Operations
The number of successful full synchronization operations since

configuration synchronization was last enabled, or since the last reboot
(the later of the two).
Default: 0
Number of Successful
Connections
The number of successful individual synchronization operations since

the last full configuration synchronization.
Default: 0
Synchronization Failures
The number of synchronization operations (individual or full

synchronization) that failed since last enablement or reboot (the later).
The failures include only operations that failed due to application
problems to update the slave device.
They do not include disconnections, connection setup failures, failed
compatibility checks and inability to reboot the slave because it was the
VRRP active device.
Default: 0
Disconnections
The number of times that the peer was disconnected since last
enablement or reboot (the later).
Default: 0
Slave Configuration
version (Master only)
Version/timestamp of last time the configuration was modified on

Master, but not necessarily propagated to slave.
If this time is identical to the slave configuration version then the two
devices are in sync.
Default: 0
Reset Slave Device

When the changes performed on the configuration master require the device reboot to become
active or when full synchronization is performed, you need to reboot the slave device.
To avoid unnecessary failover from a forwarded connection disruption, the master device will not
reboot the slave device, if the slave device is the VRRP active device. Full synchronization is required
and the configuration synchronization is suspended until VRRP control returns to the master of
configuration and only then will full synchronization occur.
This behavior can be overridden by a configuration flag named Allow Active Slave Reboot. When this
flag is enabled, the configuration master disregards the VRRP status and reboots the slave device
whenever the configuration synchronization requires.
For configuration changes requiring a reboot (such as table size tuning), the master device updates
the slave device with the configuration change like any other change, but will not reboot the slave
immediately. It will instead wait until it is rebooted itself, because until then, the configuration
change will not have taken effect in either device, and the configurations are still in synchronization.
When the master device comes online after reboot, a self-check will show that it has a more updated
configuration (due to the reboot) and full synchronization will occur.
If a configuration change requiring a reboot was performed, and the slave device was rebooted for
any reason (manually, due to crash or due to full synchronization after connection loss) before the
master device was rebooted, then the slave device will now have a more updated configuration than
the master. This is the only case where this occurs.
155

Manually Resetting a Slave Device

From a device that has Master role, the administrator can reboot a Slave device. This allows you to
override the Allow Active Slave Reboot flag disabled status and to force a slave device reboot.
To manually reset a Slave device

1.
From the main menu, select Redundancy > Configuration Synchronization > Monitoring
> Reset Slave. The Reset Slave Device window appears.
2.
Click Set (for Reboot Slave (master only). The slave device is reset.
Reconnect
From a device that has Master role, the administrator can force a reconnect to the slave device. This
should be used when you have changed the interface through which you want the config-sync
connection to be established.
To reconnect to slave from Master device

1.
From the main menu, select Redundancy > Configuration Synchronization > Monitoring
> Reconnect. The Reconnect window appears.
2.
Click Set (for Reconnect to Slave (master only). The slave is reconnected.
156

Traffic Management and Application Acceleration
Chapter 3 Traffic Management and Application

Acceleration
This chapter introduces concepts for load balancing and application acceleration (when enabled) and
explains how to configure your data center for traffic management policies. It includes these topics:
Configuring Farms, page 159
Configuring Servers, page 170
Traffic Management Policies, page 183
SSL Offloading and Authentication, page 194
Application Acceleration, page 217
Layer 7 Traffic Management, page 228
Layer 7 Modification, page 238
Layer 7 Server Persistency, page 252
Client Table Management, page 264
Network Address Translation (NAT), page 274
Configuring AppDirector Advanced Global Parameters, page 289
The following workflow helps you to understand how to configure traffic management and
acceleration for AppDirector and distinguishes between Acceleration enabled and disabled
functionalities.
157

AppDirector load balances traffic to application servers that provide various application services,
such as FTP, Web, Mail, ERP, CRM, Streaming, VoIP, etc.
To receive the requested service, user traffic is directed to a homogenous and redundant group of
servers. This is managed by AppDirector, which decides:
158

To which group of servers to direct the request to provide the service required by the client.
To which server within the required group to direct the traffic to optimize the service provided
and to ensure its operation.
The main elements involved in configuring server load balancing on AppDirector are:
1. Farm - A group of application servers that provide the same service. A farm can provide multiple
services and a server can be part of multiple farms.
2. Virtual IP (VIP) - A single point of entry through which clients can access a variety of services.
3. Layer 7 Policy - a set of rules that allow to select a farm based on application data (Layer 7).
4. Layer 4 Policy - a set of rules that allow to select a farm based on layer 4 and layer 7 data if
required (by linking to a Layer 7 policy) and activate application acceleration capabilities. The
layer 4 data used to classify traffic via L4 Polices is:
a.
b.
Destination IP (VIP)
Layer 4 Protocol (TCP, UDP, ICMP, SCTP, Any or Other)
c.
Layer 4 Port
d.
Source IP Range
When traffic reaches the services point of entry (VIP) AppDirector Matches the Layer 4 data in the
packet to Layer 4 policies configured on the device until the best match is found. Once a matching
Layer 4 Policy is found the device processes the traffic according to the services required for this
Layer 4 Policy. As an example the following actions are performed for HTTPS traffic processing:
1. SSL processing is performed by AppDirector, if required, to off-load it from the servers.
2. If HTTP caching is enabled, AppDirector can respond from the cache, to off-load it from servers
if the requested object is in the cache. In this case steps 3-5 are not relevant.
3. If a Layer 7 policy is attached, the device processes the application request searching for the
Layer 7 policy criteria to select the target farm, if not the target farm is the one directly attached
to the Layer 4 policy.
4. Traffic is forwarded to the server best able to deliver the requested service within the target
farm.
5. If HTTP caching is enabled, cache objects from the response according to configuration.
6. HTTP response can be compressed if required.
7. Response is SSL encrypted before being sent to client.
Configuring Farms
This section describes how to configure Farms for AppDirector operations. Topics include:
Farm Parameters, page 159
Additional HTTP Connectivity Checks Parameters, page 167
No HTTP Service Page, page 168
Farm Parameters
A server farm is a group of networked servers that provide the same service. Servers contained in a
server farm can be placed in different physical locations, belong to different vendors, or have
different capacities. Differences between servers within a farm are transparent to clients. If all the
servers within a group provide the same service managed by the AppDirector device, this group can
be defined as an AppDirector server farm. A server providing multiple services can be used in
multiple farms. For example, Server 3 (S3), as shown in this figure, provides Web service in one
farm and FTP service in another server farm.
159

Web Farm
S1
S2
FTP Farm
S3
S4
S5
S6
To add or edit a new server farm

1.
From the AppDirector menu, select Farms > Farm Table. The Farms Table window appears.
Select the desired farm name. The Farm Table Update window appears.
2.
Set the parameters..
Parameter
Description
Farm Name
Name of farm (Read- Only in Edit Mode).
Admin Status
Can be one of the following options:

Enable: Farm is active. All users are balanced between servers.
Disable: Farm is inactive. Clients connecting to the farm cannot
be served.
Dispatch Method
Method used to determine to which server traffic is directed:

Cyclic: Directs traffic to each operational server 1 by 1 (round
robin).
Weighted Cyclic: This method uses the Weighted Round Robin
algorithm. AppDirector distributes clients requests for service in the
round robin manner taking into consideration the weight of servers
in that farm. Explicitly, every new session is distributed to the next
server up to the server weight. For example, if one server has a
weight of 2 and another server has weight of 5, the first two sessions
are sent to #1, the next five are sent to #2. Sessions eight and nine
are sent to #1 again, and ten to fourteen are sent to #1 and so on.
Least Amount of Traffic: Directs traffic to server with least traffic
belonging to this farm (relevant when server belongs to multiple
farms). Server weights are also considered.
Fewest Number of Users: Directs traffic to server with least
amount of users belonging to this farm (relevant when server
belongs to multiple farms). Server weights are also considered.
Least Amount of Traffic Local: Directs users to the server with the
least traffic. Server weights are also considered.
Fewest Number of Users Local: Directs users to the server with
the fewest users. Server weights are also considered.
nt-1: AppDirector queries the farm's servers for Windows NT SNMP
statistics and redirects new sessions to the least busy server
according to the servers' reported statistics.
nt-2: Similar to nt-1, but using the second weights scheme.
private-1: AppDirector queries the farm's servers for private SNMP
parameters, as defined in the first private weights scheme. Ratios of
users on servers are balanced according to reported statistics.
160

Parameter
Description
Dispatch Method
(continued)
private-2: Similar to private-1, but using second weights scheme.

Response Time: Enables Response Time load balancing. This load
balances the servers in the farm based on the least loaded server as
calculated by the Response Level. Server weights are also
considered.
Note: You need to create a health check that also measures
response time, for each server, to have the response time
dispatch method working properly. See Binding, page 347.
Hashing: AppDirector selects a server for a session using a static
Hash function. This method enables AppDirector to repeatedly direct
requests from the same client to the same server within a farm even
after the client entry has aged, as long as the server is still in
service.
This Dispatch Method also provides support for reverse proxy Web
farms, avoiding data replication among the proxy servers.
Input for the Hash function is usually the Client IP only. A formula is
applied to this IP address. Output received is a numeric value. When
the traffic is SIP, input for the hash function is either Call-ID or
Request-URI (configurable) and when the traffic is RADIUS input for
the hash function is user-defined RADIUS attribute value.
Note: When a Hash result indicates to use a server with status
of Not in Service, a second hash is used to select an available
server for the session.
Sessions Mode
The method used to handle new sessions:
Regular: All sessions from the same client IP to the same service
(VIP + Protocol + port) are forwarded to the same server.
Entry Per Session: All sessions from the same client IP to the
same service (VIP + Protocol + port) are forwarded to the same
server, but each session is recorded in the client table providing
more accurate minimum-user load balancing.
Server Per Session: Different sessions opened by a client IP are

served by different servers, according to load balancing
algorithms. This enhances load balancing performance but may
hinder some applications dependent on being served by the
same server. It also may overload internal tables.
Remove on Session End - EPS: After TCP client session ends, the
client's entry is removed from the Client Table ends after 5-6
seconds. This automatically enables Entry Per Session.
Remove on Session End - SPS: After TCP client session ends, the
client's entry is immediately removed from the Client Table after
5-6 seconds. This automatically enables Server Per Session.
Aging Time [sec]
Amount of time a non-active session is kept in the client table (in

seconds). As long as a session is kept in the client table, the client is
connected to the same server.
Bandwidth Limit
Maximum amount of bandwidth in Kbps allowed for this farm. If

traffic through the farm exceeds the configured limit for any given
second, AppDirector drops excess packets.
Note: Bandwidth Limit is measured in Kbps, so 1Mbps is represented
with a bandwidth limit of 1000. A value of 0 = no bandwidth limit.
Default: No Limit.
161

Parameter
Description
Connectivity Checks
Connectivity Check
Method
Indicates method of checking for server availability.

Values: No Checks, Ping, TCP Port, UDP Port and HTTP Page.
If Ping is selected, AppDirector pings the servers to verify valid
communication. If HTTP Page is selected, AppDirector tries to
retrieve the web page (as configured in the Home Page field) from
the servers.
TCP Port/ UDP Port causes AppDirector to attempt to connect to the
specified application port, according to the protocol.
Connectivity Check
Retries
Number of polling attempts made before a server is considered

inactive.
Connectivity Check
Interval
How often the device polls servers (seconds).
Connectivity Check
Port
Specific port where you can conduct a connectivity check.
Extended Check
Frequency
To save unnecessary web page requests, web page retrieval is

performed only periodically for HTTP page connectivity check. Once
in a number of requests, according to the retrieval frequency, the
web page is requested. Otherwise, a simple TCP check for port 80
occurs.
Authorized Username
Used for password protected HTTP page checks.
Authorized Password
Used for password protected HTTP page checks.
Home Page
With the "HTTP pages" check method, this defines the default web
page retrieved from servers. If this web page is unavailable, the
server is considered down.
Connection Denials
(Read-Only)
Number of times connection to this farm was denied.
Operational Status
(Read Only)
Farm Operational Status OID is calculated according to these rules:
Values: FTP, HTTP, SMTP, DNS, NNTP, HTTPS, RTSP, RADIUS or any
port number you enter manually. For example, HTTP automatically
checks port 80.
Active when:
(Farm Admin Status is Enabled) AND (at least one farm server is
Active).
Not In Service when:
(Farm Admin Status is Disabled) OR (all farm servers Operational

Status is not Active = Not In Service or No New Sessions).
Note: When the Farm Operational Status is changing, the device

sends a trap to notify.
3.
162

Additional Farm Parameters

You can use the Extended Parameters window to configure additional server farm information.
To configure extended farm parameters

1. From the AppDirector menu, select Farms > Extended Parameters. The Extended Farm
2. Select a farm. The Extended Farm Parameters Update window appears.
Parameter
Description
Farm Name (ReadOnly)
Name of the farm.
Connection Management
Close Session At
Aging
Specifies when a TCP session is aged whether you want the device to
send RESET to client, server or both.
Values:
Server side - Gracefully close the client-side connection when it ages.
Client side - Gracefully close the client-side connection when it ages
out the persistency entry from the client table.
Client & Server side - When Client Aging expires for a specific
session, AppDirector removes the Client Table entry for this session
and sends a RESET to the server to close the associated port.
(Applicable to TCP sessions only).
Disabled
Connection Limit
Exception
AppDirector allows Connection Limit configured for servers to be

exceeded.
When this is enabled, in cases where existing client opens new sessions
and all sessions should use the same server, the session should use the
same server. For example, when using EntryPerSession or Client Grouping
Mask.
Default: Disabled
Reset Client on
Server Failure
When it closes a connection with the client by sending it a RESET when a

server is detected to be down.
Default: Disabled
Note: This cannot be enabled on a Regular farm. This feature requires
one of these layer 4 modes (EPS or SPS). Here, every session
can obtain client entry.
Client NAT
Client NAT Address
Range
Range of NAT addresses, based on the NAT Address Table, to be used for
this farm. A client with an IP address within the Client NAT Range,
approaching the farm, is NATed according to the selected NAT Address
Range. Also see Client NAT Addresses, page 276.
163

Parameter
Description
Add X-ForwardedFor to HTTP

requests
When using Client NAT, the source IP address is replaced by NAT address,
so that server cannot know the identity of the original client.
To solve this problem AppDirector can insert an X-Forwarded-For header
with the identity of the original client in the traffic forwarded to server.
Default: Disabled
HTTP Persistency
Insert Cookie for
HTTP Persistency
When enabled, AppDirector supports client-server persistency for HTTP

where the server does not insert a cookie into the reply or when replies
from all servers contain the same cookie.
Persistency is maintained using cookies that AppDirector generates
automatically and inserts in replies to the client.
There are 3 modes for the field:
Enabled
Disabled (Default)
Enable and Remove Cookie on Return Path: allows cookies previously
inserted by AppDirector to be removed from client requests before
forwarding to the server.
Select Server Per

Transaction
Defines whether a new server is selected per each transaction (Enabled).

Default: Enabled.
SSL Persistency
SSL ID Tracking:
See SSL Persistency, page 261.

When the SSL ID Tracking parameter is enabled, AppDirector keeps track
of SSL Session IDs to ensure that all sessions with the same SSL ID are
served by the same server even when Server Per Session Client Table
mode is used.
SSL ID Aging
The amount of time a non-active client is kept in the client table (in
seconds). As long as a client is kept in the client table, the client is
connected to the same server.
You can configure this as part of the farm configuration. The default value
is 120 seconds. Allowed values are from 1 second to 65,535 seconds.
RADIUS Persistency
RADIUS Attribute
The RADIUS attribute is required to maintain persistency for RADIUS

sessions.
Remote Authentication Dial-In User Server (RADIUS) attributes are used
to define specific authentication, authorization, and accounting (AAA)
elements in a user profile, which is stored on the RADIUS daemon.
Values: 0 (default - no RADIUS attribute will be learnt) - 255
Radius Secret
164
Used for the RADIUS Connectivity Check on the Farm. When the farm is a
Radius Server Farm, the Radius secret must be configured to allow access
to the farm.

Parameter
Description
RADIUS Proxy
Attribute
When RADIUS servers that AppDirector is managing operate as proxies

and forward access/accounting requests to another RADIUS server, the
RADIUS Proxy attribute allows AppDirector to ensure that the RADIUS
responses are sent to the correct proxy server.
This attribute must be inserted by the proxy RADIUS servers before
forwarding the request and must include as the first 4 bytes the server IP
in hex format.
Values: 0 (default = disabled) - 255
SIP Persistency
Hash Parameter for To maintain client-server persistency in SIP sessions, the device searches
SIP
the Call-ID header in SIP and selects an available server based on a static
hash algorithm performed on the Call ID.
If the farm is part of a Layer 4 Policy, the input function for the Hash is
the requested URL.
Default: Call-ID
No Service Page
No Service Page
HTTP Code
This parameter allows you to configure the code to be used for the
"Sorry" page response sent when this farm is unavailable.
Values:
100 Continue
302 Moved Temporarily
200 OK (Default)
304 Not Modified
202 Accepted
400 Bad request
204 No Content
401 Unauthorized
205 Reset Content
402 Payment Required
206 Partial Content
403 Forbidden
300 Multiple Choices
404 Object Not Found
301 Moved Permanently
503 Service Unavailable
Backend SSL
Backend SSL State
This parameter allows you to override the SSL policy back-end SSL
settings and forward traffic to the back-end servers in clear text. This
capability is required when SSL offloading is required on the front-end,
but on the back-end some of the Layer 7 services require back-end SSL
encryption.
Values:
Override to Clear text
Respect SSL Policy (default)
165

Parameter
Description
Transparent Server
Support
You can enable AppDirector to manage AppXcel devices.

Values include:
Disabled
Enabled
Front-End AppXcel Farm: If farm is AppXcel farm used as front end.
TCP Splitting: If the farm is the back-end farm.
4.
166
Click Set. Your configuration is set

Additional HTTP Connectivity Checks Parameters

When the HTTP page is used for connectivity checks you can can configure additional parameters:
Acceptable HTTP Codes
Content Checks
Acceptable HTTP Codes

This defines up to 10 HTTP codes that when included in server response indicate a healthy server.
To add or edit a HTTP Acceptable Response Code

1. From the AppDirector menu, select Farms > HTTP Codes. The Acceptable HTTP Codes window
appears.
2. When adding a new code, click Create. The Acceptable HTTP Codes Create window appears.
3. From the Acceptable HTTP Code drop down list, select the acceptable code.
4. When editing, select the required farm. The Acceptable HTTP Codes Update window appears.
Parameter
Description
Farm Name
From the Farm Name drop down list field select a farm name.
Acceptable HTTP Code Values:

100 Continue
200 OK
304 Not Modified
202 Accepted
400 Bad request
204 No Content
401 Unauthorized
205 Reset Content
402 Payment Required
206 Partial Content
403 Forbidden
300 Multiple Choices
404 Object Not Found
301 Moved Permanently
503 Service Unavailable
6. Click Set. The HTTP Code is added to the Acceptable HTTP Code Table
Note: You must also have at least one code on the list. The maximum number of codes or
farms is 10.
Content Checks
This defines strings whose existences or absence from retrieved HTTP page indicate a healthy
server. AppDirector examines the HTTP header of the server response and considers responses with
the user-defined HTTP status code to indicate a healthy server.
You can configure HTTP status codes to be used as acceptable responses. By default, an HTTP code
of 200 indicates service availability.
Servers and applications can pass health checks but if the content is not accurate, (for example,
corrupt or misplaced files), AppDirector can also check for content accuracy. There are several
methods including:
167

using an application-level health check by using an HTTP GET request for a URL of customer
choice, the load balancer can check the returned Web page for accuracy.
scanning the page for certain keywords (shown here).
calculating a checksum and compare it against a configured value.
For other applications, such as FTP, the load balancer can download a file and compute the
checksum to check accuracy.
To configure new dynamic content checks

1.
From the AppDirector menu, select Farms > Content Checks. The Content Checks window
appears.
2.
When creating, click Create. The Content Checks Create window appears.
3.
When updating, select required farm. The Content Checks window appears
4.
Set the parameters.
Parameter
Description
Farm Name
Name of the farm where the extended check is made.
Search String
The string to look for in the HTTP response.
Check Mode
Type of check to perform.

Values:
String Exists (default): Checks if string exists.
String is Absent: Checks if string exists.
5.
Click Set. The string is added to the Content Check Table.
No HTTP Service Page

When no servers can be used for a specific session, AppDirector can reply to a Web request (to port
80) with a simple Web page, indicating that the service is currently not available. Servers that
cannot be used for a session include those in Not In Service or in No New Sessions mode. The No
HTTP Service Page window is configured for each farm. Each Web page is limited to 1K of HTML
code. When configuring the No HTTP Service Page, the page text must be entered as one line with
no line separators. Sample HTML code for a default Web page is shown here:
<HTML>
<HEAD>
<TITLE>Service Unavailable</TITLE>
</HEAD>
<BODY>
 
Service is currently unavailable. Please try again later.


</BODY>
</HTML>
168

To set the No HTTP Service

1. From AppDirector menu, select Farms > No Service Page. The No Service Page window
appears.
2. Select a farm from the drop-down menu.
3. Select Get, Set or Delete as appropriate.
Notes:
>> Setting content for the page activates this feature. By default, no content is displayed
for a farm. To remove this feature, select the farm and select Delete.
>> You should set this page if you want a user to get a message when the service is not
available and if there is no answer to the DNS.
>> If a "No Service Page" is defined for a farm bound to a DNS Host Name Entry (as for
farm www.farm123data.com), the device will reply with a DNS answer even if all servers
of the farm are down.
169

Configuring Servers
This section discusses server configuration and includes these topics:
Physical Servers, page 170
Application/Farm Servers, page 172
Dispatch Methods, page 177
Local Triangulation, page 181
AppDirector works with farm servers; logical entities that are associated with application services
provided by the physical servers that run these applications. Adding and configuring servers in an
AppDirector farm requires configuring the physical server parameters, then the farm parameters
and finally the application parameters.
Every service is hosted on the physical server, and should be defined in the system. For each
service, you can define a logical entity (a farm server) and attach it to the farm that provides this
service. Configuring farm servers means organizing servers according to how you use their services.
Physical Servers
When you add hardware elements to the network and define them as servers, every service is
hosted on the physical server, and should be defined in the system.
Before setting up a physical server, you must establish IP connectivity of the server to AppDirector
and to the host.
A physical server that provides multiple services may participate in multiple farms. In each farm,
this physical server is represented by a unique farm server that provides one specific service. Each
service is associated with a farm, and you can define its load balancing scheme and customized
Health Checks. In this way, if one of the services provided by a physical server is not available, other
services can still be used.
To configure a machine in the server farm

1.
From the AppDirector menu, select Servers > Physical Servers. The Physical Servers window
appears.
2.
Select the server you want to edit. The Physical Servers Update window appears.
170

3. Set the parameters:
Parameter
Description
Server Name
Physical server identification.
Admin Status
User defined management status of the server. Valid values are:

Enabled (Default): The server is active and ready to reply to new
requests for service.
Connections-Shutdown: No new connection will be forwarded to
the server, even if persistency information (client IP or Layer 7
session id) indicates this server. Traffic on existing connections is
still forwarded to the server until the connection is closed or
inactivity Aging Time is reached.
Sessions-Shutdown: New connections that do not belong to an
existing session on the server will not be forwarded to the server.
An existing session is defined by persistency information (client IP
or Layer 7 session id) that indicates this server. New connections
belonging to an existing session are still forwarded to the server
until all connections related to this session are closed and the Layer
7 session id reaches its Aging Time.
Recovery Time
Period of time, in seconds, during which no data is sent to the physical

server after the server recovers from a failure. When a server's
operational status is changed from inactive to active (dynamically or
administratively), the physical server is not eligible to receive clients for
this period of time.
Recovery Time applies to all servers in all farms that share the same
Server Name (the physical server name that was defined above). Once
this time has elapsed, the physical server becomes eligible to receive
client requests.
When the Recovery Time parameter is set to 0 (default), the server is
eligible to receive client requests immediately after changing its
operational status from inactive to active.
Maximum Value:4294967295 seconds
Default: 0 seconds
Warmup Time
(seconds)
Time, in seconds, after the server is up, during which clients are slowly
sent to this physical server at an increasing rate so that the server can
reach its capacity gradually. AppDirector internally raises the server
weight for this period of time, until the server's weight is the preconfigured weight).
If the Warm-up Time parameter is set to 0 (default), the server
performs activation at full weight immediately upon a change in
operational status from inactive to active after waiting the Recovery
Time.
Default: 0 seconds
Note: Not applicable for farm servers where load balancing decision is
made using the Cyclic Dispatch Method.
171

Parameter
Description
Connection Limit
Maximum number of simultaneous users that can be directed to the

physical server. This depends on the farms Sessions mode (see Client
Table Sessions Modes, page 268). When the limit is reached, new
requests are no longer directed to this server. All open sessions are
continued.
When this is configured to 0 (default), this mechanism is disabled for
this physical server and there is no user number limit.
Note: When configuring the physical server, ensure that the
Connection Limit in the farm servers with the same Server
Name is lower than or equal to the Connection Limit in the
physical server. The total number of active sessions that run
simultaneously on the farm servers must not be higher than
the Connection Limit value defined on the physical server.
Maximum number of application server connections.
You can configure a trap to be sent if a certain percentage of the
connection limit configured for the server is exceeded.
Default: 0, (no maximum)
4.
Peak Load
Maximal number of frames per second dispatched to server since last

reset.
Attach Users
The total number of currently active users attached to this server.
Frames Rate
Number of Bytes load rate per second dispatched to server.
Frames Load
Number of Bytes load per second dispatched to server.
Conn Limit Reached
The limit for the maximal number of client sessions which can be
opened on this server has been reached.
Click Set. Your configuration is set
Application/Farm Servers
AppDirector works with server farms rather than with individual servers. An AppDirector farm is a
group of networked servers that provide the same service. Utilizing multiple servers organized in a
farm accelerates the service response time and improves overall performance.
An application server (also called farm server) is identified by the name of the farm it belongs to, the
IP address of the server and the server port. The server name is mandatory and identifies the
physical server providing the service. A single application server can be included in a farm several
times, with a different Server Port number for each instance. For example, an HTTP web server
might use ports 8080, 8081, and 8082.
To add or edit an Application/Farm server to a server farm

1.
From the AppDirector menu, select Servers > Application Servers > Table. The Server Table
window appears.
2.
Click Create. The Server Table Create window appears.
172

Parameter
Description
Server Name
Application/Farm Server identification.
Farm Name
Name of the farm to which this application server belongs.
Server Address
The IP address of the physical server that provides this application.

The address is defined for each application server, so that a physical
server can have several IP addresses.
Server Port
Allows you to configure several application servers belonging to the same

farm by using the same physical server with the same IP address. with a
different Server Port number for each instance. For example, an HTTP
web server might use ports 8080, 8081, and 8082.
If Server Port is set to None, only one instance of the application
associated with the Server Address is available as a farm server in the
current farm.
Server Description
A free text field where you can type a description for each server.
Maximum Length: 80 characters.
The server description is not saved in the configuration file. If you export
the configuration file and upload it, the server description is not saved.
Admin Status
Admin Status is the user defined management status of the server that
you can change at any stage of servers configuration or operation. The
following options are available:
Enabled: The server is enabled to receive new requests.
Disabled: The server is not active. When setting the Admin Status to
Disabled, AppDirector removes all entries relevant to this server from
the Client Table, stops sending new requests to this server, and
disconnects all connected clients.
Connections-Shutdown: No new connection will be forwarded to

the server, even if persistency information (client IP or Layer 7
session id) indicates this server. Traffic on existing connections is still
forwarded to the server until the connection is closed or inactivity
Aging Time is reached.
Sessions-Shutdown: New connections that do not belong to an
existing session on the server will not be forwarded to the server. An
existing session is defined by persistency information (client IP or
Layer 7 session id) that indicates this server. New connections
belonging to an existing session are still forwarded to the server until
all connections related to this session are closed and the Layer 7
session id reaches its Aging Time.
Before performing maintenance procedures, set Admin Status to
Shutdown. Start maintenance procedures after active sessions
completion.
Operational Status
Operational status of application on server.

Active: server is active
Not In Service: server is or will become inactive. Existing sessions
will be redirected to other servers.
No New Sessions: server will receive no new sessions. Existing
sessions are allowed to complete.
173

Parameter
Description
Forwarding Parameters
Type
Server types are:

Regular (Default): A local server.
Local Triangulation: A local server that sends response directly to
client, bypassing AppDirector. Sending responses in this way reduces
the number of hops through which the reply packet passes,
improving the response time. In addition, the traffic passing through
AppDirector is reduced, since most incoming requests are rather
small and outbound traffic represents the bulk of data exchanged
between clients and servers. When working in the Local Triangulation
mode, the inbound traffic must flow through AppDirector as in the
regular configuration. The response from server to client, however, is
sent directly to the client, without passing through AppDirector. The
client can be located on the same network as AppDirector and the
server, or it can be located behind the router. Server Port must be set
to None for Local Triangulation servers. Local Triangulation servers
are also known as Loopback servers.
Distributed AppDirector (Global License Only): A remote
AppDirector which manages another server farm providing the same
service in another location. AppDirector devices exchange dynamic
information about the load. Clients requests are redirected to the
nearest and most available site using various redirection methods.
Note: The Server Port must be set to None for Distributed AppDirector
servers.
Local Farm: The server is a farm configured on this AppDirector.
AppDirector utilizes the Redirect to Self feature. The farm regards
the Local Farm as a regular server, except that clients can be sent to
the Local Farm only using the HTTP and DNS redirection.
Local AppDirector: Used in configurations where a farm server on
AppDirector 1 is an AppDirector 2. Traffic from AppDirector 1 is
forwarded to AppDirector 2. Information about load balancing of
servers on AppDirector 2 is provided using LRP.
Remote Server (Global License Only): A stand-a-lone server that
is placed at a different site than AppDirector. Traffic is redirected to a
Remote Server using all redirection methods except for Global
Triangulation. The server port can be set to a value other than None
for remote servers only if the farms redirection mode includes HTTP,
SIP or RTSP. Otherwise all the remote servers with the same IP are
considered a single server.
Redirect To URL
The URL to which traffic is redirected when HTTP, RTSP or SIP redirection
by name is performed (Redirection by Name must be configured in the
farm redirection settings).
This option is available for:
Global License
Redirect to Self capability.
Farm Name for Local This allows you to configure the farm whose load and availability should
Farm
be the load and availability of this server. This parameter is mandatory
for servers of type Local Farm and it is not configurable for any other
type of server. You must configure the correct Farm Name in the local
farm server. If no Farm Name is configured the server is Not In Service.
174

Parameter
Description
Load Balancing Parameters
Weight
The weight of the server in a farm is the servers priority or importance

relative to the other servers in the farm. You can define that a particular
server in a farm has more weight than other servers, so more traffic is
forwarded to this server than to other servers.
Server weights operate as ratios. For example, when the Dispatch
Method is set to Least Number of Users, the weights determine the ratio
of the number of users between the servers. If the Least Amount of
Traffic method is used, the weights determine the ratio of the amount of
traffic between the servers. A server with weight 2 receives twice the
amount of traffic as a server with weight 1.
Values: 1(default) - 10,000
Response Threshold This defines the number of milliseconds where the server may reply to
the GET command. When the server's reply takes longer, the status of
the logical server is set to No New Sessions.
Default: 0
Bandwidth Limit
Maximum amount of bandwidth in Kbps allowed for this application

server. If traffic through the server exceeds the configured limit for any
given second, AppDirector drops excess packets.
Notes:
Bandwidth Limit is measured in Kbps, so 1Mbps is represented with a
bandwidth limit of 1000. A value of 0 = no bandwidth limit.
On OnDemand Switch 3 platforms the bandwidth limit cannot be
enforced.
Default: 0 (No Limit).
Connection Limit
This is the maximum number of users that can be directed to the

application server. The number of users allowed depends on the Sessions
Mode selected:
When the Entry Per Session or Server Per Session modes are
selected, the number of users is the number of sessions on this
server.
When the Regular mode is selected, the number of users is the
number of client IPs whose sessions were forwarded to this server.
Default: 0 (disabled for this server and no user number limit).
Values: 0 - No maximum
Note: The Connection Limit parameter can be exceeded when an
existing client opens a new session and, according to the
Sessions mode, the session uses the same server. This applies
when using the Entry Per Sessions Mode. To allow exceeding
the Connection Limit parameter, you can enable the Connection
Limit Exception parameter, which defines how AppDirector
behaves when there is a conflict between Connection Limit and
persistency scheme. The Connection Limit Exception parameter
is defined for each farm.
175

Parameter
Description
Redundancy Parameters
Operation Mode
Determines whether the server is a backup server or not.

Regular (Default): The server's health is checked, as long as it is
available the server is eligible for receiving client requests.
Backup: The server's health is checked, but the server does not receive
any client requests. The server becomes eligible for client requests when
all the servers in the Regular mode have failed.
Backup Preemption
Determines when the failover mode between the server and its specific
backup address, after the specific backup server took over.
Enabled (default): Once the server becomes active again, it takes
over from the specific backup server.
Disabled: Specific backup server remains active as long as it is
available, even after this server recovers from failure.
Notes:
This is relevant only when a Backup Server Address is configured.
Backup Server
Address
Defines another server in this farm that specifically backs up this

application server. If this application server fails, the dedicated backup
server is used for all sessions of the failed server.
Default : 0.0.0.0, indicating that no specific backup server is defined.
Note: A Backup Server Address can be used with Backup Preemption.
Client NAT
Client NAT
Defines whether Client NAT should be performed on sessions to this

server.
Enable
Disable
Client NAT Address

Range
4.
Defines the Client NAT IP range to be used for NATting sessions to this
server. Also see Client NAT Quick Setup, page 277.
Tracking Farm Servers

To enable tracking of all the farm servers associated with the specific physical server, farm servers
are organized in groups, identified by the server name. All farm servers with the same server name
are considered by AppDirector as running on the same physical server. Farm server parameters are
configured per farm and per server, and control the process of providing a particular service.
Physical server configuration is performed for each server name, and applies to all farm servers on
the same AppDirector with the same name, implying they all run on the same machine.
Notes:
>> For Local Farm servers, the server IP address must be the Layer 4 Policy VIP that points
to the local farm.
>> FTP traffic cannot be load balanced between multiple instances of the application. The
Server Port parameter of an FTP server must be set to 0.
176

>> All farm servers with the same IP and belonging to the same farm must have the same
server type.
>> If the server type of one of these farm servers is changed, the server type of all farm
servers sharing the same IP and farm name as the changed server will also
automatically change.
>> The server port must be specified for AppDirector to recognize which port the application
is running.
>> If the server port is disabled then AppDirector cannot change the destination port and
automatically uses the Layer 4 VIP port instead
Dispatch Methods
Dispatch Methods are the load balancing algorithms that determine how client requests are
distributed between servers in a farm. AppDirector receives requests for service from clients and
decides to which server to direct each request. During this process, AppDirector finds the best
server to provide the requested service. The criterion according to which AppDirector selects the
best server is defined by the Dispatch Method.
You can define the Dispatch Method during the process of AppDirector Farm configuration, according
to the farm characteristics and users needs. This may differ between applications, depending on the
service that the particular farm provides. For example, the number of users is a significant factor for
a Web farm, while the amount of traffic can be more important for an FTP farm. The following
Dispatch Methods are available:
Cyclic
When this is selected, AppDirector forwards traffic dynamically to each sever in a round-robin
fashion.
Weighted Cyclic
This method combines the Cyclic dispatch method with server weight considerations. The weight of
a server in a farm is the servers priority, or the servers importance. You can define that a particular
server in a farm has more weight than other servers. Therefore, more requests for service are
forwarded to this server than to servers with a lower weight.
When the Weighted Cyclic dispatch method is selected, AppDirector distributes clients requests for
service in the round-robin manner, taking into consideration the weight of servers in that farm.
Explicitly, every new session is distributed to the next server up to the server weight. For example, if
one server has a weight of 2 and another server has weight of 5, the first two sessions are sent to
#1, the next five are sent to #2, sessions eight and nine are sent to #1 again, and ten to fourteen
are sent to #1 etc. For more information about servers weight, see Configuring Servers, page 170.
Fewest Number of Users

This is used when a new request for service is sent to an AppDirector Virtual IP address. It is
directed to the server with the least number of sessions at that given time. Server weight is also
considered.
Note: The number of sessions is defined by the number of active Client Table entries that
contain information about the sessions in which this server participates (see Client Table
Management, page 264).
177

Fewest Number of Users - Local

This method is used when the same servers participate in multiple farms. When this method is
selected, AppDirector looks for the server with the fewest number of users only within the farm that
is currently addressed by the client. Traffic of other farms is not considered.
Least Amount of Traffic

Using this method, a new request for service is directed to the server with the least amount of traffic
at that given time. Server weight is also considered.
Note: Traffic is defined as packets per second (pps) from AppDirector to the server and from
the server to AppDirector (back to the client), as recorded in AppDirectors Client Table
for all traffic forwarded to that server.
Least Amount of Traffic - Local

This method is used when the same servers participate in multiple farms. AppDirector looks for the
server with the least amount of traffic only within the farm that is currently addressed by the client.
Traffic of other farms is not considered. Server weight is also considered.
Response Time
This method allows AppDirector to select the fastest server in the farm. When this method is used,
the load balancing process is based on choosing the least loaded server as calculated by the
Response Level measured by the Health Monitoring module.
The Health Monitoring module enables users to track the round trip time of Health Checks. The
device keeps a Response Level indicator for each check. The Response Level is the average ratio
between the response time and the configured Timeout.
This average is calculated over a number of samples as defined in the Response Level Samples
parameter. A value of 0 in the Response Level Samples parameter disables the parameter; any other
value between 1-9 defines the number of samples. The Response Level Samples parameter can be
used in the Health Checks in which the Measure Response Time parameter is enabled. Server weight
is also considered.
Note: If all servers in the farm have the same response level, AppDirector will choose one of
the servers all the time according to its IP address.
To configure Response Time Dispatch Method

1.
Enable the Health Monitoring module for this farm, and set the Response Level Samples
parameter and the Measure Response Time parameter for each Health Check.
2.
Set the farms Dispatch Method parameter to Response Time.
Hashing
When this method is applied, AppDirector selects a server for a session using a static Hash function.
This method enables AppDirector to repeatedly direct requests from the same client to the same
server within a farm even after the client entry has aged, as long as the server is still in service. This
Dispatch Method also provides support for reverse proxy Web farms, avoiding data replication
among the proxy servers.
178

A static Hash function enables AppDirector to choose the server for a session on the basis of the
sessions information. The input for the Hash function is usually the Client IP only. A formula is
applied to this IP address. The output that is received is a numeric value.
Note: When a Hash result indicates to use a server with the status of Not in Service, a second
Hash is used to select an available server for the session.
SNMP Based Dispatch Global Settings

You can use the Load Balancing Algorithms Global Settings window to set the Server SNMP port.
To define the SNMP Based Dispatch Global Settings

1. From the AppDirector menu select SNMP Based Dispatch > Global. The Load Balancing
Algorithms Global Settings window appears.
Parameter
Description
Server SNMP Port
Server SNMP Port used to poll the relevant statuses from the servers.
Default: 161
3. Click Set. Your preference is recorded.
Private Parameters (Private-1 and Private-2)

This dispatch method could be called "Load Balancing by any parameter that you want". You only
require an SNMP agent running on your servers that can respond with whatever information you
need to load balance. This can be CPU utilization, memory utilization, a number of active TCP
connections or disk free space, for example.
Private 1 and Private-2 work in a similar fashion. They allow more than a single set of SNMP OIDs
without making a dynamic table. Therefore, you can define Private-1 and use it in one farm and then
define Private-2 and use it in another.
AppDirector polls each server in a farm that uses Private-1 or Private-2 with SNMP GET for the
OID(s) that you defined. The replies are normalized into a percentage scale 0.100% and applied as
a dynamic weight to the server's number of client table entries when the load balancing decision is
made. This means that when Private-1 or Private-2 are used, AppDirector uses the Least Number of
Users dispatch method.
When the Private-1 or the Private-2 Dispatch Method is selected, AppDirector queries the farms
servers for private SNMP parameters according to a predefined private weights scheme. The ratio of
sessions on the servers is balanced according to the statistics.
You need to define which MIB variables are queried and set the private weights scheme. The
parameters are set according to the weights that you define in the first private weights scheme for
Private-1, and in the second private weights scheme for Private-2.
Note: When using these Dispatch Methods, you need to configure the Private Scheme. In this
scheme, you can set the weight of the statistics parameters.
179

To configure private parameters load balancing

1.
From the AppDirector menu, select SNMP Based Dispatch > Private Parameters. The
Private Parameters window appears.
2.
Set the parameters.
Parameter
Description
Serial Number
Serial no. of the scheme. Scheme no. 1 is used for dispatch method
private-1, etc.
Check Period {sec}
Time interval between queries for the requested parameters.
Var 1 Object ID
SNMP ID of the first private variable to check.
Var 1 Weight
Relational weight for considering value of first parameter.
Var 2 Object ID
SNMP ID of the second private variable to check.
Var 2 Weight
Relational weight for considering value of second parameter.
Retries
Describes how many unanswered requests for a variable will make it be

ignored in the load balancing decision.
Community
Community name to use when addressing the server.
Var 1 Mode
Measuring percentage free or percentage busy of first parameter.

Percent Free: Variable value specified in Var1 Object ID describes
the percentage still free.
Percent Busy: Variable value specified in Var1 Object ID describes
percentage currently busy.
Var 2 Mode
Measuring percentage free or percentage busy of the first parameter.

Percent Free: Variable value specified in Var2 Object ID describes
the percentage still free.
Percent Busy: Variable value specified in Var2 Object ID describes
percentage currently busy.
3.
When updating Private Parameters, select the desired server. The Private Parameters Update
window appears which contains the above parameters:
Windows NT Load Balancing Parameters

There are two Windows NT servers load balancing algorithms. These parameters are used to load
balance the users of the farms that are configured with nt-1 or nt-2 dispatch methods. You use the
Windows NT Parameters window to configure the Windows NT load balancing algorithm.
180

To configure Windows NT load balancing

1. From the AppDirector menu, select SNMP Based Dispatch > Windows NT Parameters. The
Windows NT Parameters window appears.
Parameter
Description
Serial Number
Serial number of the scheme. Scheme number 1 is used for dispatch

method nt-1, etc.
Check Period
Time interval between queries for the frequently updating parameters

(number of open sessions, amount of traffic).
Open Session Weight
Relational weight for number of active sessions on the server.
Incoming Traffic
Weight
Relational weight for amount of traffic coming into the server.
Outgoing Traffic
Weight
Relational weight for amount of traffic going out of the server.
Regular Check Period
Time interval between queries for other less dynamic parameters

(average response time, limits on users and TCP connections).
Response Weight
Relational weight for average response time of the server.
Users Limit Weight
Relational weight for limit on number of logged in users on server.
TCP Limit Weight
Relational weight for limit of TCP connections to the server.
Retries
Defines how many unanswered requests for a variable will make it be

ignored in the load balancing decision.
Community
Community name to use when addressing the server.
3. When updating Windows NT Parameters, select the desired server. The Windows NT Parameters
Update window appears which contains the above parameters.
4. Click Set. The algorithm is set.
Local Triangulation
The Local Triangulation mode provides the ability to send servers responses directly to the client.
Sending responses that way reduces the number of hops through which the reply packet passes,
improving the response time. In addition, the traffic passing through AppDirector is reduced, since
most incoming requests are rather small and outbound traffic represents the bulk of data exchanged
between clients and servers.
181

When working in the Local Triangulation mode, the inbound traffic must flow through AppDirector as
in the regular configuration. When a new request for service arrives, AppDirector selects the best
server for the required service. The response from server to client, however, is sent directly to the
client, without passing through AppDirector. The client can be located on the same network as
AppDirector and the server, or it can be located behind the router.
Note: Layer 7 Switching, which requires Delayed Binding, is not supported when using Local
Triangulation. When using Delayed Binding, AppDirector acts as a reverse proxy
between clients and server.
Note: AppDirector determines the VLAN tag that is used according to the destination IP of the
packet after AppDirector has made all the required modifications to the packet. When
using Local Triangulation, AppDirector forwards packets to servers with the destination
IP of the farm. However, the tag must be set according to the subnet of the servers.
Configuring Local Triangulation

Configuring the Local Triangulation mode involves the following steps:
1.
Setting up farm servers to operate in Local Triangulation mode.
2.
Enabling this capability in the servers themselves.
Farm servers can be configured to operate as Local Triangulation type servers. You can add Local
Triangulation type servers and Regular type servers to the same farm. Local Triangulation is
effective for one-leg topologies and reduces traffic on the AppDirector interface. The process of
defining Local Triangulation is dependent on the operating system installed on the farm servers.
Setting up Local Triangulation on the physical servers requires adding a loopback adapter. A
loopback address is a valid IP address assigned to a server. The server does not respond to ARP
requests destined to the loopback address. The address assigned to the loopback adapter is the
address of the Virtual IP. The server responds directly to the client with the AppDirector virtual
address, eliminating the need for server-to-client traffic to flow through AppDirector.
Farm Connectivity Checks for Local Triangulation Servers

Farm connectivity checks defined for Local Triangulation servers use the Layer 4 Policy VIP as the
Destination IP. When a farm that includes a Local Triangulation server is associated with more than
one Layer 4 Policy VIP, AppDirector checks the server using the first VIP that was found in the Layer
4 Policy. Do not include the same Local Triangulation server in a farm associated with multiple VIPs.
If the same servers serve multiple VIPs, include these servers in multiple farms, and associate each
farm with a single Layer 4 Policy VIP.
Health Monitoring Checks for Local Triangulation Servers

When defining Health Monitoring checks for a Local Triangulation server, you can set the Destination
IP for a check to the Layer 4 Policy VIP. When a farm that includes a Local Triangulation server is
associated with more than one Layer 4 Policy VIP, you can define multiple Health Checks using
different VIPs.
If there is a problem, since the relations between check definitions can be only AND or OR, it is
impossible to identify the service (which Layer 4 Policy VIP) in which the problem occurred from the
check results. Therefore, when a single server is available via multiple VIPs, multiple Health Checks
are associated with the server, but there is no association between the Health Checks and the VIPs.
For further information regarding Health Monitoring checks, see Health Monitoring Check Table,
page 333.
182

Traffic Management Policies

This section discusses how AppDirector Traffic Management enhances application delivery via Server
Load Balancing and Application Acceleration and includes these topics:
Layer 4 Policies, page 183
Layer 4 Policies Lookup Mechanism, page 186
Layer 4 Policy Statistics, page 187
HTTP Policies, page 188
TCP Policies, page 192
Layer 4 Policies
A Layer 4 Policy allows you to set a single point of entry, i.e., a single Virtual IP address, for a variety
of application services, allowing different groups of users to receive services according to their
individual needs.
All the VIPs managed by AppDirector are defined under Layer 4 Policies. When AppDirector receives
the first packet of a session destined to a Virtual IP address, it searches for a Layer 4 Policy that
matches the Layer 4 Protocol, Destination port, Source IP, etc. Then, based on this information,
AppDirector selects the farm allocated to this service and the best server for the task from that
farm, and forwards the packet to that server.
Note: For FTP, there is no need to create a port 20 Layer 4 policy for the active FTP-data
connections. AppDirector handles active and passive data connections to the same VIP
as the FTP-control Layer 4 policy automatically. FTP-data exists as an application if a
direct active FTP-data connection to a port other than 20 occurs.
In addition to farm selection, the Layer 4 policy also defines application acceleration policies to be
applied on traffic matching the Layer 4 policy, when required. Application acceleration policies
include SSL offload configuration, compression and caching rules and HTTP multiplexing activation.
To set up or update a Layer 4 Policy

1. From the AppDirector menu, select Layer 4 Traffic Redirection > Layer 4 Policies. The
Layer 4 Policies window appears.
2. Click Create, OR select the Layer 4 Policy Name if you wish to update. The Layer 4 Policy
Create window appears
Parameter
Description
Layer 4 Policy Name
A unique name identifying the Layer 4 Policy.
Policy Classifiers
Virtual IP
The IP address through which clients access the application service/s

that this Layer 4 policy processes.
183

Parameter
Description
Layer 4 Protocol
The Layer 4 protocol for which the policy provides services. Values
include:
TCP (Default)
UDP
ICMP
SCTP
Any: Any IP protocol, including TCP, UDP and ICMP
Other: Any IP traffic that is not TCP, UDP or ICMP
Layer 4 Port
Destination Layer 4 port for the configured Layer 4 Protocol.

Default: Any.
Application
The Application parameter allows using custom TCP or UDP ports for
applications that require special handling, such as HTTP, HTTPS, FTP,
SIP, etc. For example, use port 2100 for FTP Control Channel.
For well-known protocols, such as 80 for HTTP, there is no need to
specify the application.
For Virtual IP Interface configuration, the Application parameter must
be set to Virtual IP Interface.
Applications supported include:
Any (Default)
RTSP
FTP Control
TS COOKIE
HTTP
RADIUS
HTTPS
TCP
PING
TPTP
REXEC
UDP
RSH
Virtual IP Interface
SCTP
MH-SCTP (MultiHoming SCTP)
SIP
Generic-SSL (with Layer 4 Port

defined)
DNS (for Layer 7 load

balancing only)
Source IP From
Starting address of range of client IPs for which policy provides

services.
Source IP To
Last address of range of client IPs for which policy provides services.
Segment Name
Name of segment to which this Layer 4 policy belongs. Also see

Implementing Segmentation with AppDirector, page 400.
Policy Actions
Farm Name
Farm providing services for traffic matching this policy. If a Layer 7

policy is configured, this parameter is not available.
Default: None.
Layer 7 Policy Name
Select from predefined policy. Determines that Layer 7 farm selection

must be applied to the traffic that matches the Layer 4 Policy.
Default: None.
Note: This is HTTP dependent and cannot be used with Generic-SSL
offloading, if selected in the Layer 4 Policy Application.
184

Parameter
Description
HTTP Policy
Defines HTTP traffic related parameters both in terms of classification

and traffic handling. A default HTTP policy is automatically linked to
any new Layer 4 policy. Also see HTTP Policies, page 188.
Note: An HTTP Layer 4 policy is a Layer 4 policy with the Layer 4
Port set to 80 or the Application parameter set to HTTP.
TCP Policy
Select a predefined TCP Policy to enable back-end connection pooling

for a generic TCP. This enables you to reuse existing TCP connections
to back-end application servers, reducing both the handshake time
and processing overhead of establishing new TCP connections on the
back-end application server to serve subsequent requests.
Default: None.
Note: A TCP Layer 4 policy is a Layer 4 policy with the Application
parameter set to TCP.
SSL Policy
Select a predefined SSL policy to enable SSL offload for traffic

matching the Layer 4 policy. This specifies SSL related behavior such
as service server certificate, allowed Cipher suites etc. See SSL
Policies, page 195 for details.
Default: None.
Caching Policy
Select a predefined Caching policy to enable caching for HTTP traffic

matching the Layer 4 policy. See Caching Policies, page 220 for
details.
Default: None
Compression Policy
Select predefined Compression policy to enable compression on the

HTTP traffic matching the Layer 4 policy. Also see Compression
Policies, page 224.
Default: None
Client Authentication
Policy
Select predefined Client Authentication policy to enable Client

authentication for SSL offload on HTTPS traffic matching the Layer 4
policy. For details, see Client Authentication Policies, page 199.
Default: None
185

Parameter
Description
Policy Settings
Redundancy Status
Defines whether this policy is active for main or backup device.

Values: Primary (default) or Backup.
Note:
This is not relevant when operating in an Active-Backup VRRP
redundant configuration.
The Layer 4 policy redundancy status has no affect on VRRP
configurations. In these configurations, the status is derived from
devices associated with the VRID which is bound to the policy.
Policy DefinedBy
Reports whether this policy was created by a user or by the system

(for Triangulation VIP).
Backend Encryption
Port
4.
Sets the port to which an AppXcel device sends the backend host
encrypted traffic. The Backend Encryption Port must be set to the
same value as the Server Port in the Tunnel that is defined on AppXcel.
Layer 4 Policies Lookup Mechanism

When AppDirector receives a packet where the Destination IP address is a Virtual IP address,
AppDirector performs the following steps:
AppDirector searches its Client Table for a matching entry.

The match can be either a full Layer 4 match for a farm whose Sessions Mode is different than
Regular mode, or a match of Source IP, Destination VIP and Destination port. If a matching
entry is found, the packet is forwarded according to the existing server selection. If no matching
entry is found, AppDirector performs Step 2.
AppDirector searches its Layer 4 Policies to find an entry that matches the traffic
This is performed according to existing farm selection in the following order:

1.
First AppDirector searches for a full match between the Destination IP, Destination IP Protocol
and Destination Port fields of the incoming packet parameters and Layer 4 Policy Virtual IP,
Layer 4 Protocol, and Layer 4 Port parameters.
2.
If no match is found, AppDirector re-scans the Layer 4 Policies again, looking for a full match
between the Destination IP address and Destination IP Protocol fields of the incoming packet,
and Layer 4 Policy Virtual IP and Layer 4 Protocol parameter, which include TCP, UDP, ICMP, Any
or Other.
3.
If no match is found, AppDirector re-scans the Layer 4 Policies looking for a match between the
Destination IP address of the incoming packet and the Layer 4 Policy Virtual IP parameter.
4.
If there is no match, the packet is discarded.
5.
If the entry is matched, AppDirector performs an additional search in the Layer 4 Policies Table,
checking whether the incoming packets Source IP fits into the Layer 4 client IP address range.
6.
This search is applied only to entries that were matched in Step 2.
7.
The Layer 4 policy redirects the traffic to the proxy if SSL/Cache/Compression/Client

Authentication policies are attached to it.
186

8. The traffic from the Proxy is then redirected back to the AppDirector to an internal Layer 4 policy
and from there to a farm and server.
9. After a policy is matched, a server is selected within the farm associated with the matched
policy, and the packet is forwarded to that server.
10. If the Layer 4 Policy is mapped to a Layer 7 Policy, the Delayed Bind is activated. When
AppDirector receives enough information from the HTTP Header, a farm can be selected
according to that Layer 7 Policy.
Note: The order of configured policies has no impact; the most specific policy is always
matched, using the above logic.
Layer 4 Policy Statistics

A Layer 4 Policy is a single point of entry into your network that provides you with a variety of the
application services allowing different groups of users to receive services according to their
individual needs. The Statistics window allows you to view the statistics of a particular policy.
To view statistics for Farms

1. From the AppDirector menu, select Layer 4 Traffic Redirection > Statistics. The Layer 4
Policy Statistics window appears.
2. You can view these read-only parameters:
Parameter
Description
Virtual IP
A single point of entry through which clients can access a variety of

application services is called Virtual IP address (VIP).
Layer 4 Protocol
The Layer 4 protocol used by the relevant policy. Values include:

TCP (Default)
UDP
ICMP
SCTP
Any: Any IP protocol, including TCP, UDP and ICMP
Other: Any IP traffic that is not TCP, UDP or ICMP
Layer 4 Port
Destination Layer 4 port for the configured Layer 4 Protocol.

Default: Any.
Source IP From
Starting address of range of client IPs for which policy provides services.
Total Matches
Displays total number of packets that matched the Layer 4 Policy.
Last Second
Matches
Up to the second update on policy matches.
3. Click a Virtual IP of the desired policy. The Layer 4 Policy Statistics Update window appears
with the statistics on the policy.
187

HTTP Policies
Serving high numbers of concurrent users requires Web Servers to handle large volumes of
connections, which can exhaust Server connection capacity, and affect clients Quality of Experience
(QoE). To lower the connections volumes AppDirector offers the option for multiplexing HTTP
connections, thus serving multiple clients over much smaller number of server connection and
ensuring short response time by Server's, which leads to improving clients QoE.
Since HTTP policy is compulsory in most Layer 4 policies (any policy that is port 80 or 443 or
application HTTP or HTTPS), there is a "Default" HTTP policy that you can configure that is attached
to any new Layer 4 policy created.
What is HTTP Multiplexing?

HTTP request multiplexing (connection reuse) inspects and load balances HTTP requests and
provides server offload via request multiplexing. You can use the HTTP multiplexing approach to
distribute HTTP requests more intelligently across a farm.
HTTP Multiplexing as defined here, includes a pool of Back-End connections utilized to serve the
Front-End connection. These connections are re-used whenever an idle connection is available for
the required server. If there is no idle connection at the request time, a new connection with the
Back-End server is set.
Persistent Layer 7 Switching Process

Using HTTP 1.1, a client can send multiple requests for service over a single TCP connection.
AppDirector with Persistent Layer 7 Switching supports full inspection of all HTTP requests within the
same TCP connection. The requests for service sent using HTTP 1.1 can be forwarded by AppDirector
to the required farms and servers.
AppDirector with Persistent Layer 7 Switching has the ability to forward requests for service to
different servers without closing the TCP connection with the client when using the following
AppDirector mechanisms:
Layer 7 Policies for farm selection.
Session IDs for server persistency.
During persistent Layer 7 Switching, AppDirector constantly inspects all HTTP requests and ensures
that an appropriate farm/server handles each request. This is transparent to the client and saves
system resources because AppDirector keeps a single TCP connection with the client. The process
includes the following steps:
1.
A client sends SYN towards AppDirector Layer 4 Policy VIP.
2.
AppDirector performs a TCP handshake with the client to receive the HTTP request.
3.
AppDirector analyzes the GET requests data and selects a farm/server according to the first
request.
4.
AppDirector initiates a TCP handshake with the server and forwards the traffic to it.
5.
AppDirector inspects further requests over the same TCP connection.
6.
When a new farm or server is required, AppDirector opens a new TCP connection with the
server.
Note: Persistent Layer 7 Switching sessions are not mirrored to a redundant AppDirector.
Persistent Layer 7 Switching and NAT

When Persistent Layer 7 Switching is configured for the Layer 4 Policy in the Complete and
Overwrite or Complete and Maintain modes, the same physical server can reside in more than one
farm under the same Layer 4 Policy. In such a case, Client NAT must be used on each farm
188

Persistent Layer 7 Switching - Per Transaction

Persistent Layer7 switching can also be used to distribute individual requests from the long lived TCP
sessions across multiple servers.
This is configurable using a farm configuration flag: Select Server Per Transaction.
When Select Server Per Transaction is set to Enabled, AppDirector selects a new server for each
transaction in the same connection. Explicitly -when server persistency is not used or when the
Persistency Parameter is not present in the request.
When Select Server Per Transaction is set to Disabled (default), AppDirector uses the same server
for a connection, unless a different farm is selected by Layer 7 policy, or a different server is
required according to server persistency (DSID). The flag is applicable only when Sessions Mode is
set to Select Server Per Session, and is ignored otherwise. You should use Select Server Per
Transaction in cases where there is very little number of long TCP connections.
Configuring HTTP Policies

The HTTP Policy defines the following parameters
1. HTTP Layer 7 classification parameters - relevant only when a Layer 7 policy is attached to the
Layer 4 policy.
2. HTTP Connection Handling parameters:
a.
b.
How to handle back-end connections when performing Layer 7 processing on HTTP 1.1
traffic (multiple requests per connection on the client side) - Layer 7 Persistent Switching
Whether to activate HTTP multiplexing
A default HTTP policy is automatically attached to any Layer 4 Policy.
To configure HTTP Policy

1. From the AppDirector menu, select Layer 4 Traffic Redirection > HTTP Policies. The
AppDirector HTTP Policies window appears.
Parameter
Description
Policy Name
(Mandatory)
A unique policy name.

Default: empty.
Classification
189

Parameter
Description
POST Classification
Input
Defines whether AppDirector inspects the HTTP header or body for the
content-based farm selection.
HTTP POST Classification Input can have the following values:
Header (Default): Information only from HTTP Header is used for
farm selection using Layer 7 Policies. This mode can be used when
all requests, including POST, are classified according to the HTTP
Header only, not by message body.
Body: For POST requests, message body is used for farm selection
using Layer 7 Policies. This is recommended when traffic needs to be
classified according to information in the message body only, as it
provides better performance (as only the relevant part of the request
is classified).
Header and Body: For POST requests, message body and header
are used.
Note: For all HTTP methods except POST, only the HTTP header is
used.
Bytes of Request to
Read
Specifies how deep into the HTTP request AppDirector searches for the
content specified in the predefined Layer 7 Policy methods.
By default, AppDirector searches for defined methods until the end of the
HTTP Header.
Default: 3.5 Kbytes
Maximum: 64 Kbytes
Note: This parameter is also related to the response (when learning
DSIDs).
HTTP Normalization
Enables or disables normalization of URLs in HTTP requests, before

parsing the HTTP request itself. It includes these options:
Disable (Default)
Decode% (Hexadecimal) - For example, http://
%77%77%77%2e%72%61%64%77%61%72%65%2e%63%6f%6
d/ would be www.radware.com.
Normalize directory traversals ('.' and './')
Remove double slashes - '//'
Convert DOS '\' to '/'
Remove NULL characters '%00'
Note: AppDirector uses the normalized request for the Layer 7
classification, but forwards the client's original request to the
server.
190

Parameter
Description
Connection Handling
Layer 7 Persistent
Switching Mode
Used when AppDirector receives an HTTP 1.1 request allowing multiple

client requests over the same TCP connection.
Setting the status of the Persistent Layer 7 switching:
First: AppDirector inspects the first request in each TCP connection,
selects a server, and forwards the request. During the rest of the TCP
connection, AppDirector forwards all further requests to that server.
Overwrite: AppDirector inspects all requests over a single TCP
connection. If a new server is required for additional client requests,
AppDirector closes the connection with the server that was selected
for the first request and opens a new connection with the new server.
Note: Mirroring is not supported when delayed binding is used with
Layer 7 Persistent Switching Mode and configured to either
overwrite or maintain. Mirroring is however supported for when
Layer 7 Persistent Switching Mode is set to First.
Caution: Radware does not recommend using this mode.

Maintain (Default): AppDirector inspects all requests over a single
TCP connection. If a new server is required for additional client
requests, AppDirector opens a new connection with the new server
without closing the connections to all previously used backend
servers.
Note: Using Layer 7 persistency switching mode with value "maintain"
or "overwrite" modifies Sessions Mode behavior in the client
table to remove the entry on session end even if the user has
not configured the farm in this way.
191

Parameter
Description
Multiplex Back-End
Connections
TCP multiplexing is a technique used primarily by load balancers and

application delivery controllers (but also by some stand-alone web
application acceleration solutions) that enables the device to "reuse"
existing TCP connections.
This is similar to the way in which persistent HTTP 1.1 connections work
in that a single HTTP connection can be used to retrieve multiple objects,
thus reducing the impact of TCP overhead on application performance.
TCP multiplexing allows the same thing to happen for TCP-based
applications (usually HTTP / web) except that instead of the reuse being
limited to only 1 client, the connections can be reused over many clients,
resulting in much greater efficiency of web servers and faster performing
applications.
AppDirector establishes a number of connections to the servers in its pool
and keeps the connections open. When a request is received by the
AppDirector from the client, the request is evaluated and then directed to
a server over an existing connection. This has the effect of reducing the
overhead imposed by establishing and tearing down the TCP connection
with the server, improving the responsiveness of the application.
Values: enable/disable (default)
Note: The Multiplex Back-End Connections feature is HTTP dependent
and cannot be used with Generic-SSL offloading, if selected in
the Layer 4 Policy Application. See Layer 4 Policies, page 183.
Back-End
Connection Close
idle timeout
3.
Defines maximum idle time after which connection to the back-end

server is closed. This is not available when multiplexing is disabled
Note:
>> AppDirector does not send X-Forwarded-For to the server when the HTTP policy is set to
First. This does not apply when it is set to Maintain.
>> In First switching mode, the backend connection uses HTTP 1.1 with keep-alive enabled.
TCP Policies
Configuring TCP policies enables you to provide connection pooling for generic TCP protocols (nonHTTP).
In a connection pooled environment, a pool of server connections is maintained for servicing client
connections. When a client requests a connection, an unused connection is selected from the server
pool and used to service the request. When the client request is complete, the server connection is
returned to the pool and the client connection dropped.
This has the effect of reducing the overhead imposed by establishing and tearing down the TCP
connection with the server, improving the responsiveness of the application.
192

Notes:
>> This feature cannot work for HTTP as this requires additional Layer 7 protocol
intervention. For HTTP, AppDirector provides HTTP-level multiplexing activated via HTTP
Policy.
>> When enabling back-end connection pooling for a Layer 4 policy, you must configure
Client NAT on the farms attached to that Layer 4 policy. For details, see Client NAT,
page 275.
>> Layer 7 farm selection and server persistency is not available for generic TCP.
>> To associate a TCP Policy with a Layer 4 Policy, the Layer 4 Policy protocol should be TCP
and the Application should be either TCP or generic SSL.
>> When a generic SSL Application is selected, an SSL Policy also needs to be attached to
the Layer 4 Policy to allow SSL offloading.
To configure TCP policies

1. From the AppDirector menu, select Layer 4 Traffic Redirection > TCP Policies. The TCP
Policies window appears.
Parameter
Description
Policy Name
Unique policy name.

Default: empty.
Connections Pool Size
The maximum number of connections that AD holds in the connection

reuse pool. If the pool is already full, then a server-side connection
closes after the response is completed.
Back-End Connection
Idle Timeout
(seconds)
The maximum time a back-end connection must be idle before it can

be closed, once its lifetime has passed.
TCP Pooling Back-End

Connections
You can enable or disable the back-end connections pooling capability.

Values: Enabled/Disabled
193

SSL Offloading and Authentication

Implementing SSL offloading alleviates strain placed on servers while optimizing not only SSL
duties, but also overall servers network performance. This section covers the following topics:
SSL Policies, page 195
Authentication Policies Overview, page 199
Client Authentication Policies, page 199
Trust-service Status List (TSL) Authentication Policies, page 203
Certificate Validation Policies, page 211
SSL Offloading utilizes a strategy implemented within an organizations data center to handle the
encryption, decryption and verification of Secure Sockets Layer (SSL) transmissions across a
business network. SSL acceleration is the method used for offloading the processor-intensive public
key encryption algorithms involved in SSL transactions to a dedicated device thereby freeing up
server resources that can be devoted to other tasks. AppDirector acts as proxy and offloads all SSL
operations, leaving the software servers to process the clear text which is significantly less intense.
The offloading process also provides added security to business networks by identifying malicious
traffic disguised as normal SSL encrypted files. Because offloading devices are devoted to SSL
activities, they have a better ability to discover these hidden attacks than normal intrusion
prevention systems.
SSL Offloading serves 4 main purposes that contribute together to establishing a secure
communication channel:
Authentication: Each communicating partner should be able to verify that the other is who it
claims to be and not an impostor.
Privacy: A third party should not be able to eavesdrop on a private communication.
Integrity: Protocol should automatically or easily detect any tampering with the transmission.
Non-repudiation: Sender should not be able to claim that they did not send what the receiver
received.
Notes:
>> SSL can encapsulate any protocol and AppDirector can support this. However, some
supporting capabilities for SSL offloading leverage HTTP protocol capabilities and are
therefore are not available when AppDirector is used for generic protocol SSL offloading.
>> Protocols that include special commands for SSL initiation and behavior (FTP, POP3 or
SMTP), require special support and are not guaranteed to work flawlessly in any SSL
environment.
>> The HTTP protocol provides widespread support for SSL offloading but some HTTP
dependent features cannot be used with Generic-SSL over other protocols.
>> For non-HTTP traffic, a generic offloading capability is supported including encryption
and decryption but not parsing or other services. You can select this option from the
Layer 4 Policy application parameter. See Layer 4 Policies, page 183.
Online Certificate Status Protocol (OCSP)

OCSP authenticates network traffic by checking the revocation status of a client certificate using
data stored on a remote OCSP server. Client credentials are based on SSL certificates. See OCSP
configurable parameters in:
To configure AppDirector Client Authentication Policy, page 200
To configure TSL files chain, page 206
To set TSL Authentication Policies, page 209
194

SSL Policies
When AppDirector manages SSL encrypted traffic, the necessary certificates and ciphers must be
defined to allow SSL handshake.
To configure AppDirector SSL Policies

1. From the AppDirector menu, select Layer 4 Traffic Redirection > SSL Policies. The
AppDirector SSL Policies window appears.
Parameter
Description
Policy Name
(Mandatory)
Name of SSL Policy
Front End SSL

Front-end SSL State
This parameter enables you to define whether SSL offload is required

on the front-end. When this parameter is disabled it allows to support
configurations where front-end traffic arrives in clear text, but traffic to
the back-end servers must be SSL encrypted.
Values: Enabled (Default)/Disabled.
Certificate
(Mandatory)
Server certificate to use for SSL connections. The certificate needs to

be defined prior to setting the SSL policy in Security > Certificates.
Cipher Suite
(Mandatory)
This enables you to control which cipher suites are allowed by

AppDirector during SSL handshake. From the drop-down list select the
cipher suite to be associated or type in a requested cipher of your
choice.
RSA (Default): Cipher suite using RSA key exchange.
ALL: All cipher suites.
PCI DSS Compliance: Payment Card Industry Data Security
Standard
ALL Non-Null Ciphers: All cipher suites except the NULL ciphers
and ciphers offering no authentication, which must be explicitly
enabled.
SSLv3: SSL v3.0 cipher suites.
TLSv1: TLS v1.0 cipher suites
Export: Export encryption algorithms including 40 and 56 bit.
Low: Low exception cipher suites, currently using 64 or 56 bit
encryption algorithms but excluding export cipher suites.
Medium: Medium encryption cipher suites, currently using 128
bit encryption
High: High encryption cipher suites. Currently key lengths are
larger than 128 bits.
RSA:RC4-128:MD5: Cipher suites using RSA key exchange, 128
bit RC4 for encryption and MD5 for MAC.
RSA:RC4-128:SHA1: Cipher suite using RSA key exchange, 128
bit RC4 for encryption and SHA1 hash for MAC.
RSA:DES:SHA1:Cipher suite using RSA key exchange, 3DES for
encryption and SHA1 hash for MAC.
195

Parameter
Description
Cipher Suite
(Mandatory)
RSA:3DES:SHA1:Cipher suite using RSA key exchange, 3DES for

encryption and SHA1 hash for MAC.
continued
RSA:AES-128:SHA1: Cipher suite using RSA key exchange, 128bit AES for encryption and SHA1 hash for MAC.
RSA:AES-256:SHA1: Cipher suite using RSA key exchange, 256bit AES for encryption and SHA1 hash for MAC.
MSIE Export56: 56 bit export version of Microsoft Internet
Browser v 5.
User Defined - AppDirector supports all ciphers supported by the
accepted OpenSSL format and more information can be found in
OpenSSL documentation.
Note: For a comprehensive list of all front-end and back-end ciphers
used by AppDirector, see Complete List of the Content Of All
Cipher Suites (Front-end and Back-end), page 593.
User-Defined Ciphers
If the predefined list does not suit your needs, you can specify allowed
ciphers. The OpenSSL convention for specifying ciphers must be
followed. This field is non-active even if defined unless User Defined
is selected in Cipher Suite.
Intermediate
Certificate
Specify if the server certificate used was not provided by a root CA

(Certificate Authority). This is a chain of certificates of the CA-s up to a
root CA.
Values: List of Intermediate CA certificate imported into AppDirector.
Note: If a chain of CAs needs to be sent with the server's
certificate, they should all be imported together to
AppDirector as a single Intermediate CA object. To perform
this action, open each Intermediate CA certificate (PEM
format) in text editor, copy all certificate texts into a single
text chain and then paste it into the Import Certificate text
box
Listening Server port
Enables you to define the port where the backend server is listening.
When changing from HTTPS (port 443) to HTTP (port 80) traffic often
needs to be sent to a different port to where it was originally destined.
Default: 80
Note: If the Back End listening port is not configured, the Layer 4
policy port is used to access the back end servers.
Pass SSL info in

Headers
Select type of information that you need to pass to Back-End servers in

HTTP headers. See step 3.
Note: This feature is HTTP dependent and cannot be used with
Generic-SSL offloading, if selected in the Layer 4 Policy
Application. See Layer 4 Policies, page 183
196

Parameter
Description
Protocol Redirection
HTTP Redirection
Conversion State
See HTTP to HTTPS Protocol Redirection, page 321

When Backend SSL is working, this feature is not needed and you
cannot configure them together.
Values: Enable/Disable (Default).
Notes:
When enabled, conversion is always done when hostname in
response matches hostname in request.
When SSL Policy Protocol Redirection and Layer 7 Header and
Body Modifications are enabled on the same service, and the
server sends a 302 Redirect response, the new location protocol is
always set to HTTPS to enable the redirect location to work for the
clients, (despite the setting in the Layer 7 Modification method).
This feature is HTTP dependent and cannot be used with GenericSSL offloading, if selected in the Layer 4 Policy Application. See
Layer 4 Policies, page 183
Also Redirect When

Host Match The
Following RegularExpression
If HTTP to HTTPS conversion is required for additional hosts besides

service default, you can use this field to define them by Regular
Expression.
Default: Empty.
Note: This feature is HTTP dependent and cannot be used with
Generic-SSL offloading, if selected in the Layer 4 Policy
Application. See Layer 4 Policies, page 183.
Back End SSL

Backend SSL State
Backend SSL provides the ability to re-encrypt traffic between

AppDirector and the Web Servers in environments where enhanced
security is required.
Values: Enable/Disable (Default).
Backend SSL Cipher
Defines Backend encryption strength.

Values: Low (Default), Medium, High, User Defined
Backend SSL User

Defined Ciphers
Supports all ciphers supported by the accepted OpenSSL format and

more information can be found in OpenSSL documentation.
If the predefined list does not suit your needs, you can specify allowed
ciphers. The OpenSSL convention for specifying ciphers must be
followed. This field is non-active even if defined unless User Defined
is selected in Cipher Suite.
Values: 0-64 character string (case insensitive), Default: empty
Note: User-Defined field must be set when User Defined is selected
in Backend SSL Cipher.
3. Please use the following comprehensive Cipher Suite table when configuring your SSL policy.
4. For passing SSL information in Headers, click ... alongside this field. The Passing SSL
information to Back-End servers in HTTP Headers dialog window opens.
197

Notes:
>> When using Generic-SSL offloading, you cannot use HTTP headers to forward data to
servers.
>> "You cannot create an SSL policy where both Front-end and Back-end SSL State
parameters are disabled.
5.
Mark the Information Type that you wish to select and the accompanying Header Name field is
enabled for you to add or edit the appropriate header name. Select from:
Parameter
Description
Cipher Suite
Defines which Cipher suite is to be used during the SSL handshake. The
cipher suite used by the client, for example RC4-MD5.
SSL Version
The SSL version used by the client, for example SSLv3.
Cipher Bits
The number of bits used for encryption by the cipher, for example 128
Bit
Add Front-End
HTTPS Header
Adds a special header to requests sent to the server signaling them that
an SSL offloading device is being used. Servers that support this will
send redirect messages (HTTP 302) with the location set to HTTPS
instead of HTTP (see HTTP Redirection Conversion State parameter
above for more information).
Example
When working with HTTPS to a backend Outlook Web-Access (OWA)
server the responses are not presented properly in a Firefox browser.
This can be worked around using AppDirector SSL information headers
and adding the Add Front-End HTTPS Header to the SSL policy.
The dialog window is shown here.
6.
198

Authentication Policies Overview

SSL authentication allows a server to confirm a clients identity as part of public-key cryptography,
that a clients certificate and public ID are checked to be valid and that they were issued by a trusted
certificate authority (CA).
An authentication policy is a set of settings applied to the authentication process and to the
verification of authentication data.
AppDirector supports two mutually exclusive authentication policies types, they are:
Client Authentication Policies, page 199 Or
Trust-service Status List (TSL) Authentication Policies, page 203
Client Authentication Policies

Client certificates enable network administrators to authenticate clients via a certificate generated
by a central Certificate Authority (CA). When it is necessary to authenticate a client during the
handshake process of the SSL, AppDirector sends a client certificate request to the client. To
complete the handshake, the client then sends the client certificate to AppDirector to be validated. If
the certificate is valid then the handshake process is complete on both sides and can start sending
data. If the certificate is not valid then the session is terminated.
Figure 8: Performing Client Authentication
199

Authentication Setup
1. An Administrator sets up an Organizational CA. As part of this process, the CA has a self-signed
(or 3rd party) Certificate installed on it to identify it.
2. The CA server generates Client Certificates for the Clients. Clients install certificates into their
Browser repository.
3. To create trust between the CA and the Authentication Server (AppDirector), the Client CA
certificate is imported into AppDirector.
4. The Administrator then sets up an OCSP server (may be the same CA, or a central OCSP of a few
organizational CAs).
5. An OCSP URL for sending the OCSP validation requests is set up on the OCSP server
6. The OCSP URL is updated as a field inside the Client Certificate and/or AppDirector.
7. Optionally, the OCSP server receives a certificate for signing OCSP responses or the OCSP
certificate is imported into AppDirector to validate OCSP response
9. CRLs are generated by Clients CA and updated regularly for the OCSP server.
Automated Authentication Flow

1.
As part of the SSL handshake, the Client sends a Client Certificate to AppDirector.
2.
AppDirector matches the Client CA issuer field against the Client CA that is trusted according
to its configuration.
3.
AppDirector checks the Certificates valid dates
4.
AppDirector then sends an OCSP validation request to the OCSP server URL.
5.
The OCSP Server generates a response (valid/invalid), signs it with its own certificates and
returns it to AppDirector.
6.
AppDirector now validates the response with the OCSP Certificate.
7.
If all is verified, a SSL tunnel is established.
To authenticate the clients identity a CA certificate has to be imported into AppDirector. This CA
certificate is used when the AppDirector receives a client certificate and attempts to validate it. The
client certificate is valid only when its issuer conforms to the CA certificate that was imported into
the AppDirector. Client certificates must be installed on the client browsers by the organization or by
the clients. You can check if a valid client's certificate was revoked by the CA by configuring
AppDirector to check its status using OCSP (Online Certificate Status Protocol).
To configure AppDirector Client Authentication Policy

1.
From the AppDirector menu, select Layer 4 Traffic Redirection > Authentication > Client
Authentication Policies. The Authentication Policies window appears.
2.
Set the parameters.
200
Parameter
Description
Policy Name
Name of the Policy.
Trusted CA
Select trusted Client CA certificate. The Client CA Certificate appears in

the Certificates Table after the import. See Importing Certificates,
page 453 for more information.

Parameter
Description
CA Required
Defines whether AppDirector verifies that the specified CA in the Client CA

Certificate field has signed the client certificate.
When disabled, any certificate that the client presents is accepted,
regardless of whether it was issued by the trusted CA.
If OCSP is enabled then the revocation test is performed.
Values: enabled (default)/disabled.
Redirection URL
Defines the URL to redirect clients to when Client Authentication fails and
you wish to notify this to users in a graceful way rather than by default
browser message.
Default: Empty
CA Depth
Users need to be able to look up a trusted CA (known in authentication

policy as Client CA) in a chain of proxy certificates generated by various
elements in the connection path. Each element creates a proxy certificate
for the next element in the chain, so that a chain longer than 9 elements
(currently max allowed depth in authentication policy) can be created.
This parameter therefore enables you to define the maximum
intermediate CAs in the CAs chain that AppDirector will search to validate
the link between the client's certificate to the specified Client CA
certificate.
Default: 2 CAs
Note: Maximum value: 100 CAs (with a larger number of Certificate
Authorities (CA) possible in the chain lookup for a match for the
trusted CA defined in the Authentication policy). This enables
support for client authentication with proxy certificates.
Pass Certificate info Allows forwarding Client Certificate information to the application servers
in Headers
using HTTP headers. For more information see Certificate Information
Headers, page 202.
Certificate
Validation Policy
Enables you to select a Certificate Validation Policy to be used during the

Client Authentication process. For more information see Certificate
Validation Policies, page 211.
Certificate Validation
Certificate
Revocation Check
Defines whether AppDirector verifies that the client's certificate has not
been revoked by the CA (Certificate Authority) before completing the SSL/
TLS handshake. The revocation check can be performed using OCSP.
Values: OCSP / Disable (default).
Response Time
Deviation (sec)
Allows for overlooking small deviations between AppDirector and OCSP

server timestamps for OCSP signatures verification.
Values: 0 (default) - 3600 in seconds
Note: For correct time validation, you should use NTP, and must define
the AppDirector Time-Zone. See Time Settings, page 440.
Verify Certificate
Chain
When enabled, an OCSP request is sent for every certificate in the chain,
When disabled, an OCSP request is sent to client certificate only.
OCSP URI
Precedence
Controls OCSP URI precedence, whether to use the user-configured URI

or the URI that is embedded in the client's certificate.
OCSP URI
Specify a URI for OCSP certificate status check.
201

Parameter
Description
Response Allowed
Signing Algorithm
Defines the specific signature algorithms allowed for signing OCSP

responses.
Values: All (default), MD5, SHA1, SHA256, SHA384, SHA512
OCSP Cache Time
Defines the time for which validated OCSP responses are cached. Since
CA servers update the CRLs on the OCSP parochially (every 12 hours or
24 hours), there is no need to overload the OCSP server with repetitive
OCSP requests for the same certificate. The Caching is per Client
Authentication or TSL Authentication policy and entries are not shared
between policies. The OCSP cache time is defined in minutes.
Values: 0 (default) - 180000 minutes
Note: When set to 0, OCSP Cache is disabled.
Send Nonce
An OCSP nonce offers an optional tool for a relying party to determine

that it is receiving up-to-date certificate status information from a
responder. A nonce is a random sequence of 20 bytes placed in an OCSP
request. The responder must use its secret key to sign a response
containing this nonce.
3.
4.
In the required Layer 4 policy, select the Client Authentication policy that you configured.
To purge Cache
1.
Select policy name from the drop down list with policies names.
2.
Click Purge. The Cache is purged.
Notes:
>> With Generic-SSL offloading, you cannot use HTTP headers to forward data to servers.
>> With each Certificate of Client CA you can bind multiple CA Certificates to a single Client
Authentication policy by concatenating multiple certificates into a single import
operation. To use multiple client CA certificates on the same Client Authentication policy:
open the CAs PEM certificate files with a text editor and copy the content. In the
AppDirector certificate import, paste the certificates text into the text box together one
after the other. During the import they are concatenated.
Certificate Information Headers

In a regular SSL transaction, AppDirector strips off all the client certificates information and issues
an HTTP GET request to the web server. The server cannot log the client information for statistics
and cannot perform any user authorization without relying on the SSL authentication mechanism.
Click
and the Pass certificate info in Headers window appears with a matching checkbox. The
following HTTP header types are displayed, (each information type is shown below with
corresponding parameter name in square brackets).
Note: The CCRT-XXXX in each row below is the default HTTP header name under which
information is sent. This can be changed.
Version - CCRT-Version: [version]
202

Serial Number - CCRT-SN: [serial]
Signature Algorithm - CCRT-SignatureAlgo: [algo]
Issuer - CCRT-Issuer: [issuer]
Validity Dates - CCRT-NotBefore: [before], CCRT-NotAfter: [after]
Subject - CCRT-Subject: [subject]
Public Key Type - CCRT-PublicKeyType: [type]
Certificate - CCRT-Certificate: [certificate]
MD5 Hash - CCRT-MD5Hash: [hash]
If you want to add a given header, check the matching box.
Options for all Header Types
The Certificate Header has two options:
1. Certificate Header Lines Format - Multi Lines (default)/Single Line.
a.
b.
Multi line format is equivalent to esc_ctrl, esc_msb, sep_multiline, spc_eq and lname.
Comments start with /* and end with */.
Single line format is equivalent to specifying the esc_2253, esc_ctrl, esc_msb, utf8,
dump_nostr, dump_der, use_quote, sep_comma_plus_spc, spc_eq, and sname options.
Comments start with //.
2. Information Character Set - ASCII/Unicode - When Using ASCII encoding for sending certificate
details AppDirector uses slash (/) as delimiter between information fields. When using Unicode
encoding for sending the certificates details AppDirector uses commas (,) as delimiter.
Once you click OK, the window generates the argument list separated by the | delimiter.
When Pass Certificate Info in Headers is used, AppDirector can pass required fields of the client
certificate to the web server in the GET requests. An application on the web server then extracts this
information from the GET request's HTTP headers and uses it for proprietary purposes.
A client certificate field is passed on, as is, to the web server. If, for any reason, a field carries no
information, then that field is not passed on to the web server. However, if a field carries some
information, but one or more sub fields do not carry any, for example, the E= sub field in the
Subject field, then that field (Subject) is copied to the HTTP header as is.
To configure AppDirector support for forwarding Client Certificate fields to the back-end web server,
see To configure AppDirector Client Authentication Policy, page 200.
Trust-service Status List (TSL) Authentication Policies

Trust-service Status List (TSL) is an ETSI standard (TS 102 231). ETSI is recognized as an official
European Standards Organization by the European Commission (EC). TSL defines how you can
query the latest, most up-to-date CA information from a central location (for example, the
government). To read more about TSL, see the following topics:
TSL Structure, page 204
TSL Information, page 205
Trusting a TSL, page 205
TSL Configuration Workflow, page 205
TSL File Import, page 205
Configuring TSL Files Chain, page 206
Configuring TSL Authentication Policies, page 209
Configuring TSL Files Repository, page 211
In practice, the TSL standard handles situations where one organization is responsible for the
creation, distribution and management of electronic ID cards (e.g. Government), and other
organizations need to authenticate users based on the e-IDs (e.g. Tax management, Health
203

Insurance, Financial institutes, employers, etc.). In these cases, all organizations using the e-IDs
infrastructure need to be aware of changes performed by the managing organization (i.e. new
servers added to host more user identities).
AppDirector provides support of the TSL standard allowing automatic fetching and updating of client
authentication configuration in compliance with the TSL standard
TSL Structure
The TSL contains four major components, structured as follows:
Scheme information: provides information on the issuing scheme;
List of TSPs: identifies the TSPs recognized by the scheme;
List of recognized Services provided by each TSP: indicates the service(s) provided by these
TSPs and the current recognition status of these service(s);
History information: indicates the status history of each service.
The logical model of the TSL is shown here.
Figure 9: TSL Logical Model
Note: A Free TSL editing tool is available at http://www.osor.eu/projects/tsledit
204

TSL Information
The TSL contains structured information. Some of the information is necessary to identify the TSL
itself or to facilitate its search: a first category of these fields such as TSL tag (to facilitate locating
the TSL with a search engine), scheme information (such as version identifier, scheme operator
name, etc.), are used as header information, to be able identify the correct TSL to be used.
The other data that forms part of the TSL body includes a sequence of fields holding information on
the TSPs that the scheme oversees. Additionally, for each TSP, a sequence of fields holds information
on the service(s) provided by that TSP. For each service, a sequence of fields holds information on
the status history of that service.
Finally, a signature is computed over all fields of the TSL. The logic of the list is that, once the
assessment scheme operator has accredited, or become aware of the existence of, a TSP and of its
services, for each of them the current status, as determined according to the scheme rules, is
indicated in the TSL.
Trusting a TSL
A TSL is a signed electronic document. To verify the signature, relying parties need to be able to
access the applicable public key. Since the scheme issuing the TSL is more hierarchical than the
TSPs governed by that scheme, the authenticity of the public key should not be certified by any TSP
inside or outside the scheme. Providing the scheme's public key is a similar problem to providing the
public key of a CA service. The key used for signing the TSL must have a public-key certificate
published.
TSL Configuration Workflow

In order to setup AppDirector for TSL based clients authentication the following steps are required:
1. Upload a Root TSL Certificate. This is imported into the regular Security feature - Importing
Certificates, page 453.
2. Upload an original TSL file and create a TSL files chain entry associated with the above Root TSL
and TSL file. See To configure TSL files chain, page 206.
3. Create a TSL authentication policy that is associated with the above TSL file chains. See To set
TSL Authentication Policies, page 209.
4. Create a Certificate Validation Policy. See Certificate Validation Policies, page 211.
5. Create a Layer 4 Policy that is associated with the TSL authentication policy, SSL Policy, Farm,
Servers. See To set up or update a Layer 4 Policy, page 183.
6. To ensure that OCSP response time stamps are validated correctly, check that AppDirector time
and time-zone are configured, preferably using NTP. See Time Settings, page 440.
TSL File Import

The TSL File Import feature is designed to add TSL xml files to the TSL repository as part of the
configuration process. The first file import is performed manually and then subsequently,
automatically.
An imported original TSL xml file will usually include:
Trusted Clients CAs
OCSP URLs per trusted CA
Trusted OCSP responders certificates
Main and Backup URL for next TSL file fetching
Max validity time for using the TSL file
On every TSL file import (manual/automatic) a list of validations are performed to ensure its
integrity and currency. These include File signature verification and sequential number progress.
205

To import a TSL File

1.
From the AppDirector menu, select Layer 4 Traffic Redirection > Authentication > TSL File
Import. The TSL File Import window appears.
2.
In the File field, click Browse and locate the file that you want to import. Alternatively, click
Browse to search the directory tree for the file.
3.
Click Import. An Import Finished message appears and a Create Chain button appears.
4.
Click Create Chain. The TSL Files Chain window appears. See Configuring TSL Files Chain,
page 206.
Configuring TSL Files Chain

The TSL Files Chain is the chain of related files created by the continuous updating of TSL files. It
holds TSL files chains with their related updating attributes.
Need for TSL Proxy
In cases where there is no access to the external internet cloud, but the TSL files server is located
externally, you need to define a Proxy server where AppDirector can perform the TSL update
requests.
To configure TSL files chain

1.
From the AppDirector menu, select Layer 4 Traffic Redirection > Authentication > TSL
Files Chain. The TSL Files Chain window appears.
2.
Set the parameters.
Parameter
Description
Chain Name
Identifying name of TSL Files Chain.
TSL Parameters
TSL Root CA
Name of the TSL Root certificate to be used from the certificate table. The
TSL Root Certificate should be first imported into the Certificates Table.
For more information about importing certificates see Importing
Certificates, page 453.
Values: Null (default), TSL Root Certificate.
Original File
206
Name of the original manually uploaded TSL file. For more information
about uploading the original TSL file to AppDirector see TSL File Import,
page 205.

Parameter
Description
Automatic Update
Hours
Defined time (hours and minutes) when AppDirector checks and fetches
an updated TSL File, ( e.g. 02:00).
Values: HH:MM (in 24hr format with multiple values separated by
commas without spaces).
Examples:
14:35 will make the update run at 2:35 PM
02:00,14:15, 18:00 will make the updates run at 2:00AM, 2:15PM
and 6:00PM
Notes:
Setting the Update to none causes automatic updates to be turned
off.
When you change the time, by NTP or daylight saving (see Time
Settings, page 440), TSL updates set before the change will still
occur, ignoring this time change in the pre-scheduled update.
However, after one upgrade, they will reschedule according to the
correct clock.
TSL Proxy
Proxy URI
Proxy URL Address
Proxy Username
User name for the proxy server.
Proxy Password
Password for the proxy server.
Note: Proxy, username and password fields support UTF-8 characters.

3. Once you have established TSL Files chains, you can review them on the TSL File Chain window.
The following parameters will be displayed.
Parameter
Description
Chain Name
Identifying name of TSL Files Chain.
TSL Parameters
TSL Root CA
Name of the current used TSL Root certificate from the certificate table.
This is the current TSL file chain in use that was added manually or the
one replaced via the new TSL file.
Values: Null (default), TSL Root Certificate.
Original File
Name of the original manually uploaded TSL file.
Active File
After initial definition is performed, this field shows the name of the
active TSL file at any time. This is not visible during initial configuration.
207

Parameter
Description
Automatic Update
Hours
Defined time (hours and minutes) when AppDirector attempts to fetch an

updated TSL File, ( e.g.02:00 = 2AM).
Values: Time of day represented as HH:MM (multiple times can be
defined with separating commas).
Examples:
14:35 will make the update run at 2:35 PM
02:00,14:15, 18:00 will make the updates run at 2:00AM, 2:15PM
and 6:00PM
Notes:
Setting the Update to none causes automatic updates to be turned
off.
When you change the time, by NTP or daylight saving (see Time
Settings, page 440), TSL updates set before the change will still
occur, ignoring this time change in the pre-scheduled update.
However, after one upgrade, they will reschedule according to the
correct clock.
Last Import Time
Last time the TSL file was manually or automatically updated. (DD-MMYYYY HH:MM format).
TSL File Active Until Time in which Active TSL file becomes obsolete (in DD-MM-YYYY HH:MM
format). At this time AppDirector will generate an SNMP alert to notify the
situation but will continue to work with the obsolete file's configuration.
An additional alert will be issued on every update interval.
Next TSL Root

Next TSL Root
If a TSL file includes a new TSL root that should replace the defined TSL
Root at a given time, this field will show the name of the new TSL Root
Certificate, (the Next Root TSL file).
Next TSL Root valid If a TSL file includes a new TSL root that should replace the defined TSL
date
Root at a given time, this field will show the time in which the new TSL
Root Certificate will become active for signing new TSL files.
4.
Updating for Authentication

1.
Once an initial TSL configuration has been created, it will now contain the update time and the
location from which to take the next TSL file (Primary and Secondary URIs for next update are
embedded in the origin TSL file). As per update schedule, AppDirector requests a TSL update
from the TSL URL
2.
The TSL server sends a new TSL file.
3.
4.
The TSL Files are parsed by the Authentication server and the following elements are extracted:
Certificates off all trusted Client CAs (with their OCSP URLS)
OCSP server signing certificates
URL of TSL server for next update,
At the specified update time, a new TSL file will be fetched and verified.
AppDirector supports TSL update fetching over the HTTP protocol. If the fetch fails, a connection to
the secondary URL is attempted (up to three times to each URL). If all retrieval attempts fail, a trap
is sent by AppDirector.
208

Figure 10: TSL Updating for Authentication
Configuring TSL Authentication Policies

The TSL Authentication Policy includes all TSL configurations and is attached to the Layer 4 policy
using the same parameter as the Client Authentication Policy. This means that the Client
Authentication Policy and TLS Authentication Policy are mutually exclusive. Select one or the other.
The association of a TSL Authentication Policy with a Layer 4 Policy defines the TSL service on the
AppDirector. The TSL policy encapsulates all required data to support the TSL service.
To set TSL Authentication Policies

1. From the AppDirector menu, select Layer 4 Traffic Redirection > Authentication > TSL
Authentication Policies. The TSL Authentication Policies window appears.
Parameter
Description
Policy Name
Unique name of the TSL Authentication Policy.
CA Required
Defines whether AppDirector verifies that a CA has signed the client

certificate.
When disabled, any certificate that the client presents is accepted,
regardless of whether it was generated by a trusted CA or not.
Values: enabled (default)/disabled.
209

Parameter
Description
Redirection URL
Defines the URL to redirect clients to when Client Authentication fails

and you wish to notify this to users in a graceful way rather than by
default browser message.
CA Depth
Defines the maximum intermediate CAs in the CAs chain that

AppDirector will search to validate the link between the client's
certificate to the received Client CA certificate.
Values: 1(default)
Pass Certificate info

in Headers
Allows forwarding Client Certificate information to the application

servers using HTTP headers. For more information see Certificate
Information Headers, page 202.
Certificate Validation
Policy
Defines the Client's certificate field validation policy to be used during

Authentication. For more information about Certificate Validation Policy
see Certificate Validation Policies, page 211.
TSL File Chain
Select TSL Files Chain to be used in this TLS Policy. The TSL File Chain
must be configured prior to configuring the TSL Policy. See Configuring
TSL Files Repository, page 211 for more information.
OCSP Parameters
OCSP Cache Time
Defines the time for which validated OCSP responses are cached. Since
CA servers update the CRLs on the OCSP parochially (every 12 hours or
24 hours), there is no need to overload the OCSP server with repetitive
OCSP requests for the same certificate. The Cache is per Client
Authentication or TSL Authentication policy and entries are not shared
between policies. The OCSP cache time is defined in minutes.
Values: 0 (default) - 180000 minutes
Note: When set to 0, OCSP Cache is disabled.
Response Allowed
Signing Algorithm
Defines the specific signature algorithms allows for signing OCSP

responses.
Values: All (default), MD5, SHA1, SHA256, SHA384, SHA512
Response Time
Deviation (sec)
Allows for overlooking small deviations between AppDirector and OCSP

server timestamps for OCSP signatures verification.
Values: 0 (default) - 3600 in seconds
Note: For correct time validation, it is recommended to use NTP, and
you must define the AppDirector Time-Zone. See Time
Settings, page 440.
Send Nonce
An OCSP nonce offers an optional tool for a relying party to determine

that it is receiving up-to-date certificate status information from a
responder. A nonce is a random sequence of 20 bytes placed in an
OCSP request. The responder must use its secret key to sign a response
containing this nonce.
OCSP Cache Purge
The OCSP cache purge operation is used for clearing OCSP cached
responses. OCSP cache purging is done per client authentication policy
or for all client authentication policies.
Select policy name from drop down with policies names.
3.
210

Configuring TSL Files Repository

The TSL Files Repository holds all the TSL original files imported manually to AppDirector, and the
current Active files fetched automatically by AppDirector per TSL file chain. All Files can be
downloaded from AppDirector for viewing purposes. After a TSL file goes through the validation
process and is flagged as valid, it is placed in a static link per TSL Files-chain on AppDirector so that
other components in the environment can use it. The link is always:
https://[ip addr]/GetActiveTslFileChain?chain=[TSL_files_chain_name]
To export a TSL Authentication File

1. From the AppDirector menu, select Layer 4 Traffic Redirection > Authentication > TSL File
Repository. The TSL File Repository window appears.
2. Lists of files appear under these categories: Active TSL Files, Original TSL Files, Failed Active,
Last Active.
3. To delete a TSL file, select delete next to it. The file will be deleted unless connected to a TSL
File chain.
4. To download or export a TSL file, select download next to the appropriate TSL file. A file
download dialog appears. You can choose to open or save it to your own desktop.
Certificate Validation Policies

Certificate Validation Policies allow you to define any certificate field or extension for which only
specific values are allowed. They can be connected to either Client Authentication or TSL
Authentication Policies. They work according to the following logic:
All fields/extensions that appear in policy must appear in the certificate (AND)
One of the values defined for each field/extension should match the value that appear in this
field/extension in the certificate (OR), In case of multiple values in the extensions data,
AppDirector will look for ANY OF the extensions values within the values defined in the CVP.
If field/extension value in policy is defined as "*" (asterisk) it means that the field/extension
should appear in certificate but may have any value.
If a field/extension is marked as "Optional" in Certificate Validation Policy it may or may not

appear in the certificate, but if it appears it must adhere to the above logic, i.e. if it exists
logic=AND else logic=Ignore
To configure Certificate Validation policy

1. From the AppDirector menu, select Layer 4 Traffic Redirection > Authentication >
Certificate Validation Policies. The Certificate Validation Policies window appears.
Parameter
Description
Policy Name
Name of the Policy.
Certificate Field /
Extension Name
The Field name to validate. Select from the values shown in Certificate
Validation Policies Values Formats per Field/Extension., page 213 or
define another extension by writing in its OID.
Default: Version
211

Parameter
Description
Index
The rule index is used as an identifier only and its numeric value has no
other meaning.
Values: 0 (default) - 65000
Field/ Extension Valid

Value
Define valid values per Field/Extension. for example: Signature

Algorithm may have few allowed values with different indexes
index1=MD5, Index2=SHA1.
For valid values format per field/extension, see Certificate Validation
Policies Values Formats per Field/Extension., page 213.
Optional Extension
If a field/extension is marked as "Optional" in Certificate Validation

Policy it may or may not appear in the certificate, but if it appears it
must adhere to the above logic, i.e. if it exists logic=AND else
logic=Ignore.
Values: Enabled/Disabled (default)
3.
Certificate Validation Policies Format Specification

The tables below show specific formats and examples for each type of field and extension.
1.
Commonly used formats

ORGANIZATION =
C=<Country>, ST=<State>, L=<Locality>, O=<Organization>, OU=< Organization Unit>,
CN=<Common Name>/emailAddress=<email address>
Sub-values that are not specified may be omitted.
GENERIC NAME = one of the following:
email:<email address>
DNS:<dns>
URI:<uri>
DirName:ORGANIZATION format
IP Address:<ip address> (sometimes <ip address>/<subnet mask>)
Registered ID:<id>
2.
Certificate Fields
Only the fields listed in the table are supported.
Notes:
>> Since the match is substring-based, it is not necessary to provide values in full format.
Therefore, if a configured value is a substring of the value given in a certificate, there
will be a match.
>> The matching of certificate fields content is exact, partial strings matches will fail. This
means that to match an issuer or subject, for example, the full DN should be specified
and not CN only. i.e. CompanyCA will fail because it is CN value only, and full DN such
as C=US, O=MyCompany, CN=CompanyCA will match.
212

Table 1: Certificate Validation Policies Values Formats per Field/Extension.
Field Name
Format
Example
Version
Number (decimal)
Serial number
Hex String
0x5057
Issuer
ORGANIZATION common format
C=US, ST=NY, L=NA, O=Radware,

OU=CT100, CN=client_1/
emailAddress=ct100@radware.com
Subject
ORGANIZATION common format
C=DE, O=gematik LTU,

CN=brk002as3.gematik.net/
serialNumber=rel234 BROKER SSL-C
515.00
Public key: Signing

Algorithm
One of the following values:

rsaEncryption
dsaEncryption
Public key: Length
Number (decimal)
1024
Signature Algorithm
One of the following values:
sha1WithRSAEncryption
md2WithRSAEncryption
dsaWithSHA
dsaWithSHA1
dsaWithSHA1-old
ecdsa-with-SHA1
mdc2WithRSA
ripemd160WithRSA
3. Known certificate extensions
213

The list below shows extensions that are known and explicitly formatted by openssl.
Extension Name
Format
Example
Subject Key Identifier
Hex String
19:71:D3:07:AD:60:88:5C:C3:A0:3F
:AE:B2:52:08:EC:47:CC:11:1B
Key Usage
One or more of the following

values, comma separated
Digital Signature, Non Repudiation
Digital Signature
Non Repudiation
Key Encipherment
Data Encipherment
Key Agreement
Certificate Sign
CRL Sign, Encipher Only
Decipher Only
Subject Alternative
Name
One or more of GENERIC NAME

formats, comma separated
(same type may appear more
than once)
email:my@other.address, URI:http://
my.url.org
Issuer Alternative Name See Subject Alternative Name

Basic Constraints
CA:FALSE
CA:FALSE
Since client certificate can never

be CA, other possible formats are
irrelevant
Certificate Policies
Policy: <Policy OID1>; Policy:

Policy: 1.2.276.0.76.4.84; Policy:
<Policy OID2>; Policy: <Policy 1.2.276.0.76.4.63; User Notice:;
OIDN>; User Notice:; [CPS:
Explicit Text: oid_policy_sf_cp
<cps uri>] / [User Notice:
[Explicit Text: <user notice
text>]/[Organization:
<organisation>;Number[s]:<co
mma-separated list of notice
numbers>]<user notice>] /
[Unknown Qualifier: <other
qualifier>]
Authority Key Identifier
Hex string
CRL Distribution Points
One or more of the GENERIC

NAME formats, comma
separated.
URI:http://my.com/my.crl,URI:http://
oth.com/my.crl
(reasons and crlIssuer extension

sub-fields are not supported)
Authority Information
Access
214
[OCSP]/[CA Issuers] - <info>
OCSP - URI:http://ocsp.my.org/
Where <info> is in GENERIC

NAME format

Extension Name
Extended Key Usage
Format
values or OIDs (dot notation),
comma separated:
Example
Netscape Server Gated Crypto,
Microsoft Server Gated Crypto,
2.3.4.5
Code Signing
E-mail Protection
Time Stamping
Microsoft Individual Code
Signing
Microsoft Commercial Code
Signing
Microsoft Trust List Signing
Microsoft Server Gated
Crypto
Microsoft Encrypted File
System
Netscape Server Gated
Crypto
TLS Web Server
Authentication
TLS Web Client
Authentication
Netscape Certificate
Type

values, comma separated
SSL Client
SSL Client
SSL Server
S/MIME
Object Signing
Unused
SSL CA
S/MIME CA
Object Signing CA
Netscape Base URL
String
Netscape Revocation
URL
String
Netscape CA Revocation String

URL
Netscape Renewal URL
String
Netscape CA Policy URL
String
Netscape SSL Server

Name
String
Netscape Comment
String
Thawte Strong Extranet
Version: <version decimal>

(0x<version hex>);Zone:
<zone1>, User: <user1>;Zone:
<zone2>, User: <user2>;..
User: <userN>;Zone: <zoneN>
Version: 2 (0x3); Zone: zone1
215

Extension Name
Format
Subject Information
Access
See Authority Information Access
Proxy Certificate
Information
Path Length Constraint:

[<Number>]/[infinite]; Policy
Language: <language>;Policy
Text: <policy data>
Inhibit Any Policy
Number (decimal)
Name Constraints
Permitted:<list of permitted
entities GENERIC NAME format,
separated by semicolon>;
Example
Excluded: <list of permitted

entities in GENERIC NAME
format, separated by semicolon>
4.
User-Defined Certificate Extensions

Unknown certificate extensions formatting is done as follows:
Extension Name format can only be specified as OID
Extension Value format is list of parsed as ASN1 types separated by colon.
Example
Extension Name: 1.3.36.8.3.3
Extension Value: countryName:DE:organizationName:gematik:Broker:1.2.276.0.76.4.88
216

Application Acceleration
This section refers to when Application Acceleration features are enabled and includes these topics:
Benefits of Application Acceleration, page 217
Enabling Application Acceleration, page 218
Acceleration Policies, page 219
Benefits of Application Acceleration

The proliferation of new web enabled applications coupled with the trend of data center
consolidation put great strain on web application servers that need to cope with ever increasing
transactions volume. Growing portion of these applications use SSL (Secure Socket Layer)
encryption as mean to secure and protect the privacy of sensitive information, common examples
are e-commerce shopping carts, e-banking, and more. However, servers are very inefficient in
processing encrypted transactions. Processing encrypted transactions require a much higher
allocation of CPU resources than do simple Web page serving, in some cases, as seen in figure 3
performing SSL encryption/ decryption is 100 times more demanding than handling the same
request as clear text. Performing these SSL calculations slow Web server performances, leading to
inconsistent user experience, and even downtime.
AppDirectors application acceleration features relieve Web servers from performing CPU intensive
SSL calculations by handling all the associated encryption, decryption, session and certificate
management tasks. Unlike Web servers, AppDirector is optimized to perform SSL calculations, using
dedicated ASIC-based hardware and software. Offloading these SSL calculations relieves Web server
CPUs allowing it to serve the application in a greater efficiency.
Compression
Todays Web-based applications which are richer in their textual and visual content still run over
non-optimized HTTP protocol, which was originally designed for dial-up speed applications and one
way transfers of data between two machines, and is therefore less efficient at dealing with the new
types of multi sequence and high bandwidth web traffic. This chatty nature of HTTP and the
growing volume of each transaction, due to the richer content, slow response time considerably and
consume expensive bandwidth.
A Radware hardware-based compression solution can ensure optimal application delivery and
bandwidth savings, as can be seen in figure 4, through compression of web pages such as HTML and
JavaScript in real-time before transmission on the network. This is important especially for small
remote offices and home offices users where bandwidth may be limited. This dynamic HTML
compression accelerates traffic by reducing the payload using an open compression standard (gzip
and Deflate), providing a powerful performance boost since HTML is an ASCII text, which is highly
compressible. The support of industry-standard gzip algorithm (as well the Deflate algorithm)
ensures compatibility with virtually all popular web browsers without requiring any special software
installation on the end-user machine.
AppDirector offers options to control compression behavior. These capabilities include the ability to
define whether objects should be compressed for Browser, Content-Type or URL specific behavior,
and view and use Predefined exceptions of the default compression behavior based on known
Browsers limitations.
217

Caching
Web pages are composed of a series of objects. Many of these objects are static objects that are the
same from page to page. Radware AFE can automatically recognize requests for such objects and
retrieve them directly from the devices local cache without fetching them from the web server. This
capability offloads the server from dealing with unnecessary requests and as the same time
accelerates objects delivery to the end-user.
Caching can also save transformed objects at the cache such as different versions of a given image
that has been compressed and optimized differently for various end users and end users' devices (as
it was explained in the Image optimization section).
Radwares caching is fully compliant with RFC 2616 of HTTP 1.1. It respects all relevant HTTP
Headers (such as: Cache-control, Expires, Authorization, and Pragma), which are the Web
Application means of dictating which content is to be cached and when it should be refreshed.
AppDirector has options to determine its Cache behavior, both in terms of which content to cache,
and in terms of which content to serve to clients from Cache or from Servers. AppDirector Cache
policy includes the option to define per URL caching behavior and cache maximum time, and the
option to better leverage client Browser's cache to improve response times and QoE.
Enabling Application Acceleration

To access these AppDirector features you need the Application Acceleration Engine set to Enabled.
To enable Acceleration and Compression

1.
From the AppDirector menu, select Global > Tweaks. The Tweaks window appears.
2.
Within the Tweaks window, ensure that you select the Acceleration Engine parameter and mark
as Enabled.
3.
This process will require a device reboot.
To disable Acceleration and Compression

1.
2.
Within the Tweaks window, ensure that you select the Acceleration Engine parameter and mark
as Disabled.
3.
This process will require a device reboot.
Caution: You will not be able to upload a configuration file with Application Acceleration Enabled
when the device is in Application Acceleration Disabled mode
218

Acceleration Policies
AppDirector provides end-to-end performance acceleration of Web-based applications for all endusers types such as desktops, PDAs and smart-phones. AppDirector also uses advanced and
granular application intelligence (Layer 7 load balancing) for end-to-end business-smart networking.
This section describes the configuration necessary to activate acceleration mechanisms and to finetune HTTP content-based load balancing. It includes the following:
Copy Rule Lists, page 219
Caching Policies, page 220
Caching URL Rule Lists, page 222
Compression Policies, page 224
Compression Browsers Exception Rule Lists, page 226
Compression URL Rule-Lists, page 227
Rule Lists
To assist configurable compression and caching, Radware has developed Rule - Lists (lists of rules)
that match defined patterns on a set of HTTP headers (User Agent, MIME Type) or URI and
determine whether to perform an action (compress or cache). Rule-Lists are scanned for a match
until the first match is found. Therefore, rules priorities that determine rule order are important.
Leveraging Rule List Behavior

Rule-Lists behavior is where rules are scanned from top to bottom according to their set priority, and
once a match is found, the action designated in this rule is performed, and the Rule-List will not be
scanned for further matches. This allows you to create exceptions for exceptions within the same
Rule-List. For Example, if you have a folder containing cacheable objects (e.g. Images folder) and
within a folder containing non-cacheable objects (e.g. content updating, reports, graph images),
you can set a rule of priority 1 that will match the Non-Cacheable objects folder (Graphs folder),
followed by a more general rule with priority 2 to cache all father-folder objects (images folder).
When the Rule-List is scanned for a match, the more specific exception is matched first, without
continuing to match again on the more general expectation, thus receiving the required behavior.
Copy Rule Lists

Since Rule-Lists may contain many rules, and often the same list can be required but with only
minor changes, AppDirector allows you to copy Rule-Lists into a new Rule-List.
To duplicate an entire rule list, you need:
to define name of source rule list (source for Copy)
to define name of target rule list from list of existing Rule-lists or new (Destination of Copy)
When Set is pressed, all rules are copied from Source to Destination.
Notes:
>> If rules already exist in the Destination policy, you will receive the following message:
"The target Rule List already contain rules. To avoid accidental
overwrite, please delete rules or entire Rule-List and retry."

>> Overwrite of existing Rule-List using Copy Rule List is not allowed.
219

To use the AppDirector Copy Rule Lists

1.
From the AppDirector menu, select Layer 4 Traffic Redirection > Copy Rule Lists. The
AppDirector Copy Rule List window appears.
2.
Set the parameters.
Parameter
Description
Rule-List Type
Type of Rule-List to be copied.

None (default)
Compression Browser Exception List
Compression URL Exception List
Cache URL Policy List
Source Rule List

Name
Select from already defined rule lists of defined type above.
Destination Rule List

Name
Define name of new Rule-List to which all rules in Source Rule-List are
copied.
Default: none
Default: none
3.
Caching Policies
AppDirector supports caching of HTTP traffic. Caching improves the overall network performance.
Using caching, backend servers are required to serve less content, which can save on fetching data
and creating dynamic HTML pages.
Caching can also decrease the number of required TCP connections to the backend servers. It allows
a more efficient use of compression features, as AppDirector can cache compressed objects, and
save the need to re-compress the same object for each client request. Caching is memory based.
Once Caching is enabled for one Layer 4 Policy or more, up to 50% of available Acceleration Engine
memory is used for cache. The amount of memory used depends on traffic and the cached objects
and is configurable from 1 % - 50% (default 20%) in the Tuning Table.
Note: If a Caching policy is defined, by default the action is cache all the content.
Using Leverage Browser Cache parameter

When cached content is served by AppDirector to a clients browser, the client experiences better
Quality of Service (QoS) than if it was served from the server. Further enhancement to client QoS is
achieved when the clients Browser caches the content for reusing on the next request that will need
it. However, not all content is optimally cached by browsers thus failing to provide the best possible
QoS. AppDirector can optimize the browser caching by updating the Cache-Control directives on
every cache-served object. The object headers are updated to reflect the future time it can be
cached for by the browser according to the AppDirector cache time (whether from server headers or
AppDirector Cache URL Exceptions Rule-List). AppDirector will also ensure that the content will not
be served from the browser cache after it is considered stale. AppDirector will provide the browser
with the time that already exists in the AppDirector Cache, so that the browser can calculate the
remaining time correctly.
220

To configure AppDirector Caching Policy

1. From the AppDirector menu, select Layer 4 Traffic Redirection > Caching Policies. The
AppDirector Caching Policy window appears.
Parameter
Description
Policy Name
(Mandatory)
Name of the Policy.
Minimum Object
Size [Bytes]
Minimum size of object in bytes to be stored.
Maximum Object
Size [Bytes]
Maximum size of objects in bytes to stored.
Default: Empty
Default: 1024 bytes
Default: 102,400 bytes
Expiration [seconds] Maximum time that an object is kept, even if the object header is
specified longer. If the object header or configuration via Cache URL RuleList is specified less, it is purged according to its header / configuration.
Default: 86,400 (24 hours)
Leverage Browser
Cache
You can modify caching headers to leverage client side (browser) cache:
For objects marked for caching:
Add/modify objects' HTTP headers to include Cache-control: public, maxage=X.
X is derived from general cache settings or from the URI rule responsible
for caching the specific object.
Values: Enabled/Disabled (default).
Respect Server
Headers
Specifies how Server Response cache headers are treated.

Respect-All (e.g.RFC behavior) - If no header is sent by the server
specifying the cacheability of the object, AppDirector caches the
object.
Cache-All - caches everything regardless of headers.
In both modes, Cache URI rules override and allow for Exception.
Values: Respect All (default), Cache All .
Note: If a Caching policy is defined by default, the action is cache all
the content.
Respect Client
Headers
Specifies how Client request cache headers are treated:

Respect-All (i.e. RFC behavior) - in this mode must-validate, ifmodified, etc. headers are enforced as "get fresh from Server" and
request is forwarded to server.
Respect Refresh headers only - causes only the following headers in
client requests to be respected: "max-age=0", "no-cache",
"pragma:no-cache". All other content is served from cache if it exists
there.
Serve All from Cache - ignores all client side headers serving from
cache anything that exists there.
Values: Respect All (default), Respect Refresh headers only, Serve All
from Cache.
221

Parameter
Description
URL Exceptions Rule Disable or select from list of Cache URL Rule lists.
List
Default: Disable
Note: You can define Domain without anything in the URL field to
support use-cases of different behavior per domain. However, if
Domain is not defined (Domain_type=none) then the URL field
is mandatory.
Ignore Query
Parameters
Specifies whether query parameters added to object URL should be

ignored when saving/serving object from cache.
3.
4.
In the required Layer4 policy, select the Cache policy that you configured.
To purge cache
1.
From the AppDirector menu, select Layer 4 Traffic Redirection > Caching Policies. The
AppDirector Caching Policy window appears.
2.
Select any Layer 4 policy or All.
3.
Click Set. Cache is purged.
Caching URL Rule Lists

AppDirector allows you to define Cache behavior in terms of caching responses and serving requests
from cache. You can define rules that determine whether to cache on top of the RFC headers
decision. If rules specify caching, you can then configure the time (in seconds) of the object to be
cached. The Cache URL Exception Rule-List is used to create exceptions to the set responses caching
behavior and can be used alternatively as in a positive model or negative model.
Using Cache URL Rule-List in Negative model

When Cache Policy Respect Server Headers parameter is set to Cache All, AppDirector does not
inspect HTTP responses Headers for Cache-Control directives. Whenever a received object is
within the size limits (Minimum size-Maximum Size) set in the Cache Policy, it is Cached. This mode
assumes that the Web Server was not configured to send correct Cache-Control directives. Here,
you need to provide, in the URL Exception Rule-List, a list of all objects URIs that should not be
cached.
Using Cache URL Rule-List in Positive model

When Cache Policy Respect Server Headers parameter is set to Respect All AppDirector inspects
every response HTTP headers and caches them according to Cache-Control headers directives.
This mode assumes that the Web Server was configured correctly to provide the right Cache-Control
directives for every object. However, you may want to make exceptions to caching behavior and
configure using the server headers, where you can use the URL exceptions Rule-List. In this model
the Rule-List will include mainly positive (Cache) expectations to server received behavior per URI.
222

To configure the AppDirector Caching URL Rule List

1. From the AppDirector menu, select Layer 4 Traffic Redirection > Caching URL Rule Lists.
The AppDirector Caching URL Rule List window appears.
Parameter
Description
Rule-List Name
There are multiple rule-lists. Each is a policy that contains multiple rules.
Default: none
Rule Priority
Location of the rule in the Rule-List. Since Rule-Lists are scanned for a
match from top (priority 1) to bottom (priority ~65000) this enables you
to set the location of the rule in the rule-list. See Leveraging Rule List
Behavior, page 219.
Rule Name
Name of each rule in the Rule-List used to identify it.

Default: Empty
Domain Comparison Defines whether should be evaluated as a String or Regular Expression

Method
Values: None (default)/Text Match/Regular-Expression
Domain
Defines the Virtual Host for which this rules applies

Note: When the Domain Comparison Method is defined as "None" this
field cannot be used. If Domain Comparison Method is defined
as Text Match or RegEx, it must be defined.
URL Comparison
Method
Defines whether URL field should be evaluated as String or Regular

Expression
Values: Text Match (default)/Regular-Expression
URL
Define URL of specific object (file/folder) to be matched by this rule.

Default: empty
Cache
Values: Enable/Disable (Default)
Expiration Time
Values: 0 - 86400 (24hr)- default.

Note: Time is accepted only if Cache is enabled.
If Value is set to 0 then cache time is set according to the minimum
between time from server header (Expires or Max-Age headers) and the
Cache policy Max-time-to-cache parameter. This allows you to create
rules that force caching without affecting the time set by the servers.
This is useful when you create a general rule for No-Cache and want to
create an exception within it. For more information on these exceptions
see Leveraging Rule List Behavior, page 219.
223

Compression Policies
HTTP Compression is a publicly defined way to compress content (mostly textual) transferred from
Web servers across the world wide Web to browsers. The impact of compression is that the number
of transmitted bytes is reduced and thus a higher performance is gained. HTTP Compression uses
public domain compression algorithms to encode HTML, XML, JavaScript, CSS and other file formats
at the server-side.
AppDirector Compression policy includes 3 levels of optional exceptions. The First level is a list of
known problems (bugs) in commonly used browsers that cause them to mishandle specific types of
compressed content and thus predefined expectations exists to avoid these problems. This list can
be viewed as the in the Browsers Exceptions Rule-List screen as the Predefined Browser Limitation
Rule-List. The Predefined Browser Limitation Rule-List can be customized by copying it using the
Copy Rule-Lists into a new Browser Exceptions rule list. The second level of exceptions provided in
the form a customized Browser exceptions Rule-List that can define compression behavior in term of
browser type (User-Agent) and Content-Type (File type as it appears in Object headers). The third
level of exceptions allows defining very specific compression behavior per URI, similarly to Cache
URL exception Rule-List. Exceptions are evaluated from most granular (URL Exceptions) through to
more gross ones (Browser Exceptions) to the most general ones (Predefined Browser Limitations) to
allow user to use them a narrowing series of filters.
You can configure compression of HTTP content from AppDirector to the client. AppDirector supports
either Gzip or Deflate algorithms. AppDirector has a default compression by software service. The
compression level indicates how much the file is compressed. It does not indicate the compressed
file size, this depends on the file content itself.
To configure the AppDirector Compression Policy

1.
From the AppDirector menu, select Layer 4 Traffic Redirection > Compression Policies.
The AppDirector Compression Policy window appears.
2.
Set the parameters.
Parameter
Description
Policy Name
(Mandatory)
Name of Policy.
Algorithm
Used for defining the preferred compression algorithm which is used

by AppDirector if client can receive both Gzip and Deflate compressed
content.
Default: Empty
Values: Gzip (default), Deflate

Engine
Defines the type of compression engine used and enables you to

choose software compression or hardware compression.
Default: Software (if Hardware card is installed, default becomes
Hardware. If not installed Hardware is not allowed).
Minimum Content
Length (Bytes)
Minimum file size to be compressed to avoid wasting resource on files

that are already small.
Default: 10240 Bytes
Note: If content length header is not specified, limit does not apply
224

Parameter
Description
Maximum Content
Length (Bytes)
Maximum value of Content Length header in K-bytes of the object to

be compressed.
Values: From size configured in Minimum Content Length to
104857600 Bytes
Default: 104857600 Bytes
Notes:
If content length header is not specified, then limit does not apply.
Value is 0 (unlimited) following upgraded Compression policies.
Compression Level
Used for setting the Gzip compression level.

Values: Low <1 (default) > 9 High. ( Gzip software compression only).
Note: Changing the compression level to > 1 has a severe impact
on throughput and only a minor reduction in compressed file
size.
Allow Compression By
Server
This deletes the Accept Encoding Header from requests sent to the
server to prevent it from performing compression.
Values: Disabled (default)/enabled
Use Predefined
Browser Exceptions
Enable or Disable workarounds for browser limitations for compression

according to their type.
Values:
Predefined Browser Limitations List (default)
None
Note: Predefined Browser Exceptions are defined in the Predefined
Browser Limitations Rule-List that can be found in the
Compression Browsers Exception Rule Lists, page 226.
Browser Exceptions
Rule List
Helps to skip compression of certain objects that create a problem

when uncompressed or require too much resource with little benefit
(e.g. PDFs & PPT folder).
Values: None (default)/Specific URL
URL Exceptions Rule

List
Define specific URLs (files/folders) for which all other settings should
be overridden and compression or no-compression should be done.
Values: None (default)/Specific URL
Notes:
You can define Domain without anything in the URL field to
support use-cases of different behavior per domain.
However, if the Domain is not defined (Domain_type=none), then
the URL field is mandatory.

4. In the required Layer 4 policy, select the compression policy that you configured
225

Compression Browsers Exception Rule Lists

This enables you to define Rule-Lists of Compression exceptions based on User-Agent (Browser
type) or Content-type (file type). These exceptions are evaluated after the Compression URL
exceptions, so they can be overrided by them, if needed.
To configure the AppDirector Compression Browser Exceptions Rule List

1.
From the AppDirector menu, select Layer 4 Traffic Redirection > Compression Browsers
Exceptions Rule Lists. The AppDirector Compression Browser Rule List window appears.
2.
Set the parameters.
Parameter
Description
Rule List Name
Rule-List name. There are multiple rule-lists. Each Rule-List is a policy

that contains multiple rules.
Default: Empty
Rule Priority
Location of the rule in the Rule-List.

Since Rule-Lists are scanned for a match from top (priority 1) to
bottom (priority ~65000).
Default: 200
This enables you to set the location of the rule in the rule-list.
See Leveraging Rule List Behavior, page 219.
Rule Name

Default: Empty
User Agent
Comparison Method
Defines whether UA field should be evaluated as String or Regular

Expression.
Values: Text Match (default), Regular Expression
User Agent
Client program used to access servers on a network.

Values: Empty (default), Regular, Regex
Content Type
Comparison Method
Defines whether this should be evaluated as String or Regular

Expression.
Values: Text Match, Regular Expression
Content Type
Define Content Type string to match for this rule.

Default: text/html
Compress
3.
Values: Enabled (Default),Disabled
Note: To manage Rule-Lists efficiently, use the filter boxes at the top of the Rules table.
226

Compression URL Rule-Lists

This enables you to define Rule-Lists of Compression exceptions based on object URL (file/folder).
These exceptions are first evaluated making them the most granular means of defining compress/
don't-compress behavior.
To configure the AppDirector Compression URL Rule List

1. From the AppDirector menu, select Layer 4 Traffic Redirection > Compression URL RuleLists. The AppDirector Compression URL Rule List window appears.
Parameter
Description
Rule-List Name
Rule-List name. There are multiple rule-lists. Each Rule-List is a policy

that contains multiple rules.
Default: Empty
Rule Priority
match from top (priority 1) to bottom (priority ~65000) this enables to
set the location of the rule in the rule-list. See Leveraging Rule List
Behavior, page 219.
Default: 1
Rule Name

Default: Empty
Domain Comparison Allows defining different behavior for specific URLs within different virtual
Method
hosts on the same server. Defines whether used at all (None), or to be
evaluated as a String or Regular Expression
Values: None (default)/Text Match/Regular-Expression
Domain
Defines the Virtual Host for which this rules applies

Notes:
When Domain Comparison Method is defined as "None" this field
cannot be used.
If Domain Comparison Method is defined as Text Match or RegEx it
must be defined.
URL Comparison
Method
Defines whether URL field is to be evaluated as String or Regular

Expression
Values: Text Match (default)/Regular-Expression
URL
Define URL of specific object (file/folder) to be matched by this rule.

Default: Empty
Compress
Values: Enable/Disable (Default)
Note: To manage Rule-Lists efficiently, use the filter boxes at the top of the Rules table.
227

Layer 7 Traffic Management

This section describes the different capabilities available for application-aware traffic management
and includes these topics:
Layer 7 Methods, page 228
Layer 7 Farm Selection, page 234
Layer 7 Statistics, page 237
Layer 7 Modification, page 238
Layer 7 Server Persistency, page 252
Layer 7 Methods
A Layer 7 Method defines a specific criteria (namely the existence or non existence of certain specific
content within the message), evaluated on a specific part of each handled message. Layer 7
Methods are used in load balancing and modification decisions. A condition will evaluate to TRUE
only if all values specified in the method match values appearing in the specified part of the
message. In addition, Layer 7 Methods are used to define the modification required on the traffic
(different Layer 7 method is used to identify the traffic where modification is necessary).
The following table shows the available Layer 7 methods and where they can be used:
Table 2: Layer 7 Methods
Method Type Identifies
Available
for Layer
7 Farm
selection
Available for Layer 7

modifications
Identify traffic
(Match)
Modify traffic
(Action)
Insert*,
Replace
URL
Hostname and/or path in Host header x

or in URL for proxy requests
Insert,
Remove*,
Replace
File Type
File type in URL
Insert, Replace, Replace

Remove
Header Field
Header field
Insert, Remove, Insert, Replace

Replace
Cookie
Cookie header in request message

Replace
Regular
Expression
String anywhere in message (for

Layer 7 modifications only in header
area)
Insert, Remove,
Replace
Text
String anywhere in message (for

Layer 7 modifications only in header
area)
Insert (Header Insert (Header

Only), Remove, Only)
Replace
Replace
(Header and
Body)
Status Line
Status Line
Insert, Replace
Set Cookie
Set Cookie Header

Replace
Advanced
URL in request message or HREF in
URL Condition response body
228
Replace
Replace

Method Type Identifies
Available
for Layer
7 Farm
selection
Advanced
URL
Modification
URL in request message or HREF in

response body
RADIUS
Attribute
Specified RADIUS attribute value
Available for Layer 7

modifications
Identify traffic
(Match)
Modify traffic
(Action)
Insert, Replace
Note:
>> All content settings of the Methods are case sensitive.
>> * - Only URL methods that have Path argument but no Host argument can be used.
To configure Layer 7 methods

1. From the AppDirector menu, select Layer 7 Farm Selection > Methods. The Method Table
window appears.
2. Click Create. The Method Table Create window appears.
Parameter
Description
Method Name
Name that you want the method to be recognized as.

Example: Method Name = Test 1
Method Type
Select one of the method types as shown above.

Example: Method type = Header Field
Arguments
Appropriate argument type will appear when clicking the file selection
icon. Select according to Hostname and Path.
4. To define the arguments relevant to the selected method, click the option
The arguments window for the selected Method type appears.
button alongside.
Note: In the case of Advance URL Condition and Advance URL Modification, arguments
appear as fields in the Method Create/Edit window and not as separate windows.
229

This table describes the various arguments for available Method Types.
Table 3: Layer 7 Method Arguments
Method Type
Method
Specific
Parameters
Description
Example
URL
Host Name
Host name part of URL in the header.
Host Name =
www.a.com
Values: None (default), define string.

String should be according to
hostname limitations.
Path
Path part of URL in the header

indicates matching/action on path
Path = cgi-bin
Values: None (default), string up to

256 characters. String can contain
only characters allowed in path.
File Type
File Type
Type of file in the URL
TYP=html
Header Field
Header Field
Specific header field (mandatory)
HDR=AcceptLanguage|TKN=en
-us
Note: If the value of header field is

null (no value) then it acts as
a wildcard so that there is a
match for any packet with
such a header with any
value.
Token
Value inside the specific header field
TKN=en-us
Cookie
Cookie Key
Available only if you

have Cookie
Persistency License.
Specific Cookie Key in the request

Cookie header (mandatory)
KEY=
server|VAL=red
Cookie Value
Specific Cookie value
VAL=red
Regular
Expression
Regular Expression (string pattern

matching)
EXP=.abc
Regular Expression
230

Method Type
Method
Specific
Parameters
Description
Example
Set Cookie
Key
A specific Cookie Key in the reply Set

Cookie header (mandatory)
KEY=server
Value
Specific Cookie value
VAL=red
Path
Path part of URL
P=cgi-bin
Domain
Domain to be added to the cookie
DMN=service.com
Expire After
This determines for how long the client EA=3H.

can use this Cookie.
This value is added to the system time
at the moment of insertion and
included in the cookie, to determine
the exact time when this cookie
expires.
The value is followed by a letter that
determines the time unit used as
follows:
S = seconds
M = no letter for minutes
H = hours
D = days
For example:
24H for 24 hours
60M for 60 minutes
1440S for 1440 seconds
1D for 1 day.
Status Line
Status Code
Reply Status Code
SCD=404
Status Text
Text accompanying status code.
SPHS=Not Found
Text
Text
String
TXT=abcdefg
Radius Attribute
Attribute
Number
RADIUS attribute number (AN)
AN=1
Vendor ID
Vendor ID for Vendor Specific attribute VI=311

(VSA). Only relevant when Attribute
Number is 26.
Vendor
Vendor specific attribute type allows to VT=6
Specific
search for a specific sub-attribute
Attribute Type inside a vendor specific attribute.
Relevant only when Attribute Number
is 26.
Attribute Value Values of type string (ASCII), integer
or IP address only are supported. For
Vendor Specific attributes only values
of type string are supported.
AV=domain.com
231

Method Type
Method
Specific
Parameters
Description
Example
Match Type
Defines how requested attribute value M=S

is searched within the packet attribute
value. Applies to string values, only.
Values:
Equal (EQ)
Contain (CT)
Prefix (P)
Suffix (S)
Advanced URL
Condition
Protocol
Type of protocol selected:
e.g. HTTP.
Values: None (default)/HTTP /HTTPS

Host Name
Host name part of URL in HTTP header. Host Name =

Values: Empty (default), define string. www.a.com
String according to hostname
limitations.
Hostname
Match Type
Indicates how hostname matching of

sting is performed.
Values: None (default), Equal,
Contain, Prefix, Suffix
Port
Indicates matching/action on Port.

Values: 0 (default), Port number
Path
Path part of URL in HTTP header

Path = cgi-bin
Values: Empty (default), string up to

only characters allowed in path.
Note: if there is no dot in the last
element of a path, the entire
string, until the end of URL
or first non-alphanumeric
char is called a Path and
there is no page element
there. Therefore in these
examples:
http://abc.com/XXXX/
YYY?param
http://abc.com/XXXX/YYY
Radware refers to the path as
XXXX/YYY .
232

Method Type
Method
Specific
Parameters
Description
Page Name
Indicates matching/action on Page

name.
Example
Values: Empty (default), define string

Page Type
Indicates matching/action on page

type
of file extension
Path Match
Type
Indicates how path matching of sting

is done
Values: None (default), Equal Contain,
Prefix, Suffix
Advanced URL
Modification
Protocol
Type of protocol selected:
e.g. HTTP.
Values: None (default)/HTTP /HTTPS

Host Name
Host name part of URL in HTTP header. HN=

Values: Empty (default), define string. www.a.com or
String should be according to
HN=www.a.com|P
hostname limitations.
=cgi-bin
Port
Indicates matching/action on Port.

Values: 0 (default), Port number
Hostname
ActionType
Indicates action to be taken on

hostname
Values: None (default), insert before,
insert after, remove, replace
Path
Path part of URL in HTTP header

P=cgi-bin
Values: Empty (default), string up to

only characters allowed in path
Path Action
Type

type
Values: None (default) or define string
of file extension.
Page Type

type
of file extension
Page Name
Indicates matching/action on Page

name.
5. Select the options as shown in the table above and click Set. You are returned to the main
Method Table window.
233

Dynamic Values for Method Parameters (Tokens)

When Layer 7 methods are used to modify HTTP, AppDirector can define the value to be used to
insert or update a Layer 7 header (Layer 7 method argument) as dynamic information taken from
the traffic. The following values can be used:.
The variables can be used in conjunction with static text; for example, 'External-IP-port:
$VIP:$VIP_Port'. To indicate a $ in the text, use $$.
Layer 7 Farm Selection

The Layer 7 content aware decision making mechanism allows providing multiple services via a
single entry point (IP and application port). For example:
Providing content to end users based on language and/or type of browser (PC or mobile).
Providing differentiated service to e-commerce customers based on what they want to buy
(URL).
Layer 7 farm selection is available for:
HTTP or other HTTP-like (has HTTP-like header) TCP protocols.
UDP protocols.
Notes:
>> When performing Layer 7 farm selection for UDP traffic, AppDirector inspects each
packet separately and selects the appropriate farm and server.
>> Layer 7 farm selection is NOT available for dynamic protocols, such as FTP and TFTP.
Layer 7 Farm Selection Flow

1.
When AppDirector receives the first packet of a session destined to a Virtual IP address, it
searches for a Layer 4 Policy that matches the Layer 4 Protocol, Destination Port, Source IP, etc.
(see Layer 4 Policies Lookup Mechanism, page 186).
2.
If the matched Layer 4 Policy is for TCP traffic and is linked to a Layer 7 Policy, Delayed Binding
is activated.
3.
AppDirector performs a TCP handshake with the client to receive the application request.
4.
When AppDirector receives enough information, it matches the data in the request with each
one of the entries of the Layer 7 Policy attached to that specific Layer 4 Policy. If traffic is UDP,
the matching process is performed for each packet.
5.
Once a match is found, AppDirector load balances the traffic to the farm defined in the matched
entry. For HTTP, HTTPS and SIP, the action of a Layer 7 policy can be to redirect the traffic,
instead of load balancing it to a farm.
6.
AppDirector selects the best server for the task from the farm providing the requested service.
7.
When traffic is TCP AppDirector initiates a TCP handshake with the server and forwards traffic,
once TCP connection is established. For UDP, AppDirector just forwards the traffic to the selected
server.
Configuring Layer 7 Farm Selection

Layer 7 farm selection is configured by defining Layer 7 policies and attaching each Layer 7 policy to
a Layer 4 policy. Each Layer 7 policy can include a number of entries. Each entry defines Layer 7
condition and the action - load balancing to a specific farm or redirection to a specific destination
(host name or IP). For example, a Layer 7 Policy can send an English request for www.a.com to one
farm, and a German request to a .gif file to another farm.
234

When AppDirector matches new session data to a Layer 7 policy, the entries are matched according
to their index (from lower to higher index) and first matching entry is used. For this reason when
there are overlapping conditions, the most specific condition should have the lowest index.
Note: If no matching Layer 7 Policy entry is found, the session is discarded - if it is TCP, a RST
is sent to client.
Each Layer 7 Policy entry can use up to two Layer 7 criteria, (Layer 7 Methods) such as URL or HTTP
Header, and the criteria is combined with AND logic. Each entry specifies the farm to be used if the
Layer 7 criteria in it matches the request.
To configure Layer 7 policies

1. From the AppDirector menu, select Layer 7 Farm Selection > Policies. The Layer 7 Policy
2. Click Create. The Layer 7 Policy Table Create window appears.
Parameter
Description
Policy Name
Name of the policy.
Policy Index
Order in which policy entries are matched. You cannot update the Index
once it is defined.
First Method
First method used to select a specific farm. Also see Layer 7 Methods,
page 228.
Second Method
Second method used to select a specific farm. Also see Layer 7 Methods,
page 228.
Farm Name
Farm to which the traffic must be load balanced when this entrys criteria
is matched.
Note: You can define an empty string as the farm name. When such
rules are matched, AppDirector resets the TCP connection,
effectively blocking access.
4. A policy can have a number of arguments (optional). To select an Argument, click the option
button alongside. The Arguments for Policy window appears.
5. Select the options as shown in the table below and click Set. You are returned to the main
Layer7 Policy Table window. In the Arguments field, you can view all configured arguments in
string format. Each argument has its own code displayed in string format.
235

Parameter
Description
Arguments
Retain HTTP Persistency (PRSST): If the argument is ON,

AppDirector maintains HTTP 1.1 persistency. If the argument is OFF
(or undefined), AppDirector breaks HTTP 1.1 persistency.
HTTP Redirect To (RDR): Performs HTTP redirection to the specified
name or IP.
When using this argument, leave the Farm Name field empty.
Values are case sensitive.
All arguments in Layer 7 Policy can use up to 255 characters,
including parameter names and segment markers.
Note: To avoid appending the URI requested by the client at the end
of the Redirect-To string, you can set @ as the first character of the
Redirect-To parameter. For example, when the user requests
www.site.com/index.htm and the Redirect-To of the selected server is
@www.a1.com, the user is redirected to www.a1.com rather than to
www.a1.com/index.htm.
HTTPS Redirect To (RDRS): AppDirector redirects the HTTP request
to the specified name or IP and modifies the request to a HTTPS
request.
Redirection Code (RDRC): Defines the code to be used for
redirection. Options are:
302 Moved Temporarily ( uses 302 code irrespective of HTTP
version)
RFC Moved Temporarily (the redirection code is according to the
RFC, for HTTP1.0- 302 and for HTTP1.1 - 307)
Moved Permanently (code 301)
SIP Redirect To (RDRSIP): Performs SIP redirection to the specified
name or IP.
Note: The arguments are case sensitive, meaning that when you configure the Arguments
string directly, the arguments keys must be defined in upper case.
6.
236

Layer 7 Statistics
You can view statistics for Layer 7 Policies. For each policy, you can view the total number of
matched HTTP GET requests and the number of HTTP GET requests per second.
To view statistics for farms

1. From the AppDirector menu, select Layer 7 Farm Selection > Statistics. The Layer 7 Policy
Statistics Table window appears, which contains the following read-only parameters:
Parameter
Description
Policy Name
Name of the policy.
Policy Index
Search order of your policy, e.g. one will make the policy appear first.
Total Matches
Total number of matched requests.
2. Click on a Policy Name. Statistics on that policy appear.
To reset Layer 7 statistics

Click Set. The Layer 7 statistics counters have been reset.
To view statistics for farms via CLI

Use the command ad l7 farm-selection statistics.
Layer 7 Farm Selection for DNS

When load balancing DNS traffic, AppDirector can select farms based on a requested domain name.
The DNS Layer 7 farm selection uses the same mechanism used for DNS resolution (see Host
Names, page 311) instead of the Layer 7 policies mechanism.
To perform DNS Layer 7 farm selection

1. Set your Layer 4 policy with the Application parameter to DNS.
2. Set your default farm for DNS traffic selected in the farm parameter (no Layer 7 policy allowed).
Note: If the domain name requested in the DNS query received is not known, traffic will be
forwarded (load balanced) to the default farm.
237

3.
For each domain name for which DNS farm selection is required, entries for Host Names must be
configured with the following parameters:
Host Name = required domain name
Farm = name of required farm
Layer 4 Policy = DNS Layer 4 policy name
DNS Action = Forward
Similarly an entry can be configured for a group of domain names using the Regexp Host Names
table.
When traffic arrives matching the DNS Layer 4 policy, the domain is extracted from the DNS request
for lookup in the Host Names/Regexp Host Names.
If a domain is found and the DNS Action is set to Forward and the query is A, AAAA or PTR, the
request is load balanced to the farm specified in the Host Names entry
If a domain is found but the DNS Action is set to Resolve and the query is A, AAAA or PTR,
AppDirector resolves the DNS query and sends a response, without load balancing it to any backend server.
Note: For an AAAA query the device replies with an empty answer, communicating to the DNS
client that the domain name is known, but the query type is not supported.
If a domain is not found or a record type is not supported by AppDirector, a request is load balanced
to the default farm, (the farm specified in the DNS Layer 4 policy).
When traffic reaches an AppDirector IP interface or Virtual IP Interface (VIPI), DNS load balancing
cannot be performed. Resolution can only performed by the device. If the requested domain appears
in the Host Names table with the DNS Action set to Forward, a No such name response is sent.
Layer 7 Modification
You may often need to change the headers or body of a HTTP session, for a variety of reasons. Some
of the examples are:
Inserting a HTTP Header X-Forwarded-For when redirecting traffic, to convey to the Destination
server who was the originator of the communication.
Removing a HTTP Header from server replies to clients to hide server identity.
Inserting cookies for persistency purposes.
AppDirector provides the following Layer 7 modification capabilities:
extensive Layer 7 modifications capabilities including, inserting, removing and updating Layer 7
headers, such as URL, cookie, header fields and status line as well as any Layer 7 header that
can be identified by a specific text or regular expression.
URL rewrite in HTTP headers and body.
text modifications in HTTP body.
Layer 7 header modifications support HTTP or other HTTP-like (has HTTP-like header) TCP traffic
only.
238

Layer 7 Modification Rules

Layer 7 Modifications rules are attached to farms, indicating modifications to requests and responses
that are being forwarded by AppDirector. A number of different rules can be performed on traffic to
the same farm, where the order of execution is given by the rule index.
Each rule defines the traffic that needs to be modified, the modification type that is performed and
the modification itself. To define traffic modification criteria and the modification itself, Layer 7
Methods are used.
Note: When multiple rules are configured for the same farm, they should not define
modifications on the same section. If such modification rules are configured, only the
first one, (with the lowest index), will be performed.
To create a Layer 7 Modification Rule

1. From the AppDirector menu select Layer 7 Modification > Rules. The Layer 7 Modification
2. Select Create. The Layer 7 Modification Table Create window appears.
3. Set the parameters..
Parameter
Description
Name
Key name.
Index
Sets order in which AppDirector matches traffic to the modification rules

and performs the modification.
Default: 1
Farm
Unique identifier. The farm where this rule is applied.
Modification Scope
Indicates the part of the message where modifications are performed.

Values:
Header Only (default): Modification is performed on the message
header only.
Header And Body: URL Rewrite Modification is performed on the HTTP
message header and body. In addition this mode enables you to
perform text changes (replace or remove by replacing with null
string) in HTTP body.
Also see Content Types that Layer 7 Header and Body Modification
can process, page 243.
Note: When SSL Policy Protocol Redirection and L7 Header & Body
Modifications are enabled on the same service, and the server
sends a 302 Redirect response, the protocol of the new location
is always set to HTTPS to enable the redirect location to work for
the clients. This is regardless of the setting in the L7
Modification method.
239

Parameter
Description
Direction
Indicates if modification is done only on users' requests, only on server

responses or on both users' requests and servers' response.
Values:
Request (default), Reply, Bidirectional (Header and Body)
Request (default), Reply (Header Only)
Note: Bidirectional means AppDirector allows modification to the
header and body on responses as part of URL obfuscation.
Admin Status
Allows disabling a rule without removing it.

Enabled (default)
Disabled
4.
The rest of the parameters depend on the value of the Modification Scope.
a.
When Modification Scope is set to Header only:
Parameter
Description
Modification Type
Defines the Layer 7 modification:

Insert (Default): Inserts a Layer 7 parameter
Replace: Replaces a Layer 7 parameter
Remove: Removes a Layer 7 parameter
b.
Match Condition
Layer 7 method that defines the sessions for which a modification is

made.
Modification
Layer 7 method that defines the modification that is made.
When Modification Scope is set to Header and Body:
Parameter
Description
Header and Body
Condition
This allows you to select from defined Layer 7 Methods of type

Advanced URL condition or Text.
This defines the condition upon which modification is performed and
what is modified.
Header and Body

Modification
This allows you to select from defined Layer 7 Methods of type

Advance URL Modification or Text.
This defines the condition upon which modification is performed and
and the modification action and data.
5.
240

Header Only Modification Type Behavior

Action
Configuration
Behavior
Insert
Match Condition:
The Match Condition, when present, defines

the traffic where the Insert action must be
performed.
Methods that can be used are:

URL
File Type
Header Field
Cookie
Set Cookie
Regular Expression
Text
Modification (Mandatory):
Methods that can be used are (with no
restriction to the method used for Match
Condition):
URL - with Path argument only
Header Field
Cookie
Set Cookie
The result of the Insert action depends on

the method used as Modification:
URL: Appends the text configured in the
path argument at the end of the original
requested path in the Host header or, in
case of proxy requests, from URL.
Header Field: Inserts the header field at
the beginning of the header area
Cookie: Inserts cookie header at the
beginning of the header area, after the
request line. Relevant to Request direction
only.
Text: Inserts text at the beginning of the
header area
Set Cookie: Inserts Set Cookie header at
the beginning of the header area. Relevant
to Reply direction only.
Text
Remove
Match Condition (Mandatory):

Methods that can be used are:
URL (with Path argument only)
File Type
Header Field
Cookie
Set Cookie
The result of the Remove action depends on

URL: Removes path from Host header or, in
case of proxy requests, from URL. In case
that the match is on part of the path, then
only the matched part is removed.
File Type: Removes file type in the URL.
Relevant to Request direction only.
Text
Header Field: The entire matching header

field is removed, not only the argument
specified in Match Condition.
Note: Modification cannot be defined

for Remove action.
Only the first encountered matching header

field in the message is removed.
Regular Expression
To remove part of a header field value, the

Text method can be used, but it requires
that the removed value is quite unique in
the packet.
Cookie: The entire key=value pair is
removed form the Cookie header, not only
the argument specified in Match Condition.
Relevant to Request direction only.
Regular Expression: Any string matching
the condition is removed.
Text: The string matching the condition is
removed.
Set Cookie: The entire Set Cookie header is
removed, not only the arguments specified
in Match Condition. Relevant to Reply
direction only.
241

Action
Configuration
Behavior
Replace
Match Condition (Optional):
The Match Condition, when present, defines

the traffic and the object where the Replace
action must be performed.
When Match Condition is not defined the

only Modification methods allowed are
URL and Status Line.
When Match Condition is defined the
Match Condition and Modification
methods must be of the same type. The
only exceptions are:
When using Text as Modification
method either a Text or Regular
Expression can be used as Match
Condition.
When using Advanced URL
Modification as Modification method,
Advanced URL Condition must be the
Match Condition.
Action performed by Replace action can be:

Update of arguments specified in the
Modification method
Removal of arguments - when the
update value in the Modification method
is set to $Blank
Insert of arguments (only for Set
Cookie and Status Line methods) when the argument defined in the
Modification method, does not appear in
the original message.
The whole argument is being updated and
not only the match area. To replace only
part of an argument use text or Regular
Expression as Match Condition and Text as
Modification.
The result of the Replace action depends on
URL: Replaces hostname and/or path in
Host header or, for proxy requests, in URL.
File Type: Replaces file type specified by
Match Condition with the one specified in
Header Field: Replaces values defined in
Modification method in header field specified
by Match Condition. Replaces only the first
encountered matching header field in the
message.
Cookie: Replaces values defined in
Modification method in cookie pair specified
by Match Condition. Relevant to Request
direction only.
Text: Replaces the string specified by Match
Condition with the one specified in
Status Line: Replaces values defined in
Modification method for Status Line
arguments specified by Match Condition. If
arguments specified in Modification method
are not present in message, they are added.
Relevant to Reply direction only.
Set Cookie: Replaces values defined in
Modification method for Set Cookie
arguments specified by Match Condition. If
arguments specified in Modification method
are not present in message, they are added.
Relevant to Reply direction only.
242

Note: * Only methods supported for each Action type are mentioned.
Common Layer 7 Modifications

This table shows configuration examples of common Layer 7 modifications:
Example
Modific Direction
ation
Type
Inserting X-Forwarded-For HTTP Insert

Header with client IP
Client Requests
Match
Condition
Modification
Empty
Method= Header
Field
Header Field = XForwarded-For
Token=$Client_IP
Inserting a cookie with key of

MyKey and a value of MyFarm
Insert
Server Replies
Method=Set-Cookie
Cookie Key=MyKey
Cookie Value=
MyFarm
Updating a cookie with key of

Update
MyKey and value of MyFarm to
the value of the selected server
and port
Server Replies
Inserting a cookie with key of

Insert
MyKey and a value of MyFarm at
the end of the URL
Client Requests
Method = Set- Method = Set-Cookie

Cookie
Cookie Key =
MyKey
Method=URL
Path=?MyKey=MyFar
m
Content Types that Layer 7 Header and Body Modification can process
The following content types expressed as content-type text/......can be processed by Layer
7 Header and Body Modification:
asp
vnd.wap.wml
x-script.csh
x-server-parsed-html
css
vnd.wap.wmlscript
x-script.elisp
x-setext
html
webviewhtml
x-script.guile
x-sgml
mcf
x-asm
x-script.ksh
x-speech
pascal
x-audiosoft-intra
x-script.lisp
x-uil
plain
x-c
x-script.perl
x-vcalendar
richtext
x-component
x-script.perl-module
xml
scriplet
x-fortran
x-script.phyton
javascript
sgml
x-h
x-script.rexx
x-javascript
tab-separated-values
x-java-source
x-script.scheme
application/x-javascript
uri-list
x-la-asf
x-script.sh
vnd.abc
x-m
x-script.tcl
vnd.fmi.flexstor
x-pascal
x-script.tcsh
vnd.rn-realtext
x-script
x-script.zsh
243

Layer 7 Modification Rules Automatic Configuration

There are two cases where AppDirector automatically generates Layer 7 modification rules.
1.
When the Add X-Forwarded-For to HTTP request parameter is enabled in a farm, AppDirector
automatically generates a Layer 7 modification rule that inserts the X-Forwarded-For header
with the value of the original client IP in packets sent to the server. This capability is useful when
AppDirector performs Client NAT on traffic sent to servers - it allows server visibility of the
original clients.
2.
When the Insert Cookie for HTTP Persistency parameter is enabled in a farm, if the value of
this parameter is set to Enabled, AppDirector automatically generates the necessary
configuration to insert a cookie that contains the server identifier in the reply and keep
persistency for subsequent requests from the same client according to inserted value. A
different value is created for each client. The value is encoded using base64 encoding. The
device generates the following automatic configuration:
The following entry in Layer 7 methods:
Name Auto-G <Cookie> Farm Name
Method Set-cookie
Key <key>
Value $Dyn_Cookie_Value (Minimum length is 1 character)
A Layer 7 modification rule for the farm:
Index (The lowest available character)
Action Insert
Direction Server Replies
Layer 7 Method for Match Empty
Layer 7 Method for Action Auto-G <Cookie> Farm Name
AppDirector also creates the appropriate Text Match Session ID Persistency entry from the server,
before forwarding it to the client.
If Insert Cookie for HTTP Persistency is set to Enable and remove on return path" AppDirector
automatically generates two Layer 7 modification rules, one that inserts a cookie that contains the
server identifier and one that removes this identifier from subsequent requests before forwarding
them to the server. The Layer 7 methods and modification rules that are automatically generated are
read-only. If a user deactivates the capability in the farm configuration, the Layer 7 Modification rule
and Layer 7 method automatically generated for this capability are removed.
The following scenarios show the configurations for rewriting different parts of a URL. Configuring
URL rewriting policies is performed in the Edit URL Rewrite Policy window.
For all scenario examples, configuration that is not specified means default values are used.
In general, it is recommended to be as specific as possible in the Rewrite configuration. For example,
always specify the Domain Name, even when it is not changed.
Layer 7 Modification Examples

Insert X-Forwarded-For
The following scenario displays the modification rule for inserting X-Forwarded-For header with
Client IP value in all requests. This is useful for providing servers with the identity of the original
client when Client NAT is performed.
Match Condition
Modification
Modification Type Direction
Optional
Header Field method:
Insert
Request
Name=X-Forwarded-For
Token=$Client_IP
244

Cookie Insert/Rewrite
The following scenarios display the modification rule for inserting or rewriting cookie for persistency
purposes. AppDirector can insert a cookie in server reply, if the application does not do it, to ensure
subsequent requests from same client are forwarded to the same server. In certain cases the
application inserts a cookie in reply, but with the same value for all servers - in such cases
AppDirector can rewrite the value with a value that will identify the server.
To insert a Set Cookie header in server reply, with key MyKey and value representing
the replying server
Match Condition
Modification
Optional
Set Cookie method:
Insert
Reply
Key=MyKey
Value= $Server_SID_Cookie or
$Dyn_Cookie_Value
To change in server reply the cookie value in a Set Cookie header (Rewrite) with value
representing the replying server
Match Condition
Modification
Set CookieKey=AppKeyl
Set Cookie method:
Replace
Reply
Value=$Server_SID_Cookie or
$Dyn_Cookie_Value
Append cookie to URL
Match Condition
Modification
Optional
URL method:
Insert
Request
Path=?Mykey=MyCookie
Protocol Rewrite
The following scenarios display the URL Rewriting policy for rewriting the URL protocol in all requests
and replies, and in requests and replies of a specific domain:
To change all front-end HTTPS requests to back-end HTTP requests and all HTTP links
to HTTPS links:
Parameter
Match Method for URL
URL Modification
Method
Protocol
HTTPS
HTTP
Additional Parameters
245

To change HTTPS://www.site.com to HTTP://www.site.com and back:
Parameter
Match Method for URL
URL Modification
Method
Protocol
HTTPS
HTTP
Domain Name
www.site.com
www.site.com
Comparison- n Type: Equal

Operation: Replace
Examples Domain Name Rewrite

The following examples display the URL Rewriting policy for rewriting the URL domain name:
To change HTTPS://www.front-site.com to HTTP://www.back-server.com:
Parameter
Match Method for URL URL Modification

Method
Protocol
HTTPS
HTTP
Domain Name
www.front-site.com
www.back-server.com
Comparison Type: Equal

Operation: Replace
To change HTTPS://www.front-site.com to HTTP://www.back-server.com:
Parameter

Method
Protocol
HTTPS
HTTP
Domain Name
www.front-site.com
www.back-server.com

Operation: Replace
246

To change HTTPS://site.com to HTTP://my.site.com:
Parameter

Method
Protocol
HTTPS
HTTP
Domain Name
site.com
my.site.com

Operation: Replace
Or, alternatively
Parameter

Method
Protocol
HTTPS
HTTP
Domain Name
site.com
my.

Operation: Add Before
Note: Setting the back-end Domain Name to "my" instead of "my." results in changing
site.com to mysite.com.
To change HTTPS://*.front-site.com/*.* to HTTP://*.back-server.com/*.*:
Parameter

Method
Protocol
HTTPS
HTTP
Domain Name
front-site.com
back-server.com
Comparison Type: Ends With

Operation: Replace
Note: With Operation Replace, the exact text that appears in the Front-end Domain Name is
replaced with the text that appears in Back-end Domain Name. For example, the URL
www.front-site.com/path/page.type with the above configuration is rewritten to
www.back-server/path/page.type, and the URL www1.front-site.com/path/page.type is
rewritten to www1.back-server.com/path/page.type.
247

Port Rewrite
When the client sends a request to destination port 80 for the URL HTTP://www.site.com, or to
HTTP://www.site.com:80 AppDirector rewrites the request to HTTP://www.site.com:8080. For the
reply, AppDirector rewrites URLs of HTTP://www.site.com:8080 to HTTP://www.site.com:80.
Note: When the back-end server is listening on port 8080 and there is no port number
specified explicitly in the URL, then there is no need for AppDirector to change the port
and both Front-End and Back-end Ports must be set to 80.
When the Front-End Port is the same as the Back-end Port, the device does not change the port
specified in the request. If no port is specified in the client's request or in server's reply, then the
device treats it as port 443 for encrypted traffic, and as port 80 for clear text traffic.
Path Rewrite
The following scenarios display the URL Rewriting policy for rewriting the URL path:
To change HTTPS://www.site.com/aaa/*.* to HTTP://www.site.com/mypath/aaa/

*.*:
Parameter

Method
Protocol
HTTPS
HTTP
Domain Name
www.site.com
www.site.com

Operation: Replace
Path
aaa
mypath/
Comparison
Type: Equal
Note: Setting the back-end Path to "/mypath" instead of "mypath/" as above, where the
operation is "Add Before", results in changing the URL HTTPS://www.site.com/aaa/ to
HTTPS://www.site.com//mypathaaa/.
248

To change HTTPS://www.front-site.com/aaa/*.* to HTTP://www.back-server.com/

aaa/mypath/*.*:
Parameter

Method
Protocol
HTTPS
HTTP
Domain Name
www.front-site.com
www.back-server.com

Operation: Replace
Path
aaa
/mypath

Operation: Append After
To change HTTP://www.front-site.com/*aaa*/*.* to HTTP://www.front-site.com/

mypath/*aaa*/*.*:
Parameter

Method
Protocol
HTTP
HTTP
Domain Name
www.front-site.com
www.front-site.com

Operation: Replace
Path
aaa
mypath/
Comparison Type:Contain
To change HTTP://www.front-site.com/*aaa*/*.* to HTTP://www.front-site.com/

mypath/*aaa*/*.*:
Parameter

Method
Protocol
HTTP
HTTP
Domain Name
www.front-site.com
www.front-site.com

Operation: Replace
Path
aaa
mypath/
Comparison Type:Contain
Note: When Comparison Type is set to Contain, then Operation Add Before implies the
additional text is added at the beginning of the path. Similarly, when Operation is set to
Append After, the additional text is added at the end of the path.
249

Page Rewrite
The following scenarios display the URL Rewriting policy for rewriting the URL page:
To change HTTPS://www.site.com/aaa/page.type to HTTP://www.site.com/

mypath/newpage.type:
Parameter

Method
Protocol
HTTPS
HTTP
Domain Name
www.site.com
www.site.com

Operation: Replace
Path
aaa
mypath

Operation: Replace
Page
page
newpage
Note: The Path is defined as the part of the URL between the first slash to the last slash. For a
URL like www.site.com/aaa/page.type/ (with a slash at the end) all directories are used
as the path, and not as page and page type.
Real Life Examples

The following scenarios of URL rewriting policies combine the rewriting of different parts of a URL in
a single policy.
To rewrite the URL HTTPS://www.front-site.com/mypath/*.* to HTTP://www.backserver.com/*.* use the following configuration:
Parameter
Match Method for

URL
URL Modification
Method
Protocol
HTTPS
HTTP
Domain Name
www.front-site.com
www.back-server.com

Operation: Replace
Path
mypath
Comparison Type: Starts With

Operation: Remove
250

To rewrite the URL HTTPS://www.front-site.com/*.* to HTTP://www.backserver.com/mypath/*.* use the following configuration:
Parameter
Match Method for

URL
URL Modification
Method
Protocol
HTTPS
HTTP
Domain Name
www.front-site.com
www.back-server.com

Operation: Replace
Path
mypath
Comparison Type: Contain

To rewrite the URL HTTPS://www.front-site.com/front-path/*.* to HTTP://

www.back-server.com/mypath/front-path/*.* use the following configuration:
Parameter
Match Method for

URL
URL Modification
Method
Protocol
HTTPS
HTTP
Domain Name
www.front-site.com
www.back-server.com

Operation: Replace
Path
front-path
mypath/
Comparison Type: Contain

Layer 7 Modification Statistics

Layer 7 modification rules are configured at the farm level. Multiple rules can be configured for each
farm. From the Layer 7 Modification Statistics window the Layer 7 modification statistics are viewed.
To create a Layer 7 Modification Table

From the AppDirector menu select Layer 7 Modification > Statistics. The Layer 7 Modification
Statistics window appears which contains the following read-only parameters:
Parameter
Description
Modification Name
Key name.
Hits since Reset
Number of rules matched/changed per rule since the last reset.
251

Layer 7 Modification Reset Statistics

You can reset Layer 7 modification statistics from the Layer 7 Modification Reset Statistics window.
To Reset the Layer 7 Modification Statistics

1.
From the AppDirector menu, select Layer 7 Server Modification > Reset Statistics. The
Modification Reset Statistics window appears.
2.
Press Set. The global statistics of Layer 7 modification rules are reset.
Layer 7 Server Persistency

This describes persistency from the IP level up to Layer 7, providing application aware server
persistency.
Session ID Persistency
When it is necessary to establish multiple connections from the same user to the same server in a
farm, these sessions can be identified by application layer information found in the client's requests.
AppDirector is able to detect / inspect the Session ID information in the traffic and use it for server
selection in further connections, providing application aware server persistency. You can configure
different persistency schemes for different applications and for different farms.
The Layer 7 server persistency mechanism consists of two major blocks:
1.
2.
The packet parser: used to identify the persistency parameter in the traffic.AppDirector allows
searching for any Persistency Parameter within a packet in a text or binary format. AppDirector
searches for Session ID using the following:
Text Match Session ID Persistency: AppDirector searches for text strings within the
packet. The search can be for any Persistency Parameter anywhere in the packet.
Pattern Match Session ID Persistency: AppDirector matches binary patterns within

packets. Binary Session ID Matching is done using pattern matching. You can configure the
offset where the pattern begins and a mask to apply to the pattern, before checking if it is in
the Session ID Table.
Session IDs Management - manages the link between the persistency parameter values and
servers to which they apply. There are 2 options:
Static Session IDs. The user configures persistency parameter values attached to each
server farm and also has to configure a Text Match or Pattern Match entry that defines
where in the message to search for the statically configured persistency parameter.
Dynamically learned values. AppDirector learns persistency parameter values for farm
servers from the traffic passing through it and ensures future transactions with the same
persistency parameter value are sent to the same farm server. In this case, an aging
mechanism is employed to manage the lifetime of each persistency parameter value.
Hashing. Persistency is ensured by performing hash using the persistency parameter value
as input. No values are recorded. This method is especially useful in ensuring URL based
persistency for reverse proxy applications.
Session ID persistency is available for the following types of traffic:
HTTP or other HTTP-like (has HTTP-like header) TCP protocols.
UDP protocols.
IP traffic in general (using pattern match).
Session ID persistency is NOT available for dynamic protocols, e.g; FTP, TFTP.
252

Notes:
>> When using Session ID Persistency for UDP traffic, AppDirector inspects each packet
separately and selects the appropriate server.
>> The Cookie Persistency License allows AppDirector to search the HTTP headers for
Session ID Persistency. Without it, AppDirector inspects only the URI and no other HTTP
headers.
>> When DSID and Layer 7 Modifications are configured together (when applied to the
same request/response) , DISD parsing is performed first, then Layer 7 Modifications.
This means that when the modification changes the part in the header to which DISD is
referred, the DISD server selection and learning is performed according to the original
data, prior to the modifications.
General Flow
The general flow is as follows:
Parse Layer 7 data and find the session ID value in request.
1. If found, search the value in the internal session ID table (the internal table includes both
statically configured and dynamically learned values).
a.
b.
If found, traffic is forwarded to the server indicated in the table.

If not found select a server according to farm Dispatch Method if learning is enabled for this
farm , learn the new value, either from request or from reply, depending on persistency
parameter configuration.
2. If not found, select a server and forward packet normally.
Parameters for All Farms

Persistency method is configured per farm, however the following parameters apply to all farms:
1. Session ID Sharing. With Session ID Sharing, you can share Session ID information among
multiple farms, when the same Persistency Parameter is used for the farms. When a specific
Session ID is configured or learned through one farm, the same Session ID may also be used for
server selection in other farms that use the same Persistency Parameter and the same servers.
2. DSID reply Learning in "First" mode. When using dynamically learned session IDs, this
option defines whether the device should inspect each reply of each transaction, on the same
TCP session, even if Layer 7 Persistent Switching Mode is set to FIRST for the Layer 4 policy the
traffic matched. The default and recommended value is Inspect First Reply. Inspect All Server
Replies should only be used if required for compatibility with previous version.
Configuring Text Match Session ID Persistency

Text Match Session ID persistency mechanism allows identifying persistency parameter by parsing
the message and looking for specified text anywhere in the message.
To search for Session ID according to Text Match Session ID Persistency

1. From the AppDirector menu, select Layer 7 Server Persistency > Text Match. The Text
Match Session ID Persistency window appears.
2. Click Create. The Text Match Session ID Persistency Create window appears.
253

3.
Set the parameters.
Parameter
Description
Farm Name
Name of farm for which session ID persistency is used.
Layer 4 Protocol
Layer 4 Protocol for which traffic is intercepted for Session IDs.

Values: TCP (Default), UDP or other
Application Port
Port for which traffic is intercepted for Session IDs.

Default: 0 (indicates that all ports must be inspected).
Lookup Mode
Defines location within the request where Session ID appears.

Values:
Cookie: The device looks within the Cookie header for the value
following "Persistency Parameter=". The Persistency Parameter is
case sensitive.
Note: Using Cookie Persistency License allows AppDirector to search
the HTTP headers for Session ID Persistency. Without the
License, AppDirector inspects only the URI and not further
HTTP headers.
Header: The device looks for the value following "Header Name:",
if Persistency Parameter is not defined, or within the Header Name
for the value following "Persistency Parameter=" when Persistency
Parameter is defined. The Header Name and Persistency Parameter
are case insensitive.
RegExp: The device looks anywhere in the packet for the value
following "Persistency Parameter=". The identifier is caseinsensitive (unless indicated specifically in the expression).
URL cookie: The device looks within request-URI for value
following "Persistency Parameter=". The Persistency Parameter is
case sensitive.
Note: URL cookie cannot be set with a Learning Direction of Server
Reply.
Text: The device looks anywhere in the packet for the value
following "Persistency Parameter=". The identifier is casesensitive.
RADIUS Attribute: Stores the RADIUS Attribute and server, to
ensure persistency for traffic sessions. The Persistency Parameter
can only be a number (RADIUS attribute), not a string and the
value of the attribute must be searched not until a stop character,
but according to the attribute length mentioned in the configured
RADIUS attribute.
The Persistency Parameter can only be a number (RADIUS
attribute number) between 0 and 255 and the attribute value must
be searched not until a stop character, but according to the Value
Max Length field.
XML Tag: The device looks for the specified XML tag value or tag
attribute. This enables you to maintain persistency based on a XML
request tag/attribute and/or XML response tag/attribute.
Note: Tag names are defined without the opening and closing
characters (< >) and are NOT case sensitive.
254

Parameter
Description
Lookup Mode
(continued)
In order to define a specific tag, you can concatenate tag names with
slash characters like writing a path (like using XPath).
Notes:
The Parameter Match value will only be allowed to be defined as
"prefix" because in XML the value is not the name itself.
Value offset can remain 0 and AppDirector will know to look for the
value after the closing ">" of the XML tag name.
Persistency Parameter Key of the persistency parameter, up to 64 characters.

For example, persistency parameter can be "Call-ID" in SIP, or AcceptLanguage in HTTP.
Note: This parameter represents the persistency parameter found in
XML requests when XML Tag Lookup Mode is selected.
Persistency Parameter ID to look for during dynamic session ID search on the server reply .
for Reply
Notes:
(used only when
Case sensitive.
Lookup Mode is set to
You need to specify the XML tag and the XML path (partial or
XML Tag)
absolute) to the XML tag by which persistency should be
maintained.
For XML tag attribute add @<attribute_name> at the end of the
XML path.
Persistency Method
Defines whether the persistency parameter defined in this entry should

be used to ensure persistency based on the Session ID table
mechanism (learning) or via hashing.
Values:
Use Table (default): Use this persistency parameter via the
Dynamic Session ID table to ensure server persistency.
Hash: Use this persistency parameter as input for the hash
function to select a server. If a server is not available, AppDirector
selects another server and stores the persistency value and
selected server in the Session ID table, to ensure persistency for
further traffic in this session. The farm Dispatch Method must be
set to hashing.
Header Name (when

HTTP Header Lookup
Mode is selected)
Name of the header where the persistency parameter appears.

Relevant only when Lookup Mode is Header Field.
Parameter Match
This defines if we learn the value that starts immediately after the end
of the Parameter Identifier (when the value is set to Exact) or after the
value that starts after the separator/s ( when the value is set to Prefix).
The separators can be white spaces and "=".
Note: This parameter does not appear when XML Tag Lookup Mode
is selected.
Values:
Exact (Default): Indicates that the configured Persistency
Parameter value must exactly match the received Persistency
Parameter value.
Prefix: Indicates that the configured value appears as a prefix
with possible additional characters following. When using this
mode, a separator can appear between the identifier and the value
in the packet. The separator can be: white space, =, :.
255

Parameter
Description
Value Max Length
Maximum length of the Session ID value if there is no stop character.

Values: 1 - 256 (default)
Value Offset
The offset where the Session ID value resides, within the value
following the Persistency Parameter name. Default is 0, meaning value
location is right after the Persistency Parameter name and value
separator.
Value Offset is used when the value of the Persistency Parameter is
composed of a dynamic value that changes during the session, followed
by a static value that identifies the session, so that AppDirector ignores
the dynamic prefix of the value for server persistency. For example, the
value is a timestamp followed by client ID, where persistency is based
on client ID only.
Default: 0
Stop Chars
Characters that indicate the end of the Session ID value. Up to 10

characters can be defined. No delimiters are required in this field.
Tab, CR (carriage return), LF (line feed), and so on, are considered as
Stop Characters.
Default: ";"
Learning Direction
Indicates which traffic is inspected by AppDirector to gather

persistency information and to use that information for a specific
session:
Server Reply (Default): AppDirector dynamically learns which
session IDs are to be associated with each server, according to
information in replies from servers. AppDirector inspects also client
requests, to find if they contain a session ID that was already
learned by AppDirector, to forward them to the correct server
accordingly.
Client Request: Can be used when Session IDs appear only in
requests from clients, and means that AppDirector does not
inspect replies from servers. This can be used, for example, when
persistency is based on client IP that appears in X-Forwarded-For
HTTP header, or when only static values of Session IDs are used,
as manually configured in the Static Session ID Persistency Table.
Both Directions: AppDirector inspects both client requests and
servers replies to learn about persistency identifiers.
No Learning: Persistency information is not gathered. You should
define this value when Static Session ID Persistency is used.
Inactivity Timeout
[sec]
Defines how long the association of Session ID values to servers should

be kept when no traffic with this Session ID value is passing through
AppDirector. This is similar to Aging Time in the Client Table.
Values: 1 - 86,400 seconds (24 hours)
Default: 60 seconds
256

Parameter
Description
Ignore Server Reply
Used to enhance AppDirector performance when Session ID values can

be learned from server reply, when Learning Direction is set to Server
Reply or to Both Directions.
Values:
Never (Default): AppDirector searches even if it has already
found a Session ID for this session. Here, AppDirector updates the
Session ID Persistency table according to data in the servers reply.
When ID is in Request: AppDirector performs this way when the
Learning Direction parameter is set to Server Reply or to Both
Directions. When AppDirector has found a Session ID in a client's
request, it does not further inspect the server reply. When a
Session ID already exists in the client's request, and it can be
guaranteed that the server does not change that Session ID, you
can set this field to When ID is in Request.
Tip: Use this option when Static Session IDs are used.
Ignore Source IP
When this is set, only the Session ID info is used for persistency.
Sessions with the same session ID are always forwarded to the same
server.
Disabling this parameter, forces AppDirector to also use the source IP
where there is a session ID match. Two sessions with the same session
ID, but with a different source IP address can be forwarded to different
servers. This mode is relevant only for dynamic entries.
Default: Enabled.
Configuring Session ID Hash Persistency
To ensure persistency based on hash of a Layer 7 Session ID

1. Set Dispatch Method to Hashing in the farm configuration (link to farm parameters).
2. Configure the desired persistency parameter as Text Match Session ID, with the Persistency
Method set to Hash.
Configuring Pattern Match Session ID Persistency

When the Pattern Match Session ID Persistency mechanism is used, AppDirector matches binary
patterns within the packets.
To search for Session ID according to Pattern Match Session ID Persistency

1. From the AppDirector menu, select Layer 7 Server Persistency >Pattern Match. The Pattern
Match Session ID Persistency window appears.
2. Click Create. The Pattern Match Session ID Persistency Create window appears.
257

3.
Set the parameters.
Parameter
Description
Farm Name
Name of farm for which session ID persistency is used.
Application Port
Port for which traffic is intercepted for Session IDs. A value of 0

indicates that all ports are inspected.
For example, to inspect HTTP Traffic, set Layer 4 Protocol to TCP and
Application Port to 80.
Values: Any (default), DNS, FTP, HTTP, HTTPS, NNTP, SMTP.
Layer 4 Protocol
Layer 4 protocol for which traffic is intercepted for Session IDs. Can be
Values: TCP (Default), UDP or other.
Pattern Mask
Mask for the search pattern, also defines length of the pattern
matched. This is a hexadecimal field.
Default: 0xffffffff, meaning a 4 bytes long pattern is used for an exact
match.
Maximum pattern length is 128 bits (16 octets).
Inactivity Timeout
Defines how long the association of Session ID values to servers should

be kept when no traffic with this Session ID value is passing through
AppDirector . The mechanism is similar to Aging Time in the Client
Table. Values: 1 to 86,400 seconds (24 hours).
Default: 60 seconds
Pattern Offset
Offset in the packet, where the search starts.

Default: 0
Offset Relative To
Administrators can specify from which part of the packet the offset is
referring to.
The size of the Offset Relative To parameter, must be greater or equal
to the value of the Pattern Offset parameter plus the length
(determined by the Pattern Mask parameter).
Values: IP header (Default); IP data, Layer 4 header or Layer 4 data.
Ignore Source IP
Enabled (Default): When enabled, only the Session ID

information is used for persistency. Sessions with the same
Session ID are always forwarded to the same server.
Disabled: AppDirector also uses the Source IP when there is a
Session ID match. Two sessions with the same Session ID but a
different Source IP address can be forwarded to different servers.
Learning Direction
Indicates which traffic is inspected by AppDirector to gather

persistency information and to use that information for a specific
session:
Client Request (Default): Used when Session IDs appear only in
requests from clients, so that AppDirector does not inspect replies
from servers. This can be used, when persistency is based on client
IP that appears in X-Forwarded-For HTTP header, or when only
static values of Session IDs are used, as manually configured in
the Static Session ID Persistency Table.
No Learning: Persistency information is not gathered. Define
this value when Static Session ID Persistency is used.
258

Parameter
Description
Persistency Method
Defines whether the persistency parameter defined in this entry should

be used to ensure persistency based on the Session ID table
mechanism (learning) or via hashing.
Values:
Use Table (default): Use this persistency parameter via the
Dynamic Session ID table to ensure server persistency.
Hash: Use this persistency parameter as input for the hash
function to select a server. If a server is not available, AppDirector
selects another server and stores the persistency value and
selected server in the Session ID table, to ensure persistency for
further traffic of this session. The farm Dispatch Method must be
set to hashing.
Data Format
If the parameter is set to IP String, the octets extracted according to

the configured pattern represent the IP address in string format.
Values: Binary (default), IP String
Configuring Static Session ID Persistency

Static Session ID Persistency allows AppDirector to send traffic with specified Session IDs to
specified servers.
To configure Session ID tracking

1. From the AppDirector menu, select Layer 7 Server Persistency> Static Session ID
Persistency. The Static Session ID Persistency Table window appears.
2. Click Create. The Static Session ID Persistency Create window appears.
Parameter
Description
Farm Name
Name of the server farm.
Session ID Value
Session ID value identifying a specific server in a farm.
Server Address
The server within the farm that is identified by the Session ID Value.
When AppDirector detects traffic that contains this Session ID Value, it
directs the traffic to the server specified in this parameter.
Server Port
Default is Zero (0) if no application port has been specified.
Value Type
Text (default): Find the session ID value in the processed traffic

using the text match mechanism.
Pattern: Find the session ID value in the processed traffic using the
pattern match mechanism.
4. Click Set. The Static Session ID Persistency Create window closes and a new entry is created.
259

HTTP Persistency
AppDirector can support HTTP persistency according to any parameter by using the Session ID
mechanism. However the most popular persistency mechanism for HTTP is cookie persistency server inserts cookie that identifies it in the reply to client, and the client uses the cookie in all its
subsequent requests. AppDirector support several mechanisms for HTTP cookie persistency:
Cookie Learning
By learning the cookie from server initial reply, AppDirector can ensure that all subsequent requests
from that client reach the same server. For this purpose a Text Match Session ID entry that looks for
cookie key inserted by the server needs to be configured for the farm in question.
Cookie Insert
When servers do not insert cookies, AppDirector can insert a cookie that identifies the server used in
the server reply, before forwarding the reply to the client. To insert a cookie, AppDirector uses its
Layer 7 modification capabilities. When you set the Insert Cookie for HTTP Persistency to Enable for
the farm in question, AppDirector automatically generates the required configuration - see Layer 7
Modification Rules Automatic Configuration, page 244. This can also be manually defined.
Cookie Insert & Remove

Some application servers utilize cookies to associate server or application instances, and their
default behavior involves searching their Database/Datastore for any application/instance associated
with cookies. When unknown cookies appear, it attempts a lengthy search delaying the response.
This can be solved by inserting the cookie on Reply, but removing it in subsequent Requests (on the
way to server). When you set the Insert Cookie for HTTP Persistency to "Enable and remove on
return path" for the farm in question, AppDirector automatically generates the required
configuration - see Layer 7 Modification Rules Automatic Configuration.
Cookie Rewrite
When all servers insert the same cookie value, AppDirector can replace the cookie value that arrives
from the server with a value that enables identification of that server, (the Layer 7 modification
capability called Replace). The required configuration includes:
Set Cookie Layer 7 method that identifies the cookie inserted by server
Set Cookie Layer 7 method that defines the cookie cookie value that should replace the server
inserted value on the reply
Replace Layer 7 modification rule
Text Match Session ID entry that searches for cookie values inserted by server in subsequent
requests
Static Session ID entries that map the cookie value inserted for each server to that server.
Note: For Cookie / Insert Rewrite, you need the Cookie Persistency License.
URL Hash
When load balancing reverse proxies it is required to maintain persistency for the URL, and
particularly include the object, so that objects are not duplicated between the reverse cache servers.
In cases were huge numbers of objects exist persistency can be ensured by hashing mechanism.
260

To achieve URL Hash Persistency

1. Set Dispatch Method to Hashing in the farm configuration, (see Farm Parameters, page 159).
2. Configure URL persistency parameter as Text Match Session ID, with the Persistency Method set
to Hash.
Note: This mechanism can be used to ensure persistency via hashing mechanism using any
HTTP persistency parameter, not only URL.
SSL Persistency
SSL ID Tracking ensures that all TCP sessions of a SSL session are forwarded to the same server.
When SSL ID Tracking is enabled, AppDirector uses Delayed Binding, and waits to receive the packet
with the SSL ID before choosing a server.
If the SSL ID is found in the internal Session IDs table, traffic is forwarded to the specified server, if
not the SSL ID value is learned (added to the internal Session IDs table). The SSL ID Session ID
entries are aged according to the aging of corresponding entries in the Client Table. The Client Table
is used to maintain the session data.
SSL ID tracking can only be enabled on a farm whose Sessions Mode is set to Server Per Session. By
default, SSL Tracking is disabled. For farms that use the Server Per Sessions Mode where the SSL ID
Tracking parameter is disabled, AppDirector automatically uses the Entry Per Sessions Mode for the
SSL traffic (port 443). Other traffic is shown in the Client Table using the Server Per Sessions Mode.
Notes:
>> SSL ID cannot be learnt for servers of type Local Triangulation.
>> SSL Session IDs are mirrored as they are kept in the Session ID table.
SIP Persistency
AppDirector also enables you to load balance and maintain client-server persistency for SIP servers.
Persistency of SIP over UDP sessions is maintained by searching for Layer 7 information, like CallID, within SIP headers. Administrators can use one or both of the following methods to maintain
client - server persistency:
1. Using Hashing as a dispatch method: AppDirector searches either the Call-ID header or the
Request-URL header in the SIP (Hash Parameter for SIP) and selects one available server
based on a hashing algorithm performed on the specified parameter.
By using Dispatch Method hashing on Request-URI, while simultaneously tracking Call-ID via
dynamic leaning mechanism, AppDirector provides persistency for multi-party calls and
conference calls.
2. Using Dynamic Session IDs: AppDirector maintains persistency based on any field within the
SIP header (for example, branch tag). When using the Dynamic Session ID for persistency, it is
recommended to use an inactivity timeout longer than the call's expected duration.
To provide easy SIP persistency configuration when a Layer 4 policy is defined with Application
set to SIP (Layer 4 protocol must be UDP), AppDirector automatically creates a Layer 7 Server
Persistency Text Match entry looking for SIP Call-ID for all the farms connected to this Layer 4
policy.
261

Radware recommends setting farms Sessions Mode to RemoveOnSessionEnd. AppDirector will
age the Dynamic Session ID entry and the Client Table entry when a SIP BYE or CANCEL
message is received for that Call-ID.
RADIUS Persistency
AppDirector supports server persistency for RADIUS traffic using the RADIUS attribute values to
maintain persistency in other application sessions (e.g. HTTP) using the following mechanisms:
RADIUS Attribute
The RADIUS attribute is required to maintain persistency for either RADIUS sessions as well as other
application sessions (e.g. HTTP).
Remote Authentication Dial-In User Server (RADIUS) attributes are used to define specific
authentication, authorization, and accounting (AAA) elements in a user profile, which is stored on
the RADIUS daemon.
Administrators can use one of the following methods to maintain client server persistency for
RADIUS using RADIUS Attribute value.
Hashing - AppDirector selects an available server based on a hashing algorithm performed on

the value of the specified RADIUS Attribute. You can configure hash persistency via the Text
Match Session ID mechanism or for a simplified configuration
Dynamic Session ID learning mechanism (Text Match) - if no RADIUS Attribute

persistency rule is configured, persistency will be kept using a RADIUS Identifier.
You can configure the RADIUS Attribute parameter at the farm configuration with the required
RADIUS Attribute value. A Text Match Session ID persistency with Hash Persistency Method rule will
be automatically generated.
RADIUS attributes are used to define specific authentication, authorization, and accounting (AAA)
elements in a user profile, which is stored on the RADIUS daemon. You can configure the RADIUS
Attribute parameter at the farm configuration with the required RADIUS Attribute value. The default
is 0, indicating that AppDirector will not look for RADIUS attributes in order to maintain persistency.
In order to maintain persistency for RADIUS traffic (UDP ports 1812, 1813, 1645, 1646 or Layer 4
Policy Application parameter set to RADIUS), AppDirector searches the attribute within the RADIUS
packets & learns its value for the following requests. The learnt values may be used in order to
maintain persistency for other applications (e.g. HTTP).
Persistency can be maintained on any Dispatch Method, but when using Hashing, (page 178), the
behavior is different although persistency is still preserved:
the hash function will be used in order to select a server.
in case the hash function selects a server which is not available, another server will be selected
and the selection will be recorded in the Layer 7 Server Persistency Table (the reason for this is
the natural server selection has to be overridden) You should set the Session ID Table size as
necessary.
Values range from 0 (default - no RADIUS attribute will be learnt) to 255.

The Sessions Mode must be Server Per Session. No additional configuration is required. The same
mechanism is used for sessions originating from AppDirector managed servers to a remote RADIUS
server that are NATed using Server NAT.
The RADIUS Attribute is used for any RADIUS message types (Authentication, Accounting,
Authorization). If a server is not available, AppDirector selects another server and stores the
RADIUS Attribute and selected server in the Layer 7 Server Persistency Table, to ensure persistency
for the following sessions.
RADIUS Proxy Support

With RADIUS Proxy Support. When AppDirector manages RADIUS proxy servers that forward
access/accounting requests from clients to another RADIUS server, it is required to ensure that the
request and reply are sent via the same RADIUS server.
262

For this purpose you need a RADIUS proxy server that can add a special attribute that includes its IP
address in decimal format to the request. When this is present, AppDirector extracts the first 4 bytes
of its value, ensures that this is an IP address of an available server and forwards the reply to it.
Notes:
>> Configuring the RADIUS Proxy Support parameter overrides persistency according to the
defined RADIUS Attribute in the farm.
>> To work with RADIUS, you must first enable UDP tracking.
This behavior can be defined per farm using the RADIUS Proxy Support parameter. When set to 0,
the capability is disabled. To enable the capability, define the number of the RADIUS attribute that
contains the persistency value.
Layer 7 Server Persistency Statistics
To view the Statistics window

From the AppDirector window, select Layer 7 Server Persistency > Statistics. The Dynamic SID
Statistics window appears with the following read-only parameters:
Parameter
Description
Persistency Identifier
matches
Number of times a packet (both requests and responses) matched a

Persistency Parameter configured in the Dynamic Session ID table.
Default: 0
Successfully parsed
Dynamic SID values
Number of times a Dynamic SID value found following the configured

Persistency Identifier
Default: 0
Dynamic SID Value

Learned from Server
Number of times that Session ID value was learned from the Servers
request.
Default: 0
Dynamic SID Value

Learned from Client
Number of times that Session ID value was learned from the client's
request.
Default: 0
Reset Dynamic SID

Statistics
Resets the Dynamic SID Statistics.
263

Client Table Management

This section discusses the Client Table, which stores data about sessions managed by AppDirector
and also describes how to manage and present the Client Table. It includes the following topics:
Types of Client Table Entries, page 264
Static Client Table, page 265
View Filtered Clients, page 266
Client Table Views, page 266
To maintain client-server persistency in an AppDirector farm, AppDirector uses the Client Table. This
monitors which clients are connected to which servers for each Local Farm. When a client first
approaches a farm, AppDirector checks whether there is an existing client entry in the Client Table:
If the appropriate entry is found, the client is directed to the server that appears in the Client
Table. In that case, there is no need to make a load balancing decision.
If an entry does not exist, a farm is selected according to the service requested. A server is then
selected according to load balancing considerations defined by the Dispatch Method or according
to the Layer 7 Persistency information, where applicable. An entry is then added to the Client
Table, indicating which server was selected.
Once an entry is created in the Client Table, all subsequent packets that arrive from the client to a
farm are forwarded to the server indicated in the Client Table entry. The traffic in the opposite
direction, from the server to the client, is sent using the Virtual IP address with which the requested
service is associated. This VIP address is used as the Source IP address of the outgoing traffic, which
is also reflected in the Client Table entry.
The Client Table also provides information about the way a client is sent to the server; for example,
whether the selected server is a local server, whether the server is on a separate site, or if Port
Multiplexing is used. Here is an example of a Client Table:
Source
Address
Source Port
Requested
Address
Requested
Port
Farm Name
Server
Address
Server Port
100.1.1.1
1062
100.1.1.100
80
Farm A
10.1.1.2
8080
100.1.1.2
1011
100.1.1.100
80
Farm B
10.1.1.2
8080
100.1.1.3
1079
100.1.1.100
80
Farm C
10.1.1.1
8080
Client Table Configuration Guidelines:

The configuration of the Client Table involves the following steps:
1.
Set up the Sessions Modes
2.
Set up the Client Table Global Parameters
Now you can view the Client Table information using various view options.
Types of Client Table Entries

There are different types of entries in the Client Table. Each depends on the conditions in which the
session occurs, such as: who initiated the session, the structure of the network, the needs of the
specific clients, etc. Entries include:
Static Client: clients that are always assigned to the same server within the farm.
Dynamic Client: Dynamic clients are forwarded to a server that is available during the
connection establishment process. AppDirector selects the best available server according to the
load balancing definitions, as configured in the Dispatch Method or according to persistency.
264

NAT: NAT entries in the Client Table are created for sessions initiated by the servers when
Server Network Address Translation (NAT) is used. NAT is used in this case to translate the
servers IP address to the Virtual IP address that is used to access the farm.
Note: When the server is disabled, the Client Table entries belonging to that server remain
active to allow NAT for outgoing sessions originating from the server. Only when the
server is removed are its sessions deleted from the Client Table.
Client NAT: Client NAT entries are created for sessions in which Client NAT is used. Using the
Client NAT capability, AppDirector hides the IP addresses of the clients from the servers. The
original Source IP of a request is replaced by AppDirector with the configured NAT IP and port
before forwarding the request to the server.
The Client NAT feature is used when, for example, the client and the server are on the same
subnet, so that the client IP address must be hidden. If not, servers may send replies directly to
clients, instead of sending them through AppDirector.
Outbound NAT: Outbound NAT client entries are created for sessions in which the Outbound
NAT capability is used. The Outbound NAT capability allows AppDirector to hide servers or other
local hosts when sending traffic through AppDirector. Using the Outbound NAT capability,
AppDirector replaces the original Source IP of a packet that is routed or bridged by AppDirector
with the configured NAT IP before forwarding the request. It also replaces the Source port.
Static Client Table

You may need to ensure that certain clients always access a specific server on the server farm,
regardless of load balancing; for example, if you always need to access a specific server for
management purposes by an administrator. Static clients are clients that are always assigned to the
same server within the farm.
Note: If a client is configured to statically use a specific server in a farm and the server is
down, AppDirector does not select a new server. Also see Application/Farm Servers,
page 172.
To add static clients to the Client Table

1. From the AppDirector menu, select Clients > Static Client Table. The Static Client Table
window appears.
2. Click Create. The Client Table Create window appears
Parameter
Description
Client Address
IP address of the client. (Address from which the request is sent).
Farm Name
Name of farm providing the requested service.
Status
Status of client. This variable indicates the administrative status of this

entry.
Values: Active/Inactive
265

Parameter
Description
Client Type
Type of Client Table entry:

Values: Static (Default), Dynamic, ClientNAT, ServerNat and
OutboundNat.
Server Address
IP address of server to which client is connected.
Server Port
The port of the server currently serving this client.

Default: Zero (0) if no application port specified.
4.
Click Set. The client is added to the list as a static client.
View Filtered Clients

The Client Table stores information about every client request handled by AppDirector. The size of
the table makes it difficult to view. To generate reliable and useful reports and to prevent system
failures, use Client Table filters to present information from the table.
To view filtered Clients

From the AppDirector menu, select Clients > Filtered Client Table. The Filtered Client Table
window appears, displaying these read only parameters:
Parameter
Description
Client Address
The IP source address of the client.
Client Port
The source port of the client.

Default: 0
Requested Address
VIP of the farm that contains the required server.
Requested Port
Port of the requested TCP/UDP server.

Default: 0
Server Address
IP address of server to which client is connected.
Client Table Views

Since the Client Table stores information about every client request handled by AppDirector, it is too
large to view without filtering the data. Use Client Table filters to retrieve and view a subset of table
entries.
To generate reliable and useful reports and to prevent system failures, use Client Table filters to
present information from the table. You can define up to five different filters, where the logical
condition between the filters is an OR condition. The condition between the different parameters
within a filter is an AND condition. Each of the filters can be active or inactive. By default, all filters
are inactive and when all filters are inactive, an empty table is displayed.
The View Filters Create window allows you to set up to 5 different filters, where the logical condition
between the filters is an OR condition. The condition between the different parameters within a filter
is an AND condition. It is also possible to activate and deactivate each of the filters, by default the
filters are inactive, which means that the whole Client Table is presented.
266

To configure the View Filters window

1. From the AppDirector menu, select Clients > View Filters. The View Filters window appears.
2. Select the relevant filter from the table or Select Create. The View Filters Create window
appears.
Parameter
Description
Index
Shows Filter Index number currently selected.

Values: 1 - 5
Default: 1
Status
Administrative status of the view entry

Values:
Active: enables the view
Inactive: disables the view
Source IP From/To
Range of clients addresses.

Default: 0
Requested IP From/ Range of addresses of servers providing requested service.

To
Default: 0
Source Port From/To Similar to destination port, the source port that a packet should carry to
match the filter can be configured.
Default: 0
Requested Port
From/To
Destination port number for that protocol. For example, for HTTP, the
protocol can be configured as TCP and the destination port as 80. The
port configuration can also allow for a range of ports to be configured.
Default: 0
Farm Name
Name of the clients farm on the Remote AppDirector.
Server IP
IP address of server where Remote AppDirector is located, and reports its

load to distributing AppDirector.
Client Type
This variable indicates the administrative type of this entry.

Values:
Any (Default)
Client NAT
Dynamic
Server NAT
Static
Outbound NAT
267

Parameter
Description
Action
The type of action to be performed on entries matching this filter.

Values:
No Action (default)
Delete All Matching (Selected Filters)
Count All Matching (Selected Filters)
VLANTag
VLAN Tag information is used to generate reports for each customer by

using the customer's VLAN Tag value. This parameter represents the
802.1q VLAN tag associated with the client entry.
Default: A value of "0" in this field indicates that the VLAN Tag is not
available.
4.
Reset Client on Server Failure

When a server goes down, AppDirector redirects client requests to another available server. To
provide quicker server failover, AppDirector can close the connection with the client as soon as the
server is detected to be down. This will cause the client to immediately establish a new session to
another server, ready to deliver data. This functionality can be activated per farm using the Reset
Client on Server Failure feature. The Reset Client on Server Failure parameter is disabled by default.
When Reset Client on Server Failure is enabled and the farm server is detected as not in service,
AppDirector evaluates the client entries associated with the server and closes all the open TCP
connections and clears the Client Table entry from the Client Table.
Note: The Reset Client on Server Failure cannot be activated for farms with the Sessions Mode
set to Regular.
Close Session At Aging

When the Client Aging on the device expires for a specific session, the device removes the Client
Table entry for this session. AppDirector can also send a RESET to the server to close the associated
port on the server, so the server can release the resources that were allocated for this session. This
behavior is applicable for TCP sessions. This behavior is configurable with the Close Session at Aging
farm parameter.
Client Table Sessions Modes

To achieve maximum flexibility, AppDirector allows the Client Table to work in several modes. These
modes are configured per AppDirector farm, during the farm configuration process. The AppDirector
farm configuration example shown here is used in the following explanation of the Sessions Modes.
268

Figure 11: Typical AppDirector Application

AppDirector
Client
Server 1
VIP Address
100.1.1.100
100.1.1.
Server 2
Note: Definitions of Sessions Modes per farm can be overwritten using global parameters.
Entry Per Sessions Mode

When Entry Per Sessions is used as the Sessions mode, AppDirector maintains Layer 3 persistency.
In the Entry Per Sessions Mode, a new entry is added to the Client Table for each new session,
allowing you to define one server to be part of multiple farms.
In the Entry Per Sessions Mode, clients can send requests directly to a servers IP address and to a
farms VIP address simultaneously. Before sending a reply, AppDirector searches the Client Table for
an entry with the appropriate Source port. If such an entry is found, AppDirector sends the response
through the VIP address indicated in the Client Table. If no entry is found, the response is sent
directly from the servers IP address to the clients IP address.
Note: When a client sends HTTPS requests, it will work in Entry Per Sessions Mode regardless
of the Sessions Mode selected by the user.
The Entry Per Sessions Mode identifies an entry by the following parameters:
Farm Name
VIP Address
Client IP Address
Server IP Address
Source Port Used from the Client to the Server
Destination Port Used from the Client to the Server
If, the client approaches the AppDirector Virtual IP address through HTTP, then for this client
AppDirector selects Server 1 with a 10.1.1.1 IP address. In this case, the Client Table entry looks as
follows:
Source IP Source Port

Address
100.1.1.1
1234
Requested
Address
100.1.1.100
Requested
Port
80
Farm Name
Farm 1
Server IP
Address
10.1.1.1
Source Port
1234
While active, this entry instructs AppDirector to perform the following tasks:
Request for service: All packets from client 100.1.1.1 go to port 1234 VIP address 100.1.1.100
and Destination port 80 and are forwarded to Server 10.1.1.1.
Response: All packets from Server 10.1.1.1 to client 100.1.1.1 with Source port 80 and
Destination port 1234 are sent from AppDirector using Source address 100.1.1.100.
269

In this mode, a new entry is added to the Client Table for every session established between the
client and the server. For example, in a simple Web page retrieval, a client may open a few TCP
sessions with the server, using each session to transfer different parts of the page, such as text, GIF
files, etc. Each of these sessions, identified by Destination port 80 and a unique Source port, such as
1234, 1235, 1236, etc., constitute a new entry in the Client Table.
Note: An entrys age is reset only when AppDirector receives a new packet from the specific
session, which is already reflected in the Client Table.
Once a Client Table entry is established between the client and the server, all subsequent packets
that match this entry are forwarded to the same server. Moreover, as long as there is an open
session between the client IP and the VIP, all subsequent sessions from that client IP to that VIP and
Destination Port are sent to the same server, even when different sessions (different Source ports)
use different Client Table entries.
Note: Once an entry is made from a client to a server within a farm, the client continues to
approach the same server, regardless of application (provided the same farm is used).
Since a new table entry is made into the Client Table for every new session, the Client Table has
many entries. You can increase the Client Table to accept more entries based on the amount of RAM
available on the AppDirector unit (see Client Table Settings Tuning, page 65).

AppDirector finds entries in the Client Table by running the Hash function. The input for this function
is the clients IP address, where AppDirector performs calculations for finding the index number of
the required entry. The Layer 3 Client Table is always used when Entry Per Session is used.
AppDirector uses the Layer 3 Client Table to ensure Layer 3 persistency. This table contains
information about the server selected for each client (Source IP address) in each farm, and allows
AppDirector to select a server for a new session.
Note: The size of the Layer 3 Client Table can be configured and is defined as a percentage of
the Client Table size (see Client Table Settings Tuning, page 65).
270

Regular Mode
In Regular mode, AppDirector maintains Layer 3 persistency. In this mode, each entry is identified
by the following parameters:
Layer 4 Policy VIP Address
Client IP Address
Destination TCP/UDP Port Used from the Client to the Server
If, the client approaches the AppDirector Virtual IP address through HTTP, then for this client
AppDirector selects Server 1 with 10.1.1.1 IP address. Here, the Client Table entry looks as follows:
Source IP
Address
Source Port
Requested
Address
Requested
Port
Farm Name
Server IP
Address
100.1.1.1
100.1.1.100
80
Farm 1
10.1.1.1
While active, this entry instructs AppDirector to perform the following tasks:
Request for service: All packets from client 100.1.1.1 to farm associated with VIP 100.1.1.100
and with Destination port 80 are forwarded to server 10.1.1.1.
Response: All packets from server 10.1.1.1 to client 100.1.1.1 with Source port 80 are sent from
AppDirector using Source address 100.1.1.100.
Global (Per Device) Session Mode
To configure AppDirector Global Parameters

1. From the AppDirector menu, select Global > Global Parameters. The Global Parameters
window appears.
Parameter
Description
Open New Entry

When Source Port
Different
Enable: Each session that a client opens, is recorded in the Client

Table separately.
Select New Server

When Source Port
Different
Enable: Different sessions opened by a client's application are served

by different servers, according to the load balancing algorithms.
Disable (default): All client sessions are considered a single session,

providing better performance.
Disable (default)
Note: This option provides a more accurate minimum-user load
balancing, but may hinder some applications that depend on the
same server. It also may overload AppDirector`s internal tables.
This option overrides the New Entry On Source Port option.
271

Note: Open New Entry When Source Port Different and Select New Server When
Source Port Different can override the per farm configuration if set to Enable. You
can also configure both under each farm. However, if you enable them in the global
configuration it will override what has been configured in a farm.
3.
Parameter
Description
Load Report Interval
Interval (in seconds) for sending dynamic updates of the local load to
other AppDirector's devices that are served by this AppDirector. Also
see Configuring Local Report Protocol, page 303.
Changing Sessions Modes Using Global Parameters

Using Global Parameters, you can set AppDirector farms to operate in Entry Per Sessions Mode or
Server Per Sessions Mode. The equivalents of a farms Session modes in Global Parameters are:
Entry Per Session - the Open New Entry When Source Port Different parameter.
Server Per Session - the Select New Server When Source Port Different parameter.
The difference between individual farm and global configuration is that global configuration applies
to all the farms on AppDirector, and can override the configuration of the individual farm.
By default, global parameters are disabled, meaning that all the farms are in the Entry Per Sessions
Mode, unless a different mode was defined during the farm configuration process.
Enabling the Open New Entry When Source Port Different parameter automatically sets all
AppDirector farms to Entry Per Sessions Mode, except for the farms where Server Per Sessions
Mode is already defined.
Enabling the Select New Server When Source Port Different parameter automatically sets all
AppDirector farms to Server Per Sessions Mode.
Tip: Radware recommends disabling the Open New Entry When Source Port Different parameter
and the Select New Server When Source Port Different parameter before setting Sessions
modes for individual farms.
The table below shows the relationship between farm settings and global settings. The top row
shows Farm Modes and the left column shows Global Parameters. The value within each table cell
represents the effective AppDirector behavior when the global setting is the value on the left and the
farm level setting is as above.
Global Parameters
Farm Parameters
Regular
Entry Per Session
Server Per Session
Regular
Entry Per Session
Server Per Session
Open New Entry When Source Entry Per Session

Port Different
Entry Per Session
Server Per Session
Select New Server When

Source Port Different
Server Per Session
Server Per Session
Regular
272
Server Per Session

Server Per Session

In the Server Per Sessions Mode, multiple sessions from the same client are load balanced
separately. This mode is recommended when an application represents a large number of users by a
single IP address as a client to AppDirector; for example, if many clients trying to reach AppDirector
are located behind a proxy server. The Server Per Sessions Mode identifies an entry as follows:
By VIP Address
By Client IP Address
By Source Port used from the Client to the Server
By Destination Port used from the Client to the Server
In Figure 11 - Typical AppDirector Application, page 269, the client opens six sessions to the
AppDirector virtual address of 100.1.1.100 to retrieve a Web page, with all sessions destined to port
80. As the table shows, both servers 10.1.1.1 and 10.1.1.2 are being used for client 100.1.1.1.
Source IP
Address
Source Port
Requested
Address
Requested
Port
Farm Name
Server IP
Address
100.1.1.1
1234
100.1.1.100
80
Farm 1
10.1.1.1
100.1.1.1
1235
100.1.1.100
80
Farm 1
10.1.1.2
100.1.1.1
1236
100.1.1.100
80
Farm 1
10.1.1.1
100.1.1.1
1237
100.1.1.100
80
Farm 1
10.1.1.2
100.1.1.1
1238
100.1.1.100
80
Farm 1
10.1.1.1
100.1.1.1
1239
100.1.1.100
80
Farm 1
10.1.1.2
Note: The Server Per Sessions Mode is similar to the Entry Per Sessions Mode, as new entries
are added in the Client Table for new sessions. The difference is that the sessions from
the same client can be forwarded to different servers. As in the Entry Per Sessions
Mode, the considerations of the Client Table size should be taken into account.
UDP Session Tracking

When traffic is transmitted using the UDP protocol, each UDP request is represented by a single
packet. Here, all packets from the same client IP have the same Source IP, Source port, Destination
IP, and Destination port numbers. It is therefore impossible to create a new entry in the Client Table
for each request. Using the UDP Session Tracking parameter, AppDirector load balances requests for
service of that type.
By default, the UDP Session Tracking parameter is enabled and AppDirector tracks all the TCP/UDP
sessions using the Client Table. If you disable tracking, only TCP sessions are included in the Client
Table. Persistency is not maintained and each packet of the session can be forwarded to a different
server. When the UDP Session Tracking parameter is disabled, individual UDP packets are load
balanced packet by packet. and client NAT cannot be used for UDP sessions, since UDP sessions are
not inserted into the Client Table.
Note: If UDP Session Tracking is disabled, each UDP server can participate in only one farm.
Remove on Session End

The Remove on Session End mode allows AppDirector to remove entries from the Client Table before
Aging Time expires. This mode is used to clear entries representing the TCP sessions closed before
the end of the Aging Time.
273

AppDirector keeps track of the number of users attached to each server using the Client Table. This
information is important when using the least amount of users dispatch method. AppDirector
enhances server statistics by decreasing the number of users once a FIN is detected.
The Remove on Session End mode operates like the Entry Per Sessions Mode, except:
AppDirector marks the entry for deletion from the Client Table when it detects a RST or FIN
packet between server and client, as the RST/FIN packets indicate that the session is closed.
The entry is aged in five seconds and subsequently removed.
For SIP/UDP traffic, AppDirector checks the SIP messages for the BYE command and applies the
rapid Client Table entry aging mechanism when such a command is detected.
Remove Entry in Select Server

When used in conjunction with the Server Per Sessions Mode, the Remove Entry in Select Server
mode allows AppDirector to remove entries from the Client Table before Aging Time expires. This
mode is used to clear entries representing TCP sessions that were closed before the end of the Aging
Time. This mode operates like the Server Per Sessions Mode except for the following:
AppDirector marks the entry for deletion from the Client Table when it detects a RST or FIN
packet between server and client, as the RST/FIN packets indicate that the session is closed.
The entry is aged in five seconds and subsequently removed.
Network Address Translation (NAT)

This section discusses Network Address Translation (NAT) features and contains these topics:
Client NAT, page 275
Server NAT, page 279
Outbound NAT, page 284
Network Address Translation (NAT) is the translation of an IP address used within one network to a
different IP address known within another network. One network is usually the inside network and
the other is the outside. NAT hides the Source IP address. AppDirector uses these NATs..
Parameter
Description
Client NAT
Hides the IP addresses of clients approaching AppDirector farms, to

solve routing issues. Both client IP and port are changed during Client
NAT.
Server NAT
Server NAT allows AppDirector to hide the servers IP address for

outbound traffic in sessions initiated by servers. Server NAT uses
StaticNAT, which means that only the IP address is changed without
port translation. Server NAT is used for servers positioned behind
AppDirector.
Outbound NAT
Hides IP addresses of hosts behind AppDirector and sends traffic

through AppDirector. The IP address and the port are translated.
274

Client NAT
Using the Client NAT parameter, you can enable the Client NAT capability for the given farm server.
Using Client NAT for a server means that AppDirector hides the Source IP addresses of clients that
access the server in the farm. For more information on Client NAT capability,.
Note: Client NAT cannot be used for UDP sessions when UDP Session Tracking is disabled, as
UDP sessions are not inserted into the Client Table.
Client NAT enables AppDirector to hide client IP addresses when forwarding traffic to servers in
farms. During this process, AppDirector uses Dynamic NAT to replace the original Source IP of a
request with a predefined NAT IP address and dynamically selected ports, before forwarding the
request to the server.
Configuring Client NAT

The process of Client NAT configuration has several stages. Before configuring the Client NAT
parameters, you need to:
enable the Client NAT capability
set the Client NAT Tuning parameters globally on AppDirector.
Once the Client NAT feature is enabled on AppDirector, you can start configuring the Client NAT
parameters.
First, you need to specify the ranges of the Source IP addresses in the incoming traffic that you
want to NAT. This is done in the Client NAT Intercept Addresses table. This table defines clients
whose source addresses are NATed.
Next, you need to configure the IP addresses that AppDirector uses to translate the Source IP
addresses of clients' requests. These are configured in the Client NAT Address table. This table
defines the addresses that are used to perform NAT. The NAT addresses are also configured in
ranges. The maximum number of configurable NAT addresses depends on the tuning value of
the NAT Addresses table parameters, (see NAT Settings Tuning, page 65). For each farm, you
can select a single NAT address range and for each server in the farm, you need to enable the
Client NAT capability and optionally, select NAT addresses.
AppDirector allows you to configure different NAT address ranges for different servers in the farm.
When no NAT address range is configured for the server, AppDirector uses the NAT address range
configured for the farm.
When a client with an IP address within one of the Client NAT Intercepted address ranges
approaches a farm, a server is selected. If the Client NAT parameter is Enabled in the selected
servers configuration, AppDirector NATs the client's IP address and port using the configured NAT
address range for the server or for the farm. When the reply from the server reaches AppDirector, it
replaces the NAT address and port with the original client address and port, before forwarding the
reply to the client.
275

Notes:
>> When no NAT addresses are configured, no Client NAT is performed.
>> You can use the Client NAT capability only for Regular Servers, and not for Remote
Servers, Distributed AppDirectors, Local Farm, or Loopback Servers. If Client NAT is
required for a Remote Server, you need to configure this server as a Local Server in the
farm, with Client NAT enabled. This ensures that traffic is forwarded to that server rather
than redirected.
>> When Client NAT is used in a farm where the Sessions mode is set to Regular,
AppDirector uses the Entry Per Sessions Mode for the Client NAT sessions.
>> In a redundant AppDirector scenario, the same NAT Addresses and Client NAT intercept
addresses must be configured on both AppDirector devices.
Client NAT Global Parameters

Client NAT conceals various network elements located behind AppDirector . When sending traffic
through AppDirector with Client NAT, AppDirector replaces the original source IP of a packet that is
routed or bridged by AppDirector with the configured NAT IP before forwarding the request, and
replacing the source port.
Note: Client NAT is supported for TCP/UDP/ICMP traffic
To enable Client NAT

1.
From the AppDirector menu, select NAT > Client NAT > Global Parameters. The Client NAT
Global Parameters window appears,.
Parameter
Description
Client NAT
Enable/ Disable.
Client NAT hides client IP addresses approaching AppDirector farms, to
solve routing issues. Both client IP and port are changed using Client
NAT.
2.
Set the Client NAT to Enable. Client NAT is now enabled.
3.
Client NAT Addresses

The Client NAT Addresses option for the farm specifies the NAT Addresses that are used to hide IP
addresses of clients accessing this farm. For each farm you can select a single NAT Addresses range.
Note: When no Client NAT Address Range is selected for a farm, AppDirector uses one of the
farms configured Client NAT Address Range when performing Client NAT for servers in
this farm.
276

To create a NAT Address Range

1. From the AppDirector menu, select NAT > Client NAT > NAT Addresses. The Client NAT
Address Table window appears.
2. Click Create. The NAT Addresses Ranges Create window appears.
Parameter
Description
From IP Address
The first NAT address in the required range.
To IP Address
The last NAT address in the required range.
Client NAT Intercept Addresses

The Client NAT Intercept Addresses window allows you to specify ranges of the source IP addresses
in the incoming traffic that you want to NAT. This defines clients whose source addresses are NATed.
Note: To set the parameters of the Client NAT Intercept Addresses Table window, you must
initially enable Client NAT.
To set the parameters of the Client NAT Intercepted Addresses Table

1. From the AppDirector menu select NAT > Client NAT > Intercept Addresses. The Client NAT
Intercept Table window appears.
2. Click Create. The Client NAT Intercept Table Create window appears.
Parameter
Description
From Client IP
The first NAT address in the required range.
To Client IP
The last NAT address in the required range.
Client NAT Quick Setup

The Client NAT Address Range defines a specific NAT range to use to hide client IP addresses when
forwarding traffic to this server
As part of HTTP policy there is a link to the Client NAT Quick Setup. This lists all defined Client NAT
ranges and Farms and enables you to set a client NAT range on multiple farms.
It also includes the option to define a new Client NAT range and to set X-Forwarded-For header
automatically on a farm with the client NAT. You can run the Wizard while selecting client NAT range
0.0.0.0 to reverse the setting on all farms to No Client NAT and/or No X-Forwarded for.
277

To configure Client NAT Address Range

1.
From the AppDirector menu select NAT. The NAT Settings window appears.
2.
Click the Client NAT Quick Setup button below. The Client NAT Quick Setup window appears.
3.
Set the parameters.
Parameter
Description
Client NAT Range
Select from list of defined Client NAT ranges.
New Client NAT Range

From IP Address
Defines new client NAT range: from IP address.
To IP Address
Defines new client NAT range: to IP address.
Select All Farms
This changes all Farms check-boxes state to "selected".
Enable X-ForwardedMark the checkbox.

For Header on Selected
Farms
Apply for all client
source IP addresses
For all client source IP addresses, mark the checkbox.

Note: When no client NAT address range is selected for a farm,
AppDirector uses any of the configured client NAT address
ranges when performing Client NAT forservers in the farm.
4.
List all farms defined in the system. Each farm should have an accompanying check-box marked
to select it.
5.
Click OK. Your configuration is set.
Notes:
>> Once you have set the paramaters and at least one NAT range was allocated,
AppDirector will check that there is at least one Intercept range configured, if not, it will
automatically configure a 0.0.0.0 to 255.255.255.255 range
>> If you want to fine tune the ranges, you can do this through Client NAT Addresses,
page 276.
Insert X-Forwarded-For
In many cases it is important for the server that provides a service to know the identity of the client;
for example, for billing. When using Client NAT, the source IP address is replaced by the NAT
address, so that the server cannot know the identity of the original client. To solve this problem
AppDirector can insert an X-Forwarded-For header with the identity of the original client in the traffic
forwarded to server.
To activate this capability in AppDirector, enable the Add X-Forwarded-For in HTTP request
parameters in the farm configuration. Once activated, the following Layer 7 modification rule is
automatically generated for the farm:
Parameter
Description
Index
The lowest available
Name
Auto-G <Farm-Name>
Action
Insert
278

Parameter
Description
Direction
Client Requests
Layer 7 Method for Match
(empty)
Layer 7 Method for Action
Auto-G <Farm Name> X-Forwarded-For
AppDirector also generates the following entry in Layer 7 methods:
Parameter
Description
Name
Auto-G <Farm Name> X-Forwarded-For
Method
Header Field
Header Field
X-Forwarded-For
Token
$Client_IP
Server NAT
Server NAT allows AppDirector to hide the servers IP address for outbound traffic in sessions
initiated by servers. Server NAT uses StaticNAT, which means that only the IP address is changed
without port translation. Server NAT is used for servers positioned behind AppDirector.
When a session is initiated by a server, the servers request for service is sent using its IP address as
the source address. If the servers IP address is a private IP address, the servers address must be
translated to a public IP address. This ensures proper routing of the reply back across the Internet
to the NATing device and back to the server. To enable servers with private IP addresses to initiate
sessions out of their private network, you can use the Server NAT feature. When enabled, the
servers IP is translated to the Layer 4 Policys VIP and a new entry is added to the Client Table.
Sessions originating from servers are tracked in the Client Table and tagged with a NAT tag to
differentiate this traffic from other regular inbound client traffic.
Notes:
>> Server NAT sessions always use the Entry Per Sessions Mode.
>> When Server NAT is disabled, AppDirector forwards traffic with the servers original
source address. No address translation is done, and no entries are added to the Client
Table.
>> When Server NAT is enabled, you can define the Use Specific NAT Address parameters
for all server NAT sessions. When the default of the Use Specific NAT Address
parameters is 0.0.0.0, AppDirector selects the address according to the VIP of the Layer
4 Policy that is associated with the farm in which the server is included.
>> If no servers are defined, you can define an "empty" farm, associate this farm with a
Layer 4 Policy, and use its VIP address as the specific NAT address.
>> If the traffic is received from a server with Not In Service status, the traffic is handled
according to the definitions of the When Server Is Not-In-Service parameters.
>> When a server participates in multiple farms, outgoing server sessions are translated to
the VIP address of the first found Layer 4 Policy associated with the farm in which this
server is included.
>> Use of a specific server NAT address impacts the NAT address used for all servers.
>> When mirroring is used, server NAT entries are not mirrored.
This figure shows how the servers Source IP is replaced with the Layer 4 Policys VIP.
279

Figure 12: Replacing the Server Source IP with Layer 4 Policy VIP
Internet
Router
Source IP
100.1.1.20
10.1.1.100
AppDirector
VIP 10.1.1.100
Source IP 10.1.1.1
10.1.1.1
10.1.1.2
10.1.1.3
Servers
Server NAT Global Parameters

This enables you to configure the Server NAT. Server NAT replaces original IP addresses of
AppDirector servers with AppDirector farm VIP addresses for outgoing traffic. Only the IP addresses
are translated, without a change of ports. When using Server NAT with the regular VLAN, you can
disable Server NAT for traffic on the regular VLAN. This is configurable using the Server in Regular
VLAN flag. When set to Bridge Only, AppDirector does not create Server NAT entries in the Client
Table for traffic between VLAN ports, but bridges such traffic. The default is NAT and Bridge, which
maintains the previous behavior where all traffic from servers uses Server NAT.
Note: Mirroring cannot be used in Server NAT.
To configure the Global NAT parameters

1.
From the AppDirector menu, select NAT > Server NAT > Global Parameters. The Server
NAT window appears.
2.
Set the parameters.
Parameter
Description
Server NAT
Enable or Disable (Default) the Server NAT feature. Server NAT hides
IP addresses of messages sent from the server.
Use Specific NAT

Addresses
You can choose a farm address to be used as a NAT address for all
servers in all the farms, when required.
Remove at Session
End
Whether to delete session entry from the session table at the session
end. if not - the entries will be deleted by aging.
Values: Disabled (default),enabled
3.
280

Server NAT Parameters

This allows you to configure how traffic received from a server with status Not In Service should be
handled when Server NAT is Enabled. When using Server NAT in conjunction with the regular VLAN,
you can disable Server NAT for traffic on the regular VLAN. This is configurable using the Server in
Regular VLAN flag. When set to Bridge Only, AppDirector does not create Server NAT entries in the
Client Table for traffic between VLAN ports, but bridges such traffic.
To set the Server NAT parameters

1. From the AppDirector menu select NAT > Server NAT > NAT Parameters. The Server NAT
Parameter
Description
When Server is Not- NAT (default): Use Server NAT.

In Service
Forward: Forward packets using routing, without Server NAT and
without adding entries to Client Table.
Discard: Drop packets received from a server in Not In Service
status.
Server in Regular
VLAN
Disables Server NAT for traffic on regular VLAN:

NAT and Bridge (Default): Keeps the previous behavior, where all
traffic from servers uses Server NAT.
Bridge Only: AppDirector bridges traffic and does not perform NAT.
No Server NAT entries are created in the Client Table for traffic
between VLAN ports.
Server NAT VIP Selection per Server

This feature provides static NAT for servers outbound traffic while being able to configure the VIP to
be used as NAT address per server.
AppDirector already enables you to perform dynamic NAT for outbound traffic from servers using VIP
as well as for any outbound traffic using regular NAT addresses (non-VIP) as well as static NAT using
non-VIP addresses (for SCTP).
Example
Using the Outbound NAT configuration we want to support static and dynamic NAT using VIP and
non-VIP addresses per intercept range.
You can work with dynamic NAT only using VIP and non-VIP addresses.
For this you need the following:
1. Add NAT type to your Outbound NAT Intercept configuration. The values are Dynamic (default)
and Static.
2. When the Outbound NAT address is VIP
a.
b.
NAT is not performed for intercept addresses that are not servers managed by AppDirector.
When NAT type is Static - perform static NAT (server NAT). In this case the Server NAT
global settings (for VIP not in service and VLAN) are relevant.
281

3.
When Outbound NAT address is not VIP

a.
b.
When NAT type is Dynamic - perform regular Outbound NAT

When NAT type is Static - perform static NAT like was implemented for SCTP, but for TCP and
UDP. In this case the Intercept Range and NAT range must be equal.
4.
First configure an Outbound NAT address that represents "regular" Server NAT behavior (the
first VIP configured attached to the transmitting server is used) - for example 255.255.255.255
or 0.0.0.0.
5.
Upon upgrading, translate the configuration as follows:

a.
b.
If your Server NAT is enabled and the specific VIP is 0.0.0.0 then for all servers you need to
configure the special IP as an Outbound NAT
If your Server NAT is enabled and a specific VIP is configured then for all the servers that
you need to configure, set this IP as an Outbound NAT.
Configurations for a Server NAT VIP Solution

1.
Non-VIP Dynamic NAT - like traditional Outbound NAT, the NAT Type field is set to Dynamic
(default).
appdirector nat outbound address-range
From IP Address
192.10.10.1
To IP Address (-t )
192.10.10.2
appdirector nat outbound range-to-nat

Intercept From IP
2.2.2.1
To IP (-t )
2.2.2.254
Outbound NAT Addresses (-nf) 192.10.10.1

NAT Type (-nt)
Dynamic
Note: In AppDirector 2.x versions, the NAT Type parameter will be in the Outbound NAT range
and not in the intercepted range.
282

2. Non-VIP Static NAT
From IP Address
192.10.10.1
To IP Address (-t )
192.10.10.10

Intercept From IP
2.2.2.1
To IP (-t )
2.2.2.10
Outbound NAT Addresses (-nf)
192.10.10.1
NAT Type (-nt)
Static
Notes:
>> The intercept range and NAT address range must be equal in size - otherwise error: "The
NAT addresses range must be equal in size to the intercepted addresses range" will be
displayed.
>> In AppDirector 2.x versions, the NAT Type parameter will be in the Outbound NAT range
and not in the intercepted range
3. VIP Dynamic NAT
From IP Address
192.10.10.1
To IP Address (-t )
192.10.10.1

Intercept From IP
2.2.2.1
To IP (-t )
2.2.2.10
192.10.10.1
NAT Type (-nt)
Dynamic
Notes:
>> If the NAT address range includes VIP, the range size must be 1.
283

4.
VIP Static NAT

From IP Address
192.10.10.1
To IP Address (-t )
192.10.10.1

Intercept From IP
2.2.2.1
To IP (-t )
2.2.2.10
192.10.10.1
NAT Type (-nt)
Static
Notes:
>> Traffic from server X will always be NATted using the same VIP (configured in the
Outbound Intercept NAT entry that includes server X in the intercept range), regardless
of the protocol/port used.
>> You cannot configure more than one VIP to the same range of servers.
The Outbound NAT Ports per Address tuning parameter must be set to at least 15,000 because this
requires that NAT ports over 10,000 will be used to minimize the possibility of conflict with inbound
sessions. The availability of each port will be checked before it is used for Outbound NAT.
Outbound NAT
Outbound NAT enables AppDirector to hide various network elements located behind AppDirector.
Using this feature, AppDirector implements Dynamic NAT, which replaces the original Source IP and
source port of a packet that is routed or bridged with the configured NAT IP, before forwarding the
request.
Note: Outbound NAT is supported for TCP/UDP/ICMP/SCTP traffic.

Using Outbound NAT, AppDirector can NAT not only traffic from IP addresses of servers managed by
AppDirector, but also from any IP address behind AppDirector. The network elements whose
addresses are NATed can be servers or other local hosts. You can set different NAT addresses for
different ranges of Intercepted Addresses.
Outbound NAT applies only to traffic routed or bridged by AppDirector. Traffic destined for a
Layer 4 Policy VIP address is not NATed using Outbound NAT, even if the elements IP appears in the
Outbound NAT Intercept Addresses table. For NAT traffic to Layer 4 Policy VIPs, use Client NAT (see
page 275).
Note: Outbound NAT entries in the Client Table always use the Entry Per Sessions Mode.
284

Figure 13: Outbound NAT Operation
Dest. Address 100.1.1.100
AppDirector
2 Return
1 Request
Source Port 7777
Destination Port 7777
Outbound NAT Address 100.1.1.100

Source Address 10.1.1.11
Destination Address 10.1.1.11
Port 8888
Src Address 100.1.1.100
Port 8888
Internet
Network
Elements
10.1.1.11
10.1.1.12
10.1.1.1
The AppDirector Outbound NAT operation (as shown here) proceeds as follows:
1. A network element located behind AppDirector sends a request for service to an IP. The request
is intercepted by AppDirector, which replaces the intercepted source address 10.1.1.11 and port
7777 with the Outbound NAT address 100.1.1.100 and port 8888.
2. AppDirector receives the reply packet, replaces the destination address 100.1.1.100 and port
8888 with the elements original address 10.1.1.11 and port 7777, and returns it to the
originating network element.
Next Hop Routers

Each host or router that handles a packet examines the Destination Address in the IP header,
computes the next hop that will bring the packet one step closer to its destination, and delivers the
packet to the next hop, where the process is repeated. A Next Hop Router (NHR) is a network
element and is used for outbound traffic in Multi Homing configurations. NAT addresses can be
associated with Next Hop Routers (NHRs), similar to the way VIPs are associated with NHRs. This
provides a backup NHR for NAT Addresses, or for the simultaneous use of two NHRs with Hashing for
the outbound traffic.
Setting Up Outbound NAT

This process has several stages. Before configuring Outbound NAT, you need to:
1. Set the Outbound NAT Tuning parameters (see NAT Settings Tuning, page 65).
2. Globally enable the Outbound NAT feature on AppDirector.
285

Outbound NAT Global Parameters

When sending traffic through AppDirector with Outbound NAT, AppDirector replaces the original
source IP of a packet that is routed or bridged by AppDirector with the configured NAT IP before
forwarding the request, and replacing the source port.
Note: Outbound NAT is supported for TCP/UDP/ICMP/SCTP traffic.
To enable Outbound NAT

1.
From the AppDirector menu, select NAT > Outbound NAT > Global Parameters. The
Outbound NAT Global Parameters window appears
2.
Set the parameters.
Parameter
Description
Outbound NAT
Enable/ Disable(Default):
Outbound NAT hides the IP addresses of clients approaching
AppDirector farms, to solve routing issues. Both client IP and port are
changed in the process of Client NAT.
3.
Set the Outbound NAT to Enable.
4.
Click Set. Outbound NAT is now enabled.

Outbound NAT Addresses are the IP addresses that must be used to translate source IP of outbound
traffic. To define which source IPs are to be translated and to what Outbound NAT address configure
Outbound NAT Intercept Addresses..
To tune the Outbound NAT settings

1.
From the Services menu select Tuning > Device. The Device Tuning window appears.
2.
Set the Outbound NAT Addresses After Reset and Outbound NAT Intercept Ranges After Reset
parameters to the required number of entries.
3.
Click Set.
To set the parameters of the Outbound NAT Address Table

1.
From the AppDirector menu, select NAT > Outbound NAT > NAT Addresses. The Outbound
NAT Address Table window appears.
2.
Click Create. The Outbound NAT Address Table Create window appears.
3.
Set the parameters.
286

Parameter
Description
From IP Address
The first address in the NAT Addresses range.
To IP Address
The last address in the NAT Addresses range.

Note: The maximum number of IP addresses that can be defined in the
Outbound NAT IP Addresses table must not be higher than the value of
Outbound NAT Addresses Table specified in Tuning Table.
Redundancy Mode
For redundancy operation:

Active (Default): Farm is operating regularly on AppDirector.
Backup: Farm is not operational, and it backs up another farm on
another AppDirector device. When other AppDirector fails, this farm takes
over and becomes operational.
Segment Name
Segment providing the traffic that arrives from the configured segment.
NAT Mode
Defines whether this NAT address range is used to perform regular

dynamic NAT on outbound traffic (source IP and port translation) or static
NAT using VIP (N to 1 source IP translation only) or static NAT for SCTP
NAT for SCTP (N to N source IP translation only).
Values: Dynamic (default), SCTP NAT, Static
Outbound Intercept Addresses

You can associate Outbound NAT Intercept Addresses with Outbound NAT Addresses, to indicate
which NAT addresses are to be used for different Intercept addresses. When no Outbound NAT
Addresses are associated with an Outbound NAT Intercept Range, then AppDirector selects any of
the configured Outbound NAT Addresses when NATing traffic from that range.
Note: When an Outbound NAT Intercept Range includes servers managed by AppDirector,
Outbound NAT is performed for traffic from the servers even if Server NAT is enabled.
To set the parameters of Outbound NAT Intercept Addresses

1. From the AppDirector menu select NAT > Outbound NAT > Intercept Addresses. The
Outbound NAT Intercept Table window appears.
2. Click Create. The Outbound NAT Intercept Table Create window appears
Parameter
Description
Intercept From IP
First address in the Outbound NAT Intercept addresses range.
To IP
Last address in the Outbound NAT Intercept addresses range.
Aging Time
Period of idle time after which the Client Table entries associated with this
range are removed. Aging Time for Outbound NAT entries is determined
according to the aging time set by the user in the Outbound NAT
Intercept table.
287

Parameter
Description
Outbound NAT
Addresses
Associates a specific NAT address with selected intercepted range of

addresses.
Default: 0.0.0.0.
Remove Entry at
Session End
Whether to delete session entry from the session table at the session
end. If not - the entries will be deleted by aging.
Values: Disabled (default)/Enabled
4.
Outbound NAT using VIP

This feature enables you to use a VIP address as a NAT address in outbound NAT.
You need to configure the outbound parameters as follows:
From IP Address
2.10.10.10
To IP Address (-t )
2.10.10.10

Intercept From IP
2.2.2.1
To IP (-t )
2.2.2.10
2.10.10.10
NAT Type (-nt)
Static
Notes:
>> 2.2.2.1-2.2.2.10 is the range of the servers needs to use NAT.
>> 2.10.10.10 is a VIP on the device.
>> When a server from this range sends outbound traffic, NAT will be used, regardless of
the port\protocol of the server.
>> You cannot configure more than one VIP for the same range of servers.
>> Since we use high ports, you must configure more than 15,000 ports for the tuning of
outbound NAT.
288

Configuring AppDirector Advanced Global Parameters

The AppDirector Global Parameters window allows you to configure advanced system level settings.
To configure global information

1. From the AppDirector menu, select Global > Global Parameters. The Global Parameters
window appears.
Parameter
Description
Open New Entry

When Source Port
Different
When enabled, different sessions from the same client to the same
destination are counted separately, but all use the same firewall.
Enabling this option can produce finer load balancing and ensure that all
sessions from the same client to the same server use the same firewall.
When disabled, all the sessions of one application are considered a
single session, to enable better performance.
Select New Server

When Source Port
Different
When enabled, different sessions opened by a client's application are

served by different servers, according to the load balancing algorithms.
This option provides a more accurate minimum-user load balancing, but
may hinder some applications that depend on being served by the same
server. It also may overload the device's internal tables.
This option overrides the New Entry On Source Port option.
Values: Enable/disable
Interval (in seconds) for sending dynamic updates of local load to other
AppDirectors served by this AppDirector.
Load Report Timeout
The time (in seconds) this device will wait to receive load reports from a
remote device. After this timeout, the remote device is not considered
to be responding.
According to the number of retries configured in the farm, the remote
AppDirector becomes inactive, similar to the connectivity checks of
regular servers.
289

Tweaks
The AppDirector Global Parameters Tweaks window allows you to further refine your advanced
system level settings including the enabling and disabling of the Acceleration Engine.
To refine global information

1.
2.
Set the parameters.
Parameter
Description
Client Grouping Mask
Sets the grouping mask for clients. This IP mask defines a group of
clients for which the same farm server should be selected.
E.g. 255.255.255.255
UDP Sessions Tracking Whether UDP sessions are recorded in the Client Table.
Values: Enable (default)/ Disable.
One Trap
Determines how traps are issued when a server fails.

Values: Enable (default)/ Disable.
User Configured
Timeout After TCP
Failure
If this option is enabled, AppDirector will wait the amount of time

specified in the connectivity interval of the farm before rechecking the
server after a TCP connectivity check is not responded to.
When enabled, the default period is 3.5 seconds.
Default: Disable
No Slash After GET in

Extended HTTP Check
In the extended HTTP check, AppDirector issues the request to the

server in the format GET /<home page>. Enabling this option omits the
slash.
Default: Disable.
Extended Check Host

Mode
By default, AppDirector uses the server's IP address in the HTTP

request of the extended HTTP check. This allows the use of the farm
name instead.
Default: Server IP.
Extended LRP Security When the Triangulation redirection method is used (see Global
Triangulation Redirection, page 324), the Triangulation VIP address
must be on the same subnet as the Virtual IP address, for security
reasons.
To ensure that the Triangulation VIP address configured for a farm is on
the same subnet as that farm, the Extended LRP Security option must
be enabled.
Session ID Sharing
Enables or disables sharing of the Session ID information among

multiple farms using the same Session ID.
When a specific Session ID value is learned through one farm, the
same Session ID value can be used also for server selection in other
farms.
Default: Disable
When a Session ID value is learned through a client's session with one
farm (farm1) and then is seen in a client request for another farm
(farm2), AppDirector checks that the server indicated by the Session
ID value (a server in farm1) is also in farm2.
If not, then AppDirector uses load balancing to select a server in farm2.
290

Parameter
Description
DSID reply Learning in When using a DSID policy, this option causes the device to inspect each
'First' mode
reply of each transaction, on the same session, even if Layer 7
Persistent Switching Mode is set to FIRST.
AppDirector inspects the first request in each TCP connection, selects a
server, and forwards the request. During the rest of the TCP
connection, AppDirector forwards all further requests to that server.
If you need to learn from each response, you should configure one of
the 'complete' Persistent Layer 7 Switching modes (Overwrite or
Maintain).
Inspect first reply disabled (default)
Inspect all server replies provides backwards compatibility with
previous AppDirector versions.
Note: DSID is HTTP dependent and cannot be used with GenericSSL offloading selected in the Layer 4 Policy Application,
therefore Inspect First (disabled) is used. See Layer 4
Policies, page 183.
Outbound SIP Session Outbound SIP sessions must use Server NAT to hide the server IP
Support
address behind the service IP (VIP).
To return the session reply to the initiating server, AppDirector must
use a Call-ID persistency mechanism.
Values: Disabled (default), Enabled
Note: Support for Outbound SIP sessions has a performance
impact. Therefore, this feature is activated by flagging the
Outbound SIP only when required (disabled by default). Also
see Outbound SIP Sessions, page 406
When Outbound SIP traffic must be supported:
Servers from the sent outbound traffic can only belong to farms
attached to a SIP Layer 4 policy. This ensures that a SIP service
VIP is used as Server NAT.
If Layer 7 load balancing is used (for inbound SIP Layer 4 policies),
DSID must be enabled for all farms belonging to this Layer 7
policy.
SIP Aging on Session
End
Aging time for SIP dynamic SID entries and SIP client entries as a
result of the SIP session end, measured in seconds.
291

Parameter
Description
Acceleration Engine
(requires reboot)
Controls the Application Acceleration Engine. Values:

Enable (default)
Disable
Outbound Inquiries
Time-Out
Generic parameter for any AppDirector originated request timeout (e.g.

DNS, OCSP, TSL file fetch).
Note: Not applicable to NTP inquiries performed by AppDirector.
3.
Note: Status changes including enabling/disabling the acceleration engine are not exported to
the configuration file when the device configuration is saved. When copying
configurations between AppDirector devices, ensure that their statuses are aligned
before importing a configuration.
292

Configuring Global Load Balancing
Chapter 4 Configuring Global Load Balancing

This chapter describes the methods used in the global application switching schemes for global
traffic management. This chapter includes the following sections:
Global Traffic Management, page 293
Proximity, page 297
Configuring Local Report Protocol, page 303
Domain Name System (DNS), page 311
Redirection, page 319
Global Traffic Management

This section introduces global traffic management methods and devices and includes these topics:
IP Traffic Management, page 293
Global Solution Configuration Guidelines, page 296
IP Traffic Management
The global IP traffic management solution is intended for companies with server sites in multiple
locations. Distribution of server sites at different locations ensures high availability while maintaining
multiple level redundancy. If there is damage to a single server, farm, or site, business continuity is
maintained since switching from one server site to another is transparent to the users.
Globalization of business requires global server sites that ensure availability and efficiency over
great geographical distances. Organizations can increase productivity through resource sharing
among different branches placed in various locations.
For example, in a company, that has multiple data centers located all over the world, each data
center may act as an independent business unit. Global traffic management leads to better
administration and provides all employees, business partners and customers with critical resources,
24/7 availability, and optimal content delivery.
This figure illustrates an example of a global load balancing scheme.
New York
London
AppDirector provides site optimization and availability over geographic distances in a way that is
entirely transparent to the user. Various corporate resources are treated as a single entity. The
entire corporate data resource can be represented by a single logical address that corresponds to
entities at multiple physical locations.
293

Transactional Flow
Before considering a global solution it is essential to understand the flow of transactions over the
web and the challenges posed when multiple sites are used.
DNS resolution. To access Internet services the first basic step regardless of the application is
host name resolution; finding the IP address for the service name, using the DNS (Domain
Name System) protocol.
Application Transaction. Once the client receives the IP address of the target host name the
application transaction starts. A common client transaction involves multiple steps and often
multiple TCP connections. During the transaction a client may perform name resolution a few
times, work behind proxies or experience disconnections and resets. Therefore, the IP address
of the client may not be consistent.
AppDirector Global solution follows the transaction flow to provide availability and continuity
throughout the entire transaction life:
DNS Redirection - AppDirector functions as authoritative domain name server for the services
it load balances. When an AppDirector device receives a DNS A record query it selects the best
site for the service and answers with that site VIP.
Application Redirection - is required in the following cases:
During the transaction life, the site selected by the DNS redirection mechanism becomes
unavailable or overloaded.
During an HTTP transaction life, a new TCP connection arrives at a different site than the
one where the transaction started.
Protocols that do not use DNS as a first step.
AppDirector supports specific protocol redirection mechanisms (HTTP/S, RTSP and SIP) and generic
mechanisms (Proxy and Radware patented Global Triangulation).
Site Selection
AppDirector selects the best site based on availability, load and network proximity.
Load & Availability. Any AppDirector with site selection privileges must know the condition of
every other site to make the appropriate decisions, based on the real-time dynamic load. This is
achieved via Radware proprietary protocol called LRP (Load Report Protocol).
Proximity. Network proximity indicates the network distance or time distance between a user
and a data resource. For example, if a user is geographically closer to the New York site than to
the Chicago site, yet can access the Chicago site faster when the network path to the New York
site is overloaded. To measure network proximity AppDirector devices perform proximity checks
to the client subnet. In addition any AppDirector with site selection privileges must know the
network proximity of the client to every other site to make the appropriate decisions. This is
achieved via Radware proprietary protocol called PRP (Proximity Report Protocol).
Caution: All devices in a Global configuration must run the same software version to ensure
that LRP and PRP algorithms can run between the sites.
Load Balancing Scheme

AppDirector-Global balances traffic between multiple distributed sites according to the load present
at each site. However the AppDirector Global device selects itself as the best site as long as the load
on its local servers is lower than the Distribution Threshold configured for the specific farm and local
servers are available. An AppDirector Global device starts distributing immediately in the following
cases:
All local servers are inactive, either operationally or administratively (disabled or in backup
mode).
The Distribution Threshold is set to 0.
294

The maximum number of users that an AppDirector device can receive from other AppDirectors is
determined by the configured Farm Capacity Threshold. Once reached, the AppDirector device uses
LRP to inform all other AppDirectors sending traffic to this farm that it can no longer handle directed
traffic.
You can define the Distribution Threshold parameters and the Capacity Threshold parameters per
farm within AppDirector-Global. These parameters are measured in number of Client Table entries
for this farm. You can also define the Capacity Threshold for the farms of AppDirector devices.
Radware Devices Used in Global Solution

To implement the global traffic management solution, you need to work with an AppDirector-Global
device - an AppDirector device where a Global Traffic Management license is installed. An
AppDirector Global device supports both local traffic management and global traffic management best site selection. A distributed site can be a remote server or another AppDirector site. The table
below describes the differences between AppDirector and AppDirector global solutions for
functionality.
Table 4: AppDirector: Regular versus Global Functionality
Functionality
AppDirector
AppDirector Global
Server types supported
Regular
Regular
Local Triangulation
Local Triangulation
Local Farm
Local Farm
Remote Server
Local AppDirector
Distributed AppDirector
LRP
Send
Send and Receive
PRP
Answer PRP queries
Answer and Initiate PRP

queries
Redirects traffic to other locations
No
Yes
Redirection Type Supported
DNS, HTTP & RTSP for

Local Redirection
DNS, HTTP & RTSP & Global

Triangulation.
DNS Server Functionality (DNS

Resolution)
Yes
Yes
VIP Anycast advertisement
Yes
Yes
BWM & IPS and DoS functionality
With proper license
With proper license
Cookie Persistency
Yes*
Yes*
(Requires Special License)
295

Server
Server
Server
Distributed devices:
AppDirector/AppDirector-Global
Remote
Server
Main device:
AppDirector-Global
Server
Server
Server
Global Solution Configuration Guidelines

To achieve a globally distributed solution, the following steps should be performed:
On a device without site selection privileges (AppDirector or AppDirector Global) you need to
perform the following actions:
Configure provided services as for local load balancing (farms including local servers, Layer 4
policies, host names, etc.)
In order to preserve global persistency for HTTP traffic under any circumstance, it is
recommended to activate Insert cookie for HTTP Persistency. See HTTP Persistency in Global
Environments for more details.
Configure an LRP entry for each combination of a farm that is part of a distributed service and a
site with distribution privileges.
Configure the proximity checks that you want the device to perform.
On a device with site selection privileges (must be AppDirector Global) you need to:
Define a farm for each distributed service. Each farm includes local servers plus Distributed
AppDirector servers for all distributed sites (the server address is the VIP address of the service
on the distributed AppDirector or a public NAT address of that VIP) and/or remote servers.
Note: If a distributed site is connected via multiple WAN links (multi-homing), it appears in the
distributing site farm as multiple servers - one for each WAN link (each server address is
the public NAT address for the distributed site VIP via a different WAN link).
For each farm the redirection methods must be configured.
In order to preserve global persistency for HTTP traffic under any circumstance, it is
recommended to activate Insert cookie for HTTP Persistency. See HTTP Persistency in Global
Environments for more details.
Configure the rest of the service configuration as for local load balancing (Layer 4 policies, host
names, etc.)
Configure proximity, including static proximity if required.
Configure DNS persistency, if required.
296

When the solution includes multiple sites with distribution privileges, LRP entries must be configured
to report local load to the other distributing sites.
Note: To ensure that the inter-site proprietary data exchange protocols work properly, the
devices in all sites must run the same version.
Caution: All devices in a Global configuration must run the same software version to ensure
that LRP and PRP algorithms can run between the sites.
Proximity
This section provides information about the methods AppDirector uses to measure proximity to
redirect traffic and includes the following topics:
Proximity Parameters, page 298
Proximity Checks, page 299
Proximity Report Protocol (PRP), page 300
Static Proximity Database, page 301
AppDirector-Global maintains two proximity databases that hold information about a specific subnet
of IP addresses and lists the best three servers for this range. The servers are presented in the list
according to proximity considerations, the closest server appearing first. The server is either a
Virtual IP address on a Distributed AppDirector device (bound to a cluster of physical servers) or a
standalone remote server. If the top priority server is unavailable or loaded, AppDirector-Global
sends clients to the next best server/site. If multiple application instances (farm servers) are defined
on the top priority server, AppDirector-Global distributes the clients between the instances in a
weighted cyclic manner. The following databases are kept:
Static database, user-defined
Dynamic database, built dynamically by AppDirector-Global
297

Proximity Parameters
Before you configure proximity checks, you need to set up the Proximity Parameters.
To configure Proximity Parameters

1.
From the AppDirector menu, select Proximity > Parameters > General. The Proximity
2.
Set the parameters.
Parameter
Description
Proximity Mode
The user can determine the proximity mode as either:

No Proximity (default): No proximity is operated.
Static Proximity: AppDirector will only use redirections according
to static proximity table. Dynamic auto learning mechanism is off.
Full Proximity: AppDirector will redirect according to the static
redirections, and will use auto learning for subnets which are not
defined as static entries.
Main DNS Address
IP address of the local primary DNS server. AppDirector avoids

unnecessary proximity calculations in case the DNS server is located
near AppDirector. DNS requests that are received from this DNS
server are replied using load considerations only.
Backup DNS Address
IP address of the local secondary DNS server. AppDirector avoids

unnecessary proximity calculations in case the DNS server is located
near AppDirector.
DNS requests that are received from this DNS server are replied using
load considerations only.
Proximity Aging
Period
Period of time, in minutes, in which a dynamic entry is kept in the

database.
When this time is about to expire and a new request is received from
a client IP within this range, AppDirector -Global refreshes the
information of that entry by re-executing the proximity checks.
Values: 0 - 10080 minutes (a week)
Default: 2880 minutes (2 days).
Hops Weight
Emphasis to put on the number of hops between client and farms

when determining proximity.
The number of hops affects the load balancing decision based on
proximity considerations.
Latency Weight
Emphasis to put on the time between client and farms when

determining proximity. The number effects the load balancing
decision based on proximity considerations.
298

Parameter
Description
Load Weight
Emphasis to put on the load of remote server farm between client and
farms when determining proximity. The number effects the load
balancing decision based on proximity considerations.
Proximity Table
Cleanup
The frequency of the Proximity Table cleanup.

Default: 0
3. Click Set. The proximity parameters are recorded.
Proximity Checks
AppDirector has a sophisticated mechanism to detect network proximity using a dynamic
database of clients and their proximate sites. This is constantly updated by an auto-learning
mechanism.
To get accurate network proximity results, the checking method should be configured to cross all
obstacles en route to the client. AppDirector uses several methods to detect the number of hops
and the latency from the client to each of the sites. These methods ensure that the proximity
check will go through any router and firewall with maximum accuracy.
When a client approaches AppDirector, a proximity check is performed by each site and the
results are communicated using the Proximity Report Protocol (PRP). Now AppDirector can
redirect the client to the closest site. When another client from the same network approaches
AppDirector, later, the nearest site is now known, and the client is immediately redirected there.
To configure Proximity checks

1. From the AppDirector menu, select Proximity > Parameters > Proximity Checks. The
Proximity Checks window appears.
Parameter
Description
Proximity Checks
Sets whether the AppDirector device is allowed to perform proximity

checks for AppDirector-Global. The proximity probes themselves are a
combination of IP,TCP and application layer probes (Including TCP ACKs
and ICMP Echo requests) to ensure accurate measurements.
Values:
Enable (Default): AppDirector/AppDirector-Global can serve as a
Distributed server for other AppDirector-Global devices and can perform
proximity checks for them. These AppDirector devices appear in the
Distributed Sites definitions.
Disable: No proximity checks are done for other AppDirector devices.
Basic Check
A simple ping test unrelated to the application used by the user who
triggered the proximity check.
Default: Enabled
Advanced Check
Test that simulates standard applications (using UDP traffic). Sometimes

IDS devices may consider such proximity check packets as an attack.
Default: Enabled.
299

Parameter
Description
Application
Independent
Check
Test that uses application information in packet received from the

remote client to simulate a response.
Application UDP
Traceroute Check
Using the traceroute tool for the proximity check in the example above,
AppDirector can measure latency and the number of hops to the last
router. The traceroute proximity check is implemented using the UDP
protocol to port 37853.
Default: Enabled.
Default: Enabled.
Application Aware
Check
Test that simulates a generic response, unrelated to client's request.
Failure Notification
Controls whether user is notified when proximity checks fail.
Check Retries
If another AppDirector does not answer consecutive PRP requests,

AppDirector-Global assumes that it cannot answer and ignores that
particular AppDirector for this client.
Default: Enabled.
Default: 2
Check Interval
An interval in seconds during which AppDirector -Global sends a PRP

request packet to another AppDirector. If no answer is received within
this period, AppDirector-Global resends the PRP request packet.
Default: 5
3.
Click Set. The proximity checks are recorded.
Proximity Report Protocol (PRP)

AppDirector-Global can redirect traffic to distributed locations over the Internet, if the distributed
site provides better service to the client (in terms of availability, load and proximity). These
distributed sites can have a standalone server or a server farm managed by another AppDirector.
Information on the proximity of these distributed sites to the client enables AppDirector-Global to
make such decisions. When a distributed site is equipped with an AppDirector that manages a server
farm, a proprietary inter-AppDirector protocol, called PRP (Proximity Reporting Protocol), is used by
AppDirector-Global to query other remote AppDirectors about their proximity to a client (can be
client or DNS server). PRP is a simple UDP-based protocol that uses port UDP port 2091.
To select the closest site for a specific client, AppDirector-Global finds out how far this client is
from all the AppDirectors in the system. To do this, AppDirector-Global calculates the number of
router hops and latency between itself and the client. Then, AppDirector-Global requests all other
AppDirectors to do the same and receives a report from each indicating router hops and latency
between each of them and the client.
To ask other AppDirectors about the proximity information, AppDirector-Global uses the Proximity
Report Protocol (PRP), which is a UDP-based protocol. When AppDirector-Global needs to gather
proximity information about a client, it sends PRP requests to all AppDirectors in the system. Each
AppDirector then calculates router hops and latency between itself and the client and reports back to
AppDirector-Global, using a PRP response packet. PRP uses UDP port 2091.
Notes:
>> AppDirector can also send PRP reports. Only AppDirector-Global can send PRP requests
for proximity information. In addition, AppDirector-Global receives and uses the PRP
responses to distribute traffic globally according to proximity considerations.
300

>> An AppDirector which receives the request from the client and is initiating the PRP
queries must always be an AppDirector-Global.
>> An AppDirector device that receives PRP queries and responds can be either AppDirector
or AppDirector-Global and proximity checks must be configured.
When a client request arrives from a class C network for which there is no proximity data,
AppDirector gathers proximity information for the class C network of the client. To gather this data
the Initiator AppDirector performs the following:
Sends proximity checks to this new class C network.
Sends PRP queries to all distributed servers (Distributed AppDirector type servers) in the farm
servicing this client request, asking them to perform proximity checks to this class C network.
An AppDirector that initiates PRP queries saves both its own proximity results and those
received from AppDirectors receiving PRP queries in its Dynamic Proximity table for future
requests from this class C network.
PRP in a Multi-Homed Environment

When an AppDirector is installed behind a NAT device that load balances inbound and outbound
traffic between multiple WAN links it is operating in a multi-homed environment. Here, an
AppDirector service (VIP) is accessible via a number of public IP addresses - one for each WAN link
load balanced by the multi-homing device.
Static Proximity Database

The Static Proximity Table is user-defined. Each row in the table defines the farm that it applies to
and a range of IP addresses. This range can include only one IP address or an entire IP address
range. For the predefined range, you can list up to three IP addresses in order of priority. The
priority defines which IP should server the client request. This is used when redirecting client in a
Global solution, either in the DNS stage or later (HTTP, RTSP, etc.).
Each server can be:
IP of a Distributed AppDirector type server in the relevant farm
IP of a Remote Server type server in the relevant farm
VIP of a Layer 4 policy which is associated with the relevant farm
Notes:
>> You need to enter the VIP that is associated with the farm in the static proximity so that
the VIP is always associated with the farm.
>> The number of proximity subnets is configurable per farm. The default number of entries
is 500, but you can select any value between 1-5000. If you configure more entries than
the available memory allows, AppDirector prints a message to the terminal and writes it
to the log file.
>> After setting the new values, the device must be rebooted.
>> You can configure for a known range of clients, the three nearest sites that will provide
the service. Only if all the configured sites are down or overloaded will the next most
convenient site be selected to provide the service.
You use the Static Proximity Table window to configure this feature. This window manages the
ranges of static proximity redirections. You can configure ranges of IP addresses of clients for each
farm address with a list of the three preferred sites for this range. If the range should be handled in
the local site, the local site farm name should be entered.
301

For the predefined range, you can list up to three IP addresses in order of priority. The priority
defines which IP should server the client request. This is used when redirecting client in a Global
solution, either in the DNS stage or later (HTTP, RTSP, etc.). The Static Proximity window allows you
to insert a new static client.
To define the static proximity parameters

1.
From the AppDirector menu, select Proximity > Static Proximity. The Static Proximity
window appears.
2.
Click Create/Update. The Static Proximity Create/Update window appears.
3.
Set the parameters.
Parameter
Farm Name
Description
Name of the farm to which the entry is applied.
Default: None
From Address
IP address of the first client IP in the range.
To Address
IP address of the last client IP in the range.
Server 1

OR
IP of a Remote Server type server in the relevant farm OR
Local Service: The first priority server that this range of clients
will be redirected to.
Server 2

OR
Local Service: The second priority server that this range of clients
Server 3

OR
Local Service: The third priority server that this range of clients
4.
Click Set. The client is added to the list.
Default Redirection
Default Redirection is applicable only for remote or distributed servers. When proximity is used and
a client for whom no proximity settings are defined approaches AppDirector, a server is selected for
that client based on load considerations only. When no proximity information is available for a client,
Default Redirection enables you to define which servers to use and in which order of priority. The
table below presents the parameters you need to set for each farm in which you want to employ
Default Redirection.
302

To configure Default Redirection

1. From the AppDirector menu, select Distributed System > Default Redirection. The Default
Redirection window appears.
2. Click Create. The Default Redirection Create window appears.
Parameter
Description
Farm Name
Name of farm to use Default Redirection.
Priority
Priority order in which servers are used, where 0 indicates the highest
priority.
Default: 0
Server Address
Default server IP address used when no proximity information available

for client approaching this farm.
Values: Remote or distributed servers configured for this farm. No
default.
Server Port
Zero (0) if no application port has been specified.
Admin Status
Enables or disables Default Redirection for the farm.

Default: Enabled.
Configuring Local Report Protocol

This section describes methods used to provide an AppDirector-Global device with load and
availability information for other AppDirector sites to redirect traffic according to load and
availability. The following topics are included:
Introducing the Load Report Protocol (LRP), page 303
Local Load Report Protocol (Local LRP), page 309
Introducing the Load Report Protocol (LRP)

AppDirector-Global can redirect traffic to distributed locations over the Internet, if the distributed
site provides better service to the client (in terms of availability, load and proximity). These
distributed sites can have a standalone server or a server farm managed by another AppDirector.
AppDirector-Global needs information on the load and availability of these distributed sites to be
able to make such decisions. When a distributed site is equipped with an AppDirector that manages
a server farm, a proprietary inter-AppDirector protocol, called LRP (Load Report Protocol), is used by
distributed AppDirectors to report the availability and load of their farms to other AppDirectors. LRP
is a simple UDP-based protocol using UDP port 2090.
Note: An AppDirector running this version will be able to communicate via LRP only with
AppDirector devices running version 2.14 or higher or devices running AppDirector 1.07
versions from 1.07.15 and higher.
303

For better clarity we are going to call the device which sends load reports for its farms the "Local
AppDirector" and the device that receives the reports, the "Remote AppDirector.
A Local AppDirector can be either an AppDirector or an AppDirector-Global. A Remote AppDirector
must always be an AppDirector-Global.
If more then one global site is a primary site and makes redirection decisions, an AppDirector-Global
device can function as both a Local and as a Remote device - it will send load reports to other
primary sites and receive load reports from all other sites.
The Local AppDirector reports the load of all of its farms that appear as distributed servers
(Distributed AppDirector server type) in Remote AppDirectors.
The frequency (in seconds) with which LRP reports are sent is configurable via the Load Report
Interval parameter on a Local AppDirector.
A Remote AppDirector can receive reports only for servers that appear in any of its farms as
Distributed AppDirector servers.
The time (in seconds) a Remote AppDirector waits to receive load reports from the Local AppDirector
is configured via the Load Report Timeout parameter in the Remote AppDirector. After this timeout,
the Remote AppDirector considers the Local AppDirector as non-responding and the status of the
Distributed Server that represents this Local AppDirector farm in the Remote AppDirector farm is
changed to Not In Service.
The Local AppDirector must be configured with all the reports it needs to send to Remote
AppDirectors. The Report Table is used for this purpose.
A Load Report entry must be configured for each combination of a local farm that appears as a
distributed server in other sites and a Remote AppDirector to which its load must be reported. For
example, if the Local AppDirector has 3 farms that appear as distributed servers in 2 remote
AppDirectors, 6 entries are to be configured in the Report Table.
The configuration of a Report Table entry depends on the environment at the Local AppDirector site.
The factors that influence it are:
Whether the Global Triangulation method can be used to redirect traffic to this Local AppDirector
farm.
Whether any NAT device is installed in front of the Local AppDirector device and/or Remote
AppDirector device.
Whether any multi-homing NAT device (such as LinkProof) is installed in front of the Local
AppDirector device
The following figure describes a configuration in which SF-Farm from San Francisco (Local
AppDirector) appears as a distributed server in NY-Farm from New York (Remote AppDirector)
meaning that the AppDirector in San Francisco (Local) must send reports to the AppDirector-Global
in New York (Remote).
304

Figure 14: Load Reporting
To configure Load Report for Local AppDirector

1. From the AppDirector menu, select Distributed System > Report Configuration. The Load
Report window appears.
2. Click Create. The Load Report Create window appears.
305

Parameter
Description
Distributed Farm
Name
Name of farm in the Remote device that includes the Local

AppDirector farm as a distributed server - in the example above, NYFarm.
Distributed Server
Server address for the distributed server in the Remote AppDirector the value of this parameter depends on whether a NAT device is
installed before the Local AppDirector.
No NAT device: Local AppDirector Layer 4 policy VIP that is
connected to the farm whose load we are reporting - in the
example above, 200.1.1.200.
NAT device: NAT address of the Local AppDirector Layer 4
policy VIP that is connected to the farm whose load we are
reporting - in the example above, 250.1.1.200.
Farm Name
Name of the local farm whose load we are reporting - in the example
above, SF-Farm. This is required if the Layer 4 policy configured for
this entry points to a Layer 7 policy (otherwise it s automatically set
to the farm name used in the Layer 4 policy).
Note: If no farm name configured, no report is sent.
L4 Policy Name
Layer 4 policy configured in the Local device, that points to the farm
whose load we are reporting - in the example above, SF-Policy.
Triangulation VIP
Virtual IP address for global triangulation on the Local AppDirector in the example above, 200.1.1.220. This parameter is relevant only
when Global Triangulation is used.
Triangulation VIP NAT
Public IP address for Triangulation VIP, required only when Global

Triangulation with NAT is used - in the example above 250.1.1.220.
Destination Address
IP interface of the Remote AppDirector device, or NAT IP for this

interface, to which load and availability reports for local farms are
sent - in the example above 100.1.1.10, or 163.1.1.10 if NAT device
is present.
Redundant Destination IP interface of a backup Remote AppDirector device, or NAT IP for

Address
this interface.
Health Monitoring ID
An identifier for this report that allows it to be associated with health

monitoring checks, required only when a multi-homing device is
installed in front of Local AppDirector. For more details see LRP in
multi-homed environments.
Operation Status
Values: Active /Inactive.

(Read Only) in Update mode.
Original VIP
Original VIP (on the Remote AppDirector) to which the client sent the
request, required when Global Triangulation is used- in the example
above 100.1.1.100, or 163.1.1.100 if NAT device is present. This is
the address that the Local AppDirector device uses as source IP for
triangulated traffic.
4.
5.
Adjust Load Report Interval and Load Report Timeout fields in the Global Configuration window,
as described in the Global Configuration section.
306

LRP in Multi-Homed Environments

When an AppDirector is installed behind a NAT device that load balances inbound and outbound
traffic between multiple WAN links it means it operates in a multi-homed environment. The most
obvious example of such a NAT device is Radware's LinkProof.
In such an environment an AppDirector service (VIP) is accessible via a number of public IP
addresses - one for each WAN link load balanced by the multi-homing device.
When a Local AppDirector site is multi-homed, it affects the LRP in the following way:
1. The Local AppDirector must send multiple reports for each "local farm-Remote AppDirector"
combination - one report for each WAN link managed by the multi-homing device. For example,
if the site has 3 WAN links, 3 Report Table entries are configured for each "local farm-Remote
AppDirector" combination.
2. The Remote AppDirector farm must also have multiple distributed servers representing the same
Local AppDirector farm. In the above example, 3 distributed servers that represent Local
AppDirector must be configured in the Remote AppDirector farm.
3. The Local AppDirector needs to split the actual load of the local farm between the multiple
reports it sends to the same Remote AppDirector. In the above example, if the current load is
1500 users, each of the three reports Local AppDirector is sending will report 500 users.
4. The reports Local AppDirector is sending must also take into consideration the availability of the
WAN links - if one of the WAN links is unavailable, Local AppDirector cannot send the relevant
report for this entry. For the example in figure 2, if link A is down, Local AppDirector should not
send a report for distributed server 250.1.1.200 - the Remote AppDirector will understand that
this server is unavailable.
To allow Local AppDirector to check WAN links availability and send LRP messages accordingly,
health checks must be configured for each WAN link on Local AppDirector. The health check of each
link must be bound to the respective Load Report entry. In the Health Monitoring Bind table (page
.) the Load Report entry is identified by its Health Monitoring ID field (a string identifier must be
configured in this field when the Load Report entry is defined).
To ensure that each health check configured on Local AppDirector will indeed check the required link
there are two options:
The destination IP of the health check is the internal interface of the access router for that link in this case LinkProof routes the health check request to the proper router.
The destination IP of the health check is an external address from the respective link provider
(DNS server, etc). The address used for each health check must be different. The LinkProof must
be configured to send each health check through the appropriate link by using traffic routing
policies (grouping or flow policies according to LinkProof version) to ensure the correct WAN link
is checked - for details please see LinkProof user guide.
Example
The following is an example of the configuration required on a Local AppDirector that is installed
behind a LinkProof (Figure 2).
Step 1.
Configure the appropriate entries in the Report Table.
Parameter
Entry 1
Entry 2
Entry 3
Distributed Farm
NY-Farm
NY-Farm
NY-Farm
Distributed Server
250.1.1.200
192.1.1.200
176.1.1.200
L4 Policy
SF-Policy
SF-Policy
SF-Policy
Farm Name
SF-Farm
SF-Farm
SF-Farm
307

Parameter
Entry 1
Entry 2
Entry 3
Triangulation VIP
200.1.1.220
200.1.1.220
200.1.1.220
Triangulation VIP NAT
250.1.1.220
192.1.1.220
176.1.1.220
Report Destination
Address
100.1.1.10
100.1.1.10
100.1.1.10
Health Monitoring ID
SF-link1
SF-link2
SF-link3
Origin IP Address
100.1.1.100
100.1.1.100
100.1.1.100
Backup Report
Destination Address
Step 2.
Configure health checks for each WAN link. This example shows configuration of simple health
checks, but a health check group can also be bound to a Load Report entry.
Health Check Name
WAN1
WAN2
WAN3
Method/Arguments
As required
As required
As required
Destination Host
250.1.1.11
192.1.1.31
176.1.1.53
Next Hop Router
200.1.1.10
200.1.1.10
200.1.1.10
Step 3.
Bind each health check with the corresponding Load Report entry.
Health Check Name
WAN1
WAN2
WAN3
Server/NHR/Report
Report-SF-link1
Report-SF-link2
Report-SF-link3
308

Figure 15: LRP Multi-Homing example - Local AppDirector installed behind a LinkProof
Local Load Report Protocol (Local LRP)

Large companies may have large networks, including multiple sites and broad internal networks.
Handling these networks might require a layer of devices, consisting of global, local, or centralized
AppDirectors. This is emphasized when security devices such as firewalls are connected in front of
the internal LAN. Since firewalls usually perform NAT and policy management on internal clients,
connecting one AppDirector on the external side of the firewall entails complicated IP management.
Connecting one AppDirector on the internal side of the firewall does not solve the problem if there
are global sites to be handled; the solution is a two-tiered AppDirector setup.
Global AppDirectors handle traffic redirection between two sites, while Local AppDirectors handle
local servers. From the Global AppDirector view, the farm of the Local AppDirector is a local server
handling all traffic to the internal network.
309

The solution is to use LRP messages between the two AppDirector devices using the Local
AppDirector server type. Traffic is forwarded to the Local AppDirector devices and not redirected, as
in the global solution with Distributed AppDirectors. In a Global Triangulation scheme, the local
AppDirector is configured as a farm of the Global AppDirector, causing the Global AppDirector to load
balance traffic to the local AppDirector as if it was a regular server.
To configure Local LRP

1.
On the global AppDirector, define the local AppDirector as a local AppDirector server in the
relevant farm's Remote Server Table.
2.
On the local AppDirector, define the relevant LRP reporting entries to accommodate the
relationship between the global and local AppDirectors.
To configure AppDirector Local LRP

1.
From the AppDirector menu, select Global > Global Parameters. The Global Parameters
window appears.
2.
Set the parameters.
Parameter
Description
Open New Entry When Enable: Each session that a client opens, is recorded in the Client
Source Port Different
Table separately.
Disable (default): All client sessions are considered a single
session, providing better performance.
Select New Server
When Source Port
Different
Enable: Different sessions opened by a client's application are

served by different servers, according to the load balancing
algorithms.
Disable (default)
Note: This option provides a more accurate minimum-user load
balancing, but may hinder some applications that depend on
the same server. It also may overload AppDirector`s internal
tables. This option overrides the New Entry On Source Port
option.
3.
310
Interval (in seconds) for sending dynamic updates of the local load to
other AppDirector's devices that are served by this AppDirector. Also
see Configuring Local Report Protocol, page 303.
Load Report Timeout
The time (in seconds) a Remote AppDirector waits to receive load

reports from the Local AppDirector is configured via the Load Report
Timeout parameter in the Remote AppDirector. Also see Configuring
Local Report Protocol, page 303.

Domain Name System (DNS)

This section discusses host names and persistency and contains the following topics:
Host Names, page 311
DNS Server Parameters, page 315
Static DNS Persistency, page 317
DNS Statistics, page 319
The Domain Name System (DNS) allows Internet hosts to use names rather than IP addresses when
accessing an Internet resource. DNS translates easy-to-remember names, such as
www.radware.com, to IP addresses. When a user instructs a Web browser to go to a URL such as
www.radware.com, DNS equates that name with an IP address allowing the users machine to
communicate through IP with the machine that hosts the website of www.radware.com.
The DNS server consists of two main components:
The resolver: Component responsible for asking a DNS question about the IP address,
associated with the URL representing this address.
The name server: Component responsible for answering a DNS query. This is the agent
present in DNS servers. When asked "What is the IP address of www.company.com?", the
name server answers to the best of its ability.
All basic Internet hosts and TCP/IP stacks contain the resolver, while DNS servers contain both
components: resolver and name server. The resolver is necessary if there is a question that the DNS
server cannot answer.
There are two kinds of DNS questions, or DNS "queries," that can be asked:
Iterative: An iterative query CAN be answered with an absolute answer (IP address) or a
referral.
Recursive: A recursive query MUST be answered with an absolute answer (IP address).
Client resolvers cannot handle referrals and therefore, can only ask recursive questions. Server
resolvers, on the other hand, can handle referrals and can ask recursive or iterative questions.
Although it is more common for server resolvers to make iterative queries, they may at times make
recursive queries. When a name server is asked a recursive question, it must answer the question. If
it does not know the answer, it finds it. When a name server is asked an iterative question, it
answers the question to the best of its ability. If a name server knows the answer, the response is
the requested IP address; if a name server does not know the answer, the response is a referral
answer that includes the DNS and IP address of one or more name server(s) that may know the
answer.In the DNS, the IP world is divided into domains. Each domain contains hosts. For example,
a host known as www.radware.com is a host in the radware.com domain. Radware.com is a subdomain of the.com domain. Each domain in the Internet community has one or more authoritative
name servers. An authoritative name server for a domain is responsible for all sub-domains and
hosts within the domain or any of the sub-domains.
Host Names
This DNS table is used to define the relationships between hostnames and farms. You configure the
Host Names Table by defining the IP of the farm which handles the URL.
You can define wildcard host names using the RegExp Host Name Table in addition to the definition
of explicit URLs in the Host Names Table. This allows you to set a single definition for many similar
URLs that are hosted on the same farm. When a DNS request arrives AppDirector first looks for an
exact match in the Host Name Table. If such a match is not found, AppDirector looks for a match in
the RegExp Host Name Table according to the configured order of entries. When no match is found,
AppDirector discards the DNS request.
311

To set/update the parameters of the Host Names Table

1.
From the AppDirector menu, select DNS > Host Names. The Host Names Table window
appears.
Parameter
Description
Host Name
Verifies that the farm name is bound to a Layer 7 policy.

(Read-Only Parameter for Update mode)
Farm Name
Farm that you want to include in this policy, for example, Main Farm.
Default: None
Notes:
When a host name entry is created, if the Layer 4 Policy defined for
this host name entry has the Farm Name field configured (does not
include a Layer 7 policy), that farm name is displayed in the host
name entry Farm Name field by default.
System administrators need to configure the appropriate farm,
whose availability the decision for host name DNS resolution is
made.
Layer 4 Policy Name
Layer 4 Policy Name associated with Host Name entry provides

information about the relevant farm, and Virtual IP to be used in reply.
The farm is used to consider the servers load and can optionally use
Remote Servers or Distributed AppDirector in the farm for the DNS
resolution process.
If the Layer 4 policy selected for host name entry is connected to a
Layer 7 policy, then you need to select the appropriate farm in the Farm
Name field. If no farm is selected, DNS queries to this host name will
not be answered and the Farm Name from the Layer 4 Policy is
automatically selected.
Note: System administrators need to configure the appropriate farm,
on whose availability the decision for DNS resolution of this host name
is made.
External NAT Address Required when AppDirector is located behind a NAT device that NATs
the VIP address for the host name. AppDirector must use External NAT
Address in its DNS reply for DNS queries for host names.
312

Parameter
Preferred Resolve IP
Description
Chooses how to resolve for the best available IP.
0.0.0.0 (default): Here the host name is resolved to the best
available IP without taking Operation Mode into account.
The VIP of the Layer 4 policy defined for this host name (default):
Here the host name is resolved to the best available IP while taking
Operation Mode into account. If a local server in Regular Operation
Mode is available and the Farm distribution threshold was not
reached, the device answers with the Layer 4 policy VIP, if not it
selects the IP of one of the remote and distributed server's IPs
according to availability, load and proximity.
The IP of a Distributed AppDirector server or a Remote server in
the farm attached to the Layer 4 policy defined for this host name.
While the specified server is available, the host name is resolved to
its IP.
DNS Action
This defines whether the DNS query for a host name should be resolved
by AppDirector for globally load balancing applications or forwarded to
the configured farm for DNS traffic load balancing.
When set to Forward, this parameter enables AppDirector to provide
Layer 7 farm selection for DNS traffic. (See Layer 7 Farm Selection for
DNS, page 237).
Values: Resolve, Forward.
2. When creating, in the Host Names Table window, click Create. The Host Names Table Create
window appears, which contains the above parameters:
3. When updating, in the Host Names Table window, select the desired Host Name. The Host
Names Table Update window appears.
To update the parameters of the RegExp Host Name Table

1. From the AppDirector menu select DNS > Host Names. The Host Names window appears.
2. Select the desired Host Name. The RegExp Host Names Update window appears.
Parameter
Description
RegExp Host Name
Displays the Regexp Host Name for the Farm table.

Enter in the URL type. For example any URL that begins with the string
www.abc., followed by any text using letters and then followed by
.com is resolved to the IP of the related farm or to the Layer 4 policy,
when defined.
Index
Regular expression evaluation order.

Default: 0
313

Parameter
Description
Layer 4 Policy Name Layer 4 Policy Name associated with a Host Name entry provides
information about the relevant farm, and Virtual IP to be used in reply.
The farm is used to consider the servers load and can optionally use
Remote Servers or Distributed AppDirector in the farm for the DNS
resolution process.
If the Layer 4 policy selected is connected to a Layer 7 policy, then you
need to select the appropriate farm in the Farm Name field. If no farm is
selected, DNS queries to this host name will not be answered and the
Farm Name from the Layer 4 Policy is automatically selected.
Note: System administrators need to configure the appropriate farm,
whose availability the decision for host name DNS resolution is made.
Farm Name
Farm that you want to include in this policy, for example, Main Farm.
Default: None
Notes:
When a host name entry is created, if the Layer 4 Policy defined for
this has the Farm Name field configured (without a Layer 7 policy),
that farm name is displayed in the host name entry Farm Name field
by default.
System administrators need to configure the appropriate farm,
whose availability is decided for host name DNS resolution.
External NAT
Address
Required when AppDirector is located behind a NAT device that NATs the
Virtual IP address for the host name. Here, AppDirector must use the
External NAT Address in DNS reply for DNS queries for host names.
Preferred Resolve IP Chooses how to resolve for the best available IP.
0.0.0.0 (default): The host name is resolved to the best available IP
(either local VIP or VIP of a distributed site as part of local farm). The
device selects a Non-Backup server local or distributed (if the farm
reach the threshold), if there is no Non-Backup it will choose a
Backup server but it will treat the Backup Distributed server as
regular distributed server.
The Local VIP - The VIP of the Layer 4 policy defined for this host
name. If a local server is available, the device answers with the
Layer 4 policy VIP. If not, it selects the IP of one of the remote and
distributed server's IPs according to availability, load and proximity.
The device selects a Non-Backup server local or distributed (if the
farm reach the threshold), if there is no Non-Backup it will choose a
Backup server.
Remote VIP - IP of a Distributed AppDirector server or a Remote
server (not recommended, but possible) in the farm attached to the
Layer 4 policy defined for this host name. If the distributed server is
active it will ALWAYS be chosen regardless of the other servers.
DNS Action
This defines whether the DNS query for a host name should be resolved
by AppDirector or forwarded to another DNS server.
Values: Resolve, Forward.
4.
314

Notes:
>> Host Name field in both tables (Host Name and RegExp Host Name Table) is case
insensitive.
>> Total number of entries in Host Name Table and RegExp Host Name Table is determined
by the value of Host Names parameter in Tuning settings.
>> A . In a regular expression means any single character, to indicate a ., a\ must be
used before the ..
DNS Server Parameters

You can provide multiple a Virtual IP Interface address that can be backed up by the redundant
device. If the main device fails, DNS requests are handled seamlessly and transparently by the
redundant device.
To configure a Virtual IP Interface address to be backed up

1. From the AppDirector menu, select DNS > Server. The DNS Server Parameters window
appears.
Parameter
Description
DNS Service
Enable or Disable (Default) the DNS service.
Two Records in DNS Enable or Disable (Default) return of two A records in the DNS response.
Reply
Enable returns two A records, disable returns one.
DNS Persistency
AppDirector maintains persistency for consecutive DNS queries received from the same DNS client
IP address. For example, if a DNS server honors the low TTL that the AppDirector assigned to DNS
replies, it sends queries for the same farm every few seconds. If the client does not cache the
replies, or caches them for a short period, consecutive connections for the same session may end up
on two different sites.
When AppDirector receives a DNS request for a host name, for example www.a.com, it first
searches for the host name in the Host Name Table; and if the host name is not found, AppDirector
searches the RegExp Host Name Table. Once an entry is matched, the relevant Layer 4 Policy that
serves this host name is determined.
If DNS Persistency is configured for this Layer 4 Policy, AppDirector searches the static and dynamic
tables to determine the IP address used in the DNS reply. When AppDirector devices are used in
multiple sites to provide a global solution, Hashing can be used to provide consistent DNS replies
from different AppDirector devices to the same DNS client IP.
DNS Persistency can be configured for each farm using:
DNS Persistency: When AppDirector answers a DNS request, it creates an entry in the DNS
Persistency Table, indicating the requester's IP address and the VIP that was sent as a response.
AppDirector provides the same reply to that requester as long as there is a record in the table.
Static DNS Persistency: You can statically set VIPs to be used for a range of DNS IP
addresses.
315

You can tune the DNS Persistency and Static DNS Persistency Tables.
Note: When using redundant AppDirector devices, mirroring can be used for the DNS
Persistency Table. Similar to other mirrored tables, you can enable or disable DNS
Persistency Table Mirroring, and set the Update Time and Mirroring Percentage (see
Stateful Failover (Mirroring), page 140).
Working with DNS Persistency

DNS Persistency can be maintained using load balancing or Hashing. When DNS Persistency is
maintained using load balancing, AppDirector dynamically selects the VIP to be used for the DNS
reply based on load and proximity information. Subsequent requests from the same IP are replied to
using the same VIP. You can also set Static DNS Persistency. Each range of DNS client IPs can be
associated with a predefined VIP (see Static DNS Persistency, page 317).
Use of Hashing in the Global DNS Persistency Solution

In the global DNS Persistency solution, ensure that multiple AppDirector devices located at different
sites use the same DNS reply for the same client IP. Then, DNS Persistency is maintained using the
Hash function. To select the VIP for the DNS reply, AppDirector uses Hash on the DNS client IP
address. You need to consider the following when using Hash for Global DNS Persistency:
AppDirector devices must be configured so that the same VIPs are available for DNS replies.
When Hash is used for DNS Persistency, server weights are taken into account. To ensure that
different AppDirectors choose the same server, you must set servers with the same respective
weights.
If the VIP selected by Hashing is not available, AppDirector selects the next available VIP. This
behavior is consistent among different AppDirectors.
Entries in the DNS table should be created ONLY if the selected by the hash VIP option is NOT
available at the moment and because of that a different VIP must be selected.
When Hashing is used for DNS Persistency, load and proximity information are not used in the
DNS reply process.
When Hashing is used for DNS Persistency, Capacity Threshold and Distribution Threshold are
ignored.
DNS Grouping Mask

DNS Persistency can be maintained for groups of DNS client IP addresses, both when using Load
Balancing or Hash. For example, when the DNS Grouping Mask is set to 255.255.255.0, the same
DNS replies are sent to IP address 1.1.1.1 and 1.1.1.66.
To define DNS persistency

1.
From the AppDirector menu, select Farms > DNS Persistency Parameters. The DNS
Persistency Parameters Table window appears.
2.
Select the farm where you want to define DNS persistency. The DNS Persistency Parameters
Table Update window appears.
316

Parameter
Description
Farm Name
Name of the farm for which DNS persistency is used.

(Read Only)
Status
Disabled (Default): Disables DNS Persistency.

Enabled: Enables DNS Persistency.
Mode
AppDirector selects VIP used in DNS replies for the farm using these
modes:
Load Balancing (Default): Load Balancing algorithms are used,
considering load and proximity information.
Hash: Hash on client IP address. This can be used when AppDirector
devices are in a multiple site and global DNS persistency is required.
Static Mode
Disabled (Default): Disables Static DNS Persistency.

Enabled: Enables Static DNS Persistency.
Aging Mode
Entries in DNS Persistency Table can be aged based on these modes:

Fixed: Entry is removed from the table after the period of time
defined by the Aging Time parameter.
Inactivity (Default): Entry is removed from table if during the period
defined by the Aging Time parameter no additional DNS queries are
received from the same DNS client IP address.
Aging Time
Defines how many seconds an entry remains in DNS Persistency Table.

Values: 1 - 4,234,967,295 seconds (136 years).
Default: 60 seconds
Grouping Mask
Defines mask for a group of DNS client IP addresses.

Default: 255.255.255.255 (persistency is maintained for single client IP
addresses).
4. Click Set. The DNS Persistency Parameters Table Update window closes.
Aging Mode
Entries in the DNS Persistency Table can be aged by the Fixed or Inactivity modes. When Fixed
mode is used, the entry is removed from the table after the period of time defined by the Aging Time
parameter. When Inactivity mode is used, the entry is removed from the table if no additional DNS
queries are received from the same DNS client IP address during the period defined by the Aging
Time parameter.

Static DNS Persistency operates at the farm level based on Client IP Range. This means that
requests from client IP addresses in the same range to different hostnames that are mapped to the
same farm are replied using the same VIP. This VIP is called Preferred VIP and can be defined using
the Static DNS Persistency table.
You can also set an Alternate VIP to be used when the Preferred VIP is not available or overloaded.
When the Preferred VIP is not available and the Alternate VIP is set to Any, then AppDirector
dynamically selects the VIP for the DNS reply.
Note: To use static DNS, you need to first set the tuning on the device.
317

To define static DNS persistency

1.
From the AppDirector menu, select DNS > Persistency Table. The Static DNS Persistency
2.
Click Create. The Static DNS Persistency Table Create window appears.
Note: Before adding entries to the Static DNS Persistency table, you must enable DNS
Persistency and Static DNS Persistency.
3.
Set the parameters.
Parameter
Description
Farm Name
Select the name to describe the AppDirector farm.
From Client IP Address First IP address in client IP range for static DNS resolution.
To Client IP Address
Last IP address in client IP range for static DNS resolution.
Preferred VIP
IP address to be used for DNS replies for host names managed by this
farm. This address is usually set to the Virtual IP address associated to
Layer 4 Policy, or one of that farm's servers, of type Remote Server,
Distributed Server, or Local Farm.
Note: AppDirector uses this IP address only if the corresponding farm
server is available.
Alternate VIP
Alternate VIP can be set to one of the following values:

None (default): AppDirector does not reply to DNS query if the
preferred server is not available.
Any: When the preferred server is not available, AppDirector
selects a VIP according to the configuration of the DNS Persistency
Mode parameter using Load Balancing algorithm or using Hash.
Note: AppDirector uses the IP address configured as Alternate VIP
for DNS replies only when the corresponding farm or server is
available.
4.
318
Click Set. The DNS Persistency Parameters Table Update window closes and the new
parameters appear in the DNS Persistency Parameters Table window.

DNS Statistics
You can generate statistics regarding DNS requests.
To view the DNS Statistics

From the AppDirector menu, select DNS > Statistics. The DNS Statistics window appears, which
contains the following read-only statistics:
Parameter
Description
DNS Requests Last Second
Number of DNS requests in the last second.

Default: 0
DNS Replies Last Second
Number of DNS replies in the last second.

Default: 0
Failed DNS Requests Last

Second
Number of DNS failed requests in the last second.

Default: 0
Redirection
This section describes methods used to redirect traffic in the global traffic management solution and
includes the following topics:
DNS Redirection, page 320
HTTP Redirection, page 320
HTTP to HTTPS Protocol Redirection, page 321
RTSP Redirection, page 323
SIP Redirection, page 323
Proxy Redirection, page 323
Global Triangulation Redirection, page 324
Setting Redirection Parameters, page 326
Anycast Advertise, page 328
When using the global traffic management solution, several Redirection methods can help to define
how service requests are redirected.
When a client sends a new request for service, AppDirector selects the best available server. If the
required server is at the local site, AppDirector forwards the service request to that server. If the
required server is at a remote site, AppDirector redirects the service request using one of the
methods.
Multiple redirection modes can be enabled per farm. Exceptions include Global Triangulation and
Proxy (Client NAT) which cannot be enabled simultaneously.
When an application-specific redirection process (HTTP, RTSP, SIP) and a Global Triangulation or
Proxy mode are enabled in a farm, traffic belonging to an application for which a specific redirection
mode is enabled (HTTP, RTSP or SIP) is redirected accordingly, while other applications are
redirected using the Triangulation or Proxy methods.
319

DNS Redirection
The DNS Redirection method is based on the DNS process (see DNS Persistency, page 315). When a
client sends a DNS query to find the IP address of the host name of the requested service,
AppDirector operates as a DNS server. When a DNS query is made, AppDirector responds with the IP
address of the best site for the client. If the local AppDirector decides that the current site is best
suited for handling the client, it sends the query to its own VIP address. Otherwise, AppDirector
resolves the DNS query using the IP address of a remote farm or server. Redirection is only
performed during the DNS query/answer stage. Therefore, if DNS Redirection is enabled on a farm,
any packet destined to the Virtual IP address is handled by the local servers of this farm.
The DNS Redirection process involves the following steps:
1.
The DNS request reaches the AppDirector-Global physical IP Interface or Virtual IP Interface
from a DNS server. The request is to resolve a host name to an IP address.
2.
No search of the Client Table is made. AppDirector-Global searches the Static Proximity Table
for a range fitting the asking DNS server. If a match is made, the top priority server from the
active AND not overloaded servers is selected. AppDirector-Global resolves the name to the IP
address of the chosen server, which can be a local Layer 4 VIP or a VIP configured on a remote
AppDirector.
3.
If there is no match in the Static Proximity Table, the Dynamic Proximity Table is searched. If
there is a match, AppDirector-Global resolves the request to the Layer 4 VIP address of the
highest priority site (currently active and not overloaded), accounting for the hops weight,
latency weight, and the load weight variables.
4.
If there is no match, AppDirector-Global resolves the request to the IP address of the least
loaded site, while calculating proximity information for the querying DNS server (if proximity is
enabled). Then AppDirector-Global sends PRP requests to other AppDirectors to do the same.
5.
AppDirector-Global resolves the query to the IP address of the least loaded site.
Notes:
>> DNS answers are made with a DNS TTL of 0,(default) to reduce Internet caching and to
keep the system dynamic.
>> You can set DNS TTL to a higher value and you can set different DNS TTL values for
different farms.
Using AppDirector-Global, DNS Redirection works best if DNS servers from all over the Internet
make queries to AppDirector-Global. If the DNS servers local to AppDirector-Global or responsible
for the super-domain make queries to AppDirector-Global, their proximity calculations result in
inaccurate data. AppDirector-Global allows you to configure up to two DNS servers with requests
that are resolved to the least loaded site; no proximity calculations are made if a request comes
from either of these two DNS servers.
HTTP Redirection
The HTTP redirection method is used to redirect the HTTP traffic as follows:
1.
The client sends the GET request using the HTTP protocol to a VIP address of AppDirector.
2.
AppDirector receives the request and selects the best server for the task.
3.
If AppDirector decides that a distributed site or remote server is the most appropriate, then it
issues an HTTP redirect to the user indicating that the user has been redirected. Here,
AppDirector replies to the HTTP request using an HTTP code redirection code (Moved Temporarily
or Moved Permanently) and redirects the client to the relevant server.
320

HTTP redirection can be done by IP address or by name. HTTP redirection by IP redirects the request
for service to the IP of the remote server or the VIP of the Distributed AppDirector. When using HTTP
redirection by name, AppDirector redirects the client to another URL. The URL used for redirection is
configured using the Redirect To URL parameter in the server to which redirection is performed.
Note: When redirect by name is enabled and the redirect to URL field is empty, AppDirector
uses server name for redirection.
HTTP to HTTPS Protocol Redirection

HTTP to HTTPS protocol redirection is based on the location field in HTTP headers where AppDirector
handles SSL for backend servers, and the backend server performs a redirect using HTTP headers
specifying URL with HTTP:// instead of HTTPS://. AppDirector can redirect HTTP traffic to HTTPS.
Using this method, you can configure AppDirector to redirect clients to secure access to the site. You
can set AppDirector to indicate to a client to access the site using HTTPS rather than HTTP when
redirecting a client using HTTP redirection.
HTTP Persistency in Global Environment

In order to ensure transaction stickiness at all times in a global environment it is recommended to
use the Insert cookie capability, together with HTTP Redirection, for all farms involved.
AppDirector can identify the cookie used by client belongs to a different site (was inserted at the
beginning of the transaction by an AppDirector at that site) and employ HTTP redirection to transfer
the new request to the original site.
To maintain site and server persistency in a global environment:
HTTP redirection must be by name
Hostnames for all sites must belong to the same domain (for example www.a.com for the main
service, www.site1.a.com for site 1 and www.site2.a.com for site 2)
Ensure that the automatically generated Set-Cookie method uses the same cookie key in all
sites. This can be achieved either by using the same Farm Name in all sites, or by editing the
automatically generated cookie key.
Set the domain value of the automatically generated Set-Cookie method to the service domain
(in the example above a.com)
When AppDirector performs SSL for Back End servers the servers receives the requests in HTTP
(clear), therefore, when servers perform redirect to another page/site (using HTTP headers in
response with location field), it can now also use HTTP. If the clients receive this header they will
initiate the new connection over HTTP instead of over HTTPS and is dropped. Therefore the
AppDirector, that sends the response back to the clients must change the server's redirection
location URL appearing in the HTTP header from HTTP:// to HTTPS://.
This modifies the location header of any HTTP header in server's responses from HTTP:// to HTTPS:/
/, and the target port. The modification is performed where the host name in the client's request
matches the host name in the server's response, or where matching criteria are met. Matching
criteria can consist of one Regex that represent hostnames.
321

Notes:
>> For HTTPS redirection - if the Layer 4 policy port is different than port 443, the Layer 4
policy port is appended after a colon to the URL.
>> For HTTP redirection - If the Layer 4 policy port is different than port 80, the Layer 4
policy port is appended after a colon to the URL
>> When Backend SSL is working, you do not need to use HTTP to HTTPS protocol
redirection and you cannot configure them together.
Protocol Redirection
If a user requests the www.ab.com/base_redirect.html page, the page is redirected to www.bb.com/
Redirect/Path/redirect_page.html.
If the redirect was from ab.com to ab.com/some-other-path, no regular expression
is needed since this is the same host.
In this example, the redirect was from ab.com to bb.com and this works only when the regular
expression matches the host (the new host). Thus, when the regular expression is www.ab.com, it
does not match bb.com (which is the real location of the page).
The redirection works as follows:
AppDirector changes http to https for the following regular expressions:
"www.bb.com"
"www.b*.com"
"/*"
"bb.com"
"bb"
"www"
".com"
"."
".c"
"bb.com/Redirect/"
"www.bb.com/Redirect/Path/redirect_page.html"
"/"
AppDirector does not change to https for the following regular expressions:
"www.ab.com"
"www.bb.com/blabla"
""
" "
"ab.com"
322

RTSP Redirection
Real Time Streaming Protocol (RTSP) is used for audio/video streaming applications such as news
broadcasts, radio stations and live shows over the Internet. Using RTSP redirection, AppDirector can
redirect RTSP sessions to a remote site.
AppDirector forwards a RTSP request to a remote server or AppDirector. During the redirection,
AppDirector responds with a standard RTSP redirection message causing the client sending the
request to establish a new connection to a remote site to view/hear the streaming information. RTSP
redirection is used for requests to TCP port 554 and is enabled by the RTSP Redirection.
The RTSP redirection and the HTTP redirection methods work similarly. The RTSP redirection process
involves the following steps:
1. The client uses the RTSP protocol to send the Options, Describe, or Setup (request for a file)
commands to the VIP address of AppDirector.
2. AppDirector receives the request for service and selects the best server.
3. If AppDirector decides that a distributed site, rather than a local server, is the most appropriate,
then AppDirector issues a RTSP redirect to the user, redirecting the user to one of the distributed
sites.
RTSP redirection can be done by an IP address or by name. The name is taken from the Redirect To
URL parameter of the server. If the Redirect To URL parameter is not configured, the Server Name is
used instead (see HTTP Redirection, page 320). RTSP redirection can be used globally, redirecting
clients to remote farms or servers, or locally, using Redirect to Self (see Using Redirect to Self in
Multi-Homed Environments, page 396).
Note: RTSP redirection preserves the client-server persistency of RTSP sessions when the
Client Table mode Select Server When Source Port is Different is used.
SIP Redirection
The Session Initiation Protocol (SIP) is an IETF standard for a signaling protocol used for
establishing sessions between two or more end users. The SIP redirection method is used to redirect
SIP session invitations to external domains, such as a distributed or remote server.
The SIP redirection process involves the following steps:
1. The client sends the SIP request to an AppDirectors VIP address.
2. AppDirector receives the request and selects the best server for the task.
3. AppDirector chooses the distributed site or remote server, replies to the SIP request using the
SIP code 302 (Moved Temporarily) and redirects the client to the relevant server.
4. SIP redirection can be done by an IP address or by name. SIP redirection by an IP address
redirects the request for service to the IP of the remote server or the Distributed AppDirectors
VIP. When using SIP redirection by name, AppDirector redirects the client to another URL.
5. SIP redirection by name is configured using the Redirect To URL parameter for the server.
Proxy Redirection
This method uses Client NAT to redirect traffic. AppDirector acts as a proxy at the IP level, retrieving
content and then responding to the user. Before selecting this method, the Client NAT must be
enabled on the device and the Client NAT range must be configured for the farm. When traffic is
forwarded to another site, AppDirector replaces the original Source IP of the request with a
predefined NAT IP address and dynamically selected ports. Client NAT enables AppDirector to hide
the IP addresses of clients when forwarding traffic to servers in farms. Using Proxy redirection, the
323

server does not see the original client IP address. In certain applications, the application server
needs to know the clients identity and therefore AppDirector has a service entry point where the
client can insert the X-Forwarded-For Header in the traffic it redirects.
Global Triangulation Redirection

To handle the distribution of IP protocols (e.g.TCP or UDP), and when other redirection methods
cannot be used, use Global Triangulation redirection. The following figure illustrates an example
where a user needs to receive FTP services from ftp.company.com and approaches the main
AppDirectors VIP. If the main AppDirector has reached its Distribution Threshold and decides to
send this user to a Remote AppDirector, a simple delivery of the users packets to the Remote
AppDirectors VIP will not succeed. Since the user attempted to open the FTP session with main
AppDirector, if the reply comes from Remote AppDirector, the session fails. For a successful FTP
session, the reply to the user must be sent using the main AppDirector VIP as the Source IP
address.
Notes:
>> You cannot use Global Triangulation when any Acceleration Engine related capability (i.e.
SSL, Cache, Compression, and Authentication) is used.
>> The Triangulation redirection method is not applicable in a global solution configuration
that uses remote servers.
main
AppDirector
main VIP
Triangulation
VIP
Address
Remote
AppDirector
Remote VIP
User
To overcome this issue, AppDirector utilizes a process called VIP Mapping, which is used at the
receiving AppDirectors end (in this example, Remote AppDirector). The process consists of the
mapping of three parameters:
Parameter
Description
Distributed Server
VIP address of the Remote AppDirector. The Remote VIP address is

configured as a distributed server in the farm on the main AppDirector.
Triangulation VIP
Address
Virtual address on the Remote AppDirector associated with the main

AppDirector farm. This indicates that Remote AppDirector must send
the reply to the user using the main AppDirector VIP as the source
address.
Origin VIP Address
VIP address of the main AppDirector farm that directed the user to this
AppDirector. The Origin VIP Address in the example is the virtual
address of the main VIP.
324

This mapping is achieved via the LRP mechanism.
When Remote AppDirector receives packets destined for the Triangulation VIP address, it selects a
server in the relevant farm and forwards the request to it. The difference is that for the reply from
the server to the user, Remote AppDirector replaces the source address of the packet with the Origin
VIP Address, in this example, the main VIP. This way, the user receives replies from the same
address with which it tried to open the IP session.
Notes:
>> Global Triangulation does not work with persistent Layer 7 switching.
>> Layer 7 with Global Triangulation assumes all sites have the same configuration.
>> In Layer 7 with Global Triangulation, the main device sends the request to the
distributed site with no TCP handshake, just the GET.
The Global Triangulation redirection process involves the following stages:
1. User sends a new service request to VIP of main AppDirector (main VIP).
2. Main AppDirector receives the request for service and selects the best server for the task in the
relevant farm.
3. Main AppDirector decides to send the user to a distributed site. The request for service is sent
using the Triangulation VIP address associated with the Remote AppDirector VIP.
4. Remote AppDirector sends the packet to one of its local servers. The reply to the user is sent
using the Origin VIP Address as the source address.
Main VIP
Triangulation
VIP
Address
User IP
User IP
Main VIP
AppDirector uses Layer 4 Policies internally to manage Triangulation VIP addresses for Global
Triangulation. The Triangulation VIP addresses are defined in the Distributed Sites table.
AppDirector automatically creates, updates, and deletes the corresponding Layer 4 entries. These
entries appear in Layer 4 Policies. They are:
Layer 4 Policy Name parameters is Auto_Triangulation.
Policy Defined By parameter is System, for internally managed Layer 4 Policies.
325

Extended LRP Security

When the Triangulation redirection method is used (see Global Triangulation Redirection, page 324),
the Triangulation VIP address must be on the same subnet as the Virtual IP address, for security
reasons. To ensure that the Triangulation VIP address configured for a farm is on the same subnet as
that farm, the Extended LRP Security option must be enabled.
Note: The Triangulation VIP address and the Layer 4 Virtual IP address cannot be configured
on different subnets when Extended LRP Security is enabled. Extended LRP Security is
defined globally for each AppDirector and enabled by default. To place them on different
subnets, you must disable this option.
Setting Redirection Parameters

When using the global traffic management solution, several Redirection methods are available to
define how service requests are redirected to their required destinations. When a client sends a new
request for service, AppDirector selects the best available server for the task. If the required server
is placed at the local site, AppDirector forwards the request for service to that server. If the required
server is located at the remote site, AppDirector redirects the request for service using one of the
redirection methods. The redirection methods are configured at farm level. Multiple redirection
methods can be configured for each farm.
To set Redirection Parameters

1.
From the AppDirector menu, select Farms > Redirection. The Redirection Table window
appears.
2.
Select the farm where you want to define redirection. The Redirection Table Update window
appears
3.
Set the parameters.
Parameter
Description
Farm Name
Name of farm for which redirection is configured. Read-only parameter.
DNS Redirection
Enables the DNS redirection method.

Based on the DNS mechanism. When a client sends a DNS query to
find an IP address of requested service host name, AppDirector
operates as a DNS server.
DNS Response TLL
Number of seconds in which DNS responses are cached.

Default: 0
HTTP Redirection
Enables HTTP redirection method and is used to redirect HTTP traffic.

Values:
Disabled (default)
Moved Permanently
RFC Moved Temporarily
326

Parameter
Redirect To HTTPS
Description
Enables the HTTPS redirection method.
Values:
Disabled
Enabled (default)- both HTTP and HTTPS traffic that arrives at this
farm will be redirected to HTTPS, in case redirection is necessary.
HTTPS only - only HTTPS is redirected (HTTP is not redirected to
HTTPS).
RTSP Redirection
Enables the RTSP redirection method where AppDirector can redirect

RTSP sessions to a remote site.
Default: Disabled
SIP Redirection
Enables the SIP redirection method.

Default: Disabled
AppDirector can redirect Session Initiation Protocol (SIP) sessions
(UDP) using the redirection option (302) within the SIP protocol.
Global Triangulation
Enables the Global Triangulation method.

Default: Disabled
Global Triangulation uses a Radware proprietary scheme to redirect
traffic to a remote AppDirector.
Proxy Redirection
(Client NAT)
Enables the Proxy redirection method.

Default: Disabled
This method uses Client NAT to redirect traffic to another server or site.
When selected, the Client NAT ranges must also be configured.
Redirect By Name
Server's Redirect To parameter is used as the host name to which

redirect is performed (for HTTP/HTTPS/RTSP/SIP). Or you can use the
server IP.
Farm Distribution
Threshold
Local load balancing is performed between local servers until the farm
reaches the Distribution Threshold limit. Then the distribution
algorithm allows AppDirector to redirect users to other servers.
Default: 2,500
Farm Capacity
Threshold
Maximum number of connections that farm's local servers may accept.

When this threshold is reached, LRP reports from the farm inform you
that no more redirects can be accepted from distributed AppDirectors.
Default: 5,000
Static Proximity
Entries
Number of entries in Static Proximity Table. If you configure more

entries than memory allows, AppDirector prints a message to the
terminal and writes it to the log file.
User defined Static Proximity table displays proximity subnets per
farm. Each table row displays the accompanying farm and a range of IP
addresses.
Values: 1 - 5000
Default: 500
327

Parameter
Description
Application
Redirection Mode
Defines whether DNS redirection is:

only redirection method for this farm
primary method: backup redirection methods can be configured
where the application request (after DNS resolution) reaches a site
where there are no servers available
one of the farm redirection methods.
The following values are available:
Disabled (Default): Farm can only use DNS redirection.
Enabled: Application redirection is performed using redirection
methods enabled for this farm.
DNS Fallback Redirection: Application redirection is used only if
DNS Redirection is enabled and availability problems exist. The
method used depends on methods enabled for this farm.
4.
Click Set. The Redirection Table Update window closes and the new parameters appear in the
Redirection Table window.
Anycast Advertise
Anycast is the process that allows a single IP address to be announced from multiple locations. Its a
simulation of a situation where a routing domain may have multiple routes that lead to a certain
destination. Such an application is useful if a service is required globally, and there are multiple
service points that should be totally transparent to the user.
Once a packet has the Anycast address as a destination, the routing domain will control the flow of
that packet towards one of the destinations.
A global system may use the Anycast to announce multiple service points. There are two types of
Anycast service:
Global Anycast: The global Anycast addresses are equally announced from multiple locations
allowing users to connect to these points concurrently. The routing logic creates the load
distribution between the different service points. This type of Anycast is suitable for stateless
applications only, such as DNS. This type of Anycast can be used to select the DNS resolver in a
global solution.
Local Anycast: The local Anycast addresses are not concurrently active in more than a single
primary site. Secondary sites use these addresses only to provide a transparent backup to the
primary site. For the routing logic there should be a single location that serves each IP address.
This type of Anycast is suitable for all protocols as long as the primary site is active persistency
is maintained.
To create an entry in the Anycast Advertise Table

1.
From the AppDirector menu, select Distributed System > Anycast Advertise Table. The
Anycast Advertise Table window appears.
2.
Click Create. The Anycast Advertise Table Create window appears.
328

Parameter
Description
Layer 4 Policy Name
Name that provides AppDirector with information on the IP that must

be advertised (Layer 4 Policy VIP).
The value that appears in this field depends on the type of the Layer 4
policy, whether this is a Virtual IP Interface (VIPI) or not and if not
what is the farm on whose status the advertisement depends:
Note: The advertisement does not depend on farm status (it depends
on device status up/down)
Host Route Metric
VIP Advertisement via Dynamic Routing is used to advertise a Farm's

VIP or any other configured IP address via RIP or OSPF. You can
configure the route metric to be used when adding the route to the
routing table. This can be used when two devices are used on different
sites for site redundancy.
When the main site is available, the device adds the VIP to the routing
table with the configured metric, then removes the entry from the
routing table when the servers are unavailable. When the farms in both
sites are available, clients are routed to the selected device based on
the route metric. Enter the required metric value.
Default: 1
Advertised VIP Farm

Name
Name of farm on whose availability this advertisement is made. Layer 4

Policy VIP is only advertised if this farm is available. If Layer 4 policy
Application is set to Virtual IP Interface, this field is obsolete.
Default: None
External NAT IP
If AppDirector is installed behind a NAT device, the advertised IP must

be not the VIP, but rather its public (NAT) address. When a NAT address
is defined in the relevant entry, AppDirector responds with the External
NAT IP Address.
329

330

Configuring Health Monitoring
Chapter 5 Configuring Health Monitoring

This chapter describes the Health Monitoring module, a component of the Radware APSolute OS
architecture and includes the following sections:
Health Checks, page 332
AppDirector Farm Connectivity Checks, page 353
The Health Monitoring module implemented on Radware IAS (Intelligent Application Switching)
products is responsible for checking the health of network elements like servers, firewalls, and Next
Hop Routers (NHRs) that are managed by the IAS device. It determines which network elements are
available for service, enabling the IAS device to load balance traffic among the available resources.
Traffic management decisions are based mainly on the availability of the load-balanced elements
and other resources on the data path. The module provides flexible configuration for health
monitoring of the load-balanced elements. The module supports various predefined and userdefined checks, and enables the creation of dependencies between Health Checks of different
elements.
The Health Monitoring module enables users to track the round-trip time of Health Checks. The
device keeps a Response Level indicator for each check. The Response Level is the average ratio
between the response time and the configured Timeout. The average is calculated based on the
number of samples defined in the Response Level Samples parameters in the Global window. Setting
the Response Level Samples to 0 disables the parameters; any other value between 1-9 defines the
number of samples.
Checked Element
A Checked Element is a network element that is managed and load balanced by the Radware device.
For example, AppDirector-checked elements include the Farm Servers, NHRs, and LRP and PRP
reports.
The health of a Checked Element may depend on a network element that the IAS device does not
load balance. For example, the health of a server managed by AppDirector may depend on the
health of a database server, or other application servers, which are not load balanced by the
AppDirector, or the health of a Next Hop Router managed by LinkProof may depend on the
availability of the service provider.
Health Check
A Health Check defines how to test the health of any network element (not necessarily a Checked
Element). A check configuration includes such parameters as the Check Method, the TCP/UDP port
to which the test is sent, the time interval for the test, its timeout, the number of retries, and more.
These parameters are explained in detail in the Health Checks section. A network element can be
tested using one or more Health Checks.
Health Monitoring Global Parameters

The Health Monitoring module enables extensive health monitoring of all network devices, for
example, server farms. The module enables the device to optimize load balancing by making sure
which network elements are available and active. The Health Monitoring menu's Global Parameters
window allows you to configure the Health Monitoring mode.
331

To configure Health Monitoring Global Parameters

1.
From the Health Monitoring menu select Global Parameters. The Health Monitoring Global
2.
Set the parameters.
Parameter
Description
Health Monitoring
Determines whether to use the Health Monitoring module or the

device's connectivity checks.
Default: Disabled
Response Level
Samples
Number of Response Level samples serving as basis for calculating

average Response Level. The device keeps a Response Level indicator
for each check. This is the average ratio between response time and
configured Timeout.
Default: 0
Notes:
A value of 0 disables this parameter and no sample is taken.
Any other value between 1 - 9 defines the number of samples.
SSL Certificate Entry

Name
This is used by the device when the Web server requires a client
certificate during the SSL handshake.
Default: Client certificate generated by the device.
3.
Note: SSL certificate file and SSL private keys are not exported as part of the device
configuration export.
Health Checks
This section discusses Health Checks and contains the following topics:
Group Health Checks, page 333
Single Health Checks, page 333
Health Checks Per Farm, page 333
Binding, page 347
Packet Sequence Table, page 348
Server Table, page 349
Diameter Argument List and Additional Method Arguments, page 350
Uploading, Downloading and Deleting the Diameter File using Binary File Transfer, page 352
User Defined Methods, page 352
You can add or edit health check parameters in the Check Table. The Check Table lists the
configured Health Checks. If a check is not bound to any of the Checked Elements, it is still
performed. If it fails, the device sends notification messages (SNMP Traps, Syslog messages or mail
messages), indicating the failure of the check.
332

Quantity of Health Checks

There is no radware recommended number of heath checks as this depends on many variables. For
example:
Frequency of checks (interval)
Timeout for each check
Load on the device (without Health Monitoring running)
Other generic applications configured to run
For example, having 5000 checks with a large interval of two days could perform better than 200
checks with in interval of 2 seconds.
Group Health Checks

Using group health checks enables the creation of complex health conditions for the Checked
Elements. For instance, consider a Web server that communicates with one of two database servers
and uses one of two routers to provide service. This Web server is bound using three different
binding groups: one group contains Health Checks for the two routers (each check is NonMandatory), another group contains Health Checks for the database servers (each check is NonMandatory), and the third group contains the Health Checks for the Web server. As long as one of
the database servers and one of the routers is active, and the Web server Health Check passes, the
Web server is considered active. Otherwise, the Health Monitoring module determines that the Web
server is unable to provide the required service.
You can also configure groups of health checks. Health Check Binding can also be grouped for
complex conditioning of tests, using the logical conditions AND/OR.
Single Health Checks

You can add or edit health check parameters in the Check Table. The Check Table lists the
configured Health Checks.
Health Checks Per Farm

Used in large configurations with farms containing multiple servers, the Farm-Oriented Health Check
automates and simplifies the Health Monitoring configuration process by replicating a defined check
for all servers in a farm. Health Check Binding can also be grouped for complex conditioning of tests,
using the logical conditions AND/OR.
Health Monitoring Check Table

The Checks Table window contains user-configurable checks, based on the Health Check Methods.
To create/update an entry in the Checks Table:

1. From the Health Monitoring menu select Checks Table. The Health Monitoring Check Table
window appears.
2. Click Create/Update. The Checks Table Create/Update window appears.
Parameter
Description
Check Name
User defined name of health check.
Check Method (pre-defined methods used to configure a health check)
333

Parameter
Description
ARP
A reading of the unit ARP cache for the 2 most recently acquired entries.
One at a time, the device sends ARP requests to these machines,
attempting to stimulate network traffic. After each request, the device
counts all received traffic for up to 5 seconds.
If traffic is received, the interface is considered operational. If no traffic is
received, an ARP request is sent to the next machine. If at the end of the
list, no traffic has been received, the ping test begins.
Citrix Application
Browsing
The module sends a "Hello" request to the Citrix server which responds
by sending the list of applications running on it. Based on this reply, the
module compares the applications available on the server with a list of up
to four applications configured by the user.
If all configured applications are running on the Citrix server, the check
passes. If none are running, the module completes the handshake. This
check uses UDP port 1604 by default.
Arguments: e.g. application names.
Citrix ICA
The module initiates a connection to the Citrix server, using TCP port
1494 and performs a Citrix handshake. This check passes when the
Health Monitoring module identifies the Citrix's reply within the first reply
packet.
DHCP
The Dynamic Host Configuration Protocol allows the automatic

configuration of individual hosts in a network. When a new client
connects to the network for the first time, the DHCP servers assign the
client its IP address, Subnet Mask, Default Gateway and other
parameters. Using the DHCP health check, the device sends a
DHCPDISCOVER to the DHCP server.
No Arguments
The DHCPDISCOVER is sent to the MAC address of the configured server,

based on the Destination Host field. After sending the DHCPDISCOVER,
the device sends a DHCPREQUEST to the server. Once the server replies,
the device sends a DHCERELEASE command to the DHCP server.
Arguments:
IP Address: Non-mandatory parameters. When configured, it can
either accept an individual IP Address or a Network Address. When
the DHCP server replies to the health check, AppDirector compares
the server's reply with the configured value. If the server replies with
a different IP address or a different address range than the
configured value, the check fails.
Subnet Mask: This is mandatory only if the IP Address field is
configured. The Subnet Mask refers to the IP Address and allows
configuring either to an individual client (using 255.255.255.255) or
any other subnet mask.
Default Gateway: Non-mandatory parameters. When configured,
the device compares the server's reply with the configured value. If
the server replies with a different IP address, the check fails.
DNS Server: Non-mandatory parameters. When this is configured,
the device compares the server's reply with the configured value. If
the server replies with a different IP address, the check fails.
WINS Server: Non-mandatory parameters. When configured, the
device compares the server's reply with the configured value. If the
server replies with a different IP address than the configured value,
the check fails.
334

Parameter
Description
DHCP (continued)
Domain: Non-mandatory parameters. When configured, the device

compares the server's reply with the configured value. When the
server replies with a different value, the check fails.
MAC Address: Non-mandatory parameters. When configured, the
device uses the configured MAC address as the MAC address within
the DHCP packet (and not as the Source MAC address in the packet's
header). By default, the device uses its base MAC address. When
this is configured, the device uses the configured MAC address in the
DHCP data and not in the DHCP headers.
Relay Agent: Non-mandatory parameters. When this is configured,
the device uses the configured address as the GIADDR field in the
DHCP data. This field can accept only IP addresses which are IP
interfaces of the device and virtual interfaces. When no field is
configured, the device sends the DHCP request to the server and
passes the check when the server replies with any IP address.
Diameter
To check Diameter application availability, the Diameter health check

initiates a connection to the Diameter server. The module performs a
Diameter handshake (CER/CEA) and sends an LIR message or another
application message.
Then the Diameter connection is disconnected using the DPR or the DPA
message. The check passes when the accepted result codes are received
from the Diameter server. The Diameter server defines various Attribute
Value Pairs (AVP) and expected attribute values in the response received
from the Diameter server.
Arguments: Diameter Argument List Name
For details on the Diameter Argument list, see Diameter Argument List
and Additional Method Arguments, page 350.
DNS
The module submits a DNS query to the configured Destination address

and host. The module verifies that the reply is received with no errors,
and that the reply matches a specific address (if specified).
If the IP address parameter is not defined, only the return code of the
reply is validated (not the IP address it contains).
Arguments: Hostname; Host Address
FIX
The module creates a FIX packet and sends it to the FIX server (after the
TCP handshake). A successful check is where the value of TestReqID in
the reply packet is the same as the one configured; the "SenderCompID"
is the configured value of the "TargetCompID" field, and vice versa; and
the FIX version is the same as the configured value.
Arguments: TestReqID; SenderCompID; TargetCompID; FIX Version.
Note: Since the TestReqID parameter is non-mandatory, the default is
the number of seconds since 01/01/1970.
FTP
The module executes USER and PASS commands on the FTP server.
When the login process is successfully completed, the module executes a
SYST command.
It can verify the existence of the file on the FTP server, but it does not
download the file or check its size. The module verifies that all the
commands are executed successfully, then terminates the connection.
Arguments: Username; Password; Filename.
Note: The module uses a control session only, not a data session,
unless it is necessary to verify the existence of a file.
335

Parameter
Description
HTTP
The module submits an HTTP request to the Destination IP address. In

addition, you can define a specific URL to test. The request can be a GET,
POST, or HEAD request.
Requests can be in a proxy format or a Web format, and can include a
no-cache directive. By default, the module verifies that the returned
status is 200. If the checked server is password protected, the module
may send an authorized name and user password. The module sends the
HTTP request in HTTP 1.0 format.
Arguments: Host name; path; HTTP Header, HTTP method; HTTP format
(proxy/Web); use of no-cache; text for search within a HTTP header and
body, and an indication whether the text appears or not; Username and
Password for basic authentication; NTLM authentication option; and up to
four valid HTTP return codes.
HTTPS
The module performs an SSL handshake opposite the server. After the
session starts, the device sends a GET request from the Checked
Element.
Arguments: HTTP Header, HTTPS Method; Username; Password; Match
Search String; Match Mode; HTTPS Return Codes.
Note: Radware recommends to use interval values > 15 seconds and
timeout values > 10 seconds.
IMAP4
The module executes a LOGIN command to the IMAP server, and verifies
that the returned code is OK.
Arguments: Username; Password.
LDAP
The Health Monitoring module enhances the Health Checks for LDAP
servers by allowing performing searches in the LDAP server. Before
Health Monitoring performs the search, it issues a Bind request command
to the LDAP server.
After performing the search, it closes the connection with the Unbind
command. A successful search receives an answer from the server that
includes a "searchResultEntry" message. An unsuccessful search receives
an answer that only includes only a "searchResultDone" message.
Arguments:
Username: A user with privileges to search the LDAP server.
Password: The password of the user.
Base Object: The location in the directory from which the LDAP
search begins.
Attribute Name: The attribute to look for. For example, CN Common Name.
Search Value: The value to search for.
Search scope: baseObject, singleLevel, wholeSubtree
Search Deref Aliases: neverDerefAliases, dereflnSearching,
derefFindingBaseObj, derefAlways
336

Parameter
Description
LDAPS
The Health Monitoring module enables LDAP Health Checks to be

performed over the SSL transport layer.
When using the LDAPS checks, it is recommended to set values greater
than 15 seconds for the time interval and 10 seconds for the timeout.
Arguments:
User: A user with privileges to search the LDAPS server.
Password: The password of the user.
Base Object: The location in the directory from which the LDAP
search begins.
Attribute Name: The attribute to look for. For example CN - Common
Name.
Search Value: The value to search for.
Search scope: baseObject, singleLevel, wholeSubtree
Search Deref Aliases: neverDerefAliases, dereflnSearching,
derefFindingBaseObj, derefAlways.
NNTP
The module executes a LIST command and verifies that the returned
status is valid.
No Arguments
Physical Port
The module checks the physical interface status. When the link is up, the
check passes.
Arguments: Physical port number.
Ping
The module sends an ICMP echo request to the Destination address and
waits for an echo reply.
The module checks that the reply was received from the Destination
address to which that the request was sent, and that the sequence
number is correct.
Arguments: Fail; Ping Data Size.
Fail: Whether the reply is received or not, by default, the check fails
when the server does not reply.
Ping Data Size: The size of the ICMP echo request (1 byte to 1024
bytes). The default is 64 bytes.
POP3
The module executes USER and PASS commands on POP3 server, and
checks that the returned code is OK.
Arguments: Username; Password.
RADIUS
Authentication
The module sends an Access Request with a User Name, Password and a
Secret string, and verifies that the request was accepted by the server,
which then expects an Access Accept reply.
Arguments: Username; Password; Secret.
Note: Ensure that the RADIUS server is configured to accept RADIUS
requests from the Radware device.
337

Parameter
Description
RADIUS Accounting
The module sends a Radius Accounting Request with a User Name,

Password and Secret string, and verifies that the request was accepted
by the server which then expects an Access Accept reply.
Arguments: Username; Password; Secret.
Notes:
Ensure that the RADIUS server is configured to accept RADIUS
requests from the Radware device.
If the Destination Port Number is not configured then the device
uses UDP port 1813.
RTSP
The module executes a DESCRIBE command and expects a return status

of 200.
Arguments: Hostname; Path (on the server)
SIP UDP/ SIP TCP
The Health Monitoring module allows users to perform Health Monitoring

checks on SIP servers. The SIP Health Check is done using the Options
method.
This method is used to query SIP proxies and end-points as to their
capabilities. The capabilities themselves are not relevant to the Health
Check, but what is relevant, is the "200 OK" response from the server.
Arguments:
Request URI: The requests destination.
From: The logical name of the device.
Peer From:Can be configured on the slave device where there is a
CDE setup.
Max Forward: The default is 1.
Match search string.
Match mode.
SIP Return code.
SMTP
The module executes a HELLO command to the SMTP server and checks
that the returned code is 250.
Arguments: HELO
SNMP
The module sends an SNMP GET request, and validates the value in the
reply. When the returned value is lower than the minimum range
expected or higher than the maximum range expected, the check fails.
When the returned value is higher than the No New Sessions Value, the
bound element is set to No New Sessions. The results of the SNMP
Check can be used for a load-balancing decision, similar to Private Load
Balancing Algorithms.
Arguments: SNMP Object ID to be checked; Community; Min. Value;
Max. Value; No New Sessions Value; Use Results For Load Balancing.
Notes:
For a device to consider the outcome of the check in the load
balancing decisions, set the farms Dispatch Method to Response
Time.
The SNMP health check supports Integer, Counter and Gauge values.
While Integer can be a negative value, Counter and Gauge must
always be greater than 0.
338

Parameter
Description
SSL Hello
The module sends an SSL Hello packet to the server (using SSL3), and
waits for an SSL Hello reply. The session is then closed (using a RESET
command).
Note: Since generating SSL keys on the server is a time consuming
process, it is recommended to use a timeout of 3 to 5 seconds.
Arguments: SSL Version, can be either V2.3 or V3.0. SSL v3.0 means
that pure SSL v3 is used. SSL v2.3 means that the client sends an SSL v2
request to open a SSL v3 session (Internet Explorer operates this way).
Default: SSL v2.3
TCP Port
The module checks the availability of the specified TCP port.

Arguments:
Complete TCP Handshake: Sets whether an ACK packet is sent
before the RST packet. Setting this parameter to Yes results in the
following TCP handshake flow: SYN, SYN_ACK, ACK, RST. Setting
this parameter to No results in the following TCP handshake flow:
SYN, SYN_ACK, RST.
Complete with Fin.
TCP User-Defined
The module uses a user-defined TCP Health Check.

Arguments: Sequence ID (the user-defined check).
TFTP
The module checks the availability of TFTP servers. The check opens
TFTP connection to the tested server and starts downloading the
configured file. Once the first block is received, the check is considered
successful and connection is disconnected.
Arguments: File Full Path
UDP User Defined
The module uses a user-defined UDP Health Check.

Arguments: Sequence ID (the user-defined check).
UDP Port
This checks availability of the specified UDP port. It does not test the
server's availability, but the application's availability within the server.
This is due to the nature of UDP.
When the UDP application is operational, no reply is received; when the
UDP application is not operational, an ICMP message UDP Port
Unreachable is sent. No reply indicates the applications availability, so
when the server is down, the application might still be considered as
running. Therefore, the UDP Port check is always used with another
server availability check like Ping or ARP.
No Arguments
Destination Host
(Mandatory)
Destination IP address or hostname of network server to be checked. The

destination host can also accept hostnames and not only ip addresses.
Next Hop
IP address of the next hop on the network for this check. This is needed
to direct the health check session to a network element's MAC address.
Destination Port
The destination's TCP\UDP port number.

Arguments:
The additional argument for the relevant health check method. Possible
arguments are based on the Method, and may be one, or a combination
of, the following:
The arguments are entered in the following format: Argument1=value1|
Argument2=Value2. For example, the following is an argument for a FTP
check: USER=JohnSmith| PASS=ABC
339

Parameter
Description
Arguments
Depending on the Check Method that you select, a separate Arguments

window appears listing the associated arguments for this method.
Enter name of your argument and click Set. The argument is set for the
Health Check Method and you are returned to the Health Monitoring
Check Table window.
Interval
This interval defines the health checks execution interval in seconds.

This field accepts only integers, and its value must be greater than the
timeout value. Maximum value: 2^32-1 seconds.
Retries
Number of times that a health check must fail before the Health
Monitoring module reevaluates the elements availability status.
Note: This field accepts only integers.
Timeout
Maximum number of seconds that the device waits for response to the
Health Check. This field accepts only integers. Maximum value: 2^32-2
seconds.
No New Session
Timeout
Amount of time to pass, since initiating a check, until AppDirector

recognizes this element as heavily loaded and does not send any new
sessions to it.
Measure Response
Time
Determines whether the response time of the check is being used for
load balancing decisions. Applicable only when Dispatch Method is set to
Response Time LB. The Response Time is measured in milliseconds.
Default: Disabled
Also see Dispatch Methods, page 177.
Note: There are several parameters that must be configured in health
monitoring, for the Response Time Dispatch method or all
traffic will be directed only to first server.
1. Configure Health monitoring -->Global Parameters -->Health
Monitoring Status - to Enable
2. Configure Health monitoring -->Global Parameters --> Response
Level Samples - to non zero value
3. Create Health Monitoring --> Check Table and configure Measure
Response Time - to Enable for All servers in
the farm
4. Create Health Monitoring --> Binding Table for All servers in the farm
Reverse Check
Result
Indicates whether the check fails when reply is received according to the
check arguments or the check passes when no reply received.
Default: Disable (the check fails when the server does not reply).
Table 5 - Predefined Health Check Methods, page 341 describes the predefined Health Check
Methods with the configurable parameters.
4.
340

This table lists the additional configurable method arguments for each Check Method, and details
mandatory arguments, default values, and more.
Table 5: Predefined Health Check Methods
Method
Name (and
ID)
Argument
Name
ARP
No arguments
Citrix
Application 1
Application 2
Argument Description Mandatory
for Application
browsing
Additional Info
Default
No
Application 3
Application 4
Citrix ICA
No arguments
DHCP
IP Address
Subnet Mask
255.255.255.255
Default
Gateway
DNS Server
WINS Server
Domain
MAC Address
Relay Agent
Diameter
Diameter
Argument List
Name
DNS
Hostname
Host name to query.
Yes
Host Address
Address to be
received.
No
Username
Username.
Yes
Password
Password.
Yes
Filename
The file to search on

the FTP server.
No
FIX
Validate
only the
DNS return
code.
TESTREQID
SENDERCOMP
ID
TARGETCOMPI
D
FIX Version
FTP
341

Method
Name (and
ID)
HTTP
Argument
Name
Path
Path of file on Web

server to be
requested.
No
Hostname
Host name.
No
HTTP Method
HTTP method to
submit.
No
Additional Info
Default
Any configured
value must begin
with a/.
GET,
GET
POST
HEAD
Proxy HTTP
Use proxy HTTP.
No
Yes = Use
proxy HTTP,
No
No = Use
Web server
HTTP.
Pragma
Nocache
Use pragma: nocache.
No
Yes= Use
pragma: nocache,
No
N0=Do not
use pragma:
no-cache.
Authentication Authentication Type
Type
No
Username
Username for basic

authentication.
No
Password
Password for basic

authentication.
No
Match Search
string
Content match pattern No

is either present or
absent.
Basic, NTLM
BASIC
Yes =Fail
check if
pattern not
found
Yes
No =Fail
check if
pattern is
found.
Match Mode
Pattern for content

match.
No
String exists
String is
absent
Wildcards not
supported.
342
HTTP Return
Code
Valid http code 1
No
HTTP Return
Code
Valid http code 2
No
HTTP Return
Code
Valid http code 3
No
HTTP Return
Code
Valid http code 4
No

Method
Name (and
ID)
Argument
Name
Additional Info
Default
HTTP Header
Name
HTTP Header
Value
HTTPS
HTTPS Method HTTPS method to

submit.
No
GET,
GET
POST
HEAD
Username
Username for basic

authentication.
No
Password
Password for basic

authentication.
No
Match Search
string
Content match pattern No

is either present or
absent.
Yes =Fail
check if
pattern not
found
Yes
No =Fail
check if
pattern is
found.
Match Mode
Pattern for content

match.
No
String exists
String is
absent
Wildcards not
supported.
IMAP4
HTTPS Return Valid https code 1

Code
No

Code
No

Code
No

Code
No
Username
Username
Yes
Password
Password
Yes
343

Method
Name (and
ID)
LDAP
Argument
Name
Username
Username
Password
Password
Base Object
Location in directory
from which the search
starts.
Attribute
name
The attribute to look

for. For example, CN Common Name.
Search value
The value to search
Search Scope
baseObject
No
Additional Info
Default
If you configure
Base, then
Attribute is
mandatory.
No
singleLevel
wholeSubtree
Search Deref
Aliases
neverDerefAliases
dereflnSearching
derefFindingBaseOb
j
derefAlways
LDAPS
Username
Username
Password
Password
Base Object
Location in directory
from which the search
starts.
Attribute
name
The attribute to look

for. For example, CN Common Name.
Search value
The value to search
Search Scope
baseObject
No
If you configure
Base, then
Attribute is
mandatory.
No
singleLevel
wholeSubtree
Search Deref
Aliases
neverDerefAliases
dereflnSearching
derefFindingBaseOb
j
derefAlways
NNTP
No arguments
Physical
Port
Port Number
344
Physical port number.
Yes

Method
Name (and
ID)
PING
Argument
Name
Fail
Check fails when reply No

is received or not
received.
Ping Data Size Packet size
No
Username
Username
Yes
Password
Password
No
Username
Username
Yes
Password
Password
Yes
Secret
Radius Secret
No
Radius
Username
Authenticatio
Password
n
Secret
Username
Yes
Password
Yes
Radius Secret
No
RTSP
Hostname
Host name to use in

request.
No
Path
Path of file on RTSP

server to be
requested.
Yes
POP
Radius
Accounting
SIP TCP
Additional Info
Yes = Fail when

server replies,
Default
No
No =Fail when
server does not
reply.
=1 - 1024 bytes
IP address of
server.
Request URI
From
Peer From
Max Forward
Match search
string
Match mode
SIP return
code
SIP return
code
SIP return
code
SIP return
code
345

Method
Name (and
ID)
SIP UDP
Argument
Name
Additional Info
Default
Request URI
From
Peer From
Max Forward
Match search
string
Match mode
SIP return
code
SIP return
code
SIP return
code
SIP return
code
SMTP
HELO
At the start of all SMTP

transactions, the
calling machine
identifies itself, literally
by saying "HELO" with
its computer name.
SNMP
OID
Object ID to be used
by the check.
Yes
Community
The community used

by the device.
Yes
Min. value
Minimum value for

Yes
check to pass. If the
minimum is lower than
the configured value,
the check fails.
Max value
Maximum value for

check to pass. If the
maximum is higher
than the configured
value, the check fails.
No New
Sessions
value
The value between the Yes

NNS and the max. If
the value falls between
these two numbers,
then the Checked
Element is in No New
Session mode.
Use Results
For Load
Balancing
The measured
response time for the
check.
346
Yes
Yes
No
No

Method
Name (and
ID)
SSL Hello
Argument
Name
SSL Version
v2.3 or v3.0.
Yes
Additional Info
V2.3 or V3.0
Default
v2.3
SSL v3.0 means pure

SSLv3 is used.
SSLv2.3 means that
the client sends an
SSLv2 request to open
an SSLv3 session (this
is how Internet
Explorer works, for
example).
TCP Port (1)
Complete TCP Sets whether check

No
Handshake
sends ACK packet
before the RST packet.
Yes
Complete with When enabled, the

FIN
device ends the TCP
check with a FIN
Packet.
Yes
TCP UserDefined (8)
Sequence ID
TFTP
File Full Path
UDP Port (9)
No arguments
UDP User
Defined
Sequence ID
Packet sequence to
submit.
Yes
Packet sequence to
submit.
Yes
Binding
Using the health checks, you can associate, or bind, a health check with a checked element. You can
also define whether the check is mandatory and set the group number.
When several groups are associated with a single Checked Element, they are evaluated with a
logical AND between them. Non-Mandatory checks in a group are evaluated with a logical OR
between them, so that when there is more than one Non-Mandatory check in a group, a failure of
one check does not fail the server.
To bind a health check to a network element

1. From the Health Monitoring menu, select Binding Table. The Health Monitoring Binding Table
window appears.
2. Click Create. The Health Monitoring Binding Table Create window appears.
Parameter
Description
Check
The name of the health check as defined by the user in the Checks Table.
Server/NHR/Report The Health Monitoring module binds health checks to NHRs/Servers/LRP

and PRP reports, which determine the availability of those elements.
Select type of report/server/NHR to perform health monitoring checks.
347

Parameter
Group
Description
Group number to which check belongs.
allows you to combine different health checks with the same checked
element.
uses logical AND/OR depending on the Mandatory field.
Group number is only relevant for a given specific checked element.
Mandatory
Defines if Health Check is mandatory for Checked Elements health. The

Non- Mandatory status for checks within a group is equal to an OR
relationship between the Health Checks, while the Mandatory status is
equal to an AND condition.
Values: Mandatory (Default), Non-Mandatory.
When mixing Mandatory and Non-mandatory health check bindings, there
is a logical AND between the Mandatory & Non-Mandatory groups. This
means that if a Non-Mandatory health check binding fails a certain
element, even if all Mandatory bindings pass, the element will be reported
as Unavailable (Not In Service).
4.
Click Set. The specified health check is bound to the selected element.
Packet Sequence Table

The Packet Sequence Table window enables the user to define a packet sequence for a specific,
TCP\UDP, health check. The user defines a sequence of Send and Receive packets, containing a
configurable string. AppDirector then transmits the Send packets and verifies that the string in the
reply matches the string configured for the Receive packets.
Notes:
>> In order to define a packet, you need to add 0x before the packet itself; for example:
0x00016e69722e747874006f6374657400
>> In a regular expression, a hex string cannot be used.
To create a packet sequence

1.
From the Health Monitoring menu, select Packet Sequence Table. The Health Monitoring
Packet Sequence Table window appears.
2.
Click Create. The Health Monitoring Packet Sequence Table Create window appears.
348

Parameter
Description
Seq ID (Sequence ID) ID number of entire packet sequence. Each sequence defines a new
user-defined check. All packets with same Sequence ID belong to same
check.
Default: 0
PKT ID (Packet ID)
ID number of the specific packet within the sequence.

Default: 0
Note: The first Packet ID of each sequence must always be 0. Packet ID
numbers of a sequence must be consecutive.
Type
Type of packet.
Values: Send/Transmit (Default), or Receive.
String
Content of packet for verification process. This is the string that is

either sent within the packet or the string to match when the packet is
received. For Receive type packets, it can include a regular expression.
Description
Description of the specific packet in the sequence.
Compare Method
Used for comparing between content of received packet and content

configured in the String parameter.
The following possibilities are available:
Regular Expression (Default): String that matches a regular
expression rule.
Binary: The exact String that is matched when the packet is
received.
Server Table
This table is a read-only table and displays each server configured for the device, in the Application
Server Table, and its status.
To access the Server Table

1. From the Health Monitoring menu, select Server Table. The Health Monitoring Server Table
window appears.
2. Select the desired server, and the HM Server Table View Details window appears.
3. View these read-only parameters:
Parameter
Description
Server
Index number of the element attached by the AppDirector in the

Application Server Table
Description
Description of the network server, for example, Cache.
Farm Name
The name of the farm in which the server is included.
Availability Status
Availability status of the element, Available or Unavailable.
IP Address
IP address of the network server.
349

Parameter
Description
Response Level
Response Level is a normalized grade, given to the check, based on the

response times of each successful check over the configured Response
Level Sample rate and the configured timeout.
Uptime%
Ratio (in presents) of the number of the success checks and the total
number of checks (successful and failures).
Success Counter
The total number of successful checks.
Failure Counter
The total number of unsuccessful checks.
Diameter Argument List and Additional Method Arguments

You can configure additional arguments specific to each Health Check Method.
When using Web Based Management, CLI, Telnet or SSH, you can configure the additional
arguments using a string with this format:
ARG=VAL|ARG=VAL|.
Following each argument, the equal sign appears, then the required value. A | sign is used as a
delimiter between the arguments. No extra spaces are allowed.
The Diameter Argument Lists Configuration window allows you to configure additional arguments
specific to each Health Check Method.
To set the parameters of the Diameter Argument List

1.
From the Health Monitoring window, select Diameter > Arguments List. The Diameter
Argument Lists Configuration window appears.
2.
Click Create. The Diameter Argument Lists Configuration Create window appears.
3.
Set the parameters.
Parameter
Description
Argument List Name
The name that you define for this Argument List.
Description
The user defined description of this argument list.
Binary File Provided
Defines whether a user-defined message has been provided.

Values: Yes/No/Not Applicable
Origin-Host
Host name FQDN that identifies the end point that created the
Diameter message and is present in all Diameter messages.
Note: The Origin-Host AVP may resolve to more than one address.
Origin-Realm
Contains the realm of the originator of the Diameter message and is

present in all Diameter messages.
Vendor ID
Value assigned to vendor of Diameter application by IANA. Default is

the value identifying 3GPP.
Default: 0
Product-Name
350
The vendor assigned name for the product.

Parameter
Description
Application Message
Type
Defines the application message that is sent after the Diameter

connection is established.
Values:
LIR (default): AppDirector generates an LIR (Location Info Request)
message.
Binary File: Associate a binary file as the Diameter data for the health
check packet. The maximum size for the binary file is 1K.
None: No application message is sent.
Auth-Application-Id
The Auth-Application-Id AVP (AVP Code 258) is used to advertise

support of the Authentication and Authorization portion of an
application.
Default: 0
Auth-Session-State
Specifies which state is maintained for a particular session. The

following values are supported:
State Maintained (0) (default): Used to specify that a session state
is being maintained, and the access device must issue a session
termination message when service to the user is terminated.
No State Maintained (1): Used to specify that no session
termination messages is sent by the access device upon expiration
of the Authorization-Lifetime.
Destination-Realm
Contains realm (FQDN) to which message is routed.
Destination-Host
Host name of the destination Diameter server. Absence of the

Destination-Host AVP causes a message to be sent to any Diameter
server supporting the application within the realm specified in
Destination- Realm AVP. When no value is specified, this AVP is not
used. When set to 0.0.0.0 the value is taken from the Checked Element
IP.
Public Identity
Public identity of user referred to in LIR request.
Disconnect Cause
A Diameter node must include this AVP in the Disconnect-Peer-Request

message to inform the peer of the reason for its intention to shutdown
the transport connection. The following values are supported:
Rebooting (default): A scheduled reboot is imminent.
Busy: The peers internal resources are constrained, and it has
determined that the transport connection needs to be closed.
Do Not Want to Talk to You: The peer has decided to terminate the
transport connection since it does not expect any messages to be
exchanged in the near future.
Accepted Result Codes List of acceptable codes that can be received in a CEA, DPA and LIA
messages. These codes are separated by commas (,)or semi colons (;).
The default is 2001, 2002, 2003, 2004, 2005.
Diameter First Registration (2001)
Diameter Subsequent Registration (2002)
Diameter Unregistered Service (2003)
Diameter Success Server Name Not Served (2004)
Diameter Server Selection (2005)
351

Uploading, Downloading and Deleting the Diameter File using Binary File
Transfer
Binary File Transfer involves sending a file from one location to another in which all eight bits of the
byte are transmitted either intact or via some encoding scheme. The Diameter Binary File Transfer
window allows you to upload or download the diameter file to the device.
To upload the diameter file

1.
From the Health Monitoring menu, select Diameter > Binary File Transfer. The Diameter
Binary File Transfer window appears.
2.
To upload from the Upload Diameter File option, select the Diameter Argument List Name
from a drop-down list.
3.
Click Set. The file is uploaded.
To download the diameter file

1.
2.
To download from the Download Diameter File option, select the Diameter Argument List
Name from a drop-down list.
3.
Click Set. The file is downloaded.
Deleting the Diameter File

The Diameter Binary File Transfer window also allows you to delete the diameter file.
To delete the diameter file

1.
2.
To delete from the Delete Diameter File option, select the Diameter Argument List Name
from a drop-down list.
3.
Click Set. The file is deleted.
User Defined Methods

If you require a specific Health Check Method not provided by the module, you can configure the
Health Check protocol manually by defining a stream of send and receive packets for every packet
sequence, each with a string to send or receive. The module sends the packets, and verifies that the
received packets contain the predefined string. Packet sequences are defined in the Packet
Sequence Table. Once defined, the check can be used in Health Check configurations. User-defined
Checks are available for TCP checks only.
352

AppDirector Farm Connectivity Checks

This section describes additional options for server monitoring included in the Farm configuration
process and includes the following topics:
Ping Connectivity Method, page 353
TCP Port Connectivity Method, page 354
UDP Port Connectivity Method, page 354
HTTP Page Connectivity Method, page 354
Disabled Connectivity Method, page 355
To load balance traffic reaching an AppDirector farm, the farm servers must be checked. AppDirector
periodically checks server health. A successful check shows that the service is available on the
server. Failure to connect causes AppDirector to term the server unavailable although AppDirector
continues to check its availability and generates a Syslog, E-mail, SNMP or CLI trap to indicate that
the server is "Not In Service." AppDirector also monitors the server status in its farms ensuring that
they are available and can handle the request. You can perform a Health Check of the servers using
these methods:
Basic: Farm Connectivity Check.
Advanced: Health Monitoring module.
Notes:
>> You can use either Connectivity Checks or Health Monitoring Checks with Farms
regardless of the Health Monitoring Status. However, when both are used, one will
override the other, which means that if a Connectivity Check is set, it will override a
Health Monitoring Report.
>> If there is a need for a large number of concurrent checks, Radware recommends using
Health Monitoring instead of Connectivity checks.
This table describes parameters to configure the Connectivity Methods.
Parameter
Description
Connectivity Check Port Specific port where to conduct connectivity check. It can be TCP or UDP,
depending on Connectivity Method selected.
Note: When the Connectivity Method is HTTP Page, a TCP port is
checked.
Values: FTP, HTTP (default), SMTP, DNS, NNTP, HTTPS, RTSP, RADIUS, or
any port number you enter manually. For example, HTTP automatically
checks port 80.
Connectivity Interval
How often AppDirector polls the servers (secs).

Default: 10
Connectivity Retries
Number of polling attempts made before server is deemed inactive.

Default: 5
Ping Connectivity Method

AppDirector pings servers to verify valid communication. AppDirector performs this by sending an
ICMP echo request to the server. If a server is available, it sends an ICMP echo reply. When a Ping
fails, the server is down.
353

TCP Port Connectivity Method

When this method is selected, AppDirector attempts to connect to the specified application port by
completing the TCP three-way handshake, which includes the following steps:
1.
AppDirector initiates a request by sending a SYN packet.
2.
The server sends a SYN-ACK packet back to AppDirector.
3.
AppDirector sends a FIN-ACK packet to the server, completing the TCP 3 way handshake and
requesting to terminate the connection.
4.
The server replies with an ACK packet followed by a FIN-ACK packet.
5.
To close the connection, AppDirector sends an ACK packet to the server.
When connection between a server and AppDirector cannot be established, AppDirector

automatically sends connectivity checks every 3.5 seconds, regardless of Connectivity Interval
value. You can configure the Timeout for connectivity checks by setting the Timeout After TCP
Failure parameter. When this is enabled, AppDirector sends connectivity checks according to the
Connectivity Interval parameters in the farm configuration.
Note: Configurations established in the Advanced Settings window apply to all AppDirector
farms that use the TCP Port connectivity check method.
6.
To enable the user-defined timeout for the connectivity check specified in the Connectivity
Interval parameter (even after a TCP check failure), select Timeout After TCP Failure.
UDP Port Connectivity Method

When UDP Port Connectivity Method is selected, AppDirector attempts to connect to the specified
application port, according to the UDP protocol.
If the predefined port is not available, AppDirector receives a message Destination Unreachable. If
the port is available, no answer is sent. It is impossible to know whether the answer was not sent
because the server is available, or because the host computer is not working and is unable to send a
response of any kind. To get a clear indication as to whether the server is available or not,
AppDirector pings the server when no answer is received.
Note: A server is active only when no answer is received from the server during attempts to
connect using the UDP protocol, AND AppDirector receives a successful ping reply.
HTTP Page Connectivity Method

For HTTP Page checking, AppDirector periodically performs HTTP GETs for a predefined URL. If the
requested Web page is unavailable, the server is considered down. The URL is defined in the Home
Page parameters. You can define a Home Page URL that is up to 80 characters long.
The Retrieval Frequency saves unnecessary Web page requests by performing only periodical Web
page retrieval. The Web page is requested only once in a number of requests, according to the
predefined Retrieval Frequency. Otherwise, a simple TCP check occurs on port 80, or a user-defined
port.
AppDirector examines the HTTP header of the server response and considers responses with the
user-defined HTTP status code to indicate a healthy server. You can configure HTTP status codes to
be used as acceptable responses. By default, an HTTP code of 200 indicates that the service is
available.
354

AppDirector can examine the content of the returned Web page and check for the presence or
absence of a defined content string using the Content Checking for HTTP parameters. A string (up to
64 characters, case insensitive) can be defined per AppDirector farm.
When an AppDirector farm polls an HTTP page from a server, AppDirector issues the request to the
server in the format: GET /<home page>, meaning that the Home Page parameter is preceded by a
"/". The leading slash can cause problems, especially if an absolute URL is to be polled from the
server (e.g. http://www.site.com - as with a proxy server). To disable the leading slash, set the No
Slash After GET option for the Extended HTTP Check parameters.
When the HTTP request is sent, the Host name used by default in the request is the servers IP
address. You can change the Host name used in the HTTP request to the AppDirector farm name,
using the Extended Check Host Mode parameters.
Long URL Checks

When using the HTTP Farm Connectivity Check, URLs of more than 80 characters can be configured.
The Long Extended Check URL window allows you to enter and view Long URLs for an HTTP Farm
Connectivity Check. When using Configuration Download from the device, this configuration is not
sent as part of the configuration file. However, this configuration is saved in the compact flash and is
not erased when the device is reset
To enter a Long URL for an HTTP Farm Connectivity Check

1. From the AppDirector menu, select Farms > Long URL Check. The Long Extended Check URL
window appears.
Parameter
Description
Farm
Name of the required farm.
Long Extended Check URL
URL of more than 80 characters to be checked.
To view a Long URL for a specific HTTP Farm Connectivity Check

1. From the Long Extended Check URL window, select the required farm.
2. Click Get. The URL appears and can be edited.
Response Threshold
Using Farm connectivity checks with HTTP Page check, the Response Threshold parameter defines
the number of milliseconds the server has to reply to the GET command. When the server's reply
takes longer, the status of the logical server is set to No New Sessions. The default is 0.
Disabled Connectivity Method

Connectivity checking is disabled. If no farm connectivity checks are performed, AppDirector
considers all servers to be available by default. If farm connectivity checks were performed and then
the Connectivity Method becomes disabled, the status of the servers remains the same as it was the
moment the checks were disabled. If connectivity checks are disabled, and a server renews its
activity after a failure, this server is still regarded by the AppDirector as not available.
355

356

Classes and Bandwidth Management
Chapter 6 Classes and Bandwidth

Management
This describes Classes and Bandwidth Management and includes these sections:
Bandwidth Management Introduction, page 357
Bandwidth Management and Classifier Settings, page 361
Configuring Bandwidth Management, page 364
Services, page 374
Bandwidth Management Introduction

Bandwidth management, in general, is a simple concept. The idea is to be able to differentiate
orclassify user traffic according to a wide array of criteria and then assign various priorities to
eachclassified packet or session. For example, bandwidth management allows an administrator
togive HTTP traffic a higher priority over SMTP traffic, which in turn may have higher priority overFTP
traffic. A bandwidth management solution can also track the bandwidthused by each application and
set limits as to how much each classified traffic pattern can utilize. There are a variety of methods
used to enforce the bandwidth management policies configured by an administrator. The simplest
method would be to discard packets when certain thresholds are reached or when certain preallocated session buffers are overflowing. More complex mechanisms include TCP rate shaping and
priority based queuing.
TCP rate shaping uses the inherent flow control mechanisms of the TCP protocol. By adjusting
parameters in the packets TCP headers, a bandwidth management solution can signal the end
nodes to throttle the rate at which to transmit packets. Needless to say, the mechanism only works
with TCP sessions. TCP rate shaping also has some uncertainties associated with it, as the amount of
bandwidth associated with sessions can rarely be exactly enforced. Rate shaping also does not work
well with protocols that use short lived sessions (such as HTTP), since such sessions usually end
before the bandwidth manager has decided how to shape the rate of the session.
Priority based queuing is a means by which all classified packets are placed in packet queues,each
with its own preset priority. A number of queues are available and when it comes to traffic
forwarding, packets are forwarded from the higher priority queues first. This is an oversimplified
version of what really happens, but it presents the general concept. Various algorithms and safety
measures should be deployed to ensure methodical packet forwarding and protection against
starvation, where lower priority packets wait in queues for intolerably long amounts of time.
Radwares bandwidth management solution uses priority queues as the fundamental framework
behind its operation.
357

Radware Implementation of Bandwidth Management

Although the general concept of bandwidth management is simple, the complexity lies within the
implementation and the intricacies. The following diagram describes the general components and
tasks that make up Radwares bandwidth management mechanism.
Figure 16: Radwares Implementation of Bandwidth Management
The Bandwidth Management module includes a feature set that allows you to have full control over
the available bandwidth. Using these features, applications can be prioritized according to a wide
array of criteria, while taking the bandwidth used by each application into account. For example,
Bandwidth Management allows you to give HTTP traffic a higher priority than SMTP traffic, which in
turn, may have higher priority than FTP traffic. The Bandwidth Management solution can also track
the total bandwidth used by each application, ensuring a guaranteed bandwidth for certain
applications and setting limits for each classified traffic pattern.
AppDirectors Bandwidth Management capability allows you to define policies that restrict or
maintain the bandwidth that can be sent or received by each application, user, or segment.
Controlling the maximal bandwidth of corporate resources that DoS attacks can consume limits the
attack spread, ensuring that other mission critical operations continue to enjoy the bandwidth and
service level required to guarantee smooth business operation. Carriers can also ensure that a
customer's Service License Agreement (SLA) is not compromised due to a DoS attack launched by
another customer.
Using the Bandwidth Management module, Radware devices classify traffic according to pre-defined
criteria and enforce a set of actions on that traffic. A comprehensive set of user-configurable policies
controls how the device identifies and acts upon each packet.
There are 4 major components in the system: the classifier, the queues, the scheduler and the Policy
Database.
358

Classifier
The packet first flows into the system through the classifier. Its the classifiers duty to decide what
to do with the packet. A very comprehensive set of user-configurable policies that make up the
policy database control how the classifier identifies each packet and what it does with each packet.
When the classifier sees the packet, it can do one of three things:
Discards the packet - This allows the Bandwidth Management module to provide packet
filtering. If configured, a reset packet is sent to the server and/or the client.
Forwards the packet in real time - This means the packet bypasses the entire bandwidth
management system and is immediately forwarded by the device. The end result is effectively
the same as if bandwidth management was not enabled.
Prioritizes the packet - This allows the device to prioritize services.
How the classifier treats the packet is governed by the policy that best matches the packet. If the
classifier prioritizes the packet it places it into a queue, which. then gets a priority from 0-7, with 0
being the highest priority and 7 the lowest. Each policy gets its own queue. So, the number of
queues is equal to the number of policies in the policy database, but each queue is labeled with one
of the 8 priorities 0- 7. This means that there could be 100 queues (if there are 100 policies), with
each queue having a label from 0- 7.
Scheduler Algorithm
The scheduler takes packets from the queues and forwards them. The scheduler operates through
one of two algorithms: Cyclic and CBQ (Class Based Queuing).
With the Cyclic algorithm, the scheduler gives each priority a preference ratio of 2:1 over the
immediately adjacent lower priority. In other words, a 0 queue has twice the priority of a 1 queue,
which has twice the priority of a 2 queue, etc. The scheduler systematically goes through queues of
the same priority when it is time to forward a packet with this priority. The queues with the highest
priorities are emptied before lower priority queues. A ratio of 2:1 ensures that a queue is not
starved.
The CBQ algorithm has the same packet-forwarding pattern as the Cyclic algorithm, with one
significant difference. The CBQ algorithm is aware of a predefined bandwidth configured per policy.
Each policy can be configured with a guaranteed bandwidth and a maximum bandwidth (see
Guaranteed Bandwidth, page 362).
Application Classification
Application Classification is defined as Per Packet or Per Session. If it is defined as Per Packet, the
device classifies each packet that flows through it. In this mode, every packet must be individually
classified.
If the Application Classification is defined as Per Session, all packets are classified by session. An
intricate algorithm is used to classify all packets in a session until a best fit policy is found. Once
the session is classified, all packets belonging to the same session are given the same classification,
allowing the classifier to classify sessions rather than every single packet.
Classification Mode
The following classification modes are available:
Policies: The device classifies each packet or session by matching it to policies configured by
the user.
Diffserv: The device classifies packets only by the DSCP (Differentiated Services Code Point)
value.
ToS: The device classifies packets only by the ToS (Type of Service) bit value.
359

Bandwidth Borrowing
if the scheduler is operating through the CBQ algorithm, it can forward packets from queues,
considering the maximum bandwidth configured by that queues policy. If borrowing is enabled and
the scheduler visits a queue whose bandwidth has been exceeded (or is about to be exceeded), then
the scheduler will see if any other policy has left over bandwidth. If such a policy is found,
bandwidth is borrowed from that policy and allocated to the policy whose bandwidth limit was about
to be violated. This allows a scheduling scheme where available bandwidth can be used from other
queues, if the queue in question has exceeded its configured limit.
Borrowing can be enabled when the scheduler operates through the CBQ algorithm. If enabled, the
scheduler can borrow bandwidth from queues that can spare it, to forward packets from queues that
have exceeded (or are about to exceed) their allotted amount of bandwidth
Random Early Detection

The Random Early Detection (RED) algorithm is used to protect queues from overflowing. The
algorithm draws from the inherent retransmission and flow control characteristics of TCP.
When the RED algorithm is deployed, the status of the queues is monitored. When the queues
approach full capacity, random TCP packets are intercepted and dropped. TCP sends fewer packets
when packets are being dropped.
Radware's bandwidth management device deploys RED in two forms:
Global RED - Global RED monitors the capacity of all the queues (i.e., the global set of queues),
and randomly discards TCP packets before the classifier sees them.
Weighted RED (WRED) - The RED algorithm checks the priority of the queue (instead of all the
packets in the queues), before deciding whether or not packets get dropped.
Maximum Bandwidth
Each policy in the policy database can be configured with its own maximum allowed bandwidth.
Aside from per-policy configurations, the device can also be configured with a global bandwidth
limit. This is the bandwidth limit for the entire device, regardless of individual policy configurations.
This limit is the sum of per-physical-port maximum bandwidth configuration. Each physical port for
the device can be configured with its own maximum allotted bandwidth, the sum of which will make
up the global device bandwidth limit. Note that if borrowing is enabled, bandwidth can not be
borrowed beyond the configured maximum bandwidth.
360

Bandwidth Management and Classifier Settings

Bandwidth Management policy settings enable you to classify and manage traffic passing through
the Radware device.
A policy is a set of conditions (classification criteria) and the actions that apply as a consequence of
the conditions being satisfied. The policy database has two sections, active and inactive. The
temporary, or inactive, policy database contains policies that can be altered and configured without
affecting the current operation of the device. Changes to these policies are not effected until the
inactive database is activated. Activation updates the active policy database, which sorts the packets
that flow through it.
The second section of the Policy Database is the polices, by which the device classifies the traffic. To
activate the inactive database, administrators need to manually update the policiy database.
When the classifier classifies the traffic it scans the entire policy database until there is a match
between the packet/session to one of the policies. Once there is a match the classifier stops the
scan. Hence it is important to set the order of the policy according to the volume of the traffic, and
set the most common protocol first.
Default Policy - The last policy in the policy database is the default policy. All traffic that is not
matched by the user defined policy is matched by the default policy. By default, the default
policy forward traffic is assigned a priority 4.
Bandwidth Management Classification Criteria

A policy has two main functions:
To define how traffic should be classified to match the policy
To define which action is to be applied on the classified traffic
A policy includes the following traffic classification criteria:
Source: Defines the source of traffic. This can be a specific IP address or a network. A network
is a collection of ranges and/or subnets. Configure the networks; the default value is any,
covering traffic from any source.
Destination: Defines the destination of the traffic. Can be specific IPs, a range of IP addresses,
or IP subnet addresses. The default value is any, which covers traffic to any destination.
Note: To limit or block access to the device's interface, type the IP address of the interface in
the Destination box.
Direction: Defines traffic direction. Setting direction to "one way" enables asymmetric
Bandwidth Management. When a policy is set to "one way", the classifier searches for traffic in
one direction only and the device classifies only traffic in one direction; return traffic is not
classified. When a policy is set to "two way", the classifier searches for traffic in both directions
and the device replaces Source and Destination IP addresses and ports (if the policy is a Layer 4
or Layer 7) of the return traffic.
Service: Defines the traffic type. The Service configured per policy allows the policy to consider
other aspects of the packet, such as protocol (IP/TCP/UDP), TCP/UDP port numbers, bit patterns
at any offset in the packet, and content (such as URLs or Cookies) deep in the upper layers of
the packet. The default value is none, which covers all protocols.
Inbound Physical Port Group: Classifies only traffic received on physical interfaces of the
device. It enables you to set different policies on identical traffic classes received on different
interfaces of the device.
VLAN Tag Group: Defines VLAN traffic classification according to VLAN ID tags.
Traffic Flow Identification: Defines what type of traffic flow is limited via this policy. The
available options are:
361

Client (Source IP)
Session (Source IP and port)
Connection (Source IP and Destination IP)
Full Layer 4 Session (Source and Destination IP and port)
Session Cookie (must configure cookie identifier)
None (bandwidth is performed on the whole session)
Cookie Field Identifier (string that identifies the cookie field with the that value used to
determine the different traffic flows)
Note: This is required only when Traffic Flow Identification is set to SessionCookie. In such a
case, the BWM classifier searches for the Cookie Field Identifier followed by = and
classifies flows according to the value.
Classification Point: In the nature of Traffic Redirection and Load Balancing decisions, the
device has to modify packets when it forwards the packets to and from the servers. In
AppDirector for example, client's traffic is destined to the Layer 4 Policy VIP, but the AppDirector
makes a Load Balancing decision and forwards the packet to the selected server, it has to
change the destination IP address to the server's real IP address. On LinkProof, clients use their
own IP addresses and after LinkProof forwards the traffic to the NHR, it uses the SmartNAT and
changes the source IP address. Bandwidth Management allows administrators to select at which
point in the traffic flow the classification is performed: before modifying the packet or after the
modification.
Bandwidth Management Rules

Once traffic is classified and matched to a policy, Bandwidth Management rules are applied to the
policy.
Action
The action determines the access given to traffic. Possible values include:
Forward: The connection is accepted and traffic is forwarded to its destination. This is the
default value.
Block: All packets are dropped.
Block and Reset: All packets are dropped. In TCP traffic, an RST packet is sent to the client.
Block and Bi-directional Reset: All packets are dropped. In TCP traffic, an RST packet is sent
to both the client and the server.
Priority
If the action associated with the policy is forward, the packet is classified according to the
configured priority. There are nine options available; real time forwarding, and priorities 0 through
7.
Guaranteed Bandwidth
If the scheduler is configured to use the CBQ algorithm, the policy can be assigned a minimum
(guaranteed) bandwidth. The scheduler does not allow classified packets to exceed this allotted
bandwidth, unless borrowing is enabled. Note that the maximum bandwidth configured for the
entire device, as described above, overrides per-policy bandwidth configurations. In other words,
the sum of the guaranteed bandwidth for all the policies cannot be higher than the total device
bandwidth.
362

Maximum Limit
Borrowing can be enabled when the scheduler operates through the CBQ algorithm. If enabled, the
scheduler can borrow bandwidth from other queues, to forward packets from queues that have
exceeded, or are about to exceed, their allotted amount of bandwidth. Guaranteed Bandwidth and
Maximum Limit with the following values cause bandwidth allotted to a policy to act as follows:
Guaranteed
Bandwidth
Maximum
Bandwidth
Policy Bandwidth
No Minimum
No Minimum
Burstable with no limit, no minimum guaranteed.
No Minimum
Burstable with no limit, minimum of X guaranteed.
No Minimum
Burstable to Y, no minimum guaranteed.
Y (Y>X)
Burstable to Y, minimum of X guaranteed.
Non-burstable, X guaranteed.
Policy Group
You can define several bandwidth borrowing domains on a device by organizing policies in groups.
Bandwidth that is not utilized by a specific policy in a group is allocated proportionally to the other
policies. Allowing policies to borrow from each other prevents starvation and utilizes the bandwidth
more efficiently. Only policies within the same group can share bandwidth.
The total bandwidth available for a policy group is the sum of the Guaranteed Bandwidth values of
all the policies in the group. Also see Viewing Active Policy Groups, page 368.
Configuring a Policy Group Workflow

1. Set the Global BWM Dynamic Borrowing to Enable.
2. Define policy groups.
3. Define the device policies. Configure Guaranteed Bandwidth to the desired value and Maximum
Bandwidth to 0. The bandwidth limitation is ignored as the policies borrow unused bandwidth
from other policies in the group. Assign each policy to the relevant policy group.
4. Perform Update policies command.
Traffic Flow Max BW

Traffic flow is the path of traffic between network elements. This is the maximum bandwidth allowed
per traffic flow.
Max Concurrent Sessions

The maximum number of concurrent sessions allowed for a client IP.
Note: Not available when Traffic Flow Identification is set to Session or Full Layer 4 Session.
MAX Requests Per Second

When the Traffic Flow Max BW parameter is configured and the Traffic Flow Identification is set to
Session Cookie, the device tracks and limits the number of requests, such as HTTP GET, Post or
HEAD per Cookie.
363

Packet Marking
Packet Marking refers to Differentiated Services Code Point (DSCP) or Diffserv. It enables the device
to mark the matched packet with a range of bits.
Policy Index (Order)

The Policy Index, or order, is a number that determines the order of the policy in the policy
database. When the classifier receives a packet, it tries to find a policy that matches the packet. The
classifier searches the policy database starting with policy #1 and descending in order. The search
stops once a policy is matched. The last policy configured is the policy enforced on all packets that
do not match other policies; the default policy.
Activation/Inactivation Schedule
Some policies in a network remain inactive during specific hours of the day and are activated during
others. For example, an enterprise may give high priority to mail traffic between 08:00 - 10:00. You
can schedule the activation and inactivation of specific Bandwidth Management policies using the
Event Scheduler, which can then be attached to a policy's configurations. "Events" define the date
and time in which an action must be performed.
Configuring Bandwidth Management

You can configure the bandwidth for your device according to your needs by using Radware's Quality
of Service (QoS) tool. This enables you to classify user traffic according to a wide array of criteria,
then traffic is handled according to the matching policy. A Bandwidth Management solution can also
track the bandwidth used by each application and set limits as to how much bandwidth is used.
Note: Full functionality of the Bandwidth Management module is only available with a SynApps
license.
The BWM Global Parameters window specifies the BWM functionality of the device.
364

To configure Bandwidth Management

1. From the BWM menu, select Global Parameters. The Global Parameters window appears.
Parameter
Description
Classification Mode
Select from:
Disable: No classification. BWM management feature is disabled.
Policies: The device classifies each packet or session by matching it
to policies configured by the user.
Diffserv: The device classifies packets only by the DSCP
(Differentiated Services Code Point) value.
ToS: The device classifies packets only by the ToS (Type of Service)
bit value.
Note: After changing Classification Mode, device needs a reboot.
Scheduling
Algorithms
The scheduler forwards packets from the queues. The scheduler operates
through one of two algorithms: WRR (Weighted Round Robin) and CBQ
(Class Based Queuing).
WRR (Weighted Round Robin) - the scheduler gives each priority
a preference ratio of 2:1 over the immediately adjacent lower
priority. A 0 queue has twice the priority of a 1 queue, which has
twice the priority of a 2 queue, etc. The scheduler systematically
goes through same priority queues when it is time to forward a
packet with this priority.
CBQ (Class Based Queuing) - has the same packet-forwarding
pattern as WRR, with one significant difference. CBQ is aware of the
predefined bandwidth configured per policy. As policies are
configured, they can be given a guaranteed minimum and a
maximum allotted bandwidth, in Kbps.
Note: Unless CBQ is used, policies cannot be configured with an
associated bandwidth allocation.
Random Early
Detection (RED)
If the RED algorithm is deployed, the status of the queues is monitored. If

the queues approach full capacity, random TCP packets are intercepted
and dropped. The bandwidth management device can deploy RED in two
forms:
Global: The RED algorithm monitors the capacity of all queues and
randomly discards TCP packets before the classifier sees them.
Weighted: The RED algorithm checks the priority of the queue
(instead of for all the packets in all the queues) before deciding
whether a packet gets dropped or not.
Queue Size
The number of packets in each BWM queue. There is 1 queue per each
traffic shaping policy.
Default: 128
Dynamic Borrowing
(checkbox)
Enables the scheduler to borrow bandwidth from other queues within a

group, to forward packets from queues that have exceeded (or are about
to exceed) their allotted amount of bandwidth. Available only when the
scheduler operates through the CBQ algorithm.
365

Parameter
Description
BW per Traffic Flow

Aging
Time, in seconds, a non-active traffic flow is kept in the flow table used by
the Bandwidth Management module.
Max packets for

Session
Classification
When Application Classification mode is set to Per Session and one of the
policies is configured to search for content, this parameter displays
maximum number of packets that the device searches through for the
configured content.
If the device cannot find the content after searching the number of
packets defined in the parameter, the device will stop searching.
Values: 0 (Disabled - the device will search for the content in all the
packets belonging to the session) - 100.
Default:5
3.
Viewing Active BWM Policies

You can view active policies, and configure new ones. The Bandwidth Management module uses a
policy database. The policies in a database can be altered and configured without affecting the
current operation of the device. As these policies are adjusted, the changes are not in effect unless
the inactive database is activated. The activation updates the active policy database, which is what
the classifier uses to sort through the packets that flow through it.
You can modify these policies according to your requirements at any given time.
To view active policies

1.
From the BWM menu, select View Active Policies. The Active Policies Table window appears.
2.
From the Active Policies Table window, select the policy you wish to view. The table displays the
parameters of the active policy.
Parameter
Description
Name
User-defined name of the policy.
Index
Index number of the policy.
Destination
Destination address of the packet being matched by the policy.

Note: The source or destination can be an IP address or a network
address.
366
Source
Source address of the packet being matched by the policy.
Action
Action to be applied to the packet is either Forward, Block, Block and

reset, or Block and bi-directional reset.
Direction
Direction to which the policy relates is either Oneway or Twoway.

Oneway means a policy only matches packets where the source IP and
port match the source, and the destination. Twoway means that if the
source matches the destination and vice versa, this is also a match.
Priority
Priority attached to the packet by which it is forwarded is either Realtime or a value of 0-7, 7 being the lowest priority. Priority is only
applicable if the action is forward.
Policy Type
Type of policy, BWM or Farm Cluster.
Description
A description of the policy.

Parameter
Description
Guaranteed
Bandwidth
Defined bandwidth limitation for packets matching this policy. This

option is used in conjunction with CBQ, not WWR.
Maximum Bandwidth
Maximum amount of bandwidth that can be borrowed for this policy.
Service Type
Values: None, Basic Filter, Advanced Filter or Filter Group.
Service
Name of the service required for this policy, based on the Service Type.
Packet Marking
Refers to Differentiated Services Code Point (DSCP) or Diffserv.

Enables you to mark the packet with a range of bits displayed in the
dropdown list.
Reporting
Whether blocked packets should be reported, either Enable or Disable.
Inbound Physical Port

Group
User set policies for identical traffic classes that are received on
different interfaces of the device. For example, the user can allow
HTTP access to the main server only to traffic entering the device via
physical interface 3. This provides greater flexibility in configuration.
VLAN Tag Group
From dropdown list, select name of tag group that you want to use.
Policy Group
Select from the list of the user defined Policy Groups.
View Active Policy Extensions

You can view the additional policy parameters in the Active Policies Extensions window.
To view Active Policies Extensions

1. From the BWM menu, select View Active > Policy Extensions. The Active Policies Extensions
window appears, which contains the following read-only parameters.
Parameter
Description
Name
The user-defined name of the policy.
Classification Point
Indicates whether the classification is done before of after packet

modification.
After Changes: Classifies the device after the packet changes.
Before Changes: Classifies the device before the packet changes.
Traffic Flow
Identification
Defines what type of traffic flow we are going to limit via this policy. The
Client (source IP).
Session (source IP and port).
Connection (source IP and destination IP).
FullL4Session (source and destination IP and port).
SessionCookie (must configure cookie identifier).
Traffic Flow Max BW Maximum bandwidth in Kbps allowed per traffic flow.
(Kbps)
Max Concurrent
Sessions
Maximum number of concurrent sessions allowed for a client IP.

Note: This option is not available if the Traffic Flow Identifier is set to
Session or FullL4Session.
367

Parameter
Description
Max HTTP Rqts Per

Second
When the Traffic Flow Max BW parameter is configured, and the Traffic
Flow Identification parameter is set to Session Cookie, the device can
track and limit the number of requests, such as HTTP GET or Post or
HEAD per Cookie.
Cookie Field
Identifier
String that identifies the cookie field whose value must be used to
determine the different traffic flows.
Note: This is required only when Traffic Flow Identification is set to
SessionCookie. When Traffic Flow Identification is set to
SessionCookie, the BWM classifier searches for the Cookie Field
Identifier followed by = and classifies flows according to the
value.
Policy Group
Select from the list of the user defined policy groups.
Inactivation
Schedule
You can schedule the inactivation of specific Bandwidth Management

policies. Using Event Scheduler you can create "events" which can then
be attached to a policy's configurations. "Events" define the date and
time in which an action must be performed.
Viewing Active Policy Groups

You can view the active policy groups in the Active Policies Table window. This table displays all the
active policy groups. You cannot add or remove policy groups from this table.
To view policy groups

From the BWM menu, select View Active > Policy Group. The Active Policy Group Table window
appears, with the following parameter.
Parameter
Description
Name
Modify Policies
You can add, modify and delete policies in the Modify Policies Table window, according to your
requirements. In addition, you can edit the default policy of the device. A default policy exists, which
can be matched to any traffic that does not match a user-defined policy. You can change the action
and the priority of the default policy only.
To create a new policy

1.
From the BWM menu, select Modify Policies. The Modify Policies Table window appears.
2.
Click Create. The Modify Policies Table Create window appears.
3.
Set the parameters.
368
Parameter
Description
Name
Index
The index number of the policy
Source
The source address of the packet being matched by the policy.

Parameter
Description
Destination
The destination address of the packet being matched by the policy.

address
Direction
The direction to which the policy relates is either Oneway or Twoway.

Action
The action to be applied to the packet is either Forward, Block, Block

and reset, or Block and bi-directional reset.
Priority (SynApps
only)
The priority attached to the packet by which it is forwarded is either

Real-time or a value of 0-7, 7 being the lowest priority. Priority is only
Policy Type
The type of policy, BWM or Farm Cluster.
Guaranteed
Bandwidth (SynApps
only)
The defined bandwidth limitation for packets matching this policy. This
Service
Service Type
Description
Operational Status
Specifies the operational status of the policy, Active or Inactive.

Note: If you select inactive, when policies are updated, this policy is
not used to be matched against packets.
Packet Marking
(SynApps only)
Refers to Differentiated Services Code Point (DSCP) or Diffserv.

Enables you to mark the packet with a range of bits displayed in the
dropdown list.
Reporting
Maximum Bandwidth
(SynApps)
Inbound Physical Port User set policies for identical traffic classes that are received on
Group
different interfaces of the device. For example, the user can allow HTTP
access to the main server only to traffic entering the device via
physical interface 3. This provides greater flexibility in configuration.
VLAN Tag Group
From dropdown list, select name of the tag group that you want to use.
Policy Group
Modify Policy Group

policies, enabling them to borrow from other policies preventing starvation and utilizing the
bandwidth more efficiently. Only policies that participate in a specific group can share bandwidth.
To total bandwidth available for a policy group is the sum of Guaranteed Bandwidth values of all
policies in the group.
369

The Policies Group table contains all the bandwidth policy groups. You can add new policy groups to
this table.
Note: For all the policies that are associated with a policy group the Guaranteed Bandwidth
parameter must be set to a value greater than 0 and Borrowing Limit parameter to 0.
The Dynamic Borrowing global parameter must be enabled.
To create a new Policy Group

1.
From the Bandwidth Management menu, select Modify > Policy Groups. The Modify Policy
Group Table window appears.
2.
Click Create. The Modify Policy Group Table Create window appears.
3.
In the Name text box, type the name of the new Policy Group and click Set. The new policy
group appears in the Modify Policy Group Table window and the Active Policy Group Table.
4.
Continue to set the remaining parameters.
Parameter
Description
Name
Index
Index number of the policy
Source
Source address of the packet being matched by the policy.
Destination
Destination address of the packet being matched by the policy.

address
Direction
Direction to which the policy relates is either Oneway or Twoway.

Action
Action to be applied to the packet is either Forward, Block, Block and

reset, or Block and bi-directional reset.
Priority (SynApps
only)
Priority attached to the packet by which it is forwarded is either Realtime or a value of 0-7, 7 being the lowest priority. Priority is only
Policy Type
Type of policy: BWM or Farm Cluster.
Guaranteed
Bandwidth (SynApps
only)
Defined bandwidth limitation for packets matching this policy. This

Service
Service Type
Description
Operational Status
Specifies the operational status of the policy, Active or Inactive.

Note: If you select inactive, when policies are updated, this policy is
not used to be matched against packets.
Packet Marking
(SynApps only)
370
Refers to Differentiated Services Code Point (DSCP) or Diffserv. Enables

you to mark the packet with a range of bits displayed in the dropdown
list.

Parameter
Description
Reporting
Maximum Bandwidth
(SynApps)
Inbound Physical Port User set policies for identical traffic classes that are received on
Group
different interfaces of the device. For example, the user can allow HTTP
access to the main server only to traffic entering the device via physical
interface 3. This provides greater flexibility in configuration.
VLAN Tag Group
From dropdown list, select name of the tag group that you want to use.
Policy Group
To delete policies
1. From the Modify Policies Table window, select the policy you require to delete.
2. Click Delete. The policy is deleted.
Modify Policy Extensions

In the Modify Policies Extensions window you can modify policy extensions according to your
requirements.
To Modify Policies Extensions

1. From the BWM menu, select View Active > Modify > View Active Policy Extensions. The
Active Policies Extensions window appears.
Parameter
Description
Name
Indicates whether the classification is done before of after packet

modification.
Traffic Flow
Identification
Defines what type of traffic flow we are going to limit via this policy. The
Client (source IP).
Traffic Flow Max BW Maximum bandwidth in Kbps allowed per traffic flow.
(Kbps)
371

Parameter
Description
Max Concurrent
Sessions
Max HTTP Rqts Per

Second
HEAD per Cookie.
Cookie Field
Identifier
Note: This option is not available if the Traffic Flow Identifier is set to
Session or FullL4Session.

SessionCookie. When Traffic Flow Identification is set to
SessionCookie, the BWM classifier searches for the Cookie Field
Identifier followed by = and classifies flows according to the
value.
3.
Policy Group
Inactivation
Schedule

Bandwidth Management and Classes Update Policies

You can activate the latest changes made in Bandwidth Management or Classes. You use the
Activate Latest Changes window to activate the Inactive Policies.
To activate inactive policies

1.
From the BWM or Classes menu, select Update Policies. The Activate Latest Changes window
appears.
2.
Click Set to implement the latest policy changes.
Configuring Networks
The Bandwidth Management module allows multiple Networks to have the same configured name.
This allows a Network with the name net1 to encompass multiple, disjointed IP address ranges.
This makes the Network name a logical pointer to all ranges configured with that name and further
facilitates the configuration and management of the system. You can view active networks, and
configure new ones. You can define networks used by the device (active) and you can define
networks kept in a separate database until they are required (inactive). You can add, modify and
delete these networks according to your requirements.
372

To create a new network

1. From the Classes menu, select Modify > Networks. The Modify Network Table window
appears.
2. Click Create. The Modify Network Table Create window appears.
Parameter
Description
Name
User-defined network name.
Sub Index
Unique index number of the subnet. Each network can have several
subnets. Sub Indexes for the subnets within the same network must be
unique.
Address
IP address of the subnet.
Mask
Mask address of the subnet.
From IP
First IP address in the range of addresses.
To IP
Last IP address in the range of addresses.
Mode
Network mode is either IP Mask or IP Range.
Note: To simplify configuration, a network can consist of a combination of network subnets and
ranges. For example:
>> Range = 176.200.100.0: 176.200.100.255
>> Subnet = 172.0.0.0: 255.0.0.0
Viewing Active Networks

The View Active Networks window allows you to view and modify active networks and to configure
new ones. You can define networks to be used by the device, which are kept in the active part of the
database, and you can define networks that will kept in a separate, temporary database until they
are required. You can add, modify and delete these networks according to your requirements.
To view active networks

From the Classes menu, select View Active Networks. The Active Network Table window appears,
with the network parameters as listed above.
To edit a network
1. From the Modify Network Table window, select the network you require to edit. The Modify
Network Table Update window appears.
2. Adjust the values of the appropriate fields.
373

3.
To delete networks
1.
From the Modify Network Table window, select the network you want to delete.
2.
Click Delete. The network is deleted.
Services
Services can be configured within the Bandwidth Management system and are configured separately
from policies. As each policy is configured, it can be associated with a configured Service. The
Service associated with a policy in the policy database can be a basic filter, an advanced filter or a
filter group.
Basic Filters
A basic filter has the following components:
Protocol: The specific protocol that the packet carries. The possible choices are IP, TCP, UDP,
ICMP, and Other. If the protocol is configured as IP, all IP packets (including TCP and UDP) are
considered. When configuring TCP or UDP protocol, some additional parameters are also
available:
Destination Port (From-To) - Destination port number for the protocol. For example, for
HTTP, the protocol is configured as TCP and the Destination port as 80. The port
configuration can also allow for a range of ports to be configured.
Source Port (From-To) - Similar to the Destination port; the Source port that a packet
carries to match the filter.
Offset Mask Pattern Condition (OMPC): The OMPC is a condition where any bit pattern can be
located for a match at any offset in the packet. This helps to locate specific bits in the IP header.
You do not have to configure an OMPC per filter. However, when an OMPC is configured, the
packet needs to match the configured protocol (and Source/Destination ports) AND the OMPC.
Content
When the protocol configured is TCP or UDP, you can search for any text string in the packet. Similar
to an OMPC, a text pattern can be searched for at any offset in the packet. HTTP URLs are perfect
examples of how a text search can help in classifying a session.
The service editor allows you to choose between multiple types of configurable content: URL, host
name, HTTP header field, Cookie, mail domain, mail to, mail from, mail subject, file type, regular
expression and text. For example, when the content type is URL, then the session is assumed to be
HTTP with a GET, HEAD, or POST method. The classifier searches the URL following the GET/HEAD/
POST to find a match for the configured text. In this case, the configured offset is meaningless since
the GET/HEAD/POST is in a fixed location in the HTTP header. If the content type is text, then the
entire packet is searched for the content text, starting at the configured offset. By allowing a filter to
take the content of a packet/session into account, the classifier can recognize and classify a wider
array of packets and sessions.
Like OMPCs, content rules are not mandatory to configure. However, when a content rule exists in
the filter, the packet needs to match the configured protocol (and ports), OMPC (if one exists) AND
the content rule.
374

Pre-Defined Filters
This table lists pre-defined Bandwidth Management filters for each service.
Table 6:
Service Name
Description
Filter
Name
ERP/CRM
sap
Basic
Database
mssql
Microsoft SQL service group
Group
mssql-monitor
SQL monitoring traffic
Basic
mssql-server
SQL server traffic
Basic
oracle
Oracle database application service group
Group
oracle-v1
Oracle SQL* Net v1-based traffic (v6, Oracle7)
Basic
oracle-v2
Oracle SQL*Net v2/Net 8-based traffic (Oracle7,8,8i,9i)
Basic
oracle-server 1
Oracle Server (e-business solutions) on port 1525
Basic
oracle-server2
Oracle Server (e-business solutions) ON PORT 1527
Basic
oracle-server3
Oracle Server (e-business solutions) on port 1529
Basic
Thin Client or Server Based

citrix
Citrix connectivity application service group.
Group
Enables any type of client to access applications across any type of

network connection.
citrix-ica
Citrix Independent Computer Architecture (ICA)
Basic
citrix-rtmp
Citrix RTMP
Basic
citrix-rtmp
Citrix RTMP
Basic
citrix-ima
Citrix Integrated Management Architecture
Basic
citrix-ma-client
Citrix MA Client
Basic
citrix-admin
Citrix Admin
Basic
p2p
Peer-2-Peer applications
Group
edonkey
File sharing application
Basic
gnutella
File sharing and distribution network
Basic
fasttrack
User-to-User Media Exchange
Basic
Kaaza
File Sharing Application (Note: Music City Morpheous and Grokster

classify as Kaaza)
Basic
Peer-to-Peer
Internet
dns
Domain Name Server protocol
ftp-session
File Transfer Protocol service - both FTP commands and data
Basic
http
Web traffic
Basic
http-alt
Web traffic on port 8080
Basic
https
Secure Web traffic
Basic
icmp
Internet Control Message Protocol
Basic
375

Table 6:
Service Name
Description
ip
IP traffic
nntp
Usenet NetNews Transfer Protocol
Filter
Name
Basic
telnet
tftp
Basic
udp
Basic
Instant Messaging
aol-msg
AOL Instant Messenger
Basic
icq
ICQ
Basic
msn-msg
MSN Messenger Chat Service
Basic
yahoo-msg
Yahoo Messenger
Group
yahoo-msg1
Yahoo Messenger on port 5000
Basic
yahoo-msg2
Basic
yahoo-msg3
Basic
Email
mail
Group
smtp
Basic
imap
Basic
pop3
Basic
Basic Filters
The Active Basic Filters window allows you to view the basic filters of the active services.
To view a basic filter

1.
From the Classes menu select Modify Services > Basic Filters. The Active Basic Filters
window appears.
2.
Select the required name. The Active Basic Filters Update window appears with these read-only
parameters.
Parameter
Description
Name
Name of the filter as you define it
Protocol
Values: IP, UDP, TCP, ICMP. NonIP, SCTP
Destination App Port
Last port in the range of destination ports for UDP and TCP traffic only.
Values: 0 (default) - 65535.
Defined value must be greater than Destination Port Range: From
value.
376

Parameter
Description
Source App. Port
Last port in the range of source ports for UDP and TCP traffic only.
Values: 0 (default) - 65535.
Defined value must be greater than the Source Port Range: From
value.
OMPC Offset
Location in the packet from which the checking of data is started to

find specific bits in the IP/TCP header.
OMPC Offset Relative

to
Indicates to which OMPC offset the selected offset is relative to.

If the IP/UDP/ICMP protocols are selected, you can configure:
None (Default), IP Header, IP Data.
If the TCP protocol is selected, you can set these values:
None (Default), IP Header, IP Data, TCP Data.
OMPC Mask
Mask for OMPC data. Values: a combination of hexadecimal numbers

(0-9, a-f). Value must be defined according to the OMPC Length
parameter.
OMPC Pattern
Fixed size pattern within the packet that OMPC rule attempts to find.
Values: a combination of hexadecimal numbers (0-9, a-f). The value
must be defined according to the OMPC Length parameter.
OMPC Pattern parameter definition must contain 8 symbols. If the
OMPC Length value is lower than fourBytes, you need complete it with
zeros.
For example, if OMPC Length is twoBytes, OMPC Pattern can
be:abcd0000.
Default: 00000000.
OMPC Condition
Values: N/A (Default), equal, notEqual, greaterThan or lessThan.
OMPC Length
Values: N/A (Default), oneByte, twoBytes, threeBytes or fourBytes.
Content Offset
Location in packet from which the checking of content is started.

Content
Contains the value of the content search.

Values: < space > ! " # $ % & ' ( ) * + , -. / 0 1 2 3 4 5 6 7 8 9 : ; <
=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_
àbcdefghijklmnopqrstuvwxyz{|}~.
377

Parameter
Description
Content Type
Enables you to search for a specific content type from these values:
N/A (Default)
URL: In the HTTP Request URI
Host Name: In the HTTP Header
Text: Anywhere in the packet
HTTP Header Field: In the HTTP Header
Mail Domain: In the SMTP Header
Mail To: In the SMTP Header
Mail From: In the SMTP Header
Mail Subject: In the SMTP Header
Regular Expression: Anywhere in the packet
Header Type: HTTP Header field. The "Content" field includes the
header field name, and the "Content data" field includes the field
value
File Type: Type of requested file in the http GET command (jpg,
exe etc.)
Cookie Data: HTTP cookie field. The "content" field includes the
cookie name, and the "content data" field includes the cookie
value.
Filter Type
Select Application Security for Application Security filters, OR Regular

for Bandwidth Management filters.
Content Max Length
Maximum length to be searched within the selected Content Type.

Values: 0(default) - 1513
Content Max Length value must be equal or greater than Offset value.
Content Data
Refers to search for content within the packet.

Values: N/A, URL or Text.
Content Encoding
Application Security can search for content in languages other than

English, for case sensitive/insensitive text and hexadecimal strings.
Values:
None (Default)
Case Insensitive
Case Sensitive
HEX
International
Content Data Encoding Application Security can search for content in languages other than
English, for case sensitive/insensitive text and hexadecimal strings.
Values:
None (Default)
Case Insensitive
Case Sensitive
HEX
International
Description
378
A description of the filter.

3. Click Set. The new Basic Filter is added to the Basic Filters Table.
Note: If you edit the parameters of the filter, which is bound to the existing policy, you need to
activate the latest changes
AND Group Filters and OR Group Filters

An AND Group Filter is a combination of basic filters with a logical AND between them. Let's assume
filters F1, F2, and F3 have been individually configured. Advanced filter AF1 can be defined as:
AF1= {F1 AND F2 AND F3}.
In order for AF1 to be a match, all three filters (F1, F2, and F3) must match the packet being
classified.
An OR Group Filter is a combination of basic filters and/or advanced filters with a logical OR between
them. To continue the example above, filter group FG1 can be defined as:
FG1 = {AF1 OR F4 OR F6}.
In order for FG1 to be a match, either advanced filter AF1, basic filter F4, or basic filter F6 have to
match the packet being classified.
Radware devices are pre-configured with a set of basic filters and group filters that represent
applications commonly found in most networks.
Creating and Modifying AND Group Tables

AppDirector enables you to view active services and to configure new services. You can define
services used by the device, which are kept in the active part of the database, and you can define
services kept in a separate, temporary database until they are required.
You can create basic filters and then combine them with logical conditions to achieve more
sophisticated filters, as shown in the Modify AND Group Table window. Use filter groups (for logical
OR between filters) and advanced filters (for logical AND between filters). The Modify AND Group
Table window allows you to modify an advanced filter.
To create or modify an AND Group table

1. From the Classes menu, select Modify > Services > AND Groups. The Modify AND Groups
2. Select the required advanced name. The Modify AND Groups Update Table window appears, with
these read-only parameters:
Parameter
Description
AND Group Name
User-defined AND Group name.
Basic Filter Name
Name of the basic filter that is to be added to the Advance Filter.
Note: If you edit the parameters of the advanced filter, which is bound to the existing policy,
you need to activate the latest changes.
379

Creating and Modifying OR Groups Table

You can also add, modify and delete the filters that build the services according to your
requirements. The Modify OR Groups Table window allows you to modify an existing filter group.
To add/modify a new OR Group

1.
From the menu select Classes > Modify > Services > OR Groups. The Modify OR Groups
2.
Click Create. The Modify OR Groups Table Create window appears.
3.
Set the parameters.
Parameter
Description
OR Group Name
Name of the Filter Group that you define
Filter Type
Basic: The basic building block of a Service is a basic filter which is made
up of the following components:
Protocol:
Destination Port (From-To)
Source Port (From-To)
Offset Mask Pattern Condition (OMPC)
Content
AND Group: Combination of basic filters with a logical AND between them.
Note: A Filter Group is a combination of basic filters and/or advanced
filters with a logical OR between them. To continue the example
above, filter group FG1 can be defined as FG1 = {AF1 OR F4 OR
F6}
Filter Name
4.
Name of entry assigned to a specific filter group.
Viewing Active Services

AppDirector enables you to view active services, and configure new ones.
To view active services

From the Classes menu, select View Active > Services > Basic Filters or AND Groups, or OR
Groups.
OR
From the Security menu select Application Security > View Active Services > Basic Filters,
Advanced Filters or Filter Groups. The selected table window appears.
OR
From the Security menu select Application Security > DoS Shield > View Active Services >
Basic Filters, Advanced Filters. The selected table window appears.
380

Application Port Groups

Application Port Groups represent the Layer 4 ports for UDP and TCP traffic. Each group is identified
by its unique name. Each group name can be associated with a number of entries in the Application
Port Groups table. The values can be: 0 - 65535.
To Create or Modify Application Port Groups

1. From the Classes menu, select Modify > Application Port Groups. The Modify Application Port
Groups Table window appears.
2. Click Create. The Modify Application Port Groups Table Create window appears.
3. Set the parameters .
Parameter
Description
Name
A user defined group name
From Port
Define the first port in the range.

Notes:
To define a group with a single port, set the same value for the From
Port and To Port parameters.
To associate a number of ranges with the same port group, use the
same group name for all the ranges that you want to include in one
group.
To Port
Define the last port in the range.
Group Type
Defines the group type either static or regular.
4. For Updating, in the Modify Application Port Groups Table window, click on the application name.
The Modify Appl. Port Groups Table Update window appears
To view Application Port Groups

1. From the Classes menu, select View Active > Appl Port Groups. The Active Application Port
2. Select the desired name. The Active Application Port Groups Table Update window appears
which contains the following read-only parameters.
Parameter
Description
Name
A user defined group name
From Port
Define the first port in the range.

Notes:
To define a group with a single port, set the same value for the From
Port and To Port parameters.
To associate a number of ranges with the same port group, use the
same group name for all the ranges that you want to include in one
group.
381

382
To Port
Define the last port in the range.
Group Type

Physical Port Groups

You can set different policies to identical traffic classes that are received on different interfaces of
the device. For example, you can allow access to the main server only to traffic entering the device
via physical interface 3. This provides greater flexibility in configuration.
You must first configure Port Groups, which are collections of Physical Interfaces of the device, and
then associate a Port Group to the required policies. The Modify Physical Port Groups Table window
allows you to modify an existing port group.
To modify a port group

1. From the Classes menu, select Modify > Port Groups. The Modify Physical Port Groups Table
window appears.
2. Select a group name. The Modify Physical Port Groups Table Update window appears.
Parameter
Description
Group Name
User-configured name of the port group.
Inbound Port
Inbound port for this group. Values can be a port number or Any.
4. Click Set. The Port Group is configured.
VLAN Tag Groups

VLAN Tag Groups enable you to set different policies for identical traffic classes received with
different values of 802.1q VLAN Tags; e.g., you can allow SMTP access to the Internet only to traffic
tagged with a specific value VLAN Tag.
This provides configuration flexibility. You must first configure the VLAN Tag Groups.
To modify VLAN tag groups

1. From the Classes menu select Modify > VLAN Tag Groups. The Modify VLAN Tag Groups Table
window appears.
Parameter
Description
Group Name
Name of the group of VLAN Tags.
VLAN Tag
A VLAN Tag number.
VLAN Tag Range From
Lowest value in range of VLAN Tags that you want to define.
VLAN Tag Range To
Highest value in range of VLAN Tags that you want to define.
Group Mode
Mode of the group that you want to define is Discrete if you define a
single VLAN Tag number, OR Range if you define range of the group.
383

Note: This feature is applicable only when the 802.1q parameter is set to Enabled.
Classifications performed according to the tag of the received packet
To view VLAN tag groups

1.
From the Classes menu select View Active > VLAN Tag Groups. The Modify VLAN Tag Groups
Table window appears
2.
Set the parameters.
3.
Parameter
Description
Group Name
VLAN Tag
A VLAN Tag number.
VLAN Tag Range From
Lowest value in range of VLAN Tags that you want to define.
VLAN Tag Range To
Highest value in range of VLAN Tags that you want to define.
Group Mode
Mode of group that you want to define is Discrete if you define a single
VLAN Tag number, OR Range if you define range of the group.
MAC Groups
To view or modify MAC Groups

1.
From the Classes menu select Modify > MAC Groups. The Modify MAC Address Groups Table
appears.
2.
Click Create. The Modify MAC Address Groups Table Create window appears.
3.
Set the parameters.
4.
Parameter
Description
Group Name
Name of the MAC address group.
MAC Address
A MAC Address number.
Protocol Discovery
This describes the Protocol Discovery feature that allows you to recognize different applications
running on your network by creating Protocol Discovery Policies.
To use the Bandwidth Management module optimally, network administrators must be aware of the
different applications running on their networks and the amount of bandwidth they consume. The
Protocol Discovery feature provides a full view of the different protocols running on the network.
This feature can be activated on the entire network or on separate sub-networks by defining
Protocol Discovery policies.
384


A Protocol Discovery policy comprises traffic classification criteria including:
Source: Defines the source of traffic. It can be a specific IP address or a network. A network is
a collection of ranges and/or subnets. Configure the Networks; the default value is any, which
covers traffic from any source.
Destination: Defines the traffic destination. It can be specific IPs, a range of IP addresses, or
an IP subnet address. The default value is any, which covers traffic to any destination.
Source MAC Address Group: Views applications and protocols present in the traffic sent by a
transparent network device (firewall, router).
Destination MAC Group: Views applications and protocols present in the traffic sent to a
transparent network device (firewall, router).
Inbound Physical Port Group: Classifies only traffic received on certain interfaces of the
device. Enables you to set different policies for identical traffic classes that are received on
different device interfaces.
VLAN Tag Group: Defines VLAN traffic classification according to VLAN ID tags.
Classification Point: Defines the point where traffic redirection occurs. The device modifies
packets by changing the Destination IP from the Virtual IP to the servers real IP address. The
traffic can be classified as before packet changes, or after packet changes, After Changes.
Direction: Defines the direction of the traffic. It can be One Way (from Source to Destination)
or Two Way.
Operational Status: Determines whether Policy is active or not. Select from Active or Inactive.
Interface Classification
This describes the process of interface classification, which enhances Bandwidth performance
Editing Port Bandwidth

To optimize the queuing algorithm, it is essential for the BWM module to be aware of the maximum
available ports bandwidth. This can be configured via the BWM Port Bandwidth table. By default, the
maximum available is determined by the port type - 100 Mbps for FE ports and 1Gbps for Giga
ports. The queuing filter only starts functioning upon link saturation. Configuring the maximum is
the only way to determine if the link is saturated.
To edit Port Bandwidth

1. From the BWM menu select Miscellaneous > Port Bandwidth Table. The Port Bandwidth
2. Select the port for which you require to edit the bandwidth. The Port Bandwidth Table Update
window appears.
Parameter
Description
Port Index
Port number.
Port Bandwidth (kbps) Bandwidth available to the specific port.

Port Used Bandwidth
(kbps)
Amount of bandwidth used on the specific port.
385

Cancel Classification Per Port

This feature enables the user to configure ports where classification is not performed. In this way
valuable processing time can be saved while enabling a simpler method of configuring the device.
Cancel Classification Per VLAN is also available for a VLAN configuration.
To cancel classification for a port

1.
From the BWM menu select Miscellaneous > Cancel Classification Per Port. The Cancel
Classification Per Port window appears.
2.
Set the parameters.
Parameter
Description
Inbound Port
Number of the required port for inbound traffic.
Outbound Port
Number of the required port for outbound traffic.
Direction
Direction of traffic flow through each port.

Values can be Oneway, the traffic flows in through the Inbound Port and
out through the Outbound Port, or Twoway, the traffic flows both ways
through both ports.
3.
Modifying Application Port Groups

by its unique name and each group name can be associated with a number of entries in the
Application Port Groups table.
To create the Modify Appl. Port Groups Table parameters

1.
From the Classes menu, select Modify Appl Port Groups. The Modify Appl. Port Groups Table
window appears.
2.
Click Create. The Modify Appl. Port Groups Table Create window appears.
3.
Set the parameters.
386
Parameter
Description
Name
A user defined group name.
From Port
Define the first port in the range. (Values from 0)
To Port
Define the last port in the range.(Values to 65535)
Group Type

Notes:
>> To define a group with a single port, set the same value for the From Port and To Port
parameters.
>> To associate a number of ranges with the same port group, use the same group name
for all the ranges that you want to include in one group.
To update the parameters of the Modify Appl. Port Groups Table

1. From the Classes menu, select Modify Appl Port Groups. The Modify Appl. Port Groups Table
window appears.
2. Click on the application name. The Modify Appl. Port Groups Table Update window appears.
Proceed from step 3.
Viewing Application Port Groups
To view active application port groups

1. From the Classes menu, select View Active > Appl Port Groups. The Active Application Port
2. Select the desired name. The Active Application Port Groups Table Update window appears with
read-only parameters. See To create the Modify Appl. Port Groups Table parameters, page 385.
Modify MAC Groups
To modify MAC Groups

1. From the Classes menu select Modify > MAC Groups. The Modify MAC Address Groups Table
appears.
2. Click Create. The Modify MAC Address Groups Table Create window appears.
Parameter
Description
Group Name
Name of the MAC address group.
MAC Address
A MAC address number.
View Active MAC Groups

To classify traffic according to Mac addresses, you can create groups of Mac addresses.
387

To view the Active MAC Groups:

From the Classes menu select View Active MAC Groups. The Active MAC Address Groups Table
window appears with read-only parameters. See To modify MAC Groups, page 386.
View Active VLAN Tag Groups

The Active VLAN Tags Table Update window allows you to view the active VLAN tag groups.
To view the Active VLAN Tag Groups

1.
From the Classes menu select View Active VLAN tag Groups. The Active VLAN Tags Table
window appears.
2.
Select a group name. The Active VLAN Tags Table Update window appears which contains the
following read-only parameters.
Parameter
Description
Group Name
VLAN Tag
A VLAN Tag number.
VLAN Tag Range

From
Lowest value in the range of VLAN Tags that you want to define.
VLAN Tag Range To
Highest value in the range of VLAN Tags that you want to define.
Group Mode
The group mode that you want to define is:

Discrete: when you define a single VLAN Tag number, OR
Range: when you define the range of the group.
Note: This is applicable only when the 802.1q parameter is set to Enabled. Classifications
performed according to the tag of the received packet.
Modify Port Groups

then associate a Port Group to the required policies.
The Modify Physical Port Groups Table window allows you to modify an existing port group.

1.
From the Classes menu, select Modify Port Groups. The Modify Physical Port Groups Table
window appears.
2.
Select a group name. The Modify Physical Port Groups Table Update window appears.
388

Parameter
Description
Group Name
User-configured name of the port group.
Inbound Port
Inbound port for this group. Values can be a port number or Any.
To create a new port group

1. From the Classes menu select Modify >Port Groups. The Modify Physical Port Groups Table
window appears.
2. Select Create. The Physical Port Groups Table Create window appears. Proceed as step 3.
389

Advanced Capabilities
Chapter 7 Advanced Capabilities

This chapter displays AppDirector advanced capabilities and includes the following sections:
Diameter and LDAP Load Balancing, page 389
Multihoming, page 392
Segmentation, page 398
Session Initiation Protocol (SIP), page 404
Stream Control Transmission Protocol (SCTP), page 406
Performance Statistics, page 408
Statistics Monitor, page 437
Utilities, page 439
Diameter and LDAP Load Balancing

OR USING AN APPDIRECTOR WITH AN APPXCEL DEVICE (also see Optimizing AppDirector with
AppXcel Application Accelerator, page 581).
Radware enables the management and load distribution of LDAP messages originating from a single
TCP connection across multiple LDAP servers. By handling LDAP messages independently of the
number of sources and transmission control protocol (TCP) connections, Radware guarantees highavailability, accelerated performance.
How does it work?
1. Perform Load Balance and maintain the connection Due to the nature of this protocol you
need to do TCP splitting to perform Load Balancing. The TCP Splitting table defines for
AppDirector which backend servers provide the service that an AppXcel farm must perform TCP
Splitting for, so that the AppDirector knows which backend servers to configure on the AppXcel
devices in this farm.
2. Monitor the Diameter or LDAP servers The Diameter health check (see initiates a connection
to the Diameter server. The module then performs a Diameter handshake (CER or CEA) and
sends an LIR message or another application message. This monitor help you to see if the server
is down in order to send the traffic to another server.
389

Application Server TCP Splitting
TCP Splitting is the ability to maintain open concurrent connections opposite all servers providing
Diameter or LDAP services, while a single connection was opened by the client. It is important to
improve TCP throughput due to the many applications that use TCP. A performance characteristic of
TCP is that the rate at which its window size increases is inversely proportional to the average round
trip time (RTT), and the average window size is directly related to the throughput. Thus, reducing
the RTT between connection endpoints can increase the window size faster, resulting in increased
throughput.
An intuitive way to reduce the effective RTT of a direct TCP connection between any two hosts is to
split that connection into multiple pipelined sub-connections so that each sub-connection has a
lower RTT than the direct connection. In addition to increasing throughput, TCP Splitting can also
route around failures and discover paths that are better than the direct path. This not only improves
the connection throughput but also improve the reliability and quality of paths between endpoints.
How does TCP Splitting work?

TCP splitting uses a performance enhancing proxy access node that divides the end-to-end TCP
connection between the client and the server into a multi-overlay-hop path where each overlay hop
is an independent TCP connection, such that the RTT of each overlay hop is lower than the direct RTT
between A and B. Each hop's throughput is governed by that hop's RTT and will be individually
higher than the direct throughput between A and B.
But performance issues can arise due to the interaction among path segments and different layers
for any particular solution. For example, in TCP Splitting, the intermediate node (the spoofer) sends
back a spoofing ACK packet to the TCP sender immediately upon receiving a TCP data packet instead
of waiting for the ACK from the final TCP destination.
One of the well known problems of TCP splitting is that by breaking the end-to-end connection, a
split TCP connection is no longer reliable or secure, and a server failure may cause the client to
believe that data has been successfully received when it has not. From the Application Server TCP
Splitting window you can access the TCP Splitting for the Application Server.
To update the Application Server TCP Splitting

1.
From the AppDirector menu, select Servers > Application Servers > TCP SplittingTable.
The Application Server TCP Splitting Table window is displayed.
2.
Select a server to edit. Click Create. The Application Server TCP Splitting Update Table Create
window is displayed.
3.
Set the parameters.
4.
390
Parameter
Description
Farm Name
The farm name.
Server Address
The server address.
Server Port
The server port.
Managed Device Name
The name of the managed device in the managed device table.
Tunnel ID
The tunnel ID of the tunnel in the AppXcel.

TCP Splitting Table
Dynamic load balancing protects ISP networks from sudden congestion caused by load spikes or link
failures. Dynamic load balancing protocols, however, require schemes for splitting traffic across
multiple paths at a fine granularity. Current splitting schemes present a tussle between slicing
granularity and packet reordering. Splitting traffic at the granularity of packets quickly and
accurately assigns the desired traffic share to each path, but can reorder packets within a TCP flow,
confusing TCP congestion control.
Splitting traffic at the granularity of a flow avoids packet reordering but may overshoot the desired
shares by up to 60% in dynamic environments, resulting in low end-to-end network throughput.
The TCP Splitting table defines for AppDirector which backend servers provide the service that this
AppXcel farm must perform TCP Splitting for, so that AppDirector knows which backend servers to
configure on the AppXcel devices in this farm.
An entry in this table is configured by selecting a Layer 4 policy from a drop-down list. The dropdown list only displays Layer 4 policies that meet the following conditions:
It is a TCP Policy with a specific port.
A farm is associated to this Layer 4 policy (not an Layer 7 policy).
In the farm associated with the policy: the Transparent Server Support parameter is set to TCP
Splitting.
Once a Layer 4 policy is configured in the TCP Splitting table of a Front-End AppXcel farm, the Layer
4 policy parameters that are subjected to the conditions above (Layer 4 Protocol and Layer 4 Port,
Farm Name) and the Transparent Server Support parameter of the Layer 4 policy farm, cannot be
changed to values that do not meet the above conditions.
See also Application Server TCP Splitting, page 390.
To create or update the Application Server TCP Splitting Table

1. From the AppDirector menu, select Farms > TCP Splitting Table. The TCP Splitting Table
2. Select a server to edit. The Application Server TCP Splitting Update window is displayed.
Parameter
Description
Front-End AppXcel
Farm Name
Farm name that holds the Front-End servers (AppXcel tunnels).
Backend L4 Policy
Name
Layer 4 policy name that points to the Backend server.
391

Multihoming
This section explains AppDirector Multihoming capability as a solution to load balancing between
servers and routers of different ISPs and includes the following topics:
Default Router Per Virtual IP, page 393
Using Redirect to Self in Multi-Homed Environments, page 396
The AppDirector Multihoming solution is intended for networks in which AppDirector is connected to
multiple ISPs.
Using Multihoming, AppDirector can simultaneously use multiple ISPs for inbound traffic. To achieve
multihoming AppDirector uses the ability to configure a default router per Virtual IP Next Hop
Router, (VIP NHR) and to redirect to self.
To ensure ISP persistency for HTTP transactions (all the sessions related to a HTTP transaction are
processed via the same ISP) it is recommended to use Insert Cookie for HTTP persistency capability.
This capability must be enabled for all farms involved in the process. Here, AppDirector will ensure
ISP persistency automatically.
Figure 17: Multihoming with AppDirector
Router 1
Router 2
Router 3
AppDirector
VIP1
VIP3
VIP2
Farm 1
Farm 2
Router 1
Farm 3
Router 2
Router 3
AppDirector
VIP1
Farm 1
392
VIP2
Farm 2
VIP3
Farm 3

Default Router Per Virtual IP

AppDirector allows defining a different default router, and a backup one, for each Virtual IP
(including Virtual IP Interfaces) and Outbound NAT addresses. Load sharing can be enabled between
the two routers to enable multihoming. The VIP's default router is used for any type of traffic
forwarded by the AppDirector from this VIP, or generated by the AppDirector in respect to this VIP,
such as:
DNS answers.
LRP or PRP communication.
Client proximity checks.
HTTP redirection instructions.
Triangulated packets.
Note: Static routes cannot be configured per Virtual IP, only the default router can be
configured individually for each Virtual IP. Specific static routes are configured globally
for the device and take precedence over the default route.
You can set a backup default router for AppDirector. This enables using a backup router for traffic
generated by AppDirector that is not farm-related, such as ping, SNMP, or DNS requests, and for
traffic related to farms that do not have a default router configured.
Setting Up Default Router Per VIP

All the Next-Hop Routers that are connected to the AppDirector device are defined in the NHR table.
NHRs are associated with the Virtual IP addresses of the device using the VIP NHR table.
Note: The VIP NHR table is enabled only when the packet is destined for the default gateway
of the box but because of the static route, the packet was not destined for the default
gateway so in these instances the VIP NHR table is not enabled. The NHR per VIP
feature works only for traffic that matches the device's default gateway.
393

Before defining the VIP NHR table, you need to add a new NHR to the network and set up the
general NHR parameters.
Parameter
Description
NHR IP Address
Address of the selected NHR.
Administrative Status
Enabled
The user-defined management status of the NHR:

Enabled (Default): NHR is active and ready
Disabled: The NHR is not active.
Check Method
The following methods are available:

Ping: AppDirector pings the desired Path Health Check IP
according to the predefined Check Interval and Retries.
Disabled (Default): When the router Health Check is disabled,
AppDirector still checks by sending ARPs to the router's MAC
address.
Health Monitoring Module: NHR is checked using the Health
Monitoring module. AppDirector continually sends ARP requests to
the NHR to ensure its MAC is correct. If the ARP requests fail, the
NHR is labeled Not-in-Service.
Path Health Check IP
AppDirector pings the remote IP via the specified router to make sure
the router is healthy and connected to its uplink. If a Path Health Check
fails, the relevant router is considered Not in Service.
Default: 0.0.0.0
Check Interval
How often AppDirector polls the NHR (in seconds).

Default: 10
Check Retries
Number of polling attempts that are made before a NHR is considered

inactive.
Default: 3
Note: When the Health Check of the router is disabled, AppDirector still checks the health of
the router by sending ARPs to the router's MAC address.
Once the general NHR parameters are defined, you can set up the VIP NHR table parameters. For
each Virtual IP, you can configure a default router and a backup router, as shown here.
Parameter
Description
VIP Address
VIP address on AppDirector for which default gateway is set. This

includes Layer 4 Policy addresses, Virtual IP Interface Addresses, etc.
A special entry for Virtual IP 0.0.0.0 is automatically inserted into the
VIP NHR table, reflecting the AppDirector default router from the
Routing Table.
Default: 0.0.0.0
NHR Weight
Weight that AppDirector considers when distributing sessions of the

Virtual IP among the NHRs, ensuring that each session uses a single
NHR.
Default: 1
Backup NHR IP Address
The backup router for this Virtual IP.

Default: 0.0.0.0, no NHR is set.
394

Parameter
Description
Backup NHR Weight
Backup weight that AppDirector considers when it distributes sessions

of Virtual IP among the NHRs.
Default: 1
No Route Action
If both routers set for a VIP are down, AppDirector behaves as follows:
Discard: Discards the packet.
Use Regular Routing (Default): Uses the Routing Table.
NHR Load Sharing
Enables or disables load sharing between the primary and backup

NHRs, as follows:
Layer 3 Hashing: Traffic is sent through both primary NHR and
backup NHR. Load sharing is based on Layer 3 information (IP
addresses).
Layer 4 Hashing: Traffic is sent through both primary NHR and
backup NHR. Load sharing is based on Layer 4 information (IP
addresses and ports).
Disabled (Default): Traffic is sent through primary NHR only.
When a default router and a backup router are configured, you can send outgoing traffic through
both NHRs simultaneously. AppDirector performs load sharing between the NHRs of the traffic that
arrives from the farms, using Hashing on the Source and Destination IP addresses. This ensures that
each session uses a single NHR.
Note: When a server participates in multiple farms, each with a different NHR, AppDirector
makes sure to use a NAT address, which is a VIP address that has an active NHR. This
means AppDirector keeps a list of up to three VIPs to which a server belongs. When a
NAT address for the server is needed, AppDirector uses only VIPs with an active NHR.
395

Example Default Router per VIP

Figure 18 - Default Router Per VIP, page 396, illustrates a typical configuration where a default
router is defined for each VIP on AppDirector.
Figure 18: Default Router Per VIP

ISP 1
ISP 2
Router 1
Router 2
201.1.1.20
202.2.2.20
201.1.1.1
Port 1
202.2.2.10
AppDirector
VIP: 201.1.1.10
VIP: 202.2.2.10
Port 2
10.1.1.10
Server 1
10.1.1.1
Server 2
10.1.1.2
Properties:
VIP 1 uses Router 1
VIP 2 uses Router 2
AppDirector general traffic users Router 1 Configuration
Using Redirect to Self in Multi-Homed Environments

Redirect to Self is the ability to redirect clients accessing a VIP to another VIP on the same
AppDirector device. The Redirect to Self capability can be used in various configurations and serve
various needs. Take, for example, a Multi-homed environment. Farm 1 can redirect requests for
service to Farm 2, while Farm 2 redirects to Farm 1, where Farm 1 and Farm 2 are on the same
AppDirector, each accessible via a different ISP.
Configuration of the Redirect to Self capability in AppDirector is based on defining farms as servers.
You can set up a farm using other farms as servers in your farm. The type of server used in this
configuration is the LocalFarm server type. The LocalFarm server is another farm on the same
396

AppDirector. When using redirection based on IP addresses, the IP representing the LocalFarm is an
IP address that can be accessed by the clients; usually a public IP address. The Redirect to Self
capability works with the following redirection methods: DNS, SIP, HTTP, and RTSP.
Note: Redirect to Self cannot be used with Global Triangulation.

In a Multi-homed environment, the Redirect to Self capability can be utilized to share traffic between
multiple ISPs, where AppDirector is directly connected to the access routers of these ISPs. Using this
configuration, you can load balance not only between servers, but also between ISP routers.
Note: This configuration requires the NHR per VIP feature (see Default Router Per Virtual IP,
page 393).
Example Redirect to Self

For example, AppDirector is connected to two ISPs, where Router 1 is connected to ISP 1, and
Router 2 is connected to ISP 2. Two identical farms (containing the same servers) are configured on
the AppDirector device, each associated with an IP address that belongs to one of the ISPs and with
a default router which is the router of the ISP. Router 1 is the default router of Farm 1, and Router 2
is the default router of Farm 2. Then, Farm 1 is added as a server for Farm 2, and Farm 2 as a server
for Farm 1. This enables Farm 1 to redirect clients to VIP 2 representing Farm 2, and vice versa.
When a client accesses Farm 1, a server is selected in this farm using the predefined Dispatch
Method.
If the server Farm 2 is selected, redirection takes place. Using this configuration, you can achieve
load balancing not only between the servers, but also between the routers of the ISPs. This figure
illustrates this configuration.
Example Multi-homed Environment

This figure presents a regular configuration of a Multi-homed environment where AppDirector is
connected to multiple ISPs.
397

Figure 19: Multihomed Environment

ISP 2
ISP 1
Router 1
Router 2
201.1.1.20
202.2.2.20
201.1.1.10
202.2.2.10
Port 1
AppDirector
VIP: 202.2.2.10
VIP: 201.1.1.10
Port 2
10.1.1.10
Server 2
Server 1
10.1.1.1
10.1.1.2
Properties
Traffic is shared between multiple ISPs.
When a client accesses Farm 1, a server is selected in this farm, by the usual load balancing
considerations. If server Farm 2 is selected, then redirection takes place.
Using this configuration, the user achieves load balancing not only between the servers, but also
between the routers of the ISPs.
Segmentation
This section discusses the use of segmentation when working with AppDirector in the network and
includes the following topics:
Segmentation Overview, page 398
Implementing Segmentation with AppDirector, page 400
Segmentation Overview
Segmentation involves dividing your network into logical segments, where a single AppDirector load
balances the traffic for all segments, but traffic between segments is always inspected by a external
inspection device (e.g. firewalls, anti-virus device etc.)
Using Segmentation, a single AppDirector device connects to multiple segments around the firewall
(see Figure 20 - Physical Port Segmentation, page 399). AppDirector forces the traffic originating in
one firewall segment and destined to a different segment to pass through the firewall. This also
applies when the Destination IP is a VIP of the Layer 4 Policy that resides on the same AppDirector
device.
398

Notes:
>> You have to attach the VIP to a "different segment" otherwise the traffic from the
"firewall segment" to a VIP in the default segment will be redirected to the "firewall"
segment NHR on the request path.
>> On the reply path the behavior will be according to the non-segment-action parameter.
Figure 20: Physical Port Segmentation

Firewall
Interface 2
DMZ2
VIP
Interface 1
10.10.10.2
20.20.20.2
10.10.10.1
20.20.20.
Interface 2
DMZ1
VIP 10.10.10.100
Interface 1
AppDirector
Segmentation can be configured using physical ports, as shown here. Physical switches ports that
connect computing devices (nodes) can be logically grouped together to form segmented virtual
LANs on the same physical switch. VLANs require switches that have managed Layer 2 switching
capabilities. Switches without management capabilities are usually not capable of implementing
VLANs.
Segmentation can also be configured using VLAN tags, as shown here.
Figure 21: VLAN Tag Segmentation

Clients
Firewall
AppDirector
Tag 20
Tag 10
DMZ 2
VIP 2
DMZ 1
VIP 1
399

Implementing Segmentation with AppDirector

When implementing Segmentation with AppDirector, you define a type of network entity known as a
segment. Segments are logical entities that can be associated either with physical ports (including
VLANs and Trunks) or with VLAN Tags. A NHR must be associated with each segment. Typically this
would be the firewall interface of that segment. A backup NHR can also be configured for each
segment.
Layer 4 policies are also associated with segments, to define the logical location of each VIP.
Segmentation is performed when there is a conflict between the segment to which the client belongs
and the segment to which the Layer 4 policy belongs. AppDirector directly redirects traffic for a
Layer 4 policys VIP only when the traffic arrives from a client in the same segment where this policy
resides.
When the device receives traffic that cannot be handled due to segment conflicts, (meaning the
segment over which traffic was received does not match the Layer 4 policy segment) the device
sends this traffic to the NHR of the receiving (clients) segment, while reply traffic is forwarded from
the server to the NHR of the Layer 4 policy segment.
Default Segments
Physical ports, Trunks and 802.1q VLAN Tags that are not part of any segment are considered to be
members of a default segment.
No specific NHR is defined for the default segment, but the default gateway belongs to the default
segment.
Traffic from a client belonging to segment to a destination (the default segment for the server or
VIP) will be redirected via the segment NHR. However, the reply will be redirected according to the
Default Segment Operating Method.
Note: If you want to allow asymmetric routing, on an ODS 3 platform, the Session Table must
to be disabled in order for the traffic to be correctly routed.
Configuring Segmentation
1. Enable Segmentation and configure default segment behavior
2. Configure Segments and attach NHRs.
Notes:
>> AppDirector default gateway can only belong to the default segment.
>> Device management can only be performed via a port or VLAN tag that belongs to the
default segment.
400

Segmentation Configuration
To set the Segmentation Global Parameters

1. From the AppDirector menu, select Segmentation > Global Parameters. The Segmentation
Global Parameters window is displayed.
Parameter
Description
Segmentation
Operating Method
Select one of the following operating methods:

Ports Segmentation is enabled and is based on the device physical
ports, trunks or VLANs.
VLAN Tag Segmentation is enabled and based on the 802.1q
environment. When the VLAN Tag mode is in use, the 802.1q
environment must be enabled and the Multi-VLAN Tag Handling
parameter must be set to Overwrite.
Disable (default): The feature is disabled.
Shared Ports
The segmentation shared port list. This is used to configure Ports or

VLANs.The device will not perform segmentation on any sessions from or
to these Layer 2 interfaces (ports, trunks and/or VLANs). To disable the
feature set an empty string.
Notes:
Traffic from a default segment to a shared port will be routed
normally and will ignore the Default Segment Operating Method.
Shared ports cannot be VLANs.
Default Segment
Operating Method
Physical ports, Trunks and 802.1q VLAN Tags that are not part of any
segment are considered to be members of a default segment. You can
configure the behavior of traffic from a port or tag that is not a member
of any segment and is destined to a port or tag that is a segment
member.
Select the Default Segment Operating Method, from one of these:
Forward (Handling without Segmentation): Forwards traffic to
destination (not via a firewall)- as if Segmentation was disabled.
Discard: Discards the traffic.
Default Gateway (Handling with Segmentation if necessary)(Default): Forwards the traffic to the AppDirector Default gateway
with Segmentation, if necessary.
Notes:
Traffic from a shared port to a VIP (Load balanced) or directly to a
server (Routing) will be sent directly.
Load balancing to a VIP and the selected server is on a shared port the shared port is unrelated in this scenario. Segmentation will
never occur between the VIP and the server's segment.
Segmentation conflict might happen here but this depends on the
client and VIP parameter.
401

Parameter
Description
Default Segment
Shared VIP
This shows segmentation prevention for sessions from the server to the
Layer 4 policy with this segment. When disabled, the segmentation will
not be honored.
Enables you to provide clients in any other segment direct access,
without passing via the firewall, to the Layer 4 policy VIPs belonging to
this segment.
Default: Disabled
Note: Segmentation is always applied to traffic from other segments
to IPs belonging to servers in this segment.
... next to Shared Ports. The Arguments for Port List window is displayed as shown here.
3.
Click
4.
Mark the port check boxes as required.
5.
Click Set. You are returned to the Segment Table window.
6.
Segment Table
The Segment Table allows you to create segments and associate physical ports, VLANs Trunks or
802.1q VLAN Tags to the segment. Sometimes you need to use a single AppDirector device to load
balance multiple farms, each located on a different segment around a firewall.
In such cases, AppDirector must ensure that all traffic between segments passes through the
firewall.
To define the parameters of the Segment Table

1.
From the AppDirector menu select Segmentation > Segment Table. The View Filters window
is displayed.
2.
Click Create. The Segment Table Create window is displayed.
3.
Set the parameters.
402
Parameter
Description
Segment Name
Enter a name for the new segment.
Port List
Allows you to associate Fast Ethernet ports, Giga Ethernet ports or

trunk ports with the segment.
VLAN Tag List
VLAN tag associated with this segment.

Parameter
Description
Shared VIP
Enables you to provide clients in any other segment direct access,

without passing via the firewall, to the Layer 4 policy VIPs belonging to
this segment.
Values: Enable or Disable (default)
Note: Segmentation is always applied to traffic from other segments
to IPs belonging to servers in this segment, (routed traffic).
Backend
Segmentation
This defines the behavior when the Layer 4 policy (VIP) and server
providing service to this VIP belong to different segments.
Values:
Enabled (default): Performs segmentation (forward traffic to Layer
4 policy segment NHR).
Disabled: Forwards traffic directly to server.
4. Click
... next to Port List. The Arguments for Port List window is displayed as shown here.
5. Mark port check boxes as required.

6. Click Set. You are returned to the Segment Table window.
Segmentation NHR
The Segmentation NHR Table is used to assign and update next hop routers to segments. A NHR
must be associated with each segment. Typically this would be the firewall interface of that
segment. When AppDirector receives traffic that cannot be handled due to segment conflicts (that
is, the segment over which traffic was received does not match the segment over which traffic
should be forwarded), AppDirector sends this traffic to the NHR of the receiving segment
To assign an NHR to a segment

1. From the AppDirector menu select Segmentation > Segment NHR. The Segmentation NHR
2. Click Create. The Segment NHR Table Create window is displayed
Parameter
Description
Segment Name
Select the segment name from the drop-down list.
NHR IP Address
IP hop of the next router.
Backup NHR IP
Address
IP of the Backup to NHR.
403

Parameter
NHR Weight
Description
Configure a weight for each NHR.
Default: 1
Backup NHR Weight
Define a backup weight for the NHR.

Default: 1
NHR Load Sharing
Enabling NHR Load Sharing sends outgoing traffic through both NHRs
at the same time.
Default: Disabled
No Route Action
Allows you to configure AppDirector behavior when both the main and
backup NHRs are down.
Values:
Discard (default): Discards the traffic
Use Regular Routing: Sends traffic according to the regular route
4.
To update a segment NHR

1.
From the AppDirector menu select Segmentation > Segment NHR. The Segmentation NHR
2.
Select the desired segment name. The Segment NHR Table Update window is displayed
3.
Set the parameters as shown in assign an NHR to a segment.
4.
Session Initiation Protocol (SIP)

This explains SIP server load balancing and client-server persistency and includes these topics:
SIP Load Balancing with AppDirector, page 405
Farm Selection Based on SIP Parameters, page 405
Load Balancing SIP Servers, page 405
Outbound SIP Sessions, page 406
The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating,
modifying and terminating sessions with one or more participants. These sessions include internet
telephone calls, multimedia distribution, and multimedia conferences. However, it can be used in any
application where session initiation is a requirement. SIP works with several other protocols and is
only involved in the signalling portion of a communication session. SIP acts as a carrier for the
Session Description Protocol (SDP), which describes the media content of a session, e.g. what IP
ports to use, the codec being used etc. All voice or video communications are performed over
separate session protocols, usually RTP.
404

SIP Load Balancing with AppDirector

AppDirector provides the following support for load balancing SIP traffic:
Application specific health checks using the OPTIONS SIP method, see Health Checks Per Farm,
page 333.
Application-aware farm selection for SIP over UDP (Layer 7 policies).
Application-aware server persistency for SIP over UDP, see SIP Persistency, page 261.
Note: For SIP over TCP, AppDirector offers Layer 4 farm selection and server persistency, and
application specific health check
Farm Selection Based on SIP Parameters

AppDirector can be used to provide Layer 7 farm selection based on SIP header data for SIP over
UDP. The same Layer 7 methods for HTTP can be used for SIP. Using Layer 7 Policies, you can select
different farms based on different parameters.
For example, one farm can handle all the SIP Registration and a second farm handles the SIP call
setup and termination. Layer 7 Policies allow redirection of the session when a specific policy is
matched. This can be done using the 302 return status code.
Load Balancing SIP Servers

In SIP protocol, IP addresses can be embedded in SIP headers and SDP data. This poses a problem
when load balancing SIP traffic. The SIP server that handles the traffic will respond using its own IP
address in the SIP data. Since the client who sent the traffic to AppDirector expects an answer at the
SIP level (not UDP level) from VIP, this will cause the SIP session to fail.
Here are a few available options for solving this issue:
1. Define the SIP servers as Local Triangulation servers in AppDirector.
a.
b.
On each SIP server configure the loopback adapter with a SIP service VIP.
AppDirector will send the traffic to the loopback address of the selected server and the
server will use this address inside the SIP payload in the answer.
Note: The network configuration does not need to be Local Triangulation - response traffic can
return via AppDirector, (AppDirector must be the default gateway for the servers).
2. Define the SIP servers as Regular servers in AppDirector.
a.
b.
c.
On each SIP server, there is a physical IP interface. Configure a second IP interface using the
SIP service VIP. This can be configured on the physical adapter, a loopback adapter or a
virtual adapter.
Bind the SIP application to this interface, instead of the physical IP interface.
AppDirector sends traffic to the physical address of the server and the server will use this
address inside the SIP payload in the answer.
SIP sessions always load balance with servers per session, even if you define eps or regular Sessions
Mode on the farm.
405

Outbound SIP Sessions

Outbound SIP sessions must use Server NAT to hide server IP address behind service IP (VIP). Since
all sessions from servers within the SIP farm are forwarded using the same IP address as a Source
IP and the same source port, AppDirector needs a special process to return the traffic to the initiator
server. Dynamic Sessions ID must be used, and the Learning Direction must be set to Both
Directions. Then, AppDirector returns the traffic based on any of the SIP headers, such as Call-ID.
All traffic is routed via AppDirector when using such configurations.
Support for Outbound SIP sessions has a performance impact. To prevent this, the feature must be
activated by flagging Outbound SIP only when required (disabled by default). This flag is available in
WBM via the AppDirector > Global >Tweaks window, (see Configuring AppDirector Advanced
Global Parameters, page 289) and in CLI via appdirector global outbound-sip command.
The Layer 4 policy can either use port 5060 and UDP as the Layer 4 protocol or specify SIP as the
application.
Notes: Please note that when Outbound SIP traffic needs to be supported the following
requirements must be met:
>> Servers from which outbound traffic is sent can only belong to farms that are attached
to a SIP Layer 4 policy - to ensure a SIP service VIP is used as Server NAT.
>> If Layer 7 load balancing is used (for the inbound SIP Layer 4 policies), DSID must be
enabled for all the farms that belong to that Layer 7 policy.
Stream Control Transmission Protocol (SCTP)

Stream Control Transmission Protocol (SCTP) is a Transport Layer protocol, serving in a similar role
to the popular protocols Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). It
provides some of the same service features, ensuring reliable, in-sequence, transport of messages
with congestion control. In the absence of native SCTP support in operating systems you can tunnel
SCTP over UDP, and map TCP API calls to SCTP ones.
SCTP is a reliable transport protocol operating on top of a potentially unreliable connectionless
packet service such as IP. It offers acknowledged error-free non-duplicated transfer of datagrams
(messages). Detection of data corruption, loss of data and duplication of data is achieved by using
checksums and sequence numbers. A selective retransmission mechanism is applied to correct loss
or corruption of data.
The decisive difference from TCP is multi-homing and the concept of several streams within a
connection. In TCP, a stream is referred to as a sequence of bytes, but in a SCTP, a stream
represents a sequence of messages (and these may be very short or long).
SCTP can be used as the transport protocol for applications where monitoring and detection of loss
of session is required. For such applications, the SCTP path or session failure detection mechanisms,
especially the heartbeat, will actively monitor the connectivity of the session.
An SCTP association looks like this, so the services of SCTP are naturally at the same layer as TCP or
UDP services.
406

Figure 22: Diagram showing the concept of an SCTP association
:
We define a single-home SCTP association as a connection between two single IP addresses. A
multi-home SCTP association is a connection between multiple addresses. Both client and server can
supply additional addresses on top of the one that is carried in the L3 header.
The client sends the additional IP addresses in the INIT packet while the server sends the additional
IP addresses in the INIT-ACK packet.
When NAT is performed for SCTP the INIT and INIT-ACK packets should be updated and the SCTP
association should be supported.
SCTP Load Balancing with AppDirector

AppDirector supports Layer 4 load balancing for SCTP. The following SCTP communication types are
supported:
Single-homed SCTP
Multi-homed SCTP
NAT for outbound SCTP
Note: Layer 7 load balancing is not supported for SCTP.
Single-homed SCTP
A single-home SCTP association is a connection between two single IP addresses.
To support single-homed Layer 4 load balancing, the following configuration is required in the Layer
4 policy:
Protocol set to SCTP
Application set to SCTP
407

Multi-homed SCTP
A multi-homed SCTP association is a connection between multiple addresses belonging to the same
entities. Both client and server can supply additional addresses on top of the one that is carried in
the L3 header.
The client sends the additional IP addresses in the INIT packet while the server sends the additional
IP addresses in the INIT-ACK packet.
To support multi-homed association for inbound traffic the following configuration is required:
A farm with one regular server and one backup server for each external link
Layer 4 policy with VIP for each external link:
Protocol set to SCTP
Application set to MH-SCTP
The SCTP server answers with multiple internal IP addresses in the INIT-ACK message (a server IP
from each farm). AppDirector must NAT all addresses to their respective VIPs (VIP to each server is
associated).
Note: Sessions Mode Regular and Client NAT cannot be used for multi-homed SCTP
associations.
Outbound SCTP
For outbound SCTP traffic AppDirector can NAT all the IP addresses that appear in the INIT message.
See also Outbound NAT Addresses, page 286.
To configure NAT for outbound SCTP

1.
Configure Outbound NAT range with NAT Mode set to SCTP NAT.
2.
Configure Outbound NAT Intercept range that includes the SCTP servers and connect to the
appropriate Outbound NAT range. The two ranges must have the same size.
Note: Outbound NAT is performed only for SCTP traffic initiated by servers that are defined as
farm servers on AppDirector.
Performance Statistics
This section discusses general performance indicators (statistics) and includes the following topics:
Acceleration Engine Statistics, page 409.
Last Second Statistics, page 423.
Element Statistics, page 424.
IP Interface Statistics, page 428.
Servers, page 430.
AppDirector Statistics, page 432.
TCP Splitting Statistics, page 433.
Protocol Statistics, page 435.
408

Acceleration Engine Statistics
You also have the ability to take a comprehensive view of monitoring and statistics information
through the WBM. Acceleration engine data is shown in aggregated tables that facilitate a quick
check on the Acceleration Engine status and value. Using these statistics tables, you can drill down
to a specific interface, Layer 4 policy or Rule-list rules.
Notes:
>> All Views are set to refresh automatically according to the refresh rate specified in
configuration view.
>> In WBM, all statistics pages allow you to filter for viewing only specific items.
>> The configurable statistics measuring period and WBM view Auto-refresh time are shown
at the bottom of each statistics window. To edit go to Configuration, page 421.
Throughput Summary
From the Performance menu, select Acceleration > Throughput> Summary. The Acceleration
Engine Throughput Summary window is displayed with these read-only parameters:
Parameter
Description
Client Side Throughput Mbits In - Average of incoming traffic from clients into the
Acceleration Engine per second.
Mbits Out - Average of outgoing traffic towards clients from the
Total (In + Out) - Average of total clients related traffic going in both
ways through the Acceleration Engine per second.
Server Side
Throughput
Mbits In - Average of incoming traffic from servers into the

Mbits Out - Average of outgoing traffic towards servers from the
Total (In + Out) - Average of total servers related traffic going in both
ways through the Acceleration Engine per second.
Total Throughput
Mbits In - Average of incoming traffic coming into the Acceleration

Engine per second.
Mbits Out - Average of outgoing traffic from the Acceleration Engine
per second.
Total (In + Out) - Average of total traffic going in both ways through
the Acceleration Engine per second.
409

Throughput per Layer 4 Policy

From the Performance menu, select Acceleration > Throughput> Per L4 Policy. The
Acceleration Engine Throughput Per L4 Policy window is displayed with these read-only parameters:
Parameter
Description
Client Side Throughput
Mbits In - Average of incoming traffic from clients into the

Acceleration Engine per second per Layer 4 policy.
Mbits Out - Average of outgoing traffic towards clients from the
Total (In + Out) - Average of total clients related traffic going in
both ways through the Acceleration Engine per second per Layer 4
policy.
Server Side Throughput
Mbits In - Average of incoming traffic from servers into the

Mbits Out - Average of outgoing traffic towards servers from the
Total (In + Out) - Average of total servers related traffic going in
both ways through the Acceleration Engine per second per Layer 4
policy.
Total Throughput
Mbits In - Average of incoming traffic coming into the Acceleration

Engine per second per Layer 4 policy.
Mbits Out - Average of outgoing traffic from the Acceleration
Engine per second per Layer 4 policy.
Total (In + Out) - Average of total traffic going in both ways
through the Acceleration Engine per second per Layer 4 policy.
Note: Statistics shown for all Layer 4 policies also include their Acceleration capabilities, that
is. their traffic flows through Acceleration Engine. A Layer 4 policy that does not include
any Acceleration policy (SSL, Cache, compression, Multiplexing) will not show this view.
Connections Summary
From the Performance menu, select Acceleration > Connections> Summary. The Acceleration
Engine Connections Statistics Summary window is displayed.
Parameter
Description
Client Side Concurrent Connections
Current Number of clients concurrent connections held by

Acceleration Engine.
Client Side New Connections
Counted Number of new clients connections opened by

Acceleration Engine every measuring period.
Server Side Concurrent Connections
Current Number of concurrent servers connections held by

Acceleration Engine.
Server Side New Connections
Counted Number of new servers connections opened by

Acceleration Engine every measuring period.
Total Concurrent Connections
Total Counted Number of clients connections opened by

Acceleration Engine every second.
Total New Establish Connections
Total Counted Number of new clients connections opened

by Acceleration Engine every second.
410

Parameter
Description
Connections Multiplexing Percentage

(Server or Client Connections)
Percentage of number of clients connections and server

connections that shows how well the Acceleration Engine
decreases the connection load on servers at the time of
measuring (instantaneous measuring).
New Connections Establishing Rate

(Conn/Sec)
Average number of connections opened to or by the

Connections per Layer 4 Policy

From the Performance menu, select Acceleration > Connections> Summary. The Acceleration
Engine Connections Statistics Per L4 Policy window is displayed.
Parameter
Description
Client Side Connections
Concurrent
Current Number of clients concurrent connections held

by Acceleration Engine per Layer 4 policy.
New
Counted Number of new clients connections opened by

Acceleration Engine every second per Layer 4 policy.
Concurrent
Current Number of concurrent servers connections held

by Acceleration Engine per Layer 4 policy.
New
Counted Number of new servers connections opened by

Concurrent
Total Counted Number of clients connections opened by

New
Total Counted Number of new clients connections

opened by Acceleration Engine every second per Layer
4 policy.
Server Side Connections
Total Connections
Multiplexing Percentage
Percentage of the number of clients connections and server connections

that shows how well the Acceleration Engine decreases the connection
load on servers at the time of measuring (instantaneous measuring) per
Layer 4 policy.
New Connections/Sec
Average number of new connections opened by Acceleration Engine per

second per Layer 4 policy.
HTTP Requests Summary

From the Performance menu, select Acceleration > HTTP> Requests And Responses
>Summary. The Acceleration Engine HTTP Requests Summary window is displayed.
Parameter
Description
Requests - Clients > AppDirector
Number of clients requests from AppDirector done in the

measuring period.
Requests - AppDirector > Servers
Number of AppDirector requests from Servers done in the

measuring period.
411

Parameter
Description
Responses - Servers > AppDirector
Number of Servers responses to AppDirector in the

measuring period.
Responses - AppDirector > Clients
Number of AppDirector responses to Clients in the

measuring period.
HTTP Transaction Rate
Transactions per seconds rate calculated by total number of

transactions divided by measuring period.
HTTP Requests per Layer 4 Policy

From the Performance menu, select Acceleration > HTTP> Requests And Responses >Per L4
Policy. The Acceleration Engine HTTP Requests Per L4 Policy window is displayed.
Parameter
Description
L4 Policy
Name of L4 Policy for which this row shows statistics.
Requests
Clients -> AE
Number of clients requests from AppDirector done in the

measuring period per Layer 4 policy.
AE -> Servers
Number of AppDirector requests from Servers done in the

Clients -> AE
Number of Servers responses to AppDirector in the

AE -> Servers
Number of AppDirector responses to Clients in the measuring

period per Layer 4 policy.
Responses
Transaction/Sec.
Transactions per seconds rate calculated by total number of transactions

divided by measuring period per Layer 4 policy.
HTTP Statistics Summary

From the Performance menu, select Acceleration > HTTP> Statistics >Summary. The
Acceleration Engine HTTP Statistics Summary window is displayed.
Parameter
Description
Clients Using Keep-Alive
Number of clients counted sending "Connection:

Keep-Alive" HTTP Header or Using HTTP 1.1.
HTTP 1.0 Percentage
Percent of requests done using HTTP 1.0 during

measuring period.
HTTP 1.1 Percentage
Percent of requests done using HTTP 1.1 during

measuring period.
Number of HTTP to HTTPS redirections
Number of HTTP redirect location headers updated

from HTTP to HTTPS by AppDirector.
Average Number of Requests per

Connection
Average number of requests done over each client

connection calculated by total number of client
request divided by number of clients side connections.
412

Parameter
Description
Number of responses smaller than 1KB
Number of Responses for which content size reported

smaller than 1KB.
Number of responses 1KB - 10KB

between 1KB and 10KB.


Number of responses larger than 100KB

larger than 100KB.
HTTP Statistics per Layer 4 Policy

From the Performance menu, select Acceleration > HTTP> Statistics >L4 Per Policy. The
Acceleration Engine HTTP Statistics Per L4 Policy window is displayed.
Parameter
Description
L4 Policy
Name of L4 Policy for which this row shows

statistics.
Clients Using Keep Alive
Number of clients counted sending

"Connection: Keep-Alive" HTTP Header or
Using HTTP 1.1 per Layer 4 policy.
HTTP 1.0 v 1.1 Percentage
Percentage of the number of HTTP statistics

per Layer 4 policy.
HTTP to HTTPS Redirections
Number of HTTP redirect location headers

updated from HTTP to HTTPS by AppDirector
per Layer 4 policy.
Average Requests/Connection
Average number of requests done over each

client connection calculated by total number
of client request divided by number of clients
side connections per Layer 4 policy.
Number of responses per Content

size
Smaller than
1KB
Number of Responses for which content size

reported smaller than 1KB per Layer 4 policy.
1KB - 10KB

reported between 1KB and 10KB per Layer 4
policy.
11KB - 50KB

reported between 11KB and 50KB per Layer 4
policy.
51KB -100KB

reported between 51KB and 100KB per Layer
4 policy.
Larger than
100KB

reported larger than 100KB per Layer 4 policy.
413

SSL Statistics Summary

From the Performance menu, select Acceleration > SSL> Statistics Summary. The Acceleration
Engine SSL Statistics Summary window is displayed.
Parameter
Description
New SSL handshake (Session/Sec)
Number of New SSL handshakes between Clients and

AppDirector per second.
Reused SSL sessions (Session/Sec)
Number of Existing SSL Handshakes reused by clients to

communicate with AppDirector per second.
Reused SSL sessions (%)
Percentage of SSL session reusing keys.
SSLv2 Percentage
Percentage of session using SSLv2 out of all session during

measuring period.
SSLv3 Percentage

measuring period.
TLS Percentage
Percentage of session using TLS out of all session during

measuring period.
SSL Statistics per Layer 4 Policy

From the Performance menu, select Acceleration > SSL> Statistics per L4 Policy. The
Acceleration Engine SSL Statistics Per L4 Policy window is displayed.
Parameter
Description
Name
New Handshakes/Sec
Number of New SSL handshakes between Clients and

AppDirector per second per Layer 4 policy.
Reused Sessions /Sec
Number of Existing SSL Handshakes reused by clients to

communicate with AppDirector per second per Layer 4 policy.
Reused Session Percentage
Percentage of SSL session reusing keys per Layer 4 policy.
SSL V2 Percentage

SSL V3 Percentage

TLS Percentage
Percentage of session using TLS out of all session during

Note: Statistics displayed for all Layer 4 policies also includes their Acceleration capabilities,
(their traffic flows through Acceleration Engine). A Layer 4 policy that does not include
any Acceleration policy (SSL, Cache, compression, Multiplexing) does not show this
view.
414

Cache Summary
From the Performance menu, select Acceleration > Cache > Summary. The Cache Summary
Parameter
Description
Number of Objects Served from

Cache
Number of Objects served by cache within the measuring

period.
Cache Hits Percentage
Percent of HTTP requests served by objects from cache.
Cache Serving Rate (Requests/

Second)
Rate of requests served by cache every second, calculated by

total number of requests served by cache divided by
measuring period.
Number of New Cached objects
Amount of new objects cached by size during the measuring

period.
Object Caching Rate (Requests/

Second)
Average number of objects cached by size every second

calculated by amount of new cached objects divided by
measuring period.
New Cached Bytes
Amount of new bytes cached by size during the measuring

period.
Byte Caching Rate (Bytes/Second)
Average number of bytes cached every second calculated by

amount of new bytes objects divided by measuring period.
Objects of Average Size Smaller

than 10KB
Amount of objects cached by size during last measuring

period of Average size smaller than 10KB.
Objects of Average Size 11KB100KB

period of Average size between 11KB and 100KB.
Objects of Average Size 101KB-1MB Amount of objects cached by size during last measuring
period of Average size between 101KB and 1MB
Objects of Average Size Larger than Amount of objects cached by size during last measuring
1MB
period of Average size larger than 1MB.
415

Cache Rates per Layer 4 Policy Summary

From the Performance menu, select Acceleration > Cache > Rates per L4 Policy. The Cache
Rates Per L4 Policy window is displayed.
Parameter
Description
Name
Number of Objects Served
Number of Objects served by cache within the measuring period per

Layer 4 policy.
Cache Hits%
Percent of HTTP requests served by objects from cache per Layer 4

policy.
Cache Requests/Sec
Rate of requests served by cache every second, calculated by total

number of requests served by cache divided by measuring period per
Layer 4 policy.
New Cached Objects
Amount of new objects cached during the measuring period per Layer
4 policy.
Objects/sec Cached
Average number of objects cached every second calculated by amount

of new cached objects divided by measuring period per Layer 4 policy.
New Cached Bytes
Amount of new bytes cached during the measuring period per Layer 4
policy.
Bytes/Sec Cache
Average number of bytes cached every second calculated by amount

of new bytes objects divided by measuring period per Layer 4 policy.
is, their traffic flows through Acceleration Engine. A Layer 4 policy that does not include
Cache Statistics per Layer 4 Policy

From the Performance menu, select Acceleration > Cache > Statistics per L4 Policy. The Cache
Statistics per L4 Policy window is displayed.
Parameter
Description
Name
Name of Layer 4 policy for which this row shows statistics.
Objects of Average
Size
Smaller than 10K

period of Average size smaller than 10KB per Layer 4
policy.
11KB - 100KB

period of Average size between 11KB and 100KB per
Layer 4 policy.
101KB - 1MB

period of Average size between 101KB and 1MB per
Layer 4 policy.
Larger than 1MB

period of Average size larger than 1MB per Layer 4
policy.
416

is, their traffic flows through Acceleration Engine. A Layer 4 policy that does not include
Cache URL-Exceptions Rule-Lists

From the Performance menu, select Acceleration > Cache > URL- Exceptions > Rule-Lists
Statistics. The Cache URL-Exceptions Rule-Lists Statistics window is displayed.
Parameter
Description
Name
Cached Objects
Number of objects cached per URL Exceptions policy.
Cached Bytes
Number of bytes cached per URL Exceptions policy.
Cache URL Rule-List per Rule

From the Performance menu, select Acceleration > Cache > URL- Exceptions > Rule-Lists perRule Statistics. The Cache URL-Exceptions Rule-Lists per-Rule Statistics window is displayed.
Parameter
Description
Rule List Name
There are multiple rule-lists. Each is a policy that contains multiple

rules.
Rule Name
Rule Priority
Behavior, page 219 on how to use the priority efficiently.
Cached Objects
Number of objects cached as a result of matching the rule.
Cached Bytes
Number of bytes cached as a result of matching the rule.
Notes:
>> You can use URL files to specify folders or file types to be cached or not cached. You can
do this by entering a string in the URL filed containing only the file extension or folder
name.
>> If these strings appear elsewhere in the URL, they will also be matched.
Cache Content
You can download a file containing the entire list of objects residing in cache at download time.
1. From the Performance menu, select Acceleration > Cache > Cache Content. The
Acceleration Engine Cache Object-List window is displayed.
2. To save the file listing all cache content, select Save Cache Dump file.
3. A dialog box is displayed asking you if you wish to open or save the Cache Dump file.
417

4.
If you click Open, a Microsoft Excel .csv file will open displaying the following parameters:
Parameter
Description
URL
Objects full URI path.
Size (KB)
Size of the cached object.
Chunked
Is object stored chunked?

Values Yes or No.
The same object can be cached more than once in a chunked copy and
unchunked copy.
Compressed
Is object stored or compressed?

Values: Yes or No.
Last Access
5.
Date or Time of last access to objects.
If you click Save, you are prompted to save a .csv file in the following default format:
yyyy-mm-dd-hh-mm-ss_cache_dump_file.csv based on your current device system

time.
Compression Summary
From the Performance menu, select Acceleration > Compression > Summary. The Compression
Summary window is displayed.
Parameter
Description
Uncompressed Throughput (Kbps)
Total Throughput of compressible objects before

compression counted during measuring period.
Average Uncompressed Object Size (Kbps) Average object size before compression.
Compressed Throughput (Kbps)
Total Throughput of compressible objects after

compression counted during measuring period.
Average Compressed Object Size (Kbps)
Average object size after compression.
Average Compression Percentage (%)
Average compression percentage during measuring

period calculated by average uncompressed size
divided by average compressed size.
418

Compression Statistics per Layer 4 Policy

From the Performance menu, select Acceleration > Compression > Statistics per L4 Policy.
The Compression Statistics Per L4 Policy window is displayed.
Parameter
Description
Name
Uncompressed Throughput (KB)
Total Throughput of compressible objects before compression

counted during measuring period per Layer 4 policy.
Average Uncompressed Size (KB)
Average object size before compression per Layer 4 policy.
Compressed Throughput (KB)
Total Throughput of compressible objects after compression

counted during measuring period per Layer 4 policy.
Average Compressed Size (KB)
Average object size after compression per Layer 4 policy
Compression Percentage
The compression percentage is measured by ((Server Side

Objects accumulative size) (Client Side Objects
accumulative size))*100/(Server Side Objects accumulative
size). e.g. 1MB received from server 400KB sent to client =
60% compression by (1000-400)*100/1000.
Note: Statistics shown for all Layer 4 policies also include their Acceleration capabilities, i.e.
their traffic flows through Acceleration Engine. A Layer 4 policy that does not include any
Acceleration policy (SSL, Cache, compression, Multiplexing) will not show this view.
Compression URL- Exceptions Rule-Lists

From the Performance menu, select Acceleration > Compression > URL - Exceptions > RuleLists Statistics. The Compression URL-Exceptions Rule-Lists Statistics window is displayed.
Parameter
Description
Name
Name of Compressions URL Exception Policy for which this row shows
statistics.
Matched Objects
Number of objects matched during measuring period by the URL

Exception Policy for which this row shows statistics.
Size Before Compression Total uncompressed size of objects matched during measuring period by
the URL Exception Policy for which this row shows statistics.
Size After Compression
Total compressed size of objects matched during measuring period by

419

Compression URL- Exceptions Rule-List per Rule

From the Performance menu, select Acceleration > Compression > URL- Exceptions > RuleList per Rule Statistics. The Compression URL-Exceptions Rule-List per Rule Statistics window is
displayed.
Parameter
Description
Rule List Name
There are multiple rule-lists. Each Rule-List is a policy that contains

multiple rules.
Rule Name
Rule Priority
Behavior, page 219on how to use the priority efficiently.
Matched Objects
Number of objects matched by this rule during measuring period.
Size Before Compression
Total size of all matched objects before compression.
Total size of all matched objects after compression.
Compression percentage per rule.
Notes:
>> You can use URL files to specify folders or file types to be compressed or not
compressed. You can do this by entering a string in the URL filed containing only the file
extension or folder name.
>> If these strings appear elsewhere in the URL, they will also be matched.
Compression Browser-Exceptions Rule-Lists

From the Performance menu, select Acceleration > Compression > Browser - Exceptions >
Rule-Lists Statistics. The Compression Browser-Exceptions Rule-Lists Statistics window is
displayed.
Parameter
Description
Name
Name of Compressions URL Exception Policy for which this row shows
statistics.
Matched Objects
Number of objects matched during measuring period by the URL

Exception Policy for which this row shows statistics.
Total uncompressed size of objects matched during measuring period

by the URL Exception Policy for which this row shows statistics.
Total compressed size of objects matched during measuring period by

Compression Browser-Exceptions Rule-List per Rule

From the Performance menu, select Acceleration > Compression > Browser- Exceptions >
Rule-List per Rule Statistics. The Compression Browser-Exceptions Rule-List per Rule Statistics
Parameter
Description
Rule List Name
There are multiple rule-lists. Each Rule-List is a policy that contains

multiple rules.
420

Rule Name
Rule Priority
Behavior, page 219 on how to use the priority efficiently.
Matched Objects
Number of objects matched by this rule during measuring period.
Total uncompressed size of all objects matched by this rule.
Total compressed size of all objects matched by this rule.
Percentage of compressed and uncompressed size of all objects

matched by this rule.
Configuration
1. From the Performance menu, select Acceleration > Compression > Configuration. The
Acceleration Engine Configuration window is displayed.
Parameter
Description
Statistics measuring period

(Sec)
Defines time period in which values are being collected. Data

always shows results of previous measuring period.
All measuring and statistics are performed within a defined timeframe. This parameter allows controlling this time frame. Since
numbers are updated at the end of every measuring period, a
longer period will give better Averages results but will lower the
ability to see real time monitoring values.
Default: 5 seconds.
WBM Statistics display auto- Defined the period after which the WBM display will automatically
refresh (Sec)
refresh to show recently measured values.
421

Bandwidth Management Statistics

The following are relevant when running a Bandwidth Management policy.
Policy Statistics Global Parameters Status

You can enable or disable the monitoring of policy statistics and adjust the monitoring period, using
the Policy Statistics Global Parameters window.
To configure Policy Statistics Global Parameters

1.
From the Performance menu, select BWM Policy Statistics Global Parameters. The Policy
Statistics Global Parameters window is displayed.
Parameter
Description
Statistics measuring
period (Sec)
Defines the time period in which values are being collected. Presented
data always shows results of previous measuring period.
All measuring and statistics are performed within a defined timeframe. This parameter allows controlling this time frame. Since
numbers are updated at the end of every measuring period, a longer
period will give better Averages results but will lower the ability to see
real time monitoring values.
Default: 5 seconds.
WBM Statistics display Defined the period after which the WBM display will automatically
auto-refresh (Sec)
refresh to show recently measured values.
2.
3.
422
Set the parameters.
Parameter
Description
Policy Statistics
Monitoring
Enables or disables (default) the monitoring of policy statistics by the

device.
Policy Statistics
Reporting Period
Amount of time, in seconds, that policy statistics should be monitored.
SRP
Enables or disables (default) SRP.
Default: 60

Last Second Statistics

The Policy Statistics window enables you to view the policy statistics.
Note: To view this table, Application Servers Statistics, page 430 must be enabled.
To view Policy Statistics for the last second

From the Performance menu, select BWM Policy Statistics > Last Second Statistics. The Policy
Statistics Table window is displayed with the following parameters.
Parameter
Description
Policy Name
The name of the displayed policy.
Packets (sec)
The number of packets matching the policy during the last second.
Matched BW (Kbits)
The amount of matched bandwidth.
Sent BW (Kbits)
The amount of bandwidth sent during the last second.
Last Period Statistics
To view Policy Statistics for the last period

1. From the Performance menu, select BWM Policy Statistics > Last Period Statistics. The
Policy Statistics Table window is displayed, which contains the following parameters.
2. Select the name of a specific Policy. The Policy Statistics Table window is displayed, which
contains the following read-only parameters.
Parameter
Description
Policy Name
The name of the displayed policy.
Packets (sec)
The number of packets matching the policy during the last period.
Matched BW (Kbits)
The amount of matched bandwidth.
Sent BW (Kbits)
The amount of bandwidth sent during the last period.
423

Element Statistics
Element statistics contains several indicators for viewing AppDirector performance. They include:
IP Packet Statistics, page 424
SNMP Packet Statistics, page 425
IP Router Statistics, page 426
OSPF Packet Statistics, page 427
Resource Utilization Statistics, page 428
IP Packet Statistics
The IP Packets Statistics window allows you to view statistics for the IP elements of the device.
To view IP Packet statistics

From the Performance menu, select Element Statistics > IP. The IP Packets Statistics window is
displayed.
Parameter
Description
IP Receives
Total number of input datagrams received from interfaces, including

those received in error.
IP Header Errors
Number of input datagrams discarded due to header error due to errors

in their IP headers, including bad checksums, version number
mismatch, other format errors, time-to-live exceeded, errors
discovered in processing their IP options, etc.
IP Discarded
Total number of input datagrams discarded. Note: This counter does

not include any datagrams discarded while awaiting re-assembly.
IP Successfully Delivered
Total number of input datagrams successfully delivered to IP userprotocols (including ICMP).
IP Out Requests
Total number of IP datagrams, which local IP user-protocols (including

ICMP) supplied to IP in requests for transmission.
IP Out Discard
Number of output IP datagrams for which no problem was encountered

to prevent their transmission to their destination, but which were
discarded (e.g., for lack of buffer space).
424

SNMP Packet Statistics

The SNMP Packet Statistics window enables you to view statistics for the devices SNMP elements.
To view SNMP packet statistics

From the Performance menu select Element Statistics > SNMP. The SNMP Packets Statistics
.
Parameter
Description
SNMP Received Packets Total number of messages delivered to the SNMP entity from the transport
service.
SNMP Sent Packets
Total number of SNMP messages passed from the SNMP protocol entity to
the transport service.
SNMP Successful 'Get'

Requests
Total number of MIB objects retrieved successfully by the SNMP protocol

entity as the result of receiving valid SNMP Get-Request and Get-Next
PDUs.
SNMP Successful 'Set'

Requests
Total number of MIB objects altered successfully by the SNMP protocol

entity as the result of receiving valid SNMP Set-Request PDUs.
SNMP 'Get' Requests
Total number of SNMP Get-Request PDUs processed PDUs accepted and

processed by the SNMP protocol entity.
SNMP 'Get-next'
Requests
Total number of SNMP Get-Request PDUs accepted and processed by the

SNMP protocol entity.
SNMP 'Set' Requests
Total number of SNMP Set-Request PDUs accepted and processed by the

SNMP protocol entity.
SNMP Out 'TooBig'
Total number of SNMP PDUs generated by the SNMP protocol entity and
for which the value of the error-status field is 'tooBig.'
SNMP Out
'NoSuchName'
for which the value of the error-status is 'noSuchName.'
SNMP Out 'BadValue'
for which the value of the error-status field is 'badValue.'
SNMP Out 'GenErrs'
for which the value of the error-status field is 'genErr.'
SNMP Out 'GetResponses'
Total number of SNMP Get-Response PDUs generated by the SNMP

protocol entity.
SNMP Out Traps
Total number of SNMP Trap PDUs generated by the SNMP protocol entity.
425

IP Router Statistics
The IP Router Statistics window allows you to view statistics for the IP Router elements of the
device.
To view IP Router statistics

From the Performance menu select Element Statistics > IP Router. The IP Router Statistics
window is displayed and contains these read-only parameters:
Parameter
Description
IP Forwarded
Number of input datagrams for which this entity was not their final IP
destination, as a result of which an attempt was made to find a route to
forward them to that final destination. In entities, which do not act as
IP Gateways, this counter will include only those packets that were
Source - Routed via this entity, and the Source - Route option
processing was successful.
IP Unknown Protocol
Number of locally-addressed datagrams received successfully but

discarded because of an unknown or unsupported protocol.
IP Out No Routes
Number of IP datagrams discarded because no route could be found to

transmit them to their destination. This counter includes packets
counted in ipForwDatagrams which meet this `no-route' criterion.
Notes:
This includes datagrams, which a host cannot route as all its
default gateways are down.
This counter includes any packets counted in ipForwDatagrams,
which meet the `no-route' criterion. It also includes datagrams
that cannot be routed as all its default gateways are down.
IP Fragments Received
Number of IP fragments received which needed to be reassembled at

this entity.
IP Fragments Successfully Number of IP datagrams successfully re-assembled.

Re-assembled
IP Fragments Failed Reassembly
Number of failures detected by IP re-assembly algorithm (reason:

timed out, errors, etc).
Note: This is not necessarily a count of discarded IP fragments since
some algorithms (notably the algorithm in RFC 815) can lose track of
the number of fragments by combining them when received.
IP Datagrams Successfully Number of IP datagrams successfully fragmented at this entity.

Fragmented
IP Datagrams Discarded Failed Fragmentation
Number of IP datagrams discarded because they needed to be

fragmented at this entity but could not be, e.g., because their Don't
Fragment flag was set.
IP Datagram Fragments
Generated
Number of IP datagram fragments generated as a result of

fragmentation at this entity.
IP Datagram Fragments
Generated
Number of IP datagram fragments generated as a result of

fragmentation at this entity.
Valid Routing Entries

Discarded
Number of valid routing entries discarded.
426

Parameter
Description
RIP - Changes Made to IP

Route Database
Number of changes made to the IP Route Database by RIP.
RIP - Global Responses

Sent to RIP Queries
Number of responses sent to RIP queries from other systems.
OSPF Packet Statistics

Open Shortest Path First (OSPF) is an interior gateway routing protocol developed for IP networks.
OSPF is based on the shortest path first or link-state algorithm. Routers use link-state algorithms to
send routing information to all nodes in a network by calculating the shortest path to each node,
based on a topography of the internet constructed by each node.
After sending the routing information, each router sends the portion of the Routing Table (keeps
track of routers to particular network destinations) that describes the state of its own links, and the
complete routing structure (topography). Shortest path first algorithms allow for more frequent
updates.
With OSPF, you can build a more stable network as fast convergence prevents such problems as
routing loops and Count-to-Infinity (when routers continuously increment the hop count to a
particular network).
The OSPF Packet Statistics window allows you to view statistics for the OSPF packet statistics
elements of the device.
To view OSPF packet statistics

From the Performance menu select Element Statistics > OSPF. The OSPF Packet Statistics window
is displayed, which contains the following read-only parameters.:
Parameter
Description
OSPF - New LSAs

originated
Reports the number of originating OSPF link-state advertisements in the

link-state database.
OSPF - LSAs received - The number of link-state advertisements received that are determined to
new instantiations
be new instantiations. This number does not include newer instantiations
of self-originated link-state advertisements
427

Resource Utilization Statistics

The Resource Utilization window allows you to view statistics on for the device's average resource
utilization.
To view resource utilization statistics

From the Performance menu, select Element Statistics > Resources. The Resource Utilization
window is displayed, which contains the following read-only parameters:
Parameter
Description
Resource Utilization
Percent of device's CPU currently utilized.
RS Resource Utilization
Percent of device's RS resource currently utilized.
RE Resource Utilization
Percent of device's RE resource currently utilized.
Last 5 sec. Average

Utilization
Last 60 sec. Average

Utilization
Acceleration-Engine Cores
These statistics measure CPU utilization per accelerator.
Parameter
Description
Accel-Engine System Total Percentage of Acceleration engine RAM allocated for cache occupied on
Memory
measuring time. Also see Caching Policies, page 220.
Values: 1 - 50%
Default: 20%
Acceleration-Engine id 1
% CPU Utilization per accelerator
IP Interface Statistics
The IP Interface Statistics window allows you to monitor the number of packets discarded and
ignored, enabling you to quickly summarize the state of network congestion from a given interface.
To view IP statistics
1.
From the Performance menu select; IP Statistics. The IP Statistics window is displayed.
2.
Select the desired interface entry. The IP Statistics Update window is displayed.
428

Parameter
Description
Interface Address
IP address of the selected interface.
RIP - Response Packets Number of RIP responses received by RIP process which were
Discarded
subsequently discarded for any reason.
Discard Examples:
version 0 packet
unknown command type
packet was smaller than the minimum size allowed for IPRIP
packets.
received a packet with an invalid version in its header.
received a packet with an invalid header.
discarded a response packet from a neighbor with IP address:
%1. IPRIPv2 is not configured to accept packets from this
neighbor.
discarded a version: %1 packet received on the interface with IP
address: %2 from a neighbor with IP address: %3. The above
interface is configured to accept only version: %4 packets.
discarded a packet received on the interface with IP address: %1
from a neighboring router with IP address: %2, because the
packet failed authentication.
discarded a response packet from a neighbor with IP address:
%1. The packet was not sent from the standard IP RIP port (520).
RIP - Routes Ignored
Number of routes, in valid RIP packets, ignored for any reason.

Ignore Examples:
unknown address family.
invalid metric.
discontiguous networks (major nets separating other major nets).
new route is inferior to previous one prior to update.
certain RIP implementations set up to ignore host routes.
response did not originate from a RIP port.
RIP - Updates Sent
Number of triggered RIP updates sent on this interface. This explicitly

does NOT include full updates sent containing new information.
4. Click Set. The status is changed.
429

Servers
As part of AppDirectors toolset, you can monitor server performance including server status, traffic
load and numbers of connections and disconnections.
Application Servers Statistics

The Application Server Statistics window allows you to view performance statistics of the application
servers.
To monitor application server statistics

1.
From the Performance menu, select Server > Application Server Statistics. The Application
Server Statistics window is displayed.
2.
From the Farm drop down list, select the farm for which you want to present the servers
summary. The Application Servers Summary table displays the following read-only statistics:
Parameter
Description
Status
The status of the farm/server:

Active The farm/the server is up and running. A farm is active
when it has at least one server up and running.
No New Sessions No new sessions can be forwarded to the
farm/server due to overload.
Not in Service This farm/server is not available. A farm is not
available when all its servers are Not In Service.
Farm/Server
Name of farm/server, (click the farm or server name to read the

confirmation go to the respective farm/server configuration window).
Kbits
Amount of traffic in kbits forwarded to/from the farm/server in the last

second.
Packets
Amount of packets forwarded to/from the farm/server in the last

second.
Connections
Number of concurrent connections established with the farm/server.

Current displays the current number of concurrent
connections active on the farm/server.
Peak displays the maximum number of concurrent connections
active on the farm/server since device reboot or statistics reset.
Total displays the total number of all connections that were
opened to the farm/server since device reboot or statistics reset.
430

Parameter
Description
TCP Disconnections
Number of disconnections in the TCP sessions established with the

farm/server.
Current displays the number of TCP connections to the farm/
server terminated during the last second.
Peak displays the maximum number of TCP connections to the
farm/server terminated per second since device reboot or
statistics reset.
Total displays the total number of TCP connections to the
farm/server terminated since device reboot or statistics reset.
New TCP Connections
Number of TCP connections with the farm/server.

Current displays the number of new TCP connections opened
to the farm/server during the last second.
Peak displays the maximum number of TCP connections per
second opened to the farm/server since device reboot or statistics
reset.
Total displays the total number of TCP connections opened to
the farm/server since device reboot or statistics reset.
3. To define the frequency in which the summary is refreshed, in the Refresh Interval text box,
type the number of seconds and click Set.
4. To reset statistics, click Set.
Physical Servers Statistics

The Physical Server Statistics window allows you to view performance statistics of the physical
servers.
To monitor physical server statistics

1. From the Performance menu, select Server > Physical Server Statistics. The Physical Server
Statistics window is displayed.
2. The Physical Servers Summary table displays these read-only statistics.
Parameter
Description
Status
The status of the farm or server:

Active: the server is up and running
No New Sessions: No new sessions can be forwarded to the farm/
server.
Not in Service: This server is not available.
Physical Server
Name of farm or server, (click the farm or server name to read the
confirmation window).
Kbits
Amount of traffic in kbits forwarded to or from farm or server.
Packets
Amount of packets forwarded to or from farm or server.
Connections
Number of connections established with the farm or server.
431

Parameter
Description
TCP Disconnections Number of disconnections in the TCP sessions established with the farm or
server.
New TCP
Connections
Number of TCP connections established with the farm or server.
Note: Incoming connections are those accepted by the server. Outgoing connections are those
initiated by the server.
3.
To define the frequency in which the summary is refreshed, in the Refresh Interval text box,
4.
To reset statistics, click Set.
AppDirector Statistics
The AppDirector statistics window enables you to monitor specific AppDirector elements providing
you with a picture of how well AppDirector is performing using measures of Client table and
Proximity table fillup or Redundancy failure.
To monitor AppDirector statistics

From the Performance menu, select AppDirector Statistics. The AppDirector Statistics window is
displayed, which contains the following read-only parameters:
Parameter
Description
Redundancy Failure
Indicates that the AppDirector failed.
Redundancy Takeover
Indicates that the AppDirector failed.
Client Table Fillup
Indicates that the client table filled up.
Proximity Table Fillup
Indicates how many times the proximity redirection method was

reached.
DNS Request (last second)
Number of DNS queries received in last second
DNS Replies (last second)
Number of DNS queries answered in last second.
432

TCP Splitting Statistics
TCP Splitting is the ability to maintain open concurrent connections opposite all servers providing
Diameter or LDAP services, while a single connection was opened by the client.
The TCP Splitting Statistics window allows you to view performance statistics of the TCP distribution
process for each AppXcel Front-End farm and its servers.
To monitor TCP Splitting Statistics

1. From the Performance menu, select TCP Splitting Statistics. The TCP Splitting Statistics
2. From the Farm drop down list, select the farm for which you want to present the TCP splitting
summary. The TCP Splitting Summary table displays the following read-only statistics:
Parameter
Description
Refresh Interval
How often the data is automatically refreshed.

Update
Click to refresh the display.
Reset
Click to reset the statistics to zero.
For each physical server, the following information is displayed:
Note: C = Current, P = Peak, T = Total
Parameter
Description
Status
Status of the farm or server. One of the following:

Active. For a farm, all servers in the farm are active.
No New Sessions (NNS). For a farm, none of the servers have new
sessions.
Not In Service (NIS). For a farm, no servers in the farm are in
service.
In a farm, at least one server is NIS or NNS
Farm/Server
Kbits
Name of the farm or server

In
Out
Packets
In
Out
Number of Kilo-bits received by the server since the Reset button was last
pressed.
Number of Kilo-bits transmitted by the server since the Reset button was
last pressed.
Number of packets received by the server since the Reset button was last
pressed.
Number of packets transmitted by the server since the Reset button was
last pressed.
433

Parameter
Description
Connections
Current number of inbound connections (the number of client table

entries with type Regular).
Peak number of inbound connections (the number of client table entries

with type Regular) since the Reset button was last pressed.
Total number of inbound connections (the number of client table entries

with type Regular) since the Reset button was last pressed.
TCP Connections C
New TCP
Connections
Application
Connections
Number of TCP connections to the server that were terminated during the
last second.
Peak number of TCP connections to the server that were terminated

during one second since the Reset button was last pressed.
Total number of TCP connections to the server that were terminated since
the Reset button was last pressed.
Number of new TCP connections that were opened to the server during
the last second.
Peak number of new TCP connections that were opened to the server
during one second since the Reset button was last pressed.
Total number of new TCP connections that were opened to the server
since the Reset button was last pressed.
Number of application handshakes that the AppXcel device counted

during the last 5 seconds.
LDAP: the number of bind messages
Diameter: the number of CER messages
Application
Disconnections
Peak number of application handshakes that the AppXcel device counted.
Total number of application handshakes that the AppXcel device counted.
Number of application messages that terminated the connection during

the last 5 seconds.
LDAP: the number of unbind messages
Diameter: the number of DPR (Disconnect Peer Request) messages
Application
Request
Application
Failure
Peak number of application messages that terminated the connection.
Total number of application messages that terminated the connection.
Number of application messages forwarded and load-balanced by the

AppXcel device between all servers during the last 5 seconds. Note: Not
including handshake and disconnection messages.
Peak number of application messages forwarded and load-balanced by the

AppXcel device during one second between all servers.
Total number of application messages forwarded and load-balanced by the

AppXcel device between all servers.
Number of application messages with errors (indicated by a field in the

message) during the last 5 seconds.
Peak number of application messages with errors during one second.
Total number of application messages with errors.
3.
To define the frequency in which the summary is refreshed, in the Refresh Interval text box,
4.
To reset statistics, click Set. Your configuration is set.
434

Protocol Statistics
You can display complete protocol statistics information using this feature. If enabled, Protocol
Discovery classification is performed only on traffic to or from the configured default gateway.
Protocol Statistics Global Parameters

You can configure the global parameters of protocol statistics using the Protocol Statistics Global
Parameters window.
To configure Protocol Statistics Global Parameters

1. From the Performance menu, select Protocol Statistics > Global Parameters. The Protocol
Statistics Global Parameters window is displayed
Parameter
Description
Status
This variable indicates whether the device will gather protocols'

statistics
Default: Enable or Disable
Protocol Statistics
Reporting Period
[secs.]
Amount of time that protocol statistics should be monitored.
SRP Destination
Address
IP Address of the SRP. The statistics will be sent to this address in SRP
mode.
Default: 60
Default: 0.0.0.0
SRP
Configures the protocol statistics reporting operation

Values: Enables or disables (default) SRP.
Protocol Statistics
Aging
Period in which table entries are kept until removed.

Default: Entries Lifetime

You need to be aware of the different applications running on your network and the amount of
bandwidth they consume. To allow a full view of the different protocols running on the network there
is a protocol discovery feature that can be activated on the entire network or on separate subnetworks by defining Protocol Discovery policies in the Protocol Discovery Policies window.
To set the Protocol Discovery Policies

1. From the Performance menu select, Protocol Statistics > Protocol Discovery Policies. The
Protocol Discovery Policies window is displayed.
2. Click Create. The Protocol Discovery Policies Create window is displayed.
435

3.
Set the parameters.
Parameter
Description
Name
Index
Location of policy in protection table that reflects the order in which the
classification is performed.
Destination
Defines destination of the traffic. Can be specific IPs, or a range of IP

addresses or IP Subnet address. Default is any which covers traffic to
any destination.
Source
Defines source of traffic. Can be specific IPs, or a range of IP addresses

or IP Subnet address. Default is any which covers traffic from any
source.
Destination MAC
Address Group
Enables you to discover applications and protocols present in traffic sent

to a transparent network device.
Default: None
Source MAC Address Enables you to discover applications and protocols present in the traffic
Group
sent by a transparent network device (firewall, router).
Default: None
Inbound Physical
Port Group
Classifies only traffic received on certain interfaces of the device. Enables

you to set different policies to identical traffic classes received on
different interfaces of the device.
Default: None
VLAN Tag Group
Defines VLAN traffic classification according to VLAN ID (VLAN Identifier)

tags.
Default: None
Direction
Defines the direction of the traffic.

Values One Way (from Source to Destination) /Two Way (Default)
Operational Status
Select either Active (Default) or Inactive.
Indicates whether classification is done before or after packet

modification.
After Changes (Default): Classifies the device after the packet
changes.
4.
436

View Protocol Statistics

The Protocol Statistics Table window enables you to view the protocol statistics.
Note: To view this table, Protocol Statistics Monitoring must be enabled. See Protocol Statistics
Global Parameters, page 435.
To view the Protocol Statistics Table

From the Statistics menu, select Protocol Statistics and then choose View Protocol Statistics.
The Protocol Statistics Table window is displayed, which contains the following parameters:
Parameter
Description
Policy Name
Name of the policy.
Protocol
IP protocol.
Port
TCP or UDP port used by the protocol.
Bandwidth
Total bandwidth per second used for this protocol during the last period.
Peak Bandwidth
Peak bandwidth per second used for this protocol during the last period.
Packets
Total number of packets per second used for this protocol during the last
period.
Statistics Monitor
This section shows you how to configure and send statistics to or from the Statistics Monitor.
Statistics Monitor SRP

The SRP Management Host IP Address window is used to create statistics files on a remote machine.
To send statistics from/to the Statistics Monitor

1. From the Services menu, select Statistics Monitor > SRP. The SRP Management Host IP
Address window is displayed.
2. Type the SRP Management Host IP Address: The IP address of the machine where to create
the statistics files. This is normally the machine where either the web-based software is running.
3. Click Set. The statistics are sent to the statistics monitor.
437

Statistics Monitor Configuration

The Statistics Monitor window is used to create statistics files on a remote machine.
To send statistics from the AppDirector to the Statistics Monitor

1.
From the Services menu, select Statistics Monitor > Configuration. The Statistics Monitor
Configuration window is displayed.
2.
Set the parameters.
Parameter
Description
Statistic Reporting
Mode
Enables or disables the creation of statistics files. You can choose what
kind of statistics to broadcast:
Full: Broadcasts all statistics
Disable (Default): Disables broadcasting
Flow: Broadcasts statistics concerning flow
Health: Broadcasts statistics concerning health
Flow Statistics Polling How often, in minutes and seconds, to update the statistics file with
Time [sec]
new flow rate data. The file is cumulative, and new data is added to
existing data.
Health Statistics
Polling Time [sec]
3.
How often, in minutes and seconds, to update the statistics file with
new health data. The file is cumulative, and new data is added to
existing data.
Note: Since the statistics files are cumulative, you must ensure that you disable the Statistic
Reporting Mode before you create files larger than you desire. Failure to do so can result
in creating files that fill all available memory.
438

Utilities
This section contains additional device-related AppDirector utilities and includes these topics:
DNS Client, page 439
Time Settings, page 440
Event Scheduler, page 442
DNS Client
You can configure AppDirector to operate as a DNS client. When the DNS client is disabled, IP
addresses cannot be resolved. When the DNS client is enabled, you need to configure servers for
which AppDirector will send out queries for host name resolving.
You can set the Domain Name Service parameters in the DNS Client Parameters window. You can
define the primary and the alternate DNS servers for dynamic DNS. In addition you can set static
DNS parameters.
To define DNS servers

1. From the Services menu, select DNS. The DNS Client Parameters window is displayed. with
parameters shown below.
Parameter
DNS Client
Description
Status of DNS Client.
Enabled or Disabled (default) DNS client functionality.
Primary DNS Server
The primary DNS server address that should be used by the device for
DNS
Alternate DNS Server
The alternate DNS server address that should be used by the device
for DNS
2. To define the primary DNS server, in the Primary DNS server box type the IP address of the
primary DNS server and click Set.
3. To define the alternate DNS server, in the Alternate DNS server box type the IP address of the
alternate DNS server and click Set.
Note: Primary and alternate DNS server addresses contain the default value 0.0.0.0. If you
decide to delete primary or secondary DNS server addresses, which are already
configured with a different value, you can reset them back to this default value - 0.0.0.0
To set static DNS

1. From the Services menu, select DNS. The DNS Client Parameters window is displayed.
2. Click Create. The Static DNS Table Create window is displayed
439

3.
4.
Set the parameters.
Parameter
Description
Host Name
Domain name for the specified IP address.
IP Address
IP address for the specified domain name.
Click Set.Your configuration is set.
Time Settings
This collection of utilities helps you to synchronize and configure devices for appropriate daylight
saving periods. Utilities included are:
Configuring Network Time Protocol, page 440.
Daylight Saving, page 440.
Date and Time, page 442.
Configuring Network Time Protocol

Network Time Protocol (NTP) enables users to synchronize devices by distributing an accurate clock
across the network. In predefined intervals, a device sends time query messages to the Network
Time Server. The server returns the date and time to the device.
Enabling or disabling the NTP feature results in different levels of accuracy. When NTP is disabled,
the devices time and date have to be set manually. When NTP is enabled, several parameters need
to be configured: the IP address of the Network Time Server, the polling interval (in seconds), the
time zone offset from GMT, and the NTP server port (default 123).
To define the NTP parameters

1.
From the Services menu select Time Settings > NTP. The Network Time window is displayed
2.
Set the parameters.
3.
Parameter
Description
NTP Server
IP address of the NTP server.
NTP Polling Interval [sec]
Amount of time between sending of requests to the NTP server.
NTP Time Zone
Time zone in which the device is located, in correlation to GMT (12:00 to + 12:00 hours).
NTP Server Port
Access port number for the NTP server.
NTP Status
Status of NTP function, either Enable or Disable (Default). When

this feature is disabled the time and date must be set manually.
Daylight Saving
Radware devices support daylight saving time. You need to configure the start and end date of the
daylight saving time. During the daylight saving time period, the device automatically adds one hour
to the system clock. The device also indicates whether it is on standard time or daylight saving time
using the Daylight Saving Designations indicator.
440

To configure the Daylight Saving hours

1. From the Services menu, select Time Settings > Daylight Saving. The Daylight Saving
window is displayed with the following parameters:
Parameter
Description
Daylight Saving
Admin Status
Enables and disables (default) Daylight Saving feature.
Daylight Saving
States the Daylight Saving Designation zone
Designations (Readonly)
Starts [dd/mm:hh]
Click the dotted icon alongside. A pop-up is displayed. Enter the date and
time from which Daylight Saving starts with the following parameters:
Mode: Date - an absolute date to configure OR
Recurring: - if it is the same instance for start or/and end (e.g. DST
always starts on the 1st Sunday in April)
Month: January-December
Day: 1-31
Hour:0-22
Start Date and Time Shows the Start date and time in full as follows e.g. TUE JUL 01 02:00:00
(Read Only)
2007.
Ends [dd/mm:hh]
Click the dotted icon alongside. A pop-up is displayed. Enter the date and
time when Daylight Saving ends as follows:
Mode: Date - an absolute date to configure OR
Recurring: - if it is the same instance for start or/and end (e.g. DST
always starts on the 1st Sunday in April)
Month: January-December
Day: 1-31
Hour:1-23
End Date and Time

(Read Only)
Shows the End date and time in full as follows e.g. TUE JAN 01 02:00:00
2008.
Delta
Difference between Daylight Savings Time and Standard Time Setting.

The number of hours by which the clock is to be adjusted is configurable
using the Delta parameter.
Default: 1 hour
441

Date and Time
To configure the Date and Time

1.
From the Services menu, select Time Settings > Date and Time. The Daylight Saving System
date and Time window is displayed with the following parameters.
2.
Set the parameters according to the explanations providedparameters.
3.
Parameter
Description
System Time
[hh:mm:ss]
Manages the device's system time, in the format hh:mm:ss.
System Date
[dd/mm/yyyy]
Manages the device's system date, in the format dd/mm/yyyy.
Event Scheduler
Some network policies remain inactive during specific hours of the day and are activated during
others. For example, an enterprise may give high priority to mail traffic between 08:00 - 10:00.
Sometimes within networks we need specific policies to remain inactive during certain hours of the
day, or for a certain policy to be activated in the middle of the night. For example - a school's library,
may want to block instant messaging during school hours, but allowing instant messages after
school hours or an enterprise may give high priority for mail traffic between 08:00 - 10:00. You can
schedule the activation and inactivation of specific Bandwidth Management policies using the Event
Scheduler, which can then be attached to a policy's configurations. Events define the date and time
in which an action must be performed.
To configure the Event Scheduler

1.
From the Services menu, select Event Scheduler. The Event Scheduler window is displayed.
2.
Click Create. The Event Scheduler Create window is displayed.
3.
Set the parameters.
Parameter
Description
Name
A user defined name for the event.
Frequency
Defines the event frequency, whether it occurs once, daily or weekly.
Time (hh:mm)
The time on the designated day.

Note: If multiple days are selected, then the "Time" value is the same
for all the configured days in which the event occurs.
Default: 12:00 am (0000).
442

Parameter
Description
Days
If Weekly Frequency is selected, you must configure where day the

event occurs.
Date (dd/mm/yyyy)
If Frequency selected is once, then you need to configure the date

where the event occurs.
443

444

Security
Chapter 8 Security
This chapter discusses Security modules and sub-modules, and contains these sections:
AppDirector Device Security, page 445
Keys and Certificates, page 450
Application Security, page 456
AppDirector Device Security

This section describes AppDirector device security interfaces and methods and includes these topics:
Management Ports (Setting Physical Management Ports Restrictions), page 445
Ports Access, page 446
User Table and Authentication, page 446
Caution: All Radware devices include security features and settings that help prevent
unauthorized access and unit tampering.
Management Ports (Setting Physical Management Ports Restrictions)

On AppDirector devices, network traffic to the management port is fully isolated from traffic ports
and therefore no network traffic is forwarded between management and traffic ports. Radware
devices provide a packet-filtering database, which can be configured to control access to and
through the unit, based on various factors, e.g. protocol, port, and source or destination addresses.
Access to devices can be limited to specified physical interfaces. Interfaces connected to insecure
network segments can be configured to discard some or all management traffic directed at the
device itself. Administrators can allow certain types of management traffic to a device (for example;
SSH), while denying others such as SNMP. If an intruder attempts to access the device through a
disabled port, the Radware unit denies access, and generates syslog and CLI traps as notification.
This option enables you to define the permissible management ports using WBM and Telnet.
To configure the Management Ports

1. From the Security menu, select Management Ports. The Management Ports Table window
appears.
2. Select a Port. The Management Ports Table Update window appears.
Parameter
Description
Port Number
Displays the ID number of each physical port.
SNMP
Displays access permission for SNMP configuration for each management

port.
Values: Enable (Default) or Disable.
445

Security
Parameter
Description
Telnet
Displays access permission for Telnet configuration for each management

port.
SSH
Displays access permission for SSH configuration for each management

port.
SSL
Displays access permission for SSL configuration for each management

port.
Web
Displays access permission for Web Based configuration for each

management port.
4.
Select the state from the dropdown lists, Enable or Disable, for each management option.
5.
Ports Access
You can define which physical interfaces can be pinged. When a ping is sent to an interface for which
ping is not allowed, the packet is discarded. By default, all the interfaces of the device allow pings.
To configure physical ports to allow ping

1.
From the Security menu, select Ports Access. The Ports Access window appears.
2.
Select a Port Number link. The Ping Ports Access Update window appears.
3.
In the Ping Device field, select Enabled or Disabled.
Parameter
Description
Port Number
Displays the ID number of each physical port.
Ping State
Enabled (default) - accept Ping operations on the physical port.

Disabled - ignore Ping operations on the physical port.
4.
Click Set. The configuration is updated.
User Table and Authentication

This feature enables you to define additional users to access via Telnet, SSH and Web services (Webbased management and SOAP). This option is password protected with an individual password
configurable for each user, and also may be configured to alert the user to errors in the system via
e-mail. Up to 20 users can be defined.
446

Security
To configure the method of authenticating the user's access

1. From the Security menu, select Users. The User Table and Authentication window appears.
Parameter
Description
Authentication
Method
Method of authenticating a user's access to configuration tool.

Local User Table (Default): Device uses the User Table to
authenticate access.
Radius and Local User Table: Device uses Radius server(s) to
authenticate access. If request to Radius server is timed out,
then the device uses the User Table to authenticate access.
Note: At least one user with read-write access level must be
configured in the local User Table, to enable device access,
even if RADIUS servers are unavailable.
3. Select the appropriate Authentication Method and click Set. The Authentication Method is set.
To configure the Users Table

1. From the Security menu, select Users. The User Table and Authentication window appears.
2. Click Create. The User Table Create window appears.
Parameter
Description
User Name
The name of the user.
Password
The text password for this user.
Email
The e-mail address for this user
Severity
Level of warning required by user. Options are as follows:

None (Default): AppDirector will not send warning messages to
user.
Fatal: AppDirector sends only Fatal messages to User.
Error: AppDirector sends Fatal and Error messages to User.
Warning: AppDirector sends Fatal, Error, Warning messages to
User.
Info: AppDirector sends Fatal, Error, Warning, Info messages to
User.
Access Level
Sets the users level of access to the WBM and CLI interfaces.
Values: Read-Write, Read-Only, None.
447

Security
Parameter
Description
SSH Public Key

Name
Select from the drop-down list, the name of the SSH public key relevant
for this user. This is the name of the certificate table entry where the
SSH public key resides
Note: This public key must have been previously imported into
AppDirector via the Certificates management capability.
4.
RADIUS Authentication
RADIUS (Remote Authentication Dial In User Service), defined in RFC 2865, is a protocol for remote
user authentication and accounting. RADIUS enables centralized management of authentication
data, such as user names and passwords.
When a user attempts to login to a RADIUS client, such as a router, the router send the
authentication request to the RADIUS server. The communication between the RADIUS client and
the RADIUS server are authenticated and encrypted through the use of a shared secret, which is not
transmitted over the network.
RADIUS utilizes the MD5 algorithm for secure password hashing.
Radware and RADIUS Authentication

Radware devices provide additional security by authenticating users accessing the device for
management purposes. Before a management session starts, the device can authenticate the user
with a RADIUS server. These servers determine whether a user can access AppDirector
management, using CLI, Telnet, SSH, or WBM.
If a RADIUS server is not available, then the device uses the User Table to authenticate access.
Therefore, at least one user with a read-write access level must be configured in the local User
Table, to enable device access, even if RADIUS servers are unavailable.
If the remote user is successfully authenticated by the authentication server, the device verifies the
privileges of the remote user and authorizes the appropriate access.
For this purpose, AppDirector searches for Service-Type attribute (AVP 6), built into all RADIUS
servers, in the Access-Accept response.
Read-Write (administrator) user privilege is built into all Radius servers (Service-Type value 6).
Read-Only user privilege (Service-Type value 255) has to be defined in the RADIUS dictionary.
The file name of the dictionary is RADIUS vendor-dependent.
Radware private enterprise code is 89.
Table 7: RADIUS dictionary sample:
Attribute
Service-Type
26
[vid=89 type1=26 len1=+1 data=integer] R
Value
Service-Type
Read-Only
255
448

Security
To configure RADIUS authentication

1. From the Services menu, select Management Interfaces > Admin Radius Authentication.
The Radius Parameters window appears.
Parameter
Description
Main RADIUS IP
Address
IP address of the primary RADIUS server.
Main RADIUS Port

Number
Access port number of the primary Radius server. Access port numbers
can be either 1645 (default) or 1812.
Main RADIUS
Secret
Authentication password for primary RADIUS server.
Backup RADIUS IP
Address
IP address of the backup RADIUS server.
Backup RADIUS
Port Number
Access port number of the backup Radius server. Access port numbers
can be either 1645 (default) or 1812.
Backup RADIUS
Secret
Authentication password for backup RADIUS server.
RADIUS Timeout
Time that device waits for reply from RADIUS server before a retry, or (if
the value RADIUS Retries is exceeded) before the device acknowledges
that the server is offline.
Default: 5
RADIUS Retries
Number of connection retries to RADIUS server, when the RADIUS server

does not respond to first connection attempt.
If RADIUS Retries is exceeded, and if all connection attempts fail (RADIUS
Timeout), the backup RADIUS server is used.
Default: 3
RADIUS Client Life

Time
Duration (in seconds) of client's authentication. After RADIUS Client

Lifetime expires, the device re-authenticates the user.
Default: 30
Default
Authorization
This defines the access level to be provided to a user authenticated by a

RADIUS server, but where user privileges were not provided (or unknown
user privileges were provided).
Values:
Read-Write (default)
Read-Only
No Access (user is denied access)
3. Click Set. The Radius authentication parameters are configured.
449

Security
Keys and Certificates

This section covers keys and certificates management and includes these topics:
Certificates, page 450
Keys, page 450
Certificates Workflows, page 450
Configuration of Keys and Certificates, page 452
Certificates
Certificates are digitally signed indicators which identify the server or user. They are usually
provided in the form of an electronic key or value. The digital certificate represents the certification
of an individual business or organizational public key but can also be used to show the privileges and
roles for which the holder has been certified. It also includes information from a third party verifying
identity. Authentication is needed to ensure that users in a communication or transaction are who
they claim to be. A basic certificate includes:
The certificate holders identity
The certificates serial number
The certificate holders expiry date
A copy of the certificate holders public key
The identity of the Certificate Authority (CA) and its digital signature to affirm the digital
certificate was issued by a valid agency.
Keys
A key is a variable set of numbers that the sender applies to decrypted data to produce encrypted
data, to be sent via the internet. Usually a pair of public and private keys is used. A private key is
kept secret and used, only by its owner, to encrypt and decrypt data. A public key has a wide
distribution and is not secret. It is used for encrypting data and for verifying signatures. One key is
used by the sender to encrypt or interpret the data. The recipient also uses the key to authenticate
that the data comes from the sender.
The use of keys ensures that unauthorized personnel cannot decipher the data. Only with the
appropriate key can the information be easily deciphered or understood. Stolen or copied data would
be incomprehensible without the appropriate key to decipher it and prevent forgery. AppDirector
supports the following key size lengths - 512, 1024 or 2048 bytes.
Certificates Workflows
To create a Certificate Signing Request (CSR)

When a new Certificate is needed, this process should be followed
1.
Create a certificate (see Certificates Table) and select CSR.
2.
Complete the relevant fields (or update the defaults before you start)
3.
Click OK. The Key and CSR are created
4.
Move to the Export Certificates window. Export the CSR to file or Text and send to a Certificate
Signing Authority such as Varisign.
5.
After receiving the signed certificate back from CA, use the Import Certificates window to import
it into the CSR and convert it to a Key and a Certificate.
450

Security
To create a Self-Signed Certificate

If the certificate does not need to be trusted by users (e.g. lab environment or other internal only
cases), AppDirector can create a certificate on its own.
1. Create a Certificate and select Certificate
2. Complete the relevant fields (or update the defaults before you start)
3. Click OK. Key and Certificate are created
To move a Key and Certificate pair from Web server to AppDirector or between
AppDirectors (in redundancy configuration)
1. On the 1st AppDirector machine go to Export Certificates window and select Export Key.
2. On the 1st AppDirector machine go to Export Certificates window and export a Certificate, (if
you have web servers you can export in one PKCS12 unified file).
3. On the 2nd AppDirector machine go to Import Certificates window and select Import Key.
4. On the 2nd AppDirector machine go to Import Certificates window and import Certificate.
To use an Intermediate CA for Signed Certificate

1. In the Import Certificates window, import the Intermediate CA server certificate.
2. In the AppDirector SSL Policy window, select Imported certificate in the Intermediate CA field.
Figure 23 - Intermediate CA, page 451 shows an example of Intermediate CA and its usage.
Figure 23: Intermediate CA
451

Security
Configuration of Keys and Certificates

Keys and certificates are an important part of AppDirector configuration. A key is a set of numbers
or characters used to encode/decode data. A certificate is an electronic identity containing
information about your company and verification from a third party about this identity. Radware
supports the Privacy Enhanced Mail (PEM) and Public Key Cryptography Standard # 12, (PKCS#12)
exchange methods.
PEM - helps to secure email using public key cryptography
PKCS#12 - is a standard for storing private keys and certificates securely and is used in
Internet browsers with their import and export options.
This file format can encrypt and seal private keys and certificates with a digital signature, if
required. It can be imported into the device regardless of encryption. AppDirector can be configured
using an existing key/certificate, or by creating a new key/certificate.
Note: Secure management of PKI components - all certificates and key management
operations can only be performed using secure protocols such as HTTPS, SSH and
SNMPv3. Read-Only capabilities are still available when using HTTP, Telnet or SNMPv1
and v2.
Certificates Table
This table holds all imported and created PKI entities. Each PKI entity in the table has a name used
for viewing the certificate details.
To View/Create/Update the Certificates Table

1.
From the Security Menu, select Certificates > Table. The Certificates window appears.
2.
For Updating, click on the Certificate name. The Certificate Update window appears.
3.
For creating a new certificate, click Create. The Certificate Create window appears
4.
Set the parameters.
Parameter
Description
Name
Name of Key or Certificate.
Entry Type
This displays the type of the entry. With a Certificate or Signing

Request (CSR) type, the entry also includes a Private Key.
Key
Certificate
Signing Request
Intermediate CA certificate
Certificate of Client CA
Key Size
Larger key sizes offer an increased level of security. We recommend

that certificates have a key size of 1024 bits or more.
Using a certificate of this size makes it extremely difficult to forge a
digital signature or decode an encrypted message. Select from (Bytes):
512
1024
2048
452

Security
Parameter
Description
Key Passphrase
The Key Passphrase encrypts the key in storage and is required to

export the key from AppDirector. Since Private Keys are the most
sensitive parts of PKI data they must be protected by passphrase.
A Passphrase should be at least 4 characters and you should use
stronger passphrases than those based on letters, numbers and signs.
Maximum size: 1995 bytes.
Certificate / Certificate Signing Request (CSR) Details

Common Name
The domain name of the organization. For example, www.radware.com
Locality
Name of the city.
State or Province
State or province.
Organization
Name of the organization.
Organization Unit
Department/ Unit within the organization
Country Name
Organization country.
Email
Any email address that you want to include within the certificate.
Certificate Validity
Duration (in days) that the certificate will remain valid.

Values: 1 - 365 days.
Notes:
>> Default values for Certificate and CSR fields can be set in Certificate Defaults, page 456.
>> A key can also be modified into a certificate by importing its corresponding certificates
(to complete the PKI key-pair) to AppDirector.
>> You cannot create a new entry with same name as the key entry.
Certificate Expiry
SNMP traps are sent when certificates are about to expire. They are sent per certificate 30, 15, and
5 days before expiration. You should check only server certificates (used for SSL) in repository once
a day for expiration date.
If Certificate expiration is in 30, 15 or 5,4,3,2,1 days, a SNMP Alert (warning) is generated and if a
Certificate has expired, a SNMP Alert (Error) is generated.
Importing Certificates
This enables you to either import Keys/Certificates from another machine (Duplicate), to import a
Certificate to an existing Signing Request to complete its process, and to import a Intermediate CA
or Certificate of Client CA to be used in Certificate configuration or Client Authentication
configuration.
Keys and Certificates can be imported to AppDirector in either PEM or PKCS#!2 formats. If your key
and certificate are encapsulated in a PKCS#12 (*.p12) file you can import them to AppDirector by
selecting Key & Certificate as entity type. If you have separate PEM files for Key and for certificate
you will need to import them consecutively into the same entity name.
453

Security
To import Certificates
1.
From the Security Menu, select Certificates > Import. The Import PKI Components window
appears showing.
2.
Set the parameters..
Parameter
Description
Entry Name
Input new entry name to create by import, or existing entry name to

overwrite or complete Key or CSR.
Entry Type
The following values are in PEM format:

Key - import key from backup or exported from another machine.
To complete the configuration, you will need to import a certificate
into this key.
Key and Certificate - If your key and certificate are encapsulated
in a PKCS#12 (*.p12) file, you can import them to AppDirector.
Certificate - import certificate from backup or exported from
another machine. The certificate must be imported onto a
matching key or CSR.
Intermediate CA - import a certificate to be used in the SSL
policy. See Intermediate CA in SSL Policies, page 195.
Certificate of Client CA - import a certificate to be used in the
Client Authentication policy Certificate of Client CA field. See
Client Authentication Policies, page 199.
This value is not in PEM format:
Certificate of TSL Root CA - See Configuring TSL Files Chain,
page 206.
Format (Read Only)
Parameter derived from type and displaying the expected file format.
Passphrase
Since Private Keys are the most sensitive parts of PKI data they must
be protected by passphrase.
A Passphrase should be at least 4 characters and you should use
stronger passphrases than those based on letters, numbers and signs.
Text
3.
In this area you can paste Certificate or Key in encrypted text format.
Now, click Import.
Exporting Certificates
Key, Certificate and Signing Request export is used for backup purposes, moving existing
configurations to another machine or for completion of Signing Request processes. Here is a brief
explanation of how to export certificates from a device either by copying and pasting a key or
downloading a file.
Keys and Certificates can be exported from AppDirector in either PEM or PKCS#!2 formats. If you
want to encapsulate key and certificate in a PKCS#12 file (*.p12) you can export them from
AppDirector selecting Key & Certificate as entity type. If you want them as separate PEM files for
Key and for certificate you need to export them consecutively selecting Key and Certificate as
entry types.
454

Security
Note: The Radware key is created without a Radware password at system startup, thus it can
be exported without a Radware password.
To export Certificates
1. From the Security Menu, select Certificates > Export. The Export PKI components window
appears showing. Key, Certificate or CSR.
2. To display an existing key, certificate or CSR with all parameters, click Show. All certificate
details are displayed here.
Parameter
Description
Entry Name
Select name of entry to export.
Entry Type
This displays the type of the entry. In case of a Certificate or Signing

Request (CSR) type the entry also includes a Private Key.
Select from:
Key - import key from backup or exported from another machine. To
complete the configuration, you will need to import a certificate into
this key.
Key and Certificate - If your key and certificate are encapsulated in
a PKCS#12 (*.p12) file, you can import them to SIP Director.
Certificate - import certificate from backup or exported from another
machine. The certificate must be imported onto a matching key or
CSR.
Format
Read-Only parameter derived from the type and displaying the expected
file format.
Passphrase
Required when exporting Keys. Use passphrase entered when key was
created/imported. You need to enter the key passphrase to validate that
you are authorized to export it.
Since Private Keys are the most sensitive parts of PKI data they must be
protected by a passphrase. A Passphrase should be at least 4 characters
and you should use stronger passphrases than those based on letters,
numbers and signs.
Text
In this space the Key/Certificate/CSR text is shown in text format for you
to Copy-paste it, when you use the "show" option.
3. Choose Show or Export. Click Show to display Key/Certificate/CSR in encrypted text format
for copy-paste purposes, e.g. sending CSR to Certificate signing authority.
4. A dialog message appears asking if you want to open or save the certificate file? If you click
Open, the file is opened in a browser window. If you click Save you are prompted to save the
file.
455

Security
Certificate Defaults
This enables you to define your organization's default parameter to be used when creating Signing
Requests or Self-signed certificates.
To view/edit Default Values for Certificates

1.
From the Security Menu, select Certificates > Default Values. The Default Values window
appears.
2.
Set the parameters.
Parameter
Description
Certificate Common
Domain name of the organization. For example, www.radware.com.
Certificate Locality
Name of the city.
Certificate State or
Province
State or province.
Certificate Organization
Name of the organization.
Certificate Organization
Unit
Department/ Unit within the organization
Certificate Country Name Organization country

Certificate Email
3.
Any email address to include within the certificate.
Application Security
This section helps you set up and configure Application Security profiles and contains these topics:
SYN Flood Protection, page 457
Session Table and Session Table Lookup Mode, page 462
The following topics can only be accessed when you are in:
Standard Acceleration Mode
Signature Protection, page 465
Behavioral DoS, page 487
Connection Limit, page 499
Global Suspend Table, page 503
Security Reporting, page 504
Attack Database, page 509
Update Policies, page 512
Packet Anomalies, page 512
Applications only control the use of resources granted to them, and not which resources are granted
to them. They, in turn, determine the use of these resources by users of the application through
application security.
456

Security
Application Security:
provides protection against single or multiple packet attacks that cause denial of service.
encompasses measures taken throughout the application's life-cycle to prevent exceptions in an

applications security policy or the underlying system (vulnerabilities) through flaws in the
design, development, deployment, upgrading, or maintenance of the application.
Application Security profiles:
are part of the protection from and prevention of denial of service attacks.
are predefined traffic detectors that scan incoming traffic identifying known attack signatures.
The profiles use various attacks that find malicious packets and make decisions based on
predefined settings.
SYN Flood Protection

SYN Flood Protection is a service that protects the hosts located behind the device, and the device
itself, from SYN flood attacks, with delayed binding.
A SYN Flood attack is a DoS attack where the attacker sends a huge amount of please-start-aconnection packets but no follow-up packets. The SYN Flood attack is performed by sending a SYN
packet without completing the TCP three-way handshake. Another type of SYN Flood attack is done
by completing the TCP three-way handshake, but without sending data packets afterwards. Radware
provides complete protection against both types of SYN Flood attacks.
These attacks are detected and blocked by SYN Flood Protection Policies.
Before Setting Up SYN Flood Protection

Before activating the SYN Flood Protection module, you need to configure the Session Table to
operate at Layer 4. SYN attack detection is operational only when the device operates at Layer 4.
SYN Flood Protection Settings And Tunings

SYN profiles provide protection against SYN flood attacks. During a SYN flood attack, the attacker
sends a volume of TCP SYN packets requesting new TCP connections without completing the TCP
handshake, or completing the TCP handshake, but not requesting data. This fills up the server
connection queues, denying service to legitimate TCP users. SYN Flood Protection protects the hosts
located behind the device and the device itself from SYN flood attacks by performing delayed
binding. A SYN flood attack is a denial of service attack where the attacker sends a huge amount of
please-start-a-connection packets and then no follow up packets. The SYN Flood attack is performed
by sending a SYN packet without completing the TCP three-way handshake. Another type of SYN
Flood attack is done by completing the TCP three-way handshake, but no data packets are sent
afterwards. Radware provides complete protection against both types of SYN Flood attacks. The
attacks are detected and blocked by SYN Flood Protection Policies. The reports regarding the current
attacks appear in the Active Triggers table.
SYN-ACK Reflection Attacks Prevention

SYN-ACK Reflection Attacks Prevention prevents reflection of SYN attacks and reduces the SYN-ACK
packet storms created as a response to DoS attacks.
When a device is under SYN attack, it sends a SYN-ACK packet with an embedded Cookie, to prompt
the client to continue the session. With DoS SYN attacks, two problems may arise:
Third parties can use the SYN-ACK replies to launch attacks on selected sites by adopting the
selected site's address as the Source IP address of the attack.
The SYN-ACK packets create a storm of reflected traffic that consumes bandwidth and blocks
legitimate traffic.
457

Security
To enable SYN Flood Protection

1.
From the Security menu, select SYN Flood Protection > Global Parameters. The SYN Flood
Protection Parameters window appears.
2.
Set the parameters.
Parameter
Description
SYN Flood Protection

Status
Enables (default) / Disables SYN Flood Protection mode. Values:

Enabled, Disabled, Standby. Standby activates the SYN Flood
Protection module without rebooting the device.
Statistics Max
For each policy, the maximum number of destinations that can be
destinations per policy reflected in the statistics report.
Note: Destination is a single IP, dest port, or RX port.
Values: 1 - 100
Default: 5
Statistics time period
(Secs)
Number of seconds used to calculate average values for SYN

protection statistics.
Values: 1 - 100
Default: 60
Attack Periodic Report

Threshold (%
incomplete secs)
If the percentage of incomplete sessions for a destination protected by

a policy exceeds this threshold, the attack is reported periodically. A
value of 0 means no report is available.
Values: 1 - 100%
Default: 50
SYN ACK Reflection

Limiting threshold representing the maximum number of uncompleted
Maximum SYN Cookies TCP sessions per source IP per second, to be answered. Any session
per Source
exceeding this frequency is ignored.
Values: 1 - 100,000
Default: 1,000
TCP Protection Timeout Timeout to complete the TCP 3-way handshake. Values: 0-10 seconds
(0 means no timeout).
Default: 5
SYN Protection
Tracking Time
The number of seconds during which the number of SYNs directed to

the same destination must be below the Deactivation Threshold value.
If the number of SYNs exceeds the deactivation threshold within that
time, the destination protection is deactivated.
Values: 0 -10 seconds (0 means no timeout).
Default:5
SYN ACK Reflection

SrcIP Sampling Per
Second
Amount of SYN packets per second that are sampled and their source
IP is to be monitored.
Values: 0 - 10000
Default: 100
SYN ACK Reflection

Protection Mode
Activate SYN-ACK Reflection Attack Prevention using these modes:

Enable: The prevention mode
Report Only: The report-only mode (no prevention)
Disable (Default): The mechanism is disabled
458

Security
Parameter
Description
Maximum Traps per

Time Interval
Maximum number of SYN Flood and ACK reflection traps per defined
time interval.
Value: >0
Default: 100
Traps Time Interval

(seconds)
User-defined time interval (in seconds) for limiting traps.

Value: >0
Note: Before enabling SYN Flood protection you must set the Session/Client Table to operate in
the Layer 4 mode.
SYN Protection Policies

SYN Protection Policies are sets of predefined SYN flood detectors and protectors. Here, you can
configure SYN Protection Policies for AppDirector version 2.10.
SYN Flood Protection Policies

Once the SYN Flood Protection is enabled, you can define Protection policies. A policy is defined
according to a destination address or address range.
To create a SYN Flood Protection Policy

1. From the Security menu select SYN Flood Protection > Protection Policies. The SYN Flood
Protection Policies window appears.
2. Click Create. The SYN Protection Policies Create window appears.
Parameter
Description
Name
The user-defined name of the policy
Index
Location of policy in the protection table that reflects the order in which
the classification is performed.
Protection Mode
Includes a dropdown menu with the following options:

Enabled: Activates SYN Cookies for all sessions
Triggered: Activates SYN Cookies only when SYN attack is identified
Disabled: Never use SYN Cookies
Operational Status
Active or Inactive.
Activation Threshold Maximum number of SYN packets that are allowed to arrive at the same
destination per second. If the Activation Threshold goes beyond the
predefined number, the traffic is recognized as an attack and the packets
are terminated.
Default: 2500
Verification Type
Define the process of completing the TCP session:
459

Security
Parameter
Description
Description
A free text describing the policy.
Deactivation
Threshold
The minimum number of SYN packets per second that can arrive at the
same destination. If the number of packets that arrive at the same
destination is below Deactivation Threshold, the SYN Flood protection
policy is deactivated and the traffic is no longer protected.
Default: 1500
4.
Ack
Session is completed when the Ack packet arrives (following a SYN /

SYN-ACK packets exchange)
Request
Session is completed when the first data request packet arrives

(following a SYN / SYN-ACK packets exchange)
Destination
Destination address of packet matched by policy.
Physical Port Group
User-defined physical port group or aggregated Link for SYN flood

protection.
Count Statistics
Enable or disable counting of statistics for destinations defined in policy.
Service
Basic filter of protected application destination port.
SYN Flood Statistics

To make the process of defining policy thresholds easier for you, you can view SYN Statistics prior to
configuring the thresholds. The SYN statistics window provides information on the number of SYNs,
complete sessions and other data, thus helping you to define reliable thresholds.
To access the SYN statistics

1.
From the Security menu select SYN Flood Protection > Statistics. The SYN Flood Protection
Statistics window appears.
2.
Select the desired policy. Leaving this field empty displays statistical data for all policies. For
each policy the following data appears:
460
Parameter
Description
Name
Name of policy whose traffic data is collected and analyzed.
Dest IP
A specific destination IP included in the policy.
Dest Port
A specific destination port included in the policy.
RX Port
A specific RX port included in the policy.
Attack Status
Current status of attack. Values: Protected (Under Attack), Protected

(No Attack), Monitoring (No Attack), Not Protected.
Active Time (Secs)
Activity time of this entry in the table.
SYNs Last Sec
The number of SYNs within the last second.
Valid Sess Last Sec
The number of valid sessions within the last second.
SYNs/Sec Avg
The average number of SYNs per second.
Valid Sess/Sec Avg
The average number of valid sessions per second.
SYNs/Sec Peak
Highest value of SYNs per second during the statistical analysis period.

Security
Parameter
Description
Valid Sess/Sec Peak
Highest value of valid sessions per second during statistical analysis

period.
Attack Start
Last attack detection time and date.
Attack Term
Last attack termination time and date.
3. To update the table click Set.
Notes:
>> To define a group with a single port, assign the same value to From Port and To Port.
>> Use the same group name for all ranges that you want to include in the group.
4. Click OK. A new row appears in the Application Port Group table.
5. Click OK. The Application Port Group window closes.
6. From the Destination App. Port Group drop-down list, select a group that was defined in the
7. In the Attack Description field, enter a description of the attack.
8. Click OK. The SYN Attack Configuration window closes, and a new user-defined attack appears
in the All Regular Filters pane of the Connect & Protect Table window.
Note: AppDirector will recognize an attack when there is more then 1000 packets per second.
Viewing the SYN Statistics

To make defining policy thresholds easier, you can view SYN Statistics prior to configuring the
thresholds. The SYN Statistics table provides information on the number of SYNs, complete
sessions, and other data, from which you can define reliable thresholds in custom policies.
SYN Flood Reporting - Active Triggers

You can view active SYN Flood attacks via the Active Triggers table. This table displays the
parameters of the Active Triggers table.
To view the SYN Flood Active Triggers Table

From the Security menu select SYN Flood Protection > Active Triggers. The Active SYN
Protection Triggers window appears, which contains the following read-only parameters:)
Parameter
Description
Type
The type of the identified attack:
IP Address
Source IP for SYN ACK Reflection, and dest IP for all other types.
Active Time (Secs)
Number of seconds since the attack began.
Total SYN
Total number of SYN packets for this trigger.
Total SYN Dropped sessions
Total number of unverified sessions for this trigger.
461

Security
Parameter
Description
Last Sec SYN
Number of SYN Flood attacks recognized in last second.
Last Sec Verified
Number of ACKs recognized in the last second.
TCP-Handshake-Timeout
The Timeout for the SYN option enables the protection of the Client Table against SYN attacks that
occur during the TCP handshake process.
When a client sends SYN to the Layer 4 Policy, AppDirector selects a server, adds a new entry to the
Client Table, and forwards SYN to the selected server. If, during a predefined period of time (which
can last for 1 to10 seconds), no additional response arrives from this client, it is regarded as a SYN
attack. In that case, the entry is deleted from the Client Table, and the Reset command is sent to
the server to release the resources allocated to this session. Values run from 1 to 10 seconds and
the default is 5 seconds.
Note: The Timeout for SYN parameter is applicable only when the Open Entry When Source
Port Different or the Select New Server When Source Port Different parameters are
enabled. The Timeout for SYN parameter applies only to TCP sessions.
You can enter the value (in seconds) that AppDirector assigns to a new session started by a SYN
packet if no further traffic is received from the client, until the entry is removed from the Client
Table and a Reset is sent to the server. If the defined SYN Timeout is 0 (regular aging time), this
indicates that the parameter is disabled, and sessions are removed from the Client Table according
to the value defined as the Aging Time.
Session Table and Session Table Lookup Mode

The Session Table enables the device to efficiently process traffic that is only routed or bridged by
the device and not load balanced. It is a mechanism similar to the Client Table that allows the device
to track sessions that are not recorded in the Client Table
The Session Table records session information when bandwidth management Layer 7 policies are
applied to traffic running through the device. It supports stateful features for traffic, such as SYN
Protection. The Session Table Lookup mode indicates what layer of address information is used to
categorize packets in the Session Table.
Notes:
>> The Session Table is disabled by default. When SYN Flood Protection is used, the Session
Table must be enabled.
>> Full Layer 3 and Full Layer 4 modes are supported.
>> Packets must be categorized with the Full Layer 4 Session Table Lookup mode when SYN
Protection is used.
462

Security
To configure the Session Table Global parameters

1. From the Device menu, select Session Table> Global Parameters. The Session Table
2. Set the Parameters.
Parameter
Description
Session Table
Status
Whether the session table is active or not. If the device does not need
to provide high performance for routed or bridged traffic, it is
disabled.
Default: Disabled
Session Table Aging

Time
Amount of time a non-active session is kept in Session Table ( secs).

If 0 - the regular session aging time is used
Session Table
Lookup Mode
Indicates what layer of address information is used to categorize

packets in the Session Table. This means whether the sessions are
treated per user (L3-IP address) or per session (L4-IP addresses and
ports).
Modes include:
Full Layer3: An entry exists in the Session Table for each Source
IP and Destination IP combination of packets passing through the
device. This mode is recommended for higher performance,
unless traffic classification on Layer 4 or 7 is required.
Full Layer4 (Default): An entry exists in the Session Table for
each Source IP, Source port, Destination IP, and Destination port
combination of packets passing through the device. This default
mode for the Session Table and is recommended when traffic
classification on Layers 4 or 7 is required.
Remove Session
Table Entry at
Session End
Removes sessions from the Session Table when the session ends
(only valid for Full Layer 4 Lookup mode). Recommended to free
resources when the Aging Time of Session Table is set to a high
value; however, it can cause slight performance degradation.
Default: Enabled
Send Reset To
Server Status
Checks whether the Session Table sends a reset packet to the server
if no data is transmitted through the session, because it could be a
SYN attack.
Default: Disabled
463

Security
View Table Query Results

The View Table Query Results window allows you to define the way in which the Session Table
information is represented. The Session Table Entries table displays the information that you decided
to present. Using Session Table Query Filters you can set what information is displayed in the
Session Table Entries table.
To define what information is presented in the Session Table Entries table

1.
From the Device menu, select Session Table > View Table Query Results. The Session Table
Entries window appears.
2.
To set the Session Table Query Filters, from the Session Table Entries window click Create. The
Session Table Query Filters Table Create window appears.
3.
Set the parameters.
Parameter
Description
Maximum
Displayed Entries
Maximum number of session table entries that will be displayed. To set

the number of Session Table entries that you want to present, type the
number that you want here.
Number of Used
Entries (Read Only)
Number of entries currently used.
Session Table Entries

Source IP
Source IP within the defined subnet.
Dest IP
Destination IP within the defined subnet.
Source Port
Session source port.
Dest Port
Session destination port.
Protocol
4.
464
Lifetime
Lifetime of the entry.
Aging Type
Aging Type of the entry.
SYN Flood Status
SYN flood status of the entry.
Click Set. The Session Table Entries table displays information from the Session Table according
to your preferences with these parameters.
Parameter
Description
Name
Unique filter name.
Source IP
Source IP within the defined subnet.
Dest IP
Destination IP within the defined subnet.
Source Port
Session source port.
Dest Port
Session destination port.

Security
Working in Application Acceleration Disabled Mode
When you disable the acceleration engine, (see Tweaks, page 290), you can utilize the further
security features based on other licenses shown here. But first you need to follow these steps:
1. Ensure that you have the correct licenses.
a.
b.
c.
As a default, all AppDirector users receive a basic AppDirector licence. In addition, you may
also have a cookie persistency license.
However, to run Bandwidth Management and IPS features, you will additionally need a bwmips licence.
To run DoS Shield and BDos features, you need a dos license but will first need the BWM and
IPS license, bwm-ips.
2. If you do not have the correct license(s), you will need to obtain them as follows:
a.
b.
Order the required license part number.

Send with the order, the MAC address and the current license ID for the license type you
require. This information is available in the License Upgrade window in Web Based
Management
c.
The new license string will be received by email.
3. Using Web Based Management (Device / License Upgrade), or CLI (using the command system
license) enter the new license string. Also see Upgrading Licenses Using WBM, page 53 and
Upgrading Licenses Using the CLI, page 55.
Signature Protection
Signature protection detects and prevents network-oriented attacks, Operation System (OS)
oriented attacks and application-oriented attacks by comparing each packet to the set of signatures
stored in the Signatures database. The attacks handled by this protection can be divided into the
following groups:
Server-based vulnerabilities:
Web vulnerabilities
Mail server vulnerabilities
FTP server vulnerabilities
SQL server vulnerabilities
DNS server vulnerabilities
SIP server vulnerabilities
Worms & Viruses
Trojans & Backdoors
Client side vulnerabilities
IRC bots
Spyware
Phishing
Anonymizers
Radware provides you with the Signatures database that contains signatures of predefined attacks.
These attacks are included in the predefined groups and profiles supplied by Radware. Using the
predefined groups and profiles, you can create new protection policies. Each attack group includes a
number of attack signatures that are grouped together according to their common characteristics.
The groups are included in protection profiles that are applied to protection policies
465

Security
Security Signatures File Update

To constantly update the signatures database, AppDirector Security uses the Signatures File Update
feature. All devices are updated using the latest signatures file, which is a database that contains a
list of updated attacks.
To guarantee maximum protection for your network, you must update the signatures file per device.
During the update process, APSolute Insite connects to the Radware website to check whether you
can access the file for the specified device.
Note: To get the Security Update Service, you must purchase it separately.
An updated signatures file can be found every Monday on the Radware Security Zone (http://
www.radware.com/content/security/attack/weeklyupdates.asp), plus, the website is updated on an
ongoing basis with emergency updates when required.
You can Update the Signatures file in the following ways:
Manual updating: If you have an updated file that was downloaded manually from the
Radware website, you can upload the signatures file to AppDirector manually.
Manual downloading and updating: You can download the update file from the Radware
website and update using this file.
Automatic downloading and updating: You can schedule automatic downloads and updates
of the signatures file.
Tip: To provide protection for your network, it is recommended to set automatic daily updates.
The Signature Protection option contains these features:
Application Security Global Parameters, page 467.
IP Reassembly and Min IP Fragmentation, page 467
Denial of Service (DoS), page 469
DoS Shield, page 469.
Basic Static Filters, page 470.
Basic User Filters, page 474.
Advanced Static Filters, page 476.
Advanced User Filters, page 477.
Attacks, page 477
Static Attacks, page 478.
User Attacks, page 480.
Copy Groups, page 482.
Static Groups, page 483.
User Groups, page 483.
Copy Profiles, page 484.
Static Profiles, page 484.
User Profiles, page 485.
Signature Protection Policies, page 485.
Exclude Attacks, page 486.
466

Security
Application Security Global Parameters

Application Security is a mechanism that delivers advanced attack detection and prevention
capabilities. This mechanism is used by several security modules to provide maximum protection for
network elements, hosts and applications.
To set the Application Security Global Parameters

1. From the Security menu select, Signature Protection > Application Security > Global
Parameters. The Application Security Tuning window appears.
Parameter
Description
Start Protection
Select Enable (default) to start protection.
Min Risk
From the drop-down list define the risk level.

Values: Info, Low, Medium, High
MAX URI Length
Maximum URI length permitted. If URI is longer than the configured

value, this URI is considered as illegitimate and is dropped. The default
value is 500 characters.
MIN fragmented
URI packet Size
The minimum permitted size of an incomplete URI in an HTTP request. A

shorter packet length is treated as URI protocol anomaly and is dropped.
The default value is 50 characters.
Security Tracking
Tables Free-Up
Frequency [ms]
The Free-Up Frequency for each table determines how often the device
clears unnecessary entries from the table, and stores information about
newly detected security events.
Unicode Encoding
The language encoding (the language and character set) to use for
detecting security events.
Session-Drop
Mechanism Status
When enabled, terminates the whole session when a single malicious

packet is recognized.
IP Reassembly and Min IP Fragmentation

AppDirector provides protection against IP traffic evasion techniques with a signature-based
recognition of IP attacks. Signature lookup is done on a packet-by-packet basis. Hackers (or a host
operating system) may split an attack over two or more IP fragments belonging to the same IP
packet, bypassing of the signature-based detection engine.
Fragmenting of a packet may happen either intentionally by a hacker or by an application due to
Layer 2 MTU constraints. As a result, the IP signature-based detection engine is bypassed. Used by
hackers, this technique is called Evasion.
AppDirector enables assembling IP fragments into a complete IP packet to search for attack
signatures split among multiple IP fragments. Fragments of an IP packet are assembled until the
packet is complete. The device continues to forward the fragments and only when an attack is
detected, the predefined action is taken. The action is based on the last fragment received.
IP Reassembly is effective for attack signatures in Intrusions, Anomalies, Anti-Scanning, and
Application Security for DoS.
467

Security
To provide protection from fragmented IP traffic, AppDirector uses:
IP Reassembly: AppDirector assembles the IP fragments into a complete IP packet and looks for
attack signatures split among multiple IP fragments.
Min IP Fragmentation: AppDirector detects abnormally small IP fragments and applies a

predefined Action mode to them.
There is no report of a specific attack. It is mentioned only when a fragment has been identified as
an attack.
To configure the IP Defragmentation parameters

1.
From the Security menumenu select, select Signature Protection > Application Security >
IP FragmentsGlobal Parameters. The Application Security IP Fragments Tuning window
appears.
2.
Set the parameters.
Parameter
Description
Protection Status
Enable / Disable (default).
IP Reassembly no
memory Action Mode
The device action when the device lacks memory resources to perform
IP reassembly.
Values
IP Reassembly aging
time [sec]
Drop: The packet is discarded
Forward (default): The packet is forwarded to the defined

destination
Maximum period of time, in seconds, during which DefensePro keeps

consecutive fragments of the same IP packet in case not all the
fragments of this packet have been received yet. After this period
DefensePro drops the fragments.
Default: 3
IP Reassembly
Overlap status
Sets the data overlapping status within IP fragments. Overlapping may

also indicate an attack evasion technique.
Values:
IP Reassembly
Overlap Action Mode
468
Allow (default): The overlapping is not identified as an attack and

the IP packet fragment is forwarded to its destination
Deny: The overlapping is defined as an attack and the predefined

IP Reassembly Overlap Action Mode is used to prevent it
The Action mode settings when IP Reassembly Overlap status is set to

"Deny."
Report Only (default): The fragment is forwarded to the defined

destination
Drop: The fragment is discarded
Reset Source: A TCP-Reset packet is sent to the packet Source IP
Reset Destination: A TCP-Reset packet is sent to the destination

address
Reset Bi-directional: TCP-Reset packets are sent to both the packet

source IP and the packet destination IP

Security
Parameter
Min IP Fragment
protection status
Min IP Fragment
Action Mode
Description
Enable/Disable (default) the Min Fragment protection feature.
Note: There is no dependency between the IP Reassembly feature
and the Min Fragment protection feature. Min Fragment
protection can be enabled when the IP Reassembly feature is
Enabled or Disabled.
Action mode settings when Min IP Fragment Protection is set to Enable:
Report Only: The fragment is forwarded to the defined destination
Drop (default): The fragment is discarded
Reset Source: A TCP-Reset packet is sent to the packet Source IP
Reset Destination: A TCP-Reset packet is sent to the destination
address
Reset Bi-directional: TCP-Reset packets are sent to both the packet
source IP and the packet destination IP
MIN IP Fragment Size The minimum permitted size of a fragmented IP packet. A shorter
packet length is treated as an IP protocol anomaly and is dropped.
Values: 1-65535 Bytes.
Default: 512 Bytes.
Denial of Service (DoS)

Radwares security scheme provides organizations with extensive Denial of Service (DoS) detection
and protection capabilities while maintaining high network throughput. When hackers send mass
volumes of traffic, they overload networks or servers, causing denied access for legitimate users.
This is known as a Denial of Service (DoS) or Distributed Denial of Service (DDoS) attack. DoS
occurs as a result of various types of flooding caused by hackers, such as UDP, TCP, and ICMP. The
DoS/DDoS module provides protection against packet flooding, thereby preventing denial of service.
To provide protection against denial of service, the DoS/DDoS module incorporates two different
services that mitigate DoS attacks:
DoS Shield Profiling: Sampling-based service that provides protection against the packet
flooding which causes a denial of service effect. This protection is provided for TCP, UDP, and
ICMP floods. This service utilizes advanced sampling, which significantly reduces the device CPU
load compared to packet-by-packet scanning.
Application Security Profiling: Packet-by-packet scanning service that provides protection

against DoS attacks, using signature-based packet-by-packet scanning.
The sampling-based service provides optimized performance in high throughput networks. Once an
attack is detected, the DoS Shield module sets the relevant attack filter for packet-by-packet
inspection. The packet-by-packet scanning service is based on the DoS protection group, named
DOS.
DoS Shield
To prevent denial of service, DoS Shield samples traffic flowing through the device and limits the
bandwidth of traffic that has been recognized as a DoS attack using predefined actions.
This is based on working with two attack states: Dormant and Active.
Dormant state indicates using the sampling method for recognition prior to action activation. An
attack in Dormant state can become active only if the number of packets that enter your network
exceeds the predefined limit.
469

Security
Active state indicates that the action must be implemented on each packet that matches the attack
signature.
The DoS Shield counts packets matching the Dormant and Active states. Samples of the traffic are
compared with the list of attacks in Dormant state. When a pre-configured number of packets is
reached, the status of the attack changes to Active. DoS Shield utilizes two processes working in
parallel. One statistically monitors traffic to check if any of the attacks in Dormant state have
become active. When an attack is detected as active, this attack is handled by the second process.
Each packet passing through the device is compared to the list of currently active attacks. If no
match is found, a portion of the packets is sent to be compared with Dormant attacks while the
other packets are forwarded to the network.
Prior to using DoS Shield, you need to enable the DoS Shield module. In the DoS Shield Global
Parameters window you can enable the DoS Shield module and set its global parameters.
To configure DoS Shield Global Parameters

1.
From the Security Menu select Signature Protection > DoS Shield > Global Parameters.
The DoS Shield Global Parameters window appears.
2.
Set the parameters.
Parameter
Description
Start Protection
Enable (default) DoS Shield module operation.
Sampling Rate
The rate in which packets are sampled and compared to the Dormant
Attacks.
You can configure a number indicating how many packets the sampling
is performed. Default: 101, (1 out of 101 packets is checked).
Sampling Frequency
[sec]
3.
How often DoS Shield compares the predefined thresholds for each
Dormant Attack to the current value of counters of packets matching
the attack. Default: 5 seconds
Basic Static Filters

The Security Basic Static Filters window allows you to view the Basic Filter, which constitutes
protection against a specific attack, meaning that each Basic Filter has a specific attack signature
and protection parameters.
The Advanced Filter represents a logical AND between two or more Basic Filters. Some attacks have
a complex signature comprised of several patterns and content strings. These attacks require more
than one basic filter to protect against them.
Note: You can create the Advanced Filters using the user-defined Basic Filters only.
470

Security
To view the Security Basic Static Filters

1. From the Security menu, select Signature Protection > Filters > Basic Filters > Static. The
Static Basic Filter Table window appears.
2. Select the basic static filter for which you want to view the details. The Static Basic Filter Table
Update window appears with the following read-only parameters.
Parameter
Description
Name
The name of the filter as you define it.
Protocol
The protocol used: IP, UDP, TCP or ICMP.
Source App. Port
The source application ports.

Destination App.
Port
The destination application ports.
OMPC Offset
The location in the packet from which the checking of data is started to
find specific bits in the IP/TCP header.

OMPC Offset
Relative to
OMPC Mask
The mask for the OMPC data. Possible values: a combination of

hexadecimal numbers (0-9, a-f). The value must be defined according to
the OMPC Length parameter. The OMPC Pattern parameter definition
must contain 8 symbols. If the OMPC Length value is lower than
fourBytes, you need complete it with zeros.
Values: None (default), IP Header, IP Data, L4 Data, L4 Header, Ethernet.
For example, if OMPC Length is twoBytes, OMPC Mask can be:abcd0000.

Default value: 00000000.
OMPC Pattern
The fixed size pattern within the packet that OMPC rule attempts to find.
must be defined according to the OMPC Length parameter. The OMPC
Pattern parameter definition must contain 8 symbols. If the OMPC Length
value is lower than fourBytes, you need complete it with zeros.
For example, if OMPC Length is twoBytes, OMPC Pattern can
be:abcd0000.
Default value: 00000000.
OMPC Condition
The OMPC condition can be either N/A, equal, notEqual, greaterThan or

lessThan.
Default: N/A.
OMPC Length
The length of the OMPC (Offset Mask Pattern Condition) data can be N/A,
oneByte, twoBytes, threeBytes or fourBytes.
Default: N/A.
Content Offset
The location in the packet from which the checking of content is started.
Distance
A range that defines the allowed distance between two content

characters.
If the distance is beyond the specified range, it is recognized as an
attack.
471

Security
Parameter
Description
Content
Contains the value of the content search. Possible values: < space > ! " #
$ % & ' ( ) * + , -. / 0 1 2 3 4 5 6 7 8 9 : ; < = > ? @ A B C D E F G H I
JKLMNOPQRSTUVWXYZ[\]^_àbcdefghijklmno
pqrstuvwxyz{|}~
Content Type
Enables you to search for a specific content type, which can include:
URL: In the HTTP Request URI. No normalization procedures are
taken.
Normalized URL: To avoid evasion techniques when classifying HTTPGET requests, the URL content is transformed into its canonical
representation, to interpret the URL in the same way the server
would. The normalization procedure supports the following cases:
Directory referencing by reducing '/./' into '/' or "A/B/../" to "A/

";
Changing backslash ('\') to slash ('/');
Changing HEX encoding to ASCII characters. For example the

hex value %20 is changed to " " (space).
Unicode support, UTF-8 and IIS encoding.

value.
File Type: The type of the requested file in the http GET command
(jpg, exe etc).
POP3 User: User field in the POP3 Header
cookie name, and the "content data" field includes the cookie value
FTP Content: Scans the data transmitted using FTP, performing
normalization of the FTP packets and stripping of telnet opcodes
FTP Command: Performs parsing of FTP commands to commands
and arguments, while performing normalization of the FTP packets
and stripping of telnet opcodes.
RPC: Reassembles RPC requests over several packets
RPC RFC 1831 standard provides a feature called Record Marking

Standard (RM). This is used to delimit several RPC requests sent
on top of the transport protocol. When there is a stream-oriented
protocol (TCP or SCTP), RPC uses a kind of fragmentation to
delimit between the records. In spite of its original purpose,
fragmentation may also divide records in the middle and not only
at their boundaries. In some cases, this functionality may be
used to evade IPS systems.
N/A: Default
472

Security
Parameter
Description
Content Max Length Maximum length to be searched within the selected Content Type.
The Content Max Length value must be equal or greater than the Offset
value.
Content Data
Refers to the search for the content within the packet. It can be N/A, URL
or Text.
Content Encoding
Application Security can search for content in non-english languages for

case sensitive or case insensitive text and hexadecimal strings.
Values:
None (default)
Case Insensitive
Case Sensitive
HEX
International
The value of this field corresponds to the Content Type parameter.
Content Data Reg

Expression
Expression content held anywhere within the packet. Select this

parameter to indicate that the Content Data field value is formatted as a
regular expression (and not as free text to search).
From the dropdown list, select either Yes/No.
Content Regular
Expression
A regular expression (abbreviated as regexp, regex), is a string that

describes or matches a set of strings, by certain syntax rules. You can set
a Regex search for all content types. This parameter allows you to
search for content type anywhere in the packet. (Content is TCP/UDP
data or IP Data for other protocols or beginning L3 of non-IP traffic.
Content Data
Encoding
Application Security can search for data in languages other than English,
for case sensitive or case insensitive data and hexadecimal strings.
Values:
None (default)
Case Insensitive
Case Sensitive
HEX
International
473

Security
Basic User Filters
To view the Security Basic Static Filters

1.
From the Security menu, select Signature Protection > Filters > Basic Filters > User. The
User Basic Filter Table window appears.
2.
Select the basic static filter for which you want to view the details. The User Basic Filter Table
Update window appears with the following read-only parameters.
Parameter
Description
Name
Name of the filter as you define it.
Protocol
Protocol used: IP, UDP, TCP or ICMP.
Source App. Port
Source application ports.

Destination App. Port
Destination application ports.

OMPC Offset
Location in the packet from which the checking of data is started to find
specific bits in the IP/TCP header.
OMPC Offset Relative

to
OMPC Mask
Mask for the OMPC data.
Values: None (default), IP Header, IP Data, L4 Data, L4 Header,

Ethernet.
Values: A combination of hexadecimal numbers (0-9, a-f).
These must be defined according to the OMPC Length parameter. The
OMPC Pattern parameter definition must contain 8 symbols. If the
OMPC Length value is lower than fourBytes, you need to complete it
with zeros. For example, if OMPC Length is twoBytes, OMPC Mask can
be:abcd0000.
Default: 00000000.
OMPC Pattern
Fixed size pattern within the packet that OMPC rule attempts to find.
must be defined according to the OMPC Length parameter.
The OMPC Pattern parameter definition must contain 8 symbols. If the
OMPC Length value is lower than fourBytes, you need to complete it
with zeros. For example, if OMPC Length is twoBytes, OMPC Pattern can
be:abcd0000.
Default: 00000000.
OMPC Condition
Values: N/A (default), equal, notEqual, greaterThan or lessThan.
OMPC Length
Length of the OMPC (Offset Mask Pattern Condition) data:

Values: N/A (default), oneByte, twoBytes, threeBytes or fourBytes.
Content Offset
Location in packet from which the checking of content is started.

Distance
A range that defines allowed distance between two content characters.

If the distance is beyond the specified range, it is recognized as an
attack.
474

Security
Parameter
Description
Content
Contains the value of the content search.

Values: < space > ! " # $ % & ' ( ) * + , -. / 0 1 2 3 4 5 6 7 8 9 : ; < =
>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_à
bcdefghijklmnopqrstuvwxyz{|}~
Content Type
Enables you to search for a specific content type, including:

URL: In the HTTP Request URI. No normalization procedures are
taken.
Normalized URL: To avoid evasion techniques when classifying
HTTP-GET requests, URL content is transformed into its canonical
representation, to interpret the URL in the same way the server
would. The normalization procedure supports the following cases:
Directory referencing by reducing '/./' into '/' or "A/B/../" to "A/

";
Changing backslash ('\') to slash ('/');
Changing HEX encoding to ASCII characters. For example the

hex value %20 is changed to " " (space).
Unicode support, UTF-8 and IIS encoding.

value
File Type: The type of the requested file in the http GET command
(jpg, exe etc.).
POP3 User: User field in the POP3 Header
cookie name, and the "content data" field includes the cookie value
FTP Content: Scans the data transmitted using FTP, performing
normalization of the FTP packets and stripping of telnet opcodes
FTP Command: Performs parsing of FTP commands to commands
and arguments, while performing normalization of the FTP packets
and stripping of telnet opcodes
RPC: Reassembles RPC requests over several packets
RPC RFC 1831 standard provides a feature called Record

Marking Standard (RM). This is used to delimit several RPC
requests sent on top of the transport protocol. In case of a
stream-oriented protocol (TCP or SCTP) RPC uses a kind of
fragmentation to delimit between the records. In spite of its
original purpose, fragmentation may also divide records in the
middle and not only at their boundaries. In some cases, this
functionality may be used to evade IPS systems.
N/A: Default
475

Security
Parameter
Description
Content Max Length
Maximum length to be searched within the selected Content Type.

Content Max Length value must be equal or greater than Offset value.
Content Data
Refers to search for content within the packet.

Values: N/A, URL or Text.
Content Encoding
Application Security can search for content in languages other than

English, for case sensitive or case insensitive text and hexadecimal
strings.
Values:
None (default)
Case Insensitive
Case Sensitive
HEX
International
Content Data Reg

Expression
Expression content held anywhere within the packet. Select this

parameter to indicate that the Content Data field value is formatted as
a regular expression (and not as free text to search).
Content Regular
Expression
A regular expression (abbreviated as regexp, regex), is a string that

describes or matches a set of strings, by certain syntax rules. You can
set a Regex search for all content types. This parameter allows you to
search for content type anywhere in the packet. (Content is TCP/UDP
data or IP Data for other protocols or beginning L3 of non-IP traffic.
Content Data
Encoding
Application Security can search for data in languages other than

English, for case sensitive or case insensitive data and hexadecimal
strings.
Values:
None (default)
Case Insensitive
Case Sensitive
HEX
International
Advanced Static Filters

Note: Note: You can create the Advanced Filters using the User Defined Basic Filters only.
The Advanced Static Filters window allows you to view the Advanced Static Filter Table.
476

Security
To view Advanced Static Filters

From the Security menu, select Signature Protection > Filters > Advanced Filters > Static.
The Static Advanced Filters window appears. The Advanced Filters Table contains the following
parameters:
Parameter
Description
Name
The name of the filter.
Number of Filters
The number of filters for this entry.
Advanced User Filters

The User Defined Advanced Filters window allows you to create Advanced Filters.
To create a Advanced Filter

1. From the Security menu, select Signature Protection > Filters > Advanced Filters > User.
The User Defined Advanced Filters window appears.
2. Click Create. The Create Advanced Filter window appears.
Parameter
Description
Advanced
The name of the Advance Filter that you define.
Basics
The name of the Basic filter that is associated to the Advanced filter.
Attacks
An Attack is a building block of the profile. Each Attack contains one or more protection filters and
attributes that determine which packets are malicious and how the signature protection mechanism
treats those packets.
Attack parameters define how the malicious packet is tracked and treated once its signature is
recognized in the traffic. Each Attack is bound to a tracking function, which defines how the packet is
handled when it is matched with the signature. The main purpose of these functions is to determine
whether a packet is harmful and to take appropriate action.
The Attacks table provides you with filtering that allows viewing of Radware and user-defined
Attacks. You can define filtering criteria and display all Attacks matching the criteria in the Attacks
table. In addition you can add user-defined Attacks.
For further information see:
Top Ten Attacks, page 506
Attack Database Version, page 509
Attack Database Send to Device, page 509
477

Security
Static Attacks
The Attacks Database contains attacks provided by Radware. You can add user-defined attacks to
reflect specific needs of your network, or edit the existing attacks.
To edit a Static Attack

1.
From the Security menu select, Signature Protection > Attacks > Static. The Signature
Protection Static Attack Configuration Table window appears.
2.
Select a static attack. The Signature Protection Static Attack Configuration Update window
appears.
3.
Set the parameters.
Parameter
Description
ID
The unique identifying number (read-only).
Attack Name
User-defined name for this attack. Attack Name is used when DoS
Shield sends information about attack status changes (read-only).
Filter Name
The filter assigned to this attack (read-only).
Filter Type
The type of filter (read-only).
Tracking Time
Sets amount of time (in milliseconds) in which the threshold is

measured. When a number of packets greater than the threshold value
passes through the device, during this defined time period, the device
recognizes it as an attack.
Default: 1000
Active Threshold
Sets the maximum number of attack packets that are allowed in each
Tracking Time unit. The attack packets are recognized as legitimate
traffic when they are transmitted within the Tracking Time period.
Default: 10
Tracking Type
Defines how the device decides which traffic to block or drop, when
under an attack of this type.
Values:
Drop All (default): Use when each packet of the defined attack is
harmful. For example: Code Red and Nimda attacks.
Source Count: Select this option when the defined attack is
source-based, meaning the hacker attack can be recognized
according to its source address. For example: Horizontal Port Scan,
were the hacker scans a certain application port (TCP or UDP) to
detect which servers are available on the network.
Target Count: Select this option when the defined attack is
destination-based, meaning the hacker is attacking a specific
destination such as a Web server. For example: Ping Flood and
DDoS attacks
Source and Target Count: Select this option when the attack type
is a source and destination based attack, meaning the hacker is
attacking from a specific source IP to a specific destination IP. For
example: Port Scan attack.
Sampling: Select this option when the defined attack is based on
sampling. The rate at which packets are sampled and compared to
the Dormant Attacks.
478

Security
Parameter
Description
Action Mode
When an attack is detected, one of the following actions can be taken:

Report Only: The packet is forwarded to the defined destination.
Drop (default): The packet is discarded.
Reset Source: Sends a TCP-Reset packet to the packet Source IP.
Reset Destination: Sends a TCP-Reset packet to the destination
address.
Reset Bi-directional: Sends a TCPReset packet to both, the packet
source IP and the packet destination IP.
Attack Type
Static or User-defined attack type.
Risk
You can define the attack risk as High, Medium (default) or Low
depending on the severity of the damage that the attack can cause to
your system.
Direction
A certain protection policy may contain attacks that should be searched

only for traffic from client to server or only on traffic from server to
client.
To provide simple and efficient scanning configuration you can set per
attack the traffic direction for which it is relevant.
Values:
Inbound: On traffic from policy Source to policy Destination
Outbound: On traffic from policy Destination to policy Source
Inbound & Outbound (default for custom attacks) : On all traffic
between policy Source to policy Destination.
Suspend Action
This functionality allows the user to define that for certain attacks, in
addition to the action defined in the attack, the device should also
suspend traffic from the IP address that was the source of the attack,
for a period of time.
Values:
None: Suspend action is disabled for this attack.
SrcIP: All traffic from the IP address identified as source of this
attack will be suspended.
SrcIP, DestIP: Traffic from the IP address identified as source of
this attack to the destination IP under attack will be suspended.
SrcIP, DestPort: Traffic from the IP address identified as source of
this attack to the application (destination port) under attack will be
suspended.
SrcIP, DestIP, DestPort. Traffic from the IP address identified as
source of this attack to the destination IP and port under attack
will be suspended.
SrcIP, DestIP, SrcPort, DestPort. Traffic from the IP address and
port identified as source of this attack to the destination IP and
port under attack will be suspended.
Drop Threshold
The number of packets matching the attack that can be forwarded in

each second when the attack is Active.
A value of Drop All (or 0) means that all packets must be blocked. Any
value other than Drop All is used for attacks that match a pattern of
legitimate traffic, for example UDP Flood attacks.
479

Security
4.
Parameter
Description
Term Threshold
If for the duration of the Attack Aging Period this threshold is not
exceeded, the status of the attack reverts to Dormant. You can also
select Do not Deactivate (or 0).
Exclude Src
Exclude source IP address of the attack.
Exclude Dest
Exclude destination IP address of the attack.
State
Select Enable (default) to activate the policy.
User Attacks
The Attacks Database contains attacks provided by Radware. You can add user-defined attacks to
reflect specific needs of your network, or edit the existing attacks.
The User Attacks window allows you to edit existing attacks.
To edit a User Attack

1.
From the Security menu, select Signature Protection > Attacks > User. The User Attacks
2.
Click Create. The User Attacks Table Create window appears.
3.
Set the parameters.
Parameter
Description
ID
Attack Name
User-defined name for this attack. Attack Name is used when DoS
Shield sends information about attack status changes (read-only).
Filter Name
The filter assigned to this attack (read-only).
Filter Type
The type of filter (read-only).
Tracking Time
Sets the amount of time (in milliseconds) in which the Threshold is

measured. When a number of packets that is greater than the
Threshold value passes through the device, during this defined time
period, the device recognizes it as an attack.
Default: 1000
Active Threshold
Sets the maximum number of attack packets that are allowed in each
Tracking Time unit. The attack packets are recognized as legitimate
traffic when they are transmitted within the Tracking Time period.
Default: 10
480

Security
Parameter
Description
Tracking Type
Defines how the device decides which traffic to block or drop, when
under an attack of this type.
Values:
Source Count: Select this option when the defined attack is sourcebased, meaning the hacker attack can be recognized according to
its source address. For example: Horizontal Port Scan, were the
hacker scans a certain application port (TCP or UDP) to detect
which servers are available on the network.
destination such as a Web server. For example: Ping Flood and
DDoS attacks
Source and Target Count: Select this option when the attack type
is a source and destination based attack, meaning the hacker is
attacking from a specific source IP to a specific destination IP. For
example: Port Scan attack.
Sampling: Select this option when the defined attack is based on
sampling. The rate at which packets are sampled and compared to
the Dormant Attacks.
Action Mode

address.
Attack Type
Static or User-defined attack type.
Risk
You can define the attack risk as High, Medium (default) or Low
depending on the severity of the damage that the attack can cause to
your system.
Direction
A certain protection policy may contain attacks that should be searched

only for traffic from client to server or only on traffic from server to
client.
To provide simple and efficient scanning configuration you can set per
attack the traffic direction for which it is relevant.
Values:
Inbound: On traffic from policy Source to policy Destination
Outbound: On traffic from policy Destination to policy Source
Inbound & Outbound (default for custom attacks) : On all traffic
between policy Source to policy Destination.
481

Security
Parameter
Description
Suspend Action
This allows you to define that for certain attacks, in addition to the
action defined in the attack, the device should also suspend traffic from
the IP address that was the source of the attack, for a period of time.
Values:
SrcIP, DestIP: Traffic from the IP address identified as source of
this attack to the destination IP under attack will be suspended.
suspended.
source of this attack to the destination IP and port under attack will
be suspended.
SrcIP, DestIP, SrcPort, DestPort. Traffic from the IP address and
port identified as source of this attack to the destination IP and
port under attack will be suspended.
Drop Threshold
The number of packets matching the attack that can be forwarded in

each second when the attack is Active.
A value of Drop All (or 0) means that all packets must be blocked. Any
value other than Drop All is used for attacks that match a pattern of
legitimate traffic, for example UDP Flood attacks.
4.
Term Threshold
If for the duration of the Attack Aging Period this threshold is not
exceeded, the status of the attack reverts to Dormant. You can also
select Do not Deactivate (or 0).
Exclude Src
Exclude source IP address of the attack.
Exclude Dest
Exclude destination IP address of the attack.
State
Select Enable (default) to activate the policy.
Click Set. Your preferences are rSecorded.
Copy Groups
Radware attack characteristics are static, meaning the user cannot change any of the filter
properties. Changing the attack setting is possible, as the settings include the tracking values and
action values.
If you want to change an attack group, you can create a new user-defined attack group or new userdefined attack, respectively. You can then modify, remove or add attacks to user-defined groups.
You can copy a complete group as a user-defined attack, for which you can add, remove or modify
attack including attack characteristics modifications.
482

Security
To create a new user defined group

1. From the Security menu, select Signature Protection > Groups > Copy Groups. The Copy
Groups window appears
Parameter
Description
Existing Group
Select the relevant existing group for which you wish to create a copy.
New Group
The user defined New Group name.
Static Groups
The Static Groups window displays a list of existing groups of static filters. You can select a group
name to see a list of the group's static filters.
To view Static Groups

1. From the Security menu, select Signature Protection > Groups > Static. The Static Groups
window appears.
Parameter
Description
Name
The name of the group.
Description
A description of the group.
Number of Filters
The number of static filters in the group.
Note: To see a list of filters in a group, from the Static Groups window click the name of the
group. The Group Contents window appears with a list of the group's filters
User Groups
The User Groups window allows you to create groups of filters.
To configure User Groups

1. From the Security menu, select Signature Protection > Groups > User. The User Defined
Groups window appears.
2. Click Create. The Create Group window appears
483

Security
3.
Set the parameters.
Parameter
Description
Group
The user defined group.
Attack
Contains a dropdown list of Radware Static Attacks.
4.
5.
To add another filter to an existing group, from the User Defined Groups window, click the
required group's name. The Group Contents window opens.
6.
Click Create. The Add Attack Into Group window appears.
7.
From the Attack dropdown list, select the attack to add to the group, and click Set.
Copy Profiles
If you want to change a profile, you can create a new user-defined profile by copying a previously
created profile and then renaming it. You can then change the new profile.
To copy a profile
1.
From the Security menu, select Signature Protection > Application Security Profiles >
Copy Profiles. The Application Security Copy Profiles window appears
2.
Set the parameters.
3.
Parameter
Description
Existing Profile
Contains a dropdown list of all the existing profiles.
New Profile
Type the new profile name.
Static Profiles
Radware profile characteristics are static, meaning the user cannot change any of the filter
properties. Changing the profile setting is possible, as the settings include the tracking values and
action values. In the Profiles window you can create profiles, which can then be applied to policies.
To create a new Static profile

1.
From the Security menu, select Signature Protection > Profiles > Static. The Static Profiles
window appears presenting the configured profiles.
2.
Set the parameters.
3.
484
Parameter
Description
Profile Name
The name of the user defined profile.
DoS Attack
Select an attack that you want to associate with the new profile.
Click Set. The window closes and the new profile appears in the Profiles table.

Security
To add more attacks to the same profile

1. From the DoS Profiles table, click on the profile to which you want to add more attacks. The DoS
Profile (profile name) Contents window appears.
2. Click Create. The Add DoS Attack To DoS Profile window appears with the name of the profile in
the DoS Profile Name box.
3. From the DoS Attack dropdown list, select the attack that you want to add to the profile and
click Set. The new attack appears in the DOS Attacks Table that contains attacks associated with
this specific profile.
User Profiles
The User Defined Profiles window allows you to create profiles.
To create a user defined profile

1. From the Security menu, select Signature Protection > Profiles > User. The User Profiles
window appears, with a table of the existing user-defined profiles.
Parameter
Description
Profile
The user defined profile name.
Group
The group to which the profile belongs.
Category
The category to which the profile belongs:

Values: Anomalies, Anti-Scanning, DOS, Intrusion (default).

4. To add another group to an existing profile, from the User Profiles window, click the required
profile's name. The Profile Contents window opens.
5. Click Create. The Add Group To Profile window opens.
6. From the Group dropdown list, select the group to add to the profile, and click Set.
Signature Protection Policies

A Protection Policy is a mechanism that scans traffic of a particular Network and a physical port.
Protection Policies are applied on filter groups. A filter group uses basic and advanced filters as its
building blocks.
To create a Policy
1. From the Security menu, select Signature Protection > Policies. The Policies window
appears.
2. Click Create. The Policies Create window appears.
485

Security
3.
Set the parameters.
Parameter
Description
Policy Name
The name of the Policy that you define.
Policy Profile
The predefined Filter Group for which this policy is created.
Policy Source Address Definition of the network range to which the Policy is applied.
Default: any.
Policy Destination
Address
Definition of the network range to which the Policy is applied.
Direction
Whether you want to apply the Policy to the defined network range only
in one direction: source - destination (oneway); or in two directions:
source - destination, destination - source (twoways). Default: Oneway.
Default: any.
Inbound Physical Port The physical port group of the device that receives the inbound traffic.
Group
State
Select Active to activate the policy.
Action
The action taken when the policy is activated.

Values: Block and Report; Report Only.
VLAN Tag Group
4.
Defines VLAN traffic classification according to VLAN ID (VLAN

Identifier) tags.
Click Set. Your preference are recorded.
Exclude Attacks
Excluded Attack Addresses are used in Signature protection profiles only. When installing an IPS to
protect a wide range of servers and Source IP addresses running different applications, certain
filters cause false alarms to specific proprietary servers/applications. You can exclude these servers/
applications from being checked by the signatures causing the false alarms. The Excluded Attack
Addresses window enables you to exclude particular Attacks from your network definitions.
To define what attacks to exclude

1.
From the Security menu, select Signature Protection > Exclude Attacks. The Signature
Protection Attacks Excluded Addresses Configuration window appears.
2.
Click Create. The Signature Protection Attacks Excluded Addresses Configuration Create
window appears
3.
Set the parameters.
Parameter
Description
State
Action
The action taken when the policy is activated.

Values: Block and Report; Report Only.
VLAN Tag Group
4.
486
Defines VLAN traffic classification according to VLAN ID (VLAN

Identifier) tags.

Security
Behavioral DoS
The Behavioral DoS (B-DoS) module provides traffic anomaly detection and on-the-fly signature
creation for immediate DoS attack protection.
The B-DoS module detects and prevents network attacks from the public network by detecting
traffic anomalies preventing unknown flood attacks by identifying the footprint of the anomalous
traffic. The B-DoS module protects against Network Flood Attacks, which cause a great deal of
irrelevant traffic to fill available network bandwidth, denying the use of network resources to
legitimate users.
Network Flood protection types include:
SYN Flood
TCP Flood
UDP Flood
ICMP Flood
IGMP Flood
The B-DoS module utilizes known network traffic base lines for each protocol type (i.e., TCP,
UDP,ICMP and IGMP) and compares traffic anomalies with them.
The next step is identifying the attack footprint, which translates into an attack signature. This
module then configures a filter to protect the network according to the policy settings, and activates
the feedback module to optimize the signature and reduce false positives. Once the attack has
ceased, the feedback process is also responsible for removing the attack signature.
The Behavioral DoS module detects statistical traffic anomalies and creates an accurate attack
footprint (signature) based on heuristic protocol information analysis. This ensures accurate attack
filtering with few false-positives. The SYN flood protection provided by the B-DoS module is nonintrusive detecting attacks as they happen, cleaning the links from excessive traffic.
This security option contains these features:
Behavioral DoS Global Parameters, page 488.
Behavioral DoS Profiles, page 488.
Behavioral DoS Policies, page 489.
Behavioral DoS Advanced Settings, page 490.
Behavioral DoS Bandwidth Parameters, page 491.
Behavioral DoS Learning Reset, page 491.
Behavioral DoS Set Default Quotas, page 492.
Behavioral DoS Protocol Quotas, page 492.
Behavioral TCP Footprint Bypass, page 494.
Behavioral TCP Syn Footprint Bypass, page 496.
Behavioral UDP Footprint Bypass, page 497.
Behavioral ICMP Footprint Bypass, page 499.
Behavioral IGMP Footprint Bypass, page 499.
487

Security
Behavioral DoS Global Parameters

The Behavioral DoS Global Parameters window allows you to enable Behavioral DoS Protection
Status.
Note: To configure the Behavioral DoS module, a B-Dos license is required in addition to the
DoS License.
To set Behavioral DoS Global Parameters:

1.
From the Security menu select Behavioral DoS > Global Parameters. The Behavioral DoS Global
2.
Set the parameters.
3.
Parameter
Description
Protection Status
Enable/disable (default) Behavioral DoS global parameters.
Behavioral DoS Profiles

The Behavioral DoS Profiles allows you to create a Behavioral DoS profile. A profile defines the set
of protocols for protection, which can then be assigned to the Behavioral DoS policy.
To set Behavioral DoS Profiles

1.
From the Security menu select Behavioral DoS > Behavioral DoS Profiles. The Behavioral
DoS Profiles window appears.
2.
Click Create. The Behavioral DoS Profiles Create window appears.
3.
Set the parameters.
Parameter
Description
Profile Name
Enter a user defined name for the profile.
TCP SYN flood status
Values: Active/Inactive (default)

Select Active to protect against TCP SYN flood attacks in this profile.
UDP flood status

Select Active to protect against UDP flood attacks in this profile.
ICMP flood status

Select Active to protect against ICMP flood attacks in this profile.
TCP Reset Flood status Values: Active/Inactive (default)

Select Active to protect against TCP reset flood attacks in this profile.
TCP FIN+ACK Flood
status
488

Select Active to protect against protect against TCP FIN+ACK flood
attacks in this profile.

Security
Parameter
Description
TCP Push+ACK Flood

Select Active to protect against TCP Push+ACK Flood attacks in this
profile.
IGMP flood status

Select Active to protect against IGMP flood attacks in this profile.
Behavioral DoS Policies

A Behavioral DoS security policy contains security profiles activated within predefined ranges of
ports/VLANs, or within a predefined network. First, create a security policy, then assign protection
profiles to the policy.
To set Behavioral DoS Policies

1. From the Security menu select Behavioral DoS > Behavioral DoS Policies. The Behavioral
DoS Policies window appears.
2. Click Create. The Behavioral DoS Policies Create window appears.
Parameter
Description
Policy Name
The name of the user defined policy.
Policy Profile
The predefined filter group for which this policy is created.
Policy Source
Address
Definition of the network range to which the policy is applied.
Policy Destination
Address
Definition of the network range to which the policy is applied.
Direction
Whether to apply Policy to defined network range only in one direction:
Default: Any.
Default: Any.
Values:
source - destination (oneway)= default
source - destination and destination - source (twoways).
Inbound Physical
Port Group
Physical port group of the device that receives the inbound traffic.
State
Values Inactive/Active (default)

VLAN Tag Group
Defines VLAN traffic classification according to VLAN ID (VLAN Identifier)

tags.
Packet Report
Used to view a capture of an individual attack packet.

Enable/disable (default) packet reporting for this attack.
Action
Action taken when the policy is activated.

Values: Block and Report (default), Report Only.
489

Security
Behavioral DoS Advanced Settings

The Behavioral DoS Advanced Setting allows you to set the Learning Response Period upon which
baselines are primary weighed and enabling the Sampling status and defining the severity level of
the Footprint.
Note: You must configure network flood protection separately for TCP floods, UDP floods, ICMP
floods, and IGMP floods.
To set Behavioral Advanced Settings

1.
From the Security menu select Behavioral DoS > Advanced > Global Parameters. The
Behavioral DoS Advanced Settings window appears.
2.
Set the parameters.
Parameter
Description
Learning Response
Period
Defines the period upon which the baselines are primarily weighed.
If major structural changes occur in the network, such as major
bandwidth addition or reduction, new network-intensive applications
are installed, or other major network changes, then you should change
the Learning Response Period to day.
Values: day, week (default), month
Sampling Status
The Sampling Status allows you to aggregate Traffic Statistics to

improve performance levels. Select either:
Enable (default): Traffic statistics are aggregated through a
sampling algorithm which improves overall performance of the
AppDirector protection system. The risk: although the decision
engine is tuned according to the sampling error, the chances for
false positive decisions are increased.
Disable: Traffic statistic are aggregated without sampling.
Footprint Strictness
When a new attack is detected, the B-DoS module generates on the fly
an attack signature to block the traffic anomaly created by the attack.
As there is no mechanism free of false positives, there is a trade-off in
this module between the false-positive rate and blocking rate.
Define the strictness level of the footprint, either:
Low: By setting the strictness to Low the device will perform best
attacks blocking, however the false positive ratio is increased.
Medium: Default
High: By setting the strictness to High, the false-positive ratio is
reduced to minimum, however there may be a higher chance that
attacks will not be blocked.
3.
490

Security
Behavioral DoS Bandwidth Parameters

The Behavioral DoS Bandwidth Parameters window allows you to configure the amount of Bandwidth
for inbound and outbound traffic.
To create a B-DoS security policy, you first need to define the Bandwidth settings for Behavioral DoS
inbound and outbound traffic.
Note: Dont forget to enter bandwidth values before you configure network protections.
To set Behavioral DoS Bandwidth Parameters

1. From the Security menu select Behavioral DoS > Advanced > Bandwidth Parameters. The
Behavioral DoS Bandwidth Parameters window appears.
Parameter
Description
Inbound Bandwidth Available bandwidth for inbound traffic. The value should be lower than
[Kbit/Sec]
the bandwidth of the circuit or the assigned inbound bandwidth from your
Internet Service Provider.
Default: 300,000
Outbound
Bandwidth [Kbit/
Sec]
Available bandwidth for outbound traffic. The value should be lower than
the bandwidth of the circuit or the assigned outbound bandwidth from
your Internet Service Provider.
Default: 300,000
Behavioral DoS Learning Reset

Behavioral DoS protection learns traffic parameters from the transport layer of incoming packets
and generates normative baselines for traffic.
The Learning Period setting defines the period based upon which baselines are primarily weighted.
When the baseline for the policy is reset, the baseline traffic statistics are cleared and then
AppDirector immediately initiates a new learning period. This is done when the characteristics of the
protected network have changed entirely and bandwidth quotas need to be changed to
accommodate the network changes.
The Behavioral DoS Learning Reset window allows you to reset the learning period for all, none or
specific policies.
491

Security
To set the Behavioral DoS Learning Reset

1.
From the Security menu select Behavioral DoS > Advanced > Learning Reset. The
Behavioral DoS Learning Reset window appears.
2.
Set the parameters.
Parameter
Description
Reset Baseline For

Policy
From the dropdown list, select either:

None
All Policies according to the explanations provided.
3.
Behavioral DoS Set Default Quotas

The Behavioral DoS Default Quotas can be set in the Behavioral DoS Set Default Quotas window.
To set the Behavioral DoS Default Quota

1.
From the Security menu select Behavioral DoS > Advanced > Set Default Quota. The
Behavioral DoS Set Default Quota window appears.
2.
Behavioral DoS Protocol Quotas

The Behavioral DoS Protocol Quotas window allows you to define the quota limits for the percentage
of total inbound and outbound bandwidth that a specific protocol is permitted to use.
Note: You should always use the default quotas initially. Adjust quota values based on your
experience with your networks performance and usual protocol traffic characteristics.
To set the Behavioral DoS Protocol Quotas

1.
From the Security menu select Behavioral DoS > Advanced >Quotas. The Behavioral DoS
Protocol Quotas window appears.
2.
Select a direction. The Behavioral DoS Protocol Quotas window appears.
3.
Set the parameters.
492
Parameter
Description
Direction
Inbound or Outbound according to which direction was selected from

the table (Read-only).
TCP Quota [%]
Set the quota limits for the percentage of total inbound and outbound
bandwidth for the TCP quota.

Security
Parameter
Description
UDP Quota [%]
bandwidth for the UDP quota.
ICMP Quota [%]
bandwidth for the ICMP quota.
IGMP Quota [%]
bandwidth for the IGMP quota.
Bypass Footprints
Flood attacks commonly disrupt networks by using all or most of the available bandwidth.
You can configure AppDirector to detect and block network flood attacks by defining attack
footprints. Attack Footprints are selected fields in the packet header or payload. AppDirector
automatically detects the footprints and generates filters to protect against the attack
The following table displays the Footprint bypass types and values for each attack group.
Footprint Type
UDP
ICMP
TCP
IGMP
Default
Bypass
Values
Range
Transport layer checksum
NR
Values cannot
be configured.
No values.
TCP Sequence Number
NR
NR
NR
0 - (2^32-1)
IP ID Number
0 - (2^16-1)
DNS ID
NR
NR
NR
0 - (2^16-1)
DNS Qname checksum
NR
NR
NR
Values cannot
be configured.
No Values.
DNS Qcount
NR
NR
NR
0 - (2^16-1)
Source Port
NR
NR
0 - (2^16-1)
Source IP
0.0.0.0.
255.255.255.25
5
ToS
1 - 255
493

Security
Footprint Type
UDP
ICMP
TCP
IGMP
Default
Bypass
Values
Range
Packet Size
ICMP: 74 (60
L3)
0 - (2^16-1)
TCP Syn: 60,

62, 66,
74,(46, 48,
52, 60 L3)
TCP ACK: 60
(46 L3)
TCP ACK +
FIN: 60 (46
L3)
TCP RST: 60
(46 L3)
Fragment
Destination Port
NR
nr
0 - (2^16-1)
Destination IP
0.0.0.0 255.255.255.25
5
ICMP/IGMP Message Type
NR
NR
0-255
TTL
0-255
Values cannot
be configured.
No Values.
Behavioral TCP Footprint Bypass

The DoS Shield mechanism implements the sampling algorithm and accommodates traffic flooding
targeted to create denial of network services. The Behavioral TCP Footprint Bypass can be set in the
Behavioral TCP Footprint Bypass window.
To set the Behavioral TCP Footprint Bypass

1.
From the Security menu select Behavioral DoS > Advanced > Footprint Bypass > TCP. The
Behavioral TCP Footprint Bypass window appears.
2.
Select a bypass field. The Behavioral TCP Footprint Bypass Update window appears.
494

Security
Parameter
Description
Bypass Field
Enter the values for the Bypass fields:

Sequence Number - The Sequence number value from the TCP
packet header.
ID Number - The ID number from the IP packet header.
Source Port - The Source Port of the generated attack.
Source IP - The Source IP address of the generated attack.
ToS - The Type of Service value from the IP packet header.
Packet Size - The size of the packet in bytes, including data link
header.
Destination Undefined Port - The destination TCP port of the attack,
if the port is not defined in the Protected Service file for TCP SYN
Attack protection.
Destination Undefined IP - The destination IP address of the attack if
the host is not defined in the Protected Hosts file for TCP SYN Attack
protection.
Fragment - TCP Fragmented Packet.
Destination Defined Port - The destination TCP port of the attack, if
the port is explicitly defined in the Protected Services file for TCP
SYN Attack protection.
Destination Defined IP - The destination IP address of the attack, if
the host is explicitly defined in the Protected Hosts file for TCP SYN
Attack protection.
TTL - Time-to-Live value in the IP packet header.
Bypass Status
Allows you to define the status of the bypass, from the dropdown list.
Values: Accept (default), Bypass
Bypass Values
Enter the bypass values for the Bypass fields.

TCP Sequence Number: 0 - (2^32-1)
ID Number: 0 - (2^16-1)
Source Port: 0 - (2^16-1)
Source IP: 0 - (2^16-1)
ToS: 1-255
Packet Size: 0 - (2^16-1)
Destination Undefined Port: 0 - (2^16-1)
Fragment : No values
Destination Defined Port: 0 - (2^16-1)
Destination Defined IP: 0.0.0.0 - 255.255.255.255
TTL: 0 - 255
495

Security
Behavioral TCP Syn Footprint Bypass

The Behavioral TCP Syn Footprint Bypass window allows you to update the TCP-SYN Footprint
Bypass fields.
To set the Behavioral TCP Syn Footprint Bypass

1.
From the Security menu select Behavioral DoS > Advanced > Footprint Bypass > TCP
SYN. The Behavioral TCP Syn Footprint Bypass window appears.
2.
Select a bypass field. The Behavioral TCP Syn Footprint Bypass Update window appears.
3.
Set the parameters.
Parameter
Description
Bypass Field

Sequence Number - The Sequence number value from the TCP/
SYN packet header.
header.
Fragment - TCP/SYN Fragmented Packet.
Destination Defined Port - The destination TCP/SYN port of the
attack, if the port is explicitly defined in the Protected Services file
for TCP SYN Attack protection.
Destination Defined IP - The destination IP address of the attack,
if the host is explicitly defined in the Protected Hosts file for TCP
Bypass Status
496

Security
Parameter
Description
Bypass Values

Sequence Number - The Sequence number value from the TCP/
SYN packet header.
header.
Fragment - TCP/SYN Fragmented Packet.
Destination Defined Port - The destination TCP/SYN port of the
attack, if the port is explicitly defined in the Protected Services file
for TCP SYN Attack protection.
Destination Defined IP - The destination IP address of the attack,
if the host is explicitly defined in the Protected Hosts file for TCP
Behavioral UDP Footprint Bypass

The Behavioral UDP Footprint Bypass window allows you to update the UDP Bypass field, status and
values.
To set the Behavioral UDP Footprint Bypass

1. From the Security menu select Behavioral DoS > Advanced > Footprint Bypass > UDP. The
Behavioral UDP Footprint Bypass window appears.
2. Select a bypass field. The Behavioral UDP Footprint Bypass Update window appears.
497

Security
3.
Set the parameters.
Parameter
Description
Bypass Field

Enter in the values for the Bypass fields:
Checksum - Checksum value in the UDP header of the packet.
Packet ID Number - ID number in the IP packet header.
DNS Query ID Number - ID number of a DNS query.
DNS Query Qname - Domain name requested by a DNS query.
DNS Qcount - Number of DNS queries in a single DNS session.
Source Port -Source port of the attack.
Source IP - Source IP address of the attack.
ToS -Type of Service value from the IP packet header.
Packet Size - Size of the packet in bytes, including the data-link
layer.
Destination Undefined Port - Destination port of the attack, if this
port is not defined in the Protected Services table.
Destination undefined IP - Destination IP address of the attack, if
this host is not defined in the Protected Hosts Table.
Fragment - UDP fragmented packet.
Destination Defined Port - Destination port of the attack, if this port
is defined in the Protected Services table.
Destination Defined IP - Destination IP address of the attack, if this
host is defined in the Protected Hosts table.
TTL - Time-To-Live value in the IP packet header.
Bypass Status
Bypass Values

Checksum: No values
Packet ID Number: 0 - (2^32-1)
DNS Query ID Number: 0 - (2^16-1)
DNS Query Qname: No Values
DNS Qcount: 0 - (2^16-1)
Source Port: 0 - (2^32-1)
Source IP: 0.0.0.0 - 255.255.255.255
ToS: 1- 255
Packet Size: 0 - (2^16-1)
Destination Undefined Port: 0 - (2^16-1)
Destination undefined IP: 0.0.0.0 - 255.255.255.255
Fragment : No values
Destination Defined Port: 0 - (2^16-1)
TTL: 0 - 255
4.
498

Security
Behavioral ICMP Footprint Bypass

ICMP Header Violation attacks exploits existing vulnerabilities in some of the IP stack
implementations through corrupted ICMP packets (i.e., Unknown IMCP message types, etc.).
The Behavioral ICMP Footprint Bypass window allows you to update the ICMP Bypass field, status
and values.
To set the Behavioral ICMP Footprint Bypass

1. From the Security menu select Behavioral DoS > Advanced > Footprint Bypass > ICMP.
The Behavioral ICMP Footprint Bypass window appears.
2. Select a bypass field. The Behavioral ICMP Footprint Bypass Update window appears.
Behavioral IGMP Footprint Bypass

The Behavioral IGMP Footprint Bypass window allows you to update the IGMP Bypass field, status
and values.
To set the Behavioral IGMP Footprint Bypass

1. From the Security menu select Behavioral DoS > Advanced > Footprint Bypass > IGMP.
The Behavioral IGMP Footprint Bypass window appears.
2. Select a bypass field. The Behavioral IGMP Footprint Bypass Update window appears.
Connection Limit
The Dos-Shield module provides protection against known DoS attacks. To protect against unknown
flooding attacks, AppDirector implements the connection limit capability. This mitigates any kind of
TCP or UDP flood attack whether a half-open attack (SYN-attack), a connection attack or a request
attack.
Connection Limit Profiles, page 500
Connection Limit Policies, page 500
Connection Limit Attacks, page 501
499

Security
Connection Limit Profiles

The Connection Limit Profiles window allows you to create a new Connection Limit profile.
To create a connection limit profile

1.
From the Security menu select Connection Limit > Profiles. The Connection Limiting Profiles
window appears.
2.
Select Create. The Connection Limiting Profiles Create window appears
3.
Set the parameters.
4.
Parameter
Description
Connection Limiting
Profile
Type in a user defined name for your new profile.
Connection Limiting
Attack
Select the type of attack from the dropdown list .
Connection Limit Policies

The Connection Limit Policies window allows you to define a policy for the Connection Limit.
To create a connection limit policy

1.
From the Security menu select Connection Limit > Policy. The Connection Limiting Policy
window appears.
2.
Select Create. The Connection Limiting Policy Create window appears
3.
Set the parameters.
Parameter
Description
Policy Name
The name of the policy to be applied.
Policy Profile
From the Policy dropdown list select the name of your profile created in
the Behavioral DoS Profiles window.
Policy Source Address Definition of the external network range to which the Policy is applied.
The range of IP addresses making up the protected network. You must
enter the Policy Source Address of the protected network to activate
protection. All defined protected hosts are automatically entered into
the network range.
Default: Any.
Policy Destination
Address
Definition of the internal network range to which the Policy is applied.

The range of IP addresses making up the protected network
You must enter the Policy Destination Address of the protected network
to activate protection. All defined protected hosts are automatically
entered into the network range.
Default: Any.
500

Security
Parameter
Description
Direction
From the dropdown list select the direction of your policy, either:
Oneway (default) - Protects from attacks from the external to
internal (inbound traffic)
Twoway - Protects from attacks from external to Internal and from
Internal to external (outbound).
Inbound Physical Port

Group
The physical port group of the device that receives the inbound traffic.
State

Active (default)
Inactive
VLAN Tag Group
Defines VLAN traffic classification according to VLAN ID tags.
Action
Defines the required action of the policy, select either:

Report Only.
Block and Report (default)
Connection Limit Attacks

The Connection Limit Attacks window allows you to define a Connection Limit Attack.
To create a connection limit attack

1. From the Security menu select Connection Limit > Attacks. The Connection Limiting Attack
window appears.
2. Select Create. The Connection Limiting Attack Create window appears.
Parameter
Description
ID
Attack Name
User-defined name for this attack. Attack Name is used when DoS Shield
sends information about attack status changes (read-only).
Destination App.
Port
Group of Layer 4 ports that represent the application that you want to
protect.
Protocol
Layer 4 protocol of the application that you want to protect, TCP/UDP.
Threshold
Maximum number of sessions per second that allowed for each Layer3
entity tracked by this attack any additional session is dropped. When
the threshold is reached an attack is identified and alert is sent.
Default: 10
501

Security
Parameter
Description
Tracking Type
Defines how the device decides which traffic to block or drop, when under
an attack of this type.
Values:
Source Count: Select this option when the defined attack is sourcebased, meaning the hacker attack can be recognized according to its
source address. For example: Horizontal Port Scan, were the hacker
scans a certain application port (TCP or UDP) to detect which servers
are available on the network.
destination such as a Web server. For example: Ping Flood and DDoS
attacks
Source and Target Count: Select this option when the attack type is a
source and destination based attack, meaning the hacker is attacking
from a specific source IP to a specific destination IP. For example:
Port Scan attack.
Action Mode

address.
Risk
You can define the attack risk as High, Medium, or Low depending on the
severity of the damage that the attack can cause to your system.
Default: Medium
Tracking Time
Sets the amount of time, in milliseconds, for measuring Threshold. When

a number of packets exceeding the Threshold value passes through the
device within the configured Tracking Time period, the device recognizes
it as an attack.
Default: 1000
502

Security
Parameter
Description
Suspend Action
This enables you to define that for certain attacks, in addition to the
action defined in the attack, the device should also suspend traffic from
the IP address that was the source of the attack, for a period of time.
Values:
SrcIP, DestIP: Traffic from the IP address identified as source of this
attack to the destination IP under attack will be suspended.
suspended.
source of this attack to the destination IP and port under attack will
be suspended.
SrcIP, DestIP, SrcPort, DestPort. Traffic from the IP address and port
identified as source of this attack to the destination IP and port under
Global Suspend Table

The Suspend Table allows you to set the device to suspend traffic from the IP address that was the
source of the attack for a defined period of time. The Suspend Action is available as an option for the
attack types:
Intrusions
Anomalies
Anti-Scanning
DoS/DDoS
The period for which a source is suspended is set according to the following algorithm:
The first time a source is suspended, the suspension time is according to the Minimal Aging Time
configured for the Suspend Table.
Each time the same source is suspended again the suspension length is doubled, until it reaches the
Maximum Aging Time set for the Suspend Table.
Once the suspension length has reached the maximum length allowed, it will remain constant for
each additional suspension.
Global Suspend Table Parameters, page 504
Global Suspend Table, page 504
503

Security
Global Suspend Table Parameters

The Suspend Table Parameters window enables you to set the tuning parameters for the Suspend
Table.
To set the Suspend Table parameters

1.
From the Security menu select Global > Suspend Table > Parameters. The Suspend Table
2.
Set the parameters.
Parameter
Description
Suspend Table min.

blocking time [Sec]
Length of time for which source IPs that are first-time offenders are
suspended.
Default: 10 seconds
Suspend Table max

blocking time [Sec]
Maximum length of time for which a source IP can be suspended.
Suspend Table max

same source entries
If the number of entries for the same source IP is higher than this
threshold all traffic from this source IP is suspended (this can happen
when Suspend Action is not set to SrcIP only)
Default: 600 seconds
Default: 4
3.
Global Suspend Table

The Suspend Table window allows you to view and monitor attacks that are currently in the Suspend
Table.
To view the Suspend Table

From the Security menu select Global > Suspend Table > Table. The Suspend Table Parameters
window appears, which contains the following read-only parameters.
Security Reporting
A security event is an attack or a protocol anomaly. You can configure each device to alert you
whenever a security event takes place.
When an attack is detected, the device creates a security event that includes the information
relevant to the specific attack. Once an event has been created, the device reports it in the following
ways:
Security Logs, which are saved in a flash.
SNMP traps.
Syslog messages can be sent to a Syslog station.
E-mail messages can be sent to specific users.
Security Terminal Echo
You can enable the reporting channels used by Radware devices to receive information about
security events. You can also set the device to report detected attacks based on various risk levels.
504

Security
The Security Reporting option contains these features:
Reporting Global Parameters, page 505
NetForensics, page 506
Top Ten Attacks, page 506
Reporting Security Log Show, page 507
Reporting Security Log Clear, page 509
Reporting Global Parameters

The Reporting Global Parameters window allows you to enable AppDirector reporting channels, set
the polling time parameters of the Alert Table and the Log File.
To define the Reporting Global Parameters

1. From the Security menu, select Reporting > Global Parameters. The Global Parameters
Information window appears.
Parameter
Description
Report Interval
Number of seconds that defines frequency in which the reports are sent
though the reporting channels.
Default: 5
Max Alerts per

Report
Number of alerts that define the maximum number of security events

that can appear in each report (sent within the reporting interval).
Default: 1000
Report Per-Attack
Aggregation
Threshold
Sets the number of events for a specific attack during a reporting interval
before the events are aggregated to a report.
Default: 5
Note: When the number of generated events exceeds the Report
Aggregation Threshold value, the IP value of the event appears
as 0.0.0.0, which indicates "Any."
SNMP Traps Sending Enable/Disable (default) sending of SNMP traps.

Syslog Sending
Enable/Disable (default) sending of syslog.
Terminal Echo
Enable/Disable (default) reporting using the terminal echo.
Email Sending
Enable/Disable (default) sending email reports.
SNMP Traps Sending Defines the risk level.

Risk
Values: Low (default), Medium, High
Email Sending Risk
Defines the risk level.

Terminal Echo Risk

Syslog Sending Risk Defines the risk level.

505

Security
Parameter
Description
Security Log Status
All events and alerts are logged in an all-purpose cyclic Log File. The Log
File can be obtained at any time but its size is limited. When the number
of entries is beyond the permitted limit, the oldest entries are
overwritten. You are notified about the status of Log File utilization.
Notifications appear when the file is 80% utilized and 100% utilized.
Values: Enable/Disable (default)
3.
NetForensics
netForensics is a Security Information Management (SIM) that gathers information from various
security equipment in the network and provides analysis tools and a unified view of network
security. netForensics supports the collection of security events generated by Radware devices.
To set the NetForensics parameters

1.
From the Security menu, select Reporting > NetForensic. The NetForensic Reporting
2.
Set the parameters.
Parameter
Description
Reporting Status
Defines reporting status to NetForensic agent.

Values: Enabled/Disabled (default)
Agent IP Address
The IP address of the NetForensic collector.

Default: 0.0.0.0
Agent Port
The TCP listening port of the NetForensic collector.

Default: 555
3.
Top Ten Attacks

Predefined attack reports help you to explore Security attack patterns over time. Radware has
created predefined reports for specific types of attack analysis. Attacks can be ranked by volume
and by type. Predefined reports also include reports for groups of attacks, or attacks relating to a
specific module.
Predefined reports allow you to focus attention on specific threats. Attack information is pre-sorted,
with the most important security event information plotted in easily read charts, for your
convenience.
The following predefined attack reports are available:
Parameter
Description
SNMP Traps Sending

Risk
Email Sending Risk

506

Security
Parameter
Description
Terminal Echo Risk

Syslog Sending Risk

Security Log Status
All events and alerts are logged in an all-purpose cyclic Log File. The Log
File can be obtained at any time.
The size of Log File is limited. When the number of entries is beyond the
permitted limit, the oldest entries are overwritten. You are notified
regarding the status of the Log File utilization. The notifications appear
when the file is 80% utilized and 100% utilized.
Values: Enable/Disable (default)
To generate a predefined report

1. From the Security menu select Reporting > Top Ten Attacks. The Top Ten Attacks window
appears.
Parameter
Description
Choose Type
Select the type of attack report you want.
Seconds
Enter the number of seconds (retroactive from the current time) for the
report.
3. Click Set. The report is generated and displayed.
Reporting Security Log Show

When the device recognizes security events, they are logged in a cyclic Log File. This can be
accessed at any time, but it is limited; when the entry number exceeds the limit, the oldest entries
are overwritten. Notifications about the Log File utilization status appear when the file is 80% and
100% utilized. To start logging, configure one or more devices to perform logging.
All events and alerts are logged in an all-purpose cyclic Log File. This can be obtained at any time.
To The size of Log File is limited. When the number of entries is beyond the permitted limit, the
oldest entries are overwritten. You are notified regarding the status of the Log File utilization.
The notifications appear when the file is 80% utilized and 100% utilized.view alerts
1. From the Security menu, select Reporting > Security Log > Show. The Security Log File
window appears.
2. From the Logfile Table, click on the Attack Index number to view the event parameters of the
attack. The Security Log File Update window appears, showing the event parameters.
507

Security
3.
Set the parameters.
Parameter
Description
Attack Index
The number of the entry in the table.
Radware ID
ID Radwares unique identifier of the attack.
Attack Name
The name of the attack that was detected.
Attack Source Address The IP address from which the attack arrived.
Attack Destination
Address
The IP address to which the attack is destined.
Message Type
The current status of the event:

Occurred - Each packet matched with signatures is reported as an
attack and must be dropped. In that case the Tracking Type that is
activated is Drop All.
Started/terminated - When the amount of packets that match with
signatures, goes beyond the predefined threshold within the
Tracking Time, the reported Attack Status is started. When the
amount of packets that match with signatures is below the
predefined threshold, the reported Attack Status becomes
terminated. In that case the Tracking Type that is activated is
Target, or Target & Source.
Attack Time
The time and date when the report was generated.
Source Port
TCP/UDP source port.
Destination Port
TCP/UDP destination port
Context
Context in which the attack was recognized: Regular/ SSL tunneling.
Protocol
The transmission protocol used: TCP/ UDP/ ICMP/IP.
Physical Port
The port on the device from which the attack arrived.
VLAN Tag
VLAN Tag information, according to which you can generate reports for
each customer by using the customer's VLAN Tag value. A value of "0"
in this field indicates that the VLAN Tag is not available.
Note: AppDirector on Application Switch 4 does not support VLAN
Tagging, and a value of "0" is always placed.
Category
The category of the attack: Anomalies, Anti-Scanning, DOS, Intrusion.
Policy Name
The policy that was used to detect the attack.
Packet Count
The number of packets in the attack since the latest trap was sent.
Byte Count
The number of Bytes that were dropped/forwarded.
Action
The reported action can be:

Forward: The packet is forwarded to its destination.
Drop: The packet is discarded.
address.
508

Security
Parameter
Description
Report Mode
The following Report Modes are available:

Drop: The packet is discarded.
Forward: The packet is forwarded to the defined destination.
Reset Source: Sends TCP-Reset packet to the packet Source IP.
Reset Destination: Sends TCP-Reset packet to the destination
address.
Default: Takes the Action Mode parameter defined in the
Application Security Global Parameters window.
Risk
How dangerous the attack is: High, Low, Medium, Not Available.
4. Click Set. The report is generated and displayed.
Reporting Security Log Clear

The Security Log Clear window allows you to clear the previously created log.
To clear the Log

1. From the Security menu select Reporting > Security Log > Clear. The Clear Security Log
window appears.
2. Click Set. The Security log is cleared.
Attack Database
The Dormant Attacks database is a list of attacks supplied by Radware. These attacks provide
constant protection against all recent DoS attacks. Each attack includes protection filters that are
configured to detect and block malicious packets. You can use these attacks to define prevention
profiles. Most existing DoS attacks can be prevented using Radware attacks.
Attack Database Version

The Attack Database Version window is a read-only window displaying the version of the current
attack database.
To view the attack database version

From the Security menu select Attack Database > Version. The Attack Database Version window
appears, displaying the version number of the current attack database.
Attack Database Send to Device

The Application Security module uses the Application Security Signature File Update feature for
constant updates of the signatures database. All devices with the Application Security module are
updated using the latest Application Security Signature file, which is a database that contains a list
of updated attacks.
The update of the Application Security Signature File is performed per device using the Send to
Device window.
509

Security
You can download an updated Application Security Signature file from the Radware Web site every
Monday. If an emergency update is required, the Web site is updated in addition to weekly updates.
To view the Attack Database version:

1.
From the Security menu, select Attack Database > Send to Device. The Send to Device
window appears displaying the current Attack Database version of the device.
2.
From the File field, type the name of the file, or click Browse to navigate to the relevant file.
3.
Click Set.
View Active Policy Extensions

You can view the additional policy parameters in the Active Policies Extensions window.
To view Active Policies Extensions

From the BWM menu, select View Active > Policy Extensions. The Active Policies Extensions
window appears, which contains these read-only parameters.
Parameter
Description
Name
Indicates whether classification is performed before/after packet

modification.
Traffic Flow Identification
Defines what type of traffic flow we are going to limit via this policy.
The available options are:
Client (source IP).
Traffic Flow Max BW

(Kbps)
Maximum bandwidth in Kbps allowed per traffic flow.
Max Concurrent Sessions

Note: This option is not available if the Traffic Flow Identifier is set
to Session or FullL4Session.
Max HTTP Rqts Per

Second
HEAD per Cookie.
Cookie Field Identifier
SessionCookie. The BWM classifier searches for the Cookie
Field Identifier followed by = and classifies flows according
to value.
510

Security
Parameter
Description
Policy Group
Inactivation Schedule

Modify Policy Group

policies, enabling them to borrow from other policies preventing starvation and utilizing the
bandwidth more efficiently. Only policies that participate in a specific group can share bandwidth.
To total bandwidth available for a policy group is the sum of Guaranteed Bandwidth values of all
policies in the group.
The Policies Group table contains all the bandwidth policy groups. You can add new policy groups to
this table.
Note: For all the policies associated with a policy group, the Guaranteed Bandwidth parameter
must be set to a value greater than 0 and Borrowing Limit parameter to 0. The Dynamic
Borrowing global parameter must be enabled.
To create a new Policy Group

1. From the Bandwidth Management menu, select Modify > Policy Groups. The Modify Policy
Group Table window appears.
2. Click Create. The Modify Policy Group Table Create window appears.
3. In the Name text box, type the name of the new Policy Group and click Set. The new policy
group appears in the Modify Policy Group Table window and the Active Policy Group Table.
Editing Port Bandwidth

To optimize the queuing algorithm, it is essential for the BWM module to be aware of the maximum
available ports bandwidth. This can be configured via the BWM Port Bandwidth table. By default, the
maximum available is determined by the port type - 100 Mbps for FE ports and 1Gbps for Giga
ports. The queuing filter only starts functioning upon link saturation. Configuring the maximum is
the only way to determine if the link is saturated.
To edit Port Bandwidth

1. From the BWM menu select Miscellaneous > Port Bandwidth Table. The Port Bandwidth
2. Select the port for which you require to edit the bandwidth. The Port Bandwidth Table Update
window appears.
511

Security
3.
4.
Set the parameters.
Parameter
Description
Port Index
The port number.
Port Bandwidth
(kbps)
The bandwidth available to the specific port.
Port Used Bandwidth

(kbps)
The amount of bandwidth used on the specific port.
Cancel Classification Per Port

This feature enables the user to configure ports where classification is not performed. In this way
valuable processing time can be saved while enabling a simpler method of configuring the device.
Cancel Classification Per VLAN is also available for a VLAN configuration.
To cancel classification for a port

1.
From the BWM menu select Miscellaneous > Cancel Classification Per Port. The Cancel
Classification Per Port window appears.
2.
Set the parameters.
3.
Parameter
Description
Inbound Port
The number of the required port for inbound traffic.
Outbound Port
The number of the required port for outbound traffic.
Direction
Direction of traffic flow through each port. Values can be Oneway, the
traffic flows in through the Inbound Port and out through the Outbound
Port, or Twoway, the traffic flows both ways through both ports.
Update Policies
In case you edit the parameters of a basic filter or an advanced filter, which is bound to the existing
policy, you need to update the policy with the recent changes.
To activate the latest changes

1.
From Security menu, select Update Policies. The Activate Latest Changes window appears.
2.
Click Set. The policies are updated.
Packet Anomalies
To avoid detection, hackers use evasion techniques, such as splitting packets and sending attacks in
fragments. An attack that contains fragmented packets is called a Protocol Anomaly attack. These
attacks are detected and blocked.
512

Security
Whenever a packet matching one of the predefined checks arrives, it is automatically blocked
,discarded and reported. However you can also allow certain anomalous traffic to flow through the
device without inspection.
The Packet Anomalies window allows you to allow certain packets to pass through the device without
inspection and defining the risk factor.
To set the Packet Anomalies parameters

1. From the Security menu, select Packet Anomalies > Attacks. The Packet Anomalies Attacks
window appears.
2. Select the relevant ID from the table. The Packet Anomalies Attacks Update window appears.
Parameter
Description
ID
Displays the selected ID number of the packet selected from the table.
Name
Displays the name of the Packet Anomaly according to what was selected
in the Packet Anomalies table.
Action
From the dropdown list, define the action for the Packet Anomaly, select
either:
Forward: Selecting Forward means that the packet is allowed to pass
through the device without inspection.
Drop: Selecting Drop means that the Packet is dropped.
Risk
Define the risk for the Packet Anomaly according to your preference.
Values: Info, Low, Medium, High
Modifying Application Port Groups

by its unique name and each group name can be associated with a number of entries in the
To create the Modify Appl. Port Groups Table parameters

1. From the Classes menu, select Modify Appl Port Groups. The Modify Appl. Port Groups Table
window appears.
2. Click Create. The Modify Appl. Port Groups Table Create window appears.
3. Set the parameters..
Parameter
Description
Name
A user defined group name.
From Port
Define the first port in the range. (Values from 0)
To Port
Define the last port in the range.(Values to 65535)
Group Type
513

Security
Notes:
>> To define a group with a single port, set the same value for the From Port and To Port
parameters.
>> To associate a number of ranges with the same port group, use the same group name
for all the ranges that you want to include in one group.
4.
To update the parameters of the Modify Appl. Port Groups Table

1.
From the Classes menu, select Modify Appl Port Groups. The Modify Appl. Port Groups Table
window appears.
2.
Click on the application name. The Modify Appl. Port Groups Table Update window appears.
Proceed from step 3.
Viewing Application Port Groups
To view active application port groups

1.
From the Classes menu, select View Active > Appl Port Groups. The Active Application Port
2.
Select the desired name. The Active Application Port Groups Table Update window appears with
read-only parameters. See To create the Modify Appl. Port Groups Table parameters, page 513.
Modify MAC Groups
To modify MAC Groups

1.
From the Classes menu select Modify > MAC Groups. The Modify MAC Address Groups Table
appears.
2.
Click Create. The Modify MAC Address Groups Table Create window appears.
3.
Set the parameters.
4.
514
Parameter
Description
Group Name
The name of the MAC address group.
MAC Address
A MAC address number.

Security
View Active MAC Groups

To classify traffic according to Mac addresses, you can create groups of Mac addresses.
To view the Active MAC Groups:

From the Classes menu select View Active MAC Groups. The Active MAC Address Groups Table
window appears with read-only parameters. See To modify MAC Groups, page 514.
View Active VLAN Tag Groups

The Active VLAN Tags Table Update window allows you to view the active VLAN tag groups.
To view the Active VLAN Tag Groups

1. From the Classes menu select View Active VLAN tag Groups. The Active VLAN Tags Table
window appears.
2. Select a group name. The Active VLAN Tags Table Update window appears which contains the
following read-only parameters:
Note: This is applicable only when the 802.1q parameter is set to Enabled. Classifications
performed according to the tag of the received packet.
Modify Port Groups

then associate a Port Group to the required policies.
The Modify Physical Port Groups Table window allows you to modify an existing port group.

1. From the Classes menu, select Modify Port Groups. The Modify Physical Port Groups Table
window appears.
2. Select a group name. The Modify Physical Port Groups Table Update window appears.
Parameter
Description
Group Name
The user-configured name of the port group.
Inbound Port
The inbound port for this group. Values can be a port number or Any.
515

Security
To create a new port group

1.
From the Classes menu select Modify >Port Groups. The Modify Physical Port Groups Table
window appears.
2.
Select Create. The Physical Port Groups Table Create window appears. Proceed as step 3.
Application Security Tuning

From the Application Security Tuning Parameters window you can view and edit the application
security tuning parameters. The changes take effect after the reset.
Caution: It is strongly advised that Application Security tuning only be performed after
consulting Radware Technical Support.
To tune AppDirector Application Security tables

1.
From the Services menu, select Tuning > Security > Application Security. The Application
Security Tuning window appears.
2.
Set the parameters.
Parameter
Description
Source Table
The current number of entries in the Source Table that contains attacks
detection mechanism, which is based on the source addresses of the
incoming traffic.
If the number of packets sent from the same source is above the
predefined limit, this is identified as an attack.
The Source Table tuning parameter defines in how many sessions to
check the source address.
Source Table After

Reset
The number of entries in the Source Table after reset.
Target Table
Represents the current size of the table for destination entries. This
table contains attacks detection mechanism, which is based on the
destination addresses of the incoming traffic.
If the number of packets sent to the same destination is above the
predefined limit, this is identified as an attack.
The Target Table tuning parameter defines in how many sessions to
check the destination address.
516
Target Table After

Reset
The size of the table for destination entries that you define. The
settings are applied after reset.
Source and Target

Table
Represents the current size of the table for both source and destination
entries, which are counted as one.
Source and Target

Table After Reset
The size of the table for both source and destination entries that you
define. The settings are applied after reset.

Security
Parameter
Description
DHCP Table
The current number of entries in the DHCP Table that contains attacks
detection mechanism based on counting of IP requests for each MAC
address.
The requests are made using the Dynamic Host Configuration Protocol.
When the number of IP requests for a particular MAC address is above
the predefined limit, an attack is identified.
The DHCP Discover tuning parameter determines for how many MAC
addresses to check the number of IP requests.
DHCP Table After

Reset
Number of entries in the DHCP Table after reset.
Maximal number of
groups to be defined
by user

device.
Maximal number of
groups to be defined
by user after reset

device after reset.
Maximal number of
by user

device.
Maximal number of
by user after reset

device after reset.
IP Reassembly buffers Current allotted memory, in MB, of the IP Reassembly buffers pool.
pool size [MB]
IP Reassembly buffers Allotted memory, in MB, of the IP Reassembly buffers pool after reset.
pool size after reset
[MB]
Maximal number of
Maximum number of entries that can be defined in the NPCF table.
Maximal number of
after reset
Maximum number of entries that can be defined in the NPCF table after
reset.
Maximal number of
srcIPs in Suspend
Table
Maximum number of entries that can be defined in the Suspend table.
Maximal number of
srcIPs in Suspend
Table after reset
Maximum number of entries that can be defined in the Suspend table

after reset.
Maximal number of
Maximum number of entries that can be defined in the Anti-Scanning IP
Anti-Scanning IP pairs pairs table.
Table
Maximal number of
Maximum number of entries that can be defined in the Anti-Scanning IP
Anti-Scanning IP pairs pairs table after reset.
Table after reset
517

Security
Behavioral DoS Tuning Parameters

The Behavioral DoS Tuning Parameters window allows you to set the maximal number of Behavioral
DoS policies. The default number of policies for Behavioral DoS is 10. If you wish to configure more
then you need to reset the number of policies allowed.
Note: Each time you update a value for a Behavioral DoS, you can check whether there is
enough free memory for the requested value.
To set the maximum number of Behavioral DoS policies

1.
From the Services menu, select Tuning > Security > Behavioral DoS. The Behavioral DoS
Tuning Parameters window appears.
2.
Set the parameters.
3.
518
Parameter
Description
Maximal number of
Behavioral DoS
policies
Maximum number of Behavioral DoS policies that can be defined on the

device.
Maximal number of
Behavioral DoS
policies after reset
Maximum number of Behavioral DoS policies that can be defined on the

device after reset.
Appendix A Radware Technical Glossary

This glossary is a list of terms and definitions used in the Radware technical environment. Some of
the words belong to the public domain, and some are Radware-specific, but all are used in the
Radware documentation.
Term
Definition
802.1Q Trunking
802.1Q Trunking is an IEEE protocol that interconnects VLANs between

multiple switches, routers, and servers. With 802.1Q. A network administrator
can define a VLAN topology to span multiple physical devices. When VLANs are
physically attached to different switches, because the trunk link carries traffic
for all of these VLANs, all the users in a given VLAN are in the same broadcast
domain.
IEEE 802.1Q switches normally support FastEthernet and GigabitEthernet
interfaces. An 802.1Q trunk link provides VLAN identification by adding a 4byte tag to an Ethernet Frame as it leaves a trunk port. Because the frame has
been changed, a new frame check sequence (FCS) must also be computed and
added to the frame.
Active-Active
Active-Active is a redundancy configuration involving two AppDirector devices

(both must be the same type) where each device can be both the Active
device for predefined Farms and the Backup device for other Farms. In the
event of a failure of one device, the other device temporarily assumes
ownership of all Farms.
Active-Backup
In an Active/Backup configuration, the primary AppDirector device is

configured with the primary Virtual IP addresses. This device performs the
regular AppDirector operations, handling all the inbound sessions to the
Virtual IP addresses and distributing traffic among the servers in the farm
linked to the Virtual IP address (via Layer 4 Policy).
519

Radware Technical Glossary
Term
Definition
Application
Delivery
Controller (ADC)
Application Delivery Controllers (ADCs) enhance the performance and security

of Web- or Internet Protocol-based applications for end users by providing a
suite of services at the network and application layers.
ADCs reside in the data center, in front of frontline Web servers; devices for
optimizing response time of applications on a network, using load balancing
technologies on Layer 4-7. They are deployed asymmetrically (only at the data
center end). These services can include:
Layer 4 through Layer 7 redirection, load balancing and failover.
Transmission Control Protocol (TCP) connection multiplexing.
Server offloading (for example, SSL termination and TCP connection
management).
Data compression.
Network-address translation.
Network-level security functions, distributed denial-of-service protection
and server cloaking.
Selective compression.
Caching.
Content transformation and rewrite.
Application firewall.
Transaction assurance.
Rules and programmatic interfaces.
HTML (and other application protocol) optimizations "pre-fetching" or
selective encoding.
Virtualization.
Application
Delivery Network
An Application Delivery Network (ADN) is a suite of technologies that, when

deployed together, provide application availability, security, and acceleration.
At the core of an ADN is the Application Delivery Controller (ADC), an
advanced traffic management device that is often also referred to as a web
switch, content switch, or multilayer switch, the purpose of which is to
distribute traffic among a number of servers or geographically dislocated sites
based on application specific criterion.
The ADN evolved from Layer 4-7 switches in the late 1990s when it became
apparent that traditional load balancing techniques were not robust enough to
handle the increasingly complex mix of application traffic being delivered over
a wider variety of network connectivity options.
AND Group
520
An AND Group is a combination of basic services (link) with a logical AND

between them. AND Group is defined as a part of Classes (link) traffic
characterization.

Term
Definition
Anycast
Anycast is a network addressing and routing scheme that allows a single IP

address to be announced from multiple locations. Data is routed to the
"nearest" or "best" destination as determined by the routing topology, such as
Proximity. With Anycast, although it is a one-to-many association, only one
receiver is chosen, as determined by proximity.
With Unicast, there is a one-to-one association between source and receiver.
With Broadcast and Multicast, there is a one-to-many association between the
source address and network endpoints (all information is replicated).
Anycast offers two failover mechanisms:
Equal Anycast uses standard routing protocols (BGP, OSPF, and RIP) to
advertise service availability from all global AppDirector sites. It relies on the
routing logic to govern the delivery of messages to one of these locations.
Using Equal Anycast optimizes the user response time, as each request is
routed to the closest site.
Prioritized Anycast allows the selective failover mechanism by advertising
the service with different priorities to different locations. As a result, once a
site fails, the routing system will immediately redirect its traffic to the backup
sites. Prioritized Anycast allows transparent application continuity in case of
site failure.
API
An Application Programming Interface (API) is a source code interface that a

computer application, operating system or library provides to support requests
for services to be made of it by a computer program.
An API is similar to an Application Binary Interface (ABI) in that it specifies
details of how two independent computer programs can interact, however an
API is defined at a higher level.
AppDirector
(Radware)
Radware AppDirector (AD) is an intelligent application delivery controller for

data centers that provides scalability and application-level security for IT
infrastructure optimization, fault tolerance and redundancy.
AppDirector combines the power of Radwares Multi-Gigabit Application
Switching hardware with APSolute OS Application-Smart Networking to ensure
local and global server availability, accelerated application performance and
safeguard applications with integrated intrusion prevention and denial of
service protection for fast, reliable, secure application delivery.
AppDirector uses advanced Layer 4-7 policies and granular application
intelligence for end-to-end application-smart networking, aligning server
infrastructure operations with application front end requirements to eliminate
traffic surges, server bottlenecks, connectivity disconnects and downtime for
assured application access, full application continuity and redundancy.
AppDirector enables fine tuning of network behavior at all critical points, endto-end, based on granular application-specific classification of packets to
optimize traffic flows for a wide range of enterprise web applications such as
CRM, ERP, and other IP-based applications including support for VoIP,
streaming media, and secure LDAP applications.
521

Term
Definition
Application
Delivery
Controller
(Radware)
Radwares Application Delivery Controller (ADC) solution ensures application

uptime and transaction completion through real time identification and
bypassing of inactive / faulty elements along the transaction path (such as,
application failure, server failure, server farm failure or site failure). The
integrated local and global load balancing capabilities provide the industrys
most comprehensive disaster recovery solution for globally dispersed data
centers, guaranteeing optimal response time and application availability at all
times.
ADC provides:
Removal of performance bottlenecks
Full availability of the entire transaction path, accelerating response time
across Wide Area Network connections
Comprehensive mitigation of network and application level attacks
Application
Grouping
Application Grouping allows you to select the next hop routers to handle traffic
destined for a specific application port.
APSolute
Operating System
The APSolute Operating System is the operating system for the Radware
ASIC-based Application Switches. The AppDirector is based on Radwares
APSolute Operating System.
You use the Application Grouping Table to configure destination grouping.

Application grouping is only available when Client Table Mode is set to Layer 4.
The core of this OS is a classification and flow-management engine that uses a

rule database for traffic identification and redirection. The database is
configured with policies based on Layer 3 to Layer 7 information, including
source and destination IPs, application type, session IDs, cookies, payload
information and content.
ARP
Address Resolution Protocol (ARP) is the standard Layer 2 method for finding a
host's hardware address (MAC) via its network layer address (IP).
A client station broadcasts an ARP request onto the network with the IP
address of the target node it wishes to communicate with, and the node with
that address responds by sending back its physical address so that packets
can be transmitted. ARP returns the layer 2 address for a layer 3 address.
Due to the overwhelming prevalence of IPv4 and Ethernet, ARP is primarily
used to translate IP addresses to Ethernet MAC addresses. It is also used for
IP over other LAN technologies, such as Token Ring, FDDI, or IEEE 802.11,
and for IP over ATM.
522

Term
Definition
ARP, Fake
A Fake ARP is an optional, additional Gratuitous ARP broadcast sent by a

Backup AppDirector device containing an IP Address owned by an Active
device and using the Active MAC Address.
In a redundancy cluster with two AppDirector devices, the Backup device
constantly monitors the health of the Active device. When it detects that the
main device is down it takes over control, including IP addresses, . The backup
device sends gratuitous ARPs to all local stations informing them that the main
device IP addresses now correspond to the MAC addresses of the backup
device.
After the Active device becomes active again, it also does the same; it sends
gratuitous ARP to all local stations informing them that the main device IP
addresses now correspond to the MAC addresses of the main device.
To speed up this process, the backup device publishes a message. This is a
fake ARP, as one device (the backup) publishes the ARP of another device (the
Active). The fake ARP might confuse some Layer 3 switches, as they update
their ARP tables by the source MAC of the packet, rather than by the MAC in
the information part of the packet.
ARP, Gratuitous
A Gratuitous ARP is an ARP broadcast sent out by a device for the sole purpose
of keeping other devices informed of its presence on the network.
ARP Table
ARP table contains the destination MAC address for each destination IP.
Authority DNS
Server
Authority DNS Server - any DNS server that contains a complete copy of the
domain's zone file is considered to be authoritative for that domain only. A
complete copy of a zone file must have:
A valid Start of Authority (SOA) record
Valid Name Server (NS) records for the domain
The listed NS records should match the servers listed in the SOA record.
Servers listed in the zone file, but not in the SOA record are called lame
servers.
It is considered standard practice to have a primary authoritative DNS server
(the first server on your list) and a secondary authoritative DNS server/s (all
other servers on your list).
The secondary and primary servers should be on different IP subnets and the
hardware should be located in different physical locations, for safety and
redundancy purposes. A secondary server can, and should be, authoritative
for any domain for which it performs secondary authoritative resolution.
Backup in VLAN
In Regular VLAN configuration, the device that is inactive can cause broadcast
storms and lead to loops. Backup in VLAN, when enabled, prevents loop
creation.
BER
Basic Encoding Rules (BER) are a set of ASN.1 encoding rules that define a
specific way in which information may be encoded in a binary form. It is used
as the underlying mechanism for encoding LDAP messages.
523

Term
Definition
BGP
The Border Gateway Protocol (BGP) routing protocol, defined in RFC 1771,
provides loop-free inter-domain routing between Autonomous Systems (AS is
a set of routers that operate under the same administration).
BGP is often the protocol used between gateway hosts on the Internet and is
also often run among the networks of Internet service providers (ISPs).
Hosts using BGP communicate using the Transmission Control Protocol (TCP)
and send updated router table information only when one host has detected a
change. Only the affected part of the routing table is sent.
Binding
Binding is the process by which protocols are associated with one another and
the network adapter to provide a complete set of protocols needed for
handling data from the application layer to the physical layer. For example, the
configuration of a Load Balancer to associate certain servers with certain
applications.
Binding, Delayed
Delayed Binding (TCP splicing), is the delaying of the connection between the
client and the server until sufficient information is acquired to make a routing
decision. Some application switches and routers delay binding the client
session to the server until the proper handshakes are completed.
BOOTP
Bootstrap Protocol (BOOTP), is a UDP network protocol used by a network

client to obtain its IP address automatically. This is usually done in the
bootstrap process of computers or operating systems running on them. BOOTP
servers obtain IP addresses from a pool of addresses and assign them to
clients, enabling 'diskless workstation' computers to obtain an IP address prior
to loading any advanced operating system.
Bridging
Bridging - is a packet-forwarding method, implemented in software, (as

opposed to a VLAN where traffic is switched in hardware).
In a bridged network, no correspondence is required between addresses and
paths. Unlike routing, bridging makes no assumptions about where in a
network a particular address is located. Instead, it depends on broadcasting to
locate unknown devices.
AppDirector learns the MAC addresses of frames arriving from each physical
interface, and maintains a list of MAC addresses per interface, stored in a
Bridge Forwarding table. When a frame arrives from an interface, AppDirector
looks for the frame destination addresses according to the following
conditions:
If the destination address is listed in the same interface as the source
address, AppDirector discards the frame.
If the destination address is listed in another interface, AppDirector
forwards the frame to the relevant interface.
If the address is not listed in any interface, AppDirector broadcasts the
frame to all interfaces participating in the VLAN.
Bridge Forwarding
Table
524
This lists the MAC addresses of frames arriving from each physical interface.

Term
Definition
Broadcast Domain
A Broadcast Domain is a set of all devices that will receive broadcast frames
originating from any device within the set.
Broadcast domains can be bounded by VLANs in a stand-alone environment.
In an internetworking environment, they are bounded by routers because
routers do not forward broadcast frames.
Class
Class, in object-oriented programming, a class is a programming language

construct used to gather related instance variables and methods.
In Radware, a class is defined as a combination of service definitions and
network segment definitions that characterize a certain type of traffic.
Services characterize traffic by Layer 3-7 criteria, while network segments
characterize traffic by Layer 1-3 criteria.
The Classes module allows multiple Networks to have the same configured
name. This allows a Network with the name net1 to encompass multiple
disjointed IP address ranges. This makes the Network Group Name a logical
pointer to all ranges configured with that name.
Client NAT
Address table
Client NAT Address table - defines the addresses that are available for the
AppDirector to choose from to perform NAT.
Client Table
(Radware)
A Radware Client Table is an internal table used by a Web Server Device to

store Client session information, such as Client IP Address, Client IP Port,
Farm IP Address, Server IP Address, Last Activity Time, Attach Time. It keeps
track of clients connected to the servers for each of the Local Farms to
maintain client-server persistency.
The NAT addresses are also configured in ranges. The maximum number of
configurable NAT addresses depends on the value of the NAT Addresses table
parameters.
The Layer 3 Client table contains information about the server selected for
each client (Source IP address) in each farm, defined as a percent of the Client
Table size.
If AppDirector finds that a request exists in the Client Table the request is
directed to the server recorded in the table. If an entry does not exist, a farm
is selected according to the service requested, and a server is selected
according to load balancing considerations or according to the Layer 7
Persistency info, The selected server is recorded in the table.
Once an entry is created in the Client Table, all subsequent packets that arrive
from the client to a farm are forwarded to the server recorded in the entry.
Client Table,
Mirrored
A Mirrored Client Table is the internal table used by a Backup device to store
the Client session information mirrored by the Active device.
Cluster
A Cluster is a group of multiple servers that appear to be a single unit.

A Cluster is two or more Radware devices (AD, LP, and CID) configured in
active/active or active/backup redundancy.
525

Term
Definition
Cookies, HTTP
HTTP cookies are parcels of text sent by a server to a user via a web browser
to allow the server to store its own information about a user and then sent
back unchanged by the browser each time its client accesses that server.
HTTP cookies are used for authenticating, tracking, and maintaining specific
information about users, such as site preferences and the contents of their
electronic shopping carts.
When a user initiates a connection to the server, a new TCP connection is
established with the server and an HTTP request is sent. A cookie-enabled
server processes the HTTP request and sends the user an HTTP response
containing a Set-Cookie HTTP Header with the relevant cookie. Once the client
receives the cookie in the HTTP response, it stores it locally (unless configured
to ignore cookies), usually in a form of a text file. Multiple Set-Cookie Headers
may be used in an HTTP reply.
A Set-Cookie header contains the following information:
Cookie name and value, in the format of key=value, (minimum character
length is 1).
A comment (optional).
A domain name, which always starts with a leading dot (optional).
The expires parameter, which indicates the maximum age of the cookie
(optional). When not specified in the Set-Cookie Header, the browser
deletes the cookie as soon as the browser is closed.
Cookie, Session
A Session Cookie (aka transient cookie) is stored in temporary memory and

erased when the user closes the Web browser. Session cookies do not collect
information from the users computer. They store information in the form of a
session identification that does not personally identify the user
Cookie, Persistent
A Persistent Cookie (aka permanent cookie) is stored on a users hard drive

until it expires (persistent cookies are set with expiration dates) or until the
user deletes the cookie. Persistent cookies are used to collect identifying
information about the user, such as Web surfing behavior or other user
preferences.
DHCP
Dynamic Host Configuration Protocol (DHCP) is a protocol used by networked

computers (clients) to obtain IP addresses and other parameters such as the
default gateway, subnet mask, and IP addresses of DNS servers from a DHCP
server. The DHCP server ensures that all IP addresses are unique, e.g., no IP
address is assigned to a second client while the first client's assignment is
valid (its lease has not expired). Thus IP address pool management is done by
the server and not by a human network administrator.
526

Term
Definition
DNS Resolution
A Domain Name Server (DNS) translates hostnames to IP addresses. At the

stage when the domain points to name servers across all (or most) servers on
the net, the domain is said to have been resolved (or propagated), that is,
has arrived at DNS Resolution.
For example, when you want to know the internet address of en.wikipedia.org,
DNS can tell you it's 66.230.200.100.
In addition, the DNS makes it possible to assign Internet destinations to the
human organization or concern they represent, independently of the physical
routing hierarchy represented by the numerical IP address. Because of this,
hyperlinks and Internet contact information can remain the same, whatever
the current IP routing arrangements may be, and can take a human-readable
form (such as "wikipedia.org").
Dynamic Cookies
Dynamic Cookies are supported by AppDirector, as set by the servers. The

user defines a fixed key for the farm, then AppDirector tracks the use of
different cookie values, or session IDs, by different servers. When a client
request arrives at the AppDirector without a cookie, AppDirector selects a
server according to the regular algorithms. The server will generate a dynamic
cookie and send it to this client. AppDirector detects the dynamic cookie and
remembers that the specific session ID is a cookie that was sent from that
specific server. This information is kept in AppDirector's memory for a
configurable period of time (Inactivity Timeout). During this period, whenever
a client connects with the same cookie (the client's IP address may change),
AppDirector will send that client to the same server that generated the cookie.
Dynamic Routing
Dynamic Routing constructs routing tables automatically, based on information

carried by dynamic routing protocols.
Dynamic routing protocols perform path determination and route table update
functions. They also determine the next-best path if the best path to a
destination becomes unusable. The capability to compensate for topology
changes is the most important advantage dynamic routing offers over static
routing.
Dynamic Routing Protocols are, for example, OSPF, RIP, BGP ...
Dynamic IP
Address
Dynamic IP address - is an IP address selected from a table that changes

every time a user logs on to the network (Internet).
Dynamic
Proximity Table
Dynamic Proximity Table is the internal table used by an AppDirector device to

store Dynamic Network Proximity information, such as Farm Address, 24-bit IP
Subnet, Server IP Addresses, Latency per Server, and Hops per Server.
The information can either be calculated by the AppDirector device itself or
reported by other AppDirector devices comprising a multi-site, global solution.
Dynamic Proximity features are only available on the WSD-NP.
527

Term
Definition
Element, Checked
A Checked Element is a network element that is managed and load balanced

by the Radware device. For example, AppDirector-checked elements include
the Farm Servers, NHRs, and LRP and PRP reports.
The health of a Checked Element may depend on a network element that the
IAS device does not load balance. For example, the health of a server
managed by AppDirector may depend on the health of a database server, or
other application servers, which are not load balanced by the AppDirector, or
the health of a Next Hop Router managed by LinkProof may depend on the
availability of the service provider.
Failover
A Failover of a machine in a cluster is when a machine takes over packet

filtering in place of another machine in the cluster that failed.
Farm (Server )
An AppDirector Server Farm (aka. Farm) is a collection of one or more

networked and load-balanced servers hosting a common service or application
that is accessible via a common VIP. A server can be a member of more than
one Farm.
Using a load balancer, a server farm streamlines internal processes by
distributing the workload between the individual components of the farm and
expedites computing processes by harnessing the power of multiple servers.
Server farms rely on load-balancing software to satisfy tracking demand for
processing power from different machines, prioritizing the tasks, and
scheduling and rescheduling them depending on user priority and demand.
When one server in a farm fails, another takes up the load.
Servers contained in a server farm can be placed in different physical
locations, belong to different vendors, or have different capacities, all of which
is transparent to the user. A server in a farm can also serve in multiple farms.
Farm Profile
See Profile, Load Balancing.
Filter, Basic
Filter, Basic is a regular filter which defines the criteria for classifying traffic.
A filter can consist of Layer 2 - Layer 7 classifying criteria, part of the classes
database
Force Port Down
Force Port Down enables the temporary forcing down electrically of physical
ports belonging to a VLAN when the VLAN is disabled due to Interface
Grouping activation.
This allows the switches connected to these ports to clear their MAC tables and
prevent them from continuing to send traffic to the wrong AppDirector device;
this problem is relevant mainly for Regular VLANs.
This capability is supported only in VRRP configuration.
528

Term
Definition
FTP
File Transfer Protocol (FTP) is a protocol for exchanging files over the Internet.
FTP works in the same way as HTTP for transferring Web pages from a server
to a user's browser and SMTP for transferring electronic mail across the
Internet in that, like these technologies, FTP uses the Internet's TCP/IP
protocols to enable data transfer. FTP is most commonly used to download a
file from a server using the Internet or to upload a file to a server (e.g.,
uploading a Web page file to a server).
Full Duplex
Full Duplex is the transmission of data in two directions simultaneously.

In full-duplex mode, the data that you transmit does not appear on your
screen until it has been received and sent back by the other party. This
enables you to validate that the data has been accurately transmitted.
Gateway
A Gateway on a network is a device, often a specialized computer, that

enables communication between networks of different architectures and using
different protocols. The gateway converts the information being transmitted to
a form that is understood by the receiving network
Global Solution
Radwares Global Rapid Application Delivery solution enables the deployment

of geographically dispersed sites to facilitate the direction of users to the site
best suited to provide service. If one site becomes unavailable, users are
transparently redirected to an available site.
Radware provides:
Six different redirection methods which can seamlessly redirect sessions
between servers and sites for any IP application to ensure availability,
performance, security and 100% persistency.
Multiple session tracking mechanisms that enable identification of
individual sessions, understand where that session is being served and
share the session information between Radware devices in each of the
sites.
Group Health
Check
Group Health Checks enables the creation of complex health conditions for
Checked Elements.
For instance, consider a Web server that communicates with one of two
database servers and uses one of two routers to provide service. This Web
server is bound using three different binding groups:
One contains Health Checks for the two routers (each check is nonmandatory).
Another contains Health Checks for the database servers (each check is
non-mandatory).
The third contains the Health Checks for the Web server.
As long as one of the database servers and one of the routers are active, and
the Web server Health Check passes, the Web server is considered active.
Otherwise, the Health Monitoring module determines that the Web server is
unable to provide the required service.
529

Term
Definition
Group, Server
A Server Group is subset of configured server hosts used for a particular

service.
A server may belong to several groups and a group may transverse several
farms.
Hardware Load
Balancer
A hardware load-balancing device (HLD), also known as a Layer 4-7 router, is

a physical unit that directs requests to individual servers in a network, based
on factors such as server processor utilization, the number of connections to a
server, or the overall server performance.
The use of an HLD minimizes the probability that any particular server is
overwhelmed and optimizes the bandwidth available to each computer or
terminal. In addition, the use of an HLD can minimize network downtime,
facilitate traffic prioritization, provide end-to-end application monitoring,
provide user authentication, and help protect against malicious activity such
as denial-of-service (DoS) attacks.
Health Check
A Health Check defines how to test the health of any network element (not
necessarily a Checked Element).
A check configuration includes such parameters as the Check Method, the
TCP/UDP port to which the test is sent, the time interval for the test, its
timeout, the number of retries, and more. A network element can be tested
using one or more Health Checks.
Health Checking,
Advanced
Advanced health checking is the ability of an Application Delivery Network

(ADN) to determine not only the state of the server where an application is
hosted, but the status of the application it is delivering.
Advanced health checking techniques allow the Application Delivery Controller
(ADC) to intelligently determine whether or not the content being returned by
the server is correct and should be delivered to the client.
Health Monitoring
Health Monitoring is the mechanism by which a load balancer checks to ensure

that a load balanced server is up and functioning. Health monitoring includes:
ICMP ping
TCP port open
HTTP HEAD or GET command and looking for an HTTP 200 response.
Radwares health monitoring includes an extensive library of pre-defined
health checks to identify any type of failure, whether it is a server hardware
failure, an operating system problem, a specific application failure or a backend database failure.
High Availability
High Availability is the ability of a cluster to maintain a connection after a

failure without loss of connectivity.
In an Active-Backup cluster, only the Active machine filters packets. If a failure
occurs on the Active machine, one of the other machines in the cluster
assumes its responsibilities.
530

Term
Definition
Hop
A hop is the trip that a data packet takes from one router to another as it
traverses a network on the way to its destination.
ICMP
The Internet Control Message Protocol (ICMP) is a a protocol that carries

information about the status of the network, used by networked computers
operating systems to send error messagesindicating, for instance, network
congestion, unavailability of a requested service or that a host or router could
not be reached.
IDN
Internationalized Domain Names (IDN) is a standard for Internet domain

naming that allows characters other than the 37 basic ASCII characters (a-z,
0-9 and -) as laid down in RFC 3490 ("Internationalizing Domain Names in
Applications" (IDNA)).
AppDirector uses host names in the following configurations:
As a DNS server, AppDirector replies with a Layer 4 Virtual IP address or
an external NAT address.
With Layer 7 Polices, farm selection can be based on host names. It is also
possible to redirect HTTP, HTTPS, and SIP traffic.
With HTTP redirection, the server name or server's "Redirect to" attribute
are used for the redirection.
Interface
Grouping
Interface Grouping in a Redundancy cluster ensures that the Backup device

will take over even if only some of the Active device physical ports are down.
When this feature is enabled, a device will intentionally stop responding to
ARPs on all of its ports if any of its physical ports is down, causing the Backup
device to take over.
Selective Interface Grouping - enables the definition of the physical ports
that will trigger interface grouping, and subsequently device failover. When
Interface grouping is triggered, it stops responding to ARP only on the ports
that are included in the Selective Interface Group. The most common example
of a port that should not usually trigger device failover is the Management
Pport.
Interface,
Hardware
(Physical)
A Hardware Interface is an architecture that interconnects two pieces of

hardware. It includes the design of the plug and socket, the type, number and
purpose of the wires and the electrical signals that are passed across them.
USB, FireWire, Ethernet, parallel and serial ports and CompactFlash cards, PCI
cards and PC cards are all examples of hardware interfaces (devices
connecting to other devices).
Interface, Physical
(Radware)
A Physical Interface, as defined in Radware terminology, is one of the Fast

Ethernet or Application Switch ports of the AppDirector / DefensePro.
In the Fast Ethernet platform, AppDirector can have either 2 or 4 physical
interfaces, depending on the hardware configuration. In the Application Switch
platform, AppDirector can have up to 10 physical interfaces.
531

Term
Definition
Interface, IP
Physical
A Physical IP Address is an IP address assigned to an AppDirector interface.
IP Interface
(Radware)
An IP Interface is an interface that allows interoperable connection of virtual

components to devices to ensure rapid creation and integration of
interoperable virtual components.
This address belongs to AppDirector and is used for SNMP management and/
or routing purposes.
An IP Interface has a format and language (description of signals and

protocol) that defines the services one system is capable of delivering to
another.
The standards define a protocol for the transfer of requests and responses and
the contents and coding of these requests and responses.
An IP interface on AppDirector is comprised of two components:
An IP address
An associated interface.
The associated interface can be a physical interface or a virtual interface
(VLAN). IP routing is performed between AppDirector IP interfaces, while
bridging is performed within an IP interface that contains an IP address
associated with a VLAN.
IP Address,
Physical
A Physical IP Address is assigned to an AppDirector interface. This address

belongs to AppDirector and is used for SNMP management and/or routing
purposes.
IP Forwarding
Table
The IP Forwarding Table contains the destination MAC address and port for
each destination IP address.
IP Routing
The forwarding of IP packets to their destination using a Routing Table.
IPCS
Internet Protocol Communication Server (IPCS)
IPCM
Internet Protocol Call Manager (IPCM)
LAN
A Local Area Network (LAN) can be defined as a broadcast domain.
A MAC address is searched in this table before it is searched in the ARP table.
Hubs, bridges or switches in the same physical segment or segments connect

all end node devices. End nodes can communicate with each other without the
need for a router. Communications with devices on other LAN segments
requires the use of a router.
532

Term
Definition
Layer 4
Classification
A Layer 4 Classification allows you to set a single Virtual IP address for

multiple application services for different groups of users.
You can define traffic segregation for a Layer 4 Classification on the basis of
the Destination port and Layer 4 protocol. All the VIPs managed by
AppDirector are defined under Layer 4 Classifications.
When AppDirector receives the first packet of a session destined to a Virtual IP
address, it searches for a Layer 4 Classification that matches the Layer 4
Protocol, Destination port, Source IP. Then, based on this information, Traffic
Redirection selects the farm allocated to this service, while the Load Balancer
finds the best server for the task from that farm, and forwards the packet to
that server.
Layer-4-7
Switching
Layer 4 through 7 switching means switching packets based on Layer 4-7

protocol header information in the packets.
Layer-7 Switching
Layer-7 Switching (aka Layer-7 load balancing or application-level load

balancing) parses requests in the application layer and distributes requests to
servers to destination farms in Layer-4 Policies that match the request (Traffic
Redirection). The Load Balancing function then allocates the request to the
best server in the farm.
Layer 7
Classification
Rule
A Layer 7 Classification Rule consists of one or two Layer 7 Methods.The rule

can be bound to multiple Traffic Redirection rules on the same device, and the
same Layer 7 Classification Rule can be reused on multiple devices.
Layer 7 Data
Modification
Layer 7 Data Modfication is often required when changing the headers of an

HTTP session. Some examples are:
TCP and UDP are the most used Layer 4 protocols and their headers contain
the information required to make an intelligent switching decision. For
example, the HTTP protocol normally runs on TCP Port 80. Radwares Traffic
Redirection can make the decision to prioritize, block or redirect traffic based
on, for example, TCP or UDP port numbers.
Insert HTTP Header X-Forwarded-For to convey to destination the

originator of the communication.
Remove HTTP Header from server replies to clients to hide server identity.
Insert cookie for persistency purposes.
AppDirector modifies Layer 7 fields such as URL, cookie, header fields and
status lines and any Layer 7 data that can be identified by a certain string or
regular expression.
533

Term
Definition
LDAP
The Lightweight Directory Access Protocol (LDAP) is an application protocol for

querying and modifying directory services running over TCP/IP.
The most common example is the telephone directory, which consists of a
series of names (either of a person or organization) organized alphabetically,
with an address and phone number attached.
LDAP deployments use Domain Name System (DNS) names for structuring the
topmost levels of the hierarchy. Deeper inside the directory might appear
entries representing people, organizational units, printers, documents, groups
of people or anything else which represents a given tree entry (or multiple
entries).
Layer 7 Methods
Layer 7 Methods are used to classify Layer 7 traffic, such as URLs, cookies,
etc. A Layer 7 Method must be bound to a Layer 7 Classification rule in order
for it to be used in a Traffic Redirection rule and the same Layer 7 Method can
be reused on multiple devices.
License, Cookie
Persistency
The Cookie Persistency License permits the AppDirector to check HTTP

headers for Session ID Persistency. Without the Cookie Persistency license,
AppDirector only inspects the URI and does not check further into the HTTP
header.
Link Aggregation
Link Aggregation allows one or more links to be aggregated together (using

multiple Ethernet network cables/ports in parallel) to form a logical Link
Aggregation Group, such that a MAC client can treat the Link Aggregation
Group as if it were a single link (from IEEE Standard 802.3, 2000 Edition, page
1215).
Link Aggregation increases bandwidth beyond the limits of any one single
cable or port. The failure or replacement of a single link within a Link
Aggregation Group need not cause failure of a MAC Client. LA is available
through Physical Layer technology options (10 Mb/s, 100 Mb/s, 1000 Mb/s,
etc.).
Load sharing can distribute MAC Client traffic across multiple links.
534

Term
Definition
Load Balancing
Load Balancing can be software, hardware or both. Radware Load Balancing

software runs on servers, or appliances that contain the appropriate hardware
and software, or Layer 2/3 switches with extended functionality.
Load balancing software uses an algorithm or formula to distribute incoming
HTTP requests across Web servers in a server farm to optimize traffic load.
Dynamic load balancing uses current performance information from each node
to determine the device that should receive each new packet, so that no single
device is overwhelmed with traffic. The load balancer takes into consideration
performance factors, such as current server performance and current
connection load.
Load Balancers have the following benefits:
Scalability is the ability to continue functioning well even when
distributing load across an increased number of real servers.
Availability is the ability to divert requests (transparently and on the fly)
to healthy servers when real servers or applications fail the health
check.
Manageability is the ability to continue serving requests, distributing the
load to other servers, while a server is being upgraded.
Security - by being a front end to servers, a Load Balancer can hide
(NAT) the private IP addresses of the servers and show only its own public
VIP to the world.
Quality of Service can be defined differently for each application.
Load Balancers have at least four applications:
Server load balancing distributes load across multiple servers in a farm
Global server load balancing directs requests to different data centers
with server farms
Firewall load balancing directs load across multiple firewalls
Transparent cache switching offloads static content to caches to improve
performance
See also Stateless Load Balancing and Stateful Load Balancing.
Load Balancing,
Software
A software load balancing solution can be loaded on the clients hardware of

the users choice, such as DNS Round Robin. Software solutions work best
for smaller, less complex applications with a lower network complexity.
Load Balancing,
Hardware
Hardware load balancers use virtual IP addresses to represent a group of

servers and rewrite source and destination IPs as they route traffic. There are
two types of load balancing solutions that could be classified as hardware load
balancers.
Switch or router based which balances at the network level using layer 2 and 3
functionality. It is the most robust; however, it does not provide the ability to
direct traffic based on cookies or URLs.
A software/hardware solution that provides more functionality and flexibility
with switching based on layers 4 through 7, but is more complicated to
configure.
535

Term
Definition
Load Balancing,
Clustering
Clustering or Session Replication Load Balancing can be used as an alternative

to hardware load balancing when sticky sessions or persistence is required.
It consists of a farm or cluster of web application servers which have the
ability to replicate and maintain session state in memory on all servers or
using a common database. Traffic can then be directed to any server in the
cluster even if persistence is required since all servers have current session
state for all sessions.
Clustering offers the advantage of high availability and failover support. When
one server fails or is taken out of service, the other servers are still aware of
session states for sessions on the failed server and are therefore able to
seamlessly take over. Clustering does not in actuality replace load balancing.
The traffic still has to be directed to the servers in an ordered manner by some
process. However it does solve the problem of maintaining session stickiness.
Load Distribution
Load distribution is helps to improve performance of Web Servers (response

to user requests) on a computer network by evenly dispersing jobs to different
nodes or routes in a manner that no one route or node is overused.
There are three well-known Load Distribution strategies:
DNS-based implements a round-robin assignment of requests to redundant
WSs that maintains an optimum balance among those WSs.
Mirror-based provides access to the Web Server that is geographically closer.
QoS-based in this strategy, it is assumed that the DNS maintains the
addresses of all the WSs that implement the required services, and makes the
source browser responsible for implementing its own load distribution. The
source browser interrogates the DNS to obtain the addresses of all the WSs
that implement the required service. Before sending a request, the browser
probes the WSs by sending a dummy request (broadcasting UDP messages)
and determines the best URT (User Response Time).
Load Distribution can be stateful (persistent) or stateless (single session).
Load Balancer
Capacity
Load Balancer Capacity - Load Balancers are network devices, but they have
more in common with Web servers when it comes to performance
characteristics. Web servers are measured in connections per second, while
routers and switches are measured in pure throughput (bits per second).
The most important performance metric for load balancers is connections per
second. The work involved in accepting and establishing a TCP session,
potentially parsing the HTTP header, and forwarding the traffic to another Web
server, is substantial when compared with the relatively easy task of
throughput. Throughput is dependent on the speed of the network interface
(Fast Ethernet: 100Mbps or Gigabit Ethernet: 1,000Mbps).
536

Term
Definition
Load Sharing
Load Sharing utilizes multi-path routing to allow a source to use any of several
paths to a particular destination at any given time.
Multi-path routing has several advantages as compared to single-path routing,
including smoothing out the traffic, load balancing, supporting QoS, improving
reliability, and enhancing the privacy of the information being sent.
In a Load Sharing Gateway Cluster, all machines in the cluster filter packets,
providing transparent failover to any of the other machines in the cluster and
enhanced reliability and performance.
Load Sharing is also known as Active/Active.
Logical Server
Software that runs on physical servers, to process requests, such as web,

mail, DNS, MYSQL and other servers.
LRP
Load Report Protocol (LRP) is used by AppDirectors to report their status and
load to other AppDirectors and to the Global AppDirector. The redirection
decisions which each global AppDirector makes are based on load, availability
and proximity.
MAC
The Media Access Control (MAC) address is your computer's unique hardware
number. On an Ethernet LAN, it is the same as your Ethernet address.
When connected to the Internet, a correspondence table relates your IP
address to your computer's physical (MAC) address on the LAN.
The MAC address is used by the Media Access Control sublayer of the DataLink Layer (DLC) of telecommunication protocols. There is a different MAC
sublayer for each physical device type. The other sublayer level in the DLC
layer is the Logical Link Control sublayer.
MIB
A Management Information Base (MIB) is a formal description of a set of

network objects that can be managed using the Simple Network Management
Protocol (SNMP).
The format of the MIB is defined as part of the SNMP. (All other MIBs are
extensions of this basic management information base.) MIB-I refers to the
initial MIB definition; MIB-II refers to the current definition. SNMPv2 includes
MIB-II and adds some new objects.
MIME
Multipurpose Internet Mail Extensions (MIME) is a protocol widely used on the

Internet to enable e-mail to include multiple types of information, such as
text, graphics, sound, and video.
MIME uses the message header for describing media types included in the
document. This information is then used by software on the destination
machine to determine whether the particular data types can be "replayed,"
and if so, by what programs.
Mirroring
Mirroring is a means of backing up data on a network by duplicating it, in its

entirety, on a separate physical device.
537

Term
Definition
Mirroring
(dynamic client
tables)
Mirroring (dynamic client tables) - in redundant clusters, mirroring maintains a

copy of the dynamic client tables of the active device to the backup device. If
the active device fails, the backup device takes up the sessions, and continues
forwarding requests to the same server in the farm.
Mirroring is recommended for use with state-sensitive and long-term sessions,
such as Telnet or FTP, but should not be activated with HTTP applications
where sessions are short and a reload mechanism is built-in or transparent.
Mirroring should also not be used with Dynamic Session ID Tracking.
Monitor
A Monitor verifies connections and services on nodes that are members of load
balancing pools. A monitor can be either a health monitor or a performance
monitor, to check the status of a node or service on an ongoing basis, at a set
interval.
Multi-homing
Multi-homing (aka. Multi-WAN Switching) is where a corporate network uses

more than one link and/or Internet Service Provider in parallel to connect to
the outside world.
Multiplexing
Multiplexing is the process of weaving multiple signals onto a single channel or

communications line. In multiplexing, segments of information from each
signal are interleaved and separated by time, frequency, or space.
NAT
Network Address Translation (NAT) is the translation of an IP address used

within one network (a LAN or internal network) to a different IP address
known within another network (a public, external network).
The purpose of NAT is to hide the Source IP address. The following NAT
options are used in Radware:
NAT, Client - hides IP addresses of users sending requests to the
Internet via the AppDirector
NAT, Server - translates the servers IP address in outbound serverinitiated sessions, to a corresponding public address, using Static NAT
(only the IP address is changed, no port NAT is done)
NAT, Outbound - allows only connections that originate from servers on
the internal network to initiate sessions both with the internal network
and with the public Internet.
NAT, Client
Client NAT - AppDirector uses this parameter to hide the IP addresses of the
clients from the servers.
The original Source IP of a request is replaced by the configured NAT IP and
port before forwarding the request to the server.
The Client NAT feature is used when, for example, the client and the server
are on the same subnet, so that the IP address of the client must be hidden. If
it is not, servers may send replies directly to clients, rather than sending them
through AppDirector.
NAT, Dynamic
538
Dynamic NAT - maps an unregistered IP address to a registered IP address

from a group of registered IP addresses.

Term
Definition
NAT, Outbound
Outbound NAT is used to perform IP address translation on traffic originating

from behind an AppDirector or Web Server Director (WSD).
The Outbound NAT parameter instructs AppDirector to replace the original
source IP and source port of a packet with a Dynamic NAT IP from a registered
IP list, and a NAT port.
Outbound NAT is supported for TCP/UDP/ICMP traffic and applied only to traffic
that is routed or bridged by AppDirector.
The difference between Outbound NAT and Server NAT is that Outbound NAT
generates an outbound NAT port (TCP/UDP).
NAT, Overlapping
Overlapping NAT is when IP addresses used on an internal network are

registered IP addresses in use on another network.
The router must maintain a lookup table of these addresses so that it can
intercept them and replace them with registered unique IP addresses. The NAT
router must translate the internal addresses to registered unique addresses
and translate the external registered addresses to unique addresses in the
private network. This can be done either through static NAT or by using DNS
and implementing Dynamic NAT.
NAT, Pooled
Pooled NAT is similar to Port Address Translation (PAT) except there is a oneto-one mapping of addresses; the number of inside network clients is the
same as the number of outside network IP addresses.
The NAT router has a pool of available IP addresses, and each client receives
its own IP address when it requests a NAT translation. The next available IP
address is selected each time that the client requests a translation.
NAT, Server
Server NAT is a parameter in the AppDirector configuration that, when

enabled, hides a servers IP address for outbound traffic in sessions initiated
by the server, using static NAT (only the IP address is changed, no port
translation is done). Server NAT is applied to servers positioned behind
AppDirector.
When a session is initiated by a server, the servers request for service is sent
using its IP address as the source address. If the servers IP address is a
private IP address, the servers address must be translated to a public IP
address. The servers IP is translated to the Layer 4 Classifications VIP and a
new entry is added to the Client Table. Sessions originating from servers are
tracked in the Client Table and tagged with a NAT tag to differentiate this
traffic from other inbound client traffic.
NAT, Static
Static NAT is a type of NAT in which client requests with private IP addresses
are mapped to a fixed public IP address (for example, the case of an email
server).
This allows an internal host, such as a Web server, to have an unregistered
(private) IP address and still be reachable over the Internet.
Networks
A Network is a generic term and is not described in this glossary.
539

Term
Definition
Network (Scalefree)
In Scale-free Networks, structure and dynamics are independent of the

systems size (the number of nodes) It has the same properties irrelevant of
the number of nodes.
Network Layers
(OSI Model)
Layer 7: Application layer interfaces directly to, and performs common

application services for, the application processes; also issues requests to the
presentation layer.
Layer 6: Presentation layer transforms data to provide a standard
interface for the Application layer. MIME encoding, data encryption and similar
manipulation of the presentation are done at this layer to present the data as
a service or protocol developer sees fit.
Layer 5: Session layer controls the dialogues/connections (sessions)
between computers. It establishes, manages and terminates the connections
between the local and remote application. It provides for either full-duplex or
half-duplex operation, and establishes checkpointing, adjournment,
termination, and restart procedures.
Layer 4: Transport layer provides transparent transfer of data between
end users, relieving the upper layers while providing reliable data transfer.
Layer 3: Network layer provides the functional and procedural means of
transferring variable length data sequences from a source to a destination via
one or more networks while maintaining the quality of service requested by
the Transport layer.
Layer 2: Data Link layer provides the functional and procedural means to
transfer data between network entities and to detect and possibly correct
errors that may occur in the Physical layer.
Layer 1: Physical layer defines all the electrical and physical
specifications for devices.
NHR
A Next-Hop Router (NHR) is a network element with an IP address through

which traffic is routed.
NHRP
Next Hop Resolution Protocol (NHRP) is a protocol or method to find the most
direct route (the fewest number of hops) to the receiving computer. NHRP
informs the source of the most direct path to the closest router to the
destination.
NHRP is a query-and-reply protocol that builds a network knowledge table
that can be used for all subsequent traffic, and send packets directly to the
destination computer.
NMS
Network Management System (NMS) is a comprehensive system of equipment

used in centrally monitoring, controlling, and managing a data
communications network. An NMS has the ability to exchange information with
other NMSs and EMSs via northbound interfaces.
NTP
The Network Time Protocol (NTP) is a protocol for synchronizing the clocks of
computer systems over packet-switched, variable-latency data networks.
NTP uses UDP port 123 as its transport layer. It is designed particularly to
resist the effects of variable latency (jitter buffer).
540

Term
Definition
On Demand
Switch
Radware's OnDemand Switch is a data center switch that scales up as a

customer's business expands and demands increased application
performance, increased throughput of data traffic and data availability.
OR Group
An OR Group is a logical OR between two Basic Filters, part of the classes

database.
OSPF
Open Shortest Path First (OSPF) is a dynamic routing protocol used within
large IP networks.
Using OSPF, a host that obtains a change to a routing table or detects a
change in the network, immediately multicasts the information to all other
hosts in the network so that all will have the same routing table information.
Unlike the RIP in which the entire routing table is sent, the host using OSPF
sends only the part that has changed. With RIP, the routing table is sent to a
neighbor host every 30 seconds. OSPF multicasts the updated information
only when a change has taken place.
Out-of-band
Monitoring
Out-of-band Monitoring is a health check by the Load Balancer for TCP

response time generated specifically by the Load Balancer to the server.
Using out-of-band monitoring, it is easier to check the validity of the request
content.
In contrast, in-band monitoring refers to a TCP health check using the natural
traffic flow between the client and the server.
Outbound NAT
Intercept
Addresses Table
The Outbound NAT Intercept Addresses table lists networking elements with
source addresses that have been NATed.
Packet, Network
A Network Packet consists of two kinds of data: protocol control information

(PCI) and user data (also known as payload).
PCI carries information about the user data, such as source and destination
addresses, error detection codes like checksums, and sequencing information.
PCI is found in packet headers and trailers, with user data in between.
PAP
Password Authentication Protocol (PAP) is an access control protocol for dialing

into a network that provides only basic functionality. When the client logs onto
the network, the network access server (NAS) requests the username and
password from the client and sends it to the authentication server for
verification. Since the password is sent over the line unencrypted from the
client, it provides password checking, but is not secure from eavesdropping.
PAT
Port Address Translation (PAT) translates TCP or UDP communications

between hosts on a private network and hosts on a public network. It allows a
single public IP address to be used by many hosts on the LAN.
A PAT device transparently modifies IP packets, as they pass from the multiple
hosts on the LAN to the public network, so that all the packets appear to
originate from a single host - the PAT device.
541

Term
Definition
PBNM
Policy Based Network Management (PBNM) technology provides the ability to

define and distribute policies for the management of enterprise and SP
networks. Policies can reside either on the devices themselves or in the
network management system to control essential network resources such as
traffic engineering, bandwidth, and security.
Persistency
For interactive Web sites to successfully complete a single application

transaction with dynamic content across a TCP/IP session, you must start and
end a user session serviced by the same web server (aka sticky session or
Source IP Persistence).
Session persistency is also achieved by forwarding all parts of a session that
are identified by a unique identifier, to the same web server. There are no
persistence requirements for static content.
The two basic types of persistence methods for load balancers are source IP
address and cookies.
With Source IP Address, the load balancer looks at the source address (or
source address and source port) of the incoming request to keep track of a
session.
With Cookie Persistence, the load balancer checks an HTTP cookie to
differentiate users (the best method). The server only stores the information
for a given time, as set by an expiration date in the cookie.
In some cases, AppDirector must identify the session by an application
identifier, rather than by Layer 3 (IP address) and Layer 4 (TCP/UDP ports)
information.
Persistency, HTTP
HTTP persistency can mean either that AppDirector allows multiple HTTP
requests within a single TCP session, or that AppDirector restricts the TCP
session to a single HTTP request.
The latter is required when the customer cannot guarantee that a single server
can serve all requests within a single TCP session, for example, when different
farms serve different file types.
Persistence,
Session
Session Persistence (aka sticky connection, because client must stick to the
same server for all sessions) is when the Load Balancer sends all connections
from a gvien client to the same server.
Ping
PING is a utility to determine whether a specific IP address is accessible.

It works by sending a packet to the specified address and waiting for a reply.
PING is used primarily to troubleshoot Internet connections.
Port Group,
Application
542
An Application Port Group combines Layer 4 ports for UDP and TCP traffic only.
Each group is identified by its unique name. Each group name can be
associated with a number of entries in the Application Port Groups table.

Term
Definition
Port Groups,
Physical
Port Groups is a method of grouping network segments by physical ports.

Only packets that arrive from defined physical ports are classified by security
policies and bandwidth management policies. For example, you can allow only
HTTP traffic to the main server through a certain physical interface #3.
On a Load Balancer, if a running application on any one group fails, the Load
Balancer will mark the entire group of applications down on a given real
server. It will direct requests only to those servers that have all the necessary
applications running to complete a transaction.
Port Group,
Physical Inbound /
Outbound
Inbound Physical Port Groups classify only traffic received/sent on certain

interfaces of the device, thus enabling you to set different rules for identical
traffic classes that are received on different device interfaces.
Port Group,
Source /
Destination
Source / Destination Port Groups are intended for UDP and TCP traffic only.
Port Mirroring
Port Mirroring enables the AppDirector device to duplicate traffic from one
physical port to another physical port on the same device.
For example, when an Intrusion Detection System (IDS) device is connected
to one of the ports on the AppDirector device, you can configure port mirroring
for received traffic only, for transmitted traffic only, or for both. You can also
decide whether to mirror the received broadcast packets.
Port Trunking
Port Trunking (aka Link Aggregration) is a method of increasing bandwidth by

combining physical network links into a single logical link. Link aggregation
increases the capacity and availability of the communications channel between
devices - both switches and end stations - by using the Fast Ethernet and
Gigabit Ethernet technology.
Profile, Load
Balancing
A Load Balancing Profile configures load-balancing parameters for a server

farm.
Protocol
Discovery
Protocol Discovery provides a view of the protocols running on the network.
Each server farm can have only one profile, although a Load Balancing profile
can be applied to other farms.
Network administrators must be aware of the different applications running on

their network and the amount of bandwidth they consume. The Protocol
Discovery feature can be activated on the entire network or on separate subnetworks by defining Protocol Discovery rules.
See Radwares Content Inspection Director manual.
Protocol Port
A Protocol Port is an abstraction that TCP/IP transport protocols use to

distinguish between multiple destinations within a given host computer.
TCP/IP protocols identify ports using small positive integers. Usually, the
operating system allows an application program to specify which port it wants
to use. Some ports are reserved for standard services, such as e-mail.
543

Term
Definition
Proximity
Global AppDirectors calculate round-trip latency and router hop-count from

each remote site to incoming request to determine the fastest site. Requests
are then dynamically redirected to a site where User Response Time (URT),
the time it takes from initiating a request until the user gets a response, is the
smallest.
Technically, only Global AppDirectors can trigger proximity calculations and
store the results, but even local AppDirectors can participate in the process.
There are three consideration that determine the proximity of the server:
Traffic load on the available servers
Number of hops required to reach the server
Latency, the User Response Time (URT)
AppDirector-Global maintains two proximity databases that hold information
about a specific subnet of IP addresses and list the best three servers
according to proximity; the closest server is displayed first. The server is
either a Virtual IP address on a Distributed AppDirector device (bound to a
cluster of physical servers) or a standalone remote server. AppDirector-Global
uses the weighted round-robin algorithm to determine the destination.
Proxy Redirection
Proxy Redirection uses the Client NAT mechanism to redirect traffic to another
server or site, while ensuring that the return traffic flows through the
AppDirector that received the original request.
PRP
Proximity Report Protocol (PRP) is a protocol running on UDP port 2091. It is

used by Global AppDirectors to exchange information about the network
proximity of clients with other Global AppDirectors, such as calculations of
store results of proximity and distributed AppDirector partners in a Proximity
Table.
Physical Servers
Actually or virtually self-contained computers with their own operating

systems (Linux, FreeBSD Unix, or Windows).
RADIUS
Remote Authentication Dial In User Service (RADIUS) is a client/server

protocol and application to enable remote access servers to communicate with
a central server to authenticate dial-in users and authorize their access to the
requested system or service.
RADIUS allows a company to maintain user profiles in a central database that
all remote servers can share. Centralization allows the definition of a rule that
can be applied at a single administered network point, and makes it easier to
track usage for billing and for logging network statistics.
Created by Livingston (now owned by Lucent), RADIUS is a de facto industry
standard used by a number of network product companies and is a proposed
IETF standard.
544

Term
Definition
RED
Random Early Detection (RED) an algorithm that uses the inherent

retransmission and flow control characteristics of TCP to protect queues from
overflowing. Radwares bandwidth management mechanism (BWM) deploys
RED in two forms: Global RED and Weighted RED (WRED).
The statuses of queues are monitored, and when queues approach full
capacity, random TCP packets are intercepted and dropped. When all queues
are full, packets are dropped from all sessions. All TCP session endpoints are
forced to use flow control to slow down each session, causing all sessions to be
throttled down making retransmission necessary. Furthermore, UDP packets
are dropped and lost (UDP does not have any inherent packet recovery
mechanism).
Redirection,
Global
(Radware)
Global Redirection directs requests for original content to specific caches

based on content, service location and resource availability on a central server
or global redirector.
Radware Global Redirection is 3-tiered:
Tier-1 DNS Resolution Redirection uses DNS resolution for site selection.
Based on site availability, load and proximity, AppDirector responds with
the VIP address of the best site. Implementing DNS resolution service on
globally dispersed AppDirectors provides DNS redundancy. In addition the
VIP address used for DNS resolution is announced to the routing domain
by Anycast.
Tier 2 Global Application Redirection uses HTTP redirection, Global
Triangulation, redirection and Client NAT. Application persistency uses
application server identifiers stored in the URL, HTTP cookie or SIP Call-ID
to prevent session disconnect.
Tier 3 Local Server Selection after the site is determined, the local
AppDirector selects a local server using the Load Balancer, maintaining
application persistency throughout the process.
545

Term
Definition
Redirection
Methods, Global
The following redirection methods are used:

DNS Redirection responds to DNS queries for the IP address of a specific
host name representing the service, with an IP address that provides the
best service. The IP address can belong to a Local Farm or to a remote
farm/server.
HTTP Redirection redirects the request to an alternate site, either a
standalone server or another AppDirector with its own VIP.
Redirection is to an alternate site, either to a standalone server or another
AppDirector with its own VIP.
Triangulation mainly intended for non-HTTP traffic, where traffic is sent
to remote AppDirectors using reserved addresses. A data triangle is
formed in which the request is the first point, the redirecting AppDirector
the second point, and the AppDirector that responds to the request locally
is the third point. This method is not applicable to a global configuration
using remote servers.
HTTP & Triangulation where HTTP traffic is redirected using the HTTP
redirection method, traffic is redirected using the method, and non-HTTP
traffic is redirected using the Triangulation method.
DNS & HTTP & Triangulation provides the redirection suitable for the
type of incoming traffic. The DNS method is used for DNS requests, HTTP
redirection is used for HTTP requests, redirection is used for requests, and
Global Triangulation method is used for other types of requests.
Redundancy (in
Load Balancing)
Redundancy in load balancing can be set up as:

Active-Standby (one unit is Active and taking up all the load, while the
Standby kicks in when the Active fails)
Active-Active (both units are Active concurrently)
Active-Active is more complicated to setup and troubleshoot. However,
when you have two units of equal power, Active-Active can provide twice
the capacity over Active-Standby, because both units are in use. But,
when running close to 100% on both units, if you do have a failure youre
oversubscribed by 100% on the remaining unit, which degrades your
expected performance.
Redundancy,
Physical & Virtual
IP addresses
When used in Redundancy cluster configurations, the Primary and Secondary

AppDirector devices utilize both physical and virtual IP Addresses.
While the same virtual IP address is defined on both the Primary and
Secondary, different physical IP addresses are used. If a physical interface of
the Primary is set as the default gateway of a server, then when the Secondary
takes over, it also takes over the physical IP address. However, the Secondary
cannot ping its default gateway IP address, as the Primary is down.
Using Virtual IP Interface addresses as default gateway of AppDirector servers
and other devices enables pinging. To do this, create a Virtual IP Interface
address for each local subnet of AppDirector, and use this address in the
relevant routing tables for hosts on that subnet. Make sure to set the same
virtual IP Interface addresses as backup on the Secondary device.
546

Term
Definition
Redundancy,
(Radware)
Redundancy is supported in the AppDirector and AppDirector devices in two

modes:
Active-Backup - with up to three devices, where one of the devices is the
designated Active (with the highest priority on Virtual Router) device for
all services (VIPs). In the event of a failure of the Active device, the
Backup device takes over and temporarily assumes ownership of the VIPs.
Active-Active - with up to three devices, where each device is both the
Active device for some VIPs and the Backup device for other VIPs. In the
event of a failure of one device, the other device temporarily assumes
ownership of all VIPs.
Radware also provides a proprietary redundancy method that uses the
Address Resolution Protocol (ARP) to monitor the other devices and to check
their availability. The recommended redundancy mechanism for AppDirector is
Virtual Router Redundancy Protocol (VRRP).
Regular
Expression
A regular expression (can be abbreviated to regex) is a method of searching

for a specified pattern in text. For example, a regular expression could tell a
program to search for all text lines that contain the word header and then to
print out each line in which a match is found or substitute another text
sequence (for example, just H) where any match occurs.
As an example of the syntax, the regular expression \bex can be used to
describe (and search for) all of the instances of the string ex that occur at
word breaks (signified by the \b). Thus in the phrase, Texts for expert
experimenters, the regular expression \bex returns the ex in expert and
experimenters, but not in Texts (because the ex occurs inside the word
there and not at the word break).
Requests Table
Contains Layer 7 information saved during Delayed Binding.
REXEC
Remote Exec (rexec), like rsh allows you to execute non-interactive programs
on another system.
The difference between rsh and rexec is that rexec requires you to specify a
valid password for the other system and rsh does not.
The other system must be running a remote exec daemon (rexecd) to handle
the incoming rexec command. Most Unix and Linux systems include a remote
exec daemon, but Windows does not.
547

Term
Definition
RIP
Routing Information Protocol (RIP) is a widely-used Interior Gateway Protocol

(IGP) routing protocols for managing router information within a selfcontained network such as a corporate LAN or an interconnected group of such
LANs. Using RIP, a gateway host (with a router) sends its entire routing table
(which lists all the other hosts it knows about) to its closest neighbor host
every 30 seconds. The neighbor host in turn will pass the information on to its
next neighbor until all hosts within the network have the same knowledge of
routing paths, a state known as network convergence. RIP uses a hop count as
a way to determine network distance. Each host with a router in the network
uses the routing table information to determine the next host to route a
packet to for a specified destination.
RIP is considered an effective solution for small homogeneous networks. For
larger, more complicated networks, RIPs transmission of the entire routing
table every 30 seconds may put a heavy load of extra traffic on the network.
The major alternative to RIP is the Open Shortest Path First Protocol (OSPF).
AppDirector supports RIP version 1 and RIP version 2.
Router
A Router is a network device, operating on Layer 3, that transmits message

packets, routing them over the best route available at the time. Routers are
used to connect multiple network segments, including those based on differing
architectures and protocols.
Router, Neighbor
A router sharing a common data link.

A distance vector routing protocol sends its updates to neighboring routers
and depends on them to pass the update information along to their neighbors.
For this reason, distance vector routing is said to use hop-by-hop updates.
Routing Engine
(RE)
The Radware Routing Engine (RE) deals with:

Real time traffic: forward, update tables, move to RS or discard
LB -> Layer 4 Classification, farm and server selection, Layer 3 & Layer 7
persistency
In-depth packet inspection -> Layer 7 persistency
Routing, bridging
IPFTT (ARP and Routing cache), Bridge FFT (Bridge cache)
Routing Services
(RS)
Radware Routing Services (RS) deals with Client Table Aging, HM, Statistics,
SNMP (management), Dynamic routing, ARP, ICMP, Proximity.
Routing Table
A Routing Table is a table of routing rules used by routers to determine the

path of a packet, either to the local network or via a next-hop router.
By default, all networks directly attached to AppDirector are recorded in the
routing table, information about destinations and the best available route.
Additional entries to the table can either be statically configured or
dynamically created through a Dynamic Routing Protocol, such as OSPF, RIP,
BGP.
548

Term
Definition
RSH
Remote Shell (rsh) [aka remsh or rcmd] allows you to execute non-interactive
programs on another system.
RSH executes the command on the other system and returns the program's
standard output and standard error output. The other system must be running
a remote shell daemon (rshd) to handle the incoming rsh command.
Unix and Linux systems include a remote shell daemon, but Windows does
not.
RTP
Real-Time Transport Protocol (RTP) defines a standardized packet format for

delivering multimedia over the Internet. RTP does not have a standard TCP or
UDP port where it communicates.
RTSP
RealTime Streaming Protocol () is an application layer protocol used to

transmit streaming audio, video and 3D animation over the Internet.
It enables the client software to provide remote control of the server with
functions such as pause, rewind and fast forward. is widely used in conjunction
with the RTP transport protocol.
SCTP
In computer networking, the Stream Control Transmission Protocol (SCTP) is a

Transport Layer protocol, serving in a similar role as the popular protocols
Transmission Control Protocol (TCP) and User Datagram Protocol (UDP).
SCTP applications submit their data to be transmitted in messages (groups of
bytes) to the SCTP transport layer. SCTP places messages and control
information into separate chunks (data chunks and control chunks), each
identified by a chunk header. A message can be fragmented over a number of
data chunks, but each data chunk contains data from only one user message.
SCTP chunks are bundled into SCTP packets. The SCTP packet, which is
submitted to the Internet Protocol, consists of a packet header, SCTP control
chunks when necessary, followed by SCTP data chunks when available.
Server Group
A set of configured server hosts used for a particular service.
Session
A logical connection created between two hosts to exchange data, using

sequencing and acknowledgments to send data reliably. In the context of load
balancing TCP/IP traffic, a set of client requests directed to a server. The
server program sometimes maintains state information between requests.
Session ID
A Session ID is a unique number that a Web site's server assigns a specific

user for the duration of that user's visit (session).
The session ID can be stored as a cookie, form field, or URL (Uniform Resource
Locator). Some Web servers generate session IDs by simply incrementing
static numbers. However, most servers use algorithms that involve more
complex methods, such as factoring in the date and time of the visit along
with other variables defined by the server administrator.
549

Term
Definition
Session ID Table
The Session ID table contains the Session IDs collected from server replies
when Session ID Persistency is active.
SNMP
The Simple Network Management Protocol (SNMP) is an application layer,

asynchronous command/response polling protocol that facilitates the
exchange of management information between network devices. SNMP is a
part of the Transmission Control Protocol/Internet Protocol (TCP/IP) protocol
suite. Radware devices work with the following versions of SNMP: SNMPv1,
SNMPv2, and SNMPv3.
All management traffic is initiated by the SNMP-based network management
station (except for trap messages), which addresses the managed entities in
its management domain. Only the addressed managed entity answers the
polling of the management station.
SNMP Community
Name
An SNMP community name is a text string that acts as a password. It is used

to authenticate messages that are sent between APSolute Vision (the SNMP
manager) and the AppDirector (the SNMP agent). The community string is
included in every packet that is transmitted between the SNMP manager and
the SNMP agent.
Community names are recorded in a Community Name Table. They can be
changed directly on the AppDirector.
SOA
Service-Oriented Architecture (SOA) - is software that builds applications out

of software services. Online services are functions such as filling out an online
application for an account, viewing an online bank statement, or placing an
online book or airline ticket order.
Instead of services embedding calls to each other in their source code,
protocols are defined which describe how one or more services can talk to
each other. This architecture then relies on a business process expert to link
and sequence services, in a process known as orchestration, to meet a new or
existing business system requirement. These services communicate with each
other by passing data from one service to another, or by coordinating an
activity between one or more services.
SOAP
Simple Object Access Protocol (SOAP) is the standard for web services
messages.
Based on XML, SOAP defines an envelope format and various rules for
describing its contents. With WSDL and UDDI, it is one of the three foundation
standards of web services.
Socket
550
A sockect is a combination of IP address and port number.

Term
Definition
SSL Acceleration /
Offloading
With SSL Offloading, the cryptography is performed with the load balancers
main processor. SSL Offloading is less expensive, because no additional
hardware is required. However, because CPU-intensive cryptographic functions
are done on the general processor, the number of SSL connections a given
device can handle is limited
With SSL Acceleration, the cryptography is done on a separate SSL accelerator
card (usually an installed PCI card), enabling even a modest box to handle
thousands of SSL transactions per second.
You can perform cookie-based persistence, even on an SSL connection.
Without SSL offloading/acceleration, the load balancer cannot see the HTTP
headers, which contain the cookie that is used for persistence.
If you terminate the SSL session at the load balancer, the HTTP headers are
then viewable by the load balancer. With SSL acceleration, you get the ability
to do cookie persistence on Secure-HTTP traffic, and the performance increase
that hardware acceleration gives you.
SSO
Single sign-on (SSO) is a method of access control that enables a user to

authenticate once and gain access to the resources of multiple software
systems.
Shared Object
A Shared Object is a single instance of an object used in multiple entries, such

as a Farm Profile that is used in multiple Farms.
SSL
Secure Sockets Layer (SSL) is a protocol developed by Netscape for

transmitting private documents via the Internet.
SSL uses a cryptographic system that uses two keys to encrypt data - a public
key known to everyone and a private or secret key known only to the recipient
of the message. Both Netscape Navigator and Internet Explorer support SSL,
and many Web sites use the protocol to obtain confidential user information,
such as credit card numbers.By convention, URLs that require an SSL
connection start with https: instead of http:
SSL Table
Keeps track of SSL Session IDs.
Stateless Load
Balancing
Stateless Load Balancing treats all requests equally. By using a hashing

algorithm on source and destination ports and IP addresses in a request and
according to the hash result directs the request to its destination server.
Stateful Load
Balancing
Stateful Load Balancing detects session initiation and termination and uses
load-distribution method to determine the destination server. All subsequent
packets received for that session are sent to the same destination server until
the session is terminated.
To do this, the Load Balancer keeps a session table and creates an entry when
a new session is initiated, then removing the entry when the session is
terminated.
551

Term
Definition
Stateful Failover
In a redundancy cluster, Stateful Failover enables the backup device to take

over when a main device fails, without dropping existing sessions or breaking
persistency.
AppDirector supports stateful failover between two devices in a cluster by
mirroring the content of the tables that define session state: Client table,
Session ID (persistency) table, Proximity table and DNS Persistency table.
Instead of using mirroring, a dedicated direct connection (cross-cable or
trunk) between the AppDirector devices reduces latency and avoids packet
loss that can happen when sending mirroring data over the network.
Stateful
Inspection
Stateful Inspection ensures that transmission and application stateful rules are
enforced according to the protocol RFCs.
Switch, LAN
A LAN Switch is a network device that consists of multiple ports that connect
LAN segments (Ethernet and Token Ring) and a high-speed port (such as 100Mbps Ethernet, Fiber Distributed Data Interface [FDDI], or 155-Mbps ATM).
The high-speed port, in turn, connects the LAN switch to other devices in the
network.
A LAN switch has dedicated bandwidth per port, and each port represents a
different segment. For best performance, network designers often assign just
one host to a port, giving that host dedicated bandwidth of 10 Mbps, as shown
in Figure 123, or 16 Mbps for Token Ring networks.
Switch, Network
A Network Switch is a small hardware device that operates at the Layer 2

(Data Link Layer) of the OSI model, that joins multiple computers together
within one local area network (LAN).
A network switch contains more intelligence than a hub and is capable of
inspecting data packets as they are received, determining the source and
destination device of that packet, and forwarding it appropriately.
Super Farm
A Super Farm is a Farm of Farms.
TCP/IP
The Transmission Control Protocol (TCP) is a Layer 4 protocol, often simply

referred to as TCP/IP. Using TCP, applications on networked hosts can create
connections to one another, over which they can exchange streams of data
using Stream Sockets.
The protocol guarantees reliable and in-order delivery of data from sender to
receiver. TCP also distinguishes data for multiple connections by concurrent
applications (e.g., Web server and e-mail server) running on the same host.
Traffic, Network
552
Traffic is data transmitted over a network. Traffic is a very general term and
refers to overall network usage at a given moment, although it can refer to
specific transactions, messages, records or users in any kind of data or
telephone network.

Term
Definition
TFTP
Trivial File Transfer Protocol (TFTP), a simple form of the File Transfer Protocol
(FTP), TFTP uses the User Datagram Protocol (UDP)and provides no security
features. It is often used by servers to boot diskless workstations, X-terminals,
and routers.
Traffic Redirection
Policy
A Traffic Redirection Policy is a set of rules with Layer 4 and Layer 7 conditions
that directs requests to the appropriate server farms.
Traffic Redirection
Rule
A Traffic Redirection Rule is a set of Layer 4 and Layer 7 conditions that

determines the destination server farm for a request.
Traffic Shaping
The purpose of traffic shaping is to increase network performance by

controlling the amount of data that flows in and out of the network. Traffic is
categorized, queued, and directed according to network policies that you
define.
Trunk
Trunks main purpose is to carry traffic between switches and maintain VLAN
information.
Unlike an access link, the trunk link does not belong to a single VLAN but
instead can carry traffic from several VLANs over a point-to-point link between
two devices that understand the protocol. Because a trunk is a point-to-point
connection between two switches, it is very efficient and highly recommended
that it runs in full-duplex mode.
Trunk Port
Trunk Port - trunking is a special function that can be assigned to a port,

making that port capable of carrying traffic for any or all of the VLANs
accessible by a particular switch.
Such a port is called a trunk port, in contrast to an access port, which carries
traffic only to and from the specific VLAN assigned to it. A trunk port marks
frames with special identifying tags (either ISL tags or 802.1Q tags) as they
pass between switches, so each frame can be routed to its intended VLAN. An
access port does not provide such tags, because the VLAN for it is preassigned, and identifying markers is therefore unnecessary.
TTL
Time To Live (TTL) is a limit on the period of time or number of iterations or

transmissions in computer and computer network technology that a unit of
data (such as a record) can experience before it should be discarded.
TTS
Text to Speech (TTS).
553

Term
Definition
UDP
The User Datagram Protocol (UDP) protocol enables programs on networked

computers to send short messages sometimes known as datagrams (using
Datagram Sockets) to one another. UDP is sometimes called the Universal
Datagram Protocol or Unreliable Datagram Protocol.
UDP does not provide the reliability and ordering that TCP does. Datagrams
may arrive out of order, appear duplicated, or go missing without notice.
Without the overhead of checking whether every packet arrived, UDP is faster
and more efficient for many lightweight or time-sensitive purposes. Also, its
stateless nature is useful for servers that answer small queries from huge
numbers of clients. Compared to TCP, UDP is required for broadcast (send to
all on local network) and multicast (send to all subscribers).
URL Parsing
URL Parsing is a Layer 7 (protocol aware) feature (sometimes referred to as

content switching, but not switching in a Layer 2 network sense).
It enables a site to send traffic to different servers according to the URL in the
request. For instance, a group of image servers will serve up everything under
http://exampledomain.com/images, while a set of map servers will handle
anything under http://exampledomain.com/map.
Virtual DNS
Virtual DNS - in addition to or instead of using an IP address assigned to a

physical port, an AppDirector device can use DNS Virtual Addresses to respond
to DNS requests for its Farms.
Virtual IP
Virtual IP Address (VIP) is an IP address that is shared among multiple domain

names or multiple servers. It enables one IP address to be used for multiple
destinations, either when insufficient IP addresses are available, or as a
means to balance traffic to multiple servers in a server farm.
Virtual Server
A Virtual Server with its virtual address is the visible, routable entity through
which nodes in a load balancing pool are made available to a client, either
directly or indirectly, through a rule.
554

Term
Definition
VLAN
A Virtual Local Area Network, in Radware terminology, is a group of selected

physical interfaces that are configured as a single logical interface.
This feature is similar to what is called a switch or bridge group. In Radware
products, a VLAN of interfaces and 802.1q VLAN tagging are separate and
distinct features.
VLANs are configured through software rather than hardware, which makes
them extremely flexible. One of the biggest advantages of VLANs is that when
a computer is physically moved to another location, it can stay on the same
VLAN without any hardware reconfiguration.
LAN Switches (Layer 2 Services) - LAN switches can group individual ports into
logical switched workgroups called VLANs, thereby restricting the broadcast
domain to designated VLAN member ports. VLANs are also known as switched
domains and autonomous switching domains.
Communication between VLANs requires a router.
VLANs offer a method of dividing one physical network into multiple broadcast
domains. However, VLAN-enabled switches cannot, by themselves, forward
traffic across VLAN boundaries. For inter-VLAN communication, a Layer 3
router is required.
VLAN, Regular
(Radware)
A Regular VLAN can be described as an IP Bridge (a software bridge) between

multiple ports that provides traffic redirection of traffic between Layer 2 and
Layer 3. Several ports can be grouped for network segregation. Non-IP frames
are transmitted transparently, whether VLAN-tagged or un-tagged. The entire
traffic passes through the CPU.
A Regular VLAN is one of the following types:
IP Protocol - The VLAN requires an IP address. All of the traffic between
ports is monitored transparently by AppDirector. Packets that need
intelligent intervention are checked and modified and forwarded to the
relevant port. Other packets are simply bridged by AppDirector as if they
were on the same wire.
Other Protocol - a VLAN with the protocol "Other" cannot be assigned an
IP address. This type of VLAN is used to bridge the non-IP traffic through
AppDirector. To handle both packets that need intelligent intervention and
non-IP traffic, you can configure IP VLAN and Other VLAN on the same
ports.
Recommended: If only Layer 3 traffic passes through the AppDirector, use IP
Protocols, however, if the entire traffic passes through the AppDirector, use
Other Protocol.
VLAN Interface
A virtual LAN (VLAN) is a logical definition of a network work group. It is

roughly equivalent to a broadcast domain.
A VLAN interface is your systems point of attachment to a given VLAN. A
VLAN and a VLAN interface are analogous to an IP sub-network and an IP
interface.
555

Term
Definition
VLAN Tag
A VLAN Tag identifies traffic belonging to different VLANs.

The IEEE standard 802.1Q standard defines a method called VLAN tagging,
where switches insert a 4-byte VLAN tag into the header of each frame. The
tag contains a 12-bit VLAN ID that identifies the frames VLAN membership.
This enables multiple VLANs to use the same switch port.
Each VLAN is tagged with a unique identifier to identify different VLAN traffic
on the same physical portal, allowing VLANs to communicate with one another
using a Layer-3 router. If a packet arrives without a VLAN tag, AppDirector
sets a tag according to the destination local subnet.
AppDirector can overwrite or retain VLAN Tags on packets passing through it.
When the status of VLAN Tag support is changed, the device must be
rebooted.
VoIP
Voice-over-IP (VoIP) is a telephony term describing the facilities for delivering

voice using IP. It involves sending voice information in some digital form in
discrete packets rather than in the traditional circuit-oriented format of the
PSTN.
VoIP/SIP
VoIP/SIP Front-End solutions - A high availability VoIP/SIP signaling and

messaging solution for network border elements / SBC to support carriergrade SIP-based VoIP multimedia service delivery.
VRID
Virtual Router IDentifier - a virtual router must use 00-00-5E-00-01-XX

as its Media Access Control (MAC) address. The last byte of the address (XX)
is the Virtual Router IDentifier (VRID), which is different for each virtual router
in the network. This address is used by only one physical router at a time, and
is the only way that other physical routers can identify the master router
within a virtual router. Physical routers acting as virtual routers must
communicate within themselves using packets with multicast IP address
224.0.0.18 and IP protocol number 112.
Master routers have a priority of 255 and backup router(s) can have priority
between 1-254. When a planned withdrawal of a master router is to take
place, it changes its priority to zero which forces a backup router to take up
the master router status more quickly. This is to reduce the black hole period.
556

Term
Definition
VRRP
Virtual Router Redundancy Protocol (VRRP) eliminates a single point of

failure inherent in static default routed environments.
VRRP was initially developed to provide high availability for routers, however it
can be supported by a wide range of devices that are not routers as it is not a
routing protocol - it does not advertise IP routes nor affect the routing table.
In redundancy setups with VRRP, IP Addresses are associated with the Virtual
MAC Addresses that are owned by the main device, and are taken over by the
backup device at fail-over time
Increased availability is achieved by advertising a virtual router (an abstract
representation of master and backup routers acting as a cluster) as a default
gateway to the host(s) instead of one physical router. Two or more physical
routers are then configured to stand for the virtual router, with only one doing
the routing at any given time. If the current physical router that is routing the
data on behalf of the virtual router fails, an arrangement is made for another
physical router to automatically replace it.
The physical router that is currently forwarding data on behalf of the virtual
router is called the master router. Physical routers standing by to take over
from the master router in case something goes wrong are called backup
routers.
Weight, Server
Server Weight is a ratio assigned to a server that determines the amount of

traffic forwarded to it relative to other servers. Server weights range from 1
to 10,000.
For example, when the Dispatch Method is Least Number of Users, a weight of
3 gives that server three times the number of users than a server with a
weight of 1.
With Least Amount of Traffic, a server with weight 2 receives twice the amount
of traffic as a server with weight 1.
Default weight is 1.
557

558
Appendix B Regular Expressions

This appendix provides an overview of the basic syntax of regular expressions used in AppDirector
modules, for example in the DNS Regexp Host Name table, in the Health Monitoring module.
'^' and '$'. These symbols indicate the beginning and end of a string, respectively, as follows:
"^The": Matches any string that starts with "The"
"of despair$": Matches a string that ends in the substring "of despair"
"âbc$": A string that starts and ends with "abc" this can only be "abc"
"notice":A string that has the text "notice" within it.
If neither of the two characters is used (as in the last example), this means that the pattern may
occur anywhere within the string and is not "hooked" to any of the edges.
Symbols '*', '+', and '?' indicate the number of times a character or a sequence of characters
may occur. These symbols mean "zero or more", "one or more", and "zero or one", respectively.
For example:
"ab*": Matches a string that has an a followed by zero or more b's ("a", "ab", "abbb", etc.)
"ab+": Same, but there is at least one b ("ab", "abbb", etc.)
"ab?": There might be one or no b
"a?b+$": A possible a followed by one or more b's ending a string
Bounds can also be used. Bounds are defined inside the brace brackets and indicate ranges in the
number of occurrences:
"ab{2}": Matches a string that has an a followed by exactly two b's ("abb");
"ab{2,}": Matches a string that has at least two b's ("abb", "abbbb", etc.);
"ab{3,5}": Matches a string that has from three to five b's ("abbb", "abbbb", or "abbbbb").
The first number of a range must always be specified, for example: "{0,2}", not "{,2}").
Symbols '*', '+', and '?' denote the same as bounds "{0,}", "{1,}" and "{0,1}",
respectively.
To quantify a sequence of characters, they must be defined within parentheses:
"a(bc)*": Matches a string that has an a followed by zero or more copies of the sequence
"bc";
"a(bc){1,5}":Matches a string that has one to five copies of bc.
The '|' symbol is an OR operator:
"hi|hello": Matches a string that includes either "hi" or "hello".
"(b|cd)ef" is a string that includes either "bef" or "cdef".
"(a|b)*c" is a string that has a sequence of alternating as and b's ending with c.
A period ('.') stands for any single character:
"a.[0-9]": Matches a string that has an a followed by a single character and a digit.
"^.{3}$": A string with exactly 3 characters
Bracket expressions specify which characters are allowed in a single position of a string:
"[ab]": Matches a string that has either an a or a b (identical to "a|b")

"[a-d]":A string that has lowercase letters 'a' through 'd' (identical to "a|b|c|d" and
"[abcd]");
559

Regular Expressions
"^[a-zA-Z]": A string that starts with a letter
"[0-9]%": A string that has a single digit before a percent sign
",[a-zA-Z0-9]$":A string that ends in a comma, followed by an alphanumeric character
You can also list the characters which you do not want to appear in the string. Use a '^' as the first
symbol in a bracket expression. For example:
"%[â-zA-Z]%" matches a string with a character that is not a letter, between two percent
signs.
To take the characters "^.[$()|*+?{\" literally, they must follow a backslash ('\'), to denote
they have a special meaning. This includes the backslash character itself.
Remember that bracket expressions are an exception to the above rule. Within brackets, all special
characters, including the backslash ('\'), lose their special meanings. For example, "[*\+?{}.]"
matches precisely any of the characters within the brackets.
560

Troubleshooting
Appendix C Troubleshooting
This appendix provides:
Diagnostic Tools, page 561
Acceleration-Engine Logs, page 576
Downloading the Technical Support File, page 578
Diagnostic Tools
This section contains common Diagnostics tools to use with AppDirector and contains these topics:
Diagnostics Trace-Log, page 561
Traffic Capture, page 564
Diagnostics Tools Policies, page 569
Diagnostics Tools File Management, page 571
System Diagnostics, page 572
When the device does not operate as expected and traffic is not redirected according to configured
policies, you must diagnose the system to understand the problem, or to help provide Radware with
more information. System administrators can use the following Diagnostics tools:
Diagnostics Trace-Log
Traffic Capture
Diagnostics will stop automatically in the following cases:
You manually stop the diagnostics tasks
You reboot the device
Diagnostics Trace-Log
Understanding the traffic flow within the device is an important stage in the diagnostic process.
Using the Diagnostics Trace-Log feature, system administrators can trace traffic passing via the
device to understand the flow of packets. To pinpoint the source of the problem, Diagnostics TraceLog allows differentiating between various application modules. For example, you can trace the
Health Monitoring Module to understand why a specific check fails.
INFO: starting check DHCP

DEBUG: Destination port used=67 (Method: DHCP, Name: DHCP)
WARNING: Calling Timeout function (Method: DHCP, Name: DHCP)
DEBUG: Failure function called, failing check (Method: DHCP, Name: DHCP)
For each Radware product, there is a list of available modules under the traced applications menu.
Note: In this version, Diagnostics Trace-Log is provided for APSolute OS generic modules only
(Health Check, Bandwidth Management), not for AppDirector specific functionality.
When using the Diagnostics Trace-Log, you can configure the message format using the following
parameters:
Date - The traced date.
Time - The traced time.
561

Troubleshooting
Platform Name - The platform mib name.
Line Number -the line number in the source code (used by Radware's R&D).
Packet ID - an ID given by the device for each packet. This allows seeing the packets order.
Module Name - The name of the traced module.
Task Name - The name of the specific task of the traced module.
>> The trace-log module is also used as a logging mechanism. When the trace-log feature is
enabled the device will write logs for two scenarios, Packet Flow and Log File. In both
cases the messages are written to the same log file.
>> Packet flow for each packet, logs are written describing the actions the device took
regarding this packet.
>> Log file this is a regular log file as found in other (not Radware) applications. Each
module in the device writes it own logs. In this case there is no direct connection
between the logs written to the traffic passing through the device. For example, if the
log severity level of the BWM module is set to Info the BWM module will write a message
to the log each time the user enable/disable the BWM feature.
Diagnostics Trace-Log Tool Configuration

The Diagnostics Trace Tool Configuration window allows you to understand the traffic flow within the
device is an important stage in the debugging process.
To set the Diagnostics Trace Tool Configuration parameters

1.
From the Services menu, select Diagnostics > Trace-Log > Parameters. The Diagnostics
Trace Tool Configuration window appears.
2.
Set the parameters.
Parameter
Description
Status
Enables/disables the Diagnostics Trace capability.
Output To Sys-log
Server
Enables/Disables the sending of output from the diagnostic trace to a

Syslog Server.
Output To File
Enables/disables the file to be kept on the compact flash. Due to

compact flash size limitation, two files are employed for the task of
saving the data. Once the first file is filled up, the device automatically
switches to the second file, until the second file is filled up and then it
overwrites the first file and so on. Options are:
RAM drive and flash
RAM drive
None
Output To Terminal
3.
Enables/Disables the sending of output from the diagnostic trace to

the Terminal.
Diagnostics Trace-Log Message Format

The Diagnostics Trace Message Format window allows you to define the parameters that appear in
the trace message.
562

Troubleshooting
To set the parameters of the Diagnostics Trace Message Format window

1. From the Services menu, select Diagnostics > Trace > Message Format. The Diagnostics
Trace Message Format window appears.
Parameter
Description
Date
Date when the message was generated.
Time
Time when the message was generated.
Platform Name
Platform mib name.
File Name
Output file name.
Line Number
Line number in the source code (used by Radware's R&D).
Packet Id
An ID assigned by the device to each packet. This enables you see the
order of the packets.
Module Name
Name of the traced module.
Task Name
Name of the specific task of the traced module.
Trace-Log Modules
The Trace Modules window allows you to view the results of the debug trace process according to the
application modules employed by the device. Differentiating between various application modules in
the debug process helps to pinpoint the source of the problem. For example, you can trace only the
Health Monitoring Module to understand why a specific check fails.
To set the Traced Modules parameters

1. From the Services menu, select Diagnostics > Trace-Log > Modules. The Traced Modules
window appears.
2. Set the parameters .
Parameter
Description
Name
Name of the traced module.
Status
Current status of the traced module.
Severity
Severity of bug traced in this module.

Values: Notice, Emergency, Warning, Alert, Critical, Error, Info, Debug
3. Click on the relevant name from the table. The Traced Modules Update window appears.
563

Troubleshooting
Traffic Capture
Traffic Capture allows system administrators to capture the traffic passing via the device and traffic
that is generated by the device. The capture is saved in a TCPDUMP format for later analysis.
For remote administration and debugging, it is also possible to send the output of the Traffic
snapshots to the terminal (CLI / Telnet and SSH).
System administrators may also configure the capture point - when the packet reaches the device,
when packet leaves the device or in both cases. This allows better understanding of the traffic flow
in case the device manipulates the packet, due to NAT, Traffic from VIP to real server, etc.
Traffic Captures allow you to capture the traffic passing via the device and traffic that is generated
by the device. Captured traffic can be saved in a TCPDUMP format for later analysis. For remote
administration and debugging it is also possible to send the output of the Traffic Captures to the
terminal (CLI / Telnet and SSH). You can configure the capture point. Using the snapshot point you
can capture packets that reach the device, packets that leave the device or both. This allows better
understanding of the traffic flow in case the device manipulates the packet, due to NAT, Traffic from
VIP to real server etc.
To set the parameters of the Capture Tool Configuration window

1.
From the Services menu, select Diagnostics > Capture > Parameters. The Capture Tool
2.
Set the parameters.
Parameter
Description
Status
Enables/disables (default) the Traffic Snapshot capability.
Output To File
Enables/disables the file to be kept on the compact flash. Due to

compact flash size limitation, two files are used to save data. Once the
first file is full, the device automatically switches to the second, until it
is full and then it overwrites the first file, etc.
Values: RAM drive and flash, RAM drive, None
Output To Terminal
Enables/disables (default) sending output of the traffic captures to the

Terminal.
Capture Point
Indicates location of capture point.

Values:
On-Packet-Arrive - capture Rx only (only packets entering the
device ports)
On-packet-send - capture Tx only (only packet leaving the device
ports)
Both - capture both Rx and Tx
Note: Capture can be performed when the packet arrives at the
device, when it leaves the device or both.
564

Troubleshooting
Parameter
Description
Traffic Match Mode
This controls how a session traversing a VIP will be captured logically.

Each session sent to device VIP has two sides - client side (the session
between the client and the VIP) and server side (the session between
the AppDirector and the server). If the configured capturing policy
matches any part of these two sessions then select:
Inbound only - capture the client side session only
Inbound and Outbound - capture both the client side and the
corresponding server side sessions
Note: This parameter has no effect on traffic that does not traverse
a VIP.
Note: When rebooting the device, the capture moves to Disable.
System Diagnostics Capture Mode

Capture Mode defines at what point of the Radware device the traffic is filtered by classification
filters.
This is relevant only for traffic that is handled by the Client Table.
This is relevant when the IP address changes during the session (examples: NAT, VIP etc.).
You can choose to match traffic patterns from two values:

Inbound only (Default): A device captures packets where the IP appears explicitly in the
traffic. The device matches the configured policies against traffic as first seen when it enters the
device. Only matching traffic is captured. This mode has a low performance penalty.
Inbound and Outbound: A device captures the complete session, including parts where the
configured IP does not appear (for example; before or after NAT). The device matches the
configured policies against the traffic, both entering and leaving the device. Only matching
traffic is captured. This mode has a high impact on device performance.
Notes:
>> Inbound and Outbound mode can potentially affect performance.
>> When rebooting the device, the capture option moves to "disable " (since the "enable"
state reduces the performance of the device) .
System Diagnostics Capture Point

Capture Point defines at what point in the Radware device the traffic is captured for the .cap file or
terminal output. The options are:
On-packet-arrive - Point A
On-packet-send - Point B
Both - Both Point A & B.
The Capture Point can also be set using the CLI command system diagnostics capture point.
Traffic in this scenario is as follows:
1. Client IP to VIP
2. Client IP to Server IP
565

Troubleshooting
4.
VIP to Client IP
With Capture filters set to: Any to VIP and VIP to Any, the output depends on the Capture Mode used
and on Capture Point, as follows:
Mode \ Point
On-packet-arrive
On-packet-send
Inbound \ Both
Step #1
Step #2
Inbound & Outbound \ Both
Step #1 and Step #3
Step #1 trough Step #4
To capture all steps with Capture Mode of Inbound Only, use Capture Point of Both and set policies
as follows: Any to VIP and Server IPs to Any.
TCP-Dump (Sniffer)
TCP-Dump is a common packet sniffer that runs under the command line. It allows you to intercept
and display TCP/IP and other packets being transmitted or received over a network. It is one of the
most useful tools for debugging network problems. Benefits include:
captures traffic flow through proxy for configuration debugging and checking purposes
well known syntax of filters available on the internet
standard pcap format has many tools available including wireshark
When the AppDirector acceleration engine module is used, information about TCP Connections and
Sessions, terminated and processed by it, can be received using TCP-Dump.
You can use TCP-Dump on any AppDirector interface. You can output dump to the CLI prompt or
export it to a file (over SSH).
After you connect to the acceleration engine module (see Direct Access to Proxy, page 575)use the
following commands at prompt for TCP-Dump:
system tcpdump print [-t <timeout (sec)>] [-c <max number of packets>] [-s
<size>]
This displays the TCP-Dump at the prompt. The information is continuously printed to the screen
until the collection timeout is over.
system tcpdump export [-t <timeout (sec)>] [-c<max number of packets>] [-s
<size>]
This exports the TCP-Dump information to a text file. Information is saved in the file until the
collection timeout is over where the following variable suffixes are:
-t - The period for the TCP-Dump to collect data. By default It is 60 seconds.
-c - Maximum number of packets to collect. By default it is 10000 packets.
-s - Maximum packet length to be captured. By default it is 0 (capture whole packet).
You can apply traffic filters to the dump. AppDirector uses the Ethereal format of expressions. For a
complete description refer to: http://www.ethereal.com/docs/man-pages/tcpdump.8.html
566

Troubleshooting
Example for commonly used filters:
To filter by destination IP
Enter: 'dst host' and the IP.
To filter by source IP
Enter: 'src host' and the IP.
To filter by destination TCP port

Enter: 'dst port' and the port.
To filter by source port

Enter 'src port' and the port.
SSL Dump
SSL dump is an SSL/TLS network protocol analyzer. It identifies TCP connections on the chosen
network interface and attempts to interpret them as SSL/TLS traffic. When it identifies SSL/TLS
traffic, it decodes the records and displays them in a textual form. If provided with the appropriate
keying material, it will also decrypt the connections and display the application data traffic. Benefits
include:
captures encrypted traffic and can view it in the clear for debugging and checking.
previously you needed to export from the device and use 3rd party software combined with
device Keys to decrypt and see traffic but with SSL dump, it is easier and safer.
Normally, one of the most useful tools for debugging network problems is sniffing or TCP-Dump
utilities, however, because part of the traffic that goes through AppDirector acceleration engine is
encrypted, an SSL dump is also required, to dump and decrypt traffic. This feature is available only
from CLI, by direct access. For more information on how to direct access the proxy, see Direct
Access to Proxy, page 575.
Using this command you can dump traffic and decrypt it using keys configured on the device. The
following need to be set:
1. The key(s) used for traffic decryption
2. SSLDump:
a.
b.
Traffic to dump and decrypt. This is set using a filter expression as described above in TCPDump (Sniffer), page 566.
How long to capture traffic. This is set using the Timeout parameter, default is 60 seconds,
(maximum packets to capture is 10000).
system ssldump print [-t <timeout (sec)>] [-k <key-index1,key-index2,keyindexN>
567

Troubleshooting
This displays the SSLDump at the prompt. The information is continuously printed to the screen until
the collection timeout is over.
system ssldump [-t <timeout (sec)>] [-c<max number of packets>] [-s <size>]
This exports the SSLDump information to a text file. Information is saved in the file until the
collection timeout is over where the following variable suffixes are:
-t - The period for the SSLDump to collect data. By default It is 60 seconds.

-k - specify the key names to be used separated by commas. If you do not enter the -k
parameter, the device uses all existing keys.
The output of SSLdump is a text file (or multiple files, if multiple keys are used) and the output files
are packed into a zip file.
With SSLdump, print to screen is not available, the user can only save the output to file (or multiple
files if multiple keys are used).
Examples
The following prompt is received:
Max packets count: 10000

Timeout: 60 seconds (as was set in the-t flag in the ssldump command)
Max packet length: capture whole packet
Enter filter expression. Press <enter> to continue: >
1.
When pressing "enter" you receive the following prompt:
Capture started.
Press <ctrl-c> to stop.
2.
The CLI is locked until capture timeout is reached, default maximum packet count has been
reached (10,000) or you have pressed <ctrl-c>.
3.
In the background, a tcpdump process is run with the default parameters or with the filter
expression that you entered.
4.
The device now runs the "ssldump" on the output file of the "tcpdump" K times (1 time for each
of the chosen keys). Eventually there will be K+1 files inside the machine:
"tcpdump" capture file and K ssldump files (one for each key).
5.
These files will be zipped into one file called "ssldump.tar.gz", which is saved in /tmp dir.
6.
You are now prompted to export the file.
ssldump for the keyname id X when X is the key name. This is the prompt for each key.
1-SSH
2-Quit
Please select export protocol [1-2]:
7.
If you choose "1", you will get the following prompt:
Capture ended.
You must copy /tmp/ssldump.tar.gz via scp:
scp -P <SSH port, default: 1500> radware@<device ip>:/tmp/ssldump.tar.gz
Warning:
/tmp/ssldump.tar.gz will be deleted after the command ends.
Press enter to quit.
568

Troubleshooting
8. Now you use scp to copy the ssldump.tar.gz file to a local machine from the device.
9. When you press <enter>, the interactive command exits and the user is back to the CLI
prompt. At this point, all the ssldump, TCP-Dump and tar.gz files are deleted from the machine.
Diagnostics Tools Policies

In most cases there is no need to capture the entire traffic passing via the device. With the powerful
classification engine, system administrators can configure diagnostics policies. Using the diagnostics
policies, the device classifies the traffic and only in case there is a match between the traffic
patterns and diagnostics policies the device stores the information. The classification is based on a
combination of the following criteria:
The classification is based on a combination of the following criteria:
1. Inbound physical port group
2. Outbound physical port group
3. VLAN Tag group
4. Source MAC group
5. Destination MAC group
6. Source Network
7. Destination Network
8. Services (only filters based on L3 and L4 are supported).
The Diagnostics Policies Create window allows you to define the debug policies.
Note: To reuse the policy, edit the policy and set it again.
To create a Diagnostics Policy parameters

1. From the Services menu, select Debug > Policies. The Diagnostics Policies window appears.
2. Click Create. The Diagnostics Policies Create window appears.
Parameter
Description
Name
User defined name of the policy.
Index
Number assigned to this policy in Debug Policy table. Using this index
number, policies are identified by the device.
Description
User defined description of the policy.
VLAN Tag Group
VLAN Tag group to be classified.
Destination
All packets destined to defined IP address are classified.
Source
All packets originating from defined IP address are classified.
Inbound/Outbound
Port Group
Inbound/outbound port group to be classified.
Service Type
Service Types to be classified.
Service
Services to be classified.
569

Troubleshooting
4.
Parameter
Description
Source/Destination
MAC Group
MAC group to be classified.
Maximal Number of
Packets
Maximal amount of packets to capture.
Maximal Packet
Length
Maximal length for capture of a single packet.
Capture Status
Enables/Disables the Capture capability.
Trace Status
Enables/Disables the Trace capability.
Once the device captures the predefined amount of packets, it stops

capturing traffic. In some cases, the device captures fewer number of
packets than the configured value. This happens when the device is
configured to drop packets.
In addition to the above, the user can configure the amount of packets to capture. Once the device
captures the predefined amount of packets, it stops capturing traffic for the specific policy. In some
cases, the device captures fewer number of packets than the configurable value. This happens when
the device is configured to drop packets.
Note: In capture mode when limiting the number of packets to reuse the policy, it is necessary
to edit the policy and reset it.
Classification by diagnostics policy is performed for all packets arriving to device immediately after
their arrival. Only packets generated on device are being classified before the packet is sent. This
may cause the following:
When Capture point is set to "on-packet-send", the number of packets contained in the capture
file may be lower than the preconfigured limit. This can happen if some packets arriving to
device were matched by the policy but were not sent (since it was blocked by the device).
When Capture point is set to "both", the capture file may contain more packets than the
predefined limit (This happens, when sending ping to device).
For Traffic Capture you can also configure the length of the packet that the device captures. By
default the device captures the entire packet.
570

Troubleshooting
Diagnostics Tools File Management

The output of the Diagnostics Tools is kept on the RAM Drive and Flash memory (if configured). The
device uses two files for each tool and once one file reaches its capacity limit, the device starts
keeping the information in the other file. Once the second file reaches its capacity, the device
overwrites the first file etc. When one of the files on the RAM Drive reaches its capacity limit, the
device appends its contents to the file on the compact flash.
The Diagnostic Tools Files Management window allows you to download or delete files from the RAM
or Main Flash drive to analyze the date.
To download or delete Trace Files

1. From the Services menu, select Diagnostics > Files. The Diagnostic Tools Files Management
window appears.
Parameter
Description
File Name
Name of RAM file or Main Flash file depending on file selection.
File Size
Indicates the file size in bytes.
Action
Select the required action:

Download: Selecting download starts the download process of the
selected file. Follow the on screen instructions.
Delete: Deletes the selected file
3. Select either, the RAM or Flash file as appropriate.

4. From the action field select the required action and follow the on screen instructions.
5. Once the device collects the information, you can download the output files as follows:
To access the file system using FTP Client. The files are located under the dbgtools
directories (CF / CM and RD). To access the device via the FTP service, the FTP server must
be enabled prior to access.
Using TFTP In addition, the files can be sent to a TFTP server (supported only via the CLI
using the CLI command "system diagnostics files send.
Using the Web Based Management.
Notes:
>> Diagnostic Tools may cause a performance penalty on the AppDirector device by
increasing CPU load and console response time.
>> If a software upgrade is being performed while any of the diagnostics tools are being
executed, operation of the diagnostics tools stops and all diagnostics files are erased.
>> After reboot, the diagnostics tools is disabled by default.
571

Troubleshooting
Diagnostics Tools Tuning

Using this feature, you can configure how many policies were run after reset.
To tune diagnostic policies

1.
Select Services > Tuning > Diagnostics. The Diagnostics Tools Tuning window appears.
2.
Enter the number of policies.
3.
Parameter
Description
Policies
Displays maximum number of policies in Debug Policies table.
Policies after reset
Displays maximum number of policies in Debug Policies table after

reset.
Click Set. The configuration is saved.
System Diagnostics
This section includes these topics:
Traffic Captures, page 574
Diagnostics Trace, page 575
Direct Access to Proxy, page 575
Included in this appendix is a short introduction to Radware system diagnostics using CLI. The
system diagnostics tool set is accessed by performing the command, System Diagnostics in the
terminal console. For more detailed information see the accompanying CLI Reference Guide.
capture
Packets Capture Diagnostics Tool
mode
Packets Capture Mode Definition
inbound - The filter in capture mode is

performed on packets at each entry point
to the RADWARE device.
inbound and outbound - The filter in capture mode is
performed on packets both at the entry
and exit points to and from the AppDirector
device(impairs performance severely)
output
Capture Output Configuration
file Capture Output To File Configuration

term Capture Output To Terminal
Configuration
point
Packets Capture Point Definition
(1) on-packet-arrive
(2) on-packet-send
(3) both
status
Capture Tool Status
1 - enabled
2 - disabled
files
abort
572
Diagnostics Tools Generated Files Management

Abort file download

Troubleshooting
del
Delete file
system diagnostics files del [file name/all]

[RD/MF]
RD - RAM drive file
MF - main flash file
list List files generated by diagnostic tools
send Send file to TFTP server
system diagnostics files send [file name]
[RD/MF] [TFTP Server ID] <-v>
RD - RAM drive file
MF - main flash file
-v - send file to terminal policies
Diagnostics Policies
<get>
<Name>
set
<Name> <-switch value>
destroy/del <Name>
create/add <Name> <-switch value>
help
<-switch>
Switches:
-i
: Index
-d
: Description
-src : Source
-dst : Destination
-rx
: Inbound Port Group
-tx
: Outbound Port Group
-st
: Service Type
-srv : Service
-vt
: VLAN Tag Group
-sm
: Source MAC Group
-dm
: Destination MAC Group
-cap : Capture Status

-tr
: Trace-Log Status
-pn
: Maximal Number of Packets
-pl
: Maximal Packet Length
trace-log
Trace-Log Diagnostics Tool
modules
Trace-Log Modules
system diagnostics trace-log modules help:

<get>
<Name>
set
<Name> <-switch value>
help
<-switch>
Switches:
-st
: Status
-sev : Severity
msg-format Message Format Configuration
573

Troubleshooting
date
Status of Date in the trace-log

message format
file
Status of File in the trace-log

message format
line
Status of Line in the trace-log

message format
module
Status of Module in the tracelog message format
pckt-id Status of Packet-ID in the

trace-log message format
platform Status of Platform in the tracelog message format
task
Status of Task in the trace-log

message format
time
Status of Time in the trace-log

message format
output
file
Trace-Log Output Configuration
Trace-Log Output To File

Configuration
syslog
term
Trace-Log Output To Syslog

Configuration
Trace-Log Output To Terminal
Configuration
status Diagnostics Trace-Log Status

1 - enabled
2 - disabled
Traffic Captures
Parameter
Description
Status
Shows if Traffic Capture status is enabled or disabled
Output to File
Enables the file to be kept on compact flash. Due to compact flash size
limitation, two files are employed to save data. Once the first is full, the
device automatically switches to the second until the second file is full.
The device then overwrites the first file etc.using this file name
convention:
capture_device_name_DDMMYYYY_HHMMSS (for Example capture_AppDirector_27122051_010302_1.cap).
Output to Terminal
Enables sending traffic output captures to the Terminal
Output to RAM Drive
Enables you to send traffic output captures to the RAM Drive. Here, the
file is deleted after device reboot.
Capture Point
Shows location of capture point . Capture can be performed when the

packet reaches the device, when packet leaves the device or both
Traffic Match Mode
Controls how a session traversing a VIP will be captured logically.
574

Troubleshooting
Diagnostics Trace
Parameter
Description
Status
Shows whether Diagnostics Trace status is enabled or disabled.
Output to File
Enables file to be kept on compact flash. Due to compact flash size

limitation, two files are employed to save data. Once the first is full, the
device automatically switches to the second until the second file is full
and then it overwrites the first file etc. The device uses this file name
convention: trace_log_Device_name_DDMMYYYY_HHMMSS (for Example
- trace_log_AppDirector_27122051_010302_1.txt ).
Output to Terminal
Enables you to send traffic captures output to the Terminal.
Output to RAM Drive
Enables you to send traffic captures output to the RAM Drive - For AS 1.
Output to Syslog
Enables you to send the output of the Diagnostics Trace to a Syslog

Server.
Direct Access to Proxy

AppDirector enables you to directly connect to the internal AppDirector acceleration engine module
where you need to perform related debugging or to view traffic flows. It provides the following
benefits:
you gain access to see the proxy module logs
you gain access to the proxy module to run TCP-Dump and SSLdump
you can run proxy CLI commands
To gain access, use the following command:
manage proxy-access status set enable

and then you receive the following output:
Proxy |
SSH Port
------|---------1
1500
Use any IP address on AppDirector SSH enabled ports to access the proxy on the specified port (in
the above example: 1500).
Note: Only a single IP can connect to a proxy port at any time.

After you enable it, you can login to the AppDirector acceleration engine through port 1500, (this is
a default but not fixed) with users configured on the AppDirector.
To control the log files, run the following command on direct access:
system logfile
For using the tcpdump and ssldump feature see TCP-Dump (Sniffer), page 566.
575

Troubleshooting
Acceleration-Engine Logs
Application Acceleration Enabled

Troubleshooting service problems requires an understanding of decisions and actions performed by
AppDirector and its Acceleration Engine. These logs enable you to view these decisions and actions.
To configure the Acceleration Engine Logging

1.
From the Services menu, select Logging > Acceleration-Engine Logs. The AccelerationEngine Logs window appears.
2.
Set the parameters.
Parameter
Description
Compression Logs
Determines whether Compression activity is logged.

Values: enable/disable (default).
Caching Logs
Determines whether Caching activity is logged.

HTTP Logs
Determines whether HTTP activity is logged.

SSL Logs
Determines whether SSL activity is logged.

3.
Click Set. The Acceleration Engine Logs are configured.
To save a Log File

When you have finished logging, you can download the collected log data to a file on your PC. Select
Save Log File and a save dialog window appears. Click Open or Save.
Note: The downloaded log file is in text format, and can be best viewed by importing into
Microsoft Excel. For best results, import the file into Microsoft Excel.
To clear a Log File

Finally, when you have the information that you need, you can select Clear Log File. A message will
appear informing you that the log was successfully cleared.
576

Troubleshooting
Using Acceleration Logs Efficiently

To view Acceleration logs conveniently, you can import them via Microsoft Excel where they can be
filtered and sorted.
To import a log
1. Open Microsoft Excel.
1. Open the log as a text file within Microsoft Excel. Step 1 of the Text Import Wizard dialog
appears.
2. Mark the radio button Delimited.
3. Click Next. Step 2 of the Text Import Wizard dialog appears.
4. First define space as a delimiter .

5. Now select Treat consecutive delimiters as one, as shown in the example here.
6. Click Next. Step 3 of the Text Import Wizard dialog appears.
7. Click Finish. The Log opens as a Microsoft Excel spreadsheet.
577

Troubleshooting
To edit the Log file in Microsoft Excel

1.
Perform find and replace of all + to (space).
2.
Select row 8 (first row of logs) and go to Microsoft Excel 2007 View menu.
3.
Select Freeze Panes (to keep the header row constant).
Note: Use Windows > Freeze-Pane in older versions of Excel.
4.
Select row 7 (last headings row) and go to Data menu.
5.
Select the Filter button (Auto-Filters in older versions of Microsoft Excel). You can use the filters
to see logs by date/time, and then filter the specific session that you want to review using the
session-ID column filter.
Downloading the Technical Support File

When debugging, AppDirector generates a separate file delivered in text format and aggregating all
CLI commands needed by Radware Technical Support. The file also includes output of various CLI
commands, e.g; a printout of the Client table. You can download this file and send it to Radware
Technical Support.
To download the Technical Support file

1.
In the main WBM window, from the File menu select Support. The Download Technical Support
Info File window appears.
2.
Click Set to download the file. A file download dialog box opens asking if you wish to open or
save the file.
3.
Click Open or Save.
578

Troubleshooting
Notes:
>> The .TAR format that includes AppDirector support, AppXcel DX log, AppXcel logger and
the AppDirector configuration file is only available via WBM. However, if you download
the Technical Support file via CLI (.i.e. TFTP) it only includes the regular support file.
>> To ensure that all device messages are displayed, please define your AppDirector WBM
as a "safe site" in your pop-up blocker, and enable it to display pop-up messages.
>> For more information, refer to the Radware CLI Reference Manual.
579

Troubleshooting
580

Optimizing AppDirector with AppXcel Application
Appendix D Optimizing AppDirector with

AppXcel Application Accelerator
This appendix describes how AppDirector interacts with AppXcel. For further detailed information on
the AppXcel device see the AppXcel User Guide.
AppXcel and AppDirector, Radwares infrastructure load balancer, are optimized to work together.
AppXcel is a transaction accelerator that is optimized to perform SSL calculations. Off-loading these
calculations to AppXcel relieves web server CPU, thereby increasing its capacity, and increases the
services potential number of Transactions Per Second (TPS). Combining AppXcel with AppDirector
creates a comprehensive solution that dramatically increases network certainty and performance.
When SSL based traffic approaches the network, AppDirector identifies that the traffic must first be
decrypted. AppDirector makes a load balancing decision about the best AppXcel accelerator to send
the traffic to for decryption. Once the traffic is decrypted, AppDirector receives the traffic back and
load balances the decrypted traffic to the best available server.
When you use AppDirector with AppXcel in your ADC, you first create an AppXcel farm on
AppDirector. A farm is a group of servers providing the same service. When a new service request
arrives, AppDirector identifies the required service and selects the most available server within the
farm that provides this service. Each farm is identified by its Virtual IP Address (VIP). This IP
address is used by clients to approach the farm and each server within the farm is recognized by its
IP address.
For more information about configuring AppXcel with AppDirector, see the AppDirector Technical
Solution Guide.
581

Optimizing AppDirector with AppXcel Application Accelerator
582

SSL Encryption,Certificates and Ciphers
Appendix E SSL Encryption,Certificates and

Ciphers
This appendix is intended as an extra resource for security issues, speciifcally Certificates and
Ciphers Suites. If you are planning to configure a SSL policy, then you will find valuable background
information along with relevant Cipher Suites. See "Complete List of the Content Of All Cipher Suites
(Front-end and Back-end)" on page 593.
SSL Encryption, page 583
Certificates, page 584
Ciphers and Cipher Suites, page 590
SSL Encryption
Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic
protocols that provide communications security over the Internet. TLS and SSL encrypt the
segments of network connections above the Transport Layer, using symmetric cryptography for
privacy and a keyed message authentication code for message reliability. This allows us to encrypt
the data stream itself, which can then be transmitted securely, using any of the application layer
protocols. Two encryption techniques are used:
Public key encryption is used to encrypt and decrypt certificates during the SSL handshake.
A mutually agreed symmetric encryption technique, such as DES (data encryption standard), or
triple DES, is used in the data transfer following the handshake.
To make an environment secure, you must be sure that any communication is with "trusted" sites
whose identity you can be sure of. SSL uses certificates for authentication these are digitally
signed documents which bind the public key to the identity of the private key owner. Authentication
happens at connection time, and is independent of the application or the application protocol.
Authentication involves making sure that sites with which you communicate are who they claim to
be. With SSL, authentication is performed by an exchange of certificates, which are blocks of data in
a format described in ITU-T standard X.509. The X.509 certificates are issued, and digitally signed
by an external authority known as a certificate authority.
Encryption Protects Data During Transmission

Web servers and Web browsers rely on the Secure Sockets Layer (SSL) protocol to create a uniquely
encrypted channel for private communications over the public Internet. Each SSL Certificate consists
of a public key and a private key. The public key is used to encrypt information and the private key
is used to decipher it. When a Web browser points to a secured domain, a level of encryption is
established based on the type of SSL Certificate as well as the client Web browser, operating system
and host servers capabilities. That is why SSL Certificates feature a range of encryption levels such
as "up to 256-bit".
Strong encryption, at 128 bits, can calculate 288 times as many combinations as 40-bit encryption.
That's over a trillion times a trillion times stronger. At current computing speeds, a hacker with the
time, tools, and motivation to attack using brute force would require a trillion years to break into a
session protected by an SGC-enabled certificate. To enable strong encryption for the most site
visitors, choose an SSL Certificate that enables at least 128-bit encryption for 99.9% of Web site
visitors. True 128-bit SSL Certificates
583

Credentials Establish Identity Online

Credentials for establishing identity are common: a drivers license, a passport, a company badge.
SSL Certificates are credentials for the online world, uniquely issued to a specific domain and Web
server and authenticated by the SSL Certificate provider. When a browser connects to a server, the
server sends the identification information to the browser.
To view a Web sites credentials:
Click the closed padlock in a browser window
Click the trust mark (such as the VeriSign Trust Seal)
Look in the green address bar*
Authentication Generates Trust in Credentials

Trust of a credential depends on confidence in the credential issuer, because the issuer vouches for
the credentials authenticity. Certificate Authorities use a variety of authentication methods to verify
information provided by organizations. VeriSign, the leading Certificate Authority, is well known and
trusted by browser vendors because of our rigorous authentication methods and highly reliable
infrastructure. Browsers extend that trust to SSL Certificates issued by VeriSign.
Certificates
In cryptography, X.509 is an ITU-T standard for a public key infrastructure (PKI) for single sign-on
(SSO) and Privilege Management Infrastructure (PMI). X.509 specifies, amongst other things,
standard formats for public key certificates, certificate revocation lists, attribute certificates, and a
certification path validation algorithm.
In cryptography, a public key certificate (also known as a digital certificate or identity certificate) is
an electronic document which uses a digital signature to bind together a public key with an identity
information such as the name of a person or an organization, their address, and so forth. The
certificate can be used to verify that a public key belongs to an individual.
In a typical public key infrastructure (PKI) scheme, the signature will be of a certificate authority
(CA). In a web of trust scheme, the signature is of either the user (a self-signed certificate) or other
users ("endorsements"). In either case, the signatures on a certificate are attestations by the
certificate signer that the identity information and the public key belong together.
For provable security this reliance on something external to the system has the consequence that
any public key certification scheme has to rely on some special setup assumption, such as the
existence of a certificate authority.
Certificates can be created for Unix-based servers with tools such as OpenSSL's ssl-ca or SuSE's
gensslcert.
Contents of a Typical Digital Certificate
Serial Number Used to uniquely identify the certificate.
Subject The person, or entity identified.
Signature Algorithm The algorithm used to create the signature.
Issuer The entity that verified the information and issued the certificate.
Valid-From The date the certificate is first valid from.
Valid-To The expiration date.
Public Key The public key to encrypt a message to the named subject.
Thumbprint Algorithm The algorithm used to hash the certificate.
Thumbprint The hash itself to ensure that the certificate has not been tampered with.
584

Classes
VeriSign introduced the concept of classes of digital certificates:
Class 1 for individuals, intended for email
Class 2 for organizations, for which proof of identity is required
Class 3 for servers and software signing, for which independent verification and checking of
identity and authority is done by the issuing certificate authority
Class 4 for online business transactions between companies
Class 5 for private organizations or governmental security
Certificates and web site security

The most common use of certificates is for HTTPS-based web sites. A web browser validates that an
SSL (Transport Layer Security) web server is authentic, so that the user can feel secure that their
interaction with the web site has no eavesdroppers and that the web site is who it claims to be. This
security is important for electronic commerce. In practice, a web site operator obtains a certificate
by applying to a certificate provider with a certificate signing request. The certificate request is an
electronic document that contains the web site name, contact email address, and company
information. The certificate provider signs the request, thus producing a public certificate. This
public certificate is served to any web browser that connects to the web site and proves to the web
browser that the provider believed that the provider issued a certificate to the owner of the web site.
Before issuing a certificate, the certificate provider will request the contact email address for the
web site from a public domain name registrar, and check that published address against the email
address supplied in the certificate request. Therefore, an https web site is only secure to the extent
that the end user can be sure that the web site is operated by someone in contact with the person
that registered the domain name.
As an example, when a user connects to https://www.example.com/ with their browser, if the
browser gives no certificate warning message, then the user can be sure that interacting with
https://www.example.com/ is equivalent to interacting with the entity in contact with the email
address listed in the public registrar under "example.com", even though that email address may not
be displayed anywhere on the web site. No other surety of any kind is implied. Further, the
relationship between the purchaser of the certificate, the operator of the web site, and the generator
of the web site content may be tenuous and is not guaranteed. At best, the certificate guarantees
uniqueness of the web site, provided that the web site itself has not been compromised (hacked) or
the certificate issuing process subverted.
X.509 Certificates
An X.509 certificate specifies a binding between a public key and a set of attributes that includes (at
least) a subject, name, issuer name, serial number and validity interval. This binding may be subject
to subsequent revocation advertised by mechanisms that include issuance of CRLs, OCSP tokens or
mechanisms that are outside the X.509 framework, such as XKMS. An X.509 certificate may be used
to validate a public key that may be used to authenticate a SOAP message or to identify the public
key with SOAP message that has been encrypted.
X.509 certificates rely on the use of key pairs. A key pair consists of two distinct values,either of
which may be used to encrypt data. Once data has been encrypted with one of the keys, it can
subsequently only be decrypted using the other key. For this reason the mechanism is sometimes
referred to as asymmetric key cryptography. Once a key pair has been generated, then one of the
keys is published (made known to anyone that wants it); theother remains known only to one
person. An X.509 certificate for an entity contains (among other things) the public key for that
entity.
By presenting its certificate, as well as some data which has been encrypted with its privatekey, an
entity can therefore prove its identity (because no one other than the owner of theprivate key could
have encrypted the data). Provided the certificate owner is a trusted entity, a transaction can
proceed safe in the knowledge that no-one is masquerading as that entity. A natural way of
organising mutual authentication would be for everyone to keep a copy ofthe certificates for all the
entities that they trust: when I am presented with a certificate, I just check to see if its in my list.
585

However, this doesnt scale very well: a list of certificates for alllegitimate users might be
impractically large, as well as being difficult to keep up to date. To make this easier, each X.509
certificate contains the identity of another entity which "issued"the certificate; such an entity is
referred to as a Certificate Authority (CA). By issuing (orsigning) a certificate, a CA vouches for the
entity that owns the certificate. Assuming I trustthe CA, then by obtaining the CAs certificate I can
safely trust any certificate subsequentlypresented to me which has been signed by the CA.
So an X.509 certificate contains (among other things) the following information:
The identity of the Certificate Authority (CA) which issued the certificate
A range of dates outside which the certificate may not be used
The name of the entity that the certificate belongs to. Such names are represented as
Distinguished Names.
Entitys public key

The process for obtaining a key pair and certificate for an entity is first to create a key pair and a
Certificate Signing Request (CSR). The CSR includes (among other things) the public key and the
name of the entity. The CSR is then submitted to the CA, which will (assuming it is happy to do so)
produce a corresponding certificate, whose "issuer" field will contain the identity of the CA.
The certificate issued by the CA for the entity may be given to anyone (the certificate itself contains
no confidential information). But it can only be used to perform strong authentication by the entity
itself, since using the certificate in this way requires knowledge of the private key.
Note: The CA never sees the entitys private key (it is not contained in the CSR), so even it
cannot subsequently use the certificate in this way.
Secure Identities
Assuming you have obtained a certificate, then in order to make use of it to perform strong
authentication, you need:
The certificate itself
Your private key
Some information about what CAs you yourself are prepared to trust (because the other entity will
send you their certificate, and you will want to check that whoever issued it is on your list)
Isode software refers to this set of information as an "identity": you may have one or more
identities, each of which will be stored in a separate file. Whenever X.509 strong authentication is
performed, each entity will use an identity of its own.
Since identities include sensitive data (the private key), they are stored in an encrypted form using
a passphrase, and can only be used by someone who knows that passphrase. The passphrase itself
is used only to gain access to the identity on the local system: it is never transmitted as part of any
strong authentication operation.
Signed Operations
As part of the X.500 Directory Standard, individual directory operations (such as read, search and
modify) may be "signed". In the case of a signed operation, a cryptographically secure signature is
computed and included in both the request that is sent to the Directory, and the response which the
Directory returns. Signing a message incurs an overhead, but makes it much less likely that the
content of that message could be tampered with without the recipient realising.
586

Online Certificate Status Protocol (OSCP)

The Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining the
revocation status of an X.509 digital certificate. It is described in RFC 2560 and is on the Internet
standards track. It was created as an alternative to certificate revocation lists (CRL), specifically
addressing certain problems associated with using CRLs in a public key infrastructure (PKI).
Messages communicated via OCSP are encoded in ASN.1 and are usually communicated over HTTP.
The "request/response" nature of these messages leads to OCSP servers being termed OCSP
responders.
Compared to CRLs
Since an OCSP response contains less information than a typical CRL(certificate revocation list),
OCSP can feasibly provide more timely information regarding the revocation status of a certificate
without burdening the network. However, the greater number of requests and connection overhead
may overwhelm this benefit if the client does not cache responses.
Using OCSP, clients do not need to parse CRLs themselves, saving client-side complexity. However,
this is balanced by the practical need to maintain a cache. In practice, such considerations are of
little consequence, since most applications rely on third-party libraries for all X.509 functions.
CRLs may be seen as analogous to a credit card company's "bad customer list" an unnecessary
public exposure.
OCSP discloses to the requester that a particular network host used a particular certificate at a
particular time. OCSP does not mandate encryption, so this information also may be intercepted by
other parties.
Basic PKI implementation

Alice and Bob have public key certificates issued by Ivan, the Certificate Authority (CA).
Alice wishes to perform a transaction with Bob and sends him her public key certificate.
Bob, concerned that Alice's private key may have been compromised, creates an 'OCSP request' that
contains Alice's certificate serial number and sends it to Ivan.
Ivan's OCSP responder looks up the revocation status of Alice's certificate (using the certificate
serial number Bob informed) in his own CA database. If Alice's private key had been compromised,
this is the only trusted location at which the fact would be recorded.
Ivan's OCSP responder confirms that Alice's certificate is still OK, and returns a signed, successful
'OCSP response' to Bob.
Bob cryptographically verifies the signed response (He has Ivan's public key on-hand Ivan is a
trusted responder) and ensures that it was produced recently.
Bob completes the transaction with Alice.
Protocol details
An OCSP responder may return a signed response signifying that the certificate specified in the
request is 'good', 'revoked' or 'unknown'. If it cannot process the request, it may return an error
code.
The OCSP request format supports additional extensions. This enables extensive customization to a
particular PKI scheme.
OCSP can be resistant to replay attacks, where a signed, 'good' response is captured by a malicious
intermediary and replayed to the client at a later date after the subject certificate may have been
revoked. OCSP overcomes this by allowing a nonce to be included in the request that must be
included in the corresponding response.
587

However, the replay attack, while a possibility, is not a major threat to validation systems. This is
due to the steps it takes to actually exploit this weakness. The attacker would have to be in a
position to
capture the traffic and subsequently replay that traffic,
capture the status of a certificate whose status is about to change and
conduct a transaction requiring the status of that certificate within the time frame of the validity
of the response.
Since it is not often that a revoked certificate is unrevoked (only if it is suspended is it even possible)
a person would have to capture a good response and wait until the certificate was revoked then
replay it.
OCSP can support more than one level of CA. OCSP requests may be chained between peer
responders to query the issuing CA appropriate for the subject certificate, with responders validating
each other's responses against the root CA using their own OCSP requests.
An OCSP responder may be queried for revocation information by delegated path validation (DPV)
servers. OCSP does not, by itself, perform any DPV of supplied certificates.
The key that signs a response need not be the same key that signed the certificate. The certificate's
issuer may delegate another authority to be the OCSP responder. In this case, the responder's
certificate (the one that is used to sign the response) must be issued by the issuer of the certificate
in question, and must include a certain extension that marks it as an OCSP signing authority (more
precisely, an extended key usage extension with the OID {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) keyPurpose(3) ocspSigning(9)})
OCSP Browser Support

Internet Explorer starting with version 7 on Windows Vista (not XP) supports OCSP checking. All
versions of Firefox support OCSP checking. Firefox 3 enables OCSP checking by default.
Safari on Mac OS X supports OCSP checking. OCSPD process in Safari is frequently the cause of
Safari spinning beachballs and systemwide stalls or 'paralysis'. This may be confirmed by
monitoring CPU or real memory usage of processes in the Activity Monitor application.
Versions of Opera from 8.0[1] to the current version support OCSP checking.
Certificate Signing Request (CSR)

In public key infrastructure systems, a certificate signing request (also CSR or certification request)
is a message sent from an applicant to a certificate authority in order to apply for a digital identity
certificate. Before creating a CSR, the applicant first generates a key pair, keeping the private key
secret. The CSR contains information identifying the applicant (such as a distinguished name in the
case of an X.509 certificate), and the public key chosen by the applicant. The corresponding private
key is not included in the CSR, but is used to digitally sign the entire request. The CSR may be
accompanied by other credentials or proofs of identity required by the certificate authority, and the
certificate authority may contact the applicant for further information.
If the request is successful, the certificate authority will send back an identity certificate that has
been digitally signed with the private key of the certificate authority.
Certificate Authority
In cryptography, a certificate authority or certification authority (CA) is an independent entity that
issues digital certificates for use by other parties. It is an example of a trusted third party. Before
issuing a certificate, a certificate authority will examine the credentials of the person or organization
that has requested the certificate. When the certificate has been issued, information about it is held
on a publicly accessible repository. Users can consult the repository to check the status and validity
of any certificates receivedCAs are characteristic of many public key infrastructure (PKI) schemes.
In order that one system can be assured that a certificate received from another system is genuine,
a trusted third party that can vouch for the certificate is needed.
588

Certificate authorities issue several levels of security certificates for different purposes. For
example:
Secure e-mail
Client authentication
Server authentication
There are many commercial CAs that charge for their services. There are also several providers
issuing digital certificates to the public at no cost. Institutions and governments may have their own
CAs.
Issuing a certificate
This article may be confusing or unclear to readers. Please help clarify the article; suggestions may
be found on the talk page. (February 2009)
A CA issues digital certificates that contain a public key and the identity of the owner. The matching
private key is not similarly made available publicly, but kept secret by the end user who generated
the key pair. The certificate is also an attestation by the CA that the public key contained in the
certificate belongs to the person, organization, server or other entity noted in the certificate. A CA's
obligation in such schemes is to verify an applicant's credentials, so that users and relying parties
can trust the information in the CA's certificates. CAs use a variety of standards and tests to do so.
In essence the Certificate Authority is responsible for saying "yes" this person is who they say they
are, and we, the CA, verify that.
If the user trusts the CA and can verify the CA's signature, then he can also verify that a certain
public key does indeed belong to whomever is identified in the certificate.
Subversion of CA
If the CA can be subverted, then the security of the entire system is lost for each user for whom the
CA is attesting a link between a public key and an identity.
For example, suppose an attacker, Eve (not using the Alice and Bob convention), manages to get a
CA to issue to her a certificate that claims to represent Alice. That is, the certificate would publicly
state that it represents Alice, and might include other information about Alice. Some of the
information about Alice, such as her employer name, might be true, increasing the certificate's
credibility. Eve, however, would have the all-important private key associated with the certificate.
Eve could then use the certificate to send digitally signed email to Bob, tricking Bob into believing
that the email was from Alice. Bob might even respond with encrypted email, believing that it could
only be read by Alice, when Eve is actually able to decrypt it using the private key.
Security
The problem of assuring correctness of match between data and entity when the data are presented
to the CA (perhaps over an electronic network), and when the credentials of the person/company/
program asking for a certificate are likewise presented, is difficult. This is why commercial CAs often
use a combination of authentication techniques including leveraging government bureaus, the
payment infrastructure, third parties' databases and services, and custom heuristics. In some
enterprise systems, local forms of authentication such as Kerberos can be used to obtain a
certificate which can in turn be used by external relying parties. Notaries are required in some cases
to personally know the party whose signature is being notarized; this is a higher standard than is
reached by many CAs.
In large-scale deployments, Alice may not be familiar with Bob's certificate authority (perhaps they
each have a different CA server), so Bob's certificate may also include his CA's public key signed by
a different CA2, which is presumably recognizable by Alice. This process typically leads to a
hierarchy or mesh of CAs and CA certificates.
589

Ciphers and Cipher Suites

This section covers an introduction to Ciphers, Cipher suites in general and those specifically used by
AppDirector.
Ciphers, page 590
Cipher Suites, page 591
Cipher Suites, page 591
Cipher Suites Used by AppDirector, page 592
Ciphers
In cryptography, a cipher (or cypher) is an algorithm for performing encryption or decryption a
series of well-defined steps that can be followed as a procedure. An alternative, less common term
is encipherment. In non-technical usage, a cipher is the same thing as a code; however, the
concepts are distinct in cryptography. In classical cryptography, ciphers were distinguished from
codes. Codes operated by substituting according to a large codebook which linked a random string
of characters or numbers to a word or phrase. For example, UQJHSE could be the code for
Proceed to the following coordinates. When using a cipher the original information is known as
plaintext, and the encrypted form as ciphertext. The ciphertext message contains all the information
of the plaintext message, but is not in a format readable by a human or computer without the
proper mechanism to decrypt it; it should resemble random gibberish to those not intended to read
it.
The operation of a cipher usually depends on a piece of auxiliary information, called a key or, in
traditional NSA parlance, a cryptovariable. The encrypting procedure is varied depending on the key,
which changes the detailed operation of the algorithm. A key must be selected before using a cipher
to encrypt a message. Without knowledge of the key, it should be difficult, if not nearly impossible,
to decrypt the resulting ciphertext into readable plaintext.
Most modern ciphers can be categorized in several ways
By whether they work on blocks of symbols usually of a fixed size (block ciphers), or on a
continuous stream of symbols (stream ciphers).
By whether the same key is used for both encryption and decryption (symmetric key
algorithms), or if a different key is used for each (asymmetric key algorithms). If the algorithm
is symmetric, the key must be known to the recipient and sender and to no one else. If the
algorithm is an asymmetric one, the enciphering key is different from, but closely related to, the
deciphering key. If one key cannot be deduced from the other, the asymmetric key algorithm
has the public/private key property and one of the keys may be made public without loss of
confidentiality
Modern encryption methods can be divided by two criteria by type of key used, and by type of
input data.
Type of Key Used

These ciphers are divided into:
symmetric key algorithms (Private-key cryptography) where the same key is used for
encryption and decryption. In a symmetric key algorithm (e.g., DES and AES), the sender and
receiver must have a shared key set up in advance and kept secret from all other parties; the
sender uses this key for encryption, and the receiver uses the same key for decryption. The
Feistel cipher uses a combination of substitution and transposition techniques. Most block cipher
algorithms are based on this structure
asymmetric key algorithms (Public-key cryptography) where two different keys are
used for encryption and decryption. In an asymmetric key algorithm (e.g., RSA), there are two
separate keys: a public key is published and enables any sender to perform encryption, while a
private key is kept secret by the receiver and enables only him to perform correct decryption.
590

Input Data
Ciphers can be distinguished into two types by the type of input data:
block ciphers, which encrypt block of data of fixed size, and
stream ciphers, which encrypt continuous streams of data
Key size and vulnerability

In a pure mathematical attack (i.e., lacking any other information to help break a cipher), three
factors above all, count:
Mathematical advances that allow new attacks or weaknesses to be discovered and exploited.
Computational power available, i.e., the computing power which can be brought to bear on the
problem. It is important to note that average performance/capacity of a single computer is not
the only factor to consider. An adversary can use multiple computers at once, for instance, to
increase the speed of exhaustive search for a key (i.e., brute force attack) substantially.
Key size, i.e., the size of key used to encrypt a message. As the key size increases, so does the
complexity of exhaustive search to the point where it becomes infeasible to crack encryption
directly.
Cipher Suites
A cipher suite is a named combination of authentication, encryption, and message authentication
code (MAC) algorithms used to negotiate the security settings for a network connection using the
Transport Layer Security (TLS) or Secure Sockets Layer (SSL) network protocol.
The structure and use of the cipher suite concept is defined in the documents that define the
protocol (RFC 5246 standard for TLS version 1.2). A reference for named cipher suites is provided in
RFC 2434, the TLS Cipher Suite Registry.
When a TLS connection is established, a handshaking, known as the TLS Handshake Protocol,
occurs. Within this handshake, a client hello (ClientHello) and a server hello (ServerHello) message
is passed. (RFC 5246, p. 37) First, the client sends a cipher suite list, a list of the cipher suites that
it supports, in order of preference. Then the server replies with the cipher suite that it has selected
from the client cipher suite list. (RFC 5246, p. 40) In order to test which TLS ciphers that a server
supports an SSL/TLS Scanner may be used.
Each named cipher suite defines a key exchange algorithm, a bulk encryption algorithm, a message
authentication code (MAC) algorithm, and a pseudorandom function (PRF). (RFC 5246, p. 40)
The key exchange algorithm is used to determine if and how the client and server will authenticate
during the handshake. (RFC 5246, p. 47).
The bulk encryption algorithm is used to encrypt the message stream. It also includes the key size
and the lengths of explicit and implicit initialization vectors (cryptographic nonces). (RFC 5246, p.
17).
The message authentication code (MAC) algorithm is used to create the message digest, a
cryptographic hash of each block of the message stream. (RFC 5246, p. 17).
The pseudorandom function (PRF) is used to create the master secret, a 48-byte secret shared
between the two peers in the connection. The master secret is used as a source of entropy when
creating session keys, such as the one used to create the MAC. (RFC 5246, p. 16-17, 26).
591

Cipher Suites Used by AppDirector

The Cipher Suites parameter is used to configure SSL policies. It enables you to control which cipher
suites are allowed by AppDirector during the SSL handshake, see SSL Policies, page 195.
Complete List of the Content Of All Cipher Suites (Front-end and Back-end), page 593 shows a list of
all Cipher suites including the following categories.
RSA (Default): Cipher suite using RSA key exchange.
ALL: All cipher suites.
PCI DSS Compliance: Payment Card Industry Data Security Standard
ALL Non-Null Ciphers: All cipher suites except the NULL ciphers and ciphers offering no
authentication, which must be explicitly enabled.
SSLv3: SSL v3.0 cipher suites.
TLSv1: TLS v1.0 cipher suites
Export: Export encryption algorithms including 40 and 56 bit.
Low: Low exception cipher suites, currently using 64 or 56 bit encryption algorithms but
excluding export cipher suites.
Medium: Medium encryption cipher suites, currently using 128 bit encryption
High: High encryption cipher suites. Currently key lengths are larger than 128 bits.
RSA:RC4-128:MD5: Cipher suites using RSA key exchange, 128 bit RC4 for encryption and MD5
for MAC.
RSA:RC4-128:SHA1: Cipher suite using RSA key exchange, 128 bit RC4 for encryption and
SHA1 hash for MAC.
RSA:DES:SHA1:Cipher suite using RSA key exchange, 3DES for encryption and SHA1 hash for
MAC.
RSA:3DES:SHA1:Cipher suite using RSA key exchange, 3DES for encryption and SHA1 hash for
MAC.
RSA:AES-128:SHA1: Cipher suite using RSA key exchange, 128-bit AES for encryption and
SHA1 hash for MAC.
RSA:AES-256:SHA1: Cipher suite using RSA key exchange, 256-bit AES for encryption and
SHA1 hash for MAC.
MSIE Export56: 56 bit export version of Microsoft Internet Browser v 5.
User Defined - AppDirector supports all ciphers supported by the accepted OpenSSL format and
more information can be found in OpenSSL documentation.
592

Table 8: Complete List of the Content Of All Cipher Suites (Front-end and Back-end)
The terms used in this table are:
AESAdvanced Encryption Standard
DESData Encryption Standard
DSSDigital Signature Standard
MD5Message Digest algorithm
RC2, RC4Rivest encryption
RSARivest-Shamir-Adleman encryption
SHA-1Secure Hash algorithm
3DESDES applied three times
Cipher Suite Name
Kx key
exchange
algorithm
Au
Enc symmetric Mac digest
authentication encryption
algorithm
algorithm
algorithm
AES256-SHA
Kx=RSA
Au=RSA
Enc=AES(256)
DES-CBC3-SHA
Kx=RSA
Au=RSA
Enc=3DES(168) Mac=SHA1
AES128-SHA
Kx=RSA
Au=RSA
Enc=AES(128)
Mac=SHA1
RC4-SHA
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=SHA1
RC4-MD5
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=MD5
DES-CBC-SHA
Kx=RSA
Au=RSA
Enc=DES(56)
Mac=SHA1
NULL-SHA
Kx=RSA
Au=RSA
Enc=None
Mac=SHA1
NULL-MD5
Kx=RSA
Au=RSA
Enc=None
Mac=MD5
ADH-AES256-SHA
Kx=DH
Au=None
Enc=AES(256)
Mac=SHA1
Front End - ALL

Mac=SHA1
DHE-RSA-AES256-SHA
Kx=DH
Au=RSA
Enc=AES(256)
Mac=SHA1
DHE-DSS-AES256-SHA
Kx=DH
Au=DSS
Enc=AES(256)
Mac=SHA1
ADH-DES-CBC3-SHA
Kx=DH
Au=None
EDH-RSA-DES-CBC3-SHA
Kx=DH
Au=RSA
Enc=3DES(168) Mac=MD5
EDH-DSS-DES-CBC3-SHA
Kx=DH
Au=DSS
DHE-DSS-RC4-SHA
Kx=DH
Au=DSS
Enc=RC4(128)
ADH-AES128-SHA
Kx=DH
Au=None
Enc=AES(128)
Mac=SHA1
DHE-RSA-AES128-SHA
Kx=DH
Au=RSA
Enc=AES(128)
Mac=SHA1
DHE-DSS-AES128-SHA
Kx=DH
Au=DSS
Enc=AES(128)
Mac=SHA1
Mac=SHA1
ADH-RC4-MD5
Kx=DH
Au=None
Enc=RC4(128)
Mac=MD5
ADH-DES-CBC-SHA
Kx=DH
Au=None
Enc=DES(56)
Mac=SHA1
EDH-RSA-DES-CBC-SHA
Kx=DH
Au=RSA
Enc=DES(56)
Mac=SHA1
EDH-DSS-DES-CBC-SHA
Kx=DH
Au=DSS
Enc=DES(56)
Mac=SHA1
EXP1024-RC4-SHA
Kx=RSA(1024)
Au=RSA
Enc=RC4(56)
Mac=SHA1
export
EXP1024-DES-CBC-SHA
Kx=RSA(1024)
Au=RSA
Enc=DES(56)
Mac=SHA1
export
EXP-DES-CBC-SHA
Kx=RSA(512)
Au=RSA
Enc=DES(40)
Mac=SHA1
export
593

Cipher Suite Name
Kx key
exchange
algorithm
Au
algorithm
algorithm
algorithm
EXP-RC4-MD5
Kx=RSA(512)
Au=RSA
Enc=RC4(40)
Mac=MD5
export
EXP1024-DHE-DSS-RC4-SHA Kx=DH(1024)
Au=DSS
Enc=RC4(56)
Mac=SHA1
export
EXP1024-DHE-DSS-DESCBC-SHA
Kx=DH(1024)
Au=DSS
Enc=DES(56)
Mac=SHA1
export
EXP-ADH-DES-CBC-SHA
Kx=DH(512)
Au=None
Enc=DES(40)
Mac=SHA1
export
EXP-ADH-RC4-MD5
Kx=DH(512)
Au=None
Enc=RC4(40)
Mac=MD5
export
EXP-EDH-RSA-DES-CBC-SHA
Kx=DH(512)
Au=RSA
Enc=DES(40)
Mac=SHA1
export
EXP-EDH-DSS-DES-CBC-SHA Kx=DH(512)
Au=DSS
Enc=DES(40)
Mac=SHA1
export
Mac=SHA1
Front End - PCI DSS Compliance

AES256-SHA
Kx=RSA
Au=RSA
Enc=AES(256)
DES-CBC3-SHA
Kx=RSA
Au=RSA
AES128-SHA
Kx=RSA
Au=RSA
Enc=AES(128)
Mac=SHA1
RC4-SHA
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=SHA1
RC4-MD5
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=MD5
DHE-DSS-AES256-SHA
Kx=DH(512)
Au=DSS
Enc=AES(256)
Mac=SHA1
Kx=DH(512)
Au=RSA
Kx=DH(512)
Au=DSS
DHE-DSS-RC4-SHA
Kx=DH(512)
Au=DSS
Enc=RC4(128)
Mac=SHA1
DHE-DSS-AES128-SHA
Kx=DH(512)
Au=DSS
Enc=AES(128)
Mac=SHA1
Mac=SHA1
Front End - All Non Null Ciphers

AES256-SHA
Kx=RSA
Au=RSA
Enc=AES(256)
DES-CBC3-SHA
Kx=RSA
Au=RSA
AES128-SHA
Kx=RSA
Au=RSA
Enc=AES(128)
Mac=SHA1
RC4-SHA
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=SHA1
RC4-MD5
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=MD5
DES-CBC-SHA
Kx=RSA
Au=RSA
Enc=DES(56)
Mac=SHA1
DHE-RSA-AES256-SHA
Kx=DH
Au=RSA
Enc=AES(256)
Mac=SHA1
Mac=SHA1
DHE-DSS-AES256-SHA
Kx=DH
Au=DSS
Enc=AES(256)
Kx=DH
Au=RSA
Kx=DH
Au=DSS
DHE-DSS-RC4-SHA
Kx=DH
Au=DSS
Enc=RC4(128)
Mac=SHA1
DHE-RSA-AES128-SHA
Kx=DH
Au=RSA
Enc=AES(128)
Mac=SHA1
DHE-DSS-AES128-SHA
Kx=DH
Au=DSS
Enc=AES(128)
Mac=SHA1
594

Cipher Suite Name
Kx key
exchange
algorithm
Au
algorithm
algorithm
algorithm
EDH-RSA-DES-CBC-SHA
Kx=DH
Au=RSA
Enc=DES(56)
Mac=SHA1
EDH-DSS-DES-CBC-SHA
Kx=DH
Au=DSS
Enc=DES(56)
Mac=SHA1
EXP1024-RC4-SHA
Kx=RSA(1024)
Au=RSA
Enc=RC4(56)
Mac=SHA1
export
EXP1024-DES-CBC-SHA
Kx=RSA(1024)
Au=RSA
Enc=DES(56)
Mac=SHA1
export
EXP-DES-CBC-SHA
Kx=RSA(512
Au=RSA
Enc=DES(40)
Mac=SHA1
export
EXP-RC4-MD5
Kx=RSA(512
Au=RSA
Enc=RC4(40)
Mac=MD5
export
Au=DSS
Enc=RC4(56)
Mac=SHA1
export
Kx=DH(1024)
Au=DSS
Enc=DES(56
Mac=SHA1
export
Kx=DH(512)
Au=RSA
Enc=DES(40)
Mac=SHA1
export
Au=DSS
Enc=DES(40)
Mac=SHA1
export
Mac=SHA1
Front End - SSL v3

AES256-SHA
Kx=RSA
Au=RSA
Enc=AES(256)
DES-CBC3-SHA
Kx=RSA
Au=RSA
AES128-SHA
Kx=RSA
Au=RSA
Enc=AES(128)
Mac=SHA1
RC4-SHA
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=SHA1
RC4-MD5
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=MD5
DES-CBC-SHA
Kx=RSA
Au=RSA
Enc=DES(56)
Mac=SHA1
NULL-SHA
Kx=RSA
Au=RSA
Enc=None
Mac=SHA1
NULL-MD5
Kx=RSA
Au=RSA
Enc=None
Mac=MD5
ADH-AES256-SHA
Kx=DH
Au=None
Enc=AES(256)
Mac=SHA1
DHE-RSA-AES256-SHA
Kx=DH
Au=RSA
Enc=AES(256)
Mac=SHA1
DHE-DSS-AES256-SHA
Kx=DH
Au=DSS
Enc=AES(256)
Mac=SHA1
ADH-DES-CBC3-SHA
Kx=DH
Au=None
Kx=DH
Au=RSA
Kx=DH
Au=DSS
DHE-DSS-RC4-SHA
Kx=DH
Au=DSS
Enc=RC4(128)
Mac=SHA1
ADH-AES128-SHA
Kx=DH
Au=None
Enc=AES(128)
Mac=SHA1
DHE-RSA-AES128-SHA
Kx=DH
Au=RSA
Enc=AES(128)
Mac=SHA1
DHE-DSS-AES128-SHA
Kx=DH
Au=DSS
Enc=AES(128)
Mac=SHA1
ADH-RC4-MD5
Kx=DH
Au=None
Enc=RC4(128)
Mac=MD5
ADH-DES-CBC-SHA
Kx=DH
Au=None
Enc=DES(56)
Mac=SHA1
EDH-RSA-DES-CBC-SHA
Kx=DH
Au=RSA
Enc=DES(56)
Mac=SHA1
595

Cipher Suite Name
Kx key
exchange
algorithm
Au
algorithm
algorithm
algorithm
EDH-DSS-DES-CBC-SHA
Kx=DH
Au=DSS
Enc=DES(56)
Mac=SHA1
EXP1024-RC4-SHA
Kx=RSA(1024)
Au=RSA
Enc=RC4(56)
Mac=SHA1
export
EXP1024-DES-CBC-SHA
Kx=RSA(1024)
Au=RSA
Enc=DES(56)
Mac=SHA1
export
EXP-DES-CBC-SHA
Kx=RSA(512)
Au=RSA
Enc=DES(40)
Mac=SHA1
export
EXP-RC4-MD5
Kx=RSA(512)
Au=RSA
Enc=RC4(40)
Mac=MD5
export
EXP1024-DHE-DSS-RC4-SHA Kx=RSA(1024)
Au=DSS
Enc=RC4(56)
Mac=SHA1
export
Kx=RSA(1024)
Au=DSS
Enc=DES(56)
Mac=SHA1
export
EXP-ADH-DES-CBC-SHA
Kx=RSA(512)
Au=None
Enc=DES(40)
Mac=SHA1
export
EXP-ADH-RC4-MD5
Kx=RSA(512)
Au=None
Enc=RC4(40)
Mac=MD5
export
Kx=RSA(512)
Au=RSA
Enc=DES(40)
Mac=SHA1
export
EXP-EDH-DSS-DES-CBC-SHA Kx=RSA(512)
Au=DSS
Enc=DES(40)
Mac=SHA1
export
Mac=SHA1
Front End - TLSv1

AES256-SHA
Kx=RSA
Au=RSA
Enc=AES(256)
DES-CBC3-SHA
Kx=RSA
Au=RSA
AES128-SHA
Kx=RSA
Au=RSA
Enc=AES(128)
Mac=SHA1
RC4-SHA
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=SHA1
RC4-MD5
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=MD5
DES-CBC-SHA
Kx=RSA
Au=RSA
Enc=DES(56)
Mac=SHA1
NULL-SHA
Kx=RSA
Au=RSA
Enc=None
Mac=SHA1
NULL-MD5
Kx=RSA
Au=RSA
Enc=None
Mac=MD5
ADH-AES256-SHA
Kx=DH
Au=None
Enc=AES(256)
Mac=SHA1
DHE-RSA-AES256-SHA
Kx=DH
Au=RSA
Enc=AES(256)
Mac=SHA1
DHE-DSS-AES256-SHA
Kx=DH
Au=DSS
Enc=AES(256)
Mac=SHA1
ADH-DES-CBC3-SHA
Kx=DH
Au=None
Kx=DH
Au=RSA
Kx=DH
Au=DSS
DHE-DSS-RC4-SHA
Kx=DH
Au=DSS
Enc=RC4(128)
Mac=SHA1
ADH-AES128-SHA
Kx=DH
Au=None
Enc=AES(128)
Mac=SHA1
DHE-RSA-AES128-SHA
Kx=DH
Au=RSA
Enc=AES(128)
Mac=SHA1
DHE-DSS-AES128-SHA
Kx=DH
Au=DSS
Enc=AES(128)
Mac=SHA1
ADH-RC4-MD5
Kx=DH
Au=DSS
Enc=RC4(128)
Mac=MD5
596

Cipher Suite Name
Kx key
exchange
algorithm
Au
algorithm
algorithm
algorithm
ADH-DES-CBC-SHA
Kx=DH
Au=None
Enc=DES(56)
Mac=SHA1
EDH-RSA-DES-CBC-SHA
Kx=DH
Au=RSA
Enc=DES(56)
Mac=SHA1
EDH-DSS-DES-CBC-SHA
Kx=DH
Au=DSS
Enc=DES(56)
Mac=SHA1
EXP1024-RC4-SHA
Kx=RSA(1024)
Au=RSA
Enc=RC4(56)
Mac=SHA1
export
EXP1024-DES-CBC-SHA
Kx=RSA(1024)
Au=RSA
Enc=DES(56)
Mac=SHA1
export
EXP-DES-CBC-SHA
Kx=RSA(512)
Au=RSA
Enc=DES(40)
Mac=SHA1
export
EXP-RC4-MD5
Kx=RSA(512)
Au=RSA
Enc=RC4(40)
Mac=MD5
export
Au=DSS
Enc=RC4(56)
Mac=SHA1
export
Kx=DH(1024)
Au=DSS
Enc=DES(56)
Mac=SHA1
export
EXP-ADH-DES-CBC-SHA
Kx=DH(512)
Au=None
Enc=DES(40)
Mac=SHA1
export
EXP-ADH-RC4-MD5
Kx=DH(512)
Au=None
Enc=RC4(40)
Mac=MD5
export
Kx=DH(512)
Au=RSA
Enc=DES(40)
Mac=SHA1
export
Au=DSS
Enc=DES(40)
Mac=SHA1
export
Front End - Export
Front End - Low

DES-CBC-SHA
Kx=RSA
Au=RSA
Enc=DES(56)
Mac=SHA1
ADH-DES-CBC-SHA
Kx=DH
Au=None
Enc=DES(56)
Mac=SHA1
EDH-RSA-DES-CBC-SHA
Kx=DH
Au=RSA
Enc=DES(56)
Mac=SHA1
EDH-DSS-DES-CBC-SHA
Kx=DH
Au=DSS
Enc=DES(56)
Mac=SHA1
RC4-SHA
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=SHA1
RC4-MD5
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=MD5
DHE-DSS-RC4-SHA
Kx=DH
Au=DSS
Enc=RC4(128)
Mac=SHA1
ADH-RC4-MD5
Kx=DH
Au=None
Enc=RC4(128)
Mac=MD5
AES256-SHA
Kx=RSA
Au=RSA
Enc=AES(256)
Mac=SHA1
DES-CBC3-SHA
Kx=RSA
Au=RSA
AES128-SHA
Kx=RSA
Au=RSA
Enc=AES(128)
Mac=SHA1
ADH-AES256-SHA
Kx=DH
Au=None
Enc=AES(256)
Mac=SHA1
DHE-RSA-AES256-SHA
Kx=DH
Au=RSA
Enc=AES(256)
Mac=SHA1
Front End - Medium
Front End - High
597

Cipher Suite Name
Kx key
exchange
algorithm
Au
algorithm
algorithm
algorithm
DHE-DSS-AES256-SHA
Kx=DH
Au=DSS
Enc=AES(256)
ADH-DES-CBC3-SHA
Kx=DH
Au=None
Kx=DH
Au=RSA
Kx=DH
Au=DSS
ADH-AES128-SHA
Kx=DH
Au=None
Enc=AES(128)
Mac=SHA1
DHE-RSA-AES128-SHA
Kx=DH
Au=RSA
Enc=AES(128)
Mac=SHA1
DHE-DSS-AES128-SHA
Kx=DH
Au=DSS
Enc=AES(128)
Mac=SHA1
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=MD5
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=SHA1
Kx=RSA
Au=RSA
Enc=DES(56)
Mac=SHA1
Kx=RSA
Au=RSA
Kx=RSA
Au=RSA
Enc=AES(128)
Mac=SHA1
Kx=RSA
Au=RSA
Enc=AES(256)
Mac=SHA1
AES256-SHA
Kx=RSA
Au=RSA
Enc=AES(256)
Mac=SHA1
DES-CBC3-SHA
Kx=RSA
Au=RSA
AES128-SHA
Kx=RSA
Au=RSA
Enc=AES(128)
Mac=SHA1
RC4-SHA
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=SHA1
RC4-MD5
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=MD5
DES-CBC-SHA
Kx=RSA
Au=RSA
Enc=DES(56)
Mac=SHA1
DHE-RSA-AES256-SHA
Kx=DH
Au=RSA
Enc=AES(256)
Mac=SHA1
DHE-DSS-AES256-SHA
Kx=DH
Au=DSS
Enc=AES(256)
Mac=SHA1
Kx=DH
Au=RSA
Kx=DH
Au=DSS
DHE-RSA-AES128-SHA
Kx=DH
Au=RSA
Enc=AES(128)
Mac=SHA1
DHE-DSS-AES128-SHA
Kx=DH
Au=DSS
Enc=AES(128)
Mac=SHA1
DHE-DSS-RC4-SHA
Kx=DH
Au=DSS
Enc=RC4(128)
Mac=SHA1
EDH-RSA-DES-CBC-SHA
Kx=DH
Au=RSA
Enc=DES(56)
Mac=SHA1
EDH-DSS-DES-CBC-SHA
Kx=DH
Au=DSS
Enc=DES(56)
Mac=SHA1
EXP-DES-CBC-SHA
Kx=RSA
Au=RSA
Enc=DES(40)
Mac=SHA1
export
Mac=SHA1
RSA:RC4-128:MD5:
RC4-MD5
RSA:RC4-128:SHA1:
RC4-SHA
RSA:DES:SHA1:
DES-CBC-SHA
RSA:3DES:SHA1:
DES-CBC3-SHA
RSA:AES-128:SHA1:
AES128-SHA
RSA:AES-256:SHA1:
AES256-SHA
MSIE Export56
598

Cipher Suite Name
Kx key
exchange
algorithm
Au
algorithm
algorithm
algorithm
EXP-RC4-MD5
Kx=RSA
Au=RSA
Enc=RC4(40)
Mac=MD5
export
Kx=DH(512)
Au=RSA
Enc=DES(40)
Mac=SHA1
export
Au=DSS
Enc=DES(40)
Mac=SHA1
export
Back-End - Low
RC4-SHA
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=SHA1
RC4-MD5
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=MD5
DES-CBC-SHA
Kx=RSA
Au=RSA
Enc=DES(56)
Mac=SHA1
RC4-SHA
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=SHA1
RC4-MD5
Kx=RSA
Au=RSA
Enc=RC4(128)
Mac=MD5
AES256-SHA
Kx=RSA
Au=RSA
Enc=AES(256)
Mac=SHA1
DES-CBC3-SHA
Kx=RSA
Au=RSA
AES128-SHA
Kx=RSA
Au=RSA
Enc=AES(128)
Back End - Medium
Back End - High
Mac=SHA1
Securing a Connection - the SSL Handshake

The most computationally expensive part of an SSL session is the SSL handshake, where the SSL
server (usually an SSL webserver) and the SSL client (usually a web browser) agree on a number of
parameters that establish the security of the connection. Part of the role of the SSL handshake is to
agree on session keys (symmetric keys, used for the duration of a given session), but the encryption
and signature of the SSL handshake messages itself is done using asymmetric keys (contained in
the certificates), which requires more computational power than the symmetric cryptography used
for the encryption/decryption of the session data. Typically a hardware SSL accelerator will offload
processing of the SSL handshake while leaving the server software to process the less intense
symmetric cryptography of the actual SSL data exchange, but some accelerators act as a proxy
handling all SSL operations and leaving the server seeing only unencrypted connections.
599

AppDirector User Guide Version 2.14

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

AppDirector User Guide Version 2.14

Загружено:

Авторское право:

Доступные форматы

AppDirector User Guide

Software Version 2.14.03