Radward

AppDirector User Guide
Software Version: 1.06

Document ID: AD_01_06_UG
July 2008
2 Document ID: AD_01_06_UG
Document ID: AD_01_06_UG 3
Important Notice
This guide is delivered subject to the following conditions and restrictions:
Copyright Radware Ltd. 2006 2007. 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 AppXcel, 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 61000-3-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:
Note: Additional information
Tip: A suggestion or workaround
To A statement and instructions
Example: An example scenario
Caution: Possible damage to equipment, software, or data
Warning: Possible physical harm to the operator
IPv6 Ready Can use IPv6 (128-bit addresses) as well as IPv4 (32-bit addresses)
Table of Contents
Important Notice .............................................................................................. 3
Copyright Notices ............................................................................................ 3
Safety Instructions ........................................................................................... 5
Document Conventions ................................................................................... 8
Chapter 1 Introduction ............................................................................ 19
Introducing AppDirector ................................................................................ 19
General Introduction ............................................................................................. 19
Main AppDirector Concepts ................................................................................. 19
AppDirector Modules Overview ..................................................................... 22
Introducing AppDirector Modules ......................................................................... 23
Management Tools ............................................................................................... 25
AppDirector Licenses and Platforms ............................................................. 25
AppDirector Licenses ........................................................................................... 25
Cookies, BWM & IPS and DoS Licenses ............................................................. 26
License Support Summary ................................................................................... 26
AppDirector Platforms Supported ......................................................................... 27
Chapter 2 Getting Started with AppDirector ......................................... 29
Management Interfaces ................................................................................ 29
APSolute Insite Management Interface ................................................................ 29
Command Line Interface ...................................................................................... 30
Web Based Management ..................................................................................... 32
APSolute API Overview ........................................................................................ 33
Application Performance Monitoring .................................................................... 35
Configuring SNMP ........................................................................................ 35
SNMP Overview ................................................................................................... 35
SNMPv3 ............................................................................................................... 35
Defining SNMP Users .......................................................................................... 36
SNMP - VACM Edit Security to Group ................................................................. 37
VACM - MIB View ................................................................................................. 38
SNMP - Access .................................................................................................... 38
SNMP - Target Address ....................................................................................... 39
SNMP - Target ..................................................................................................... 40
SNMP - Community Table(SNMPv1 and SNMPv2 Only) .................................... 41
SNMP - Notify Table ............................................................................................. 42
AppDirector Device Management Options .................................................... 48
Telnet and SSH .................................................................................................... 48
Configuration Auditing .......................................................................................... 49
Trap Logging ........................................................................................................ 50
Table of Contents
AppDirector Device Security ......................................................................... 51
Bandwidth Management Access .......................................................................... 51
Users Table .......................................................................................................... 51
RADIUS Authentication ........................................................................................ 52
Ping Physical Port Permissions ............................................................................ 55
Chapter 3 Administering AppDirector ................................................... 57
Version and Configuration Management ....................................................... 57
Software Version Update ...................................................................................... 58
Configuration File Management ........................................................................... 60
Licensing and Upgrading Licenses ....................................................................... 65
Upgrading Boot Versions ...................................................................................... 68
Rebooting Devices ............................................................................................... 68
Device Tuning .............................................................................................. 68
Device Tuning Introduction ................................................................................... 68
OnDemand Switch 1 Tuning ................................................................................. 69
APM Device Parameters ...................................................................................... 71
Bandwidth Management Settings Tuning ............................................................. 73
Client Table Settings Tuning ................................................................................ 73
DNS Settings Tuning ............................................................................................ 74
NAT Settings Tuning ............................................................................................ 74
Security Tuning - Introduction ............................................................................... 74
Tuning Memory Check ......................................................................................... 76
Device Notifications ....................................................................................... 77
Notifications - General .......................................................................................... 77
Utilities ........................................................................................................... 81
DNS Client ............................................................................................................ 81
Network Time Protocol (NTP) ............................................................................... 82
Daylight Saving Time Support .............................................................................. 83
Port Settings .................................................................................................. 84
Interface Physical Configuration (Speed and Duplex) .......................................... 85
Port Mirroring ........................................................................................................ 85
Link Aggregation ................................................................................................... 86
Virtual LAN .................................................................................................... 88
Introducing Virtual LAN ......................................................................................... 88
AppDirector VLAN Types ..................................................................................... 90
Layer 2 Capability for OnDemand Switches ......................................................... 90
Bridging ............................................................................................................... 91
VLAN Configuration .............................................................................................. 91
Redundancy With VLAN ....................................................................................... 93
VLAN Tagging ............................................................................................... 93
VLAN Tagging Support ......................................................................................... 93
Rewriting VLAN Tags ........................................................................................... 94
IP Addressing ................................................................................................ 95
Table of Contents
Introduction to IP Addressing ............................................................................... 95
Setting Up Interface IP Addresses ....................................................................... 95
Routing ................................................................................................................ 95
Chapter 4 Configuring Load Balancing Policies.................................. 97
Introducing AppDirector Traffic Management ................................................ 97
Traffic Management: Load Balancing Servers ..................................................... 97
Introducing Layer 4-7 Policies ............................................................................. 97
Layer 4-7 Policies: Farm Selection Criteria ......................................................... 98
Layer 4-7 Configuration Overview ....................................................................... 98
Farm Selection Using Layer 4 Policies .......................................................... 99
Introducing Layer 4 Policies ................................................................................. 99
Setting Up Layer 4 Policies .................................................................................. 99
Layer 4 Policies Lookup Mechanism ................................................................. 102
Farm Selection Using Layer 7 Policies ........................................................ 104
Introducing Layer 7 Policies ............................................................................... 104
Layer 7 Policies Traffic Flow .............................................................................. 105
Defining Layer 7 Policies ................................................................................... 105
Persistent Layer 7 Switching ............................................................................. 109
Session ID Persistency ...................................................................................... 111
Cookie Insert / Rewrite ...................................................................................... 117
Session ID Sharing ........................................................................................... 120
Setting Up Farms ......................................................................................... 120
Server Farms ..................................................................................................... 121
Working with Farms ........................................................................................... 121
Configuring Farms ............................................................................................. 122
Dispatch Methods .............................................................................................. 129
No HTTP Service Page ..................................................................................... 134
Servers ........................................................................................................ 134
Servers Introduction ........................................................................................... 135
Farm Servers ..................................................................................................... 135
Physical Servers ................................................................................................ 140
Application Servers ............................................................................................ 142
MS Terminal Servers and Session Persistency ................................................. 144
Local Triangulation ............................................................................................ 145
Clients ......................................................................................................... 149
Client Table Management .................................................................................. 149
Sessions Modes ................................................................................................ 150
Removing an Entry from the Client Table .......................................................... 156
Client Table Global Parameters ......................................................................... 157
Types of Client Table Entries ............................................................................. 161
Client Table Filters ............................................................................................. 163
Client Table Views ............................................................................................. 164
Reset Client on Server Failure ........................................................................... 165
Close Session At Aging ..................................................................................... 166
Table of Contents
Chapter 5 Configuring Global Load Balancing .................................. 167
Global Application Switching Overview ....................................................... 167
Global IP Traffic Management ........................................................................... 167
How Global Traffic Management Works ............................................................ 168
Working with AppDirector-Global ...................................................................... 170
Proximity ...................................................................................................... 172
Proximity Introduction ........................................................................................ 172
Proximity Report Protocol (PRP) ....................................................................... 173
Static Proximity Database ................................................................................. 173
Dynamic Proximity Database ............................................................................ 174
Configuring Local Report Protocol .............................................................. 178
Load Report Protocol (LRP) .............................................................................. 178
Local LRP .......................................................................................................... 182
Redirection .................................................................................................. 182
Redirection Methods .......................................................................................... 183
DNS Redirection ................................................................................................ 183
DNS Persistency ............................................................................................... 188
HTTP Redirection .............................................................................................. 192
HTTPS Redirection ............................................................................................ 193
RTSP Redirection .............................................................................................. 194
SIP Redirection .................................................................................................. 194
Proxy Redirection .............................................................................................. 195
Global Triangulation Redirection ....................................................................... 196
VIP Advertising via Dynamic Routing .......................................................... 198
Dynamic Routing ............................................................................................... 198
Routing Information Protocol ....................................................................... 200
Introduction to Routing Information Protocol ..................................................... 201
Open Shortest Path First ............................................................................. 202
Introducing OSPF .............................................................................................. 202
Border Gateway Protocol ............................................................................ 203
Introducing Border Gateway Protocol ................................................................ 203
Spanning Tree Protocol ............................................................................... 204
Spanning Tree Protocol Introduction ................................................................. 204
Spanning Tree Ports .......................................................................................... 205
Spanning Tree Instances ................................................................................... 206
Chapter 6 AppDirector Advanced Configuration ............................... 209
Network Address Translation ...................................................................... 209
Introducing Network Address Translation .......................................................... 209
Server NAT ........................................................................................................ 209
Outbound NAT ................................................................................................... 212
Client NAT ......................................................................................................... 217
Multihoming ................................................................................................. 224
Table of Contents
What is Multihoming .......................................................................................... 224
Default Router Per Virtual IP ............................................................................. 225
Using Redirect to Self in Multi-Homed Environments ........................................ 231
Segmentation .............................................................................................. 237
Segmentation Introduction ................................................................................. 238
Supporting Segmentation with AppDirector ....................................................... 239
Layer 7 Header Modification ........................................................................ 243
Layer 7 Header Modification Overview .............................................................. 243
Defining Layer 7 Methods .................................................................................. 243
Defining Layer 7 Header Modification Rules ..................................................... 245
Layer 7 Modification Rules Automatic Configuration ......................................... 246
Session Initiation Protocol (SIP) .................................................................. 247
Introducing SIP .................................................................................................. 247
SIP Load Balancing with AppDirector ................................................................ 247
Farm Selection Based on SIP Parameters ........................................................ 247
Load Balancing SIP Servers .............................................................................. 247
Outbound SIP Sessions ..................................................................................... 248
Network Time Protocol Support ................................................................... 248
Chapter 7 Configuring Redundancy.................................................... 251
AppDirector Redundancy ............................................................................ 251
Introducing AppDirector Redundancy ................................................................ 251
Active/Backup Setup .......................................................................................... 252
Active/Active Setup ............................................................................................ 253
Interface Grouping ............................................................................................. 253
Redundancy Copy Configuration ....................................................................... 254
Selective Interface Grouping ............................................................................. 255
Stateful Failover (Mirroring) ............................................................................... 256
Advanced Redundancy ...................................................................................... 258
Physical IP Addresses vs. Virtual IP Addresses Redundancy ........................... 259
Force Port Down ................................................................................................ 260
VRRP Redundancy ..................................................................................... 260
Introducing VRRP .............................................................................................. 260
VRRP nxn Redundancy ..................................................................................... 262
Direct Server Connection with VRRP ................................................................ 263
VRRP Redundancy Copy Configuration ............................................................ 264
Automated VRRP Configuration Updates .......................................................... 269
Proprietary ARP Redundancy ..................................................................... 270
Proprietary ARP ................................................................................................. 270
Proprietary Active-Backup Redundancy Copy Configuration ............................ 271
Backup Fake ARP ............................................................................................. 274
Chapter 8 Configuring Bandwidth Management Policies and Classes 277
Bandwidth Management Introduction ......................................................... 277
Table of Contents
Introducing Bandwidth Management ................................................................. 277
Bandwidth Management Policies ................................................................ 278
What is a Bandwidth Management Policy ......................................................... 279
Bandwidth Management Classification Criteria ................................................. 279
Bandwidth Management Rules .......................................................................... 280
Classes ........................................................................................................ 282
Services ............................................................................................................. 283
Configuring Networks ........................................................................................ 285
Physical Port Groups ......................................................................................... 286
VLAN Tag Groups ............................................................................................. 286
Protocol Discovery ...................................................................................... 292
What is Protocol Discovery? .............................................................................. 292
Protocol Discovery Policies ............................................................................... 292
Interface Classification ................................................................................ 293
Port Bandwidth .................................................................................................. 293
Chapter 9 Configuring Health Monitoring........................................... 295
Health Monitoring - Introduction .................................................................. 295
Health Monitoring Module Introduction .............................................................. 295
Checked Element .............................................................................................. 295
Health Check ..................................................................................................... 296
Health Check Configuration ........................................................................ 296
Health Monitoring Configuration Guidelines ...................................................... 296
Health Monitoring Global Parameters Setup ..................................................... 296
Health Checks ................................................................................................... 297
Health Checks Per Server ................................................................................. 301
Health Checks Per Farm ................................................................................... 302
Health Check Methods ................................................................................ 302
Predefined Methods .......................................................................................... 302
User Defined Methods ....................................................................................... 313
AppDirector Farm Connectivity Checks ...................................................... 315
Introducing Farm Connectivity Checks .............................................................. 315
Ping Connectivity Method .................................................................................. 316
TCP Port Connectivity Method .......................................................................... 316
UDP Port Connectivity Method .......................................................................... 317
HTTP Page Connectivity Method ...................................................................... 318
Disabled Connectivity Method ........................................................................... 320
Chapter 10 Security............................................................................... 321
Security Overview ....................................................................................... 321
Security Introduction .......................................................................................... 321
Security Modules ............................................................................................... 322
Setting Up Security Policies in the Connect and Protect Table ......................... 324
Enabling Protection and Setting Up General Security Parameters ................... 326
Table of Contents
Defining Connectivity ......................................................................................... 329
Managing the Signatures Database ............................................................ 331
Protection Profiles and Groups .......................................................................... 331
Security Signatures File Update ........................................................................ 335
Intrusions ..................................................................................................... 339
Introduction to Intrusions ................................................................................... 339
Intrusion Prevention Using Profiles and Groups ................................................ 340
Defining Intrusion Prevention with User-Defined Settings ................................. 340
Setting Up Attacks and Filters ........................................................................... 341
Custom Attack Groups ....................................................................................... 348
Creating a New User-Defined Intrusion Prevention Profile ................................ 349
DoS/DDoS ................................................................................................... 350
Introducing DoS/DDoS ...................................................................................... 350
DoS/DDoS Protection Services ......................................................................... 350
Introduction to DoS Shield ................................................................................. 351
Setting Up DoS Shield Using Radware Profiles ................................................ 353
Defining DoS Shield with User-Defined Settings ............................................... 353
Introduction to Application Security ................................................................... 355
Setting Up Application Security for DoS/DDoS Using Profiles and Groups ....... 356
Defining Application Security Profiles with User-Defined Settings .................... 356
Behavioral DoS ........................................................................................... 359
Introduction to Behavioral DoS .......................................................................... 359
Behavioral DoS Global Parameters ................................................................... 360
Behavioral DoS Advanced Settings ................................................................... 361
Connection Limit .......................................................................................... 364
Creating Connection Limiting Policies ............................................................... 364
SYN Flood Protection .................................................................................. 366
Introduction to SYN Flood Protection ................................................................ 366
Before Setting Up SYN Flood Protection ........................................................... 367
SYN Flood Protection General Settings ............................................................ 367
Creating Custom SYN Attacks ........................................................................... 369
Configuring SYN Flood Protection Policies ....................................................... 370
SYN Flood Reporting ......................................................................................... 372
Protocol Anomalies ...................................................................................... 373
Anomalies Introduction ...................................................................................... 373
Setting Up the Anomalies Module Using Predefined Profiles ............................ 374
Defining Anomalies with User-Defined Settings ................................................ 374
Anti-Scanning .............................................................................................. 376
Introduction to Scanning .................................................................................... 376
Setting Up Anti-Scanning Using Profiles and Groups ........................................ 377
Defining Anti-Scanning with User-Defined Settings ........................................... 377
Session Table .............................................................................................. 377
Session Table and Session Table Lookup Mode .............................................. 377
Configuring the Session Table ........................................................................... 378
Table of Contents
Evasion Techniques .................................................................................... 379
Introduction to Evasion Techniques .................................................................. 379
IP Reassembly and Min IP Fragmentation ........................................................ 379
TCP Reassembly ............................................................................................... 381
Security Events and Reports ....................................................................... 382
Events and Event Reporting .............................................................................. 382
Reporting Channels ........................................................................................... 384
Security Reports ................................................................................................ 388
Dedicated Management Port ............................................................................. 389
Chapter 11 Security Monitoring and Reporting.................................. 391
Introducing Security Monitoring ................................................................... 391
Real-Time Dashboard ................................................................................. 392
Dashboard Layout ............................................................................................. 393
Viewing Top Scan Dashboard ..................................................................... 394
The Mitigation View ..................................................................................... 396
General Attack Views .................................................................................. 397
An Attack View .................................................................................................. 398
History Views and Real-Time Views .................................................................. 398
Attacks Over the Predefined Period of Time ..................................................... 398
Viewing Attack Logs .......................................................................................... 399
Viewing Attacks Graph ..................................................................................... 405
Split Attacks View .............................................................................................. 406
Viewing Attack Properties .................................................................................. 407
Filtering the Attack Views .................................................................................. 411
Viewing Attack Groups ...................................................................................... 413
Predefined Attack Views .................................................................................... 414
User Defined Attack Views ................................................................................ 414
The HTTP Views ......................................................................................... 419
HTTP Request-URL Size Distribution ............................................................... 420
Continuous HTTP Traffic Statistics .................................................................... 421
24x7 Normal HTTP Traffic Statistics ................................................................. 422
Viewing the Geographical Security Map ..................................................... 423
Traffic Monitoring View ................................................................................ 424
Security Reporting ....................................................................................... 426
Appendix A Radware Technical Glossary .......................................... 435
Alphabetic List ............................................................................................. 435
Appendix B Regular Expressions........................................................ 487
Appendix C Optimizing AppDirector with AppXcel Application Accelerator 489
Introduction to Intelligent Application Switches ........................................... 489
Table of Contents
IMS Environment ............................................................................................... 489
Introducing AppXcel .................................................................................... 489
AppXcel Overview ............................................................................................. 490
AppXcel and AppDirector Integrated Solutions ................................................. 490
AppXcel Configuration ....................................................................................... 495
Configuration Scenarios for AppDirector/AppXcel ............................................. 500
Appendix D Diagnostic Tools .............................................................. 511
Introduction ........................................................................................................ 511
Diagnostics Trace-Log ....................................................................................... 511
Traffic Capture ................................................................................................... 512
Diagnostics Tools Policies ................................................................................. 513
Diagnostics Tools File Management .................................................................. 514
System Diagnostics ........................................................................................... 514
Table of Contents
Chapter 1 Introduction
This chapter introduces AppDirector capabilities and provides a brief description of its main
characteristics. It includes the following sections:
Introducing AppDirector, page 19
AppDirector Modules Overview, page 22
Introducing AppDirector
This section provides an introduction to AppDirector and explains its main features. This section
includes the following topics:
General Introduction, page 19
Main AppDirector Concepts, page 19
General Introduction
AppDirector by Radware is an Application Delivery Controller that delivers Layer 4-7
1
local and
global switching 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. Communication may be 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.
The AppDirector Application Smart Service modules offer these capabilities:
24/7 Network Health Monitoring
Intelligent Load Balancing
Fault Management
Traffic Shaping
Complete protection from attacks, denial of service, intrusions, etc.
Main AppDirector Concepts
AppDirector performs load balancing of incoming IP traffic (including HTTP, HTTPS, FTP, TCP and
UDP). Web traffic load balancing is not limited to a specific web browser. Incoming traffic destined
for the Farm application servers contains service requests to be provided by the servers.
AppDirector forwards these requests to the appropriate servers. AppDirector is responsible for:
Redirecting the service requests to the best site.
Selecting the most available server from those providing the required service.
1. OSI Layer Model
Introduction
Forwarding the request to a local server that can provide the required service.
Ensuring that all the packets of a single service request are forwarded to the same server.
Ensuring that the user gets the appropriate response.
Servers
AppDirector manages traffic destined for the application servers, to optimize their operation. To
achieve optimization, AppDirector works with server farms. Each service provided by the physical
server is represented by a logical entity on AppDirector and each logical entity participates in a farm.
Farms
A farm is a group of servers providing the same service. Servers are grouped in farms according to
the type of service provided. You can define a farm on AppDirector for each 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 AppDirector 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.
Layer 4 Policies
Layer 4 Policies with a defined VIP are used to provide multiple services using a single point of entry
to the network and to save valuable public IP addresses. The Layer 4 Policy defines a logical entity
on AppDirector that represents a variety of services using a single public VIP. Layer 4 Policies define
how different types of traffic are handled according to the service requested and dispatched to
appropriate farms. Each new service request destined for the VIP is directed to one of the farms
providing the required service, as defined in the Layer 4 Policy. The request is forwarded to the most
appropriate server in the farm.
Farm selection is transparent to users and is based on the service that the farm provides. For more
information, see Introducing Layer 4-7 Policies, page 97. AppDirector selects a farm according to
the following considerations:
Application to which the request is sent: AppDirector operates in Layer 4 (TCP/UDP) using
the destination port of the request to select the appropriate farm; for example, different
services are provided for different applications or different client IP addresses.
Content of the request: AppDirector operates at Layer 7 using predefined policies to identify
the content of the service request and determine the appropriate farm; for example, service can
be differentiated by URL, file type, language requested, etc.
Content Based Switching
When selecting a farm, content-based switching is the ability to provide multiple services using a
single point of entry. Farm selection with the required service is actioned according to the request
content. Content-based switching is also used to guarantee that all session related traffic arrives at
the same server. To achieve this, AppDirector maintains session persistency (e.g, session identifiers
such as cookies, or any other header) to a server, based on the request content.
NAT
To save public IP addresses, AppDirector uses Network Address Translation (NAT). This is the
translation of an IP address used within one network to a different IP address known within another
network. NAT is typically used to translate private IP addresses into public IP addresses. For more
information on NAT, see AppDirector Advanced Configuration. NAT hides the Source IP address.
AppDirector uses the following NAT options:
Server NAT is used to hide server IP addresses for outbound traffic.
Client NAT is used to hide client IP addresses when sending user requests to server farms (also
known as source NAT or full NAT).
Introduction
Outbound NAT enhances server NAT by providing a more sophisticated mechanism hiding IP
addresses of internal hosts for outbound traffic (also known as Port Address Translation or PAT).
Global Solution
AppDirector provides a global traffic management solution that enables full disaster recovery, even
with site failure. Global traffic management is suitable for networks with distributed server sites.
Using global solutions, AppDirector selects the best site to provide the service, based on load
considerations, i.e, which site is the most available, and proximity considerations, i.e, which site is
closest to the user. For more information on Redirection methods, see Redirection Methods,
page 183.
Redirection is performed using the following methods:
DNS (by resolving to different VIPs)
HTTP (by issuing a 302 Redirect)
RSTP (by issuing a 302 Redirect)
Global Triangulation (by transparent redirection of any IP traffic.
Multihoming
This solution is designed for networks where AppDirector is connected to multiple Wide Area
Networks. Using Multihoming, AppDirector can simultaneously use multiple WANs for inbound
traffic. When selecting the WAN link to be used for a client, AppDirector-Global can also use
proximity information to redirect clients via an appropriate WAN. AppDirector then uses redirection
methods to redirect the session to a farm corresponding to the WAN. For more information on
Multihoming, see Multihoming, page 224.
Redundancy
AppDirectors redundancy mechanism enables you to define a backup AppDirector for each device in
case of failure. Each pair of AppDirectors can function in an Active / Backup setup or Active / Active
setup. For more on Redundancy, see Configuring Redundancy, page 1.
You can set up Redundancy between AppDirector devices using these methods:
Proprietary ARP
VRRP
Persistency
Session persistency ensures that all traffic related to a single application session reaches the same
server.
Keeping session persistency is usually based on the source address or the source address and
source port. Sometimes this may not be sufficient, for example, when the Source IP address of the
client is changed during the session, or when separate TCP connections are associated with a single
logical session and should be forwarded to the same server.
Here, AppDirector must identify the session by an application identifier, rather than by Layer 3 (IP
address) and Layer 4 (TCP/UDP ports) information. AppDirector can recognize an application level
indication of the session identifier, track these identifiers, and ensure that all sessions with the same
identifier use the same server.
Persistency Priority Scheme
When selecting servers, AppDirector considers the following persistency priority scheme:
1. Session ID
2. Source TCP Port
3. Source IP Address.
Introduction
When Session ID Persistency is defined and no Session ID information is found, server selection
depends on the predefined Dispatch method (see Dispatch Methods, page 129) and Sessions mode:
When Regular mode is configured, AppDirector forces Entry Per Session mode for TCP traffic to
the farms VIP, where the destination port requires Session ID Persistency. This implies that
server selection for such traffic is based on the Session ID, and when no Session ID is found,
server selection is based on client IP. Other traffic to the farm is reflected in the Client Table
using the Regular mode.
When Server Per Session mode is used, AppDirector selects the best available server for each
new session for which no Session ID information is found.
When Entry Per Session mode is configured, AppDirector distributes requests with no Session ID
information according to the Source IP of the request. Each new session is identified according
to the Source IP and port. Source IP-based Session Persistency is maintained by the Client Table
mechanism and the Layer 3 Client Table mechanism (see Clients, page 149).
Notes:
>> Using the Session ID Persistency mechanism for a farm implies the Remove on
Session End mode (which automatically enables Entry Per Session). Radware
recommends to configure the Server Per Session mode when multiple sessions are
using a single Source IP address.
>> Multi Packet HTTP Header and IP Fragmentation are supported when using Session ID
Persistency.
Types of Persistency Supported by AppDirector
AppDirector supports these methods for maintaining application persistency:
Client Table Layer 4 persistency based on client IP, and optionally, client port. The
persistency is determined by the Session mode defined for the farm (see Clients, page 149).
Layer 3 Client Table intended for Layer 3 persistency.
Session ID Persistency that provides a flexible mechanism to maintain persistency for IP
traffic based on text or pattern match.
DNS Persistency, page 188 intended for DNS requests.
MS Terminal Servers and Session Persistency, page 144 for Microsoft terminal servers.
The Hashing Dispatch Method (see Hashing, page 131) can be used to maintain client IP
persistency when using Layer 4 Client Table, or to maintain URL-based persistency when used
with Layer 7 Policies (see Persistent Layer 7 Switching, page 109).
RADIUS Persistency, page 53 intended for RADIUS sessions.
SIP Persistency, page 195 intended for SIP sessions.
SSL ID Tracking Persistency for Server Per Session Mode, page 154 for SSL sessions.
AppDirector Modules Overview
This section provides an overview of AppDirector modules. This section includes the following topics:
Introducing AppDirector Modules, page 23
Management Tools, page 25
Introduction
Introducing AppDirector Modules
Introduction
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
1

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, applications, and so on. 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 1.
Traffic Redirection
The Traffic Redirection module provides Layer 4 - Layer 7
2
switching capability. This module
performs server selection in a Farm, based on availability, load, and content considerations. For
more information on Traffic Redirection, see Configuring Global Load Balancing, page 167.
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. Traffic Redirection enables
you to add network elements without service interruption in a geographically dispersed and global
context .
Bandwidth Management
The Bandwidth Management module allows administrators to have full control over their available
bandwidth enabling Radware devices to classify traffic that passes through them according to
predefined criteria and enforcing a set of actions for that traffic. For more information, see
Bandwidth Management Policies, page 278.
1. OSI Layer Model
2. OSI Layer Model
Introduction
Bandwidth Management enables you to classify user traffic according to a wide array of criteria, and
then apply a user-defined action to each classified packet or session: either block traffic or shape
traffic. For example, Bandwidth Management allows you to give HTTP traffic a higher priority over
SMTP traffic, which in turn may have higher priority over FTP traffic. The module can also track the
bandwidth used by each application and limit and ensure how much each classified traffic pattern
can utilize.
Security
The Security module detects, blocks, and prevents application attacks, helping to protect against
viruses, worms, DoS, and intrusions for immediate and high capacity application security. This
module provides secure connectivity with high performance, while permitting legitimate business
related traffic to flow unhindered. For more information on Security, see Security, page 321.
Using the Security module, AppDirector performs deep packet inspection at multi-Gigabit speed,
providing security from the network layer up to the application layer. This approach includes
advanced mitigation tools, such as:
Application Security and IPS
Enhanced DoS Protection
SYN Flood Protection.
AppDirector and AppDirector-Global Versions
AppDirector helps you with local server load balancing. The device can participate in a global
solution, and send LRP/PRP reports to AppDirector Global in the network. However, it cannot
receive LRP/PRP reports, or perform global redirection based on LRP/PRP information.
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. For more about proximity, see Proximity Introduction, page 172.
AppDirector Global uses LRP and PRP as follows:
Load Report Protocol (LRP) AppDirector-Global devices communicate with each other to report
load using LRP. AppDirector-Global uses the LRP information to select the most available site to
redirect a client to. The LRP protocol utilizes UDP port 2090, this may require Firewalls in the
path to be configured to permit such traffic.
Proximity Report Protocol (PRP) AppDirector-Global devices communicate with each other using
PRP to exchange client network proximity information. AppDirector-Global then uses the PRP
information to select an optimal path (based on network hops, and minimum latency to client)
to redirect a client request. The PRP protocol utilizes UDP port 2091. This may require Firewalls
in the path to be configured to permit such traffic.
AppDirector-100
AppDirector-100 is an entry-level member of the AppDirector family limited to 30 MBps throughout,
and has the following limitations:
AppDirector-100 cannot participate in the global solution, and does not support LRP/PRP
reports.
AppDirector-100 does not support VIP Advertising via the Dynamic Routing.
Oracle Application
The Oracle Application Wizard guides the user through a step-by-step Radware configuration for the
Oracle environment.
Introduction
Using APSolute Insite, the Application Module utilizes Oracle terminology to configure AppDirector
and AppXcel. The Application Wizard is an easy configuration tool for setting Radware devices in the
Oracle environment. The Application Module can be used both for a first time configuration and for
configuration updates.
The Oracle Application Module configuration includes the following steps:
1. General: Specify the VIPs used for the farms or groups of servers, and the optional configuration
of additional SSL Acceleration and Client Network Address Translation.
2. APPHOST Servers: Specify the names of the two Application Tier server farms and their servers.
3. IDMHOST Servers: Defines the IDMHOST servers.
4. OIDHOST Servers: Specify the names and servers of the Oracle Internet Directory servers in the
Data Tier server farms.
5. SSL Servers: Specifies the names, tunnels, and management information of the AppXcel devices
used for SSL Acceleration in the Application and Identity Management Tiers.
6. Layer 4 Policy: Defines the farms or groups of servers that provide a common application on the
same port and protocol.
7. Health Monitoring: Specifies the application health check used to determine if the servers in the
Application, Data and Identity Management Tiers are operational. For each farm, the relevant
Health Check can be defined according to farm service.
8. Key and Certificates: Specifies the SSL information required by the AppXcel devices to perform
SSL acceleration.
9. Summary: Displays information about the set device configuration.
Management Tools
APSolute Insite is AppDirectors primary network management system (NMS). Using this
management tool, you can manage and monitor your Radware devices using a user- friendly GUI.
APSolute Insite helps you to configure the Intelligent Application Switching (IAS) environment by
managing the site graphically. When network elements are connected through the site map,
administrators can set parameters for related elements (e.g., Web servers and firewalls).
While APSolute Insite allows you to manage the entire network, you can also manage a single
AppDirector device using:
Web Based Management (WBM), using HTTP and/or HTTPS.
Command Line Interface (CLI), using Telnet, SSH, or Serial Console access.
AppDirector Licenses and Platforms
This section provides detailed descriptions of AppDirector licenses.
AppDirector Licenses, page 25
Cookies, BWM & IPS and DoS Licenses, page 26
License Support Summary, page 26
AppDirector Platforms Supported, page 27
AppDirector Licenses
This is a one-time license based on the device MAC address and a license ID that changes every
time a new license is inserted.
Introduction
AppDirector-100 License
AppDirector-100 can only provide local traffic load balancing. This includes DNS resolve (without
DNS persistency). AD-100 cannot participate in a distributed solution, not even by advertising
dynamic routes.
AppDirector License
A regular AppDirector license provides local traffic load balancing and can participate in a global
solution as a distributed site only.
AppDirector-Global License
To use AppDirector-Global, you need to purchase a special license.
AppDirector-Throughput License
This license is required when running OnDemand Switch platforms.
Cookies, BWM & IPS and DoS Licenses
You can add additional features by using the following optional licenses:
Cookie Persistency: This allows AppDirector to search the HTTP headers for Session ID
Persistency. Without this license, AppDirector inspects only the URI and not the HTTP headers.
BWM & IPS: This offers Bandwidth management, and application security including Intrusion
Prevention Services, protocol anomalies, evasion avoidance, etc. For more information about
BWM, see Introducing Bandwidth Management, page 277. For more information on security, see
Security Modules, page 322.
DoS: Provides Denial of Service (DoS) detection and protection capabilities along with
Behavioral DoS protection using fuzzy logic to learn new and unknown DoS attacks. For more
information on DoS detection, see Introducing DoS/DDoS, page 350. For more information on
B-DoS protection, see Behavioral DoS, page 359.
License Support Summary
This table summarizes functionality with different AppDirector licenses:
Table 1: AppDirector License Table
Functionality AppDirector - 100 AppDirector
AppDirector
Global
Server Types Supported
Regular
Local Triangulation
Local Farm
Regular
Local Triangulation
Local Farm
Regular
Local Triangulation
Local Farm
Remote Server
Local AppDirector
Distributed
AppDirector
LRP
No Send Send and Receive
PRP
No Answer PRP
queries
Answer and Initiate
PRP queries
Introduction
AppDirector Platforms Supported
Release 1.06 of AppDirector is supported on the following platforms.
Table 2: AppDirector Platform Support
For a full description of AppDirector Platforms and hardware configuration, see the Radware
Installation and Maintenance Guide.
Redirects Traffic to Other
Locations
No No Yes
Redirection Type
Supported
HTTP & RTSP for
Local Redirection
DNS, HTTP &
RTSP for Local
Redirection
DNS, HTTP & RTSP
& Global
Triangulation.
DNS Server Functionality
(DNS Resolution)
No Yes Yes
VIP Anycast
Advertisement
No Yes Yes
BWM&IPS and DoS
Functionality
No With proper license With proper license
Cookie Persistency
(Requires Special
License)
Yes* Yes* Yes*
AppDirector Platform AppDirector Product Name
Application Switch 1
AppDirector 100, 200, 202
AppDirector 1000
AppDirector 3020, 1020
AppDirector 6000
OnDemand Switch 1
AppDirector 204, 504, 1004, 2004, 4004
OnDemand Switch 2
AppDirector 1016, 2016, 4016
Introduction
Chapter 2 Getting Started with AppDirector
This chapter provides information about the AppDirector management and maintenance processes.
For information on installing and configuring AppDirector, see the Installation and Maintenance
Guide. This chapter includes the following sections:
Management Interfaces, page 29
Configuring SNMP, page 35
AppDirector Device Management Options, page 48
AppDirector Device Security, page 51
Management Interfaces
This section describes interfaces and methods for AppDirector device configuration and setting
access permissions. This section includes the following topics:
APSolute Insite Management Interface, page 29
Command Line Interface, page 30
Web Based Management, page 32
APSolute API Overview, page 33
Application Performance Monitoring, page 35
APSolute Insite Management Interface
APSolute Insite is the main management interface for Radware products. Additional management
interfaces that allow you to configure and operate Radware devices include:
Web Based Management (WBM)
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 APSolute
Insite
Web Based
Management
Command
Line I nterface
SNMP
V1, V3
+
HTTP
+
Secure Web
+
Telnet
+
Getting Started with AppDirector
Command Line Interface
Access to the Command Line Interface (CLI) requires a serial cable and a terminal emulation
application. The majority of available options are the same for all Radware devices.
You can also use CLI for debugging purposes. 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 using APSolute Insite and send it to Technical Support.
To download the Technical Support file:
1. In the main APSolute Insite window, from the Device menu select Download Technical
Support File. The Download Technical Support window appears.
SSH
+
RS-232
+
bwm Policy management and classification
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
AppDirector AppDirector parameters
manage Device management configuration
net Network configuration
ping Sends echo requests
reboot Reboot the device
redundancy Redundancy settings
security Security settings
services General networking services
statistics Device statistics configuration
system System parameters
Port APSolute
Insite
Web Based
Management
Command
Line I nterface
2. From the Select Device drop-down list, select the device for which you would like to generate
the file.
3. In the File Name text box, type the path and name of the file to contain the information, or click
Browse and locate the required file.
4. Click Receive. The status bar shows the progress of the file generation.
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
CLI Supported Capabilities
Radware's Command Line Interface can be used through console access, Telnet, or SSH. CLI
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 the 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 the CLI command telnet <IP
address>.
SSH client: To initiate a Telnet session to remote hosts. Use the CLI command ssh <IP
address>.
DNS Client: Uses configured DNS servers to query IP addresses of a host name. First enable
DNS Client. Use the command services nslookup <hostname>.
The DNS client is also configurable from APSolute Insite. Make sure to enable DNS and set DNS
servers appropriately, using the services DNS client commands. The DNS client also enables using
host names rather than IP addresses in commands such as trace-route, ping, telnet, etc.
Note: For more information, refer to the Radware CLI Reference Manual.
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.
When using WBM, on-line help is also available from the Radware corporate website. However, you
can specify a custom location for the help files.
Web access can be confined to SSL. An administrator can specify the TCP port for Web Based
Management (WBM) and the secure WBM.
To open WBM from APSolute Insite:
1. In Site Explorer or on the map, select the AppDirector device icon.
2. From the Device menu select Management Application > Web Management.
To open WBM from a browser:
From a browser window enter the IP address of the AppDirector device.
WBM is supported with the following Internet browsers:
Internet Explorer version 6 (when using Windows operating systems)
Internet Explorer version 7
Mozilla (when using Linux operating systems)
Firefox
Note: In WBM, online help is available by clicking the ? icon that appears on every screen.
To create a new SSL certificate:
1. From a browser window enter the IP address of your AppDirector. The AppDirector WBM main
window appears.
2. From the Services menu, select SSL > Certificates. The SSL Certificates window appears.
3. Click Create. The Create Self Signed Certificate window appears.
4. Set the available parameters according to your personal requirements and then click Set. Your
preferences are recorded.
Note: SSL keys and certificates are not exported with the configuration.
Web Services
Radware devices can be managed through SNMP, serial port, Telnet, SSH, HTTP (via internal web
application) and HTTPS. To provide customers with the capability to develop enhanced application
monitoring, customized application delivery network management applications and advanced
automation tools, Radware provides Web Services interface on AppDirector by introducing APSolute
API, an open standards-based SOAP (XML) API.
Integration with APSolute API allows customers a comprehensive view of AppDirector device
performance. This includes 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 AppDirector Web Services operate via HTTP or HTTPS requests, like a regular web browser. Web
Services are by default disabled on AppDirector. They can be enabled via:
CLI: manage web-services status
WBM: Services/Web/Web Services window
Insite: Via Access tab of Setup window.
Note: Web Services can only be enabled if either web or secure web management interface
is enabled on the device. Changing the Web Services status requires resetting the
device.
To enable Web Services:
1. From the main APSolute Insite window, double-click on the AppDirector device icon. The SetUp
window appears.
2. Select Access. The Access pane appears.
3. Select the Web Services check box.
4. Click OK.Your preferences are recorded.
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 Web-
services interface to all Radware application switches and appliances providing for native software
access from any external application or development tool environment.
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.
2. Ability to configure and monitor the devices via SOAP commands that mirror Radware's SNMP
MIB. Commands include:
a. For scalar MIB parameter: retrieve (get) the value and change (set) the value
b. 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).
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).
Methods are organized into groups called interfaces that contain all the methods to control and
monitor a specific device feature. Examples include:
Farms interface for farm management.
Policies interface for Bandwidth Management policies management.
A Web Service Description Language (WSDL) file is provided for each interface.
Interfaces are further organized into high-level groups called modules corresponding to specific
APSolute OS modules, generic networking and management functionality or product-specific
features. APSolute API offers the following modules:
The AppDirector module includes interfaces that control application delivery on an AppDirector
device (available on AppDirector only).
The BWM module includes interfaces that control the allocation and prioritization of traffic
bandwidth passing through the device.
The Classes module has interfaces configuring classes of traffic for APSolute OS classification
engine, e.g. VLAN-tag groups, layer 4-7 services, etc.
The CLI module includes a single interface that allows applications to issue CLI commands and
accept the ensuing response.
The Device module includes interfaces that control device-level services, e.g. configuration
management, reboot, tuning, etc. and retrieve information regarding device status, utilization
and performance statistics.
The Health Monitoring module includes interfaces to configure how the device verifies the
health-status of managed elements, and to retrieve the results of health tests (not relevant for
DefensePro).
The Management module includes interfaces that control management-access to the device
and management services such as Web-based management, Telnet and task-scheduling.
The Networking module includes interfaces controlling Layers 1-3 device behavior, e.g.
physical port settings, bridging, routing, IP interfaces, VLAN tags, etc.
The Security module includes interfaces that control IPS.
APSolute API Software Development Kit (SDK)
The APSolute API SDK 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.
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
Application Performance Monitoring
Application Performance Monitoring (APM) is a APSolute OS module and is responsible for gathering
various performance and efficiency statistics (both at the network and application level) for various
subsets of traffic that pass through the device. For more information on APM, see the latest
APSolute Insite User Guide. Currently, APM is supported only on DefensePro 4.0 and AppDirector
1.06.
Configuring SNMP
This section explains how to configure SNMP on AppDirector. Examples for SNMP versions 1, 2, and
3 are included. This section includes the following topics:
SNMP Overview, page 35
SNMPv3, page 35
Defining SNMP Users, page 36
SNMP - VACM Edit Security to Group, page 37
VACM - MIB View, page 38
SNMP - Access, page 38
SNMP - Target Address, page 39
SNMP - Target, page 40
SNMP - Community Table(SNMPv1 and SNMPv2 Only), page 41
SNMP - Notify Table, page 42
SNMP Overview
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.
Note: By default, APSolute Insite connects to AppDirector using SNMPv1.
To connect to the device using SNMPv3:
1. From the main APSolute Insite window, click 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 icon. The Connect AppDirector Device window appears.
3. Enter the Device IP Address and check the SNMPv3 checkbox. The SNMPv3 pane appears.
4. Set the following parameters according the explanations provided:
5. Click OK. APSolute Insite is connected to the device through SNMPv3.
To view the SNMP pane:
1. From the main APSolute Insite window, select Device > Device Permissions. The Device
Permissions window appears.
2. Click SNMP. The SNMP pane appears, displaying the current permissions.
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.
To define a new SNMP user:
1. From the main APSolute Insite window, select the AppDirector device want to configure.
2. From the Device menu select Device Permissions. The Device Permissions window appears.
3. Click SNMP. The SNMP pane appears.
4. Click Users. The User Based Security Model window appears.
5. Click Add. The Edit User Based Security Model window appears.
6. Set the following according to the explanations provided:
User Name
User name, up to 18 characters.
Use Authentication
Check this box to use authentication.
Authentication Protocol
Select the authentication protocol to use during the authentication
process. Possible values: MD5, SHA1.
Authentication Password
Password required for authentication.
Use Privacy
Check this box to use privacy.
Privacy Password
Enter the privacy password.
Notes:
>> Privacy is only supported in conjunction with authentication.
>> The User Name parameter is also called Security Name.
1. To create a new user with the same configuration as an existing user, select the existing user
whose configuration you want to clone.
2. Enter a user name.
3. Select the authentication protocol that you would like to use.
4. Enter the password to be used during the authentication process.
5. Enter the password required to enable privacy.
6. Click OK. A new user is created.
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.
To configure VACM Edit Security to Group:
1. From the main APSolute Insite window, select the AppDirector device icon.
3. Click SNMP.The SNMP pane appears.
4. Click Add. The VACM - Edit Security to Group window appears.
5. Set the following parameters according to the explanations provided:
Clone FromUsed
Existing user whose configuration you want to clone.
User Name
User name (up to 18 characters).
None: Clear text is used during the session.
MD5: MD5 hashing is used for authentication.
SHA: SHA encryption is used for authentication.
Password to be used during the authentication process.
User Privacy Protocol
None: The data is not encrypted.
DES: DES encryption is used.
Privacy Password
Password required to enable privacy.
1. Select the SNMP version to be associated with this group.
2. Select a relevant security name (the name as defined in the Users Table).
3. Select a name from the list of available group names.
4. Click OK. Your preferences are recorded.
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.
To set the parameters of the VACM MIB tree:
2. From the Device menu, select Device Permissions. The Device Permissions window appears.
4. Click Access. The VACM Group Access window appears.
5. Click View. The VACM MIB View window appears.
7. Click Update to apply the settings.
8. Click OK to exit the window.
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 VACM - MIB View, page 38.
Security Model
SNMP version to be associated with this group.
Possible values: SNMPv1, SNMPv2, or User Based (SNMPv3).
Security Name
Relevant security name (as defined in the Users Table).
Group Name
Name from the list of available group names.
Family ViewName
Same Family View Name can be used for multiple entries.
Family Subtree
Object ID of the MIB subtree.
Type
Specify whether the object of this entry is included or excluded in the
MIB view.
To add an entry to the SNMP Access table:
4. Click Access. The VACM - Group Access window appears.
5. Click Add. The VACM - Edit Group Access window appears.
7. Click OK to save your settings and close the window.
SNMP - Target Address
In SNMPv3, the Target Address table contains transport addresses used to generate traps. If an
entry tag list contains a SNMP Notify Table tag, this target is selected for receipt notification. For
SNMP versions 1 and 2, this table restricts the range of addresses from which SNMP requests are
accepted. If an entrys transport tag is not empty, it must be included in one or more entries in the
Target Address table.
To add a new SNMP Target Address:
1. From the main APSolute Insite window, select the AppDirector device.
4. Click Targets. The Target Address window appears.
Group Name:
Name of the group.
Security Model
Security Model values are predefined sets of permissions that can
be applied to groups. A set is defined according to the SNMP
version. By selecting this version you determine the accompanying
permissions set.
Possible values: SNMPv1, SNMPv2, or USM (SNMPv3).
Security Level
No Authentication: No authentication or privacy are required.
Auth Not Private: Authentication is required, but privacy is not
required.
Auth Private: Both authentication and privacy are required.
Default value: No Authentication.
Read ViewName
Select an item from a list of all the available views that are configured
in the VACM - MIB View window, and provide Read access to the
Object IDs specified in the selected view.
Write ViewName
in the VACM - MIB View window, and provide Write access to the
Notify ViewName
in the VACM - MIB View window, and provide Notify access to the
5. Click Add. The Edit Target Address window appears.

Tip: The SNMP Target Address window also allows you to access the SNMP Target
parameters window (see SNMP - Target, page 40).
SNMP - Target
The Target table defines parameters to be used in generating a message. Entries in this table are
referenced in the Target Address table.
To set the Target Parameters:
1. From the main APSolute Insite window, select the AppDirector device.
5. Click Parameters.The Target Parameters window appears.
6. Click Add. The Edit Target window appears.
Name:
Name of this entry.
SNMP:
SNMP version (Click checkbox)
Target Address
IP address of the management station that is used:
Provide access to the specified IP address only.
Send SNMP traps to that IP address.
Target Port
Number of the Target Port. The TCP port to be used: 161 for SNMP
Access and 162 for SNMP Traps.
Default value: 162.
Target Mask
A subnet mask of the management station.
Tag List
This must be the same tag as the Community Transport Tag in the
Community Table, or a tag from the Notify table, dependant on whether
incoming or outgoing SNMP packets are to be tagged.
Default value: v3Traps.
Parameters
Name of the entry in the parameters table to be used when sending the
SNMP Traps.
Name
Enter the name of the new parameters.
Message Processing
Model
Select the model: SNMP Ver 1, SNMP Ver 2c, or SNMP Ver 3.
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.
To add an entry to the SNMP Community table:
4. Click Community. The Community window appears.
5. Click Add, and then set the following parameters according to the explanations provided:
6. Enter a descriptive name for Community Name.
7. Enter the User name associated with the community string.
8. Click OK to save the settings and close the window.
Security Model
Select the security model as explained in Security Model,
page 39.
Possible values: SNMP Ver 1, SNMP Ver 2c, User Based
(SNMPv3).
Security Name
Type the security name of the user.
Security Level
Select the security level:
No Authentication: No authentication or privacy are required.
Auth Not Private: Authentication is required, but privacy is not
required.
Auth Private: Both authentication and privacy are required.
Index
Descriptive name for this entry.
Community Name
String for the community.
Security Name
User name associated with the community string.
Community
Transport Tag
This string specifies a target address set from which the SNMP agent
accepts SNMP requests and to which traps are sent. Target addresses
identified by this tag are defined in the Target Address table (see SNMP
- Target Address, page 39).
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 parameters
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 39). 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 set the notifications for the Target Address:
5. Click Notify. The Notify Table window appears.
6. Click Add. The Edit Notify Table appears.
8. Click Ok to apply the settings and close the window.
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).
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:
Name
Name of the entry.
Tag
This string selects one or more entries in the Target Address table. All entries in this
table whose tag list contains this tag are selected for receipt of notifications.
Type
Type of notification; for example, trap.
User Name
administrator
MD5
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.
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.
13. Click Access. The VACM Group Access window appears.
14. Click Add, then set the following parameters according to the explanations provided:
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.
17. Set the following parameters according to the values provided:
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. 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).
Privacy Protocol
DES
Privacy Password
password
Group Name
admin
Security Model
USM
Security Level
AuthPrivate
Read ViewName
iso
Write ViewName
iso
Notify ViewName
iso
Security Model
USM
Security Name
administrator
Group Name
admin
b. To associate a new user with a group, from the SNMP window, click Add and associate the
new user with a group.
c. To restrict SNMPv1 and SNMPv2 access to the device, remove the "public" community entry
from the Community window (see SNMP - Community Table(SNMPv1 and SNMPv2 Only),
page 41).
Example:Configuring Read-Only Permissions for SNMPv1 and Full Access for
SNMPv3
This example shows how to allow SNMPv1 access to the device by adding an entry in the Community
table using the configuration of the example in SNMPv3 Access to the Device with Authentication
and Privacy, page 42.
To configure Read-Only Permissions for SNMPv1 and Full Access for SNMPv3:
1. In the main APSolute Insite window, select Device > Add Radware Device > AppDirector.
The AppDirector icon appears in Site Explorer and/or on the map.
3. Enter the Device IP Address and select the SNMPv3 checkbox. The SNMPv3 pane appears.
4. In the User Name field, enter radware. When connecting using this user name, neither
authentication nor privacy is required.
7. Click SNMP. The SNMP pane appears containing the following configuration options: Targets,
Views, Users, Community, Access. These options are explained in this configuration example.
9. Click Add, and set the following parameters:
10. Click OK twice to close the Community window.
11. In the SNMP window, click Access. The VACM Group Access window appears.
12. Click Add, and set the following parameters to the explanations provided:
Index
SNMPv1 Access
Community Name
password
Security Name
administrator
Group Name
admins
Security Model
SNMPv1
Security Level
No Authentication
Read ViewName
iso
13. Click OK twice to return to the SNMP window.
14. To create a VACM entry for User Administrator and Security module SNMPv1, in the SNMP
window, click Add. The VACM Edit Security To Group window appears.
When the SNMPv1 session is initiated with the community name "password," the device associates
the user name "administrator" with the Group "admins" based on the information from the VACM
Edit Security To Group window. According to the VACM Group Access window, only Read permissions
are set for the User Administrator in SNMPv1.
Note: APSolute Insite supports only SNMPv3 and SNMPv1.
Example:Changing the Default Community Name When Using SNMPv1 and
SNMPv2
According to the default configuration of the device, the default Community Name is "public." This
example shows how to change the default Community Name from "public" to any other name.
To change Default Community Name when using SNMPv1 and SNMPv2:
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).
3. Enter the Device IP Address, use the default Device Community Name, and click OK. The device
is connected using SNMPv1.
7. To add a new entry to the Community table, in the Community window, click Add. The Edit
Community window appears.
9. Click OK, and return to the main map.
10. Right-click the AppDirector device icon, and select Connect. The Connect AppDirector Device
window appears.
11. Type the new community name, and click OK.
12. Repeat steps 4-8, this time deleting the old public entry from the Community table.
Write ViewName
None
Notify ViewName
iso
Index
descriptive text
Community Name
new_community
Security Name
public
Example:Allowing SNMPv1 and SNMPv2 Access to Predefined Management
Stations
This example shows how to restrict management access to a Radware device for SNMPv1 and
SNMPv2, allowing only predefined Network Management Stations to access the device.
To configure access to SNMPv1 and SNMPv2 by Predefined Management Stations:
1. From the main APSolute Insite window, select Device >
Add Radware Device > AppDirector. The AppDirector device 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, use the default Device Community Name, and click OK. The
device is connected using SNMPv1.
7. Select the required entry and click Edit. The Edit Community window appears.
8. In the Community Transport Tag text box, type nms and then click OK twice to return to the
main SNMP pane.
9. In the SNMP pane, click Targets. The Target Address window appears.
10. Click Notify. The Notify window appears.
11. Click Add. The Notify Table window appears.
13. Click OK, and return to the Target window.
14. Click Add to add a new entry to the table by defining the following parameters according to the
explanations provided:
Name
Enter a descriptive name.
Tag
NMS
Note: The value must be the same as the Community Transport Tag in the
Community table.
Name
A descriptive name.
Target Address
IP address of the NMS.
Target Port
161
Target Mask
Tag List
nms
Parameters
public-v1
15. Click OK to close the Target window.
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 in SNMPv3 Access to the Device with
Authentication and Privacy, page 42.
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.
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.
12. Click OK twice to return to the Target Address window.
13. Click Add, and set the following parameters according to values provided:
Name
Secure Traps
Message Processing Model
SNMP Ver 3
Security Model
User Based
Security Name
Administrator
Security Level
Auth Private
Name
Admins_NMS
Target Address
10.204.100.18
Target Port
162
Target Mask
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.
16. Using an interface other than APSolute Insite, connect to the device. The Events & Traps window
displays SNMP traps that the device sends using SNMPv3 with authentication and privacy.
AppDirector Device Management Options
This section covers trapping, logging and special management access. This section includes the
following topics:
Telnet and SSH, page 48
Configuration Auditing, page 49
Trap Logging, page 50
Telnet and SSH
Radware supports both Telnet and SSH management access. You can specify the TCP ports for
Telnet management and SSH in the Access pane of the devices SetUp window. Time-outs are added
for logging into CLI (Command Line Interface) through Telnet and SSH. After establishing a CLI
session with the device, user name and password must be inserted within 30 seconds. In case of
three incorrect logins, the terminal is locked for 10 minutes and no further logins are accepted from
that IP address. Once a login is successful, the CLI session closes after five minutes of idle time.
To configure Telnet access:
1. In the main APSolute Insite window, right-click the AppDirector device icon and select SetUp.
The SetUp window appears.
2. Click Access. The Access pane appears.
3. Set the Telnet parameters.
To configure SSH access:
1. In the APSolute Insite main window, right-click the AppDirector device icon and select SetUp.
2. Click Access. The Access pane appears.
3. Set the SSH parameters.
Notes:
>> AppDirector supports up to two simultaneous Telnet or SSH sessions.
>> Management applications can be configured to use non-standard TCP UDP ports. For
example, port 8081 can be used for HTTP even though it is not the standard HTTP
port.
Tag List
V3Traps
Parameters
Secure Traps
How to Enable Management Applications on Specific Physical Ports
You can enable management applications on specific ports, launching configuration tools including
SNMP based applications, Telnet, and WBM, but only through those physical ports you have defined.
You can also disable launching Telnet or WBM through specific ports.
To enable web management ports:
1. In the main APSolute Insite window, select the AppDirector device to be configured.
3. Click the Management Settings tab. The Management Settings pane appears, showing the
current device in the Device dropdown list.
4. From the Device drop-down list, select a device.
5. From the Management Ports drop-down list, select the management application.
6. Check the ports that you would like to enable or disable.
7. Click either Enable All or Disable All.
8. Click Apply to save your settings.
9. Repeat steps 4-8 to enable or disable specific ports for another management application.
Configuration Auditing
Configuration Auditing is the process of logging every configuration change and activity into a
special logging server. When Configuration Auditing is enabled, the device keeps a track of all
changes made to the configuration by sending a SNMP Trap and Syslog message (where enabled
and configured).
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 or APSolute Insite). 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.
How to Enable and Disable Configuration Auditing
You can enable and disable Configuration Auditing via the Services menu in Web Based
Management; using the CLI command "manage auditing status set" or via the "Global" tab (under
Device Setup Window) in APSolute Insite.
Notes:
>> Where there is no CLI equivalent to a Web Based Management or APSolute Insite
command, the device reports the parameters MIB Name.
>> You can retrieve Configuration Auditing messages via E-mail by enabling E-mail
Reporting.
Trap Logging
The trap log contains records of the SNMP traps generated by AppDirector. Each log entry contains
the following fields:
ID
Trap Severity
Trap Text
Date & Time
Trap OID
The trap log is not cleared when AppDirector is restarted. The size of the log, depends on available
memory. The default size is 1000 entries. The trap log is used in a cyclic manner with AppDirector
over-writing the oldest entry in the log when the log is full. The traps log can be cleared manually.
To configure trap logging in APSolute Insite:
1. From the main APsolute Insite window, select Options > Preferences. The Management
Preferences window appears.
2. Click Traps and SMTP. The Traps and SMTP pane appears.
4. Click Apply and OK
To configure trap logging in CLI
The manage trap-logging command allows users to configure, view and clear the trap log
parameters.
User Email Address
Email address of the APSolute Insite station.
SMTP Server Address
IP address of the SMTP email server.
Traps Automatic Save
Check this box to allow logging of SNMP traps in a dedicated
log file.
Traps Auto Save File
Complete path and file name of the log file.
AppDirector Device Security
This section describes the interfaces and methods related to AppDirector device security. All
Radware devices are equipped with a variety of security features and settings that help prevent
unauthorized access and unit tampering. In addition to the predefined security, you can use the IPS
activation key with APSolute OS to upgrade the security level for your network. This section includes
the following topics:
Bandwidth Management Access, page 51
Users Table, page 51
RADIUS Authentication, page 52
Ping Physical Port Permissions, page 55
Bandwidth Management Access
Radware devices provide a packet-filtering database, which can be configured to control access to
and through the unit, based on a variety of factors, e.g. protocol, port, and source or destination
addresses.
To access the Bandwidth Management window:
From the APSolute Insite main window, select APSolute OS > BW Management. The
Bandwidth Management window appears.
Management Ports
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 (e.g. SSH),
while denying others (e.g. 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.
To configure management ports:
2. Click Management Settings. The Management Settings pane appears.
3. From the Device drop-down list, select a device.
4. From the Management Ports drop-down list, select the management application.
5. Check the ports that you would like to enable or disable.
6. Click either Enable All or Disable All.
7. Click Apply to save your settings.
8. Repeat steps 4-8 to enable or disable specific ports for another management application.
Users Table
You can create a list of personnel authorized to access AppDirector. Users Table entries allow access
to AppDirector through any enabled access method (Web, Telnet, SSH, WBM). Up to 20 users can be
defined. When Trace Status is enabled, users can receive e-mail notifications of changes on the
device.
To set the Users Table:
2. Click Users Table. The Users Table pane appears.
3. Click Add. The Edit Device Users window appears.
5. Click OK to apply setup and exit. The new entry appears in the Users Table.
RADIUS Authentication
Radware devices provide additional security by authenticating users who access the device for
management purposes. Before a management session starts, the Radware 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. You can also use the Users Table when RADIUS
servers are not available.
To configure RADIUS authentication:
1. From the main APSolute Insite window, select Options > APSolute Insite Permissions. The
APSolute Insite Permissions window appears.
2. Click RADIUS. The RADIUS pane appears.
Device Name
Select the device name or IP (if device is not named).
User Name
Enter the user name, (up to 19 characters long).
Password
Enter the password, (up to 19 characters long).
E-mail
Enter the e-mail address of the user.
Notification
Set minimum trap severity level for user notification.
Values: None (the user receives no traps), Info, Warning, Error, Fatal (the
user receives traps with severity info or higher).
Default value: None.
Access Level
Sets users level of access to the WBM and CLI interfaces. Choose from:
Read-Write
Read-Only
None
Trace Status
Enable to notify users of configuration changes made in the device.
Values: Administrator, Operator.
Default value: Operator.
Notes:
>> RADIUS authentication is available for CLI, Telnet, SSH, WBM, and Secure WBM. It is
not available for APSolute Insite.
>> Radware devices must have access to the RADIUS server.
RADIUS Persistency
AppDirector supports server persistency for RADIUS traffic by tracking the RADIUS Identifier within
the RADIUS header and by using RADIUS attributes.
To maintain RADIUS persistency for RADIUS traffic destined to UDP ports 1812, 1813, 1645, or
1646, AppDirector uses the RADIUS Identifier, in addition to the Source IP address and port in the
Client Table. The Client Table mode must be set to Server Per Session. No additional configuration is
required.
The same mechanism is used for sessions originating from servers that are NATed using Server NAT
Traffic that originates from an AppDirector server to a remote RADIUS server if added to the Client
Table with the RADIUS Identifier value and destination IP address and port. When a reply is received
from the remote RADIUS server, AppDirector uses the RADIUS Identifier value to send the reply to
the correct AppDirector server.
Authentication
Method
Select one of the following:
Local Users Table
RADIUS
Main RADIUS IP
Address
IP address of the primary RADIUS server.
Main RADIUS Port
Access port number of primary RADIUS server.
Main RADIUS Secret
Authentication password for primary RADIUS server.
Backup RADIUS IP
Address
IP address of the backup RADIUS server.
Backup RADIUS Port
Access port number of backup RADIUS server.
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 value: 5.
RADIUS Retries
Number of connection retries to the RADIUS server, when the RADIUS
server does not respond to the first connection attempt.
Note: If the value of RADIUS Retries is exceeded, and if all
connection attempts fail (RADIUS Timeout), the backup
RADIUS server is used.
Default value: 3.
You can also configure AppDirector to maintain persistency by a specified RADIUS Attribute. This is
required to maintain persistency for RADIUS Accounting messages. You can configure the RADIUS
Attribute parameter at the farm configuration with the required RADIUS Attribute number. The
default value is 0, indicating that RADIUS persistency is based on the RADIUS Identifier only. When
using persistency based also on the RADIUS Attribute, the Dispatch Method must be set to Static
Hashing (see Hashing, page 131).
When persistency is based on the RADIUS Attribute, if a server is not available, AppDirector selects
another server and stores the RADIUS Attribute and selected server in the RADIUS Attribute Table,
to ensure persistency for further traffic of this session.
Note: To work with RADIUS, you must first enable UDP tracking.
RADIUS Persistency Configuration Guidelines
1. To maintain persistency based only on the RADIUS Identifier, set the Sessions mode to Server
Per Session (see Server Per Session, page 154). Persistency by RADIUS Identifier is
automatically used for traffic on RADIUS ports (1812, 1813, 1645, or 1646).
2. To maintain persistency based on RADIUS Attribute, set the RADIUS Attribute parameter at the
farm configuration, and make sure to use the Hashing Dispatch Method (see Hashing,
page 131). Set the RADIUS Attribute Table size as required. Optionally, also set the RADIUS
Attribute Aging Time parameter.
To configure RADIUS Attribute:
1. In the main window, select APSolute OS > Traffic Redirection. The Traffic Redirection
window appears.
2. In the Farms pane, select the farm in which you want to set RADIUS persistency and click Edit.
The Farm window appears.
3. Select Traffic Settings. The Traffic Settings pane appears.
4. In the RADIUS Attribute text box, enter the RADIUS Identifier number.
5. Click OK.
To set the RADIUS Attribute Table size:
1. In the main window, right-click the AppDirector device icon and select SetUp. The SetUp
window appears.
2. Select Global > Advanced Settings > Edit Settings. The Advanced Settings window
appears.
3. In the RADIUS Attribute Aging text box, enter the number of seconds indicating the interval
between the moment the entry becomes inactive until its removal from the RADIUS Attribute
Table. You can enter a number between 1 and 1,000,000. The default aging time is 60 seconds.
4. In the scroll down list, in the RADIUS Attribute Entries text box, enter a number between 1 and
1,000,000. The default size is 1.
RADIUS Persistency with RADIUS Proxy Support
When a RADIUS server needs to forward access/accounting requests to another RADIUS server, the
first RADIUS server acts as a RADIUS proxy that sends requests to the second RADIUS server.
To ensure that the request and reply are sent via the same RADIUS server, you can add a special
attribute to the request. The attribute value includes the proxy RADIUS server IP address in the
decimal format. When 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.
Note: Configuring of the RADIUS Proxy Support parameter overrides persistency according
to the defined RADIUS Attribute in the farm.
This behavior can be defined per farm using the RADIUS Proxy Support parameter. When this
parameter is set to 0, the capability is disabled. To enable the capability, define the RADIUS Proxy
Support value.
To configure RADIUS Proxy Attribute:
window appears.
2. In the Farms pane, select the farm in which you want to set RADIUS persistency and click Edit.
4. In the RADIUS Proxy Support text box, enter the RADIUS Proxy Support value, (decimal 0-255)
and the maximum number you can enter is 1000000000 where 0 means that the parameter is
disabled.
Ping Physical Port Permissions
AppDirector allows you to 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 define the ports to be pinged:
1. On the main toolbar, click the Panel View button ( ). An image of the AppDirector panel
appears.
2. Right-click the port you wish to ping, and select Ping Port State.
Chapter 3 Administering AppDirector
This chapter provides information about the AppDirector management and maintenance processes,
and includes the following sections:
Version and Configuration Management, page 57
Device Tuning, page 68
Device Notifications, page 77
Utilities, page 81
Port Settings, page 84
Virtual LAN, page 88
VLAN Tagging, page 93
IP Addressing, page 95
Version and Configuration Management
This section includes the following topics:
Introducing Upgrades, page 57
Software Version Update, page 58
Configuration File Management, page 60
Licensing and Upgrading Licenses, page 65
Rebooting Devices, page 68
Introducing 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:
APSolute Insite
WBM
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.
>> APSolute Insite verifies the password before reboot and upgrade.
Administering AppDirector
>> When downgrading to a software version not supporting the current device license,
the license is lost. Contact Radware for more information.
Software Version Update
To display a list of software versions loaded on the device:
In the Command Line Interface, use the command: system file-system software.
In WBM, click File > Software List.
In APSolute Insite, right-click the Device icon, select SetUp, click Device Upgrades, and click
Software List.
To change active software version:
In the Command Line Interface, use the command:
syst emf i l e- syst emconf i g act - appl set X,
where X is the application index as previously displayed.
In WBM, click File > Software List. Select the inactive version (Active Field has value False),
and change the Active parameters to True. Click Set to record your preferences. You are
prompted to reboot the device
Note: Each software version has its own configuration file
Flash Memory Management
The following table displays Flash Memory for the Application and OnDemand Switches.
Table 3: Flash Memory
Note: Do not power up or reboot Application Switch 2 or Application Switch 4 when the
compact flash card is not inserted.
Switch Internal Flash Compact Flash
AS1
2 Application Software versions Not available
AS2
Backup Application version 2 Application Software versions
AS4
AS5
ODS-1
ODS-2
Software Version Update
You can download a new software version by using either WBM or APSolute Insite. For versions
using the File System, the software file is in TAR format, while for previous versions it appears in
binary (BIN) format.
To upgrade the software version via WBM:
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 a browser window enter the IP address of your AppDirector. Web Based Management
opens.
5. From the File menu, select Software Upgrade. The Update Device Software window appears.
6. If you are upgrading or downgrading to a different major version, enter your password in the
Password field. For instructions on obtaining a password, see step 3 above.
Note: The password is case-sensitive.
7. 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-as2-1_00_01.tar is the file for version 1.00.01.
8. 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.
9. Check Enable New Version to apply the upgrade.
10. Click Set. You are prompted to reset the device.
11. In the Device menu, select Reset Device. The Reset the Device window appears.
12. Click Set to reset AppDirector.
To update the software version with APSolute Insite:
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 the main APSolute Insite window, right-click the AppDirector icon and select SetUp. The
SetUp window appears.
5. In the SetUp window, click Device Upgrades. The Device Upgrades window appears.
6. 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.
7. In the New Version text box, enter the software version number that you wrote down in step
1. Note: the software version also appears in the name of the software update file; for example,
appdirector-as2-1_00_01.tar is the file for version 1.00.01.
8. If you are upgrading or downgrading to a different major version, enter your password in the
Password field. For instructions on obtaining a password, see step 3 above.
Note: The password is case-sensitive.
9. Check Enable New Version to apply the upgrade.
Note: If Enable New Version is not checked, the device continues to run the previous
software version.
10. Click Send. The status of the upload is displayed in the Progress Status bar. You are prompted
to restart the device.
Configuration File Management
The configuration file format is based on the CLI format (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 running APSolute Insite in a binary
format. You can also perform this from WBM.
The configuration file can be received from the device in the following ways:
Displayed within the CLI (Console, Telnet, SSH) by entering: system config immediate
and then copying the output to a text editor.
Downloaded from the device using WBM, APSolute Insite 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:
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.
Commands which do not require rebooting the device. Copying and pasting a command takes
effect immediately after the paste.
The first section includes commands which require rebooting the device, and has the following
heading:
The following commands require resetting the device to take effect printed at its
beginning.
The second section includes commands which do not require rebooting the device and commands
not bound to SNMP, and has the following heading:
The following commands take effect immediately printed at its beginning.
Commands are printed within each section, in the order of implementation; e.g. 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.
!File Signature: 063390ed2ce0e9dfc98c78266a90a7e4.
Device Configuration Update
The configuration of the device can be updated in one of three 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 supported:
a. By pasting the configuration into the terminal using the command: system config paste
start.
b. Once all the data is pasted, the following command must be issued: system config paste
stop.
c. By uploading the file using WBM and selecting the option - Append Commands to
Configuration File in the Upload Configuration File to Device window.
d. By uploading the file using APSolute Insite and selecting the option - Append Commands
to Configuration File in the Upload tab of the Configuration File Upload window.
e. By performing the terminal command:
f. system config upload append.
Using the Append method it is only possible to append commands which do not require rebooting
the device for the commands to take affect.
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, the user enters system config upload append
with the following option -v. The output to the terminal displays each command and its result, i.e.
whether it succeeded or not.
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 this also supports commands that require
rebooting the device for the commands to take affect.
The flow of commands using the Append and Reboot option is as follows:
a. All commands requiring the reboot of the device are implemented first.
b. The device is rebooted.
c. 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.
c. By uploading the file using APSolute Insite and selecting the option - Append Commands
to Configuration File with Reboot in the Upload tab of the Configuration File Upload
window.
To log the command outputs in the terminal, the user enters:
system config upload append-reboot,
with the following option -v. The output to the terminal displays each command and its result, i.e.
whether it succeeded or not.
3. Replace - You can replace the complete configuration file with a new configuration file.
Performing this action requires rebooting the device. You can upload the configuration file to the
device as follows:
a. By performing the terminal command: system config upload replace.
b. 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 to
the device either a configuration file in CLI format or BER format.
c. By uploading the file using APSolute Insite and selecting the option - Replace
Configuration File in the Upload tab of the Configuration File Upload window.
Figure 1: Configuration File Upload Window
Note: System config upload replace does not support configuration from previous versions.
When using this option, you can upload to the device either a configuration file in CLI format or BER
format for backward compatibility.
Automatic Rollback to Last Known Good Configuration
The device also supports an automatic rollback to last good known configuration (in case of 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 File Conversion
Devices support the receipt of configuration files in both BER and CLI format. However, configuration
files are downloaded only in CLI format. You can convert from BER format to CLI format and vice
versa using APSolute Insite.
Configuration Management Log File
The Configuration Management log file logs every error printout which occurs when uploading text
files. Errors occurring during the upload of BER files are not logged.
The log file is accessed via the following management options:
1. Console - The following command is used to view the Configuration Management logfile:
system config logfile <get/reset>.
2. APSolute Insite - The log file can be downloaded from a tab called Log File, which is part of
the Configuration File window. The information within the log window is automatically read from
the device.
The following operation can be performed via the Log File view:
Download the log file - Select a file name and click Apply to initiate the download of the file
from the device.
3. WBM - The log file is managed via the following menus:
a. The user can clear the file via the following menu:
File > Configuration > Log File > Clear.
b. The user can download the file via the following menu:
File > Configuration > Log File > Download.
c. The user can display the file via the following menu:
File > Configuration > Log File > Show.
Each event is also sent via Email, Syslog, SNMP traps and console trap.
Saving and Restoring Configuration Files
This section discusses the saving and restoring of Configuration Files.
To download the configuration file from the device:
1. From the main APSolute Insite window, select Device > Configuration File. The Configuration
File window appears.
2. In the Download pane, click Browse and navigate to the file to save.
3. Click Apply. The configuration file is saved.
Note: For previous versions of AppDirector: The downloaded configuration file appears
in BER format. If you wish to view the BER format file, you must convert to ASCII
format.
To upload a configuration file to the device:
1. From the APSolute Insite main window, select Device > Configuration File. The Configuration
2. Click Upload. The Upload pane appears.
3. In the Upload Mode field, specify how the file is to be restored:
4. If the file that you want to upload is located on your network, click Browse and locate the file.
5. If the file that you want to upload is located on an external TFTP server, select External TFTP
Server IP Address and enter the server's IP address in the adjacent field.
6. In the File Name field, enter the full path to the file on the TFTP server.
7. Select the required configuration file and click Apply. The selected configuration is sent to the
device.
8. Click Close to close the Configuration File window.
9. Reboot the device.
Append Commands to
Configuration File
Used when a new configuration file is a text file containing CLI
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 to
Configuration File with
Reboot
Similar to above except that the device is rebooted after the
commands have been appended to the configuration file.
Replace Configuration File
Existing configuration file is replaced by the uploaded one, and
the device is rebooted.
To convert a BER file to ASCII format:
2. Select Edit. The Edit pane appears.
3. Select from the following parameters:
4. Select Convert From: BER to ASCII.
5. Click Browse and navigate to the BER file you want to convert to ASCII.
6. Select the required configuration file and click OK. You are returned to the Edit pane.
7. Click Apply. The file format is converted to ASCII.
To convert an ASCII file to BER format:
4. Select Convert From: ASCII to BER.
5. Click Browse and navigate to the ASCII file you want to convert to BER.
6. Select the required configuration file and click OK. You are returned to the Edit pane.
7. Click Apply. The file format is converted to ASCII.
Select Device
Confirm the device IP selected.
Device Type
Click on the radio button and choose a device.
Device Version
Pre-1.06 Versions available include:
1.00
1.01
1.02 and 1.03.04
Select Device
Confirm the device IP selected.
Device Type
Device Version
Pre-1.06 Versions available include:
1.00
1.01
1.02 and 1.03.04
To edit an ASCII file:
3. Select ASCII Formatted File Name window.
4. Click Browse and navigate to the ASCII file that you want to edit.
5. Select the required configuration file and click Open. Next, click Edit ASCII File and the file
opens on the desktop.
6. Edit the open configuration file as appropriate. To save, select File >Save or to Save As, select
File>Save As from the top menu.
7. Click Close to close the open configuration file. You are returned to the Edit pane.
8. Click Apply to apply your changes.
To upgrade your configuration:
2. Select Upgrade Configuration. The Upgrade Configuration pane appears.
4. Once you have selected the source and destination files for the upgrade, click Apply. The
configuration file is upgraded.
Licensing and Upgrading Licenses
You can upgrade the software capabilities of AppDirector via the licensing procedure; for example,
adding BWM and IPS 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. For example, if a license that
included the BWM and IPS activation key was given to you on a trial basis but not purchased,
Radware provides you with another license, but without the BWM and IPS activation key. 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.
Device Type
Configuration Upgrade
Indicates upgrade from one version to next.
BER Source File
Click Browse, select the required configuration file and click Open.
BER Destination File
Click Browse, select the required configuration file and click Open.
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.
To upgrade a software license:
1. From the main APSolute Insite window, right-click the AppDirector device icon and select
SetUp. The SetUp window appears.
2. Click Device Upgrades. The Device Upgrades window appears.
3. Click License Upgrade. The Licence Upgrade pane appears.
4. In the New License Key text box, enter your new license code.
Note: The license code is case-sensitive.
5. Click OK. You are prompted to reset the device.
6. Click OK to perform the reset.
Upgrading Hardware Licenses
To upgrade a hardware license:
2. Click Device Upgrades. The Device Upgrades window appears.
3. Click Hardware Licence. The Licence Upgrade pane appears, displaying the current license in
the New Licence Code text box.
4. Type your new license code.
Note: The license code is case sensitive.
5. Click OK. You are prompted to reset the device to validate the license.
6. Click OK to perform the reset.
Upgrading Throughput Licenses
An OnDemand Switch platform must always have a throughput license. If this license is missing
("virgin" device out of production line or hardware failure) the default throughput license will be:
For ODS-1: 200Mbps
For ODS-2: 2Gbps
The following values will be available for throughput license on On Demand Switch platforms:
AD Product Names License String ODS 1 ODS 2
AD204
200 Mbps x
AD504
500 Mbps x
To Add/Upgrade a Throughput License
1. From the main window, double-click the device. The Setup window appears.
2. Click Device Upgrades. The Device Upgrades dialog box appears.
3. Click the Throughput License tab. The Throughput License pane appears displaying the
current license in the New Licence Key text box.
4. Type your new license key.
5. The license code is case sensitive.
6. Click OK. The Information box prompts you to reset the device in order to validate the license.
7. Click OK 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.
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.
AD1004/AD1016
1 Gbps x x
AD2004/AD2016
2 Gbps x x
AD4004/AD4016
4 Gbps x x
Upgrading Licenses Using WBM
The following procedure enables you to upgrade your license using WBM.
To upgrade a license using WBM:
1. From the Device menu, select License Upgrade. The License Upgrade window appears.
2. In the Insert Your License Code text box, type the code of the new license, and then click Set.
Upgrading Boot Versions
As Radware's product line develops, it will be necessary to upgrade a device's Boot Code to support
new software.
Rebooting Devices
You can reboot the device at any given time.
To reset an AppDirector device:
1. In the main APSolute Insite window, select the AppDirector device icon.
2. From the Device menu select Reboot.
Device Tuning
This section describes the interfaces and methods for AppDirector device tuning. This section
Device Tuning Introduction, page 68
OnDemand Switch 1 Tuning, page 69
APM Device Parameters, page 71
Bandwidth Management Settings Tuning, page 73
Client Table Settings Tuning, page 73
DNS Settings Tuning, page 74
NAT Settings Tuning, page 74
Security Tuning - Introduction, page 74
Tuning Memory Check, page 76
Device Tuning Introduction
You can determine the maximum number of entries allowed in the various tables in the following
Device Tuning Table tabs:
AppDirector
BWM
Security Settings
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.
To edit the device tuning settings in APSolute Insite:
1. Right-click the AppDirector device icon and select SetUp. The SetUp window appears.
2. Click Global. The Global pane appears.
3. Select a settings group and click Edit Settings. The parameters window for the selected
settings group appears, with the Tuning Settings table at the bottom of the window.
Note: Device tuning should only be carried out after consulting Radware Technical Support.
OnDemand Switch 1 Tuning
Radwares new OnDemand Switch 1 Tuning parameters are described here:
Bridge Forwarding Table
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
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
Contains Destination MAC Address per Destination IP.
Routing Table
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
Defines the relationship between host names and Layer 4 Policy
entry. For more information, see Configuring Load Balancing
Policies, page 97.
Request Table
Contains Layer 7 information saved during delayed binding.
Client NAT Addresses
Specifies the 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 of the configured Client
NAT Address Ranges when performing Client NAT for
servers in this farm.
Client NAT Ports Per
Address
Specifies number of ports used with each IP address.
Note: Before enabling Client NAT this parameter must be set
to a value higher than zero.
Proximity Subnets
Defines limit on the number of Proximity subnets.
Session IDs
Using Session ID Persistency, a server's reply contains a
Session ID. This is saved in this table.
RADIUS Attribute Table
Stores the RADIUS Attribute and server, to ensure persistency
for traffic sessions.
Network Segments
Segments supported when device uses segmentation.
L4 Policies
Maximum number of L4 policies defined on device.
Session Resets Table
Current amount of sessions that the device tracks to send
RESET in case "Send Rest To Server" is enabled in the Session
Table.
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:
Note:
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.
APM Device Parameters
Application Performance Monitoring (APM) is an APSolute OS module running on Insite ManagePro
(with added APM license). This is currently configured to run on AppDirector and DefensePro
devices. APM is responsible for gathering various performance and efficiency statistics (both at
network and application level) for various subsets of traffic that passes through the device. Each
APM module of each device is configured by, and reports its information to, a central management
station which processes the raw reported data and presents it as defined in the product
specification. For further information, see the latest APSolute Insite User Guide chapter on APM.
APM Tuning Parameters
The APM module has specific tuning parameters relevant in the device that sets up priority, memory
usage and other tuning options relevant in the device. When the device is shipped, default values
apply, yet you can tune these values according to your specific equipment.
Table 4: APM Tuning Parameter Settings
NHRs
A Next Hop Router (NHR) is a network element used for
outbound traffic in AppDirector/WSD/LinkProof 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.
Number of APMPolicies:
Maximum number of policies allowed.E.g., if there are two logical
monitors, one with HTTP and HTTPS and the other with HTTP and
SMTP =4 policies.
Farms Per APMPolicy:
Maximum average of farms per policy. Since all the policies of a logical
monitor have the same farms, then this is in effect the maximum
average of farms per logical monitor. Maximum average in this case
means total number of farms cannot exceed {<number of
policies>*<Farms per Policy>}.
Note: The number of Farms per single Policy can exceed this
limitation.
FarmElements Per Farm:
Maximum average of Farm Elements (Servers) per Farm. The term
maximum average in this case means that the total number of Farm
Elements cant exceed {<number of Policies>*<Farms per
Policy>*<Farm Elements per Farm>}
Note: The number of Farm Elements per Farm can exceed this
limitation.
Leg Farms Per APM
Policy:
Maximum average of leg farms per policy. Similar to Farms Per Policy,
just for Leg farms (this is not used in AppDirector or DefensePro).
Number of APMAlerts:
View and set number of Alerts per Policy.
APM Device Global Parameters
The APM module has specific tuning parameters relevant to the device. They help to set up priority,
memory usage and other tuning options. When the device is shipped, default values apply, yet you
still have the ability to tune these values according to your specific equipment. The configuration of
the specific device is done via the APM Settings window
To view/ edit APM Settings
1. Click on the Configuration Mode tab at the bottom of the APM main window. You are now in
Configuration mode.
2. Select the device whose APM settings you wish to view/edit.
3. Either double-click on the device or right-click and select Setup > Global. The Setup Global
Parameters window appears.
4. Select APM Settings. A list of current APM Settings is displayed.
5. To edit these settings, click Edit Settings. The APM Settings window appears.
6. Set the parameters according to the explanations provided below.
7. Click OK to save, or Apply for immediate effect.
Number Of APM
Sessions:
Maximum number of concurrent sessions handled by APM.
Policies Per Session:
Maximum average number of policies for which a single session is
classified.
Sampling
Algorithm:
The two sampling algorithms supported are:
Deterministic - ensures that if there are several Radware devices along a
path, and they are all configured with the same sampling rate and precise
sampling, they will sample the same sessions. This is because sampling is
performed according to information in the packet. Use Deterministic when
more than one device is used within the path
nonDeterministic - does not guarantee the same sampling rate but if the
sampling rate is, 5%, then for every 20 consecutive sessions, exactly 1 will
be sampled. Setting the Sampling Algorithm to Non Deterministic does not
guarantee that the same sessions are sampled on all devices, but all
devices sample traffic according to the Sampling Rate.
Sampling Rate:
This defines the percentage of traffic matched by the APM policy to be
sampled. The default sampling rate is 5% of traffic matched by the APM
policy.
Precise Sampling:
True - classification is done before sampling.
False - sampling is done before classification. Precise Sampling =False
means that sampling is done before classification. For example, if the
Sampling Rate is 5% and the APM monitor monitors HTTP traffic only,
Precise Sampling =False causes 95% of all traffic to be ignored
(regardless of whether or not it is HTTP). And among the 5% that is left,
the HTTP traffic is sampled. This means that the amount of HTTP traffic
that is sampled may not be precisely 5% of the HTTP traffic
Note: This sampling method is more efficient because it eliminates the
need to perform classification for 95% of the traffic.
Max Entries In:
See APM Tuning Parameters, page 71
Bandwidth Management Settings Tuning
You can tune the Bandwidth Management Settings tables according to your needs. This table shows
descriptions of the Bandwidth Management tables and provides their tuning parameters.
Table 5: Bandwidth Management Settings Tuning.
Client Table Settings Tuning
You can tune the Client Table Settings according to your needs. The following table shows
descriptions of the Client Tables and their tuning parameters.
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.
BWPer 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.
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.
NAT Settings Tuning
You can tune the NAT Settings according to your needs. The following table presents descriptions of
the NAT Settings Tables and provides their tuning parameters.
Security Tuning - Introduction
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.
Table 6: Client Table Settings Tuning Parameters
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.
Table 7: DNS Settings Tuning Parameters
Static DNS Table
Maximum number of DNS entries used in static DNS Persistency. See
Static DNS Persistency, page 191).
Dynamic DNS Table
Maximum number of DNS entries used in dynamic DNS Persistency. See
DNS Persistency, page 188.
Table 8: NAT Settings Tuning Parameters
NAT Ports Table
Specifies number of ports used with each IP address.
Note: 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
Defines number of IP addresses to be used by Outbound NAT.
Note: Before enabling Outbound NAT, this parameter must be set
Outbound NAT Ports per
Address
Defines number of ports used with each NAT IP address.
Outbound NAT Intercept
Addresses
Defines number of IP ranges intercepted and NATed by Outbound
NAT.
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.
Security Settings Tuning
You can tune the Security tables according to your needs. Descriptions of the Security tables and
their tuning parameters are shown here.
Session Table Tuning
This shows Session Table tuning parameters.
Table 9: Security Tuning Parameters
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.
IP Reas-sembly 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.
SYN Table Tuning
SYN tables are used to define the SYN Flood protection. This shows SYN Flood protection tuning
parameters.
Tuning Memory Check
The Device Tuning table enables you to pre-check whether the configured values will cause memory
allocation problems. For every value you update in an AppDirector table, the device can check
whether sufficient memory is available. This is done automatically when you update tuning values in
APSolute Insite. However, following the tuning changes, you can perform a manual check using WBM
or CLI.
In WBM, select:
Services > Tuning > Memory Check.
In CLI, use the command:
system tune test-after-reset-values.
Table 10: Session Table Tuning
Session Table Size
Keeps track of sessions.
Session Passive Protocol
Records passive protocol port commands, so that all related
sessions can be linked together.
Table 11: SYN Table Tuning
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.
SYN Protection Requests
Table
Stores the ACK or data packet that the client sends, until the
handshake with the server is complete and the packet is sent to the
server. The Requests table and the Syn Protection table must be
about the same size. The Triggers table is smaller.
SYN Protection Triggers
Table
Stores the active triggers - the Destination IPs/ports from which
device identifies ongoing attack.
SYN Protection Policies Table
Stores policies that control the SYN protection behavior for different
types of traffic. For each traffic type, the user can configure whether
to:
always apply SYN protection.
apply SYN protection only when an attack is detected.
never apply SYN protection.
SYN ACK Reflection IPs Table
Number of SYN packets per second that are sampled and their
Source IPs monitored.
SYN Flood Statistics Entries
Number of entries that appear in the Syn Flood Statistics table.
Device Notifications
This section describes the AppDirector Notifications feature which distributes warning messages
about failures and problems in network elements. This section includes the following topics:
Notifications - General, page 77
E-mail Notification, page 77
Threshold Warnings and Statistics, page 78
Notifications - General
To help minimize the impact of failure in devices such as firewalls, routers or application servers, all
Radware devices provide a choice of notification methods, including CLI Traps, Syslog, and E-mail.
To send traps by CLI, Telnet, and SSH, the command is:
manage terminal traps-outputs set-on.
For console only:
manage terminal traps-outputs set normal.
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 WARNI NG Next HopRout er 10. 10. 10. 10
I s Not Respondi ng t o Pi ng.
Send Traps To All CLI Users
This option enables you to configure whether traps are sent only to the serial terminal or also to SSH
and Telnet clients.
Syslog
Event traps can also be mirrored to a Syslog server. On AppDirector, as on all Radware products, you
can configure the appropriate information, using the General > Preferences > Traps and SMTP
option. Any traps generated by the Radware device are mirrored to the specified Syslog server.
The Syslog server enables you to define the status and the event log server address. You can also
define additional notification criteria such as Facility and Severity, which are expressed by numerical
values. Facility indicates the senders type of device, while Severity indicates the importance or
impact of the reported event. The user-defined Facility value is used when the device sends Syslog
messages. The default value is 21, that is Local Use 6." The Severity value is determined
dynamically for each message that is sent.
E-mail Notification
You can configure the device to send e-mail messages to users listed in the device's Users Table. For
each user, you can set the level of SNMP Traps notification the user receives in the Users Table. Each
user is assigned a level of severity and receives traps according to that severity or higher.
The severity levels are: Info, Warning, Error, and Fatal. When assigned the severity level of Error,
the user receives e-mail traps of events with severity levels of Error and Fatal. This configuration
applies both for SNMP traps and for SMTP e-mail notifications. SMTP notifications are enabled
globally.
The device has another method of notification. Using the Send E-mail on Errors option, you can
configure traps to be sent by e-mail to predefined users with different levels of severity.
To access E-mail notifications
From the main menu, select General > Preferences > Traps and SMTP.
Configuration Trace
AppDirector can monitor any configuration changes on the device, and report those changes by
sending out e-mail notifications. Every time the value of a configuration variable changes,
information about all the variables in the same MIB entry is reported to users. Configuration reports
are enabled for each user in the Users Table.
The notification message contains the following 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.
Configurable SMTP To Field
When AppDirector sends e-mail messages to inform about events, it sends static text in the To field.
The user can configure a static string to be used for the To field in SMTP by setting the To Field Text
parameters. When the To Field Text parameters is set to an empty string, the text in the To field is
generated by the device according to the message severity.
To set the SMTP To Field Text parameters in APSolute Insite:
1. From the main APsolute Insite window, select Device > Traps and SMTP. The Traps and SMTP
window appears.
2. In the To Field Text field, enter the recipient e-mail address for event notification messages.
To set the SMTP To Field Text parameters in Web Based Management:
1. From the Services menu, select E-mail Reporting. The E-mail Reporting window appears.
2. In the To Field Text field, enter the recipient email address for event notification messages.
3. Click Set. Your preferences are recorded.
To set the SMTP To Field Text parameters in CLI:
Use the command manage emai l - t r aps t o- f i el d- t ext .
Threshold Warnings and Statistics
To optimize AppDirector configuration and resource utilization, AppDirector continuously monitors
the resource usage, and notifies the user when usage thresholds are exceeded.
AppDirector keeps the following statistics:
1. For the tables: Client Table, Dynamic Session ID Table and Request Table, AppDirector keeps the
following statistics:
a. The current number of entries
b. The average value for the last 5 seconds
c. The average value for the last 60 seconds
2. For Client NAT ports: AppDirector keeps the average for the last 30 seconds per Client NAT
address.
3. For Outbound NAT ports: AppDirector keeps the average for the last 30 seconds per Outbound
NAT address.
4. Server connection limit for application servers: AppDirector keeps the average for the last 30
seconds per application server.
5. Server connection limit for physical servers: AppDirector keeps the average for the last 30
seconds per physical server.
6. Farm capacity threshold: AppDirector keeps the average for the last 30 seconds per farm.
The value of the parameters tracked for threshold warning can be viewed via statistics in Insite.
Threshold warnings are available for the following tables:
Client Table
Dynamic Session ID Table
L3 Client Table
Request Table
Farm Capacity
Client NAT port number per address
Outbound NAT port number per address
Server connection limit for application and physical servers
To define Threshold Warnings:
3. Select Threshold Warnings > Edit Settings. The Threshold Settings window appears.
Send Threshold Warnings
(checkbox):
Enables or disables the threshold warning traps feature.
The default value is Enable.
Min Time Between Warnings
(sec):
Minimum time, in seconds, between consecutive warnings sent
about the same resource. The default value is 60. Value of 0
means traps are sent continuously.
Client Table Threshold
Level:
Percentage of Client Table usage above which a trap is sent.
The default value is 85.
Application Servers
Connection Limit Threshold
Level:
Percentage of Application Servers Connection Limit usage
above which a trap is sent. Default value 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.
Physical Servers
Connection Limit Threshold
Level:
Percentage of Physical Servers Connection Limit usage above
which a trap is sent. Default value 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.
FarmCapacity Threshold
Level:
Percentage of farm capacity used above which a trap is sent.
The default value is 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 value is 85. When 85% of Client NAT ports for any
Client NAT address are used, a trap is sent.
Outbound NAT Threshold
Level:
Percentage of Outbound NAT ports usage above which a trap is
sent. Default value is 85. When 85% of Outbound NAT ports for
any Client NAT address are used, a trap is sent.
Session ID Threshold Level:
Percentage of the Session ID table usage above which a trap is
sent. Default value is 85. When 85% of the Session ID table is
used, a trap is sent.
Requests Threshold Level:
Percentage of the Request table usage above which a trap is
sent. Default value is 85. When 85% of the Request table is
used, a trap is sent.
L3 Client Table Threshold
Level:
Defines percentage of L3 Client Table usage. When the number
of rows in this table goes beyond the predefined threshold, 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 value is 85.
CPU Utilization Threshold
Level:
When a device reaches high CPU utilization this can be caused
by high traffic volume, bugs, endless loops, etc. Devices should
actively notify their status, if this status is suspected to be a non-
valid status. This will increase the availability.
For example, you can send a trap, if a 30 sec. average CPU
utilization in the device is higher than a specified threshold and
another trap could be sent if the device had 30 seconds of CPU
utilization lower than the specified threshold.
Sending the Trap
Every 30 seconds the device will calculate a 30 seconds
average and check if it is higher than the specified threshold. If
so, the device will send a trap and set a flag indicating that a
Trap was sent. If the flag is set, the trap will not be sent again.
The flag will be cleared and another trap will be sent when all
last measures (6 measures indicating 30 seconds) are lower
than the threshold.
Utilities
This section describes additional device-related AppDirector utilities. This section includes the
following topics:
DNS Client, page 81
Network Time Protocol (NTP), page 82
Daylight Saving Time Support, page 83
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.
To display the DNS Table:
1. From the main APSolute Insite window, select APSolute OS > Traffic Redirection. The Traffic
Redirection window appears.
2. Click DNS. The DNS pane appears.
3. To enable the DNS client, check Client DNS.
4. In the DNS Primary Address text box, enter the address of the primary DNS server that is used
to query IP addresses of host names.
The traps text states:
30 seconds average of Device CPU Utilization has
exceeded a threshold of <threshold>%
30 seconds average of Device CPU Utilization has returned
to a value below threshold <threshold>%
User Configuration
This threshold can be configured using a CLI command, or
WBM or SNMP. When you change the threshold level, the trap
mechanism is reset, and a trap will be sent if the current 30
seconds CPU utilization average is higher than the new
threshold regardless of the traps sent prior to the threshold
change. Traps will be sent only if threshold warning sending has
been enabled (as other threshold traps).
A value of 0 will mean that the threshold will never be sent.The
default threshold level is 95. Other valid values are: 1-99
The CLI command is:
manage appdirector-thresholds settings
cpu-utilization
The web page URL is:
Services/AppDirector Thresholds/Settings
The MIB is:
rsWSDCpuUtilizationTrapThreshold
(Integer, under rsNWSD 73)
5. In the DNS Alternate Address text box, enter the address of the backup DNS server that is used
to query IP addresses of host names if the primary server is not in service.
6. In CLI (Command Line Interface), enter the following command:
services nslookup <hostname> .
7. The DNS Table is displayed.
To define the static DNS Table:
2. Click DNS. The DNS pane appears.
3. To enable the DNS client, check Client DNS.
4. Select Static DNS. The Static DNS Table appears in the DNS pane.
6. Click Add. The new client is listed in the Static DNS Table.
Network Time Protocol (NTP)
Network Time Protocol (NTP) enables you 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 sends the date and time to the device. Enabling or disabling the NTP
capability results in different levels of accuracy.
Note: When NTP is disabled, the device time and date must be set manually.
To configure Network Time Protocol (NTP):
1. In the main APSolute Insite window, right-click the AppDirector device icon and select SetUp.
2. Click the Networking button and select NTP. The Network Time Protocol Preferences window
appears.
Host Name URL for which you want to set the IP address.
IP Address IP address of the URL.
NTP Server Address
Address of the NTP server.
Active (checkbox)
Enables or disables the NTP feature (default: disabled).
Note: The NTP Server Address must be configured to enable
the NTP feature.
NTP Port
The NTP server port (default: 123).
Daylight Saving Time Support
Radware devices support daylight saving time. You need to configure the start and end date of
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.
Note: When the system clock is manually configured, the system time is changed only when
daylight saving time starts or ends. If the daylight saving time is enabled during the
daylight saving time period, the device does not change the system time.
To configure Daylight Saving Time in APSolute Insite:
1. In the main window, double-click the WSD icon. The Setup window appears.
2. Click Networking. From the dropdown list, select Daylight Saving. The Daylight Savings Time
Settings window appears.
3. Set the parameters according to the explanations provided:
NTP Checking Interval
Interval, in seconds, that a time query message is sent to the NTP
server (default: 172,800).
Time Zone
Time zone offset from GMT (default: -12:00).
Daylight Saving
Status
Enables and disables the daylight saving feature.
Default value: Disabled.
Daylight Saving
Designation
States the daylight saving designation zone. Read-only parameter.
Mode
Select from these two modes:
Date: an absolute date to configure.
Recurring: if it starts or ends based on specific criteria (e.g. DST
always starts on the 1st Sunday in April).
Delta (hours)
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 value: 1 hour.
4. Click Apply and OK.
To configure Daylight Saving Time In WBM:
1. From the Services menu, select Daylight Saving.
2. Configure the daylight saving time start and end dates and times.
3. From the Daylight Saving Admin Status dropdown list, select Enabled.
To configure Daylight Saving Time in the CLI:
1. From the CLI, type services daylight-saving status set enabled to enable daylight saving
time.
2. To configure the start and end dates and time, type services daylight-saving begins D|dd/
mm:h or R|instance/weekday/mm:h and services daylight-saving ends D|dd/
mm:h or R|instance/weekday/mm:h respectively.
Port Settings
This section discusses AppDirector features which are connected with traffic and port management.
Interface Physical Configuration (Speed and Duplex), page 85
Port Mirroring, page 85
Link Aggregation, page 86
Virtual LAN, page 88
Start
Type in the daylight saving start details as follows:
Begin Day (Date Mode Only): Select from 1-31
Begin Weekday (Recurring Mode Only): Select from Sunday
through Saturday.
Begin Instance (Recurring Mode Only): Select 1st, 2nd, 3rd, 4th or
last instance of weekday per month when DST starts.
Begin Month: Select from J anuary through December.
Begin Hour 0-22: Select from 00 to 22 (to represent 0000 through
2200).
Date&Time: Displays the selection.
End
Type in the daylight saving end details as follows:
End Day (Date Mode Only): Select from 1-31.
End Weekday (Recurring Mode Only): Select from Sunday
through Saturday.
End Instance (Recurring Mode Only): Select 1st, 2nd, 3rd, 4th or
last instance of weekday per month when DST starts.
End Month: Select from J anuary through December.
End Hour 1-23: Select from 01 to 23 (to represent 0100 through
2300).
Date&Time: Displays the selection.
Interface Physical Configuration (Speed and Duplex)
You can force configuration to physical interfaces if the network does not support auto negotiation,
or if you want to change the configuration manually. You can set speed and duplex separately for
each Fast Ethernet port and Giga Ethernet port.
To update the ports physical attributes:
1. In the main APsolute Insite window, right-click the APSolute device icon and select SetUp. The
2. Select Networking > Physical Settings. The Physical Settings window appears.
3. To update a port in the table, select a port and set the following:
4. Click Update to save the changes.
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 configure Port Mirroring:
window appears.
Port Name
Index number of the port.
Port Speed
Port Traffic speed. Values can be Ethernet, Fast Ethernet, Giga Ethernet, or
XG Ethernet. Enabled when Port Auto Negotiation is set to Off.
Port Duplex
Whether port allows both inbound and outbound traffic (Full Duplex) or one
way only (Half Duplex). Enabled when Port Auto Negotiation set to Off.
Port Auto
Negotiation
Automatically detects and configures the speed and duplex required for the
interface.
2. Select Networking > Port Mirroring. The Port Mirroring window appears, listing the current
Input and Output Ports.
3. In the Port Mirroring Table window, select a line and click Edit. The Edit Port Mirroring window
appears.
4. From the Receive/Transmit dropdown list, select Receive only, Transmit only, or Transmit
and Receive.
5. In the Promiscuous Mode checkbox, define the mode as follows:
6. Click Add to apply the setup, and then click OK to exit the window.
Notes: .
>> Port mirroring is not supported with VLAN.
>> Port mirroring is not supported on ODS 1.
>> You can mirror up to 3 input ports per output port on AS1.
>> When port mirroring on AS3, the Transmit Only parameter cannot be set.
>> When port mirroring on AS2, the aggregated throughput (mirrored and original traffic)
that can be forwarded is limited to 1.5 Gbps
>> ODS 2 supports port mirroring of up to 4 ports.
>> Port mirroring with trunk is not supported on AS1,AS2 and AS3.
>> Trunk cannot be a port mirroring destination but can be a source.
Link Aggregation
Link Aggregration is a method of increasing bandwidth by combining physical network links into a
single logical link. This increases the capacity and availability of the communications channel
between devices - both switches and end stations - using Fast Ethernet and Gigabit Ethernet
technology.
Multiple parallel physical links between two devices can be grouped together to form a single logical
link. Link Aggregation also provides load balancing where processing and communications activities
are distributed across several links in a trunk to prevent single link overloading. Treating multiple
LAN connections as one aggregated link ensures these advantages:
Enabled (Default)
All traffic is copied.
Disabled
Only traffic to the destined port is copied.
Higher link availability.
Increased link capacity.
Improvements in existing hardware.
No upgrading to higher-capacity link technology is necessary. Radware devices support Link
Aggregation according to the IEEE 802.3ad standard for Link Aggregation. Link Aggregation is
supported on:
Point-to-point links.
Links operating in full duplex mode.
Aggregation is permitted only among links with the same speed and direction. Bandwidth
increments are provided in units of 100Mbps and 1Gbps.
The Radware Link Aggregation function allows you to define up to seven pre-configured trunks. Up
to seven physical links can be aggregated into one trunk. Once configured, a trunk can be part of a
regular VLAN interface or used as an IP interface. All trunk configuration is static.
To configure Link Aggregation:
window appears.
2. Click Networking > Link Aggregation. The Link Aggregation window appears.
3. Define the trunks algorithm for Layer 2, Layer 3, and Layer 4 as follows:

Notes:
>> The same algorithm must be applied on the other switch in the trunk.
>> AS1,AS2,AS3 and ODS 1 do not support hardware trunks for external ports (only
software trunks), therefore you cannot add such trunks to Switch VLANs or, define it
for port mirroring.
>> AS1, AS2 and ODS-1 switches do not support trunks in VLAN (all types) while AS4,
AS5 and ODS 2 switches support trunk in VLAN (all types) since they support
hardware trunks.
4. To associate ports with trunks, select a trunk from the list of trunks and click Edit. The Edit Link
Aggregation window appears.
5. Select the ports that you want to associate with the trunk and click OK.
6. To apply a new trunk definition to your device, add a new interface using the new trunk. In the
SetUp window, click Add. The Interface window appears.
Ignore
Ignore the headers of that layer.
Source Address
Consider packets source only.
Destination Address
Consider packets destination only.
Both Addresses
Consider packets source and destination.
8. Click OK. A new trunk appears in the Interface table.
Trunk Management
Trunk management will only use the management ports (MNG-1 and MNG-2) and the management
ports cannot be a part of any other trunk.The Management trunk is a special trunk only for On
Demand Switch devices and will always be the last trunk in the list.
OnDemand Switches Management Ports Redundancy
You can define the management ports to be a part of the same trunk (T-MNG).
If this is the case, one port is active while the other port is in backup.Failure of the active port will
seamlessly activate the backup port. The two management ports are sharing the same IP address.
OnDemand Switches Management Ports Isolation
Network traffic to the management port is fully isolated from the traffic ports and therefore no
network traffic will be forwarded between the management and traffic ports.
Virtual LAN
This section (VLAN) explains the types of virtual LAN networks, and their functionality and
configuration in AppDirector and includes the following topics:
Introducing Virtual LAN, page 88
AppDirector VLAN Types, page 90
Layer 2 Capability for OnDemand Switches, page 90
Bridging, page 91
VLAN Configuration, page 91
Redundancy With VLAN, page 93
Introducing Virtual LAN
A Virtual LAN (VLAN) is a group of devices that share the same broadcast domain within a switched
network. Broadcast domains describe the extent that a network propagates a broadcast frame
generated by a device.
VLANs can be defined as a group of devices on different physical LAN sections or on a single LAN
section, 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 will be able
to share resources and bandwidth as if they were connected to the same section.
If Num
Select a trunk from the dropdown list, e.g., T-1.
IP Address
Trunks IP address.
Network Mask
Trunks network mask.
Broadcast Type
The broadcast address can be:
ONEFILL: full of ones.
ZEROFILL: full of zeros.
VLAN Membership
Normally there are three ways of assigning a member to a VLAN. In a port based VLAN, the
administrator assigns each port of a switch to a VLAN. For example, ports 6-10 might be assigned to
the Manufacturing VLAN, ports 1-4 to the Sales VLAN and ports 4-6 to the Accounts VLAN. The main
drawback of VLANs defined by port is that the systems manager must reconfigure VLAN
membership when a user moves from one port to another.
In MAC address-based VLANs, membership is defined by the source or destination MAC. The main
advantage of this model is that the switch doesn't need to be reconfigured when a user makes a
move to a different port. The main problem with MAC address-based VLANs is that a single MAC
address cannot easily be a member of multiple VLANs.
VLANs based on Layer 3 information take into account protocol type (IP, NetBIOS) and Layer 3
addresses in determining VLAN membership. One of the main benefits of this method is that users
can physically move their workstation without having to reconfigure their workstation's network
address. The shortcoming of VLANs based on Layer 3 is the slow performance.
Switches with VLAN capability can create the same division of the network into separate LANs or
broadcast domains. It is similar to "color coding" your ports.
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.
Usage of VLANs
One of the main application areas for VLANs these days is Hosting Centers. Customers of hosting
centers often avoid routes through the Internet (ISP networks) to access the hosting centers,
because they want to minimize exposure to hackers. Data centers can reduce their investments by
using VLANs to create a separate dedicated LAN to each customer's server with the same physical
LAN infrastructure. Because each VLAN uses its own IP subnet, the customer's private address
spaces can also be preserved.
Assigning Ports to VLANs
To create a VLAN, you can add links and ports to it. Links are connections between two devices that
provide a path for traffic on that VLAN. Ports are connections to end stations.
You can also move ports from one VLAN to another, and delete ports from a VLAN. You can also
merge the ports from two existing VLANs in one VLAN.
A typical procedure would involve:
1. Creating a VLAN, giving it a name.
2. Giving the VLAN an IP Address.
3. Adding ports to that VLAN.
4. Deleting ports out of a VLAN.
5. Assigning tags and designating Trunk (uplink) ports.
By default when you add ports to a VLAN, they are added untagged. Most user ports will be
untagged. The reason for adding tags to ports is to allow multiple VLAN traffic to traverse those
ports, as with trunk ports. Trunk ports (or Uplinks) can contain several thousand VLANS on a single
link. This is useful if you have more than one VLAN at an edge switch. In order to have more than
one VLAN on a uplink you will need to add an 802.1q tag to port. See VLAN Tagging Support,
page 93.
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 supports 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 inter-port traffic 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.
Note: This option can also be defined with a Switch VLAN (Switch VLAN protocol) for wire-
speed performance.
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.
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.
Note: This is a Layer 2 VLAN and can be standalone or part of a Regular VLAN.
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 arriving at the VLAN port are switched according to Layer 2 information,
except for those frames whose Layer 2 address is the same as the AppDirector port Layer 2 address.
Frames with AppDirector Layer 2 destination are processed by the AppDirector application and then
forwarded.
Layer 2 Capability for OnDemand Switches
This table summarizes layer2 capability for Radwares OnDemand switches.
Layer 2 Feature ODS 1 ODS 2
STP 802.1d No Yes
Link aggregation 802.3ad Yes Yes
VLAN tagging 802.1q Yes Yes
VLAN switching No Yes
Radware Segmentation (physical Port and VLAN) Yes Yes
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. The table
that stores this list is called the Bridge Forwarding table.
When a frame arrives from one interface, AppDirector looks for the frame Destination addresses
within its address list according these 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.
To add a MAC address to a port:
window appears.
2. Click Networking > VLAN. The Virtual LAN window appears.
3. Click Bridge SetUp, select the port to which you want to add a MAC address, and click Add.
The Edit Global Forwarding Table appears.
4. Type the relevant MAC address and click OK.
VLAN Configuration
To enable AppDirector to perform Traffic Redirection policies on traffic destined for the Internet,
VLAN protocol is set to IP. This requires clients to configure AppDirector as their default router.
To create a VLAN:
1. In the SetUp window, select Networking > VLAN. The Virtual LAN window appears.
2. To connect a physical port on the device to the VLAN you are creating, in the Assign Port to
VLAN pane, select the checkboxes of the ports you want to assign to the VLAN.
3. In the Virtual LAN window, set the following parameters according to the explanations provided:
Port mirroring (Copy port) No Yes
Regular VLAN (bridging) Yes Yes
Assign Port to VLAN
(checkboxes)
Select ports on device that you want to be assigned to the VLAN.
Interface Number
Interface number of VLAN to be automatically assigned by the
management station.
Layer 2 Feature ODS 1 ODS 2
4. Click Add. The new VLAN appears in the VLAN Table.
To configure VLAN parameters:
1. In the SetUp window, select Networking > VLAN. The Virtual LAN window appears.
2. Click Parameters, and set the following parameters according to the explanations provided:
Type
Required VLAN type:
Regular: The device acts as a bridge.
Switch: The Switch type is a Layer 2 VLAN. Switch VLAN can be
standalone or part of a Regular VLAN.
Default value: Regular.
Protocol
Required VLAN protocol. You can choose IP or Switch VLAN only
when the VLAN type is Switch. Otherwise, the protocol is IP or
Other, as discussed in AppDirector VLAN Types, page 90.
Default value: Other.
Up Criterion
Default by Type (default value):
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: VLAN is up when all ports participating in the VLAN are
up.
One Port: VLAN is up when at least one of the ports participating
in the VLAN is up.
Down Criterion
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: VLAN is down when all ports participating in the VLAN
are down.
One Port: VLAN is down when at least one of the ports in the
VLAN is down.
802.1q Environment
(checkbox)
Enables or disables VLAN tagging (This operation requires you
to reboot the device).
VLAN Tag Handling
Handling method of VLAN Tagging (enabled only if 802.1q
Environment checkbox is selected). Choose from:
Overwrite: VLAN tag of outgoing interface/port is used.
Retain: VLAN tag of original incoming interface is used.
Default: Retain.
Ethernet Type
(for user-defined VLANs)
Define the Ethernet type for user-defined VLANs. You can
configure the VLAN to forward other types of protocols.
3. Click Apply to save the configuration, and then click OK. Your preferences are recorded.
Tip: In the Bridge SetUp pane, you can monitor, add to, and edit the bridge forwarding
nodes. See IP Addressing, page 95.
Redundancy With VLAN
When working with VLANs, two AppDirectors can be configured in the
Active / Backup redundancy setup only. Active mode is not available due to the fact that two active
devices configured with VLAN on the same network segment might create a network loop. For more
information about AppDirector Redundancy settings, see Configuring Redundancy, page 251.
VLAN Tagging
This section describes how VLAN tags are used in AppDirector configurations. This section includes
VLAN Tagging Support, page 93
Rewriting VLAN Tags, page 94
VLAN Tagging Support
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 forwarding or overwriting them, support for 802.1q
environment must be enabled (802.1q Environment parameter). By default VLAN Tags are not
supported on AppDirector. When the status of VLAN Tag support is changed, reboot the device.
Retaining VLAN Tags
AppDirector enables you to preserve existing VLAN Tags on incoming traffic that passes through the
device. See VLAN Configuration, page 91.
Notes:
>> If a packet arrives without a VLAN tag, AppDirector sets a tag according to the
destination local subnet (see Rewriting VLAN Tags, page 94).
Ethernet Type Mask (for
user-defined VLANs)
Define the mask on Ethernet type for user-defined VLANs.
Bridge Address
The MAC address used by the device.
Bridge Type
Types of bridging that the device performs.
Bridge Forwarding Table
Aging Time
Indicates how long, in seconds, unused entries are to remain in
the Forwarding Table. The counter is reset each time the entry is
used. When the Aging Time period expires, the entries are
deleted from the table.
Minimum value: 10 seconds.
>> Rewriting VLAN tags according to Destination is a default standard behavior, while
retaining VLAN tags is rarely used.
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.
Each IP interface can have a VLAN tag associated with it.
Notes:
>> You may configure the same VLAN Tag on multiple interfaces.
>> You may configure a VLAN Tag on a VLAN interface.
AppDirector recognizes an IP interface as a physical port/IP address combination.
When using AppDirector with VLAN Tagging, all packets that are 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.
To set a VLAN Tag for an IP Interface:
window appears.
2. Select an existing interface and click Edit, or click Add. The Interface window appears (see
Setting Up Interface IP Addresses, page 95).
3. Set the VLAN Tag parameters as required. A value of 0 indicates that no tag is used.
4. Click OK to apply changes.
5. In the SetUp window, click Networking > VLAN. The Virtual LAN window appears.
6. Select Parameters. The Parameters pane appears.
7. Select 802.1q Environment and set VLAN Tag Handling to Overwrite (the default value is
Retain) according to the explanations provided.
IP Addressing
This section discusses the configuration of IP addressing.
Introduction to IP Addressing
IP addresses are 32-bit binary numbers and each 32-bit IP address consists of two sub-addresses;
one identifying the network, and the other identifying the host of the network, with an imaginary
boundary separating the two.
Setting Up Interface IP Addresses
AppDirector performs routing between all defined IP interfaces. Using the main SetUp window, you
can define the IP addresses for AppDirector interfaces, assigning an IP address and an IP Network
Mask for each defined interface.
Routing
Routing is AppDirectors 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.
When AppDirector forwards an IP packet, the IP Routing Table is used to determine the Next-
Hop IP address and the Next-Hop interface.
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.
Setting Up the 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 is an intra-domain IP routing protocol, replacing RIP in larger or more
complex networks. The Routing Table allows you to configure routing and define the default
gateway.
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.
Overwrite
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.
Note: This is the default value.
To configure routing:
window appears.
2. Select Networking > Routing Table. The Routing Table window appears.
3. Click Add. The Edit Physical Route table appears. Set the following parameters according to the
To configure a default gateway:
1. Follow steps 1-3 as explained in To configure routing:, page 96.
2. In the Edit Physical Route table, type the relevant values for the Next Hop parameters and for
the If Number. For the Destination IP Address and Network Mask parameters, use default values
(0.0.0.0).
Note: You can also set a backup default gateway for the device, and use both the active and
backup gateways simultaneously using load sharing. For more information, see
Default Router Per Virtual IP, page 225.
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.
If Number
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 remote routing:
Remote (Forwards packets)
Reject (Discards packets)
Local (Read-only)
Chapter 4 Configuring Load Balancing
Policies
This chapter introduces the basics of Layer 4-7 switching and the farm management concept and
includes the following sections:
Introducing AppDirector Traffic Management, page 97
Farm Selection Using Layer 4 Policies, page 99
Farm Selection Using Layer 7 Policies, page 104
Setting Up Farms, page 120
Servers, page 134
Clients, page 149
Introducing AppDirector Traffic Management
This section describes how to use AppDirector Layer 4-7 classification, server farm management,
and traffic redirection. Traffic Management ensures optimal delivery of applications deployed over
the servers and maximizes utilization of the existing resources used by these applications. This
section includes the following topics:
Traffic Management: Load Balancing Servers, page 97
Introducing Layer 4-7 Policies, page 97
Layer 4-7 Policies: Farm Selection Criteria, page 98
Layer 4-7 Configuration Overview, page 98
Traffic Management: Load Balancing Servers
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:
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.
A group of application servers that provide the same service is called a server farm. A single point of
entry through which clients can access a variety of application services is called a Virtual IP address
(VIP). AppDirector Layer 4-7 Policies define the rules for farm selection for different services
accessed through the same VIP. Based on Layer 4-7 Policies, traffic targeted to the VIP is redirected
to the optimal farm to deliver the required application service.
Introducing Layer 4-7 Policies
AppDirector Layer 4 and Layer 7 Policies are the sets of rules which define the device behavior.
Through Layer 4-7 Policies, traffic is first classified based on network or application parameters.
Depending on the service required, AppDirector selects a farm based on the specifications within the
Layer 4-7 Policy that is eligible for a clients request. Then, based on the defined policy, a redirection
decision is made, which forwards traffic to the required server farm. The traffic is subsequently
forwarded to the server best able to deliver the requested service within the selected farm.
Configuring Load Balancing Policies
Layer 4-7 Policies allow you to configure a single Virtual IP address; an access point to different
services provided by different farms. A single Virtual IP can provide a different service for different
applications, URLs, clients, etc.
Each server within the AppDirector farm is recognized by its IP address. The IP addresses of the
servers are used by AppDirector and are usually hidden from the clients so that the process of
server selection is transparent for the users.
Layer 4-7 Policies: Farm Selection Criteria
When a new request for service reaches AppDirector, AppDirector uses Layer 4-7 Policy Table
configurations to select the farm to provide the service. AppDirector can select the farm according to
the following considerations:
Application to which the request is sent: AppDirector operates in Layer 4, using the Layer 4
Protocol (TCP/UDP) and destination port of the request to select the required farm. 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 and Destination port, selects a server from
the farm allocated to this service (Layer 4 Policy), and forwards the packet to that server.
Source from which the request arrived: AppDirector can provide different services to different
groups of clients accessing the same VIP and port. To provide services to different groups,
AppDirector can select the required Layer 4 Policy according to the source address, in addition to
the Layer 4 Protocol and Destination port.
Content of the request: AppDirector can operate in Layer 7 according to predefined policies.
Using these policies, AppDirector can use the Layer 7 content of the request for service to
choose the most suitable farm to handle the request. 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 and Destination port. If the matched Layer 4 Policy is linked to a Layer 7 Policy,
Delayed Bind is performed. When AppDirector receives enough information to make the Layer 7
decision, a farm can be selected according to that Layer 7 Policy.
Layer 4-7 Configuration Overview
The access point for all the requests for service arriving at AppDirector is the Virtual IP address
managed by AppDirector. All the Virtual IP addresses managed by AppDirector are configured in the
Layer 4 Policy table. For each Virtual IP, any number of Layer 4 Policies can be configured to define
application level handling for different types of traffic to the same VIP. To set Layer 7 handling, you
can attach a Layer 7 Policy to each Layer 4 Policy.
To configure Access Point:
1. Connect to the device:
a. Double-click the AppDirector device icon. The Connect to Device window appears.
b. Type the devices IP address and click OK.
2. In the main window, click APSolute OS > Traffic Redirection. The Traffic Redirection window
appears.
3. Configure the service access point:
a. Configure Farms
b. Configure Layer 7 Policies
c. Configure Layer 4 Policies
Farm Selection Using Layer 4Policies
This section explains how AppDirector utilizes various application services using a single entry point,
achieved by defining a Layer 4 Policy. The following topics are included in this section:
Introducing Layer 4 Policies, page 99
Setting Up Layer 4 Policies, page 99
Layer 4 Policies Lookup Mechanism, page 102
Introducing 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.
You can define traffic segregation for a Layer 4 Policy on the basis of the Destination port and
Layer 4 Protocol. 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.
Setting Up Layer 4Policies
The following describes the procedure for defining a new Layer 4 Policy.
To set up a Layer 4 Policy:
2. Select L4 Policies. The L4 Policies pane appears.
3. Click Add. The L4 Policies window appears.
4. In the VIP Address text box, enter the address of the Layer 4 Policy that you want to create and
click Add. The Add L4 Policy window appears.
L4 Policy Name
A unique name identifying the L4 Policy.
L4 Protocol
The L4 protocol used.
TCP
UDP
ICMP
Any - any IP protocol, including TCP, UDP, and ICMP
Other - any IP traffic that is not TCP, UDP, or ICMP
Default value: TCP
6. When the Layer 7 Policy parameter is defined (see Farm Selection Using Layer 7 Policies,
page 104), set the following Layer 7 Related parameters according to explanations provided.
L4 Port
Destination L4 port for the configured L4 protocol.
Default value: 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. There is no need to specify the application when using a
well known port on the layer 4 policy.
For Virtual IP Interface configuration, the Application parameter must be
set to Virtual IP Interface.
Default value: None
Source IP From-To
Range of client IPs for which policy provides services.
FarmName
Farm that provides services for traffic matching policy.
Default value: None
Segment Name
Defines the segment to which this L4 policy is associated; it is required
when using Segmentation (see Segmentation, page 237).
For Virtual IP Interface configuration, the segment name parameter is not
required.
Default value: None
Redundancy Status For the primary device, configure the policy as Primary status; on the
backup device, configure the policy as Backup status.
Default value: Primary.
Layer 7 Policy
Name
Selects a predefined policy. Determines that Layer 7 farm selection must
be applied to the traffic that matches the Layer 4 Policy (see Farm
Selection Using Layer 7 Policies, page 104).
Default value: None
Backend
Encryption Port
Sets the port to which AppXcel 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. The Backend Encryption
Port can be any TCP port.
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. You can limit the depth for the search by defining this parameter.
AppDirector searches until the end of the HTTP Header unless the defined
depth is reached. The argument relates to multiple packets only. If the
defined depth is shorter than the minimum allowed packet size,
AppDirector searches whole packet regardless of the depth value.
Default value: 3.5 Kbytes
Max: 10 Kbytes
When parameter is set to 0, AppDirector searches request packet until the
end of the HTTP Header.
Note: The amount of bytes defined must be sufficient so that they
include the deepest parameter that needs to be parsed.
Radware recommends that a Default Policy be defined to ensure
that if the depth defined is not large enough, the session is still
forwarded to a farm and not discarded.
POST Classifi-
cation 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:
HTTP Header: 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. This is the default value.
Message Body: For POST requests, message body is used for farm
selection using Layer 7 Policies. This mode 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).
Both: For POST requests, message body and header are used for
classification.
Note: For all HTTP methods except POST only the HTTP header is
used.
7. Click OK. The Add L4 Policy window closes, and a new service appears in the VIP table.
8. Click OK. The L4 Policies window closes, and the defined policy appears in the L4 Policies table.
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:
1. AppDirector searches its Client Table for a matching entry. The match can be either a full Layer
4 match for a farm whose Session 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.
2. AppDirector searches its Layer 4 Policy Table to find an entry that matches the traffic according
to existing farm selection in the following order:
L7 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 Request: 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.
Complete and 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.
Complete and Maintain: 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.
Future client requests using this TCP Connection are sent to the server
eliminating the need to re-establish the TCP connection.
AppDirector receives multiple requests for different servers over a single
TCP connection while maintaining sessions with all the servers that were
selected allowing it to be reused for other requests which select the same
servers.
Default value: First Request
HTTP
Normalization
Enables or disables normalization of URLs in HTTP requests, before
parsing the HTTP request itself.
HTTP Normalization includes the following functions:
Decode% (Hexadecimal) - For example, http://
%77%77%77%2e%72%61%64%77%61%72%65%2e%63%6f%6d/
would be www.radware.com.
Normalize directory traversals ('.' and './')
Remove double slashes - '//'
Convert DOS '\' to '/'
Remove NULL characters '%00'
AppDirector uses the normalized request for the Layer 7 classification, but
forwards the client's original request to the server.
Default value: Disable
a. 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.
b. 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.
c. 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.
d. If there is no match, the packet is discarded.
3. 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.
Note: This search is applied only to entries that were matched in Step 2.
4. 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.
5. 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 (see Farm Selection Using Layer 7 Policies, page 104).
Note: The order of configured policies has no impact; the most specific policy is always
matched, using the above logic.
For example, a packet that is destined to 100.1.1.1, TCP port 80, from client 3.3.3.3, and was
matched in Step 2 above to a Layer 4 Policy with:
First, AppDirector scans the Layer 4 Policies table for a full match between the Destination IP
address, Destination IP Protocol, and Destination Port, looking for the following entry:
100.1.1.1 TCP 80
If the match is not found, AppDirector re-scans the Layer 4 Policies table for a full match
between the Destination IP address, Destination IP Protocol, and Destination Port, looking for
the entry:100.1.1.1 TCP.
If the match is not found, AppDirector re-scans the Layer 4 Policies table for a full match of the
Destination IP address, looking for the entry 100.1.1.1
The match between the packet and the policy was performed as follows:
Destination IP Address Protocol Destination Port
Incoming Packet
100.1.1.1 TCP 80
Layer 4 Policy
100.1.1.1 Any Any
Match Between IP Address Protocol Port
Packet
100.1.1.1 TCP port 80
Layer 4 Policy
100.1.1.1 Any Any
Notes:
>> To optimize device performance, it is recommended to use Layer 4 Policies that specify
the Layer 4 Protocol and Port, at least for the applications that represent most of the
traffic AppDirector must process. As you can see in the lookup mechanism described
above, generic policies (Layer 4 Protocol and Port are set to Any) are matched only on
the third scanning cycle of the Layer 4 Policy database, while specific policies are
matched on the first scanning cycle.
>> As the destination data is matched first, and afterwards the Source IP, it is
recommended to configure specific Layer 4 Protocol and Port for the Layer 4 Policies
for which the Source group is set.
To define Layer 4 Policy to allow a Ping to a VIP:
1. Set the Layer 4 policy to ICMP. You can add a Layer 4 policy that defines which farm is used for
the ICMP.
Or
2. Set the Layer 4 policy to Any. You can add a general Any Layer 4 policy. This selection is less
recommended.
Farm Selection Using Layer 7Policies
This section provides information about defining and using the content-based service selection
mechanism. This section includes the following topics:
Introducing Layer 7 Policies, page 104
Layer 7 Policies Traffic Flow, page 105
Defining Layer 7 Policies, page 105
Persistent Layer 7 Switching, page 109
Introducing Layer 7 Policies
The Layer 7 content aware decision making mechanism allows you to have a single point of entry to
the site, and provides differentiated service for different user groups.
A Layer 7 decision is made using a mechanism called Delayed Binding. When Delayed Binding is
used, AppDirector first performs a TCP handshake with the client to receive the HTTP request.
AppDirector parses the HTTP requests data, usually HTTP headers, and performs the load balancing
decision. Only after that, does AppDirector select a farm and a server. Lastly, AppDirector initiates a
TCP handshake with the server and forwards the traffic to it.
Layer 4 Policy Name VIP Layer 4 Protocol FarmName
ICMP My VIP ICMP My Farm
Layer 4 Policy Name VIP Layer 4 Protocol FarmName
Any My VIP Any My Farm
You can define Layer 7 Policies with names and characteristics for the specific protocol and port.
Farm selection using Layer 7 policies is available for:
HTTP or other HTTP-like (has HTTP-like header) TCP protocols.
UDP protocols.
Farm selection using Layer 7 policies is NOT available for dynamic protocols, such as FTP and TFTP.
When Layer 7 Policies are used, farm selection is based on matching the request data with a list of
Layer 7 Policies defining the Layer 7 parameters differentiating the service. The process of server
selection within the farm can also be content-based, using a third Layer 7 parameter.
Note: When using Layer 7 Policies for UDP traffic, AppDirector inspects each packet
separately and selects the appropriate farm and server.
Using Layer 7 Policies, you can set HTTP Persistency mode per policy. HTTP persistency means
whether AppDirector allows multiple HTTP requests within a single TCP session, or whether
AppDirector forces a single HTTP request within each TCP session. 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. You can set redirection directly in the
Layer 7 Policy. For example, you can redirect traffic to remote sites based on the requested URL.
Delayed Binding Mechanismwith Layer 7 Policies
A Layer 7 decision for TCP traffic is made using a mechanism called Delayed Binding. When Delayed
Binding is used:
1. AppDirector performs a TCP handshake with the client to receive the HTTP request.
2. AppDirector parses the HTTP requests data, usually HTTP Headers, and performs the load
balancing decision.
3. AppDirector selects the requested service.
4. AppDirector selects the best server for the task from the farm that provides the requested
service.
5. AppDirector initiates a TCP handshake with server and forwards traffic.
Layer 7 Policies Traffic Flow
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 Setting
Up Layer 4 Policies, page 99).
If the matched Layer 4 Policy is linked to a Layer 7 Policy for TCP Traffic, Delayed Bind is activated.
When AppDirector receives enough information, it matches the data in the request with each one of
the Layer 7 Policy entries having the Layer 7 Policy name indicated for that specific Layer 4 Policy
(see Introducing Layer 4 Policies, page 99).
Each entry, or rule, in a single Layer 7 Policy can use up to two Layer 7 criteria, such as URL or HTTP
Header, and the criteria can be combined with AND logic. Each rule specifies the farm to be used if
the Layer 7 criteria in it matches the request. The criteria according to which AppDirector classifies
traffic are called Layer 7 Methods.
Defining Layer 7 Policies
To perform a content-based decision, AppDirector works with Layer 7 Policies that use various
Methods for the application level traffic classification. Methods define how AppDirector identifies the
content type, and on this basis, selects a farm that provides the requested service. AppDirector uses
Layer 7 Policies only as an integral part of a Layer 4 Policy. Therefore, Layer 7 Policies must be
bound to Layer 4 Policies.
Layer 7 Policies Configuration Guidelines
1. Defining Methods, page 106
2. Defining Layer 7 Policies Using Methods, page 108
Defining Methods
Methods are the basic building blocks for Layer 7 service selection. They define content by which
traffic is differentiated. You can use the same Method to select one or more services. The following
Method Types are available:
URL: Looks for a specified host name and/or path in the HTTP request.
File Type: Looks for a specified File Type in the HTTP request.
Header Field: Looks for a specified Header Field in the HTTP request.
Cookie: Looks for a specified Cookie in the HTTP request.
Regular Expression: Looks for a regular expression anywhere in the HTTP request.
AppDirector supports Posix 1002.3 regular expressions; the string can be up to 80 characters.
Text: Looks for a text string anywhere in the HTTP request.
Notes:
>> All content settings of the Methods are case sensitive.
>> To perform farm selection based on Cookies, regardless of the Layer 7 method used,
you must have the Cookie Persistency License.
This table describes the parameters of the available Method Types.

Table 12: Layer 7 Method Types
Method Type Method
Specific
Parameter
s
Description Example
URL
Host Name Host name part of the URL in the HTTP header Host Name =
www.a.com
Path Path part of the URL in the HTTP header Path =cgi-bin
File Type
File Type Type of file in the URL Type =html
Header Field
Header Field Specific header field in the HTTP request
(mandatory)
Header Field =
Accept-
Language
Token Value inside the specific header field
(mandatory)
Token =en-us
Cookie
Note: The Cookie
method is
available
only if you
have the
Cookie
Persistency
License.
Cookie Key Specific Cookie Key in the HTTP request
(mandatory)
Cookie Key =
server
Cookie Value Value of the Cookie Key (mandatory) Cookie Value =
red
Regular
Expression
Regular
Expression
Regular Expression (string pattern matching) Regular
Expression
=.abc
To define a Method for service selection:
2. Click L4 Policies. The L4 Policies pane appears.
3. Click L7 Policies. The Layer 7 Policies window appears.
4. Click L7 Methods. The Layer 7 Methods window appears.
5. Click Add. The Edit Layer 7 Method window appears.

Note: The rest of parameters that appear in the Edit Layer 7 Methods window depend on the
value of the Method Type parameter.
7. Click OK. The Edit Layer 7 Method window closes and a new method appears in the Layer 7
Methods table.
Set Cookie
Cookie Key A specific Cookie Key in the HTTP request
(mandatory)
Cookie Key =
server
Cookie Value The value of the Cookie Key (mandatory) Cookie Value =
red
Path The path part of the URL in the HTTP header Path =cgi-bin
Domain Domain to be added to the cookie DMN=service.
com
Expire After This parameter determines for how long the
client 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.
For example,
24H for 24
hours, or 60M
for 60 minutes,
1440S for 1440
seconds, and
1D for 1 day.
Status Line
Status Code The value defined here is followed by a letter
that determines the time unit used (S for
seconds, M or no letter for minutes, H for hours,
D for days).
SCD=404
Status Phrase The text that accompanies the status code. SPHS=Not
Found
Text
Text Text anywhere in the HTTP request
Method Name The name of the Method that you define.
Method Type The type of Method.
Table 12: Layer 7 Method Types (cont.)
Method Type Method
Specific
Parameter
s
Description Example
Note: When Layer 7 policies with the URL method is used, Hashing ensures that all requests
for the same host name are sent to the same server. Reverse Proxy is supported by
Hashing the hostname in the URL requested by the client, regardless of the client IP
address.
Defining Layer 7Policies Using Methods
Methods are bound to farms by Layer 7 Policies, the policies define how Methods are used to select
a specific service. You can use up to two Methods to select the requested service.
To define a new Layer 7 Policy:
2. Click L4 Policies. The L4 Policies pane appears.
3. Click L7 Policies. The Layer 7 Policies window appears.
4. Click Add Policy. The policy parameters appear in the right pane. Set the following parameters
according to the explanations provided:
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
Second Method
Second method used to select a specific farm
FarmName
Farm to which the request is forwarded when methods are matched.
You can define an empty string as the farm name. When such rules are
matched, AppDirector resets the TCP connection, effectively blocking
access.
HTTP Redirect To
Performs HTTP redirection to a specified name or IP. For example, if
the parameter is defined with the name sip.site.com, AppDirector
redirects the HTTP request to the specified name.
Note:
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.
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.
5. Click Add. A new Layer 7 Policy appears in the left pane of the Layer 7 Policies window.
Persistent Layer 7 Switching
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 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.
Persistent Layer 7 Switching Process
During the process of persistent Layer 7 Switching, AppDirector constantly inspects all the HTTP
requests and ensures that an appropriate farm and server handles each request. This is transparent
to the client. This 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 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 that
server.
HTTPS Redirect To
Performs HTTPS redirection to a specified name or IP. For example, if
the parameter is defined with the name www.site.com, AppDirector
redirects the HTTP request to the HTTPS:// www.site.com.
Note:
Retain HTTP
Persistency
When this is enabled, AppDirector allows multiple HTTP requests
within a single TCP connection.
When this is disabled (default), AppDirector forces a single request
within each connection. When multiple requests over same connection
need to be served by different AppDirector farms, you can:
Disable Retain HTTP Persistency.
Set the L7 Persistent Switching Mode at the Layer 4 Policy to
Complete and Overwrite or Complete and Maintain.
SIP Redirect To
Performs SIP redirection to a specified name or IP. For example, if the
parameter is defined with the name www.site.com, AppDirector
redirects the SIP request to the specified name.
Note:
Note: Persistent Layer 7 Switching sessions are not mirrored to a redundant AppDirector.
Configuring Persistent Layer 7 Switching
Persistent Layer 7 Switching can be defined independently for service selection, using Layer 7
Policies, and for server selection, using Session ID Persistency.
You can configure service selection using Layer 7 Policies that are included in the Layer 4 Policies
(see Setting Up Layer 4 Policies, page 99).
You can configure server selection using the Session ID Persistency Table. You can configure the
following Persistent Layer 7 Switching modes:
First Request: AppDirector inspects the first request in each TCP connection, selects a server,
and forwards the request accordingly. During the rest of the TCP connection, AppDirector
forwards all further requests to that server.
Complete and Overwrite: AppDirector inspects all requests over a single TCP connection.
Whenever a new server is required for further client requests, AppDirector closes the connection
with the server that was selected for the first request for service and opens a new connection
with a new server. This is recommended when there are minimal changes of the backend server
within a single TCP connection with a client.
Complete and Maintain: AppDirector inspects all requests over a single TCP connection.
Whenever a new server is required for further client requests, AppDirector opens a new
connection with the new server without closing the connections to all previously used backend
servers. Future client requests using this TCP connection result (which selects a previously used
server for the client connection) are sent to the server, eliminating the need to re-establish the
TCP connection. AppDirector receives multiple requests for different servers over a single TCP
connection, while maintaining sessions with all the servers that were selected, so that the
connection can be used for other requests which select the same servers.
This is recommended when the backend server frequently changes within a single TCP connection
with a client.
When Persistent Layer 7 Switching is configured in Layer 4 Policy and the selected farm is not
configured for Session ID Persistency, a server is selected according to load considerations. In such
a case, AppDirector uses the previously selected server to serve any further requests that result in
the same selection.
When the following applies:
1. Layer 7 Policies in use
2. One of the farms uses Session ID Persistency
3. Different Persistent Layer 7 Switching modes are set for the Layer 4 Policy and for the Session
IDs.
AppDirector behaves as follows:
When Persistent Layer 7 Switching is set to either Complete and Maintain or Complete and
Overwrite modes, both in Layer 4 Policy and in Session ID, the mode configured in the Layer 4
Policy is applied.
When Persistent Layer 7 Switching in the Layer 4 Policy is set to First Request in L4 Policy, and
Persistent Layer 7 Switching for Session IDs is set to one of these modes (i.e: to Complete and
Overwrite or Complete and Maintain), then for a session destined to the Layer 4 Policy VIP, the
first request is parsed to select both a farm and a server. Further requests are parsed only for
the server selection.
When Persistent Layer 7 Switching is set to Complete and Maintain or Complete and Overwrite
modes only for the Layer 4 Policy, all HTTP requests are parsed both for farm selection and for
server Persistency. It is important to parse all requests for server selection because different
farms may be selected for different requests; therefore, different servers must be used.
This behavior is summarized in the following table:

Persistent Layer7 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
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 identifier 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 L7 policy, or a different server is required
according to server persistency (DSID). The flag is applicable only when Session 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.
Session ID Persistency
Sometimes it is necessary to establish multiple connections from the same user to the same server
in a farm. Such 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.
Session ID Persistency is used for IP Traffic and enables AppDirector to direct all requests for service
that have the same session identifier to the same server in the farm. Session ID Persistency
operates from the IP level up to Layer 7, providing application aware server persistency. You can
configure different persistency schemes for different applications and for different farms.
AppDirector allows searching for any persistency identifier 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 identifier 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 ID persistency is available for the following types of traffic:
HTTP or other HTTP-like (has HTTP-like header) TCP protocols.
UDP protocols.
First Request
Complete and Overwrite or
Complete and Maintain
First (Request)
Only the first request is
inspected for farm/server
selection.
The first request is inspected for
farm selection, and all the other
requests are inspected for server
selection.
Complete and Overwrite or
Complete and Maintain
All requests to the Layer 4 Policy VIP are inspected for farm and
server selection. The mode used (Complete and Overwrite or
Complete and Maintain) is the one configured in the Layer 4 Policy.
L4 Policy:
Session IDs:
IP traffic in general (using pattern match).
Session ID persistency is NOT available for dynamic protocols, e.g; FTP, TFTP.
Note: When using Session ID Persistency for UDP traffic, AppDirector inspects each packet
separately and selects the appropriate server.
The Session ID may be configured manually via the static mechanism (see Static Session ID
Persistency, page 116), or learned dynamically. When AppDirector finds a Session ID that does not
appear in the Session ID Table, AppDirector dynamically selects the best available server using the
Dispatch Method configured for the farm (see Dispatch Methods, page 129), and adds an entry to
the Session ID Table indicating the server used for this Session ID.
Note: 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.
Sometimes administrators need to maintain Client - Server persistency based on a Session ID.
However, this is not always sufficient, and there is also a need to track the Source IP because
several clients may use the same Session ID. Using Session ID Persistency, you can track both the
Session ID and the client's Source IP and maintain persistency based on both; when AppDirector
identifies a new Source IP with the same Session ID, a new load balancing decision is made.
Configuring Session ID Persistency
When Session ID Persistency is used, clients requests sometimes contain Session IDs. AppDirector
detects these, and keeps server persistency for further traffic arriving with the same Session ID. A
Session ID is kept in AppDirector memory for a period of time as defined by the Inactivity Timeout
parameter. During this period, whenever a client connects with the same Session ID, AppDirector
directs that client to the same server according to the Session ID.
Note: Using the Cookie Persistency License allows AppDirector to search the HTTP headers
for Session ID Persistency. Without the License, AppDirector inspects only the URI and
no other HTTP headers.
You can tune the Session ID Persistency Table (see Device Tuning, page 68).
The Session ID can be a text string or a binary pattern. You can configure AppDirector to perform a:
Text Match.
Pattern Match.
Text Match Session ID Persistency
When Session ID Persistency is configured using the Text Match option, AppDirector maintains
persistency by searching for the textual Session ID.
This table presents the Text Match Session ID Persistency parameters.
Table 13: Text Match Session ID Persistency Parameters
L4 Protocol
Layer 4 Protocol for which traffic is intercepted for Session IDs. Possible values:
TCP, UDP, or Other.
Default value: TCP
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.
Default value: 0
Lookup Mode
Defines the location within the request where the Session ID appears. Possible
values are:
Header: Indicates whether AppDirector searches for HTTP header with a
separator of ":" between the Persistency Identifier and the value used for server
persistency.
Cookie/URL Cookie: Indicates whether AppDirector searches for a separator
of "=" between the Persistency Identifier and the value used for server
persistency.
Note: If you have the Cookie Persistency License (see Note, page 112), this
parameter appears as Cookie; otherwise, it appears as URL Cookie.
RegExp: Indicates whether AppDirector searches for a predefined regular
expression in the HTTP header.
Using the Cookie Persistency License allows AppDirector to search the HTTP
headers for Session ID Persistency. Without the License, AppDirector inspects only
the URI and no other HTTP headers. This applies to all of the options listed above.
Default value: Cookie/URL Cookie
Persistency
Identifier
Key of the Persistency Identifier, up to 64 characters.
For example, the Persistency Identifier can be "Call-ID" in SIP or Accept-Language
in HTTP.
Note: When the Lookup Mode is set to Header, the Persistency Identifier is case
insensitive and no colon is required at the end of the Persistency Identifier
value; for example, it can be X-Forwarded-For and not X-Forwarded-
For:. When Lookup Mode is set to Cookie, the Persistency Identifier is
case sensitive. When Lookup Mode is set to RegExp, the regular
expression defines whether the Persistency Identifier is case sensitive or
not.
No default.
Identifier Match
Exact: Indicates that the configured Persistency Identifier value must exactly
match the received Persistency Identifier name.
Prefix: Indicates that the configured Persistency Identifier 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, deliminator, =, or :.
Default value: Exact
Learning
Direction
Indicates which traffic is inspected by AppDirector to gather persistency information:
Server Reply means AppDirector dynamically learns which Session IDs are to
be associated with each server, according to information in server replies.
AppDirector also inspects client requests to find out if they contain a Session ID
that has already been learned by AppDirector and forwards the requests to the
correct server.
Note: To enable the Server Reply parameter the Cookie Persistency License
must be installed.
Client Request can be used when Session IDs appear only in client requests
and indicates that AppDirector does not inspect server replies. This can be
used, for example, when persistency is based on a 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 means AppDirector inspects both client requests and servers
replies to learn about Persistency Identifiers.
No Learning means that persistency information is not gathered. Radware
recommends to define this value when Static Session ID Persistency is used.
Default value: Server Reply.
Ignore Server
Reply
Used to enhance AppDirector performance when Session ID values can be learned
from server reply; or when Learning Direction is set to Server Reply or to Both
Directions. Possible values are:
Never to ignore the server reply. AppDirector checks the reply even if it has
already found a Session ID for this session. In such cases, AppDirector updates
the Session ID Persistency Table according to the information in the servers
reply.
When ID is in Request improves AppDirector performance when the Learning
Direction parameter is set to Server Reply or to Both Directions. When
AppDirector finds a Session ID in the client's request, it does not inspect the
server reply further. When a Session ID already exists in the client's request,
and it can be guaranteed that the server will not change that Session ID, you
can set this field to When ID is in Request.
Tip: Use this when Static Session IDs are used.
Default value: Never
Value Max
Length
Maximum length of Session ID value if there is no stop character.
Possible values: 1 to 256
Default value: 256
Value Offset
The offset where the Session ID value resides, within the value following the
Persistency Identifier name.
Value Offset is used when value of the Persistency Identifier is composed of 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.
Default value: 0; the value is located immediately after the Persistency Identifier
name and value separator.
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. All white space, including space,
pane, CR (carriage return), LF (line feed), etc., is always considered a Stop
Character.
Default value: ";"
Table 13: Text Match Session ID Persistency Parameters (cont.)
Pattern Match Session ID Persistency
When Session ID Persistency is configured using the Pattern Match option, AppDirector maintains
persistency by matching the binary Session ID pattern.
This table shows the Pattern Match Session ID Persistency parameters.

Inactivity
Timeout
Defines how long the association of Session ID values to servers is to be kept when
no traffic with this Session ID value is passing through AppDirector. This is similar to
Aging Time in the Client Table. Possible values: 1 to 65,535 seconds (18.2 hours).
Default value: 60 seconds.
Persistent
Layer 7
Switching
Mode
Using HTTP 1.1, defines AppDirector behavior with multiple client requests over the
same TCP connection.
Sets the status of Persistent Layer 7 Switching:
First (Request): AppDirector inspects the first request in each TCP connection,
selects a server, and forwards the request accordingly. 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.
Whenever a new server is required for further client requests, AppDirector
closes the connection with the selected server for the first request and opens a
new connection with the new server.
Maintain: AppDirector inspects all requests over a single TCP connection.
Whenever a new server is required for further client requests, AppDirector
opens a new connection with the new server without closing the connections to
all previously used backend servers.
Default value: First (Request)
Ignore Source
IP
When enabled, only the Session ID information is used for persistency. Sessions
with the same Session ID are always forwarded to the same server.
When this is 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
may be forwarded to different servers.
Default value: Enabled
Table 14: Pattern Match Session ID Persistency Parameters
L4 Protocol
Layer 4 Protocol for traffic is intercepted for Session IDs. Can be TCP / UDP
or other.
Default value: TCP
Application Port
Port for traffic intercepted for Session IDs. A value of 0 indicates that all ports
are inspected.
Default value: 0
Offset Relative To
Administrators can specify which part of the packet the offset refers to.
Possible values: IP header, IP data, Layer 4 header, or Layer 4 data.
Default value: IP header
Pattern Offset
The offset in the packet where the search starts.
Default value: 0
Pattern Mask
Mask for search pattern; also defines length of the pattern matched. This is a
hexadecimal field.
Default value: 0xffffffff, a 4-byte long pattern is used for exact match.
Maximum pattern length is 8 bytes.
Table 13: Text Match Session ID Persistency Parameters (cont.)
Static Session ID Persistency
You can also perform a static configuration. In a regular Session ID Persistency configuration,
AppDirector learns Session ID values dynamically. Static Session ID Persistency allows AppDirector
to send traffic with specified Session IDs to specific servers. When AppDirector receives a session
destined for a farm that uses Session ID Persistency, it checks the configured values in the Session
ID Persistency Table. You can configure which Session ID value indicates the selection of a specific
server.
Note: Before configuring Static Session ID Persistency, define the Session ID Persistency
scheme (see Configuring Session ID Persistency, page 112).
To set up Static Session ID Persistency:
window appears.
2. In the Farms pane, select the farm where you want to define Session ID Persistency and click
Edit, OR click Add to create a new farm. The Farm window appears.
3. Select Session IDs. The Session IDs pane appears.
4. To define Static Session ID Persistency using the text match mechanism, in the Session IDs
pane, select Text Match. The Session IDs Table with text strings appears.
Inactivity Timeout
Defines how long association of Session ID values to servers is be kept
when no traffic with this Session ID value is passing through AppDirector.
This is similar to Aging Time in the Client Table.
Possible values: 1 to 65,535 seconds (18.2 hours)
Default value: 60 seconds
Persistent Layer 7
Switching mode
Using HTTP 1.1, defines AppDirector behavior with multiple client requests
over the same TCP connection. For more information, see Note, page 109.
Set the status of the Persistent Layer 7 Switching:
First (Request): 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. Whenever a new server is required for further client
requests, AppDirector closes the connection with the server selected for
the first request and opens a new connection with the new server.
Maintain: AppDirector inspects all requests over a single TCP
connection. Whenever a new server is required for further client
requests, AppDirector opens a new connection with the new server
without closing the connections to all previously used backend servers.
Default value: First (Request)
Ignore Source IP When enabled, only the Session ID information is used for persistency.
Sessions with the same Session ID are always forwarded to the same
server.
When this is disabled, AppDirector also uses the Source IP if there is a
Session ID match. Two sessions with the same Session ID but a different
Source IP address may be forwarded to different servers.
Default value: Enabled
Table 14: Pattern Match Session ID Persistency Parameters (cont.)
5. To define Static Session ID Persistency using the pattern match mechanism, select Pattern
Match. The Session IDs Table with binary patterns appears.
6. Click Static Session ID Persistency. The Static Session ID Persistency Table window appears.
8. Click Add. A new entry appears in the Static Session ID Persistency Table.
To configure Text Match Session ID Using Regular Expression:
window appears.
2. In the Farms pane, select the farm in which you want to define Session ID Persistency and click
3. Click the Session IDs pane. The Session IDs pane appears.
4. Click Add. The Edit Session ID Persistency Table Text Match window appears.
5. Select Text Match.Text match session ID persistency parameters appear.
6. From the Lookup Mode dropdown list, select Regexp.
7. In the Persistency Identifier text box, type: /([a-zA-Z0-9]+/){2}.
8. To indicate where the persistency identifier ends, in the Stop Chars text box, type: /.
Note: All white space, including space, pane, CR (carriage return), LF (line feed), and so on,
is always considered a Stop Character.
Cookie Insert / Rewrite
With Cookie / Insert Rewrite capability, AppDirector supports client-server persistency for HTTP
where the server does not insert a cookie into the reply or when replies from all the servers contain
the same cookie. When the reply from the server is sent with no cookie, persistency is maintained
using cookies that AppDirector generates automatically and sends with the reply to the client. When
the replies from all the servers connected to AppDirector contain the same predefined cookie,
persistency is maintained using the Rewrite capability. AppDirector replaces a cookie that arrives
from the server with a cookie that enables identification of that server. AppDirector sends the new
cookie to the client with the servers reply and thus persistency is maintained
.
Notes:
>> For Cookie / Insert Rewrite, you need the Cookie Persistency License.
>> When a single client session carries more than one request, set the Persistency mode
to Overwrite to support Cookie Insertion or Overwrite on all the server responses. In
the Inspect Default mode, only the first response is handled.
Session ID Value
Value identifying a specific server in a farm.
Server Address
Server within the farm identified by the Session ID value. When
AppDirector detects traffic containing this Session ID value, it directs it
to the server specified in this parameter.
Session ID Type
Text: AppDirector searches for text strings within the packet.
Pattern: AppDirector matches binary patterns within the packets.
>> Cookie Insert / Rewrite is supported in conjunction with Persistent Layer 7 Switching,
page 109.
>> Ensure that Session ID Persistency Table size is set in the Tuning table.
Using Cookie Insert / Rewrite, AppDirector can operate in the following modes:
Cookie Insertion
Cookie Insert and remove
Cookie Rewrite
Cookie Insertion
In Cookie Insertion mode, AppDirector adds a cookie to the server reply. In subsequent requests,
this cookie is used to maintain server persistency.
To achieve persistency in the Cookie Insert mode:
1. AppDirector forwards the initial clients request for service, with no cookies set, to the most
available server in the farm.
2. The server processes this request and sends the HTTP reply to the client.
3. AppDirector receives the servers reply, inserts the cookie key and value to the reply and sends
it to the client. The new cookie value contains information regarding the selected server.
4. The reply that reaches the client contains the following cookies:
5. The cookie sent by AppDirector.
6. Other cookies sent by the server. When the server sends its own cookies, AppDirector adds the
persistency related cookie to the servers cookies and sends all the cookies to the client.
7. During subsequent requests, the clients request includes the cookie information. AppDirector
uses the cookie value within the HTTP request to identify the server associated with the cookie
and forwards the request to the initially selected server.
To configure Cookie Insertion:
1. Select the Insert Cookie for HTTP Persistency option in the farm configuration. AppDirector
automatically generates a Layer 7 modification rule for the farm with the following Layer 7
method:
2. AppDirector also generates the following entry in layer 7 methods:
Index
The lowest available
Name
Auto-G <Cookie>Farm Name (Minimum length is 1 character)
Action
Insert
Direction
Server Replies
L7 Method for
Match
Empty
L7 Method for
Action
Auto-G <Cookie>Farm Name
AppDirector also creates the appropriate Static Session ID Entries for the farm, and the Text Match
Session ID Persistency table. For details see Layer 7 Header Modification, page 243.
Cookie Insert and Remove
Some application servers utilize cookies to associate server or application instances, and their
default behavior is to search their Database/Datastore for any application/instance associated with
cookies. When unknown cookies appear, it attempts a time-consuming search, and delays the
response.
This can be solved by inserting the cookie on Reply, but removing it in subsequent Requests (on the
way to server). This can be achieved by setting the value of Insert HTTP Cookie for Persistency to
"Enable and remove on return path". AppDirector generates two L7 Modification Rules for the farm,
"Auto_G Cookie <Farm Name>" that inserts cookie on Reply before forwarding to client and "Auto_G
R Cookie <Farm Name>" that removes the same cookie from requests before forwarding them to
server.
Note:
>> Enabling Insert Cookie feature on the farm creates an automatic layer 7 modification
rule.
>> The name for the new automatic layer 7modification rule is assembled as: Auto-G
Cookie + blank + 5 first letters from the farm name. If this name already exists you
should add a 2 digits index at the end of the name.
>> This method is limited by 100 Auto methods with the same farm name.
Cookie Rewrite
In Cookie Rewrite mode, the server adds a placeholder cookie with a fixed value. AppDirector
rewrites the placeholder cookie value and uses the cookie value in subsequent requests to maintain
server persistency.
Persistency in the Cookie Rewrite mode
To achieve persistency when implementing Cookie Rewrite mode.
AppDirector forwards the initial clients request with no cookies set, to the most available server
in the farm.
The server inserts a placeholder cookie in the HTTP reply to the client.
AppDirector receives the servers reply, rewrites the placeholder cookie value and sends the
reply with the new cookie to the client. The new cookie value contains information regarding the
selected server.
During subsequent requests, the clients request includes cookie information. AppDirector uses
the cookie value within the HTTP request to identify the server associated with the cookie and
forwards the request to the initially selected server.
Name
Auto-G <Cookie>Farm Name
Method
Set-cookie
Key
<key>
Value
$Server_SID_Cookie (Minimum length is 1 character)
To configure Cookie Rewrite:
Configure Layer 7 Modification Rules. See Layer 7 Header Modification Overview, page 243.
Session ID Sharing
When the same servers are used in multiple farms, server persistency may be required when the
client accesses a different farm. With Session ID Sharing, you can share Session ID information
among multiple farms, when the same Persistency Identifier 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 Identifier and the same servers.
To enable Session ID Sharing:
window appears.
3. Select Advanced Settings > Edit Settings. The Advanced Settings window appears.
4. Select Dynamic Session ID Sharing. Click OK. Session ID Sharing is enabled.
Notes:
>> Dynamic Session ID Sharing enables or disables sharing of the Session ID information
among multiple farms using the same Dynamic Session ID. When a specific Session
ID value is learned through one farm, the same Session ID value may be used also for
server selection in other farms.
>> Dynamic Session ID Sharing is applicable only when Session ID Persistency is used for
more than one farm on an AppDirector device (see Configuring Session ID
Persistency, page 112).
DSID reply Learning in 'First' mode:
When using a DSID policy, enabling this option will cause the device to inspect each reply of each
transaction, on the same session, even if L7 Persistent Switching Mode is set to FIRST. This option is
set to disabled unless required for compatibility with older versions of AppDirector when you can set
it to Enabled.
Please leave as Disabled unless previous AppDirector version compatibility is required.
When enabled, there are two options:
inspect all server replies
inspect first reply
Setting Up Farms
This section provides information regarding configuring AppDirector server farms. This section
Server Farms, page 121
Working with Farms, page 121
Configuring Farms, page 122
Dispatch Methods, page 129
No HTTP Service Page, page 134
Server Farms
AppDirector operates with server farms rather than with individual servers. Utilizing multiple servers
organized in a farm accelerates the service response time and improves the overall performance.
An AppDirector 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 that provides multiple services can be used in multiple farms. For example, Server 3 (S3),
as shown in Figure 4-1, provides Web service in one farm and FTP service in another farm.
Figure 2: Server Participation in Multiple Farms
Working with Farms
Clients that require a service provided by a specific farm send their requests to the VIP address
associated with that farm, as shown in this figure. AppDirector selects the best available server in
the selected farm and forwards the clients request to this server using the servers IP address as
the Destination IP. The Source IP address is usually unchanged and remains the clients IP address.
Web Farm
FTP Farm
S1
S2 S3 S4 S5 S6
Figure 3: AppDirector FarmWorking Flow
Typically, the servers response to the user is also sent through AppDirector. The selected server
sends its response to the client via AppDirector using the clients IP as the Destination Address and
the Servers IP as the Source IP. When the response is received by AppDirector, the source address
is changed to the VIP of the Layer 4 Policy associated with the farm. This ensures that clients
communicate only with the Layer 4 Policy VIP.
Configuring Farms
The farm configuration process involves the following components accessed from successive tabs in
Traffic Redirection:
Traffic Settings, page 123
Farm Servers, page 135
AppDirector Farm Connectivity Checks, page 315
Session ID Persistency, page 111
DNS Persistency, page 188,
Layer 7 Header Modification, page 243
TCP Splitting, page 128
Redirection, page 182
Farm Operational Status
The Farm Operational Status OID is used to understand the farm's Admin Status and the status of
servers in the farm. The Farm Operational Status is Active or Not In Service according to the
following rules:
Request for Service
Response
Client
Client IP
Virtual IP Address
Server 1
Server 2
Farm 1
AppDirector
Server 3
Server 4
Farm 2
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
device sends a trap to indicate that.
To Check the Farm Operational Status in APSolute Insite:
1. From the main APSolute Insite window, select Device > Add Radware
Device > AppDirector. An AppDirector device icon appears in Site Explorer or on the map
(depending on the view selected).
3. Enter the devices IP address and click OK.
4. From the APSolute OS menu, select Traffic Redirection. The Traffic Redirection window
appears.
5. Select Farms. The Farms pane appears.
6. In the summary row for each farm, there is a column showing the farms current operational
status.
To configure Farms:
Device > AppDirector. An AppDirector device icon appears in Site Explorer or on the map
3. Enter the devices IP address and click OK.
4. From the APSolute OS menu, select Traffic Redirection. The Traffic Redirection window
appears.
5. Select Farms. The Farms pane appears.
6. Click Add. The Farm window appears.
7. Define a farm:
a. Select a Device (IP) from the Device drop-down menu.
b. In the Farm Name text box, set a name for the farm.
c. Mark the Active Farm checkbox to activate the farm.
d. Continue to Traffic Settings or other tabs for further farm configuration.
Traffic Settings
Traffic Settings allow you to set various AppDirector traffic settings that affect AppDirector load
balancing decisions.
To configure traffic settings parameters:
1. In the Traffic Settings tab, continue to configure the Farm by setting the following parameters:
Table 15: Basic Parameters:
Dispatch
Methods:
The method used to determine to which server in the farm traffic will be
directed:
Cyclic: Directs traffic to each healthy server one by one (round robin).
Weighted Cyclic: This method uses the Weighted Round Robin
algorithm and respects a servers weight.
Least Traffic: Directs traffic to the server with the least traffic.
Least Users Number: Directs traffic to the server with the least amount
of users.
Local Least Traffic: Directs users to the server with the least traffic, from
this farm only, for example, traffic from other farms is not considered.
Local Least Users Number: Directs users to the server with the fewest
users, from this farm only, for example, users of other farms are not
considered.
NT-1: The device starts querying the farm's servers for Windows NT
SNMP statistics. The device redirects the farm's clients to the least busy
server according to the servers' reported statistics. This method may be
used only with Windows NT servers. The parameters are considered
according to the weights configured in the first Windows NT weights
scheme.
NT-2: Similar to nt-1, but using the second weights scheme.
Private-1: When choosing this method, the device will query the farm's
servers for private SNMP parameters, as defined in the first private
weights scheme. The ratios of users on the servers will be balanced
according to the reported statistics.
Private-2: Similar to private-1, but using the second weights scheme.
Response Time: Enables Response Time load balancing. This method
load balances the servers in the farm based on the least loaded server
as calculated by the Response Level.
Note: It is necessary to create a health check bind table for each server,
in order to have the response time dispatch method working properly.
Hashing: When selected, the device performs a static Hash function in
order to select a server for this session. The input for the hash function
can be determined by the Client Table mode, it can be either source and
destination IP addresses, source and destination IP addresses and
ports, source IP only, or destination IP only. This is a static method where
the server is chosen for a session purely by the session information.
Note:
To maintain client-server persistency in the SIP sessions, the device
searches the Call-ID header in the SIP and selects one of the available
servers based on a static hash algorithm performed on the Call ID or
Request-URI.
Load Balancing criteria are available when selecting these Dispatch
Methods: NT-1, NT-2, Private-1, Private-2. Click Load Balancing. The
AppDirector Global Load Balancing Algorithms window appears.
Table 16: Protocol Related Parameters
Sessions Mode:
The method used to handle new sessions:
Regular: Each client that connects to the farm represents one entry in
the Client Table, regardless of the number of sessions that client has.
Entry Per Session: Each session a client opens is recorded in the client
table. This provides more accurate minimum-user load balancing.
Note: When a client sends HTTPS requests, it will work in Entry Per
Session mode regardless of the Sessions Mode selected by the user.
Server Per Session: Different sessions opened by a client's application
will be served by different servers, according to the load balancing
algorithms. This option enhances load balancing performance but may
hinder some applications that depend on being served by the same
server. It also may overload the device's internal tables.
Remove on Session End: After a TCP client session ends, the next
time that the device scans the Client Table (between 5 - 60 seconds) the
client's entry is removed from the Client Table. This option automatically
enables Entry Per Session.
Remove Entry in Select Server: After a TCP client session ends, the
next time that the device scans the Client Table (between 5 - 60 seconds)
the client's entry is immediately removed from the Client Table. This
option automatically enables Server Per Session.
Client Aging
Time: (sec)
The Client Aging Time parameter indicates the interval between the moment
the entry becomes inactive and until this entry is removed from the Client
Table. An entry is active as long as there is continuous traffic between the
client and the server. Every time an incoming packet or an outgoing packet is
identified by a Client Table entry, the Client Aging Time for this entry is reset.
The Client Aging Time parameter is configured per farm. For example: when
the Time value is 100 seconds, it means that if no traffic is identified by an
entry within 100 seconds, this entry is removed from the Client Table.
Close Session at
Aging
(checkbox):
When the Client Aging on the device expires for a specific session, the device
removes the Client Table entry for this session by sending a RESET to the
server to close the associated port. (This behavior is applicable to TCP
sessions).
Reset Client on
Server Failure:
Close the connection with the client as soon as a server is detected to be
down.
Transparent
Server Support:
This field allows you to enable managing AppXcel devices by the AppDirector
device. Values to choose include:
Disabled
Enabled
Front-End AppXcel Farm: If the farm is the AppXcel farm used as the
front end.
TCP Splitting: If the farm is the back-end farm.
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 will be 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.
Table 17: Global Parameters (only with Global License)
SSL ID Tracking:
Whether SSL sessions are tracked according to their session ID. You can
Enable or Disable this option.
Note: In AppDirector farms set to Server Per Session mode, you can
enable tracking of the SSL sessions. When the SSL ID Tracking
parameter is enabled, AppDirector keeps track of SSL Session IDs
in the regular Session ID table.
RADIUS
Attribute:
When persistency is based on RADIUS Attribute, if a server is not available,
the device selects another server and stores the RADIUS Attribute and
selected server in the RADIUS Attribute Table, in order to ensure persistency
for further traffic of this session.
Configuration of the RADIUS Proxy Attribute parameter overrides persistency
according to the defined RADIUS Attribute in the farm.
This behavior can be defined per farm using the RADIUS Proxy Attribute
parameter. When this parameter is set to 0, the capability is disabled. To
enable the capability, define the RADIUS Proxy Attribute value.
In the RADIUS Proxy Attribute text box, enter the RADIUS Proxy Attribute
value, which can be 0-255, where 0 means that the parameter is disabled.
Default: 0. Enter a value from 0 to 255.
RADIUS Proxy
Support:
Attribute ID of the Radius Proxy Support attribute in the packet.
Used in cases in which a RADIUS needs to forward the access/accounting
request to another RADIUS server. As a result it acts as a RADIUS proxy and
sends to request to that server. A State attribute has been added to the proxy-
ed request. The value of the attribute will include as the first 4 bytes the server
IP address in hex format.
When this parameter is set to 0, the feature is disabled.
To enable the feature, set the parameter to the required Attribute ID, which is
used to specify the server IP.
Hash Parameter
for SIP:
To maintain client-server persistency in the SIP sessions, the device searches
the Call-ID header in the SIP and selects one of the available servers based
on a static hash algorithm performed on the Call ID. If the farm is part of a URL
SuperFarm, the input function for the Hash is the requested URL.Options are
Call-ID or requestURI.
Default:Call-ID
Redirection to
HTTPS
(checkbox):
When enabled, this feature enables the device to redirect HTTP traffic to
HTTPS addresses. This is useful when sites cannot be accessed directly
using HTTP but using HTTPS. In configurations per farm, on farm can
redirect HTTP traffic to HTTP in a remote farm, and a second farm on the
same device redirects HTTP to HTTPS on a remote farm
Distribution
Threshold:
Determines the threshold of the number of users served by the local (regular)
servers; above this threshold, the device starts redirecting clients to the
remote servers and to other devices in distributed locations.
Redirection
Mode:
Defines the redirection method:
HTTP Redirection: The device uses HTTP redirection for sending
HTTP sessions to remote sites. Other sessions (not HTTP) will be
handled by the local servers only.
Triangle Redirection: All clients (including HTTP) are redirected by the
triangulation method.
HTTP & Triangle Redirection: HTTP sessions are redirected by the
HTTP redirection. All other sessions are redirected by the triangulation
method.
DNS Redirection: The device can operate as a DNS redirection, as
well as a session redirection. If the device is defined as the farm's
authoritative DNS, and DNS redirection is enabled, then the dispatching
decision takes place in the DNS resolution stage and the reply is for the
distributed site address. This mode is more efficient, because only one
request comes to the device. On the other hand, when using proximity, it
is possible that the requesting host (the server that will also receive the
redirection) is not the client, but just one of the DNS servers on the
network: thus the redirection will always be to the closest server on the
network, but not always to the server closest to the client.
DNS & HTTP & Triangle Redirection: DNS redirection is used for DNS
sessions, HTTP redirection used for HTTP sessions, and Triangle
redirection is used for all other sessions.
No Redirection: The device does not redirect clients of this farm to any
of remote or distributed servers. This also disables the dynamic
proximity mechanism for the farm.
RTSP Redirection: The device forwards an RTSP request to a remote
server or device, by responding with a standard RTSP redirection
message causing the requesting client to establish a new connection to
a remote site in order to view/hear streaming information. RTSP
redirection can be used globally, redirecting clients to remote farms or
servers, or locally, using Redirect to Self. RTSP Redirection preserves
client-server persistency of RTSP sessions when Sessions Mode Select
Server When Source Port is Different is used.
HTTP Redirection
Mode:
The device uses HTTP redirection for sending HTTP sessions to
remote sites in two ways:
IP Mode: This mode redirects HTTP sessions to an IP address.
Name Mode: This mode redirects HTTP sessions to an URL address,
for example, www.radware.com.
DNS Redirection
Fallback:
If you configure the redirection mode to DNS Redirection, and there are no
local servers available, you can configure a fallback redirection mode for
non-DNS sessions.
HTTP Redirection: The device uses HTTP redirection for sending
HTTP sessions to remote sites. Other sessions (not HTTP or DNS) will
be discarded.
Triangulation: All clients (including HTTP) are redirected by the
HTTP Redirection & Triangulation: HTTP sessions are redirected by
the HTTP redirection. All other sessions are redirected by the
DNS Only:
Table 18: Advanced Parameters
2. Click Apply > OK. Your preferences are recorded.
TCP Splitting
TCP Splitting is the ability to maintain open concurrent connections opposite all servers providing
Diameter or LDAP services, while a single connection is opened by the client.
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.
DNS Response
TTL:
Users can set the DNS TTL that the device uses in DNS replies. The DNS
TTL instructs the receiving DNS server for how long the DNS reply can be
cached.
This parameter can be set per farm, making the global parameter obsolete.
With a version upgrade, the device automatically sets the value previously
configured in the global parameter, for each farm.
Static Proximity
Entries:
The number of proximity subnets are configurable per farm. The default
number of entries is 500, and users can choose any value between 1-5000.
Static Proximity is configurable through the farm parameters. If the user
configures more entries than the available memory allows, the device prints a
message to the terminal and writes it to the log file.
Capacity
Threshold:
This is relevant to a device which is part of a distributed environment, where
traffic is redirected to it by other devices. When the capacity threshold is met,
the device reports to remote devices that it is no longer accepting further
distributed sessions. However, all traffic reaching the VIP of this farm is
directly served by this device.
Bandwidth Limit:
The dropdown list enables you to specify the bandwidth limit for the farm.
Connection Limit
Exception
(checkbox):
The device allows the Connection Limit configured for servers to be
exceeded, in AS4es where an existing client opens a new session, according
to the Client Table mode, the session should use the same server. This
applies, for example, when using EntryPerSession or Client Grouping Mask.
This option can be configured per farm.
Client NAT
Address Range
From:
The 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.
Segment Name:
Enter a name for the new segment
Sometimes you need to use a single device to load balance multiple farms,
each located on a different segment around a firewall. Here, the device must
ensure that all traffic between segments is passed through the firewall.
Dividing your network into logical segments, where a single device load
balances the traffic in a way that all segments can be inspected by a single
Firewall is called Segmentation.
Add X-
Forwarded-For to
HTTP requests:
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 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 to HTTP request parameter in the farm configuration.
An entry in this table is configured by selecting a layer 4 policy from a dropdown 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 L4 Policy (not an L7 Policy).
In the farm associated to 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) as well as the Transparent Server Support parameter of the layer 4 policy farm, cannot
be changed to values that do not meet the above conditions.
To update the farm TCP Splitting:
1. From the main window, select APSolute OS > Traffic Redirection. The Traffic Redirection
window appears.
2. Click Farms. The Farms pane appears.
3. Select a farm that holds the Front-End servers, which are the AppXcel tunnels and click Edit.
4. Click TCP Splitting. The TCP Splitting pane appears.
5. From the Backend L4 Policy Name drop-down list, select the name of the layer 4 policy that
points to the Backend server and click Add. The policy is assigned to the Front-End AppXcel
Farm.
6. Click OK and OK again.
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
Weighted Cyclic
Fewest Number of Users
Fewest Number of Users - Local
Least Amount of Traffic
Least Amount of Traffic - Local
Response Time
Hashing
Private-1 and Private-2
NT-1 AND NT-2
Cyclic
When this method is selected, AppDirector forwards the 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, refer to Servers, page 134.
Fewest Number of Users
This method 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 Clients,
page 149).
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. When this method is
selected, 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.
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 (see Chapter 10).
2. Set the farms Dispatch Method parameter to Response Time (see Response Time, page 130).
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.
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.
The use of Hashing provides the following:
Persistency on the basis of the client IP address. For each request from the same client,
AppDirector applies the same formula and receives the same output number. This ensures that
the same server within the farm is selected for all requests from the same client IP.
Using Static Hash as a Dispatch Method: When using this Dispatch Method, AppDirector
searches the Call-ID header in the SIP and selects one of the available servers based on a static
hash algorithm performed on the Call ID. See Session Initiation Protocol (SIP), page 247. The
Layer 4 Policy should either use port 5060 and UDP as the Layer 4 Protocol or specify SIP as the
application.
When Layer 7 policies with the URL method is used, Hashing ensures that all requests for the
same host name are sent to the same server. Reverse Proxy is supported by Hashing the
hostname in the URL requested by the client, regardless of the client IP address.
Server weight is taken into account as follows: when the Hash Dispatch Method is used, server
weight is limited to 10. The use of Hashing with Specific Backup Server is supported, see Backup
Server Address, page 138.
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 actually 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.
1. In the Traffic Settings pane, click Load Balancing. The Load Balancing window appears
2. Click Private Parameters.The Private Parameters pane appears.
3. Set the following parameters according to the explanations provided.
4. Click OK to apply the configuration.
Scheme
Scheme to be used: Private-1 or Private-2.
Special Check Period
Time interval between queries for the requested parameters.
Retries
Defines how many unanswered requests for a variable cause this
variable to be ignored in the load balancing decision.
Community
Community name for addressing the server.
Var1 Object ID
SNMP ID of the first private variable to check.
Var1 Mode
To measure the percentage available or the percentage utilized of the
first parameter.
Percent Free: Value of variable specified in Var1 Object ID represents
the percentage still free.
Percent Busy: Value of variable specified in Var1 Object ID represents
percentage currently busy.
Weight (for Var1
Mode)
Relational weight for considering the value of the first parameter.
Var2 Object ID
SNMP ID of second private variable to check.
Var2 Mode
Whether to measure the percentage available or the percentage utilized
of the second parameter.
Percent Free: Value of the variable specified in Var2 Object ID
represents the percentage still free.
Percent Busy: Value of variable specified in Var2 Object ID represents
the percentage currently busy.
Weight (for Var2
Mode)
Relational weight for considering the value of the second parameter.
NT-1 and NT-2
When these are selected, AppDirector queries the farm servers for Windows NT SNMP statistics and
forwards the farms clients to the least busy server according to the servers reported statistics.
To define NT-1 or the NT-2 Dispatch Method:
1. In the main window, select the device icon and click Traffic Redirection. The Traffic
2. Double-click an existing farm. The Edit Farm window appears.
3. Click Traffic Settings. The Traffic Settings pane appears.
4. From the Dispatch Method dropdown list, select the dispatch method.
5. If you selected the NT-1 or NT-2 Dispatch Method:
6. In the Traffic Settings pane, click Load Balancing. The Load Balancing Algorithms window
appears.
7. Click Windows NT. The Windows_NT pane appears.
Scheme
Scheme to be used, either NT-1 or NT-2.
Check Period
Time interval between queries for the frequently updated parameters
(the number of open sessions, amount of traffic).
Open Sessions Weight
Relational weight for considering the number of active sessions on
the server.
Incoming Traffic Weight
Relational weight for considering the amount of traffic coming to the
server.
Outgoing Traffic Weight
Relational weight for considering the 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 considering the average response time of the
server.
Users Limit Weight
Relational weight for considering the limit on the number of logged in
users on the server.
TCP Limit Weight
Relational weight for considering the limit of TCP connections to the
server.
Retries
Defines how many unanswered requests for a variable cause this
variable to be ignored in the load balancing decision.
NT Community
Community name to use when addressing the server.
No HTTP Service Page
When all servers belonging to a farm cannot be used for a specific session, AppDirector can reply to
a Web request (destined 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 servers in Not In Service or in No
New Sessions mode. No HTTP Service Page is configured for each farm. Each Web page is limited to
1K of HTML code.
Note: When configuring the No HTTP Service Page, the text of the page must be entered as
one line with no line separators.
An example HTML code for a default Web page:
<HTML>
<HEAD>
<TITLE>Service Unavailable</TITLE>
</HEAD>
<BODY>
 
Service is currently unavailable. Please try again later.


</BODY>
</HTML>
To define the default Web page:
1. In the main APSolute Insite window, right-click the AppDirector device icon and select
APSolute OS > Traffic Redirection. The Traffic Redirection window appears.
2. In the Farms pane of the Traffic Redirection window, select a farm and click Edit. The Farm
window appears.
3. Click No HTTP Service Page. The No HTTP Service Page window appears.
4. Type the text that you want to appear on the default web page and click OK.
Servers
This section presents introductory information about how AppDirector works with servers. This
Servers Introduction, page 135
Farm Servers, page 135
Physical Servers, page 140
Application Servers, page 142
Local Triangulation, page 145
Close Session At Aging, page 166
Servers Introduction
AppDirector works with farms of servers where all servers provide the same service. Farm servers
are logical entities that are associated with application services that are provided by the physical
servers that run these applications.
Adding and configuring servers in an AppDirector farm requires:
1. Adding physical servers.
2. Setting up farm servers.
Adding physical servers means adding the hardware elements to the network and defining them as
servers. This is done using APSolute Insite after the installation of the physical server.
Every service is hosted on the physical server, and as such, 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 the servers according to the way you use
their services.
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 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.
To Configure Servers
1. Configure the physical servers parameters (see Physical Servers, page 140).
2. Configure the farm servers parameters (see Farm Servers, page 135).
Farm Servers
Farm servers represent applications residing on the physical server. Each application provides a
particular service.
A farm server is identified by the name of the farm it belongs to, the IP address of the server and
the server port. The name identifies the physical server providing the service. The Server Name
parameter is configured when the physical server is added to the APSolute Insite map.
The IP address of the farm server is also defined during the process of adding a physical server to a
map. The address is defined for each farm server, so that a physical server can have several IP
addresses. A farm servers configuration has parameters that define a servers behavior within a
specified farm. The following parameters can be configured:
Server Name
Type
Server Description
Server Weight
Connection Limit
Bandwidth LimitBackup Server Address
Backup Server Address
Backup Preemption
Redirect to IP and URL
Client NAT
NAT Address Range
Admin Status
Operation Mode
Farm Name for Local Farm
To configure a Farm Server
APSolute OS > Traffic Redirection. The Traffic Redirection window appears.
2. In the Farms pane of the Traffic Redirection window, select a farm and click Edit. The Farm
window appears.
3. Select Farm Servers. The Farm Servers window appears.
4. Click Add. Set the farm server parameters according to the explanations provided (see Farm
Servers, page 135).
5. Click OK. The Farm Servers window closes, and a new entry appears in the Farm Servers table.
Server Name
The name of the server. When a user defines HTTP redirection by name and the redirect to URL field
is empty, AppDirector uses the server name for redirection.
Server Type
Regular: A local server (does not need redirection).
Local Triangulation: Local Triangulation is the ability of the local server to send the response from
a server directly to a client, bypassing AppDirector. For more information, refer to Local
Triangulation, page 145. Local Triangulation servers can also be referred to as Loopback servers.
This type of server can also be used in configuration with SIP (see Session Initiation Protocol (SIP),
page 247).
The server port must be set to None for a Local Triangulation server, unless the server is used where
traffic returns to the client via AppDirector.
Distributed AppDirector (Global): A remote AppDirector which manages another server farm in
another location. AppDirector devices exchange dynamic information about the load, and clients
requests are redirected to the nearest and most available site using various redirection methods.
For Distributed AppDirector servers, the server port can only be set to None. Multiple instances can
be configured for the regular farm servers of the local or remote AppDirector devices.
Remote Server (Global): This server type is defined for the Global solution, where AppDirector
redirects requests to servers placed at remote locations. The Remote Server is 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 or RTSP. When DNS redirection is used, all the remote servers with
the same IP are considered a single server.
Local Farm: The server is a farm configured on this AppDirector. Using this option, 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 HTTP, RTSP, SIP and DNS Redirection. For more
information, see Using Redirect to Self in Multi-Homed Environments, page 231.
The server port can be set for Local Farm servers only if the farms Application Redirection includes
HTTP, SIP or RTSP. When DNS redirection is used, all the remote servers with the same IP are
considered a single server.
Local AppDirector: This server type is used in configurations where a farm server on AppDirector 1
is AppDirector 2. The traffic from AppDirector 1 is forwarded to AppDirector 2. The information
about the load balancing of the servers on AppDirector 2 is provided using LRP.
Server Description
A free text field that allows you to type a description for each server. The Server Description can be
up to 80 characters long.
Note: The server description is not saved in the configuration file; if you export the
configuration file and then upload it, the server description is not saved.
Server Weight
The weight of the server in a farm is the servers priority or importance. 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. Server weight ranges from 1 to 10,000. A server with weight 2 receives twice the
amount of traffic as a server with weight 1. The default weight is 1.
Connection Limit
The Connection Limit is the maximum number of users that can be directed to a server for a service
provided by the farm. The number of users allowed depends on the Sessions mode selected because
it determines the number of active entries in the Client Table for sessions destined to the specific
server.
When the Entry Per Session or Server Per Session modes are selected, the number of active entries
destined to the same server is higher than in the Regular mode (see Regular, page 153).
When the Regular mode is selected, all requests from a single client IP destined to the same server
are reflected by a single entry in the Client Table (see Client Table Views, page 164).
The default value for the Connection Limit parameter is 0. When it is configured to 0, it is disabled
for this server and there is no user number limit.
Connection Limit Exception
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 Session 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.
To enable Connection Limit Exception:
1. From the main APSolute Insite window, select APSolute Insite > Traffic Redirection. The
Traffic Redirection window appears.
2. Select a farm and click Edit. The Farm window appears.
4. Check Connection Limit Exception.
Bandwidth Limit
Bandwidth Limit is the maximum amount of bandwidth in Kbps allowed for this application server. If
through traffic exceeds the configured limit for any given second, AppDirector drops excess packets.
The default value is No Limit.
Note: The limit is measured in Kbps, so 1Mbps is represented with a Bandwidth Limit of
1000. A value of 0 means that there is no Bandwidth Limit.
On a per farm basis, AppDirector can be configured with an upper threshold for Kilobytes per second
(Kbps) for a specific farm. If traffic exceeds the configured limit for any given second, AppDirector
drops the excess packets.
To define Bandwidth Limit for a farm:
1. From the main APSolute Insite window, select APSolute Insite > Traffic Redirection. The
2. Select a farm and click Edit. The Farm window appears.
4. Set the Bandwidth Limit parameter.
Backup Server Address
Using Backup servers provides a more flexible load balancing solution. One or several servers can be
configured to be activated only if regular active servers were to fail. Single machines can then act as
backup for multiple clusters.
Servers in the Backup operation mode can provide backup for the farm. When all the farm servers
are down, the backup servers are used.
The Backup Server Address parameter defines a backup for a specific regular server in the farm. If a
regular server fails, a dedicated backup server is used for all sessions of the failed server.
Default value is 0.0.0.0, indicating that no specific backup server is defined.
If an IP address is configured as a Backup Server Address for a regular server, it appears in multiple
farm servers (for example, with different server ports) in the same farm. AppDirector selects one of
the available server instances and uses it as the specified server in case of server failure. The same
logic is used when the Backup Server Address is the same as the server IP.
Note: Backup Server Address can be used with Backup Preemption.
Backup Preemption
When the specific backup server (defined by the Backup Server Address parameter) takes over and
the Backup Preemption feature is enabled, the regular server assumes control as soon as it is online
again.
When Backup Preemption is disabled, the device uses only the regular servers for load balancing. If
a regular server is Not in Service, its specific backup server joins the available servers in the farm.
This backup server is used as one of the available servers in the farm even when the regular server
is online again. Only when the specific backup server fails, the regular server assumes control. This
configuration is designed for applications where servers work in pairs, each server has its own
designated backup server, and only one of each pair is used at any time. Backup Preemption is
supported only when there is a single specific backup server configured for each regular server in
the farm.
By default, Backup Preemption is set to Enabled.
Redirect to IP and URL
The Redirect to URL and the Redirect to IP parameters are used with the global solution or in
conjunction with the Redirect to Self capability (see Using Redirect to Self in Multi-Homed
Environments, page 231).
Redirect to URL- Applies to all servers to which AppDirector redirects traffic when the Redirect By
Name parameter is enabled. You can set the name to be used when redirecting traffic to this
server. The following delimiters can be used to separate the VIP and name: " (space), ","
(comma), and ";" (semicolon).
Redirect to IP - Applies to all servers to which AppDirector redirects traffic when the Redirect By
Name parameter is disabled. This parameter specifies the IP address to which the traffic is to be
redirected.
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, see Client NAT,
page 217.
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.
NAT Address Range
When Client NAT capability is used, the NAT Address Range parameter 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. For more
information about Client NAT capability, see Client NAT, page 217.
Admin Status
Admin Status is the user-defined management status of the server that you can change at any stage
of the servers configuration or operation. The following options are available:
Enabled: The server is active and ready to reply to 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.
Shutdown: The server cannot get new requests. The existing sessions are completed according
to the Aging Time.
Tip: Before performing maintenance procedures, set Admin Status to Shutdown. Start
maintenance procedures after completion of active sessions.
Operation Mode
Farm servers can be configured with one of the following operational modes:
Regular: Server's health is checked, and if still available, the server is eligible to receive client
requests. This is the default operational mode.
Backup: 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.
FarmName for Local Farm
This parameter allows you to configure the farm whose load and availability are to be considered as
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.
The farm name selected in the Farm Name for Local Farm must be different than the Farm Name
parameter (in the server key).
Physical Servers
Before setting up a physical server, you must establish IP connectivity of the server to AppDirector
and to the host running Insite. Once IP connectivity is available, you can start adding physical
servers to the APSolute Insite map.
This table describes the setup parameters of the physical server.

Table 19: Physical Server Parameters
Server Name
The Physical Server Name defines the name of the group of farm servers
that are associated with this physical server. Adding a new server to a
farm using a Server Name that was already defined in another farm,
implies that it is the same physical server.
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.
Connection Limit
Maximum number of Client Table entries that can run simultaneously on
the physical server. This depends on the farms Sessions mode (see
Sessions Modes, page 150). When the limit is reached, new requests
are no longer directed to this server. All open sessions are continued.
When the Connection Limit parameter 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. 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.
Warm-up Time
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 weight of the
server for this period of time, at the end of which the server's weight is the
pre-configured 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.
Note: Not applicable for farm servers where the load balancing
decision is made using the Cyclic Dispatch Method.
To add a physical server to a farm:
1. From the main APSolute Insite window, select Device > Servers > Server. A server icon
appears in Site Explorer or on the map (depending on the view selected).
2. Double-click the server icon. The Server window appears.
3. Set the following physical server parameters:
4. Add a farm to AppDirector:
a. Right-click the AppDirector device icon and select APSolute OS > Traffic Redirection.
The Traffic Redirection window appears.
b. In the Farms pane, click Add. The Farm window appears.
c. Set the following parameters according to the explanations provided:
d. Click OK. The Farm window closes and the new farm appears in the Farms table.
5. Add a farm server to the farm:
a. In the Farms pane, select the farm that you have created and click Edit. The Farm window
appears.
b. In the Farm Servers pane of the Farm window, click Add. The Farm Servers window
appears. Set the parameters as follows:
IP Address
IP addresses of the server. For each farm server associated with this
physical server, you define an IP address. You can define multiple farm
servers for a single physical server. You can also define multiple IP
addresses for the same physical server.
Global Server
(checkbox)
Enables this server to be available to other remote AppDirector devices to
provide Global load balancing solution architecture (see Chapter 6).
Server Name
Enter a name for the server.
IP Address
Enter the servers IP address.
Device
AppDirector
FarmName
Farm 1
Active Farm
Selected
Mode
Active
Server Name Server 1
Type Regular
Admin Status Enabled
Table 19: Physical Server Parameters (cont.)
c. Click OK. The new server appears in the Farm Servers table.
6. Set up the physical server parameters:
a. Double-click the server icon. The Server window appears.
b. In the Settings pane, set the parameters of the physical server as explained in Table 4-1.
c. Click OK.Your preferences are recorded.
Application Servers
An application server's unique identifier - or key - includes several parameters. A single application
server may 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.
There is also a maximum number of application server connections that you can configure by setting
a trap to be sent according to if a certain percentage of the connection limit configured for the server
is exceeded.
To add an application server to a farm:
1. From the main window, select the device for which you want to configure an application server.
2. Open the Device menu and select Physical Servers. The Servers window appears.
3. Click the Application Servers tab. The Application Servers pane appears.
4. Double-click the server that you want to configure. The Server window appears.
5. In the Settings pane of the Server window, set the following parameters according to the
Server Address The address of the server
Operation Mode Regular
Server Name:
Physical server name. The IP address of the default server that is used
when no proximity information is available for a client that approaches this
farm.
Values: Remote or distributed servers configured for this farm. No
default.
Admin Status:
Enables or disables Default Redirection for the farm.
Default: Enabled
Enabled: The server is active and ready to reply to new requests for
service.
Disabled: The server is not active. When setting the Admin Status to
Disabled, the device removes all the entries relevant to this server from
the Client Table, stops sending new requests for service to this server,
and disconnects all the connected clients.
Shutdown: The server cannot get new requests for service. The existing
sessions are completed according to the Aging Time.
6. Click Apply. Your settings are saved.
7. Click the Traffic tab. The Traffic pane appears.
Recovery Time:
Period of time, in seconds, during which no data is sent to the physical
server until the server recovers from a failure. When a server's
operational status is changed from inactive to active (dynamically or
administratively), the 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. Once this time is reached, the server becomes eligible for
receive client requests.
Default: 0
When this value is set, the server is eligible immediately after changing
operational status from inactive to active.
Warm-Up Time:
The 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.
If the Warm-up Time parameter is set to 0, the server performs activation
at full weight upon a change in operational status from inactive" to
"active and after waiting the Recovery Time.
Default: 0
Note: This option is not applicable to farm servers in which the load
balancing decision is made using the Cyclic Dispatch Method.
Connection Limit:
The percentage of Application Servers Connection Limit usage above
which a trap is sent. Default value 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.
Default: 0
IP Address:
To add an IP address, enter address here and click Add.
Global Server:
Check to indicate a global server.
Device Name:
Name of device if name was assigned. If not named, its IP address
appears in the Device Name field.
Server Farm:
The name of the server's farm.
Server Address:
Servers IP address.
Admin Status:
User defined management status of the server that you can change at any
stage of the servers configuration or operation. Options include:
Enabled: The server is active and ready to reply to new requests for
service.
Disabled: The server is not active. When setting the Admin Status to
Disabled, the device removes all the entries relevant to the server from
the Client Table, stops sending new requests for service to this server and
disconnects all the connected clients.
Shutdown: The server cannot get new requests for service. The existing
sessions are completed according to the Aging Time
Operational Status:
Servers operational status.
9. Click OK to apply the settings and close the Server window.
10. Click OK to close the Servers window.
MS Terminal Servers and Session Persistency
In a terminal server-based computing environment, all application execution and data processing
occur on the server, and users can get application services from this server without installing the
applications on their computers. In a load-balanced environment, the load-balancing device needs
to ensure that when clients reconnect to the farm, they are directed to the same server as before,
thereby continuing their session and not starting a new one. In each farm of terminal servers, a list
of sessions indexed by user name is kept in the Session Directory. This directory allows clients to
reconnect to the terminal server where the disconnected session resides and resume that session.
When working in a terminal-servers environment with AppDirector, each session is first sent to one
of the servers in the farm, using the predefined Dispatch Method. Clients log in using their
Username and Password. After the server validates the login information, it queries the Session
Directory with the Username. The servers reply to the client includes a special Cookie, an RDP
(Remote Display Protocol) Cookie, which contains both login information and the correct server IP
address embedded and encrypted. This RDP Cookie is used in the next request from the client.
AppDirector ensures that the client is sent to the correct server, as indicated in the RDP Cookie.
Operation Mode:
A farm server can be configured to have one of the following operational
modes:
Regular: The server's health is checked, and as long as it is available the
server is eligible to receive client requests. This is the default operation
mode.
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.
Multiplexed Server
Port:
Port Multiplexing is a port address translation that allows the device to
accept traffic destined to a specific port and translate that traffic to a
different port before forwarding it to a server farm. When client requests
for service are destined to the configured Multiplexed Farm Port, the
device changes the destination port of the request to the configured
Multiplexed Server Port before forwarding the request to the selected
server.
Weight:
Weight of the server in a farm is the servers priority or importance. You
can specify that a particular server in a farm has more weight than other
servers. This means that 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.
The weight ranges from 1 to 10,000. A server with weight 2 receives twice
the amount of traffic as a server with weight 1. The default weight is 1.
Attach Users
Number:
Number of currently active users attached to this server.
Peak Load:
Maximum number of frames per second dispatched to server since the
last reset.
Frames Rate:
Number of frames per second dispatched to server.
You need to set the Terminal Server port that defines the TCP port over which AppDirector looks for
RDP Cookies. The default value is 0, indicating that no ports are inspected for RDP Cookies. Port
3389 is the standard Terminal Server connection port. AppDirector searches all RDP traffic for the
generally known RDP Cookie name used for this purpose, and uses the RDP Cookie Values
accordingly.The RDP Cookie may contain a TCP port number in addition to the server IP address,
indicating the TCP port on the server with which the client establishes the session. AppDirector reads
this and uses port multiplexing internally to guarantee that the session is established with the
correct TCP server port.
To define MS Terminal Servers Session Persistency:
window appears.
2. Click L 4 Policies. The Layer 4 Policies pane appears.
3. Click Add. The L4 Policies window appears.
4. In the VIP Address text box, enter the VIP address and click Add. The Add L4 Policy window
appears.
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 typically 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. 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.
L4 Protocol
TCP
L4 Port
Any
L4 Policy Name
Define a name for the policy, e.g.; Policy 1.
FarmName
From the dropdown list, select the farm that you want to include in this
policy.
Application
TS Cookie
Figure 4: AppDirector Local Triangulation Network Setup
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.
To configure Local Triangulation
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 servers in the
farm.
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.
FarmConnectivity 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 table. 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.
1 2
3
AppDirector
Servers Clients
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.
Configuring AppDirector with Local Triangulation
You can also set up an AppDirector configuration that enables servers to reply directly to the client
without passing through AppDirector. To do this the following conditions need to be met:
The servers and the router are on the same subnet as AppDirector.
The Virtual IP address of AppDirector is also the loopback address assigned to the servers.
This enables responses from the servers to go directly to the clients via the router without passing
through AppDirector.
To configure AppDirector with Local Triangulation:
Device > AppDirector. The AppDirector icon appears in Site Explorer and/or on the map
2. To connect the device, double-click the AppDirector icon. The Connect AppDirector Device
window appears.
3. Type the devices IP address: 10.1.1.10. Click OK.
4. Add the 10.1.1.20 router as the default gateway.
5. Add an interface on AppDirector:
a. Right-click the AppDirector icon and select SetUp. The SetUp window appears.
b. Click Add. The Interface window appears. Set the interface parameters as follows:
6. Add the servers:
a. Open the Device menu and select Servers > Server.
b. Double-click the Server icon. The Server window appears.
c. Set the servers name and IP as follows:
d. Click Add and then OK.
e. Add a second server. Set the servers name and IP as follows:
If Number
F-1
IP Address
100.1.1.10
Network Mask
255.255.0.0
Server Name
Server 1
IP Address
10.1.1.1
f. Click Add and then OK.
g. Add a third server. Set the servers name and IP as follows:
h. Click Add and then OK.
7. Add a farm:
a. From the APSolute OS window select Traffic Redirection. The Traffic Redirection window
appears.
b. In the Farms pane of the Traffic Redirection window, click Add. The Farm window appears.
c. Set the name of the farm as follows:
d. Click Apply. The Farm window remains open.
e. Alternatively, select the AppDirector and server that you want in the farm, and from the
main toolbar, click Link. In the same way, you can add more servers to the farm.
8. Add servers to the farm:
a. In the Farm window, click Add. The Farm Servers window appears.
b. Set servers name and type as follows:
c. Add the second server. Set the following parameters:
d. Add the third server. Set the following parameters:
9. Click OK. The Farm Servers window closes.
10. In the Traffic Redirection window, click OK.
11. Configure each servers loopback address as 100.1.1.100.
12. Add a new Layer 4 Policy to AppDirector:
Server Name
Server 2
IP Address
10.1.1.2
Server Name Server 3
IP Address 10.1.1.3
FarmName
Farm 1
Server Name
Server 1
Type
Local Triangulation
Server Name
Server 2
Type
Local Triangulation
Server Name
Server 3
Type
Local Triangulation
a. Right-click the AppDirector icon and select APSolute OS > Traffic Redirection. The
b. Click L4 Policies. The L4 Policies pane appears.
c. Click Add. The L4 Policies window appears.
d. In the VIP Address text box, enter 100.1.1.100 and click Add. The Add L4 Policy window
appears. Set the following parameters:
Clients
This section provides information about the Client Table, which stores the data about the sessions
managed by AppDirector. This section also describes how to manage and present the Client Table
and includes the following topics:
Client Table Management, page 149
Sessions Modes, page 150
Removing an Entry from the Client Table, page 156
Client Table Global Parameters, page 157
Types of Client Table Entries, page 161
Client Table Filters, page 163
Client Table Views, page 164
Reset Client on Server Failure, page 165
Client Table Management
To maintain client-server persistency in an AppDirector farm, AppDirector uses the Client Table. This
table keeps track of which clients are connected to which servers for each of the Local Farms.
When a client first approaches a farm, AppDirector checks whether an entry for this client already
exists 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 the load balancing considerations that are defined by the Dispatch Method
(see Dispatch Methods, page 129) or according to the Layer 7 Persistency info, when applicable
(see AppDirector Advanced Configuration, page 209). 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.
L4 Protocol
Any
L4 Port
Any
L4 Policy Name
Define a name for the policy; for example, Policy 1.
FarmName
From the drop-down list, select the farm that you want to include in this
policy; for example, Farm 1.
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. This table shows an example of a Client Table:
The following figure shows a farm configuration according to the Client Table shown in Table 20:,
page 150.
Figure 5: Client Table Configuration
To configure the Client Table
1. Set up the Sessions Modes (Sessions Modes, page 150).
2. Set up the Client Table Global Parameters (Client Table Global Parameters, page 157).
Now you can view the Client Table information using various view options.
Sessions Modes
To achieve maximum flexibility, AppDirector allows the Client Table to work in several modes. The
modes are configured per AppDirector farm, during the farm configuration process. The following
Sessions Modes are available:
Table 20: Client Table Example
Source
Address
Source Port
Requested
Address
Request
ed Port
FarmName
Server
Address
Server
Port
100.1.1.1 1062 100.1.1.100 80 FarmA 10.1.1.2 8080
100.1.1.2 1011 100.1.1.100 80 FarmB 10.1.1.2 8080
100.1.1.3 1079 100.1.1.100 80 FarmC 10.1.1.1 8080
www. si t e. com
www. r adwar e. com
AppDirector
Server 1 Server 2
100.1.1.
100.1.1.
100.1.1.3
Clients
Entry Per Session (default)
Regular
Server Per Session
Remove on Session End
Remove Entry in Select Server
The AppDirector farm configuration example shown here is used in the following explanation of the
Sessions Modes.
Figure 6: Typical AppDirector Application
To configure the Sessions Mode for a farm:
2. Double-click the required farm. The Farm window appears.
3. Click the Traffic Settings pane. The Traffic Settings pane appears.
4. From the Sessions Mode drop-down list, select the required mode.
5. If you selected Remove on Session End, check Close Session at Aging.
Note: Definitions of Sessions Modes per farm can be overwritten using global parameters
(see Client Table Global Parameters, page 157).
Entry Per Session
When Entry Per Session is used as the Sessions mode, AppDirector maintains Layer 3 persistency. In
the Entry Per Session 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.
AppDirector
Server 1
Server 2
Client
100.1.1. VIP Address
100.1.1.100
In the Entry Per Session 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 Session mode regardless
of the Sessions Mode selected by the user.
The Entry Per Session 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:
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.
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 the application (as long as 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 73).
Table 21: Entry Per Session Mode Client Table Entry
Source IP
Address
Source
Port
Requested
Address
Requested
Port
FarmName
Server IP
Address
Source
Port
100.1.1.1 1234 100.1.1.100 80 Farm 1 10.1.1.1 1234
AppDirector finds entries in the Client Table by running the Hash function. The input for this function
is the clients IP address, on which 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 it 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 73).
Regular
In the 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. In this case, the Client Table entry looks as
follows:
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.
All subsequent packets from the client to the virtual address with this Destination port match this
Client Table entry. The Source port used by the client is not considered. In the Regular mode, all the
sessions destined to the same VIP and port are represented by a single entry in the Client Table,
regardless of the Source port(s).
During the response process, AppDirector looks at the traffic from Server 1 (10.1.1.1) to client
(100.1.1.1) and changes the Source address from the servers IP to the VIP.
Note: The response from the server must be sent using the VIP address, and not using the
servers IP address as a Source address. Otherwise, the connection fails because the
client that sent a request to the VIP receives a response from the servers IP address.
When a Client Table entry is active, you cannot send requests directly to a server in the farm while
using the same Destination port that is specified in the active entry. AppDirector still changes the
Source address to VIP during the response. In that case, the session fails. You can send requests to
other servers in the farm since there is no active Client Table entry defined for them.
Once an entry that reflects the connection between the client and the farm is removed from the
Client Table, you can send requests for service directly to the server. If a packet is sent directly to
Server 1 (10.1.1.1) and there is no corresponding entry in the Client Table, the response from the
server is sent to the client using the IP address of the server (10.1.1.1) as the Source address.
Table 22: Regular Mode Client Table Entry
Source IP
Address
Source Port
Requested
Address
Requested
Port
FarmName
Server IP
Address
100.1.1.1 100.1.1.100 80 Farm 1 10.1.1.1
You can send a request for service to the same VIP using a different application and therefore a
different Destination port number. For example, HTTP traffic to port 80 and then FTP traffic to port
21 on the same Destination VIP. For the new request a new Client Table entry is added. The only
difference between the two entries is the Destination TCP port which is 80 for the first entry and 21
for the second entry. Any new table entries for client 100.1.1.1 to farm 100.1.1.100 automatically
use server 10.1.1.1.
Notes:
>> Once an entry is made from a client to a server, the client continues to approach the
same server, regardless of the application.
>> FTP can only work in EPS mode or higher. Therefore, when setting FTP to work in
regular mode it automatically works in Entry Per Session mode and not Regular mode.
Server Per Session
In the Server Per Session 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 approach
AppDirector are located behind a proxy server.
The Server Per Session 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 6:, page 151, the client opens six sessions to the AppDirector virtual address of
100.1.1.100 for the retrieval of a Web page, with all sessions destined to port 80. In this case, the
Client Table may resemble Table 23:, page 154. As the table shows, both servers 10.1.1.1 and
10.1.1.2 are being used for client 100.1.1.1.
The Server Per Session mode is similar to the Entry Per Session 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 Session mode, the considerations of the Client
Table size should be taken into account.
SSL ID Tracking Persistency for Server Per Session Mode
In AppDirector, with farms set to Server Per Session mode, you can enable tracking of the SSL
sessions. When the SSL ID Tracking parameter is enabled, AppDirector keeps track of SSL Session
IDs in the regular Session ID table.
Table 23: Server Per Session Mode Client Table Entry
Source IP
Address
Source Port
Requested
Address
Requested
Port
FarmName
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
The SSL ID Session Entries are aged according to the aging of the corresponding entries in the
Client Table. The Client Table is used to maintain the session information. The Session ID Table
contains SSL Session IDs that AppDirector reads from the SSL header (the part that is not
encrypted).
SSL ID Tracking helps to ensure that all the 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. The SSL ID, if destined for a particular farm, is sent
to the appropriate server. If not selected for a certain farm, it is load balanced by AppDirector and
the SSL ID table is updated.
For farms that use the Server Per Session mode where the SSL ID Tracking parameter is disabled,
AppDirector automatically uses the Entry Per Session mode for the SSL traffic (port 443). Other
traffic to the farm is reflected in the Client Table using the Server Per Session mode.
SSL Session IDs are mirrored as they are kept in the Session ID table.
The SSL ID Tracking parameter is disabled by default.
To enable SSL ID Tracking:
window appears.
2. In the Farms pane, select the farm in which you want to define Session ID Persistency and click
3. Click the Traffic Settings pane. The Traffic Settings pane appears.
4. Select the SSL ID Tracking checkbox. SSL ID Tracking is enabled.
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.
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 in the same way as the Entry Per Session mode, except
for the following:
AppDirector marks the entry for deletion from the Client Table when it detects a RST or FIN
packet between the server and the 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 Session 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 Session 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.
Select Server Per Transaction
This flag is used with Sessions Mode for farm configuration and Layer 7 Persistent Switching Mode
for Layer 4 policy configuration.
When using Select Server Per Session mode Layer 7 Persistent Switching Mode with maintain or
overwrite, this flag will decide whether the device will use a new server for each transaction
(enable) or only for each session (disable).
Removing an Entry from the Client Table
There are two ways to remove Client Table entries in AppDirector:
Client Aging Time and Automatically Deleting Client Table Entries, page 156.
Manually Deleting Client Table Entries, page 156.
Client Aging Time and Automatically Deleting Client Table Entries
AppDirector removes the relevant entries from the Client Table:
When one of the servers within a farm becomes unavailable.
When the Aging Time timer of an entry expires. The Client Aging Time parameter is set per
farm. See the procedure below.
When using the Remove On Session End/ Remove Entry In Select Server Sessions mode (see
Remove on Session End, page 155).
The Client Aging Time parameter indicates the interval between the moment the entry becomes
inactive and when the entry is removed from the Client Table. An entry is active as long as there is
continuous traffic between the client and the server.
Every time an incoming packet or an outgoing packet is identified by a Client Table entry, the Client
Aging Time for this entry is reset. The Client Aging Time parameter is configured for each farm. For
example, when the Time value is 100 seconds, it means that if no traffic is identified for an entry
within 100 seconds, this entry is removed from the Client Table.
To set up Client Aging Time:
1. From the main window, select an AppDirector device icon and click Traffic Redirection. The
2. In the Farms pane, click Add/Edit. The Farm window appears.
4. In the Client Aging Time text box, type the value (in seconds) for this parameter.
5. Possible values: 1 - 4294967295 seconds (136 years).
6. Default value: 60 seconds.
Manually Deleting Client Table Entries
A Client Table entry is automatically deleted either when its session ends or when it has been
inactive for the duration of its aging time. However you can delete Client Table entries manually.
To manually delete entries from the Client Table, you must use filters. For instructions on creating
filters, see Client Table Filters, page 163.
To delete a specific entry from the Filtered Client Table:
1. From the main window, select Device > Client Table. The Client Table window appears.
2. Select Filtered. The Filtered Client Table is displayed under the Filter field.
3. Select an entry from the table, and click Remove. The entry is deleted.
To delete all entries matching a specific filter or to count all matching entries:
1. From the main window, select Device > Client Table. The Client Table window appears.
2. Click the Filter Selection button( ). The Client Table View Filters window appears.
3. Select one or more filters.
4. To delete all Client Table entries that match the selected filters, click Delete All Matching.
5. To count all Client Table entries that match the selected filters, click Count All Matching.
6. Click OK to close the Client Table View Filters window.
7. Click OK to close the Clients window.
Client Table Global Parameters
Global Configuration of the Client Table can be performed before or after the farm configuration.
This applies to the AppDirector device, so that all the Layer 4 Policies defined on this device are
affected by Global Parameters settings.
Changing Sessions Modes Using Global Parameters
Using Global Parameters, you can set AppDirector farms to operate in Entry Per Session mode or
Server Per Session 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 Session
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 Session mode, except for the farms where Server Per Session mode
is already defined.
Enabling the Select New Server When Source Port Different parameter automatically sets all
AppDirector farms to Server Per Session 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.
Table 24:, page 158 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.

Client Table Settings
To efficiently handle the flow of traffic between clients and routers/firewalls, Radware devices
employ the Client Table. The Client Table stores client session information, which is necessary to
maintain session persistency.
When a client first approaches the device, the device checks whether an entry for this client already
exists in the Client Table. If the appropriate entry is found, the client is directed to the routers/
firewalls that appear in the Client Table. In such a case, a load balancing decision is unnecessary.
If an entry does not exist, an entry is made into the Client Table. A router/firewall is selected,
according to the load balancing considerations that are defined by the Dispatch Method, and is
recorded in the Client Table.
To configure Client parameters:
1. From the main window, double-click the device icon. The Setup window appears.
2. Click the Global tab and select Client Table Settings. Any existing parameters are displayed in
the area at the bottom of the screen.
3. Click Edit Settings. The Client Table Settings window appears.
Table 24: Global Definitions of Sessions Modes
FarmParameters
Global Parameters
Regular Entry Per Session Server Per Session
Regular
Regular Entry Per Session Server Per Session
Open NewEntry
When Source Port
Different
Entry Per Session Entry Per Session Server Per Session
Select NewServer
When Source Port
Different
Server Per Session Server Per Session Server Per Session
Open Entry When
Source Port Different
(checkbox):
When enabled, each session a client opens is recorded in the Client
Table separately. The same server serves all these entries as multiple
entries in the Client Table using a single server. This distinguishes
between sessions of the same client, which is required when the same
server is located in a few farms, when farm access or direct server
access are required simultaneously. When this feature is disabled, all of
the client's sessions are considered a single session, providing better
performance.
Client Group Masking:
Client Grouping is a mechanism that allows redirecting groups of clients
to the same server. You can specify a subnet mask such that all clients
with this subnet who access a particular farm are redirected to the same
server in that farm.
Use Source Port in
Client Table Hashing
(checkbox):
Enabling this option improves performance in installations where the
device receives clients through a NAT or proxy.
Note: The device must be rebooted after changing this option, however
this option should not be used if the device or the farms are using Open
New Entry When Source Port Different.
Note: Open New Entry When Source Port Different and Select New Server When Source Port
Different can override the per farm configuration if the relevant checkbox is marked.
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.
5. Click Ok. Your preferences are recorded.
To set Client Table Tuning parameters:
1. From the main window, double-click the device icon. The Setup window appears.
2. Click the Global tab and select Client Table Settings. The Client Table Settings window
appears.
3. Set the following tuning parameters according to the explanations provided:
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.
Select NewServer
when Source Port
Different (checkbox):
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.
UDP Session Tracking
(checkbox):
Whether UDP sessions are included in the Client Table. You can enable
or disable this option by selecting the checkbox or deselecting it.
Transport Server
Support in Delayed
Binding (checkbox):
A global parameter that determines whether the device supports
AppXcel in Proxy Transparent mode during the L7 farm selection
process, since the farm is unknown at the beginning of that process.
Available values:
Disable (default): AppXcel with Transparent Tunnel is not used
with this AppDirector device.
Enable: AppXcel with Transparent Tunnel is used with this
AppDirector device
Enable Same VIP (new with AppDirector 1.06): AppXcel with
Transparent Tunnel is used with this AppDirector device. The VIP
used for SSL traffic is the same as used for backend traffic.
Client Table
Allows you to change the size of the Client table. Enter the new value
and click OK.
The size of Layer 3 Client Table can be configured, and is defined as a
percent of the Client Table size. The default value is 20.
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.

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.
Note: The security modules provide complete protection against SYN attacks. For more
information (see SYN Flood Protection, page 366).
Possible values: 1 to 10 seconds
To set the SYN Protection Timeout:
APSolute OS > Security. The Connect & Protect Table window appears.
2. Click a cell in the SYN Flood column. The Settings pane appears under the table.
3. Click SYN Settings and click Edit Settings. The SYN Flood Protection Settings window
appears.
4. From the SYN Protection Timeout drop-down list, select a timeout value.
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.
TCP Handshake Timeout
Possible values 1 to 10 seconds
To disable UDP Session Tracking:
3. Select Client Table Settings > Edit Settings. The Client Table Settings window appears.
4. Clear the UDP Session Tracking checkbox.
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. The following types of entries are available:
Static Client Entries
Dynamic Client Entries
NAT Entries
Client NAT Entries
Outbound NAT Entries
Static Client Entries
You may need to ensure that certain clients always access a specific server on the server farm,
regardless of load balancing considerations; 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 that server is
down, AppDirector does not select a new server for this client.
Table 4-7 shows fields contained in the Static Client Table entries.
To define static clients:
1. From the main APSolute Insite window, select Device > Client Table. The Client Table window
appears.
Table 25: Static Client Table Fields
Client Address
Address from which the request is sent.
Farm
Name of the farm that provides the requested service.
Attached Server
IP address of the predefined server that always provides service to the static
client.
Last Activity
Previous request answered by the Attached Server.
Attached Time
Number of seconds that have passed since the entry was added to the Client
Table.
2. From the Device drop-down list, select the device for which you want to define a static client.
3. Select Static.
4. Ensure that the Client IP option is selected and click Add. The Add Client window appears.
6. Click OK. A new entry appears in the Client Table.
Dynamic Client Entries
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 (see Dispatch Methods, page 129) or according to persistency
considerations.
NAT Entries
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.
FarmName
Name of farm to which the client is connected.
Client Address
IP address of the client.
Attached Server
IP address of server providing the service.
Server Port:
Port on the server that provides the service. (only in AppDirector
1.0.1 and later)
Client Type:
Dynamic, ClientNAT, ServerNAT, OutboundNAT, Static, Any (default)
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.
The Aging Time parameter (see Client Aging Time and Automatically Deleting Client Table Entries,
page 156) for NAT entries is determined according to the farm configuration; the default value is 60
seconds.
For more information about Server NAT, refer to Server NAT, page 209.
Client NAT Entries
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 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.
The Aging Time parameter (see Client Aging Time and Automatically Deleting Client Table Entries,
page 156) for Client NAT entries is determined according to the farm configuration. The default
value is 60 seconds. For more information about Client NAT, refer to Client NAT, page 217.
Outbound NAT Entries
Outbound NAT client entries are created for sessions in which the Outbound NAT capability is used.
Note: Outbound NAT is supported only for TCP/UDP/ICMP traffic.
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.
The Aging Time parameter for Outbound NAT entries is determined according to the Aging Time set
by the user in the Outbound NAT Intercept table. The default value is 60 seconds. For more
information about Outbound NAT, refer to Outbound NAT, page 212.
Client Table Filters
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.
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 may be active or inactive. By default, all filters are inactive and when all filters are
inactive, an empty table is displayed.
To create and activate a Client Table filter:
appears.
2. From the Device drop-down list, select the AppDirector for which you would like to create a
Client Table filter.
3. Select Dynamic.
4. Click the Filter Selection button ( ). The Client Table View Filters window appears.
5. Select a table entry. Each entry represents a filter.
6. Click Edit. The Edit Client Table View Filters window appears.
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. For instructions on creating filters, see Client Table Filters, page 163.
The following table describes the Client Table fields.
Filter Admin Status
Select enabled to activate the filter.
Source Address From/
Source Address To
First and last IPs in the range of Source IP addresses for which to
retrieve entries from the Client Table. A Source address is the
address from which a request is sent.
Destination Address From/
Destination Address To
First and last IPs in the range of Destination IP addresses for
which to retrieve entries from the Client Table. A Destination
Address is the address to which a request is sent.
Source Port From/Source
Port To
First and last port numbers in the range of Source ports for which
to retrieve entries from the Client Table. A Source port is the port
from which a request is sent.
Destination Port From/
Destination Port To
First and last port numbers in the range of Destinations ports for
which to retrieve entries from the Client Table. A Destination port
is the port to which a request is sent.
FarmName
Name of farm providing requested service.
Server Address
Address of server providing requested service.
Client Type
Select one of the following Client Table entry types: any,
clientNAT, dynamic, outbound, serverNAT, static.
For more information, see Types of Client Table Entries,
page 161.
Table 26: Client Table Fields
Source Address
Address from which the request is sent.
Source Port
Port from which the request is sent.
Requested Address
VIP of the requested service. This is the Destination IP in the client request.
Requested Port
Requested Destination port appearing in client request.
FarmName
Name of the farm that provides the requested service.
Server Address
Address of server that provides the requested service.
Attached Time
Number of seconds that have passed since the entry was added to the
Client Table.
To view entries from the Client Table using filters:
appears.
2. From the Device drop-down list, select the device for which you want to view Client Table
entries.
3. Click . The Client Table View Filters window appears.
4. Check the Admin Status boxes of the filters that you want to use.
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.
Notes:
>> The Reset Client on Server Failure cannot be activated for farms with the Session
Mode set to Regular.
>> This feature is not supported on accelerated platforms (AS4 and AS5).
To set up Reset Client on Server Failure
1. From the main window, right-click on the device and select APSolute OS > Traffic
Redirection. The Traffic Redirection window appears.
NAT Address
Address used for NAT, if the client type is ClientNAT, ServerNat or
OutboundNat.
NAT Port
Port used for NAT, if the client type is ClientNAT or OutboundNat.
Time To Live
Period of time after which this entry is terminated, which means the gap
between the Aging Time value (see Client Aging Time and
Automatically Deleting Client Table Entries, page 156), and the time
when the session was active for the last time. This parameter is calculated
and dynamically presented by AppDirector.
Client Type
Type of Client Table entry: Dynamic, ClientNAT, ServerNat, OutboundNat,
Static.
For more information, see Types of Client Table Entries, page 161.
Session Mode The Session mode (see Sessions Modes, page 150), as it is defined in
the farm configuration: Regular, Entry Per Session, Server Per Session,
Remove on Session End, Remove Entry In Select Server.
User Data Any additional data related to the specific client entry.
Table 26: Client Table Fields
2. In the Farms pane, select Add or Edit. The Farm window appears.
4. Select the Reset Client on Server Failure checkbox.
5. Click Apply and OK. Your preferences are recorded.
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.
To enable Close Session at Aging:
1. From the main window select APSolute OS > Traffic Redirection. The Traffic Redirection
window appears.
2. In the Farms pane, select a farm and press Edit. The Farm window appears.
3. Select Traffic Settings, the Traffic Settings pane appears.
4. Select the Close Session At Aging checkbox.
Chapter 5 Configuring Global Load Balancing
This chapter describes the methods used in the global application switching schemes for global
traffic management and this includes the following sections:
Global Application Switching Overview, page 167
Proximity, page 172
Configuring Local Report Protocol, page 178
Redirection, page 182
VIP Advertising via Dynamic Routing, page 198
Routing Information Protocol, page 200
Open Shortest Path First, page 202
Border Gateway Protocol, page 203
Spanning Tree Protocol, page 204
Global Application Switching Overview
This section introduces the global traffic management methods and devices. This section includes
Global IP Traffic Management, page 167
How Global Traffic Management Works, page 168
Working with AppDirector-Global, page 170
Global 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.
Figure 7:, page 168 illustrates an example of a global load balancing scheme.
Configuring Global Load Balancing
Figure 7: Global Load Balancing Scheme
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.
How Global Traffic Management Works
An AppDirector included in a global traffic management solution continually monitors the network
and responds to permanent or transient performance conditions, directing customers to the best
available site. The two key decisions are selecting the best site and redirecting the user to this site,
if needed. A server is then selected within the local site and the best server farm is selected
according to load balancing and/or proximity considerations.
Load Balancing: To distribute the traffic load among physical sites, the load balancers in the
network must continuously update each other with health and performance indices. The main load
balancing site must know the condition of every other site to make the appropriate decisions, based
on the real-time dynamic load.
Proximity: Proximity considerations are based on network 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.
Using these considerations, AppDirector makes the load balancing decision where to redirect the
request for service.
Redirection Methods
Once a site for a particular task has been selected, the user is redirected to that site. To perform the
redirection, AppDirector uses the following methods:
DNS: DNS Redirection uses the DNS server. AppDirector responds to DNS queries for the IP
address of a specified host name that represents the service. When such a query is made,
AppDirector responds with an IP address that provides the best service for the client. This IP
address belongs to a Local Farm on AppDirector, to a remote farm on the distributed
AppDirector, or to a remote standalone server.
HTTP: For HTTP traffic, AppDirector uses the standard HTTP redirection process (code 302/
moved temporarily) to redirect the client to an alternate site. This alternate site can either be a
standalone server or another AppDirector with its own VIP.
London New York
RTSP: For RTSP traffic, AppDirector uses the standard RTSP redirection process to redirect the
client to an alternate site. This alternate site can either be a standalone server or another
AppDirector with its own VIP.
Triangulation: Triangulation is mainly intended for non-HTTP traffic. In this scheme, traffic is
sent to remote AppDirectors using specially reserved addresses. A data triangle is formed in
which the client is the first point, the redirecting AppDirector is the second point, and the
AppDirector that handles the client locally is the third point.
HTTP & Triangulation: In this combination, HTTP traffic is redirected using the HTTP
redirection method, RTSP traffic is redirected using the RTSP method, and non-HTTP traffic is
redirected using the Triangulation method.
DNS & HTTP & Triangulation: This redirection method depends on the type of incoming
traffic. The DNS method is used for DNS queries, HTTP redirection is used for HTTP traffic, RTSP
redirection is used for RTSP traffic, and the Global Triangulation method is used for other types
of traffic.
Radware Devices Used in Global Solution
To implement the global traffic management solution, you need to work with AppDirector-Global.
This device lets you redirect the incoming traffic to distributed remote servers or to remote sites that
contain AppDirector(s). To use AppDirector-Global, you need to purchase a special license.
Notes:
>> AppDirector provides only a local load balancing solution.
>> Global traffic management requires AppDirector-Global.
>> AppDirector-100 cannot participate in the global solution.
AppDirector-Global is a global redirecting device that can also handle load balancing of local servers.
Data centers with the AppDirector-Global device can be configured to participate in a global load
balancing scenario by performing load balancing for distributed sites, according to proximity, load,
and availability considerations.
To configure the global solution, AppDirector-Global uses remote servers or Distributed
AppDirectors. The remote server is a standalone server that is physically located away from the
AppDirector device. You can configure a remote server as an integral part of a server farm.
AppDirector can direct service requests to that server just as it does for a local server in the farm.
Note: The Triangulation redirection method is not applicable in a global solution
configuration that uses remote servers.
Information that AppDirector gets from the remote server regarding the current load level and
server availability is limited. The Distributed AppDirector devices inform each other about their
servers' availability, the number of clients connected, and other factors. Communication between
devices is achieved using Load Report Protocol (LRP). On the basis of this data, load balancing
decisions are made and, out of all the servers in the distributed farm, the best server is selected for
the particular request.
Proximity Report Protocol (PRP) is used when AppDirector-Global devices participate in the global
solution. PRP is used to exchange information about the proximity of clients to the AppDirector
devices.
Figure 8:, page 170 illustrates an example of a global solution with a remote server and Distributed
AppDirector.
Figure 8: Remote Server and Distributed AppDirector
Working with AppDirector-Global
AppDirector-Global performs local load balancing, and distributed load balancing, according to load
considerations. It also directs clients to the closest sites based on network proximity
considerations.
Load Balancing with AppDirector-Global
The AppDirector-Global device makes redirection decisions based on load and availability.
Information about the current load on the local AppDirector device is reported to AppDirector-Global
using the Load Report Protocol (LRP).
When setting up a global solution, you can combine AppDirector-Global and other AppDirector
devices by defining AppDirector-Global as the main device that manages a local farm of servers. The
remote farm can be configured as another server in that farm providing the same service. To define
the remote farm, you can use AppDirector, which constantly reports about current load and
availability to AppDirector-Global in the main site. If AppDirector fails, AppDirector-Global stops
redirecting traffic to the downed location until the site resumes communicating with the global
redirectors.
Note: AppDirector can send LRP reports to AppDirector-Global, but it cannot make global
load balancing decisions or redirect traffic to other locations. LRP is a UDP-based
protocol that uses UDP port 2090.
Each AppDirector-Global has its own local servers, but is also configured with the VIP address of its
partner as a remote server.
Main device:
AppDirector-Global
Server
Remote
Server
Server Server
Distributed devices:
AppDirector/AppDirector-Global
Server Server Server
Load Balancing Scheme
AppDirector-Global performs load balancing across a distributed system via the distribution
algorithm. AppDirector-Global balances traffic between multiple distributed sites according to the
load present at each site. A new request for service is redirected to the least loaded site. The local
AppDirector in this site then ensures that the least loaded server is used. AppDirector-Global
performs local load balancing between its local servers until the farm reaches the Distribution
Threshold limit. Once this threshold is reached, the distribution algorithm allows AppDirector to
redirect users to other servers or server farms distributed across the network.
Note: AppDirector-Global starts distributing immediately if all the local servers become
inactive, either operationally or administratively.
The maximum number of users that an AppDirector device can receive from other AppDirectors is
determined by the configured 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.
To set up Distribution Threshold and Capacity Threshold:
window appears.
2. Click Add. The Farm window appears in Traffic Settings mode.
3. In the Global Solutions Parameters section, in the respective text boxes, type the required
values for Distribution Threshold and Capacity Threshold.
4. Default values: Capacity Threshold - 5000; Distribution Threshold - 2500.
5. Click OK. Your preferences are recorded
Proximity Considerations
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 the latency between itself and the client. Then, AppDirector-Global requests all
other AppDirectors in the system to do the same and receives a report from each of these
AppDirectors 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.
Note: 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.
Proximity
This section discusses the methods AppDirector uses to measure proximity to redirect traffic. This
Proximity Introduction, page 172
Proximity Report Protocol (PRP), page 173
Static Proximity Database, page 173
Dynamic Proximity Database, page 174
Proximity Introduction
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
Note: PRP requests are sent to other AppDirectors in the system only if no entry for the
subnet of the client is present in the dynamic/static proximity database. If no
proximity settings are defined, server selection is done according to load
considerations.
To configure proximity
1. Before setting up proximity parameters for an AppDirector-Global device, you need to define the
Proximity mode:
a. From the main window, select APSolute OS > Traffic Redirection. The Traffic Redirection
window appears.
b. Click Redirection. The Redirection pane appears.
c. Click Add. The Traffic Redirection window appears.
d. Click Proximity. The Proximity pane appears. Select one of the following Proximity modes:
2. Define the Static Proximity Table parameters (see Static Proximity Database, page 173).
3. Define the Dynamic Proximity Table parameters (see Dynamic Proximity Database, page 174).
No Proximity
AppDirector-Global operates exactly as AppDirector.
Static Proximity
AppDirector-Global redirects according to the Static Proximity Table. The
dynamic auto learning process is off.
Full Proximity
AppDirector-Global redirects according to the static proximity settings, and
uses auto learning for subnets which are not defined as static entries.
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.
An AppDirector which receives the request from the client and is initiating the PRP queries must
always be an AppDirector-Global. Here, both proximity parameters and proximity checks must be
configured (see Dynamic Proximity Table, page 175).
An AppDirector device that receives PRP queries and responds can be either AppDirector or
AppDirector-Global and proximity checks must be configured.
Note: AppDirector-100 does not support PRP.
When a client request arrives from a class C network for which there is no proximity data,
AppDirector proceeds to gather proximity information for the class C network of the client. To gather
proximity data the Initiator AppDirector performs the following:
Sends proximity checks to this new class C network.
Sends PRP queries to all the distributed servers (servers of type Distributed AppDirector) in the
farm that provide service for 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 one of:
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 L4 policy which is associated with the relevant farm
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.
Note: After setting the new values, the device must be rebooted.
The following table describes the static proximity parameters.
Note: When the servers indicated in the Static Proximity Table are not available, then
AppDirector uses Dynamic Proximity. If no information is found in the Dynamic
Proximity Table, AppDirector uses load balancing based on server load only, like
AppDirector-Global.
To define the static proximity parameters:
window appears.
2. Click Redirection. The Redirection pane appears.
3. Click Add. The Traffic Redirection window appears.
4. In the Traffic Redirection window, click Proximity, the Proximity pane appears. Click Add. The
Static Proximity window appears.
5. In the Static Proximity window, set the proximity parameters as explained in Table 27:, page
174, and click OK. Your preferences are recorded.
Dynamic Proximity Database
The dynamic proximity database is built according to the PRP polling performed by AppDirector-
Global. The Dynamic Proximity Table server priorities are determined when PRP responses are
received from other AppDirectors in the system. When each AppDirector in the system responds
with hop count and latency calculation, AppDirector-Global aggregates the responses and
determines the top three servers for this subnet.
Note: Dynamic Proximity Table entries are kept for class C subnets.
Table 27: Static Proximity parameters
FarmName
Name of the farm to which the entry is applied.
FromAddress
IP address of the first client IP in the range.
To Address
IP address of the last client IP in the range.
Server1
IP of a Distributed AppDirector type server in the relevant farm OR
IP of a Remote Server type server in the relevant farm OR
Server2
Server3
Dynamic Proximity Table
When a client approaches AppDirector-Global and there is already a dynamic entry for the subnet of
this client in the Dynamic Proximity Table, the age of the entry is checked. If the client approaches
AppDirector-Global within the last 5% of the entrys allowed maximum age, the proximity
information for this subnet is recalculated by AppDirector-Global itself and by all other AppDirectors
in the system, through PRP.
The 5% period is calculated by subtracting the last update time from the current time, when the
client arrives. If this time is greater than 95% of the configured Proximity Aging Time, the proximity
information for this subnet is recalculated so the entry can be considered fresh. Once the proximity
information is recalculated, the last update time is adjusted accordingly. This is only done if the last
5% of the allowed age is equal to or less than one hour. For example, if the Aging Time of the
dynamic table is configured for 100 minutes and a client from the subnet approaches AppDirector-
Global during minute 96, the entry is renewed by PRP requests to other AppDirectors. If the Aging
Time is set to 100 hours, the entry is not renewed during hour 96 but only when a client approaches
the AppDirector-Global after hour 99.
If the Dynamic Proximity Table is full, it undergoes a cleanup procedure. AppDirector-Global detects
the most recently used entries and those that have not been used for some time. The oldest of the
three entries is deleted from the table to make room for new entries. If these deleted subnets
require service from AppDirector-Global again, proximity information is recalculated for them.
By default, the Dynamic Proximity Table holds up to 4,096 entries. This size is tunable and can be
increased to 32,767 entries. Increasing the Dynamic Proximity Table size may require a reduction of
the maximum allowable Client Table size.
To display the Dynamic Proximity Table:
Use the following CLI command:
AppDirector proximity dynamic table
To clear the Dynamic Proximity table:
window appears.
4. Click Proximity. The Proximity pane appears.
5. Click Clear Dynamic Proximity.
6. Press OK. Your preferences are recorded.
Dynamic Proximity Parameters
To allow AppDirector-Global to generate the dynamic database, you need to configure two sets of
parameters: Proximity parameters and Proximity checks.
The following table describes the Dynamic Proximity parameters.
AppDirector-Global uses proximity check schemes to find the best available site for a remote user.
AppDirector-Global enables you to select the checks used for proximity calculations. AppDirector has
a sophisticated process to detect network proximity.
It uses a dynamic database of clients and their proximate sites that is constantly being updated by
an auto-learning process.
To get accurate network proximity results the checking method will cross all obstacles on the way to
the client. AppDirector uses several different methods to detect the number of hops and the latency
from the client to each of the sites. Those methods ensure that the proximity check will go through
any router and firewall, ensuring maximal accuracy.
When a client approaches AppDirector, a proximity check is performed by each site and results are
communicated using the Proximity Report Protocol (PRP). Then AppDirector can redirect the client to
the closest site. When another client from the same network later approaches AppDirector, the
nearest site is now known, and the client is immediately redirected to that site.
Notes:
>> In some cases, different Intrusion Detection Systems (IDS) might consider the
proximity check packets as attacks on devices located behind IDS.
Table 28: Dynamic Proximity parameters
Main DNS:
IP address of the local primary DNS server. AppDirector avoids unnecessary
proximity calculations If the DNS server is located near AppDirector. DNS
requests that are received from this DNS server are replied to based on load
considerations only.
Backup DNS:
IP address of the local secondary DNS server. AppDirector avoids
unnecessary proximity calculations if the DNS server is located near
AppDirector. DNS requests that are received from this DNS server are
replied to based on 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 entry information by
re-executing the proximity checks.
Possible values: between 0 and 10,080 minutes (one week).
Default value: 2880 minutes (2 days).
Hops Weight:
Emphasis on number of hops between client and farms when determining
proximity. The number of hops affects the load balancing decision based on
proximity considerations.
Possible values: between 1 and 100.
Default value: 1.
Latency Weight:
Emphasis on time between client and farms when determining proximity.
The number affects the load balancing decision based on proximity
considerations.
Default value: 1.
Load Weight:
Emphasis on load of the remote server farm between the client and farms
when determining proximity. The number affects the load balancing decision
based on proximity considerations.
Default value: 1.
Proximity Table
Cleanup (Min.):
Frequency of the Proximity Table cleanup.
Default value: 0.
>> If only DNS Redirection and/or Global Triangulation are enabled as redirection
methods.AppDirector will answer the request even if the destination is or is not
already located in the dynamic proximity table.
>> This allows all AppDirector Global units to always gather information about the
proximity of all global sites to the client or DNS server.
The following table describes the proximity checks.
To configure dynamic proximity parameters:
window appears.
4. Click Proximity, the Proximity pane appears.
5. Set the Proximity parameters as explained in Table 28:, page 176.
Table 29: Proximity Checks
Proximity Checks:
Sets whether the AppDirector device is allowed to perform proximity checks
for AppDirector-Global. You can set one of the following options:
Enable: AppDirector/AppDirector-Global can serve as a Distributed server
for other AppDirector-Global devices and can perform proximity checks for
them. Those AppDirector devices appear in the Distributed Sites definitions.
Disable: No proximity checks are done for other AppDirector devices.
Default value: Enabled.
Basic Check:
Test unrelated to the application used by the user who triggered the
proximity check.
Advanced Check:
Test that simulates standard applications. IDS devices may consider such
proximity check packets as an attack.
Application
Independent Check:
Test that uses application information in a packet received from a remote
client to simulate a response.
Application Aware
Check:
Test that simulates a generic response, unrelated to the client's request.
Check Interval
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 value: 5.
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 value: 2.
Failure Notification:
After the device sends the proximity request(s), it waits for a reply. If no reply
arrives, this parameter defines whether to notify that the check has failed.
Enabled: Proximity check failure notifications are sent.
Disabled: Proximity check failure notifications are not sent.
Default: Disabled.
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 following table shows the parameters you need to set for each farm in which you want to
employ Default Redirection.

To configure Default Redirection:
window appears.
4. Click Default Redirection when No Proximity. The Distributed Site window appears.
5. Set the parameters as explained in Table 30:, page 181.
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 in this section:
Load Report Protocol (LRP), page 178
Local LRP, page 182
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.
FarmName:
Name of farm to use Default Redirection.
Priority:
Priority order in which the servers are used, where 0 indicates the highest
priority.
Default value: 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.
Admin Status:
Enables or disables Default Redirection for the farm.
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.
Figure 9: Load Reporting
Figure 9:, page 180 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).
The following table describes the parameters used to configure a Load Report entry on the Local
AppDirector.

To To configure the LRP Parameters:
1. From the main window, double-click the AppDirector icon. The SetUp window appears.
4. Configure the following parameters:
Load Report Interval: The interval (in seconds) between LRP transmissions to a Remote
AppDirector. Default: 10 seconds. This parameter is relevant for the Local AppDirector.
Table 30: LRP parameters
Distributed Farm:
Name of farm in the Remote device that includes the Local AppDirector
farm as a distributed server - in the example above, NY-Farm.
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.
L4 Policy:
Layer 4 policy configured in the Local device, that points to the farm
whose load we are reporting - in the example above, SF-Policy.
FarmName:
Name of the local farm whose load we are reporting - in the example
above, SF-Farm. This is required if the L4 policy configured for this entry
points to a L7 policy (otherwise it s automatically set to the farm name
used in the L4 policy).
Note: If no farm name configured, no report is sent.
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.
Report 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.
Backup Report
Destination Address:
IP interface of a backup Remote AppDirector device, or NAT IP for 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.
Origin 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.
Report Timeout: The time (in seconds) this device waits to receive load reports from
distributed (Local) AppDirector devices. After this timeout, the distributed device is
considered to be not responding. Default: 25 seconds. This is relevant for the Remote
AppDirector only.
To configure a Load Report:
window appears.
2. Click Distributed Site. The Distribute Site pane appears.
3. Click Add. The Edit Report Table window appears.
4. Set the parameters as explained in Table 30:, page 181.
5. Click OK. Your preferences are recorded
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.
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 Figure 10:, page 196, 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.
Redirection
This section describes methods used to redirect traffic in the global traffic management solution.
Redirection Methods, page 183
DNS Redirection, page 183
HTTP Redirection, page 192
RTSP Redirection, page 194
SIP Redirection, page 194
Proxy Redirection, page 195
Global Triangulation Redirection, page 196
VIP Advertising via Dynamic Routing, page 198
Redirection Methods
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
following methods:
DNS Redirection
HTTP Redirection
RTSP Redirection
SIP Redirection
Proxy Redirection
Global Triangulation Redirection
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.
DNS Redirection
The DNS Redirection method is based on the DNS process (see DNS Persistency, page 188). 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.
DNS Basics
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, which is
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 a question like "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:
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.
The DNS Redirection method is used when AppDirector is listed in a domain as the authoritative DNS
server for a sub-domain that has the name of the service. If the hosted site is www.radware.com,
then AppDirector needs to be an authoritative name server for www.radware.com in the name
servers responsible for company.com.
DNS Redirection Process
In DNS Redirection, DNS requests reach the AppDirector-Global IP Interface address or Virtual IP
Interface address requesting to resolve a host name to an IP address. AppDirector-Global responds
with the IP address of the most available farm or the IP address of a standalone server that is part
of this policy. AppDirector-Global can also respond with the VIP address of the closest available
AppDirector to the asking DNS machine. All the network proximity calculations and measurements
are made between the address from which the DNS request is sent and the AppDirector-Global IP
Interface address to which the request is destined.
Note: DNS queries must be sent to a device physical IP interface address or the Virtual IP
interface address, and not to the Layer 4 Policy Virtual IP. Traffic to the Layer 4 Policy
IP address is load balanced by AppDirector.
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 (that is active and not overloaded), taking into account 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.
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).
>> 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.
AppDirector DNS Configuration
AppDirector DNS configuration involves the following:
Configuring the global DNS parameters.
Configuring the farm DNS parameters.
Configuring the Virtual IP Interface Addresses Table.
Configuring the Host Names Table and Regular Expression Host Names Table.
AppDirector DNS Global Configuration
Before setting up DNS tables, you need to enable the DNS service and define its general
parameters, as shown in the following table.
To configure the Farm DNS parameters
window appears.
3. Select Redirection. The Redirection pane appears.
DNS Fallback
When DNS Redirection is enabled, you can define whether DNS is the only redirection method for
this farm, the primary redirection method or just one of the available redirection methods for the
farm. If DNS is the primary redirection method, backup redirection methods can be configured for
Table 31: General DNS parameters
DNS Service: Enables or disables the DNS service.
Respond with
Two A Records:
Enables and disables the return of two A records in the DNS
response, as follows:
Enabled: AppDirector replies to DNS queries that contain the
two best available IP addresses to provide the requested
service.
Disabled: AppDirector replies to DNS queries that include a
single IP address.
Redirection Mode: Mark the check box to enable DNS
Redirection.
DNS Response
Time TTL:
Number of seconds after which DNS
responses are cached. The default value is 0.
cases when the application request reaches a site where there are no servers available. The
redirection method used depends on the methods that are enabled for this farm. If DNS is just one
of the redirection methods for this farm, when an application request for which we have redirection
enable (HTTP for example) arrives, a redirection decision can be made even if there are available
servers.
To set DNS Redirection Type:
window appears.
4. In the Application Redirection settings, set the Application Redirection parameter to DNS
Fallback Redirection.
Virtual IP Interface Addresses Table
DNS requests are sent to an AppDirectors IP address. To provide back up for the AppDirector
device, you can define a Virtual IP Interface address associated with the redundant devices. If the
main AppDirector device fails, DNS requests are handled by the redundant device.
Each AppDirector within the global system uses a Virtual IP Interface address, which is always online
for DNS queries and for LRP communication with remote AppDirector devices. The Virtual IP
Interface address is used by the active device and in case of failure, the back up device acquires this
address.
To set up the Virtual IP Interface Addresses table parameters:
window appears.
2. Select L4 Policy. The L4 Policy pane appears.
3. Click Add. The L4 Policies window appears. In the VIP Address field, enter the required VIP
address.
4. Click Add. The Add L4 Policy window appears. Set the Application field to Virtual Interface.
Host Names Table and Regular Expression Host Names Table
For a resolution of service host names to a Layer 4 policy VIP, AppDirector can be used as a DNS
server. Using the Host Names table and the RegExp Host Names table, each host name can be
associated with a Virtual IP that represents the local IP for that host name, and with the farm that
provides the service. The farm is used to consider server load. Optionally, the host name can be
resolved to Remote Servers or Distributed AppDirectors in the farm.
Note: When the AppDirector in use is located behind a NAT device, AppDirector uses the NAT
address in the DNS reply, rather than the real VIP address.
AppDirector allows you to define explicit URLs in the Host Names table and the host names by using
the RegExp Host Names table. This table allows you to set a single definition for many similar URLs
that are hosted on the same farm. Host names in the RegExp Host Names table follow the rules of
regular expressions.
The following is an example entry in the Dynamic Host Name to IP table:
This table entry defines any URL beginning with the string "www.abc.", followed by any text using
letters and then followed by ".com", to be resolved to the IP of the configured L4 Policy my-pol or to
IP addresses of global servers defined in the farm associated with this Layer 4 Policy; i.e. a server
with the server type of Remote Server, Distributed AppDirector, or Local AppDirector.
Note: A "." in a regular expression means any single character; to indicate a ".", a "\" must
be used before the ".".
The number of entries in the RegExp Host Names table is determined by the value of the Host
Names parameter in Tuning settings (see procedure below).
When a DNS request arrives, AppDirector performs the following search procedure to resolve the
farm name:
1. Host name search in Host Name table and RegExp Host Name table: AppDirector checks
whether this host name appears in the Host Name table. If no entry exists, AppDirector
searches the Regexp Host Name table for a matching entry. If a matching entry for the host
name is not found in either table, AppDirector does not respond to the DNS request.
2. Selecting a server for the DNS reply: If an entry for the requested host name is found in one
of the tables, AppDirector selects the IP address to use for the DNS reply.
3. IP address: can be one of the following IPs:
a. A Layer 4 Policy Virtual IP.
b. A NAT Address as defined in the host name entry.
c. For a Global AppDirector: An IP address of the server with the server type of Remote Server,
Distributed AppDirector, or Local AppDirector in the farm associated with Layer 4 Policy.
4. For a Global AppDirector: If DNS Redirection is supported for the farm, AppDirector first uses
load and proximity information to determine whether the client request is be handled by local
servers or by one of the remote servers; for example, servers with the server type of Remote
Server, Distributed AppDirector, or local AppDirector. If the service is to be provided by the
above server types, AppDirector uses the IP set for the server in the DNS reply.
5. Local Service: If the service for the client request is provided locally AppDirector uses the
Virtual IP of the Layer 4 Policy, or the External NAT address if it was set in the matching host
name entry.
To set up Host Names or RegExp Host Names Table parameters:
window appears.
2. Select DNS. The DNS pane appears.
3. Select the Host Names option and set the following parameters according to the explanations
provided:
Index RegEx Host Name L4 Policy Name
External NAT
Address
1 www\.abc\.[a-z]*\.com 10.10.10.10
Host Name:
Name that represents the service. This parameter is case insensitive.
L4 Policy Name:
Address of the farm that handles the service associated with this
name.
4. Click Add. The Host Name is added to the table.
5. Click OK to apply the setup and exit.
To change the number of Host Names that can be configured:
1. In the main window, double-click the device icon. The SetUp window appears.
2. Click Global. The Global pane appears. Select Advanced Settings > Edit Settings. The
Advanced Settings window appears.
3. In the table, type the new size of the Host Names table. Default is 256.
DNS Redirection with Multihoming
To implement DNS Redirection when using AppDirector with Multihoming, you need to configure the
Host Names table or the RegExp Host Names table with the relevant URLs referring to one of the
Layer 4 Policies.
DNS Persistency
AppDirector maintains persistency for consecutive DNS queries received from the same DNS client
IP address.
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.
External NAT Address:
Device will resolve the host name to this policy's VIP or NAT address
of this VIP (External NAT address).
FarmName:
Name of the farm providing service to this host name. This must be
configured if the Layer 4 policy is connected to a Layer 7 policy (if the
layer 4 policy is not connected to layer 7 policy, this parameter is set to
the farm configured in the layer 4 policy). If no farm is selected, DNS
queries to this host name will not be answered (there is no farm to
provide the service).
It is the system administrators responsibility to configure the
appropriate farm on whose availability the decision for DNS resolution
of this host name is made
Preferred Resolve IP:
Choosing 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 that is part of the local
farm). This mode ignores the servers operation mode in the layer 4
policy farm.
Layer 4 Policy VIP is defined for this host name. In this case, if a local
server is available the device answers with the L4 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. If the specified farm server is unavailable the local layer 4 policy
VIP or the distributed or remote servers IP in the farm is selected
according to availability, load and proximity.
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.
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 256).
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 191).
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.
Note: Global DNS Persistency with Hash cannot be used in conjunction with LRP/PRP
through NAT.
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.
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.
To define DNS Persistency:
window appears.
2. In the Farms pane, select the farm and click Edit. The Farm window appears.
3. Select DNS Persistency. The DNS Persistency pane appears.
Aging Time:
Defines how many seconds an entry remains in the DNS Persistency Table.
Possible values: 1 - 4,183,142,400 seconds (136 years).
Aging Mode:
Entries in the DNS Persistency Table can be aged based on one of the
following modes:
Fixed: The entry is removed from the table after the period of time
defined by the Aging Time parameter.
Inactivity: The entry is removed from the table if, during the period
defined by the Aging Time parameter, no additional DNS queries are
received from the same DNS client IP address.
Default value: Inactivity.
Persistency Mode:
AppDirector selects the VIP used in DNS replies for the farm using one of
the following modes:
Load Balancing: Load Balancing algorithms are used, considering
load and proximity information.
Hash: Hash on client IP address is used. This mode can be used when
AppDirector devices are used in multiple sites and global DNS
Persistency is required.
Default value: Load Balancing.
Persistency
Status:
Disabled: Disables DNS Persistency.
Enabled: Enables DNS Persistency.
Note: Before enabling DNS Persistency, set tuning for the DNS
Persistency Table.
5. Click OK twice. Your preferences are recorded.
Static DNS Persistency
Static DNS Persistency operates at the farm level based on Client IP Range, meaning that requests
from client IP addresses in the same range to different host names, mapped to the same farm, are
answered using the same VIP. This VIP is called the 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 is overloaded.
When the Preferred VIP is not available and the Alternate VIP is set to Any, AppDirector dynamically
selects the VIP for the DNS reply, as explained in Working with DNS Persistency, page 189.
When the Preferred VIP is not available, AppDirector uses the configured Alternate VIP or selects
one. AppDirector records the VIP used in the DNS Persistency Table to ensure that further requests
from the same DNS client IP are replied to with the Alternate VIP, even if the Preferred VIP is back
online.
Note: To use static DNS it is necessary to first set the tuning on the device.
To define Static DNS Persistency:
window appears.
2. In the Farms pane, select the farm and click Edit. The Farm window appears.
3. Select DNS Persistency. The DNS Persistency pane appears.
Static Mode:
Disabled: Disables Static DNS Persistency.
Enabled: Enables Static DNS Persistency.
Note: Before enabling Static DNS Persistency, set tuning for the Static
DNS Persistency Table.
Grouping Mask:
Define the mask for a group of DNS client IP addresses.
Default value: 255.255.255.255, shows that persistency is maintained for
single client IP addresses.
FromClient IP
Address:
First IP address in the Client IP Range for static DNS resolution.
To Client IP
Address:
Last IP address in the Client IP Range for static DNS resolution.
Note: Before adding entries to the Static DNS Persistency Table, you must enable DNS
Persistency and Static DNS Persistency.
Tuning the DNS Persistency Tables
You can tune the size of the Static and DNS Persistency Tables.
To tune DNS Persistency Tables
window appears.
2. Select Global > DNS Settings and click Edit Settings. The DNS Settings window appears.
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 HTTP code 302 (Moved Temporarily) and redirects
the client to the relevant server.
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 with Layer 4
Policy, or to one of that farm's servers. The farm server can be a Remote
Server, a Distributed Server, or a 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:
IP address of Layer 4 Policy, or a specific server in the farm of type
Remote Server, Distributed Server, or Local Farm.
None: AppDirector does not reply to a DNS query if the preferred server is
not available.
Any: AppDirector selects a VIP when the preferred server is not available
according to configuration of DNS Persistency Mode parameter, using a
Load Balancing algorithm or Hash.
Note: AppDirector uses the IP address configured as Alternate VIP for DNS
replies only when the corresponding farm or server is available.
Dynamic DNS Table:
Number of entries for the Dynamic DNS Table.
Default value 0; Maximum value: 512,000.
Static DNS Table:
Number of the entries for the Static DNS Table.
Default value 0; Maximum value: 4,096.
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 (see
Redirect to IP and URL, page 139).
Note: When redirect by name is enabled and the redirect to URL field is empty, the device
uses the server name for redirection.
To define HTTP redirection:
window appears.
2. Click on a farm. The Farm window appears.
4. In the Application Redirection settings, from the Application Redirection dropdown list, select
Enable.
5. Select the HTTP Redirection check box and click OK.
6. If it is required to redirect by IP, set Redirect to URL to Disabled.
Redirecting HTTP Traffic for a Specified URL
Redirection is available with Remote, Distributed or Local Farm servers. You can also redirect based
on Layer 7 information.
1. For redirection to local farm servers, see Using Redirect to Self in Multi-Homed Environments,
page 231.
2. For redirection to remote or distributed servers, see Working with AppDirector-Global,
page 170.
3. To redirect HTTP traffic to a specific URL, www.site.com, to HTTPS for a specified URL
(www.site.com), the following is recommended:
4. Set the L4 Policy for the VIP / TCP / Port 80 to use a L7 Policy, see Setting Up Layer 4 Policies,
page 99.
5. Set the HTTPS Redirect To parameter in the L7 Policy entry for the URL, see Defining Layer 7
Policies, page 105.
HTTPS Redirection
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.
To define HTTPS Redirection:
window appears.
Enable.
5. Select HTTP Redirection and Redirect to HTTPS, and click OK.
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 (see Redirect to IP and URL, page 139). If the Redirect To URL
parameter is not configured, the Server Name is used instead (see HTTP Redirection, page 192).
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 231).
Notes:
>> RTSP redirection preserves the client-server persistency of RTSP sessions when the
Client Table mode Select Server When Source Port is Different is used.
>> RTSP Redirection cannot be enabled on a Farm if the Farm is associated with a Layer 7
Policy.
>> Layer 7 Policies cannot be associated with a Farm if RTSP Redirection is enabled for
that Farm.
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 (see
Redirect to IP and URL, page 139).
To define SIP redirection
window appears.
Enable.
5. Select the SIP Redirection check box, and click OK.
SIP Persistency
AppDirector incorporates the ability 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 Call-
ID, within the SIP headers. Administrators can use one of the following methods (or both) to
maintain client - server persistency:
Using Hashing as a dispatch method: When using this 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.
Using Dynamic Session IDs: When 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 (L4 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. Radware recommends setting farms Session 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.
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
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.
To define Proxy redirection:
window appears.
2. Click on a farm. The Farm window appears in Traffic Settings mode.
Enable.
5. Select the Proxy Redirection check box, and click OK.
6. To insert an X-Forwarded-For Header in the redirected traffic:
a. In the Farm window, select Traffic Settings. The Traffic Settings pane appears.
b. Select the Insert X-Forwarded-For checkbox.
c. Click OK. Your preferences are recorded.
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. Lets assume that 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 does 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 VIP of the main AppDirector as the Source IP address.
Figure 10: Global Triangulation Scheme
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:
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.
main
AppDirector
main VIP
Triangulatio
n VIP
Address
Remote
AppDirector
Remote VIP
User
This mapping must be defined in a distributed AppDirector for all existing combinations of a service
(local farm), accessible from: other sites, a main site from which the service is available and a WAN
connection through which the service is available.
When Remote AppDirector receives packets destined to 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.
Note:
>> 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.
Figure 11: Triangulation Redirection Process
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.
Main VIP
Triangulation
VIP
Address
Main VIP User IP
User IP
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 the Layer 4 Policy table. They are:
Layer 4 Policy Name parameters is Auto_Triangulation.
Policy Defined By parameter is System, for internally managed Layer 4 Policies.
To define Global Triangulation Redirection
window appears.
Enable.
5. Select the Global Triangulation Redirection check box, and click OK.
Extended LRP Security
When the Triangulation redirection method is used (see Global Triangulation Redirection, page 196),
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 is enabled by default. To have the
Triangulation VIP address and the Layer 4 Virtual IP address on different subnets, you
must disable this option.
To disable Extended LRP Security:
1. From the main window, double-click the AppDirector icon. The SetUp window appears.
2. Click Global, the Global pane appears.
4. Clear the Extended LRP Security checkbox, and click OK.
VIP Advertising via Dynamic Routing
This section describes how RIP, OSPF and BGP announcements can be used where AppDirector is
load balancing. This section includes the following topic:
Dynamic Routing, page 198
Dynamic Routing
Dynamic routing protocols, including RIP (v2), OSPF and BGP are used to announce and distribute
routing information (networks and hosts) between routers. AppDirector allows participation in RIP
and OSPF announcements, based on farm availability and the existing RIP and OSPF capabilities.
The VIP Advertising via the Dynamic Routing feature achieves redundancy by using a single
AppDirector on each site or by using a single AppDirector and a remote backup server that
participates in the RIP, OSPF or BGP environment.
Notes:
>> This feature is not available on AppDirector - 100.
>> Supported only when there is an IP interface with the same subnet as the configured
Virtual IP address.
A global system can use Anycast to announce multiple service points. There are two layers of
Anycast service:
Global Anycast: These addresses are equally announced from multiple locations allowing users
to connect to these points concurrently. Routing logic will create the load distribution between
the different service points. This type of Anycast is suitable for stateless applications only, such
as DNS and can be used to select the DNS resolving AppDirector globally.
Local Anycast: These 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 routing logic, there is a single location that serves each IP address. Local Anycast is suitable
for all protocols, as long as the primary site with active persistency is maintained.
How VIP Advertising via the Dynamic Routing Works
VIP Advertisement via Dynamic Routing is used to advertise a Farm's VIP or any other configured IP
address via RIP or OSPF. When a farm is active and its servers are available, AppDirector adds a
static routing entry in the Routing Table using the specific Virtual IP as the network address and
subnet mask 255.255.255.255 with the relevant Next Hop Router. Selecting the next hop route is
based on the following IP Interface conditions:
The IP Interface on AppDirector exists on the same subnet as the VIP NHR. This is applicable
only when a VIP NHR exists.
The IP Interface on AppDirector exists on the same subnet as the VIP. This applies only when
the VIP is on a subnet that is local to AppDirector.
The IP Interface on AppDirector exists on the same subnet as the default gateway of
AppDirector.
A static route for the device virtual IP is advertised when the AppDirector device is active. Once an
entry is added to the Routing Table, AppDirector advertises its IP or NAT addresses, if configured,
through the configurable Dynamic Routing protocols. When the farm is unavailable, AppDirector
removes the relevant static routing entry from the Routing Table and announces the removal
through RIP, OSPF or BGP. Then another server or AppDirector that participates in the RIP, OSPF and
BGP and advertises the same VIP with a lower priority, receives traffic to the VIP.
Adding a Farm-related Route
AppDirector adds a farm-related route to the Routing Table if:
There is at least one available server in the farm.
The admin status of the farm is set to Enabled.
The AppDirector is the active AppDirector for that particular farm.
When all servers are in the "No New Sessions" state, AppDirector keeps the route in the Routing
Table.
Removing a Route
AppDirector removes a route from the Routing Table if:
All the servers in the farm are not available (not in service).
The farm's Redundancy mode has changed to "Backup."
The AppDirector became a backup AppDirector for the configured farm.
To configure dynamic routing
1. Before enabling VIP Advertising via Dynamic Routing, configure RIP (see Introduction to Routing
Information Protocol, page 201), OSPF (see Introducing OSPF, page 202) or BGP (see
Introducing Border Gateway Protocol, page 203). Enable Leak Static Routes on either RIP or
OSPF.
2. Specify address to be advertised for the farm and/or AppDirector.
window appears.
4. Click Distributed Site. The Distributed Sites pane appears.
5. Select the Anycast Advertisements option button. Click Add. The Edit Advertised Route
window appears.
7. Click OK.
Routing Information Protocol
This section explains how to view RIP Parameters in AppDirector. This section includes the following
topic:
Introduction to Routing Information Protocol, page 201
L4 Policy Name:
L4 Policy Name defining the VIP to be advertised.
Host Route
Metric:
Configure the route metric to be used when adding the route to the routing
table. This can be where 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 farms in both sites are
available, clients will be routed to the selected device based on the route
metric.
For BGP, the metric is used according to AppDirector location in the BGP
network: A lower value is preferred. The Metric is used in a BGP field called
LOCAL_PREF, where a high value means a preferred site
As Local Pref parameters when advertising to a BGP peer in the same
autonomous system (iBGP) - highest value can be 65535.
As prepend number when advertising to a BGP peer in a different
autonomous system (eBGP) - highest value can be 126.
Maximum Values: RIP - 16, OSPF - 65535.
FarmName:
Advertisement is made on this farm. Layer 4 Policy VIP is only advertised if
this farm is available.
A Farm Name is required if the L4 policy points to a L7 policy, otherwise the
farm configured in the L4 policy is automatically used. If the Layer 4 policy
Application is set to Virtual IP Interface, this field is obsolete.
External NAT
Address:
Where AppDirector is installed behind a NAT device (such as LP), the
advertised IP must be not the VIP, but rather its public (NAT) address.
Introduction to 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 etc., 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.
The VIP Advertising via the Dynamic Routing feature 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 that participates in the RIP or OSPF environment. For more information about dynamic
routing, see Dynamic Routing, page 198.
To view the RI P Parameters window:
1. In the SetUp window, select Networking > RIP. The RIP parameters window appears,
containing the following options:
2. Click Edit. The Edit RIP window appears.
Leak OSPF Routes
(checkbox)
Controls redistribution of routes from OSPF to RIP. When this parameter is
enabled, all routes learned through OSPF are advertised into RIP.
Leak Static Routes
(checkbox)
Controls redistribution of routes from static routes to RIP. When this
parameter is enabled, you define all the static routes in the Routing Table.
Note: When using Leak Status Routes the Auto-Send parameters must
be disabled on the RIP interface(s).
Advertisement
Interval (checkbox)
RIP Advertisement interval. Interval at which AppDirector starts advertising
RIP messages.
Default: 30 seconds.
IP Address
IP address of the current interface.
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.
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.
Open Shortest Path First
This section explains how to view the OSPF window in AppDirector. This section includes the
following topic:
Introducing OSPF, page 202
Introducing OSPF
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 VIP Advertising via the Dynamic Routing feature allows 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 that participates in the RIP or OSPF environment. For more information about dynamic
routing, see Dynamic Routing, page 198.
The OSPF protocol is configured from the OSPF window.
To view the OSPF window
window appears.
2. Click Networking > OSPF. The OSPF window appears.
Default Metric
Metric for default route entry in RIP updates originated on this interface. 0
(Zero) indicates that no default route must be originated; here, a default
route through another router is propagated.
Virtual Distance
Define the virtual number of hops assigned to the interface. This enables
fine-tuning of the RIP routing algorithm.
Status
Define the status of the RIP in the router.
Auto Send
Enable to minimize network traffic when AppDirector is the only router on
the network.
Note: When this is 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.
Border Gateway Protocol
This section explains how to configure VIP Advertising in AppDirector. This section includes the
following topic:
Introducing Border Gateway Protocol, page 203
Introducing Border Gateway Protocol
Dynamic routing protocols, such as BGP, 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.
To configure VIP Advertising via BGP
2. Select Networking > BGP Route Injection. The BGP Route Injection window appears.
3. Select the Enable BGP Route Injection checkbox. Click OK.
4. To add or edit a BGP peer, in the BGP Route Injection window press Add or Edit. The Edit BGP
Peer window appears.
5. In the Peer pane define the BGP peers to which the announcements are sent and monitor the
connections.
Peer IP
Address
IP address of the remote peer.
Keep Alive
Time (sec)
Time interval used by AppDirector for sending keep alive messages to the remote
peer. Zero (0) indicates that keep alive messages are not sent.
Hold Time
(sec)
Defines hold time offered by AppDirector during a BGP connection establishment.
During this time, a peer must receive a keep alive or an update message from the
remote peer to consider the BGP connection active. Zero (0) indicates that keep
alive messages will not be sent by AppDirector and AppDirector will not expect
keep alive messages from the remote peer.
Connect
Retry Interval
(sec)
Interval in which AppDirector tries to re-establish BGP connection with remote
peer after TCP failure event.
Notes:
>> VIP Advertising via Dynamic Routing is not activated for each AppDirector-Global
device.
>> A VIP can be configured as an advertised VIP only on a single farm.
>> This feature is not available for AppDirector - 100.
Spanning Tree Protocol
This section explains how AppDirector supports the Spanning Tree Protocol (backwards compatible
with STP) and includes the following topics:
Spanning Tree Protocol Introduction, page 204
Spanning Tree Ports, page 205
Spanning Tree Instances, page 206
Spanning Tree Protocol Introduction
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.
Peer State
Idle: Peer is stopped.
Connect: AppDirector initiated a TCP connection towards the remote peer.
Active: Peer is waiting the duration of a connect retry interval, after failing to
establish a TCP connection to the remote peer. AppDirector also listens on
port 179 for potential incoming connections from the remote peer.
OpenSent: TCP connection has been successfully established with 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. In response, AppDirector sent a KEEPALIVE message and expects to
receive a KEEPALIVE message from the remote peer.
Established: A BGP connection is established with the remote peer.
AppDirector can exchange UPDATE messages with the remote peer.
Admin Status
Administratively Enable or Disable the peer.
Keep Alive
Time Current
Period where AppDirector must receive a keep alive or update message from
remote peer to consider the BGP connection active. Zero (0) indicates that keep
alive messages are not sent.
Hold Time
Current
Defines the time where AppDirector must receive a keep alive or an update
message from the remote peer to consider BGP connection active. Zero (0)
indicates that AppDirector does not wait for keep alive messages to consider the
peer active.
Remote AS
The remote autonomous system number.
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.
Note: STP is NOT Supported with AS1 or AS2 or OnDemand Switch 1 Platforms.
STP Global Settings
The Spanning Tree Global Settings window allows the configuration of the global parameters of the
Spanning Tree, which affects all the Spanning Tree instances running on the device.
To configure the STP Global Settings:
1. From the main window, select the AD device icon and then click, SetUp > Networking > STP
> Global Settings. The STP Global Settings pane appears, which contains the following
parameters:
2. Set the parameters according to the explanations provided.
Note: Default values will take effect only after a reboot, or when creating new instances.
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, allowing the device to forward traffic as quickly as possible. You can also
exclude any physical port from participating in the STP algorithm.
Spanning Tree Mode:
Enables or Disables Spanning Tree support per VLAN.
Default Bridge Priority:
Value represents default priority of bridge.
Default value: 32768. Optional values, 0 - 61440 in multiples of
4096. The lower the value, the higher the priority.
Default Hello Time [sec.]:
Value represents interval in seconds, between 2 BPDU packets
sent by device.
Default value: 2 seconds. Optional values, 1 - 10 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
[sec.]:
Time, in seconds, the device waits before changing the port`s
state.
Default value: 15 seconds. Optional values, 4 -- 30 seconds.
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. Optional values, 0 - 240 in multiples of 16.
To configure Spanning Tree Ports
1. From the main window, select the AD device icon and then click SetUp > Networking > STP >
STP Ports. The STP Ports pane appears.
2. Select the port you wish to edit and click Edit. The Spanning Tree Edit Port Table window
appears, which contains the following parameters:
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.
Note: Spanning Tree per VLAN is supported only when the VLANs do not share any physical
ports (each VLAN has its own physical ports).
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.
Path Cost:
This sets the spanning tree path cost for this port. Possible range is 1
to 65535, defined automatically according to port speed. You can
change this value.
Note:
Default values for Path Costs on the devices ports are influenced by
the port speed. The defaults have been changed since AppDirector
1.04 and are now aligned with the RFC.
Port Old Default New Default
Speed AppDir 1.04 AppDir 1.06
10Mbps 10 100
100Mbps 10 19
1Gbps 4 4
10Gbps 1 2
Enable STP on Port:
Enables STP support on the selected port. When disabled, physical
port does not participate in STP.
Enable Mode Fast:
When enabled, this port will change its status to forwarding state.
Port Role (Read Only:)
Indicates the port(s) role in the Spanning Tree.
Port State (Read Only):
Indicates the port(s) state in the Spanning Tree.
To configure Spanning Tree Instances
1. From the main window, select the AD device icon and then select SetUp > Networking > STP
> STP Instances. The STP Instances pane appears.
2. Select the relevant VLAN you wish to edit and click Edit. The Edit Spanning Tree Instances
window appears containing the following parameters:
3. Set the parameters based to the explanations provided.
Apply Settings to Multiple VLANs
You may apply STP Instances settings for multiple VLANs.
To apply STP Instances to multiple VLANs
1. From the main window, select the AD device icon and then click SetUp > Networking > STP >
STP Instances. The STP Instances pane appears.
2. Select the relevant VLAN you wish to edit and click Edit. The Edit Spanning Instance window
appears.
3. Click the + icon next to the VLAN dropdown menu. The Apply Settings to Multiple VLANs
window appears.
4. Either select the individual VLANs or click the Select All button to apply the STP Instance
settings to all VLANs.
VLAN:
VLAN to apply these settings to, alternatively you may apply the settings to
multiple VLANs.
Enable RSTP on
VLAN:
Enables RSTP for the selected VLAN.
Bridge Priority:
Default priority of the bridge.
Bridge Maximum
Aging [sec.]:
Maximum time, in seconds, that the device waits for a BPDU packet before it
tries to re-configure.
Hello Time
Interval [sec.]:
Interval, in seconds, between two BPDU packets sent by the device.
Forward Delay
Time [sec.]:
Time, in seconds, the device waits before changing the port's state.
Chapter 6 AppDirector Advanced
Configuration
This chapter discusses AppDirector advanced capabilities, and includes the following sections:
Network Address Translation, page 209
Multihoming, page 224
Segmentation, page 237
Layer 7 Header Modification, page 243
Session Initiation Protocol (SIP), page 247
Network Time Protocol Support, page 248
Network Address Translation
This section describes AppDirector Network Address Translation (NAT) features. This section includes
Introducing Network Address Translation, page 209
Server NAT, page 209
Outbound NAT, page 212
Client NAT, page 217
Introducing Network Address Translation
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. NATs purpose is to hide the Source IP address. AppDirector uses the
following NAT options:
Server NAT
Server NAT allows AppDirector to hide the servers IP address for outbound traffic in sessions
initiated by servers. Server NAT uses static NAT, which means that only the IP address is changed;
no port translation is done. 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.
Server NAT
Hides the servers IP address for outbound traffic in sessions initiated by servers.
Server NAT uses static NAT, where only the IP address is changed; no port
translation is done. 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.
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.
AppDirector Advanced Configuration
To enable servers with private IP addresses to initiate sessions out of their private network, you can
use the Server NAT feature. When this is 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.
Note: Server NAT sessions always use the Entry Per Session mode.
Figure 12 Server NAT Operation, page 211 shows how the servers Source IP is replaced with the
Layer 4 Policys VIP.
When the Server NAT feature is disabled, AppDirector forwards the traffic with the original source
address of the server. 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 value 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.
Notes:
>> When a server participates in multiple farms, outgoing server sessions are translated
to the VIP address of the first found Layer 4 Policy that is associated with the farm in
which this server is included.
>> Use of a specific server NAT address impacts the NAT address that is used for all
servers.
>> When mirroring is used, server NAT entries are not mirrored.
Figure 12: Server NAT Operation
To set up Server NAT:
1. From the main window, double-click the AppDirector device icon. The SetUp window appears.
3. Select NAT Settings > Edit Settings. The NAT Settings window appears.
4. To enable Server NAT, select Server NAT and set the following parameters according to the
Use Specific NAT
Address
Select the public address that replaces the original servers address.
Default value: 0.0.0.0. AppDirector selects one of the addresses in
this list (VIP addresses of the Layer 4 Policies defined on
AppDirector).
When Server Is Not-In-
Service
When traffic is received from a server with Not In Service status and
Server NAT is Enabled, the traffic can be handled as follows:
NAT: Use Server NAT.
Forward: Forward packets using routing, without Server NAT
and without adding entries to the Client Table.
Discard: Drop packets received from a server in Not In Service
status.
Internet
Router
AppDirector
Servers
100.1.1.20
VIP 10.1.1.100
10.1.1.1 10.1.1.2 10.1.1.3
Source IP 10.1.1.1
Source IP
10.1.1.100
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 traffic.
Using Outbound NAT, AppDirector can NAT not only traffic from IP addresses of servers configured in
Layer 4 Policies on 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.
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 used for outbound traffic in AppDirector/WSD/LinkProof 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.
How does Outbound NAT work?
When Outbound NAT is enabled, the traffic from Source IP addresses that belongs to servers
configured on AppDirector but which does not appear in the Outbound NAT Intercept Addresses
table, is handled according to the Server NAT configuration. When Server NAT is disabled, such
traffic is not NATed.
Note: Traffic from Source IP addresses that does not belong to servers configured on
AppDirector and do not appear in the Outbound NAT Intercept Addresses table is not
NATed; it is forwarded as is.
Outbound NAT applies only to traffic that is routed or bridged by AppDirector. Traffic destined to 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
Client NAT, page 217).
Note: Outbound NAT entries in the Client Table always use the Entry Per Session mode.
Figure 13 Outbound NAT Operation, page 213 illustrates an AppDirector Outbound NAT operation.
When Server in Regular
VLAN
Disables Server NAT for traffic on regular VLAN:
NAT and Bridge: Keeps the previous behavior, where all server
traffic uses Server NAT.
Bridge Only: AppDirector bridges the traffic and does not
perform NAT. No Server NAT entries are created in the Client
Table for traffic between VLAN ports.
Default value: NAT and Bridge.
Figure 13: Outbound NAT Operation
The AppDirector Outbound NAT operation (as shown in this example), 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.
Setting Up Outbound NAT
The process of Outbound NAT configuration has several stages. Before configuring Outbound NAT,
you need to:
1. Set the Outbound NAT Tuning parameters (see NAT Settings Tuning, page 74).
2. Globally enable the Outbound NAT feature on AppDirector.
Internet
AppDirector
Network
Outbound NAT Address 100.1.1.100
10.1.1.11 10.1.1.12
10.1.1.1
1

R
e
q
u
e
s
t
2

R
e
t
u
r
n
D
e
s
t
i
n
a
t
i
o
n

A
d
d
r
e
s
s

1
0
.
1
.
1
.
1
1
S
o
u
r
c
e

A
d
d
r
e
s
s

1
0
.
1
.
1
.
1
1
Elements
S
r
c

A
d
d
r
e
s
s

1
0
0
.
1
.
1
.
1
0
0
D
e
s
t
.

A
d
d
r
e
s
s

1
0
0
.
1
.
1
.
1
0
0
P
o
r
t

8
8
8
8
P
o
r
t

8
8
8
8
D
e
s
t
i
n
a
t
i
o
n

P
o
r
t

7
7
7
7
S
o
u
r
c
e

P
o
r
t

7
7
7
7
Setting tuning parameters must be performed prior to enabling the Outbound NAT capability. You
need to change the Tuning Table settings of the Outbound NAT Intercept Addresses table, Outbound
NAT Addresses table and Outbound NAT Ports table to have values higher than zero. You can then
enable Outbound NAT.
Once the Outbound NAT capability is enabled on AppDirector, start configuring the Outbound NAT
parameters per farm. First, you need to specify the ranges of the Source IP addresses of traffic that
you want to NAT using the Outbound NAT Intercept Addresses table. This table defines elements
with source addresses that are NATed. The maximum number of configurable intercepted addresses
depends on the value of the Outbound NAT Intercept Addresses table parameters in the Tuning
Table.
Note: Up to 128 ranges of intercepted addresses can be configured.
Next, configure the IP addresses that AppDirector uses to translate the Source IP addresses of the
selected network elements. This is configured in the Outbound NAT Address table. This table defines
the addresses that are used to perform NAT. The Outbound NAT Addresses are configured in ranges.
The maximum number of configurable Outbound NAT Addresses depends on the value of the
Outbound NAT Addresses table parameters in the Tuning Table. In a redundant AppDirector
scenario, the same Outbound NAT Addresses and Outbound Intercept NAT addresses must be
configured on both AppDirector devices. Outbound NAT Addresses must be defined with the proper
Redundancy mode, which includes the Backup address on the Backup device and the Active address
on the Active device.
Note: Outbound NAT Addresses must be unique in AppDirector configuration and cannot be
defined as Layer 4 Policy VIP addresses, Virtual Interfaces.
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, AppDirector selects any of the
configured Outbound NAT Addresses when NATing traffic from that range.
You can associate Outbound NAT Addresses with NHRs, using the VIP-NHR table. This determines
the NHR to which AppDirector sends traffic that is NATed, using Outbound NAT Addresses. You can
also set a backup NHR, or set both NHRs to be used simultaneously, using Hashing. The health of
NHRs is determined by the Health Monitoring module.
Using Outbound NAT, traffic that reaches AppDirector with a Source IP address within one of the
Intercepted Address Ranges to be routed or bridged by AppDirector (not load balanced), is NATed by
AppDirector as follows:
AppDirector NATs the Source IP address and port using the configured Outbound NAT Addresses
range for the Intercepted Address (or any NAT Address if not configured). When the reply reaches
AppDirector with the Destination IP and port of the NAT address, AppDirector replaces the packet
destination with the original address and port, before forwarding the reply.
In a redundant AppDirector scenario, the same Outbound NAT Addresses and Outbound Intercept
NAT addresses must be configured on both AppDirector devices. Outbound NAT Addresses must be
defined with the proper Redundancy mode, including the Active IP address on the main device and
the Backup IP address on the backup device. The Client Table entries of the Outbound NAT sessions
are removed after the Aging Time, which is defined for each Intercepted Addresses range. At the
end of the period of time defined in the Aging Time parameters, the entry is removed from the Client
Table.
When multiple NAT addresses are associated with a range of Intercepted Addresses, AppDirector
uses the first available port (1025) in the first NAT address for the first session, the first available
port in the second NAT address for the second session, etc.
Outbound NAT supports ICMP and traceroute initiated by internal hosts, including cases where 2
internal hosts simultaneously send ICMP or traceroute to the same destination host.
Note: Client Table mirroring for Outbound NAT entries is not supported.
To configure Outbound NAT:
4. Tune the following Outbound NAT tables:
Note: For more information about tuning the Outbound NAT tables, refer to NAT Settings
Tuning, page 74.
To enable Outbound NAT:
NAT Ports Table:
Defines number of ports to be used with each NAT IP address.
Default value: 64512.
Maximum value: 64512.
NAT Addresses
Table:
The NAT Addresses parameter specifies the number of IP addresses to be
used for NAT.
Note: Before enabling Client NAT, this parameter must be set to a value
higher than zero.
Default value: 0.
Maximum value: 128.
Outbound NAT
Addresses:
Specifies number of IP addresses to be used by Outbound NAT.
Note: Before enabling Outbound NAT, this parameter must be set to a
value higher than zero.
Default value: 0.
Maximum value: 128.
Outbound NAT
Ports per
Address:
Specifies the number of ports to be used with each NAT IP address.
Default value: 64,512.
Outbound NAT
Intercept
Addresses:
Specifies the number of IP ranges that are intercepted and NATed by
Outbound NAT.
Note: Before enabling Outbound NAT, this parameter must be set to a
value higher than zero.
Default value: 0.
4. To enable Outbound NAT, in the NAT Settings window, select Outbound NAT.
5. Click OK twice to close the windows.
window appears.
7. Click NAT. The NAT pane appears.
8. Select Outbound NAT Addresses. The Outbound NAT addresses table appears.
9. Define the range of addresses that are used to perform NAT:
Note: The maximum number of IP addresses that can be defined in the Outbound NAT
Addresses table must not be higher than the value of the Outbound NAT Addresses
table specified in the Tuning Table.
10. Click Add. The defined range appears in the table.
Tip: In a redundant AppDirector scenario, the same NAT Addresses and Outbound NAT
Addresses must be configured on both AppDirector devices.
11. In the NAT pane, select Outbound NAT Intercept Address. The Outbound NAT intercept
addresses table appears.
12. Define the range of intercepted client addresses:

Notes:
>> To NAT all outgoing traffic, configure the range:
>> 0.0.0.1 - 255.255.255.254.
>> When defining a network range, the Network Address and Broadcast Address must be
excluded from the defined range. For example the network range for 192.168.0.0/25
is: 192.168.0.1-192.168.0.254.
13. Click Add. The defined range appears in the Outbound NAT Intercept Addresses table.
14. Click Apply. The range of IP addresses of the network elements that you want to NAT is defined.
15. Click OK to close the Traffic Redirection window.
FromIP Address
The first address in the NAT Addresses range.
To IP Address
The last address in the NAT Addresses range.
Intercept FromIP Address:
First address in the Outbound NAT Intercept Addresses range.
To IP Address:
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.
Outbound NAT Addresses:
Associates a specific NAT address with the selected intercepted
range of addresses.
The default value is 0.0.0.0, any NAT address configured on the
device can be used.
16. To set AppDirector to forward all the outbound traffic that is NATed using specified Outbound
NAT Addresses via a specified NHR:
a. In the main window, double-click the NHR that you want to associate with Outbound NAT
Addresses. The Next Hop Router window appears.
b. Click Advanced Settings and then click Add. The Edit VIP NHR window appears.
c. From the VIP Address drop-down list, select the Outbound NAT Address that you want to
associate with this NHR, set backup NHR as required, and click OK.
For more information about setting NHR for VIPs, see Default Router Per Virtual IP, page 225.
Client NAT
Client NAT enables AppDirector to hide the IP addresses of clients 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.
Figure 14 Client NAT Operation, page 218 illustrates an example of Client NAT operation.
The operation proceeds as follows:
1. Client 10.1.1.11 sends a request for service to VIP on AppDirector, which is intercepted by
AppDirector.
2. AppDirector performs load balancing and selects a server to forward the clients request.
3. Once the server is selected, AppDirector replaces the clients original source address with a NAT
address (20.1.1.1 in Figure 14:, page 218) and changes the source port. AppDirector sets the
destination IP to the servers IP address, as usual.
4. The server sends a reply to the client using the NAT address 20.1.1.1 as the destination address.
5. AppDirector receives the reply packet, replaces the destination address 20.1.1.1 and port with
the clients original address 10.1.1.11 and port, and sends it to the client. AppDirector can also
add an X-Forwarded-For Header with the value of the user-configurable Client IP to the packet.
Figure 14: Client NAT Operation
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 and 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.
The next step is 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

N
A
T

t
o

C
l
i
e
n
t

S
o
u
r
c
e

A
d
d
r
e
s
s

2
0
.
1
.
1
.
1
D
e
s
t
i
n
a
t
i
o
n

A
d
d
r
e
s
s

2
0
.
1
.
1
.
1
D
e
s
t
i
n
a
t
i
o
n

A
d
d
r
e
s
s

1
0
.
1
.
1
.
1
1
S
o
u
r
c
e

A
d
d
r
e
s
s

1
0
.
1
.
1
.
1
1
Internet
Port 2 100.1.1.10
AppDirecto
Virtual IP Address
2

L
o
a
d

B
a
l
a
n
c
i
n
g
3

R
e
p
l
y
Port 1 10.1.1.10
1

R
e
q
u
e
s
t
4

R
e
t
u
r
n
Client Servers
10.1.1.1
10.1.1.2
10.1.1.1 10.1.1.1
NAT Addresses table parameters (see NAT Settings Tuning, page 74). 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 the user 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. Client NAT cannot be used for UDP sessions when UDP Session Tracking is
disabled, and UDP sessions are not inserted into the Client Table.
To configure Client NAT:
Note: Client NAT cannot be enabled globally before the Tuning parameters of the NAT
Addresses table and NAT Ports table are set to a value higher than 0.
Note: The device must be restarted for the Tuning parameter changes to take effect.
5. To enable Client NAT, select Client NAT.
Note: Once the Client NAT feature is globally enabled, it must also be specifically enabled for
each required farm server.
window appears.
8. Click NAT. The NAT pane appears.
9. Select Client NAT Intercept Addresses. The Client NAT Intercept Addresses table appears.
NAT Ports Table: Specifies number of ports used with each IP address.
Default and Maximum value: 64,512.
Note: AppDirector uses a port range that starts at 1024 and ends according
to the NAT Ports per Address value.
NAT Addresses
Table:
The NAT Addresses parameter specifies the number of IP addresses
to be used for NAT.
Default value: 1; Maximum value: 128.
Note: Before enabling the Client NAT, this parameter must be set to a value
higher than zero.
Note: Up to 128 ranges of client addresses can be configured.
10. Define the range of intercepted client addresses:

Note: To NAT all incoming traffic, configure the following range:
0.0.0.0-255.255.255.255.
11. Click Add. The defined range appears in the table.
12. Click Apply. The range of client IP addresses is defined.
13. In the NAT pane, select Client NAT Addresses. The Client NAT addresses table appears.
Note: In a redundant AppDirector scenario, the same Client NAT Intercepted Addresses
must be configured on both AppDirector devices.
14. Define the range of addresses that are used to perform NAT:

Note: The maximum number of IP addresses that can be defined in the Client NAT IP
Addresses table must not be higher than the value of Client NAT Intercept Addresses
specified in the Tuning Table.
15. In the Traffic Redirection window, click Farms. The Farms pane appears, listing all the farms
currently configured on AppDirector.
16. From the Farms list, select the farm for which you want to define NAT and click Edit. The Farm
window appears.
17. Click Traffic Settings.
18. From the NAT Addresses Range drop-down list, select the range of addresses used to translate
client requests required for this farm.
19. Click OK twice to apply the changes and close the Edit Farm window.
20. Enable Client NAT on the required servers:
a. In the Farm window, click Farm Servers. The Farm Servers pane appears, listing all the
servers defined on this farm.
b. Select the required server and click Edit. The Farm Servers window appears.
c. In the Farm Servers window, check Client NAT.
d. Optionally, you can specify a client NAT address range for each server. From the Client NAT
Address Range drop-down list, select the required range.
e. Click OK. Your preferences are recorded.
FromClient IP Address:
The first address in the Client NAT Intercept Addresses range.
To Client IP Address:
The last address in the Client NAT Intercept Addresses range.
FromClient IP Address:
The first address in the Client NAT Addresses range.
To Client IP Address:
The last address in the Client NAT Addresses range.
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:
AppDirector also generates the following entry in Layer 7 methods:

To configure the client NAT:
1. Connect to the device and define the interfaces for ports 1 and 2:
a. From the main APSolute Insite window, select View > Split View.
b. From the Device menu select Add Radware Device > AppDirector. The AppDirector icon
appears on the map.
c. Double-click the AppDirector icon. The Connect AppDirector Device window appears.
d. In the Device IP Address field, enter 10.1.1.10 and click OK.
e. Right-click the AppDirector icon and select SetUp. The SetUp window appears.
f. Click Add. The Interface window appears.
g. Set the following parameters according to the explanations provided:
Index:
The lowest available
Name:
Auto-G <Farm-Name>
Action:
Insert
Direction:
Client Requests
L7 Method for Match:
(empty)
L7 Method for Action:
Auto-G <Farm Name>X-Forwarded-For
Name:
Auto-G <Farm Name>X-Forwarded-For
Method:
Header Field
Header Field:
X-Forwarded-For
Token:
$Client_IP
h. Click OK. Your preferences are recorded.
2. Add two servers:
a. From the main window, select Device > Servers > Server. A server icon appears.

d. Click OK. Your preferences are recorded.
e. In the main window, from the Device menu select Servers > Server. A second server icon
appears.
f. Double-click the second Server icon. The Server window appears.
g. Set the following parameters according to the explanation provided:
3. Add a farm to AppDirector:
a. In the main window, select APSolute OS > Traffic Redirection. The Traffic Redirection
window appears.
b. Click Farms. The Farms pane appears.
c. Click Add. The Farm window appears.
d. Set the following parameter according to the explanation provided:
4. Add servers to the farm:
a. In the Farm window, click Add. The Farm Servers window appears.
b. In the Server Name field, select Server 1 and click OK.
c. In the Farm window, click Add. The Farm Servers window appears.
d. In the Server Name field, select Server 2 and click OK.
e. Click Ok to exit the Edit Farm window.
IF Num:
F-1
IP Address:
100.1.1.10
Network Mask:
255.255.255.0
Server Name:
Server 1
Admin Status:
Selected
IP Address:
10.1.1.55
Server Name:
Server 2
Admin Status:
Selected
IP Address:
10.1.1.66
FarmName:
Farm 1
d. In the VIP Address field, enter 100.1.1.100, and click Add. The Add L4 Policy window
appears.
e. Set the following parameters according to the explanations provided:
6. Enable the Client NAT:
a. Right-click the AppDirector device icon and select SetUp. The SetUp window appears.
b. Click Global. The Global pane appears.
c. Select NAT Settings > Edit Settings. The NAT Settings window appears.
d. Set the NAT Addresses Table parameters to 2. Click OK twice to apply the setup and exit all
windows.
e. Reboot the device. Right-click the AppDirector device icon and select Reboot.
f. Right-click the AppDirector device icon. Select SetUp. The SetUp window appears.
g. Click Global. The Global pane appears.
h. Select NAT Settings and click Edit Settings. The NAT Settings window appears.
i. Select the Client NAT checkbox. Client NAT is enabled.
7. Define the range of intercepted clients:
a. In the Traffic Redirection window, click NAT. The NAT pane appears.
b. Select Client NAT Intercept and set these parameters as follows:
8. Define the Client NAT Addresses:
a. In the Traffic Redirection window, click NAT. The NAT pane appears.
b. Select Client NAT Address and set these parameters as follows:
c. Click OK. Your preferences are recorded.
9. Define the Client NAT Addresses per farm:
a. In the Traffic Redirection window, click Farms. The Farms pane appears, listing all the farms
currently configured on AppDirector.
L4 Protocol:
TCP
L4 Port:
80
L4 Policy Name:
Define a name for the policy, for example, Policy 1.
FarmName:
From the drop-down list, select the farm to include in this policy.
FromIP Address:
10.1.1.1
To IP Address:
10.1.1.20
FromIP Address:
10.1.1.200
To IP Address:
10.1.1.201
b. Select the farm where you will define NAT and click Edit. The Farm window appears.
c. Click the Traffic Settings pane and from the NAT Addresses Range drop-down list select the
10.1.1.200 range.
d. Click Apply.
10. Enable Client NAT in the required servers:
a. In the Farm window, click the Farm Servers pane. The Farm Servers pane appears, listing all
the servers defined on this farm.
b. Select the required server and click Edit. The Farm Servers window appears.
c. Select Client NAT > OK. Repeat for servers 10.1.1.55 and 10.1.1.66.
d. Click OK twice to apply the setup and exit all windows. Your preferences are recorded.
Multihoming
This section explains AppDirector Multihoming capability as a solution to load balancing between
servers and routers of different ISPs. This section includes the following topics:
What is Multihoming, page 224
Default Router Per Virtual IP, page 225
Using Redirect to Self in Multi-Homed Environments, page 231
What is Multihoming
The AppDirector Multihoming solution is intended for networks in which AppDirector is connected to
multiple ISPs. In this configuration, incoming traffic from ISPs is load balanced by AppDirector
between the farm servers.
Using Multihoming, AppDirector can simultaneously use multiple ISPs for inbound traffic.
AppDirector-Global can use proximity and load information when selecting the ISP used for a client.
AppDirector then uses redirection methods to redirect the session to a VIP that corresponds to the
relevant ISP. The following figure illustrates the Multihoming scheme.
Figure 15: Multihoming with AppDirector
Default Router Per Virtual IP
When the Default Router Per VIP configuration is used, you can define a different default router for
each Virtual IP. The VIP's default router is used for any type of traffic forwarded by AppDirector from
this VIP or generated by AppDirector in respect to this VIP, such as:
DNS answers.
LRP/PRP communication.
Client proximity checks.
HTTP redirection instructions.
Triangulated packets.
When using the Default Router Per VIP capability, a router can be configured for each Virtual IP on
AppDirector, including Virtual IP Interfaces and Outbound NAT ranges. For each VIP, you can set a
default gateway and a backup default gateway.
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. Before
defining the VIP NHR table, you need to add a new NHR to the network and set up the general NHR
parameters.
AppDirector
Farm 1
Farm 2
Farm 3
Router 1 Router 2 Router 3
VIP1 VIP2
VIP3

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 in the following
table:

Table 32: General NHR parameters
NHR IP Address:
Address of the selected NHR.
Administrative Status
Enabled:
The user-defined management status of the NHR:
Enabled: 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: 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 will
be labeled Not-in-Service.
Default: Disabled.
Path Health CheckIP:
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 value: 0.0.0.0.
Check Interval:
How often AppDirector polls the NHR (in seconds).
Default value: 10.
Check Retries:
The number of polling attempts that are made before a NHR is considered
inactive.
Default value: 3.
Table 33: VIP NHR Table parameters
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 value: 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 value: 1.
Backup NHR IP
Address:
The backup router for this Virtual IP.
Default value: 0.0.0.0, no NHR is set.
Backup NHR Weight:
Backup weight that AppDirector considers when it distributes sessions of
Virtual IP among the NHRs.
Default value: 1.
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.
To configure Default Router per VIP:
1. Define the interfaces for Ports 1 and 2:
a. From the main APSolute Insite window, select View > Split View.
b. From the Device menu select Add Radware Device > AppDirector. The AppDirector icon
appears on the map.
c. Double-click the AppDirector device icon. The Connect AppDirector Device window
appears.
d. In the Device IP Address field, enter 201.1.1.10.
e. Right-click the AppDirector device icon and select SetUp. The SetUp window appears.
i. In the SetUp window, click Add. The Interface window appears.
j. Set the following parameters according to the explanations provided:
No Route Action:
If both routers set for a VIP are down, AppDirector behaves as follows:
Discard: Discards the packet.
Use Regular Routing: Uses the Routing Table.
Default value: Use Regular Routing.
NHR Load Sharing:
Enables or disables load sharing between the primary and backup NHRs,
as follows:
L3 Hashing: Traffic is sent through both primary NHR and backup
NHR. Load sharing is based on Layer 3 information (IP addresses).
L4 Hashing: Traffic is sent through both primary NHR and backup
NHR. Load sharing is based on Layer 4 information (IP addresses and
ports).
Disabled: Traffic is sent through primary NHR only.
Default: Disabled.
IF Num:
F-1
IP Address:
202.2.2.10
Network Mask:
255.255.255.0
IF Num:
F-2
IP Address:
10.1.1.10
Network Mask:
255.255.255.0
Table 33: VIP NHR Table parameters (cont.)
k. Click OK. Your preferences are recorded.
2. Define the default gateway:
a. Right-click the AppDirector device icon and select SetUp. The SetUp window appears.
b. Click Networking and select Routing Table. The Routing Table window appears.
c. Click Add. The Edit Physical Route window appears.
d. Set the following parameters according to the explanations provided:
3. Add the first server to the map:
a. From the main window, select Device > Servers > Server. A server icon appears.
d. Click Add and OK.Your preferences are recorded.
4. Add the second server to the map:
a. From the main window, select Device > Servers > Server. A second server icon appears.
b. Double-click the server icon. The Server window appears.
d. Click Add and OK. Your preferences are recorded.
5. Add a server farm to AppDirector:
window appears.
e. Click Traffic Settings. The Traffic Settings pane appears.
f. Set the following parameter according to the explanations provided:
Destination IP Address:
0.0.0.0
Network Mask:
0.0.0.0
Next Hop:
201.1.1.20
IF Number:
F-1
Server Name:
Server 1
IP Address:
10.1.1.1
Server Name:
Server 2
IP Address:
10.1.1.2
FarmName:
Farm 1
g. Click OK twice to return to the main window.
a. Right-click the AppDirector device icon and select APSolute OS > Traffic Redirection.
The Traffic Redirection window appears.
d. In the VIP Address text box, enter 201.1.1.100 and click Add. The Add L4 Policy window
appears.
f. Click OK twice to return to the Traffic Redirection window.
7. Add the second server farm to AppDirector:
a. In the Traffic Redirection window, click Farms. The Farms pane appears.
b. Click Add. The Farm window appears.
c. Set the following parameter according to the explanation provided:
d. Click OK to return to the Traffic Redirection window.
a. Click L4 Policies. The L4 Policies pane appears.
b. Click Add. The L4 Policies window appears.
c. In the VIP Address field, enter 202.2.2.100 and click Add. The Add L4 Policy window
appears.
e. Click OK twice to return to the Traffic Redirection window.
9. Add Server 2 to Farm 1:
a. Click Farms. The Farms pane appears.
Dispatch Method:
Least amount of traffic-Local
L4 Protocol:
TCP
L4 Port:
80
L4 Policy Name:
Policy 1
FarmName:
Farm 1
FarmName:
Farm 2
L4 Protocol:
TCP
L4 Port:
80
L4 Policy Name:
Policy 2
FarmName:
Farm 2
b. Select the Farm 1 entry and click Edit. The Farm window appears.
c. Click Add. The Farm Servers window appears.
c. In the Farm window, click Add. The Farm Servers window appears.
c. Click Add. The Farm Servers window appears.
12. Add the first router to the map:
a. From the main window, select Device > NHR. An NHR icon appears on the map.
b. Double-click the NHR icon. The Next Hop Router window appears.
13. Configure Router 1 on AppDirector:
a. Holding the Control key, select both the AppDirector device icon and the Router 1 icon.
b. From the main toolbar, click the Link Device button ( ). The Next Hop Router window
appears.
c. Select Advanced Settings.
d. In the Advanced Settings pane, click Apply and Add.
14. Add the second router to the map:
a. From the main window, select Device > NHR. An NHR icon appears on the map.
Server Name:
Server 2
Server Name:
Server 1
Server Name:
Server 2
Next Hop Router Name:
Router 1
IP Address:
201.1.1.20
d. Click Add and OK.
a. Holding the Control key, select both the AppDirector device icon and the Router 1 icon.
b. From the main toolbar, click the Link Device button ( ). The Next Hop Router window
appears.
c. Select the Advanced Settings pane.
d. In the Advanced Settings pane, Apply and Add.
e. Click OK.
Note: For each NHR, define Health Checks, as explained in Table 32, page 226.
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 (see Server Name, page 136). The LocalFarm server is
another farm on the same 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 the routers of the
ISPs.
Note: This configuration requires the NHR per VIP feature (see page 225).
Example:Multi-homed Environment
Figure 16 Multihomed Environment, page 232, presents a regular configuration of a Multi-homed
environment where AppDirector is connected to multiple ISPs.
NHR Name:
Router 2
IP Address:
202.2.2.20
Figure 16: Multihomed Environment
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.
To Configure Redirect to Self in a Multihoming Environment:
1. Define the interfaces for Ports 1 and 2:
a. From the main APSolute Insite window, select View > select Split View.
b. From the Device menu select Add Radware Device > AppDirector. The AppDirector
device icon appears on the map.
c. Double-click the AppDirector device icon. The Connect AppDirector Device window
appears.
ISP 1
ISP 2
10.1.1.1 10.1.1.2
Server 1 Server 2
Port 2
10.1.1.10
202.2.2.10
Port 1
201.1.1.1
AppDirector
VIP: 202.2.2.10 VIP: 201.1.1.10
201.1.1.20
202.2.2.20
Router
Router
d. In the Device IP Address field, enter 201.1.1.10 and click OK.
e. Right-click the AppDirector device icon and select SetUp. The SetUp window appears.
i. In the SetUp window, click Add. The Interface window appears.
j. Set the following parameters according to the explanations provided:
k. Click OK. Your preferences are recorded.
2. Define the default gateway:
a. In the SetUp window, click Networking and select Routing Table. The Routing Table
window appears.
b. Click Add. The Edit Physical Route window appears.
d. Click OK.Your preferences are recorded.
3. Add the first server to the map:
a. From Device menu, select Servers > Server. A server icon appears on the map.
4. Add the second server to the map:
IF Num:
F-1
IP Address:
202.2.2.10
Network Mask:
255.255.255.0
IF Num:
F-2
IP Address:
10.1.1.10
Network Mask:
255.255.255.0
0.0.0.0
Network Mask:
0.0.0.0
Next Hop:
201.1.1.20
IF Number:
F-1
Server Name:
Server 1
IP Address:
10.1.1.1
a. From the Device menu select Servers > Server. A second server icon appears on the map.
b. Double-click the second Server icon. The Server window appears.
c. Set the following parameters according to the explanation provided:
window appears.
e. Click the Traffic Settings tab. The Traffic Settings pane appears.
f. Set the following parameters according to the explanations provided:
g. Click OK. Your preferences are recorded.
b. Click the L4 Policies tab. The L4 Policies pane appears.
d. In the VIP Address field, enter 201.1.1.100 and click Add. The Add L4 Policy window
appears.
Server Name:
Server 2
IP Address:
10.1.1.2
FarmName:
Farm 1
Dispatch Method:
Redirection Mode:
HTTP
Redirect By Name:
Enable
L4 Protocol:
TCP
L4 Port:
80
L4 Policy Name:
Policy 1
FarmName:
Farm 1
d. Click Traffic Settings. The Traffic Settings pane appears.
f. Click OK. Your preferences are recorded.
b. Click the L4 Policies tab. The L4 Policies pane appears.
appears.
c. Select the Farm Servers pane and click Add. The Farm Servers window appears.
c. In the Farm window, select the Farm Servers pane and click Add. The Farm Servers
window appears.
FarmName:
Farm 2
Dispatch Method:
Redirection Mode:
HTTP
Redirect By Name:
Enable
L4 Protocol:
TCP
L4 Port:
80
L4 Policy Name:
Policy 2.
FarmName:
Farm 2
Server Name:
Server 1
d. In the Farm Servers window, set the following parameter according to the explanation
provided:
11. Configure Farm 2 as a server to Farm 1:
b. Select Farm 1 entry and click Edit. The Farm window appears.
c. Click the Farm Servers pane and click Add. The Farm Servers window appears.
e. Click OK twice. Your preferences are recorded.
14. Configure Farm 1 as a server to Farm 2:
e. Click OK three times to return to the main window.
15. Add the first router to the map:
a. From the main window select Device > NHR. An NHR icon appears on the map.
Server Name:
Server 2
Server Name:
Farm2
Server Name:
Server 1
Server Name:
Server 2
Server Name:
Farm 1
a. Holding the Control key, select both the AppDirector icon and the Router 1 icon.
b. On the toolbar, click the Link Device button ( ). The Next Hop Router window appears.
c. Select Advanced Settings pane.
d. Click Apply and Add. The VIP NHR Table window appears.
e. Set the following parameter according to the explanation provided:
17. Add the second router to the map:
a. From the main window select Device > NHR. A second NHR icon appears on the map.
b. Double-click the second NHR icon. The Next Hop Router window appears.
a. Holding the Control key, select both the AppDirector icon, the Router 2 icon.
b. On the toolbar, click the Link Device button ( ). The Next Hop Router window appears.
c. Select the Advanced Settings pane.
d. Click Apply and Add. The VIP NHR Table window appears.
e. Set the following parameter according to the explanation provided:
f. Click OK.Your preferences are recorded.
Note: For each NHR, define Health Checks, as explained in Table 32, page 226.
Segmentation
This section discusses the use of segmentation when working with AppDirector in the network and
incudes the following topics
Segmentation Introduction, page 238
Supporting Segmentation with AppDirector, page 239
NHR Name:
Router 1
IP Address:
201.1.1.20
VIP Address: 201.1.1.100
NHR Name:
Router 2
IP Address:
202.2.2.20
VIP Address:
202.2.2.100
Segmentation Introduction
When you use a single AppDirector device to load balance multiple farms, each located on a
different segment around a firewall, AppDirector must ensure that all traffic between segments is
passed through the firewall. Segmentation involves dividing your network into logical segments,
where a single AppDirector load balances the traffic so that all segments can be inspected by a
single firewall.
Using Segmentation, a single AppDirector device connects to multiple segments around the firewall
(see Figure 17 Physical Port Segmentation, page 238). 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.
Figure 17: Physical Port Segmentation
Segmentation can be configured using physical ports, as shown in Figure 17 Physical Port
Segmentation, page 238, or using VLAN tags, as shown in Figure 18 VLAN Tag Segmentation, page
238.
Figure 18: VLAN Tag Segmentation
Interface 1
Interface 1
Interface 2
Interface 2
10.10.10.2
10.10.10.1
20.20.20.2
20.20.20.
DMZ1
DMZ2
VIP 10.10.10.100 VIP
Firewall
AppDirector
Firewall
Clients
DMZ 1 DMZ 2
VIP 2
Tag 20
Tag 10
AppDirector
Supporting Segmentation with AppDirector
To support Segmentation, AppDirector defines 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. Layer 4 Policies are also associated with segments, to define the logical
location of each VIP. AppDirector allows traffic for a Layer 4 Policys VIP only when the traffic arrives
from the same segment where this policy resides.
A default gateway can be associated with each segment; usually, the firewall interface of that
segment. There are cases when AppDirector receives traffic that cannot be handled due to segment
conflicts; the segment over which traffic was received does not match the segment to which traffic is
forwarded. AppDirector does not route traffic between segments. All traffic between segments is
sent via a segment NHR.
Notes:
>> Using APSolute Insite you cannot create a Segment without assigning it an NHR.
Therefore you cannot create Segments when there are no NHRs configured on the
device.
>> AppDirector default gateway can only belong to the default segment.
>> Device management can only be performed via a port/VLAN tag that belongs to the
default segment. Using APSolute Insite's User Management capability you can
nevertheless allow different system users to manage only their own segment.
Users can configure the operational mode for Segmentation as follows:
Users can configure the Default Action parameters as shown here:
The default option is to send the traffic to the AppDirector default gateway. Traffic to VIPs are
associated with a default segment.
To configure segmentation for AppDirector:
1. From the main APSolute Insite window, select View > Split View.
a. From the Device menu, select Add Radware Device > AppDirector. The AppDirector
icon appears on the map.
b. Double-click the AppDirector device icon. The Connect AppDirector Device window
appears.
Disable
The feature is disabled.
By Port
Segmentation is enabled and is based on the devices physical ports, Trunks or VLANs.
By VLAN
Tag
Segmentation is enabled and based on the 802.1q environment. When VLAN Tag mode
is in use, 8021q environment must be enabled and the VLAN Tag Handling parameter
must be set to Retain.
Default
Gateway
Handling with Segmentation if necessary - Forwards traffic to the AppDirector Default
gateway with Segmentation if required.
Discard
Discards the traffic.
Forward
Handling without Segmentation - Forwards traffic to destination (not via Firewall)- as if
Segmentation was disabled.
c. In the Device IP Address field, enter 10.10.10.10.
d. Check Offline Device.
2. Add the first server to the site:
a. From the Device menu select Servers > Server. A server icon appears on the map.
3. Add the second server to the site:
a. From the Device menu select Servers > Server. A server icon appears on the map.
4. Add two NHRs to the site:
a. From the main window select Device > NHR. A second NHR icon appears on the map.
b. Double-click the second NHR icon. The Next Hop Router window appears.
e. Add the second NHR as explained above. In the Next Hop Router window, set the following
parameters according to the explanations provided:
f. Click Add and OK. Your preferences are recorded.
5. Enable Segmentation:
window appears.
b. Click Segmentation. The Segmentation pane appears.
Server Name:
Server 1
IP Address:
10.10.10.1
Server Name:
Server 2
IP Address:
20.20.20.2
NHR Name;
NHR - 1
IP Address;
10.10.10.254
NHR Name:
NHR - 2
IP Address:
20.20.20.254
d. Click Apply. You will be prompted to reboot the device. Click OK. Your preferences are
recorded.
6. Add Segments:
a. In the Traffic Redirection window, select the Segmentation pane and then click Add. The
Define Segment window appears.
b. Configure the first segment by setting the following parameters according to the
d. In the Segmentation pane, click Add. The Define Segment window appears.
e. Configure the second segment by setting the following parameters according to the
appears.
Operation Mode:
By port
Segment Name:
DMZ-1
NHR:
10.10.10.254
Backup NHR:
20.20.20.254
Physical Ports:
F-1
Segment Name:
DMZ-2
NHR:
20.20.20.254
Backup NHR:
10.10.10.254
Physical Ports:
F-2
Farm Name: Farm 1
a. From the main window, select APSolute Insite > Traffic Redirection. The Traffic
10. Add the second Layer 4 Policy to AppDirector:
appears.
b. Select the server farm and click Edit. The Farm window appears.
e. Click OK twice. Your preferences are recorded.
L4 Protocol:
TCP
L4 Port:
80
L4 Policy Name:
Policy 1
FarmName:
Farm 1
Segment Name:
DMZ1
FarmName:
Farm 2
L4 Protocol:
TCP
L4 Port:
80
L4 Policy Name:
Policy 2
FarmName:
Farm 2
Segment Name:
DMZ2
Server Name:
Server 1
b. Select the server farm and click Edit. The Farm window appears.
c. Click the Farm Servers pane and click Add. The Farm Servers window appears.
e. Click OK twice.Your preferences are recorded.
Layer 7 Header Modification
This section describes how using Data Modification, AppDirector is able to modify and configure the
Layer 7 Header. This section includes:
Layer 7 Header Modification Overview, page 243
Defining Layer 7 Methods, page 243
Defining Layer 7 Header Modification Rules, page 245
Layer 7 Header Modification Overview
Often you need to change the headers of a HTTP session, for a variety of reasons including:
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.
The Set-Cookie Header Layer 7 Method.
AppDirector provides extensive Layer 7 modifications capabilities including, inserting, removing and
updating Layer 7 headers.
AppDirector can modify well known Layer 7 fields such as URL, cookie, header fields and status line
and any Layer 7 header that can be identified by a specific text or regular expression.
Layer 7 modifications are supported for HTTP or other HTTP-like (has HTTP-like header) TCP traffic
only.
Layer 7 modification rules use Layer 7 methods to define the traffic to be modified and to identify
the header that is being modified.
To configure Layer 7 Policies
1. Defining Layer 7 Methods, page 243
2. Defining Layer 7 Header Modification Rules, page 245
Defining Layer 7 Methods
The same Layer 7 methods that are available for Layer 7 policies are available for Layer 7
modification rules, see Defining Methods, page 106.
There are two additional Layer 7 methods that are available only for Layer 7 header modification.
Table 34, page 244 describes the parameters of the following Method Types.
Status Line: This method is used to update the reply status line.
Server Name:
Server 2
Set-Cookie: This method is used to insert a new cookie in server replies or to update or remove
an existing set-cookie header. A set-cookie header can be updated by using both Match Method
and Action Method type set-cookie in a L7 modification rule. This allows the following changes to
a cookie:
Update a set-cookie key, value and/or its attributes (path, domain and expires).
Add set-cookie attributes (path, domain, expires). If a value is mentioned for a set-cookie
attribute in the Action Method and the set-cookie header in the received packet does not
include this attribute, the attribute is added.
Remove an attribute. If the value of this attribute is defined as Blank in the Action Method,
this attribute is removed.
A set-cookie header can be removed by using Set-Cookie as L7 Method for Match and Remove
as Action.
Dynamic Values for Method Parameters
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 dynamic values can be
used:
Table 34: Layer 7 Method Types
Method
Type
Method Specific
parameters
Description Example
Set Cookie
Cookie Key A specific Cookie Key in the HTTP
request (mandatory)
Cookie Key =server
Cookie Value Value of the Cookie Key
(mandatory)
Cookie Value =red
Path Path part of the URL in the HTTP
header
Path =cgi-bin
Domain Domain to be added to the cookie DMN=service. com
Expire After Determines for how long the client
can use this Cookie.
Added to system time at the
moment of insertion and included in
the cookie, to determine the exact
time when this cookie expires.
For example, 24H for 24
hours, or 60M for 60 minutes,
1440S for 1440 seconds, and
1D for 1 day.
Value defined here is followed by a
letter that determines the time unit
used (S for seconds, M or no letter
for minutes, H for hours, D for days).
Status Line
Status Code HTTP status code as defined in the
HTTP RFC
404
Status Phrase Text accompanying the status code Not Found
$Blank
Used when the user wants to remove the content of a field in an update rule.
(for example - create an update modification rule for set cookie, and use
"$Blank" in the "expire after" field in order to remove any expiration from the
cookie).
$Client_IP
Original client IP as it appears in the request arriving from AppDirector.
$Client_Port
Original client port appearing in request arriving from AppDirector.
Note: 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 $$.
Defining Layer 7 Header Modification Rules
Layer 7 header modification rules are configured at the farm level. Multiple rules can be configured
for each farm.
To configure a Layer 7 modification rule:
window appears.
2. Click Farms. The Farms pane appears.
3. Select a Farm from Farms listed and click Edit or click Add to add a new Farm. The Farm
window opens in Traffic Settings mode.
4. Select the L7 Modifications tab. The Layer 7 Modification window appears.
5. Click Add. Set the following parameters according to the explanations provided:
$VIP_IP
Original destination IP appearing in request arriving from AppDirector.
$VIP_Port
Original destination port appearing in request arriving from AppDirector.
$Server_IP
IP address of the server that was selected by AppDirector for this session.
$Server_Port
Destination port to which traffic is forwarded when sent to the server.
$Server_SID_Cookie
Taken from the Static Session ID Persistency for Text Match for the farm,
with a different value for each server.
Index:
Sets order in which AppDirector matches traffic to the modification rules and performs
the modification.
Name:
Unique identifier (cannot be changed).
Direction:
Defines if modifications should be made to Client Requests and/or Server Replies.
Action:
Defines the Layer 7 modification that takes place:
Insert: Inserts a Layer 7 parameter.
Remove: Removes a Layer 7 parameter.
Update: Updates a Layer 7 parameter.
L7 Method
for Match:
Uses the same Layer 7 methods database used by Layer 7 policies. This is
mandatory when Action is set to Remove, optional if Action is set to Insert and
mandatory when Action is set to Update (unless Status Line or URL method).
Layer 7 Modification Examples
This table shows configuration examples of common Layer 7 modifications:
Layer 7 Modification Rules Automatic Configuration
There are two cases where AppDirector automatically generates Layer 7 modification rules.
When the Add X- Forwarded - For to HTTP request parameters is enabled in a farm,
AppDirector automatically generates a Layer 7 modification rule that inserts the X-Forwarded-
For header in packets sent to the server. When AppDirector redirects traffic using the Client NAT
redirection method, it inserts the X-Forwarded-For HTTP Header with the value of the original
client IP. For details see Client NAT, page 217.
When the I nsert Cookie for HTTP Persistency parameter is enabled in a farm, if the value of
this parameter is set to Enabled, AppDirector automatically generates a Layer 7 modification
rule that inserts a cookie that contains the server identifier. When traffic returns from the server,
before forwarding it to the client, AppDirector inserts cookies with the server session ID for HTTP
persistency. 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.
L7 Method
for Action:
Uses the same Layer 7 methods database used by Layer 7 policies. This is
mandatory when Action is set to Insert or Update, and redundant if Action is set to
Remove.
Admin
Status:
Allows disabling a rule without removing it.
Table 35: Layer 7 Header Modification
Example Action Direction
L7 Method for
Match
L7 Method for
Action
Inserting X-Forwarded-For
HTTP Header with client IP
Insert Client Requests Empty Method=Header
Field
Header Field =X-
Forwarded-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 MyKey and value of
MyFarm to the value of the
selected server and port
Update Server Replies Method =Set-
Cookie
Cookie Key =
MyKey
Method =Set-
Cookie
Inserting a cookie with key of
MyKey and a value of
MyFarm at the end of the
URL
Insert Client Requests Method=URL
Path=?MyKey=MyF
arm
Session Initiation Protocol (SIP)
This section explains load balancing and maintaining client-server persistency for SIP servers and
Introducing SIP, page 247
SIP Load Balancing with AppDirector, page 247
Farm Selection Based on SIP Parameters, page 247
Load Balancing SIP Servers, page 247
Outbound SIP Sessions, page 248
Introducing SIP
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/video communications are done over separate
session protocols, usually RTP.
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 Predefined Methods,
page 9.
Application-aware farm selection for SIP over UDP (Layer 7 policies).
Application-aware server persistency for SIP over UDP, see SIP Persistency, page 195.
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.
Load Balancing SIP Servers
In SIP protocol, IP addresses can be embedded in SIP headers and SDP data. This is a problem
when load balancing SIP traffic. The SIP server that handles the traffic responds using its own IP
address in the SIP data. As the client sending the traffic to AppDirector expects an answer at the SIP
level (not UDP level) from VIP, this causes 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. On each SIP server configure the loopback adapter with a SIP service VIP.
b. 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.
2. Define the SIP servers as Regular servers in AppDirector.
a. 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.
b. Bind the SIP application to this interface, instead of the physical IP interface.
c. AppDirector sends traffic to the physical address of the server and the server will use this
address inside the SIP payload in the answer.
Note: SIP sessions always load balance with servers per session, even you define eps/
regular session mode on the farm.
Outbound SIP Sessions
Some servers, configured with a loopback interface, use the loopback's IP address when the server
initiates traffic. Since all the servers within the SIP farm use the same IP address as a Source IP,
AppDirector needs a special process to return the traffic to the initiator server. To do so, a 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 and the source MAC
address of the server. All traffic is routed via AppDirector when using such configurations.
The Layer 4 Policy can either use port 5060 and UDP as the Layer 4 Protocol or specify SIP as the
application.
Note: Outbound SIP sessions are not supported for servers of type Local Triangulation.
Network Time Protocol Support
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 configure NTP:
2. Select Networking > NTP. The Network Time Protocol Preferences window appears.
NTP Server Address:
Address of the NTP server.
Active (checkbox):
Enables or disables the NTP feature.
NTP Server Address must be configured to enable the NTP feature.
NTP Port:
The NTP server port.
Default value:123.
NTP Checking Interval:
Interval, in seconds, that a time query message is sent to the NTP
server.
Default value:172,800.
Time Zone:
The time zone offset from GMT.
Default value: -12:00.
Chapter 7 Configuring Redundancy
This chapter discusses how to configure AppDirector using redundancy, and includes the following
sections:
AppDirector Redundancy, page 251
VRRP Redundancy, page 260
Proprietary ARP Redundancy, page 270
AppDirector Redundancy
Introducing AppDirector Redundancy, page 251
Active/Backup Setup, page 252
Active/Active Setup, page 253
Interface Grouping, page 253
Redundancy Copy Configuration, page 254
Stateful Failover (Mirroring), page 256
Physical IP Addresses vs. Virtual IP Addresses Redundancy, page 259
Force Port Down, page 260
Introducing AppDirector Redundancy
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.
Configuring Redundancy
Figure 19: AppDirector Redundancy Scheme

Active/Backup Setup
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.
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.
AppDirector 2
Router
Users
Network A
Port 1
MAC A
Port 1
MAC C
Network B
Port 2
MAC B
Port 2
MAC D
AppDirector 1
Server
2
Server
1
Internet
IP A 2
IP B 2
IP A 1
IP B 1
virtual IP
virtual IP
Active/Active Setup
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.
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.
Interface Grouping
To provide a complete solution for redundancy against all failures, AppDirector employs a system
called Interface Grouping. If AppDirector notices that one of its physical ports is down, it
intentionally brings all other active ports down. Enable this parameter on both devices in a
redundant configuration.
Notes:
>> You can select ports to be configured to trigger Interface Grouping.
>> If a dedicated management port was configured on the device, this port will not
trigger Interface Grouping.
>> For more information, see Redundancy Copy Configuration, page 254.
When a physical port 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 port
that went down.
2. If there were IP addresses configured on the port, AppDirector deactivates all other active ports.
3. If there were no IP addresses configured on the port, nothing happens and normal operation
continues.
Note: When a VLAN (Regular or Switch IP) goes down, Interface Grouping is triggered.
Backup Interface Grouping
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 primary device (defined in the Redundancy Table or VRID Table) if it is out of service. Once
the respective interface of the primary device is available, the backup device releases this interface.
Enable Backup Interface Grouping on both devices when using VRRP in Active-Backup configuration,
and only on the backup device when using proprietary ARP. Disable it for Active-Active
configurations.
To enable Interface Grouping:
1. From the main APSolute Insite window, select an AppDirector device icon.
2. Holding the Ctrl key, select a second AppDirector device icon. Both devices are selected.
3. On the toolbar, click the Link Device button ( ). The Multiple Device Links window appears.
Close the window.
4. Right-click one of the linked AppDirector icons and select SetUp. The SetUp window appears.
5. Click Redundancies. The Redundancies window appears.
6. From the Relation Type drop-down list, choose from the following:
a. IP Active-Active.
b. IP Active-Backup.
7. Click Advanced Redundancy. The Advanced Redundancy window appears.
8. From the Device Name drop-down list, select as follows:
a. For IP active/active:
Select the first device.
Check Interface Grouping.
From the Device Name drop-down list, select the second device.
Check Interface Grouping.
b. For IP Active Backup - select the primary device.
c. For Backup Device - check Backup Interface Grouping.
9. Check Interface Grouping.
10. Click OK.
Redundancy Copy Configuration
You can copy the main device's configuration to the backup device. For more information on various
Redundancy configurations, see also the following:
VRRP Redundancy Copy Configuration, page 264
Proprietary Active-Backup Redundancy Copy Configuration, page 271
To define advanced redundancy parameters:
1. In the main window, right-click the device icon and select Setup. The Setup window opens.
3. Click Copy Configuration. The Copy Configuration window appears.
5. Click Apply > Ok. The Copy Configuration window closes.
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.
To define Selective Interface Grouping:
Close the window.
6. Click Selective Interface Grouping. The Selective Interface Grouping window appears.
7. Select the ports to initiate Interface Grouping.
8. From the Port Status drop-down, select Included.
9. Click Update.
Defining the Interface Grouping Behavior in VLANs
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.
Active device is working
in VLAN mode (check-
box):
Enables the active device to operate in the VLAN mode.
Action After Conversion
mode:
The way the main device's configuration is sent to the backup
device:
Send to Destination Device Using SNMP: The main device's
configuration is sent to the backup device using SNMP.
Send to Destination Device Using TFTP: The main device's
configuration is sent to the backup device using TFTP.
Save Converted Configuration To File: Enables saving the
main device's configuration to a separate file.
To define Interface Grouping behavior in VLANs:
2. Select Networking > VLAN. The Virtual LAN window appears.
3. Select the required VLAN and set the following parameters according to the explanations
provided:
4. Click Update. Your preferences are recorded.
5. In the Virtual LAN window, select required VLAN and click on VLAN Ports Interface Grouping.
The VLAN Ports Interface Grouping window opens, showing the ports that participate in the
VLAN.
6. Select a port to include it in Interface Grouping, or clear a port to exclude it from Interface
Grouping. By default all ports are Included.
Note: The VLAN Ports Interface Grouping is accessible only if ports are already attached to
the VLAN.
7. Click OK. The VLAN window closes.
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.
For effective mirroring, provide a direct connection between the two devices. An IP interface must
be configured on each device for the direct connection port and address used as the Mirroring
Device Address for the other device.
Exclude the physical port used for inter-device communication from Interface grouping.
To increase reliability, a trunk (link aggregation) can be used for the direct connection between the
two devices.
Up Criterion
All Ports: VLAN is up when all ports participating in the VLAN are up.
For Regular VLAN: All ports in the VLAN are up.
Note: Only true when interface grouping is enabled, otherwise ports behave
like Switch VLAN.
For Switch VLAN: At least one of the ports in the VLAN is up.
One Port: VLAN is up when at least one of the ports participating in the VLAN is
up.
Down
Criterion
All Ports: VLAN is down when all ports participating in the VLAN are down.
For Regular VLAN: At least one of the ports in the VLAN is down.
Note: Only true when interface grouping is enabled, otherwise ports behave
the same as Switch VLAN.
For Switch VLAN: All ports in the VLAN are down.
One Port: VLAN is down when at least one of the ports participating in the VLAN
is down.
Mirroring can handle long and short sessions and support HTTP traffic. The following are mirrored:
Client table (L4-L7) (FTP, HTTP, and NAT - all types)
Dynamic Session ID Table
DNS Persistency Table (AppDirector Global Only)
Proximity table
Mirroring parameters must be configured on both active and backup devices.
Notes:
>> When setting up Mirroring, Radware recommends using the same AppDir software
version for the main and backup devices.
>> You need to define the IP address to which the mirroring messages are sent (IP
interface of the other AppDirector in the redundant pair) on both active 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.(see Introducing VRRP, page 260).
To configure mirroring for Active-Active Devices:
Close the window.
4. Right-click the active AppDirector device and select SetUp. The SetUp window appears.
6. Select IP Active-Active or VRRP Active-Active from the Relation Type field and click
Mirroring. The Mirroring window appears.
Active 1 Device Name (Read Only):
Name of the primary device.
Active 1 IP Address (Read Only):
IP address of the primary device.
Active 2 Device Name (Read Only):
Name of the secondary device.
Active 2 IP Address (Read Only):
IP address of the secondary device.
Client Table Mirroring:
Enables Client Table mirroring.
Proximity Table Mirroring:
Select to enable Proximity Table mirroring
(AppDirector-Global only).
Dynamic DNS Persistency Table
Mirroring:
Check to enable DNS Persistency Table mirroring
(Available in AppDirector-Global only).
Session ID Table:
Select to enable Session ID Table mirroring.
8. Click OK to apply the settings and close the window.
9. In the Mirroring window, set the following parameters according to the explanations provided:
Note:
>> You may sometimes need to manually trigger a failover from the main device to the
backup, for example for maintenance of the main device. To fail the main AppDirector,
use one of the following:
>> From the Insite main window go to Setup> Redundancies >VRRP
>> OR via a Web Based Management window: WSD > Redundancy >VRRP > Virtual
Routers, using the All VRI Ds Up or All VRI Ds Down options.
>> OR by CLI command: r edundancy vr r p gl obal - admi n- st at us
Advanced Redundancy
You can configure more than one device on a network so that one device (the backup device) will
back up another (the main device). In there is a failure of any network interface on the main device
will fail the whole device, and the backup device, previously idle, will take over all activity.
Mirroring Status:
Defines if this device mirrors other devices tables.
Select Disabled or Enabled.
Mirror Device Address:
IP address of the other device (on Backup define
Active's IP address and vice versa). Select from
available physical IP addresses.
Primary Device Name:
Name of the primary device.
Primary IP Address:
IP address of the primary device.
Backup Device Name:
Name of the secondary device.
Backup IP Address:
IP address of the secondary device.
Client Table:
Select to enable DNS Client Table mirroring (Available in AppDirector-
Global only).
Proximity Table:
Select to enable Proximity Table mirroring.
Dynamic DNS
Persistency Table:
Check to enable DNS Persistency Table mirroring.
Session ID Table:
Select to enable Session ID Table mirroring.
Mirroring Status:
Defines if this device mirrors other devices tables. Select Disabled or
Enabled.
Mirror Device Address:
IP address of the other device in the mirroring procedure (on Backup
define Active's IP address and vice versa). Select from available
physical IP addresses.
Devices do not use a dedicated connection or cable to monitor one another's status. Instead,
Radware offers two different methods for complete redundancy between pairs of devices:
Proprietary ARP method and VRRP.
To define advanced redundancy parameters:
1. Click APSolute OS. The APSolute OS menu appears.
2. Click Redundancy. The Redundancy window appears.
3. Click Advanced Redundancy. The Advanced Redundancy window appears.
Physical IP Addresses vs. 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
Device Name:
Name of the device.
Device IP:
IP address of the device, (read only).
Interface Grouping
(checkbox):
The Backup device takes control only if all the interfaces of the Main
device are out of service.
Backup Fake ARP
(checkbox):
When two devices are working in the redundant mode, the Backup
device constantly monitors the health of the Main device. Once the
Backup device detects that the Main device fails, the Backup device
takes control, which means that the Backup device now owns the IP
addresses of the Main device. The Backup device sends gratuitous
ARP to all local stations informing that the main device IP addresses
now correspond to the MAC addresses of the Backup device. This
process ensures smooth redundancy from the main device to the
backup.
Backup Device in
VLAN (checkbox):
Allow to backup another device in a Regular VLAN configuration.
Note: The configuration of "Backup Device in VLAN" should be done
prior to the physical connection of the devices.
If the devices are physically connected prior to the "Backup Device in
VLAN" configuration, then their Bridge FFT had already learned the
network MAC addresses in a way that causes a loop. In order to break
this loop and refresh the devices Bridge FFT - The devices should be
rebooted
Backup Interface
Grouping (checkbox)
Enables the backup to take over only when all IP interfaces defined in
the Redundancy Table fail and releases those interfaces only when all
the main's interfaces are up.
ARP with Interface
Grouping:
Select either Send or Avoid. Enabled only when Interface Grouping is
selected).
Force Down Ports
Time (seconds):
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 that should be used depends on how long it takes the
switch to clear its MAC tables.
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.
Physical interfaces are defined as the Destination IP address on the primary device and as Next Hop
Router on the backup 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.
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.
Note that this capability will not function when VRRP is not enabled and there is no VLAN configured
as part of the VRRP interfaces.
Configuration
This capability can be configured via WBM (AppDirector -> Redundancy -> Global Configuration) or
CLI (r edundancy f or ce- down- por t s- t i me command) via the following parameter.
Note: 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).
VRRP Redundancy
This section describes AppDirector redundancy using VRRP and includes these topics:
Introducing VRRP, page 260
VRRP nxn Redundancy, page 262
Direct Server Connection with VRRP, page 263
VRRP Redundancy Copy Configuration, page 264
Automated VRRP Configuration Updates, page 269
Introducing VRRP
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).
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.
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.
AppDirector devices support two redundancy modes:
Active-Backup - A redundancy scenario with 2 devices, with one device being the designated
Active device for all services (VIPs). In the event of a failure of the Active device, the Backup
device temporarily assumes ownership of the VIPs.
Active-Active - A redundancy scenario with 2 devices, each 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.
VRRP in Radware
In regular primary-backup scenarios, a VR is required for each interface of AppDirector. In a
standard AppDirector setup, 2 VRs are required.
You need to configure all VRs on each device, and associate the appropriate IP addresses with each
VR. Usually, the physical IP interfaces of the external side of a device and the VIP address are
associated with VR-I. The device IP interfaces of the server side of the device are associated with
VR-S. However Radware recommends to associate virtual IP interfaces (VIPI) instead of physical IP
interfaces. Using VRRP, you can set up more than one redundant AppDirector to back up a primary
AppDirector with hierarchy.
To configure VRRP redundancy:
Close the window.
6. From the Relation Type drop-down list, select VRRP.
7. To assign virtual routers to both the primary and backup devices, click Add VRID. The Edit
VRRP Table window appears.
VR-I
For the internet side of AppDirector, it is associated with the IP address of the primary
AppDirector and to the Virtual IP address.
VR-S
For the server side of AppDirector.
9. To define which IP addresses are backed-up with VRRP, in the Redundancies window, click
Associated IP. The Associated IP Address window appears.
10. Insert an entry for each IP address that you want to associate with each configured VR.
VRRP nxn Redundancy
Multiple AppDirector devices can be configured to achieve a full redundancy scheme between any
number of devices.
In this scheme, when each device manages one or more active Virtual IPs (VIPs) and mutual
hierarchical backup between the devices are configured, as long as the device is active, all its Virtual
IPs remain active.
This type of redundancy is configured using VRRP, in a similar manner to the AppDirector Active/
Active configuration (see Active/Active Setup, page 253).
Interface:
Interface number.
Default value: F-1.
VR ID:
Virtual routers identification number. Value range: 1-255.
Enable Virtual Router
(checkbox):
Enables or disables administrative status of VR.
Priority:
Defined with the values 1-255, where the highest priority (255) must be
assigned to the VR that is associated with a devices physical IP address
(IP address that the device owns).
Default value: 100.
Primary IP:
Primary IP address. The device adds a default value unless the user
defines one. The primary IP address is used internally only, as the
Source IP of VRRP messages sent by this device.
Authentication Type:
Type of authentication.
Authentication Key:
Password up to 8 characters in length.
Advertisement
Interval:
Interval at which packets are checked in seconds.
Default value: 1 sec.
Preemption Mode:
Defines the takeover procedure for the 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. When the device with the higher
priority for this VR resumes functioning, the Preemption mode decides
whether it must retake control of the VR from the device with the lower
priority. Values are True (the higher priority device takes over the VR)
and False (the device with the lower priority maintains control of the VR).
Default value: True.
Protocol:
IP protocol name for AppDirector (not configurable).
Direct Server Connection with VRRP
VRRP with Switch IP VLAN allows the direct connection of servers to AppDirector in conjunction with
routing and bridging. Using this configuration, servers with dual Network Interface Cards are directly
connected to AppDirector devices. AppDirector uses routing (Figure 20 Direct Server Connection
with VRRP and Routing, page 263) or bridging (Figure 21 Direct Server Connection with VRRP and
Bridging, page 264) between the external network, connected to routers or switches, and the
internal network, connected to servers. Servers are connected directly to AppDirector interfaces. A
cross cable is required to connect the two AppDirector devices (using Giga or Fast Ethernet ports).
The interfaces to which the servers are connected and the interface used for connecting the two
AppDirector devices are associated with a Switch IP VLAN. This puts all the servers on a single
switch.
Using bridging, only Active/Backup mode is supported where one AppDirector is active for all Virtual
IPs and the other provides a host standby. Using routing, the Active/Active mode can be also used,
where some of the Virtual IPs are active on AppDirector-L and other Virtual IPs are active on
AppDirector-R.
Using bridging, you need to configure a Regular VLAN, including the Switch IP VLAN, and the
AppDirector interface to the external side. This creates a bridge between the Switch VLAN and the
interface. When needed, multiple AppDirector interfaces can be added to this Regular VLAN.
Using routing with Layer 2 or Layer 3 switches, either connecting AppDirector and servers or
connecting AppDirector to the external subnet, you must avoid any configuration that contains a
loop. For example, avoid having a cross cable between the switches and between AppDirector
devices, or connecting each AppDirector to two cross-connected switches where the two connections
are on the same Switch IP VLAN on AppDirector.
Figure 20: Direct Server Connection with VRRP and Routing
AppDirector uses routing between the subnet (of the servers) and the (external) subnet. This is
essential to avoid loops in the network.
When adding or removing ports on a Switch IP VLAN that is already associated with a VRID, the
user must set the VRID Admin Status to Down, make the change, and then set the status to Up
again.
Routers
Switch IP
VLAN 2 on
AppDirecto
r-L
Server Server
Switch IP
VLAN 2 on
AppDirecto
r-R
Switch IP
VLAN 1 on
AppDirector
-L
Switch IP
VLAN 1 on
AppDirecto
r-R
Figure 21: Direct Server Connection with VRRP and Bridging
Interface Grouping Used with Direct Connection
To support redundant configuration with direct server connectivity, the Interface Grouping operation
is modified. Interface Grouping is always part of the AppDirector redundancy layout. Enabling
Interface Grouping on the primary device ensures that if one of the interfaces of the device fails, the
device closes all its other interfaces and becomes invisible to the network.
Using Switch VLAN, the grouping takes place only when all the interfaces that were configured in a
Switch VLAN are down. Interface Grouping is released when the all the interfaces in a Switch VLAN
are up.
Using Switch VLAN as part of a Regular VLAN, grouping takes place only when all interfaces in a
Switch VLAN are down or when any other port in the Regular VLAN is down. Interface Grouping is
released when all interfaces in a switch VLAN are up, or when all other ports in the Regular VLAN are
up.
Note: This default behavior can be overwritten by configuration of Selective Interface
Grouping (see Redundancy Copy Configuration, page 254).
VRRP Redundancy Copy Configuration
This section contains recommended redundancy configurations for use with VRRP Redundancy.
VRRP Active-Backup Routing Preemption Enabled
Active Backup
L4 Policies
Configurations:
All VIPs should be set to
redundancy mode - Primary
Outbound NAT IPs should be set
to redundancy mode - Active.
redundancy mode - Backup
Outbound NAT should be set to
Routers or
Switches
Switch IP
VLAN on
AppDirector
-L
Server Server
Switch IP
VLAN on
AppDirector-R
External
Side
Internal
Side
Interface Grouping
Configurations:
Interface Grouping-Enabled
Backup interface grouping-
Enabled
Selective interface grouping - only
interfaces that are within a VR
should be associated.
Backup interface Grouping-
Enabled
Selective interface grouping - The
same ports that are excluded on
Active should be Excluded on
backup.
Mirroring
Configurations:
Mirroring Tables - Tabled for
mirroring should be selected (If
user wishes to activate mirroring)
Mirroring State - should be Enable
on backup device, the mirroring
address should stay 0.0.0.0 and to
be configured later by the user
(Only if the user configured on the
main device tables to be
mirrored).
Mirroring Address - If a user
wishes to complete the
configuration of mirroring on the
backup device prior to the copy-
configuration feature - the user will
select mirroring state to be Enable
and will set an IP address of the
mirror device. These values
should be saved after the copy-
configuration.
Regular VLAN
Configurations:
VRRP
Configurations:
VRRP Associated addresses on
Actives VR should be associated
on Backup's
VRs Configurations on the backup
should stay as configured before
the copy configuration.
Proprietary
Configurations:
VRRP Active-Backup Routing Preemption Disabled
VRRP Active-Backup VLAN Preemption Enabled
Active Backup
L4 Policies
Configurations:
Outbound NAT IPs should be
set to redundancy mode -
Active.
All VIPs should be set to redundancy
mode - Primary
redundancy mode - Active.
Interface
Grouping
Configurations:
Selective interface grouping -
only interfaces that are within
a VR should be
Enabled
Interface Grouping -Enabled
Backup interface grouping-Enabled
Selective interface grouping - The same
ports that are excluded on the Active
device are excluded on the Backup
device.
Mirroring
Configurations:
mirroring should be selected
(If user wishes to activate
mirroring)
Mirroring State - Should be
set to enable (If user wishes
to activate mirroring)
Mirroring Address - Should be
set by the user (If user wishes
to activate mirroring)
Mirroring Tables - Should select the
same tables that were selected on the
Active device.
Mirroring Address - If a user wishes to
complete the configuration of mirroring
on the backup device prior to the copy-
select mirroring state to be Enable and
will set an IP address of the mirror
device. These values should be saved
after the copy-configuration.
Regular VLAN
Configurations:
VRRP
Configurations:
VRRP Associated addresses on Actives
VR should be associated on Backup's
should stay as configured before the
copy configuration.
Proprietary
Configurations:
Active Backup
L4 Policies
Configurations:
VRRP Active-Backup VLAN Preemption Disabled
Interface
Grouping
Configurations:
Enabled
Enabled
backup.
Mirroring
Configurations:
main device tables to be mirrored).
configuration.
Regular VLAN
Configurations:
VLAN interface grouping - Exclude
interfaces which their failure
shouldn't affect the entire VLAN.
When working with Regular VLAN
as a part of the VRRP - Backup in
VLAN should be enabled
as a part of the VRRP - Force Port
Down
VLAN interface grouping - The
same ports that were Exclude on
active should be excluded on
backup.
When backup device in VLAN is
marked on Active it should be
enabled on Backup
When Force Port Down is enabled
on Active device it should be
enabled on backup.
VRRP
Configurations:
on Backup's
Proprietary
Configurations:
Active Backup
L4 Policies
Configurations:
Interface Grouping
Configurations:
should be
Enabled
Interface Grouping -Enabled
Enabled
backup
Mirroring
Configurations:
Mirroring State - Should be set to
enable (If user wishes to activate
mirroring)
Mirroring Address - Should be set
by the user (If user wishes to
activate mirroring)
Mirroring Tables - Should select
the same tables that were
selected on the Active device.
configuration feature - the user
will select mirroring state to be
Enable and will set an IP address
of the mirror device. These values
configuration.
Regular VLAN
Configurations:
VLAN interface grouping - Exclude
interfaces which their failure
shouldn't affect the entire VLAN.
enabled on backup.
same ports that were excluded on
backup.
enabled on Backup
When Force Port Down is
enabled on Active device it should
be enabled on backup.
VRRP
Configurations:
on Backup's
Proprietary
Configurations:
VRRP Active-Active
Automated VRRP Configuration Updates
AppDirector can automatically add a new Virtual IP configured on the 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
Active Backup
L4 Policies
Configurations:
All VIPs should be set to the
desired redundancy mode -
Primary/Backup
to desired redundancy mode -
Active/Backup.
All VIPs that had been set to the
desired redundancy mode on
Active should be set to the opposite
state at Backup - Primary/Backup
Outbound NAT IPs that had been
set to the desired redundancy
mode on Active should be set to the
opposite state at Backup - Active/
Backup
Interface
Grouping
Configurations:
Disabled
Disabled
backup.
Mirroring
Configurations:
mirroring)
activate mirroring)
Mirroring Tables - Should select the
same tables that were selected on
the Active device.
Mirroring Address - If a user wishes
to complete the configuration of
mirroring on the backup device
prior to the copy-configuration
feature - the user will select
mirroring state to be Enable and will
set an IP address of the mirror
device. These values should be
saved after the copy-configuration.
Regular VLAN
Configurations:
VRRP
Configurations:
on Backup's
Proprietary
Configurations:
interface. If there is no VRID defined for an AppDirector interface with a subnet that matches the
new Virtual IP, this Virtual IP is not automatically associated to a VRRP. The Automated VRRP
Configuration Updates parameters is enabled by default.
To configure VRRP Automated Configuration updates:
1. From the main window, right-click the device and select APSolute OS > Redundancy. The
Redundancies window appears.
2. From the Relation Type dropdown list, select VRRP.
3. Select the Automated VRRP Configuration Updates checkbox.
4. Click OK.
Proprietary ARP Redundancy
This section describes the redundancy methods that use the Address Resolution Protocol, and
Proprietary ARP, page 270
Proprietary Active-Backup Redundancy Copy Configuration, page 271
Backup Fake ARP, page 274
Proprietary ARP
Proprietary ARP (Address Resolution Protocol) ensures that the backup AppDirector is available and
that the network connections between the primary and backup devices are up. If the primary device
fails, the backup device takes control and continues operating between clients and servers that had
been established on the primary device.
With Proprietary ARP redundancy, the backup device manages the polling process by continuously
polling the primary device, using the ARP protocol (see Table 36, page 270). If the primary device
fails, the teaching process is realized when the backup device sends broadcast ARPs informing its
network neighbors that the IP addresses of the primary device are now associated with its own MAC
addresses. This ensures that all traffic destined to the IP addresses of the primary device reaches
the backup device.
Table 36: Polling Parameters
Set the polling parameters in APSolute Insites Redundancy Table window. To open the Redundancy
Table window:
1. From the APSolute Insite window, right-click the AppDirector icon and select APSolute
OS > Redundancy. The Redundancies window appears.
2. Click Add to add a new entry to the Redundancy Table, or select an entry and click Edit. The
Redundancy Table appears.
Polling
Interval:
How often backup device polls the primary device (in seconds).
Default value: 3.
Timeout:
Interval, in seconds, during which AppDirector must respond. If AppDirector does not
respond within this interval it is considered inoperable. If the Time Out is zero (0),
AppDirector ignores the row.
Default value: 12.
Proprietary Active-Backup Redundancy Copy Configuration
This section contains recommended redundancy configurations for use with Proprietary Redundancy.
Proprietary Active-Backup Routing
Active Backup
L4 Policies
Configurations:
Outbound NAT IPs should be set to
Interface
Grouping
Configurations:
Backup interface grouping-Disabled
Interface Grouping-Disabled
Enabled
backup.
Mirroring
Configurations:
mirroring should be selected (If user
wishes to activate mirroring)
main device tables to be
mirrored).
configuration.
Regular VLAN
Configurations:
VRRP
Configurations:
Proprietary
Configurations:
Global redundancy mode is set to
Proprietary before the copy-
configuration and should be saved
like that after the copy-
configuration.
The redundancy IPinterface table
that configured by the user on the
backup device before the copy
configuration should be saved
after the copy-configuration.
Proprietary Active-Backup VLAN
Active Backup
L4 Policies
Configurations:
Interface
Grouping
Configurations:
Disabled
Interface Grouping-Disabled
Enabled
backup.
Mirroring
Configurations:
main device tables to be mirrored).
mirror device. These values should
be saved after the copy-
configuration.
Regular VLAN
Configurations:
VLAN interface grouping -
Exclude interfaces which their
failure shouldn't affect the entire
VLAN.
as a part of the VRRP - Force Port
Down
same ports that were Exclude on
backup.
enabled on Backup
enabled on backup.
Proprietary Active-Active
VRRP
Configurations:
Proprietary
Configurations:
Global redundancy mode is set to
Proprietary before the copy-
configuration and should be saved
like that after the copy-
configuration.
The redundancy ip interface table
that configured by the user on the
backup device before the copy
configuration should be saved after
the copy-configuration.
Active Backup
L4 Policies
Configurations:
All VIPs should be set to the
desired redundancy mode -
Primary/Backup
Outbound NAT IPs should be set to
desired redundancy mode - Active/
Backup.
All VIPs that had been set to the
desired redundancy mode on
Active should be set to the
opposite state at Backup -
Primary/Backup
Outbound NAT IPs that had been
set to the desired redundancy
mode on Active should be set to
the opposite state at Backup -
Active/Backup
Interface Grouping
Configurations:
Disabled
Disabled
Selective interface grouping -
The same ports that are
excluded on Active should be
Excluded on backup.
Mirroring
Configurations:
mirroring)
activate mirroring)
Mirroring Tables - Should select
the same tables that were
selected on the Active device.
configuration feature - the user
will select mirroring state to be
Enable and will set an IP address
of the mirror device. These
values should be saved after the
copy-configuration.
Regular VLAN
Configurations:
Backup Fake ARP
When two AppDirector devices work in redundancy mode, the backup device constantly monitors
the health of the primary device. If the backup device detects that the primary device is down, the
backup device takes control; the backup device now owns the IP addresses of the primary device.
The backup device sends gratuitous ARPs to all local stations informing that the primary device IP
addresses now correspond to the MAC addresses of the backup device. This ensures smooth
redundancy from the primary device to the backup.
When the primary device is operational again, it uses the same technique. It sends gratuitous ARP
to all local stations informing them that the primary device IP addresses now correspond to the MAC
addresses of the primary device. To speed up this process, the backup device publishes a message,
(a fake ARP), as one device (the backup) publishes the other device (the primary).The backup fake
ARP is enabled by default and can be disabled.
Backup Device in VLAN
Using redundancy with bridging, the backup device must remain completely silent on the network to
prevent broadcast storms. This behavior must be set using the Backup Device in VLAN parameters.
To enable Backup Fake ARP and Backup Device in VLAN:
Close the window.
4. Right-click the backup AppDirector icon and select SetUp. The SetUp window appears.
6. Click Add. The Advanced Redundancy window appears.
7. From the Device Name drop-down list, select the IP address of the backup device.
8. Check Backup Fake ARP.
9. Check Backup Device in VLAN.
Note:
>> Configure the "Backup Device in VLAN" prior to the physical connection of the devices.
VRRP
Configurations:
Proprietary
Configurations:
Global redundancy mode is set
to Proprietary before the copy-
configuration and should be
saved like that after the copy-
configuration.
The redundancy ip interface
table that configured by the user
on the backup device before the
copy configuration should be
saved after the copy-
configuration.
>> If the devices are physically connected prior to the "Backup Device in VLAN"
configuration, then their Bridge FFT had already learned the network MAC addresses
in a way that causes a loop. To break this loop and refresh the devices Bridge FFT -
reboot the device.
Chapter 8 Configuring Bandwidth
Management Policies and Classes
This chapter describes the Bandwidth Management module, and includes the following sections:
Bandwidth Management Introduction, page 277
Bandwidth Management Policies, page 278
Classes, page 282
Protocol Discovery, page 292
Interface Classification, page 293
Bandwidth Management Introduction
This section describes the Bandwidth Management module and explains how to control the available
bandwidth. This section includes the following topic:
Introducing Bandwidth Management, page 277
Introducing 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.
When a packet is matched, the device does 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.
If the packet is to be prioritized, it is placed into a queue. The queue is then assigned a priority from
0-7, with 0 being the highest priority and 7 the lowest. There can be one queue per policy per port.
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. There could be 100 queues (if there are 100 policies), with
each queue having a label from 0-7.
Configuring Bandwidth Management Policies and Classes
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 280).
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.
RandomEarly 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.
Bandwidth Management Policies
This section describes how to define Bandwidth Management policies. This section includes the
following topics:
What is a Bandwidth Management Policy, page 279
Bandwidth Management Classification Criteria, page 279
Configuring Bandwidth Management Policies and
Bandwidth Management Rules, page 280
What is a Bandwidth Management Policy
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.
Bandwidth Management Classification Criteria
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:
Client (Source IP)
Session (Source IP and port)
Connection (Source IP and Destination IP)
Full L4 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)
Bandwidth Management Rules
Once traffic is classified and matched to a policy, the 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.
MaximumLimit
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:
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.
Guaranteed
Bandwidth
Maximum
Bandwidth
Policy Bandwidth
0 0 Burstable with no limit, no minimum guaranteed.
X 0 Burstable with no limit, minimum of X guaranteed.
0 Y Burstable to Y, no minimum guaranteed.
X Y (Y>X) Burstable to Y, minimum of X guaranteed.
X X Non-burstable, X guaranteed.
The total bandwidth available for a policy group is the sum of the Guaranteed Bandwidth values of
all the policies in the group.
To configure policy group
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: This option is not available if the Traffic Flow Identification is set to Session or Full
L4 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.
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
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.
To define events in the Events Scheduler
1. In the main window, select APSolute OS > BWManagement. The Bandwidth Management
window appears.
2. Click Policy Scheduler. The Event Scheduler window appears.
4. Click Add. The new event appears in the events table.
To apply an event to a policy
1. To create a new event, click Schedule Table and define a new event.
window appears.
3. Select Modify. The Modify pane appears.
4. Double-click the policy and the Edit Policy window appears.
5. Click Advanced. The Advanced pane appears.
6. To activate a specific event for this policy, from the Activation Schedule dropdown list, select the
event to apply to this policy and click OK.
7. To inactivate a specific event for this policy, from the Inactivation Schedule dropdown list, select
the event that you want to inactivate and click OK.
Classes
This section explains how to define services and includes the following topics:
Services, page 283
Configuring Networks, page 285
Physical Port Groups, page 286
VLAN Tag Groups, page 286
Event Name
Name of the event.
Event Frequency
Whether the event occurs once, daily, or weekly.
Event Days
If weekly frequency selected, you must set which day the event occurs.
Event Time
(HHMM)
The time on the designated day.
Default value: 12:00 am (0000).
Note: If multiple days are selected, the Time value is the same for all the
configured days the event occurs.
Event Date
(DDMMYYYY)
If the Frequency selected is once, you must set the date for the event.
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.
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.
Note: For a detailed description of the predefined filters, see Table 37, page 284.
Pre-Defined Filters
The following table lists the pre-defined Bandwidth Management filters for each service.
Table 37: Pre-Defined BWM Filters
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.
Enables any type of client to access applications across any type of
network connection.
Group
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
Peer-to-Peer
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
Internet
dns Domain Name Server protocol
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.
To configure a Network
1. In the main APSolute Insite window, select APSolute OS > Classes. The Classes window
appears.
2. Press the Networks button. The Network Table window appears.
3. Press Add. The Edit Network Table window appears.
4. Edit the Network, set the parameters and press OK.
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
ip IP traffic
nntp Usenet NetNews Transfer Protocol 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
Email
mail Group
smtp Basic
imap Basic
pop3 Basic
Table 37: Pre-Defined BWM Filters
Service Name Description
Filter
Name
Physical Port Groups
Physical port groups enable you to set different policies for identical traffic classes received on
different interfaces of the device; e.g. you can allow HTTP access to the main server only to traffic
entering the device via Physical Interface 3. You must first configure Port Groups.
To configure Port Groups
1. In the main APSolute Insite window, select APSolute OS > BWManagement. The Bandwidth
Management window appears.
2. Select the Policy Groups button. The Port Groups window appears. Select Modify. The Modify
pane appears.
3. In the Group Name text box, enter the group name.
4. Press Add and press OK.
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 configure VLAN Groups:
1. In the main APSolute Insite window select APSolute OS > Classes. The Classes window
appears.
2. Select the Port Groups button. The Port Groups window appears.
3. Select VLAN Tag Group. Click Modify Table. The Modify Table pane appears.
4. Click Add. The Edit VLAN Tag Group window appears.
5. Edit and set the parameters and click OK.
To configure Bandwidth Management
window appears.
2. Click the BWM Parameters button. The BWM Global Parameters window appears.
Classification Mode:
Select from:
Disable: No classification. The 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 the Classification Mode, the device will
require 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. 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.
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 minimum (guaranteed) and a
maximum allotted bandwidth, in Kbps.
Note: Unless CBQ is used, policies cannot be configured with an
associated bandwidth allocation.
RandomEarly 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.
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.
TCP Classification Mode:
Indicates whether to classify TCP sessions if they started with a
SYN packet.
SYN-Validation: Only classifies the session that begins with SYN.
Promiscuous: Classifies all sessions.
BWper Traffic Flow
Aging:
The length of time, in seconds, a non-active traffic flow is kept in
the flow table used by the Bandwidth Management module.
4. Click OK to apply the setup and exit the window.
5. Configure the required Physical Port Group:
a. In the main window select APSolute OS > Classes. The Classes window appears.
b. Click the Port Groups button. The Port Groups window appears.
c. Click Modify Table. The Modify Table pane appears.
Max packets for Session
Classification:
When Application Classification mode is set to Per Session mode
and one of the policies is configured to search for content, this
parameter indicates the maximum number of packets that the
device searches through for the configured content.
If the device fails to find the content after searching the number of
packets defined in the configured parameter, the device will stop
searching.
Default =5.
Disabled =0 - the device will search for the content in all the
packets belonging to the session.
Maximum value =100.
Enable Policy Statistics
Monitoring:
Enables or Disables the monitoring of policy statistics by the
device.
Policy Statistics
Reporting period (sec.):
Amount of time, in seconds, that policy statistics are monitored.
Enable Policy Statistics
Reporting (SRP):
Enables or disables policy statistics reporting.
Enable Protocol
Monitoring Status:
Enables or disables monitoring of protocol statistics by the device.
Protocol Statistics
Reporting Period (sec.):
Amount of time, in seconds, that protocol statistics are monitored.
Enable Protocol Statistics
Reporting (SRP):
Enables or disables protocol statistics reporting.
Protocol Statistics Aging:
This parameter specifies the maximum idle time, in seconds,
allowed between a request and a response per protocol, or
between two sequential packets.
Note: The user must tune the Protocol Aging with care. Radware
recommends consulting with Radware Support before making any
changes.
SRP Management IP
Address:
APSolute Insite Management Station IP address. (Statistics
Reporting Protocol - SRP is a private Radware protocol used for
efficient transmission of statistical data from the device to the
APSolute Insite Management Station).
Application
Classification:
Two types of application classification:
Per Packet: Device classifies every packet that flows through it.
Per Session: Packets are classified by session. All packets in a
session are classified until a best fit policy is found, fully
classifying the session. Once the session is fully classified, all
packets belonging to the same session are classified accordingly.
d. Click Add. The Edit Physical Port Group window appears.
e. In the Groups parameters, enter a new group: FTP ports. Select the port 5 and port 7
check boxes.
6. Configure the required VLAN Tag Groups:
a. In the Classes window select the Port Groups button. The Port Groups window appears.
b. Select VLAN Tag Groups. Click Modify Table. The Modify Table pane appears.
c. Click Add. The Edit VLAN Tag Groups window appears.
d. Create two separate entries for the Citrix VLAN by setting the following parameters:
e. Click OK and then click Update Modifications.
7. Add two networks:
a. In the Bandwidth Management window, click Classes. The Classes window appears.
b. Click the Networks button. The Network Table window appears.
c. Click Modify. The Modify pane appears. Click Add. The Edit Network window appears.
e. In the same manner, add the second network by setting the following parameters according
to the explanations provided:
f. Click OK to apply the setup and exit the window.
8. Configure the Basic Filter to identify the e-mail virus:
a. In the Bandwidth Management window, click Classes. The Classes window appears.
Group Name:
Citrix VLAN
Group Mode:
Discrete
VLAN Tag:
2 (first)
7 (second)
Network Name:
FTP Servers
Network Mode:
IP Range
FromAddress:
Create three separate entries for the FTP Servers with the following
IP addresses:
20.10.1.3
20.10.1.7
20.10.3.17
To Address:
The same as the From Address.
Network Name:
Internal
Network Mode:
IP Mask
FromAddress:
10.0.0.0
To Address:
255.0.0.0
b. Click Add Regular. The New Service pane appears.
d. Click Add Service and then click Update Active Classes.
9. Configure the Policies:
a. In the Bandwidth Management window, click Modify. The Modify pane appears. Click Add.
The Edit Policy window appears.
b. Add the following four policies according to the explanations provided:
Service Name:
Love Letter
Protocol:
TCP
Content Type:
Mail Subject
Content:
Love Letter
To limit FTP traffic to FTP servers via ports 5 and 7 to 300kbps:
Policy Name:
FTP
Service Type:
Regular
Service Name:
FTP
Source:
Any
Destination:
FTP Servers
Direction:
Oneway
Action:
Forward
Priority:
4
Inbound Physical Group:
FTP Ports
MaximumBandwidth:
300
To guarantee 2 Mbps to Citrix traffic running on VLAN 2 and 7:
Policy Name:
Citrix
Service Type:
Group
Service:
Citrix
Source:
Any
Destination:
FTP Servers
10. Click OK to apply the setup and exit the window.
Direction:
Twoway
Action
Forward
Priority:
2
Generated Bandwidth:
2000
To limit HTTP traffic to the local network to 1 Mbps:
Policy Name:
HTTP
Service Type:
Regular
Service:
HTTP
Source:
Any
Destination:
Internal
Direction:
Twoway
Action:
Forward
Priority:
3
Inbound Physical Group:
FTP Ports
MaximumBandwidth:
1000
To block the Love-Letter e-mail virus:
Policy Name:
Virus Love Letter
Service Type:
Regular
Service:
Love Letter
Source:
Any
Destination:
Any
Direction:
Twoway
Action:
Block
Protocol Discovery
This section describes the Protocol Discovery feature that allows you to recognize different
applications running on your network by creating Protocol Discovery Policies. This section includes
What is Protocol Discovery?, page 292
Protocol Discovery Policies, page 292
What is Protocol Discovery?
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.
Protocol Discovery Policies
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 destination of the traffic. 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 takes place. The device modifies
the packets by changing the Destination IP from the Virtual IP to the servers real IP address.
The traffic can be classified before packet changes, Before 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 the Policy is active or not. Select from Active or
Inactive.
To configure Protocol Discovery:
1. In the main window, select APSolute OS > Bandwidth Management. The Bandwidth
2. Click Protocol Policies. The Protocol Discovery Policies window appears.
3. Click Add. The Edit Protocol Policy window appears.
4. Set the parameters according to the traffic classification criteria.
5. Click OK to accept your changes and exit the window.
To view the results:
1. In the main window, select APSolute OS > Bandwidth Management. The Bandwidth
2. Click Protocol Policies. The Protocol Discovery Policies window appears.
3. Click View Protocol Statistics. The Protocol Statistics window appears and your results can be
viewed.
4. Click OK to exit.
Interface Classification
This section describes the process of interface classification, which enhances Bandwidth
performance. This section includes the following topic:
Port Bandwidth, page 293
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 define a port maximum available bandwidth
1. In the main window, right-click the AppDirector icon and select Panel View. The device front
panel comes into focus.
2. Right-click the required port (f1, f2, etc.) and select Interface set the following parameters
from the dropdown list. The Interface set the following parameters window appears.
3. Set the Available Bandwidth parameter for that port in Kbps and click OK.
Chapter 9 Configuring Health Monitoring
This chapter describes the Health Monitoring module, a component of the Radware APSolute OS
architecture. This chapter includes the following sections:
Health Monitoring - Introduction, page 295
Health Check Configuration, page 296
Health Checks Per Server, page 301
AppDirector Farm Connectivity Checks, page 315
Health Monitoring - Introduction
This section describes the general functionality of the module and basic health monitoring concepts.
Health Monitoring Module Introduction, page 295
Checked Element, page 295
Health Check, page 296
Health Monitoring Module Introduction
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 user-
defined 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.
Configuring Health Monitoring
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, etc. These
parameters are explained in Health Checks, page 297.
A network element can be tested using one or more Health Checks.
Health Check Configuration
This section describes how to configure health monitoring according to Health Check types. The
Health Monitoring Configuration section includes the following topics:
Health Monitoring Configuration Guidelines, page 296
Health Monitoring Global Parameters Setup, page 296
Health Checks, page 297
Health Checks Per Farm, page 302
Health Monitoring Configuration Guidelines
The Health Monitoring module is accessed using the Health Monitoring menu from APSolute Insite,
Web Based Management or via CLI.
To configure the Health Monitoring module in APSolute Insite
1. Enable the Health Monitoring module: To set and view the Health Monitoring Global parameters,
see Health Monitoring Global Parameters Setup, page 296.
2. Set the required health checks. Health checks can be configured:
a. Customized: To set up a check and bind it to a server, see Health Checks, page 297.
b. Per Server: To set up Health Checks for each server directly from the Server table, see
Health Checks Per Server, page 301.
c. Per Farm: To set up Health Checks for all servers in the farm, see Health Checks Per Farm,
page 302.
Note: Ensure that the Connectivity Method of each farm is set to Disabled by selecting
APSolute OS > Traffic Redirection > Edit Farm > Connectivity Check. This
allows the device to use the Health Monitoring module to determine the status of the
servers in the farm.
Health Monitoring Global Parameters Setup
In APSolute Insite, Health Monitoring Global parameters are set up in the Health Monitoring Settings
window.
To configure Global Health Monitoring:
1. From the main Apsolute Insite window, open the Device menu and select
Add Radware Device > AppDirector. The AppDirector icon appears in Site Explorer and/or on
the map (depending on the view selected).
2. In the main window, right-click the device icon and select SetUp. The SetUp window appears.
3. Click Global > Health Monitoring Settings, and click Edit Settings. The Health Monitoring
4. Set the following parameters:
Note: SSL certificate file and SSL private keys are not exported as part of the device
configuration export.
Health Checks
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.
The Health Checks topic includes:
General information on Binding, page 298
General information on Group Health Checks, page 298
Setting up Single Health Checks, page 298
Setting up Group Health Check, page 300
Setting up Action Macro, page 300
Health
Monitoring:
Determines whether to use the Health Monitoring module or the device's
connectivity checks.
Response Level
Samples:
The number of Response Level samples that serve as a basis for calculating
the average Response Level. The device keeps a Response Level indicator
for each check. The Response Level is the average ratio between the
response time to the configured Timeout.
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
File:
This file is used by the device when the Web server requires a client certificate
during the SSL handshake.
Default value: Client certificate generated by the device.
SSL Private Key
File:
This file is used by the device when the SSL server requires a key during the
SSL handshake.
Default value: A private key generated by the device.
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.
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.
When several groups are associated with a single Checked Element, they are evaluated with a
logical AND between them.
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 Non-
Mandatory), another group contains Health Checks for the database servers (each check is Non-
Mandatory), 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.
Single Health Checks
You can add or edit health check parameters in the Check Table. The Check Table lists the
configured Health Checks.
To configure single health checks:
1. From the main window, select a device and select APSolute OS > Health Monitoring. The
Health Checks window appears.
2. Click Health Checks DB. The Health Check DB window appears.
3. To add a new health check: In the Health Check DB window, click Add. The Edit Health Check
window appears. In this window, you can create a new entry for the Health Check DB.
4. To edit an existing health check: In the Health Check DB window, click Edit. The Edit Health
Check window appears. In this window you can create a new entry for the Health Check DB.
5. Set up the check parameters for the device.
Health Check Name:
Name of the new check.
Method:
From the dropdown list, select the check method. For the full description
of methods, see Predefined Methods, page 302.
Destination Host:
IP address for the Health Check, (Mandatory field).
Note: You can specify any IP address to enable testing any network
elements. When the best possible IP is not available locally for
the device, a default gateway must be configured.
6. Click OK to apply the setup. The Health Checks you defined are listed in the Health Checks
table.
Next Hop Router:
The IP address of the Next Hop Router that is used for the Health Check.
The Health Check is sent to the Destination MAC address of the IP
address configured in this parameter. For example, this can be used when
you need to check the health of NHRs or a loopback server (The
Destination IP Address is the Virtual IP associated with the farm, the Next
Hop IP Address is the servers address).
The Next Hop IP Address must be on same network segment as one of
the device interfaces. When this is not configured and the Destination IP
Address does not reside on the same subnet, the Health Monitoring
module uses the devices Routing Table to forward the packet.
Destination Port:
Destination TCP/UDP port number to which the Health Check is sent.
Destination port is method specific.
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 is 2^32-1 seconds.
Default value: 10.
Retries:
Defines the number of times that a Health Check must fail before the
Health Monitoring module sets the elements availability status to Down.
Note: This field accepts only integers.
Timeout:
Defines the maximum number of seconds that the device waits for a
response to the Health Check. Maximum value is 2^32-2 seconds.
Note: This field accepts only integers.
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.
Measure Response
Time:
If applicable, select this option to enable the parameter.
Using Response Time Dispatch Method, this indicates whether the check
response time participates in measuring response time.
Note: The average response time is calculated over a number of
checks, as defined in the Response Level parameter. For more
information on this dispatch method, see Response Time,
page 130.
Reverse Check
Result:
Reverse Check Result parameter indicates whether the check fails when
a reply is received according to the check arguments, or the check passes
when no reply received. Default is that the check fails when the server
does not reply.
Uptime %:
Percentage of successful checks out of the total number of checks. This is
a read-only field.
Success Counter:
Total number of the successful checks bound to the checked element.
This is a read-only field.
Failure Counter:
Total number of the unsuccessful checks bound to the checked element.
This is a read-only field.
Average Duration:
Average Duration is the average of the checks in milliseconds (measured
as: the sum of each Check Duration / Response Level sample).
7. For each selected method, you can edit the arguments. In the Edit Health Check window, click
Method Arguments. The Edit Method Arguments window appears with additional configurable
parameters.
Note: Arguments are method-specific. For a full list, see Additional Method Arguments,
page 307.
8. Select or type the relevant values for the arguments and click OK. The Edit Method Arguments
window closes. The information you added appears in the Specific Check parameter pane in the
Edit Health Check window.
9. Click OK. The Health Check is configured and the Edit Health Check window closes. The new
Health Check now appears in the table in the Health Check DB window.
10. In the Health Check DB window, repeat steps 2 to 6 to configure additional Health Checks, as
required.
Group Health Check
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.
To configure a Group Health Check
1. In the main window, select a device and select APSolute OS > Health Monitoring. The Health
Checks window appears.
2. Click Add. The Edit Active Health Check window appears.
3. Clear the Mandatory checkbox. Click Apply and OK.
4. To add a new health check group: In the Health Checks window, click the Group option and
click Add. The Edit Health Check Group window appears.
5. To edit an existing health check group: In the Health Checks window, click the Group
option and click Edit. The device Edit Health Check Group window appears.
6. From the Group Check Name dropdown list, select the name of the Health Check created in step
1.
Note: You can set up to 20 groups for a Checked Element.
7. From the Element Name dropdown list, select the name of the network element to check. The
group check you defined appears in the Edit Health Check Group table.
8. In the Enable column, select the checks required for this group.
9. In the Mandatory column, select the mandatory or non-mandatory status for each Health Check
(define if the Health Check must be mandatory to determine thes health).
10. Click Apply. The Health Check group is configured.
11. Continue to configure new groups, or click OK to exit the window. In the Health Checks window,
the group you configured is listed in the Groups column, while the checks for each group are
listed in the Health Checks column.
12. Click OK. The Health Checks window closes.
Action Macro
The Action Macro feature allows an action to be performed based on the status of a Health Check.
The action is performed by running a predefined macro file, which is bound to the Health Check.
Configuration of this feature involves the following stages:
1. Define the relevant Health Checks in the Health Checks DB window.
2. Record the macro files to execute upon receiving a trap from the device.
3. Bind the Health Checks and the macro files in the Health Check Actions window, which is
accessed by clicking Action in the Health Check DB window, see Single Health Checks,
page 298.
To configure an Action macro:
1. In the main window, select APSolute OS > Health Monitoring. The Health Checks window
appears.
2. Click Health Checks DB. The Health Checks DB window appears.
3. Click Action. The Health Check Action window appears.
4. Click Add. The Edit Health Check Action window appears.
6. To edit the arguments for the selected action, click Action Arguments. The Macro Action
window appears.
7. Set the following parameters for the action according to the explanations:
8. Click OK to exit. The configured test is updated in the Health Check DB window.
9. Click OK to apply the setup and exit. The Health Check DB window closes.
Health Checks Per Server
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.
To configure Health Checks per server:
window appears.
2. In the Farms pane, select the farm that you want to check. The Farm window appears.
3. Select the farm server, then select the Health Monitoring Settings button. The Health Checks
Per Server window appears.
Check Name:
Checks for which you want to define an Action macro.
Condition:
Health Check status to activate the Action macro.
Value range: Success; Fail. Default value: Success.
Action:
Select the type of action.
Value: Macro.
Device:
Select the relevant device.
File Name:
Select the relevant Macro File.
4. To add a health check per server: In the Health Checks Per Server window, click Add. The
Edit Active Health Check window appears. Set up the Farm Health Check.
5. To edit an existing health check per server: In the Health Checks Per Server window, click
Edit. The Edit Active Health Check window appears. Edit the Farm Health Check.
6. From the Health Check Name dropdown list, select the name of the check. For the remaining
parameters and settings in the Edit Active Health Check window, see Health Checks, page 297.
7. Click OK to apply the setup. The new farm check appears in the Health Checks per Farm table.
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.
To configure Health Checks Per Farm:
window appears.
2. In the Farms pane, select the farm to be checked and click Health Monitoring Settings. The
Health Checks Per Farm window appears.
3. To add a health check per farm: In the Health Checks Per Farm window, click Add.
4. To edit an existing health check per farm: In the Health Checks Per Farm window, click
Edit.
5. In the Edit Active Health Check window, select from the following options:
a. Duplicate this Health Check for all Farms servers: If you select this option, the Health
Check you define is replicated and assigned to all the servers in the selected farm. You can
configure up to four applications running on the server at any given time.
b. Set Health Check attribute for each Server in the Farm:
c. If you select this option, you can manually configure a custom Health Check for each server
in the selected farm.
6. From the Health Check Name dropdown list, select the name of the check. For the remaining
parameters and settings in the Edit Active Health Check window, see Health Checks, page 297.
7. Click OK to apply the setup. The new farm check appears in the Health Checks Per Farm table.
Health Check Methods
This section describes methods and protocols used in the Health Check configuration. This section
Predefined Methods, page 302
User Defined Methods, page 313
Predefined Methods
The following table describes the predefined Health Check Methods with the configurable
parameters.
Table 38: Health Check Methods
ARP:
The module sends an ARP request to the Destination address, and waits for a
reply.
Arguments: N/A.
Citrix Application
Browsing:
The module sends a "Hello" request to the Citrix server. The Citrix server
responds by sending the list of applications running on it. Based on the Citrix
servers reply, the module compares the applications available on the server with
a list of up to four applications configured by the user. If all the configured
applications are running on the Citrix server, the check passes. If none of the
configured applications 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. 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 this field is configured, it
can either accept an individual IP Address or a Network Address. When the
DHCP server replies to the health check, the device 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 field 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 this field is 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.
DNS Server: Non-mandatory parameters. When this field is 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.
WINS Server: Non-mandatory parameters. When this field is 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.
Domain: Non-mandatory parameters. When this field is configured, the
device compares the server's reply with the configured value. When the
server replies with a different value than the configured value, the check
fails.
MAC Address: Non-mandatory parameters. When this field is 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 field is
configured, the device uses the configured MAC address in the DHCP data
and not in the DHCP headers.
Replay Agent: Non-mandatory parameters. When this field 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 none of the fields are 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.
For details on the Diameter Argument list, see Table 39, page 308.
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: Host name to Query; Address to match.
FIX:
The module creates a FIX packet and sends it to the FIX server (after the TCP
handshake). A successful check is a check 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 value 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.
Table 38: Health Check Methods (cont.)
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 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; 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: Similar to HTTP Check (Host name, Path, HTTP Method, Authorized
Username and Password, Match Search String, Match Mode, HTTP 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:
User Name: 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.
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.
NNTP: The module executes a LIST command and verifies that the returned status is
valid.
Arguments: N/A
Physical Port:
The module checks the status of the physical interface. 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: Should Ping Fail; Ping Data Size.
Should Ping 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 value is 64 bytes.
POP3:
The module executes USER and PASS commands on the 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.
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.
Note: Ensure that the RADIUS server is configured to accept RADIUS
requests from the Radware device.
Note: 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: Path on the server (like HTTP); Host name.
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.
Max Forwards: The default value 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: Server name for the command. Default value: Radware.
Additional Method Arguments
You can configure additional arguments specific to each Health Check Method.
When using APSolute Insite, the Health Check window automatically shows argument values
relevant to the configured method, to fit required additional arguments for that check.
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.
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.
Note: :
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.
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).
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: Packet Sequence ID (the user-defined check).
UDP Port:
The module checks the availability of the specified UDP port. This check 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. The absence of a 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 in combination with
another server availability check like Ping or ARP.
Arguments: N/A.
To configure a Diameter health check:
1. From the main window select APSolute OS > Health Monitoring. The Health Checks window
appears.
2. Select Diameter Argument List. The Diameter Argument Lists Configuration window appears.
Set the following parameters according to the explanations provided:
Table 39: Diameter Argument List
CER Origin-Host:
Host name FQDN that identifies the end point which created the
Diameter message and is present in all Diameter messages.
The Origin-Host AVP may resolve more than one address.
CER Origin-Realm:
Contains the realm of the originator of the Diameter message and
is present in all Diameter messages.
CER Vendor-ID:
Value assigned to the vendor of the Diameter application by IANA.
The default is the value that identifies 3GPP.
CER Product-Name:
Vendor assigned name of the product.
Accepted Result-Codes:
A list of acceptable codes that can be received in CEA, DPA and
LIA messages. The codes are separated by commas (,) or semi
colons (;). The default value 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).
Application Message
Type:
Defines the application message to be sent after the Diameter
connection is established. The following values are supported:
LIR: AppDirector generates an LIR 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.
LIR Auth-Session-State:
Specifies which state is maintained for a particular session.
The following values are supported:
State Maintained (0): 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. This is the default value.
No State Maintained (1): Used to specify that no session
termination messages are sent by the access device upon
expiration of the Authorization-Lifetime.
LIR Destination-Realm:
Contains the realm (FQDN) to which the message is routed.
LIR Destination-Host:
Host name of the Destination Diameter server. The 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.
The following table lists the additional configurable method arguments for each Check Method, and
details mandatory arguments, default values, and more.
LIR Public Identity:
The public identity of the user being referred to in the LIR request.
DPR 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 (0): A scheduled reboot is imminent.
Busy (1): 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 determined that it
does not see a need for the transport connection to exist,
since it does not expect any messages to be exchanged in the
near future.
Table 40: Health Check Method Arguments
Method
Name
(and ID)
Argument
Name
Argument Description Manda-
tory
Additional Info Default
ARP (11) No args
DNS (10) HOST Host name to query. Yes
ADDR Address to be received. No Validate only the
DNS return
code.
FTP (6) USER Username. Yes
PASS Password. Yes
File Name The file to search on the FTP
server.
No No
HTTP (2) PATH Path of file on Web server to
be requested.
No Any configured
value must begin
with a/.
/
HOST Host name. No Server IP
address.
MTD HTTP method to submit. No G=GET, P=POST,
H=HEAD
G
PRX Use proxy HTTP. No Y=Use proxy HTTP,
N=Use Web server
HTTP.
N
NOCACHE Use pragma: no-cache. No Y=Use pragma: no-
cache, N=Do not
use pragma: no-
cache.
N
Table 39: Diameter Argument List
MTCH Pattern for content match. No Wildcards not
supported.
MEXIST Content match pattern is either
present or absent.
No Y=Fail check if
pattern not found,
N=Fail check if
pattern is found.
Y
USER Username for basic
authentication.
No
PASS Password for basic
authentication.
No
C1 Valid http code 1 No
IMAP (7) USER Username Yes
PASS Password Yes
LDAP USER Username
BASE The location in the directory
from which the search starts.
No If you configure
BASE, then ATTR is
mandatory.
SEARV The value to search. No
LDAPS USER A user with privileges to
search the LDAP server.
No If you configure a
user, then password
is mandatory.
PASS The password of the user. No If you configure a
user, then password
is mandatory.
BASE The location in the directory
from which the search starts.
No If you configure
BASE, then ATTR is
mandatory.
ATTR The attribute to search for, e.g
CN: Common Name.
No If you configure
ATTR, then BASE is
mandatory.
SEARV The value to search. No
PHYSICAL
PORT
NUMBER Physical port number. Yes
Table 40: Health Check Method Arguments (cont.)
Method
Name
(and ID)
Argument
Name
tory
PING (0) FAIL Check fails when reply is
received or not received.
No Y=Fail when server
replies,
N=Fail when server
does not reply.
N
DSIZE Packet size No =1 - 1024 bytes 64
POP(3) USER Username Yes
PASS Password No
RADIUS
(12)
USER Username Yes
PASS Password Yes
SECRET Radius secret No
RTSP (13) PATH Path of file on RTSP server to
be requested.
Yes
HOST Host name to use in request. No IP address of server.
SNMP (15) OID Object ID to be used by the
check.
Yes
COMM The community used by the
device.
Yes
MIN The minimum value for the
check to pass. If the minimum
is lower than the configured
value, the check fails.
Yes
MAX The maximum value for the
check to pass. If the maximum
is higher than the configured
value, the check fails.
Yes
NNS The value between the NNS
and the max. If the value falls
between these two numbers,
then the Checked Element is
in No New Session mode.
Yes
UR The measured response time
for the check.
Yes No No
SSL Hello SSLV v2.3 or v3.0. 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).
Yes V2.3 or V3.0 v3.0
SMTP (4) HELLO Argument for SMTP HELLO No RADWARE
SSL (14) HOST Host name No Server IP
address
Method
Name
(and ID)
Argument
Name
tory
PATH Path of file on Web server to
be requested.
No Any configured
value must begin
with a/.
/
HTTP
Method
HTTP method to submit. No G=GET, P=POST,
H=HEAD
G
MTCH Match Search String: Pattern
for content match.
No Wildcards not
supported.
Match mode
String exists.
String is absent.
No Y
USER Username for basic
authentication.
No
PASS Password for basic
authentication.
No
TCP Port
(1)
Complete
TCP
Handshake
Sets whether the check sends
an ACK packet before the RST
packet or not.
No
Complete
with FIN
When enabled, the device
ends the TCP check with a FIN
Packet.
Disable
TCP user-
defined (8)
SEQID Packet sequence to submit. Yes
Packet ID The ID number of the entire
packet sequence.
Yes
Sequence
Type
Whether or not this packet is a
Send or Receive packet.
Yes Value range: Send;
Receive.
Default value:
Send.
Compare
Method
How the Health Monitoring
module checks the received
packets for a required string.
Value range: Regular
Expression; Binary.
Yes Note: The Regular
Expression value
works for the
Receive packets,
while the Binary
value works for the
Send packets.
Default value:
Regular
Expression.
Sequence
String
The content of the packet for
the verification process. This
string is either sent within the
packet, or is matched when
the packet is received.
Yes The string can be up
to 225 characters
long.
Sequence
Description
The description of the specific
packet in the sequence.
No
UDP Port
(9)
no args
Method
Name
(and ID)
Argument
Name
tory
User Defined Methods
If you require a specific Health Check Method that is 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.
Note: User-defined Checks are available for TCP checks only.
To configure a user-defined method for Health Check
1. From the Device menu select APSolute OS > Health Monitoring. The Health Checks window
appears.
2. Click User Defined Methods. The User Defined Methods window appears.
3. Click Add. The Edit User Defined Methods window appears.
SIP UDP
(19)
UR The URL for the check. Yes
FROM The senders information. Yes
FRWD The maximum number of hops
between Proxy Servers.
No
MTCH Pattern for content match. No Wildcards not
supported.
MEXIST Content match pattern is either
present or absent.
No Y=Fail check if
pattern not found,
N=Fail check if
pattern is found.
C1 Valid SIP code 1 No
Method
Name
(and ID)
Argument
Name
tory
Sequence ID:
Sequence of packets, used as an argument in the TCP User Defined
health check. All packets with the same Sequence ID belong to the
same sequence. The same sequence ID can be used in multiple
checks. The maximum value for Sequence ID is: 429496729.
Packet ID:
Identifies order of sending and receiving packets within this packet
sequence. Several packets carrying information can be defined to a
user-defined check of the same sequence ID. This identifier is unique
within a packet sequence.
Note: The first Packet ID of each sequence must always be 0
and Packet IDs of a sequence must always be
consecutive.
Sequence Type:
Enables the server to define whether packet is a Send or Receive
packet.
Compare Method:
For example, if the String field is defined as "^blue" and the Compare
Method value is defined as Regular Expression, the Health
Monitoring module matches the first expression which starts with the
word blue. If the value of the Compare Method is set to Binary, the
Health Monitoring module searches for the string ^blue, taking into
account the character ^.
This string is either sent within the packet or expected when the
packet is received. For Receive type packets, the string can include
a regular expression, which is a very effective method of describing a
pattern of characters. The Health Monitoring module supports Posix
1002.3 regular expressions. The string can be up to 80 characters.
AppDirector Farm Connectivity Checks
This section describes additional options for server monitoring included in the Farm configuration
process. This section includes the following topics:
Introducing Farm Connectivity Checks, page 315
Ping Connectivity Method, page 316
TCP Port Connectivity Method, page 316
UDP Port Connectivity Method, page 317
HTTP Page Connectivity Method, page 318
Disabled Connectivity Method, page 320
Introducing Farm Connectivity Checks
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:
Sequence String:
The Health Monitoring method of TCP user defined allows definition
of binary packet sequences, which are sent within TCP segments, or
matched against the content of the received TCP segments. The
content of the packet sequence is denoted as an ASCII string with
certain escape sequences used to denote characters which are not
considered printable.
The escape sequences always start with the backslash character ('\'),
followed by one of the following characters:
- a - the ASCII '7' character is printed (Bell).
- b - the ASCII '10' character is printed (New Line feed).
- e - the ASCII '33' character is printed (Space).
- f - the ASCII '14' character is printed (Shift Out).
- n - the ASCII '12' character is printed (Form Feed).
- r - the ASCII '15' character is printed (Shift In).
- t - the ASCII '11' character is printed (Vertical Tab).
- v - the ASCII '13' character is printed (Carriage Return).
- {0,7}- if the backslash is followed by 3 octal digits, then the
character represented by an octal number, consisting of these digits,
is printed.
- x - the character represented by a 2 digit hexadecimal number,
inscribed right after the 'x', is printed. Special cases:
If the backslash character is the last character of the string, it is
discarded.
If backslash character is followed by any character other than those
listed above, it is printed verbatim. For example, if you wish to have a
backslash character in a binary string ('\'), it must be escaped: '\\'
Sequence Description:
Sequence Description: This is a textual description of the packet
sequence.
Note: Once a sequence is configured it is not possible to change
the Sequence Type from send to receive and vice versa.
Basic: Farm Connectivity Check.
Advanced: Health Monitoring module, refer to Chapter 10.
Note: 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.
The basic farm connectivity checks are defined using the Connectivity Methods. The following
Connectivity Methods are available:
Ping
TCP Port
UDP Port
HTTP Page
Disabled
The following table describes parameters to configure the Connectivity Methods.
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.
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.
Table 41: Connectivity Checks General Parameters
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.
Value can be FTP, HTTP, SMTP, DNS, NNTP, HTTPS, RTSP,
RADIUS_1645, RADIUS_1812, or any port number you enter
manually. For example, HTTP automatically checks port 80.
Default value: HTTP.
Connectivity Interval:
How often AppDirector polls the servers (seconds).
Default value: 10.
Connectivity Retries:
Number of polling attempts that are made before a server is
considered inactive.
Default value: 5.
6. 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.
To set up the connectivity check using the TCP Port method
window appears.
2. In the Farms pane, double-click to select a farm. The Farm window appears.
3. Click Connectivity Check. The Connectivity Check pane appears.
4. Select TCP Port.
5. Set the Connectivity Interval, Connectivity Check Port and Connectivity Retries parameters, as
described in Table 41, page 316.
6. In the Farm window, click Apply and OK. The Farm window closes.
7. In the Traffic Redirection window, click Apply and OK. The Traffic Redirection window closes.
8. In the main window, right-click the device icon and select SetUp. The SetUp window appears.
9. Select Global. The Global pane appears.
Note: Configurations established in the Advanced Settings window apply to all AppDirector
farms that use the TCP Port connectivity check method.
11. 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.
AppDirector checks the health of a RADIUS server by sending an access request on UDP port 1645
or 1812 to the RADIUS server. You need to define an Authorized username and Authorized password
to access RADIUS servers. AppDirector communicates with RADIUS servers using the predefined
shared key, called RADIUS Secret. The reply from the RADIUS server is checked by AppDirector. A
reply of access accept indicates that the server is healthy, otherwise the server is considered Not
in Service.
To set up connectivity checks using the UDP Port method
window appears.
2. In the Farms pane, double-click an existing farm. The Farm window appears.
3. Select Connectivity Check. The Connectivity Check window appears.
4. From the Connectivity Method dropdown list, select UDP Port.
5. Set the Connectivity Interval, Connectivity Check Port and Connectivity Retries parameters, as
described in Table 41, page 316.
To set up connectivity checks using the RADIUS method
window appears.
3. Click Connectivity Check. The Connectivity Check pane appears.
4. From the Connectivity Method dropdown list, select UDP Port.
5. Set the Connectivity Interval, and Connectivity Retries parameters, as explained in Table 41,
page 316.
6. From the Connectivity Check Port dropdown list, select RADIUS_1645 (for port 1645) or
RADIUS_1812 (for port 1812).
7. To configure the username and password to access the RADIUS servers, type the username in
the Authorized Username text box and the password (up to 16 characters) in the Authorized
Password text box.
Note: Ensure that the same username and password are configured on all RADIUS servers.
8. In the RADIUS Secret text box, type the RADIUS Secret (up to 16 characters).
Note: Ensure that the same Secret is configured on all RADIUS servers.
9. Configure the AppDirector IP address in the NAS (Network Access Server) configuration in all
RADIUS servers, with the appropriate username, password, and secret.
10. In the Farm window, click Apply and then click OK. The Farm window closes.
11. In the Traffic Redirection window, click Apply and then click OK. The Traffic Redirection window
closes.
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 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. 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.
To set up the HTTP Page connectivity check method
window appears.
3. Select Connectivity Check. The Connectivity Check pane appears.
4. From the Connectivity Method dropdown list, click HTTP Page.
5. In the HTTP Page Check pane, set the Connectivity Interval, Connectivity Check Port, and
Connectivity Retries parameters, as explained in Table 41, page 316.
6. In the Retrieval Frequency text box, type frequency you want to request Web pages.
7. In the Home Page text box, type the URL of the Web page to retrieve from the servers.
8. To perform HTTP Page check of the password-protected HTTP page, set the following:
a. username, in the Authorized Username text box. This must be alphanumeric.
b. password (up to 16 characters), in the Authorized Password text box. The password must
be alphanumeric.
9. To configure the HTTP code for the servers response:
a. Click HTTP Codes. The Acceptable HTTP Codes window appears.
b. From the HTTP Code dropdown list, select the acceptable HTTP code that appears in servers
response. The default value is 200.
c. Click Add to include the selected code in the HTTP Code table.
d. Click OK. The Acceptable HTTP Codes window closes.
Note: You can repeat the process if multiple HTTP codes are considered valid, indicates a
healthy server.
10. To check the content of the returned Web page:
a. Click HTTP Content Check. The HTTP Content Check window appears.
b. In the Search String text box, type the string that you want AppDirector to look for.
c. From the Check Mode dropdown list, select String Exists, to show that the required service
is available, or select String Is Absent, to show that the required service is not available.
d. Click Add. The string appears in the HTTP Content table with its mode.
e. Click OK. The HTTP Content Check window closes.
13. Double-click the device icon. The SetUp window appears.
14. In the SetUp window, select Global. The Global pane appears.
Note: Configurations established in the Advanced Settings window apply to all AppDirector
farms using the HTTP Page Connectivity Check Method.
16. To delete the leading slash that appears after the URL of the default Web page, select
No Slash After GET in the Extended HTTP Check checkbox. The checkbox is cleared by default.
17. To define the Host name in the HTTP request, select an item from the Extended Check Host
Name dropdown list. The default value is Server IP.
To define a Long URL Check via Web Based Management
1. From the AppDirector menu, select Farms > Long URL Check. The Long Extended Check URL
window appears.
2. From the Farm dropdown list, select the farm for which you want to check connectivity.
3. In the Long Extended Check URL text box, type the URL and click Set.
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 value 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.
Note: 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.
Chapter 10 Security
This chapter provides a general overview of the APSolute OS Security modules and sub-modules,
and an explanation of the signatures database and Radware Security Update Service (SUS). This
chapter contains the following sections:
Security Overview, page 321
Managing the Signatures Database, page 331
Intrusions, page 339
DoS/DDoS, page 350
Behavioral DoS, page 359
SYN Flood Protection, page 366
Protocol Anomalies, page 373
Anti-Scanning, page 376
Session Table, page 377
Evasion Techniques, page 379
Security Events and Reports, page 382
Security Overview
This section introduces AppDirector security, and includes the following topics:
Security Introduction, page 321
Security Modules, page 322
Setting Up Security Policies in the Connect and Protect Table, page 324
Enabling Protection and Setting Up General Security Parameters, page 326
Defining Connectivity, page 329
Security Introduction
Radwares AppDirector security module performs deep packet inspection at multi-Gigabit speed to
provide security from the network layer up to the application layer, protecting against viruses,
worms, DoS attacks and intrusions, and anomalies. AppDirector provides secure Internet
connectivity with high performance, maintaining legitimate user traffic with advanced mitigation
tools that focus on:
Intrusions
DoS
Anomalies
SYN Flood
Anti-Scanning
Detecting
Security modules detect attacks by searching for attack signatures within scanned packets. Security
modules use a constantly updated signatures database for attack detection which is applied by
defining Protection Policies.
Security
Protecting
Security modules protect network and application level resources against attacks destined for the
internal IP addresses of the network elements or the device. Protection is provided for applications,
operating systems, network equipment and the resources behind the device.
Preventing
Security modules enable real-time attack prevention within the defined network. Attack attempts
are blocked by terminating the sessions as they are recognized, either by dropping malicious
packets or by resetting connections. Both source and destination reset options are supported.
Security modules also protect against network port scanning using the Anti-Scanning module tool.
Hackers scan prior to an attack, looking for open TCP or UDP ports on the target machine. Blocking
this prevents attacks.
Reporting
When a security module detects an attack, it reports the security event. This event includes
complete traffic information, comprises source and destination IP addresses, TCP/UDP port
numbers, physical interface, date and time of attack, etc. Event information is registered internally
via the device log file and alerts table, or externally via the Syslog channel, SNMP Traps, or E-mails.
Using APSolute Insite, you can produce advanced statistic reports; for example, top attacks, total
attack traffic, attacks per IP address, and more.
Radware Security Update Service on the Web
Radware's Security Update Service delivers immediate and ongoing security filter updates, and is
available on a one-year or multi-year subscription basis for all AppDirector and APSolute OS Security
customers.
Security Modules
AppDirector Security comprises the following modules:
Intrusions
DoS/DDoS
SYN Floods
Anomalies
Anti-Scanning
Intrusions
Intrusion prevention identifies potential intrusions into a system and prevents their damage by
blocking attacks. These attacks threaten application integrity bringing down networks and
applications. Most attacks target web applications, and therefore cannot be blocked by access
control devices.
The AppDirector Intrusions module provides protection against application specific attacks aimed at
damaging various network resources and disabling the attacked system. These attacks include:
Web Server attacks aimed at damaging or exploiting web servers.
E-mail attacks, like sending worms via E-mail.
Attacks on services, such as FTP or RPC.
Security
DoS/DDoS
When hackers send mass volumes of traffic, they overload networks or servers, causing denied
access for users. This is known as Denial of Service (DoS) or Distributed Denial of Service (DDoS)
attacks. DoS Shield samples traffic flowing through the device, recognizing and limiting the
bandwidth of traffic recognized as a DoS attack, using predefined action.
The Denial of Service (DoS) attacks compromise the availability of computing resources. Usually
DoS attacks include ICMP floods, UDP floods and TCP-SYN floods that consume network bandwidth,
preventing transport of legitimate traffic. The AppDirector DoS Shield module describes the process
of protection against Denial of Service attacks. This module provides protection against flooding of
UDP, TCP and ICMP.
Radware's security scheme, implemented by the DoS Shield module, which is part of the APSolute
OS architecture, provides organizations with extensive Denial of Service (DoS) detection and
protection capabilities while maintaining high network throughput.
AppDirector DoS protection module provides real time DoS protection using an advanced sampling
paradigm, comparing sampled traffic with a list of attacks signatures (attacks in Dormant state) in
the AppDirectors attack database. The attacks signatures are looking for known flood tools by
recognizing unique bit patterns within the sample traffic. Once the activation threshold of an attack
in the Dormant state is met, its status changes to Currently Active, which means that each and
every packet is matched with the signature file of this Currently Active attack. If a match is found,
the packet is dropped. If there is no match, the packet is forwarded to the network.
SYN Floods
A SYN flood attack is a denial of service attack where the attacker sends a huge amount of please-
start-a-connection packets but no follow up packets. AppDirector provides protection against any
type of SYN flood attack, irrespective of the tools that are used to launch the attack. This protection
service utilizes a process called SYN Cookies that performs delayed binding (terminates TCP
sessions) and inserts a certain signature into the TCP sequence field.
SYN Flood Protection is a service that protects the hosts located behind a device, and the device
itself, from SYN flood attacks, by delayed binding. A SYN Flood attack sends a SYN packet without
completing the TCP three-way handshake. Another type of SYN Flood attack completes the TCP
three-way handshake, but sends no data packets afterwords.
After the completing the three-way handshake, AppDirector only processes requests that include the
signature previously inserted. This guarantees that only legitimate requests are sent to the servers,
while half open TCP connections, aimed at consuming servers resources, are terminated by the
AppDirector and do not flood the servers or the AppDirector itself. The attacks are detected and
blocked by SYN Flood Protection Policies. The reports regarding current attacks appear in the Active
Triggers table.
TCP-Handshake-Timeout
The Timeout for 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. The entry is then deleted from the Client Table and a Reset command is sent to the server,
releasing the resources allocated to this session.

TCP Handshake Timeout:
Possible values 1 to 10 seconds.
Security
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. This value applies when no further traffic is received from the client. Then, the entry is
removed from the Client Table and a Reset sent to the server.
A SYN Timeout of 0 (regular aging time) indicates that the parameter is disabled, and sessions are
removed from the Client Table according to the value defined as the Aging Time. For more
information (see SYN Flood Protection, page 366).
To set the SYN Protection Timeout
2. Click a cell in the SYN Flood column. The Settings pane appears under the table.
3. Click SYN Settings and click Edit Settings. The SYN Flood Protection Settings window
appears.
4. From the SYN Protection Timeout drop-down list, select a timeout value.
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 using Protocol Anomaly Protection.
The Anomalies module provides protection using two sub-groups:
Protocol Anomaly Protection.
HTTP Anomaly Protection.
Dropping malicious packets protects against Protocol Anomaly.
Anti-Scanning
Before launching an attack, a hacker normally tries to identify which TCP and UDP ports are open.
An open port represents a service, application, or backdoor. Ports unintentionally left open are a
serious security problem.
The Anti-Scanning module provides a process aimed at preventing hackers from gaining this
information by blocking and altering server replies sent to the hacker. This module provides
protection against network and port scanning by protecting against known scanning tools, and
scanning tools awaiting the positive reply (SYN-ACK for TCP or UDP reply). The filters in this group
block all traffic returned from the scanned server.
Setting Up Security Policies in the Connect and Protect Table
Radware Security works with the protection policies defined in the Connect and Protect Table. Each
row in the Connect and Protect Table represents a policy.
A security policy contains the security profiles activated within a predefined ranges of ports/VLANs
or within a predefined network. First, create a security policy and assign protection profiles to the
policy. Add protection profiles to the policy from any or all of the security modules.
Security profiles aggregate attack groups and attacks. Set one or more profiles for a security
module and associate a protection profile with a policy.
Security
The following figure shows the Connect and Protect Table. You can define the Action mode, the
actions AppDirector takes when an attack is recognized, for each policy.
Figure 22: Connect and Protect Table
Configuring a security policy includes enabling security, connecting, and protecting.
To configure Security Policies
1. From the main APSolute Insite window, select APSolute OS > Security. The Connect & Protect
Table window appears.
2. Enable security by configuring the security modules and defining the general security
parameters (see Enabling Protection and Setting Up General Security Parameters, page 326).
3. Configure connectivity by defining either port groups/VLANs or IP address ranges per row in the
Connect and Protect Table (see Defining Connectivity, page 329).
4. Define the Protection according to the protection module. For each connectivity row, set security
services according to the module breakdown:
a. Set up the Intrusion module parameters, see Intrusion Prevention Using Profiles and
Groups, page 340.
b. Set the DoS/DDoS module parameters, see DoS/DDoS, page 350.
c. Set up the SYN Flood module parameters, see SYN Flood Protection, page 366.
d. Set up the Anomaly module parameters, see Protocol Anomalies, page 373.
e. Set up the Anti-Scanning module parameters, see Anti-Scanning, page 376.
5. Define the Action parameters for this policy if an attack is detected:
Note: The Action mode settings do not apply to SYN Protection (see SYN Flood Protection,
page 366), as the delayed binding mechanism with embedded SYN Cookies cannot be
bypassed.
Block:
Packet is identified as an attack. To prevent the attack you need to define the
Block Action parameter of each security module.
Forward:
Packet is forwarded to the defined destination.
Mixed:
When you change the Action parameter of a security module using Web Based
Management, the Action mode appears as Mixed.
Security
Enabling Protection and Setting Up General Security Parameters
The Radware security solution takes a multi-layer approach to security that integrates several
methods of attack detection with advanced security modules, including Intrusions, DoS/DDoS,
Anomalies, SYN Flood Protection, and Anti-Scanning. The security modules are configured in the
Connect and Protect Table, and the methods of attack detection are configured in the Security
Settings window, as shown in the following figure:
Figure 23: Security Settings Window
Set the following general security settings in the Security parameters window:
Application Security.
DoS Shield.
Protocol Anomaly Protection.
Application Security Parameters
Application Security is a method providing advanced attack detection and prevention capabilities,
checking the traffic on a packet-by-packet basis. This method is used by the following security
modules to provide maximum protection for network elements, hosts, and applications: Intrusions,
Anomalies, Anti-Scanning, and Application Security for DoS/DDoS.
Note: Before using Intrusions, DoS/DDoS, Anomalies, and Anti-Scanning, enable Application
Security and set its parameters.
To start Application Security protection
1. Open the Security Settings window:
a. From the main APSolute Insite window, select APSolute OS > Security. The Connect &
Protect Table window appears.
Security
b. In the top right-hand corner of the Connect & Protect Table window, click Settings. The
Security Settings window appears.
Or:
a. From the main APSolute Insite window, right-click the AppDirector icon and select SetUp.
c. Select Security Settings and click Edit Settings. The Security Settings window appears.
d. The Modules pane contains the following parameters:
2. Select the Start Protection checkbox.
3. To terminate the whole session if a single malicious packet is recognized, check Session-
Drop Mechanism Status.
4. Click OK. You are prompted to reboot the device.
5. Click OK to reboot AppDirector. You can start using the Intrusions, DoS/DDoS, Anomalies, and
Anti-Scanning security modules.
DoS Shield Parameters
The DoS Shield implements a sampling algorithm to prevent traffic flooding of network services. This
algorithm is included in the DoS/DDoS security module.
Note: Prior to configuring the DoS/DDoS security module, you must enable DoS Shield and
set its general parameters.
To enable DoS Shield and set its general parameters
b. In the top right-hand corner of the Connect & Protect Table window, click the Settings
button. The Security Settings window appears.
Start Protection:
Select Enable to start protection.
Default: Enable.
Encoding:
Language encoding (language and character set) to use for detecting
security events.
Attacks DB Version:
Version number of current attack database loaded on the device.
Session-Drop
MechanismStatus:
When enabled, terminates the whole session when a single malicious
packet is recognized.
MinimumRisk
Level:
Device scans traffic only for attacks with risk level equal to or higher than
value of this parameter. Valid only for signature-based attacks
(Application Security and DoS Shield).
High
Medium
Low
Info - An IPS Attack For Which The Risk Parameters Is Set To Info, Is An
Ids Signature.
Security
Or:
2. In the Modules pane of Security Settings window, check Start DoS Shield Protection.
3. Click OK. You are prompted to reboot the device.
4. Click OK to reboot AppDirector.
5. Reopen the Security Settings window (as explained in step 1).
6. In the Modules pane of the Security Settings window, set the following parameters according to
7. Click OK. You can start using the DoS/DDoS security module.
Behavioral DoS
The B-DoS security policy contains security profiles that are activated within predefined ranges of
ports/VLANs, or within a predefined network.
Note: Before configuring the Behavioral DoS shield module you must enable it.
To enable Behavioral DoS
1. In the main window, click Security. The Connect and Protect Table appears.
2. In the Connect and Protect Table, double click on Settings. OR, from the main window, double-
click the device icon and then select Global > Security Settings > Edit Settings. The
Security Settings window appears.
3. In the Behavioral DoS field, enable Start Protection.
4. Restart the device. Behavioral DoS is now enabled.
Protocol Anomaly Protection parameters
The Protocol Anomaly Protection parameters are the general parameters of the Anomalies security
module.
Note: Before using Anomalies, you must enable the Application Security process and set its
parameters (see Application Security Parameters, page 326).
To set Protocol Anomaly Protection parameters
Packet
Sampling Rate
Rate at which packets are sampled and compared to Dormant Attacks. You
can configure the number of packets for which sampling is performed.
Default value is 101, 1 out of 101 packets is checked.
Sampling Time
(seconds)
Defines how often DoS Shield compares the predefined thresholds for each
Dormant Attack to the current value of packet counters matching the attack.
The default value is 5 seconds.
Security
b. In the top right-hand corner of the Connect & Protect Table window, click the Settings
button. The Security Settings window appears.
Or:
2. In the Modules pane of Security Settings, set the following parameters according to the
3. Click OK. The Security Settings window closes.
Defining Connectivity
When creating a security policy, you must initially define connectivity either by defining port groups/
VLANs or IP address ranges for each policy in the Connect & Protect Table.
Policies are represented by rows in the Connect & Protect Table. For each row, set connectivity and
security services according to the module breakdown (Intrusions, DoS/DDoS, Anomalies, SYN Flood,
Anti-Scanning).
Configuring Port Groups
Port groups allow you to define which ports are to be scanned.
To create a new port group
2. Double-click inside the Port/VLAN column. The Settings pane appears.
3. Click Add Port Group. The Edit Physical Port Group window appears.
4. In the Group box, enter a name for the new group.
5. Check the ports to be associated with the new group.
6. Click OK. The new port group is created.
To add ports to an existing Port Group
Max URL Length:
Maximum URL length permitted. If the URL is longer than the configured
value, it is considered illegitimate and is dropped. The default value is
500 characters.
Min Fragment Size:
Minimum size of fragmented IP packet permitted. A shorter packet
length is treated as an IP protocol anomaly and is dropped. The default
value is 512 Bytes.
Min Fragmented URI
Packet Size:
Minimum permitted size of an incomplete URL in an HTTP request. A
shorter packet length is treated as a URL protocol anomaly and is
dropped. The default value is 50 characters.
Security
3. Select the port group name from the Port Group drop-down list.
4. Click Port Group Table. The Port Groups window appears.
5. Click the Modify Table tab. The Modify Table pane appears.
6. Select the table entry for the group that you would like to modify.
7. Click Edit. The Edit Physical Port Group window appears.
8. Check the ports that you would like to add to the group.
9. Click OK. The port group is updated.
Configuring VLANs
You can define which VLANs are to be scanned.
To define which VLANs are to be scanned
3. Click Add VLAN Tag Group. The Edit VLAN Tag Group window appears.
5. Click OK. The Edit VLAN Tag Groups window closes.
Configuring Networks
You can set the network IP address range to be scanned.
To configure a new network
2. Double-click inside the Networks column. The Settings pane appears.
3. Click Add Network. The Edit Network Table window appears.
Group Name:
A user-defined name for the VLAN group.
Group Mode:
Set VLAN mode to one of the following:
Discrete: Individual VLAN tag, defined in device interface parameters.
Range: Group of sequential VLAN tag numbers, as defined in device
interface parameters.
VLAN Tag:
VLAN tag number. Set VLAN Tag if Group Mode is set to discrete.
VLAN Tag From:
First VLAN tag in range. Set VLAN Tag From if Group Mode is set to range.
VLAN Tag To:
Last VLAN tag in range. Set VLAN Tag To if Group Mode is set to range.
Security
To define a network from the predefined list
2. Double-click inside the Networks column. The Settings pane appears.
4. Click Apply. Your preferences are recorded.
Managing the Signatures Database
This section explains the signature database feature and how to configure it and includes the
following topics:
Protection Profiles and Groups, page 331
Security Signatures File Update, page 335
Protection Profiles and Groups
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 in the Connect and Protect
Table.
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 in the Connect and Protect Table. Protection profiles can contain various groups
or attacks, providing maximum protection for specific types of networks.
The following table presents profiles supplied by Radware.
Network Name:
A user-defined name for the network.
Network Mode:
Set network mode to one of the following:
IP Mask.
IP Range.
FromAddress:
The first address in the range.
To Address:
The last address in the range.
From:
The first address in the range.
To:
The last address in the range.
Check Packets:
Profile inspection direction; one-way or two-way.
Security
The following table describes the Radware attack groups:
Table 42: Radware Supplied Protection Profiles
Profile Description
Corporate
Gateway:
Protects the corporate network gateway. This blocks all possible intrusions passing
through the firewall, intrusions affecting the firewall, attacks affecting network stability,
and attacks assisting intruders collecting information.
Corporate
DMZ:
Protects the corporate DMZ network and generic network services provided to the
Internet and to local area network.
Corporate
DMZ Mail:
Protects the corporate DMZ network mail servers.
Corporate
DMZ Web:
Protects corporate DMZ network web servers. This protects against web server and
web application vulnerabilities.
Corporate
LAN:
Protects corporate LAN network. This protects against worms spreading amongst the
clients of a local area network and against vulnerabilities that could affect
workstations.
Carrier / POP:
Protects carrier networks, backbone networks, and ISP dial-in networks. This
protects against malicious attacks that affect the Internet in general reducing the
interruption of Internet freedom provided to Internet users.
University
LAN:
Protects the LAN in university-type networks. Attacks can originate from workstations
in the local area network. Filter groups are defined to inspect traffic in all directions
preventing information gathering that can be used as the basis for an intrusion.
Table 43: Radware Supplied Attack Groups
Attack Group Description
Top-N:
The "Top-N" group contains attack signatures that have the highest activity in the wild.
This group is updated whenever Radware's SOC finds it necessary. The signature
subset in "Top-N" is compiled from various services and moved to (or from) an
appropriate group.
Worms:
This contains attack signatures classified as Internet worms. The types of worms in this
group include: mass-mailing worms, vulnerability exploiting worms, and network-aware
worms. Signatures in the "Worms" group stop the propagation of the worms listed in the
group.
IIS:
This contains attack signatures that exploit the vulnerabilities found in the Microsoft IIS
Web Service. They protect against HTTP implementation attacks, default web page
attacks, ISAPI extension attacks and SSL attacks.
Apache:
This contains attack signatures that exploit the vulnerabilities found in Apache HTTP
and other modules. They protect against HTTP implementation attacks, default server
attacks and vulnerabilities found in Apache modules.
HTTP-MISC:
This contains attack signatures that exploit vulnerabilities found in miscellaneous web
services. They protect against HTTP implementation attacks, exploitation of various
web applications and information disclosure attacks.
Web:
This contains attack signatures that perform command injection into web services.
They prevent the command's injection into web applications. Command injection allows
command execution on the affected host with privileges on the web server.
CGI:
This contains attack signatures that exploit CGI vulnerabilities in web applications.
They prevent the exploitation of vulnerabilities found in CGI scripts that could allow an
attacker to compromise the affected host.
Security
XSS:
This contains attack signatures that perform cross-site scripting in web applications. In
cross-site scripting, a script is injected into a dynamic HTML page. When viewed by
other users, the page is redirected to malicious sites, using the users' local environment
credentials without them being aware of it. They prevent cross-site scripting on the
affected host that can lead to information theft and web session hijacking.
SQLInjection
:
This contains attack signatures that perform SQL database modifications. They prevent
the SQL queries' injection via web applications. A successful SQL query injection may
lead to information disclosure, data modification and data corruption.
ColdFusion:
This contains attack signatures that exploit vulnerabilities in the ColdFusion web
service. They prevent the exploitation of vulnerabilities found in the ColdFusion web
service which may compromise the affected host.
FrontPage:
This contains attack signatures that exploit vulnerabilities in the FrontPage Web
Service. They prevent the successful exploitation of vulnerabilities found in FrontPage
web service which may compromise the affected host.
SMTP_AS:
This contains attack signatures that exploit vulnerabilities in miscellaneous SMTP
servers. They prevent the exploitation of vulnerabilities found in SMTP implementation
from miscellaneous vendors and prevent the propagation of Internet worms.
Telnet_AS:
This contains attack signatures that exploit vulnerabilities in miscellaneous Telnet
servers. They prevent the exploitation of vulnerabilities found in Telnet implementations
from miscellaneous vendors.
FTP_AS:
This contains attack signatures that exploit vulnerabilities in miscellaneous FTP
servers. They prevent the exploitation of vulnerabilities found in FTP implementations
SQL_AS:
This contains attack signatures that exploit vulnerabilities in miscellaneous SQL
servers. They prevent the exploitation of vulnerabilities found in SQL implementations
NetBIOS:
This contains attack signatures that exploit vulnerabilities in NetBIOS service. They
prevent the exploitation of vulnerabilities found in NetBIOS implementations.
DNS_AS:
This contains attack signatures that exploit vulnerabilities in miscellaneous DNS
servers. They prevent the exploitation of vulnerabilities found in DNS implementations
POP3_AS:
This contains attack signatures that exploit vulnerabilities in miscellaneous POP3
servers. They prevent the exploitation of vulnerabilities found in POP3 implementations
IMAP_AS:
This contains attack signatures that exploit vulnerabilities in miscellaneous IMAP
servers. They prevent the exploitation of vulnerabilities found in IMAP implementations
RPC-Unix:
This contains attack signatures that exploit vulnerabilities in the Sun RPC service. They
prevent the exploitation of vulnerabilities found in Sun RPC implementations from
miscellaneous vendors.
ICMP_AS:
This contains attack signatures that exploit vulnerabilities in ICMP services. They
prevent the exploitation of vulnerabilities found in ICMP implementations from
miscellaneous vendors.
Finger:
This contains attack signatures that exploit vulnerabilities in Finger service. They
prevent the exploitation of vulnerabilities found in Finger implementations from
miscellaneous vendors and prevent information gathering attempts.
Buffer_Overfl
ow:
This contains attack signatures that exploit various services by overflowing the
declared buffer. They prevent attempted buffer overflow exploitation in those services
that do not fit the other service groups. Exploitation of vulnerabilities found in those
services compromise the affected host.
Table 43: Radware Supplied Attack Groups (cont.)
Security
Note: Groups can change according to the Signatures File version.
SNMP_AS:
This contains attack signatures that exploit vulnerabilities or bad configuration in SNMP
services. They prevent access to SNMP services with public community strings and
exploitation of vulnerabilities found in SNMP implementations.
Brute-Force:
This contains signatures of password brute force attacks in miscellaneous services.
These signatures prevent the password-guessing attacks (brute force) in
miscellaneous services.
DoS:
This contains signatures of denial-of-service attacks on miscellaneous services and
protocol implementations. They prevent the DoS attacks against miscellaneous
services and protocols.
Backdoors_I
nbound:
This contains signatures of backdoor communication that enter the infected host. They
prevent inbound backdoor communication and prevent the backdoor from being
controlled remotely.
Backdoors_
Out-bound:
This contains signatures of backdoor communication that exit the infected host. They
prevent outbound backdoor communication and prevent the backdoor from being
controlled remotely.
Protocol_An
omalies:
This contains signatures of miscellaneous protocol misbehaviors. They prevent the
usage of miscellaneous protocol anomalies that could indicate a new exploitation of
protocol vulnerability or a DoS attack.
Archive:
This contains signatures of miscellaneous out-dated attacks. These signatures prevent
out-dated attacks that are no longer valid. The group may include various types of
attacks from miscellaneous groups.
SIP:
This contains filters for protection against SIP threats. SIP (Simple Initiation Protocol) is
a protocol used to stream live video and audio data, for example, VoIP. These filters
protect SIP-based application vulnerabilities, and vulnerabilities and generic
protections of the SIP protocol itself.
Oracle:
This contains filters for protection against Oracle server related threats. Oracle is a
common database server software. Threats against Oracle servers can cause data
manipulation, data loss, theft of sensitive data and other serious consequences. The
filters that are found in this group protect against known DCE-RPC threats.
Command
Execution:
This contains filters for various vulnerabilities that allow a remote attacker to execute
commands on a target system. By executing these commands with higher than normal
permissions, the attacker can disrupt network services, modify important files, and
compromise the target system. The vulnerabilities that allow command execution cover
various services and operating systems, and constitute an extremely high risk to
system and network integrity.
Routers:
This contains filters to protect against known vulnerabilities in network routing devices.
The vulnerabilities can allow a remote attacker to disrupt network services and create a
denial of service condition. In some cases, successful exploitation may give an attacker
access to sensitive parts of the network by modifying security settings or changing
routing rules.
MS-RPC:
This contains filters for protection against threats traveling over Microsofts DCE-RPC
protocol. DCE-RPC is a common Internet protocol, which can be exploited in various
ways, causing various types of damage. The filters in this group protect against known
DCE-RPC threats.
Table 43: Radware Supplied Attack Groups (cont.)
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 the best protection for your network, it is recommended to set automatic
daily updates.
Manual Update
If you have an updated file that was downloaded manually from the Radware website, you can
upload the signatures file to AppDirector manually.
To update the signatures file manually
1. From the main APSolute Insite window, open the APSolute OS menu and select Security
Updates > Upload Attacks File. The Upload Attacks window appears, displaying a list of
devices that have a Service Agreement.
2. In the Upload Attacks table, check the devices to which you want to send the signatures
database update.
Security
Note: You must choose only the devices that have an Application Security Signature File
Update Service Agreement with Radware Support.
3. Click Browse and navigate to the signature file that you downloaded from the Radware Security
Zone (http://www.radware.com/content/security/attack/weeklyupdates.asp).
4. Click Send Attacks File To Selected Devices. An upload progress bar and progress message
are displayed for each selected device.
5. Click OK. The selected devices are updated.
Downloading and Updating
You can download an update file from the Radware website and upload the file to AppDirector.
To download a signature file update from the Radware website and upload it to your
AppDirector
1. From the main APSolute Insite window, select APSolute OS > Security Updates > Upload
Attacks File. The Upload Attacks window appears, displaying a list of devices that have a
Service Agreement.
2. In the Upload Attacks table, check the devices you want to update.
3. Click Check Now to check if a signature update file is available on the Radware website. If it is
available, you are prompted to download it.
4. Click Browse and navigate to the signature file that you downloaded.
5. Click Send Attacks File To Selected Devices. An upload progress bar and progress message
Scheduled Downloading and Updating
You can schedule automatic signature file downloads. Once the upgrade files are downloaded,
update the signatures file. Edit or remove the signatures file update settings from the Scheduler
window. To access the Scheduler window, open APSolute Insites Tools menu and select Scheduler.
You can also send an e-mail notification as part of the Automatic Signature File Update procedure.
The e-mail notification feature automatically sends an e-mail in the following cases:
The Signatures file has been downloaded to the APSolute Insite station.
The Signatures file has been downloaded to the APSolute Insite station and installed on the
device.
A single e-mail is sent per device informing the System Administrator of the action by APSolute
Insite.
To schedule automatic signature file downloads and updates
1. From the main APSolute Insite window, select
APSolute OS > Security Updates > Attacks Update Settings. The Edit Task window
appears.
Security
2. In the Time Settings area, specify the Start Hour.
Note: The End Hour option must not be enabled for this task.
3. In the Frequency Settings area, select Daily, Weekly or Minutes.
4. If you select Weekly, check which day to run the update.
5. If you select Minutes, type the number of minutes in the Minutes text box.
6. Click Next. A second Edit Task window appears, displaying a table of all devices in the network
site.
7. For each device, select the attacks update as follows:

Note: Select only devices that have an Application Security Signature File Update Service
Agreement with Radware Support.
8. To receive e-mail notifications about the attack update procedures
a. Check Signature File Update Email Notification.
b. Click Email Recipients. The E-mail Recipients window appears.
c. For each e-mail notification recipient, enter the e-mail address in the Recipients E-mail
field and click Add. Click OK to return to the Edit Task window.
d. If APSolute Insite is installed behind the proxy in your network, select Behind the Proxy,
and set the IP address and port of the proxy server.
e. Click Finish. The Edit Task window closes. The task appears in the Scheduler window (Tools
> Scheduler).
f. From the main menu, select Options > Preferences. The Management Preferences
window appears.
g. Click the Traps and SMTP tab. The Traps and SMTP pane appears.
Download and
Install:
The Application Security Signature file is automatically downloaded and
installed on the device according to the predefined schedule.
Download:
The Application Security Signature file is automatically downloaded according
to the predefined schedule. You need to install the file to use it.
Ignore:
No files are automatically downloaded to this device.
Security
h. Set the following parameters according to the explanations provided:
i. The format of the e-mail messages is as follows:
When the Download and Install procedure is configured:
When the Download procedure is configured:
9. If you selected Download in step 7 above, from the main window open the APSolute OS menu
and select Security > Upload Attacks File. The Upload Attacks window appears.
Or:
10. If you selected Download and Install in step 7 above, installation is complete. Signature file
updates are downloaded and installed automatically.
11. Select the Updates button. The Upload Attacks window appears, displaying the list of devices
that have Service Agreement.
User E-mail
Address:
Enter the mail address of the APSolute Insite station.
SMTP Server
Address:
Enter the address of the SMTP server to which the APSolute Insite station
sends the notification e-mails.
Traps Automatic
Save:
Check this box to enable logging of SNMP traps in a dedicated log file.
Traps Auto Save
File:
Enter the complete path and file name of the log file.
Email
subject:
Attacks File Update Status
Email body:
"Attacks Signature File downloaded and installed for device: <Device Type:Device
IP:MAC Address>".
Email
subject
Attacks File Update Status
Email body:
"Attacks Signature File downloaded for device: <Device Type:Device IP:MAC
Address>".
Security
12. In the Upload Attacks table, check the devices to which you want to send the signatures
database update.
Note: Select only devices that have an Application Security Signature File Update Service
Agreement with Radware Support.
13. Click Browse and navigate to the signature file that you downloaded from the Radware Security
Zone (http://www.radware.com/content/security/attack/weeklyupdates.asp).
14. Click Send Attacks File to Selected Devices. An upload progress bar and progress message
Intrusions
This section explains how to protect against intrusions into your network. This section includes the
following topics:
Introduction to Intrusions, page 339
Intrusion Prevention Using Profiles and Groups, page 340
Defining Intrusion Prevention with User-Defined Settings, page 340
Setting Up Attacks and Filters, page 341
Custom Attack Groups, page 348
Creating a New User-Defined Intrusion Prevention Profile, page 349
Introduction to Intrusions
The Intrusions Prevention module provides advanced intrusion detection and prevention capabilities,
including maximum protection for network elements, hosts and applications, by preventing various
intrusion attempts, including worms, Trojan horses, buffer overflow and other application-oriented
attacks.
Types of Attacks
Attacks are recognized by comparing each packet to a set of signatures stored in the Signatures
database. Attacks handled by the Intrusions module include:
Network-Oriented Attacks.
Security
Operating-System Oriented Attacks.
Application-Oriented Attacks.
Network-Oriented Attacks
Network-based attacks use network layer packets, such as IP, TCP, UDP, or ICMP packets to either
learn about or damage a destination host.
Operating System-Oriented Attacks
Operating System (OS)-oriented attacks break into the server by exploiting vulnerabilities in the
servers operating system. The target of the OS-oriented attack is usually to disable application
server functionality by damaging its flow or one of its resources.
Application-Oriented Attacks
Application-oriented attacks break into application servers. These attacks are recognized by
searching for the known signatures of each application in the packets; for example, a specific path
or a particular command appearing in a packet. Application-oriented type attacks attempt to exploit
vulnerabilities in the applications. Intrusion Prevention protects against these attacks by enabling
web-related protection policies.
Intrusion Prevention Using Profiles and Groups
An Intrusion Prevention Profile is a process that scans the traffic of a particular network and physical
port. The traffic classification is performed within the predefined network range with preconfigured
traffic direction. All packets passing through this range are examined by various protectors called
Attacks. Intrusion prevention profiles are applied to attack groups. An attack group uses attacks as
building blocks. Attacks contain filters. Each filter represents a signature for blocking a single attack.
Intrusion prevention profiles can only use attacks that are organized in attack groups. An attack
group represents a logical OR relation between its attacks.
An intrusion prevention profile is built over a single attack group and defines network conditions to
which the attack is scanned. Each intrusion prevention profile can be assigned to a policy specifying
network, physical inbound port parameters and direction. Radware provides a list of predefined
protection profiles that meet the requirements of various network conditions. Radware supplies a set
of predefined attack profiles and attack groups that provide constant protection against all recent
attacks (see Protection Profiles and Groups, page 331). You can use these to define protection
policies. Most of the existing intrusions can be prevented using Radware profiles.
To configure Intrusion Prevention using Radware Defined Profiles
1. Enable the Intrusion Prevention security module and define the general parameters (see
Enabling Protection and Setting Up General Security Parameters, page 326).
3. Double-click inside the Intrusions column. The Settings pane appears.
4. From the Intrusion Prevention Profiles list, select predefined intrusion prevention profiles and
apply to the policy in the Connect & Protect Table.
Defining Intrusion Prevention with User-Defined Settings
You can also create custom prevention profiles, custom attack groups, and custom attacks based on
custom filters. For new users, it is recommended to define intrusion prevention profiles using
Radware-defined attack groups only.
Security
To configure Intrusion Prevention using User-Defined Profiles
1. Enable Intrusion Prevention and define the general parameters (Enabling Protection and Setting
Up General Security Parameters, page 326).
2. Define custom attacks (see Setting Up Attacks and Filters, page 341).
3. Define custom attack groups (see Custom Attack Groups, page 348).
4. Define Intrusion prevention profile and apply it to the policy in the Connect and Protect Table
(see Creating a New User-Defined Intrusion Prevention Profile, page 349).
Setting Up Attacks and Filters
An attack (as shown in the following figure) is a building block of the intrusion prevention profile. It
contains one or more protection filters which determine which packets are malicious and how
AppDirector treats these packets.
Figure 24: CustomAttack Configuration
Each filter (Figure 25 Filter Configuration Window, page 342) contains one specific signature. Filters
are detectors that scan and classify the predefined traffic. The filters main purpose is to match the
specific packet within the traffic scanned by this filter with the attack signature from the Radware
Attack Signatures database (see Managing the Signatures Database, page 331).
Security
Figure 25: Filter Configuration Window
An attack can employ one or more filters. When more than one filter is used, the scanning process
represents a logical AND relation between the filters involved. The classification processes of all
filters applied to the same attack are involved in the scanning process. The traffic is checked for all
signatures defined in the attacks filters.
Note: For each custom attack, you must define custom filters. You cannot use filters from
other attacks when you define a custom attack.
An attacks settings parameters define how the malicious packet is tracked and treated once its
signature is recognized. Each attack is bound to a Tracking function that defines how the packet is
handled once it is matched with a signature. This is to determine whether the packet is harmful and
take appropriate action. There are two types of match functions:
The Immediate type that makes decisions based on a single packet. The signatures match to
the packet is considered an indicator for the attack, and the packet is dropped (Drop All); for
example, MS Blast.
The Threshold or Counter functions assume that a signature match alone is not enough to
decide whether a packet is offensive. The packet is considered legitimate unless the number of
packets over a period of time exceeds a threshold that defines reasonable behavior for such
traffic. Only packets that exceed the threshold within a predefined time slot are dropped; for
example, ICMP flood attacks and DoS attacks. The following table describes the attack
configuration parameters:
Table 44: Attack Configuration parameters
Attack Name
User-defined name for attack, maximum 30 characters.
Tracking Time
Sets amount of time, in milliseconds, for Threshold. When a number of packets
greater than the Threshold value passes through the device during this period,
the device recognizes it as an attack.
Security
Threshold
Sets maximum number of attack packets allowed in each Tracking Time unit.
They are recognized as legitimate traffic when transmitted within the Tracking
Time period.
Default value: 10.
Tracking Type
Defines how the device decides which traffic to block or drop, when under an
attack of this type. Values can be:
Drop All: Once the first packet is identified as harmful, the packet is
dropped. Select when each packet of the defined attack is harmful.
Sampling: A DoS shield attack.
Source & Target Count: Sessions counted per Source IP and Destination
IP combination. Select when defined attack is destination-based and
characterized by repeated packets.
Source Count: Sessions counted per Source IP. Select this when the
defined attack is Destination-based and characterized by repeated packets.
Target Count: Sessions are counted per Destination IP. Select this when
the defined attack is destination-based and characterized by repeated
packets.
Default: Drop All.
Action Mode
When an attack is detected, set one of the following:
Report Only: Packet forwarded to defined destination.
Drop: 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 TCP-Reset packet to the packet Source IP
and the packet Destination IP.
Default: Drop.
Risk Severity of damage that attack can cause to system.
High
Medium
Low
Info - An IPS attack with a Risk parameter set to Info is an IDS signature.
Default value: Medium.
Direction Sets the attacks inspection direction; incoming traffic, outgoing traffic, or both.
Suspend Action Sets the action in response to an attack:
None: Suspend action is disabled for this attack.
SrcIP: All traffic from the IP address identified as source of the attack are
suspended.
SrcIP, DestIP: Traffic from IP address identified as source of attack to the
Destination IP under attack is suspended.
SrcIP, DestPort: Traffic from IP address identified as the attack source to
the application (Destination port) under attack is suspended.
SrcIP, DestIP, DestPort: Traffic from the IP address identified as the
source of the attack to the Destination IP and port under attack is
suspended.
SrcIP, DestIP, SrcPort, DestPort: Traffic from the IP address and port
identified as the source of attack to the Destination IP and port under attack
is suspended.
Table 44: Attack Configuration parameters (cont.)
Security
To create a new attack
1. From the main window, select APSolute OS > Security. The Connect & Protect Table window
appears.
3. Click Custom Attack. The Attack Configuration window appears.
4. In the Attack Name text box, enter the name of the new attack.
5. Set the attack parameters, as explained in Table 44, page 342.
6. Click Add New. The Filter Configuration window appears.
7. In the Filter Name text box, enter the name of the filter.
8. Set the protocol parameters, as explained in Table 46, page 345.
9. Set the OMPC parameters. as explained in Table 47, page 345.
10. Define the content parameters, as explained in Table 48, page 347.
11. In the Filter Description text box, enter a description of the filter.
12. Click OK three times to return to the main window.
Filter Parameters
The parameters of each filter are divided into the following categories:
Description parameters
Protocol Definition parameters
OMPC (Bit pattern) Definition parameters
Content Definition parameters
Description Parameters
Description parameters are the user-defined descriptions of the custom attack, and are described in
the following table:
Drop Threshold
(Kbps)
Number of packets matching the attack that can be forwarded each second
when the attack is Active.
A value of Drop All (or 0) means that all packets must be blocked. Any other
value is used for attacks that match a pattern of legitimate traffic,e.g. UDP Flood
attacks.
Termination
Threshold (Kbps)
If this threshold is not exceeded during the Attack Aging Period, a notification is
sent indicating that the attack is over. This is higher than the Termination Alert
Threshold and lower than the Activation Threshold. You can also select "Do Not
Alert" (or 0).
State Select Enable to activate the policy. Default: Enable.
Filters A list of user-defined filters (see Defining DoS Shield Attacks and Filters,
page 354).
Table 45: Description Parameters
Attack Name
Name of the attack as you define it.
Description
Description of the attack.
Table 44: Attack Configuration parameters (cont.)
Security
Protocol Definition Parameters
Protocol definition parameters define transmission protocol, as described in the following table:.
To define a new application port group
1. In the Filter Configuration window, click App. Port Group. The Application Port Groups window
appears.
2. Click Modify. The Modify pane appears.
3. Click Add and set the parameters
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. Click OK. A new row appears in the Application Port Groups table.
OMPC (Bit pattern) Definition parameters
Offset Mask Pattern Condition (OMPC) parameters are a set of attack parameters that define a rule
for pattern lookups. The OMPC rule looks for a fixed size pattern of up to four bytes that uses fixed
offset masking. This is useful only for attack recognition where the attack signature is a TCP/IP
header field or a pattern in the data/payload in a fixed offset. The OMPC parameters are shown in
the following table.
Table 46: Protocol Parameters
Protocol Protocol used: IP, UDP, TCP, or ICMP. Default value: IP.
Application
Port Groups
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.
Values: 0 - 65535.
Destination
Port Group
For UDP and TCP traffic only. Select from the list of groups configured in the
Source Port
Group
For UDP and TCP traffic only. Select from the list of groups configured in the
Table 47: OMPC Definition Parameters
OMPC Length
Length of the OMPC data can be N/A, OneByte, TwoBytes, ThreeBytes, or
FourBytes.
Default value: N/A.
OMPC Pattern
The fixed size pattern within the packet that the OMPC rule attempts to find.
Possible values: a combination of hexadecimal numbers (0-9, a-f).
Value must be defined according to the OMPC Length parameters. The OMPC
Pattern parameters definition must contain eight 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.
Security
Content Definition Parameters
The Content parameters (Table 48, page 347) define the rule for a text/content string lookup. This
rule is intended for attack recognition where the attack signature is a text/content string within the
packet payload.
Offset
Location in the packet where the data checker started to find specific bits in the IP/
TCP header. The value can be: 0 - 1513.
Default value: 0.
OMPC Condition
OMPC condition can be either N/A, equal, notEqual, greaterThan, or lessThan.
Default value: N/A.
OMPC Mask
Mask for the OMPC data.
Possible values: a combination of hexadecimal numbers (0-9, a-f).
Value must be defined according to the OMPC Length parameters. The OMPC
Mask parameters 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 Mask can be: abcd0000.
OMPC Offset
Relative to
Indicates to which OMPC offset the selected offset is related. You can set the
following parameters: None, IP Header, IP Data, L4 Data, L4 Header, Ethernet.
Table 47: OMPC Definition Parameters (cont.)
Security
Table 48: Content Definition Parameters
Content Type
Enables user to search for a content type as follows:
N/A: Not available.
Host Name: In the HTTP header.
Header Type: HTTP header field. The Content field includes the header field
name, and the Content data field includes the field value.
Regular Expression: Anywhere in the packet.
Cookie Data: HTTP Cookie field. The content field includes the Cookie name,
and the content data field includes the Cookie value.
URL: In the HTTP request URL. No normalization procedures are taken.
Normalized URL: To avoid evasion techniques when classifying HTTP-GET
requests, the URL content is transformed into its canonical representation,
interpreting the URL 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.
Mail Domain: In the SMTP header.
Mail To: In the SMTP header.
Mail From: In the SMTP header.
Mail Subject: In the SMTP header.
File Type: The type of the requested file in the http GET command (jpg, exe,
etc).
POP3 User: User field in the POP3 header.
FTP Content: Scans the data transmitted using FTP, normalizes FTP packets
and strips Telnet opcodes.
FTP Command: Parses FTP commands to commands and arguments, while
normalizing FTP packets and stripping Telnet opcodes.
RPC: Reassembles RPC requests over several packets.
RPC RFC 1831 standard provides a feature called Record Marking Standard
(RM). This feature is used to delimit several RPC requests sent on top of the
transport protocol. For stream-oriented protocols (like TCP), RPC uses a kind
of fragmentation to delimit between the records. Fragmentation may also
divide records in the middle; not only at their boundaries. In some cases, this
functionality is used to evade IPS systems.
Text: Anywhere in the packet.
Default value: N/A.
Content Data
Type of content to be searched within the packet:
N/A: Not available.
URL: HTTP Get packets are scanned for URL data.
Text: For text in all packets.
Content Offset
Location in packet from where content is checked. Offset location is measured
from the beginning of the UDP or TCP header. The value can be: 0 - 1513.
Default value: 0.
Security
Custom Attack Groups
The custom attack group represents a logical OR relation between two or more attacks. The right
panel of the Attack Group Configuration window contains a list of all existing groups.
Content Encoding
Application Security can search for content in languages other than English, for
case sensitive/ insensitive text, and hexadecimal strings. Values include:
None.
Case Insensitive.
Case Sensitive.
HEX.
International.
Note: The value of this field corresponds to the Content Type parameters.
Content
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 J K L M N O P Q R S T
U V W X Y Z [ \ ] ^_ ` a b c d e f g h i j k l m n o p q r s t u v w x y z {| }~.
Content Language
Contains the language (characters set) in which the content is written.
Default language: English.
Content Max Length
Maximum length to be searched within the selected Content Type. The value
can be: 0 - 1513.
Note: The Content Max Length value must be equal to or greater than the
Offset value.
Default value: 0.
Content Data
Encoding
Application Security can search for data in languages other than English, for
case sensitive/ insensitive data, and hexadecimal strings. Values include:
None.
Case Insensitive.
Case Sensitive.
HEX.
International.
Note: The value corresponds to Content Type parameters.
Distance Range
The Range that defines the allowed distance between two content characters.
If the distance is beyond the specified range, it is recognized as an attack.
Table 48: Content Definition Parameters (cont.)
Security
Figure 26: Attack Group Configuration Window
Radware provides a set of predefined custom attack groups as part of the Signatures file. You can
also add user-defined attack groups, using predefined attacks or user-defined attacks. The
predefined attack groups are divided according to types of protection. Groups can be activated
within a protection profile, except for the Unassigned group. Probable attacks affecting performance
and attacks that are false positives, are gathered in the Unassigned group. They can be activated
either by adding an attack to an existing group or to a user-defined group.
To add a new custom attack group
3. Click Custom Group. The Attack Group Configuration window appears.
4. In the Group Name text box, enter the new attack group user-defined name.
5. Select the attacks you want to include in this group and move them to the Selected Attacks pane
by clicking the Add button.
Creating a New User-Defined Intrusion Prevention Profile
You can either select from the Radware predefined intrusion prevention profiles or create your own
custom profiles.
To create a new user-defined intrusion prevention profile
appears.
2. Double-click in the Intrusions column. The Settings pane appears.
3. Click New Profile. The New Intrusion Prevention Profile window appears.
4. Enter your new profile name.
5. Click OK. The new profile appears in the Intrusion Prevention Profile pane.
6. In the All Intrusion Attacks pane, select attack groups and move them to the new profile by
clicking the Add button.
Security
7. In the Connect & Protect Table, select the policy to which you want to apply the new intrusion
prevention profile and click Apply. The name of the new profile appears in the selected cell.
Editing Attack Groups
You can edit an attack group.
To edit an attack group
appears.
2. Double-click in the Intrusions column. The Settings pane appears.
3. From the All Intrusion Attacks list, select the attack group you want to edit and click Edit. The
Attack Group Configuration window appears.
4. Edit the parameters of the group (see Custom Attack Groups, page 348).
DoS/DDoS
This section introduces DoS/DDoS protection profiles and explains how to configure them. This
Introducing DoS/DDoS, page 350
DoS/DDoS Protection Services, page 350
Introduction to DoS Shield, page 351
Setting Up DoS Shield Using Radware Profiles, page 353
Defining DoS Shield with User-Defined Settings, page 353
Introduction to Application Security, page 355
Setting Up Application Security for DoS/DDoS Using Profiles and Groups, page 356
Defining Application Security Profiles with User-Defined Settings, page 356
Introducing DoS/DDoS
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.
DoS/DDoS Protection Services
To provide protection against denial of service, the DoS/DDoS module incorporates two different
services that mitigate DoS attacks:
DoS Shield Profiles: 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 Profiles: Packet-by-packet scanning service that provides protection
against DoS attacks, using signature-based packet-by-packet scanning.
Security
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.
Using DoS/DDoS Profiles
The two types of profiles used in the DoS/DDoS security module are Application Security Profiles and
DoS Shield Profiles.
To configure DoS/DDoS
appears.
2. Double-click inside the DoS/DDoS column. The Settings pane appears.
3. Select Application Security Profiles. The Settings pane appears (see Defining Application
Security Profiles with User-Defined Settings, page 356).
Introduction to 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.
DoS Shield Module
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.
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.
DoS Shield Traffic Flow
To detect possible attacks, when traffic reaches the device, samples are copied and inspected
against each entry in the list of Dormant attacks.
Control the sampling rate by setting how many packets that pass through the device before a packet
is examined against the list of attacks in Dormant state (see Packet Sampling Rate in Figure 27 DoS
Shield Traffic Flow Diagram, page 352) and configuring the duration of the sampling period when
different thresholds are checked (see Sampling Time in Figure 27 DoS Shield Traffic Flow Diagram,
page 352). Whenever traffic matches an Attack filter, a counter is incremented. At the end of each
Sampling Time, the counter value is normalized and compared to the thresholds configured for the
attack.
You can configure a Warning Threshold and an Activation Threshold for each attack. When the
Warning Threshold is met, a warning message is sent notifying about the attack. When the
Activation Threshold is met, the attack state changes to Active. Then, every packet passing through
the device is inspected and the forwarding limit is executed.
Security
Figure 27: DoS Shield Traffic FlowDiagram
When an attack is activated, the following actions are possible:
Traffic Bandwidth (kbps) that matches a Currently Active Attack is limited when forwarding
packets to the network.
When forwarding limit is 0, all packets matching the Currently Active Attack are blocked.
The status of a Currently Active Attack reverts to Dormant when the amount of traffic matching the
attack filter is smaller than the Attack Termination Threshold for the duration of the Aging Period for
that attack. The Aging Period allows you to set a number of Sampling Time periods. In order for the
attack to be considered over, the counters for the attack must not cross the Termination Threshold
during the configured Sampling Time period. The attacks status reverts to Dormant and its
termination is reported to the management station.
DoS Overload Mechanism
This protects the device from becoming a network bottleneck, enabling you to cascade two or more
devices, each removing excessive traffic according to capacity. When traffic load approaches the
device's maximum processing capacity, the Overload Mechanism removes excess traffic. This is an
integral part of the DoS Shield module, and must be used if DoS Shield is the only active module. Do
not use the Overload Mechanism when other modules are also activated. For possible configuration
options, see DoS Shield Parameters, page 327.
Incoming Packet
Compare to
Currently Active Attacks List
Sampling
Pre-Configured Action
Activate
Attacks
Forward the Packet to the Destination Port
Match
All packets
No
Compare to
Dormant Attacks
No
Operation
Match
Copy of
Sampled
Packets
Match
Activation
Threshold
Passed
Match
No Match
No
Match
Security
Overload Mechanismin Application Switch 1 and 2
AppDirector models 200/202 are based on the AS1 platform. Both share similar architecture; all
traffic is processed and forwarded by the master CPU. When the master CPU reaches 80%
utilization, it starts forwarding the excess packets without the DoS Shield module inspection. All the
other security modules continue to operate and filter traffic according to their policies' settings.
AppDirector 1000 is based on AS2 platform.
Overload Mechanismin Application Switch 4
AppDirector 3020 is based on the AS-4 platform, where traffic is first classified by network
processors (NPs). The overload is measured per master CPU and NP load. Once the master CPU load
reaches 80% or the NPs are overloaded, the mechanism is activated. The device starts to forward all
traffic through the NPs bypassing the master CPU for inspection by DoS Shield. All modules are
bypassed so no policies can be enforced on excess traffic.
Setting Up DoS Shield Using Radware Profiles
Radware supplies a set of predefined attack profiles and attack groups that provide constant
protection against all recent attacks (see Protection Profiles and Groups, page 331).
You can use these prevention profiles to define protection policies (see Setting Up Security Policies
in the Connect and Protect Table, page 324).
Most the existing DoS attacks can be prevented using Radware profiles.
To configure DoS Shield Configuration using Radware defined profiles:
1. Enable DoS Shield protection and set the general parameters (see DoS Shield Parameters,
page 327).
appears.
4. In the Settings pane, select DoS Shield Profiles.
5. In the DoS Prevention Profiles pane, select the predefined profiles and apply them to the policy
in the Connect & Protect Table window.
Defining DoS Shield with User-Defined Settings
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.
You can also add user-defined attacks to the database. The parameters of the Sampling (Figure 27
DoS Shield Traffic Flow Diagram, page 352) process can be configured using the DoS Shield. For
new users, it is recommended to define DoS Shield prevention profiles using Radware-defined
attacks only.
To configure DoS Shield using user-defined profiles
1. Enable DoS Shield protection and set the general parameters (see DoS Shield Parameters,
page 327).
2. Define the DoS Shield attacks (see Defining DoS Shield Attacks and Filters, page 354).
Security
3. Create a new DoS Shield profile and apply the new profile to the policy in the Connect and
Protect Table (see Creating a New DoS Shield Profile, page 355).
Defining DoS Shield Attacks and Filters
An Attack is a building block of the DoS Shield profile. Each attack contains one or more protection
filters that determine which packets are malicious and how AppDirector treats those packets.
Each filter (Figure 28 Filter Configuration, page 354) contains one specific signature. Filters are
detectors that scan and classify predefined traffic. The filters main purpose is to match the specific
packet within the traffic scanned by this filter with an attack signature from the Radware Attack
Signatures database (see Managing the Signatures Database, page 331).
Figure 28: Filter Configuration
The Signatures database contains attacks provided by Radware. You can add user-defined attacks to
reflect the specific needs of your network or edit the existing attacks.
Note:
>> For information on Filter Parameters, see Filter Parameters, page 344
>> To define a new port application group, see To define a new application port group,
page 345
>> For more information on OMPC Definition parameters, see OMPC (Bit pattern)
Definition parameters, page 345
>> For more information on Content Definition parameters, see Content Definition
Parameters, page 346
To configure a new attack
appears.
Security
3. Select DoS Shield Profiles.
5. Set the parameters as explained in Table 49, page 364.
6. To add new user-defined filters to this attack, click Add New. The Filter Configuration window
appear
7. In the Filter Name text box, type the name of the filter.
8. In the Protocol parameters pane, define the protocol, as explained in Table 46, page 345.
9. In the OMPC parameters pane, define the OMPC parameters, as explained in Table 47, page
345.
10. In the Content parameters pane, define the content parameters, as explained in Table 48, page
347.
11. In the Filter Description text box, type the description of the filter.
12. The Custom DoS Filter window closes, and the new filter appears in the Filters box of the
Custom DoS Attack window.
13. Click OK. The Edit Attacks Table window closes, and the new attack appears in the All DoS
Attacks List.
Creating a New DoS Shield Profile
You can create a new profile using Radware attacks or customized attacks.
To define a new DoS Shield profile
appears.
4. Click New Profile. The New Profile window appears.
5. In the Profile Name text box, type the name of the new profile and click OK. The New Profile
window closes, and the new profile appears in the DoS Prevention Profiles pane.
6. In the All DoS Attacks List pane, select the attack(s) that you want to add to the new profile and
click Add. The selected attack appears in the DoS Prevention Profiles pane.
7. In the Connect & Protect Table window, select the policy to which you want to apply the new
DoS Shield profile and click Apply. The name of the new profile appears in the selected cell.
Introduction to Application Security
Application Security profiles are part of the protection from and prevention of denial of service
attacks.
Application Security provides protection against single or multiple packet attacks that cause denial
of service.
Application Security profiles 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.
Security
Setting Up Application Security for DoS/DDoS Using Profiles and Groups
protection against all recent attacks (see Protection Profiles and Groups, page 331).
You can use these prevention profiles to define protection policies (see Setting Up Security Policies
in the Connect and Protect Table, page 324). Most existing attacks can be prevented using Radware
profiles.
To configure Application Security Profiles
1. Enable Application Security and define the general parameters (see Enabling Protection and
Setting Up General Security Parameters, page 326).
2. Select the predefined profiles and apply them to the policy in the Connect & Protect Table.
3. In the main window, click Security. The Connect & Protect Table window appears.
6. From the DoS Prevention Profiles list, select the predefined profiles and apply them to the
policy in the Connect & Protect Table window.
Defining Application Security Profiles with User-Defined Settings
You can also create custom prevention profiles, custom attack groups and custom attacks that are
based on custom filters.
To configure Application Security using User-Defined Settings:
1. Enable Application Security and define parameters (see Enabling Protection and Setting Up
General Security Parameters, page 326).
2. Define custom attacks (see Setting Up Attacks and Filters, page 341).
3. Define custom attack groups (see Custom Attack Groups, page 348).
4. Define the Application Security profile and apply it to the policy in the Connect & Protect Table
window (see Creating a New User-Defined Intrusion Prevention Profile, page 349).
An attack (Figure 24 Custom Attack Configuration, page 341) is a building block of the Application
Security profile. Each attack contains one or more protection filters that determine which packets
are malicious and how AppDirector treats those packets.
Each filter (Figure 25 Filter Configuration Window, page 342) contains one specific signature. Filters
are detectors that scan and classify the predefined traffic. The filters main purpose is to match the
specific packet within the traffic scanned by this filter and the attack signature from the Radware
Attack Signatures database (see Managing the Signatures Database, page 331).
An attack can employ one or more filters. When more than one filter is used, the scanning process
represents a logical AND relation between the filters involved. The classification processes of all the
filters applied to the same attack are involved in the scanning process, thus, the traffic is checked
for all the signatures defined in the attacks filters.
Security
signature is recognized. Each attack is bound to a Tracking function that defines how the packet is
handled once it is matched with a signature. The main purpose of these functions is to determine
whether the packet is harmful and take appropriate action. There are two types of match functions:
the packet is considered an indicator for the attack, and the packet is dropped (Drop All); for
example, MS Blast.
The Threshold or Counter functions. These functions assume that the signature match alone
is not enough to decide whether a packet is offensive.
Notes:
>> To create a new Custom attack, see To create a new attack, page 344
>> For information on Filter Parameters, see Filter Parameters, page 344
page 345
>> For more information on OMPC Definition parameters, see Table 47, page 345
To configure a new attack:
5. In the Attack Name text box, enter the name of the new attack.
6. Set the attack parameters, as explained in Table 49, page 364.
7. In the Attack Configuration window, click Add New. The Filter Configuration window appears.
8. In the Filter Name text box, type the name of the filter.
9. In the Protocol parameters pane, define the protocol parameters, as explained in Table 46, page
345.
10. In the OMPC parameters pane, define the OMPC parameters, as explained in Table 47, page
345.
11. In the Content parameters pane, define the content parameters, as explained in Table 48, page
347.
12. In the Filter Description text box, type the description of the filter.
13. Click OK. The Attack Configuration window closes. The new attack now appears in the Custom
Group window.
CustomAttack Groups
panel of the Attack Group Configuration window (Figure 29 Attack Group Configuration Window,
page 358) contains a list of all the existing groups.
Security
Figure 29: Attack Group Configuration Window
Radware provides a set of predefined custom attack groups as part of the Signatures file. You can
also add user-defined attack groups. The predefined attack groups are divided according to types of
protection.
4. Click Custom Group. The Attack Configuration window appears.
5. In the Attack Name field, enter new user-defined name for attack group.
6. Click OK to return to the Connect & Protect Table window.
7. From the All Dos Attacks list, select the attacks you want to include in the group and move
them to the Selected Attacks pane by clicking Add.
Creating a User-Defined Application Security Profile
You can either select from the Radware predefined Application Security profiles or create your own
custom profiles.
To create a user-defined application security profile
3. Click New Profile. The New DoS Profile window appears.
4. In the New DoS Profile window, enter a name for your new profile and click OK. The new profile
appears in the DoS Prevention Profiles pane of the Connect & Protect Table window.
5. In the All DoS Attacks pane, select the attack group(s) that you want to add to the new profile
and click Add. The selected group appears in the DoS Prevention Profiles pane.
6. In the Connect and Protect Table window, select the policy to apply the new DoS profile and click
Apply. The name of the new profile appears in the selected cell.
Security
Editing Attacks
To edit an attack
3. From the All DoS Attacks list, select the attack group that you want to edit and click
Edit Attack. The Attack Configuration window appears.
Behavioral DoS
This section presents the B-DoS (Behavioral DoS) module, which detects and prevents network flood
attacks.
Introduction to Behavioral DoS, page 359
Behavioral DoS Global Parameters, page 360
Behavioral DoS Advanced Settings, page 361
Introduction to 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 Behavioral DoS Module
The B-DoS module utilizes known network traffic baselines 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 non-
intrusive detecting attacks as they happen, cleaning the links from excessive traffic.
Security
Behavioral DoS Global Parameters
Each row in the Connect & Protect Table represents a policy. A B-DoS security policy contains
security profiles that are activated within predefined ranges of ports/VLANs, or within a predefined
network. The Connect and Protect Table is divided into sections, including the section for B-DoS. B-
DoS can be enabled globally or per profile.
Enable Behavioral DoS
To start protection, B-DoS must first be enabled.
To enable Behavioral DoS
1. In the main window, click APSolute OS > Security. The Connect and Protect Table appears.
2. Double-click on Settings. The Security Settings window appears.
3. In the Behavioral DoS field select the Start Protection checkbox.
4. Restart the device. Behavioral DoS is now enabled.
Behavioral Dos Global Configuration Guidelines
1. Defining Bandwidth Settings, page 360
2. Behavioral DoS Profiles Policies, page 360
Defining Bandwidth Settings
To create a B-DoS security policy, first define the Bandwidth settings for Behavioral DoS inbound and
outbound traffic.
To define Bandwidth Settings
1. In the main window, select APSolute OS > Security. The Connect and Protect Table appears.
2. Click inside the Behavioral DoS column, the Behavioral DoS Profiles pane appears.
3. Select a profile and click Behavioral DoS Settings. The Behavioral DoS Settings window
appears. Set the following parameter according to the explanations provided:
4. Click Apply > OK.
Behavioral DoS Profiles 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.
Bandwidth
Settings
In: Available bandwidth for inbound traffic. The value is be the lower
bandwidth of the circuit or the assigned inbound bandwidth from your
Internet Service Provider. Default value: 50,000 Kbit/s.
Out: Available bandwidth for outbound traffic. The value is be the lower
bandwidth of the circuit or the assigned outbound bandwidth from your
Internet Service Provider. Default value: 50,000 Kbit/s.
Security
To create a basic Behavioral DoS Policy
1. Define the Bandwidth Settings, Defining Bandwidth Settings, page 360.
2. Create a new profile:
a. In the main window, select APSolute OS > Security. The Connect and Protect Table
appears.
b. Click anywhere in the Behavioral DoS column. The Behavioral DoS Profiles Settings pane
appears.
c. Click New Profile. The New Behavioral DoS Profile window appears.
d. in the New Behavioral DoS window enter the profile name. Click OK.
3. In the Settings pane, select Behavioral DoS from the All Behavioral DoS Attacks tree and click
the Add mover arrow. The Behavioral DoS attack is added to your profile.
4. Select Behavioral DoS and then click Edit. The Edit Behavioral DoS Profile window appears,
which includes the following checkboxes:
a. TCP
b. TCP SYN
c. UDP
d. ICMP
e. IGMP
5. Select the type of attacks to protect against for this policy and click OK.
Note: Radware recommends that you include all attacks in your policy.
6. Click Apply > Update Policies. Click OK. The new policy now appears in the Connect and
Protect Table.
Behavioral DoS Advanced Settings
The B-DoS Advanced Settings allow you to set the Learning Response Period from which baselines
are primarily weighed, enable the sampling status and define the strictness level of the Footprint.
To configure Advanced Behavioral DoS Settings:
1. Define the Learning Response Period, Learning Response Period, page 361.
2. Set Quota Settings, Quota Settings, page 362.
3. Set the Sample level, Sampling Status, page 362.
4. Set the Footprint Strictness level, Footprint Strictness Level, page 362.
Learning Response Period
Network Flood protection learns traffic parameters from the transport layer of incoming and
outgoing packets and generates normative baselines for traffic. The Learning Period setting defines
the period from which baselines are primarily weighed.
When the baseline is reset, the baseline traffic statistics are cleared and default baselines are set.
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.
Security
To set the Learning Response Period and Reset the Baseline
1. In the Behavioral DoS settings pane, Click Behavioral DoS Settings. The Behavioral DoS
2. Select either: Day, Week or Month from the dropdown list.
3. Click Reset Baseline Learned Statistics.
4. Click Apply > OK.
Quota Settings
The B-DoS quota limits are the percentage of total inbound and outbound bandwidth that a specific
protocol is permitted to use.
To define the Quotas Settings
1. In the Behavioral DoS Settings pane, Click Behavioral DoS Settings. The Behavioral DoS
2. In the Behavioral DoS Settings window, set the incoming and outgoing values for each protocol.
Sampling Status
Sampling status allows you to aggregate Traffic Statistics to improve performance levels.
When down sampling is enabled, the system screens only part of the traffic. The down sampling
process dynamically selects the most appropriate portion of traffic that needs to be examined to
preserve the systems resources, while maintaining minimal sampling error. High sampling errors
increase the chances for false positives.
To set the Sampling Status:
1. In the Behavioral DoS Settings pane, click Behavioral DoS Settings. The Behavioral DoS
2. From the Samplings dropdown list select one of the following:
Footprint Strictness Level
Using the footprint strictness level, when a new attack is detected, the B-DoS module generates an
attack signature to block the traffic anomaly created by the attack.
Enabled
Traffic statistics are aggregated through a sampling algorithm which improves
overall performance of the AppDirector protection system.
Note: The risk of false positives is increased when the decision engine is
tuned according to the sampling error.
Disabled
Traffic statistics are aggregated without sampling.
Security
To set Footprint Strictness Levels
1. In the Behavioral DoS Settings pane, click Behavioral DoS Settings. The Behavioral DoS
2. Click on the Footprint Strictness Level dropdown box and define the strictness level:
3. Click OK > Apply.
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.
For an explanation of the bypass types and values for each attack group, See Footprint Bypass
Fields, page 363.
To set Bypass FootPrints
1. In the Behavioral DoS Settings pane, select the attack from the All Behavioral DoS Attacks
column.
2. Click Edit. The Edit (Attack Type) Flood Attack window appears.
3. In the Edit Flood Attack window, select the bypass type and click Edit. The Edit Field parameters
window appears.
Footprint Bypass Fields
This section presents the Footprint bypass types and values for each attack group
High
By setting strictness to High the false-positive ratio is reduced to a minimum.
However, there is a greater chance that attacks will not be blocked.
Medium
Default level.
Low
By setting strictness to Low the device will block the greatest number of attack.
However, the false positive rate increases.
Bypass Type
Footprint type being bypassed. B-DoS module bypasses all possible values of
the selected filter type when creating filters.
Status
Accept: Allows footprint types.
Bypass: Bypasses certain footprint types, which prevents traffic from being
blocked based on the value of the bypassed footprint.
Value
B-DoS module bypasses only selected values of a particular footprint, while
blocking all other values. These values vary according to the footprint
selected.
Enter the value for the Bypass type. See Table 49, page 364.
Security
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.
Creating Connection Limiting Policies
To create a new connection limiting policy using a predefined attack
1. From the main window, select APSolute OS > Security. The Connect and Protect Table
appears.
Table 49: Footprint Bypass Values
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 1 0 - (2^16-1)
Source Port + NR + NR 0 - (2^16-1)
Source IP + + + + 0.0.0.0.
255.255.255.255
ToS + + + + 1 - 255
Packet Size + + + + ICMP: 74 (60 L3)
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)
0 - (2^16-1)
Fragment + + + + Values cannot be
configured.
No Values.
Destination Port + NR + nr 0 - (2^16-1)
Destination IP + + + + 0.0.0.0 -
255.255.255.255
ICMP/IGMP
Message Type
NR + NR + 0-255
TTL + + + + 0-255
Security
2. Double click anywhere in the DoS/DDoS column. The DoS/DDoS Settings pane appears.
3. Select Connection Limit Profiles.The Connection Limiting Profiles pane appears.
4. Click New Profile and enter a user defined name for your new profile. Click OK.
5. Select an attack from the All Connection Limiting Attacks tree and click Add. The attack is now
added to the profile.
6. Click Apply > Update Policies.
To create a user defined custom attack
1. From the main window, select APSolute OS > Security. The Connect and Protect Table
appears.
2. Double-click anywhere in the DoS/DDoS column. The DoS/DDoS Settings pane appears.
3. Select Connection Limiting Profiles.The Connection Limit Profiles pane appears.
4. Click Custom Attack. The Connection Limiting Attack Configuration window appears, which
contains the following parameters:
5. Set the parameters according to the explanations provided and click OK. The new user defined
custom attack appears in the All Connection Limiting Attacks tree. A profile can now be added to
the attack.
Attack Name
Enter a user defined name to easily identify the attack for configuration and
reporting.
Application Port
Group of Layer 4 ports that represent the protected application.
Protocol
Layer 4 protocol of the protected application - TCP or UDP.
Packet Report
Enables or disables packet reporting for attack.
The following are generated at the connection limit:
When the activation threshold of a connection limit attack is reached,
an alert with status = started is sent.
Alerts with status = on-going are sent periodically while the attack is
On. The number of sessions per second is higher than the threshold.
An alert with status = terminated is sent when the attack stops. The
number of sessions per second is under the threshold.
Risk
Define the risk level for this attack.
Suspend Action
The suspended status of the Source IP addresses identified as the source
of the flooding attack. The options are:
None: No suspend action is to be taken.
SrcIP: All traffic from the Source IP identified as the source of this
attack is suspended (available if Tracking Type is Source count or
Source & Target count).
SrcIP-DstIP: All traffic between the Source and Destination IP
combination from which the attack was identified, is suspended
(available if Tracking Type is Source & Target count only).
Note: When tracking type is Target count, Suspend Action must be
None.
Security
SYN Flood Protection
This section describes how SYN Flood Protection works and how to configure it. This section includes
Introduction to SYN Flood Protection, page 366
Before Setting Up SYN Flood Protection, page 367
SYN Flood Protection General Settings, page 367
Creating Custom SYN Attacks, page 369
Configuring SYN Flood Protection Policies, page 370
SYN Flood Reporting, page 372
Introduction to 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-a-
connection 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. The reports regarding
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.
SYN-ACK Reflection Attacks Prevention responds to the challenge of the DoS SYN reflection attack
by limiting the amount of SYN-ACK packets sent to a specific IP address. This is how it works.
1. The limiting action is applied when the amount of SYN-ACK packets exceeds the defined
threshold.
2. The threshold represents the number of incomplete TCP sessions and is calculated by comparing
each Source IP address and the total number of SYN packets that arrived at the device, with the
number of completed TCP sessions. The time interval for this threshold is set per second.
3. The threshold is user-defined (recommended values are preconfigured as defaults) (see Table
50, page 367).
4. The limitation of SYN-ACK packets does not affect SYN attack detection.
5. Once the limiting action is applied, the device ignores any additional SYN packets arriving from
the specific IP address (the source of the attack).
Note: Device behavior in the case of a Distributed SYN attack remains unchanged.
Security
To configure SYN Flood Protection
1. Enable the Session Table (see To enable Layer 4, page 367).
2. Set the Session Table Lookup mode to Layer 4 (see To enable Layer 4, page 367).
3. Enable SYN Flood Protection and set SYN Flood General parameters (see To SYN Flood Protection
General Settings, page 367).
4. Create a new custom SYN Attack Profile (see Creating Custom SYN Attacks, page 369).
5. View the SYN Flood Order (see Viewing SYN Flood Order, page 368).
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.
To enable Layer 4
3. Select Session Table Settings > Edit Settings. The Session Table Settings window appears.
5. Click OK to exit all windows.
Note: When using the SYN Flood Protection Filters that are part of the Security module, you
must set the inbound and outbound traffic to operate in Process mode.
SYN Flood Protection General Settings
Once you configure the Session Table to operate in Layer 4 mode, you can enable SYN Flood
protection and configure its general parameters.
Session Table Status Enabled
Session Table Lookup Mode Full Layer 4
Table 50: SYN Flood Protection General parameters
SYN Flood
Protection Status
Enables/disables SYN Flood protection.
Standby means that you can activate the SYN Flood Protection module without
rebooting the device.
SYN Protection
Timeout
Timeout to complete the TCP three-way handshake.
Range: 0-10 (0 means no timeout).
Security
To enable SYN Flood protection and configure the general parameters
3. Select SYN Flood Protection Settings > Edit Settings. The SYN Flood Protection Settings
window appears.
4. Set the parameters as explained in Table 50, page 367, then click Apply and OK.
Viewing SYN Flood Order
Clicking View SYN Order allows you to view the index order the device uses to process SYN Flood
profiles.
Attack Periodic
Report Threshold:
If the percentage of incomplete sessions for a destination protected by a policy
is above this threshold, the attack is reported periodically. A value of 0 means
no report is available.
Range: 1-100%.
Default value: 30%.
SYN Protection
Tracking Time:
Number of SYN packets directed to same destination must be lower than the
value of the Deactivation Threshold (see Deactivation Threshold,
page 371) for this amount of time, in seconds, to stop the protection of the
destination.
Range: 1-10. Default value: 5.
SYN-ACK Reflection
Protection Mode:
Activate SYN-ACK Reflection Attack Prevention using:
Enable: The Prevention mode.
Report Only: The Report-only mode (no prevention).
Disable: SYN-ACK Reflection is disabled.
Default value: Disable.
SYN-ACK Reflection
SrcIP Sampling per
second:
Number of SYN packets per second sampled with their Source IP monitored.
SYN-ACK Reflection
MaximumSYN
Cookies per Source:
Maximum number of incompleted TCP sessions per Source IP per second
answered. Sessions exceeding this frequency are ignored.
Range: 1 - 100,000. Default value: 1,000.
Statistics Max
Destinations per
Policy
Maximum number of destinations per policy shown in statistics report.
Destinations are defined using the Connectivity setting from Connect and
Protect Table (see Defining Connectivity, page 329).
Note: Only destinations defined by IP addresses and L4 ports are valid for
SYN Flood protection policies.
Statistics Time
Period
Number of seconds used to calculate average values for SYN protection
statistics.
Displaying
Statistics of Policy
All SYN Flood protection policies defined on device.
Table 50: SYN Flood Protection General parameters (cont.)
Security
To view the SYN Flood order
3. Select SYN Flood Protection Settings > Edit Settings. The SYN Flood Protection Settings
window appears.
4. In the SYN Flood Settings pane, click View SYN Order. The SYN Protection Policies window
appears, as shown below:
Figure 30: SYN Protection Policies
Creating Custom SYN Attacks
Radware provides you with a set of predefined SYN attacks. You can also create user-defined
attacks.
Figure 31: SYN Attack Configuration Window
To create a custom SYN attack:
1. From the main APSolute Insite window, select APSolute Insite > Security. The Connect &
2. Double-click inside the SYN Floods column. The Settings pane appears.
Security
3. Click Custom Attack. The SYN Attack Configuration window appears.
4. In the Application Name field, enter the name of the custom SYN attack.
5. Click App. Port Group. The Application Port Group window appears, displaying the group of
Layer 4 ports for UDP and TCP traffic. Each group is identified by its unique name which can be
associated with a number of entries in the Application Port Group table. The values can be: 0 -
65535.
6. Click Modify. The Modify pane appears.
7. Click Add and set the following parameters according to the explanations provided:

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.
8. Click OK. A new row appears in the Application Port Group table.
9. Click OK. The Application Port Group window closes.
10. From the Destination App. Port Group drop-down list, select a group that was defined in the
11. In the Attack Description field, enter a description of the attack.
12. 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.
Configuring SYN Flood Protection Policies
Once you have created a custom attack, you can create a new SYN policy by adding the custom
attack to the list of Selected SYN Flood attacks and configuring policy parameters. The list denotes
which attacks have been selected for the policy.
To add a predefined SYN Attack to the Selected SYN Attacks
3. From the All Regular Filters list, select the attack you wish to add.
4. Click Add. The SYN Policy Details window appears.
Name
A user-defined group name for the application port.
FromPort
The first port in the range.
To Port
The last port in the range.
Security
6. Click OK. The selected attack appears in the Selected SYN Application Ports list.
Viewing the SYN Statistics
To make the process of 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.
To view the statistics of SYN policies
3. Click SYN Floods Statistics. The SYN Floods Statistics window appears.
Policy Index
Enter the Index number. This determines in what order the device
processes SYN Attack Profiles.
Verification Type
Define process of completing the TCP session:
Ack: session is completed when the Ack packet arrives
(following a SYN/SYN-ACK packet exchange).
Request: session is completed when the first data request
packet arrives (following a SYN/SYN-ACK/ACK packet
exchange).
Protection Mode
Select either:
Enabled: Activates full SYN Flood protection.
Triggered: Activates SYN Flood protection only when an attack
is identified. When the Session Table is 80% full, triggered
policies act as Enabled and reply to all new sessions with
Cookies.
Disabled: SYN Flood protection is disabled.
Activation Threshold
The maximum number of SYN packets allowed to arrive at the same
destination per second. If the amount of traffic goes beyond the
Activation Threshold, it is recognized as an attack and the packets
are terminated.
Deactivation Threshold
If the number of SYN packets arriving at the same destination is
below the Deactivation Threshold, the SYN Flood protection policy is
deactivated and the traffic is no longer protected.
Count Statistics
(checkbox)
Enable or disable counting Click OK. Your preferences are recorded
statistics for the destinations defined in this policy.
Policy Name
Name of the policy for which traffic data is collected and analyzed.
Dest IP
Specific Destination IP included in the policy.
Security
SYN Flood Reporting
You can view active SYN Flood attacks via the Active Triggers table. Table 51, page 372 presents the
parameters of the Active Triggers table.
Dest Port
Specific Destination port included in the policy.
RX Port
Specific RX port included in the policy.
Attack Status
Current status of the attack. Possible 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
Number of SYNs within the last second.
Valid Sess Last Sec
Number of valid sessions within last second.
SYNs/Sec Avg
Average number of SYNs per second.
Valid Sess/Sec Avg
Average number of valid sessions per second.
SYNs/Sec Peak
Highest value of SYNs per second during the statistical analysis period.
Valid Sess/Sec Peak
Highest value of valid sessions per second during the statistical analysis
period.
Attack Start
Last attack detection time and date.
Attack Term
Last attack termination time and date.
Table 51: Active Triggers Table parameters
Type
Type of identified attack:
SYN Flood Trigger: Identified attack belongs to one of policies with
Protection mode of Trigger.
SYN Enabled Policies: This attack entry will include the sum of all the
attacks that match the policies with Protection mode enabled.
SYN Protection Total: Displays in each field the sum of all other
attacks (triggers and enabled).
SYN ACK Reflection: The identified attack is a SYN ACK Reflection
attack.
IP Address
Source IP for SYN ACK Reflection: Attacks and Destination IP for all other
attacks.
L4 Port
Destination L 4 port (SYN Flood Trigger attacks only).
RX Port
Physical port on device through which attack entered.
Active Time
Number of seconds from moment attack recognized.
Last Sec SYN counter
Number of SYNs recognized in the last second.
Last Sec Verified
counter
Number of ACKs recognized in the last second.
Security
To view the Active Triggers Table
3. Click Active Triggers. The Active Triggers Table appears.
Note: If Application Security or DoS modules are enabled, SYN Flood Protection events are
created.
Protocol Anomalies
This section describes Protocol Anomalies protection and includes these topics:
Anomalies Introduction, page 373
Setting Up the Anomalies Module Using Predefined Profiles, page 374
Defining Anomalies with User-Defined Settings, page 374
Anti-Scanning, page 376
Anomalies Introduction
To avoid IDS, hackers use evasion techniques, (splitting packets or sending attacks in fragments).
Attacks containing fragmented packets are called Protocol Anomaly attacks. These are detected and
blocked using Protocol Anomaly Protection. The main types of anomalies are shown in the following
table.
Table 52: HTTP and Protocol Anomalies
Average SYN counter
Average of SYNs recognized from the moment the attack began.
Average Verified
counter
Average of ACKs recognized from the moment the attack began.
Total SYN
Total number of SYN packets for this trigger.
Total Dropped
sessions
Total number of unverified sessions for this trigger.
Anomaly Description
HTTP
Hackers split the URL across multiple packets. This attack enables them to insert
malicious data into a web server. When the URL packet size exceeds the lower
boundary of the predefined length, the packet may contain fragmented URLs. When
the URL packet size exceeds the upper boundary of the predefined length, the buffer
overflow is indicated.
Protocol
Contains signatures of miscellaneous protocol misbehaviors. These prevent usage of
miscellaneous Protocol Anomalies indicating a new vulnerability or DoS attack.
Table 51: Active Triggers Table parameters
Security
The Anomalies Module
The Anomalies module provides protection using the following sub-groups:
Protocol Anomaly protection.
HTTP Anomaly protection.
MIN fragmented URL packet size parameters.
MAX URL Length parameters.
Setting Up the Anomalies Module Using Predefined Profiles
protection against all recent attacks (see Protection Profiles and Groups, page 331). You can use
these prevention profiles to define protection policies. Existing anomalies are prevented using
Radware groups.
To configure Anomalies using Radware-Defined Attacks
1. Enable Anomalies (see Defining Anomalies with User-Defined Settings, page 374).
2. Configure Protocol Anomaly Protection parameters (see Protocol Anomaly Protection
parameters, page 328).
appears.
4. Double-click inside the Anomalies column. The Settings pane appears.
5. In the Anomaly Flood Profiles pane, select the predefined profiles and apply them to the policy in
the Connect & Protect Table.
Defining Anomalies with User-Defined Settings
You can also create custom prevention profiles, custom attack groups, and custom attacks based on
custom filters. For new users, it is recommended to define prevention profiles using Radware-
defined attack groups only.
To configure Anomalies using User-Defined Attacks:
1. Enable Anomalies (see Defining Anomalies with User-Defined Settings, page 374).
2. Configure Protocol Anomaly Protection parameters (see Protocol Anomaly Protection
parameters, page 328).
3. Define attacks (see Setting Up Attacks and Filters, page 374).
4. Define Attack Groups (see Custom Attack Groups, page 348).
5. Define Anomaly Flood Prevention Profile and apply it to the Connect and Protect Table (see
Creating User-Defined Profiles, page 375).
An Attack (Figure 24 Custom Attack Configuration, page 341) is a building block of the prevention
profile. Each attack has one or more protection filters that determine which packets are malicious.
Each filter (Figure 25 Filter Configuration Window, page 342) has one specific signature. Filters are
detectors that scan and classify the predefined traffic. Filters match the specific packet within the
traffic scanned by this filter and the attack signature from the Radware Attack Signatures database
(see Managing the Signatures Database, page 331).
Security
Attacks employ one or more filters. When more than one filter is used, the scanning process
represents a logical AND relation between the filters, meaning that all filters applied to the same
attack are involved in the scanning process. Traffic is checked for all the signatures defined in the
attacks filters.
signature is recognized. Each attack is bound to a "Tracking" function that defines how the packet is
handled when matched with a signature. This determines whether the packet is harmful and applies
appropriate action. There are two types of match functions:
the packet is considered an indicator of an attack, and the packet is dropped ("Drop All"); for
example, MS Blast.
The Threshold or Counter functions, which assume that signature match alone is not enough
for determining a packet offensive. The packet is considered legitimate unless the number of
packets over a period of time exceeds a threshold that defines "reasonable" behavior for such
traffic. Only packets exceeding the threshold within a predefined time limit are dropped. See
Table 44, page 342 for the attack configuration parameters.
Notes:
>> To create a new Custom attack, see To create a new attack, page 344
>> For information on Filter Parameters, see To Filter Parameters, page 344
page 345
>> For more information on OMPC Definition parameters, see Table 47, page 345
CustomAttack Groups
panel of the Attack Group Configuration window contains a list of all existing groups. Radware
provides you with a set of predefined custom attack groups as part of the Signatures file. You can
also add user-defined attack groups using predefined or user-defined attacks. The predefined attack
groups are divided according to types of protection.
Groups can be activated within a protection profile, except for the Unassigned group. Probable
attacks that affect performance and false positives are gathered in the unassigned group and can be
activated either by adding an attack to an existing group or to a user-defined group.
3. Click Custom Group. The Attack Group Configuration window appears.
4. In Group Name field, enter the new user-defined name for the attack group.
5. Select the attacks you want to include in the group and move them to the Selected Attacks pane
by clicking the Add button.
6. Click OK.
Creating User-Defined Profiles
Select from predefined anomaly prevention profiles or create your own.
Security
To create a new user-defined anomaly profile
3. Click New Profile. The New Anomaly Profile window appears.
4. In the Profile Name field, enter a name for your new anomaly profile and click OK. The new
profile appears in the Anomaly Flood Profiles pane.
5. In the All Anomaly Attacks pane, select the anomaly attacks that you want to include in your
anomaly profile and move them to the profile by clicking the Add button.
6. In the Connect & Protect Table, select the policy to which you want to apply the new anomaly
profile and click Apply. The name of the new profile appears in the selected cell.
Editing Attack Groups
To edit an attack group
3. From the All Anomaly Attacks list, select the attack group you want to edit and click Edit. The
Attack Group Configuration window appears.
Anti-Scanning
This section provides information on how hackers perform scanning prior to an attack and how to
prevent it. This section includes the following topics:
Introduction to Scanning, page 376
Setting Up Anti-Scanning Using Profiles and Groups, page 377
Defining Anti-Scanning with User-Defined Settings, page 377
Introduction to Scanning
Before launching an attack, hackers try to identify what TCP and UDP ports are open. An open port
represents a service, application or backdoor. Ports left open unintentionally create a serious
security problem. Application Security helps prevent hackers from gaining this information by
blocking and altering server replies sent to the hacker.
Network Scanning
Legitimate traffic is sent to learn about a system and its applications, intending to perpetrate future
attacks. As packets sent by the attacker are legitimate, analyzing the whole traffic flow is the only
way to detect the scanning.
Security
Anti-Scanning Module
The Anti-Scanning module provides protection against network and port scanning. The Scanning
Tool contains signatures of miscellaneous network scanning tools. These signatures protect the
network from the scanning tools that attempt to scan your network.
Setting Up Anti-Scanning Using Profiles and Groups
protection against all recent attacks (see Protection Profiles and Groups, page 331). You can use
these prevention profiles to define protection policies (see Setting Up Security Policies in the
Connect and Protect Table, page 324). In most cases, Radware profiles provide protection against
network and port scanning.
To configure Anti-Scanning using Radware-Defined Attacks
1. Enable Anti-Scanning and set the general parameters (see Application Security Parameters,
page 326).
3. Click inside the Anti-Scanning column. The Settings pane appears.
4. In the Anti-Scanning Profiles pane, select the predefined anti-scanning profiles and apply them
to the policy in the Connect & Protect Table.
Defining Anti-Scanning with User-Defined Settings
You can create custom prevention profiles, custom attack groups, and custom attacks based on
custom filters. For new users, it is recommended to define anti-scanning profiles using Radware-
defined attack groups only.
To To configure Anti-Scanning using User-Defined Attacks:
1. Enable Anti-Scanning and set the general parameters (see Application Security Parameters,
page 326).
2. Define attacks (see Setting Up Attacks and Filters, page 341).
3. Define Attack Groups (see Custom Attack Groups, page 348).
4. Define the Anti-Scanning profile and apply it to the Connect and Protect Table (see Setting Up
Anti-Scanning Using Profiles and Groups, page 377).
Session Table
This section explains how the device records session information and includes the following topics:
Session Table and Session Table Lookup Mode, page 377
Configuring the Session Table, page 378
Session Table and Session Table Lookup Mode
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.
Security
The Session Table Lookup mode indicates what layer of address information is used to categorize
packets in the Session Table.
Note: The Session Table is disabled by default. When SYN Flood Protection is used, the
Session Table must be enabled.
The following modes are supported:
Full Layer 3
Full Layer 4
Note: Packets must be categorized with the Full Layer 4 Session Table Lookup mode when
SYN Protection is used.
Configuring the Session Table
The following table shows the Session Table parameters.
To configure the Session Table parameters
3. Select Session Table Settings > Edit Settings. The Session Table Settings window appears.
4. Set the parameters as explained in Table 53, page 378.
Table 53: Session Table parameters
Session Table
Aging Time
Amount of time a non-active session is kept in the Session Table (in seconds).
Session Table
Status
On Application Switch 4, the Session Table is enabled by default. If the device
does not need to provide high performance for routed or bridged traffic, it is
disabled.
Session Table
Lookup Mode
Indicates what layer of address information is used to categorize packets in the
Session Table. 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: 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 mode is the 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.
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.
Security
Evasion Techniques
This section describes how the device provides protection against evasion techniques in SSL secured
traffic, IP traffic and TCP traffic. This section includes the following topics:
Introduction to Evasion Techniques, page 379
IP Reassembly and Min IP Fragmentation, page 379
TCP Reassembly, page 381
Introduction to Evasion Techniques
Evasion Techniques are attempts to hide attacks that are aimed at harming servers or operating
systems. Hacker that send malicious attacks are aware of the protections used for specific types of
traffic, so they try to bypass your Intrusion Protection System (IPS) or Intrusion Detection System
(IDS). The methods used by hackers to avoid attack prevention with IPS/IDS are called Evasion
Techniques.
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.
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.
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 IP fragments
2. Click Settings. The Security Settings window appears.
3. Click IP Fragments. The IP Fragments window appears.
Security
IP Reassembly Status
Enables/Disables the IP Reassembly feature.
IP Reassembly aging time
[sec]
Maximum period of time, in seconds that AppDirector
keeps fragments of the same IP packet when not all
the fragments have been received. After this period,
AppDirector drops the fragments.
Default value: 3.
IP Reassembly Overlap status
Sets the data overlapping status within IP fragments.
Overlapping may also indicate an attack evasion technique.
Values are:
Allow: 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.
Default value: Allow.
IP Reassembly Overlap Action
Mode
The Action mode settings when the IP Reassembly Overlap
status is set to Deny.
Report Only: 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.
Default value: Report Only.
IP Reassembly no memory
Action Mode
Action taken when the device lacks the memory resources to
perform IP reassembly. Possible values:
Drop: The packet is discarded.
Forward: The packet is forwarded to the defined
destination.
Default value: Forward.
Min IP Fragment protection
status
Note: Enables/Disables the Min IP Fragment protection
feature.
Note: There is no dependency between IP Reassembly
feature and Min IP Fragment protection. Min IP
Fragment protection can be enabled when the IP
Reassembly feature is Enabled or Disabled.
Default value: Disable.
Security
TCP Reassembly
AppDirector detects and prevents TCP traffic evasion techniques. Application level attacks, such as
worms, viruses, Trojans and buffer overflow, require deep packet inspection capability to be
detected while being transferred over network protocol. The detection engine is signature-based,
but the attack signature is split among multiple packets within a TCP application flow and the
signature detection engine is bypassed.
To prevent application level attacks, AppDirector inspects Level 7 attack signatures within a TCP
stream, regardless of the location of the signature in the data stream.
To support Content Type (Level 7) filters, the TCP Reassembly feature performs protocol parsing
according to the content field. For example, when applying an HTTP URL filter on the traffic, the
device extracts the URL field from each HTTP-GET packet within a TCP session, and reassembles the
specific field over several packets.
TCP Reassembly is effective for attack signatures in Intrusions, Anomalies, Anti-Scanning, and
Application Security for DoS.
TCP Reassembly is applied on TCP data portions and application data, according to the Content Type
in the filter.
Notes:
>> The TCP Reassembly feature is supported on SME platforms only.
>> TCP Reassembly is performed for consecutive packets only.
When an attack is located, it is reported by name. No indication is provided as to whether the attack
was detected on a reassembled stream. The device sends the reassembled datagram as evidence of
the attack.
To enable TCP Reassembly
Min IP Fragment Action Mode
Action mode settings when Min IP Fragment Protection
is set to Enable:
Report Only: 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 the
packet Source IP and the packet Destination IP.
Default value: Drop.
MIN Fragment Size
Minimum permitted size of a fragmented IP packet. A
shorter packet length is treated as an IP protocol
anomaly and is dropped.
Possible values: 1-65535 Bytes.
Default value: 512.
Security
3. From the Application Security parameters area, select TCP Reassembly Status. The TCP
Reassembly feature is enabled.
Security Events and Reports
This section describes security events and how to configure devices to use reporting channels. This
Events and Event Reporting, page 382
Reporting Channels, page 384
Security Reports, page 388
Events and Event 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 can be sent to APSolute Insite and a management station.
Syslog messages can be sent to a Syslog station.
E-mail messages can be sent to specific users.
Security Terminal Echo
Note: You need to enable and configure each reporting channel prior to use.
Enabling Reporting Channels
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 the various risk
levels.
You can get the Source/Destination IP address information for each event up to the Reporting
Aggregation level. This level is defined by the Report Aggregation Threshold parameters. The
events, including Source/Destination IP values, are indicated with Status field value set to "Sample."
Note: Counter-based attacks and DoS attacks may occur more often, and the reported IP
addresses provide only partial information of the overall picture.
To enable the reporting channels for security reports
3. Select Security Settings > Edit Settings. The Security Settings window appears.
4. In the Reporting pane, enable the reporting channels that you want to use by selecting the
appropriate checkboxes.
Security
5. In the Reporting Interval text box, type the number of seconds that determines how often to
send reports through the reporting channels.
6. In the Report Aggregation Threshold text box, type the number of events for a specific attack to
be gathered during a Reporting Interval before aggregating events into a report.
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."
7. In the Max Alerts Per Report text box, type the maximum number of alerts that can appear in
each report (sent within the Reporting Interval).
8. To generate reports using risk levels, from the drop-down menus of the reporting channels,
select the levels according to the explanations provided:
Event Parameters
Devices send various types of information about a security event (attack). The following table
summarizes the parameters of an event.
High
Report all attacks with risk value set to High.
Medium
Report all attacks with risk value set to High or Medium.
Low
Report all attacks with risk value set to High, Medium, or Low.
Table 54: Event Parameters
Risk
Attack severity level: high, medium, or low.
Date/Time
Date and time the report was generated.
Attack Name
Name of the detected attack.
Physical Port
Port on device where the attack arrived.
Action
Forward: Packet forwarded to its destination.
Drop: 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.
Category
Category of the attack: Anomalies, Anti-Scanning, DOS, Intrusion.
Protocol
Transmission protocol used to send the attack: TCP/UDP/ICMP/IP.
Source Address
IP address from which the attack arrived.
Source Port
TCP/UDP source port.
Destination Address
IP address to which the attack is destined.
Destination Port
TCP/UDP Destination port.
Radware Attack ID
Radwares unique identifier of the attack.
Packet Count
Number of packets in the attack.
Security
Reporting Channels
AppDirector supports the following reporting channels:
Traps
Email Traps
Logs
Syslog Messages
Sending Traps
Traps can be sent from the device to any computer that you choose. You must enable the device to
send SNMP traps to other computers; for example, to the management station, by defining the
computers as targets.
Trap Notification is set up through the devices Target Address table. You can specify SNMP
parameters and select which type of notification it receives. In the Community Table, you can allow
specific users access to the traps.
Note: After configuring the device to send SNMP traps, enable it to start sending traps.
Packet Bandwidth
Bandwidth of attack since latest trap sent (KByte).
Status
The current status of the event.
For Intrusions, Anomalies, Anti-Scanning, SYN Flood attacks, and
Application Security for DoS/DDoS attacks, these statuses can appear:
Occurred: Each packet matched with signatures is reported as an
attack and dropped.
Started/Terminated: When the number of packets matching
signatures exceeds the predefined threshold within the Tracking
Time, the reported Attack Status is Started. When the number of
packets matching signatures is less than the predefined threshold,
the reported Attack Status becomes Terminated.
Ongoing: This reports on the counter-attack during the attack; i.e.
between Started and Terminated.
For DoS Shield attacks, these statuses appear:
Alert: When the number of packets that match the signatures goes
beyond the predefined Warning Threshold.
Active: When the number of packets that match the signatures
goes beyond the predefined Activation Threshold.
Block: When number of packets matching signatures exceeds the
predefined Drop Threshold.
De-al: Deactivation Alert status is reported when the attack is about
to be terminated.
De-ac: Deactivation status is reported when attack is terminated.
Device IP
IP of the device associated with the attack.
VLAN Tag
VLAN Tag information is used to 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 AS4 does not support VLAN Tagging, and a
value of "0" is always set.
Table 54: Event Parameters (cont.)
Security
To configure Security Traps
1. Enable the management station to receive traps:
a. Define access parameters.
b. Define target addresses, see SNMP - Target Address, page 39.
c. Specify the type of SNMP notification a target receives, see SNMP - Notify Table, page 42.
d. Define the target parameters; e.g. message processing security level and model, see SNMP
- Target Address, page 39.
e. Optionally, map user names to communities and vice versa with the SNMP Community
Table. This table restricts the range of addresses from which SNMP requests are accepted
and to which traps are sent, see SNMP - Community Table(SNMPv1 and SNMPv2 Only),
page 41.
2. Enable the device to start sending traps, see Start Sending Traps, page 385.
3. View traps at the management station, see Toview traps received by the management station,
page 386.
4. Record security traps on the management station, see Recording Security Traps, page 385.
5. Enable traps reporting, see Enabling Reporting Channels, page 382.
6. Define the graphical representation of the security reports in APSolute Insite, refer to the
APSolute Insite Guide.
Start Sending Traps
Once you define all the notification and target parameters, enable the device to start sending traps.
To enable the device to send one trap per event
1. From the main APSolute Insite window, select Options > Preferences. The Management
Preferences window appears.
2. Select the Trap and SMTP pane. Ensure that you provide the IP address for your SMTP server.
3. Select One Trap to generate only one trap per event.
To enable the device to send traps
appears.
2. Click Settings. The Security Reporting window appears.
3. In the Application Security parameters area (at top), ensure that Traps Sending is enabled.
Click Apply to enable.
Recording Security Traps
Once you have configured the device to send traps, Radware Traps Service records them
automatically. in a local database. Information from the database is used to create Security Reports.
Radware Traps Service continues to record traps until instructed to stop.
To stop recording security traps
1. From your computers Control Panel select Start > Settings > Control Panel.
Security
2. Click on the Administrative Tools directory.
3. Double-click Services. The Services window appears.
4. Right-click Radware Traps Service and select Stop.
To view traps received by the management station
1. From the main APSolute Insite window, select Options > Events & Traps. The Traps and
Events window appears, displaying the following:

Note: Traps from multiple devices can be viewed simultaneously in the Events and Traps
window.
E-mail Traps
E-mail traps can be sent to specific users in the same way as SNMP traps.
To enable the device to send e-mail traps
1. From the main window, select Device > Traps and SMTP. The Traps and SMTP window
appears.
3. In the main window, select APSolute OS > Security. The Connect & Protect Table window
appears.
5. Click Reporting. The Reporting pane appears.
6. Check E-mail Sending.
7. Click OK to enable.
Trap number
Chronological order number of trap, numbered in order that they are generated.
Severity
Traps severity level. Trap severity ratings include, in increasing order of
severity: Informational, Warning, Error, and Fatal.
Date
Date that the trap was generated.
Time
Time that the trap was generated.
Source
IP address that triggered the trap; e.g. AppDirectors IP address.
Information
Description of the trap.
Send Emails on Errors
E-mail alert when operational error occurs on device.
One Trap
Generate only one trap per event.
Security
Logging
When the device recognizes security events, they are logged in a cyclic Log File that can be accessed
at any time. But it is limited; when the entry number exceeds the limit, the oldest entries are
overwritten. Notifications on 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.
To configure a device to perform event logging
appears.
2. Click Settings. The Security parameters window appears.
3. In the main window, select APSolute OS > Security. The Connect & Protect Table window
appears.
5. Click Reporting. The Reporting pane appears.
6. Check Logging.
Note: Information in the log file can be viewed by downloading it at the management station
into a file.
To download the Log File at the management station
2. Click TFTP Log. The Download Log File window appears.
3. In the File Name field, enter the name you wish to assign to the file.
4. Click Browse to select the directory where you want to save the file.
5. Select the External TFTP Server IP Address box to specify the IP address for an external
TFTP server. To use the default TFTP server, clear the checkbox.
6. Optionally, enable Clear Log File After Receive to clear the log file once the download is
completed.
7. Select one of the format options, HTML, Excel, or Advanced, for exporting the Log File. If you
select Advanced, click Advanced Settings. The Attack Reports window appears.
8. Select categories to filter the report:
9. From the Select Fields section, select the checkboxes to define fields displayed in the report.
Attack
Type of attack that you want to appear in the report. You can select the
attack type from a drop-down list containing all the attacks recognized by
the device. If Attack is not selected, the report includes all attacks.
Source IP
Range of Source IPs from which the attacks arrived.
Destination IP
Range of Destination IPs to which the attacks were targeted.
Attack Date
Range of dates of the attacks recognized by the device.
Security
10. Click Create Top 10 Graph and choose an item from the drop-down list to create a graph of
the 10 most frequently mentioned items in the report.
11. Click OK to close the Attacks Reports window.
12. Click Receive. The Log File is downloaded, and the status of the download is displayed.
Tip: You can access logged security events via Security Reports (see Security Reports,
page 388).
Syslog Messages
Syslog messages are sent to a Syslog station the same way as SNMP traps.
To configure the device to send syslog messages
1. From the main APSolute Insite window, select Device > Traps and SMTP. The Traps and SMTP
window appears.
2. In the Syslog Reporting area, enter the IP address of the device running the Syslog service
(Syslog) in the Syslog Station Address field.
3. Select the Syslog Operation checkbox to enable Syslog reporting.
Security Reports
The Security Reporting module allows you to view filters, create predefined/user-defined reports and
unify filtering and reporting. Each view filter can be defined by the user and used for both the Events
Log and Reports view. The predefined reports list is also used for both the Events Log and Reports
view. The Security Reporting module allows you to view information in eight different views,
including:
Dashboard View: Displays the Security Radar and dashboard pie charts.
Attacks Log View: Displays Attacks Event log, including trap parameters.
Reports View: Displays different Security Reports in graphical view.
Geographical Map: Displays a geographical map of the world noting the sources of the attacks.
Attacks Log and Reports Split View: Displays both Attacks Log and Reports in split screen
view. Applied view filters affect both simultaneously.
Attacks Log and Packet Data View: Displays both the Attacks Log and Packet Capture Data
in split screen view.
Attacks Log and Attack Description View: Displays both the Attacks Log and Attack
Description in split screen view.
Attacks Log and Attack Information View: Displays the Attacks Log, Attack Description, and
Packet Data in split screen view.
Gathering Data
You need to select a device, or group of devices, to generate data for reports. The devices monitor
attack activity. When a device detects an attack, the security module logs data on a security event.
This event fits predefined attack profiles. Once reporting channels are configured, the device starts
sending information about these events to the management station via SNMP Traps. The
management station (running APSolute Insite) stores this data and packet information in a local
database which is then used to create Security Reports.
Security
Security Monitoring Tools
Each of the monitoring tools focuses on different types of analysis requirements. Each predefined
report and view filter can be used for both the Attacks Log and Attack Reports views.
Dedicated Management Port
To provide better device management security with ports, you can define a Dedicated Management
Port (a physical port of the device), that is used for management traffic only. This can be any port on
the device.
The following notes apply to Dedicated Management Port behavior:
No traffic is forwarded through the Management Port.
The Management Port cannot be a member of any VLAN.
The Management Port is automatically excluded from Interface Grouping and is not affected by
Interface Grouping activation. For more information on Interface Grouping, see Interface
Grouping, page 3.
Only traffic with the port's specific MAC and IP interface(s) is accepted. Other traffic to the
Management Port is discarded.
Management Port Routing entries can be added to the Routing Table. These entries are required
to send replies for management sessions.
The configuration is performed for each device.
To define a Dedicated Management Port
window appears.
2. Select Access. The Access pane appears.
3. From the Dedicated Management Port dropdown list, select the port that you want to define as
the Management Port and click OK.
Note: This option is not available on A1 or ODS 1 or ODS 2 Platforms due to the 2 build-in
management ports.
Security
Chapter 11 Security Monitoring and Reporting
This chapter explains how to use and customize security monitoring views, and how to configure
user defined views and user defined security reports. The chapter includes the following sections:
Introducing Security Monitoring, page 391
Real-Time Dashboard, page 392
Viewing Top Scan Dashboard, page 394
The Mitigation View, page 396
General Attack Views, page 397
The HTTP Views, page 419
Viewing the Geographical Security Map, page 423
Traffic Monitoring View, page 424
Security Reporting, page 426
Introducing Security Monitoring
Radwares security monitoring enables you to analyze both real time and historical attacks, using
the APSolute Insite Management Interface. When the device detects an attack, it automatically
generates countermeasures that you can observe and analyze using various monitoring tools.
Radware provides you with monitoring tools that show real-time network traffic and application
behavior parameters. It also provides you with the statistical parameters that represent normal
behavior baselines, based on advanced statistic algorithms.
The Security Reporting window, as presented in Figure 32 Security Reporting Window, page 391, is
the main window from which you can work with the security monitoring views.
Figure 32: Security Reporting Window
General Attack
Other
Security Monitoring and Reporting
You can display different types of data by switching between different monitoring views. The default
monitoring view is the Logs view; it shows a table with attack parameters, with various tools to
customize the tables presentation.
The following table describes the all security monitoring views that you can display in the Security
Reporting window.
Real-Time Dashboard
The Dashboard provides a real-time and short-term history tool for examining the activity in your
network. The Dashboard enables you to analyze security events in the network, identify security
trends and perform risk analysis. This view is automatically refreshed every 30 seconds to provide
ongoing real-time analysis of the system.
The Security Dashboard also provides a live moving radar, from which attacks can be viewed as they
occur based on the frequency.
To view the Dashboard
1. In the main window, select the device icon and click Security Reporting. The Security
Reporting window appears.
2. Select Dashboard. The Dashboard appears.
Table 55: Security Monitoring Views
View Description
Displays the general attacks table that contains the attacks parameters, see
Viewing Attack Logs, page 399.
Displays the attacks as graph charts, see Viewing Attacks Graph,
page 405.
Displays the attacks in a split view showing the attacks table and graph charts,
see Split Attacks View, page 406.
Displays a real-time security analysis of your network, see Real-Time
Dashboard, page 392.
Displays the top scanning activities occurring in your network, see Viewing
Top Scan Dashboard, page 394.
Displays the general view of traffic in your network, see Traffic Monitoring
View, page 424.
Displays device activity during an attack, see The Mitigation View,
page 396.
Displays the attacks geographical sources, see Viewing the Geographical
Security Map, page 423.
Displays various HTTP traffic behavioral analysis views, see The HTTP
Views, page 419.
Figure 33: .Dashboard Desktop
Dashboard Layout
The Dashboard has two panels. On the left, is the Top Security Attacks Radar, which displays the
most intensive attacks currently in the system. The latest event is displayed below the radar (and is
saved in the Security Events database). The event is displayed with the following syntax: Last
Event: <attack name> <attack BW> occurred at <hh:mm>.
You can select dashboard data for the last hour, 2 hours, or 3 hours.
To the right, are four graphs showing the top attacks in the defined network, and their severity.
These four graphs provide a more comprehensive picture of real-time attacks to the system, by
mapping the following:
Total Number of Attacks: Total number of attacks for the display period.
Attacks By Risk (Severity): Breakdown of attacks in the display period by severity: High,
Medium, Low.
Top Attack Targets: IP addresses of the top five attack targets for the period.
Top Attack Sources: IP addresses of the top five attack sources for display period.
Total Traffic and Attacks: Shows the current number of detected attacks (red-line) compared
to the traffic rate in packets per second (green line) that traversing the device over time. View
refreshes every 15 seconds. The grey progress bar shows time.
Working with the Dashboard
Select a single device or multiple devices to filter displayed Dashboard information.
Notes:
>> When multiple devices are selected, the information displayed in the pie chart reports
is accumulative for all the devices displayed in the Dashboard. For example, the Top
Sources pie chart should take into account the Top Sources from all devices.
>> When multiple devices are selected, the information displayed in the Security Radar is
accumulative for all the devices displayed in the Dashboard. This means that identical
attacks that are reported from multiple devices appear only once, with a counter that
takes into account the multiple devices.
>> When selecting multiple devices, the Ports dropdown list is disabled. If you select only
a single device, then the Ports dropdown list is enabled so that you can select a device
physical port.
To select devices in the Dashboard
2. Click Dashboard on the toolbar. The Dashboard window opens.
3. From the Device dropdown list in the Dashboard window, select the required device. To display
all devices, select All.
4. To select multiple devices, click the + button. The Elements Selection window appears.
5. Select the devices to display in the Dashboard window and click OK.
To select physical ports:
1. From the Ports dropdown list in the Dashboard window, select the required port. To display all
ports, select All.
2. To select multiple ports, click the + button. The Port Selection window appears.
3. Select the device physical ports to display in the Dashboard window and click OK.
Viewing Top Scan Dashboard
The Top Scan Dashboard view displays the network scanning activity in your network. The view
shows the top scanned target IPs, the top scanning IPs and the distribution of the scanned ports.
Receiving additional information on a scanned port from sans.org, can help you decide whether
worms, including zero-day network worms, exist in your network.
Figure 34 Top Scan Dashboard View, page 395 shows an example of the Top Scan Dashboard view.
Figure 34: Top Scan Dashboard View
The following table explains the information presented in Figure 34 Top Scan Dashboard View, page
395.
To display the Top Scan view
2. Click Top Scan. The Top Scan view appears.
Table 56: Top Scan Dashboard Panes
Pane Description
Top Scan IPs
Displays a chart that shows the distribution of the top targeted IPs scanned by
the device.
Top Scanners
Displays a list of host IPs scanning the network.
Top Scanned Ports
Displays a pie chart of target ports distribution. For more information about
worldwide activity on a specific port, click on the link under the pie. In the
legend under the pie you can see the following:
Color: each color represents a different port number (from the top-10
ports).
(x,xxx,xxx): number of probe events activities (i.e., port hits) per probed
port.
(%) - relative portion of port hits in %.
More info: link to www.sans.org, which provides info on the recent
activities on this port worldwide.
The Mitigation View
The Mitigation view allows you to see how much attack traffic was mitigated (Figure 35:, page
396). This monitoring view is used for bandwidth consuming attacks, such as DoS, network scans,
worm propagation, etc. The graphical representation of traffic statistics, as provided by the
Mitigation view, enables you to see the ratio between traffic that passed through the device and
traffic blocked by the security protections during an attack.
Total aggregated traffic during attack: Total traffic during the attack in the selected time
resolution.
Total mitigated traffic: Total mitigated traffic during the attack in the selected time resolution.
Figure 35: The Mitigation View
The data is collected for behavioral protections and you can choose to display it in either Graph or
Table view. The following table shows the parameters that appear when Mitigation view is displayed
as a table.
Table 57: Attack Mitigation Parameters
Parameter Description
Period
How often the information in this view is presented. For example,
Time Resolution=hour and Period=12 means that the information was
collected between 11:00 and 12:00.
Aggregated Traffic
Total amount of traffic that passed through the device during the attack
period. Measured in units defined by the Units parameter.
Mitigated Traffic
Traffic that was dropped by the device.
Note: If the Action of the policy that was violated by this attack is
Report Only, the Mitigation view shows the traffic that would
have been blocked.
To display traffic using the Mitigation view
2. In the Security Reporting window, click Mitigation View. The Mitigation View window
appears.
3. Set the following parameters based on the explanations provided:
4. To display the Mitigation View in table format, select Table, see Table 57, page 396 for
descriptions of the table fields.
5. To display the Mitigation View in graph form, select Graph.
General Attack Views
This section describes general attack monitoring views and includes the following topics:
An Attack View, page 398
History Views and Real-Time Views, page 398
Attacks Over the Predefined Period of Time, page 398
Viewing Attack Logs, page 399
Normalized Traffic
The legitimate traffic that passed through the device during the attack:
Normalized = Aggregated - Mitigated.
Misused Traffic [%]
Percentage of the Mitigated traffic of the Aggregated traffic:
Units
Traffic measurement units presented in the graph or table.
Possible values include: Kilo Bytes (KBytes) and Kilo Packets.
Default: Kilo Bytes.
Time Resolution
Time period for collecting the data for this view. After this period of time, the
view is automatically refreshed. Possible values:
Hour: last 24 hours.
Day: last week.
Month: last 6 months.
Note: The view is empty until the first full cycle of the time unit is
completed. For example, the device must collect data for at least
one full month before showing monthly attack mitigation view.
Update Interval
(read only)
Notifies about the views details refresh period.
Y-axis Scale
Select logarithmic or linear.
Table 57: Attack Mitigation Parameters
Misused
Mitigated
Aggregated
------------------------------- 100 =
Viewing Attacks Graph, page 405
Split Attacks View, page 406
Viewing Attack Properties, page 407
Filtering the Attack Views, page 411
Viewing Attack Groups, page 413
Predefined Attack Views, page 414
User Defined Attack Views, page 414
An Attack View
When an attack is detected, the device creates a security event that includes the information
relevant to this specific attack. Once an event has been created, the device reports it. An attack
view displays a security event, or a group of security events, that belong to the same attack.
History Views and Real-Time Views
You can display History or Real-Time attacks views. The History view presents all the current and
historical attacks. Historical attacks are attacks that were terminated more than 30 seconds ago.
The Real-Time view presents attacks currently taking place, or ones that were terminated less than
30 seconds ago.
To display a History/Real-Time view
2. To display the History attacks view, from the Security Reporting toolbar, click History.
3. To display the Real-Time attacks view, from the Security Reporting toolbar, click Real-Time.
Real-Time Data Refresh
To achieve real-time analysis, the view has an automatic refresh rate constantly updating available
data. The view is refreshed by a configurable setting.
To select the refresh period:
2. From the Auto Refresh drop-down list, select the refresh period length.
Note: To drill down to view the security events, double-click an attack in the attack report
view. Detailed information is shown regarding related security events that are
associated with the same attack, see Events View, page 401.
Attacks Over the Predefined Period of Time
You can display attacks over a predefined period of time. You can arrange the attacks based on the
Radware defined periods of time, such as Last Week, Last Month, Last Year, OR you can define the
period you want.
To display attacks over a predefined period of time
2. From the Period drop-down list, select the one of the periods, OR click and define the period
you want in the Calendar window.
Viewing Attack Logs
The Logs view is a table that presents attacks over time. Each attack is a row in the table. The
following figure shows the history attacks log table.
Figure 36: Attack Logs View
The following table describes the attacks parameters displayed in the Logs view.
Table 58: Attacks Parameters
Risk
The predefined attack severity level:
High (red): High severity.
Medium (orange): Medium severity.
Low (yellow): Low severity.
Info (light blue): Used for cases of very low risk, or when they were not
attacks, but events that were reported providing additional information.
Status
The current status of the attack:
Occurred (Signature-based attacks): Each packet matched with
signatures is reported as an attack and must be dropped.
Started/Terminated: When an attack containing more than one
security event is detected, the Started event is sent. When there are no
longer packets that match the characteristics of the same attack, the
Terminated event is sent.
Ongoing: The status that reports the attack while the attack is taking
place; between Started and Terminated.
SSL-Context: Status appears in SSL attack only.
Attack Time
Date and time the attack occurred.
Attack Name
Name of the attack detected.
Radware Attack ID
Radwares unique attack identifier.
Policy
Name of the policy violated by this attack
Physical Port
Port on the device to which the attacks packets arrived.
Action
The reported action can be:
Forward: The packet is forwarded to its destination.
Drop: The packet is discarded.
Reset Source: A TCP-Reset packet is sent to the attackers Source IP.
Reset Destination: A TCP-Reset packet is sent to the attackers
Destination IP.
Category
The type of attack. For example, Intrusions, DoS, Anti Scanning, etc.
Protocol
Transmission protocol used to send the attack: TCP, UDP, ICMP, or IP.
Source Address
Source IP address the attack is related to.
Source Port
TCP/UDP source port.
Destination Address
Destination IP address the attack is related to.
Destination Port
TCP/UDP destination port.
Packet Count
Parameter depends on attacks Status value, as follows:
Number of packets in attack while status is Occurred.
Packet count from the beginning of the attack, while status is Ongoing.
Zero, when the status is Started/Terminated.
When the protection action is Drop, only the first dropped packet is reported,
the following packets/bytes of the dropped session are not counted.
Stateful Inspection protection always reports 0 dropped packets.
Packet Bandwidth
The bandwidth of the attack from the moment the attack started (KBits).
In Sampled and Occurred report events, if a single packet with less than 128
Bytes is dropped, the reported bandwidth value is 0.
SYN protection (SYN cookies) - the bandwidth that was dropped and
reported by SYN protection is calculated by the number of SYN packets
dropped using SYN cookies, multiplied by 60 Bytes (SYN packet size).
The Stateful Inspection protection always reports 0 bandwidth.
Device IP
The IP of the device associated with the attack.
VLAN Tag
VLAN Tag information, by which you can generate reports for each
customer using the customer's VLAN Tag value. A value of 0 in this field
indicates that the VLAN Tag is not available.
MPLS RD
MPLS Route Distinguisher information, by which you can generate reports
for each customer using the customer's RD value.
Table 58: Attacks Parameters (cont.)
To display attack logs
2. Click Logs. The Logs View table appears.
Attack Descriptions
For each attack, you can display a description that explains the origin, purpose and threat of the
attack. The descriptions database is constantly updated on the Radware Web site and updates are
downloadable.
To view attacks description
2. Click Logs. The Logs View table appears.
3. From the table, right-click the attack that you want and select Attack Description. The Attack
Description pane appears.
Events View
You can view events for each attack. The events are presented in a separate table and include
details about the attacks progress and its characteristics. An events view table contains all the
events that belong to one particular attack, as shown in Figure 37 Events Table, page 402.
In each events view table, the following attack parameters are displayed: Name, Device IP, Action
Mode, Risk, Policy Name, Context, Protocol, Category and Radware ID. For a detailed explanation of
the attacks parameters, see Table 57, page 396.
Figure 37: Events Table
The following table describes attacks events.

Table 59: Events Parameters
Date
Date the event was generated.
Time
Time the event was generated.
Source Address
Source IP address of the event.
Source Port
TCP/UDP Source port.
Destination Address
Destination IP address of the event.
Destination Port
TCP/UDP Destination port.
Physical Port
Port on the device the events packets arrived at.
Packet Count
The meaning of this parameter depends on the attacks Status
value, as follows:
The number of packets in the attack while the status is
Occurred.
The packet count from the beginning of the attack, while the
status is Ongoing.
One packet when the status is Sampling.
Zero when the status is Started/Terminated.
To display attack events
2. Click Logs. The Attacks View table appears.
3. Double-click the attack whose events you want to display. The events table of the selected
attack appears.
4. To get back to the attacks table, click To Attack View.
Packet Reporting
You can configure the device to send a captured attack packet along with the security event. In that
case APSolute Insite presents packets that were identified as attacks.
Packet information includes:
Source
Destination
Protocol
Source Port
Destination Port
Length
Bandwidth
For multiple packets, you can scroll to navigate between data captures.
Packet Reporting must be enabled before it can be used, see the Defense Pro User Guide.
To view the packets
1. In the main window, click the Security Reports tab. The Security Reports window appears.
Packet Bandwidth
The bandwidth of the attack from the moment the attack started
(KBits).
Status
The current status of the attack:
Occurred (Signature-based attacks): Each packet matched
with signatures is reported as an attack and must be dropped.
Started/Terminated: When an attack that contains more than
one security event is detected (refers to attacks that contain
multiple security events, such as DoS, scans, etc.), the Started
event is sent. When there are no longer events that match the
characteristics of the same attack, the Terminated event is
sent.
Ongoing: The status that reports the attack while the attack is
taking place; between Started and Terminated. (refers to
attacks that contain multiple security events, such as DoS,
Scans, etc.).
Sampled: An event that reports the information of a single
packet captured associated with the attack.
SSL-Context: This status appears for SSL attacks only.
Table 59: Events Parameters (cont.)
2. Click Log. The Attacks Log window appears.
3. Click Packets, or right-click the required attack and select Show Packet. A packet, if available,
is presented for each event log.
Note: Packet reporting is not supported when the Reset action is selected.
Exporting Packet Data
You can export the packet data to TCP format. You can export single or multiple packets.
The file with the packets data must be stored using the following default naming convention:
<attack name><date><time>. For example, scan-tcp-scan-16-02-2006_17_11_33.cap.
To export a single packet
1. From the Events table, right click the event and select Export Packet to Ethereal Format.
OR
2. Highlight the event, click the Packets button and select Export Packet to Ethereal Format. A
browser window appears from which you select the name and location of the file that contains
the packet data.
To export multiple packets:
In the Security Reporting window, click Packet and select Export Multiple Packets to
Ethereal Format. The device exports all the packets that are bound to entries which match the
last performed query.
For example, if you filter the log file to show all events for the last day, then when exporting
multiple packets, all the packets for the last day's events are exported and saved on the local
station.
Notes:
>> The export in this option should concatenate all relevant packets for that event.
>> Insite saves the file and launches Ethereal to display the capture.
Searching the Attack Logs Table
You can search the Logs table for specific information. For example, you can search for all attacks
with a specific Source address.
To perform a search in the attacks table:
2. From the Security Reporting toolbar, click . The Search window appears.
3. In the Search window, set the following parameters based on the explanations provided:
4. Click OK. The Search window closes.
Fields Selection
You can select particular columns to appear in the Logs view table instead of displaying all the
columns.
To select the columns to appear in the attacks view table
2. From the Security Reporting toolbar, click . The Elements Selection window appears.
3. Select the names of the columns that you want to appear in the Logs view table and click OK.
The Elements Selection window closes and the attacks view table displays only the columns that
you have selected.
4. To select all the columns, click Select All.
5. To deselect all the columns, click Deselect All.
Viewing Attacks Graph
You can display attacks in Graph view in the following chart formats:
Bar: A bar presentation, showing attacks by frequency by attack name.
Pie: Available for top attack views.
To display attacks in the Graphs views
2. Click Graphs. The Security Reporting window displays the attacks in a graph format.
3. To display attacks in the pie chart format, from the top left corner of the graph area, click .
The pie chart appears.
Keyword
Type the specific value that you want to find.
Look in Column
Select the column that contains the information by which you want to arrange
the table.
4. To display attacks in the bar chart format, from the top left corner of the graph area, click .
The bar chart appears.

Split Attacks View
You can display attacks in Split view. In this view, half of the display pane presents an attacks pie/
bar and the other half presents the attacks table.
To display attacks in the Split view
2. From the Security Reporting toolbar, click Split. The attacks split view appears.
Viewing Attack Properties
Some attack types also have a set of specific parameters.
In the Security Reporting window, you can view General Attack Characteristics or Attack Statistics.
You can view additional in-depth characteristics information about the following attack types:
Behavioral DoS attacks.
Anti Scanning attacks, including network worm propagation attacks.
HTTP Mitigation attacks.
To view attacks properties:
2. In the Logs table, right-click the attack whose properties you want to display and select Attack
Properties. The Attack Characteristics pane appears.
Behavioral DoS Attack Properties
When Behavioral DoS detects a network flood attack, such as TCP SYN or TCP RESET flood, it
analyzes attack footprints to determine the nature of the attack. The Behavioral DoS protection then
filters the attack automatically, blocking it without interrupting legitimate traffic, see the Defense
Pro User Guide for further information.
Figure 38 Behavioral DoS Attack Characteristics, page 408 shows the Attack Characteristics view,
as described in Table 60, page 408.
Figure 38: Behavioral DoS Attack Characteristics
The Attack Statistics view provides overall traffic and protocol information, showing anomalies in
traffic patterns. These anomalies indicate an attack condition.
The following view options are available:
Attack Statistics table: Displays attack traffic and normal traffic in table format. Red stands
for the real-time values that were identified as suspicious when the attack was triggered. Black
stands for normal traffic baselines. Table columns are changed based on the protocols: TCP/
UDP/ICMP.
Short-term History Graph: Displays in red the relevant traffic type for the 15 seconds prior to
when the attack was triggered and the results of the Behavioral DoS mitigation. For example, for
a UDP flood, just UDP traffic is visualized. The blue line represents the normal traffic baseline.
The following figure shows the table view, and Figure 40 Behavioral DoS Statistics Graph, page 409
shows the graph view.
Figure 39: Behavioral DoS Statistics Table
Table 60: BDoS Attack Information Parameters
Tab Description
General Attack
Characteristics
A table that displays detailed information about each field in the IP header,
TCP header, UDP header or ICMP header, characterizing common
denominators of attack traffic.
Footprint Blocking Rule
From the General Attack Characteristics table information, Behavioral DoS
protection generates a footprint blocking rule. This provides the narrowest
effective blocking rule against the flood attack.
Protection State
The state of the protection process. Possible values are:
Footprints Analysis: Behavioral DoS protection has detected an
attack and is currently performing attack footprint analysis.
Blocking: Behavioral DoS protection is blocking the attack based on
the attack footprint created during the footprint analysis state. During
this state, through a closed feedback operation, the Behavioral DoS
protection optimizes the footprint rule until it achieves the narrowest
effective mitigation rule.
Suspicious Activities: No blocking is performed because no footprint
was detected or because the blocking strictness level was not met.
Figure 40: Behavioral DoS Statistics Graph
Anti Scanning Attack Properties
When a Network Scan attack or Network worm propagation activity is detected, the Anti Scanning
protection determines the scan pattern.The device blocks the scanning activity based on the scan's
pattern.
You can view the details of the scan attack using the scan/worm propagation blocking footprint. The
following figure shows an example of such footprint.
Figure 41: Anti Scanning Footprint
An Anti Scanning footprint contains the filter blocking rule that is applicable to the scan's pattern.
Such patterns include the Source IP address, Probed ports or IP's, TTL value, Packet size, TCP
sequence number, ICMP message type and IP Identification number.
HTTP Flood Attack Details
When the device detects an HTTP Flood attack targeting a protected Web server, the HTTP Mitigator
protection performs an attack footprint analysis to determine the nature of the attack. Then the
protection filters the attack automatically, blocking it without interrupting legitimate traffic.
In the Security Reporting window, you can view the General Attack Characteristics view or the
Attack Statistics view for each HTTP flood attack.
The following figure shows the General Attack Characteristics pane and Table 61, page 410
explains the parameters presented in this pane.
Figure 42: HTTP Attack Characteristics
Table 61: HTTP Attack Characteristics Parameters
Protection Information
Number of blocked
Sources
Number of Source IP addresses identified as attackers and action
generated to mitigate the attack activities.
Protection State
The following states are available:
Characterization: The system is performing an attack footprint
analysis.
Mitigation: The system applies rate-limit operations to traffic that
contains the attack footprint.
Suspicious activities: The system does not mitigate the attack
because an attack footprint was not found, or it was not effective
mitigating the attack.
Action
Describes configured protection action: Block or Report-only.
Mitigation Mode
Configured mitigation method, Manual or Automatic.
Rate Limit Factor
Rate limit factor the system automatically selects to mitigate the attack.
The rate limit is set to limit the rate of HTTP requests containing the
Request URL, as specified in the blocking rule table. The rate, in this
case, is limited to a level not higher than the expected adapted
normal rate of this URL request size. Possible rate limit factor values
are:
Normalized rate.
50% normalized rate.
10% normalized rate.
The rate limits the traffic per attack source and its associated
request URL, as specified in the blocking rule table. Possible rate
limit values are:
50% reduction.
75% reduction.
100% reduction.
For example, 50% means that all the HTTP traffic from the attack
source to the attacked server (that includes the attack URL request
URL, as specified in the blocking rule) is limited to 50 % from its real
time rate.
Full block is applied if the attack includes only HTTP requests that
are not Post or Get. All HTTP requests that are not Post or Get
Requests, are blocked.
Blocking rules table
Source IP address Source IP addresses that were identified as attackers and that mitigation
rules applied. Up to 40 different IP addresses can be viewed.
Note: In case the HTTP flood attack is distributed very widely,
meaning more than 1000 source IP addresses, the system
does not use any source IP addresses in the blocking rule. This
mitigation option is available only when the URL Only blocking
mode option is enabled.
The following figure shows the HTTP Attack Statistics table view.
Figure 43: HTTP Attack Statistics Table
The normal values are marked in blue, representing the adapted normal traffic baselines. The
abnormal values are black, representing the real-time values identified when the attack was
triggered.
The following figure shows the HTTP Request Size Distribution view.
Figure 44: HTTP Request Size Distribution Graph
The graph displays the HTTP request URL size distribution.
The y-axis represents the number of HTTP request/sec referring to Get and Post request methods,
and the x-axis represents the Request URL size. The blue line represents the expected HTTP request
rate per size (in bytes) and the gray bars represent the real-time rate values identified when the
attack was triggered.
Filtering the Attack Views
To sort the attacks view based on your requirements, you can set the attacks view filters, as
described in the following table.
Request URL The HTTP request URLs that took part in the HTTP flood attack and the
mitigation rules applied.
Bypassed/Blocked The value is Blocked unless one of HTTP request URLs was configured
to be bypassed, then the value is Bypassed.
Table 62: Customized Log Filters
Filter Description
Date and Time
Filters based on the time events were logged.
Source Address
Filters based on the source network.
Destination Address
Filters based on the destination network.
Attack Name
Filters based on the attacks Radware ID.
Table 61: HTTP Attack Characteristics Parameters
To apply the existing filter
2. From the Filters drop-down box, click on the filter you want to apply to the Logs view table. The
table is arranged based on the filter that you have selected.
To create a new attack log filter:
2. From the Security Reporting toolbar, click next to the Filter drop-down box. The Filters
window appears.
3. Click New Filter and type the new name in the Filter Name text box.
4. Click OK. The Filter Name box closes and the new name appears in the top pane of the Filters
window.
5. Select the new filter name and click Add under the Filter Conditions pane. The Conditions
window appears.
6. From the Condition Category drop-down box, select the category as explained in Table 62, page
411, then define the conditions parameters. The new condition appears in the Filter Conditions
pane when the corresponding filter is selected in the top pane.
Note: You can add additional conditions for filtering the results. Multiple filters have a logical
AND condition between them; for example, Physical Port=2 and Source IP =1.1.1.1.
Category
Filters based on the category of the filter.
Risk
Filters based on the Attack Risk: High Priority, Medium Priority, and Low
Priority.
Protocol
Filters based on the transmission protocol; TCP, UDP or ICMP.
Source Port
Filters based on the TCP/UDP Source port.
Destination Port
Filters based on the TCP/UDP Destination port.
Physical Port
Filters based on the physical port on the device.
Status
Filters based on the status of the filter.
Action
Filters based on the action performed on the attack. Possible values for
the Action Filter Type are Drop or Forward.
Policy
Filters based on the violated policy.
MPLS RD
Filters based on the attacks MPLS RD.
Table 62: Customized Log Filters
Filter Description
7. Click OK. The Filters window closes and the new filter now appears in filters list in the Filters
drop-down box.
Viewing Attack Groups
You can group the attack logs based on the logs table fields. Then you can display a chart based on
the group that you have defined in the logs table. For example, if you select the Source Address
group, then all the attacks with the same Source Address appear as one group and all the other
attack parameters appear as N/A. Then you can display a chart that presents the number of attacks
for each Source Address group. Figure 45 Attacks View Table with Closed Groups, page 413 shows
the table with the closed groups, and Figure 46 Attacks View Table with Expanded Groups, page 413
shows the same table with the expanded groups.
Figure 45: Attacks ViewTable with Closed Groups

Figure 46: Attacks ViewTable with Expanded Groups
To arrange the attacks views table by group
2. From the Group By drop-down list, select the group by which you want to arrange the table. The
table presents groups based on the selected category.
Predefined Attack Views
Radware provides you with predefined attack views. With these views you can arrange the attacks
views table. You can use the predefined views also when generating attacks charts.
To display attacks using the Radware defined Attacks views:
2. From the Attacks List in the left pane of the window, click on the view that you want to display.
The selected view appears in the Logs/Graphs pane.
3. To change the display format from table to chart and vise versa, see Viewing Attack Logs,
page 399 and Viewing Attacks Graph, page 405.
User Defined Attack Views
You can set customized attacks views with the User Defined Security View Wizard.
To set attacks views using wizard
2. From the Security Reporting toolbar, click . The User Defined Security View Wizard appears.
Table 63: Radware Defined Attacks Views
Attacks View Description
Attacks Over Time
(default)
Displays the attacks views table with all the attacks that occurred within the
predefined time period.
Top 10 Attacks
Displays the table/pie/bar that presents the top 10 attacks by frequency.
Top 100 Attacks
Displays the table/pie/bar that presents top 100 attacks by frequency.
High Risk
Displays the table/bar with High risk attacks only.
MediumRisk
Displays the table/bar with Medium risk attacks only.
LowRisk
Displays the table/bar with Low risk attacks only.
Category
Displays attacks of one specific protection category only. The following
categories are available:
ACL
Anti Scanning
Behavioral DoS
DoS Shield
HTTP Mitigator
Intrusions protections
SYN Flood (SYN Cookies)
3. In the View Name text box, type the name of the user defined view and click Next. The Filter
window appears.
4. In the Filter window, define the filters as explained in Filtering the Attack Views, page 411, and
click Next. The Group By window appears.
5. In the Group By window, define attack groups as explained in Viewing Attack Groups, page 413,
and click Next. The Top window appears.
6. In the Top window, define the number of attacks that you want to display, as follows:
7. Click Next. The Summary window appears displaying all the settings that you have set in the
wizard so far.
All
To display all the attacks.
Top
To display a user defined number of the top attacks. Type the number of top
attacks that you want to display.
8. To change the existing settings, click Back to return to the window in which you want to make
changes.
9. To finish defining your user defined attacks view, click Finish. The User Defined Security View
Wizard window closes and the new view appears in the Views List in the left pane of the Security
Reporting window.
The HTTP Views
This section describes HTTP views. The HTTP Traffic Statistics window presents three types of HTTP
traffic statistics for each protected server.
The HTTP mitigator protection monitors rate-based and rate-invariant HTTP traffic parameters. Use
them to generate normal behavior base lines.
With these three views, you can monitor both real-time and historical (normal baselines) values and
analyze HTTP traffic anomalies.
HTTP Request-URL Size Distribution, page 420
Continuous HTTP Traffic Statistics, page 421
24x7 Normal HTTP Traffic Statistics, page 422
HTTP Request-URL Size Distribution
The HTTP Request URL Size Distribution window provides a real-time statistics graph that provides a
clear picture of how server resources are used and enables you to analyze the resources
distribution. When one or more of the HTTP request URL sizes deviates significantly from the normal
probability distribution, it means that relative usage of these server resources has increased.
The graph in the HTTP Request URL Size Distribution window displays the HTTP request URL size
distribution. The x-axis represents the Request URL size in 10 bytes grade. The y-axis represents
the percentage of HTTP Get and Post requests per URL size. The probability reflects the level of
usage of each Request URL size for the protected web server. In this graph, the blue line represents
the normal probability distribution and the gray bars represent the real-time probability (short-term
probability), as calculated in intervals of a few seconds.
To display the URL size distribution view:
1. In the bottom area of the main window, select Security Reporting. The Security Reporting main
window appears.
2. From the Security Reporting toolbar, click HTTP Views and select Server Behavior. The
HTTP requests-URL size distribution window appears.
3. In the HTTP requests-URL size distribution window, set the following parameters based on the
Protected Web Server
Select the IP address of the server for which you want to display the
normal HTTP traffic.
Refresh Period
How often the graph is automatically updated. Possible values include:
None, 15, 30, 60 seconds and 10 minutes.
The graph appears in the HTTP requests-URL size distribution window.
Continuous HTTP Traffic Statistics
The Continuous HTTP Traffic Statistics window displays continuous normal traffic baselines and 24x7
normal baselines without differentiating between traffic statistics on different week days or hours.
The x-axis represents time, and includes short-term time progress, i.e. the last 5 minutes. The y-
axis represents the rate [1/sec] of different HTTP traffic parameters.
The learning response period (the exponential sliding window period from which statistics
measurements are based) is set based on the learning sensitivity settings (default 1 week). To build
a comprehensive picture of the protected site traffic, the device monitors channels, as described in
the following table:
Note: Normal Request per source and Request per connection baseline parameters show the
highest number of HTTP requests that was generated by a single Source IP address
and single TCP connection respectively. This number fades out, unless a higher value
is observed, in a 30 minute interval.
Y-axis Scale
Select logarithmic or linear
Graph Type
The following graph types can be displayed:
General graph: Zoomed out view.
Detailed graph: Zoomed in view.
Table 64: HTTP Traffic Statistics Monitoring Channels
Channel Description
Get/Post requests per
second
Number of HTTP Get and Post requests sent to the protected server.
Other requests per
second
HTTP requests that are not Post or Get.
Other HTTP request methods can be used.
Outbound HTTP [MBps]
Bandwidth of HTTP pages sent as a response to the requests defined
using the Get & Post requests per second parameter.
Requests per source [1/
sec]
Maximum number of HTTP Get & Post requests per Source IP address.
This shows site users' behavior enabling you to recognize abnormal
activities, such as scanning or bots. Legitimate users may generate
many requests per second, but automatic devices such as bots or
scanners generate many more.
Requests per connection
[1/sec.]
The maximum number of HTTP Get & Post requests per TCP
connection.
This parameter characterizes the site users' behavior enabling you to
recognize abnormal activities, such as scanning or bots. Legitimate
users may generate many requests per second, but automatic devices
such as bots or scanners generate many more. It can be done through a
single TCP connection.
To display the URL size distribution view
window appears.
2. From the Security Reporting toolbar, click HTTP Views and select Continues Traffic
Statistics. The Continues Traffic Statistics window appears.
3. In the Continues Traffic Statistics window, set the following parameters based on the
The graph appears in the Continues Traffic Statistics window.
24x7 Normal HTTP Traffic Statistics
The 24x7 Normal Traffic Statistics view shows the graph of normal traffic baselines recorded during
the past week. The graph is automatically updated every hour.
You can view the hourly distribution of site requests and outbound HTTP traffic for each day within
the past week and for each hour within a day. The graph displays the Get & Post and other requests,
OR the HTTP Outbound traffic baselines.
Although the graph shows the past week, the hourly normal baseline is calculated based on
historical information of the same hour in the day and the same day of the week over past 4, 12 or
24 weeks. 12 weeks is the default value.
Refresh Period
How often the graph is automatically updated. Possible values include:
None, 15, 30, 60 seconds and 10 minutes.
Parameter type(s)
Type of information displayed in the graph, see Table 64, page 421.
Y-axis Scale
To display the normal HTTP traffic
window appears.
2. From the Security Reporting toolbar, click HTTP Views and select Traffic Parameters. The
24x7 Normal Traffic Statistics window appears.
The 24x7 Normal Traffic Statistics window displays the graph.
Viewing the Geographical Security Map
Attacks may occur from different locations around the world. System administrators may want to
track such attacks to see from where the attack originated. Global companies, with offices around
the world, may suffer from internal attacks hitting the HQ offices, originating from branches located
in other countries.
The Geographical Security Map enables you to generate a Top Attack Sources report and display the
results on a geographical map of the world by displaying an indication on the countries from where
the attacks originated.
You can modify the result of the report by configuring the following parameters:
Map Top: The map displays the location that has the highest number of attacks. You can set the
number of top attacks to display. The default setting is 2.
Display Last: The map displays historical information in an "hour" resolution. The default
interval is 1 hour.
Total Active Attacks: Number of attack source locations that were identified. When attacks
cannot be associated with any known location, it is considered as one (unknown) location.
To display and use the geographical map:
2. Click Map on the toolbar. The Top Attacks Geographical Maps window appears.
Day
Select the day for observing the normal base lines.
Parameter Type(s)
Type of information displayed in the graph:
Get & Post requests
Other request types
Outbound HTTP
Y-axis Scale
3. Set the time range of attacks to display from the Display Hours drop-down list. Possible values:
1, 2, or 3 hours.
4. From the Map Top drop-down list, select the number of locations, that have the highest number
of attacks, to display on the map. Possible values: 2, 5, 10, or 12 attacks.
5. To view the originating country's name, move the cursor over an attack indicator (a red circle
around the country where the attack originated). A tool tip appears with the country name.
Traffic Monitoring View
The Traffic Monitoring view displays real-time traffic monitoring statistics that provide information
on network traffic over time and displays all the IP traffic passing through the device. The following
information is included in this view: data on overall IP traffic, protocol mix, and packet discards. The
same data is displayed in the graph and in the table.
The Traffic Monitoring window also includes the Connections Statistics table, which presents
statistics based on the Session Table.
Figure 47: Traffic Monitoring View
Before displaying the traffic monitoring view, you need to define the direction of traffic to be
presented in the graph and table views. Possible values for this window are all the pairs of ports
configured in the Static Forwarding window. The Connection Statistics are displayed only when the
device is operating in the Full Layer 4 Session Table Lookup mode.
To define traffic direction
1. In the bottom area of the main window, select Security Reporting. The Security Reporting
main window appears.
2. From the Security Reporting toolbar, click Traffic Monitoring. The Traffic Monitoring window
appears.
3. Click Traffic Direction. The Traffic Direction window appears.
4. Define the direction of the traffic. For example, F2>F1: The traffic sent to F2 is considered to be
Inbound and the traffic sent to F1 is considered to be Outbound. In other words, the traffic from
F2 to F1 is Inbound and from F1 to F2 is Outbound.
5. Click OK. The Traffic Direction window closes.
To display the Traffic Monitoring view
1. In the bottom area of the main window, select Security Reporting. The Security Reporting
main window appears.
2. From the Security Reporting toolbar, click Traffic Monitoring. The Traffic Monitoring window
appears.
Security Reporting
Radware's reports generator enables you to create various report types. The information that
appears in reports can be collected from different time periods, providing a useful and detailed
picture of Radware's protections. Analyzing this information can help you provide optimal protection
for your system.
You can set user defined reports, selecting the information that you want in the reports. Reports are
defined using the reports wizard. Before configuring new reports, you need to ensure the following:
Reporting channels are enabled.
Packet reporting is enabled
To define a new report
window appears.
2. Click . The Schedule Reports window appears.
Refresh period
How Often the graph is automatically updated.
Values: None, 15, 30, 60 seconds and 10 minutes.
Units
Traffic measurement units shown in the graph and table.
Values: Bytes/sec. and Packet per Second (PPS).
Default: Bytes/sec.
Graph filters
Shows report data in the graph using these filters:
Show Traffic: Enables you to select the traffic direction that you
want to show in the graph. Traffic direction settings are set using
the Traffic Direction parameter.
Values: Inbound, Outbound, Both.
Default: Both.
Protocol: Enables you to define the Layer 4 protocol type that is
monitored in the graph.
Values include: TCP, UDP, ICMP, Other IP and All.
Default: All.
3. Click Add. The User Defined Security Report Wizard window appears.
4. In the Report Name text box, type the name of the new report.
5. In the Device area, select one of the following options:
6. In the Period area, select one of the following report generation options:
Any Device
All devices configured to send security events to the APSolute Insite
station. These events are summarized in the generated report.
Single Device
Select IP address of device for report generation.
Multiple Devices
Select devices for report generation.
All Days
Reports all data during time traffic was monitored.
Last
Reports only information collected during past Day/Week/Month.
From/To
Reports all data within the selected period of time.
7. Click Next. The Report Layout window appears.
8. In the Report Layout window, define the following:
9. Click Next. The Customer window appears.
Report Type
Radware provides you with predefined attack views that can be presented
in the report. When selecting multiple report types, all reports generated
by the device are contained in the same file.
Graph Type
Select graph type to show in the report.
Event List
To see a complete list of all the attack events, select Export attack list.
This list is very long, thus, is not required for managerial level reports. The
list is exported into an Excel file.
Report Format
Select the reports format: HTML or PDF.
10. In the Customer window, select one of the following options:
11. To define a new customer, in the Customer window, click Add. The Add Customer appears.
Any Customer
Report is generated on the entire Database.
Single Customer
Select the customer for whom report is generated.
Multiple Customers
Select the customer(s) for whom report is generated.
Customer Name
Name of the customer who receives the report.
Device
Device about which the report is generated. You can select a single
device or multiple devices.
Default: Single Device.
Interface
Select physical interface defining the customer. For example, all web
servers are connected to F2 and all mail servers to F4. Customer Web
is defined by selecting F2 and Customer Mail is defined by selecting
F4.
The following options are available:
Any Configuration: All physical interfaces are selected.
Port Groups: Select the specific physical port(s) that represent
your users
13. Click OK. The Add Customer window closes and the new customer name appears in the
Customers table.
14. Click Next. The Schedule window appears.
Destination
Defines the Destination Network of the report, which is the network
used by the customer who receives the report. Select one of the report
destinations:
All Types: All the protected destination networks
Unique IP
IP and Mask
IP Range
Tunneling
Select the tunneling options that defines your customers network
environment:
VLAN Tag
MPLS RD
16. Click Next. The Summary window appears, displaying all the report settings that you have
defined so far.
Schedule
Define when to send the report:
Specific Date: Set specific day and time
Every: Set Day/Week/Month to send the report.
Sent To
Define the e-mail for receiving the reports.
You can add only e-mails defined in the Traps & SMTP window.
Report Directory
Location
Enables saving the report locally. Define where you want to save the
report on the management station.
17. To change the report settings, click Back and change the settings in the appropriate window.
18. To generate the report, click Generate Now.
19. To complete defining the report, click Finish. The User Defined Report Wizard window closes
and the new report appears in the Schedule Reports window.
Document ID: APS_02_71_UG 404
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.
Alphabetic List
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 4-byte 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.
3-tier Software
Architecture,
(Insite 5.0)
3-tier Software Architecture - APSolute Vision is a three-tier Element Management
System with client, server and device tiers:
The Client tier provides all the interface functionalities and basic configuration validation.
The Client tier does not connect to devices directly.
The Server tier controls all other management functionalities, such as user authentication
and authorization, final configuration validation, all logging and reporting operation and
devices configuration. The Server tier also provides multi-user functionality, allowing
multiple administrators to work concurrently on APSolute Vision.
The Network Physical Devices tier encompasses all connected Radware devices.
With three tiers in a software/hardware system, each tier can be developed concurrently
by different teams of programmers in geographically separate locations and coded in
different languages. Because the programming for a tier can be changed or relocated
without affecting other tiers, the 3-tier model makes it easier for an enterprise or software
packager to continually evolve an application as new needs arise.
AAA
Authentication, Authorization and Accounting - a term for a framework for intelligently
controlling access to computer resources, enforcing rules, auditing usage, and providing
the information necessary to bill for services.
Active Up
Active Up - in a cluster configuration when the High Availability unit that was Active but has
failed,becomes available again, it returns to the cluster not as the Active machine but as a
standby.
AAC
Administrative Access Control (AAC) enables selective access by authorized individuals
and devices.
Authorized users can be classified as employees, technology service provider (TSP)
employees, vendors, contractors, customers, visitors, or any other classification. Access
should be authorized and provided only to individuals whose identity is established, and
their activities should be limited to those defined in the access control.
Devices on the network also need to be authenticated and authorized.
Radware Technical Glossary
405 Document ID: APS_02_71_UG
ACL
The Access Control List (ACL) is a list of instructions for the operating system on the
access rights of each user to a particular system object, such as a file directory or
individual file.
Each object has a security attribute that identifies its access control list and the list has an
entry for each system user with access privileges. The most common privileges are:
Read a file (or all the files in a directory)
Write to a file or files
Execute an executable file
Microsoft Windows NT/2000, Novell's NetWare, Digital's OpenVMS, and Unix-based
systems are among the operating systems that use access control lists. The list is
implemented differently by each operating system.
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
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.
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, typically in front of frontline Web servers; devices for
optimizing response time of applications on a network, typically 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.
APSolute Insite User Guide
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.
AJAX
Asynchronous J avaScript and XML - using J avaScript (J S) scripting language is a
development technique used for creating interactive web applications. The goal is to make
web pages more responsive by exchanging small amounts of data with the server behind
the scenes, so that the entire web page does not have to be reloaded each time the user
requests a change.
AND Group
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.

Anomaly
An Anomaly is an unusual or unexpected behavior of traffic patterns or a protocol.
Anonymizer
Anonymizers are services that allow the user to achieve internet privacy.
Most anonymizers act as a proxy server: When users intend to connect to an internet
server, they do not connect directly to that server, but rather via an anonymizer on their
behalf, concealing the users personal identity.
Anonymizers can be blocked by Radware at the network level, preventing both users/
hackers from accessing the anonymizers web sites and anonymized traffic targeting
servers.
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.
APM
(Radware)
Radwares Application Performance Monitor (APM) monitors and measures end-to-end
performance metrics in real-time, aggregated from single or multiple touch-points. It can
identify the location of bottlenecks along the application delivery path, and apply network
and application-level remediation techniques.
APM can trigger alarms when SLA thresholds are not met. Because of better and more
accurate monitoring, APM prevents finger-pointing between network & application teams.
APMApplication
An Application Performance Monitoring (APM) Application is a set of TCP protocols
serving a common goal. APM supports various static applications, such as web
applications which contain both HTTP and HTTPS protocols.
APMMonitor
An Application Performance Monitoring (APM) Monitor is a collection of statistics derived
from the path of an application over a series of Radware devices.
APMPath
An Application Performance Monitoring (APM) Path defines a set of Radware devices over
which an application flows.
A path may consist of one or devices and up to three server farms as the paths endpoint.
Appliance,
Radware
A Radware Appliance is a hardware device preinstalled with Insite.
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 typically defined at a
higher level
.
Application Level
Flood Attack
Application Level Flood Attacks are are protected against by DefensePros Behavioral
Denial of Service, such as zero-day flood attacks, including SYN Floods, TCP Floods,
UDP floods, ICMP and IGMP floods.
DefensePro Behavioral DoS detects a network flood attack, it analyzes the attack footprint
then applies Behavioral DoS protection filters to block flood attacks without interrupting
legitimate traffic.
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, end-to-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.

Application Front
End
(Radware)
Radwares Application Front End (AFE) 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.
AFE 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.
You use the Application Grouping Table to configure destination grouping. Application
grouping is only available when Client Table Mode is set to Layer 4.
Application Switch
(AS), (Radware)
Application Switch (AS) ranging from AS-1 to AS-5 answers IP application requirements
across network layers 4-7.
Designed to guarantee application availability, security and performance, an Application
Switch bridges the gap between IT infrastructure and IP Applications for comprehensive
control of critical operations across the enterprise.
A Radware Application Switch performs Layer 7 switching at multi-gigabit speed, and
facilitates not only traffic management, but also provides intrusion detection and
prevention at multi-gigabit speed. This allows for more comprehensive health checks at
shorter intervals without performance degradation. Hardware-based queues allow faster
enforcement of bandwidth management policies.
The differences between AS-1 to AS-5 are in the power of the hardware and the
intelligence of the software.

Application
Switch, Compact
(CAS)
The Compact Application Switch is Radwares desktop platform, featuring an intergrated
eight-port Fast Ethernet Switch. This platform is designed to meet the requirements of
Remote offices and Branch offices.
AppXcel
AppXcel is a Radware transaction/application accelerator with Web compression, Secure
Socket Layer (SSL) offloading, HTTP Radware Solutions for Virtualization multiplexing,
TCP optimization, image optimization, caching and Web firewall capabilities for fast
application and transaction response times and security.
AppXcel provides:
Web compression to reduce the amount of bandwidth consumed.
Cryptography acceleration and SSL calculations to relieve web servers of CPU- intensive
Secure Socket Layer (SSL) encryption and decryption processing.
Caching of served information AppXcel improves application performance by caching
requested information.
Image compression and caching to enable serving images faster.
Optimization of HTTP and TCP connections by opening only a limited number of user
sessions.
Combining AppXcel with AppDirector creates a comprehensive IAS (Intelligent Application
Switching) solution that dramatically increases network reliability and performance.
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.
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.
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.
In order 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.
ASP
An Application Service Provider (ASP) is a business that provides computer-based
services to customers over a network. There are several forms of ASP businesses:
A specialist or functional ASP delivers a single application, such as credit card payment
processing or timesheet services;
A vertical market ASP delivers a solution package for a specific customer type, such as a
dental practice;
An enterprise ASP delivers broad spectrum solutions;
A local ASP delivers small business services within a limited geographical area.
ASR
Automatic Speech Recognition (ASR).
ATM
Asynchronous Transfer Mode (ATM) is a cell relay, packet switching network and data link
layer protocol that encodes data traffic into small (53 bytes; 48 bytes of data and 5 bytes of
header information) fixed-sized cells.
ATM provides data link layer services that run over SONET (Synchronous Optical
Networking) Layer 1 links. This differs from other technologies based on packet-switched
networks, such as the Internet Protocol or Ethernet, in which variable sized packets
(sometimes known as frames) are used.
ATM is a connection-oriented technology, in which a logical connection is established
between the two endpoints before the actual data exchange begins.
ATMSwitch
An ATM Switch is one of the key components of ATM technology. ATM provides scalable
bandwidth that spans both LANs and WANs. It also has Quality of Service (QoS)
bandwidth on demandthat can map into and support higher-level protocol infrastructures
for emerging multimedia applications and provide a common, multiservice network
infrastructure.
Attack
An Attack is a realization of a threat, a malicious action taken against a network, host or
service.
Attack List
An Attack List is a database of known attackers as defined in the Signatures Database.
Attack DB
(Attack Signatures
Database)
Radwares Attack Signatures Database contains signatures of known attacks.
These signatures are included in the predefined groups and profiles supplied by Radware
to create protection policies in the Connect and Protect Table. Each attack group consists
of attack signatures with common characteristics intended to protect a specific application
or range of IPs.

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.
Auto-negotiation
Auto-negotiation commonly refers to the auto-configuration of Speed (e.g., 10Mb, 100Mb)
and Duplex (half-duplex or full-duplex network configuration settings) on multi-speed
network devices.
It takes control of a cable when a connection is established to a network device and
detects the various modes that exist in the device on the other end of the wire and
transmits its own abilities to automatically configure the highest performance mode of
interoperation.
Backend
Encryption Port
The Backend Encryption Port is a specially predefined port on the backend session Layer
4 classification. It can be any TCP port; it must be set to the same value as the Server Port
in the Tunnel that is defined on AppXcel.
The Backend Encryption Port indicates that backend encryption support is required in that
Layer 4 classification and also sets the port to which AppXcel sends the backend host
encrypted traffic.
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.
Bandwidth
Bandwidth is the width of the range (or band) of frequencies that an electronic signal uses
on a given transmission medium, expressed in terms of the difference between the
highest-frequency signal component and the lowest-frequency signal component,
measured in hertz (the number of cycles of change per second).
A typical voice signal has a bandwidth of approximately three kilohertz (3 kHz); an analog
television (TV) broadcast video signal has a bandwidth of six megahertz (6 MHz) -- some
2,000 times.
Bandwidth
Management
Radwares Bandwidth Management (BWM) Bandwidth Management is the process of
measuring and controlling network traffic, prioritizing applications according to their
bandwidth and not exceeding link capacity.
Radwares BWM provides attack isolation and protection against unknown flooding
attacks, prioritizes bandwidth for critical applications, and delivers traffic shaping, including
bandwidth per traffic flow to enable limiting of bandwidth per client or session within a
global BWM rule.
For example, you can assign HTTP traffic a higher priority than SMTP traffic, which in turn
may have higher priority than FTP traffic in your network. Tracking the bandwidth used by
each application enables you to:
Ensure a guaranteed bandwidth for certain applications.
Set limits as to how much bandwidth each classified traffic pattern can utilize.
BC/DR
Business Continuity (BC) and Disaster Recovery (DR) are often used interchangeably to
describe the measures to keep critical business processes functioning in the face of
natural or man-made interruptions. Business Continuity includes both High-Availability
measures (proactive steps to prevent disruptions) and Disaster Recovery measures
(reactive plans, procedures, facilities, etc.,) designed to effect recovery and return to
normal business operation.
The simplest and most effective approach to dealing with WAN and Internet reliability
issues is the concept of multi-homing, also referred to as Multi-WAN switching.
B-DoS
Behavioral DoS (Behavioral Denial of Service) protection defends networks from zero day
network flood attacks that jam available network bandwidth with spurious traffic, denying
use of network resources for legitimate users.
BDoS profiles do this by identifying the footprint of the anomalous traffic. Network Flood
protection types include:
SYN Flood
TCP Flood, including TCP Fin +Ack Flood, TCP Reset Flood
TCP Syn +Ack Flood, TCP Fragmentation Flood
UDP Flood
ICMP Flood
IGMP Flood
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.
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, aka 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.
Blacklist
A Black List defines the IP addresses that are always blocked without inspection.
Black lists are used as exceptions for security policies/rules, blocking all traffic generated
by IP addresses in the Black List.
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
This lists the MAC addresses of frames arriving from each physical interface.
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 typically bounded by routers because routers do not
forward broadcast frames.
BSN
Business-Smart Networking (BSN) aligns network behavior with business processes.
Application Aware Network Services (Application-Smart Networks)
User Aware Network Services
User Identity vs. IP Address
Business Aware Network Services
Business Events vs. Network Sessions
BSN drives productivity, ensures business continuity and enables real-time business
reaction to events, as well as reducing CAPEX & OPEX.
BSP
Best Support Package
CC
Common Criteria (CC) is an international standard (ISO/IEC 15408) for computer security.
CC describes a framework in which computer system users can specify their security
requirements, and where vendors can then implement and/or make claims about the
security attributes of their products. Testing laboratories can evaluate the products to
determine if they actually meet the claims.

CCAS
Contact Center Activity Simulator (CCAS, Call Generator)
CertainT 100
Cluster, (Radware)
CertainT 100 Clusters enable the definition of a cluster of AppXcel devices and perform
one configuration task per cluster, including replication of Certificate+Key pairs amongst all
AppXcel devices.
The Cluster consists of a master (main) device and slave devices. Activities such as
defining a Tunnel or creating a Key are performed on the master device and are then
distributed to the slave devices within the cluster. You can define the master device, the
slave devices, and edit the cluster parameters using the Farm Cluster Management
window.
CF
CompactFlash (CF) was originally developed as a type of data storage device used in
portable electronic devices.
For storage, CompactFlash typically uses flash memory in a standardized enclosure.
CGI
The Common Gateway Interface (CGI) is a specification that allows Web developers to
customize or add interactivity to Web pages.
CGI provides a means for passing data to and from a Web user and a Web server through
applications commonly known as scripts. When a Web server receives information from
the user, through the browser, it relies on a CGI application to process the information and
provide the return data to send back to the user.
CHAP
The Challenge Handshake Authentication Protocol (CHAP) is a three way handshake
protocol which is considered more secure than PAP.
CID,
(Radware)
Radwares Content Inspection Director (CID) centrally manages content security tools and
inspects content security traffic, delivering fault tolerant and scalable anti-virus scanning,
URL content filtering and anti-spamming.
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 actually encompass multiple disjointed IP
address ranges. Essentially, 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.
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.
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 in order to maintain client-server persistency.
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, WSD, LP, SF and CID) configured in
active/active or active/backup redundancy.
Collectors
Manager
The collectors' manager is an extended data collector that does everything a collector
does but also can manage other collectors. The data collected by the collectors' manager
is stored directly in the central database.
Configuration by
Exception
Configuration by Exception is the principle of a user being required to supply a value
(annotate a field or properties) only in the case when the default value is not suitable.
Configuration,
Last Applied
Last Applied Configuration is a system configuration, stored on an Insite server, that was
last applied to devices. Last Applied configuration may differ from Running Configuration if
changes were made to the Running Configuration that were not defined via an Insite
server, for example, when a configuration is defined via WBM or device CLI.
Configuration,
Running
Running Configuration (aka Device Running Configuration) is the configuration residing on
a Radware device (e.g. AD, DP, etc) and currently being used by it.
Configuration,
Saved
Saved Configuration (aka Saved System Configuration) is a system configuration stored
on an Insite server. The saved configuration includes all objects and settings, including
configuration of all managed devices in the system tree.
The Insite server can hold multiple saved configurations. Administrator can apply saved
configurations to managed devices (whether one or many). After being implemented, the
saved configuration becomes the Last Applied Configuration.
Configuration
Server
A Configuration Server is the server-side component used for all device configurations,
status, and operation management. It does not include the data collection server.
Connect &Protect
The Connect & Protect table enables the configuration of security policies.
Connection Flood
Attacks
Connection Flood Attacks happen when a TCP three-way handshake can be completed,
but no data packets are sent afterwards. Such attacks are known as connection flood
attacks.
Convergence
Convergence is the process of bringing all route tables to a state of consistency.
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 typically 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.
Critical Device
A Critical Device is a device defined by the Administrator as critical to the operation of the
cluster member. A critical device is also known as a Problem Notification (pnote).
Critical devices are constantly monitored. If a critical device stops functioning, this is
defined as a failure. A device can be hardware or a process. The fwd and cphad
processes are predefined by default as critical devices. The Security Policy is also
predefined as a critical device. The Administrator can add to the list of critical devices
using the cphaprob command
CSM
The Cisco Content Switching Module (CSM) adds advanced Layer 4 to Layer 7 content
switching capabilities to certain Cisco devices.
CTI
Computer Telephony Integration (CTI)
Data Collection
System
A Data Collection System is a collection of all the components involved in collecting the
data, storing it and presenting it to the user.
Data Collector
Data Collector - is the basic collecting component; it collects data from one or more
devices in a variety of protocols and stores the data in a local database. The collector may
also reside on a remote client site.
Database, Central
Central database is located on the main customer site, containing all the data collected by
the collectors, the data warehouse data; also used for storing configuration data.
Data Warehouse
Server
A Data Warehouse Server processes data stored in the database and prepares it for
reporting.
Deep Packet
Inspection (DPI)
Deep Packet Inspection (DPI) is a form of computer network packet filtering that examines
the data part of a packet for non-compliance to protocol. By stripping off the headers, deep
packet inspection devices can use the resulting payload to identify the program or service
being used.
DPI devices have the ability to look at Layer 2 through Layer 7 of the OSI model, including
header and data protocol structures, classifying and identifying traffic according to a
signature database. Much like virus scanners, DPI devices generally make use of
"application signatures"telltale ways of sending and receiving information that can be
used to link a particular packet with a particular application.
DPI devices can generally extract information from traffic that varies by application type: IP
addresses and URLs from HTTP traffic, SIP numbers from VoIP calls, filenames of P2P
files, and chat channels for instant messages.
A classified packet can be redirected, marked/tagged, blocked, rate limited, and of course,
reported to a reporting agent in the network.
Radwares DPI/DFI (Deep Flow Inspection) inspects, identifies and classifies over 80
different applications and provides immediate visibility into over 1,500 attack patterns and
signatures such as worms, viruses and Denial of Service attack traffic.
Radwares DPI/DFI includes unique behavioral engines capable of identifying traffic
streams, creating adaptive, self learning, statistical traffic baselines, and detecting and
mitigatating anomalies including traffic surges, DoS/DDoS floods and worm propogation.
DefensePro
DefensePro (DP), Radwares Network Intrusion Prevention System uses adaptive,
behavioral technology to protect against zero day Dos/DDoS flood attacks without manual
tuning and maintains maximum productivity even when worms or other threats penetrate
the corporate network.
DefensePro normally resides on the path between the clients and both the Internet and the
content inspection servers. All traffic, except for that flowing through local triangulation or
transparent proxy, should be inspected by DefensePro.
DefensePro supports IPv6 traffic scanning and protection, offering complete protection
against a full range of attacks carried both over Ipv4 and Ipv6 traffic. It provides carriers
with multi-layer protection for Voice over Internet Protocol (VoIP) services and secures the
inherent vulnerabilities of Session Initiation Protocol (SIP) from buffer overflow, protocol
misuse, SQL injection attacks, and more.

DFI
Deep Flow Inspection (DFI)
Discrete
Redirection
Discrete Redirection Method Flags. Starting with AppDirector 1.06, the Redirection Mode
parameter is obsolete and is replaced by individual parameters for each redirection
method:
DNS Redirection
HTTP Redirection
RTSP redirection
SIP Redirection (new method)
Global Triangulation
Proxy (Client NAT) (new method)
Multiple redirection modes can be enabled per farm. The only exceptions are Global
Triangulation and Proxy (Client NAT) that cannot be enabled simultaneously.
When application-specific redirection mechanisms (HTTP, RTSP, SIP) as well as 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) are redirected
accordingly, while other applications are redirected using the triangulation or proxy
methods.
DSR
Direct Server Return (DSR) is the direct response of a server to a client, bypassing of the
Load Balancer/AppDirector.
In order to accomplish the bypassing, it is necessary for the Load Balancer/AppDirector to
not translate (NAT) the IP address in requests.
Bypassing the Load Balancer/AppDirector can improve network performance when the
Load Balancer/AppDirector is the bottleneck.
DoS
Denial of Service - is an attempt by malicious persons to flood datacenters with messages
in order make computer resources unavailable to intended users.
DDoS
A Distributed Denial Of Service (DDoS) attack is when multiple compromised systems
overwhelm a single target with a flood of messages, blocking legitimate users access to
the target system.
In DDoS attacks, the attacking computer hosts are often personal computers with
broadband connections to the Internet that have been compromised by viruses or Trojan
programs, allowing the perpetrator to remotely control the machine and direct the attack,
often through a BotNet.
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.
DNS DDoS
Distributed Denial of Server attack on a DNS server. A typical attack involves numerous
compromised zombie systems (botnets) sending spoofed domain-name requests to DNS
servers, which process the "legitimate" request and send replies to the spoofed victims.
When the DNS server is configured to provide recursion, the DNS server, if the requested
domain name isnt available locally, will query the root name servers for the IP address.
The traffic then traverses the internet backbone, affecting the Internet Service Provider
and any upstream provider to reach the intended target.
Radware's adaptive behavior-based DoS protection learns the characteristics of DNS
traffic and re-establishes normal traffic behavior baselines. An embedded decision engine,
based on fuzzy logic, constantly analyzes DNS traffic and detects when deviations from
the normal baselines occur. Upon detection, the system performs an in-depth analysis of
the suspicious DNS packets in order to identify abnormal appearances of parameters in
the packet headers and payload.
DNS Fallback
Mode
DNS Fallback Mode defines whether DNS Redirection is:
The only redirection method for the farm
The primary redirection method for the farm. In this case only DNS Redirection is used,
unless the DNS-redirected site has no available servers and user requests cannot be
honored. Backup Redirection methods can be configured to allow application requests to
be honored in such cases.
One of the available farm redirection methods.
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").

DoS Shield
Dos Shield is Radwares security module, part of the SynApps architecture, that provides
extensive DoS detection and protection capabilities while maintaining high network
throughput.
An attack becomes a threat to the network when it starts to consume large amounts of the
networks bandwidth. The DoS Shield module detects the occurrence of such events with
an advanced sampling algorithm and takes automatic actions to solve the problem, such
as:
Known TCP, UDP, and ICMP floods
Known attack tools available on the Internet
Known floods created by BOTs automated attacks
DoS Shield protection attacks are defined using signatures from a constantly updated
Radware Signatures database.

DPI/DFI
DPI/DFI Framework Solutions - rule-based intelligent traffic management to support
emerging Internet business models and multi-Gig networked-based behavioral IPS and
DoS/DDoS to ensure service integrity and continuity
.
DSID
Dynamic Session ID (DSID) - starting with AppDirector V1.06, a DSID entry for Call-ID is
created automatically for SIP farms.
Call-ID entries can be aged when BYE or Cancel SIP messages are received for that call.
User Persistency can be for Register only - using Dynamic Session ID or for Register &
calls - using Dynamic Session ID and Session ID Sharing.
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 Protcols 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.
EAL
The Evaluation Assurance Level (EAL), is the numerical rating assigned to the target
indicating what assurance requirements were fulfilled during the evaluation. Each EAL
corresponds to a package of assurance requirements which covers the complete
development of a product, with a given level of strictness.
CC (Common Criteria) lists seven levels, with EAL1 being the most basic (and therefore
cheapest to implement and evaluate), and EAL7 being the most stringent (and most
expensive).
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.
EMS
Element Management System (EMS). Insite 5.0 is an EMS, a software-based system that
enable systems administrators to centrally manage a vast set of heterogeneous devices,
but does not have the ability to connect to other Management Systems.
This class of systems exploits vendor-specific management information base (MIB)
variables. There is one standard SNMP MIB, and all vendors extend the standard MIB to
add device-specific management objects. MIB definitions have standard syntax and
encodingfor example, Abstract Syntax Notation (ASN.1) and Basic Encoding Rules
(BER)which, essentially, allow interoperability.
See also: NMS.
EMPS
Element Management Provisioning System (EMPS)
Enabled Default
EnabledDefault is the date or time when the EnabledState of the element last changed.
If the state of the element has not changed and this property is populated, then it must be
set to a 0 interval value.
If a state change was requested, but rejected or not yet processed, the property must not
be updated.
Enabled State
EnabledState is an integer enumeration that indicates the enabled and disabled states of
an element and can also indicate the transitions between these states.
For example, shutting down (value=4) and starting (value=10) are transient states
between enabled and disabled.
Enabled - element is or could be executing commands, will process any queued
commands, and queues new requests.
Disabled (3) - element will not execute commands and will drop any new requests.
Shutting Down (4) - element is in the process of going to a Disabled state.
Not Applicable (5) - element does not support being enabled or disabled.
Enabled but Offline (6) indicates that the element might be completing commands, and
will drop any new requests.
Test (7) - element is in a test state.
Deferred (8) i- element might be completing commands, but will queue any new requests.
Quiesce (9) - element is enabled but in a " "restricted mode.
Starting (10) - element is in the process of going to an Enabled state. New requests are
queued.
Enterprise ATM
Switch
Enterprise ATM switches are sophisticated multiservice devices that are designed to form
the core backbones of large, enterprise networks. They are intended to complement the
role played by todays high-end multiprotocol routers. Enterprise ATMswitches, much as
campus ATM switches, are used to interconnect workgroup ATM switches and other ATM-
connected devices, such as LAN switches.
Enterprise-class switches, however, can act not only as ATM backbones but can serve as
the single point of integration for all of the disparate services and technology found in
enterprise backbones.
Ethernet
Ethernet is a local-area network (LAN) architecture that uses a bus or star topology and
supports data transfer rates of 10 Mbps.
The Ethernet specification served as the basis for the IEEE 802.3 standard, which
specifies the physical and lower software layers. Ethernet uses the CSMA/CD access
method to handle simultaneous demands. It is one of the most widely implemented LAN
standards.
Ethernet (Fast)
Fast Ethernet or 100BASE-T provides transmission speeds up to 100 megabits per
second and is typically used for LAN backbone systems, supporting workstations with
10BASE-T cards.
Ethernet (Gigabit)
Gigabit Ethernet provides backbone support at 1000 megabits per second (1 gigabit or 1
billion).
Ethernet, XG
Ethernet XG provides 10Gb Ethernet Layer 2 switching and ultra-low latency.
Exploit
An Exploit is a program or technique that takes advantage of a software vulnerability.
The program can be used for breaking security, or otherwise attacking a host over the
network.
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.

FarmProfile
See Profile, Load Balancing.
FCAPS
FCAPS Fault, Configuration, Accounting, Performance and Security Management
Fault management - the goal of fault management is to recognize, isolate, correct and log
faults that occur in the network.
Configuration management - the goals of configuration management are to gather and
store configurations from network devices, to track changes made to the configuration and
to configure circuits or paths through non-switched networks. As networks increase in size,
an important task is automated configuration.
Accounting management - the goal of accounting (billing) management is to gather
usage statistics for users by which users can be billed and usage quotas enforced.
Examples are disk usage, link utilization and CPU time. For non-billed networks,
administration replaces accounting to establish users, passwords, and permissions,
and to administer software backup and synchronization.
Performance management - performance management addresses the throughput,
percentage utilization, error rates and response times areas of a network. Trends indicate
capacity or reliability issues before they affect service.
Security management - security management is the process of controlling access to
assets in the network, using authentication and encryption.
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
.
FireProof
Radware's FireProof provides load balancing and fault tolerance between all installed
firewall units. In combination with the SynApps Architecture, FireProof also provides the
following solutions:
Health monitoring
Traffic re-direction
Bandwidth management
Application security
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.
FreeMarker
FreeMarker is a "template engine"; a generic tool routine to generate text output (anything
from HTML to autogenerated source code) based on templates.
It is a J ava package, a class library for J ava programmers, and not an application for end-
users in itself, but something that programmers can embed into their products.

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
.
GBIC
GigaBit Interface Converter (GBIC) is a transceiver that converts serial electric signals to
serial optical signals and vice versa. In networking, a GBIC is used to interface a fiber optic
system with an Ethernet system, such as Fibre Channel and Gigabit Ethernet.
A GBIC allows designers to design one type of device that can be adapted for either
optical or copper applications. GBICs also are hot-swappable.
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.

GMPLS
Generalized Multi-Protocol Label Switching (GMPLS) is also referred to as Multi-Protocol
Lambda Switching.
GMPLS supports not only devices that perform packet switching, but also those that
perform switching in the time, wavelength, and space domains. The development of
GMPLS requires modifications to current signaling and routing protocols. It has also
triggered the development of new protocols such as the Link Management Protocol
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 non-mandatory).
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.
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.
GVP
Genesys Voice Platform (GVP)
Half-duplex
Half-fuplex is the transmission of data in just one direction at a time.
For example, a walkie-talkie is a half-duplex device because only one party can talk at a
time.On the other hand, a telephone is a full-duplex device because both parties can talk
simultaneously.
In half-duplex mode, each character transmitted is immediately displayed on your screen.

Handshake
A Handshake is an exchange of signals between computers or between a computer and a
peripheral to establish communication.
During the handshake, the two devices identify each other and then determine which
protocols will be used to transfer data.
Handshake
Protocol
A Handshake Protocol enables the encryption of every transaction between the client
browser and the server, facilitating the sending of sensitive information.
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 will be 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 on which 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. Basic 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 back-end database failure.

Heuristic Analysis
Heuristic Analysis is behavior-based analysis, targeted to provide a filter blocking the
abnormal phenomena.
Heuristic Analysis is the ability of a virus scanner to identify a potential virus by analysing
the behavior of the program, rather than looking for a known virus signature.
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.
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.
Hypervisor
A Hypervisor (aka virtual machine monitor) is a program that allows multiple operating
systems (either different operating systems or multiple instances of the same operating
system), to share a single hardware processor.
A hypervisor must be designed for a particular processor architecture. Each operating
system appears to have the processor, memory, and other resources all to itself. However,
the hypervisor actually controls the real processor and its resources, allocating what is
needed to each operating system in turn.. Hypervisors are currently classified in two types:
Type 1 is software that runs directly on a given hardware platform (as an operating system
control program).
Type 2 is software that runs within an operating system environment.
IAS
(Radware)
IntelligentApplication Switching
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.
IDS
Radwares Intrusion Detection System (IDS) applies the latest security or attack expertise
to filter out potentially destructive/malicious events from a much larger amount of
legitimate activity.
There are two system-monitoring approaches:
NIDS Network-based IDS monitors all network traffic passing on the segment where
the agent is installed, acting upon suspicious anomalies or signature-based activity.
HIDS Host-based IDS is confined to the local host and monitor activity in detail, such
as, command execution, file access, or system calls.
Organizations generally choose a combination of these approaches, based on known
vulnerabilities. For further information, see (free registration required).

Inheritance
Inheritance is a concept used in object oriented modeling where object inheritance is a
method of defining objects that inherit much of their state/attributes from other objects (aka
parent-child relationship).
Its key objective is to reduce the redundancy in object models by arranging classes with
similar attributes and operations in a hierarchy.
Inheritance is a type of relationship among classes, wherein one class shares the structure
or behaviour defined in one (single inheritance) or more (multiple inheritance) other
classes. Inheritance defines a "kind of" hierarchy among classes in which a sub class
inherits from one or more super-classes; a sub-class typically augments or redefines the
existing structure and behaviour of its super-classes.
IIS
Internet Information Services (IIS)
IMS
IP Multimedia Subsystem
In-band
Monitoring
In-band Monitoring is a health check by the Load Balancer for TCP response time for client
TCP SYN requests using the natural traffic flow between the client and the server, using
little overhead.
In contrast, Out-of-band Monitoring refers to a health check generated specifically by the
Load Balancer to the server.
Insite Client
Application
Insite Client Application is the main Insite client application. A full, Eclipse-based thick
client, used for configuration as well as for report viewing.

Insite Web
Application
Insite Web Application is a web interface designed for data reporting that enables the
viewer to display data reports without installing a full Insite client.
InFlight
(Radware)
Radwares Inflight solution delivers real-time business events at wire speed to backend
analytic engines. Inflight performs the following:
Passive identity-based monitoring of critical online application transaction activity to
generate real-time events for business applications.
Passive capture of raw user transactional data, transforming it into useable events, and
feeding it to analytic and operational decision support engines.
Delivery of detailed session and login information enabling activity to be attributed to
actual users and immediate action to be taken.
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.
To exclude a Management Port from triggering interface grouping, set it either as Exclude
in the Selective Interface Grouping table or configure it as Dedicated Management Port.
Backup Interface Grouping - when enabled, causes the Backup to take over only when
all interfaces on the main device that are participating in redundancy are down. It will
release those interfaces only when all the main's interfaces are up.
Interface,
Hardware
(Physical)
A Hardware Interface is an architecture designed to interconnect 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 as well as 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 actual 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.
Interface, IP
Physical
A Physical IP Address is an IP address assigned to an AppDirector interface.
This address belongs to AppDirector and is used for SNMP management and/or routing
purposes.
Intrusion
Intrusion is an attempted or successful access to system resources in any unauthorized
manner.
Intrusion
Prevention
Intrusion Prevention is a security service that scans, detects and prevents real-time
attempts aimed at compromising system security.
Intrusion
Prevention,
(Signature-Based)
Signature-Based Intrusion Prevention, a function of AppXcel WAF, provides full Snort-
based signature detection to protect applications from worms (and other attacks) that
target known vulnerabilities in commercial infrastructure software (Apache, IIS etc.).
The Snort database is updated regularly via the Internet with new signatures (hosted on
www.radware.com) and content, such as affected systems, risk, accuracy, frequency, and
background information.
In DefensePro, Signature Protection profiles are based on rules that define a query on the
Signatures database. A profile can use multiple rules and each rule can contain one or
more entries from the various attribute categories.
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.
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.
Typically, 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.
IPC
InterProcess Communications (IPC) are mechanisms that allow communication between
processes.
With IPC, it is possible to create large, complex systems with complex functions that are
streamlined and uncomplicated in design.
IPC Socket
InterProcess Communications (IPC) sockets provide point-to-point, two-way
communication between two processes.
Sockets are very versatile and basic component of interprocess and intersystem
communication. A socket is an endpoint of communication to which a name can be bound.
It has a type and one or more associated processes.
IP Filtering
IP Filtering provides the ability to filter traffic based on:
Access Control Lists (ACLs)
Bogus IP ranges (Bogon filtering)
Deep patcket inspection pattern matching
In some cases, thresholds or rate limiting of IP addresses or ranges of IP addresses may
be employed.
IP Forwarding
Table
The IP Forwarding Table contains the destination MAC address and port for each
destination IP address.
A MAC address is searched in this table before it is searched in the ARP table.
IP Routing
IP Routing is the forwarding of IP packets to their destination using a Routing Table.
IPCS
Internet Protocol Communication Server (IPCS)
IPCM
Internet Protocol Call Manager (IPCM)
IPS
An Intrusion Prevention System (IPS) is a computer security mechanism that monitors
network and/or system activities for malicious or unwanted behavior and can react, in real-
time, to block or prevent those activities.
Network-based IPS, for example, will operate in-line to monitor all network traffic for
malicious code or attacks. When an attack is detected, it can drop the offending packets
while still allowing all other traffic to pass. Intrusion prevention technology is considered by
some to be an extension of intrusion detection (IDS) technology.
Intrusion prevention systems are an improvement upon traditional firewall technologies.
IPS make access control decisions based on application content, rather than IP address or
ports as traditional firewalls had done.
IPv6
IPv6 is the current version of the IP protocol that features a 128-bit addressing scheme, as
opposed to the 32-bit addressing scheme of IPv4, supporting a much higher number of
addresses.
Other improvements over IPv4, include support for multicast and anycast addressing.
IVR
Interactive Voice Response (IVR) is a telephony technology in which a touch-tone
telephone is used to interact with a database to acquire information from or enter data into
the database.

JSP
J ava Server Page (J SP) is a technology for controlling the content or appearance of Web
pages through the use of servlets, small programs specified in the Web page and run on
the Web server to modify the Web page before it is sent to the user who requested it.

LAN
A Local Area Network (LAN) can generally be defined as a broadcast domain.
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.

Latency (Network)
Latency in a network is a synonym for delay, an expression of how much time it takes for a
packet of data to get from one designated point to another.
The contributors to network latency include:
Propagation the time it takes for a packet to travel between one place and another at the
speed of light.
Transmission depending on the medium, whether optical fiber, wireless, or some other.
The size of the packet also introduces delay in a round trip.
Router and other processing each gateway node takes time to examine and possibly
change the header in a packet (for example, changing the hop count in the time-to-live
field).
Other computer and storage delays at each end of a journey, a packet may be subject to
storage and hard disk access delays at intermediate devices such as switches and
bridges.
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 basically means switching packets based on Layer 4-7
protocol header information in the packets.
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.
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:
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 as
well as any Layer 7 data that can be identified by a certain string or regular expression.
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.
License, BWM&
IPS
The BWM & IPS protection License offers Bandwidth Management, Traffic Shaping and
complete IPS protection.
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.
LinkProof
LinkProof is a Radware product designed to provide multi-WAN switching (multi-homing)
for consistent application uptime, and to address latency and bandwidth constraints.
LinkProof provides the following:
Addresses application performance degradation, not only downtime, by measuring
response times and directing traffic to the fastest responding link.
Using Proximity (patented) probes, measures hop-count and latency per unique
destination, redirecting traffic to the optimal ISP. Does not require ISP cooperation.
Detection of link-failures and automatic, transparent, failover to other links.
Use of varied link types, such as Frame-relay T1 combined with ADSL.
Simultaneous utilization of all available links and bandwidth (aka load-balancing).
Integrated VPN termination
Support for BGP environments
Denial of Service (DoS) and high-volume intrusion (worm) protection
High Availability using a redundant WAN architecture
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 in order 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
All of the above methods are able to divert traffic away from failed servers.
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 typically 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.
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 designed 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
typically are measured in connections per second, while routers and switches are typically
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).

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.
Load Sharing,
Multicast
Multicast Load Sharing in a cluster is where every member of the cluster receives all of the
packets sent to the cluster IP address. A router or Layer 3 switch forwards packets to all of
the cluster members using multicast.

Load Sharing,
Unicast
Unicast Load Sharing is where one machine receives all traffic from a router with a unicast
configuration and redistributes the packets to the other machines in the cluster.

Local Data
Collection
Database
A Local Data Collection Database is a database which is installed with the Collector on the
same machine. The Collector and the Local Data Collection Database may be installed in
a remote location or in same location as the main Insite server.
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 Data-Link 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.

ManagePro
(Radware)
Insite ManagePro (Radware) is an appliance-based central management and monitoring
system for the APSolute family of application delivery, access and security solutions.
It provides health-monitoring, real-time status, performance and security for enterprise-
wide application delivery infrastructures.
ManagePro provides the following:
Centralized Management - centralized, client-server based approach to configure and
manage multiple Radware devices on the enterprise network.
Role-Based Access Control - compartmentalization of administration rights between
various groups or individuals.
Centralized Fault Management - a consolidated view of all application delivery
infrastructure status and alerts.
ManagePro uses Traffic flow protocols: HTTPS, SNMPv1/3. It stores database
information, macros, statistics, device configuration files, etc. It allows scheduled backups
to external FTP servers and enables complete user management with session and locking
multi-user control, allowing administrators to disconnect users from ManagePro.

MDA
Model Driven Architecture (MDA) is a way of writing specifications based on a platform-
independent model. A complete MDA specification consists of a definitive platform-
independent base UML model, plus one or more platform-specific models and interface
definition sets, each describing how the base model is implemented on a different
middleware platform.
The MDA focuses primarily on the functionality and behavior of a distributed application or
system, not the technology in which it will be implemented. It divorces implementation
details from business functions without repeating the process of modeling an application or
system functionality and behavior each time a new technology (e.g., XML/SOAP) comes
along.
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.
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
in conjunction 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, designed to
check the status of a node or service on an ongoing basis, at a set interval.
MSS
Managed Security Services (MSS) - Managed network-based, behavioral IPS/DoS
security and content inspection for value-added managed carrier services across
enterprise, business and residential customers.
MSSP =Managed Security Services Provider
MTU
Maximum Transmission Unit (MTU) is the largest packet size that can be supported by a
particular network implementation.
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 generally separated by time, frequency, or space.

NAT
Network Address Translation (NAT) is the translation of an IP address used within one
network (typically 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 server-initiated 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
Dynamic NAT - maps an unregistered IP address to a registered IP address from a group
of registered IP addresses.
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 as well as 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 one-to-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 will be selected
each time 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.
Network (Scale-
free)
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, thus 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. In Radware products, NHRs are used as farm servers and can be configured and
managed through APSolute Insite.
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 basically 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).
Object
In Insite 5.0, an Object can a configuration file, a farm profile, a network, a template or any
other reusable object.
Object, Inherited
An Inherited Object acquires its values from its parent object.
For example, Object B inherits parameter values from Object A. Changing a value of a
parameter in Object A changes the value in object B.
Offline
Configuration
Insite 5.0 allows configuration of devices when offline.
The configuration file is stored in the database. Insite 5.0 acts as an intermediary between
the user and the devices. The user defines his/her requirements and Insite 5.0 applies
them to the device. After configuration, devices can be attached and configuration
implemented.
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.
OSS
Operations Support Systems (aka Operational Support Systems) (OSS) are computer
systems used by telecommunications service providers to support processes such as
maintaining network inventory, provisioning services, configuring network components,
and managing faults.
The complementary term Business Support Systems or BSS is a newer term and typically
refers to business systems dealing with customers, supporting processes such as taking
orders, processing bills, and collecting payments. The two systems together are often
abbreviated BSS/OSS or simply B/OSS.
OSS-BSS
Optimization
OSS-BSS Optimization - Fully integrated high-availability carrier AAA suite for broadband
'on-demand' AAA services including DHCP, DNS, RADIUS, LDAP and IMS-HSS Diameter
to ensure service continuity, scalability and operational .
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. Typically, 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.
Para-virtualization
Para-virtualization is an enhancement of virtualization technology in which a guest OS is
recompiled prior to installation inside a virtual machine, allowing for an interface to the
virtual machine that can differ from that of the underlying hardware. This capacity
minimizes overhead and optimizes system performance by supporting the use of virtual
machines that would be underutilized in conventional or full virtualization.
The main limitation of para-virtualization is the fact that the guest OS must be tailored
specifically to run on top of the Virtual Machine Monitor (VMM), the host program that
allows a single computer to support multiple, identical execution environments. However,
para-virtualization eliminates the need for the virtual machine to trap privileged
instructions. Trapping, a means of handling unexpected or unallowable conditions, can be
time-consuming and can adversely impact performance in systems that employ full
virtualization.
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.
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 in order 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
(typically 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.
Pipelining
Pipelining is the continuous and somewhat overlapped movement of instructions to the
CPU or in the arithmetic steps taken by the processor to perform an instruction.
Without a pipeline, a computer processor gets the first instruction from memory, performs
the operation, and then gets the next instruction from memory. While fetching the
instruction, the arithmetic part of the processor is idle.
With pipelining, the next instructions are fetched and held in a buffer while the processor is
performing arithmetic operations. When the processor is finished, the next instructions are
ready. This staging of instruction fetching is continuous, and the result is an increase in the
number of instructions that can be performed during a given time period.
Similarly, when information is required from web servers, the IPCS opens a TCP
connection to a web server and leaves it open, reducing delays in transmission. Additional
TCP connections are opened as dictated by load a new connection is opened once all
current connections are full. For continuous and uniform traffic, this improves efficiency.
However, it introduces a level of complexity in the area of load balancing.
Pareto Principle
The Pareto principle (aka the 80-20 rule) states that, for many events, 80% of the results
comes from 20% of the causes.
PAT
Port Address Translation (PAT) aka Overloading - is a form of dynamic NAT that maps
multiple unregistered IP addresses to a single registered IP address by using different
ports.
PIM
A Platform-Independent Model (PIM) is a model of a software or business system that is
independent of the specific technological platform used to implement it.
Port Group,
Application
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.
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 in order 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 the load-balancing parameters for a server farm.
Each server farm can have only one profile, although a Load Balancing profile can be
applied to other farms
Protocol
Discovery
Protocol Discovery provides a view of the protocols running on the network.
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 sub-networks 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 email.
Proximity
Global AppDirectors calculate round-trip latency as well as router hop-count from each
remote site to incoming request in order 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 appears 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 and 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
AD partners in a Proximity Table.
PSM
A Platform-Specific Model is a model of a software or business system that is linked to a
specific technological platform (e.g. a specific programming language, operating system or
database).
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.
RADIUS Attribute
Entries
The RADIUS Attribute Entries table stores the RADIUS Attribute and server, to ensure
persistency of traffic sessions.
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 (see Redirection Methods). 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.
For more information, see A Superior Global Redirection Solution.
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
actually 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 typically 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.
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 (sometimes 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).
Requested State
RequestedState is an integer enumeration that indicates the last requested or desired
state for the element. The actual state of the element is represented by EnabledState.
This property is provided to compare the last requested and current enabled or disabled
states. When EnabledState is set to 5 (Not Applicable), then this property has no meaning.
By default, the RequestedState of the element is 5 (No Change).
Offline (6) indicates that the element has been requested to transition to the Enabled but
Offline EnabledState.
Two values in RequestedState build on the statuses of EnabledState.
Reboot (10) performs a Shut Down (orderly transition to Disabled state) and moves to
EnabledState.
Reset (11) indicates that the element is first Disabled (immediate disabling of the element)
and then Enabled.
A particular instance of EnabledLogicalElement might not support
RequestedStateChange. If this occurs, the value 12 (Not Applicable) is used.
RBAC
Role Based Access Control (RBAC) is a method of regulating access to computer or
network resources based on the roles of individual users within an enterprise. Access is
the ability of an individual user to perform a specific task, such as view, create, or modify a
file. Roles are defined according to job competency, authority, and responsibility within the
enterprise.
When properly implemented, RBAC enables users to carry out a wide range of authorized
tasks by dynamically regulating their actions according to flexible functions, relationships,
and constraints. With conventional methods of access control, the granting or revoking of
user access is on a fixed, object-by-object basis. In RBAC, roles can be easily created,
changed, or discontinued as the needs of the enterprise evolve, without having to
individually update the privileges for every user.
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. Use Denicomp's Winsock REXECD/95 or Winsock REXECD/NT
software if you want to rexec into a Windows system.
Thanks to http://www.denicomp.com/readmore.htm
RIP
Routing Information Protocol (RIP) is a widely-used Interior Gateway Protocol (IGP)
routing protocols for managing router information within a self-contained 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 and so on 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.
RMI
The J ava Remote Method Invocation API, or J ava RMI, is a J ava application programming
interface for performing the object equivalent of remote procedure calls.
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
In the context of routers, a Neighbor means 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 ->L4 Classification, farm and server selection, L3 & L7 persistency
In-depth packet inspection ->L7 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, ...
RS-232
RS-232 (Recommended Standard 232) is a standard protocol for serial binary data signals
connecting between a DTE (Data terminal equipment) and a DCE (Data Circuit-
terminating Equipment).
It is commonly used in computer serial ports.
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. Use
Denicomp's Winsock RSHD/95 or Winsock RSHD/NT software if you want to rsh to a
Windows system.
The rsh command does not require you to enter a password for the other system. Trust is
established by defining host equivalency.
Thanks to http://www.denicomp.com/readmore.htm
RSTP
Rapid Spanning Tree Protocol is an evolution of the 802.1D standard; it speeds up the
convergence time of a bridged network.
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 on which 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.
SAP
Service Access Points (SAP), an 802 standard that allows assigning numbers to protocols
differently for each machine.
SAP fields are 8-bits long, with one bit reserved for global/local and one bit reserved for
group/individual. This makes it easier to identify a packet.
Related terms: Source Service Access Point (SSAP) and Destination Service Access
Point (DSAP).
Scalability
Scalability is how well a hardware or software system (actually any item) can adapt to
increased demands, or a changed environment.
For example, a scalable network system would be one that can start with just a few nodes
but can easily expand to thousands of nodes.
SecureFlow
Radwares SecureFlow enables powerful rule-based flow control coordination of security
operations across multiple devices, letting you custom fit security operations.
SecureFlow:
Forwards traffic to security devices
Selects the best server for the service.
Ensures persistency.
SecureFlow combines the power of Multi-Gigabit Application Switching hardware with
APSolute OS Application-Smart Networking
Security Policy
A Radware DefensePro Security Policy is a policy that can be adjusted to suit security
needs of different network segments or even a single server.
Security Policies are configured and applied to network segments and servers, using the
Connect&Protect table, to define the action in case of an attack:
Network protection policies
Server protection policies
Security Update
Service
Radwares Security Update Service delivers signature updates to protect against the latest
network and application security threats (such as worms, Trojans, BOTs and application
vulnerabilities).
The Security Update Service, available on the entire Radware suite of products, consists
of the following key service elements:
24/7 Security Operations Center (SOC) scanning for continuous threat monitoring,
detection, risk assessment and filter creation for threat mitigation
Emergency filters for high impact security events
Weekly updates comprising scheduled periodic updates to signature files
Custom filters for environment specific threats and newly reported attacks sent to the SOC
Segment /
Segmentation
A Segment is a logical network entity associated either to physical ports (VLANs, Trunks,
...) or to VLAN Tags.
Segmentation is the dividing up of your network into logical segments, where a single
AppDirector load-balances traffic so that all segments can be inspected by a single
firewall.
Server Farms can be associated with segments to define the logical location of each farm.
AppDirector/WSD allows traffic to a farm only when the traffic arrives from the same
Segment where the farm resides.
Segmentation is useful when it is necessary to virtualize a single AppDirector/WSD device
to load-balance multiple farms on different segments of the network.
Server
In Insite 5.0, a server is a logical server as it exists in AppDirector and WSD devices,
including redundancy cluster configurations. A server supports all logical server
parameters and can belong to multiple Service Server Groups.
Server, Reporting
A Reporting Server is the component responsible for running the required services to
display reports to the end user. It may contain a web server and procide services for both
Eclipse and web interfaces.
Server Group
A Server Group is a set of configured server hosts used for a particular service.
Server Protection
Profile
Server Protection Profiles are designed to defend from network and application attacks
targeting network servers or services, such as:
SYN Flood protection using SYN Cookies
Connection limit
Server Cracking
HTTP Page floods.
Session
A logical connection created between two hosts to exchange data, typically 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.
SBC
A Session Border Controller (SBC) is a device used in VoIP networks to control the
signaling and also the media streams involved in setting up, conducting, and tearing down
calls.
In VoIP, Session is a call, consisting of call signaling streams that control the call, call
media streams (audio, video, or data) along with information on data flow.
Border refers to a point of demarcation between one part of a network and another. For
example, at the edge of a corporate network, a firewall demarcs the local network (inside
the corporation) from the rest of the Internet (outside the corporation). Or, in a large
corporation where different departments have security needs for each location and
perhaps for each kind of data.
Controller refers to the influence that Session Border Controllers have on the data streams
that comprise Sessions, as they traverse borders between one part of a network and
another.
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.
Session ID Table
The Session ID table contains the Session IDs collected from server replies when Session
ID Persistency is active.
SFP
The Small Form-Factor Pluggable (SFP) is a compact optical transceiver used in optical
communications for both telecommunication and data communications applications. It
interfaces a network device mother board (for a switch, router or similar device) to a fiber
optic or unshielded twisted pair networking cable. It is a popular industry format supported
by several fiber optic component vendors.
SFP transceivers are available with a variety of different transmitter and receiver types,
allowing users to select the appropriate transceiver for each link to provide the required
optical reach over the available optical fiber type (e.g. multi-mode fiber or single-mode
fiber). Optical SFP modules are commonly available in four different categories:
850 nm (SX)
310 nm (LX)
1550 nm (ZX)
DWDM.
SFP transceivers are also available with a copper cable interface, allowing a host device
designed primarily for optical fiber communications to also communicate over unshielded
twisted pair networking cable. There are also CWDM and single-optic (1310/1490 nm
upstream/downstream) SFPs.
Signature
A signature is a pattern-based analysis, used to search for packets generated by known
attack tools.
Signature
Dictionary
A Signature Dictionary is a collection of signatures generated by applying a filter on the
AppXcel WAF signature database.
For example, with AppXcel WAF you can easily define a filter of all high-risk, highly
accurate, IIS 6 signatures and create a dictionary by following a simple wizard. You can
define as many dictionaries as you like. When a new signature is added to the AppXcel
WAF signature database, it is automatically added to all relevant dictionaries.
SIP
The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for
creating, modifying, and terminating sessions with one or more participants. It can be used
to create two-party , multiparty, or multicast session that include Internet telephone calls,
multimedia distribution, and multimedia conferences.
SIP provides two main functions: find potential call participants, and contact them as they
move from one location to another. SIP users receive a globally reachable address, using
a format similar to email addresses, for example: alice@mycompany.com.
There are two basic components within SIP:
SIP User Agent the end user device for the call
SIP Network Server various network devices that constitute the SIP network
infrastructure and handle the signaling associated with multiple calls There are various
types of logical SIP Network Servers, such as, SIP Proxy Server, SIP Registrar, SIP
Redirect Server:
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.
This redirection method is used to redirect SIP session invitations to external domains,
such as a distributed or remote server, using the following steps:
The client sends the SIP request to an AppDirectors VIP address.
AppDirector passes on the request to the best server for the task
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.
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. SIP redirection by name is configured using the Redirect To URL parameter
for the server.
SLA
A Service Level Agreement (SLA) is a formally negotiated agreement between two parties.
It is a contract that exists between customers and their service provider, or between
service providers.
An SLA records the common understanding about services, priorities, responsibilities,
guarantee, and such. For example, it may specify the levels of availability, serviceability,
performance, operation, or other attributes of the service like billing and even penalties in
the case of violation of the SLA.
An SLA is generally business oriented rather than technical. Its technical specifications
are commonly described through either a service level specification (SLS) or a service
level objective (SLO).
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 (Insite) 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. Typically, 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
A sockect is a combination of IP address and port number.
SPP
Sequenced Packet Protocol (SPP) was an acknowledged transport protocol, analogous to
TCP; one chief technical difference is that the sequence numbers count the packets, and
not the bytes as in TCP and PUPs BSP; it was the direct antecedent to Novells IPX/SPX.
SSl Acceleration /
Offloading
With SSLOffloading, the cryptography is typically done with the load balancers main
processor. SSL Offloading is typically 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 will be able to 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, as well as 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.
Spanning Tree
Protocol
In a network, the Spanning-Tree Protocol uses the spanning-tree algorithm to construct
topologies that do not contain any loops.
Without Spanning-Tree, it is possible for packets to be switched back to the original LAN
creating a loop. Because the spanning-tree algorithm places certain connections in
blocking mode, only a subset of the network topology is used for forwarding data.
In contrast, routers provide freedom from loops and make use of optimal paths.
Spoof
A Spoof, in internet security terms, is when one system entity poses as or assumes the
identity of another entity.
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.
In order 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.
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.
STP
Spanning Tree Protocol (STP) is a link management protocol that provides path
redundancy while preventing undesirable loops in the network.
For an Ethernet network to function properly, only one active path can exist between two
stations. Multiple active paths between stations cause loops in the network, which have
the potential for duplication of messages. When loops occur, some switches see stations
appear on both sides of the switch. This condition confuses the forwarding algorithm and
allows duplicate frames to be forwarded.
To provide path redundancy, Spanning-Tree Protocol defines a tree that spans all
switches in an extended network. Spanning-Tree Protocol forces certain redundant data
paths into a standby (blocked) state. If one network segment in the Spanning-Tree
Protocol becomes unreachable, or if Spanning-Tree Protocol costs change, the spanning-
tree algorithm reconfigures the spanning-tree topology and reestablishes the link by
activating the standby path.
Switch, LAN
A LAN Switch is a network device that typically consists of multiple ports that connect LAN
segments (Ethernet and Token Ring) and a high-speed port (such as 100-Mbps 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 generally 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.
SynApps
Architecture
Radwares SynApps architecture is made up of four modules, each with its own rich set of
features:
Traffic Redirection
Health Monitoring
Bandwidth Management
Application Security.
SYN Attack / Flood
A SYN attack/flood is a type of DoS (Denial of Service) attack. SYN flood attacks are
performed by sending a SYN packet without completing the TCP three-way handshake,
referred as single packet attack. Alternatively, the TCP three-way handshake can be
completed, but no data packets are sent afterwards. Such attacks are known as
connection flood attacks.
A SYN packet notifies a server of a new connection. The server then allocates some
memory in order to handle the incoming connection, sends back an acknowledgement,
then waits for the client to complete the connection and start sending data. By spoofing
large numbers of SYN requests, an attacker can fill up memory on the server, which waits
for more data that never arrives. Once memory has filled up, the server is unable to accept
connections from legitimate clients. This effectively disables the server. Key point: SYN
floods exploit a flaw in the core of the TCP/IP technology itself. There is no complete
defense against this attack. There are, however, partial defenses. Servers can be
configured to reserve more memory and decrease the amount of time they wait for
connections to complete.
Likewise, routers and firewalls can filter out some of the spoofed SYN packets. Finally,
there are techniques (such as SYN cookies) that can play tricks with the protocol in order
to help distinguish good SYNs from bad ones.
SYN-ACK
Reflection Attacks
Prevention
SYN-ACK Reflection Attacks Prevention is intended to prevent reflection of SYN attacks
and reduce SYN-ACK packet storms that are created as a response to DoS attacks.
When a device is under SYN attack, it sends a SYN-ACK packet with an embedded
Cookie, in order to prompt the client to continue the session.
SYN Cookies
SYN cookies are particular choices of initial TCP sequence numbers by TCP servers. The
difference between the server's initial sequence number and the client's initial sequence
number is:
top 5 bits: t mod 32, where t is a 32-bit time counter that increases every 64 seconds;
next 3 bits: an encoding of an MSS selected by the server in response to the client's MSS;
bottom 24 bits: a server-selected secret function of the client IP address and port number,
the server IP address and port number, and t.
This choice of sequence number complies with the basic TCP requirement that sequence
numbers increase slowly; the server's initial sequence number increases slightly faster
than the client's initial sequence number.
A server that uses SYN cookies does not have to drop connections when its SYN queue
fills up. Instead it sends back a SYN+ACK, exactly as if the SYN queue had been larger.
(Exceptions: the server must reject TCP options such as large windows, and it must use
one of the eight MSS values that it can encode.) When the server receives an ACK, it
checks that the secret function works for a recent value of t, and then rebuilds the SYN
queue entry from the encoded MSS.
A SYN flood is simply a series of SYN packets from forged IP addresses. The IP
addresses are chosen randomly and don't provide any hint of where the attacker is. The
SYN flood keeps the server's SYN queue full. Normally this would force the server to drop
connections. A server that uses SYN cookies, however, will continue operating normally.
The biggest effect of the SYN flood is to disable large windows.
Extracted from: D.J .Bernstein http://cr.yp.to/syncookies.html
System
A System is a repository of all the Radware devices managed by the administrators.
TCP Splitting
TCP Splitting is the ability to maintain open concurrent connections opposite all servers
providing Diameter or LDAP services, when only a single connection was opened by the
client.
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
Traffic is data transmitted over a network. Traffic is a very general term and typically 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.
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.
Threat
A Threat, in Internet security terms, is a person, thing, event, or idea, that poses a danger
to an asset.
A fundamental threat can be any of the following: information leakage,Denial of Service,
integrity violation, and illegitimate use.
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.
Trapping
Trapping is a means of handling unexpected or unallowable conditions.
Triangulation,
Global
(Radware)
Global Triangulation is Radwares patented redirection method which is used with multiple
AppDirectors to redirect traffic in a Global Application Redirection tier.
In Global Triangulation, a data triangle is formed where the client is the first vertex, the
redirecting AppDirector (Global) is the second vertex and the third vertex is a local or
global AppDirector that actually handles the client request. Clients approach one
AppDirector, but are transparently redirected to another remote AppDirector unit in a
different site. The remote AppDirector responds with the VIP of the original AppDirector
that the client initially contacted. Radwares Global Triangulation can be used for all
applications, web based and legacy, and is done transparently to the client, overcoming all
caching issues at the client side. Triangulation can also be used to globalize legacy
applications that are destined at specific IP addresses and not use DNS mechanisms.
As most of the application traffic goes from the server to the client, selecting a server with
an optimal path for the client results in accelerating response time and enhancing
application client experiences.
Triangulation,
Local
Local Triangulation enables a server to send responses directly to the client, thus reducing
the number of hops and improving response time.
Local Triangulation also reduces traffic passing through AppDirector, since outbound
traffic typically represents the bulk of exchanges between clients and servers.
When a new request arrives, AppDirector selects the best server. The response is sent
directly from the server to the client bypassing the AppDirector. The client can be located
on the same network as AppDirector and the server, or the client can be located behind
the router.
Trojan Horse
A Trojan Horse (Internet security) is a computer program that appears benign, but is
actually designed to harm or compromise the system.
It is usually designed to provide unrestricted access into internal systems, bypassing
security monitoring and auditing policies.
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 typically 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 pre-assigned, 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)
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 actually 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.
User
A User is a person logging onto Insite, whether as an administrator or as a non-
administrator, and whose permissions are dictated by User Management.
VIP Advertising
VIP Advertising via Dynamic Routing enables you to achieve redundancy by using a single
AppDirector on each site, or by using a single AppDirector and a remote backup server
that participates in the RIP or OSPF environment.
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.
Virtualization
Virtualization is a computing term that refers to the abstraction of computer resources or a
technique for hiding the physical aspects of computing resources from systems,
applications, or end users interactions.
This means that a single physical resource (such as a server or storage device) can
function as multiple logical resources, or that multiple physical resources can function as a
single logical entity. Deploying virtual infrastructure is transparent from a user experience
perspective. This provides IT managers the tools to manage resources cost-effectively
across the enterprise, enabling them to be more responsive to dynamic business and
corporate needs as well as better utilize physical infrastructure investments.
Virus
A Virus (Internet Security) is a malicious program code the intention of which is to damage
computer systems and to replicate itself to extend the possible damage.
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. In order to handle
both packets that need intelligent intervention and non-IP traffic, it is possible to 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, Switched
(Radware)
Switched VLAN provides wire-speed VLAN using the ASIC hardware switch fabric of
AppDirector. Multiple VLANs can run on the same physical port.
IEEE 802.1Q options are supported to add/remove/retain VLAN tags and can be used for
Layer 2 switching with servers, each with a dedicated VLAN tag, conditional upon the
existence of an ASIC on the device. This is not relevant to the following platforms:
ODS1(On-Demand Switch One)
AS1 (Application Switch One)
AS2.(Application Switch Two)
AppDirector devices support up to 64 regular or switched VLANs and up to 2048 VLAN
IDs. Depending on the protocol defined, frames are treated accordingly as follows:
Switched VLAN Protocol - At the VLAN port, frames are switched by Layer 2 information.
AppDirector does not intercept that traffic (no Layer 3/Layer 4 capabilities).
IP Protocol - At the VLAN port, frames are switched according to Layer 2 information,
except for those frames whose Layer 2 address is the same as the AppDirector port Layer
2 address.
Recommended: Whenever there is an ASIC, use Switched VLAN with IP Protocol,
otherwise use Regular VLAN.
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.
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 carrier-grade 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 in order to reduce the black hole period.
See Wikipedia.
VRRP
Virtual Router Redundancy Protocol (VRRP) is designed to eliminate 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 actual 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.
VxWorks
VxWorks is a Unix-like real-time operating system made and sold by Wind River Systems
of Alameda, California, USA. It is used in Radwares Application Switches 1-5, the
Compact Application Switch and the Security Platform.
Like most RTOSes, VxWorks includes a multitasking kernel with pre-emptive scheduling
and fast interrupt response, extensive inter-process communications and synchronization
facilities, and a file system.
Major distinguishing features of VxWorks include efficient POSIX-compliant memory
management, multiprocessor facilities, a shell for user interface, symbolic and source level
debugging capabilities, and performance monitoring.
Vulnerability
A Vulnerability (Internet Security) is a weakness in a machine, application or a system that
can be exploited by an attacker.
WAF
Web Application Firewall (WAF), integrated into Radwares AppXcel, is based on
Impervas SecureSphere and its Dynamic Profiling technology.
WAFs Dynamic Profiling technology continuously analyzes live Web and database
traffic to create a comprehensive model (profile) of the structure and dynamics of the
application and database. Valid application and database changes are automatically
recognized and incorporated into the profile over time.
WAFs Dynamic Profiling builds a model of legitimate application behavior by
automatically learning users normal traffic and updating their profiles without manual
intervention. By comparing profiled elements to live traffic, the WAF is able to detect
malicious activity and rule exceptions. Administrators can manually fine-tune profiles.
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.
Whitelist
A Whitelist is a list of accepted items or persons in a set. In Internet Security terms, it is a
list of e-mail addresses or domain names from which an e-mail blocking program will allow
messages to be received.
E-mail blocking programs, also called a spam filters, are intended to prevent most
unsolicited e-mail messages (spam) from being received into an email inbox.
WOC
Wireless and Optical Communications (WOC)
Worm
A Worm (Internet Security) is a type of computer virus that uses the Internet or local
networks to spread itself by sending copies of itself to other hosts.
wRED
Weighted RED. See RED.
WSD
Web Server Director (WSD) is a Radware device that ensures the full availability,
optimized operation and complete security of server farms.
WSD eliminates bottlenecks, failures and downtime from enterprise servers while
continuously protecting resources from security violations for fault tolerant operation of all
IP applications including web services, online databases and e-mail. By managing all
network traffic at Gigabit speeds, WSD attains the maximum utilization of servers across
local and global sites
Combining the power of Radware's Multi-Gigabit Layer 4-7 Application Switching
hardware platform with Radware's SynApps Application Aware service architecture
including health monitoring, load balancing, bandwidth management, intrusion prevention
and DoS protection, WSD ensure your IT infrastructure is dependable, effective and
scalable.
Appendix B Regular Expressions
This appendix provides an overview of the basic syntax of regular expressions used in SIP Director
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".
"^abc$": 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), 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]").
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:
"%[^a-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.
Appendix C 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.This chapter includes the following sections:
Introduction to Intelligent Application Switches, page 489
Introducing AppXcel, page 489
Introduction to Intelligent Application Switches
IMS Environment
The IP Multimedia Subsystem (IMS) is a standardized Next Generation Networking (NGN)
architecture for telecom operators that want to provide mobile and fixed multimedia services. It
uses a Voice-over-IP (VoIP) implementation based on a 3GPP standardized implementation of SIP,
and runs over the standard Internet Protocol (IP). Existing phone systems, both packet-switched
and circuit-switched) are supported. The aim of the IMS is not only to provide new services but all
the services, current and future, that the internet provides. In addition, users have to be able to
execute all their services when roaming and from their home networks. To achieve these goals, IMS
uses open standard IP protocols, defined by the IETF. A multimedia session between two IMS users,
between an IMS user and a user on the internet, and between two users on the internet is
established using exactly the same protocol. Moreover, the interfaces for service developers are also
based on IP protocols.
AppDirector provides high availability and enhanced performance for applications that enable IMS
services, such as provisioning, service creation and enabling for subscriber data, roaming, etc., and
for the application themselves (SIP).
The IMS environment requires special support to provide availability and performance for the
Diameter and LDAP protocols. In the IMS environment a client opens a connection to the Diameter
or LDAP server and exchanges stateless messages. The connection is open for long periods of time,
and each Diameter/LDAP client is a proxy for a large number of users. For this reason, to provide
high performance and availability for the Diameter and LDAP protocols, it is required for the front-
end acceleration solution to operate as a reverse proxy by opening simultaneous connections to all
servers providing the service for each connection opened by a client. This functionality is called TCP
splitting.
Introducing AppXcel
This section provides a general introduction to AppXcel and includes the following topics:
AppXcel Overview, page 490
AppXcel and AppDirector Integrated Solutions, page 490.
AppXcel Configuration, page 495.
AppXcel Configuration, page 495
Optimizing AppDirector with AppXcel Application Accelerator
AppXcel Overview
AppXcel is a transaction accelerator that provides cryptography acceleration as well as web
acceleration.
Unlike web servers, AppXcel is optimized to perform SSL calculations. Off loading these calculations
to AppXcel relieves web server CPUs, effectively increasing their capacity and increases the
services potential number of Transactions Per Second (TPS - the ability to handle new SSL
transactions, with AppXcel now able to handle 32000 TPS). Whereas significant benefits can be
realized by simply deploying AppXcel - Application Accelerator in the network, combining it with
AppDirector creates a comprehensive IAS (Intelligent Application Switching) solution that
dramatically increases network certainty and performance. In addition to increased total TPS and
web server
AppXcel and AppDirector Integrated Solutions
AppXcel and AppDirector, Radwares infrastructure load balancer, are optimized to work together.
In the following figure, AppDirector intercepts and load balances all traffic. Non-SSL traffic bypasses
the AppXcel server farm and receives content from the back-end servers.
Figure 1: Non SSL Traffic
Bypassing the Application Accelerator maintains overall throughput capacity and achieves load
balancing traffic to the back-end servers. The reverse trip for traffic going outbound to the internet
follows the same pattern. When SSL based traffic approaches the network, AppDirector identifies
that the traffic must first be decrypted. AppDirector makes a load balancing decision as to 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.
AppXcel Farm
AppDirector
Server Farm
Non SSL Traffic
Optimizing AppDirector with AppXcel Application
Figure 2: AppDirector / AppXcel Load balancing Decisions
Steps 1-4 shown in the figure above indicate the flow of inbound traffic. Traffic also reverses along
the same path for outbound traffic destined for the internet.
Traffic Flow Through AppDirector
The flow of traffic for a HTTPS request is as follows:
1. All traffic arrives at the AppDirector virtual IP address.
2. AppDirector identifies and then redirects the HTTPS traffic to the best available AppXcel, and
HTTP sessions are sent to the servers.
3. AppXcel decrypts the session and sends an HTTP request back to AppDirector.
4. AppDirector redirects the HTTP request to the most available server.
5. The servers response is sent back to AppDirector.
6. AppDirector redirects the response to AppXcel for re-encryption.
7. AppXcel sends the newly encrypted response to AppDirector.
8. AppDirector sends the encrypted response back to the client.
Note: When using Back End Encryption, the traffic flow between the web servers and
AppXcel differs from the traffic flow described above. See Backend Encryption in the
AppXcel User Guide for further explanation.
TCP Splitting using AppDirector and AppXcel
Radware implements TCP splitting by using AppDirector in conjunction with AppXcel as follows (see
Figure 3 Application Front-end, page 492):
AppDirector manages the Virtual IPs facing the client, the health checks toward the servers and
AppXcel failover.
AppXcel performs the TCP splitting and handles the Diameter/LDAP messages (logic and queue
mechanism).
AppDirector Server Farm
AppXcel
SSL Decrypted (3)
SSL Decrypted (4)
SSL Traffic (2)
SSL Traffic (1)
Figure 3: Application Front-end
In a TCP Splitting scenario the logic flow is shown here:
1. AppDirector receives a Diameter or LDAP connection from the client to the Virtual IP address
that represents the required Diameter or LDAP service to the clients.
2. This Virtual IP is attached to an AppXcel farm, so the TCP connection is load balanced to one of
the AppXcel devices in the farm.
3. The allocated AppXcel receives the TCP connection, terminates it and opens connections to each
of the backend servers that provide the required service. For this purpose multiple backend
servers are attached to each AppXcel tunnel and AppXcel must take into consideration the
weight of each server when allocating a connection (AppXcel must of course be aware of all the
available backend servers and their weight and status). The backend servers are represented in
AppXcel by Virtual IP addresses, not by their physical address.
4. AppDirector receives from AppXcel the new connections (to new VIPs) and forwards them to the
respective backend server without any load balancing decision. For this purpose a different farm
is configured on AppDirector for each backend server.
AppDirector and AppXcel Synchronization
To implement this flow AppDirector must configure AppXcel devices with all the backend servers
connected to a tunnel (service) and update them on the availability and load of the backend servers.
For this purpose AppDirector opens an SSH connection to the management IP of each AppXcel
configured in its new Managed Devices table. Through this SSH connection AppDirector configures
the backend servers for all LDAP and Diameter services (Tunnels on AppXcel), including services
which are configured as a Backup Application Servers on AppDirector.
Every 60 seconds or once communication resumes after a communication failure between the
devices due to AppXcel failure or a connection failure, AppDirector checks whether the configuration
is synchronized.
The synchronization process has the following steps:
AppDirector retrieves from AppXcel the size and checksum (CRC32) of the Backend Servers
table.
AppDirector verifies that the table checksum on the AppXcel is the same as its own. If it is not,
it means the AppXcel is not synchronized.

Backend
servers
Application
Front-end
Client
Original connection
Split connection
To synchronize the data AppDirector first verifies that the size of the table on the AppXcel is the
same as its own.
If it is the same, it means there were no entries added or deleted from the table, just the
content was changed. In this case AppDirector updates the table entries. If an update of an
entry fails, AppDirector clears the complete table in AppXcel and configures it from scratch.
If the size is not the same, it means entries were added to or removed from the table.
AppDirector clears the complete table in AppXcel and configures it from scratch. The
following events generate a complete AppXcel table reconfiguration: server status change,
weight change, addition or removal of backend servers.
As long as an AppXcel device is not synchronized, AppDirector considers it as a Not-In-Service
server.
Managing AppXcel Failover
To ensure 24/7 availability for the LDAP and Diameter traffic, the Application Front-End solution
must ensure that traffic will continue even in the event of failure of one of its elements (AppDirector
or AppXcel).
AppDirector failover is provided by existing redundancy mechanisms, including Client Table
mirroring.
To provide AppXcel failover, AppDirector must provide special TCP connection handling. In the event
that an AppXcel device fails, AppDirector goes over the list of TCP connections that were open on the
failed device and reestablishes them using other AppXcel devices in the farm. To ensure the
connections opened between client and backend servers continue, AppDirector must modify the TCP
sequence numbers between itself and AppXcel devices to match those used by the client and
backend servers.
Configuring AppDirector with Client NAT
Using AppDirector with AppXcel, Client NAT can be used as follows:
When AppXcel is using Transparent mode, Client NAT can be applied to traffic on its way to the
Web servers.
When AppXcel is using Non-Transparent mode, Client NAT can be applied to traffic on its way to
AppXcel devices. In this case, Client NAT can also be applied to traffic on its way to Web servers.
For more information on Client NAT see Client NAT, page 217.
Note: Client NAT must not be applied to traffic on its way to AppXcel devices when AppXcel
is operating in Transparent mode.
Configuring AppDirector for TCP Splitting
1. All the AppXcel devices managed by AppDirector must be configured in the Managed Devices
table. AppDirector opens an SSH connection with each of the devices in this table and sends the
relevant information regarding backend servers.
2. For each backend server available for this service a farm is configured and the backend server is
the only server attached to it. In this farm the Transparent Server Support parameters must be
set to TCP Splitting.
3. A layer 4 policy that attaches a backend Virtual IP and destination port to a TCP Splitting farm is
configured for each farm.
4. A farm of AppXcel devices is configured. For this farm the Transparent Server Support
parameters must be set to Front-End AppXcel Farm. The configuration of the application server
belonging to a Front-End AppXcel farm requires two additional parameters:
a. Managed Device Name (select a device name from the dropdown list in the Managed
Devices table).
b. Tunnel ID (number >= 1). The tunnel Id configured on the managed AppXcel (selected
above) for this service.
5. The TCP Splitting table must be configured for Front-End AppXcel farms. 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.
6. An entry in this table is configured by selecting a layer 4 policy from a dropdown list. The
dropdown list will only display layer 4 policies that meet the following conditions:
a. It is a TCP Policy with a specific port.
b. A farm is associated to this L4 Policy (not a L7 Policy).
c. The farm associated to the policy has Transparent Server Support set to TCP Splitting.
Note: Once a layer 4 policy was 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
parameters of the layer 4 policy farm, cannot be changed to values that do not meet
the above conditions.
7. A layer 4 policy that attaches the service Virtual IP and destination port to the AppXcel farm is
configured.
To configure Managed Devices Table
1. Right-click on the AppDirector device and select Managed Devices Table. The Managed
Devices Table window appears.
2. Click Add and set the following parameters according to the explanations provided:
4. The Managed Devices Table also displays the status of the connection to the managed devices.
The following parameters are available:
Device Name (key):
Name of the managed device.
Description (string):
Description of the managed device, free text.
Management IP:
IP address by which the managed devices can be accessed.
Management Application:
Application used to manage the remote device.
Management Port:
Layer 4 destination port of the application that is used to manage
the remote device.
Admin Status:
Controls the status of the managed device.
Disable: The connection will be closed.
Enable: The connection remains open.
Username:
Username to be used for authentication during communication
with the managed device.
Password:
Password to be used for authentication during communication
with the managed device.
Note: For configuration of AppXcel with TCP Splitting scenarios, please see the AppXcel User
Guide.
AppXcel Configuration
To configure AppXcel
1. Add an AppXcel device to the map.
2. Double-click on the AppXcel device icon. The Setup window appears.
3. Enter the management IP address (30.10.1.1) in the Device IP Address field and configure the
username and password.
5. Configure a tunnel for Diameter service:
a. Select the AppDirector and AppXcel icons and click Link. The Link Tunnel to Farm window
appears.
b. In the Link to Farm window, select Use New Tunnel and click Ok. The Edit Tunnel window
appears.
c. Click Basic, and the Basic pane appears.
Connection Status:
Connecting: Trying to establish an SSH connection.
Open: Connection is established but managed device is not in
sync yet.
In Sync: Managed device is in sync.
Terminating: Connection was closed by remote site.
Closed: Connection is closed.
#Sent Messages:
Counts number of messages sent from AppDirector to the
managed device since the connection was established. Displays
zero (0) when a connection is not present.
#Received Messages:
Counts number of messages received by AppDirector from the
managed device since the connection was established. Displays
zero (0) when a connection is not present.
Tunnel Serial ID:
1
Interface:
LAN1
IP Address:
30.1.1.1
Mask:
255.0.0.0
Port:
1812
Host Name:
Server IP:
0.0.0.0
e. Click Ok.Your preferences are recorded.
6. Configure the user for AppDirector management:
a. From the Device menu, select Device Permissions. Click Yes to open device permissions
for AppXcel. The Device Permissions window appears.
b. Click Add, the Edit Device Users window appears.
d. Click Ok.Your preferences are recorded
7. Repeat steps 1-6 for the second AppXcel device.
To configure AppDirector
1. Define the interfaces for AppDirector and default gateway.
2. Configure the AppXcel devices as devices managed by AppDirector.
a. Right-click on AppDirector icon and select Managed Devices. The Managed Devices
window appears.
b. Set the following parameters according to the explanations provided:
c. Click Ok.Your preferences are recorded
d. Repeat steps a through to c above to add another managed device according to the
Device Name: (For example) AppXcel 2
Management IP: 30.10.1.2
Username: appdirector
Password: ********
e. Click Ok.Your preferences are recorded
Server Port:
0
Service Type:
Diameter Splitting
Server Reconnection Timeout [sec.]:
30
Application Handshake Timeout [sec.]:
3
Username:
appdirector
Password:
***********
Role:
Appdirector
Device Name:
(For example) AppXcel
Management IP:
30.10.1.1
Username:
appdirector
Password:
:********
3. Add the backend servers to the map:
a. On the AppDirector toolbar, click Add and from the dropdown menu select Server. The
Server window for the selected server appears.
b. Set the following parameters according to the explanations provided:
c. Repeat steps a and b to add another two servers, set the following parameters according to
d. Click Ok.Your preferences are recorded
4. Add a new farm to AppDirector:
a. Right-click on the AppDirector device icon and select APSolute OS > Traffic
d. Select Traffic Settings. The Traffic Settings pane appears, set the following parameter
according to the explanation provided:
e. Select Farm Servers. The Farm Servers pane appears.
f. Click Add. The Farm Servers window appears.
Server Name:
For example, Server 1
IP Address:
10.1.1.1
Server Name:
IP Address:
10.1.1.2
Server Name:
IP Address:
10.1.1.3
FarmName:
Define the farm name, for example: AppXcel-farm
Active Farm:
Enabled
Transparent Server
Support:
Front-End AppXcel
Server Name:
AppXcel 1
Server Address:
30.1.1.1
Managed Device Name:
AppXcel 1
Tunnel Id:
1
h. Repeat steps e to f to add a second AppXcel farm server and set the following parameters
i. Click Ok.Your preferences are recorded
5. Add new farms to AppDirector:
a. Press Shift and highlight both the AppDirector icon and Server.
b. Click Link. The Farm Servers window appears.
c. Select Use New Farm and click Ok. The Edit Farm window appears.
e. Select Traffic Settings. The Traffic Settings window appears, set the following parameter
according to the explanation provided:
f. Repeat steps c through to e to add farms for the other backend servers. Set the following
g. Click Ok.Your preferences are recorded.
6. Add Layer 4 Policies to AppDirector:
a. In the Traffic Redirection window, click L4 Policies. The L4 Policies pane appears.
b. Click Add. The L4 Policies window appears.
Server Name:
AppXcel 2
Server Address:
30.1.1.2
Managed Device Name:
AppXcel 2
Tunnel Id:
1
FarmName:
Define the farm name, for example: Backend-1
Active Farm:
Enabled
Transparent Server
Support:
TCP Splitting
FarmName:
Active Farm:
Enabled
Transparent Server
Support:
TCP Splitting
FarmName:
Active Farm:
Enabled
Transparent Server
Support:
TCP Splitting
c. In the VIP Address text box, enter the VIP address and click Add. The Add L4 Policy window
appears.
e. Click Ok. Your preferences are recorded.
f. Repeat steps b through to d to add all required Layer 4 policies. Set the Layer 4 parameters
7. Configure the TCP Splitting table:
b. Select the AppXcel-farm and click Edit. The Farm window appears.
c. Click on TCP Splitting. The TCP Splitting pane appears.
d. From the Backend L4 Policy Name dropdown list select BES-1. Click Add to add this L4
policy to the TCP Splitting table.
e. Repeat step d to add BES-2 and BES-3 to the TCP Splitting table.
f. Click Ok.Your preferences are recorded.
AppXcel and AppDirector Integration Features Benefits
AppXcel, used with AppDirector, provides the following features and benefits:
AppDirector can load balance both the HTTPS traffic and the HTTP traffic, including the HTTP
traffic between a AppXcel farm and the server farm.
Provides higher reliability.
High availability to the servers and AppXcel devices.
Optimizes SSL processing through load balancing.
Unlimited scalability - up to 65,0000 SSL transactions per second.
Intelligently redirects SSL traffic to AppXcel. All other traffic flows directly to the server thus
optimizing performance and decreasing latency.
Manipulates packets faster and more intelligently.
Does not change the existing topology of the network. The ability to connect AppXcel off to the
side of the network means there is no need to unplug other devices or rearrange the network
topology.
L4 Protocol:
Any
L4 Port:
Any
L4 Policy Name:
Define a name for the policy, for example; Policy 1.
FarmName:
From the dropdown list, select the farm that you want to include in this
policy; for example, Farm 1.
Table 1: Layer 4 parameters
VI P Layer 4
Protocol
Layer 4
Port
Layer 4 Policy Name Farm Name
100.1.1.1 TCP 1812 Diameter AppXcel-farm
20.1.1.1 TCP 1812 BES-1 Backend-1
20.1.1.2 TCP 1812 BES-2 Backend-2
20.1.1.3 TCP 1812 BES-3 Backend-3
Sorts traffic according to configured policies, that define which traffic must be copied to which
anti-virus or URL filter system. Thus each anti-virus or URL filter system receives the type of
traffic that it processes most efficiently.
Forwards SSL traffic to the AppXcel SSL farm for decryption and then forwards decrypted traffic
to the anti-virus or URL filter system for inspection according to configured policies.
AppXcel Integration with other Layer 4 Load Balancers
When working in Active mode AppXcel can be connected with other Layer 4 load balancers other
than AppDirector with the following limitations:
AppXcel has to be configured as a non-transparent Proxy. In this case the clients Source IP is
not passed to the back-end web server.
Protection against SSL Based Attacks can only be obtained with the integrated
AppDirector + AppXcel solution. AppDirectors Application Security features examine the
decrypted traffic returning from AppXcel before sending it to the back-end server.
Layer 7 load balancing while using a secure connection to the back-end server, can only be obtained
with the integrated AppDirector + AppXcel solution. By utilizing AppDirector and AppXcels
proprietary protocol, it is possible to perform Layer 7 load balancing decisions on the decrypted
HTTP headers which are sent from AppXcel before sending the encrypted back-end traffic.
Configuration Scenarios for AppDirector/AppXcel
Using AppDirector with AppXcel, you can configure secure networks. The secure network designs
suggested in this section use an internal HTTP farm, which contains confidential information that
must not be accessed directly from the Internet with clear text HTTP:
In the first design, the internal HTTP farm is configured as part of the Layer 4 Policy using a
special port.
In the second design, the internal HTTP farm has an internal private IP to ensure that it cannot
be accessed from the Internet, but only through the AppXcel farm.
First Secure Network Design
When clients access Layer 4 Policy on AppDirector:
Traffic to port 443 (SSL) is load balanced within the SSL farm.
Traffic to port 80 (HTTP) is load balanced within the external HTTP farm, which is used for clear
text HTTP requests coming from the clients.
Another port in the Layer 4 Policy, for example 8080, is associated with an internal HTTP farm,
which is used for decrypted HTTP requests coming from the AppXcel servers.
When using a firewall in front of AppDirector, this network design forces users to access the internal
HTTP farm using HTTPS rather than HTTP. This is achieved by blocking the internal HTTP farm port,
for example 8080, on the firewall. If there are administrative users who need HTTP access to the
internal HTTP farm, this can be permitted in the firewall configuration.
Second Secure Network Design
Traffic to port 80 (HTTP) is load balanced within the external HTTP farm, which is used for clear
HTTP requests coming from the clients.
Another farm is also configured and is used for decrypted HTTP requests coming from the
AppXcel servers.
The external HTTP farm is used for clear text HTTP requests coming from the clients.
This network design forces users to access the internal HTTP farm using HTTPS rather than HTTP.
Backend SSL with AppDirector Layer 7 Policies
Working with AppDirector and AppXcel allows you to use a transparent proxy that maintains the
client IP address so it is visible to the Web server, as well as to perform Layer 7 load balancing on
the requests arriving from clients.
Layer 7 parsing can be used with backend encryption on AppXcel. This is accomplished by having a
proprietary encoded communication tunnel between AppXcel and AppDirector. This communication
between AppDirector and AppXcel is supported when AppXcel is working both in Non-Transparent
and Transparent modes.
After receiving the response from AppDirector, AppXcel opens the encrypted backend connection to
a predefined IP address and Port. The IP address to which AppXcel sends the traffic is the IP address
of the Layer 4 Policy designed to handle the backend session. This Layer 4 Policy entry is different
from the entry the client side connection approaches. The Port to which AppXcel sends the traffic is
a specially predefined port on the backend session Layer 4 Policy. This port is set using the Backend
Encryption Port parameter in the Layer 4 Policy configuration.
The Backend Encryption Port serves two purposes:
Indicates that backend encryption support is required in that Layer 4 Policy.
Sets the port to which AppXcel sends the backend host encrypted traffic. Thus, the Backend
Encryption Port must be configured using the same value as the Server Port parameter in the
Proxy that is defined on AppXcel.
The Backend Encryption Port can be any TCP port.
An additional Layer 4 Policy entry is defined to treat the encoded HTTP Headers sent from
AppXcel to AppDirector. The HTTP Headers are used by AppDirector to choose the server farm.
The second entry is bound to a Layer 7 Policy that is designed to search for predefined methods
and that listens on the user-defined port.
After choosing a server, AppDirector responds to AppXcel with the ID of the server to which
AppXcel opens the backend encrypted session.
AppXcel in turn opens the backend encrypted session towards AppDirector's Layer 4 Policy VIP
address.
To configure AppDirector with AppXcel
1. Configure IP interfaces and routing, as required.
2. Configure the SSL servers in an SSL farm and the HTTP servers in an HTTP farm.
3. Configure a Layer 4 Policy VIP. Associate port 443 (SSL) of the Layer 4 Policy with the SSL farm
and port 80 with the HTTP farm.
4. Optional: For Secure Network Designs, see Configuration Scenarios for AppDirector/AppXcel,
page 500. In these scenarios, you either add an internal HTTP farm to the Layer 4 Policy using
another port, OR configure an internal HTTP farm, which is not a part of the Layer 4 Policy. Add
servers to the internal HTTP farm, as required.
5. When using AppXcel Application Accelerators:
a. In Transparent mode, SSL and HTTP farms must use at least the Entry Per Session mode.
This is required in order to enable the AppDirector special support for this scenario. When
Server Per Session mode is required, see Advanced Configuration.
b. Non-Transparent mode, the farms can use any Sessions, as required. When Server Per
Session is required, see Advanced Configuration.
6. Configure the HTTP farm, which is used for decrypted SSL traffic, as the Server IP
(AppXcel > Tunnel Table > Edit Tunnel) using the appxcel tunnel create command in the
AppXcel configuration.
7. When implementing Secure Network Design I, the special port used for the internal HTTP farm
should be configured in the AppXcel using the Server Port parameter (AppXcel >
Tunnel Table > Edit Tunnel > Basic > Server Port) command.
Advanced AppDirector and AppXcel Configuration
Using the Server Per Session mode, enables AppDirector to separately load balance sessions
originating from the same client. Each session has a different Source Port, by which AppDirector can
identify the session. This mode is typically required when many clients have the same Source IP, as
they are located behind a proxy. This is the situation when using Non-Transparent AppXcel tunnels,
as they serve as a proxy. This means that all clear text HTTP traffic coming from them has their IP
addresses as the Source IP. In some cases, this configuration might be required with Transparent
AppXcel Accelerators as well; for example, when the clients are located behind a proxy.
To perform advanced AppDirector and AppXcel configuration
When using the Server Per Session mode, use the following configuration:
1. Configure IP interfaces and routing, as required.
2. Configure the SSL servers in an SSL farm and the HTTP servers in an HTTP farm.
3. Configure a Layer 4 Policy VIP. Associate port 443 (SSL) of the Layer 4 Policy with the SSL farm,
and port 80 with the HTTP farm.
4. Optional: For Secure Network Designs, you either add an internal HTTP farm to the Layer 4
Policy using another port, OR configure an internal HTTP farm, which is not a part of the Layer 4
Policy. Add servers to the internal HTTP farm, as required.
5. In a configuration with Transparent AppXcel tunnels, use the Server Per Session mode, as
required. In most cases, the same Sessions mode is used for the SSL and HTTP farms.
6. In a configuration with Non-Transparent AppXcel tunnels, the Server Per Session mode is
typically used for the internal HTTP farm.
7. If the Server Per Session mode is defined in the SSL farm, enable the SSL ID Tracking
parameter.
Note: When SSL ID Tracking is disabled, if the Server Per Session mode is configured,
AppDirector uses the Entry Per Session mode for sessions to the SSL port (443). This
is done to ensure that all sessions initiated by the same client use the same server.
The Regular mode is not influenced by the SSL ID Tracking configuration.
8. The HTTP farm handles clear text HTTP requests, and it can also be used with any other
AppDirector features, as required. For example, Layer 7 Policies can be used to assign different
farms to different policies or Session IDs can be used in order to maintain session persistency.
9. When AppXcel is in the Transparent mode, enable the Transparent Server Support parameter
Traffic Redirection > Edit AppDirector Farm > Traffic Settings in farms where AppXcel is
defined as a tunnel.
AppDirector > Global > Client Table Settings.
10. When working in a Backend Encryption with Layer 7 Policies scenario, the following configuration
should be performed:
a. For the client side traffic: define a Layer 4 Policy entry for port 443.
b. Bind this Layer 4 Policy entry to the AppXcel farm.
c. For the decoded HTTP Headers, the information is exchanged between AppXcel and
AppDirector: define a Layer 4 Policy entry for port 80.
11. Bind this Layer 4 Policy entry to the required Layer 7 Policy.
As an argument of the Layer 4 Policy entry, define the Backend Encryption Port as the port on which
the backend traffic is sent to the backend server; for example, this port can be set to 444. Set the
Backend Encryption Port parameter.
Example:AppDirector with AppXcel with Backend SSL and Layer 7 Policies
The following figure illustrates a configuration for AppDirector and AppXcel with Backend SSL
Support with AppDirector Layer 7 Policies.
Figure 4: Backend SSL Support with AppDirector Layer 7 Policies
Properties:
Connection between AppXcel and servers is secured using Backend Encryption.
AppDirector and AppXcel communicate with each other using a Proprietary encoded protocol.
AppXcel is configured as a transparent HTTPS Tunnel.
Server Network Side and Client Side are on different networks.
AppXcel and Server Network Side are on different networks.
AppXcel is directly connected to AppDirector.
AppDirector
Port 3 - 20.1.1.1
Port 2 - 10.1.1.1
100.1.1.100
VIP
provide
content for
Netscape
users
Servers that
provide
Explorer
users
Servers that
content for
VIP 2 10.1.1.102
VIP 1 10.1.1.101
Client
Router
100.1.1.2
AppXcel
Management IP
Tunnel IP
Port 1 - 100.1.1.1
AppDirector performs Layer 7 switching to provide different content for Netscape and Internet
Explorer users.
The Layer 7 VIP address of AppDirector is 100.1.1.100.
Two server farms exist, one for handling Netscape users and one for handling Internet Explorer
users. The two server farms handle both regular HTTP (TCP Port 80) and Backend Encryption
(TCP Port 445) traffic to the Web servers.
AppXcel Tunnel IP address is 20.1.1.2.
Server Network is 10.1.1.x for both farms.
To configure Backend SSL Support with AppDirector Layer 7 Policies
1. Set the AppXcel operation mode to Proxy using the following CLI command:
appxcel mode set proxy 20.1.1.10 255.255.225.0 -inf 1
2. Define the default gateway for AppXcel:
a. Right-click the AppXcel icon and select SetUp. The AppXcel window appears.
b. In the SetUp pane of the AppXcel window, select Networking > Routing Table.The
Routing Table window appears.
c. Click Add. The Edit Route window appears.
e. Click Ok to exit all windows.
3. Configure AppDirector:
a. Define the interfaces for Ports 2 and 3. Right-click the AppDirector icon and select
Connect. The Connect AppDirector Device window appears.
b. In the Device IP Address field, enter 100.1.1.1 and click Ok.
c. Right-click the AppDirector icon and select SetUp. The SetUp window appears.
d. Click Add. The Interface window appears.
4. Add another interface:
b. Click Add. The Interface window appears.
Type:
Default
Next Hop:
20.1.1.1
IF Num:
F-2
IP Address:
10.1.1.1
Network Mask:
255.255.255.0
IF Num: F-3
IP Address: 20.1.1.1
d. Click Ok.Your preferences are recorded.
5. Define the default gateway for AppDirector:
b. In the SetUp window, select Networking > Routing Table.The Routing Table window
appears.
c. Click Add. The Edit Physical Route window appears.
6. Add two servers:
a. Add the first server. From the Device menu select Servers > Server. A server icon
appears.
b. Double-click the server icon. The Server window appears.
d. Click Add and Ok.Your preferences are recorded.
e. Add the second server. From the Device menu select Servers > Server. A server icon
appears.
f. Double-click the server icon. The Server window appears.
h. Click Add and Ok.Your preferences are recorded.
7. Add the server farms to AppDirector:
a. Define the first farm. Right-click the AppDirector icon and select APSolute OS > Traffic
b. Select the Farms pane and click Add. The Farm window appears.
c. Enter the following value:
Network Mask: 255.255.255.0
0.0.0.0
Network Mask:
0.0.0.0
Next Hop:
100.1.1.20
IF Number:
F-1
Server Name:
Server 1
IP Address:
10.1.1.10
Server Name:
Server 2
IP Address:
10.1.1.11
FarmName:
Netscape Farm
d. In the Traffic Redirection window, select Traffic Settings. The Traffic Settings pane
appears.
g. Define the second farm. Right-click the AppDirector icon and select APSolute
OS > Traffic Redirection. The Traffic Redirection window appears.
h. Select the Farms pane and click Add. The Farm window appears.
i. Enter the following value
j. Select Traffic Settings. The Traffic Settings pane appears.
k. Set the following parameters according to the explanations provided:
l. Click Ok.Your preferences are recorded.
8. Add the servers to the server farms:
a. Add Server 1 to the Netscape Farm. In the Traffic Redirection window, select the Farm pane.
b. Select the Netscape Farm entry and click Edit. The Farm window appears.
c. Click Add. The Farm Servers window appears. Set this parameter:
e. Add Server 2 to the Internet Explorer Farm. In the Traffic Redirection window, select the
Farm pane.
f. Select the Internet Explorer Farm entry and click Edit. The Farm window appears.
g. Click Add. The Farm Servers window appears.
h. Set this parameter:
i. Click Ok twice.Your preferences are recorded.
9. Define a Key and Certificate for AppXcel:
a. Right-click the AppXcel icon and select Keys. The Keys window appears.
b. Click Import Key. The Import Key window appears.
Transparent Server
Support:
Enabled
Sessions Mode:
Server Per Session
FarmName:
Internet_Explorer Farm
Transparent Server
Support:
Enabled
Sessions Mode:
Server Per Session
Server Name:
Server 1
Server Name:
Server 2
Note: When importing a complete PKCS12 bundle to AppXcel, both the Key and Certificate
are imported and bound to each other.
10. Link AppXcel to AppDirector:
a. Holding the Control key, select the AppDirector and AppXcel icons.
b. On the toolbar, click the Link Device button ( ). The Link AppXcel to AppDirector window
appears.
c. Select Use New Tunnel then click Ok. The Edit Tunnel window appears.
d. Click Basic, and set the following parameters according to the explanations provided
e. Click the Advanced pane and set the following parameters according to the explanations
provided:
NewKey ID:
1
Key Password:
The password used for exporting the key from the Web
server.
Verify Key Password:
Re-type the password.
Import Method:
Select File.The File Name parameter appears.
File Name:
Use the Browser to locate your exported key.
AppDirector SSL Farm
Name:
Select the HTTPS Farm.
Tunnel Serial ID:
1
IP Address:
20.1.1.2
Mask:
255.255.255.0
Port:
443
Server Name:
Server Farm
Server IP:
100.1.1.100 (AppDirector VIP to handle backend traffic)
Server Port:
445
Attached Key ID:
1
Cipher Suite:
RSA
Service Type:
HTTP
11. Define the two Layer 7 Methods:
a. Define the first entry. In the Traffic Redirection window, select the L4 Policies pane and click
L7 Policies. The Layer 7 Policies window appears.
b. Click L7 Methods. The Layer 7 Methods window appears.
c. Click Add. The Edit Layer 7 Methods window appears.
e. Click Ok.Your preferences are recorded.
f. In the Backend SSL configuration: Define the second entry. In the AppDirector Traffic
Redirection window, select the Layer 4 Policies pane and click L7 Policies. The Layer 7
Policies window appears.
g. Click L7 Methods. The Layer 7 Methods window appears.
h. Click Add. The Edit Layer 7 Methods window appears.
i. Set the following parameters according to the explanations provided:
j. Click Ok.Your preferences are recorded.
12. Define the two Layer 7 Policies:
a. In the Layer 7 Policies window, click Add Policy (no new window appears). Set the following
Tunnel Transparency:
Enabled
Enable Backend SSL:
Enabled
Backend Cipher Suite:
Low
Backend Layer7 LB Port:
80
Method Name:
Netscape
Method Type:
Header Field
Header Field:
User-Agent
Token:
Mozilla/5.0
Method Name:
Internet_Explorer
Method Type:
Header Field
Header Field:
User-Agent
Token:
Mozilla/4.0
Policy Name:
Users
Policy Index:
1
b. Click Add.
c. In the Layer 7 Policies window, click Add Policy again. Set the following parameters
d. Click Add and then click Ok. Your preferences are recorded.
13. Define the Layer 4 Policy:
a. In the Traffic Redirection window, select the L4 Policies pane and click Add. The L4 Policies
window appears.
b. Set the following parameter:

c. Click Add. The Add L4 Policy window appears.

f. Click Add. Add L4 Policy window appears.

First Method: Netscape
Farm Name: Netscape Farm
Policy Name:
Users
Policy Index:
2
First Method:
Internet_Explorer
FarmName:
Internet_Explorer Farm
VIP Address:
100.1.1.100
L4 Policy Name:
Policy 1
FarmName:
HTTPS Farm
L4 Port:
443
Layer 4 Protocol:
TCP
Policy Name:
Policy 2
L4 Port:
HTTP
Layer 4 Protocol:
TCP
Layer 7 Policy Name:
User
Backend Encryption Port:
445
h. Click Ok. Your preferences are recorded.
14. Enable the Transparent Server Support for Delayed Binding parameter:
c. Select Client Table Settings > Edit Settings. The Client Table Settings window appears.
d. Select Transparent Server Support for Delayed Binding and click Enable.
Appendix D Diagnostic Tools
This appendix provides a list of common Diagnostics tools to use with SIP Director and contains the
following sections:
Introduction, page 511
Diagnostics Trace-Log, page 511
Traffic Capture, page 512
Diagnostics Tools Policies, page 513
Diagnostics Tools File Management, page 514
System Diagnostics, page 514
Introduction
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. APSolute OS offers system administrators the following Diagnostics tools:
Diagnostics Trace-Log
Traffic Capture
Diagnostics will stop automatically in the following cases:
You manually stop the diagnostics tasks
You rebooted 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 Trace-
Log 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.
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.
Diagnostic Tools
Task Name - The name of the specific task of the traced module.
Notes: 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 for each packet logs will be 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.
>> In both cases the messages are written to the same log file.
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.
Capture Options
It is important to differentiate between the two capture options: Mode and Point.
SystemDiagnostics Capture Mode
Capture Mode defines at what point of the Radware device the traffic is filtered by classification
filters.
The options are
Default - The filter in capture mode is performed on packets at each entry point to the Radware
device. In this example point A
LAB - The filter in capture mode is performed on packets both at the entry and exit points to
and from the AD device (Both points A & B)
Notes:
>> LAB mode impairs performance severely.
>> When rebooting the device, the capture option moves to "disable " (since the "enable"
state reduces the performance of the device) .
Diagnostic Tools
SystemDiagnostics 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
An-packet-send - Point B
Both - Both Point A & B.
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).
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.
Diagnostics Policy Configuration Guidelines:
1. Define Services, see xxx.
2. Define Networks, see xxx.
3. Define Classes, see xxx.
4. Define VLAN Tag groups, see xxx.
5. Define Physical port groups, see xxx.
Diagnostic Tools
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.
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.
Notes:
>> Diagnostics Tools are only available via CLI in Telnet or SSH access to the SIP Director
device.
>> Diagnostic Tools may impair a performance penalty on the SIP Director device by
increasing CPU load and console response time.
>> On Application Switch 1 when the files are downloaded from the device's internal
flash, the device may not response to management during the download process,
while traffic is still passing and managed by the device.
>> In case a software upgrade is being performed while any of the diagnostics tools are
being executed, the operation of the diagnostics tools stops and all the diagnostics
files are erased.
>> After reboot the diagnostics tools is disabled by default.
System Diagnostics
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, Syst emDi agnost i cs in the
terminal console. For more detailed information see the accompanying CLI Reference Guide.
capture Packets Capture Diagnostics Tool
mode Packets Capture Mode Definition
default - The filter in capture mode is
performed on packets at each entry point
to the RADWARE device.
lab - The filter in capture mode is
performed on packets both at the entry
and exit points to and from the AD
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
Diagnostic Tools
1 - enabled
2 - disabled
files Diagnostics Tools Generated Files Management
abort Abort file download
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>
Diagnostic Tools
Switches:
-st : Status
-sev : Severity
msg-format Message Format Configuration
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 trace-
log message format
pckt-id Status of Packet-ID in the
trace-log message format
platform Status of Platform in the trace-
log message format
task Status of Task in the trace-log
message format
time Status of Time in the trace-log
message format
output Trace-Log Output Configuration
file Trace-Log Output To File
Configuration
syslog Trace-Log Output To Syslog
Configuration
term Trace-Log Output To Terminal
Configuration
status Diagnostics Trace-Log Status
1 - enabled
2 - disabled
Traffic Captures
Status
Indicates whether the Traffic Capture status is enabled or disabled
Output to File
Enables the file to be kept on the compact flash. Due to compact flash
size limitation, two files are employed to save data. Once the first file is
full, the device automatically switches to the second file, until the second
file is full and then it overwrites the first file etc. The device uses this file
name convention:
capture_device_name_DDMMYYYY_HHMMSS (for Example -
capture_AppDirector_27122051_010302_1.cap).
Output to Terminal
Enables you to send the output of the traffic captures to the Terminal
Output to RAMDrive
Enables to send the output of the traffic captures to the RAM Drive. In
this case the file is deleted after reboot of the device
Capture Point
Indicates the location of the capture point - the capture can be done
when the packet reaches the device, when packet leaves the device or
both
Diagnostic Tools
Diagnostics Trace
Status
Indicates whether the Diagnostics Trace status is enabled or disabled.
Output to File
Enables the file to be kept on the compact flash. Due to compact flash
size limitation, two files are employed to save data. Once the first file is
full, the device automatically switches to the second file, 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 the output of the traffic captures to the Terminal.
Output to RAMDrive
Enables you to send output of traffic captures to the RAM Drive - For AS
1.
Output to Syslog
Enables you to send the output of the Diagnostics Trace to a Syslog
Server.
Diagnostic Tools

Radward

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Radward

Uploaded by

Copyright:

Available Formats

AppDirector User Guide

Software Version: 1.06

You might also like