Document ID: AD_01_06_UG July 2008 AppDirector User Guide 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 AppDirector User Guide 4 Document ID: AD_01_06_UG 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. AppDirector User Guide Document ID: AD_01_06_UG 5 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. AppDirector User Guide 6 Document ID: AD_01_06_UG 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. AppDirector User Guide Document ID: AD_01_06_UG 7 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. AppDirector User Guide 8 Document ID: AD_01_06_UG 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) Document ID: AD_01_06_UG 9 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 AppDirector User Guide Table of Contents 10 Document ID: AD_01_06_UG 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 AppDirector User Guide Table of Contents Document ID: AD_01_06_UG 11 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 AppDirector User Guide Table of Contents 12 Document ID: AD_01_06_UG 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 AppDirector User Guide Table of Contents Document ID: AD_01_06_UG 13 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 AppDirector User Guide Table of Contents 14 Document ID: AD_01_06_UG 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 AppDirector User Guide Table of Contents Document ID: AD_01_06_UG 15 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 AppDirector User Guide Table of Contents 16 Document ID: AD_01_06_UG 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 AppDirector User Guide Table of Contents Document ID: AD_01_06_UG 17 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 AppDirector User Guide Table of Contents 18 Document ID: AD_01_06_UG Document ID: AD_01_06_UG 19 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 AppDirector User Guide Introduction 20 Document ID: AD_01_06_UG 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). AppDirector User Guide Introduction Document ID: AD_01_06_UG 21 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. AppDirector User Guide Introduction 22 Document ID: AD_01_06_UG 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 AppDirector User Guide Introduction Document ID: AD_01_06_UG 23 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 AppDirector User Guide Introduction 24 Document ID: AD_01_06_UG 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. AppDirector User Guide Introduction Document ID: AD_01_06_UG 25 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. AppDirector User Guide Introduction 26 Document ID: AD_01_06_UG 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 AppDirector User Guide Introduction Document ID: AD_01_06_UG 27 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 Application Switch 2 AppDirector 1000 Application Switch 4 AppDirector 3020, 1020 Application Switch 5 AppDirector 6000 OnDemand Switch 1 AppDirector 204, 504, 1004, 2004, 4004 OnDemand Switch 2 AppDirector 1016, 2016, 4016 AppDirector User Guide Introduction 28 Document ID: AD_01_06_UG Document ID: AD_01_06_UG 29 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 + AppDirector User Guide Getting Started with AppDirector 30 Document ID: AD_01_06_UG 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 AppDirector User Guide Getting Started with AppDirector Document ID: AD_01_06_UG 31 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>. AppDirector User Guide Getting Started with AppDirector 32 Document ID: AD_01_06_UG 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. AppDirector User Guide Getting Started with AppDirector Document ID: AD_01_06_UG 33 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). AppDirector User Guide Getting Started with AppDirector 34 Document ID: AD_01_06_UG 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 AppDirector User Guide Getting Started with AppDirector Document ID: AD_01_06_UG 35 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. AppDirector User Guide Getting Started with AppDirector 36 Document ID: AD_01_06_UG 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. AppDirector User Guide Getting Started with AppDirector Document ID: AD_01_06_UG 37 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. 2. From the Device menu select Device Permissions. The Device Permissions window appears. 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). Authentication Protocol None: Clear text is used during the session. MD5: MD5 hashing is used for authentication. SHA: SHA encryption is used for authentication. Authentication Password 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. AppDirector User Guide Getting Started with AppDirector 38 Document ID: AD_01_06_UG 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: 1. From the main APSolute Insite window, select the AppDirector device icon. 2. From the Device menu, select Device Permissions. The Device Permissions window appears. 3. Click SNMP. The SNMP pane appears. 4. Click Access. The VACM Group Access window appears. 5. Click View. The VACM MIB View window appears. 6. Set the following parameters according to the explanations provided: 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. AppDirector User Guide Getting Started with AppDirector Document ID: AD_01_06_UG 39 To add an entry to the SNMP Access table: 1. From the main APSolute Insite window, select the AppDirector device icon. 2. From the Device menu select Device Permissions. The Device Permissions window appears. 3. Click SNMP. The SNMP pane appears. 4. Click Access. The VACM - Group Access window appears. 5. Click Add. The VACM - Edit Group Access window appears. 6. Set the following parameters according to the explanations provided: 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. 2. From the Device menu select Device Permissions. The Device Permissions window appears. 3. Click SNMP. The SNMP pane appears. 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 Select an item from a list of all the available views that are configured in the VACM - MIB View window, and provide Write access to the Object IDs specified in the selected view. Notify ViewName Select an item from a list of all the available views that are configured in the VACM - MIB View window, and provide Notify access to the Object IDs specified in the selected view. AppDirector User Guide Getting Started with AppDirector 40 Document ID: AD_01_06_UG 5. Click Add. The Edit Target Address window appears. 6. Set the following parameters according to the explanations provided:
7. Click OK to save your settings and close the window. 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. 2. From the Device menu, select Device Permissions. The Device Permissions window appears. 3. Click SNMP. The SNMP pane appears. 4. Click Targets. The Target Address window appears. 5. Click Parameters.The Target Parameters window appears. 6. Click Add. The Edit Target window appears. 7. Set the following parameters according to the explanations provided: 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. AppDirector User Guide Getting Started with AppDirector Document ID: AD_01_06_UG 41 8. Click OK to save your settings and close the window. 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: 1. From the main APSolute Insite window, select the AppDirector device icon. 2. From the Device menu select Device Permissions. The Device Permissions window appears. 3. Click SNMP. The SNMP pane appears. 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. Default value: No Authentication. 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. AppDirector User Guide Getting Started with AppDirector 42 Document ID: AD_01_06_UG 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: 1. From the main APSolute Insite window, select the AppDirector device icon. 2. From the Device menu, select Device Permissions. The Device Permissions window appears. 3. Click SNMP. The SNMP pane appears. 4. Click Targets. The Target Address window appears. 5. Click Notify. The Notify Table window appears. 6. Click Add. The Edit Notify Table appears. 7. Set the following parameters according to the explanations provided: 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 Authentication Protocol MD5 Authentication Password password AppDirector User Guide Getting Started with AppDirector Document ID: AD_01_06_UG 43 4. Click Set. The user is added to the User Table. 5. Open APSolute Insite. 6. From the Device menu select Add Radware Device > AppDirector. The AppDirector icon appears in Site Explorer and/or on the map. 7. Double-click the AppDirector icon. The Connect AppDirector Device window appears. 8. Enter the Device IP Address, and select the SNMPv3 checkbox. The SNMPv3 pane appears. 9. In the User Name field, enter radware. When connecting using this user name, neither authentication nor privacy is required. 10. Click OK. APSolute Insite is connected to the device through SNMPv3. 11. From the Device menu select Device Permissions. The Device Permissions window appears. 12. Click SNMP. The SNMP pane appears. 13. Click Access. The VACM Group Access window appears. 14. Click Add, then set the following parameters according to the explanations provided: 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 AppDirector User Guide Getting Started with AppDirector 44 Document ID: AD_01_06_UG 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. 2. Double-click the AppDirector 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 field, enter radware. When connecting using this user name, neither authentication nor privacy is required. 5. Click OK. APSolute Insite is connected to the device through SNMPv3. 6. From the Device menu select Device Permissions. The Device Permissions window appears. 7. Click SNMP. The SNMP pane appears containing the following configuration options: Targets, Views, Users, Community, Access. These options are explained in this configuration example. 8. Click Community. The Community window appears. 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 AppDirector User Guide Getting Started with AppDirector Document ID: AD_01_06_UG 45 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). 2. Double-click the AppDirector 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. 4. From the Device menu, select Device Permissions. The Device Permissions window appears. 5. Click SNMP. The SNMP pane appears. 6. Click Community. The Community window appears. 7. To add a new entry to the Community table, in the Community window, click Add. The Edit Community window appears. 8. Set the following parameters according to the explanations provided: 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 AppDirector User Guide Getting Started with AppDirector 46 Document ID: AD_01_06_UG 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. 4. From the Device menu, select Device Permissions. The Device Permissions window appears. 5. Click SNMP. The SNMP pane appears. 6. Click Community. The Community window appears. 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. 12. Set the following parameters according to the explanations provided: 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 A subnet mask of the management station. Tag List nms Parameters public-v1 AppDirector User Guide Getting Started with AppDirector Document ID: AD_01_06_UG 47 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. 6. From the Device menu, select Device Permissions. The Device Permissions window appears. 7. Click SNMP. The SNMP pane appears containing the following configuration options: Targets, Views, Users, Community, Access. 8. Click Target. The Target Address window appears. 9. Click Parameters. The Target Parameters window appears. 10. Click Add. The Edit Target parameters window appears. 11. Set the following parameters according to the explanations provided: 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 A subnet mask of the management station. AppDirector User Guide Getting Started with AppDirector 48 Document ID: AD_01_06_UG 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. The SetUp window appears. 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 AppDirector User Guide Getting Started with AppDirector Document ID: AD_01_06_UG 49 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. 2. From the Device menu, select Device Permissions. The Device Permissions window appears. 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. 10. Click OK. Your preferences are recorded. 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. AppDirector User Guide Getting Started with AppDirector 50 Document ID: AD_01_06_UG 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. 3. Set the following parameters according to the explanations provided: 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 User Guide Getting Started with AppDirector Document ID: AD_01_06_UG 51 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: 1. From the main APSolute Insite window, select Device > Device Permissions. The Device Permissions window appears. 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. 9. Click OK. Your preferences are recorded. 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. AppDirector User Guide Getting Started with AppDirector 52 Document ID: AD_01_06_UG To set the Users Table: 1. From the main APSolute Insite window, select Device > Device Permissions. The Device Permissions window appears. 2. Click Users Table. The Users Table pane appears. 3. Click Add. The Edit Device Users window appears. 4. Set the following parameters according to the explanations provided: 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. 3. Set the following parameters according to the explanations provided: 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. AppDirector User Guide Getting Started with AppDirector Document ID: AD_01_06_UG 53 4. Click OK. Your preferences are recorded. 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. AppDirector User Guide Getting Started with AppDirector 54 Document ID: AD_01_06_UG 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. AppDirector User Guide Getting Started with AppDirector Document ID: AD_01_06_UG 55 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: 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 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. 5. Click OK. Your preferences are recorded. 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. AppDirector User Guide Getting Started with AppDirector 56 Document ID: AD_01_06_UG Document ID: AD_01_06_UG 57 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. AppDirector User Guide Administering AppDirector 58 Document ID: AD_01_06_UG >> 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 Backup Application version 2 Application Software versions AS5 Backup Application version 2 Application Software versions ODS-1 Backup Application version 2 Application Software versions ODS-2 Backup Application version 2 Application Software versions AppDirector User Guide Administering AppDirector Document ID: AD_01_06_UG 59 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. AppDirector User Guide Administering AppDirector 60 Document ID: AD_01_06_UG 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. AppDirector User Guide Administering AppDirector Document ID: AD_01_06_UG 61 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. AppDirector User Guide Administering AppDirector 62 Document ID: AD_01_06_UG 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. AppDirector User Guide Administering AppDirector Document ID: AD_01_06_UG 63 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 File window appears. 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. AppDirector User Guide Administering AppDirector 64 Document ID: AD_01_06_UG To convert a BER file to ASCII format: 1. From the APSolute Insite main window, select Device > Configuration File. The Configuration File window appears. 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. 8. Click Close to close the Configuration File window. To convert an ASCII file to BER format: 1. From the APSolute Insite main window, select Device > Configuration File. The Configuration File window appears. 2. Select Edit. The Edit pane appears. 3. Select from the following parameters: 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. 8. Click Close to close the Configuration File window. 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 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 AppDirector User Guide Administering AppDirector Document ID: AD_01_06_UG 65 To edit an ASCII file: 1. From the APSolute Insite main window, select Device > Configuration File. The Configuration File window appears. 2. Select Edit. The Edit pane appears. 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. 9. Click Close to close the Configuration File window. To upgrade your configuration: 1. From the APSolute Insite main window, select Device > Configuration File. The Configuration File window appears. 2. Select Upgrade Configuration. The Upgrade Configuration pane appears. 3. Select from the following parameters: 4. Once you have selected the source and destination files for the upgrade, click Apply. The configuration file is upgraded. 5. Click Close to close the Configuration File window. 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 Click on the radio button and choose a device. 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. AppDirector User Guide Administering AppDirector 66 Document ID: AD_01_06_UG 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: 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 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 AppDirector User Guide Administering AppDirector Document ID: AD_01_06_UG 67 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 AppDirector User Guide Administering AppDirector 68 Document ID: AD_01_06_UG 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. 3. Click OK. Your preferences are recorded. Device Tuning This section describes the interfaces and methods for AppDirector device tuning. This section includes the following topics: 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 AppDirector User Guide Administering AppDirector Document ID: AD_01_06_UG 69 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. AppDirector User Guide Administering AppDirector 70 Document ID: AD_01_06_UG 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. AppDirector User Guide Administering AppDirector Document ID: AD_01_06_UG 71 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. AppDirector User Guide Administering AppDirector 72 Document ID: AD_01_06_UG 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 AppDirector User Guide Administering AppDirector Document ID: AD_01_06_UG 73 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. AppDirector User Guide Administering AppDirector 74 Document ID: AD_01_06_UG 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 to a value higher than zero. Outbound NAT Ports per Address Defines number of ports used with each NAT IP address. Note: Before enabling Outbound NAT, this parameter must be set to a value higher than zero. Outbound NAT Intercept Addresses Defines number of IP ranges intercepted and NATed by Outbound NAT. Note: Before enabling Outbound NAT, this parameter must be set to a value higher than zero. AppDirector User Guide Administering AppDirector Document ID: AD_01_06_UG 75 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. AppDirector User Guide Administering AppDirector 76 Document ID: AD_01_06_UG 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. AppDirector User Guide Administering AppDirector Document ID: AD_01_06_UG 77 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. AppDirector User Guide Administering AppDirector 78 Document ID: AD_01_06_UG 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. 3. Click OK. Your preferences are recorded. 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: AppDirector User Guide Administering AppDirector Document ID: AD_01_06_UG 79 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: 1. From the main APSolute Insite window, right-click the AppDirector device icon and select SetUp. The SetUp window appears. 2. Click Global. The Global pane appears. 3. Select Threshold Warnings > Edit Settings. The Threshold Settings window appears. 4. Set the following according to the explanations provided: 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. AppDirector User Guide Administering AppDirector 80 Document ID: AD_01_06_UG 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. AppDirector User Guide Administering AppDirector Document ID: AD_01_06_UG 81 5. Click OK. Your preferences are recorded. 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) AppDirector User Guide Administering AppDirector 82 Document ID: AD_01_06_UG 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: 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. Select Static DNS. The Static DNS Table appears in the DNS pane. 5. Set the following according to the explanations provided: 6. Click Add. The new client is listed in the Static DNS Table. 7. Click OK. Your preferences are recorded. 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. The SetUp window appears. 2. Click the Networking button and select NTP. The Network Time Protocol Preferences window appears. 3. Set the following according to the explanations provided: 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). AppDirector User Guide Administering AppDirector Document ID: AD_01_06_UG 83 4. Click OK. Your preferences are recorded. 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. AppDirector User Guide Administering AppDirector 84 Document ID: AD_01_06_UG 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. This section includes the following topics: 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. AppDirector User Guide Administering AppDirector Document ID: AD_01_06_UG 85 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 SetUp window appears. 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. 5. Click OK. Your preferences are recorded. 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: 1. In the main window, right-click the AppDirector device icon and select SetUp. The SetUp 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. AppDirector User Guide Administering AppDirector 86 Document ID: AD_01_06_UG 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. AppDirector User Guide Administering AppDirector Document ID: AD_01_06_UG 87 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: 1. In the main window, right-click the AppDirector device icon and select SetUp. The SetUp 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. 7. Set the following parameters according to the explanations provided: 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. AppDirector User Guide Administering AppDirector 88 Document ID: AD_01_06_UG 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. AppDirector User Guide Administering AppDirector Document ID: AD_01_06_UG 89 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 User Guide Administering AppDirector 90 Document ID: AD_01_06_UG 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 AppDirector User Guide Administering AppDirector Document ID: AD_01_06_UG 91 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: 1. In the main window, right-click the AppDirector device icon and select SetUp. The SetUp 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 AppDirector User Guide Administering AppDirector 92 Document ID: AD_01_06_UG 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 Default by Type (default value): 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. AppDirector User Guide Administering AppDirector Document ID: AD_01_06_UG 93 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 the following topics: 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. AppDirector User Guide Administering AppDirector 94 Document ID: AD_01_06_UG >> 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: 1. In the main window, right-click the AppDirector device icon and select SetUp. The SetUp 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. AppDirector User Guide Administering AppDirector Document ID: AD_01_06_UG 95 8. Click OK. Your preferences are recorded. 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. AppDirector User Guide Administering AppDirector 96 Document ID: AD_01_06_UG To configure routing: 1. In the main window, right-click the AppDirector device icon and select SetUp. The SetUp 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 explanations provided: 4. Click OK. Your preferences are recorded. 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). 3. Click OK. Your preferences are recorded. 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) Document ID: AD_01_06_UG 97 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. AppDirector User Guide Configuring Load Balancing Policies 98 Document ID: AD_01_06_UG 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 AppDirector User Guide Configuring Load Balancing Policies Document ID: AD_01_06_UG 99 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: 1. From the main APSolute Insite window, select APSolute OS > Traffic Redirection. The Traffic Redirection window appears. 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. 5. Set the following parameters according to the explanations provided: 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 AppDirector User Guide Configuring Load Balancing Policies 100 Document ID: AD_01_06_UG 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 AppDirector User Guide Configuring Load Balancing Policies Document ID: AD_01_06_UG 101 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. AppDirector User Guide Configuring Load Balancing Policies 102 Document ID: AD_01_06_UG 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 AppDirector User Guide Configuring Load Balancing Policies Document ID: AD_01_06_UG 103 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 AppDirector User Guide Configuring Load Balancing Policies 104 Document ID: AD_01_06_UG 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 AppDirector User Guide Configuring Load Balancing Policies Document ID: AD_01_06_UG 105 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. AppDirector User Guide Configuring Load Balancing Policies 106 Document ID: AD_01_06_UG 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 AppDirector User Guide Configuring Load Balancing Policies Document ID: AD_01_06_UG 107 To define a Method for service selection: 1. From the main APSolute Insite window, select APSolute OS > Traffic Redirection. The Traffic Redirection window appears. 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. 6. Set the following parameters according to the explanations provided:
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 AppDirector User Guide Configuring Load Balancing Policies 108 Document ID: AD_01_06_UG 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: 1. From the main APSolute Insite window, select APSolute OS > Traffic Redirection. The Traffic Redirection window appears. 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. AppDirector User Guide Configuring Load Balancing Policies Document ID: AD_01_06_UG 109 5. Click Add. A new Layer 7 Policy appears in the left pane of the Layer 7 Policies window. 6. Click OK. Your preferences are recorded. 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: When using this argument, leave the Farm Name field empty. Values are case sensitive. 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: When using this argument, leave the Farm Name field empty. Values are case sensitive. AppDirector User Guide Configuring Load Balancing Policies 110 Document ID: AD_01_06_UG 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: AppDirector User Guide Configuring Load Balancing Policies Document ID: AD_01_06_UG 111
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: AppDirector User Guide Configuring Load Balancing Policies 112 Document ID: AD_01_06_UG 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. AppDirector User Guide Configuring Load Balancing Policies Document ID: AD_01_06_UG 113 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 Select one of the following: 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 AppDirector User Guide Configuring Load Balancing Policies 114 Document ID: AD_01_06_UG 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.) AppDirector User Guide Configuring Load Balancing Policies Document ID: AD_01_06_UG 115 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.) AppDirector User Guide Configuring Load Balancing Policies 116 Document ID: AD_01_06_UG 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: 1. In the main window, select APSolute OS > Traffic Redirection. The Traffic Redirection 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.) AppDirector User Guide Configuring Load Balancing Policies Document ID: AD_01_06_UG 117 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. 7. Set the following parameters according to the explanations provided: 8. Click Add. A new entry appears in the Static Session ID Persistency Table. To configure Text Match Session ID Using Regular Expression: 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 define Session ID Persistency and click Edit, OR click Add to create a new farm. The Farm window appears. 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. AppDirector User Guide Configuring Load Balancing Policies 118 Document ID: AD_01_06_UG >> 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 User Guide Configuring Load Balancing Policies Document ID: AD_01_06_UG 119 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) AppDirector User Guide Configuring Load Balancing Policies 120 Document ID: AD_01_06_UG 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: 1. In the main window, right-click the AppDirector device icon and select SetUp. The SetUp window appears. 2. Click Global. The Global pane 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 includes the following topics: Server Farms, page 121 Working with Farms, page 121 Configuring Farms, page 122 AppDirector User Guide Configuring Load Balancing Policies Document ID: AD_01_06_UG 121 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 AppDirector User Guide Configuring Load Balancing Policies 122 Document ID: AD_01_06_UG 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 AppDirector User Guide Configuring Load Balancing Policies Document ID: AD_01_06_UG 123 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). 2. Double-click the AppDirector icon. The Connect AppDirector Device window appears. 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: 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). 2. Double-click the AppDirector icon. The Connect AppDirector Device window appears. 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: AppDirector User Guide Configuring Load Balancing Policies 124 Document ID: AD_01_06_UG 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. AppDirector User Guide Configuring Load Balancing Policies Document ID: AD_01_06_UG 125 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. AppDirector User Guide Configuring Load Balancing Policies 126 Document ID: AD_01_06_UG 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. AppDirector User Guide Configuring Load Balancing Policies Document ID: AD_01_06_UG 127 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 triangulation method. HTTP Redirection & Triangulation: HTTP sessions are redirected by the HTTP redirection. All other sessions are redirected by the triangulation method. DNS Only: AppDirector User Guide Configuring Load Balancing Policies 128 Document ID: AD_01_06_UG 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. AppDirector User Guide Configuring Load Balancing Policies Document ID: AD_01_06_UG 129 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. The Farm window appears. 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 AppDirector User Guide Configuring Load Balancing Policies 130 Document ID: AD_01_06_UG 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. AppDirector User Guide Configuring Load Balancing Policies Document ID: AD_01_06_UG 131 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 User Guide Configuring Load Balancing Policies 132 Document ID: AD_01_06_UG 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. AppDirector User Guide Configuring Load Balancing Policies Document ID: AD_01_06_UG 133 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 Redirection window appears. 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. 8. Set the following parameters according to the explanations provided. 9. Click OK to apply the configuration. 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. AppDirector User Guide Configuring Load Balancing Policies 134 Document ID: AD_01_06_UG 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> <P ALIGN=center><FONT SIZE=+2><br><br> Service is currently unavailable. Please try again later. </FONT> </P> </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 section includes the following topics: 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 AppDirector User Guide Configuring Load Balancing Policies Document ID: AD_01_06_UG 135 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 AppDirector User Guide Configuring Load Balancing Policies 136 Document ID: AD_01_06_UG 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 1. From 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. 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. AppDirector User Guide Configuring Load Balancing Policies Document ID: AD_01_06_UG 137 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. 3. Click Traffic Settings. The Traffic Settings pane appears. AppDirector User Guide Configuring Load Balancing Policies 138 Document ID: AD_01_06_UG 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 Traffic Redirection window appears. 2. Select a farm and click Edit. The Farm window appears. 3. Click Traffic Settings. The Traffic Settings pane 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. AppDirector User Guide Configuring Load Balancing Policies Document ID: AD_01_06_UG 139 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. AppDirector User Guide Configuring Load Balancing Policies 140 Document ID: AD_01_06_UG 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. AppDirector User Guide Configuring Load Balancing Policies Document ID: AD_01_06_UG 141 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.) AppDirector User Guide Configuring Load Balancing Policies 142 Document ID: AD_01_06_UG 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 explanations provided: 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. AppDirector User Guide Configuring Load Balancing Policies Document ID: AD_01_06_UG 143 6. Click Apply. Your settings are saved. 7. Click the Traffic tab. The Traffic pane appears. 8. Set the following parameters according to the explanations provided. 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. AppDirector User Guide Configuring Load Balancing Policies 144 Document ID: AD_01_06_UG 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. AppDirector User Guide Configuring Load Balancing Policies Document ID: AD_01_06_UG 145 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: 1. In the main window, select APSolute OS > Traffic Redirection. The Traffic Redirection 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. 5. Set the following parameters according to the explanations provided: 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 AppDirector User Guide Configuring Load Balancing Policies 146 Document ID: AD_01_06_UG 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 AppDirector User Guide Configuring Load Balancing Policies Document ID: AD_01_06_UG 147 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: 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. 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 AppDirector User Guide Configuring Load Balancing Policies 148 Document ID: AD_01_06_UG 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 AppDirector User Guide Configuring Load Balancing Policies Document ID: AD_01_06_UG 149 a. Right-click the AppDirector icon and select APSolute OS > Traffic Redirection. The Traffic Redirection window appears. 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. AppDirector User Guide Configuring Load Balancing Policies 150 Document ID: AD_01_06_UG 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 AppDirector User Guide Configuring Load Balancing Policies Document ID: AD_01_06_UG 151 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: 1. From the main APSolute Insite window, select APSolute OS > Traffic Redirection. The Traffic Redirection window appears. 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. 6. Click OK. Your preferences are recorded. 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 AppDirector User Guide Configuring Load Balancing Policies 152 Document ID: AD_01_06_UG 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 User Guide Configuring Load Balancing Policies Document ID: AD_01_06_UG 153 Layer 3 Client Table 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 AppDirector User Guide Configuring Load Balancing Policies 154 Document ID: AD_01_06_UG 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 AppDirector User Guide Configuring Load Balancing Policies Document ID: AD_01_06_UG 155 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: 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 define Session ID Persistency and click Edit, OR click Add to create a new farm. The Farm window appears. 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. AppDirector User Guide Configuring Load Balancing Policies 156 Document ID: AD_01_06_UG 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 Traffic Redirection window appears. 2. In the Farms pane, click Add/Edit. The Farm window appears. 3. Click Traffic Settings. The Traffic Settings pane 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. 7. Click OK. Your preferences are recorded. 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. AppDirector User Guide Configuring Load Balancing Policies Document ID: AD_01_06_UG 157 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. 4. Click OK.Your preferences are recorded. 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. AppDirector User Guide Configuring Load Balancing Policies 158 Document ID: AD_01_06_UG
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. 4. Set the following parameters according to the explanations provided: 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. AppDirector User Guide Configuring Load Balancing Policies Document ID: AD_01_06_UG 159 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: 4. Click OK. Your preferences are recorded. 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. Layer 3 Client Table 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. AppDirector User Guide Configuring Load Balancing Policies 160 Document ID: AD_01_06_UG 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 Default value: 5 seconds To set the SYN Protection Timeout: 1. From the main APSolute Insite window, right-click the AppDirector device icon and select 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. 5. Click OK.Your preferences are recorded. 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 Default value: 5 seconds AppDirector User Guide Configuring Load Balancing Policies Document ID: AD_01_06_UG 161 To disable UDP Session Tracking: 1. From the main APSolute Insite window, right-click the AppDirector device icon and select SetUp. The SetUp window appears. 2. Click Global. The Global pane appears. 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. AppDirector User Guide Configuring Load Balancing Policies 162 Document ID: AD_01_06_UG 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. 5. Set the following parameters according to the explanations provided: 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) AppDirector User Guide Configuring Load Balancing Policies Document ID: AD_01_06_UG 163 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: 1. From the main APSolute Insite window, select Device > Client Table. The Client Table window 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. AppDirector User Guide Configuring Load Balancing Policies 164 Document ID: AD_01_06_UG 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. 7. Set the following parameters according to the explanations provided: 8. Click OK. Your preferences are recorded. 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. AppDirector User Guide Configuring Load Balancing Policies Document ID: AD_01_06_UG 165 To view entries from the Client Table using filters: 1. From the main APSolute Insite window, select Device > Client Table. The Client Table window 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. 5. Click OK. Your preferences are recorded. 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 AppDirector User Guide Configuring Load Balancing Policies 166 Document ID: AD_01_06_UG 2. In the Farms pane, select Add or Edit. The Farm window appears. 3. Select Traffic Settings. The Traffic Settings pane 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. 5. Click Apply and OK. Your preferences are recorded. Document ID: AD_01_06_UG 167 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 the following topics: 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. AppDirector User Guide Configuring Global Load Balancing 168 Document ID: AD_01_06_UG 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 AppDirector User Guide Configuring Global Load Balancing Document ID: AD_01_06_UG 169 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. AppDirector User Guide Configuring Global Load Balancing 170 Document ID: AD_01_06_UG 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 AppDirector User Guide Configuring Global Load Balancing Document ID: AD_01_06_UG 171 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: 1. From the main window, select APSolute OS > Traffic Redirection. The Traffic Redirection 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. AppDirector User Guide Configuring Global Load Balancing 172 Document ID: AD_01_06_UG Proximity This section discusses the methods AppDirector uses to measure proximity to redirect traffic. This section includes the following topics: 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. AppDirector User Guide Configuring Global Load Balancing Document ID: AD_01_06_UG 173 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. AppDirector User Guide Configuring Global Load Balancing 174 Document ID: AD_01_06_UG 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: 1. From the main window, select APSolute OS > Traffic Redirection. The Traffic Redirection 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 VIP of a L4 policy which is associated with the relevant farm Server2 IP of a Distributed AppDirector type server in the relevant farm OR IP of a Remote Server type server in the relevant farm OR VIP of a L4 policy which is associated with the relevant farm Server3 IP of a Distributed AppDirector type server in the relevant farm OR IP of a Remote Server type server in the relevant farm OR VIP of a L4 policy which is associated with the relevant farm AppDirector User Guide Configuring Global Load Balancing Document ID: AD_01_06_UG 175 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: 1. In the main window, select APSolute OS > Traffic Redirection. The Traffic Redirection window appears. 2. Click Redirection. The Redirection pane appears. 3. Click Add. The Traffic Redirection 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 User Guide Configuring Global Load Balancing 176 Document ID: AD_01_06_UG 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. Possible values: between 1 and 100. 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. Possible values: between 1 and 100. Default value: 1. Proximity Table Cleanup (Min.): Frequency of the Proximity Table cleanup. Default value: 0. AppDirector User Guide Configuring Global Load Balancing Document ID: AD_01_06_UG 177 >> 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: 1. In the main window, select APSolute OS > Traffic Redirection. The Traffic Redirection window appears. 2. Click Redirection. The Redirection pane appears. 3. Click Add. The Traffic Redirection window appears. 4. Click Proximity, the Proximity pane appears. 5. Set the Proximity parameters as explained in Table 28:, page 176. 6. Click OK. Your preferences are recorded. 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. Default value: Enabled. Advanced Check: Test that simulates standard applications. IDS devices may consider such proximity check packets as an attack. Default value: Enabled. Application Independent Check: Test that uses application information in a packet received from a remote client to simulate a response. Default value: Enabled. Application Aware Check: Test that simulates a generic response, unrelated to the client's request. Default value: Enabled. 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. AppDirector User Guide Configuring Global Load Balancing 178 Document ID: AD_01_06_UG 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: 1. From the main window, select APSolute OS > Traffic Redirection. The Traffic Redirection window appears. 2. Click Add. The Farm window appears. 3. Click Redirection. The Redirection pane appears. 4. Click Default Redirection when No Proximity. The Distributed Site window appears. 5. Set the parameters as explained in Table 30:, page 181. 6. Click OK. Your preferences are recorded. 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. Default value: Enabled. AppDirector User Guide Configuring Global Load Balancing Document ID: AD_01_06_UG 179 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. AppDirector User Guide Configuring Global Load Balancing 180 Document ID: AD_01_06_UG 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. AppDirector User Guide Configuring Global Load Balancing Document ID: AD_01_06_UG 181
To To configure the LRP Parameters: 1. From the main window, double-click the AppDirector icon. The SetUp window appears. 2. Click Global. The Global pane appears. 3. Select Advanced Settings > Edit Settings. The Advanced Settings 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. AppDirector User Guide Configuring Global Load Balancing 182 Document ID: AD_01_06_UG 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: 1. From the main window, select APSolute OS > Traffic Redirection. The Traffic Redirection 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. This section includes the following topics: Redirection Methods, page 183 DNS Redirection, page 183 HTTP Redirection, page 192 RTSP Redirection, page 194 SIP Redirection, page 194 Proxy Redirection, page 195 AppDirector User Guide Configuring Global Load Balancing Document ID: AD_01_06_UG 183 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: AppDirector User Guide Configuring Global Load Balancing 184 Document ID: AD_01_06_UG 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). AppDirector User Guide Configuring Global Load Balancing Document ID: AD_01_06_UG 185 >> 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 1. From the main window select APSolute OS > Traffic Redirection. The Traffic Redirection window appears. 2. Click Add. The Farm window appears. 3. Select Redirection. The Redirection pane appears. 4. Set the following parameters according to the explanations provided: 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. AppDirector User Guide Configuring Global Load Balancing 186 Document ID: AD_01_06_UG 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: 1. From the main window select APSolute OS > Traffic Redirection. The Traffic Redirection window appears. 2. Click Add. The Farm window appears. 3. Select Redirection. The Redirection pane appears. 4. In the Application Redirection settings, set the Application Redirection parameter to DNS Fallback Redirection. 5. Click OK. Your preferences are recorded. 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: 1. In the main window, select APSolute OS > Traffic Redirection. The Traffic Redirection 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. 5. Click OK. Your preferences are recorded. 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: AppDirector User Guide Configuring Global Load Balancing Document ID: AD_01_06_UG 187 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: 1. From the main window, select APSolute OS > Traffic Redirection. The Traffic Redirection 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. AppDirector User Guide Configuring Global Load Balancing 188 Document ID: AD_01_06_UG 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. AppDirector User Guide Configuring Global Load Balancing Document ID: AD_01_06_UG 189 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. AppDirector User Guide Configuring Global Load Balancing 190 Document ID: AD_01_06_UG 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: 1. In the main window, select APSolute OS > Traffic Redirection. The Traffic Redirection 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. 4. Set the following parameters according to the explanations provided: Aging Time: Defines how many seconds an entry remains in the DNS Persistency Table. Possible values: 1 - 4,183,142,400 seconds (136 years). Default value: 60 seconds. 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: Select one of the following: Disabled: Disables DNS Persistency. Enabled: Enables DNS Persistency. Note: Before enabling DNS Persistency, set tuning for the DNS Persistency Table. Default value: Disabled. AppDirector User Guide Configuring Global Load Balancing Document ID: AD_01_06_UG 191 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: 1. In the main window, select APSolute OS > Traffic Redirection. The Traffic Redirection 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. 4. Set the following parameters according to the explanations provided: Static Mode: Select one of the following: Disabled: Disables Static DNS Persistency. Enabled: Enables Static DNS Persistency. Note: Before enabling Static DNS Persistency, set tuning for the Static DNS Persistency Table. Default value: Disabled. 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. AppDirector User Guide Configuring Global Load Balancing 192 Document ID: AD_01_06_UG Note: Before adding entries to the Static DNS Persistency Table, you must enable DNS Persistency and Static DNS Persistency. 5. Click OK. Your preferences are recorded. Tuning the DNS Persistency Tables You can tune the size of the Static and DNS Persistency Tables. To tune DNS Persistency Tables 1. In the main window, right-click the AppDirector device icon and select SetUp. The SetUp window appears. 2. Select Global > DNS Settings and click Edit Settings. The DNS Settings window appears. 3. Set the following parameters according to the explanations provided: 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. AppDirector User Guide Configuring Global Load Balancing Document ID: AD_01_06_UG 193 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: 1. From the main window, select APSolute OS > Traffic Redirection. The Traffic Redirection window appears. 2. Click on a farm. The Farm window appears. 3. Select Redirection. The Redirection pane 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: 1. From the main window, select APSolute OS > Traffic Redirection. The Traffic Redirection window appears. 2. Click on a farm. The Farm window appears. 3. Select Redirection. The Redirection pane appears. 4. In the Application Redirection settings, from the Application Redirection dropdown list, select Enable. AppDirector User Guide Configuring Global Load Balancing 194 Document ID: AD_01_06_UG 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). AppDirector User Guide Configuring Global Load Balancing Document ID: AD_01_06_UG 195 To define SIP redirection 1. In the main window, select APSolute OS > Traffic Redirection. The Traffic Redirection window appears. 2. Click on a farm. The Farm window appears. 3. Select Redirection. The Redirection pane appears. 4. In the Application Redirection settings, from the Application Redirection dropdown list, select 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: 1. In the main window, select APSolute OS > Traffic Redirection. The Traffic Redirection window appears. 2. Click on a farm. The Farm window appears in Traffic Settings mode. 3. Select Redirection. The Redirection pane appears. 4. In the Application Redirection settings, from the Application Redirection dropdown list, select Enable. AppDirector User Guide Configuring Global Load Balancing 196 Document ID: AD_01_06_UG 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 AppDirector User Guide Configuring Global Load Balancing Document ID: AD_01_06_UG 197 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 User Guide Configuring Global Load Balancing 198 Document ID: AD_01_06_UG 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 1. From the main window, select APSolute OS > Traffic Redirection. The Traffic Redirection window appears. 2. Click Add. The Farm window appears. 3. Select Redirection. The Redirection pane appears. 4. In the Application Redirection settings, from the Application Redirection dropdown list, select 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. 3. Select Advanced Settings > Edit Settings. The Advanced Settings window 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. AppDirector User Guide Configuring Global Load Balancing Document ID: AD_01_06_UG 199 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." AppDirector User Guide Configuring Global Load Balancing 200 Document ID: AD_01_06_UG 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. 3. In the main window, select APSolute OS > Traffic Redirection. The Traffic Redirection 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. 6. Set the following parameters according to the explanations provided: 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. AppDirector User Guide Configuring Global Load Balancing Document ID: AD_01_06_UG 201 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. 3. Set the following parameters according to the explanations provided: 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. AppDirector User Guide Configuring Global Load Balancing 202 Document ID: AD_01_06_UG 4. Click OK. Your preferences are recorded. 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 1. In the main window, right-click the AppDirector device icon and select SetUp. The SetUp 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. AppDirector User Guide Configuring Global Load Balancing Document ID: AD_01_06_UG 203 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 1. Right-click the AppDirector device icon and select SetUp. The SetUp window appears. 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. AppDirector User Guide Configuring Global Load Balancing 204 Document ID: AD_01_06_UG 6. Click OK. Your preferences are recorded. 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 User Guide Configuring Global Load Balancing Document ID: AD_01_06_UG 205 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. 3. Click Apply > OK. Your preferences are recorded. 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 value: Disabled. 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 value: 20 seconds. Optional values, 6 - 40 seconds. 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. AppDirector User Guide Configuring Global Load Balancing 206 Document ID: AD_01_06_UG 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: 3. Click Apply > OK. Your preferences are recorded. 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. Default value: 128. Optional values, 0 - 240 in multiples of 16. 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. AppDirector User Guide Configuring Global Load Balancing Document ID: AD_01_06_UG 207 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. 4. Click Apply > OK. Your preferences are recorded. 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. Default value: 32768. Optional values, 0 - 61440 in multiples of 4096. Bridge Maximum Aging [sec.]: Maximum time, in seconds, that the device waits for a BPDU packet before it tries to re-configure. Default value: 20 seconds. Optional values, 6 - 40 seconds. Hello Time Interval [sec.]: Interval, in seconds, between two BPDU packets sent by the device. Default value: 2 seconds. Optional values, 1 - 10 seconds. 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. AppDirector User Guide Configuring Global Load Balancing 208 Document ID: AD_01_06_UG Document ID: AD_01_06_UG 209 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 the following topics: 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 User Guide AppDirector Advanced Configuration 210 Document ID: AD_01_06_UG 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. AppDirector User Guide AppDirector Advanced Configuration Document ID: AD_01_06_UG 211 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. 2. Click Global. The Global pane 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 explanations provided: 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 AppDirector User Guide AppDirector Advanced Configuration 212 Document ID: AD_01_06_UG 5. Click OK. Your preferences are recorded. 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. AppDirector User Guide AppDirector Advanced Configuration Document ID: AD_01_06_UG 213 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 AppDirector User Guide AppDirector Advanced Configuration 214 Document ID: AD_01_06_UG 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. AppDirector User Guide AppDirector Advanced Configuration Document ID: AD_01_06_UG 215 Note: Client Table mirroring for Outbound NAT entries is not supported. To configure Outbound NAT: 1. From the main APSolute Insite window, right-click the AppDirector device icon and select SetUp. The SetUp window appears. 2. Click Global. The Global pane appears. 3. Select NAT Settings > Edit Settings. The NAT Settings window appears. 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: 1. From the main APSolute Insite window, right-click the AppDirector device icon and select SetUp. The SetUp window appears. 2. Click Global. The Global pane appears. 3. Select NAT Settings > Edit Settings. The NAT Settings window appears. 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. AppDirector User Guide AppDirector Advanced Configuration 216 Document ID: AD_01_06_UG 4. To enable Outbound NAT, in the NAT Settings window, select Outbound NAT. 5. Click OK twice to close the windows. 6. In the main window, select APSolute OS > Traffic Redirection. The Traffic Redirection 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. Default value: 60 seconds. 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. AppDirector User Guide AppDirector Advanced Configuration Document ID: AD_01_06_UG 217 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. AppDirector User Guide AppDirector Advanced Configuration 218 Document ID: AD_01_06_UG 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 AppDirector User Guide AppDirector Advanced Configuration Document ID: AD_01_06_UG 219 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: 1. Right-click the AppDirector device icon and select SetUp. The SetUp window appears. 2. Click Global. The Global pane appears. 3. Select NAT Settings > Edit Settings. The NAT Settings window appears. 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. 4. Set the following parameters according to the explanations provided: 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. 6. Click OK. Your preferences are recorded. 7. In the main window, select APSolute OS > Traffic Redirection. The Traffic Redirection 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. AppDirector User Guide AppDirector Advanced Configuration 220 Document ID: AD_01_06_UG 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. AppDirector User Guide AppDirector Advanced Configuration Document ID: AD_01_06_UG 221 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 AppDirector User Guide AppDirector Advanced Configuration 222 Document ID: AD_01_06_UG h. Click OK. Your preferences are recorded. 2. Add two servers: a. From the main window, select Device > Servers > Server. A server icon appears. b. Double-click the Server icon. The Server window appears. c. Set the following parameters according to the explanations provided:
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: h. Click OK. Your preferences are recorded. 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. 5. Add a new Layer 4 Policy to AppDirector: 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 AppDirector User Guide AppDirector Advanced Configuration Document ID: AD_01_06_UG 223 a. Right-click the AppDirector icon and select APSolute OS > Traffic Redirection. The Traffic Redirection window appears. b. Click L4 Policies. The L4 Policies pane appears. c. Click Add. The L4 Policies window appears. 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: c. Click OK.Your preferences are recorded. 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 AppDirector User Guide AppDirector Advanced Configuration 224 Document ID: AD_01_06_UG 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. AppDirector User Guide AppDirector Advanced Configuration Document ID: AD_01_06_UG 225 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 AppDirector User Guide AppDirector Advanced Configuration 226 Document ID: AD_01_06_UG
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. Default value: Enabled. 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. AppDirector User Guide AppDirector Advanced Configuration Document ID: AD_01_06_UG 227 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. f. Click Add. The Interface window appears. g. Set the following parameters according to the explanations provided: h. Click OK. Your preferences are recorded. 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.) AppDirector User Guide AppDirector Advanced Configuration 228 Document ID: AD_01_06_UG 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: e. Click OK. Your preferences are recorded. 3. Add the first server to the map: a. From the main window, select Device > Servers > Server. A server icon appears. b. Double-click the Server icon. The Server window appears. c. Set the following parameters according to the explanations provided: 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. c. Set the following parameters according to the explanations provided: d. Click Add and OK. Your preferences are recorded. 5. Add a server farm to AppDirector: a. From 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: 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 AppDirector User Guide AppDirector Advanced Configuration Document ID: AD_01_06_UG 229 g. Click OK twice to return to the main window. 6. Add a new Layer 4 Policy to AppDirector: a. Right-click the AppDirector device icon and select APSolute OS > Traffic Redirection. The Traffic Redirection window appears. 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 201.1.1.100 and click Add. The Add L4 Policy window appears. e. Set the following parameters according to the explanations provided: 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. 8. Add a new Layer 4 Policy to AppDirector: 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. d. Set the following parameters according to the explanations provided: 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 AppDirector User Guide AppDirector Advanced Configuration 230 Document ID: AD_01_06_UG b. Select the Farm 1 entry and click Edit. The Farm window appears. c. Click Add. The Farm Servers window appears. d. Set the following parameter according to the explanation provided: e. Click OK twice to return to the Traffic Redirection window. 10. Add Server 1 to Farm 2: a. Click Farms. The Farms pane appears. b. Select the Farm 2 entry and click Edit. The Farm window appears. c. In the Farm window, click Add. The Farm Servers window appears. d. Set the following parameter according to the explanation provided: e. Click OK twice to return to the Traffic Redirection window. 11. Add Server 2 to Farm 2: a. Click Farms. The Farms pane appears. b. Select the Farm 2 entry and click Edit. The Farm window appears. c. Click Add. The Farm Servers window appears. d. Set the following parameter according to the explanation provided: e. Click OK twice to return to the Traffic Redirection window. 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. c. Set the following parameters according to the explanations provided: d. Click Add and OK. Your preferences are recorded. 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. e. Click OK. Your preferences are recorded. 14. Add the second 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. c. Set the following parameters according to the explanations provided: Server Name: Server 2 Server Name: Server 1 Server Name: Server 2 Next Hop Router Name: Router 1 IP Address: 201.1.1.20 AppDirector User Guide AppDirector Advanced Configuration Document ID: AD_01_06_UG 231 d. Click Add and OK. 15. Configure Router 2 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 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 AppDirector User Guide AppDirector Advanced Configuration 232 Document ID: AD_01_06_UG 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 AppDirector User Guide AppDirector Advanced Configuration Document ID: AD_01_06_UG 233 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. f. Click Add. The Interface window appears. g. Set the following parameters according to the explanations provided: h. Click OK. Your preferences are recorded. 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. c. Set the following parameters according to the explanations provided: 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. b. Double-click the Server icon. The Server window appears. c. Set the following parameters according to the explanations provided: d. Click Add and OK. 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 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 AppDirector User Guide AppDirector Advanced Configuration 234 Document ID: AD_01_06_UG 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: d. Click Add and OK. Your preferences are recorded. 5. Add a server farm to AppDirector: a. From 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: 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. 6. Add a new Layer 4 Policy to AppDirector: a. Right-click the AppDirector icon and select APSolute OS > Traffic Redirection. The Traffic Redirection window appears. b. Click the L4 Policies tab. The L4 Policies pane appears. c. Click Add. The L4 Policies window appears. d. In the VIP Address field, enter 201.1.1.100 and click Add. The Add L4 Policy window appears. e. Set the following parameters according to the explanations provided: f. Click OK twice to return to the Traffic Redirection window. 7. Add the second server farm to AppDirector: a. Click Farms. The Farms pane appears. Server Name: Server 2 IP Address: 10.1.1.2 FarmName: Farm 1 Dispatch Method: Least amount of traffic-Local Redirection Mode: HTTP Redirect By Name: Enable L4 Protocol: TCP L4 Port: 80 L4 Policy Name: Policy 1 FarmName: Farm 1 AppDirector User Guide AppDirector Advanced Configuration Document ID: AD_01_06_UG 235 b. Click Add. The Farm window appears. c. Set the following parameter according to the explanation provided: d. Click Traffic Settings. The Traffic Settings pane appears. e. Set the following parameters according to the explanations provided: f. Click OK. Your preferences are recorded. 8. Add a new Layer 4 Policy to AppDirector: a. Right-click the AppDirector icon and select APSolute OS > Traffic Redirection. The Traffic Redirection window appears. b. Click the L4 Policies tab. The L4 Policies pane appears. c. Click Add. The L4 Policies window appears. d. In the VIP Address field, enter 202.2.2.100 and click Add. The Add L4 Policy window appears. e. Set the following parameters according to the explanations provided: f. Click OK twice to return to the Traffic Redirection window. 9. Add Server 1 to Farm 1: a. Click Farms. The Farms pane appears. b. Select the Farm 1 entry and click Edit. The Farm window appears. c. Select the Farm Servers pane and click Add. The Farm Servers window appears. d. Set the following parameter according to the explanation provided: e. Click OK twice to return to the Traffic Redirection window. 10. Add Server 2 to Farm 1: a. In the Traffic Redirection window, click Farms. The Farms pane appears. b. Select the Farm 1 entry and click Edit. The Farm 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: Least amount of traffic-Local 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 AppDirector User Guide AppDirector Advanced Configuration 236 Document ID: AD_01_06_UG d. In the Farm Servers window, set the following parameter according to the explanation provided: e. Click OK twice to return to the Traffic Redirection window. 11. Configure Farm 2 as a server to Farm 1: a. In the Traffic Redirection window, click Farms. The Farms pane appears. b. Select Farm 1 entry and click Edit. The Farm window appears. c. Select the Farm Servers pane and click Add. The Farm Servers window appears. d. Set the following parameter according to the explanation provided: e. Click OK twice to return to the Traffic Redirection window. 12. Add Server 1 to Farm 2: a. In the Traffic Redirection window, click Farms. The Farms pane appears. b. Select the Farm 2 entry and click Edit. The Farm window appears. c. Click the Farm Servers pane and click Add. The Farm Servers window appears. d. Set the following parameter according to the explanation provided: e. Click OK twice to return to the Traffic Redirection window. 13. Add Server 2 to Farm 2: a. In the Traffic Redirection window, click Farms. The Farms pane appears. b. Select the Farm 2 entry and click Edit. The Farm window appears. c. Select the Farm Servers pane and click Add. The Farm Servers window appears. d. Set the following parameter according to the explanation provided: e. Click OK twice. Your preferences are recorded. 14. Configure Farm 1 as a server to Farm 2: a. In the Traffic Redirection window, click Farms. The Farms pane appears. b. Select the Farm 2 entry and click Edit. The Farm window appears. c. Select the Farm Servers pane and click Add. The Farm Servers window appears. d. Set the following parameter according to the explanation provided: 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. b. Double-click the NHR icon. The Next Hop Router window appears. c. Set the following parameters according to the explanations provided: Server Name: Server 2 Server Name: Farm2 Server Name: Server 1 Server Name: Server 2 Server Name: Farm 1 AppDirector User Guide AppDirector Advanced Configuration Document ID: AD_01_06_UG 237 d. Click Add and OK. Your preferences are recorded. 16. Configure Router 1 on AppDirector: 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: f. Click OK. Your preferences are recorded. 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. c. Set the following parameters according to the explanations provided: d. Click Add and OK. 18. Configure Router 2 on AppDirector: 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 AppDirector User Guide AppDirector Advanced Configuration 238 Document ID: AD_01_06_UG 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 AppDirector User Guide AppDirector Advanced Configuration Document ID: AD_01_06_UG 239 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. AppDirector User Guide AppDirector Advanced Configuration 240 Document ID: AD_01_06_UG c. In the Device IP Address field, enter 10.10.10.10. d. Check Offline Device. e. Click OK. Your preferences are recorded. 2. Add the first server to the site: a. From the Device menu select Servers > Server. A server icon appears on the map. b. Double-click the Server icon. The Server window appears. c. Set the following parameters according to the explanations provided: d. Click Add and OK. Your preferences are recorded. 3. Add the second server to the site: a. From the Device menu select Servers > Server. A server icon appears on the map. b. Double-click the Server icon. The Server window appears. c. Set the following parameters according to the explanations provided: d. Click Add and OK. Your preferences are recorded. 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. c. Set the following parameters according to the explanations provided: d. Click Add and OK. Your preferences are recorded. 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: a. From the main window, select APSolute OS > Traffic Redirection. The Traffic Redirection window appears. b. Click Segmentation. The Segmentation pane appears. c. Set the following parameter according to the explanation provided: 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 AppDirector User Guide AppDirector Advanced Configuration Document ID: AD_01_06_UG 241 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 explanations provided: c. Click OK.Your preferences are recorded. 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 explanations provided: f. Click OK. Your preferences are recorded. 7. Add a 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: 8. Add a new Layer 4 Policy to AppDirector: a. Right-click the AppDirector icon and select APSolute OS > Traffic Redirection. The Traffic Redirection window appears. b. Click L4 Policies. The L4 Policies pane appears. c. Click Add. The L4 Policies window appears. d. In the VIP Address field, enter 10.10.10.100 and click Add. The Add L4 Policy window appears. e. Set the following parameters according to the explanations provided: 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 AppDirector User Guide AppDirector Advanced Configuration 242 Document ID: AD_01_06_UG 9. Add the second server farm to AppDirector: a. From the main window, select APSolute Insite > 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: e. Click OK. Your preferences are recorded. 10. Add the second Layer 4 Policy to AppDirector: a. Right-click the AppDirector icon and select APSolute OS > Traffic Redirection. The Traffic Redirection window appears. b. Click L4 Policies. The L4 Policies pane appears. c. Click Add. The L4 Policies window appears. d. In the VIP Address field, enter 20.20.20.100 and click Add. The Add L4 Policy window appears. e. Set the following parameters according to the explanations provided: 11. Add Server 1 to Farm 1: a. In the Traffic Redirection window, click Farms. The Farms pane appears. b. Select the server farm and click Edit. The Farm window appears. c. Select the Farm Servers pane and click Add. The Farm Servers window appears. d. Set the following parameter according to the explanation provided: 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 AppDirector User Guide AppDirector Advanced Configuration Document ID: AD_01_06_UG 243 12. Add Server 2 to Farm 2: a. In the Traffic Redirection window, click Farms. The Farms pane appears. 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. d. Set the following parameter according to the explanation provided: 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 AppDirector User Guide AppDirector Advanced Configuration 244 Document ID: AD_01_06_UG 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. AppDirector User Guide AppDirector Advanced Configuration Document ID: AD_01_06_UG 245 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: 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 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). AppDirector User Guide AppDirector Advanced Configuration 246 Document ID: AD_01_06_UG 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 AppDirector User Guide AppDirector Advanced Configuration Document ID: AD_01_06_UG 247 Session Initiation Protocol (SIP) This section explains load balancing and maintaining client-server persistency for SIP servers and includes the following topics: 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. AppDirector User Guide AppDirector Advanced Configuration 248 Document ID: AD_01_06_UG 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: 1. From the main APSolute Insite window, right-click the AppDirector device icon and select SetUp. The SetUp window appears. 2. Select Networking > NTP. The Network Time Protocol Preferences window appears. 3. Set the following parameters according to the explanations provided: NTP Server Address: Address of the NTP server. Active (checkbox): Enables or disables the NTP feature. Default value: Disabled. NTP Server Address must be configured to enable the NTP feature. NTP Port: The NTP server port. Default value:123. AppDirector User Guide AppDirector Advanced Configuration Document ID: AD_01_06_UG 249 4. Click Apply and OK. Your preferences are recorded. 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. AppDirector User Guide AppDirector Advanced Configuration 250 Document ID: AD_01_06_UG Document ID: AD_01_06_UG 251 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 This section includes the following topics: 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. AppDirector User Guide Configuring Redundancy 252 Document ID: AD_01_06_UG 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 AppDirector User Guide Configuring Redundancy Document ID: AD_01_06_UG 253 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. AppDirector User Guide Configuring Redundancy 254 Document ID: AD_01_06_UG 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. 2. Click Redundancies. The Redundancies window appears. 3. Click Copy Configuration. The Copy Configuration window appears. 4. Set the following parameters according to the explanations provided: AppDirector User Guide Configuring Redundancy Document ID: AD_01_06_UG 255 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: 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. 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. AppDirector User Guide Configuring Redundancy 256 Document ID: AD_01_06_UG To define Interface Grouping behavior in VLANs: 1. From the main APSolute Insite window, right-click the AppDirector icon and select SetUp. The SetUp window appears. 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. Default by Type (default value): 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. Default by Type (default value): 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. AppDirector User Guide Configuring Redundancy Document ID: AD_01_06_UG 257 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: 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 the active AppDirector device and select SetUp. The SetUp window appears. 5. Click Redundancies. The Redundancies window appears. 6. Select IP Active-Active or VRRP Active-Active from the Relation Type field and click Mirroring. The Mirroring window appears. 7. Set the following parameters according to the explanations provided: 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. AppDirector User Guide Configuring Redundancy 258 Document ID: AD_01_06_UG 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: 10. Click OK to apply the settings and close the window. 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. AppDirector User Guide Configuring Redundancy Document ID: AD_01_06_UG 259 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. 4. Set the following parameters according to the explanations provided: 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. AppDirector User Guide Configuring Redundancy 260 Document ID: AD_01_06_UG 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. AppDirector User Guide Configuring Redundancy Document ID: AD_01_06_UG 261 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: 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, select VRRP. 7. To assign virtual routers to both the primary and backup devices, click Add VRID. The Edit VRRP Table window appears. 8. Set the following parameters according to the explanations provided: 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. AppDirector User Guide Configuring Redundancy 262 Document ID: AD_01_06_UG 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. 11. Click OK to apply the settings and close the window. 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. Default value: Disabled. 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. Default value: No 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). AppDirector User Guide Configuring Redundancy Document ID: AD_01_06_UG 263 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 AppDirector User Guide Configuring Redundancy 264 Document ID: AD_01_06_UG 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. All VIPs should be set to redundancy mode - Backup Outbound NAT should be set to redundancy mode - Backup Routers or Switches Switch IP VLAN on AppDirector -L Server Server Switch IP VLAN on AppDirector-R External Side Internal Side AppDirector User Guide Configuring Redundancy Document ID: AD_01_06_UG 265 Interface Grouping Configurations: Interface Grouping-Enabled Backup interface grouping- Enabled Selective interface grouping - only interfaces that are within a VR should be associated. Interface Grouping-Enabled 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: AppDirector User Guide Configuring Redundancy 266 Document ID: AD_01_06_UG VRRP Active-Backup Routing Preemption Disabled VRRP Active-Backup VLAN 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. All VIPs should be set to redundancy mode - Primary Outbound NAT should be set to redundancy mode - Active. Interface Grouping Configurations: Interface Grouping-Enabled Selective interface grouping - only interfaces that are within a VR should be Backup interface grouping- 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 Tables - Tabled for 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- 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: Active Backup L4 Policies Configurations: All VIPs should be set to redundancy mode - Primary Outbound NAT IPs should be set to redundancy mode - Active. All VIPs should be set to redundancy mode - Backup Outbound NAT should be set to redundancy mode - Backup AppDirector User Guide Configuring Redundancy Document ID: AD_01_06_UG 267 VRRP Active-Backup VLAN Preemption Disabled Interface Grouping Configurations: Interface Grouping-Enabled Backup interface grouping- Enabled Selective interface grouping - only interfaces that are within a VR should be associated. Interface Grouping-Enabled 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: 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 When working with Regular VLAN 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: 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: Active Backup L4 Policies Configurations: All VIPs should be set to redundancy mode - Primary Outbound NAT IPs should be set to redundancy mode - Active. All VIPs should be set to redundancy mode - Primary Outbound NAT should be set to redundancy mode - Active. AppDirector User Guide Configuring Redundancy 268 Document ID: AD_01_06_UG Interface Grouping Configurations: Interface Grouping-Enabled Selective interface grouping - only interfaces that are within a VR should be Backup interface grouping- Enabled Interface Grouping -Enabled 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 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- 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: 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 When Force Port Down is enabled on Active device it should be enabled on backup. VLAN interface grouping - The same ports that were excluded 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: 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: AppDirector User Guide Configuring Redundancy Document ID: AD_01_06_UG 269 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 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: Interface Grouping-Enabled Backup interface grouping- Disabled Selective interface grouping - only interfaces that are within a VR should be associated. Interface Grouping-Enabled Backup interface Grouping- Disabled 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 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-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: AppDirector User Guide Configuring Redundancy 270 Document ID: AD_01_06_UG 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 includes the following topics: 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. AppDirector User Guide Configuring Redundancy Document ID: AD_01_06_UG 271 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: All VIPs should be set to redundancy mode - Primary Outbound NAT IPs should be set to redundancy mode - Active. All VIPs should be set to redundancy mode - Backup Outbound NAT should be set to redundancy mode - Backup Interface Grouping Configurations: Interface Grouping-Enabled Backup interface grouping-Disabled Selective interface grouping - only interfaces that are within a VR should be associated. Interface Grouping-Disabled 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: 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. AppDirector User Guide Configuring Redundancy 272 Document ID: AD_01_06_UG Proprietary Active-Backup VLAN Active Backup L4 Policies Configurations: All VIPs should be set to redundancy mode - Primary Outbound NAT IPs should be set to redundancy mode - Active. All VIPs should be set to redundancy mode - Backup Outbound NAT should be set to redundancy mode - Backup Interface Grouping Configurations: Interface Grouping-Enabled Backup interface grouping- Disabled Selective interface grouping - only interfaces that are within a VR should be associated. Interface Grouping-Disabled 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: 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 When working with Regular VLAN 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. AppDirector User Guide Configuring Redundancy Document ID: AD_01_06_UG 273 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: Interface Grouping-Enabled Backup interface grouping- Disabled Selective interface grouping - only interfaces that are within a VR should be associated. Interface Grouping-Enabled Backup interface Grouping- Disabled 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 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- 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: AppDirector User Guide Configuring Redundancy 274 Document ID: AD_01_06_UG 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: 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 the backup AppDirector icon and select SetUp. The SetUp window appears. 5. Click Redundancies. The Redundancies 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. 10. Click OK. Your preferences are recorded. 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. AppDirector User Guide Configuring Redundancy Document ID: AD_01_06_UG 275 >> 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. AppDirector User Guide Configuring Redundancy 276 Document ID: AD_01_06_UG Document ID: AD_01_06_UG 277 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. AppDirector User Guide Configuring Bandwidth Management Policies and Classes 278 Document ID: AD_01_06_UG 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 AppDirector User Guide Configuring Bandwidth Management Policies and Document ID: AD_01_06_UG 279 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) AppDirector User Guide Configuring Bandwidth Management Policies and Classes 280 Document ID: AD_01_06_UG 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. AppDirector User Guide Configuring Bandwidth Management Policies and Document ID: AD_01_06_UG 281 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. AppDirector User Guide Configuring Bandwidth Management Policies and Classes 282 Document ID: AD_01_06_UG 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. 3. Set the following parameters according to the explanations provided: 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. 2. In the main window, select APSolute OS > BWManagement. The Bandwidth Management 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. AppDirector User Guide Configuring Bandwidth Management Policies and Document ID: AD_01_06_UG 283 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. AppDirector User Guide Configuring Bandwidth Management Policies and Classes 284 Document ID: AD_01_06_UG 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 AppDirector User Guide Configuring Bandwidth Management Policies and Document ID: AD_01_06_UG 285 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 yahoo-msg2 Yahoo Messenger on port 5050 Basic yahoo-msg3 Yahoo Messenger on port 5100 Basic Email mail Group smtp Basic imap Basic pop3 Basic Table 37: Pre-Defined BWM Filters Service Name Description Filter Name AppDirector User Guide Configuring Bandwidth Management Policies and Classes 286 Document ID: AD_01_06_UG 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 1. In the main window, select APSolute OS > BWManagement. The Bandwidth Management window appears. 2. Click the BWM Parameters button. The BWM Global Parameters window appears. 3. Set the following parameters according to the explanations provided: AppDirector User Guide Configuring Bandwidth Management Policies and Document ID: AD_01_06_UG 287 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. AppDirector User Guide Configuring Bandwidth Management Policies and Classes 288 Document ID: AD_01_06_UG 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. AppDirector User Guide Configuring Bandwidth Management Policies and Document ID: AD_01_06_UG 289 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. f. Click OK. Your preferences are recorded. 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. d. Set the following parameters according to the explanations provided: 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 AppDirector User Guide Configuring Bandwidth Management Policies and Classes 290 Document ID: AD_01_06_UG b. Click Add Regular. The New Service pane appears. c. Set the following parameters according to the explanations provided: 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 AppDirector User Guide Configuring Bandwidth Management Policies and Document ID: AD_01_06_UG 291 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 AppDirector User Guide Configuring Bandwidth Management Policies and Classes 292 Document ID: AD_01_06_UG 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 the following topics: 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 Management window appears. 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. AppDirector User Guide Configuring Bandwidth Management Policies and Document ID: AD_01_06_UG 293 To view the results: 1. In the main window, select APSolute OS > Bandwidth Management. The Bandwidth Management window appears. 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. AppDirector User Guide Configuring Bandwidth Management Policies and Classes 294 Document ID: AD_01_06_UG Document ID: AD_01_06_UG 295 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. This section includes the following topics: 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. AppDirector User Guide Configuring Health Monitoring 296 Document ID: AD_01_06_UG 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 Server, page 301 Health Checks Per Farm, page 302 Health Checks Per Server, page 301 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. AppDirector User Guide Configuring Health Monitoring Document ID: AD_01_06_UG 297 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 Settings window appears. 4. Set the following parameters: 5. Click OK. Your preferences are recorded. 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. Default value: Enabled. 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. AppDirector User Guide Configuring Health Monitoring 298 Document ID: AD_01_06_UG 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. AppDirector User Guide Configuring Health Monitoring Document ID: AD_01_06_UG 299 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). AppDirector User Guide Configuring Health Monitoring 300 Document ID: AD_01_06_UG 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. AppDirector User Guide Configuring Health Monitoring Document ID: AD_01_06_UG 301 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. 5. Set the following parameters according to the explanations provided: 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: 1. In the main window, select APSolute OS > Traffic Redirection. The Traffic Redirection 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. AppDirector User Guide Configuring Health Monitoring 302 Document ID: AD_01_06_UG 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: 1. In the main window, select APSolute OS > Traffic Redirection. The Traffic Redirection 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 includes the following topics: Predefined Methods, page 302 User Defined Methods, page 313 Predefined Methods The following table describes the predefined Health Check Methods with the configurable parameters. AppDirector User Guide Configuring Health Monitoring Document ID: AD_01_06_UG 303 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. AppDirector User Guide Configuring Health Monitoring 304 Document ID: AD_01_06_UG 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.) AppDirector User Guide Configuring Health Monitoring Document ID: AD_01_06_UG 305 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. Table 38: Health Check Methods (cont.) AppDirector User Guide Configuring Health Monitoring 306 Document ID: AD_01_06_UG 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. Table 38: Health Check Methods (cont.) AppDirector User Guide Configuring Health Monitoring Document ID: AD_01_06_UG 307 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. Table 38: Health Check Methods (cont.) AppDirector User Guide Configuring Health Monitoring 308 Document ID: AD_01_06_UG 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. AppDirector User Guide Configuring Health Monitoring Document ID: AD_01_06_UG 309 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 AppDirector User Guide Configuring Health Monitoring 310 Document ID: AD_01_06_UG 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 C2 Valid http code 2 No C3 Valid http code 3 No C4 Valid http code 4 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 Argument Description Manda- tory Additional Info Default AppDirector User Guide Configuring Health Monitoring Document ID: AD_01_06_UG 311 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 Table 40: Health Check Method Arguments (cont.) Method Name (and ID) Argument Name Argument Description Manda- tory Additional Info Default AppDirector User Guide Configuring Health Monitoring 312 Document ID: AD_01_06_UG 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 Table 40: Health Check Method Arguments (cont.) Method Name (and ID) Argument Name Argument Description Manda- tory Additional Info Default AppDirector User Guide Configuring Health Monitoring Document ID: AD_01_06_UG 313 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. 4. Set the following parameters according to the explanations provided: 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 C2 Valid SIP code 2 No C3 Valid SIP code 3 No C4 Valid SIP code 4 No Table 40: Health Check Method Arguments (cont.) Method Name (and ID) Argument Name Argument Description Manda- tory Additional Info Default AppDirector User Guide Configuring Health Monitoring 314 Document ID: AD_01_06_UG 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 User Guide Configuring Health Monitoring Document ID: AD_01_06_UG 315 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. AppDirector User Guide Configuring Health Monitoring 316 Document ID: AD_01_06_UG 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. AppDirector User Guide Configuring Health Monitoring Document ID: AD_01_06_UG 317 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 1. In the main window, select APSolute OS > Traffic Redirection. The Traffic Redirection 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. 10. Select Advanced Settings > Edit Settings. The Advanced Settings window 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. AppDirector User Guide Configuring Health Monitoring 318 Document ID: AD_01_06_UG To set up connectivity checks using the UDP Port method 1. In the main window, select APSolute OS > Traffic Redirection. The Traffic Redirection 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. 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. To set up connectivity checks using the RADIUS method 1. In the main window, select APSolute OS > Traffic Redirection. The Traffic Redirection 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. 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. AppDirector User Guide Configuring Health Monitoring Document ID: AD_01_06_UG 319 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 1. In the main window, select APSolute OS > Traffic Redirection. The Traffic Redirection window appears. 2. In the Farms pane, double-click to select a farm. The Farm 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. AppDirector User Guide Configuring Health Monitoring 320 Document ID: AD_01_06_UG e. Click OK. The HTTP Content Check window closes. 11. In the Farm window, click Apply and OK. The Farm window closes. 12. In the Traffic Redirection window, click Apply and OK. The Traffic Redirection window closes. 13. Double-click the device icon. The SetUp window appears. 14. In the SetUp window, select Global. The Global pane appears. 15. Select Advanced Settings > Edit Settings. The Advanced Settings window 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. 4. Click OK to apply the configuration. 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. Document ID: AD_01_06_UG 321 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. AppDirector User Guide Security 322 Document ID: AD_01_06_UG 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. AppDirector User Guide Security Document ID: AD_01_06_UG 323 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. Default value: 5 seconds. AppDirector User Guide Security 324 Document ID: AD_01_06_UG 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 1. From the main APSolute Insite window, right-click the AppDirector device icon and select 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. 5. Click OK. Your preferences are recorded. 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. AppDirector User Guide Security Document ID: AD_01_06_UG 325 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. AppDirector User Guide Security 326 Document ID: AD_01_06_UG 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. AppDirector User Guide Security Document ID: AD_01_06_UG 327 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. The SetUp window appears. b. Click Global. The Global pane appears. 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 1. Open the Security Settings window: a. From the main APSolute Insite window, select APSolute OS > Security. The Connect & Protect Table window appears. 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. AppDirector User Guide Security 328 Document ID: AD_01_06_UG Or: a. From the main APSolute Insite window, right-click the AppDirector icon and select SetUp. The SetUp window appears. b. Click Global. The Global pane appears. c. Select Security Settings and click Edit Settings. The Security Settings window appears. 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 the explanations provided: 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 1. Open the Security Settings window: 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. AppDirector User Guide Security Document ID: AD_01_06_UG 329 a. From the main APSolute Insite window, select APSolute OS > Security. The Connect & Protect Table window appears. b. In the top right-hand corner of the Connect & Protect Table window, click the Settings button. The Security Settings window appears. Or: a. From the main APSolute Insite window, right-click the AppDirector icon and select SetUp. The SetUp window appears. b. Click Global. The Global pane appears. c. Select Security Settings and click Edit Settings. The Security Settings window appears. 2. In the Modules pane of Security Settings, set the following parameters according to the explanations provided: 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 1. From the main APSolute Insite window, right-click the AppDirector device icon and select APSolute OS > Security. The Connect & Protect Table window appears. 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 1. From the main APSolute Insite window, right-click the AppDirector device icon and select APSolute OS > Security. The Connect & Protect Table window appears. 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. AppDirector User Guide Security 330 Document ID: AD_01_06_UG 2. Double-click inside the Port/VLAN column. The Settings pane appears. 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 1. From the main APSolute Insite window, right-click the AppDirector device icon and select APSolute OS > Security. The Connect & Protect Table window appears. 2. Double-click inside the Port/VLAN column. The Settings pane appears. 3. Click Add VLAN Tag Group. The Edit VLAN Tag Group window appears. 4. Set the following parameters according to the explanations provided: 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 1. From the main APSolute Insite window, right-click the AppDirector device icon and select APSolute OS > Security. The Connect & Protect Table window appears. 2. Double-click inside the Networks column. The Settings pane appears. 3. Click Add Network. The Edit Network Table window appears. 4. Set the following parameters according to the explanations provided: 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. AppDirector User Guide Security Document ID: AD_01_06_UG 331 5. Click OK. Your preferences are recorded. To define a network from the predefined list 1. From the main APSolute Insite window, right-click the AppDirector device icon and select APSolute OS > Security. The Connect & Protect Table window appears. 2. Double-click inside the Networks column. The Settings pane appears. 3. Set the following parameters according to the explanations provided: 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. AppDirector User Guide Security 332 Document ID: AD_01_06_UG 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. AppDirector User Guide Security Document ID: AD_01_06_UG 333 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 from miscellaneous vendors. SQL_AS: This contains attack signatures that exploit vulnerabilities in miscellaneous SQL servers. They prevent the exploitation of vulnerabilities found in SQL implementations from miscellaneous vendors. 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 from miscellaneous vendors. POP3_AS: This contains attack signatures that exploit vulnerabilities in miscellaneous POP3 servers. They prevent the exploitation of vulnerabilities found in POP3 implementations from miscellaneous vendors. IMAP_AS: This contains attack signatures that exploit vulnerabilities in miscellaneous IMAP servers. They prevent the exploitation of vulnerabilities found in IMAP implementations from miscellaneous vendors. 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.) Attack Group Description AppDirector User Guide Security 334 Document ID: AD_01_06_UG 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.) Attack Group Description AppDirector User Guide Security Document ID: AD_01_06_UG 335 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. AppDirector User Guide Security 336 Document ID: AD_01_06_UG 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 are displayed for each selected device. 6. Click OK. The selected devices are updated. 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. AppDirector User Guide Security Document ID: AD_01_06_UG 337 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. AppDirector User Guide Security 338 Document ID: AD_01_06_UG 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>". AppDirector User Guide Security Document ID: AD_01_06_UG 339 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 are displayed for each selected device. 15. Click OK. The selected devices are updated. 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. AppDirector User Guide Security 340 Document ID: AD_01_06_UG 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). 2. From the main APSolute Insite window, select APSolute OS > Security. The Connect & Protect Table window appears. 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. AppDirector User Guide Security Document ID: AD_01_06_UG 341 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). AppDirector User Guide Security 342 Document ID: AD_01_06_UG 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. Default value: 1000. AppDirector User Guide Security Document ID: AD_01_06_UG 343 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.) AppDirector User Guide Security 344 Document ID: AD_01_06_UG To create a new attack 1. From the main window, select APSolute OS > Security. The Connect & Protect Table window appears. 2. Double-click inside the Intrusions column. The Settings pane 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.) AppDirector User Guide Security Document ID: AD_01_06_UG 345 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 Application Port Groups table. Source Port Group For UDP and TCP traffic only. Select from the list of groups configured in the Application Port Groups table. 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. Default value: 00000000. AppDirector User Guide Security 346 Document ID: AD_01_06_UG 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. Default value: 00000000. 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. Default value: None. Table 47: OMPC Definition Parameters (cont.) AppDirector User Guide Security Document ID: AD_01_06_UG 347 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. AppDirector User Guide Security 348 Document ID: AD_01_06_UG 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. Default value: None. 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. Default value: None. 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.) AppDirector User Guide Security Document ID: AD_01_06_UG 349 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 1. From the main APSolute Insite window, select APSolute OS > Security. The Connect & Protect Table window appears. 2. Double-click inside the Intrusions column. The Settings pane appears. 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 1. From the main window, select APSolute OS > Security. The Connect & Protect Table window 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. AppDirector User Guide Security 350 Document ID: AD_01_06_UG 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 1. From the main window, select APSolute OS > Security. The Connect & Protect Table window 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). 5. Click OK. Your preferences are recorded. DoS/DDoS This section introduces DoS/DDoS protection profiles and explains how to configure them. This section includes the following topics: 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. AppDirector User Guide Security Document ID: AD_01_06_UG 351 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 1. From the main window, select APSolute OS > Security. The Connect & Protect Table window 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. AppDirector User Guide Security 352 Document ID: AD_01_06_UG 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 AppDirector User Guide Security Document ID: AD_01_06_UG 353 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). 2. From the main window, select APSolute OS > Security. The Connect & Protect Table window appears. 3. Double-click inside the DoS/DDoS column. The Settings pane 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). AppDirector User Guide Security 354 Document ID: AD_01_06_UG 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 1. From the main window, select APSolute OS > Security. The Connect & Protect Table window appears. AppDirector User Guide Security Document ID: AD_01_06_UG 355 2. Double-click inside the DoS/DDoS column. The Settings pane appears. 3. Select DoS Shield Profiles. 4. Click Custom Attack. The Attack Configuration window appears. 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 Note: For each custom attack, you must define custom filters. You cannot use filters from other attacks when you define a custom attack. 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 1. From the main window, select APSolute OS > Security. The Connect & Protect Table window appears. 2. Double-click inside the DoS/DDoS column. The Settings pane appears. 3. Select DoS Shield Profiles. 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. AppDirector User Guide Security 356 Document ID: AD_01_06_UG Setting Up Application Security for DoS/DDoS Using Profiles and Groups 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 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. 4. Double-click inside the DoS/DDoS column. The Settings pane appears. 5. Select DoS Shield Profiles. 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). Setting Up Attacks and Filters 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. Note: For each custom attack, you must define custom filters. You cannot use filters from other attacks when you define a custom attack. AppDirector User Guide Security Document ID: AD_01_06_UG 357 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. 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 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. 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 >> 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 Table 47, page 345 >> For more information on Content Definition parameters, see Content Definition Parameters, page 346 To configure a new attack: 1. From the main APSolute Insite window, select APSolute OS > Security. The Connect & Protect Table window appears. 2. Double-click inside the DoS/DDoS column. The Settings pane appears. 3. Select DoS Shield Profiles. 4. Click Custom Attack. The Attack Configuration window appears. 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 The custom attack group represents a logical OR relation between two or more attacks. The right panel of the Attack Group Configuration window (Figure 29 Attack Group Configuration Window, page 358) contains a list of all the existing groups. AppDirector User Guide Security 358 Document ID: AD_01_06_UG 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. To add a new custom attack group 1. From the main APSolute Insite window, select APSolute OS > Security. The Connect & Protect Table window appears. 2. Double-click inside the DoS/DDoS column. The Settings pane appears. 3. Select DoS Shield Profiles. 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 1. From the main APSolute Insite window, select APSolute OS > Security. The Connect & Protect Table window appears. 2. Double-click inside the DoS/DDoS column. The Settings pane appears. 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. AppDirector User Guide Security Document ID: AD_01_06_UG 359 Editing Attacks To edit an attack 1. From the main APSolute Insite window, select APSolute OS > Security. The Connect & Protect Table window appears. 2. Double-click inside the DoS/DDoS column. The Settings pane appears. 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. 4. Edit the parameters of the group (see Custom Attack Groups, page 348). 5. Click OK. Your preferences are recorded. 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. AppDirector User Guide Security 360 Document ID: AD_01_06_UG 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. AppDirector User Guide Security Document ID: AD_01_06_UG 361 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. AppDirector User Guide Security 362 Document ID: AD_01_06_UG To set the Learning Response Period and Reset the Baseline 1. In the Behavioral DoS settings pane, Click Behavioral DoS Settings. The Behavioral DoS Settings window appears. 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 Settings window appears. 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 Settings window appears. 2. From the Samplings dropdown list select one of the following: 3. Click Apply and OK. Your preferences are recorded. 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. AppDirector User Guide Security Document ID: AD_01_06_UG 363 To set Footprint Strictness Levels 1. In the Behavioral DoS Settings pane, click Behavioral DoS Settings. The Behavioral DoS Settings window appears. 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. 4. Set the following parameters according to the explanations provided: 5. Click OK. Your preferences are recorded. 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. AppDirector User Guide Security 364 Document ID: AD_01_06_UG 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 AppDirector User Guide Security Document ID: AD_01_06_UG 365 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. AppDirector User Guide Security 366 Document ID: AD_01_06_UG SYN Flood Protection This section describes how SYN Flood Protection works and how to configure it. This section includes the following topics: 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. AppDirector User Guide Security Document ID: AD_01_06_UG 367 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 1. From the main APSolute Insite window, right-click the AppDirector icon and select SetUp. The SetUp window appears. 2. Click Global. The Global pane appears. 3. Select Session Table Settings > Edit Settings. The Session Table Settings window appears. 4. Set the following parameters according to the explanations provided: 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. Default value: Enabled. SYN Protection Timeout Timeout to complete the TCP three-way handshake. Range: 0-10 (0 means no timeout). Default value: 5 seconds. AppDirector User Guide Security 368 Document ID: AD_01_06_UG To enable SYN Flood protection and configure the general parameters 1. From the main APSolute Insite window, right-click the AppDirector icon and select SetUp. The SetUp window appears. 2. Click Global. The Global pane appears. 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. Range: 0-10000. Default value: 100. 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. Range: 1-100. Default value: 5. Statistics Time Period Number of seconds used to calculate average values for SYN protection statistics. Range: 1-1000. Default value: 60. Displaying Statistics of Policy All SYN Flood protection policies defined on device. Table 50: SYN Flood Protection General parameters (cont.) AppDirector User Guide Security Document ID: AD_01_06_UG 369 To view the SYN Flood order 1. From the main APSolute Insite window, right-click the AppDirector icon and select SetUp. The SetUp window appears. 2. Click Global. The Global pane appears. 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 & Protect Table window appears. 2. Double-click inside the SYN Floods column. The Settings pane appears. AppDirector User Guide Security 370 Document ID: AD_01_06_UG 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 Application Port Groups table. 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 1. From the main APSolute Insite window, select APSolute Insite > Security. The Connect & Protect Table window appears. 2. Double-click inside the SYN Floods column. The Settings pane appears. 3. From the All Regular Filters list, select the attack you wish to add. 4. Click Add. The SYN Policy Details window appears. 5. Set the following parameters according to the explanations provided: 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. AppDirector User Guide Security Document ID: AD_01_06_UG 371 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 1. From the main APSolute Insite window, select APSolute Insite > Security. The Connect & Protect Table window appears. 2. Double-click inside the SYN Floods column. The Settings pane appears. 3. Click SYN Floods Statistics. The SYN Floods Statistics window appears. 4. Set the following parameters according to the explanations provided: 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. Default value: 2500. 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. Default value: 1500. 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. AppDirector User Guide Security 372 Document ID: AD_01_06_UG 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. AppDirector User Guide Security Document ID: AD_01_06_UG 373 To view the Active Triggers Table 1. From the main APSolute Insite window, select APSolute OS > Security. The Connect & Protect Table window appears. 2. Double-click inside the SYN Floods column. The Settings pane appears. 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 AppDirector User Guide Security 374 Document ID: AD_01_06_UG 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 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. 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). 3. From the main window, select APSolute OS > Security. The Connect & Protect Table window 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). Setting Up Attacks and Filters 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). AppDirector User Guide Security Document ID: AD_01_06_UG 375 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. 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 when matched with a signature. This determines whether the packet is harmful and applies 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 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 >> 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 Table 47, page 345 >> For more information on Content Definition parameters, see Content Definition Parameters, page 346 CustomAttack 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. 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. To add a new custom attack group 1. From the main APSolute Insite window, select APSolute OS > Security. The Connect & Protect Table window appears. 2. Double-click inside the Anomalies column. The Settings pane appears. 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. AppDirector User Guide Security 376 Document ID: AD_01_06_UG To create a new user-defined anomaly profile 1. From the main APSolute Insite window, select APSolute OS > Security. The Connect & Protect Table window appears. 2. Double-click inside the Anomalies column. The Settings pane appears. 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 1. From the main APSolute Insite window, select APSolute OS > Security. The Connect & Protect Table window appears. 2. Double-click inside the Anomalies column. The Settings pane appears. 3. From the All Anomaly 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). 5. Click OK. Your preferences are recorded. 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. AppDirector User Guide Security Document ID: AD_01_06_UG 377 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 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). 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). 2. From the main APSolute Insite window, select APSolute OS > Security. The Connect & Protect Table window appears. 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. AppDirector User Guide Security 378 Document ID: AD_01_06_UG 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 1. From the main APSolute Insite window, right-click the AppDirector icon and select SetUp. The SetUp window appears. 2. Click Global. The Global pane appears. 3. Select Session Table Settings > Edit Settings. The Session Table Settings window appears. 4. Set the parameters as explained in Table 53, page 378. 5. Click OK. Your preferences are recorded. Table 53: Session Table parameters Session Table Aging Time Amount of time a non-active session is kept in the Session Table (in seconds). Default value: 100 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. AppDirector User Guide Security Document ID: AD_01_06_UG 379 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 1. From the main APSolute Insite window, select APSolute OS > Security. The Connect & Protect Table window appears. 2. Click Settings. The Security Settings window appears. 3. Click IP Fragments. The IP Fragments window appears. 4. Set the following parameters according to the explanations provided: 5. Click OK. Your preferences are recorded. AppDirector User Guide Security 380 Document ID: AD_01_06_UG IP Reassembly Status Enables/Disables the IP Reassembly feature. Default value: Disabled. 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. AppDirector User Guide Security Document ID: AD_01_06_UG 381 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 1. From the main APSolute Insite window, select APSolute OS > Security. The Connect & Protect Table window appears. 2. Click Settings. The Security Settings window appears. 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. AppDirector User Guide Security 382 Document ID: AD_01_06_UG 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 section includes the following topics: 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 1. From the main APSolute Insite window, right-click the AppDirector device icon and select SetUp. The SetUp window appears. 2. Click Global. The Global pane appears. 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. AppDirector User Guide Security Document ID: AD_01_06_UG 383 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: 9. Click OK. Your preferences are recorded. 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. AppDirector User Guide Security 384 Document ID: AD_01_06_UG 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.) AppDirector User Guide Security Document ID: AD_01_06_UG 385 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 1. From the main window, select APSolute OS > Security. The Connect & Protect Table window 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. AppDirector User Guide Security 386 Document ID: AD_01_06_UG 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. 2. Set the following parameters according to the explanations provided: 3. In the main window, select APSolute OS > Security. The Connect & Protect Table window appears. 4. Click Settings. The Security Settings 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. AppDirector User Guide Security Document ID: AD_01_06_UG 387 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 1. From the main window, select APSolute OS > Security. The Connect & Protect Table window appears. 2. Click Settings. The Security parameters window appears. 3. In the main window, select APSolute OS > Security. The Connect & Protect Table window appears. 4. Click Settings. The Security Settings window appears. 5. Click Reporting. The Reporting pane appears. 6. Check Logging. 7. Click OK. Your preferences are recorded. 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 1. From the main APSolute Insite window, select APSolute OS > Security. The Connect & Protect Table window appears. 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. AppDirector User Guide Security 388 Document ID: AD_01_06_UG 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. 4. Click OK. Your preferences are recorded. 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. AppDirector User Guide Security Document ID: AD_01_06_UG 389 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 1. In the main window, right-click the AppDirector device icon and select SetUp. The SetUp 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. AppDirector User Guide Security 390 Document ID: AD_01_06_UG Document ID: AD_01_06_UG 391 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 AppDirector User Guide Security Monitoring and Reporting 392 Document ID: AD_01_06_UG 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. AppDirector User Guide Security Monitoring and Reporting Document ID: AD_01_06_UG 393 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. AppDirector User Guide Security Monitoring and Reporting 394 Document ID: AD_01_06_UG >> 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 1. In the main window, select the device icon and click Security Reporting. The Security Reporting window appears. 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. AppDirector User Guide Security Monitoring and Reporting Document ID: AD_01_06_UG 395 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 1. In the main window, select the device icon and click Security Reporting. The Security Reporting window appears. 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. AppDirector User Guide Security Monitoring and Reporting 396 Document ID: AD_01_06_UG 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. AppDirector User Guide Security Monitoring and Reporting Document ID: AD_01_06_UG 397 To display traffic using the Mitigation view 1. In the main window, select the device icon and click Security Reporting. The Security Reporting window appears. 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 Parameter Description Misused Mitigated Aggregated ------------------------------- 100 = AppDirector User Guide Security Monitoring and Reporting 398 Document ID: AD_01_06_UG 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 1. In the main window, select the device icon and click Security Reporting. The Security Reporting window appears. 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: 1. In the main window, select the device icon and click Security Reporting. The Security Reporting window appears. 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. AppDirector User Guide Security Monitoring and Reporting Document ID: AD_01_06_UG 399 To display attacks over a predefined period of time 1. In the main window, select the device icon and click Security Reporting. The Security Reporting window appears. 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 Parameter Description 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. AppDirector User Guide Security Monitoring and Reporting 400 Document ID: AD_01_06_UG 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.) Parameter Description AppDirector User Guide Security Monitoring and Reporting Document ID: AD_01_06_UG 401 To display attack logs 1. In the main window, select the device icon and click Security Reporting. The Security Reporting window appears. 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 1. In the main window, select the device icon and click Security Reporting. The Security Reporting window appears. 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. AppDirector User Guide Security Monitoring and Reporting 402 Document ID: AD_01_06_UG Figure 37: Events Table The following table describes attacks events.
Table 59: Events Parameters Parameter Description 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. AppDirector User Guide Security Monitoring and Reporting Document ID: AD_01_06_UG 403 To display attack events 1. In the main window, select the device icon and click Security Reporting. The Security Reporting window appears. 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.) Parameter Description AppDirector User Guide Security Monitoring and Reporting 404 Document ID: AD_01_06_UG 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: 1. In the main window, select the device icon and click Security Reporting. The Security Reporting window appears. 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: AppDirector User Guide Security Monitoring and Reporting Document ID: AD_01_06_UG 405 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 1. In the main window, select the device icon and click Security Reporting. The Security Reporting window appears. 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 1. In the main window, select the device icon and click Security Reporting. The Security Reporting window appears. 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. AppDirector User Guide Security Monitoring and Reporting 406 Document ID: AD_01_06_UG 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 1. In the main window, select the device icon and click Security Reporting. The Security Reporting window appears. 2. From the Security Reporting toolbar, click Split. The attacks split view appears. AppDirector User Guide Security Monitoring and Reporting Document ID: AD_01_06_UG 407 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: 1. In the main window, select the device icon and click Security Reporting. The Security Reporting window appears. 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. AppDirector User Guide Security Monitoring and Reporting 408 Document ID: AD_01_06_UG 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. AppDirector User Guide Security Monitoring and Reporting Document ID: AD_01_06_UG 409 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 AppDirector User Guide Security Monitoring and Reporting 410 Document ID: AD_01_06_UG Table 61: HTTP Attack Characteristics Parameters Parameter Description 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. AppDirector User Guide Security Monitoring and Reporting Document ID: AD_01_06_UG 411 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 Parameter Description AppDirector User Guide Security Monitoring and Reporting 412 Document ID: AD_01_06_UG To apply the existing filter 1. In the main window, select the device icon and click Security Reporting. The Security Reporting window appears. 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: 1. In the main window, select the device icon and click Security Reporting. The Security Reporting window appears. 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 AppDirector User Guide Security Monitoring and Reporting Document ID: AD_01_06_UG 413 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 1. In the main window, select the device icon and click Security Reporting. The Security Reporting window appears. AppDirector User Guide Security Monitoring and Reporting 414 Document ID: AD_01_06_UG 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: 1. In the main window, select the device icon and click Security Reporting. The Security Reporting window appears. 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 1. In the main window, select the device icon and click Security Reporting. The Security Reporting window appears. 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) AppDirector User Guide Security Monitoring and Reporting Document ID: AD_01_06_UG 415 3. In the View Name text box, type the name of the user defined view and click Next. The Filter window appears. AppDirector User Guide Security Monitoring and Reporting 416 Document ID: AD_01_06_UG 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. AppDirector User Guide Security Monitoring and Reporting Document ID: AD_01_06_UG 417 5. In the Group By window, define attack groups as explained in Viewing Attack Groups, page 413, and click Next. The Top window appears. AppDirector User Guide Security Monitoring and Reporting 418 Document ID: AD_01_06_UG 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. AppDirector User Guide Security Monitoring and Reporting Document ID: AD_01_06_UG 419 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. This section includes the following topics: HTTP Request-URL Size Distribution, page 420 AppDirector User Guide Security Monitoring and Reporting 420 Document ID: AD_01_06_UG 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 explanations provided: 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. Default: 15 seconds. AppDirector User Guide Security Monitoring and Reporting Document ID: AD_01_06_UG 421 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. AppDirector User Guide Security Monitoring and Reporting 422 Document ID: AD_01_06_UG 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 Continues Traffic Statistics. The Continues Traffic Statistics window appears. 3. In the Continues Traffic Statistics window, set the following parameters based on the explanations provided: 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. 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. Default: 15 seconds. Parameter type(s) Type of information displayed in the graph, see Table 64, page 421. Y-axis Scale Select logarithmic or linear. AppDirector User Guide Security Monitoring and Reporting Document ID: AD_01_06_UG 423 To display the normal HTTP traffic 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 Traffic Parameters. The 24x7 Normal Traffic Statistics window appears. 3. Set the following parameters based on the explanations provided: 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: 1. In the main window, select the device icon and click Security Reporting. The Security Reporting window appears. 2. Click Map on the toolbar. The Top Attacks Geographical Maps window appears. Protected Web Server Select the IP address of the server for which you want to display the normal HTTP traffic. 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 Select logarithmic or linear. AppDirector User Guide Security Monitoring and Reporting 424 Document ID: AD_01_06_UG 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. AppDirector User Guide Security Monitoring and Reporting Document ID: AD_01_06_UG 425 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. 3. Set the following parameters based on the explanations provided: AppDirector User Guide Security Monitoring and Reporting 426 Document ID: AD_01_06_UG 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 1. In the bottom area of the main window, select Security Reporting. The Security Reporting main 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. Default: 15 seconds. 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. AppDirector User Guide Security Monitoring and Reporting Document ID: AD_01_06_UG 427 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. AppDirector User Guide Security Monitoring and Reporting 428 Document ID: AD_01_06_UG 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. AppDirector User Guide Security Monitoring and Reporting Document ID: AD_01_06_UG 429 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. AppDirector User Guide Security Monitoring and Reporting 430 Document ID: AD_01_06_UG 12. Set the following parameters according to the explanations provided: 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 AppDirector User Guide Security Monitoring and Reporting Document ID: AD_01_06_UG 431 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 AppDirector User Guide Security Monitoring and Reporting 432 Document ID: AD_01_06_UG 15. Set the following parameters based on the explanations provided: 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. AppDirector User Guide Security Monitoring and Reporting Document ID: AD_01_06_UG 433 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. AppDirector User Guide Security Monitoring and Reporting 434 Document ID: AD_01_06_UG 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 Radware Technical Glossary Document ID: APS_02_71_UG 406 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. Radware Technical Glossary 407 Document ID: APS_02_71_UG 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 APSolute Insite User Guide Radware Technical Glossary Document ID: APS_02_71_UG 408 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. Radware Technical Glossary 409 Document ID: APS_02_71_UG 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. APSolute Insite User Guide Radware Technical Glossary Document ID: APS_02_71_UG 410 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. Radware Technical Glossary 411 Document ID: APS_02_71_UG 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. APSolute Insite User Guide Radware Technical Glossary Document ID: APS_02_71_UG 412 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 Radware Technical Glossary 413 Document ID: APS_02_71_UG 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. APSolute Insite User Guide Radware Technical Glossary Document ID: APS_02_71_UG 414 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. Radware Technical Glossary 415 Document ID: APS_02_71_UG 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. APSolute Insite User Guide Radware Technical Glossary Document ID: APS_02_71_UG 416 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. Radware Technical Glossary 417 Document ID: APS_02_71_UG 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. APSolute Insite User Guide Radware Technical Glossary Document ID: APS_02_71_UG 418 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). Radware Technical Glossary 419 Document ID: APS_02_71_UG 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. APSolute Insite User Guide Radware Technical Glossary Document ID: APS_02_71_UG 420 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. Radware Technical Glossary 421 Document ID: APS_02_71_UG 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. APSolute Insite User Guide Radware Technical Glossary Document ID: APS_02_71_UG 422 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 Radware Technical Glossary 423 Document ID: APS_02_71_UG 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. APSolute Insite User Guide Radware Technical Glossary Document ID: APS_02_71_UG 424 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. Radware Technical Glossary 425 Document ID: APS_02_71_UG 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. APSolute Insite User Guide Radware Technical Glossary Document ID: APS_02_71_UG 426 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. Radware Technical Glossary 427 Document ID: APS_02_71_UG 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) APSolute Insite User Guide Radware Technical Glossary Document ID: APS_02_71_UG 428 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. Radware Technical Glossary 429 Document ID: APS_02_71_UG 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. APSolute Insite User Guide Radware Technical Glossary Document ID: APS_02_71_UG 430 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. Radware Technical Glossary 431 Document ID: APS_02_71_UG 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).
APSolute Insite User Guide Radware Technical Glossary Document ID: APS_02_71_UG 432 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.
Radware Technical Glossary 433 Document ID: APS_02_71_UG 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.
APSolute Insite User Guide Radware Technical Glossary Document ID: APS_02_71_UG 434 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. Radware Technical Glossary 435 Document ID: APS_02_71_UG 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. APSolute Insite User Guide Radware Technical Glossary Document ID: APS_02_71_UG 436 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 . Radware Technical Glossary 437 Document ID: APS_02_71_UG 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. APSolute Insite User Guide Radware Technical Glossary Document ID: APS_02_71_UG 438 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. Radware Technical Glossary 439 Document ID: APS_02_71_UG 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). APSolute Insite User Guide Radware Technical Glossary Document ID: APS_02_71_UG 440 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. Radware Technical Glossary 441 Document ID: APS_02_71_UG 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. APSolute Insite User Guide Radware Technical Glossary Document ID: APS_02_71_UG 442 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. Radware Technical Glossary 443 Document ID: APS_02_71_UG 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 APSolute Insite User Guide Radware Technical Glossary Document ID: APS_02_71_UG 444 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. Radware Technical Glossary 445 Document ID: APS_02_71_UG 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. APSolute Insite User Guide Radware Technical Glossary Document ID: APS_02_71_UG 446 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. Radware Technical Glossary 447 Document ID: APS_02_71_UG 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. APSolute Insite User Guide Radware Technical Glossary Document ID: APS_02_71_UG 448 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. Radware Technical Glossary 449 Document ID: APS_02_71_UG 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. APSolute Insite User Guide Radware Technical Glossary Document ID: APS_02_71_UG 450 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. Radware Technical Glossary 451 Document ID: APS_02_71_UG 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. APSolute Insite User Guide Radware Technical Glossary Document ID: APS_02_71_UG 452 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. Radware Technical Glossary 453 Document ID: APS_02_71_UG 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. APSolute Insite User Guide Radware Technical Glossary Document ID: APS_02_71_UG 454 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. Radware Technical Glossary 455 Document ID: APS_02_71_UG Document ID: AD_01_06_UG 487 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]"). AppDirector User Guide Regular Expressions 488 Document ID: AD_01_06_UG "^[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. Document ID: AD_01_06_UG 489 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 AppDirector User Guide Optimizing AppDirector with AppXcel Application Accelerator 490 Document ID: AD_01_06_UG 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 AppDirector User Guide Optimizing AppDirector with AppXcel Application Document ID: AD_01_06_UG 491 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) AppDirector User Guide Optimizing AppDirector with AppXcel Application Accelerator 492 Document ID: AD_01_06_UG 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 AppDirector User Guide Optimizing AppDirector with AppXcel Application Document ID: AD_01_06_UG 493 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). AppDirector User Guide Optimizing AppDirector with AppXcel Application Accelerator 494 Document ID: AD_01_06_UG 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: 3. Click Ok. Your preferences are recorded. 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. AppDirector User Guide Optimizing AppDirector with AppXcel Application Document ID: AD_01_06_UG 495 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. 4. Click Ok. Your preferences are recorded. 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. d. Set the following parameters according to the explanations provided: 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 AppDirector User Guide Optimizing AppDirector with AppXcel Application Accelerator 496 Document ID: AD_01_06_UG 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. c. Set the following parameters according to the explanations provided: 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 explanations provided: 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: :******** AppDirector User Guide Optimizing AppDirector with AppXcel Application Document ID: AD_01_06_UG 497 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 the explanations provided: 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 Redirection. The Traffic Redirection window appears. b. Click Add. The Farm window appears. c. Set the following parameters according to the explanations provided: 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. g. Set the following parameters according to the explanations provided: Server Name: For example, Server 1 IP Address: 10.1.1.1 Server Name: For example, Server 2 IP Address: 10.1.1.2 Server Name: For example, Server 3 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 AppDirector User Guide Optimizing AppDirector with AppXcel Application Accelerator 498 Document ID: AD_01_06_UG h. Repeat steps e to f to add a second AppXcel farm server and set the following parameters according to the explanations provided: 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. d. Set the following parameters according to the explanations provided: 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 parameters according to the explanations provided: 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: Define the farm name, for example: Backend-2 Active Farm: Enabled Transparent Server Support: TCP Splitting FarmName: Define the farm name, for example: Backend-3 Active Farm: Enabled Transparent Server Support: TCP Splitting AppDirector User Guide Optimizing AppDirector with AppXcel Application Document ID: AD_01_06_UG 499 c. In the VIP Address text box, enter the VIP address and click Add. The Add L4 Policy window appears. d. Set the following parameters according to the explanations provided: 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 according to the explanations provided: 7. Configure the TCP Splitting table: a. In the Traffic Redirection window, click Farms. The Farms pane appears. 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 AppDirector User Guide Optimizing AppDirector with AppXcel Application Accelerator 500 Document ID: AD_01_06_UG 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 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 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. AppDirector User Guide Optimizing AppDirector with AppXcel Application Document ID: AD_01_06_UG 501 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. When clients access Layer 4 Policy on AppDirector: Traffic to port 443 (SSL) is load balanced within the SSL farm. 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. AppDirector User Guide Optimizing AppDirector with AppXcel Application Accelerator 502 Document ID: AD_01_06_UG 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. AppDirector User Guide Optimizing AppDirector with AppXcel Application Document ID: AD_01_06_UG 503 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 User Guide Optimizing AppDirector with AppXcel Application Accelerator 504 Document ID: AD_01_06_UG 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. d. Set the following parameters according to the explanations provided: 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. e. Set the following parameters according to the explanations provided: f. Click Ok.Your preferences are recorded. 4. Add another interface: a. Right-click the AppDirector icon and select SetUp. The SetUp window appears. b. Click Add. The Interface window appears. c. Set the following parameters according to the explanations provided: 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 AppDirector User Guide Optimizing AppDirector with AppXcel Application Document ID: AD_01_06_UG 505 d. Click Ok.Your preferences are recorded. 5. Define the default gateway for AppDirector: a. Right-click the AppDirector icon and select SetUp. The SetUp window appears. b. In the SetUp window, select Networking > 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: e. Click Ok. Your preferences are recorded. 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. c. Set the following parameters according to the explanations provided: 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. g. Set the following parameters according to the explanations provided: 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 Redirection. The Traffic Redirection window appears. b. Select the Farms pane and click Add. The Farm window appears. c. Enter the following value: Network Mask: 255.255.255.0 Destination IP Address: 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 AppDirector User Guide Optimizing AppDirector with AppXcel Application Accelerator 506 Document ID: AD_01_06_UG d. In the Traffic Redirection window, select Traffic Settings. The Traffic Settings pane appears. e. Set the following parameters according to the explanations provided: f. Click Ok.Your preferences are recorded. 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: d. Click Ok.Your preferences are recorded. 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. c. Set the following parameters according to the explanations provided: 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 AppDirector User Guide Optimizing AppDirector with AppXcel Application Document ID: AD_01_06_UG 507 d. Click Ok.Your preferences are recorded. 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 AppDirector User Guide Optimizing AppDirector with AppXcel Application Accelerator 508 Document ID: AD_01_06_UG f. Click Ok.Your preferences are recorded. 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. d. Set the following parameters according to the explanations provided: 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 parameters according to the explanations provided: 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 AppDirector User Guide Optimizing AppDirector with AppXcel Application Document ID: AD_01_06_UG 509 b. Click Add. c. In the Layer 7 Policies window, click Add Policy again. Set the following parameters according to the explanations provided: 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. d. Set the following parameters according to the explanations provided:
e. Click Ok. Your preferences are recorded. f. Click Add. Add L4 Policy window appears. g. Set the following parameters according to the explanations provided:
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 AppDirector User Guide Optimizing AppDirector with AppXcel Application Accelerator 510 Document ID: AD_01_06_UG h. Click Ok. Your preferences are recorded. 14. Enable the Transparent Server Support for Delayed Binding parameter: a. Right-click the AppDirector icon and select SetUp. The SetUp window appears. b. Click Global. The Global pane appears. c. Select Client Table Settings > Edit Settings. The Client Table Settings window appears. d. Select Transparent Server Support for Delayed Binding and click Enable. e. Click Ok. Your preferences are recorded. Document ID: AD_01_06_UG 511 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. AppDirector User Guide Diagnostic Tools 512 Document ID: AD_01_06_UG 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) . AppDirector User Guide Diagnostic Tools Document ID: AD_01_06_UG 513 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. AppDirector User Guide Diagnostic Tools 514 Document ID: AD_01_06_UG 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 AppDirector User Guide Diagnostic Tools Document ID: AD_01_06_UG 515 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> AppDirector User Guide Diagnostic Tools 516 Document ID: AD_01_06_UG 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 AppDirector User Guide Diagnostic Tools Document ID: AD_01_06_UG 517 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. AppDirector User Guide Diagnostic Tools 518 Document ID: AD_01_06_UG