close

Вход

Забыли?

вход по аккаунту

?

AD 231 UG Final

код для вставкиСкачать
AppDirector User Guide
Software Version 2.31
Document ID: RDWR-AD-V0231-UG1105
May, 2011
AppDirector User Guide
2 Document ID: RDWR-AD-V0231-UG1105
Document ID: RDWR-AD-V0231-UG1105 3
Important Notices
The following important notices are presented in English, French, and German.
Important Notices
This guide is delivered subject to the following conditions and restrictions: Copyright Radware Ltd. 2006–2010. 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 Radware products described in this document, 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.
Notice importante
Ce guide est sujet aux conditions et restrictions suivantes : Copyright Radware Ltd. 2006–2010. Tous droits réservés.
Le copyright ainsi que tout autre droit lié à la propriété intellectuelle et aux secrets industriels contenus dans ce guide sont la propriété de Radware Ltd.
Ce guide d'informations est fourni à nos clients dans le cadre de l'installation et de l'usage des produits de Radware décrits dans ce document et ne pourra être utilisé dans un but autre que celui pour lequel il a été conçu.
Les informations répertoriées dans ce document restent la propriété de Radware et doivent être conservées de manière confidentielle.
Il est strictement interdit de copier, reproduire ou divulguer des informations contenues dans ce manuel sans avoir obtenu le consentement préalable écrit de Radware.
Wichtige Anmerkung
Dieses Handbuch wird vorbehaltlich folgender Bedingungen und Einschränkungen ausgeliefert: Copyright Radware Ltd. 2006–2010. Alle Rechte vorbehalten.
Das Urheberrecht und alle anderen in diesem Handbuch enthaltenen Eigentumsrechte und Geschäftsgeheimnisse sind Eigentum von Radware Ltd.
Dieses Handbuch wird Kunden von Radware mit dem ausschließlichen Zweck ausgehändigt, Informationen zu Montage und Benutzung der in diesem Dokument beschriebene Produkte von Radware bereitzustellen. Es darf für keinen anderen Zweck verwendet werden. Die in diesem Handbuch enthaltenen Informationen sind Eigentum von Radware und müssen streng vertraulich behandelt werden. Es ist streng verboten, dieses Handbuch oder Teile daraus ohne vorherige schriftliche Zustimmung von Radware zu kopieren, vervielfältigen, reproduzieren oder offen zu legen.
AppDirector User Guide
4 Document ID: RDWR-AD-V0231-UG1105
Copyright Notices The following copyright notices are presented in English, French, and German.
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 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 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
AppDirector User Guide
Document ID: RDWR-AD-V0231-UG1105 5
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.
ALL THE SOFTWARE MENTIONED ABOVE IS PROVIDED BY THE AUTHOR “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Notice traitant du copyright
Ce produit renferme des codes développés dans le cadre du projet OpenSSL.
Ce produit inclut un logiciel développé dans le cadre du projet OpenSSL. Pour un usage dans la boîte à outils OpenSSL (http://www.openssl.org/).
Copyright (c) 1998-2005 Le projet OpenSSL. Tous droits réservés. Ce produit inclut la catégorie de chiffre Rijndael. L'implémentation de Rijindael par Vincent Rijmen, Antoon Bosselaers et Paulo Barreto est du domaine public et distribuée sous les termes de la licence suivante :
@version 3.0 (Décembre 2000)
Code ANSI C code pour Rijndael (actuellement 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>.
Le commutateur OnDemand peut utiliser les composants logiciels sous licence, en vertu des termes de la licence GNU General Public License Agreement Version 2 (GPL v.2), y compris les projets à source ouverte LinuxBios et Filo. Le code source de LinuxBios et Filo est disponible sur demande auprès de Radware. Une copie de la licence est répertoriée sur:
http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
Ce code est également placé dans le domaine public.
Ce produit renferme des codes développés dans le cadre du projet OpenSSL.
Copyright (c) 1983, 1990, 1992, 1993, 1995
Les membres du conseil de l'Université de Californie. Tous droits réservés.
La distribution et l'usage sous une forme source et binaire, avec ou sans modifications, est autorisée pour autant que les conditions suivantes soient remplies :
1.La distribution d'un code source doit inclure la notice de copyright mentionnée ci-dessus, cette liste de conditions et l'avis de non-responsabilité suivant.
2.La distribution, sous une forme binaire, doit reproduire dans la documentation et/ou dans tout autre matériel fourni la notice de copyright mentionnée ci-dessus, cette liste de conditions et l'avis de non-responsabilité suivant.
3.Le nom de l'université, ainsi que le nom des contributeurs ne seront en aucun cas utilisés pour approuver ou promouvoir un produit dérivé de ce programme sans l'obtention préalable d'une autorisation écrite.
Ce produit inclut un logiciel développé par Markus Friedl AppDirector User Guide
6 Document ID: RDWR-AD-V0231-UG1105
Ce produit inclut un logiciel développé par Theo de Raadt Ce produit inclut un logiciel développé par Niels Provos Ce produit inclut un logiciel développé par Dug Song
Ce produit inclut un logiciel développé par Aaron Campbell Ce produit inclut un logiciel développé par Damien Miller Ce produit inclut un logiciel développé par Kevin Steves Ce produit inclut un logiciel développé par Daniel Kouril Ce produit inclut un logiciel développé par Wesley Griffin Ce produit inclut un logiciel développé par Per Allansson Ce produit inclut un logiciel développé par Nils Nordman
Ce produit inclut un logiciel développé par Simon Wilkinson.
La distribution et l'usage sous une forme source et binaire, avec ou sans modifications, est autorisée pour autant que les conditions suivantes soient remplies :
1.La distribution d'un code source doit inclure la notice de copyright mentionnée ci-dessus, cette liste de conditions et l'avis de non-responsabilité suivant.
2.La distribution, sous une forme binaire, doit reproduire dans la documentation et/ou dans tout autre matériel fourni la notice de copyright mentionnée ci-dessus, cette liste de conditions et l'avis de non-responsabilité suivant.
LE LOGICIEL MENTIONNÉ CI-DESSUS EST FOURNI TEL QUEL PAR LE DÉVELOPPEUR ET TOUTE GARANTIE, EXPLICITE OU IMPLICITE, Y COMPRIS, MAIS SANS S'Y LIMITER, TOUTE GARANTIE IMPLICITE DE QUALITÉ MARCHANDE ET D'ADÉQUATION À UN USAGE PARTICULIER EST EXCLUE.
EN AUCUN CAS L'AUTEUR NE POURRA ÊTRE TENU RESPONSABLE DES DOMMAGES DIRECTS, INDIRECTS, ACCESSOIRES, SPÉCIAUX, EXEMPLAIRES OU CONSÉCUTIFS (Y COMPRIS, MAIS SANS S'Y LIMITER, L'ACQUISITION DE BIENS OU DE SERVICES DE REMPLACEMENT, LA PERTE D'USAGE, DE DONNÉES OU DE PROFITS OU L'INTERRUPTION DES AFFAIRES), QUELLE QU'EN SOIT LA CAUSE ET LA THÉORIE DE RESPONSABILITÉ, QU'IL S'AGISSE D'UN CONTRAT, DE RESPONSABILITÉ STRICTE OU D'UN ACTE DOMMAGEABLE (Y COMPRIS LA NÉGLIGENCE OU AUTRE), DÉCOULANT DE QUELLE QUE FAÇON QUE CE SOIT DE L'USAGE DE CE LOGICIEL, MÊME S'IL A ÉTÉ AVERTI DE LA POSSIBILITÉ D'UN TEL DOMMAGE.
Copyrightvermerke
Dieses Produkt enthält einen vom OpenSSL-Projekt entwickelten Code
Dieses Produkt enthält vom OpenSSL-Projekt entwickelte Software. Zur Verwendung im OpenSSL Toolkit. (http://www.openssl.org/).
Copyright (c) 1998-2005 The OpenSSL Project. Alle Rechte vorbehalten. Dieses Produkt enthält die Rijndael cipher
Die Rijndael-Implementierung von Vincent Rijndael, Anton Bosselaers und Paulo Barreto ist öffentlich zugänglich und wird unter folgender Lizenz vertrieben:
@version 3.0 (December 2000)
Optimierter ANSI C Code für den Rijndael cipher (jetzt 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>
Der OnDemand Switch verwendet möglicherweise Software, die im Rahmen der DNU Allgemeine Öffentliche Lizenzvereinbarung Version 2 (GPL v.2) lizensiert sind, einschließlich LinuxBios und Filo Open Source-Projekte. Der Quellcode von LinuxBios und Filo ist bei Radware auf Anfrage erhältlich. Eine Kopie dieser Lizenz kann eingesehen werden unter:
http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
Dieser Code wird hiermit allgemein zugänglich gemacht.
Dieses Produkt enthält einen vom OpenBSD-Projekt entwickelten Code
AppDirector User Guide
Document ID: RDWR-AD-V0231-UG1105 7
Copyright (c) 1983, 1990, 1992, 1993, 1995
The Regents of the University of California. Alle Rechte vorbehalten.
Die Verbreitung und Verwendung in Quell- und binärem Format, mit oder ohne Veränderungen, sind unter folgenden Bedingungen erlaubt:
1.Die Verbreitung von Quellcodes muss den voranstehenden Copyrightvermerk, diese Liste von Bedingungen und den folgenden Haftungsausschluss beibehalten.
2.Die Verbreitung in binärem Format muss den voranstehenden Copyrightvermerk, diese Liste von Bedingungen und den folgenden Haftungsausschluss in der Dokumentation und/oder andere Materialien, die mit verteilt werden, reproduzieren.
3.Weder der Name der Universität noch die Namen der Beitragenden dürfen ohne ausdrückliche vorherige schriftliche Genehmigung verwendet werden, um von dieser Software abgeleitete Produkte zu empfehlen oder zu bewerben.
Dieses Produkt enthält von Markus Friedl entwickelte Software Dieses Produkt enthält von Theo de Raadt entwickelte Software Dieses Produkt enthält von Niels Provos entwickelte Software Dieses Produkt enthält von Dug Song entwickelte Software Dieses Produkt enthält von Aaron Campbell entwickelte Software Dieses Produkt enthält von Damien Miller entwickelte Software Dieses Produkt enthält von Kevin Steves entwickelte Software Dieses Produkt enthält von Daniel Kouril entwickelte Software Dieses Produkt enthält von Wesley Griffin entwickelte Software Dieses Produkt enthält von Per Allansson entwickelte Software Dieses Produkt enthält von Nils Nordman entwickelte Software
Dieses Produkt enthält von Simon Wilkinson entwickelte Software
Die Verbreitung und Verwendung in Quell- und binärem Format, mit oder ohne Veränderungen, sind unter folgenden Bedingungen erlaubt:
1.Die Verbreitung von Quellcodes muss den voranstehenden Copyrightvermerk, diese Liste von Bedingungen und den folgenden Haftungsausschluss beibehalten.
2.Die Verbreitung in binärem Format muss den voranstehenden Copyrightvermerk, diese Liste von Bedingungen und den folgenden Haftungsausschluss in der Dokumentation und/oder andere Materialien, die mit verteilt werden, reproduzieren.
SÄMTLICHE VORGENANNTE SOFTWARE WIRD VOM AUTOR IM IST-ZUSTAND ("AS IS") BEREITGESTELLT. JEGLICHE AUSDRÜCKLICHEN ODER IMPLIZITEN GARANTIEN, EINSCHLIESSLICH, DOCH NICHT BESCHRÄNKT AUF DIE IMPLIZIERTEN GARANTIEN DER MARKTGÄNGIGKEIT UND DER ANWENDBARKEIT FÜR EINEN BESTIMMTEN ZWECK, SIND AUSGESCHLOSSEN.
UNTER KEINEN UMSTÄNDEN HAFTET DER AUTOR FÜR DIREKTE ODER INDIREKTE SCHÄDEN, FÜR BEI VERTRAGSERFÜLLUNG ENTSTANDENE SCHÄDEN, FÜR BESONDERE SCHÄDEN, FÜR SCHADENSERSATZ MIT STRAFCHARAKTER, ODER FÜR FOLGESCHÄDEN EINSCHLIESSLICH, DOCH NICHT BESCHRÄNKT AUF, ERWERB VON ERSATZGÜTERN ODER ERSATZLEISTUNGEN; VERLUST AN NUTZUNG, DATEN ODER GEWINN; ODER GESCHÄFTSUNTERBRECHUNGEN) GLEICH, WIE SIE ENTSTANDEN SIND, UND FÜR JEGLICHE ART VON HAFTUNG, SEI ES VERTRÄGE, GEFÄHRDUNGSHAFTUNG, ODER DELIKTISCHE HAFTUNG (EINSCHLIESSLICH FAHRLÄSSIGKEIT ODER ANDERE), DIE IN JEGLICHER FORM FOLGE DER BENUTZUNG DIESER SOFTWARE IST, SELBST WENN AUF DIE MÖGLICHKEIT EINES SOLCHEN SCHADENS HINGEWIESEN WURDE.
Safety Instructions
The following safety instructions are presented in English, French, and German.
Safety Instructions
CAUTION A readily accessible disconnect device shall be incorporated in the building installation wiring. AppDirector User Guide
8 Document ID: RDWR-AD-V0231-UG1105
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. The following figure shows the caution label that is attached to Radware platforms with dual power supplies. Figure 1: Electrical Shock Hazard Label
DUAL-POWER-SUPPLY-SYSTEM SAFETY WARNING IN CHINESE
The following figure is the warning for Radware platforms with dual power supplies. Figure 2: Dual-Power-Supply-System Safety Warning in Chinese
Translation of Figure 2 - Dual-Power-Supply-System Safety Warning in Chinese
, page 8
:
This unit has more than one power supply. Disconnect all power supplies before maintenance to avoid electric shock. 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.
AppDirector User Guide
Document ID: RDWR-AD-V0231-UG1105 9
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. 48V DC-powered platforms have an input tolerance of 36-72V DC.
SPECIFICATION CHANGES Specifications are subject to change without notice. Note:This equipment has been tested and found to comply with the limits for a Class A digital device pursuant to Part 15B of the FCC Rules and EN55022 Class A, EN 55024; EN 61000-3-2; EN 61000-3-3; IEC 61000 4-2 to 4-6, IEC 61000 4-8 and IEC 61000-4-
11For 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. VCCI ELECTROMAGNETIC-INTERFERENCE STATEMENTS
Figure 3: Statment for Class A VCCI-certified Equipment
Translation of Figure 3 - Statment for Class A VCCI-certified Equipment
, page 9
:
This is a Class A product based on the standard of the Voluntary Control Council for Interference by Information Technology Equipment (VCCI). If this equipment is used in a domestic environment, radio disturbance may occur, in which case, the user may be required to take corrective action.
Figure 4: Statment for Class B VCCI-certified Equipment AppDirector User Guide
10 Document ID: RDWR-AD-V0231-UG1105
Translation of Figure 4 - Statment for Class B VCCI-certified Equipment
, page 9
:
This is a Class B product based on the standard of the Voluntary Control Council for Interference by Information Technology Equipment (VCCI). If this is used near a radio or television receiver in a domestic environment, it may cause radio interference. Install and use the equipment according to the instruction manual.
SPECIAL NOTICE FOR NORTH AMERICAN USERS
For North American power connection, select a power supply cord that is UL Listed and CSA Certified 3 - conductor, [18 AWG], terminated in a molded on plug cap rated 125 V, [5 A], with a minimum length of 1.5m [six feet] but no longer than 4.5m...For European connection, select a power supply cord that is internationally harmonized and marked “<HAR>”, 3 - conductor, 0,75 mm2 minimum mm2 wire, rated 300 V, with a PVC insulated jacket. The cord must have a molded on plug cap rated 250 V, 3 A.”.
RESTRICT AREA ACCESS The DC powered equipment should only be installed in a Restricted Access Area. INSTALLATION CODES This device must be installed according to country national electrical codes. For North America, equipment must be installed in accordance with the US National Electrical Code, Articles 110 - 16, 110 -17, and 110 -18 and the Canadian Electrical Code, Section 12.
INTERCONNECTION OF UNITS Cables for connecting to the unit RS232 and Ethernet Interfaces must be UL certified type DP-1 or DP-2. (Note- when residing in non LPS circuit)
OVERCURRENT PROTECTION A readily accessible listed branch-circuit over current protective device rated 15 A must be incorporated in the building wiring for each power input.
REPLACEABLE BATTERIES
If equipment is provided with a replaceable battery, and is replaced by an incorrect battery type, then an explosion may occur. This is the case for some Lithium batteries and the following is applicable:
• If the battery is placed in an Operator Access Area, there is a marking close to the battery or a statement in both the operating and service instructions.
• If the battery is placed elsewhere in the equipment, there is a marking close to the battery or a statement in the service instructions.
This marking or statement includes the following text warning:
CAUTION
RISK OF EXPLOSION IF BATTERY IS REPLACED BY AN INCORRECT BATTERY TYPE. DISPOSE OF USED BATTERIES ACCORDING TO THE INSTRUCTIONS.
Caution – To Reduce the Risk of Electrical Shock and Fire 1.This equipment is designed to permit connection between the earthed conductor of the DC supply circuit and the earthing conductor equipment. See Installation Instructions.
2.All servicing must be undertaken only by qualified service personnel. There are not user serviceable parts inside the unit.
3.DO NOT plug in, turn on or attempt to operate an obviously damaged unit.
4.Ensure that the chassis ventilation openings in the unit are NOT BLOCKED.
5.Replace a blown fuse ONLY with the same type and rating as is marked on the safety label adjacent to the power inlet, housing the fuse. 6.Do not operate the device in a location where the maximum ambient temperature exceeds 40°C/104°F.
AppDirector User Guide
Document ID: RDWR-AD-V0231-UG1105 11
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 liitettävä 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.
Instructions de sécurité
AVERTISSEMENT
Un dispositif de déconnexion facilement accessible sera incorporé au câblage du bâtiment.
En raison des risques de chocs électriques et des dangers énergétiques, mécaniques et d'incendie, chaque procédure impliquant l'ouverture des panneaux ou le remplacement de composants sera exécutée par du personnel qualifié.
Pour réduire les risques d'incendie et de chocs électriques, déconnectez le dispositif du bloc d'alimentation avant de retirer le couvercle ou les panneaux.
La figure suivante montre l'étiquette d'avertissement apposée sur les plateformes Radware dotées de plus d'une source d'alimentation électrique.
Figure 1 : Étiquette d'avertissement de danger de chocs électriques
Figure 5: Étiquette d'avertissement de danger de chocs électriques
AVERTISSEMENT DE SÉCURITÉ POUR LES SYSTÈMES DOTÉS DE DEUX SOURCES D'ALIMENTATION ÉLECTRIQUE (EN CHINOIS)
La figure suivante représente l'étiquette d'avertissement pour les plateformes Radware dotées de deux sources d'alimentation électrique.
AppDirector User Guide
12 Document ID: RDWR-AD-V0231-UG1105
Figure 6: Avertissement de sécurité pour les systèmes dotes de deux sources d'alimentation électrique (en chinois)
Traduction de la Figure 6 - Avertissement de sécurité pour les systèmes dotes de deux sources d'alimentation électrique (en chinois)
, page 12
:
Cette unité est dotée de plus d'une source d'alimentation électrique. Déconnectez toutes les sources d'alimentation électrique avant d'entretenir l'appareil ceci pour éviter tout choc électrique.
ENTRETIEN
N'effectuez aucun entretien autre que ceux répertoriés dans le manuel d'instructions, à moins d'être qualifié en la matière. Aucune pièce à l'intérieur de l'unité ne peut être remplacée ou réparée.
HAUTE TENSION
Tout réglage, opération d'entretien et réparation de l'instrument ouvert sous tension doit être évité. Si cela s'avère indispensable, confiez cette opération à une personne qualifiée et consciente des dangers impliqués.
Les condensateurs au sein de l'unité risquent d'être chargés même si l'unité a été déconnectée de la source d'alimentation électrique.
MISE A LA TERRE
Avant de connecter ce dispositif à la ligne électrique, les vis de protection de la borne de terre de cette unité doivent être reliées au système de mise à la terre du bâtiment.
LASER
Cet équipement est un produit laser de classe 1, conforme à la norme IEC60825 - 1 : 1993 + A1 :1997 + A2 :2001.
FUSIBLES
Assurez-vous que, seuls les fusibles à courant nominal requis et de type spécifié sont utilisés en remplacement. L'usage de fusibles réparés et le court-circuitage des porte-fusibles doivent être évités. Lorsqu'il est pratiquement certain que la protection offerte par les fusibles a été détériorée, l'instrument doit être désactivé et sécurisé contre toute opération involontaire.
TENSION DE LIGNE
Avant de connecter cet instrument à la ligne électrique, vérifiez que la tension de la source d'alimentation correspond aux exigences de l'instrument. Consultez les spécifications propres à l'alimentation nominale correcte du dispositif.
Les plateformes alimentées en 48 CC ont une tolérance d'entrée comprise entre 36 et 72 V CC. MODIFICATIONS DES SPÉCIFICATIONS
Les spécifications sont sujettes à changement sans notice préalable.
Remarque: Cet équipement a été testé et déclaré conforme aux limites définies pour un appareil numérique de classe A, conformément au paragraphe 15B de la réglementation FCC et EN55022 Classe A, EN 55024, EN 61000-3-2 ; EN 61000-3-3 ; IEC 61000 4-2 to 4-6, IEC 61000 4-8 and IEC 61000-4-11, pour la marque de conformité de la CE. Ces limites sont fixées pour fournir une protection raisonnable contre les interférences nuisibles, lorsque l'équipement est utilisé dans un environnement commercial. Cet équipement génère, utilise et peut émettre des fréquences radio et, s'il n'est pas installé et utilisé conformément au manuel d'instructions, peut entraîner des interférences nuisibles aux communications radio. Le fonctionnement de cet équipement dans une zone résidentielle est susceptible de provoquer des interférences nuisibles, auquel cas l'utilisateur devra corriger le problème à ses propres frais.
DÉCLARATIONS SUR LES INTERFÉRENCES ÉLECTROMAGNÉTIQUES VCCI
AppDirector User Guide
Document ID: RDWR-AD-V0231-UG1105 13
Figure 7: Déclaration pour l'équipement de classe A certifié VCCI
Traduction de la Figure 7 - Déclaration pour l'équipement de classe A certifié VCCI
, page 13
:
Il s'agit d'un produit de classe A, basé sur la norme du Voluntary Control Council for Interference by Information Technology Equipment (VCCI). Si cet équipement est utilisé dans un environnement domestique, des perturbations radioélectriques sont susceptibles d'apparaître. Si tel est le cas, l'utilisateur sera tenu de prendre des mesures correctives.
Figure 8: Déclaration pour l'équipement de classe B certifié VCCI
Traduction de la Figure 8 - Déclaration pour l'équipement de classe B certifié VCCI
, page 13
:
Il s'agit d'un produit de classe B, basé sur la norme du Voluntary Control Council for Interference by Information Technology Equipment (VCCI). S'il est utilisé à proximité d'un poste de radio ou d'une télévision dans un environnement domestique, il peut entraîner des interférences radio.
Installez et utilisez l'équipement selon le manuel d'instructions.
NOTICE SPÉCIALE POUR LES UTILISATEURS NORD-AMÉRICAINS
Pour un raccordement électrique en Amérique du Nord, sélectionnez un cordon d'alimentation homologué UL et certifié CSA 3 - conducteur, [18 AWG], muni d'une prise moulée à son extrémité, de 125 V, [5 A], d'une longueur minimale de 1,5 m [six pieds] et maximale de 4,5m...Pour la connexion européenne, choisissez un cordon d'alimentation mondialement homologué et marqué "<HAR>", 3 - conducteur, câble de 0,75 mm2 minimum, de 300 V, avec une gaine en PVC isolée. La prise à l'extrémité du cordon, sera dotée d'un sceau moulé indiquant: 250 V, 3 A.".
ZONE A ACCÈS RESTREINT
L'équipement alimenté en CC ne pourra être installé que dans une zone à accès restreint. CODES D'INSTALLATION
Ce dispositif doit être installé en conformité avec les codes électriques nationaux. En Amérique du Nord, l'équipement sera installé en conformité avec le code électrique national américain, articles 110-16, 110 -17, et 110 -18 et le code électrique canadien, Section 12. INTERCONNEXION DES UNÎTES.
Les câbles de connexion à l'unité RS232 et aux interfaces Ethernet seront certifiés UL, type DP-1 ou DP-2. (Remarque- s'ils ne résident pas dans un circuit LPS) PROTECTION CONTRE LES SURCHARGES.
Un circuit de dérivation, facilement accessible, sur le dispositif de protection du courant de 15 A doit être intégré au câblage du bâtiment pour chaque puissance consommée.
BATTERIES REMPLAÇABLES
AppDirector User Guide
14 Document ID: RDWR-AD-V0231-UG1105
Si l'équipement est fourni avec une batterie, et qu'elle est remplacée par un type de batterie incorrect, elle est susceptible d'exploser. C'est le cas pour certaines batteries au lithium, les éléments suivants sont donc applicables :
• Si la batterie est placée dans une zone d'accès opérateur, une marque est indiquée sur la batterie ou une remarque est insérée, aussi bien dans les instructions d'exploitation que d'entretien.
• Si la batterie est placée ailleurs dans l'équipement, une marque est indiquée sur la batterie ou une remarque est insérée dans les instructions d'entretien.
Cette marque ou remarque inclut l'avertissement textuel suivant : AVERTISSEMENT
RISQUE D'EXPLOSION SI LA BATTERIE EST REMPLACÉE PAR UN MODÈLE INCORRECT. METTRE AU REBUT LES BATTERIES CONFORMÉMENT AUX INSTRUCTIONS.
Attention - Pour réduire les risques de chocs électriques et d'incendie
1.Cet équipement est conçu pour permettre la connexion entre le conducteur de mise à la terre du circuit électrique CC et l'équipement de mise à la terre. Voir les instructions d'installation.
2.Tout entretien sera entrepris par du personnel qualifié. Aucune pièce à l'intérieur de l'unité ne peut être remplacée ou réparée.
3.NE branchez pas, n'allumez pas ou n'essayez pas d'utiliser une unité manifestement endommagée.
4.Vérifiez que l'orifice de ventilation du châssis dans l'unité n'est PAS OBSTRUE.
5.Remplacez le fusible endommagé par un modèle similaire de même puissance, tel qu'indiqué sur l'étiquette de sécurité adjacente à l'arrivée électrique hébergeant le fusible.
6.Ne faites pas fonctionner l'appareil dans un endroit, où la température ambiante dépasse la valeur maximale autorisée. 40°C/104°F.
7.Débranchez le cordon électrique de la prise murale AVANT d'essayer de retirer et/ou de vérifier le fusible d'alimentation principal.
PRODUIT LASER DE CLASSE 1 ET RÉFÉRENCE AUX NORMES LASER LES PLUS RÉCENTES : IEC 60
825-1:1993 + A1 :1997 + A2 :2001 ET EN 60825-1:1994+A1 :1996+ A2 :2001
Unités à CA pour le Danemark, la Finlande, la Norvège, la Suède (indiqué sur le produit) :
• Danemark - Unité de classe 1 - qui doit être utilisée avec un cordon CA compatible avec les déviations du Danemark. Le cordon inclut un conducteur de mise à la terre. L'unité sera branchée à une prise murale, mise à la terre. Les prises non-mises à la terre ne seront pas utilisées !
• Finlande - (Étiquette et inscription dans le manuel) - Laite on liitettävä suojamaadoituskoskettimilla varustettuun pistorasiaan" • Norvège (Étiquette et inscription dans le manuel) - "Apparatet må tilkoples jordet stikkontakt"
• L'unité peut être connectée à un système électrique IT (en Norvège uniquement).
• Suède (Étiquette et inscription dans le manuel) - "Apparaten skall anslutas till jordat uttag."
Pour brancher à l'alimentation électrique :
1.Branchez le câble d'alimentation à la prise principale, située sur le panneau arrière de l'unité.
2.Connectez le câble d'alimentation à la prise CA mise à la terre. AVERTISSEMENT
Risque de choc électrique et danger énergétique. La déconnexion d'une source d'alimentation électrique ne débranche qu'un seul module électrique. Pour isoler complètement l'unité, débranchez toutes les sources d'alimentation électrique. ATTENTION
Risque de choc et de danger électriques. Le débranchement d'une seule alimentation stabilisée ne débranche qu'un module "Alimentation Stabilisée". Pour Isoler complètement le module en cause, il faut débrancher toutes les alimentations stabilisées.
AppDirector User Guide
Document ID: RDWR-AD-V0231-UG1105 15
Attention: Pour Réduire Les Risques d'Électrocution et d'Incendie
1.Toutes les opérations d'entretien seront effectuées UNIQUEMENT par du personnel d'entretien qualifié. Aucun composant ne peut être entretenu ou remplacée par l'utilisateur.
2.NE PAS connecter, mettre sous tension ou essayer d'utiliser une unité visiblement défectueuse.
3.Assurez-vous que les ouvertures de ventilation du châssis NE SONT PAS OBSTRUÉES.
4.Remplacez un fusible qui a sauté SEULEMENT par un fusible du même type et de même capacité, comme indiqué sur l'étiquette de sécurité proche de l'entrée de l'alimentation qui contient le fusible.
5.NE PAS UTILISER l'équipement dans des locaux dont la température maximale dépasse 40 degrés Centigrades.
6.Assurez vous que le cordon d'alimentation a été déconnecté AVANT d'essayer de l'enlever et/ou vérifier le fusible de l'alimentation générale.
Sicherheitsanweisungen
VORSICHT
Die Elektroinstallation des Gebäudes muss ein unverzüglich zugängliches Stromunterbrechungsgerät integrieren.
Aufgrund des Stromschlagrisikos und der Energie-, mechanische und Feuergefahr dürfen Vorgänge, in deren Verlauf Abdeckungen entfernt oder Elemente ausgetauscht werden, ausschließlich von qualifiziertem Servicepersonal durchgeführt werden.
Zur Reduzierung der Feuer- und Stromschlaggefahr muss das Gerät vor der Entfernung der Abdeckung oder der Paneele von der Stromversorgung getrennt werden.
Folgende Abbildung zeigt das VORSICHT-Etikett, das auf die Radware-Plattformen mit Doppelspeisung angebracht ist.
Figure 9: Warnetikett Stromschlaggefahr
SICHERHEITSHINWEIS IN CHINESISCHER SPRACHE FÜR SYSTEME MIT DOPPELSPEISUNG
Die folgende Abbildung ist die Warnung für Radware-Plattformen mit Doppelspeisung.
Figure 10: Sicherheitshinweis in chinesischer Sprache für Systeme mit Doppelspeisung
Übersetzung von Figure 10 - Sicherheitshinweis in chinesischer Sprache für Systeme mit Doppelspeisung
, page 15
:
AppDirector User Guide
16 Document ID: RDWR-AD-V0231-UG1105
Die Einheit verfügt über mehr als eine Stromversorgungsquelle. Ziehen Sie zur Verhinderung von Stromschlag vor Wartungsarbeiten sämtliche Stromversorgungsleitungen ab.
WARTUNG
Führen Sie keinerlei Wartungsarbeiten aus, die nicht in der Betriebsanleitung angeführt sind, es sei denn, Sie sind dafür qualifiziert. Es gibt innerhalb des Gerätes keine wartungsfähigen Teile.
HOCHSPANNUNG
Jegliche Einstellungs-, Instandhaltungs- und Reparaturarbeiten am geöffneten Gerät unter Spannung müssen so weit wie möglich vermieden werden. Sind sie nicht vermeidbar, dürfen sie ausschließlich von qualifizierten Personen ausgeführt werden, die sich der Gefahr bewusst sind.
Innerhalb des Gerätes befindliche Kondensatoren können auch dann noch Ladung enthalten, wenn das Gerät von der Stromversorgung abgeschnitten wurde.
ERDUNG
Bevor das Gerät an die Stromversorgung angeschlossen wird, müssen die Schrauben der Erdungsleitung des Gerätes an die Erdung der Gebäudeverkabelung angeschlossen werden.
LASER
Dieses Gerät ist ein Laser-Produkt der Klasse 1 in Übereinstimmung mit IEC60825 - 1: 1993 + A1:1997 + A2:2001 Standard.
SICHERUNGEN
Vergewissern Sie sich, dass nur Sicherungen mit der erforderlichen Stromstärke und der angeführten Art verwendet werden. Die Verwendung reparierter Sicherungen sowie die Kurzschließung von Sicherungsfassungen muss vermieden werden. In Fällen, in denen wahrscheinlich ist, dass der von den Sicherungen gebotene Schutz beeinträchtigt ist, muss das Gerät abgeschaltet und gegen unbeabsichtigten Betrieb gesichert werden.
LEITUNGSSPANNUNG
Vor Anschluss dieses Gerätes an die Stromversorgung ist zu gewährleisten, dass die Spannung der Stromquelle den Anforderungen des Gerätes entspricht. Beachten Sie die technischen Angaben bezüglich der korrekten elektrischen Werte des Gerätes.
Plattformen mit 48 V DC verfügen über eine Eingangstoleranz von 36-72 V DC. ÄNDERUNGEN DER TECHNISCHEN ANGABEN
Änderungen der technischen Spezifikationen bleiben vorbehalten.
Hinweis: Dieses Gerät wurde geprüft und entspricht den Beschränkungen von digitalen Geräten der Klasse 1 gemäß Teil 15B FCC-Vorschriften und EN55022 Klasse A, EN55024; EN 61000-3-2; EN; IEC 61000 4-2 to 4-6, IEC 61000 4-8 und IEC 61000-4- 11 für Konformität mit der CE-Bezeichnung. Diese Beschränkungen dienen dem angemessenen Schutz vor schädlichen Interferenzen bei Betrieb des Gerätes in kommerziellem Umfeld. Dieses Gerät erzeugt, verwendet und strahlt elektromagnetische Hochfrequenzstrahlung aus. Wird es nicht entsprechend den Anweisungen im Handbuch montiert und benutzt, könnte es mit dem Funkverkehr interferieren und ihn beeinträchtigen. Der Betrieb dieses Gerätes in Wohnbereichen wird höchstwahrscheinlich zu schädlichen Interferenzen führen. In einem solchen Fall wäre der Benutzer verpflichtet, diese Interferenzen auf eigene Kosten zu korrigieren.
ERKLÄRUNG DER VCCI ZU ELEKTROMAGNETISCHER INTERFERENZ
Figure 11: Erklärung zu VCCI-zertifizierten Geräten der Klasse A
AppDirector User Guide
Document ID: RDWR-AD-V0231-UG1105 17
Übersetzung von Figure 11 - Erklärung zu VCCI-zertifizierten Geräten der Klasse A
, page 16
:
Dies ist ein Produkt der Klasse A gemäß den Normen des Voluntary Control Council for Interference by Information Technology Equipment (VCCI). Wird dieses Gerät in einem Wohnbereich benutzt, können elektromagnetische Störungen auftreten. In einem solchen Fall wäre der Benutzer verpflichtet, korrigierend einzugreifen.
Figure 12: Erklärung zu VCCI-zertifizierte Geräte der Klasse B
Übersetzung von Figure 12 - Erklärung zu VCCI-zertifizierte Geräte der Klasse B
, page 17
:
Dies ist ein Produkt der Klasse B gemäß den Normen des Voluntary Control Council for Interference by Information Technology Equipment (VCCI). Wird dieses Gerät in einem Wohnbereich benutzt, können elektromagnetische Störungen auftreten.
Montieren und benutzen Sie das Gerät laut Anweisungen im Benutzerhandbuch.
BESONDERER HINWEIS FÜR BENUTZER IN NORDAMERIKA
Wählen Sie für den Netzstromanschluss in Nordamerika ein Stromkabel, das in der UL aufgeführt und CSA-zertifiziert ist 3 Leiter, [18 AWG], endend in einem gegossenen Stecker, für 125 V, [5 A], mit einer Mindestlänge von 1,5 m [sechs Fuß], doch nicht länger als 4,5 m. Für europäische Anschlüsse verwenden Sie ein international harmonisiertes, mit "<HAR>" markiertes Stromkabel, mit 3 Leitern von mindestens 0,75 mm2, für 300 V, mit PVC-Umkleidung. Das Kabel muss in einem gegossenen Stecker für 250 V, 3 A enden.
BEREICH MIT EINGESCHRÄNKTEM ZUGANG
Das mit Gleichstrom betriebene Gerät darf nur in einem Bereich mit eingeschränktem Zugang montiert werden.
INSTALLATIONSCODES
Dieses Gerät muss gemäß der landesspezifischen elektrischen Codes montiert werden. In Nordamerika müssen Geräte entsprechend dem US National Electrical Code, Artikel 110 - 16, 110 - 17 und 110 - 18, sowie dem Canadian Electrical Code, Abschnitt 12, montiert werden. VERKOPPLUNG VON GERÄTEN Kabel für die Verbindung des Gerätes mit RS232- und Ethernet-
müssen UL-zertifiziert und vom Typ DP-1 oder DP-2 sein. (Anmerkung: bei Aufenthalt in einem nicht-LPS-Stromkreis) ÜBERSTROMSCHUTZ
Ein gut zugänglicher aufgeführter Überstromschutz mit Abzweigstromkreis und 15 A Stärke muss für jede Stromeingabe in der Gebäudeverkabelung integriert sein.
AUSTAUSCHBARE BATTERIEN
Wird ein Gerät mit einer austauschbaren Batterie geliefert und für diese Batterie durch einen falschen Batterietyp ersetzt, könnte dies zu einer Explosion führen. Dies trifft zu für manche Arten von Lithiumsbatterien zu, und das folgende gilt es zu beachten:
• Wird die Batterie in einem Bereich für Bediener eingesetzt, findet sich in der Nähe der Batterie eine Markierung oder Erklärung sowohl im Betriebshandbuch als auch in der Wartungsanleitung.
• Ist die Batterie an einer anderen Stelle im Gerät eingesetzt, findet sich in der Nähe der Batterie eine Markierung oder einer Erklärung in der Wartungsanleitung.
Diese Markierung oder Erklärung enthält den folgenden Warntext: VORSICHT
AppDirector User Guide
18 Document ID: RDWR-AD-V0231-UG1105
EXPLOSIONSGEFAHR, FALLS BATTERIE DURCH EINEN FALSCHEN BATTERIETYP ERSETZT WIRD. GEBRAUCHTE BATTERIEN DEN ANWEISUNGEN ENTSPRECHEND ENTSORGEN.
• Denmark - "Unit is class I - mit Wechselstromkabel benutzen, dass für die Abweichungen in Dänemark eingestellt ist. Das Kabel ist mit einem Erdungsdraht versehen. Das Kabel wird in eine geerdete Wandsteckdose angeschlossen. Keine Steckdosen ohne Erdungsleitung verwenden!"
• Finland - (Markierungsetikett und im Handbuch) - "Laite on liitettävä suojamaadoituskoskettimilla varustettuun pistorasiaan
• Norway - (Markierungsetikett und im Handbuch) - "Apparatet må tilkoples jordet stikkontakt Ausschließlich für Anschluss an IT-Netzstromsysteme in Norwegen vorgesehen
• Sweden - (Markierungsetikett und im Handbuch) - "Apparaten skall anslutas till jordat uttag."
Anschluss des Stromkabels:
1.Schließen Sie das Stromkabel an den Hauptanschluss auf der Rückseite des Gerätes an.
2.Schließen Sie das Stromkabel an den geerdeten Wechselstromanschluss an. VORSICHT
Stromschlag- und Energiegefahr Die Trennung einer Stromquelle trennt nur ein Stromversorgungsmodul von der Stromversorgung. Um das Gerät komplett zu isolieren, muss es von der gesamten Stromversorgung getrennt werden. Vorsicht - Zur Reduzierung der Stromschlag- und Feuergefahr
1.Dieses Gerät ist dazu ausgelegt, die Verbindung zwischen der geerdeten Leitung des Gleichstromkreises und dem Erdungsleiter des Gerätes zu ermöglichen. Siehe Montageanleitung.
2.Wartungsarbeiten jeglicher Art dürfen nur von qualifiziertem Servicepersonal ausgeführt werden. Es gibt innerhalb des Gerätes keine vom Benutzer zu wartenden Teile.
3.Versuchen Sie nicht, ein offensichtlich beschädigtes Gerät an den Stromkreis anzuschließen, einzuschalten oder zu betreiben.
4.Vergewissern Sie sich, dass sie Lüftungsöffnungen im Gehäuse des Gerätes NICHT BLOCKIERT SIND.
5.Ersetzen Sie eine durchgebrannte Sicherung ausschließlich mit dem selben Typ und von der selben Stärke, die auf dem Sicherheitsetikett angeführt sind, das sich neben dem Stromkabelanschluss, am Sicherungsgehäuse.
6.Betreiben Sie das Gerät nicht an einem Standort, an dem die Höchsttemperatur der Umgebung 40 °C überschreitet.
7.Vergewissern Sie sich, das Stromkabel aus dem Wandstecker zu ziehen, BEVOR Sie die Hauptsicherung entfernen und/oder prüfen.
AppDirector User Guide
Document ID: RDWR-AD-V0231-UG1105 19
Document Conventions
The following describes the conventions and symbols that this guide uses:
Item
Description
Description (French)
Beschreibung (German)
Example An example scenario Un scénario d'exemple Ein Beispielszenarium
Caution:
Possible damage to equipment, software, or data
Endommagement possible de l'équipement, des données ou du logiciel
Mögliche Schäden an Gerät, Software oder Daten
Note:
Additional information Informations complémentaires
Zusätzliche Informationen
To A statement and instructions
Références et instructions
Eine Erklärung und Anweisungen
Tip: A suggestion or workaround
Une suggestion ou solution
Ein Vorschlag oder eine Umgehung
Warning: Possible physical harm to the operator
Blessure possible de l'opérateur Verletzungsgefahr des Bedieners
AppDirector User Guide
20 Document ID: RDWR-AD-V0231-UG1105
AppDirector User Guide
Table of Contents
Document ID: RDWR-AD-V0231-UG1105 21
Table of Contents
Important Notices .......................................................................................................... 3
Copyright Notices .......................................................................................................... 4
Safety Instructions ......................................................................................................... 7
Document Conventions ............................................................................................... 19
Chapter 1 – Introducing AppDirector.................................................................... 29
AppDirector Modules ........................................................................................................... 29
Management Tools .............................................................................................................. 31
Licenses ............................................................................................................................... 31
IPv6 Support in AppDirector ................................................................................................ 32
Configuration and Workflows for AppDirector ............................................................. 33
Before Installation and Configuration ................................................................................... 33
Configuration for all AppDirectors ........................................................................................ 35
Chapter 2 – Administering and Monitoring AppDirector..................................... 37
Supported Management Interfaces for AppDirector .................................................... 37
Web Based Management .................................................................................................... 38
Web Services ....................................................................................................................... 39
Command Line Interface ..................................................................................................... 40
Configuring Telnet ............................................................................................................... 43
Configuring FTP Server ....................................................................................................... 45
Configuring SNMP ............................................................................................................... 45
Version and Configuration Management ..................................................................... 54
Upgrades ............................................................................................................................. 54
Software Versions ................................................................................................................ 54
Configuration File Management ........................................................................................... 56
Licensing and Upgrading Licenses ...................................................................................... 60
Resetting Devices ................................................................................................................ 64
Device Shutdown ................................................................................................................. 65
Tuning AppDirector ...................................................................................................... 65
Device Tuning ...................................................................................................................... 66
Device Global Parameters ................................................................................................... 69
Main Device Tuning Parameters ......................................................................................... 70
Bandwidth Management Settings Tuning ............................................................................ 72
Client Table Settings Tuning ................................................................................................ 73
DNS Settings Tuning ........................................................................................................... 73
NAT Settings Tuning ............................................................................................................ 73
Security Tuning .................................................................................................................... 74
Security Tables .................................................................................................................... 75
Session Table Tuning .......................................................................................................... 75
Tuning Memory Check ......................................................................................................... 76
AppDirector User Guide
Table of Contents
22 Document ID: RDWR-AD-V0231-UG1105
Tuning Statistics .................................................................................................................. 76
Bandwidth Management Tuning (On Demand Switch Devices Only) ................................. 77
Classifier Tuning ................................................................................................................. 77
SYN Protection Tuning ........................................................................................................ 79
Application Security Tuning ................................................................................................. 80
Behavioral DoS Tuning Parameters .................................................................................... 82
Monitoring AppDirector ............................................................................................... 83
AppDirector Dashboard ....................................................................................................... 83
Startup Screen Preferences ................................................................................................ 84
Device Information .............................................................................................................. 85
Device Monitoring ............................................................................................................... 87
Notifications ......................................................................................................................... 87
Configuration Auditing ......................................................................................................... 91
AppDirector Thresholds ....................................................................................................... 92
Basic Switching (Layer 2 Capability) .......................................................................... 98
AppDirector Physical Interface Configuration ...................................................................... 99
Layer 2 Interface Table ....................................................................................................... 99
Virtual LAN ........................................................................................................................ 101
VLAN Tagging ................................................................................................................... 107
Spanning Tree Protocol .................................................................................................... 109
Link Aggregation (Port Trunking) ...................................................................................... 112
Port Mirroring .................................................................................................................... 116
IP Addressing and Routing ....................................................................................... 117
IP Interfaces ...................................................................................................................... 118
ARP Configuration ............................................................................................................ 121
IPv6 Neighbor Discovery ................................................................................................... 121
IP Router Advertisement ................................................................................................... 123
Routing .............................................................................................................................. 126
Routing Table .................................................................................................................... 127
NHRs ................................................................................................................................. 128
VIP NHR ............................................................................................................................ 129
Routing Information Protocol ............................................................................................. 130
Open Shortest Path First (OSPF) ...................................................................................... 132
Border Gateway Protocol .................................................................................................. 138
Redundancy ............................................................................................................. 143
Network Configurations ..................................................................................................... 143
Configuration Guidelines ................................................................................................... 146
Global Redundancy Configuration .................................................................................... 153
Failover Decision ............................................................................................................... 155
Stateful Failover (Mirroring) ............................................................................................... 158
Physical IP Addresses versus Virtual IP Addresses Redundancy .................................... 161
Virtual Router Redundancy Protocol ................................................................................. 161
Configuration Synchronization .......................................................................................... 165
AppDirector User Guide
Table of Contents
Document ID: RDWR-AD-V0231-UG1105 23
Chapter 3 – Traffic Management and Application Acceleration....................... 175
Configuring Farms .................................................................................................... 177
Farm Parameters .............................................................................................................. 177
Additional HTTP Connectivity Checks Parameters .......................................................... 184
No HTTP Service Page .................................................................................................... 185
Configuring Servers .................................................................................................. 186
Physical Servers ............................................................................................................... 186
Application/Farm Servers ................................................................................................. 188
Dispatch Methods ............................................................................................................. 193
Local Triangulation ........................................................................................................... 197
Traffic Management Policies .................................................................................... 199
Layer 4 Policies ................................................................................................................ 200
Layer 4 Policies Lookup Mechanism ................................................................................ 203
Layer 4 Policy Statistics .................................................................................................... 204
HTTP Policies ................................................................................................................... 204
TCP Policies ..................................................................................................................... 208
SSL Offloading and Authentication .......................................................................... 209
SSL Policies ...................................................................................................................... 211
Authentication Policies Overview ...................................................................................... 215
Client Authentication Policies ........................................................................................... 215
Trust-service Status List (TSL) Authentication Policies .................................................... 223
Certificate Validation Policies ........................................................................................... 230
Application Acceleration ........................................................................................... 235
Benefits of Application Acceleration ................................................................................. 235
Enabling and Disabling Application Acceleration .............................................................. 236
Rule Lists .......................................................................................................................... 236
Caching ............................................................................................................................. 237
Caching URL Rule Lists .................................................................................................... 243
Compression ..................................................................................................................... 244
Layer 7 Traffic Management ..................................................................................... 249
Layer 7 Methods ............................................................................................................... 249
Layer 7 Farm Selection ..................................................................................................... 256
Layer 7 Modification .......................................................................................................... 259
Layer 7 Server Persistency ............................................................................................... 275
Client Table Management ........................................................................................ 287
Types of Client Table Entries ............................................................................................ 287
Static Client Table ............................................................................................................. 288
View Filtered Clients ......................................................................................................... 289
Client Table Views ............................................................................................................ 290
Reset Client on Server Failure .......................................................................................... 291
Close Session At Aging .................................................................................................... 291
Client Table Sessions Modes ........................................................................................... 291
Network Address Translation (NAT) ......................................................................... 297
Client NAT ........................................................................................................................ 297
AppDirector User Guide
Table of Contents
24 Document ID: RDWR-AD-V0231-UG1105
Server NAT ....................................................................................................................... 302
Outbound NAT .................................................................................................................. 304
Configuring AppDirector Advanced Global Parameters ........................................... 311
Chapter 4 – Configuring Global Load Balancing............................................... 315
Global Traffic Management ...................................................................................... 315
IP Traffic Management ...................................................................................................... 315
Global Solution Configuration Guidelines .......................................................................... 318
Proximity ................................................................................................................... 319
Proximity Parameters ........................................................................................................ 319
Proximity DNS Address ..................................................................................................... 320
Proximity Checks ............................................................................................................... 321
Proximity Report Protocol (PRP) ....................................................................................... 322
Static Proximity Database ................................................................................................. 323
Configuring Local Report Protocol ............................................................................ 326
Introducing the Load Report Protocol (LRP) ..................................................................... 326
Local Load Report Protocol (Local LRP) ........................................................................... 329
LRP in Multi-Homed Environments ................................................................................... 330
Domain Name System (DNS) ................................................................................... 331
Host Names ...................................................................................................................... 332
DNS Server Parameters .................................................................................................... 336
DNS Persistency ............................................................................................................... 337
DNS Statistics ................................................................................................................... 341
Redirection ............................................................................................................... 341
DNS Redirection ............................................................................................................... 342
HTTP Redirection .............................................................................................................. 342
HTTP to HTTPS Protocol Redirection ............................................................................... 343
RTSP Redirection ............................................................................................................. 345
SIP Redirection ................................................................................................................. 345
Proxy Redirection .............................................................................................................. 346
Global Triangulation Redirection ....................................................................................... 346
Setting Redirection Parameters ........................................................................................ 348
Anycast Advertise ............................................................................................................. 350
Chapter 5 – Configuring Health Monitoring....................................................... 353
Health Monitoring Workflow .............................................................................................. 353
Checked Element .............................................................................................................. 353
Health Check ..................................................................................................................... 353
Health Monitoring Global Parameters ............................................................................... 354
Health Checks .......................................................................................................... 355
Group Health Checks ........................................................................................................ 355
Single Health Checks ........................................................................................................ 355
Health Monitoring Check Table ......................................................................................... 355
Binding .............................................................................................................................. 364
AppDirector User Guide
Table of Contents
Document ID: RDWR-AD-V0231-UG1105 25
Packet Sequence Table .................................................................................................... 365
Server Table ..................................................................................................................... 366
Diameter Argument List and Additional Method Arguments ............................................. 367
Uploading, Downloading and Deleting the Diameter File using Binary File Transfer ....... 369
User Defined Methods ...................................................................................................... 369
AppDirector Farm Connectivity Checks .................................................................... 370
Ping Connectivity Method ................................................................................................. 370
TCP Port Connectivity Method ......................................................................................... 371
UDP Port Connectivity Method ......................................................................................... 372
HTTP Page Connectivity Method ..................................................................................... 372
Long URL Checks ............................................................................................................. 372
Disabled Connectivity Method .......................................................................................... 373
Chapter 6 – Classes and Bandwidth Management............................................ 375
Bandwidth Management and Classifier Settings ...................................................... 378
Bandwidth Management Rules ......................................................................................... 378
Configuring Bandwidth Management ....................................................................... 379
Differentiated Services ...................................................................................................... 388
Bandwidth Management and Classes Update Policies .................................................... 391
Traffic Classes .......................................................................................................... 392
Configuring Networks ....................................................................................................... 392
Services ............................................................................................................................ 394
Basic Filters ...................................................................................................................... 397
Application Port Groups .................................................................................................... 402
Physical Port Groups ........................................................................................................ 403
VLAN Tag Groups ............................................................................................................ 404
MAC Groups ..................................................................................................................... 405
Protocol Discovery .................................................................................................... 405
Interface Classification ............................................................................................. 406
Chapter 7 – Advanced Capabilities..................................................................... 411
Multihoming .............................................................................................................. 411
Default Router Per Virtual IP ............................................................................................ 411
Using Redirect to Self in Multi-Homed Environments ....................................................... 414
Segmentation ........................................................................................................... 415
Using Segmentation ......................................................................................................... 415
Segmentation with AppDirector ........................................................................................ 416
Session Initiation Protocol (SIP) ............................................................................... 422
SIP Load Balancing with AppDirector ............................................................................... 423
Farm Selection Based on SIP Parameters ....................................................................... 423
Load Balancing SIP Servers ............................................................................................. 423
Outbound SIP Sessions .................................................................................................... 423
Stream Control Transmission Protocol (SCTP) ........................................................ 424
AppDirector User Guide
Table of Contents
26 Document ID: RDWR-AD-V0231-UG1105
Performance Statistics .............................................................................................. 427
Acceleration Engine Statistics ........................................................................................... 427
Bandwidth Management Statistics .................................................................................... 442
Element Statistics .............................................................................................................. 444
IP Interface Statistics ........................................................................................................ 447
Servers .............................................................................................................................. 449
AppDirector Statistics ........................................................................................................ 452
Protocol Statistics .............................................................................................................. 453
Statistics Monitor ............................................................................................................... 455
Utilities ...................................................................................................................... 456
DNS Client ........................................................................................................................ 456
Time Settings .................................................................................................................... 457
Event Scheduler ................................................................................................................ 459
Chapter 8 – Security............................................................................................. 461
AppDirector Device Security ..................................................................................... 461
Management Ports (Setting Physical Management Ports Restrictions) ............................ 461
Ports Access ..................................................................................................................... 462
User Table and Authentication .......................................................................................... 463
Keys and Certificates ................................................................................................ 466
Certificates ........................................................................................................................ 466
Keys .................................................................................................................................. 467
Certificates Workflows ....................................................................................................... 468
Configuration of Keys and Certificates .............................................................................. 470
Session Table and Session Table Lookup Mode ..................................................... 476
Stateful ACL (Access Control Lists) ......................................................................... 478
ACL Global Parameters .................................................................................................... 479
ACL Modified Policies ....................................................................................................... 482
ACL Update Policies ......................................................................................................... 483
ACL Active Policies ........................................................................................................... 483
ACL Reports ...................................................................................................................... 485
SYN Protection ......................................................................................................... 487
SYN Flood Protection ........................................................................................................ 487
Service Protection ............................................................................................................. 492
DoS Protection ......................................................................................................... 498
Behavioral DoS ................................................................................................................. 505
Network Protection Policies ............................................................................................... 518
Global Suspend Table ....................................................................................................... 526
Security Reporting ............................................................................................................. 528
Attack Database ................................................................................................................ 532
Policy Exceptions - White List ........................................................................................... 540
AppDirector User Guide
Table of Contents
Document ID: RDWR-AD-V0231-UG1105 27
Appendix A – Radware Technical Glossary...................................................... 543
Appendix B – Regular Expressions................................................................... 583
Appendix C – Monitoring AppDirector - The Dashboard................................. 585
Global Dashboard Help .................................................................................................... 585
Customization ................................................................................................................... 586
Appendix D – Troubleshooting........................................................................... 589
Diagnostic Tools ....................................................................................................... 589
Diagnostics Trace-Log ...................................................................................................... 589
Traffic Capture .................................................................................................................. 592
Diagnostics Tools Policies ................................................................................................ 597
Diagnostics Tools File Management ................................................................................. 598
Diagnostics Tools Tuning ................................................................................................. 599
System Diagnostics .......................................................................................................... 600
Acceleration-Engine Logs ......................................................................................... 604
Clearing the Application Accelerator Log file .................................................................... 605
Using Acceleration Logs Efficiently ................................................................................... 605
Downloading the Technical Support File .................................................................. 607
Appendix E – IPv6 Fundamentals....................................................................... 609
IPv4 versus IPv6 ...................................................................................................... 609
Name Resolution ...................................................................................................... 610
Internet Protocol version 6 (IPv6) ............................................................................. 611
Internet Control Message Protocol for IPv6 (ICMPv6) ...................................................... 611
IPv6 Address Autoconfiguration ............................................................................... 613
Autoconfigured Address States ........................................................................................ 613
Types of Autoconfiguration ............................................................................................... 613
Autoconfiguration Process ................................................................................................ 613
IPv6 Routing ..................................................................................................................... 614
IPv6 Configuration Items .................................................................................................. 616
IPv6 Neighbor Discovery .................................................................................................. 617
New Header Format ......................................................................................................... 618
Large Address Space ....................................................................................................... 619
Efficient and Hierarchical Addressing and Routing Infrastructure .................................... 619
Stateless and Stateful Address Configuration .................................................................. 619
Built-in Security ................................................................................................................. 619
Better Support for Quality of Service (QoS) ...................................................................... 619
New Protocol for Neighboring Node Interaction ............................................................... 619
Extensibility ....................................................................................................................... 620
AppDirector User Guide
Table of Contents
28 Document ID: RDWR-AD-V0231-UG1105
Appendix F – SSL Encryption,Certificates and Ciphers................................... 621
SSL Encryption ......................................................................................................... 621
Encryption Protects Data During Transmission ................................................................. 621
Credentials Establish Identity Online ................................................................................. 622
Authentication Generates Trust in Credentials .................................................................. 622
Certificates ................................................................................................................ 622
Online Certificate Status Protocol (OSCP) ........................................................................ 625
Certificate Signing Request (CSR) .................................................................................... 626
Certificate Authority ........................................................................................................... 626
Ciphers and Cipher Suites ........................................................................................ 628
Ciphers .............................................................................................................................. 628
Cipher Suites ..................................................................................................................... 629
Cipher Suites Used by AppDirector ................................................................................... 630
Securing a Connection - the SSL Handshake ................................................................... 637
AppDirector User Guide
Introducing AppDirector
Document ID: RDWR-AD-V0231-UG1105 29
Chapter 1 – Introducing AppDirector
This chapter introduces AppDirector capabilities and provides a brief description of its main characteristics in the following sections:
• A
ppDirector Modules
, page 29
• Configuration and Workflows for AppDirector
, page 33
AppDirector by Radware is an Application Delivery Controller (ADC) that provides Layer 4-7 local and global application delivery and acceleration across Web applications and Database server farms, ensuring application uptime, global redundancy, and user experience optimization. AppDirector provides full availability, high performance, and complete security for mission critical applications.
AppDirector is intended for organizations that conduct their business using networked applications, the Internet, or a private intranet to communicate between offices that are geographically dispersed or between business partners and end users, as in e-commerce or online banking. As a result of the reliance on networked/Web applications like ERP, CRM, or Citrix applications, there has been significant growth in the volume of transactions and in the processing power required to execute them efficiently. AppDirector relies on a successful combination of a powerful hardware platform and an application smart service to achieve a high level of availability, performance, and security. AppDirector is based on Radware’s 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
AppDirector Modules
AppDirector successfully combines various functional modules. AppDirector’s advanced Health Monitoring module verifies the availability of the entire transaction path and resources. The Traffic Redirection module works closely with the Health Monitoring module and performs Layer 4-7 switching based on resource availability. Traffic Redirection optimizes server usage by applying intelligent dispatch load balancing algorithms. If network elements fail (for example, 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 ensures the availability of all the network elements required for the completion of a successful transaction, including routers, backend servers and applications. This module enables you to create any type of Layer 2 - Layer 7 Health Check on any network element. The wide variety of predefined Health Checks allows you to meet the specific requirements of your network. For more information on Health Monitoring, see Configuring Health Monitoring, page 353
.
AppDirector User Guide
Introducing AppDirector
30 Document ID: RDWR-AD-V0231-UG1105
Traffic Redirection
The Traffic Redirection module provides Layer 4 - Layer 7 switching capability. This module performs server selection in a Farm, based on availability, load, and content considerations. For more information on Traffic Redirection, see Traffic Management and Application Acceleration, page 175
.
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. See Traffic Management and Application Acceleration, page 175
.
When content is distributed among multiple sites, AppDirector applies a global Traffic Redirection solution combining advanced load and proximity-based decisions with different redirection methods optimizing resource usage and providing accelerated content delivery. This enables you to add network elements without service interruption in a geographically dispersed global context .
Global Traffic Redirection
AppDirector-Global provides global and local internet traffic management services redirecting 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. Acceleration Engine
AppDirector assists acceleration with the following attributes:
• Reduces web-application latency across the WAN and decreases application response time.
• Offload servers from handling SSL decryption and encryption.
• Reduce "chattiness" of TCP and HTTP protocols.
• Improves response time by offloading TCP connection handling. It accelerates repetitive content fetching time by using a cache.
• Using compression, reduces WAN bandwidth consumption and accelerates web-pages on low bandwidth (dial-up, wireless) WAN connections.
Secure Socket Layer (SSL) Offload
AppDirector can accelerate SSL traffic and offload servers. AppDirector handles the SSL key negotiation with the client and encrypting and decrypting of communication. AppDirector serves as a proxy, terminating the SSL client sessions and opening a separate session to the backend servers.
Trust-Service Status List (TSL) AppDirector is the only ADC solution that provides full support of the TSL standard allowing:
• Automatic retrieval and updates of the client authentication configuration according to the TSL standard.
• OCSP Caching to minimize authenticating infrastructure overload of Advance Clients Certificates Field. • Verification capabilities for granular control over allowed certificate holders access at network level.
TCP Optimization
AppDirector reorders TCP packets arriving that arrive out of order, offloading. This offloads this task from the backend server.
AppDirector User Guide
Introducing AppDirector
Document ID: RDWR-AD-V0231-UG1105 31
Web Compression
AppDirector compresses HTTP traffic to reduce the latency for clients that access web applications over WAN. Compression reduces the size of the objects and therefore the objects take less time to download over the WAN. Latency is high for instance, when clients are located a large number of network hops away from the server, over satellite links, or when bandwidth (and thus transfer rate) is low. AppDirector supports Compression in software by default. An optional Hardware Compression module enables AppDirector to handle higher throughput from the web application server. In addition, AppDirector can reduce the size of images that are not compressible, by reducing the amount of information in them with different techniques
Web Caching
AppDirector improves HTTP response times by caching web objects from the server and serving them from its local cache. This, in turns, saves resources on the backend servers. AppDirector caches server content according to the cache settings in the HTTP header and configuration setting used.
Management Tools
The following management tools can be used to manage a single AppDirector device.
• Web Based Management (WBM), using HTTP and/or HTTPS.
• Command Line Interface (CLI), using Telnet, SSH, or Serial Console access.
• SNMP; you can configure and monitor the device using the SNMP protocol.
Please consult the latest accompanying Release Notes for this AppDirector version for detailed management tool support information.
Licenses The licensing mechanism is used to provide an easy path for adding product capabilities after initial product purchase. There are several types of license available.
Capabilities License
This is available on all platforms and allows you to add product specific capabilities (such as Global Load Balancing) and APSolute OS capabilities (BWM and Security). This license is accumulative – it can both enable a product specific capability and APSolute OS capability for example.
This is available on all platforms and allows you to add product specific capabilities such as Global Load Balancing Capability. For more information on AppDirector and AppDirector Global capabilities, see Radware Devices Used in Global Solution, page 295
.
Note:Adding these capabilities via this license requires a device reboot.
Throughput License The Throughput License defines the product throughput capacity level and enables capacity upgrade. The licensed throughput is applied on the sum of incoming throughput through all physical data ports. The throughput license upgrade does not require rebooting the device.
SSL CPS License AppDirector comes bundled with basic SSL capabilities (maximum number of connections per second - CPS) which can be upgraded by license. This license defines the SSL offload capacity level and enables capacity upgrade (SSL CPS) for AppDirector (version 2.0 and up). The SSL CPS license upgrade does not require device rebooting.
AppDirector User Guide
Introducing AppDirector
32 Document ID: RDWR-AD-V0231-UG1105
Compression Throughput License
This license defines the HTTP compression capacity level and enables capacity upgrade (compression throughput in Mbps) for AppDirector (version 2.0 and later). The HTTP Compression license upgrade does not require device rebooting.
Note:If a Hardware Compression card is installed in the device, the HTTP Compression throughput is automatically set to unlimited.
TSL License
This allows you to handle situations where one organization is responsible for the creation, distribution and management of Digital ID cards (for example, Government), and other organizations need to authenticate users based on the Digital IDs (for example, Tax management, Health Insurance, Financial institutes, employers, etc.).
Note:Please also see the Radware Licensing Model for further information.
IPv6 Support in AppDirector
AppDirector supports dual stack IPv6 and IPv4 environments, including IPv4/IPv6 gateway functionality. AppDirector is certified for compliance with the IPv6 Ready logo phase 1 requirements. AppDirector application delivery capabilities, including Layer 4 & Layer 7 traffic management, application acceleration (SSL offload, caching, compression), global traffic redirection, high availability (health monitoring, VRRP failover), are supported for the following types of traffic:
• Pure IPv4: IPv4 client to IPv4 servers
• Pure IPv6: IPv6 client to IPv6 servers
• Mixed (gateway):
• IPv4 client to IPv4 and/or IPv6 servers
• IPv6 client to IPv4 and/or IPv6 servers
The different IP objects in the AppDirector configuration can now accept both IPv4 and IPv6 addresses, unless otherwise specified.
AppDirector User Guide
Introducing AppDirector
Document ID: RDWR-AD-V0231-UG1105 33
Configuration and Workflows for AppDirector
This section describes the step-by-step configuration for AppDirector. It is common to many scenarios and you can adjust it to meet your specific needs using your own network's IP addresses.
• B
efore Installation and Configuration
, page 33
• Configuration for all AppDirectors
, page 35
Before Installation and Configuration
Before installation, Radware recommends you take into consideration the following:
• Radware Platforms Supported
, page 33
• Physical Connectivity Concerns
, page 33
• IP Allocation Concerns
, page 34
• Management Concerns
, page 34
• Technical Support
, page 34
Radware Platforms Supported
AppDirector 2.30 supports the following Radware platforms:
• OnDemand Switch VL and VL XL
• OnDemand Switch 1 and 1 XL
• OnDemand Switch 2 and 2 XL
• OnDemand Switch 3 v.2 and 3 XL
For further information, see the Radware Installation and Maintenance Guide.
Physical Connectivity Concerns
A Radware device acts as a switch. Crossed cables should be used between switches and straight cables should be used for connecting other network hosts. Make sure you use the right type of cable as stated. Some platforms support the Auto sensing feature (MDIX) and can operate with any type of cable, however this feature is disabled once you disable Auto negotiation. Only GBICs that have been tested and approved by Radware can be used. For an updated list, refer to: http://www.radware.com/content/support/faq/gigabitethernetandgibcsupport.asp.
Auto negotiation is activated by default. In most cases, this is the preferred option. Verify that it is activated on the other side as well.
Note:Disabling Auto negotiation also disables the cable type Auto sensing feature (MDIX).
Optical cables are not provided by Radware and need to be purchased separately. Some devices use SC connectivity and LC. Make sure you have the appropriate cable. The copper cables that Radware provides are intended for management only and should not be used for other types of traffic. CAT5 certified copper cables must be used.
When connecting to network switches and working with Radware's proprietary redundancy protocol, ensure that you disable Spanning Tree or at least enable Port Fast on the relevant ports (on the switch). You can also set the Spanning Tree to operate in fast learning mode on the relevant ports. AppDirector User Guide
Introducing AppDirector
34 Document ID: RDWR-AD-V0231-UG1105
IP Allocation Concerns
Ensure that you have the IP addresses allocated and defined in your network for the AppDirector's interfaces, new servers, NAT IP addresses (if activated on the AppDirector), DNS IP addresses (if activated on the AppDirector) and for the redundant AppDirector as well.
Pay particular attention to the Local Triangulation implementation and VLANs (explained in this document) where the IP addresses of the servers should be public routable IP addresses.
Management Concerns
Radware management uses SNMP communication running on UDP port 161. Ensure that this communication port is not blocked by your firewall.
Configuration upload/download action uses TFTP protocol. Ensure that TFTP is not blocked by your firewall and the management station is not NATed toward the Radware device. As TFTP traffic is initiated from the Radware device to the management station, a relevant firewall rule should be configured. UDP ports 162 and 69 are used for TFTP. Radware devices can also use HTTP, HTTPS, Telnet, and SSH for management. If you choose to activate one of the above, verify that they are not blocked by your firewall. Traffic direction is from the management system to the Radware device. Radware devices have a console port for terminal communication. This uses an RS232 cable (provided by Radware). Technical Support
Radware offers its Certainty Support Program, a suite of technical support packages in various levels. You can view all programs at: http://www.radware.com/content/support/default.asp.
Once you purchased the relevant Certainty Support package you can either contact Radware via email (support@radware.com
) or via the phone using our worldwide toll free numbers. An updated list is available at: http://www.radware.com/content/support/support program/contact.asp
.
Additional information about the Radware Certainty Support program is available at: http://
www.radware.com/content/document.asp?_v=about&document=2774
.
AppDirector User Guide
Introducing AppDirector
Document ID: RDWR-AD-V0231-UG1105 35
Configuration for all AppDirectors
The following general workflow with mappings to appropriate chapters is shown here to help you configure your AppDirector devices.
AppDirector User Guide
Introducing AppDirector
36 Document ID: RDWR-AD-V0231-UG1105
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 37
Chapter 2 – Administering and Monitoring AppDirector
This chapter provides information on the AppDirector management and maintenance processes. For information on installing and configuring AppDirector, see the Radware Installation and Maintenance Guide. This chapter includes the following sections:
• Supported Management Interfaces for AppDirector
, page 37
• Version and Configuration Management
, page 54
• T
uning AppDirector
, page 65
• Monitoring AppDirector
, page 83
• B
asic Switching (Layer 2 Capability)
, page 98
• I
P Addressing and Routing
, page 117
• Redundancy
, page 143
Supported Management Interfaces for AppDirector
This section discusses management interfaces supported by AppDirector and includes these topics:
• Web Based Management
, page 38
• Web Services
, page 39
• Command Line Interface
, page 40
• Configuring Telnet
, page 43
• Configuring FTP Server
, page 45
• Configuring SNMP
, page 45
Web Based Management (WBM) is the main management interface for Radware products. Additionally, you can manage your AppDirector with Command Line Interface (CLI).You can connect AppDirector devices to management interfaces through network physical interfaces or serial ports. These port types are supported:
• For network connection: SNMP, HTTP, HTTPS, Telnet, SSH.
• For serial port connection: RS-232 up to 115 Kbps (default is 19,200 Kbps).
Note:Device management is available only over a IPv4 network.
This table lists the AppDirector physical interfaces and the supporting management interfaces:
Port
Web Based Management
Command Line Interface
SNMP V1, V3
HTTP x
Secure Web x
Telnet x
SSH x
RS-232 x
AppDirector User Guide
Administering and Monitoring AppDirector
38 Document ID: RDWR-AD-V0231-UG1105
Web Based Management
The WBM (Web Based Management) graphical user interface (GUI) does not require client installation, and is designed for easy and fast single device management via HTTP or HTTPS (for secure access).
When using WBM, on-line help is available (by clicking the ? icon that appears on every screen) from the Radware corporate website. However, you can specify a custom location for the help files.
Web Server Parameters
You can use Web Server Parameters to enable and define to which port the WBM should be assigned.
To configure the Web Based Management 1.From the Services menu, select Management Interfaces > Web Server > Web. The Web Server Parameters window appears.
2.Set the parameters.
3.Click Set. Your configuration is set.
Parameter
Description
Web Server Port Port to which the Web Based Management is assigned.
Web Server Status Enables or disables the status of the web server.
Web Help Location Location (path) of the web help files.
Web Access Level Values: Read Write (default) or Read Only. This setting affects both WBM and Secure WBM.
When WBM Access Level is set to Read Only, users using WBM or Secure WBM experience the following limitations:
• Cannot change the configuration of the device
• Cannot view the Community Table or User Table
• Have no access to SSH Public Key Table
• SSL keys and certificates cannot be viewed
• Configuration File cannot be sent to or received from the device
• Software update to the device is not allowed
• Cannot reset the device
Note: Setting this requires restarting the device.
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 39
Secure Web
You can define the parameters for obtaining secure HTTP requests. To define secure web parameters 1.From the Services menu, select Management Interfaces > Web Server > Secure Web. The Secure Web Parameters window appears
2.Set the parameters.
3.Click Set. Your configuration is set.
Supported Browsers
WBM is supported with the following Internet browsers:
• Microsoft Internet Explorer version 6 (when using Windows operating systems)
• Microsoft Internet Explorer version 7 • Microsoft Internet Explorer version 8 • Mozilla (when using Linux operating systems)
• Firefox
Web Services To provide customers with the capability to develop enhanced application monitoring, customized application delivery network management applications and advanced automation tools, Radware provides a web services interface on AppDirector via APSolute API, an open standards-based SOAP (XML) API. AppDirector Web Services operate via HTTP or HTTPS requests, like a regular web browser. Web Services are automatically enabled if either web or secure web management interfaces are enabled on the device. 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.
Integration with APSolute API gives you a comprehensive view of the AppDirector devices performance including historical data analysis and trending, performance diagnostics, availability reports, and automation of maintenance operations and fine-tuning of AppDirector for optimal application delivery based on parameters external to AppDirector.
Parameter
Description
Secure Web Port Port through which HTTPS gets requests.
Secure Web Status Enables or disables (default) the status of the web server.
Secure Web Certificate Entry Name
Certificate file used by secure web for encryption. AppDirector User Guide
Administering and Monitoring AppDirector
40 Document ID: RDWR-AD-V0231-UG1105
The APSolute API is a SOAP/XML interface providing full access to Radware devices for third-party applications and utilizing common development languages including Java, Visual Basic/C#, and Perl. APSolute API offers two approaches to interact with Radware devices:
1.Issuing CLI commands and receiving output via a generic SOAP method.
Note:This interface will not provide support for:
>> Non- configuration commands or monitoring, such as ping, telnet, or trace-route. >> Asynchronous output commands (for example, accelerator related CLI commands).
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).
APSolute API Software Development Kit (SDK) The APSolute API SDK provided for each AppDirector version, contains components and documentation to enable development of control and monitoring capabilities in custom-developed applications. This includes:
• WSDL files for all interfaces and modules.
• API Reference.
• Product overview.
• Sample code for basic device configuration/monitoring functions.
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:
Command Line Interface
The Command Line Interface (CLI) is a built-in, text-based menu system for access via local terminal or remote Telnet or SSH session. The main CLI menu is displayed in the following table: Development Environments
Languages
Microsoft Visual Studio .NET 2005 Visual Basic & C#
Axis 1.3 Java 1.50
Active Perl 5.8.8 Perl
CLI Command
Explanation
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
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 41
login
Login into the device
logout
Logout of the device
AppDirector
AppDirector parameters
manage terminal more-prompt
This parameter applies to all users, can be seen in "system config immediate" output and is kept between reboots of the device. However this parameter is NOT exported with the configuration file. 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
CLI Command
Explanation
AppDirector User Guide
Administering and Monitoring AppDirector
42 Document ID: RDWR-AD-V0231-UG1105
CLI Supported Capabilities
Radware's Command Line Interface provides the following capabilities:
• Consistent, logically structured, and intuitive command syntax.
• A system config
command to view the current configuration of the device, formatted as CLI command lines.
• Pasting the output of system config
, or part of it, to the CLI of another device, using the system config set
command. This option can be used for easy configuration replication.
• Help and command completion keys.
• Command line editing keys.
• Command history.
• Configurable prompt.
• Configurable banner for Telnet and SSH. • Ping: Ping other hosts on the network to test availability of those hosts.
• Traceroute: Use command trace-route <destination IP addr>
. Output format:
AppDirector#trace-route www.radware.com
trace-route to host 209.218.228.203:
1: 50ms 50ms 50ms 212.150.43.130
2: 50ms 50ms 50ms 80.74.101.129
3: 50ms 50ms 50ms 192.116.214.2
4: * * * 5: 50ms 50ms 50ms 80.74.96.40
• Telnet client: To initiate a Telnet session to remote hosts, use CLI command telnet <IP address>
. • SSH client: To initiate a SSH session to remote hosts, use CLI command ssh <IP address>
.
• DNS Lookup: Uses configured DNS servers to query IP addresses of a host name. This requires that DNS client is enabled and DNS servers configured. The DNS client also enables using host names rather than IP addresses in commands such as trace-route, ping, telnet, etc. Use the command nslookup <hostname>
. CLI Session Time-Out
You can define a period of time during which the connection with the device via the console is kept despite the session’s 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
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 43
Configuring Telnet
A Telnet connection offers the convenience of accessing the device from any workstation connected to the network. To establish a Telnet connection with the device, run the Telnet program on your workstation and issue the Telnet command, followed by the device IP address:
telnet <IP address>.
To configure Telnet access 1.From the Services menu select Management Interfaces > Telnet. The Telnet window appears. 2.Set the parameters
.
3.Click Ok. Your configuration is set.
Configuring SSH Secure Shell or SSH is a network protocol that allows data to be exchanged over a secure channel between two computers. Encryption provides confidentiality and integrity of data. SSH uses public-
key cryptography to authenticate the remote computer and allow the remote computer to authenticate the user, if necessary. As a secure alternative to using Telnet to manage device configuration, SSH ensures that all data sent over the network is encrypted and secure.
SSH Public Keys
In addition to normal password authentication, the device also supports SSH public key authentication. For this method the user has to generate an SSH key pair (public key and private key).
Parameter
Description
Telnet Port The TCP port used by the Telnet.
Telnet Status Enables and disables the Telnet access to the device. Telnet Session Timeout
Time-out (in minutes) required for device to maintain connection during periods of inactivity. When you enter a user name and password, if you make three incorrect login attempts, the terminal is locked for 10 minutes and no further logins are accepted from that IP address.
Values: 1 – 120 minutes.
Default: 5 minutes. Notes:
• To avoid affecting device performance, time-out is automatically checked every 10 seconds. This means that the actual time-out can be up to 10 seconds longer.
• If you want to set your session to never expire then set the timeout to 0 (= unlimited).
Telnet Authentication Timeout
Time-out (in seconds) required to complete authentication process. Values: 10 – 60 seconds.
Default: 30 seconds.
AppDirector User Guide
Administering and Monitoring AppDirector
44 Document ID: RDWR-AD-V0231-UG1105
Note:When both password and public key are configured for a user, the Authentication Method configured in the client software will dictate which authentication is selected for this user.
To configure an SSH public key 1.From the Security menu select Certificates > Import. The Import PKI Components window appears.
2.Import the user SSH public key (Entry Type=Key). See Importing Certificates, page 453
for details.
3.From the Security menu select Users. The Users Table and Authentication window appears.
4.Double-click on the existing user or click Create to add a new user. The User Table Update/
Create window appears.
5.In the SSH public key name drop-down select the relevant key configured in step 2 and click Set. The SSH public key is configured for this user.
Configuring the SSH Connection
There are two versions of SSH: SSH1 and SSH2. AppDirector supports only SSH2.
To set the SSH server connection parameters 1.From the Services menu select Management Interfaces > SSH > Server. The Secure Shell Parameters window appears.
2.Set the parameters.
3.Enter the SSH Port and set the SSH Status to Enable.
4.Click Set. Your configuration is set.
Parameter
Description
SSH Port Source port for the SSH server connection. SSH Status Enables or disables (default) SSH access to the device. SSH Session Timeout Timeout (minutes) for device to maintain connection while inactive. Values: 1 – 120 minutes. Default: 5 minutes
Note: To avoid affecting device performance, time-out is automatically checked every 10 seconds. This means that the actual time-out can be up to 10 seconds longer
SSH Authentication Timeout
Timeout (seconds) for completing authentication process. Available for Telnet / SSH only. When you enter a user name and password, if you make three incorrect login attempts, the terminal is locked for 10 minutes and no further logins are accepted from that IP address.
Values: 10 – 60 seconds. Default: 30 seconds. AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 45
Configuring FTP Server
The FTP Server allows you to connect to the device using FTP and transfer files to/from the device flash memory.
To configure FTP Service 1.From the Services menu, select Management Interfaces > FTP Server. The FTP Server window appears, which contains the following parameter:
2.Click Set. Your configuration is set.
Note:To access the device via a FTP service, the FTP server must be enabled prior to access
Configuring SNMP The Simple Network Management Protocol (SNMP) is an application layer protocol that facilitates the exchange of management information between network devices. SNMP is a part of the Transmission Control Protocol/Internet Protocol (TCP/IP) protocol suite. Radware devices work with the following versions of SNMP: SNMPv1, SNMPv2, and SNMPv3. Network management systems contain two primary elements: Managers and Agents. The Manager is the console through which the network administrator performs network management functions. Agents are entities that interface with the device being managed, allowing you to change or retrieve objects. These objects are arranged in what is referred to as Management Information Base (MIB). SNMP is the protocol that allows managers and agents to communicate to access these objects.
SNMPv3
SNMPv3 contains two communication layers between manager and agent:
• User Security Model (USM), which provides secure communication, including message integrity and privacy.
• View-Based Access Control Model (VACM), which provides access permissions. Parameter
Description
FTP Server Port Application port to use to access the FTP server on the device.
FTP Server Status Enable/Disable the FTP Server on the Device.
AppDirector User Guide
Administering and Monitoring AppDirector
46 Document ID: RDWR-AD-V0231-UG1105
To set the SNMP Global parameters 1.From the Security menu, select SNMP > Global Parameters. The SNMP Global Parameters window appears.
2.Set the parameters. 3.Click Set. Your configuration is set.
Defining SNMP Users
With SNMPv3 user-based management, each user can have different permissions based on the user name and connection method. You can create a new user by cloning the definitions an existing user. In the User Based Security Model window, you can define users who can connect to the device and store the access for each SNMP user. You can define users that can connect to the device and store the access parameters for each SNMP user in the User Based Security Model window.
To define a new user
1.From the Security menu select SNMP > User Table. The User Table window appears.
2.Click Create. The User Table Create window appears.
3.Set the parameters.
4.Click Set. Your configuration is set.
Parameter
Description
Supported SNMP Versions SNMP versions currently supported by the SNMP.
Supported SNMP Versions After Reset
SNMP versions supported by the SNMP agent after resetting the device. Check the SNMP version you wish to support. Un-check the versions not supported.
SNMP Port UDP port where the agent is listening for SNMP requests.
SNMP Status Status of the SNMP agent. Default: Enable
Parameter
Description
User Name Type name of the new user, up to 18 characters.
Authentication Protocol
Protocol used during authentication process. meaning using clear text during the session. Values: None, (default), MD5, SHA1, SHA2.
Authentication Password
Enter an authentication password.
Privacy Protocol Algorithm to be used for encryption. Default: None, which means that the data is not encrypted. Possible value is DES.
Privacy Password Enter a user privacy password.
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 47
SNMP VACM Edit Security to Group
SNMPv3 permissions are defined for groups of users. If, based on the connection method, there is a need to grant different permissions to the same user, you can associate a user to more than one group. For example, if user A connects to a Radware device using SNMPv3 with authentication and privacy, the user gets Read-Write permissions; if the same user A connects to a Radware device with authentication and without privacy (data is not encrypted), then the same user gets Read-Only permissions. You can associate users with groups listed in the VACM Edit Security to Group window. Access rights are defined for groups of users.
VACM MIB View The View table defines subnets of the MIB tree. These views are used to allow Read-Write access based on the MIB tree. The same Family View name can be used for multiple entries to allow maximum flexibility. Each entry can include or exclude parts of the entire MIB tree. SNMP Access
The Access table binds the groups, views, and security models. It grants permissions to the groups, based on the SNMP version. You can define the access rights for each group and security model in the VACM Group Access window. Objects can be accessed for a read, write, or notify action based on the Read View Name, Write View Name, and Notify View Name parameters. These parameters depend on the specified security model. The Read, Write, and Notify permissions are configured for Family View names, which are defined in the VACM MIB View
window, (see VACM MIB View
, page 47
).
To configure the SNMP Access Table 1.From the Security menu, select SNMP >Access Table. The SNMP Community Table window appears.
2.Click Create. The SNMP Access Table Create window appears.
3.Set the parameters. Parameter
Description
Group Name The name of your group.
Security Model Select SNMP version that represents the required Security Model.
Security models are predefined sets of permissions that can be used by the groups. These sets are defined according to the SNMP versions. By selecting the SNMP version for this parameter, you determine the permissions set to be used.
Values: Any, SNMPv1 (Default), or User Based (SNMPv3).
Security Level Select one of the relevant Security Levels:
• NoAuthNoPriv (Default): No authentication or privacy are required
• AuthNoPriv: Authentication is required, but Privacy is not required
• AuthPriv: Both authentication and privacy are required
ReadView Name Name of one or more entries in View Tree Family Table. Specifies which objects in the MIB tree are readable by this group.
AppDirector User Guide
Administering and Monitoring AppDirector
48 Document ID: RDWR-AD-V0231-UG1105
4.Click Set. Your configuration is set.
SNMP Target Address
In SNMP v3, this table contains transport addresses to be used in the generation of traps. If the tag list of an entry contains a tag from the SNMP Notify Table, this target is selected for reception of notifications. For SNMP version 1 and 2 this table is used to restrict the range of addresses from which SNMP requests are accepted and to which SNMP traps may be sent. If the Transport Tag of an entry in the community table is not empty it must be included in one or more entries in the Target Address Table window.
The Target Address Table window allows you to set and update the SNMP Target Parameters. To configure the SNMP Target Address Table
1.From the Security menu, select SNMP > Target Address Table. The SNMP Target Address Table window appears.
2.Click Create. The SNMP Target Address Table Create window appears.
3.Set the parameters. 4.Click Set. Your configuration is set.
Tip: The SNMP Target Address window also allows you to access the SNMP Target parameters window (see SNMP Target
, page 49
).
WriteView Name Name of one or more entries in View Tree Family Table. Specifies which objects in the MIB tree are writable by this group.
NotifyView Name Name of one or more entries in View Tree Family Table. Specifies which objects in MIB tree can be accessed in notifications (traps) by this group.
Parameter
Description
Name Name of this entry.
Address-Port Number of the Target Port. (TCP port to be used).
Values: 161 for SNMP Access, 162 for SNMP Traps (Default).
Address-Port must be a hex string ([1...255] bytes)
For Example, 0.0.0.0-162
Tag List List of tags separated by spaces. The tags are either tags from the Notify table or Transport tags from the Community table.
Parameters Name of entry in Parameters Table used when sending the SNMP Traps
Mask Address mask (of the subnet) specifies a set of addresses that are allowed to use a community string and verifies the source addresses for a group of target addresses. The address-mask combined with the address defines a range of addresses.
Default: 0.0.0.0
Parameter
Description
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 49
SNMP Target The Target Parameters Table window contains parameters to be used in generating a message. Entries in this table are referenced in the Target Address Table window. To configure the SNMP Target Parameters Table
1.From the Security menu, select SNMP > Target Parameters Table. The SNMP Target Parameters Table window appears.
2.Click Create. The SNMP Target Parameters Table Create window appears.
3.Set the parameters.
4.Click Set. Your configuration is set.
SNMP Community Table (SNMPv1 and SNMPv2 Only) The Community table allows backwards compatibility with SNMPv1 and SNMPv2 mapping community strings to users. Once a user is connected to a device with SNMPv1 or SNMPv2, the device checks the Community String sent in the SNMP packet. Based on a specific community string, the device maps the community string to a predefined user, which belongs to a group with certain access rights. Therefore, when working with SNMPv1 or SNMPv2, users, groups, and access must be defined. You can map community strings into user names and vice versa using the SNMP Community Table window. This table restricts the range of addresses from which SNMP requests are accepted and to which traps can be sent. The SNMP Community Table is used only for SNMP versions 1 and 2. Parameter
Description
Name Name of this entry.
Message Processing Select one of the following:
• SNMPv1 (Default)
• SNMPv2c
• SNMPv3
Security Model Select the SNMP version that represents the required Security Model. Security models are predefined sets of permissions that can be used by the groups. These sets are defined according to the SNMP versions. By selecting the SNMP version for this parameter, you determine the permissions set to be used.
Values: SNMPv1 (Default), SNMPv2c or User Based (SNMPv3).
Security Name The name of the user.
Security Level Select one of the relevant Security Levels:
• NoAuthNoPriv (Default): No authentication or privacy are required
• AuthNoPriv: Authentication is required, but Privacy is not required
• AuthPriv: Both authentication and privacy are required
AppDirector User Guide
Administering and Monitoring AppDirector
50 Document ID: RDWR-AD-V0231-UG1105
To configure the SNMP Community Table 1.From the Security menu, select SNMP > Community Table. The SNMP Community Table window appears.
2.Click Create. The SNMP Community Table Create window appears.
3.Set the parameters. 4.Click Set. Your configuration is set.
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 48
). An entry in the Target Address table whose tag list contains the tag of one or more notification table entries is selected for receipt of notifications. To configure the SNMP Notify Table
1.From the Security menu, select SNMP >Notify Table. The SNMP Notify Table window appears.
2.Click Create. The SNMP Notify Table Create window appears.
3.Set the parameters. 4.Click Set. Your configuration is set.
Parameter
Description
Index A descriptive name for this entry.
Community Name The community string.
Security Name User name associated with community string.
Transport Tag Specifies a set of target addresses from which the SNMP accepts SNMP requests and to which traps can be sent. Target addresses identified by this tag are defined in the “target address table”. If this string is empty, addresses are not checked when an SNMP request is received or when a trap is sent. If this string is not empty, the transport tag must be contained in the value of the “tag list” of at least one entry in the “target address table.”
Parameter
Description
Name A descriptive name for this entry.
Tag This string selects one or more entries in the Target Address table. All entries whose tag list contains this tag are selected for receipt of notifications.
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 51
SNMP Groups Table
You can associate users with groups in the Groups Table window. Access rights are defined for groups of users. To configure the SNMP Groups Table 1.From the Security menu, select SNMP > Groups Table. The SNMP Groups Table window appears.
2.Click Create. The SNMP Groups Table Create window appears.
3.Set the parameters. 4.Click Set. Your configuration is set.
SNMP View Table
The View Table window allows you to define subsets of the MIB tree for use in the Access Table. Different entries may have the same name. The union of all entries with the same name defines the subset of the MIB tree and can be referenced in the Access Table through its name. To configure the SNMP View Table
1.From the Security menu, select SNMP > Community Table. The SNMP View Table window appears.
2.Click Create. The SNMP View Table Create window appears.
Parameter
Description
Security Model Select SNMP version for association with this group.
Values: SNMPv1, User Based (SNMPv3).
Security Name Select relevant security name, (name as defined in the Users Table.)
Group Name Select name from list of all available group names.
AppDirector User Guide
Administering and Monitoring AppDirector
52 Document ID: RDWR-AD-V0231-UG1105
3.Set the parameters. 4.Click Set. Your configuration is set.
>> If the number of bits in the subtree mask is greater than the number of nodes of the OID, the excessive bits of the subtree mask will be ignored during subtree mask-OID matching.
Parameter
Description
View Name Name of this entry.
The MIB view is a sub-set of MIB. You can bind a community name/
username with a MIB view when configuring an agent, to control the MIB objects that NMS can access. You can configure the objects in the MIB view as excluded or included
• Excluded: indicates that not all the nodes on the subtree are included in the current MIB view.
• Included: indicates that the current MIB includes all the nodes on the subtree.
Subtree The Object ID of a subtree of the MIB. When combined with the corresponding instance of MASK, defines a family of view subtrees. MIB stores data using a tree structure. A node of the tree is a managed object and can be uniquely identified by a path starting from the root node. The managed object system can be uniquely identified by a string of numbers {1.3.6.1.2.1.1}. This string of numbers is the OID of the managed object system.
A subtree can be identified by the OID of its root node. For example, the OID of the subtree with the root node being private is the OID of node private –– {1.3.6.1.4}.
Subtree Mask A subtree OID used with a subtree mask defines a view subtree. A subtree mask is in hexadecimal format. It indicates which sub-identifiers of the associated subtree OID are significant for a particular MIB view instance. After it is converted to binary bits, each bit corresponds to a node of the OID, where:
• 1 means full match, that is, the OID of the MIB object to be accessed must be identical to the subtree OID.
• 0 means wildcard match, that is, the OID of the MIB object to be accessed can be different from the subtree OID.
For example, provided the subtree mask 0xDB (11011011 in binary) and the subtree OID 1.3.6.1.6.1.2.1, their relationship is as shown below. The view determined by them includes all the nodes under the subtree whose OID is 1.3.*.1.6.*.2.1, where * represents any number.
Type Defines if the object defined in entry is included/excluded in MIB view.
Values: Included (Default) or Excluded,
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 53
>> If the number of bits in the subtree mask is smaller than the number of nodes of the OID, the short bits of the subtree mask will be set to 1 during subtree mask-OID matching.
>> If no subtree mask is specified, the default subtree mask (all ones) will be used for mask-OID matching.
Create SNMP User
You can define users that can connect to the device and store the access parameters for each SNMP user in the User Based Security Model window.
To define a new user
1.From the Security menu select SNMP > Create SNMP User. The Create SNMP User window appears.
2.Click Create. The User Table Create window appears.
3.Set the parameters. 4.Click Create User. The new SNMP user is created.
Note:The Configuration file of the device, that contains SNMPv3 users with authentication, can only be used by the specific device that the users configured . When exporting the configuration file to another device, the passwords need to be re-entered, since passwords (of SNMPv3 users) can not be exported from one device to another. Therefore there must be at least one user in the user table (to be able to change the password) in case the configuration file is uploaded to another device. Note that this is according to SNMPv3 RFC.
Parameter
Description
SNMP Version SNMPv3, SNMPv1, SNMPv2c
User/Community Name User name or community string name.
Passwords
Use Authentication Checkmark this box to use authentication.
Authentication Password Enter an authentication password.
Use Privacy Checkmark this box to use privacy.
Privacy Password Enter a user privacy password.
Permissions
Read Values: ReadOnlyView/iso (default)
Write Values: ReadOnlyView/iso/none (default)
Notify Values: ReadOnlyView/iso/none (default)
AppDirector User Guide
Administering and Monitoring AppDirector
54 Document ID: RDWR-AD-V0231-UG1105
Version and Configuration Management
This section includes the following topics:
• Upgrades
, page 54
• Software Versions
, page 54
• Configuration File Management
, page 56
• Licensing and Upgrading Licenses
, page 60
• Resetting Devices
, page 64
• Device Shutdown
, page 65
Upgrades
You can upgrade all Radware devices to newer versions with a straightforward FLASH process. Depending on the maintenance contract, you are either eligible for new versions with new features, or for maintenance versions only.
Performing an AppDirector device upgrade involves two steps:
• Saving the current device configuration.
• Upgrading the device software. Radware releases updated versions of AppDirector software that can be uploaded. You can upgrade a device using one of these methods:
• WBM
• CLI
• APSolute Insite
A device upgrade enables new features and functions without altering the existing configuration. New software versions require a password. This can be obtained from the Radware corporate website. You must obtain this password before you load the upgrade file onto the device. If you do not supply the correct password during upgrade, you cannot proceed. A maintenance-only upgrade does not require a password. The password is based on the software version file and on the Base MAC Address of the AppDirector unit. Notes:
>> Before upgrading, save the existing configuration file.
>> Before upgrading, refer to the appropriate Release Notes.
>> When downgrading to a software version not supporting the current device license, the license is lost. Contact Radware for more information.
Software Versions
To display a list of software versions loaded on the device
• In WBM, click File > Software List.
• In the Command Line Interface, use the command: system file-system software.
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 55
To change active software version
• In WBM, click File > Software List. Select the inactive version (Inactive Field has value False), and change the Active parameters to True. Click Set to record your preferences. You are prompted to reboot the device.
• In the Command Line Interface, use the command:
system file-system config act-appl set X,
where X is the application index as previously displayed.
Notes:
>> Each software version has its own configuration file
>> You can download a new software version by using WBM. For versions using the File System, the software file is in TAR format and for previous versions, it appears in binary (BIN) format.
Updating Device Software
To upgrade the software version 1.Download the AppDirector software update zip file from Radware’s Software Status Matrix (http://www.radware.com/content/support/software/statusmatrix/default.asp). Write down the software version - you will need it later.
2.Unzip the file. You will see a file named: appdirector_[platform]_[major version]_[minor version]_[bugfix version].tar. This is the software update file.
3.If you are upgrading or downgrading to a different major version, use the Password Generator (http://www.radware.com/content/support/pwordgen/default.asp) to generate a password.
4.From browser window, enter IP address of your AppDirector. Web Based Management opens.
5.From the File menu, select Software Upgrade. The Update Device Software window appears.
6.Parameters are as follows:
— Password — Software version — File — Enable New Version Checkbox
7.If you are upgrading or downgrading to a different major version, enter your case-sensitive password in the Password field. For instructions on obtaining a password, see step 3 above.
8.In the Software version field, enter the software version that you wrote down in step 1. Note: the software version also appears in the name of the software update file; for example, appdirector-ods1-2_00_01.tar is the file for version 2.00.01.
9.In the File field, click Browse and navigate to the software update file that you downloaded and unzipped. You are looking for a file named: appdirector_[platform]_[major version]_[minor version]_[bugfix version].tar.
10.Check Enable New Version to apply the upgrade.
11.Click Set. You are prompted to reset the device.
12.In the Device menu, select Reset Device. The Reset the Device window appears.
AppDirector User Guide
Administering and Monitoring AppDirector
56 Document ID: RDWR-AD-V0231-UG1105
13.Click Set to reset AppDirector.
Backup Version Update
To manually update the backup application version or install it, use the CLI command: system file-system files copy-to-flash x, where x is the index of the new application you want to use (existing applications and their indexes are displayed by: system file-system config act-appl command).
Configuration File Management
The configuration file format is based on the CLI (system config format) and is the default format for all operations. Radware recommends saving existing configurations on each Radware device. If a change to the configuration results in problems, administrators can restore a previous configuration. Files are stored locally on the desktop or laptop. Caution:Configuration changes cannot be performed until any pending reboot has completed.
The configuration file can be received from the device in the following ways:
1.Displayed within the CLI (Console, Telnet, SSH) by entering:
system config immediate 2.Copying the output to a text editor.
3.Downloaded from the device using WBM or the terminal command:
system config download [File] [Server IP].
The configuration file output in the CLI or within the configuration file itself (downloaded from the device) is divided into two sections:
Note:Commands which require rebooting the device, including BWM Application Classification Mode, Application Security status etc. Copying and pasting a command from this section takes effect only after the device is rebooted. Commands not requiring a device reboot
Copying and pasting a command takes effect immediately after the paste. Commands are printed within each section, in the order of implementation; for example, server related commands are printed after the farm related commands. At the end of the file, the device prints the signature of the configuration file. This is used to verify the authenticity of the file and that it has not been corrupted. The signature is validated each time the configuration file is uploaded to the device, and if the validity check fails, then the device accepts the configuration, but a notification is sent to the user that the configuration file has been tampered with and there is no guarantee that it works. Note:The signature is validated only when sending a complete configuration to the device in Replace mode.
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 57
Device Configuration Update
The configuration can be updated in one of the following methods:
1.Append - You can add parts of a configuration into a device. For example, you can add a specific farm and its servers into an AppDirector's configuration. It also allows simple multi device management, pushing the same BWM Policy to multiple devices at once. It is configured:
a.By pasting the configuration into the terminal using the command
system config paste start
Once all the data is pasted, the following command must be issued
system config paste stop
b.By uploading the file using WBM and selecting the option - Append Commands to Configuration File in the Upload Configuration File to Device window.
c.By performing the terminal command
system config upload append
Using the Append method you can only append commands which do not require rebooting the device for the commands to take effect. If a command which requires reboot is pasted/
uploaded to the device using the Append method, then the command is not implemented.
To log the command outputs in the terminal, enter
system config upload append
with option -v. The output to the terminal displays each command and its result.
2.Append and Reboot - You can add parts of a configuration into a device. The difference between this option and the Append option is that it also supports commands that require rebooting the device for the commands to take effect. The flow of commands using the Append and Reboot option is as follows:
— All commands requiring the reboot of the device are implemented first.
— The device is rebooted.
— All commands not requiring reboot of the device are implemented.
The Append and Reboot method is supported using the following options:
a.By performing the terminal command:
system config upload append-reboot
b.By uploading the file using WBM and selecting the option - Append Commands to Configuration File with Reboot in the Upload Configuration File to Device window.
To log the command outputs in the terminal, enter
system config upload append-reboot
with option -v. The output to the terminal displays each command and its result.
3.Replace - You can replace the complete configuration file with a new configuration file. This requires rebooting the device. You can upload the configuration file to the device as follows:
a.By pasting the configuration into the terminal using the command: system config paste-replace
Once all the data is pasted CTRL+C must be performed.
b.By performing the terminal command
system config upload replace
c.By uploading the file using WBM and selecting the option - Replace Configuration File in the Upload Configuration File to Device window. When using this option, you can upload a configuration file to the device in CLI format.
Note:
system config upload replace does not support configuration from previous versions. AppDirector User Guide
Administering and Monitoring AppDirector
58 Document ID: RDWR-AD-V0231-UG1105
Automatic Rollback to Last Known Good Configuration
The device also supports an automatic rollback to the last good known configuration (in case of a fatal error after a configuration upload). The rollback is performed automatically if a problem occurs during the reboot and initialization process performed after a configuration file is sent to the device in Replace mode. Once the rollback occurs, the device reboots (again) and loads the configuration which existed prior to the 1st reboot.
Configuration Management Log File
The Configuration Management log file logs every error printout which occurs when uploading text files. The log file is accessed via the following management options:
1.WBM - The log file is managed via the following menus:
— The user can clear the file via the following menu:
File > Configuration > Log File > Clear.
— The user can download the file via the following menu:
File > Configuration > Log File > Download.
— The user can display the file via the following menu:
File > Configuration > Log File > Show.
2.CLI - The following command is used to view the Configuration Management logfile:
—
system config logfile <get/reset>.
Note:
>> If there is no room on the device's compact flash to store the file, the device does not log any information within the log file.
>> Each event is also sent via Email, Syslog, SNMP traps and console trap.
Uploading a Configuration File
To upload a configuration file to the device 1.From the File menu, select Configuration File > Send To Device. The Upload Configuration File to Device window appears. 2.Select the Upload mode from one of the following:
Parameter
Description
Replace Configuration File
Existing configuration file is replaced by the uploaded one, and the device is rebooted.
Append Commands 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.
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 59
3.Enter the name of the file you want to send. Alternatively, click Browse to search the directory tree for the file. 4.Click Set. The file is uploaded to the device.
Downloading a Configuration File (Saving and Restoring)
This section discusses the saving and restoring of Configuration Files by downloading. To download the configuration file from the device 1.From the File menu, select Configuration > Receive from Device. The Download Configuration File window appears. Note:When Configuration Synchronization
is enabled this parameter value is not synchronized to a peer device.
2.Set the parameters.
3.In the Configuration Type field, select one of the following:
4.Mark the checkbox if you want to include Private Keys.
5.Click Set. The file is downloaded to the device
Parameter
Description
Regular
Download the device configuration
Peer (Active-
Active)
Download configuration created for peer device synchronization in an Active-Active environment. This configuration must be uploaded to the peer device. To enable this device to create such a configuration you need to provide the IP for the same interface in the peer device for each IP Interface that you configured on this device, .
Note: Configuration file for Active-Active synchronization is supported for proprietary redundancy only.
Backup (Active-
Backup)
Download configuration created for backup device synchronization in an Active-Backup environment. This configuration must be then uploaded to the backup device. To enable this device to create such a configuration you need to provide the IP for the same interface in the peer device for each IP Interface that you configured on this device.
Exclude SNMPv3 Users
When using Peer device synchronization with AppDirector for APSolute Vision, this parameter is required.
Also see C
onfiguration Synchronization
, page 165
and specifically SNMPv3 Users Synchronization with Radware’s APSolute Vision
, page 169
for more information.
AppDirector User Guide
Administering and Monitoring AppDirector
60 Document ID: RDWR-AD-V0231-UG1105
Log Files
A server log is a log file (or several files) automatically created and maintained by a server of activity performed by it.
A typical example is a web server log which maintains a history of page requests. More recent entries are appended to the end of the file. Information about the request, including client IP address, request date/time, page requested, HTTP code, bytes served, user agent, and referer are added. These data can be combined into a single file, or separated into distinct logs, such as an access log, error log, or referer log. However, server logs do not collect user-specific information. These files are usually not accessible to general Internet users, only to the webmaster or other administrative person. Show Log File
The Configuration Error Log window allows you to view the configuration errors. The report of configuration errors presented in this log file is automatically generated by the device. To view the Log File
From the File menu, select Configuration > LogFile > Show. The Configuration Error Log window appears displaying the configuration errors.
Logfile Clear
The Clear Error Log window allows you to clear data contained in the configuration log file.
To clear the Error Log
1.From the File menu, select Logfile > Clear. The Clear Error Log window appears.
2.Click Set. The log file is cleared.
Logfile Download
The Download Error Log window allows you to download the log file that contains configuration errors. Once the file is downloaded, you can view it. To download the Error Log
1.From the File menu, select Logfile > Download. The Download Error Log window appears.
2.To download the latest error log file, click Set. The file is downloaded and now you can view it.
Licensing and Upgrading Licenses
You can upgrade the software capabilities of AppDirector via the licensing procedure; for example, adding BWM and IPS support, (when Acceleration Application is disabled).
To change licenses, you need to insert a new license code. The license provided to you, is a one-time license. Once this is changed, the old license code cannot be re-used. For example, if a license that includes BWM and IPS activation keys was given to you on a trial basis but not purchased, Radware will provide you with another license, but without these activation keys. The old license cannot be reused.
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 61
Each license is based on the device’s MAC address and on a license ID that is changed every time a new license is inserted. To obtain a license upgrade, you need to send the MAC address and the current license ID of the device. To perform a license downgrade, you have to send the MAC address and the current license ID of the device. Once you receive and insert the new license, a screen capture of the License Upgrade window or the output of system license get
CLI command must be sent to Radware to prove that you are using the new license. Radware ensures that the old license cannot be reused. The following procedures enable you to upgrade your software and throughput licenses using the Command Line Interface (CLI). Note:For users of Radware’s APSolute Insite, you can also upgrade your AppDirector device license. For further details, see the APSolute Insite User Guide.
Upgrading Licenses Using WBM You can upgrade the software capabilities of AppDirector Director via the licensing procedure and increasing product capacity (throughput). For more information about obtaining licenses, please contact Radware Technical Support. To change licenses, you need to insert a new license code. The license provided to you, is a one-time license. Once this is changed, the old license code cannot be re-used. Each license is based on the device’s MAC address and on a license ID that is changed every time a new license is inserted. To obtain a license upgrade, you need to send the MAC address and the current license ID of the device. To perform a license downgrade, you have to send the MAC address and the current license ID of the device. Once you receive and insert the new license, a screen capture of the License Upgrade window or the output of system license get CLI command must be sent to Radware to prove that you are using the new license. Radware then ensures that the old license cannot be reused.
The following procedure enables you to upgrade your license using WBM.
To upgrade a license 1.From the Device menu, select License Upgrade. The License Upgrade window appears.
2.Set the configurable parameters.
Parameter
Description
Base MAC Address
MAC address of the first port on the device.
License ID Reports the device software license ID and must be provided to the Radware ordering department when a new license is required.
Insert your License Code The device software license allows you to activate advanced software functionality.
Throughput License ID Manages the device throughput license ID and must be provided to the Radware ordering department when a new throughput license is required.
Insert your Throughput License Code Manages the device throughput level license.
AppDirector User Guide
Administering and Monitoring AppDirector
62 Document ID: RDWR-AD-V0231-UG1105
3.Enter your new license code, located on your CD case (or downloaded from www.radware.com), in the License Code field.
Note:The license code is case sensitive.
4.Enter your new License ID in the License ID field.
Note:The license ID is case sensitive.
SSL CPS License ID Sets/displays AppDirector's SSL CPS license. The SSL Connections per Second license for the device are:
• appdirector-ssl-500
• appdirector-ssl-2000
• appdirector-ssl-5000
• appdirector-ssl-10000
• appdirector-ssl-20000
• appdirector-ssl-30000
• appdirector-ssl-40000
• appdirector-ssl-50000
• appdirector-ssl-unlimited
Insert your SSL CPS License Code
Manages the device SSL CPS license ID and must be provided to Radware ordering department when a new throughput license is required.
Compression on server's side License ID Sets/displays AppDirector's Compression on server's side license. The compression on the server's side license for the device are:
• appdirector-compression-100
• appdirector-compression-250
• appdirector-compression-500
• appdirector-compression-750
• appdirector-compression-1000
• appdirector-compression-1250
• appdirector-compression-1500
• appdirector-compression-unlimited
Insert your Compression on server's side License Code Manages the device compression on the server's side license ID and must be provided to the Radware ordering department when a new throughput license is required.
Parameter
Description
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 63
5.Click Set to perform the reset. The reset may take a few minutes. A success message is displayed on completion.
Note:If your AppDirector is running in Enhanced Acceleration mode and you want to set a security license (IPS), you need to:
>> switch AppDirector to run in Standard Acceleration mode, (see Enabling and Disabling Application Acceleration, page 236
).
>> reboot your device.
>> now set the license.
AppDirector User Guide
Administering and Monitoring AppDirector
64 Document ID: RDWR-AD-V0231-UG1105
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. The license has been updated. A message is displayed in the command line. 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. 6.Click Set. Your preferences are recorded.
Resetting Devices
You may have made various changes to configurations and settings and need to reset the device for these changes to take effect. You can reboot the device at any given time.
To reset an AppDirector device 1.In the Device window, select Reset Device.
2.The device is reset.
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 65
Device Shutdown
If you need to shutdown the server device (assuming administrator privileges), use this procedure.
To shutdown the device
1.Click Shutdown. The following user dialog message appears.
2.Click OK to confirm, the device begins shutdown.
Tuning AppDirector
This section describes interfaces and methods for tuning AppDirector. Use Tuning to determine the maximum number of entries allowed in the various tables listed. This section includes these topics:
• Device Tuning
, page 66
• Device Global Parameters
, page 69
• Main Device Tuning Parameters
, page 70
• C
lient Table Settings Tuning
, page 73
• DNS Settings Tuning
, page 73
• NAT Settings Tuning
, page 73
• S
ession Table Tuning
, page 75
• T
uning Memory Check
, page 76
• Tuning Statistics
, page 76
• Bandwidth Management Tuning (O
n Demand Switch D
evices Only
)
, page 77
• Classifier Tuning
, page 77
• SYN Protection Tuning
, page 79
• Application Security Tuning
, page 80
• Behavioral DoS Tuning Parameter
s
, page 82
AppDirector User Guide
Administering and Monitoring AppDirector
66 Document ID: RDWR-AD-V0231-UG1105
Device Tuning
The Device Tuning window allows you to tune the AppDirector device. The values in the fields are synchronized and any changes are implemented after the device reset.
To tune the AppDirector device tables 1.From the Services menu, select Tuning > Device. The Device Tuning window appears.
2.Set the parameters.
Note:Only the (After Reset) parameters can be edited, the rest are read-only.
Caution:Before activating any reset value, test to ensure that there is enough memory on the device to support it. The new value will not take effect until the device is reset.
Parameter
Description
Bridge Forwarding Table
Maximum number of entries currently available in the Bridge Forwarding Table (bridging ports per destination MAC address).
Bridge Forwarding Table (After Reset)
After reset, the limit on number of local station addresses.
Set the size of the Bridge Fast Forwarding Table. IP Forwarding Table
Maximum number of entries currently available in the IP Fast Forwarding Table.
IP Forwarding Table (After Reset) After reset, Sets the size of the IP Fast Forwarding Table.
Client Table
Maximum number of entries currently available in Client Table
Client Table (After Reset) After reset, sets the size of the Client Table.
Routing Table
Maximum number of entries allowed in the Routing Table.
Routing Table (After Reset) Limit on the number of entries in the Routing Table after reset.
Hosts Table
Maximum number of entries allowed in the Host Names Table.
Hosts Table (After Reset) Maximum number of entries allowed in the Host Names Table after reset.
Request Table
Maximum number of entries currently available in the Requests Table as used by all delayed binding based mechanisms, for example, SSL ID tracking, Layer 4 Policies etc.
Request Table (After Reset)
Maximum number of entries currently available in the Requests Table as used by all delayed binding based mechanisms, for example, SSL ID tracking, Layer 4 Policies etc., after reset.
Client NAT Addresses Maximum number of entries (IP addresses) currently available in the Client NAT Addresses Table. Default: 0, Maximum: 128
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 67
Client NAT Addresses (After Reset)
Maximum number of entries (IP addresses) currently available in the Client NAT Addresses Table after reset. Default: 0, Maximum: 128
Client NAT Ports Per Address
Maximum number of ports currently available per Client NAT Address, (maximum value is 63K).
Note: Before enabling Client NAT this must be set to value > 0. Client NAT Ports Per Address (After Reset)
Maximum number of ports currently available per Client NAT Address, after reset; (maximum value is 63K).
Note: Before enabling Client NAT this must be set to value > 0. Outbound NAT Addresses
Maximum number of entries currently available in the Outbound NAT Addresses Table
Outbound NAT Addresses (After Reset)
Maximum number of entries currently available in the Outbound NAT Addresses Table, after reset.
Outbound NAT Ports Per Address
Maximum number of ports currently available per Outbound NAT address.
Outbound NAT Ports Per Address (After Reset):
Maximum number of ports currently available per Outbound NAT address, after reset.
Outbound NAT Intercept Ranges
Maximum number of entries currently available in the Outbound NAT Intercept Table.
Outbound NAT Intercept Ranges (After Reset)
Maximum number of entries currently available in the Outbound NAT Intercept Table, after reset.
Proximity Subnets
Maximum number of entries currently available in the Dynamic Proximity Table.
Proximity Subnets (After Reset) Maximum number of entries available in the Dynamic Proximity Table, after reset.
Session IDs Maximum number of entries currently available in the Session ID Table. Default table size:16,384 Maximum: 256,000
Session IDs (After Reset) Maximum number of entries available in the Session ID Table after reset.
Default table size:16,384 Maximum: 256,000
Layer3 Client Table Size of Layer 3 Client Table can be configured and defined as percent of the Client Table size. Default: 20%
Layer3 Client Table After Reset [% of the client table] Size of Layer 3 Client Table after reset can be configured and defined as a percent of the Client Table size.
Default: 20%
Network Segments
Maximum number of network segments that can be currently configured (network segments supported when the device uses the segmentation feature).
Network Segments After Reset Maximum number of network segments that can be currently configured (network segments supported when the device uses the segmentation feature), after reset.
Layer 4 Policies Maximum number of Layer 4 policies that can be defined on the device.
Parameter
Description
AppDirector User Guide
Administering and Monitoring AppDirector
68 Document ID: RDWR-AD-V0231-UG1105
3.Click Set. Your configuration is set.
You can determine the maximum number of entries allowed in the various tables in the following Device Tuning Table tabs:
• AppDirector • BWM
• Security Settings Note:Most of the parameters in the BWM and Security Settings tabs described above only exist in devices with BWM and IPS activated.
You can also define the security parameters for your previously defined security policy. The values in the fields are synchronized, and any changes are implemented after the device is reset. Caution:Device Tuning should only be performed after consulting Radware Technical Support.
Layer 4 Policies After Reset Maximum number of Layer 4 policies that can be defined on the device after reset.
Static DNS Persistency Entries Maximum number of entries currently available in the Static DNS Persistency Table.
Static DNS Persistency Entries After Reset Maximum number of entries currently available in the Static DNS Persistency Table after reset.
Dynamic DNS Persistency Entries Maximum number of entries currently available in the Dynamic DNS Persistency Table.
Dynamic DNS Persistency Entries After Reset Maximum number of entries currently available in the Dynamic DNS Persistency Table, after reset.
Session Table Displays the number of entries that the session table can hold.
Session Table After Reset Displays the number of entries that the session table can hold after a reset.
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. Session Resets Table After Reset New amount of sessions that device tracks to send RESET in case "Send Rest To Server" is enabled in the Session Table after reset.
Acceleration Engine RAM Percentage For Cache Percentage of Accel-engine RAM allocated for cache. Also see Caching Policies, page 238
.
Default: 20
Acceleration Engine RAM Percentage For Cache After Change Percentage of Accel-engine RAM allocated for cache after change.
Also see Caching Policies, page 238
.
Parameter
Description
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 69
Device Global Parameters
This feature defines the Hardware version of the product.
To view Device Global Parameters 1.In the Device menu, select Device Global Parameters. The Device Global Parameters window appears. 2.Set the parameters.
3.Click Set. Your configuration is set.
Parameter
Description
Description (Read Only)
A textual description of the entity. This value includes the full name and version identification of the system's hardware type, software operating-system, and networking software.
Name An administratively-assigned name for this managed AppDirector device/node. By convention, this is the node's fully-qualified domain name. If the name is unknown, the value is the zero-length string. Setting this value is optional.
Peer Device Name
Location The physical location of this AppDirector device/node (for example, telephone closet, 3rd floor'). Setting this value is optional.
System Up Time (Read Only)
Reports the time elapsed since the device last reboot.
Contact The contact information of the person responsible for AppDirector. Setting this value is optional.
Bootp Server Address Sets the IP address of the BootP server. The device forwards BootP requests to the BootP server and acts as a Bootp relay.
Bootp Threshold Sets the BootP threshold. (The number of seconds that the device will wait before relaying requests to the BootP server). This delay allows local BootP Servers to answer first.
Serial Number (Read Only)
Sets or returns the device serial number.
Software Version (Read Only)
Reports the device's software version, for example, 2.10.00
Hardware Version (Read Only)
Reports the device’s hardware version, for example, 3.1.
AppDirector User Guide
Administering and Monitoring AppDirector
70 Document ID: RDWR-AD-V0231-UG1105
Main Device Tuning Parameters
Main device tuning parameters are described here:
Parameter
Description
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 relationship between host names and Layer 4 Policy entry. Request Table Contains Layer 7 information saved during delayed binding.
Client NAT Addresses Specifies NAT Addresses used to hide IP addresses of clients accessing this farm. For each farm you can select a single NAT Addresses range. Note: When no Client NAT Address Range is selected for a farm, AppDirector uses any configured Client NAT Address Ranges when performing Client NAT for servers in this farm.
Client NAT Ports Per Address
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.
Layer 4 Policies Maximum number of Layer 4 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.
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 71
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:
• maximum number of application server connections.
• Weight of the server in a farm
• the Response Threshold parameter defines the number of milliseconds in which the server may reply to the GET command.
• maximum amount of bandwidth in Kbps allowed for this application server.
Physical Servers You can configure the physical servers you have included in your server farm including:
• maximum number of application server connections. • maximum number of frames per second dispatched to the server since the last reset
• number of currently active users attached to server
• number of frames per second dispatched to server
• number of frames sent to server
Servers per Farm Average of servers per farm.
Farms Default number of farms configurable on one device.
NHRs A Next Hop Router (NHR) is a network element used for outbound traffic in AppDirector Multi Homing configurations. NAT addresses can be associated with NHRs, similar to the way VIPs are associated with NHRs. This provides a backup NHR for NAT Addresses, or for the simultaneous use of two NHRs with Hashing for the outbound traffic.
VIP -> NHR The VIP NHR Table enables you to associate a next hop router, that is configured in the NHR Table, to a virtual IP address configured on the device, for example a Server Farm.
Static Proximity Entries
Number of proximity subnets are configurable per farm. Static Proximity is configurable through the farm parameters. Parameter
Description
AppDirector User Guide
Administering and Monitoring AppDirector
72 Document ID: RDWR-AD-V0231-UG1105
Bandwidth Management Settings Tuning
You can tune the Bandwidth Management Settings tables according to your needs. The following table shows descriptions of the Bandwidth Management tables and provides their tuning parameters
Parameter
Description
Policy Table Maximum number of bandwidth management policy entries in the table. A policy classifies traffic passing through the device, and enforces bandwidth management, and enables access control.
Network Table Maximum number of network ranges entered in the table. A network is a logical entity that consists of a group of IP addresses linked together by a network IP and subnet mask or a range of IP addresses (from-to) that is identified by a unique name.
Destination Table Maximum number of Destination Address entries in the table. A Destination Address can be a specific IP address, a range of IP addresses, or an IP Subnet address. Each address in the table contains an optimized list of policies. This improves classification time for the specific Destination addresses. The number of entries implies the number of concurrent Destinations which the device supports.
Regular Service Table Maximum number of regular (basic) service entries in the table. A regular service is a set of traffic parameters that define a packet.
Advanced Service Table Maximum number of advanced service entries in the table. An advanced class is a group of regular classes with a logical AND relation between them.
Grouped Service Table Maximum number of service group entries in table. A grouped service is a group of regular services and/or grouped filters with logical OR relation between them.
Content Table The device uses content searches in the Layer 7 policies that can be defined for BWM. Discreet IP Address Per Network
Maximum number of individual IP addresses in a single dynamic network. Relevant for CID only.
Subnets Per Network Maximum number of subnets sharing the same network name in a single network entry.
MAC Groups Maximum number of MAC group entries in the table. A MAC group classifies applications and protocols present in the traffic, and sent to or from a transparent network device like a firewall or router.
BW Per Traffic Flow Maximum number of traffic flows for a single policy. Used only for bandwidth management per traffic flow. Protocol Discovery Reports
Maximum number of ports to be monitored by the Protocol Discovery module. Application Port Group Group of Layer 4 ports for UDP and TCP traffic only. Each group is identified by its unique name. Each group name can be associated with a number of entries in the Application Port Groups table. AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 73
Client Table Settings Tuning
You can tune the Client Table Settings according to your needs. This table shows descriptions of the Client Tables and their tuning parameters.
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. This table shows descriptions of the NAT Settings Tables and provides their tuning parameters. Parameter
Description
Client Table Keeps track of which clients are connected to which servers for each of the Local Farms.
Layer 3 Client Table Contains information about the server selected for each client (Source IP address) in each farm, defined as a percent of the Client Table size. While setting Layer 3 Client Table entries, note the number of entries in the Client Table opened for each new session. For example, if for each session there are 5 Client Table entries, set the size of the table to 20%.
Parameter
Description
Static DNS Table Maximum number of DNS entries used in static DNS Persistency. See Static DNS Persistency
, page 339
.
Dynamic DNS Table Maximum number of DNS entries used in dynamic DNS Persistency. See
DNS Persistency
, page 337
.
Parameter
Description
NAT Ports Table Specifies number of ports used with each IP address. AppDirector uses port range starting at 1024 that ends according to NAT Ports per Address value.
NAT Addresses Table Specifies number of IP addresses used for NAT.
Outbound NAT Addresses
Note: Defines number of IP addresses to be used by Outbound NAT. Before enabling Outbound NAT, this must be set to > 0.
Outbound NAT Ports per 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 must be set to > 0.
AppDirector User Guide
Administering and Monitoring AppDirector
74 Document ID: RDWR-AD-V0231-UG1105
Security Tuning
Security tables store information about sessions passing through the device and their sizes, which are correlated to the number of sessions. Some of the tables store Layer 3 information for every Source-Destination address pair of traffic going through the device. These pairs require an entry for each combination. Some of the tables need to keep information about Layer-4 sessions, which means that every combination of Source Address, Source Port, Destination Address and Destination Port requires its own entry in the table.
Note:Layer-4 tables are usually larger than Layer-3 tables. For example, a typical TCP client, using HTTP, opens several TCP sessions to the same destination address.
Each Security table has its own Free-Up process, which is responsible for clearing the tables of old entries that are no longer required, and ensuring that all detected attacks are reported and logged properly. The Free-Up Frequency for each table determines how often the device clears unnecessary entries from the table and stores information about newly detected security events in a dedicated internal alerts buffer. The alerts are then distributed to the logfile, SNMP management station, and Syslog server, as required by the configuration. The alerts buffer ensures that the device is not overloaded with alerts distribution. AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 75
Security Tables
This table shows Security tables parameters.
Session Table Tuning
This shows Session Table tuning parameters.
Parameter
Description
Log File Polling Time (ms)
Configures how often alerts are read from the internal alerts buffer and sent to the Log File. If the device is busy, change this value to 1,000 ms. to ensure that all alerts are logged on time.
Target Table Contains an attack detection system that is based on the Destination addresses of the incoming traffic. If number of packets sent to same destination is above the predefined limit, it is identified as an attack. The Target Table tuning parameters define how often per session to check the Destination Address.
Source Table Contains attack detection system based on source addresses of the incoming traffic. If the number of packets sent from the same source is above the predefined limit, it is identified as an attack. The Source Table parameters define how often per session to check the source address.
Source & Target Table Contains an attack detection system that is based on the Source and Destination addresses of the incoming traffic. Each entry in this table contains Source and Destination addresses. If the number of packets sent from the same Source to the same Destination is above the predefined limit, it is identified as an attack. The Source & Target Table tuning parameters define how often per session to check the source address.
Security Tracking Tables Free-Up Frequency (ms)
Determines how often device clears unnecessary entries from the table, and stores information about newly detected security events.
DHCP Discover Contains an attack detection system based on counting the IP requests for each MAC address. Requests are made using the Dynamic Host Configuration Protocol. When the number of IP requests for a particular MAC address is above the predefined limit, it is identified as an attack. The DHCP Discover tuning parameters determines how many MAC addresses to check.
IP Reassembly buffers pool size (MB)
Defines memory size allocated for the IP reassembly process. To perform reassembly for more packets, you need to increase the memory size.
Parameter
Description
Session Table Size Keeps track of sessions.
Session Passive Protocol Records passive protocol port commands, so that all related sessions can be linked together.
AppDirector User Guide
Administering and Monitoring AppDirector
76 Document ID: RDWR-AD-V0231-UG1105
Tuning Memory Check AppDirector pre-checks the feasibility of values in the configured tables. This eliminates the chance of causing a memory allocation problem. Each time you update a value for a certain table, you can check whether there is enough free memory for the requested value. However, following tuning changes, you can then perform a manual check using WBM or CLI. Caution:Perform tuning only after consulting Radware Technical Support.
Note:In CLI, use the command: system tune test-after-reset-values.
To perform the device tuning memory check
1.Perform Device Tuning.
2.From the Services menu, select Tuning > Memory Check. The Tuning Memory Check window appears, which lists all the changes that have been made in Device Tuning windows.
3.Click Perform Test. The memory check is performed to verify whether the device contains sufficient memory to allocate the changes. The following messages may be displayed:
a.Sufficient memory available for the pending table size updates. Reboot to update the table sizes: Click Reboot to reboot the device and apply the changes.
b.# Kbytes are missing for the pending table size updates. Reduce the size of the tables using dispensable memory to accommodate the required updates: Click tables to access the Device Tuning windows and adjust the tables according to the amount of memory required.
Tuning Statistics
In the Tuning Statistics window you can view and edit the statistics tuning parameters. The changes take effect after the reset.
Caution:Perform tuning only after consulting Radware Technical Support.
To tune the Statistics 1.From the Services menu select Tuning > Statistics. The Statistics Tuning window appears.
2.Set the parameters.
Parameter
Description
Protocol Discovery Policies
Current size of the table for Protocol Discovery Policies entries. Read-only parameter.
Protocol Discovery Policies After Reset
Size of table for Protocol Discovery Policies entries that you define. Settings are applied after reset.
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 77
3.Click Set. Your configuration is set.
Bandwidth Management Tuning (On Demand Switch Devices Only)
The BWM Tuning window allows you to tune and view the Bandwidth Management tables.
Caution:Perform tuning only after consulting Radware Technical Support.
To tune Bandwidth Management tables
1.From the Services menu, select Tuning > BWM. The BWM Tuning window appears.
2.Set the parameters.
3.Click Set. Your preferences are recorded.
Classifier Tuning
A Classifier packet first flows into the system through the classifier. It’s the classifier’s duty to decide what to do with the packet. How the classifier treats packets passing through is governed by the Bandwidth Management policy that best matches the packet and by these tuning parameters.
From the Classifier Tuning window you can view and edit the Classifier tuning parameters. The changes take effect after the reset.
Protocol Discovery Report Entries
Total number of discovered protocols that can be recorded by the device. (Read-only).
Protocol Discovery Report Entries After Reset
Total number of the discovered protocols that can be recorded by the device after reset.
Parameter
Description
Policy Table Displays number of policy entries in the table. Policy Table (After Reset)
Displays number of policy entries in the table after reset.
BW per Traffic Flow sessions tracking
Number of traffic flows for which the device can provide bandwidth or limit the number of sessions.
Maximum value: 100,000
BW per Traffic Flow sessions tracking (After Reset)
Number of traffic flows for which the device can provide bandwidth or limit the number of sessions after reset.
Destination Table Displays number of entries in the Destination table after reset.
Destination Table (After Reset) Displays number of entries in the Destination table.
Parameter
Description
AppDirector User Guide
Administering and Monitoring AppDirector
78 Document ID: RDWR-AD-V0231-UG1105
To tune AppDirector Classifier tables 1.From the Services menu, select Tuning > Classifiers. The Classifiers Tuning window appears.
2.Set the parameters. 3.Click Set. Your configuration is set.
Parameter
Description
Network Table Displays number of ranges entered in the table. Network Table After Reset Displays number of ranges entered in the table after reset.
Discrete IP Addresses Per Network
Displays number of entries in the table for IP addresses that are allocated to a network.
Discrete IP Addresses Per Network After Reset
Displays number of entries in the table for IP addresses allocated to a network after reset.
Subnets Per Network Displays number entries in the table for network subnets.
Subnets Per Network After Reset Displays number entries in table for network subnets after reset.
MAC groups Table Displays number of MAC groups entries in the table. MAC groups Table After Reset Displays number of MAC groups entries in the table after reset. Filter Table Displays number of basic filter entries in table. Filter Table After Reset Displays number of basic filter entries in the table after reset. AND Group Table Displays number of entries in the advanced filter table.
AND Group Table After Reset
Displays number of entries in the advanced filter table after reset.
OR Group Table Displays number of entries in the group filter table.
OR Group Table After Reset
Displays number of entries in the group filter table.
Application port groups Displays number of application port group entries in the table. Application port groups After Reset Displays number of application port group entries in the table after reset.
Content Table Displays number of content entries in the table. Content Table After Reset Displays number of content entries in the table after reset.
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 79
SYN Protection Tuning
From the SYN Protection Tuning window you can view and edit the SYN protection tuning parameters. The changes take effect after the reset.
Caution:Perform tuning only after consulting Radware Technical Support.
To tune Global Security tables
1.From the Services menu, select Tuning > SYN Protection. The Syn Flood Protection Tuning window appears.
2.Set the parameters.
3.Click Set. Your configuration is set.
Parameter
Description
SYN Protection Table Current number of entries in SYN Protection Table.
SYN Protection Table after Reset
Current number of entries in SYN Protection Table after Reset.
SYN Protection Requests Table
Number of entries in SYN Protection Requests Table.
SYN Protection Requests Table After Reset Number of entries in SYN Protection Table after reset. SYN Protection Triggers Table Number of entries in SYN Protection Triggers Table.
SYN Protection Triggers Table After Reset
Number of entries in SYN Protection Triggers Table after reset.
SYN Protection Policies Table Number of entries in the SYN Protection Policies Table.
SYN Protection Policies Table After Reset Number of entries in SYN Protection Policies Table after reset.
ACK reflection IPs Table Number of entries in ACK reflection IPs Table.
ACK reflection IPs Table After Reset Number of entries in ACK reflection IPs Table after reset.
SYN Protection Attack Detection Entries Number of entries in SYN Protection Attack Detection Entries.
SYN Protection Attack Detection Entries After Reset
Number of entries in SYN Protection Attack Detection Entries after reset.
SYN Statistics Entries Number of entries in SYN Statistics Entries. SYN Statistics Entries After Reset
Number of entries in SYN Statistics Entries after reset.
AppDirector User Guide
Administering and Monitoring AppDirector
80 Document ID: RDWR-AD-V0231-UG1105
Application Security Tuning
From the Application Security Tuning Parameters window you can view and edit the application security tuning parameters. The changes take effect after device reset.
Caution:Perform tuning only after consulting Radware Technical Support.
To tune AppDirector Application Security tables
1.From the Services menu, select Tuning > Security > Application Security. The Application Security Tuning window appears.
2.Set the parameters.
Parameter
Description
Source Table The current number of entries in the Source Table that contains attacks detection mechanism, which is based on the source addresses of the incoming traffic. If the number of packets sent from the same source is above the predefined limit, this is identified as an attack. The Source Table tuning parameter defines in how many sessions to check the source address.
Source Table After Reset The number of entries in the Source Table after reset.
Target Table Represents the current size of the table for destination entries. This table contains attacks detection mechanism, which is based on the destination addresses of the incoming traffic. If the number of packets sent to the same destination is above the predefined limit, this is identified as an attack. The Target Table tuning parameter defines in how many sessions to check the destination address.
Target Table After Reset
The size of the table for destination entries that you define. The settings are applied after reset.
Source & Target Table
Represents the current size of the table for both source and destination entries, which are counted as one. Source & Target Table After Reset The size of the table for both source and destination entries that you define. The settings are applied after reset.
DHCP Table The current number of entries in the DHCP Table that contains attacks detection mechanism based on counting of IP requests for each MAC address. The requests are made using the Dynamic Host Configuration Protocol. When the number of IP requests for a particular MAC address is above the predefined limit, an attack is identified. The DHCP Discover tuning parameter determines for how many MAC addresses to check the number of IP requests.
DHCP Table After Reset
The number of entries in the DHCP Table after reset.
Maximal number of groups to be defined by user
Maximum number of user defined groups that can be defined on the device.
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 81
3.Click Set. Your preferences are recorded.
Maximal number of groups to be defined by user after reset
Maximum number of user defined groups that can be defined on the device after reset.
Maximal number of attacks to be defined by user
Maximum number of user defined attacks that can be defined on the device.
Maximal number of attacks to be defined by user after reset
Maximum number of user defined attacks that can be defined on the device after reset.
IP Reassembly buffers pool size [MB] The current allotted memory, in MB, of the IP Reassembly buffers pool.
IP Reassembly buffers pool size after reset [MB] The allotted memory, in MB, of the IP Reassembly buffers pool after reset.
Maximal number of entries in NCPF table
Maximum number of entries that can be defined in the NPCF table.
Maximal number of entries in NCPF table after reset
Maximum number of entries that can be defined in the NPCF table after reset.
Maximal number of srcIPs in Suspend Table
Maximum number of entries that can be defined in the Suspend table.
Maximal number of srcIPs in Suspend Table after reset
Maximum number of entries that can be defined in the Suspend table after reset.
Maximal number of Anti-Scanning IP pairs Table
Maximum number of entries that can be defined in the Anti-Scanning IP pairs table.
Maximal number of Anti-Scanning IP pairs Table after reset
Maximum number of entries that can be defined in the Anti-Scanning IP pairs table after reset.
Parameter
Description
AppDirector User Guide
Administering and Monitoring AppDirector
82 Document ID: RDWR-AD-V0231-UG1105
Behavioral DoS Tuning Parameters
Behavioral DoS Tuning Parameters enable you to set the maximal number of Behavioral DoS policies. The default number of policies for Behavioral DoS is 10. If you wish to configure more, you must reset the number of policies allowed.
Note:When you update a value for a Behavioral DoS, you can check whether there is enough free memory for the requested value.
To set maximum number of Behavioral DoS policies
1.From the Services menu, select Tuning > Security > Behavioral DoS. The Behavioral DoS Tuning Parameters window appears.
2.Set the parameters.
3.Click Set. Your preferences are recorded.
Parameter
Description
Maximal number of Behavioral DoS policies
Maximum number of Behavioral DoS policies that can be defined on the device.
Maximal number of Behavioral DoS policies after reset
Maximum number of Behavioral DoS policies that can be defined on the device after reset.
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 83
Monitoring AppDirector
This section includes notifications features and threshold settings. It includes these topics:
• AppDirector Dashboard
, page 83
• D
evice Information
, page 85
• Device Monitoring
, page 87
• N
otifications
, page 87
• Configuration Auditing
, page 91
• A
ppDirector Thresholds
, page 92
AppDirector Dashboard
The AppDirector Web-Based Management interface includes a monitoring dashboard that enables you to take a quick view and drill down to the system, network and services statuses and statistics. Note:The dashboard display will be your default view when logging into AppDirector only if you have previously configured it as the default screen startup preference. See Startup Screen Preferences
, page 84
.
To access the AppDirector Dashboard manually
From the main menu, select Dashboard > View. The Dashboard will be loaded.
The dashboard provides the following benefits:
• is based on a client representing monitoring and statistics information
• communicates with AppDirector over existing management protocols. • saves user preferences data
• refreshes status and health every few seconds
• shows charts and graphs and these views can be refresh information every 15 seconds, together with other Radware products sampling rate. Available data is for the period in which the Dashboard is open; once it is closed, no data is stored.
The Dashboard consists of four tabs:
• System Tab - showing device hardware and resource status and utilization
• Network Tab - showing device's network connectivity status and traffic statistics
• Application Delivery Tab - showing Virtual Services and Farms status and statistics
• Summary Tab - a tab that summarizes the most important information provided by each of the other tabs. This tab's view is customizable by clicking the view icon ("eye" dropdown) next to its name and creating your own views. See customization help for more details on this subject
At the top row of the Dashboard you'll find the following controls:
• Global Settings for selecting type of degrees to be used for temperatures, and data updates interval
• Toggle the Dashboard display refresh on and off. When display refresh is turned off, data is still retrieved and stored.
• Breakout view- allowing to show the Dashboard in a dedicated window and continuing configuration.
AppDirector User Guide
Administering and Monitoring AppDirector
84 Document ID: RDWR-AD-V0231-UG1105
Every window's content in each of the views can be exported to a file. The export contains the window content according to view settings at the export time. To Export press the export icon at the top of the window you wish to export.
Note:For more information on the AppDirector Dashboard, see Monitoring AppDirector - The Dashboard
, page 585
.
Startup Screen Preferences
You can choose to have the Dashboard as the startup screen when connecting to AppDirector via WBM, or you can select from a number of additional page options.
To set Startup Screen Preferences 1.From the main menu, select Dashboard > Preferences. The Preferences window appears.
2.Select your Startup screen preference from the table below.
3.To ensure that your preference will become the default startup screen, click Set. Your preference is recorded.
Parameter
Description
Preference • Configuration Synchronization Monitoring
• Dashboard
• Device Information • Device Image (Default)
• Farm Table
• Farm Server Table • Farm Table
• Layer 4 Policy Table
• Virtual Router Table
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 85
Device Information
This feature helps you to understand the fundamentals of your installed Radware device and accompanying software. Note:Please quote this data information when you seek assistance from Radware Technical Support.
To view Device information 1.In the Device menu, select Device Information. The Device Information window appears. 2.View the parameters.
Parameter
Description
Name Designated device name.
System Up Time Reports the time elapsed since the device last reboot.
Base MAC Address MAC address of the first port on the device.
Type Type of device installed, (for example, AppDirector with Global with Persistency).
Platform Processor/ platform type for this device. (for example, OnDemand Switch 1v1).
Ports
Number of Ports Quantity of ports on this device.
Ports Config Type and configuration of ports on this device.
License Information
Throughput Maximum accelerated throughput in Mbps (Megabits per second).
SSL CPS Secure Socket Layer Connections per second (CPS) where acceleration mode is used. Also listed is Peak usage (CPS). Compression Level of compression where acceleration mode is used. Also listed is Peak usage (Mbps). Version Information
Hardware Version The hardware version. Software Version The software version of AppDirector installed, for example 2.00.
Build Date and time stamp with the build number of the software. Version State State of this software version. Open/Closed.
APSolute OS Version Versions of Bandwidth Management and Application Security modules for this software, for example, 10.31-03.01:2.06.08.
Network Driver Version of network driver used. AppDirector User Guide
Administering and Monitoring AppDirector
86 Document ID: RDWR-AD-V0231-UG1105
Platform Information
RAM Size (MB) Amount of RAM, in megabytes. Flash Size (MB) Size of flash (permanent) memory, in megabytes. Hard Disk(s) Number of hard disks configured.
Registered Whether this software version is registered or not.
Serial Number Serial number of the device.
Date Date logged in.
Time Time logged in.
Up Time Detail of system up time in days,hours,minutes and seconds.
Base MAC Address MAC address of the first port on the device.
Active Boot Time ( in days) since active boot commenced.
Secondary Boot Time ( in days) since secondary (redundant) boot commenced.
Power Supply Single or double and its status.
Number of Cores Number of CPU cores on the device.
Number of CPUs Number of CPUs on the device.
Compression card status In service or Not in Service.
SSL card status In service or Not in Service.
Parameter
Description
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 87
Device Monitoring
Device Monitoring provides an overview of the devices configuration from a single window. From the Device Monitoring window the following information can be viewed and accessed.
To view the Device Monitoring information
1.From the Device Menu, select Device Monitoring. The Device Monitoring window appears.
2.To change the Refresh Rate, enter the required value in the field and click Update.
Notifications Radware devices provide a choice of event notification methods including:
• CLI Traps
• Device Log
• Event Log
• Syslog
• SNMP Traps
• Emails
CLI Traps When connected to any Radware product through a serial cable, the device generates traps when events occur. For example, if a Next Hop Router fails, AppDirector generates the following error:
10-01-2003 08:35:42 WARNING NextHopRouter 10.10.10.10 Is Not Responding to Ping.
You can configure if traps are sent only to the serial terminal and also to SSH and Telnet clients. or if they are not sent at all, via the CLI command: Parameter
Description
Farms A table is displayed containing the following columns:
Farm: Names of the farms configured on this device. Clicking the Farm's name displays the Farm Table Update window which enables you to view and update all the parameters of the selected farm.
Users (read only): Displays the amount of users connected to the configured farms.
Servers: Displays the amount of servers and their status in the form of the following icons:
Each icon is also a link and clicking on a specific icon displays the relevant Application Server Table Update window for the selected server.
Refresh Interval [sec]
This field defines the rate at which the Device Monitoring window is refreshed and updated. Default: 60 seconds.
AppDirector User Guide
Administering and Monitoring AppDirector
88 Document ID: RDWR-AD-V0231-UG1105
manage terminal traps-outputs set. The available values are: • normal - traps are only sent to serial terminal
• on - traps are sent via all CLI access protocols (serial, Telnet, SSH)
• off - no traps are sent
For console only:
manage terminal traps-outputs set normal.
Event Log
All the events are logged on the device and can be viewed. All the events are logged on the device and can be viewed. To view the event log 1.From the Services menu, select Logging > Event Log. The Event Log window appears showing an Event Number and an accompanying description.
2.Click Event Number to select the event that you wish to display.
3.To configure the number of results per page, choose from the accompanying dropdown for 50,(default), 25,10 or 100 results per page.
4.Now, click Reset Filter. The Results per page is reset.
To clear the event log From the Event Log window, in the Clear Event Log field, click Set. The AppDirector Event log is cleared.
SysLog
Any event traps generated by AppDirector can be mirrored to a specified Syslog server, (a device running the syslog service - syslogd).
To enable Syslog Messages 1.From the Services menu, select Logging > Syslog Reporting. The Syslog Reporting window appears.
2.Set the parameters.
Parameter
Description
Syslog Operation Enables or disables syslog reporting
Default: disabled.
Syslog Station IP address of the device running the syslog service (syslogd)
If syslog reporting is enabled, AppDirector will send performance reports to a syslog station. AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 89
3.Click Set. Syslog reporting is enabled.
SNMP Traps
This enables you to set the size of the traps log by entries.
To enable SNMP Traps
1.From the Services menu, select Logging > SNMP Traps. The Traps Logging window appears.
2.Set the parameters.
3.Click Set. Trap Logging is enabled.
Source Port Source of report.
Destination Port Destination of syslog report.
Syslog Facility User-defined value is used when the device sends Syslog messages. Values include:
• Kernel Messages
• User Level Messages
• Mail System
• System Daemons
• Authorization Messages
• Syslogd Messages
• Line Printer Subsystem
• Network News Subsystem
• UUCP
• Clock Daemon
• Security messages
• FTP Daemon
• NTP Daemon
• Log Audit
• Log Alert
• Clock Daemon2
• Local Use 0, 1, 2, 3, 4, 5, 6 (default), 7
Parameter
Description
Trap Logging Enables/Disables the Trap Logging
Minimum Severity for Trap Logging Sets the minimum severity value for the trap.
Values: Info, Error, Warning Traps Log File Size Sets the size of the traps log, as a number of entries.
Power supply trap status: Enable/disable the ability to measure power supply trap status
Parameter
Description
AppDirector User Guide
Administering and Monitoring AppDirector
90 Document ID: RDWR-AD-V0231-UG1105
E-mail Notification
The device can send notifications on events to administrators via email. For each user you can configure whether it should receive notifications via email (by defining an email address for the user) and the minimal event severity reported via SNMP traps and email. The user will receive traps of configured severity and higher. The severity levels are: Info, Warning, Error and Fatal. For email address and notification severity configuration per user see - Users (link to users configuration).
Note:AppDirector optimizes the mailing process by gathering reports and sending them in a single notification message once the buffer is full or once a timeout of 60 seconds expires.
To configure E-mail Notifications 1.From the Services menu, select Logging > Email Reporting. The Email Error Reporting window appears.
2.Set the parameters.
3.Click Set. Your configuration is set.
Configurable SMTP To Field
Message logging is disabled by default. You must enable logging if you wish to send messages to one or more output locations. When enabled, log messages are sent to a logging process, which logs messages to designated locations asynchronously to the processes that generated the messages. You must set a logging output location to view any logs.
The SMTP Client window enables AppDirector to send information messages via email to predetermined users. This feature can be used for sending trap information via email. In the User Table each user is assigned a trap severity level, Info, Warning, Error or Fatal and receives emails according to that severity level. For example, a user assigned the severity level Error, receives emails for events with the severity level Error and Fatal. To optimize AppDirector configuration and resource utilization, AppDirector can indicate and alert usage of various tables and other parameters.
To allow AppDirector to send event notifications via email, the SMTP client must be configured on the device. Parameter
Description
Send Emails on Errors
Whether to send notifications via email or not.
Values: Enabled or Disabled (Default).
To Field Text Text to use in the sent email "To" field.
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 91
To configure the SMTP Client 1.From the Services menu, select Logging > SMTP. The SMTP Client window appears.
2.Set the parameters.
3.Click Set. The SMTP Client is configured.
Note:To receive emails about errors, you need to enable features related to mail sending, such as Send Emails on Errors and for each user set email address and Severity level in the Users Table.
Configuration Auditing
Configuration Auditing is the process of logging every configuration change and activity. When Configuration Auditing is enabled, the device keeps track of all changes made to the configuration. When a user creates a new configuration object, the device reports the action, for example, user created a new farm or added a server to a farm. The device sends an event in CLI format (if the user created the object via Web Based Management). If the user modifies the existing entry, the device also reports the old and new values of the changed parameter. Deletions of objects are reported in the same CLI format. Where there is no CLI equivalent to a Web Based Management, the device reports the parameter’s MIB Name.
The notification message contains these details:
• Name of the MIB variable that was changed.
• New value of the variable.
• Time of configuration change.
Parameter
Description
SMTP Server IP address of the SMTP Server. Alternate SMTP Server Address
An IP address of an alternative SMTP Server. The alternate SMTP server is used when SMTP connection cannot be established successfully with the main SMTP server, or when main SMTP server closed the connection. The device tries to establish connection to the main SMTP server, and starts re-using it when available.
Backup Device Email Address
Sets the email of the Backup AppDirector device. This is used when the device is configured as an SMTP client. You can configure AppDirector as an SMTP client, allowing it to send email messages to specified users. This feature can be used for sending trap messages. In the User Table, each user is assigned a trap severity level (Info, Warning, Error, or Fatal) and receives emails according to that severity level. For example, a user assigned the severity level Error, receives emails for events with the severity level Error and Fatal.
Own Email Address Mail address of the device, for example myname@domain.com. SMTP Client Status Enables / Disables the SMTP client. Status must be set to Enabled to support features that are related to sending email messages.
Default: Disable
AppDirector User Guide
Administering and Monitoring AppDirector
92 Document ID: RDWR-AD-V0231-UG1105
• Configuration tool that was used (APSolute, Telnet, SSH, WBM).
• User name, when applicable.
Configuration Auditing is enabled or disabled per device and it affects all users and all management interfaces. The default is disabled.
To enable configuration auditing 1.Select Services > Auditing. The Auditing Status window appears.
2.Select enable. 3.Click Set. The auditing status is set to enable.
To disable configuration auditing 1.Select Services > Auditing. The Auditing Status window appears.
2.Select disable.
3.Click Set. The auditing status is set to disable.
AppDirector Thresholds
To optimize AppDirector configuration and resource thresholds, AppDirector can indicate and alert usage of various tables and other parameters. AppDirector continuously monitors this usage and can notify you when usage thresholds are exceeded. Threshold warnings are available for the following tables and parameters:
To view and set Threshold Settings 1.From the Services menu select AppDirector Thresholds > Settings. The AppDirector Thresholds Settings window appears
2.Set the parameters.
Parameter
Description
Send Threshold Warnings
Enables or disables (default) the threshold warning traps mechanism. Min. Time Between Warnings (sec) Minimum time, in seconds, between consecutive warnings AppDirector sends about the same resource. Default: 60 Note: Value of 0 means traps are sent continuously. Client Table Threshold Level Defines the percentage of Client Table usage where a trap is sent. Statistics are kept as follows:
• Current number of entries
• Average value for last 5 seconds
• Average value for the last 60 seconds
Default: 85
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 93
Layer 3 Client Table Threshold Level Defines percentage of Client Table usage where a trap is sent. Default: 85
Application Servers Connection Limit Threshold Level
Defines the percentage of Application Servers Connection Limit usage where a trap is sent. Default: 85
When the number of sessions to an application server exceeds 85% of the Connection Limit configured for that server, a trap is sent.
Physical Servers Connection Limit Threshold Level
Defines the percentage of Physical Servers Connection Limit usage where a trap is sent. Default: 85
When the number of sessions to a physical server exceeds 85% of the Connection Limit configured for that server, a trap is sent.
Farms Capacity Threshold Level
Defines the percentage of farm capacity used where a trap is sent. Default: 85 When the number of sessions to a farm exceeds 85% of the Capacity Threshold configured for that farm, a trap is sent.
Client NAT Threshold Level
Percentage of Client NAT ports usage above which a trap is sent. Default: 85 When 85% of Client NAT ports for any Client NAT address are used, a trap is sent.
Outbound NAT Threshold Level
Percentage of Outbound NAT ports usage above which a trap is sent. Default: 85 When 85% of Outbound NAT ports of the Outbound NAT addresses are used, a trap is sent.
Session ID Threshold Level
Percentage of the Session ID table usage above which a trap is sent. When 85% of Session ID table is used, a trap is sent.
Values: 1 - 99
Default: 85
Requests Threshold Level
Percentage of the Request table usage above which a trap is sent. Default: 85
When 85% of the Request table is used, a trap is sent.
CPU Utilization Threshold Level
High CPU on the device is caused by many reasons. A device should actively notify its status, if this status is suspected to be a non-valid status. To do this, a trap can be sent if for a period of 30 seconds the average CPU utilization in the device is higher than a specified threshold. Another trap can be sent if the device had 30 seconds of CPU utilization lower than the specified threshold. Threshold is configurable with CLI or WBM and SNMP.
Traps are sent only if threshold warning sending has been enabled (as other threshold traps).
Default: 95
Throughput Utilization Threshold Level (Mbps)
Supports configurable overflow alert threshold for licensed throughput utilization. The default for the threshold level is 90%.
Parameter
Description
AppDirector User Guide
Administering and Monitoring AppDirector
94 Document ID: RDWR-AD-V0231-UG1105
3.Click Set. Your configuration is set.
Note:When thresholds are set to 0 (disabled), no traps are sent.
AppDirector Thresholds Statistics
AppDirector Thresholds statistics contains various tables where you can view averages, configured maximums and minimums.
Tunable Tables
The Tunable Tables Usage Statistics window provides you with information regarding the utilization of various tables in AppDirector.
To view the Tunable Tables Usage Statistics parameters From the Services menu, select AppDirector Thresholds > Statistics > Tuning Tables. The Tunable Tables Usage Statistics window appears, which contains these read-only parameters:
SSL CPS Utilization Threshold Level
Supports configurable overflow alert threshold for licensed SSL CPS utilization. The default for the threshold level is 90%.
Compression Utilization Threshold Level (Mbps)
Supports configurable overflow alert threshold for licensed compression utilization. The default for the threshold level is 90%.
Parameter
Description
Table Name The name of the table in the Tunable Table.
Current Entries The number of entries in the Tunable Table. 5 sec Average Average resources utilization in the last 5 seconds.
60 sec Average Average resources utilization in the last 60 seconds.
Max Num of Entries Maximum configured table size.
Parameter
Description
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 95
Client NAT Level
The Client Table Threshold Level defines the percentage of Client Table usage where a trap is sent. The default is 85. The Client NAT Level window allows you to view the client table's threshold data.
To view the Client NAT Level parameters From the Services menu, select AppDirector Threshold > Statistics > Client NAT Level. The Client NAT Level window appears, which contains the following read-only parameters:
Outbound NAT Level
Outbound NAT Port Threshold Level defines the percentage of Outbound NAT Ports usage where a trap is sent. The default is 85. When 85% of Outbound NAT ports for the Outbound NAT addresses, a trap is sent. The Outbound NAT Level window allows you to view outbound NAT level information.
To view the Outbound NAT Level parameters
From the Services menu, select AppDirector Threshold > Statistics > Outbound NAT Level . The Outbound NAT Level window appears, which contains these read-only parameters:
Application Servers Level
Application Servers Connection Limit Threshold Level defines the percentage of Application Servers Connection Limit usage where a trap is sent. Default is 85. When the number of sessions to an application server exceeds 85% of the Connection Limit configured for that server, a trap is sent.
Application Servers Connection Limit defines the maximum number of allowed sessions open at any given time on this application server. When the limit is reached, new sessions are no longer forwarded to this application server. The Application Servers Connection Level window allows you to view the application server's Connection Level information.
Parameter
Description
NAT Address Specifies the IP address to be used for NAT.
Current Current port usage for the Client NAT address.
Average Average port usage for the Client NAT address.
Parameter
Description
NAT Address Specifies the IP address to be used for NAT.
Current Current port usage for the Outbound NAT address.
Average Average port usage for the Outbound NAT address.
AppDirector User Guide
Administering and Monitoring AppDirector
96 Document ID: RDWR-AD-V0231-UG1105
To view the Application Servers Connection Level parameters From the Services menu, select AppDirector Threshold > Statistics > Application Servers Level. The Application Servers Connection Level window appears containing these read-only parameters:
Physical Servers Level
Physical Servers Connection Limit defines the maximum number of allowed sessions open at any given time on this physical server, meaning to application servers in any AppDirector farm that share the same name. When the limit is reached, new sessions are no longer forwarded to this physical server.
Physical Servers Connection Limit Threshold Level defines the percentage of Physical Servers Connection Limit usage where a trap is sent. The default is 85. When the number of sessions to a physical server exceeds 85% of the Connection Limit configured for that server, a trap is sent.
The Physical Servers Connection Level window allows you to view the physical server's connection level information.
To view the Physical Servers Connection Level parameters From the Services menu, select AppDirector Threshold > Statistics > Physical Servers Level. The Physical Servers Connection Level window appears, which contains these read-only parameters:
Farms Capacity Level
Farm Capacity Threshold is used for a farm that is part of a distributed environment. When the farm’s Capacity Threshold is met, AppDirector reports to remote devices that it is no longer accepting further distributed sessions to this farm. The Farm Capacity Threshold Level is the percentage of farm capacity used, above which a trap is sent. The default is 85. When the number of sessions to a farm exceeds 85% of the capacity threshold configured for that farm, a trap is sent. The Farm Capacity Level window lets you view information about the Farm's Capacity Level. Parameter
Description
Farm Name Name of the farm.
Server Name Defines name of server associated with this application. Current Current attached users for Application Servers address.
Average Average attached users for the Application Servers address.
RTSP Redirect (last second)
Number of RTSP sessions redirected to this Server during the last second.
Parameter
Description
Server Name Defines name of group of farm servers associated with this physical server. Adding a new server to a farm using a Server Name already defined in another farm, implies that it is the same physical server.
Current Current attached users for the Physical Servers address. Average Average attached users for the Physical Servers address.
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 97
To view the Farm Capacity Level parameters 1.From the Services menu, select AppDirector Threshold > Statistics > Farm Capacity Level. The Farm Capacity Level window appears, which contains these read-only parameters.
2.Select the desired farm name. The Farm Capacity Level Update window appears, which contains the following read-only parameters.
Parameter
Description
Farm Name Address of the server farm.
Current Connections Number Current Current number of connection to the farm.
Average Connections Number Average number of connections to the farm.
Parameter
Description
Farm Name User-defined name of the farm.
Attached Users Number of currently active users attached to this server.
Peak Load Maximum number of frames per second dispatched to the server since the last reset.
Frame Rate Number of frames dispatched to server
Frame Rate (bytes) Number of frames per second dispatched to server.
Backup Server Used Indicates that the farm used a backup server.
Distribution Threshold Reached
Indicates the number of times this threshold is reached.
Capacity Threshold Reached Indicates that the farm has reached its full capacity.
DNS Requests Number of DNS requests for this farm.
DNS Requests (Last second) Number of DNS requests for this farm in the last second.
DNS Local Reply Number of DNS queries resolved to local farm name.
DNS Local Reply (Last second)
Number of DNS queries resolved to local farm name in last second.
DNS Reply Redirect Number of DNS queries resolved to other AppDirector.
DNS Reply Redirect (Last second)
Number of DNS queries resolved to other AppDirector in the last second.
Total HTTP (Last second) Indicates number of HTTP clients in the last second.
Local HTTP (Last second) Indicates how many HTTP clients were served locally and not redirected to another AppDirector in the last second.
Redirected HTTP (Last second)
Indicates rate at which HTTP clients were redirected in the last second.
Triangle (Last second) Indicates number of clients served by triangulation service in the last second.
Local Triangle (Last second) Indicates how many clients were served locally and not redirected by triangulation service to another AppDirector in the last second.
Redirected Triangle (Last second)
Indicates the rate at which clients were redirected by triangulation service in the last second.
AppDirector User Guide
Administering and Monitoring AppDirector
98 Document ID: RDWR-AD-V0231-UG1105
.
Note:Not available if Traffic Flow Identification is set to Session or Full Layer 4 Session.
Basic Switching (Layer 2 Capability)
This section discusses how to configure Layer 1-2 switching functions and includes these topics:
• AppDirector Physical Interface Configuration
, page 99
• Layer 2 Interface Table
, page 99
• Virtual LA
N
, page 101
• Spanning Tree Protocol
, page 109
• VLAN Tagging
, page 107
• Link Aggregation (Port Trunking)
, page 112
• Port Mirroring
, page 116
This table summarizes Layer 2 capability for Radware’s OnDemand switches.
Total RTSP (Last second) Total number of RTSP sessions handled.
Local RTSP (Last second) Total number of RTSP sessions handled by local servers.
Redirected RTSP (Last second)
Total number of RTSP sessions redirected to remote servers.
Current Connections Number Number of directed attached clients to this farm.
Average Connections Number Average number of directed attached clients to this farm.
Total SIP (Last second) Total number of SIP sessions handled.
Local SIP (Last second) Total number of SIP sessions handled by local servers.
Redirected Proxy Indicates rate at which proxy clients were redirected in last second.
Redirected SIP Indicates rate at which SIP clients were redirected in last second.
Local Proxy (Local second) Total number of proxy sessions handled by local servers.
Total Proxy (Last second) Total number of proxy sessions handled.
Layer 2 Feature
ODS1 and ODS1 XL
ODS2 and ODS2XL
ODS3 v2 and ODS3XL
ODS VL and ODS VL XL
Radware Segmentation (physical Port and VLAN)
Yes Yes Yes Yes
Regular VLAN (bridging) Yes Yes Yes Yes
Switch VLAN No Yes Yes No
VLAN tagging 802.1q Yes Yes Yes Yes
Link aggregation 802.3ad Yes Yes Yes Yes
Port mirroring (Copy port) No Yes Yes No
STP 802.1d
No Yes Yes
No Parameter
Description
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 99
AppDirector Physical Interface Configuration
AppDirector enables you to change physical attributes of each port such as speed and duplex mode.
To update the port’s physical attributes 1.From the Device menu, select Physical Interface. The Physical Interface window appears.
2.Set the parameters.
3.Select the required port. The Physical Interface Table Update window appears.
4.Update the required fields and click Set. Your configuration is set.
Layer 2 Interface Table
A Layer 2 Interface is defined as any interface with its own MAC address - physical port, trunk, VLAN. You can configure the administrative status of each interface, monitor and interface statistics. IPv6 interfaces can be defined alongside IPv4 ones for all Layer 2 interfaces, (physical ports, VLANs and trunks). Each Layer 2 interface has IPv6 parameters that apply to all the IPv6 interfaces defined for that interface. Each IP interface is also associated with a prefix. The prefix is the successor of the net mask used in IPv4. There may be no more than one IP address for the same prefix in the same Layer 2 interface. This restriction is for management convenience and applies also for IPv4. To view/edit the Layer 2 Interface Table
1.From the Device menu, select Layer 2 Interface. The Layer 2 Interface Table window appears.
2.Select the Interface Index number to edit, and the Layer 2 Interface Table Update window appears with read-only parameters.
3.Set the parameters.
Parameter
Description
Port Index Index number of the port
Speed Traffic speed of the port. Values: Ethernet, Fast Ethernet, Giga Ethernet, or XG Ethernet.
Note: According to standards, this can be changed only for copper ports. Once this is changed the Auto Negotiate parameter is set to Off.
Duplex Whether the port allows both inbound and outbound traffic (Full Duplex) or one way only (Half Duplex).
Note: According to standards, this can be changed only for copper ports with a speed lower than Giga Ethernet. Once this is changed the Auto Negotiate parameter is set to Off.
Auto Negotiate Automatically detects and configures the speed and duplex required for the interface. AppDirector User Guide
Administering and Monitoring AppDirector
100 Document ID: RDWR-AD-V0231-UG1105
Read Only Parameter
Description
Interface Index The Interface index number.
Interface Description A textual string containing information about the interface. This string should include the name of the manufacturer, the product name and the version of the interface hardware/software.
Interface MTU The size of the largest packet which can be sent/received on the interface, specified in octets. For interfaces that are used for transmitting network datagrams, this is the size of the largest network datagram that can be sent on the interface.
Interface Type Type of interface. Additional values are assigned by the Internet Assigned Numbers Authority (IANA), through updating the syntax of the textual convention.
Interface Speed An estimate of the interface's current bandwidth in bits per second.
MAC Address The MAC Address of the interface.
Interface Admin Status Controls interface administrative status. Values: Up/Down.
Operational Status Specifies the operational status of the router. Values: Up/Down.
Interface Last Change Value of sysUpTime at the time the interface entered its current operational state. If the current state was entered prior to the last re-
initialization of the local network management subsystem, then this object contains a zero value.
ifINOctets Number of incoming octets (bytes) through the interface including framing characters.
InUcastPkt Number of packets delivered by this sub-layer to a higher (sub-) layer, which were not addressed to a multicast or broadcast address at this sub-layer.
InNUcastPkt Number of packets delivered by this sub-layer to a higher (sub-) layer, which were addressed to a multicast or broadcast address at this sub-layer. ifINDiscards Number of inbound packets chosen to be discarded even though no errors had been detected to prevent their being deliverable to a higher-layer protocol. One possible reason for discarding such a packet could be to free up buffer space.
ifINErrors For packet-oriented interfaces, the number of inbound packets that contained errors preventing them from being deliverable to a higher-
layer protocol. For character-oriented or fixed-length interfaces, the number of inbound transmission units that contained errors preventing them from being deliverable to a higher-layer protocol.
ifOutOctets Total number of octets (bytes) transmitted out of the interface, including framing characters. OutUcastPkt Total number of packets that higher-level protocols requested be transmitted, and which were not addressed to a multicast or broadcast address at this sub-layer, including those that were discarded or not sent.
OutNUcastPkt Total number of packets that higher-level protocols requested be transmitted, and which were addressed to a multicast or broadcast address at this sub-layer, including those discarded or not sent.
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 101
4.Click Set. Your configuration is set.
Virtual LAN
A Virtual LAN (VLAN) is a group of devices on different physical LAN segments or on a single LAN segment, which can interact with each other as if they were all on the same physical LAN segment. In other words, a VLAN is a group of PCs, servers and other network resources that behave as if they were connected to a single, network segment even though they are not, physically. They are able to share resources and bandwidth as if they were connected to the same section. Some switches are configured to support single or multiple VLANs. When a switch supports multiple VLANs, the broadcast domains are not shared between the VLANs.
• The device learns the Layer 2 addresses on every VLAN port.
• Known unicast frames are forwarded to the relevant port.
• Unknown unicast frames and broadcast frames are forwarded to all ports.
AppDirector VLAN Types
AppDirector VLANs provide bridging and switching functionality among ports assigned to the same VLAN. AppDirector supports both Regular VLAN and Switch VLAN.
Note:AppDirector devices support up to 64 regular or switched VLANs and up to 2048 VLAN IDs.
Regular VLAN
A Regular VLAN can be described as an IP Bridge (a software bridge) between multiple ports that incorporates all the traffic redirection of passing traffic at all layers (Layer 2-Layer 7). Two protocols can be used with Regular VLANs:
• IP Protocol: The VLAN must be assigned an IP address. All of the traffic between ports is intercepted transparently by AppDirector. Packets that need intelligent intervention are checked and modified by AppDirector and then forwarded to the relevant port. Other packets are simply bridged by AppDirector as if they were on the same wire.
• Other Protocol: An Other protocol VLAN cannot be assigned an IP address. This type of VLAN is used to bridge non-IP traffic through AppDirector. To handle both packets that need intelligent intervention and non-IP traffic, you can configure IP VLAN and “Other” VLAN on the same ports.
Note:Switch VLAN can be standalone or part of a Regular VLAN.
ifOutDiscards Number of outbound packets which were chosen to be discarded even though no errors had been detected to prevent their being transmitted. One possible reason for discarding such a packet could be to free up buffer space.
ifOutErrors For packet-oriented interfaces, the number of outbound packets that could not be transmitted because of errors. For character-oriented or fixed-length interfaces, the number of outbound transmission units that could not be transmitted because of errors.
Read Only Parameter
Description
AppDirector User Guide
Administering and Monitoring AppDirector
102 Document ID: RDWR-AD-V0231-UG1105
Switch VLAN
Switch VLAN provides wire-speed VLAN capabilities implemented through the hardware switch fabric of the AppDirector device. Depending on the protocol defined for the Switch VLAN, frames are treated accordingly.
• Switch VLAN Protocol: Frames arriving at the VLAN port are switched according to Layer 2 information. AppDirector does not intercept this traffic.
• IP Protocol: Frames reaching the VLAN port are switched according to Layer 2 information, except those whose Layer 2 address is the same as the AppDirector port Layer 2 address. Frames with AppDirector Layer 2 destination are processed by AppDirector and then forwarded. VLAN Configuration
A VLAN configuration procedure involves:
1.Creating a VLAN
2.Adding ports and/or trunks to that VLAN.
In addition you can change the Ethernet type and mask used by all VLANs.
VLAN Parameters
Here you can configure the VLAN Ethernet type and mask per the device.
To configure the VLAN Parameters window 1.From the Device menu, select VLAN Parameters. The VLAN Parameters window appears.
2.Set the parameters. 3.Click Set. Your configuration is set.
Parameter
Description
VLAN Ethernet Type
Defines the Ethernet type for user defined VLANs.
VLAN Ethernet Type Mask
Defines the mask on Ethernet type for user defined VLANs
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 103
Creating and Editing VLANs and VLAN Ports
This shows you how to create and edit VLANs and VLAN ports.
To view/create a VLAN 1.From the Device menu, select VLAN Table. The Virtual LAN Table window appears. The Virtual LAN Table window appears.
2.Set the parameters. Parameter
Description
Interface Number Interface number of VLAN automatically assigned by management station.
Type Required VLAN type:
Regular (Default): The VLAN acts as a bridge. Switch: Switch VLAN can be part of a Regular VLAN.
Note: Switch VLANs are only supported on ODS2 and ODS3 devices.
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 (default).
Up Criterion Defines conditions under which a VLAN interface is considered Up.
• Default by Type (Default): For Regular VLAN, all ports in the VLAN are up.
Note: This is true when interface grouping is enabled, otherwise ports behave the same as Switch VLAN.
For Switch VLAN, at least one of the ports in the VLAN is up.
• All Ports: The VLAN is considered down when all the ports participating in the VLAN are down and it is considered up when all the ports, participating in the VLAN are up.
Note: After reboot the VLAN status is "up" even though the port is still down, therefore VLAN status should be "down".
• One Port: The VLAN is considered down when at least one port participating in the VLAN is down and it is considered up when at least one port, participating in the VLAN is up
AppDirector User Guide
Administering and Monitoring AppDirector
104 Document ID: RDWR-AD-V0231-UG1105
3.To create a new VLAN, click Create. The Virtual LAN Table Create window appears.
4.For editing, in the Virtual LAN Table window, select a VLAN to update.
5.Click Edit. The Virtual LAN Update window appears.
6.Set the parameters.
7.Click Set. Your configuration is set.
Adding Physical Ports to a VLAN
This procedure explains how to add physical ports to a VLAN.
To add physical ports to the VLAN 1.In the Virtual LAN Table window, in the VLAN Port Table section, click Create. The VLAN Port Create window appears.
2.Set the parameters.
3.Click Set. Your configuration is set. Down Criterion Defines conditions under which a VLAN interface is considered Down.
• Default by Type (Default): For Regular VLAN, at least one of the ports in the VLAN is down.
Note: This is true when interface grouping is enabled, otherwise ports behave the same as Switch VLAN.
For Switch VLAN, all ports in the VLAN are down.
• All Ports: The VLAN is considered down when all the ports participating in the VLAN are down and it is considered up when all the ports, participating in the VLAN are up.
• One Port: The VLAN is considered down when at least one port participating in the VLAN is down and it is considered up when at least one port, participating in the VLAN is up.
Parameter
Description
VLAN Interface Index
Select VLAN for which you require to add a port.
VLAN Port Index The Layer 2 interface you want to attach to the VLAN. Can be port index, trunk index, or Switch VLAN.
Port Type Interface Grouping State
Defines whether the status of this L2 interface should be taken into consideration when calculating VLAN status for Interface Grouping (relevant in redundant configurations only - see Redundancy
, page 143
) Select from:
• Included: Allows interfaces to initiate Interface Grouping if it is down.
• Excluded: Does not allow interfaces to initiate Interface Grouping if it is down.
Parameter
Description
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 105
Bridging
Once a regular VLAN is defined, AppDirector performs bridging among interfaces assigned to the same VLAN. Bridging within a VLAN means that AppDirector learns the MAC addresses of frames arriving from each physical interface, and maintains a list of MAC addresses per interface. AppDirector enables you to statically add MAC addresses to the interface list.
When a frame arrives from one interface, AppDirector looks for the frame Destination addresses within its address list according to the following conditions:
• If the Destination address is listed in the same interface as the Source address, AppDirector discards the frame. • If the Destination address is listed in another interface, AppDirector forwards the frame to the relevant interface. • If the Destination address is not listed in any interface, AppDirector broadcasts the frame to all interfaces participating in the VLAN.
Bridge Operating Parameters
To configure Bridge operating parameters, perform he procedure shown here.
To configure Bridge Operating Parameters 1.From the Bridge menu, select Operating Parameters. The Bridge Operating Parameters window appears.
2.Set the parameters
3.Change the Forwarding Table Aging Time value.
4.Click Set. Your configuration is set.
Parameter
Description
Bridge Address (Read Only)
The MAC Address used by the device.
Bridge Type (Read Only)
Types of bridging the device can perform.
Forwarding Table Aging Time
How many seconds learned entries remain in the Forwarding Table. The counter is reset each time the entry is used. After this time, entries are deleted from the table. Minimum: 10 seconds.
AppDirector User Guide
Administering and Monitoring AppDirector
106 Document ID: RDWR-AD-V0231-UG1105
Bridge Global Forwarding Table
The Bridge Global Forwarding Table is used to monitor bridge forwarding nodes. To access the Global Forwarding Table From the Bridge menu, select Global Forwarding Table. The Global Forwarding Table window appears with these read-only parameters:
Static Forwarding Table
This table is used to monitor, create and edit static bridge forwarding nodes. To create/edit the Static Forwarding Table 1.From the Bridge menu, select Static Forwarding Table. The Static Forwarding Table window appears.
2.Click Create. The Static Bridge Forwarding Table Create window appears.
3.Set the parameters.
4.Click Set. Your configuration is set.
Parameter
Description
MAC Address The Node's MAC address
Port Port through which node has been learned. Port through which frames are received from this entry.
Status Describes how node entry was added to the list, and indicates status
• Learned: The entry was automatically learned. • Self: The entry is a device port.
• Mgmt: The entry is a static node manually entered using the Edit button.
• Other: Node status cannot be described by above.
Parameter
Description
Static MAC Address
The Static node's MAC address.
Static Receive Port
Port through which frames are received from this entry.
Status Describes how node entry behaves upon device reset:
• Permanent: Entry remains after device reset. • Delete On Reset: Entry is deleted by a device reset.
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 107
VLAN Tagging
VLAN Tagging is an IEEE standard (802.1q) for supporting multiple VLANs associated with the same switch port. Each VLAN is tagged with a unique identifier to allow the identification of different VLAN traffic on the same physical port. This protocol allows individual VLANs to communicate with one another with the use of a Layer 3 router.
AppDirector can rewrite VLAN Tags or retain the tags on packets that pass through it. For AppDirector to support VLAN Tags, by either forwarding or overwriting them, support for a 802.1q environment must be enabled. By default VLAN Tags are not supported on AppDirector. When the status of VLAN Tag support is changed, you need to reboot the device. Notes:
>> VLAN tags can also be attached to IPv6 interfaces to apply to IPv6 traffic and behave exactly like IPv4 interfaces.
>> If you want 8021q information, you need to capture what is being sent to the AppDirector on the neighboring switch. Therefore 8021q header information cannot be displayed in the packet capture.
Retaining VLAN Tags
AppDirector enables you to preserve existing VLAN Tags on incoming traffic passing through the device. Rewriting VLAN Tags
VLAN Tagging can be used with AppDirector, where AppDirector is connected to multiple VLANs on the same switch, and different servers are assigned to different VLANs. VLAN Tagging support is based on the local subnet to which the traffic is sent or on the destination MAC of the packet. Therefore, AppDirector cannot tag packets by the destination subnet if it is not local to the AppDirector. The switch connected to the AppDirector must be configured consistently with the AppDirector tagging configuration.
Each IP interface can have a VLAN tag associated with it. AppDirector recognizes an IP interface as a L2 interface/IP address combination. When using AppDirector with VLAN Tagging, all packets sent to a Destination MAC address of a Next Hop Router (with an IP address on a local subnet that is associated with a tag-configured IP interface), carry the VLAN tag, regardless of the Destination IP address of the packet. In addition, all packets sent to any Destination host on a tag-configured IP interface carry the VLAN tag. This includes:
• All Health Check packets from AppDirector to Next Hop Routers, including Full Path Health Monitoring. • ARP requests and responses from AppDirector to the Next Hop Routers.
• Unicast ARPs between redundant AppDirectors.
• Gratuitous ARPs, as part of the redundancy feature. If an IP interface does not have a VLAN tag configured, then the packets are sent without a tag (standard Layer 2 MAC header).
Configurable VLAN ID values range from 0 to 4095. AppDirector automatically sets the 802.1p portion of the tag (the first three bits) to 000. If a packet arrives without a VLAN tag, to a Destination interface of AppDirector with VLAN tag, AppDirector sets a tag on the packet according to the Destination local subnet, even if it’s in retain mode and behaves as in overwrite.
AppDirector User Guide
Administering and Monitoring AppDirector
108 Document ID: RDWR-AD-V0231-UG1105
Note:802.1p is a specification for giving Layer 2 switches the ability to prioritize traffic (and perform dynamic multicast filtering).
VLAN Tagging Configuration
The VLAN Tagging window allows you to enable and disable VLAN tagging. AppDirector can rewrite VLAN Tags on packets that pass through it.Configurable VLAN ID values range from 0 to 4095. AppDirector automatically sets the 802.1p portion of the tag (the first three bits) to 000. If a packet arrives without a VLAN tag, to a Destination interface of AppDirector with VLAN tag, AppDirector sets a tag on the packet according to the Destination local subnet, even if it’s in retain mode and behaves as in overwrite.
To enable VLAN Tagging 1.From the Device menu, select VLAN Tagging. The VLAN Tagging window appears.
2.From the 802.1q Environment drop-down box, select Enable. 3.Set the VLAN Tag Handling using these parameters.
4.Click Set. Your configuration is set.
Parameter
Description
Retain The device preserves existing VLAN tags on the incoming traffic that passes through the device. Traffic generated by the device is tagged according to IP Interface configuration.
Overwrite (Default) The device performs VLAN Tagging of outgoing traffic in accordance with IP Interface configurations. AppDirector sets tags for packets according to the following parameters: • Destination IP of the packet if it is on the same local subnet with AppDirector OR • MAC address of the firewall that is configured on AppDirector and through which the packet is sent.
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 109
Spanning Tree Protocol
The Spanning Tree Protocol (STP) is a protocol that prevents loops in networks and environments where there is more than one path that the traffic may pass through. If a packet has numerous links, it can choose which path to use, which may cause loops in the network. The STP algorithm makes a calculation based on various parameters including the preferred path and logically blocks all other paths. AppDirector supports the Rapid Spanning Tree Protocol (backwards compatible with STP), allowing you to configure Spanning Tree on each VLAN of the device. Different VLANs may have different STP settings.
Notes:
>> STP is NOT supported on OnDemand Switch 1 Platforms.
>> Spanning Tree is supported only for IP-Regular and IP-Switch VLANs.
>> When working with STP in redundant configuration, VRRP redundancy mechanism must be used and the primary device must have the lowest Bridge ID.
∙Spanning Tree Global Parameters/Settings
The Spanning Tree Global Parameters/Settings window enables you to configure the global parameters of the Spanning Tree, affecting all the Spanning Tree instances running on the device.
To configure the STP Global Settings 1.From the Bridge menu, select STP > Global Parameters. The STP Global Parameters window appears.
2.Set the parameters.
Parameter
Description
Spanning Tree Mode Disables Spanning Tree support per VLAN.
Values: Disabled (Default) or Per-VLAN (enabled).
Default Bridge Priority Value represents default priority of bridge. Values: 0 - 61440 in multiples of 4096. The lower the value, the higher the priority
Default: 32768
Default Hello Time [sec.]
Value represents interval in seconds, between 2 BPDU packets sent by device. Values: 1 - 10 seconds. Default: 2 seconds. Default Max Aging Time [sec.]
Value represents the maximum time, in seconds, the device waits for a BPDU packet before it tries to re-configure. Values: 6 - 40 seconds. Default: 20 seconds. AppDirector User Guide
Administering and Monitoring AppDirector
110 Document ID: RDWR-AD-V0231-UG1105
3.Click Set. Your configuration is set.
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).
To configure Spanning Tree Instances 1.From the Bridge menu, select STP > Instances. The STP Instances window appears.
2.Select the relevant VLAN ID that you wish to edit and select it. The Spanning Tree Instances Run on this Bridge Update window appears.
3.Set the parameters.
Default Forward Delay Time [sec.]
Time that the device waits before changing the port`s state. Values: 4 - 30 seconds. Default: 15 seconds. Default Port Priority Value represents port priority. When 2 (or more) ports have same value, device uses port with lowest MAC address. Values: 0 - 240 seconds. Default value: 128 seconds. Parameter
Description
VLAN ID VLAN to apply these settings to, alternatively you may apply the settings to multiple VLANs.
Bridge Priority Default priority of the bridge.
Values: 0 - 61440 in multiples of 4096. Default: 32768 Maximum Aging Time [sec.]
Maximum time, in seconds, that the device waits for a BPDU packet before it tries to re-configure. Values: 6 - 40 seconds. Default: 20 seconds. Hello Time [sec.] Interval, in seconds, between two BPDU packets sent by device. Values: 1 - 10 seconds. Default: 2 seconds. Forward Delay Time [sec.]
Time, in seconds, the device waits before changing port's state. Values: 4 - 30 seconds. Default:15 seconds. STP Status Allows you to enable and disable the STP status.
Parameter
Description
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 111
4.Click Set. Your preferences are recorded.
Spanning Tree Ports
Within each VLAN, you can configure individual physical port behavior. Ports connected directly to servers do not need to wait for the forward delay timer to expire before they start forwarding traffic. You can enable ModeFast, enabling the device to forward traffic as quickly as possible. You can also exclude any physical port from participating in the STP algorithm.
To configure Spanning Tree Ports 1.From the Bridge menu, select STP > Ports. The STP Port Information window appears.
2.Select the relevant port from the table. The STP Port Information Update window reappears.
3.Set the parameters.
4.Click Set. Your preferences are recorded.
Parameter
Description
Port ID (Read Only) Number of the selected port from the table.
VLAN ID (Read Only) Specifies the VLAN the physical port belongs to.
Priority Represents port priority. When two (or more) ports have the same value, the device uses the port with the lowest MAC address. Values: 0 - 240 in multiples of 16. Default: 128 Path Cost This sets the spanning tree path cost for this port. Values: 1 - 65535, defined automatically according to port speed. You can also change this value. Note: Default values for costs on the devices ports are influenced by the port speed. Port Speed versus Path Cost
• 10Mbps /100
• 1Gbps /4
• 100Mbps /19
• 10Gbps/ 2
Mode Fast When enabled, this port will change its status to forwarding state.
Values: Enabled / Disabled (default).
STP Status Enables STP support on the selected port. When disabled, the physical port does not participate in STP.
Values: Enabled (default)/ Disabled
AppDirector User Guide
Administering and Monitoring AppDirector
112 Document ID: RDWR-AD-V0231-UG1105
Link Aggregation (Port Trunking)
Link Aggregation, or Port Trunking, is a method of combining physical network links into a single logical link for increased bandwidth. With Link Aggregation you can increase the capacity and availability of the communications channel between devices (both switches and end stations) using existing Fast Ethernet and Gigabit Ethernet technology. This is performed by using a set of multiple parallel physical links between two devices grouped together to form a single logical link. Link Aggregation includes the following topics:
• Link Aggregation Global Configuration
, page 113
• Link Aggregation Trunk Table
, page 114
• Link Aggregation Trunk Port Table
, page 115
• Management
Trunk
, page 116
The port trunking feature allows you to define up to seven trunks, (on OnDemand Switch 1, 2 & VL platforms and up to four on OnDemand Switch 3 platforms). Up to eight physical links can be aggregated into one trunk. AppDirector supports both static and dynamic (LACP) trunks. To provide optimal distribution for different scenarios the load sharing algorithm allows decisions based on source or destination (or both) Layer 2 address (MAC), Layer 3 address (IP), and Layer 4 address (TCP/UDP port numbers). These parameters are used as input for a hashing function.
Link aggregation also provides load balancing where the processing and communications activity is distributed across several links in a trunk ensuring that no single link is overwhelmed. By taking multiple LAN connections and treating them as a unified, aggregated link, you can achieve higher link availability and increased link capacity
Port Trunking is supported according to the IEEE 802.3ad standard for Link Aggregation as follows:
• Link Aggregation is supported only on links using the IEEE 802.3 MAC
• Link Aggregation is supported only on point-to-point links
• Link Aggregation is supported only on links operating in full duplex mode
• Link Aggregation is permitted only among links with the same speed and direction. On the device bandwidth increments are provided in units of 100Mbps and 1Gbps respectively
• The failure or replacement of a single link within a Link Aggregation Group will not cause failure from the perspective of a MAC client.
MAC Client traffic can be distributed across multiple links. To guarantee the correct ordering of frames at the receiving-end station, all frames belonging to one conversation must be transmitted through the same physical link. The algorithm for assigning frames to a conversation depends on the application environment. Radware devices can define conversations upon Layer 2, 3, or 4 information, or on combined layers. AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 113
Link Aggregation Global Configuration
To perform port trunking on a global AppDirector configuration, you need to follow this procedure.
To configure Link Aggregation Global Configuration 1.From the Device menu, select Link Aggregation > Global Configuration. The Distribution Method window appears.
2.Set the parameters.
3.Click Set. Your configuration is set.
Parameter
Description
Layer 2 For Layer 2: This defines if the MAC address is to be used in traffic distribution algorithm. Select:
• Ignore: Do not use MAC address
• Source Address: Use source MAC address
• Destination Address: Use destination MAC address
• Both Addresses (Default): Use source and destination MAC addresses
Layer 3 For Layer 3: This defines if the IP address is to be used in traffic distribution algorithm. Select: • Ignore: Do not use IP address
• Source Address: Use source IP address
• Destination Address: Use destination IP address
• Both Addresses (Default): Use source and destination IP addresses
Layer 4 For Layer 4: This defines if application port is used in the traffic distribution algorithm. Select:
• Ignore: Do not use application port
• Source Port: Use source application port
• Destination Port: Use destination application port
• Both Ports (Default): Use source and destination application ports. LACP System ID The System Identifier in MAC address format is used together with the LACP System Priority to uniquely identify the system. Default: Device MAC address.
LACP System Priority
The LACP System Priority together with the LACP System ID uniquely identify the system. Maximum value: 256.
AppDirector User Guide
Administering and Monitoring AppDirector
114 Document ID: RDWR-AD-V0231-UG1105
Link Aggregation Trunk Table
The Link Aggregation Trunks Table allows you to configure link aggregation trunks; to configure whether a trunk is static or dynamic (LACP) and to define attached ports.
To configure a Trunk
1.From the Device menu, select Link Aggregation >Trunk Table. The Link Aggregation Trunk Table window appears.
2.Set the parameters.
Parameter
Description
Name Displays the trunk name.
MAC Address Displays the MAC Address assigned to the trunk.
System Priority A 2-octet read-only value indicating the priority value associated with the system.
System ID A 6-octet read-only MAC address value used as a unique identifier for the System that contains this trunk (Aggregator). Status A read-only Boolean value indicating whether the trunk represents an Aggregated ('TRUE') or an Individual link ('FALSE').
• Individual: (False) No ports attached to this trunk.
• Aggregated: (True) Ports attached to this trunk.
Aggregated Port List
List of physical ports that are aggregated in this trunk. LACP Mode LACP can be configured as active, passive or disabled (manual aggregation). In active mode it will always send frames along the configured links. In passive mode however, it acts as "speak when spoken to", and therefore can be used as a way of controlling accidental loops (as long as the other device is in active mode).
Values: • Passive (default)
• Active
• Manual: LACP is disabled and manual aggregation is performed.
Note: When the Actor (AppDirector) does not have a partner (any mode), it acts in Manual (default) mode.
LACP TimeOut Time to wait between LACP control messages (LACPDU). If a period of time equal to three times the selected timeout passes without any new control message the link state changes.
Values: Fast (default): 1 second, Slow: 30 seconds
LACP Wait Time Time to wait after link negotiation before starting to send control messages.
LACP Actor Priority The priority assigned to this trunk by the Actor (the system sending the data unit; assigned by management or administration policy), encoded as an unsigned integer.
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 115
3.When accessing the Aggregated Port List parameter, click.... , the Ports List Arguments window appears.
4.Mark the ports that you need and click Set. You are returned to the Link Aggregation Trunk Table Update window.
5.Click Set. The trunk is configured.
Link Aggregation Trunk Port Table
The Trunk Port Table window allows you view link aggregation status for all device ports.
To view the Link Aggregation Trunk Port Table parameters From the Device menu, select Link Aggregation > Port Table. The Link Aggregation Port Table window appears, showing these parameters.
Notes:
>> The same algorithm must be applied on the other switch in the trunk.
>> OnDemand Switch 1 and VL implement link aggregation via software and not at the switch level, (these platforms do not include a Layer 2 switch hardware component). Therefore, you cannot define trunks as port mirroring participants, on these platforms.
Parameter
Description
Trunk Port Name (Read Only)
The physical port name
Port MAC (Read only) The MAC address assigned to the port.
Trunk Name Trunk to which the port is attached. Values:
• 1-7 (1-4 for OnDemand Switch 3 devices)
• Unattached (Default)
Oper Status Operational Status
Values: • Default, Not-In-Bundle: The LACP control is off (manual aggregation) and this port is not bundled in a trunk.
• Default, Bundled: The LACP control is off (manual aggregation) and this port is bundled in the specified trunk.
• LACP Control, Not-In-Bundle: The LACP control is on but this port is not bundled in a trunk.
• LACP Control, Bundled: The LACP control is off (manual aggregation) and this port is bundled in the specified trunk.
Port Status (Read only) Values:
• Individual: (False) Port is not attached to any trunk.
• Aggregated: (True) The Port is attached to a trunk. AppDirector User Guide
Administering and Monitoring AppDirector
116 Document ID: RDWR-AD-V0231-UG1105
Management Trunk
You can define a management trunk (T-MNG) that only includes the management ports (MNG-1 and MNG-2). The management ports cannot be a part of any other trunk. Using the management trunk provides redundancy at the physical level for connectivity to the management network. One link is active while the other is in backup mode. Failure of the active link seamlessly activates the backup.
Port Mirroring Port Mirroring enables the AppDirector device to duplicate traffic from one physical port on the device to another physical port on the same device. This is useful, for example, when an Intrusion Detection System (IDS) device is connected to one of the ports on the AppDirector device. You can configure port mirroring for received traffic only, for transmitted traffic only, or for both. You can also decide whether to mirror the received broadcast packets.
To set the Port Mirroring parameters 1.From the Device menu select Port Mirroring. The Port Mirroring Table window appears.
2.Click Create. The Port Mirroring Table Create window appears.
3.Set the parameters.I 4.Click Set. Your configuration is set.
Parameter
Description
Input Port The port from which the traffic is mirrored
Output Port The port to which traffic is mirrored.
Receive\Transmit Select the direction of traffic to be mirrored.
• Transmit & Receive (default)
• Receive Only
• Transmit Only
Promiscuous Mode You can either copy all traffic from the input port to the output port or copy only traffic destined for the input port. Values:
• Enabled (default): All traffic is copied to the Output Port.
• Disabled: Only traffic destined to the Input port is copied.
Note: The difference between enable / disable status is the ARP packet. If you set Promiscuous mode to enable, you can receive ARP packets with MAC address FF-FF-FF-FF-FF-FF or you can receive ARP packets without the MAC address FF-FF-
FF-FF-FF-FF.
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 117
Notes:
>> Device Port mirroring is not supported with OnDemand Switch VL or OnDemand Switch 1.
>> OnDemand Switch 2 supports port mirroring of up to 4 ports.
>> For OnDemand Switches 2 and 3, the trunk cannot be a port mirroring destination but can be a source. >> When mirroring traffic from a port which is part of a Switch VLAN, since traffic between hosts on this VLAN is switched by the ASICs of the device, this traffic is not mirrored.
>> When mirroring traffic is received on a physical port, which is part of a Switch VLAN, and if the mirrored port is configured to mirror Received Broadcast packets then these packets are mirrored from all ports on the Switch VLAN.
>> Traffic generated by the device itself, such as Connectivity Checks or management traffic, is not mirrored by Port Mirroring.
>> Using Regular VLAN, traffic with destination multicast MAC is not always mirrored.
>> You can copy traffic from one Input Port to up to two Output Ports, or from many Input Ports into one Output Port.
IP Addressing and Routing
This section discusses configuration of IP addressing and includes the following topics:
• IP Interfaces
, page 118
• ARP Configuration
, page 121
• IPv6 Neighbor Discovery
, page 121
• IP Router Advertisement
, page 123
• R
outing
, page 126
• R
outing Table
, page 127
• N
HRs
, page 128
• VIP NHR
, page 129
• Routing Information Protocol
, page 130
• Open Shortest Path First (
OSPF)
, page 132
• Border Gateway Protocol
, page 138
AppDirector User Guide
Administering and Monitoring AppDirector
118 Document ID: RDWR-AD-V0231-UG1105
IP Interfaces
An IP interface on AppDirector is an IP address associated with a layer 2 interface (physical port, VLAN or trunk). The IP interface prefix length/netmask defines the subnet attached to that layer 2 interface.
The IP interfaces serve different purposes:
• Allows AppDirector to select the layer 2 interface via which traffic sent from the device must be sent
• Serves as source address for traffic initiated by AppDirector (for management purposes, proprietary protocols between AppDirector devices, Health checks, etc.)
• Serves as default route for hosts in the attached subnet. However Radware recommends that in redundant configurations Virtual IP interfaces are used as default route. • Serves as primary IP for Virtual Routers (VRRP). Radware recommends that Virtual IP interfaces are used as primary IP. For Virtual IP interface configuration.
AppDirector performs routing between the subnets defined by the IP interfaces.
Note:AppDirector supports both IPv4 and IPv6 IP interfaces.
Link-local address
Link-local addresses are network addresses which are intended only for communications within one segment of a local network (a link) or a point-to-point connection. They allow addressing hosts without using a globally-routable address prefix. Routers will not forward packets with link-local addresses.
Link-local addresses are often used for network address configuration when no external source of network addressing information is available. This addressing is accomplished by the host operating system using a process known as stateless address autoconfiguration. This is possible in both IPv4 and IPv6.
IPv4 addresses in the range 169.254.0.0/16 are assigned automatically by a host operating system when no other IP addressing assignment is available, for example, from a DHCP server. In IPv6, link-
local addresses are required and are automatically chosen with the FE80::/10 prefix.
To show LLA entries
1.From the Router menu select IP Router > IP Interfaces. The IP Interface Table window appears.
2.Select Show LLA entries, and set to Enabled/Disabled (default).
3.Click Set. This is now configured.
The IP Interface Table window enables you to configure all the IP Interface parameters. To configure an IP Interface 1.From the Router menu select IP Router > IP Interfaces. The IP Interface Table window appears.
2.Select the IP Address, the IP Interface Table Update window appears.
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 119
3.Set the parameters.
Parameter
Description
IP Address IP address of the interface. IP address to which this entry's addressing information pertains.
IF Number Interface identifier of the Layer 2 interface. Address Origin (Read Only) The origin of the address. Values:
• other: can include a random chosen address or well-known value for example, an IANA assigned anycast address. • manual (default): indicates that the address was manually configured.
• dhcp: indicates an address that was assigned to this system by a DHCP server.
• linklayer: indicates an address created by IPv6 stateless autoconfiguration.
Status (Read Only) Current status of IP interface.
Values:
• Preferred: this is a valid address that can appear as the destination or source address of the packet.
• Deprecated: indicates that this is a valid but deprecated address that should no longer be used as a source address in new communications, but packets addressed to such an address are processed as expected.
• Invalid: indicates that this is not valid address which should not appear as the destination or source address of a packet.
• Inaccessible: indicates that the address is not accessible because the interface to which this address is assigned is not operational.
• Unknown: Unknown
• Tentative: indicates the uniqueness of the address on the link is being verified. • Duplicate: indicates the address has been determined to be non-unique on the link and so must not be used.
• Optimistic: indicates that this is available for use, subject to restrictions, while its uniqueness on a link is being verified. It is designed to minimize address configuration delays and to reduce disruption. Prefix (Read Only) Prefix attached to the IP address.
AppDirector User Guide
Administering and Monitoring AppDirector
120 Document ID: RDWR-AD-V0231-UG1105
4.Click Set. Your configuration is set.
Prefix Length Sets the prefix length that defines the subnet attached to this IP interface. • For IPv4: Prefix length varies between subnets to subnets, and it can cause painful costs when renumbering subnets. With IPv4, the allocation varies by the size of the site, and this can be a problem when you migrate from one ISP to another.
Values: 0 - 32 • For IPv6: This is a decimal value that indicates the number of contiguous, higher-order bits of the address that make up the network portion of the address. For example, 10FA:6604:8136:6502::/64 is a possible IPv6 prefix.
The prefix length for an IPv6 subnet will always be <64. It allows you to place as many IPv6 devices as the underlying network medium allows.
Values: 0 - 64
Prefix Onlink Flag (Relevant for IPv6 interfaces) The prefix list in the Neighbor Discovery cache table defines a set of IP address ranges that the host can reach. The prefix flags are L for on-link, and A for autonomous. The on-link flag indicates that addresses with that prefix can be reached directly without going through a router. Values: True/False
Prefix Autonomous Flag
(Relevant for IPv6 interfaces) The prefix list in the Neighbor Discovery cache table defines a set of IP address ranges that the host can reach. The prefix flags are L for on-link, and A for autonomous. The autonomous flag indicates that the prefix came from stateless autoconfiguration.
Values: True/False
Preferred Lifetime Router advertisement preferred life time
Valid Lifetime Router advertisement valid life time.
Fwd Broadcast Forward Broadcast. This parameter decides whether the device forwards incoming broadcasts to this interface.enabledisable This variable controls forwarding of IP (sub)net-directed broadcasts destined for an attached sub(net).
Broadcast Addr Indicates how host part of ip subnet broadcast messages will be filled: • Zero Fill - host part will be filled by 0 • One Fill - host part will be filled by 1
VLAN Tag When multiple VLANs are associated with the same switch port, the switch needs to identify to which VLAN to direct incoming traffic from that specific port. VLAN tagging provides an indication in the Layer 2 header, which enables the switch to make the correct decision. Enter the Tag to be associated with this IP Interface.
Peer IP Address The IP address for the same layer 2 interface on the redundancy peer device. This is mandatory if you want to synchronize configuration between main and backup devices.
Parameter
Description
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 121
ARP Configuration
The Address Resolution Protocol (ARP) is a computer networking protocol for determining a network host's link layer or hardware address when only its Internet Layer (IP) or Network Layer address is known. The ARP table window allows you to monitor, set and edit ARP addresses on the local router. Under IPv6, ARP's functionality is provided by the Neighbor Discovery Protocol (NDP), see IPv6 Neighbor Discovery
, page 121
.
To access the ARP Table 1.From the Router menu, select ARP Table. The ARP Table window appears.
2.Set the parameters. 3.Click Set. Your configuration is set.
IPv6 Neighbor Discovery
IPv6 Neighbor Discovery (NDisc) is a set of messages and processes that determine relationships between neighboring nodes. NDisc replaces Address Resolution Protocol (ARP), Internet Control Message Protocol (ICMP) Router Discovery, and ICMP Redirect, which are used in IPv4, and provides additional functionality. NDisc is described in RFC 2461, "Neighbor Discovery for IP Version 6 (IPv6)."
NDisc is used by routers to:
• Advertise their presence, host configuration parameters, and on-link prefixes. • Inform hosts of a better next-hop address to forward packets for a specific destination. NDisc is used by nodes to:
• Both resolve the link-layer address of a neighboring node to which an IPv6 packet is being forwarded and determine when the link-layer address of a neighboring node has changed. • Determine whether IPv6 packets can be sent to and received from a neighbor. Neighbor Cache
The neighbor cache keeps track of the neighbors on the local links with which AppDirector is in contact - it is the IPv6 parallel of the ARP table. The neighbors are either dynamically discovered using neighbor discovery protocol or statically configured. Parameter
Description
Interface Index The interface number where the station resides.
IP Address The station's IP address.
MAC Address The station's MAC address.
Type Entry type:
• Dynamic: Entry is learned from ARP protocol. If it is not active for a predetermined time, the node is deleted from the table.
• Static: Entry has been configured by the network management station and is permanent. AppDirector User Guide
Administering and Monitoring AppDirector
122 Document ID: RDWR-AD-V0231-UG1105
To create a Neighbor Cache entry
1.From the Router menu, select IPv6 Neighbor Discovery > Neighbor Cache. The Neighbor Cache window appears.
2.Click Create.
3.Set the parameters.
4.Click Set. Your configuration is set.
Duplicate Address Detection
Duplicate Address Detection (DAD) is the process by which a node determines that an IPv6 address considered for use is not already in use by a neighboring node (equivalent to the use of gratuitous ARP frames in IPv4). The DAD process consists of sending a neighbor discovery whenever the device is assigned a new IP address, asking for a neighbor with the same address. The device performs the DAD procedure for each newly configured IPv6 address: IP interface, VIP, VIPI and client NAT addresses belonging to a subnet configured on the device (matching IP interface). DAD is not performed for VIP, VIPIs and client NAT addresses that do not have a matching IP interface, (orphan addresses).
DAD is also performed per all configured IP addresses (IP interfaces, non-orphan VIPs, VIPIs and client NAT addresses) on device startup.
Parameter
Description
Interface Index Interface identifier for neighbor cache entry.
MAC Address MAC address corresponding to neighboring node’s IPv6 address.
IP Address Neighboring node’s IPv6 address.
Type (Read Only) State of the neighbor cache entry.
Values: Other, Invalid, Dynamic, Static, Local State The number of times this neighbor relationship has changed state, or an error has occurred.
Values:
• Reachable
• Stale
• Delay
• Probe
• Invalid
• Unknown
• Incomplete
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 123
To perform Duplicate Address Detection
1.From the Router menu, select IPv6 Neighbor Discovery > Duplicate Address Detection. The Duplicate Address Detection window appears.
2.Set the parameter.
3.Click Set. Your configuration is set.
IP Router Advertisement
Before a host can really participate on an internetwork, it needs to know the identity of at least one router on the local network. One way to ensure that this is the case is to just manually configure each host with the address of a local router as its default router. This method is simple, but has the typical drawbacks associated with manual processes, it is time-consuming to set up, difficult to maintain, and inflexible.
The Router Discovery Process For this purpose, a method was devised whereby a host could automatically discover the identity of local routers, and learn important information about them. In IP, this process is called router discovery, and was first defined in RFC 1256, ICMP Router Discovery Messages. Routers are responsible for sending Router Advertisement messages. These messages tell listening devices that the router exists, and provide important information about the router such as its address (or addresses, if it has more than one) and how long the host should retain information about the router. IPv4 Router Advertisement
ICMP Internet Router Discovery Protocol (IRDP) uses Internet Control Message Protocol (ICMP) router advertisements and router solicitation messages to allow a host to discover the addresses of operational routers on the subnet. Each router periodically multicasts a router advertisement from each of its multicast interfaces, announcing the IP address of that interface. Hosts listen for advertisements to discover the addresses of their neighboring routers. When a host starts, it can send a multicast router solicitation to ask for immediate advertisements.
Parameter
Description
Retransmits number Enables the DAD process and determines the number of times that the DAD Neighbor discovery message is transmitted, where value of zero means DAD is disabled.
AppDirector User Guide
Administering and Monitoring AppDirector
124 Document ID: RDWR-AD-V0231-UG1105
To configure IPv4 Router Advertisement
1.From the Router menu select IPv4 Router Advertisement. The IPv4 Router Advertisement Update window appears.
2.Set the parameters.
3.Click Set. Your configuration is set. IPv6 Router Advertisement
With IPv6, routers can be dynamically discovered and adopted as default gateways by the host nodes on the same local link, rather than having to statically configure the default gateway and change it on every network restructure. This process also allows the node to automatically assign its own global Unicast IP address, by having the router publish a prefix for the subnet to be attached to the host's link local address. This is called stateless auto-configuration and comes as an alternative to DHCP which is stateful, because it has to keep record of the assigned IP address. Nevertheless, DNS server addresses must be still obtained from DHCP servers, but this does not incur state maintenance.
This feature periodically sends Router Advertisements per each IP interface according to randomized periods. It also sends these messages in response to Router Solicitation messages.
Parameter
Description
IP Address IP address of the interface. Advert Address IP destination address for multicast Router Advertisements sent from the interface. Values are:
• all-systems multicast address, 224.0.0.1
• limited-broadcast address, 255.255.255.255
Max Advert. Interval
Maximum time in seconds between multicast Router Advertisements from the interface. Values: From Minimum Advert Interval defined below to 1800 seconds.
Min Advert. Interval
Minimum time (seconds) between sending unsolicited multicast Router Advertisements from the interface. Values are between 3 seconds and the maximum interval defined above. Default: 0.75 of the Maximum Interval.
Advert. Lifetime Maximum time (seconds) that the advertised addresses are considered valid. This must be no less than Maximum Interval as defined above, and no greater than 9000 seconds. Default: 3 times the Maximum Advert Interval.
Advertise Enables you to advertise the device IP using ICMP Router Advertise.
Preference Level Preferability of address as default router address, relative to other router addresses on same subnet.
Reset to Defaults Resets ICMP interface parameters to default values.
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 125
To configure IPv6 Router Advertisement
1.From the Router menu, select IPv6 Neighbor Discovery > IPv6 Router Advertisement. The IPv6 Router Advertisement window appears.
2.Set the parameters.
3.Click Set. Your configuration is set.
Parameter
Description
Interface Index Flag indicating weather the interface sends Router Advertisements messages
Max RA Interval The maximum amount of time between Router Advertisements sent by this router. The default is 10 minutes. Router Advertisements are sent at a random interval between the minimum and maximum times.
Managed Address Config Flag Solicitations to the all-routers multicast group. Router Advertisements contain two flags indicating what type of stateful autoconfiguration (if any) should be performed. A "managed address configuration" flag indicates whether hosts should use stateful autoconfiguration to obtain addresses. MTU Maximum Transmission Unit is the largest physical packet size measured in bytes that a network can transmit. Any messages larger than the MTU are divided into smaller packets before being sent. Retransmit Time Advertised retransmit time (delay) between sending one neighbor discovery (solicitation) and the next.
The time between retransmissions of neighbor solicitations to a neighbor when resolving the address or when probing the reachability of a neighbor. (read only).</
Default Router Lifetime Time, in minutes, after which a host considers a router down (after it has received its last Router Advertisement). Default: x minutes.
Send RA Messages Instructs router to send router advertisement messages.
Min RA Interval The minimum amount of time between Router Advertisements sent by this router. Suggested value for this timer is 30 seconds.
Other Config Flag An "other stateful configuration" flag indicates whether hosts should use stateful autoconfiguration to obtain additional information (excluding addresses).
Reachable Time Specifies the amount of time that the router can reach a remote IPv6 node (neighbor) after some reachability confirmation event has occurred. Current Hop Limit IPv6 router current advertised hop limit.
AppDirector User Guide
Administering and Monitoring AppDirector
126 Document ID: RDWR-AD-V0231-UG1105
Routing
Routing is the ability to forward IP packets to their Destination using an IP Routing Table. This table stores information about the Destinations and how they can be reached. By default, all networks directly attached to AppDirector are registered in the IP Routing Table. Other entries can either be statically configured or dynamically created through the routing protocol. AppDirector forwards IP packets to their destination using an IP Routing Table. This table stores information about the destinations and how they can be reached. By default, all networks directly attached to AppDirector are registered in the IP Routing Table. Other entries can either be statically configured or dynamically created through the routing protocol. • When AppDirector forwards an IP packet, the IP Routing Table is used to determine the 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.
IP Router Operating Parameters
The IP Router Parameters window allows you to monitor, add and edit router settings.
To access the IP Router Parameters window 1.From the Router menu, select IP Router > Operating Parameters. The Adjusting Operating Parameters window appears.
2.Set the parameters.
3.Click Set. Your configuration is set. Parameter
Description
Inactive ARP Timeout
This variable defines the maximum time period (in second) that can pass between ARP requests concerning an entry in the ARP table. After this time period, the entry is deleted from the table.
Values: 11 seconds minimum. Default: 3600 seconds (60minutes = 1 hour)
ICMP Error Messages
The Internet Control Message Protocol (ICMP) is one of the core protocols of the Internet Protocol Suite and is used by networked computers' operating systems to send error messages—indicating, for instance, that a requested service is not available or that a host or router could not be reached.
Values: Enable (Default), Disable ICMP Error Rate Limit This limits the rate at which IPv4 ICMP error messages are sent. Default: 32
ICMP Error Burst Limit Maximum icmp error messages emitted n a single burst (in packets).
Default: 64
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 127
Routing Table
AppDirector supports IP routing along with the dynamic addition and deletion of IP interfaces. This ensures that extremely low latency is maintained. The IP router supports RIP 1, RIP 2, and OSPF routing protocols OSPF and its MIB are supported as specified in RFC 1583 and RFC 1850, with some limitations. The Routing Table allows you to configure static routing and define the default gateway.
To configure static routes
1.From the Router menu, select Routing Table. The Routing Table window appears.
2.Set the parameters. Parameter
Description
Destination Address
Destination network to which the route is defined.
Prefix Length Sets the prefix length that defines the subnet attached to this IP interface. • For IPv4: Prefix length varies between subnets to subnets, and it can cause painful costs when renumbering subnets. With IPv4, the allocation varies by the size of the site, and this can be a problem when you migrate from one ISP to another.
Values: 0 - 32 • For IPv6: This is a decimal value that indicates the number of contiguous, higher-order bits of the address that make up the network portion of the address. For example, 10FA:6604:8136:6502::/64 is a possible IPv6 prefix.
The prefix length for an IPv6 subnet will always be <64. It allows you to place as many IPv6 devices as the underlying network medium allows.
Values: 0 - 64
Next Hop IP address of next hop towards Destination subnet. Next hop must reside on subnet local to the device.
Metric Number of hops to the Destination network.
AppDirector User Guide
Administering and Monitoring AppDirector
128 Document ID: RDWR-AD-V0231-UG1105
3.Click Set. Your configuration is set.
NHRs Each host or router handling a packet examines the Destination Address in the IP header, computes the next hop that will bring the packet one step closer to its destination, and delivers the packet to the next hop, where the process is repeated. A Next Hop Router (NHR) is a network element used for outbound traffic in AppDirector Multi Homing configurations. NAT addresses can be associated with Next Hop Routers (NHRs), similar to the way VIPs are associated with NHRs. The NHR Table window enables you to list the device's next hop routers.
To access the NHR Table 1.From the Router menu, select NHR Table. The NHR Table window appears.
2.Set the parameters.
Type (Update Only)
Type of route. Each routing table can contain an arbitrary number of route entries. Aside from the local routing table, which is maintained by the kernel, and the main routing table which is partially maintained by the kernel, all routing tables are controlled by the administrator or routing software. All routes on a machine can be changed or removed. Each route type causes a particular behavior described below. Values:
• Other types of routes including:
unicast, broadcast, prohibit, blackhole, throw
• Remote (Forwards packets) - refers to a route for which the next hop is not the final destination. Routes which do not result in traffic forwarding or rejection should not be displayed even if the implementation keeps them stored internally
• Reject (Discards packets) - refers to a route which, if matched, discards the message as unreachable. This is used in some protocols as a means of correctly aggregating routes
• Local (Read-only) - refers to a route for which the next hop is the final destination
Protocol (Update Only)
Type of Protocol:
Values:
Local
Interface Index Interface Index number for the dedicated management port or trunk through which the next hop of this route is reached.
Parameter
Description
NHR IP Address IP address of required NHR (next hop router). NHR MAC Address MAC address of the NHR.
Device MAC Address
MAC address of the device. Parameter
Description
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 129
3.For creating new NHR Table entries, click Create. The NHR Table Create window appears as above without NHR MAC Address, Device MAC Address, Port Number and Oper Status.
4.Click Set. Your configuration is set.
Setting Up Default Router Per VIP
All Next-Hop Routers connected to AppDirector are defined in the NHR table. NHRs are associated with the Virtual IP addresses of the device using the VIP NHR table. The VIP NHR table is enabled only when the packet is destined for the default gateway of the box. Due to the static route, the packet was not destined for the default gateway so in these instances the VIP NHR table is not enabled. The NHR per VIP feature works only for traffic that matches the device's default gateway.
Before defining the VIP NHR, add a new NHR to the network and set up the general NHR parameters
VIP NHR The VIP NHR window enables you to associate a next hop router, configured in the NHR Table, to a virtual IP address configured on the device.
To access the Virtual IP Table 1.From the Router menu, select VIP NHR Table. The VIP NHR Table window appears,.
2.Set the parameters.
Admin Status Administration status of the NHR, Enable or Disable.
Port Number Displays the number of the selected management port. Oper Status In Service/ Not In Service Path Health Check IP
IP address of network element to be checked via this NHR to establish the health status of this router.
Check Method Method that device uses to verify the NHR's health.
Values: Ping, Disable, Health Monitoring Module
Check Interval Interval, in seconds, between checks.
Check Retries Amount of checks that the device should perform without reply before it acknowledges that router is off line.
Parameter
Description
Virtual IP Address Required Virtual IP address. NHR IP Address IP address of the required next hop router.
Parameter
Description
AppDirector User Guide
Administering and Monitoring AppDirector
130 Document ID: RDWR-AD-V0231-UG1105
3.Click Set. The Virtual IP address is associated with the relevant NHR.
Routing Information Protocol
Routing Information Protocol (RIP) is a commonly-used protocol for managing router information within a self-contained network, such as a corporate Local Area Network (LAN) or an interconnected group of such LANs. RIP is classified by the Internet Engineering Task Force (IETF) as one of several internal gateway protocols (Interior Gateway Protocol). RIP is intended for small homogeneous networks.
Using RIP, a gateway host (with a router) sends its entire Routing Table, which lists all the other hosts that it recognizes, to its closest neighbor host every 30 seconds. RIP uses a hop count 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. The neighbor host then passes the information on to its next available neighbor until all hosts within the network have the same knowledge of the routing paths. This is known as Network Convergence. AppDirector supports RIP version 1 and RIP version 2. The RIP protocol is configured from the RIP Parameters window.
VIP Advertising via Dynamic Routing enables you to achieve a redundant solution by using a single AppDirector on each site, or by using a single AppDirector and a remote backup server within the RIP or OSPF environment. No Route Action Determines action if both primary and backup next hop routers are offline. Values:
• Discard: The packets are discarded.
• Use Regular Routing: Packets are forwarded using the Routing Table.
NHR Weight Determines relative amount of total traffic forwarded to the primary router when Load Sharing is enabled.
Backup NHR Weight
Determines relative amount of total traffic forwarded to backup router when Load Sharing enabled.
Backup NHR IP Address
IP address of the backup next hop router.
NHR Load Sharing Enable/disable load sharing between primary and backup next hop routers, based on relative weights.
• Layer 3 Hashing: Traffic sent through both configured and backup NHR. Load sharing is based on Layer 3 information (IP address).
• Layer 4 Hashing: Traffic sent through both configured and backup NHR. Load sharing is based on Layer 4 information (IP address and port).
• Disabled (Default): Traffic sent via configured NHR only.
Parameter
Description
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 131
To configure the RIP Parameters 1.From the Router menu, select RIP > Parameters. The RIP Parameters window appears.
2.Set the parameters.
3.Click Set. Your configuration is set.
RIP Interface Parameters
This table window allows you to set and edit RIP interface parameters. To access the RIP Interface 1.From the Router menu, select RIP > Interface Parameters. The RIP Interface Parameters window appears.
2.Set the parameters.
Parameter
Description
Administrative Status
Administrative status of RIP in the router. Disabled (default) means the process is not active on any interfaces.
Leak OSPF Routes This controls leaking (redistribution) of routes from OSPF to RIP. If enabled, all routes learned via OSPF are advertised into RIP.
Default: Enable
RIP Advertisement Interval [seconds] AppDirector sends static routes advertisements via RIP. Default: 30 seconds. Leak Static Routes Controls redistribution of routes from static routes to RIP. When enabled, all static routes learned via static are advertised into RIP. Default: Disable
Parameter
Description
IP Address The IP Address of this system on the indicated subnet. (Read Only when updating)
Incoming RIP Define type of RIP to be received.
• RIP 1: Accepting RIP 1.
• RIP 2: Accepting RIP 2.
• Do Not Receive: No RIP updates are accepted.
Status on/off
Outgoing RIP Define type of RIP to be sent.
• RIP version 1: Sending RIP updates compliant with RFC 1058.
• RIP version 2: Multicasting RIP-2 updates.
• Do Not Send: No RIP updates are sent.
AppDirector User Guide
Administering and Monitoring AppDirector
132 Document ID: RDWR-AD-V0231-UG1105
3.Click Set. The changes are reflected in the RIP Interface Table list. To Update the RIP Interface 1.From the Router menu, select RIP > Interface Parameters. The RIP Interface Parameters window appears, which contains the above parameters plus those displayed here.
2.Set the parameters.
3.Click Set. The changes are reflected in the RIP Interface Table list. Open Shortest Path First (OSPF)
Open Shortest Path First (OSPF) is an interior gateway routing protocol developed for IP networks and based on the shortest path first or linkstate algorithm. Routers use link-state algorithms to send routing information to all nodes in a network by calculating the shortest path to each node based on a topography of the Internet constructed by each node. After sending the routing information, each router sends the portion of the routing table (keeping track of routers to particular network destinations) that describes the state of its own links, and sending the complete routing structure (topography).Shortest path first algorithms allow you to perform more frequent updates.
With OSPF you can build a more stable network, as fast convergence prevents routing loops and Count-to-Infinity (when routers continuously increment the hop count to a particular network).
Default Metric Metric for default route entry in RIP updates originated on this interface. 0 (Zero) indicates that no default route can be originated; here, a default route through another router is propagated.
Virtual Distance Virtual number of hops assigned to the interface. This enables fine-
tuning of the RIP routing algorithm.
Auto Send Enable to minimize traffic when AppDirector is the only router on the network.
Note: When enabled, the device advertises RIP messages with the default metric only. This allows some stations to learn the default router address. If the device detects another RIP message, Auto Send is disabled.
Parameter
Description
Virtual Distance Virtual number of hops assigned to the interface. This enables fine-
tuning of the RIP routing algorithm.
Auto Send Enable this option to minimize network traffic when AppDirector is the only router on the network.
Note: When enabled, the device advertises RIP messages with the default metric only. This allows some stations to learn the default router address. If the device detects another RIP message, Auto Send is disabled.
Parameter
Description
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 133
OSPF Operating Parameters
To set the OSPF Operating Parameters 1.From the Router menu select OSPF > Operating Parameters. The OSPF Operating Parameters window appears.
2.Set the parameters.
3.Click Set. Your configuration is set.
OSPF Interface Parameters
The OSPF Interface Parameters window enables you to update OSPF Interface Parameters and Metrics.
To update the OSPF Interface Parameters 1.From the Router menu select OSPF > Interface Parameters. The OSPF Interface Parameters window appears.
2.Select the IP Interface. The OSPF Interface Table Update window appears.
3.Set the parameters.
Parameter
Description
Administrative Status
OSPF administrative status in the router. • Enabled: OSPF process is active on at least one interface. • Disabled: OSPF process is not active on any interfaces.
Router ID ID number of router. To ensure uniqueness the router ID should equal one of the router IP addresses. Leak RIP Routes Controls the redistribution of routes from RIP into OSPF. When this parameter is enabled, all routes inserted into the IP routing table via SNMP are advertised into OSPF as external routes.
Leak Static Routes Controls redistribution of routes from static routes to RIP. When enabled, all static routes learned via static are advertised into RIP.
Leak External Direct Routes
Controls redistribution of direct routes external to OSPF into OSPF. If enabled, all external routes are advertised into OSPF as external.
Age old link state This defines whether to update neighbors by aging the old link state before sending the new state. This parameter controls if the OSPF module will send premature aging packets when updating the link state.
Parameter
Description
IP Address IP Address of this OSPF interface.
AppDirector User Guide
Administering and Monitoring AppDirector
134 Document ID: RDWR-AD-V0231-UG1105
4.Click Set. Your configuration is set.
Interface Type OSPF interface type. Broadcast LANs are broadcast type, x.25 and Frame Relay are NBMA type, and point-to-point LANs are Point to Point type.
Administrative Status
Administrative status of the OSPF in the router. Enabled means that the OSPF process is active on at least one interface. Disabled means the process is not active on any interfaces.
IfRtrPriority Priority of this interface. Value 0 means that this router is not eligible to become the designated router on the current network. If more than one router has the same priority then router ID is used.
Hello Interval Number of seconds between Hello packets. All routers attached to a common network must have the same Hello Interval.
RtrDeadInterval Number of seconds router's Hello packets have not been seen before router's neighbors declare the router down. The Time Before Declare Router Dead value must be a multiple of the Hello Interval. All routers attached to a common network must have a Time Before Declare Router Dead value.
Interface State The interface state of the OSPF interface:
• Down: OSPF interface is down.
• Waiting: OSPF interface is currently waiting.
• Point to Point: OSPF interface is in point to point state.
• Designated Router: OSPF interface is the designated router.
• Backup Designated Router: OSPF interface is the backup designated router.
Designated Route Address of designated router, if Interface state is Designated Router.
Backup Designated Router
Address of the backup designated router, in case Interface state is Backup Designated Router.
IfAuthKey Authentication key for the interface.
AuthType Type of authentication key for the interface.
Parameter
Description
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 135
OSPF Interface Metrics Table Update If you wish to update the metrics for the OSPF interface, use this feature.
To update the OSPF Interface Metrics
1.Select the OSPF interface. The OSPF Interface Metrics Table Update window appears.
2.Reset the Metric value parameters.
Parameter
Description
IP Address IP Address of this OSPF interface.
Metric Metric of using this type of service on this interface. The default value of the TOS 0 Metric is 10.
Parameter
Description
IP Address IP Address of this OSPF interface.
Interface Type OSPF interface type. Broadcast LANs are broadcast type, x.25 and Frame Relay are NBMA type, and point-to-point LANs are Point to Point type.
Administrative Status
Administrative status of the OSPF in the router. Enabled means that the OSPF process is active on at least one interface. Disabled means the process is not active on any interfaces.
IfRtrPriority Priority of this interface. Value 0 means that this router is not eligible to become the designated router on the current network. If more than one router has the same priority then router ID is used.
Hello Interval Number of seconds between Hello packets. All routers attached to a common network must have the same Hello Interval.
RtrDeadInterval Number of seconds router's Hello packets have not been seen before router's neighbors declare the router down. The Time Before Declare Router Dead value must be a multiple of the Hello Interval. All routers attached to a common network must have a Time Before Declare Router Dead value.
Interface State The interface state of the OSPF interface:
• Down: OSPF interface is down.
• Waiting: OSPF interface is currently waiting.
• Point to Point: OSPF interface is in point to point state.
• Designated Router: OSPF interface is the designated router.
• Backup Designated Router: OSPF interface is the backup designated router.
Designated Route Address of designated router, if Interface state is Designated Router.
Backup Designated Router
Address of the backup designated router, in case Interface state is Backup Designated Router.
AppDirector User Guide
Administering and Monitoring AppDirector
136 Document ID: RDWR-AD-V0231-UG1105
3.Click Set. Your configuration is recorded.
OSPF Area Parameters
An OSPF network is divided into areas, which have 32-bit area identifiers commonly, but not always, written in the dotted decimal format of an IP address. Area identifiers are not IP addresses and may duplicate, without conflict, any IP address. The OSPF Area Parameters window allows you to access, create and update OSPF area parameters.
To access OSPF Area Parameters 1.From the Router menu, select OSPF > Area Parameters. The OSPF Area Parameters Table window appears.
2.Set the parameters.
3.When updating Area Parameters, in the OSPF Area Parameters Table window, select the Area ID.
4.When creating Area Parameters, in the OSPF Area Parameters Table window, select Create.
5.Click Set. Your changes are recorded.
OSPF Link State Database
OSPF uses both unicast and multicast to send Hello packets and link state updates. The OSPF Link State Database window allows you to access, create and update the OSPF Link State Database.
OSPF detects changes in the topology, such as link failures, very quickly and converges on a new loop-free routing structure within seconds. For this, each OSPF router collects link-state information to construct the entire network topology of so-called "areas" from which it computes the shortest IfAuthKey Authentication key for the interface.
AuthType Type of authentication key for the interface.
Parameter
Description
Area ID IP address of the area.
Import AS Extern Ability to import autonomous system external link advertisements. Values: importExternal, importNoteExternal
Number of AS Border Routers
(Update only)
Total number of Autonomous System border routers reachable within this area. This is initially 0 and calculated in each SPF pass.
Area LSA Count
(Update only)
Number of internal link-state advertisements in the link-state database.
Area LSA Checksum Sum
(Update only)
Sum of LS checksums of internal LS advertisements contained in the LS database. Use this sum to determine if there has been a change in a router's LS database, and to compare the LS database of two routers.
Parameter
Description
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 137
path tree for each route. The link-state information is maintained on each router as a link-state database (LSDB) which is a tree-image of the network topology. Identical copies of the LSDB are periodically updated through flooding on all routers in each OSPF-aware area.
To access OSPF Link State Database 1.From the Router menu, select OSPF > Link State Database. The OSPF Link State Database window appears.
2.Set the parameters.
3.When updating Link State Database, in the OSPF Link State Database window, select the Area ID .
4.When creating Link State Database, in the OSPF Link State Database window, select Create .
5.Click Set. Your configuration is set.
OSPF Neighbor Table
As a link state routing protocol, OSPF establishes and maintains neighbor relationships to exchange routing updates with other routers. The neighbor relationship table is called an adjacency database in OSPF. If OSPF is configured correctly, it forms neighbor relationships only with directly connected routers. These routers must be in the same area as the interface to form a neighbor relationship. An interface can only belong to a single area. This table allows you to access, create and update OSPF Neighbor parameters.
To access OSPF Neighbor Table 1.From the Router menu, select OSPF > Neighbor Table. The OSPF Neighbor Table window appears.
2.You can view the following parameters.
Parameter
Description
Area ID IP address of the area.
Type Each link state advertisement has a specific format. The link can be a Router Link, Network Link, External Link, Summary Link or Stub Link.
Link State ID Identifies a piece of routing domain described by the advertisement. It can be a router ID or an IP address.
Router ID Identifies the originating router in autonomous system.
Sequence Number for link. Use this to detect old and duplicate link state advertisements. The larger the sequence number the more recent the advertisement.
Parameter
Description
Neighbor's Address The IP address that this neighbor is using in its IP Source Address. Note: On addressless links, this will not be 0.0.0.0, but the address of another of the neighbor's interfaces.
AppDirector User Guide
Administering and Monitoring AppDirector
138 Document ID: RDWR-AD-V0231-UG1105
3.When updating OSPF Neighbor Table , in the OSPF Neighbor Table window, select the Neighbor’s Address.
4.When creating OSPF Neighbor Table, in the OSPF Neighbor Table window, select Create.
5.Click Set. Your configuration is set.
Border Gateway Protocol The Border Gateway Protocol (BGP) is the core routing protocol of the Internet. It works by maintaining a table of IP networks or 'prefixes' which designate network reachability among autonomous systems (AS). It is described as a path vector protocol. BGP does not use traditional Interior Gateway Protocol (IGP) metrics, but makes routing decisions based on path, network policies and/or rulesets.
Most Internet users do not use BGP directly. However, since most Internet service providers must use BGP to establish routing between one another (especially if they are multihomed), it is one of the most important protocols of the Internet. Very large private IP networks use BGP internally. An example would be the joining of a number of large Open Shortest Path First (OSPF) networks where OSPF by itself would not scale to size. Another reason to use BGP is Multihoming, (<blue>page 7-392),a network for better redundancy either to multiple access points of a single ISP or to multiple ISPs.
BGP Router Parameters
Dynamic routing protocols, such as Border Gateway Protocol, announce and distribute routing information between routers. AppDirector provides a redundant solution by using AppDirector and a remote backup server that participate in the BGP environment. AppDirector works as a BGP peer, supporting a single BGP instance (local AS), and does not route traffic based on BGP information. From the BGP Route Injection Parameters window the BGP Router Parameters can be set.
To set BGP Router Parameters 1.From the Router menu select BGP Route Injection > Router BGP Parameters. The Router BGP Parameters window appears.
2.Set the parameters.
Address Less Index If interface is without an IP address, index appears in this field. If there is an IP address, 0 appears.
Router ID Unique identifier for neighboring router in the autonomous system.
Options A bit mask corresponding to the neighbor's options. Priority Priority of this neighbor. Priority of 0 means neighbor cannot become designated router on the network.
Parameter
Description
BGP Admin Status Allows administrators to enable or disable the BGP. Local Autonomous System Number
Defines AppDirector's Autonomous System number.
Parameter
Description
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 139
3.Click Set. Your configuration is set.
BGP Peer Groups
The major benefit you achieve when you specify a BGP peer group is that a BGP peer group reduces the amount of system resources (CPU and memory) necessary in an update generation. In addition, a BGP peer group also simplifies the BGP configuration. A BGP peer group reduces the load on system resources by allowing the routing table to be checked only once, and updates to be replicated to all peer group members instead of being done individually for each peer in the peer group. Based on the number of peer group members, the number of prefixes in the table, and the number of prefixes advertised, this can significantly reduce the load. It is recommended that you group together peers with identical outbound announcement policies.
You can group BGP neighbors who share the same outbound policies together in what is called a BGP peer group. Instead of configuring each neighbor with the same policy individually, a peer group allows you to group the policies which can be applied to individual peers thus making efficient update calculation along with simplified configuration.
Peer groups have these requirements:
• All members of a peer group must share identical outbound announcement policies (such as distribute-list, filter-list, and route-map), except for default-originate, which is handled on a per-
peer basis even for peer group members.
• You can customize the inbound update policy for any member of a peer group.
• A peer group must be either internal (with internal BGP (iBGP) members) or external (with external BGP (eBGP) members). Members of an external peer group have different autonomous system (AS) numbers.
Note:The total number of BGP peers and the configurable limit and the maximum number of established BGP peers that are supported on a router depends on many variables, such as:
>> Total number of routes in the BGP table
>> Level of stability of the routes
>> Number of routes sent to each peer
>> Similarity between routes sent to different neighbors
>> Devices available memory and processor power
Peer Table
BGP neighbors, or peers, are established by manual configuration between routers to create a TCP session on port 179. A BGP speaker will periodically send 19-byte keep-alive messages to maintain the connection (every 60 seconds by default). Among routing protocols, BGP is unique in using TCP as its transport protocol.
The BGP Peer Table reflects information about BGP peer connections, such as their status and current activity. Initial BGP connection delay
Time (in seconds) to wait at device startup before establishing BGP connections.
Values: 15 - 120 seconds
Parameter
Description
AppDirector User Guide
Administering and Monitoring AppDirector
140 Document ID: RDWR-AD-V0231-UG1105
To create/edit a BGP Peer Table 1.From the Router menu, select BGP Route Injection > Peer Table. The Peer Table window appears.
2.For updating a BGP Peer, in the Peer Table window, select the Peer IP Address.
3.For creating a BGP Peer, click Create. The BGP Peer Table Create window.
4.Set the parameters.
5.Click Set. Your configuration is set.
Peer Statistics
The routing tables managed by a BGP implementation are adjusted continually to reflect changes in the network, such as links breaking and being restored or routers going down and coming back up. In the network as a whole it is normal for these changes to happen almost continuously, but for any particular router or link changes are supposed to be relatively infrequent. Therefore AppDirector users need to monitor the BGP statistics from the Peer table. To access the Peer Table statistics 1.From the Router menu select BGP Route Injection > Statistics. The Statistics window appears.
2.Select the Peer IP Address. The BGP Peer Table Statistics Update window appears.
3.Set the parameters.
Parameter
Description
Peer IP Address IP address of the remote peer.
Admin Status Allows administrators to enable or disable the peer. Connect Retry Interval
Interval where AppDirector will try to re-establish a BGP connection with remote peer after TCP failure event.
Hold Time (sec) Defines hold time offered by AppDirector during BGP connection establishment. During hold time, a peer must receive a keepalive or an update message from the remote peer to consider the BGP connection active. Zero (0) indicates that keepalive will not be sent by AppDirector and AppDirector will not expect keepalive messages from remote peer.
Keep Alive Time (sec)
Time interval used by AppDirector for sending keepalive messages to the remote peer. Zero (0) indicates that keepalive messages are not sent.
Parameter
Description
Peer IP Address IP address of the remote peer.
Admin Status Allows administrators to enable or disable the peer. AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 141
Connection State • Idle: The Peer is stopped.
• Connect: AppDirector initiated a TCP connection to remote peer.
• Active: Peer is waiting during a connect retry interval, after failing to establish TCP connection to a remote peer. In this state, AppDirector also listens on port 179 for potential incoming connections from the remote peer.
• OpenSent: A TCP connection is established with the remote peer. AppDirector sent a BGP OPEN message to the remote peer and expects to receive an OPEN message from it.
• OpenConfirm: AppDirector received an OPEN message from the remote peer. AppDirector responds with a KEEPALIVE message and expects a KEEPALIVE message from the remote peer.
• Established: BGP connection is established with remote peer. AppDirector can now exchange UPDATE messages with it.
Remote AS Remote autonomous system number.
Peer Identifier IP address identifies remote peer for current BGP connection.
Local Address AppDirector IP interface address used as source IP for BGP connection.
Local Port TCP source port number used by AppDirector for BGP connection to remote peer.
In/Out Updates The number of BGP UPDATE messages transmitted on this connection. This object should be initialized to zero (0) when the connection is established.
In/Out Total Messages
The total number of messages received from/transmitted to the remote peer on this connection. This should be initialized to zero when the connection is established.
Last Error The last error code and subcode seen by this peer on this connection. If no error has occurred, this field is zero. Otherwise, the first byte of this two byte OCTET STRING contains the error code, and the second byte contains the subcode.
FSM Established Transitions
The total number of times the BGP FSM transitioned into the established state.
FSM Established Time
This timer indicates how long (in seconds) this peer has been in the established state or how long since this peer was last in the established state. It is set to zero when a new peer is configured or the router is booted.
Connect Retry Interval (sec)
Interval in which AppDirector tries to re-establish BGP connection with remote peer after TCP failure event.
Hold Time (sec) Defines hold time offered by AppDirector during a BGP connection establishment. During this time, a peer must receive a keepalive or an update message from the remote peer to consider the BGP connection active. Zero (0) indicates that keepalive messages will not be sent by AppDirector and AppDirector will not expect keepalive messages from the remote peer.
Parameter
Description
AppDirector User Guide
Administering and Monitoring AppDirector
142 Document ID: RDWR-AD-V0231-UG1105
4.Click Set. Your configuration is set.
Keep Alive Time (sec)
Time interval used by AppDirector for sending keepalive messages to the remote peer. Zero (0) indicates that keep alive messages are not sent.
Hold Time Configured
Time interval in seconds for the Hold Time configured for this BGP speaker with this peer. This value is placed in an OPEN message sent to this peer by this BGP speaker, and is compared with the Hold Time field in an OPEN message received from the peer when determining the Hold Time (bgpPeerHoldTime) with the peer. This value must not be less than three seconds if it is not zero (0) in which case the Hold Time is NOT to be established with the peer. The suggested value for this timer is 90 seconds
Keep Alive Configured
Time interval in seconds for the KeepAlive timer configured for this BGP speaker with this peer. The value of this object will only determine the KEEPALIVE messages' frequency relative to the value specified in bgpPeerHoldTimeConfigured; the actual time interval for the KEEPALIVE messages is indicated by bgpPeerKeepAlive. A reasonable maximum value for this timer would be configured to be one third of that of bgpPeerHoldTimeConfigured. If the value of this object is zero (0), no periodical KEEPALIVE messages are sent to the peer after the BGP connection has been established. The suggested value for this timer is 30 seconds.
In Update Elapsed Time (sec.)
Elapsed time in seconds since the last BGP UPDATE message was received from the peer. Each time bgpPeerInUpdates is incremented, the value of this object is set to zero (0)
Parameter
Description
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 143
Redundancy This section introduces AppDirector redundancy capabilities and includes the following topics:
• Network Configurations
, page 143
• Configuration Guidelines
, page 146
• Global Redundancy Configuration
, page 153
• F
ailover Decision
, page 155
• S
tatef
u
l Failover (Mirroring
)
, page 158
• Physical IP Addresses v
ersus V
irtual IP Addresses Redundancy
, page 161
• V
irtual Router Redundancy Protocol
, page 161
• C
onfiguration Synchronization
, page 165
Radware recommends installing AppDirector devices in pairs to provide fault tolerance in 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, AppDirector supports 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 device’s MAC address. Radware recommends using VRRP as described above for AppDirector redundancy.
Network Configurations
The network configuration affects the redundancy configuration. The following network configurations are supported by AppDirector.
Routing
Client side and server side (as shown here) are on different networks.
AppDirector User Guide
Administering and Monitoring AppDirector
144 Document ID: RDWR-AD-V0231-UG1105
Figure 1: Routing network configuration
Bridging
Client side and server side (as shown here) are on the same network. The physical port connected to the client side and the physical port connected to the server side must belong to the same Regular VLAN to achieve bridge configuration.
Figure 2: Bridge network configuration
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 145
Fully Redundant Network Configuration
In certain cases, full redundancy of all network elements is required to ensure that the configuration supports failures of multiple network elements. This is also to ensure that the configuration can handle failures without needing to failover between AppDirector devices, as long as primary AppDirector is available.
Notes:
>> This type of configuration can be supported only when using VRRP redundancy mechanism.
>> RSTP (Rapid Spanning Tree Protocol) should be configured on AppDirector devices to prevent loops. (This type of configuration requires using a Switch VLAN on the AppDirector devices).
>> These types of configurations are not supported on OnDemand Switch VL and OnDemand Switch 1 platforms.
Here, the servers are either directly connected to both AppDirector devices (dual-NIC servers) or to two switches that are connected to both AppDirector devices. On the client side, full redundancy is achieved by either connecting each AppDirector to a different upstream router or connecting each AppDirector to the two upstream routers (or Layer 3 switches) that run STP. For these types of configurations, AppDirector needs the following routing configuration
• The two AppDirectors must be connected via two separate links.
• One of the physical ports used for inter-AppDirector connectivity and the physical port to which the client side is connected are attached to an IP Switch VLAN (shown in Figure 3 - Fully redundant routing network configuratio
n
, page 145
). This allows the primary AppDirector to continue to be active and receive client traffic even when its direct connection to the router (or the router itself) fails.
• One of the physical ports used for inter-AppDirector connectivity and the physical port to which the server side is connected are attached to another IP Switch VLAN (blue marking on Figure 3). This allows the primary AppDirector to continue to be active and see the servers even when its direct connection to the servers or their switch (or the switch itself) fails.
Figure 3: Fully redundant routing network configuration
AppDirector User Guide
Administering and Monitoring AppDirector
146 Document ID: RDWR-AD-V0231-UG1105
Bridge Configuration
• The two AppDirectors must be connected via one link
• The physical port used for inter-AppDirector connectivity and the physical port to which the server side is connected are attached to an IP Switch VLAN (blue marking on Figure 4). This allows the primary AppDirector to continue to be active and see the servers even when its direct connection to the servers or their switch (or the switch itself) fails.
• The physical port to which the client side is connected and the server side Switch VLAN are attached to a Regular VLAN (green marking on Figure 4). Figure 4: Fully redundant Bridge network configuration
Configuration Guidelines The configuration needed in redundant environments depends on the following factors:
• Redundancy configuration: Active-Backup or Active-Active
• Network configuration: Routing or Bridging
• VRRP Preemption state: enabled or disabled
Note:A fully redundant network environment only affects the required inter-AppDirector connectivity and Layer 2 configuration as described in Fully redundant network configuration section. The rest of the redundancy configuration parameters are affected by the factors mentioned above.
This chapter provides configuration guidelines for the different cases above.
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 147
Active-Backup Routing Configuration
In an Active/Backup configuration, the primary AppDirector device is configured with the primary Virtual IP addresses. This device performs the regular AppDirector operations, handling all the inbound sessions to the Virtual IP addresses and distributing traffic among the servers in the farm linked to the Virtual IP address (via Layer 4 Policy). The backup AppDirector device is configured with identical Virtual IP addresses that contain the exact same Layer 4 Policies, servers and farm settings. This device acts as a hot standby and does not perform load balancing as long as the primary device is active. When the backup AppDirector detects that the primary AppDirector has failed, the backup device takes over the IP addresses of its primary partner, informing all devices on the network that the backup device is now responsible for the services of the primary device. When the primary device is back online, the backup device releases the services if VRRP preemption is enabled (default) or if a proprietary redundancy protocol is used. If VRRP preemption is disabled, the backup device will remain active as long as it is online.
Figure 5: Active Backup
AppDirector User Guide
Administering and Monitoring AppDirector
148 Document ID: RDWR-AD-V0231-UG1105
Parameters
Primary
Secondary
Global Parameters Redundancy Admin Status
VRRP Same as primary
Interface Grouping Enable • Disabled (if preemption is
enabled).
• Enabled (if preemption is
disabled).
Backup Interface Grouping
Enable Same as primary
Backup in VLAN N/R - use default Same as primary
Force Port Down N/R - use default Same as primary
VRID Internet Side VRID 1 Same as primary
If Index 1 Same as primary
Primary IP 100.1.1.10 Same as primary
Priority 200 100
Preempt Mode Same for all VRIDs Same as primary
Associated IPs 100.1.1.100,
100.1.1.10
Outbound NAT addresses, if relevant
Same as primary
VRID Server Side VRID 2 Same as primary
If Index 3 Same as primary
Primary IP 20.1.1.10 Same as primary
Priority 200 100
Preempt Mode Same for all VRIDs Same as primary
Associated IPs 20.1.1.10
Client NAT addresses , if relevant
Same as primary
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 149
Active-Active Routing configuration
AppDirector devices can also be configured to function in an Active/Active mode where each AppDirector is the primary provider of some services and a backup for the services provided by the other AppDirector in the pair. In this case, both devices are set up as primary AppDirector for one or more Virtual IPs and as backup AppDirector for the Virtual IPs for which the other unit is primary. When one of the devices fails, the other continues to handle traffic to its own Virtual IPs while assuming responsibility for the backup device’s Virtual IPs.
Note:Using the Active/Active setup, each server can provide service to Virtual IPs that are active on one device. A server cannot provide service to multiple Virtual IPs where one Virtual IP is active on one device, while another Virtual IP is active on another device.
Figure 6: Active-Active Routing Configuration
Mirroring Mirroring Status • Disabled (if preemption is enabled). • Enabled (if preemption is disabled).
Enabled
Mirror Device IP 1.1.1.12 Default
Mirrored Tables • Client Table
• Session ID Table
• Proximity and DNS Persistency for geographically distributed solution
Same as Primary
Parameters
Primary
Secondary
AppDirector User Guide
Administering and Monitoring AppDirector
150 Document ID: RDWR-AD-V0231-UG1105
Parameters
AppDirector 1
AppDirector 2
Global Parameters Redundancy Admin Status
VRRP Same as AppDirector 1
Interface Grouping Enable • Disabled (if preemption is enabled). • Enabled (if preemption is disabled).
Backup Interface Grouping
Enable Same as AppDirector 1
Backup in VLAN N/R - use default Same as primary
Force Port Down N/R - use default Same as primary
VRID Internet Side for VIP active on AppDirector 1
VRID 1 Same as AppDirector 1
If Index 1 Same as AppDirector 1
Primary IP 100.1.1.10 Same as AppDirector 1
Priority 200 100
Preempt Mode Same for all VRIDs Same as AppDirector 1
Associated IPs 100.1.1.100,
100.1.1.10
Outbound NAT addresses (if relevant)
Same as AppDirector 1
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 151
VRID Internet Side for VIP active on AppDirector 2
VRID 2 Same as AppDirector 1
If Index 1 Same as AppDirector 1
Primary IP 200.1.1.10 Same as AppDirector 1
Priority 100 200
Preempt Mode Same for all VRIDs Same as AppDirector 1
Associated IPs 200.1.1.100,
200.1.1.10
Outbound NAT addresses (if relevant)
Same as AppDirector 1
VRID Server Side for VIP active on AppDirector 1
VRID 3 Same as AppDirector 1
If Index 3 Same as AppDirector 1
Primary IP 20.1.1.10 Same as AppDirector 1
Priority 200 100
Preempt Mode Same for all VRIDs Same as AppDirector 1
Associated IPs 20.1.1.10
Client NAT addresses (if relevant)
Same as AppDirector 1
VRID Server Side for VIP active on AppDirector 2
VRID 4 Same as AppDirector 1
If Index 3 Same as AppDirector 1
Primary IP 30.1.1.10 Same as AppDirector 1
Priority 100 200
Preempt Mode Same for all VRIDs Same as AppDirector 1
Associated IPs 30.1.1.10
Client NAT addresses (if relevant)
Same as AppDirector 1
Mirroring Mirroring Status • Disabled (if preemption is enabled). • Enabled (if preemption is disabled).
Enabled
Mirror Device IP 1.1.1.12 Default
Mirrored Tables • Client Table
• Session ID Table
• Proximity and DNS Persistency for geographically distributed solution
Same as AppDirector 1
Parameters
AppDirector 1
AppDirector 2
AppDirector User Guide
Administering and Monitoring AppDirector
152 Document ID: RDWR-AD-V0231-UG1105
Active-Backup Bridging Configuration
Figure 7: Active-Backup Bridging Configuration
Parameters
Primary
Secondary
Global Parameters Redundancy Admin Status
VRRP Same as primary
Interface Grouping Enable • Disabled (if preemption is enabled). • Enabled (if preemption is disabled).
Backup Interface Grouping
Enable Same as primary
Backup in VLAN Block Broadcast Same as primary
Force Port Down Enable Same as primary
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 153
Global Redundancy Configuration
You can configure more than one AppDirector device on a network so that they back up one another. If there is a failure of any network interface, AppDirector will fail the whole device, and the backup device, previously handling its own farms, will take over all activity. The Global Configuration window allows you to enable a backup device. To access AppDirector Global Redundancy Go to AppDirector > Redundancy > Global Configuration. The Global Redundancy Configuration window appears.
To configure global redundancy parameters 1.From the AppDirector menu, select Redundancy > Global Configuration. The Global Redundancy Configuration window appears.
2.Set the parameters.
VRID VRID 1 Same as primary
If Index 1001 Same as primary
Primary IP 100.1.1.10 Same as primary
Priority 200 100
Preempt Mode Same for all VRIDs Same as primary
Associated IPs 100.1.1.100,
100.1.1.10
Same as primary
Mirroring Mirroring Status • Disabled (if preemption is enabled). • Enabled (if preemption is disabled).
Enabled
Mirror Device IP 1.1.1.12 Default
Mirrored Tables • Client Table
• Session ID Table
Same as Primary
Parameters
Primary
Secondary
AppDirector User Guide
Administering and Monitoring AppDirector
154 Document ID: RDWR-AD-V0231-UG1105
Parameter
Description
IP Redundancy Admin Status Each pair of AppDirectors can function in an active/backup setup or active/active setup. To achieve redundancy between pairs of AppDirector devices, these methods are used:
• Disable (default)
• VRRP: Working with Virtual Router Redundancy Protocol enables dynamic redundancy to be maintained using a logical entity called a virtual router. Interface Grouping Ensures that if one port fails, the others are also taken down. When it is enabled, the backup device takes over only when all the interfaces of the main device are down.
Deafult: Disabled
ARP with Interface Grouping
Defines whether device can send ARP requests (when device is the backup device) with active interface grouping. • Send (Default)
• Avoid
Backup Device in VLAN
Enables device to backup another device in VLAN configuration.
Values:
• Forward Traffic - Forward all traffic. This is the default value, but should be used only when the device is in routing configuration.
• Block Broadcast -When the device is in backup state broadcast traffic is blocked in order to prevent loops.
• Block All - When the device is in backup state, all traffic is blocked in order to prevent loops. This cannot be used in a fully redundant network configuration.
Note: Backup in VLAN only works when the VLAN is configured as:
Type = regular and protocol = IP
Backup Interface Grouping
When it is enabled the backup will take over only when IP interfaces defined in its Redundancy Table fail. Respectively, it will release those interfaces only when all the main's interfaces are up.
Default: Enabled
VRRP Advertise Interval [msec.]
Interval that the main device sends active messages.
Values: 100 - 25,000 msec.
Default: 0 msec.
Note: Configuring the specific advertisement interval value for a VRRP entry is only possible when the global value is set to 0. When the global value is not 0, the specific values for VRRP entries are discarded and the global value is used. See V
irtual Router Redundancy Protocol
, page 161
.
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 155
3.Ensure that IP Redundancy Admin Status is enabled, unless the network is a one-legged configuration.
4.Ensure that Interface Grouping is disabled.
5.Click Set. Your configuration is set.
Failover Decision
Failover is a backup operational mode in which the functions of a system component (such as a processor, server, network, or database, for example) are assumed by secondary system components when the primary component becomes unavailable through either failure or scheduled down time. Used to make systems more fault-tolerant, failover is an integral part of mission-critical systems that must be constantly available. The procedure involves automatically offloading tasks to a standby system component so that the procedure is as seamless as possible to the end user. Failover decision is taken by a backup AppDirector when:
• The active device fails
• One or more interfaces fail on the active device. • Application Acceleration modules fail on active device
• Network path health check fails
Interface Grouping
When AppDirector notices that one of its physical ports is down, if Interface Grouping is enabled, it intentionally brings all other active ports down. VRRP Automated 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 interface.
Values: Enabled or Disabled (Default).
Force Down Ports Time
The period of time for which the port must be down. Values: 0 (the feature is disabled) or 5 - 60 seconds. When enabled, the value depends on how long it takes the switch to clear its MAC tables.
Failure Action This defines when Proxy related failures will induce failover in an active-
backup configuration. • Accel-engine Fail: Acceleration engine failure. • SSL or Accel-engine Fail: SSL accelerator or Acceleration engine failure. • Compression or Accel-engine Fail: Hardware Compression Card or Acceleration engine failure. • SSL or Compression or Accel-engine Fail: SSL Accelerator, Hardware Compression Card or Acceleration engine failure. • Ignore: Ignore failures and do not perform failover.
Parameter
Description
AppDirector User Guide
Administering and Monitoring AppDirector
156 Document ID: RDWR-AD-V0231-UG1105
When an interface (physical port, trunk or VLAN) on AppDirector goes down, due to a cable failure, switch port failure, hub failure, or other problems, AppDirector performs the following:
1.AppDirector examines the configuration to see if any IP addresses were configured on the interface that went down.
2.If there were IP addresses configured on the interface, AppDirector deactivates all other active interfaces. 3.If no IP addresses were configured on the interface, nothing occurs and normal operation continues. 4.If the interface grouping is enabled, you can set a flag that indicates that AppDirector cannot send ARPs. But, if the device can send ARPs according to this flag, the Health monitoring module updates the server's status (IG disabled). If AppDirector cannot send ARPs, the Health Monitoring module does not change the status (IG enabled).
5.When interface grouping is enabled and one or more ports are down, the status of the server will not be changed. Note that if the check was already sent before the port went down, the server status is changed to Failed (because there was no answer).
Notes:
>> You can configure per physical port whether it triggers Interface Grouping or not (Selective Interface Grouping).
>> A trunk or VLAN failure always triggers Interface Grouping, but for each VLAN you can configure per physical port whether it affects VLAN status for Interface Grouping or not (see Adding Physical Ports to a VLAN). >> The dedicated management ports failure will not trigger Interface Grouping. Backup Interface Grouping
To prevent cases where partial failover can occur the backup device should take control only if ALL the relevant interfaces of the main device are out of service, and releases those interfaces only when all the main device interfaces are back up.
The backup device takes control only if ALL the interfaces of the primary device are out of service. This solves the problem of an active and a backup device, each connected to a switch, where the switches are cross-connected. When the cable that cross-connects the switches fails, this is not communicated to the primary device. As a result, Interface Grouping is not triggered, but since the backup device cannot communicate with the primary device, the backup device takes over. This causes downtime in the service.
When the Backup Interface Grouping parameter is enabled, the backup device takes over only when all IP interfaces defined in its Redundancy Table (or VRID Table) fail, and releases those interfaces only when all the primary device interfaces are back up. When Backup Interface Grouping is not activated, the backup device takes control for each interface of the main device if it is out of service. Once the respective interface of the main device is available, the backup device releases this interface.
ARP in Interface Grouping
Determines whether the device can send ARP requests (to servers for example) while interface grouping is active; also see the parameter in Global Redundancy Configuration
, page 153
.
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 157
Backup Device and Interface Grouping Behavior in VLAN
Using redundancy in bridging environment (Regular VLAN), the backup device must remain completely silent on the network to prevent broadcast storms. This behavior should be enabled using the Backup Device in VLAN parameter in Global Redundancy Configuration
, page 153
.
The VLAN status sets the Interface Grouping behavior (a VLAN that goes down triggers Interface Grouping), but the Selective Interface Grouping settings of specific ports within the VLAN are ignored. However, VLAN behavior based ports status can be controlled via the following configurations:
• Up/Down Criterion: Per VLAN you can configure when the VLAN is considered up/down based on the number of its ports that are up/down. • Port Interface Grouping State: For each port that is attached to a VLAN you can configure whether its status will be included or excluded from Up/Down Criterion calculations.
Selective Interface Grouping
In AppDirector redundancy installations, primary and redundant AppDirectors can have separate interfaces solely for management purposes and not for handling the traffic. When one of the management ports is down and Interface Grouping is enabled, the backup device takes over. To avoid this, you can use Selective Interface Grouping, where AppDirector defines which interfaces initiate Interface Grouping and which do not. In the Selective Interface Grouping table, you can define whether each interface initiates Interface Grouping if the management port is down. All the interfaces for which VRs are defined are included in Selective Interface Grouping. This feature allows you to enable interface grouping on a selected port.
To enable interface grouping on a selected port 1.From the AppDirector menu, select Redundancy > Selective Interface Grouping. The Selective Interface Grouping window appears.
2.Select the desired Port Number. The Selective Interface Grouping Update window appears.
3.Set the parameters.
4.Click Set. Your configuration is set. Parameter
Description
Port Number Select the relevant port number.
Port Status Define for each interface whether to be included.
• Included (default): port status can determine the VLAN status. • Excluded: port status cannot determine the VLAN status.
Notes:
• when a port has an IP address, and a VRID assigned to it and is set to "excluded", and then disconnected, it will still initiate a failover.
• when a port has an IP address assigned to it, but no VRID, and is set to "include", and then disconnected, it does not initiate failover.
AppDirector User Guide
Administering and Monitoring AppDirector
158 Document ID: RDWR-AD-V0231-UG1105
Application Acceleration Module Failover AppDirector can also initiate failover on Application Acceleration capability failure, either Application Acceleration Engine or hardware SSL Acceleration card or hardware Compression card.
When such a failure occurs on the active AppDirector, the device enters the same mode as Interface Grouping and failover occurs.
Network Path Health Check Failure
The Interface Grouping mechanism can trigger failover only upon failure of physical links directly connected to AppDirector. In certain cases a failure in a network element can cause traffic to stop flowing to and from the main AppDirector, though all the directly connected links are available.
For cases where such a failure is possible, AppDirector enables you to add to the failover decision health of the network path.
To configure the network path health you need to configure regular health monitoring checks for network elements and bind them to the Network Health element, see Configuring Health Monitoring, page 353
for further details. If the Network Health fails, VRRP failover will be triggered. Stateful Failover (Mirroring)
Stateful failover allows a backup device to take over when a primary device fails, without dropping existing sessions or breaking persistency. Stateful failover is provided by mirroring the content of the tables that define a session. There are 3 Mirroring procedures that you can perform:
• A
ctive Device Mirroring
, page 159
• B
ackup Device Mirroring
, page 159
• Mirroring Device Parameters
, page 160
For effective and reliable mirroring you need to:
• Provide a direct connection between the two devices. • Configure an IP interface on each device for the direct connection port and address used as the Mirroring Device Address for the other device.
• Exclude physical port used for inter-device communication from Interface grouping.
Notes:
>> Optionally you can also use a trunk (link aggregation) for direct connection between two devices.
>> Mirroring is not supported when delayed binding is used with Layer 7 Persistent Switching Mode and configured to either overwrite or maintain. >> Mirroring is supported for the Layer 7 Persistent Switching Mode named first.
>> Client entries that are not mirrored are RADIUS client entries.
Mirroring can handle long and short sessions and support HTTP traffic. The following are mirrored: • Dynamic Session ID Table
• DNS Persistency Table (AppDirector Global Only)
• Proximity table AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 159
Active Device Mirroring
To set up device mirroring 1.From the AppDirector menu, select Redundancy > Mirroring > Active Device Parameters. The Mirroring: Active Device Parameters window appears.
2.Set the parameters.
3.Click Set. Your changes are recorded.
Backup Device Mirroring
To set up backup device mirroring 1.From the AppDirector menu, select Redundancy >Mirroring > Backup Device Parameters. The Mirroring: Backup Device Parameters window appears.
2.Set the parameter.
3.Click Set. Your changes are recorded.
Parameter
Description
Proximity Table Mirroring Enable or Disable (Default) Proximity Table Mirroring.
Dynamic DNS Persistency Table Mirroring Enable or Disable (Default) Dynamic DNS Persistency Table Mirroring.
Client Table Mirroring Enable or Disable (Default) Client table Mirroring.
Session Id Table Mirroring
Enable or Disable (Default) Session Id Table Mirroring.
Parameter
Description
Mirroring Status Enable or Disable (Default)
AppDirector User Guide
Administering and Monitoring AppDirector
160 Document ID: RDWR-AD-V0231-UG1105
Mirroring Device Parameters
To set up mirror device parameters 1.From the AppDirector menu, select Redundancy >Mirroring > Mirror Device Parameters. The Mirror Device Parameters window appears.
2.Set the parameter.
3.Click Set. Your changes are recorded.
Notes:
>> When setting up Mirroring, Radware recommends using the same AppDirector software version for the main and backup devices.
>> Setting up Mirroring affects the general device performance.
>> Radware recommends that mirroring is used for Stateful Failover with the VRRP redundancy mechanism.
To fail the main AppDirector, use one of the following:
Using a Web Based Management window: Appdirector > Redundancy >VRRP > Virtual Routers, using the All VRIDs Up or All VRIDs Down options.
OR by CLI command: redundancy vrrp global-admin-status Force Port Down
When operating in VRRP configuration, this capability allows you to force down electrically, (for a short period), physical ports belonging to a VLAN when the VLAN is disabled due to Interface Grouping activation. This allows the switches to which these ports are connected to clear their MAC tables and prevents them from continuing to send traffic to the wrong AppDirector device.
This capability can be configured (AppDirector -> Redundancy -> Global Configuration) or CLI (
redundancy force-down-ports-time
command) via the following parameter
.
Parameter
Description
Mirror Device Parameters
IP address of the device to mirror from.
Parameter
Description
Force Down Ports Time The period of time for which the port must be down. The values can be either 0 (the feature is disabled), or between 2 and 60 seconds. When enabled, the value to be used depends on how long it takes the switch to clear its MAC tables.
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 161
Notes:
>> Upon failovers, printouts displayed for ports down and up have extra 2 seconds delay (in addition to the value set in force-port-down-time).
>> This capability is supported only for one VLAN per device.
>> This capability will not function when VRRP is not enabled and there is no VLAN configured as part of the VRRP interfaces.
Physical IP Addresses versus Virtual IP Addresses Redundancy
In redundancy configurations, both primary and backup AppDirectors must be configured to work with virtual and physical addresses. The primary device ensures that the backup AppDirector supports virtual addresses. These addresses are defined on the backup AppDirector just like the primary AppDirector. Different physical IP addresses are used for the primary and backup devices, and often, another configuration is required on the redundant AppDirector to support backup for physical IP addresses of the primary device.
When a physical interface of the primary AppDirector device is set as the default gateway of a server, and the backup AppDirector takes over, the server works using the backup device as a Next Hop Router. However, in this situation the server cannot ping its default gateway IP address because the primary device is down. To avoid this, you can use Virtual IP addresses as the default gateways of servers and other devices around AppDirector. To use Virtual IP addresses, you need to create a Virtual IP Interface address for each local subnet of AppDirector, and use this address in the relevant routing tables for hosts on that subnet. Ensure that the same Virtual IP Interface addresses are set as backup on the redundant device. Please refer to Layer 4 Policies, page 200
on how to create a Virtual IP.
Virtual Router Redundancy Protocol
The Virtual Router Redundancy Protocol (VRRP) eliminates the single point of failure inherent in the static default routed environment. VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP addresses associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail-over in the forwarding responsibility should the Master become unavailable. Any of the virtual router's IP addresses on a LAN can then be used as the default first hops router by end-hosts.
To achieve redundancy between pairs of devices, Radware recommends using Virtual Router Redundancy Protocol (VRRP). VRRP enables you to maintain dynamic redundancy using a logical entity called virtual router (VRRP was initially developed to provide high availability for routers).
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 User Guide
Administering and Monitoring AppDirector
162 Document ID: RDWR-AD-V0231-UG1105
To set up the VRRP Table 1.From the AppDirector menu, select Redundancy > Global Configuration. The Global Redundancy Configuration window appears.
2.Ensure that IP Redundancy Admin Status is VRRP. 3.From the AppDirector menu, select Redundancy >VRRP > Virtual Routers. The Virtual Router Table window appears.
4.Click Create. The Virtual Router Table Create window appears.
5.Set the parameters.
Parameter
Description
IP Version Select IPv4 or IPv6.
If Index Interface number. Default: F-1
VR ID Virtual router’s identification number. Values: 1 - 255
Admin Status Displays the status of the administration, Up or Down.
Priority The highest priority (255) must be assigned to the VR associated with a device’s physical IP address (IP address that the device owns).
Values: 1 - 255
Default: 100
Notes:
• When 2 devices are configured with VRRP and the master device has a priority of 255 set for its virtual routers, shutting down all virtual routers causes the backup state to move to master but causes the client connections to cease. This is because when you down Virtual Routers, you DO NOT down the port. This port will continue functioning and as soon as you down the virtual router, the port will broadcast its MAC as the owner of the device interface IP. It will continue sending health checks with source IP and interface IP and ARPs for IPs on the directly connected networks. • These ARPs will poison the ARP cache of all machines on this network and they will record the interface MAC of the primary box as the holder of the interface IP that the backup device tried to take over via VRRP. • Therefore, all traffic sent to the primary device interface IP as a gateway (reply traffic from the servers) reaches the primary device and is routed straight to the default gateway of the device. This is not where this traffic should be heading because traffic sent to a VIP which was taken over by the backup device (the primary device will not fix the IP headers) will route the packet as it stands which will break the session. • When you use VR priority of 255 on the primary device, you must manually add its interface IP in the associated IP table.
• When you do not use VR priority of 255 on the primary device, you cannot place its interface IP in the associated IP table. This means that the default gateway will be a different IP which has no problems being poisoned but with the interface activities of the primary device. AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 163
6.Click Set. Your configuration is set.
Primary IP This is used internally only, as the source IP of VRRP messages sent by the device. It is recommended to leave the default in this parameter. The device adds a default unless the user defines one. Advertise Interval Interval at which packets are checked in seconds. Default: 1 second.
Note: Configuring the specific advertisement interval value for a VRRP entry is only possible when the global value is set to 0. When the global value is not 0, the specific values for VRRP entries are discarded and the global value is used. See Global Redundancy Configuration
, page 153
.
Preempt Mode Defines takeover procedure for VR when a device fails and then resumes functioning. When a device with a certain priority fails, the device with the next highest priority takes control of the VR. Then, when the device with the higher priority for this VR resumes functioning, Preemption Mode decides whether to retake control of VR from the device with the lower priority. Values:
• True - the higher priority device takes over the VR
• False (Default) - only if the backup priority is higher than the difference of the base priority of the master and backup, then the Master will take over.
Note: The router owning the IP address associated with the VR is an exception as it always preempts independently of parameter setting.
VR MAC The virtual MAC address of the virtual router. Although this object can be derived from the 'vrrpOperVrId' object, it is defined so that it is easily obtainable by a management application and can be included in VRRP-
related SNMP traps.
Address Count The number of IP addresses that are associated with this virtual router. This number is equal to the number of rows in the vrrpAssoIpV6AddrTable that correspond to a given IF index/VRID pair
Master IP The master router's real (primary) IP address. This is the IP address listed as the source in VRRP advertisement last received by this virtual router.
Up Time This is the value of the `sysUpTime' object when this virtual router (i.e., the `vrrpOperState') transitioned out of `initialized'.
Preferred State The preferred state of the virtual router. This field affects the configuration of the peer device's parallel VRRP entry. Values:
• Backup - indicates that the peer's VRRP entry should have a higher priority. • Master - which indicates that the peer's VRRP entry should have a lower priority.
Parameter
Description
AppDirector User Guide
Administering and Monitoring AppDirector
164 Document ID: RDWR-AD-V0231-UG1105
To activate or shut down the devices
1.In the VRIDs Up/Down drop-down list, set the desired parameter.
2.Click Set. Your configuration is set.
Associated IP Addresses
The Virtual Router Redundancy Protocol (VRRP) eliminates the single point of failure inherent in the static default routed environment. VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail-over in the forwarding responsibility should the Master become unavailable. Any of the virtual router's IP addresses on a LAN can then be used as the default first hops router by end-hosts.
You use the Associated IP Addresses window to configure the VRRP. An entry in the table contains an IP address that is associated with a virtual router. The number of rows for a given ifIndex and VrId will equal the number of IP addresses associated (for example, backed up) by the virtual router (equivalent to 'vrrpOperIpAddrCount'). To set up the Associated IP Addresses 1.From the AppDirector menu, select Redundancy > VRRP > Associated IP Addresses. The Associated IP Addresses window appears.
2.Click Create. The Associated IP Addresses Create window appears.
3.Set the parameters.
4.Click Set. Your preferences are recorded.
Parameter
Description
VRIDs Up/Down • All Down: Sets Admin Status for all VRIDs to Down. This shuts down the main device.
• All Up: Sets the Admin status of all VRIDs to Up. So that the main AppDirector is activated and takes control from the backup device.
• No Change (Default): There is no change in the Admin Status.
Parameter
Description
IP Version Select IPv4 or IPv6.
If Index Displays the interface number.
VR ID Displays the virtual routers identification number.
Note: VR ID must be Disabled to add Associated IP addresses to it. Then VR ID must be Enabled. The VR ID is set in the Virtual Routers table.
Associated IP Displays the IP address associated with this VR ID.
Note: Up to 255 IP Addresses can be associated with a single VR ID.
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 165
Configuration Synchronization
In a redundant configuration, master and slave devices require consistent configuration. Online configuration synchronization helps to prevent a tedious error-prone manual process to ensure that the configuration is synchronized between a pair of redundant devices.
This feature provides a mechanism where the configuration created on one device is updated automatically and synchronously on its redundancy peer. This way, the device configurations are guaranteed to be always synchronized, without requiring manual intervention.
This capability operates in a master/slave mode where the master device is the only one that can be configured by the administrator and the slave device is configured by the master device only. Automatic configuration synchronization is achieved by providing an online update of the slave device for all configuration operations performed on the master device.
Notes:
>> The redundancy configuration is updated on the slave device according to the recommended configuration in the Configuration Guidelines section.
>> This capability is only supported for a pair of devices using VRRP in an Active-backup scenario.
Master/Slave Roles
The roles of the devices are set manually and never change dynamically in contrast to the VRRP active ownership.
• The configuration synchronization roles are independent of the device redundancy operation mode (Active/Backup). You need to set the primary device as configuration master.
• The configuration synchronization will consider the VRRP status when rebooting the slave device (after configuration changes that require reboot). If the configuration slave is the VRRP active device, then reboot is suppressed to avoid unnecessary failover that will cause connection disruption. The master will wait for the VRRP role to switch over and only then issue a reboot.
Activating Configuration Synchronization
Pre-requisites
For auto-configuration synchronization, master and slave devices must match the following criteria:
1.Hardware platform type - master and slave devices must use the same hardware platform.
2.Memory size.
3.License - (license upgrading needs to be performed manually on both devices, as each license is bound to a specific machine).
4.Software version - Any software upgrade is performed manually on each device. During this process, the configuration synchronization must be disabled.
5.Network topology (parallel ports connected to the same subnets and the same IP addresses matching crosswise).
6.Before the configuration is synchronized for the first time, there must be at least one matching IP interface (same subnet, same interface) on the two devices. AppDirector User Guide
Administering and Monitoring AppDirector
166 Document ID: RDWR-AD-V0231-UG1105
Example A Master
IP: 1.1.1.1, Subnetmask: 255.0.0.0, Port: G-1, PeerAddress: 1.1.1.2
B Slave
IP: 1.1.1.2, Subnetmask: 255.0.0.0, Port: G-1, PeerAddress: 1.1.1.1
Notes:
>> Verify that all above steps before enabling configuration synchronization on your devices.
>> The master device checks all the above conditions (except number 5 which is the administrator’s responsibility) and will not start synchronization if one of these conditions is not satisfied.
Starting to Configure
To start configuration synchronization
1.On the master device, set the Device Role to Master and configure the Synchronization Session Password with the same value that you used on the slave device. In a few seconds the devices will start to synchronize with each other. This process will trigger a reboot of the slave device.
2.Next, on the slave device, set the Device Role to Slave and configure a new value for the Synchronization Session Password (for security purposes the initial password is randomly generated).
3.When the slave device comes up from reboot, the devices will finish the synchronization process and their configuration will be matched. Subsequently, each configuration change now made on the master device is synchronized on the slave device.
Notes:
>> For each IP interface configured on the master device a Peer IP address must be configured (to be used as IP interface on the slave device).
>> You can monitor synchronization state on the Master device. The state should show In-
Sync. See Configuration Synchronization Monitoring
, page 170
.
>> Configurations requiring reboot will only take effect on the slave after you have rebooted the Master device (and it will then automatically reboot the slave).
There are additional configuration synchronization parameters that can be modified, see Configuration Synchronization Settings
, page 167
.
The configuration synchronization status and statistics can be constantly monitored, see Configuration Synchronization Monitoring
, page 170
.
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 167
Slave Device Behavior
While the online configuration synchronization is enabled, the slave device cannot be directly configured by user, with the exception of a few parameters that are not synchronized and can then be configured directly on the slave device. These parameters are marked in both master and slave devices.
Examples of parameters that are not synchronized: Device Name, VRRP Global Admin Status, OSPF Router ID, Layer 2 Interface parameters.
You can also perform software and license upgrade on a slave device, reset statistics and clear table, perform any non-configuration commands (such as ping, telnet, etc.), perform troubleshooting operations (filter client table view, configure diagnostics and retrieve support file) as well as CLI terminal configuration.
Configuration Synchronization Settings
To configure Configuration Synchronization Settings
1.From the main menu, select Redundancy > Configuration Synchronization > Settings. The Configuration Synchronization Settings window appears.
2.Set the parameters.
Parameter
Description
Device Role The role that this device plays in configuration synchronization:
• None (default): the device does not participate in configuration synchronization
• Master: only this device is configurable and it synchronizes the slave device
• Slave: this device receives its configuration from the Master device, only change of its role in configuration synchronization and reboot can be performed on a device in Slave mode
Synchronization Session Password
The password used to establish an SSH session between the devices for configuration synchronization. The same value must be configured in both devices (master and slave) to allow session establishment. Connection Preference
The IP Interface through which configuration synchronization communication with peer device should be established. Values:
• Any: The device will try to establish connectivity via any of the device IP Interfaces. • Any MNG IP: The device will try to establish connectivity via any of the device IP Interfaces configured on dedicated MNG ports. • Select a specific device IP Interfaces. Only IP Interfaces for which a Peer IP Address is configured are eligible.
Note: If the Connection Preference is changed while the configuration synchronization communication between the devices is active, Reconnect Slave command must be performed in order to cause the devices to connect via the new preferred interface.
AppDirector User Guide
Administering and Monitoring AppDirector
168 Document ID: RDWR-AD-V0231-UG1105
Alternate Connection Preference
The IP Interface through which configuration synchronization communication with peer device should be established in case the IP Interface defined for first Connection Preference is not available. Values:
• None: No alternate connection
• Any: The device will try to establish connectivity via any of the device IP Interfaces. • Any MNG IP: The device will try to establish connectivity via any of the device IP Interfaces configured on dedicated MNG ports. Select a specific device IP Interfaces. Only IP Interfaces for which a Peer IP Address is configured are eligible.
Allow Active Slave Reboot (When device has Master role)
You can decide whether to allow the slave device to be rebooted. Due to configuration changes requiring reboot, the slave device is in active state (redundancy wise). Default: Disabled.
Peer Connectivity Timers (sec)
Slave Connect Interval (When device has Master role)
The interval at which a master device tries to establish connectivity to a disconnected slave. Default: 15 sec.
Keep Alive Interval (When device has Master role)
The interval at which a master device sends keep alive messages to slave to maintain connectivity. Default: 120 sec.
Slave Response Timeout (When device has Master role)
If the slave device does not answer either connection attempt or keep alive message within this timeout, it is considered to be disconnected. Default: 20 sec.
Slave Reboot Timeout (When device has Master role)
If the slave device does not answer connection attempt after it was rebooted within this timeout, it is considered to be disconnected. Default: 240 sec.
Peer Disconnect Alert Delay (When device has either Master or Slave role)
A trap that alerts on a slave disconnection will be sent only after the slave has been disconnected for this period (to avert flip-flops). Default: 60 sec.
Master Communication Timeout (When device has Slave role)
If the slave device does not receive communication from a master for this timeout, the master is considered disconnected. Default: 180 sec.
Parameter
Description
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 169
3.Click Set. Your configuration is set.
SNMPv3 Users Synchronization with Radware’s APSolute Vision
When managing devices over SNMPv3, APSolute Vision uses the SNMP Engine ID parameter to identify a device, which means that each AppDirector device that needs to be managed by the same Vision server over SNMPv3, must have a different Engine ID.
The security keys used for authenticating and encrypting SNMPv3 packets are generated as a function of the authoritative SNMP engine's engine ID and user passwords, which means that when we synchronize SNMPv3 users between two devices we must also copy the Engine ID, which contradicts APSolute Vision requirements.
In order to allow for Radware's APSolute Vision to manage pairs of AppDirector devices over SNMPv3, we now enable you to exclude SNMPv3 users from synchronization. In this case, SNMPv3 users will have to be defined manually on a Slave device.
The following procedures must be followed to enable APSolute Vision to manage a pair of devices over SNMPv3:
Online Configuration Synchronization
1.Enable the Exclude SNMPv3 Users parameter (Redundancy/Configuration Synchronization/
Settings).
2.If the devices were previously synchronized, you must run the following CLI command on the Slave device in order to reset the previously synchronized Engine ID and delete previously synchronized SNMPv3 users - manage snmp reset-engine-id.
3.Define the SNMPv3 users directly on the Slave device.
Manual Configuration Synchronization (download the Peer configuration file from main device and upload to peer device)
1.On the main device, enable the Exclude SNMPv3 Users parameter when downloading the Peer configuration file (File/Configuration/Receive from Device).
2.If the devices were previously synchronized, you must run the following CLI command on the peer device in order to reset the previously synchronized Engine ID and delete previously synchronized SNMPv3 users - manage snmp reset-engine-id.
3.Define the SNMPv3 users directly on the peer device.
Exclude from Synchronization
Exclude Management IP (When device has Master role)
IP interfaces defined on the management ports: MNG-1 and MNG-2. You can decide whether to synchronize management interfaces. Values: Enabled (default)/disabled
Exclude Secured Management Settings (When device has Master role)
You can decide whether to synchronize the secure management interface settings and the certificates that they use. These include the secure Web-based management and SSH. Values: Enabled (default)/disabled
Exclude SNMPv3 Users
When using AppDirector with APSolute Vision, this parameter should be set to True. This excludes SNMPv3 users from synchronization but not from the SNMP table access.
Values: True, False
For more information see SNMPv3 Users Synchronization with Radware’s APSolute Vision
, page 169
.
Parameter
Description
AppDirector User Guide
Administering and Monitoring AppDirector
170 Document ID: RDWR-AD-V0231-UG1105
Configuration Synchronization Monitoring
This feature includes monitoring values related to the configuration synchronization feature. They apply to both master and slave devices
To view Configuration Synchronization Monitoring
From the main menu, select Redundancy > Configuration Synchronization > Monitoring. The Configuration Synchronization Monitoring window appears displaying the following states and counters.
Parameter
Description
Synchronization State The current state of the configuration synchronization. Values for Master devices:
• Sync-off - Disabled • Disconnected - indicates that config-sync feature is enabled on your device, but synchronization did not yet occur
• Master-connected - Master and slave are In Synchronization, and everything you configure on master will be configured automatically on the slave.
• No-master - No master connected.
• Synchronizing - both devices are synchronizing for the first time and this state will take a few minutes until they get into In-Sync state, (until all configuration will be sent to the slave, and the slave reboots).
• In-Sync - Slave and Master devices are synchronized.
• Incompatible - the devices are not compatible. True master-slave matching has not occurred or the slave's device-role is not configured as a slave. To find the problem, first check the monitoring scalar of "incompatibility". It will give you a reason why the devices are not incompatible due to a hardware, software or configuration problem.
• Cannot-Sync- this usually indicates a configuration problem. For example, a master device tried to configure the slave, but a command failed. Check the logs and after the fix, you need to set the master's mode to disabled, and then back to "Master".
• Pending-VRRP-switch - pending failover • Out-Of-Sync - this state is useful when you have a single farm failure in the In-Sync state. Normally, Full sync triggers immediately, and may result in reconfiguring the device. Out-of- Sync allows you to carry on configuring other farms until the timeout expires.
Values for Slave devices:
• Disabled
• Disconnected (for explanation, see above)
• Master-Connected (for explanation, see above)
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 171
Incompatibility Status The reason the master and slave are incompatible. Applies only to master device and only if current state is incompatible or disconnected. Values:
• Hardware platform
• Memory size
• License
• Software version • Initial configuration (applies to disconnected state - the slave will refuse to connect in this case)
• Slave compatibility is not established
Notes:
• If there is more than one reason, then the first reason detected is displayed.
• Slave compatibility is not established when configuration synchronization is not activated.
Synchronization IP Interface
The current IP interface used for the communication with the peer device. If the devices are disconnected - null=0.0.0.0 Peer IP Displays the synchronization peer IP.
• For synchronization master devices, the slave IP is displayed.
• For synchronization slave devices, the master IP is displayed.
Peer Base MAC The base MAC of the configuration synchronized peer device that is currently logged in or has last logged in. Used as the unique identifier of the peer device. Set to null, if the peer was never connected. Configuration Timestamp The last time the configuration was successfully propagated from the master to the slave. Availability Status Availability for receiving configuration changes. When AppDirector is unavailable, and when it acts as a slave, it will refuse to accept a configuration change.
Values:
• Available
• axDown (meaning unavailable because the acceleration engine is down)
• Unavailable
Device Should Reboot Indicates whether changes were made to the configuration that require the device to be rebooted.
Values: True/False
For Master Devices Only
Last Configuration Synchronization The last time that the configuration was successfully propagated from the master to the slave. The configuration synchronization can be either individual or full synchronization.
Default: 0
Last Full Configuration Synchronization The last time that a full synchronization was successfully performed.
Default: 0
Parameter
Description
AppDirector User Guide
Administering and Monitoring AppDirector
172 Document ID: RDWR-AD-V0231-UG1105
Reset Slave Device
When the changes performed on the configuration master require the device reboot to become active or when full synchronization is performed, you need to reboot the slave device.
To avoid unnecessary failover from a forwarded connection disruption, the master device will not reboot the slave device, if the slave device is the VRRP active device. Full synchronization is required and the configuration synchronization is suspended until VRRP control returns to the master of configuration and only then will full synchronization occur.
This behavior can be overridden by a configuration flag named Allow Active Slave Reboot. When this flag is enabled, the configuration master disregards the VRRP status and reboots the slave device whenever the configuration synchronization requires.
For configuration changes requiring a reboot (such as table size tuning), the master device updates the slave device with the configuration change like any other change, but will not reboot the slave immediately. It will instead wait until it is rebooted itself, because until then, the configuration change will not have taken effect in either device, and the configurations are still in synchronization. When the master device comes online after reboot, a self-check will show that it has a more updated configuration (due to the reboot) and full synchronization will occur.
If a configuration change requiring a reboot was performed, and the slave device was rebooted for any reason (manually, due to crash or due to full synchronization after connection loss) before the master device was rebooted, then the slave device will now have a more updated configuration than the master. This is the only case where this occurs.
Discrete Synchronization Attempts
The number of successful individual synchronization operations since last full synchronization.
Default: 0
Full Synchronization Operations
The number of successful full synchronization operations since configuration synchronization was last enabled, or since the last reboot (the later of the two).
Default: 0
Number of Successful Connections
The number of successful individual synchronization operations since the last full configuration synchronization.
Default: 0
Synchronization Failures The number of synchronization operations (individual or full synchronization) that failed since last enablement or reboot (the later). The failures include only operations that failed due to application problems to update the slave device. They do not include disconnections, connection setup failures, failed compatibility checks and inability to reboot the slave because it was the VRRP active device.
Default: 0
Disconnections The number of times that the peer was disconnected since last enablement or reboot (the later).
Default: 0
Slave Configuration version (Master only)
Version/timestamp of last time the configuration was modified on Master, but not necessarily propagated to slave. If this time is identical to the slave configuration version then the two devices are in sync.
Default: 0
Parameter
Description
AppDirector User Guide
Administering and Monitoring AppDirector
Document ID: RDWR-AD-V0231-UG1105 173
Manually Resetting a Slave Device
From a device that has Master role, the administrator can reboot a Slave device. This allows you to override the Allow Active Slave Reboot flag disabled status and to force a slave device reboot.
To manually reset a Slave device
1.From the main menu, select Redundancy > Configuration Synchronization > Monitoring > Reset Slave. The Reset Slave Device window appears.
2.Click Set (for Reboot Slave (master only). The slave device is reset.
Reconnect
From a device that has Master role, the administrator can force a reconnect to the slave device. This should be used when you have changed the interface through which you want the config-sync connection to be established.
To reconnect to slave from Master device
1.From the main menu, select Redundancy > Configuration Synchronization > Monitoring > Reconnect. The Reconnect window appears.
2.Click Set (for Reconnect to Slave (master only). The slave is reconnected.
AppDirector User Guide
Administering and Monitoring AppDirector
174 Document ID: RDWR-AD-V0231-UG1105
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 175
Chapter 3 – Traffic Management and Application Acceleration
This chapter introduces concepts for load balancing and application acceleration (when enabled) and explains how to configure your data center for traffic management policies. It includes these topics:
• Configuring Farms, page 177
• Configuring Servers, page 186
• Traffic Management Policies, page 199
• SSL Offloading and Authentication, page 209
• Application Acceleration, page 235
• Layer 7 Traffic Management, page 249
• Layer 7 Modification, page 259
• Layer 7 Server Persistency, page 275
• Client Table Management, page 287
• Network Address Translation (NAT), page 297
• Configuring AppDirector Advanced Global Parameters, page 311
The following workflow helps you to understand how to configure traffic management and acceleration for AppDirector and distinguishes between Acceleration enabled and disabled functionalities.
AppDirector User Guide
Traffic Management and Application Acceleration
176 Document ID: RDWR-AD-V0231-UG1105
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:
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 177
• To which group of servers to direct the request to provide the service required by the client. • To which server within the required group to direct the traffic to optimize the service provided and to ensure its operation.
The main elements involved in configuring server load balancing on AppDirector are:
1.Farm - A group of application servers that provide the same service. A farm can provide multiple services and a server can be part of multiple farms.
2.Virtual IP (VIP) - A single point of entry through which clients can access a variety of services.
3.Layer 7 Policy - a set of rules that allow to select a farm based on application data (Layer 7).
4.Layer 4 Policy - a set of rules that allow to select a farm based on layer 4 and layer 7 data if required (by linking to a Layer 7 policy) and activate application acceleration capabilities. The layer 4 data used to classify traffic via L4 Polices is:
a.Destination IP (VIP)
b.Layer 4 Protocol (TCP, UDP, ICMP, SCTP, Any or Other)
c.Layer 4 Port
d.Source IP Range
When traffic reaches the services point of entry (VIP) AppDirector Matches the Layer 4 data in the packet to Layer 4 policies configured on the device until the best match is found. Once a matching Layer 4 Policy is found the device processes the traffic according to the services required for this Layer 4 Policy. As an example the following actions are performed for HTTPS traffic processing:
1.SSL processing is performed by AppDirector, if required, to off-load it from the servers.
2.If HTTP caching is enabled, AppDirector can respond from the cache, to off-load it from servers if the requested object is in the cache. In this case steps 3-5 are not relevant.
3.If a Layer 7 policy is attached, the device processes the application request searching for the Layer 7 policy criteria to select the target farm, if not the target farm is the one directly attached to the Layer 4 policy.
4.Traffic is forwarded to the server best able to deliver the requested service within the target farm.
5.If HTTP caching is enabled, cache objects from the response according to configuration.
6.HTTP response can be compressed if required.
7.Response is SSL encrypted before being sent to client.
Configuring Farms
This section describes how to configure Farms for AppDirector operations. Topics include:
• Farm Parameters, page 177
• Additional HTTP Connectivity Checks Parameters, page 184
• No HTTP Service Page, page 185
Farm Parameters
A server farm is a group of networked servers that provide the same service. Servers contained in a server farm can be placed in different physical locations, belong to different vendors, or have different capacities. Differences between servers within a farm are transparent to clients. If all the servers within a group provide the same service managed by the AppDirector device, this group can be defined as an AppDirector server farm. A server providing multiple services can be used in multiple farms. For example, Server 3 (S3), as shown in this figure, provides Web service in one farm and FTP service in another server farm.
AppDirector User Guide
Traffic Management and Application Acceleration
178 Document ID: RDWR-AD-V0231-UG1105
. To add or edit a new server farm 1.From the AppDirector menu, select Farms > Farm Table. The Farms Table window is displayed. Select the desired farm name. The Farm Table Update window is displayed.
2.Set the parameters..
Parameter
Description
Farm Name Name of farm (Read- Only in Edit Mode).
Admin Status Can be one of the following options:
• Enable: Farm is active. All users are balanced between servers. • Disable: Farm is inactive. Clients connecting to the farm cannot be served. Dispatch Method Method used to determine to which server traffic is directed: Cyclic: Directs traffic to each operational server 1 by 1 (round robin). Weighted Cyclic: This method uses the Weighted Round Robin algorithm. AppDirector distributes clients’ requests for service in the round robin manner taking into consideration the weight of servers in that farm. Explicitly, every new session is distributed to the next server up to the server weight. For example, if one server has a weight of 2 and another server has weight of 5, the first two sessions are sent to #1, the next five are sent to #2. Sessions eight and nine are sent to #1 again, and ten to fourteen are sent to #1 and so on.
Least Amount of Traffic: Directs traffic to server with least traffic belonging to this farm (relevant when server belongs to multiple farms). Server weights are also considered.
Fewest Number of Users: Directs traffic to server with least amount of users belonging to this farm (relevant when server belongs to multiple farms). Server weights are also considered.
Least Amount of Traffic Local: Directs users to the server with the least traffic. Server weights are also considered.
Fewest Number of Users Local: Directs users to the server with the fewest users. Server weights are also considered.
nt-1: AppDirector queries the farm's servers for Windows NT SNMP statistics and redirects new sessions to the least busy server according to the servers' reported statistics.
nt-2: Similar to nt-1, but using the second weights scheme.
private-1: AppDirector queries the farm's servers for private SNMP parameters, as defined in the first private weights scheme. Ratios of users on servers are balanced according to reported statistics.
Web Farm
FTP Farm
S1
S2
S3
S4
S5
S6
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 179
Dispatch Method (continued)
private-2: Similar to private-1, but using second weights scheme.
Response Time: Enables Response Time load balancing. This load balances the servers in the farm based on the least loaded server as calculated by the Response Level. Server weights are also considered.
• Note: You need to create a health check that also measures response time, for each server, to have the response time dispatch method working properly. See Binding, page 364
.
Hashing: AppDirector selects a server for a session using a static Hash function. This method enables AppDirector to repeatedly direct requests from the same client to the same server within a farm even after the client entry has aged, as long as the server is still in service.
This Dispatch Method also provides support for reverse proxy Web farms, avoiding data replication among the proxy servers.
Input for the Hash function is usually the Client IP only. A formula is applied to this IP address. Output received is a numeric value. When the traffic is SIP, input for the hash function is either Call-ID or Request-URI (configurable) and when the traffic is RADIUS input for the hash function is user-defined RADIUS attribute value. • Note: When a Hash result indicates to use a server with status of Not in Service, a second hash is used to select an available server for the session.
Sessions Mode The method used to handle new sessions: • Regular: All sessions from the same client IP to the same service (VIP + Protocol + port) are forwarded to the same server. • Entry Per Session: All sessions from the same client IP to the same service (VIP + Protocol + port) are forwarded to the same server, but each session is recorded in the client table providing more accurate minimum-user load balancing.
• Server Per Session: Different sessions opened by a client IP are served by different servers, according to load balancing algorithms. This enhances load balancing performance but may hinder some applications dependent on being served by the same server. It also may overload internal tables. • Remove on Session End - EPS: After TCP client session ends, the client's entry is removed from the Client Table ends after 5-6 seconds. This automatically enables Entry Per Session. • Remove on Session End - SPS: After TCP client session ends, the client's entry is immediately removed from the Client Table after 5-6 seconds. This automatically enables Server Per Session.
Aging Time [sec] Amount of time a non-active session is kept in the client table (in seconds). As long as a session is kept in the client table, the client is connected to the same server. Bandwidth Limit Maximum amount of bandwidth in Kbps allowed for this farm. If traffic through the farm exceeds the configured limit for any given second, AppDirector drops excess packets. Note: Bandwidth Limit is measured in Kbps, so 1Mbps is represented with a bandwidth limit of 1000. A value of 0 = no bandwidth limit.
Default: No Limit.
Parameter
Description
AppDirector User Guide
Traffic Management and Application Acceleration
180 Document ID: RDWR-AD-V0231-UG1105
Connectivity Checks
Connectivity Check Method
Indicates method of checking for server availability. Values: No Checks, Ping, TCP Port, UDP Port and HTTP Page. If Ping is selected, AppDirector pings the servers to verify valid communication. If HTTP Page is selected, AppDirector tries to retrieve the web page (as configured in the Home Page field) from the servers. TCP Port/ UDP Port causes AppDirector to attempt to connect to the specified application port, according to the protocol. Note: If a farm has no Layer 4 policy associated with it, the connectivity checks will stop working. This can lead to unreliable farm server table status output. If the same server is in two farms using a TCP port connectivity check, and only one farm has a Layer 4 policy associated with it, you will see the same server on the same application port up and down.
Connectivity Check Retries
Number of polling attempts made before a server is considered inactive.
Connectivity Check Interval
How often the device polls servers (seconds). Connectivity Check Port
Specific port where you can conduct a connectivity check. Values: FTP, HTTP, SMTP, DNS, NNTP, HTTPS, RTSP, RADIUS or any port number you enter manually. For example, HTTP automatically checks port 80.
Extended Check Frequency
To save unnecessary web page requests, web page retrieval is performed only periodically for HTTP page connectivity check. Once in a number of requests, according to the retrieval frequency, the web page is requested. Otherwise, a simple TCP check for port 80 occurs. Authorized Username Used for password protected HTTP page checks.
Authorized Password Used for password protected HTTP page checks.
Home Page With the "HTTP pages" check method, this defines the default web page retrieved from servers. If this web page is unavailable, the server is considered down. Connection Denials (Read-Only)
Number of times connection to this farm was denied.
Operational Status (Read Only)
The Farm Operational Status OID is calculated by these rules:
Active when: • (Farm Admin Status is Enabled) AND (at least one farm server is Active).
Not In Service when:
• (Farm Admin Status is Disabled) OR (all farm servers Operational Status is not Active = Not In Service or No New Sessions).
Note: When the Farm Operational Status is changing, the device sends a trap to notify. Parameter
Description
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 181
3.Click Set. Your configuration is set.
Additional Farm Parameters
You can use the Extended Parameters window to configure additional server farm information. To configure extended farm parameters 1.From the AppDirector menu, select Farms > Extended Parameters. The Extended Farm Parameters window is displayed.
2.Select a farm. The Extended Farm Parameters Update window is displayed.
3.Set the parameters.
Parameter
Description
Farm Name (Read-
Only)
Name of the farm. Connection Management
Close Session At Aging
When enabled and Client Aging expires for a specific session, AppDirector removes the Client Table entry for this session and sends a RESET to the server to close the associated port. (Applicable to TCP sessions only).
Default: Disabled
Connection Limit Exception
AppDirector allows Connection Limit configured for servers to be exceeded.
When this is enabled, in cases where existing client opens new sessions and all sessions should use the same server, the session should use the same server. For example, when using EntryPerSession or Client Grouping Mask. Default: Disabled
Reset Client on Server Failure
When it closes a connection with the client by sending it a RESET when a server is detected to be down.
Default: Disabled
Note: This cannot be enabled on a Regular farm. This feature requires one of these layer 4 modes (EPS or SPS). Here, every session can obtain client entry.
Client NAT
IPv4 Client NAT Address Range
Range of IPv4 NAT addresses, based on the NAT Address Table, to be used for this farm. A client with an IP address within the Client NAT Intercept Range, approaching the farm, is NATed according to the selected NAT Address Range. Also see Client NAT Addresses, page 299
.
IPv6 Client NAT Address Range
Range of IPv6 NAT addresses, based on the NAT Address Table, to be used for this farm. A client with an IP address within the Client NAT Intercept Range, approaching the farm, is NATed according to the selected NAT Address Range. Also see Client NAT Addresses, page 299
.
Add X-Forwarded-
For to HTTP requests
When using Client NAT, the source IP address is replaced by NAT address, so that server cannot know the identity of the original client. To solve this problem AppDirector can insert an X-Forwarded-For header with the identity of the original client in the traffic forwarded to server.
Default: Disabled
AppDirector User Guide
Traffic Management and Application Acceleration
182 Document ID: RDWR-AD-V0231-UG1105
HTTP Persistency
Insert Cookie for HTTP Persistency
When enabled, AppDirector supports client-server persistency for HTTP where the server does not insert a cookie into the reply or when replies from all servers contain the same cookie. Persistency is maintained using cookies that AppDirector generates automatically and inserts in replies to the client.
There are 3 modes:
• Enabled
• Disabled (Default)
• Enable and Remove Cookie on Return Path: allows cookies previously inserted by AppDirector to be removed from client requests before forwarding to the server.
Select Server Per Transaction Defines whether a new server is selected per each transaction (Enabled). • Default: Enabled.
SSL Persistency
SSL ID Tracking See SSL Persistency, page 284
.
When the SSL ID Tracking parameter is enabled, AppDirector keeps track of SSL Session IDs to ensure that all sessions with the same SSL ID are served by the same server even when Server Per Session Client Table mode is used.
SSL ID Aging The amount of time a non-active client is kept in the client table (in seconds). As long as a client is kept in the client table, the client is connected to the same server. You can configure this as part of the farm configuration. Values: 1 - 65,535 seconds.
Default: 120 seconds. RADIUS Persistency
RADIUS Attribute The RADIUS attribute is required to maintain persistency for RADIUS sessions and other application sessions (for example, HTTP) according to learnt RADIUS attribute values.
Remote Authentication Dial-In User Server (RADIUS) attributes are used to define specific authentication, authorization, and accounting (AAA) elements in a user profile, which is stored on the RADIUS daemon.
Values: 0 (default - no RADIUS attribute will be learnt) - 255
Radius Secret Used for the RADIUS Connectivity Check on the Farm. When the farm is a Radius Server Farm, the Radius secret must be configured to allow access to the farm.
RADIUS Proxy Attribute
When RADIUS servers that AppDirector is managing operate as proxies and forward access/accounting requests to another RADIUS server, the RADIUS Proxy attribute allows AppDirector to ensure that the RADIUS responses are sent to the correct proxy server. This attribute must be inserted by the proxy RADIUS servers before forwarding the request and must include as the first 4 bytes the server IP in hex format.
Values: 0 (default = disabled) - 255
Parameter
Description
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 183
4.Click Set. Your configuration is set
SIP Persistency
Hash Parameter for SIP
The device can maintain client-server persistency in SIP sessions by selecting an available server based on a static hash algorithm performed either on the Call ID or Request URI.
Default: Call-ID
No Service Page
No Service Page HTTP Code
Here you can define the code that will be returned with the configured No Service Page when the farm is not available.
Values:
• 200 - OK (Default)
• 202 - Accepted
• 204 - No Content
• 205 - Reset Content
• 206 - Partial Content
• 300 - Multiple Choices
• 301 - Moved Permanently
• 302 - Moved Temporarily
• 304 - Not Modified
• 400 - Bad Request
• 401 - Unauthorized
• 402 - Payment Required
• 403 - Forbidden
• 404 - Object Not Found
• 503 - Service Unavailable
Backend SSL Backend SSL State Here you can control the back-end SSL mode per farm when performing Layer 7 farm selection. When the Layer 4 service SSL Policy defines that Back-end SSL is enabled, this parameter enables you to overwrite this for a certain farm and have clear text back-end connections.
Values:
• Override to Clear text
• Respect SSL Policy (default)
Parameter
Description
AppDirector User Guide
Traffic Management and Application Acceleration
184 Document ID: RDWR-AD-V0231-UG1105
Additional HTTP Connectivity Checks Parameters
When the HTTP page is used for connectivity checks you can can configure additional parameters:
• Acceptable HTTP Codes • Content Checks Acceptable HTTP Codes
This defines up to 10 HTTP codes that when included in server response indicate a healthy server.
To add or edit a HTTP Acceptable Response Code 1.From the AppDirector menu, select Farms > HTTP Codes. The Acceptable HTTP Codes window is displayed. 2.When adding a new code, click Create. The Acceptable HTTP Codes Create window is displayed. 3.From the Acceptable HTTP Code drop down list, select the acceptable code. 4.When editing, select the required farm. The Acceptable HTTP Codes Update window is displayed.
5.Set the parameters.
6.Click Set. The HTTP Code is added to the Acceptable HTTP Code Table
Note:You must also have at least one code on the list. The maximum number of codes or farms is 10.
Content Checks
This defines strings whose existences or absence from retrieved HTTP page indicate a healthy server.AppDirector examines the HTTP header of the server response and considers responses with the user-defined HTTP status code to indicate a healthy server. You can configure HTTP status codes to be used as acceptable responses. By default, an HTTP code of 200 indicates service availability. Servers and applications can pass health checks but if the content is not accurate, (for example, corrupt or misplaced files), AppDirector can also check for content accuracy. There are several methods including:
• using an application-level health check by using an HTTP GET request for a URL of customer choice, the load balancer can check the returned Web page for accuracy. Parameter
Description
Farm Name From the Farm Name drop down list field select a farm name.
Acceptable HTTP Code • 100 - Continue
• 200 - OK (Default)
• 202 - Accepted
• 204 - No Content
• 205 - Reset Content
• 206 - Partial Content
• 300 - Multiple Choices
• 301 - Moved Permanently
• 302 - Moved Temporarily
• 304 - Not Modified
• 400 - Bad Request
• 401 - Unauthorized
• 402 - Payment Required
• 403 - Forbidden
• 404 - Object Not Found
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 185
• scanning the page for certain keywords (shown here). • calculating a checksum and compare it against a configured value. For other applications, such as FTP, the load balancer can download a file and compute the checksum to check accuracy. To configure new dynamic content checks 1.From the AppDirector menu, select Farms > Content Checks. The Content Checks window is displayed.
2.When creating, click Create. The Content Checks Create window is displayed.
3.When updating, select required farm. The Content Checks window is displayed
4.Set the parameters.
5.Click Set. The string is added to the Content Check Table.
No HTTP Service Page
When no servers can be used for a specific session, AppDirector can reply to a Web request (to port 80) with a simple Web page, indicating that the service is currently not available. Servers that cannot be used for a session include those in Not In Service or in No New Sessions mode. The No HTTP Service Page window is configured for each farm. Each Web page is limited to 1K of HTML code. By default when AppDirector responds with No Service page, the response code is 200 OK, however this can be changed via Additional Farm Parameters. When configuring the No HTTP Service Page, the page text must be entered as one line with no line separators. Sample HTML code for a default Web page is shown here:
<HTML>
<HEAD>
<TITLE>Service Unavailable</TITLE>
</HEAD>
<BODY>
<P ALIGN=center><FONT SIZE=+2><br><br>
Service is currently unavailable. Please try again later.
</FONT>
</P>
</BODY>
</HTML>
Parameter
Description
Farm Name Name of the farm.
Search String The string you require the device to search for.
Check Mode The mode may be one of the following options:
• String Exists (default): Checks if string exists. • String is Absent: Checks if string exists. AppDirector User Guide
Traffic Management and Application Acceleration
186 Document ID: RDWR-AD-V0231-UG1105
To set the No HTTP Service 1.From AppDirector menu, select Farms > No Service Page. The No Service Page window is displayed.
2.Select a farm from the drop-down menu. 3.Select Get, Set or Delete as appropriate. OR From the AppDirector menu, select Farms > Extended Parameters. The Extended Farm Parameters window is displayed.
Notes:
>> Setting content for the page activates this feature. By default, no content is displayed for a farm. To remove this feature, select the farm and select Delete.
>> You should set this page if you want a user to get a message when the service is not available and if there is no answer to the DNS.
>> If a "No Service Page" is defined for a farm bound to a DNS Host Name Entry (as for farm www.farm123data.com), the device will reply with a DNS answer even if all servers of the farm are down. Configuring Servers
This section discusses server configuration and includes these topics:
• Physical Servers, page 186
• Application/Farm Servers, page 188
• Dispatch Methods, page 193
• Local Triangulation, page 197
AppDirector works with farm servers; logical entities that are associated with application services provided by the physical servers that run these applications. Adding and configuring servers in an AppDirector farm requires configuring the physical server parameters, then the farm parameters and finally the application parameters.
Every service is hosted on the physical server, and should be defined in the system. For each service, you can define a logical entity (a farm server) and attach it to the farm that provides this service. Configuring farm servers means organizing servers according to how you use their services. Physical Servers
When you add hardware elements to the network and define them as servers, every service is hosted on the physical server, and should be defined in the system. Before setting up a physical server, you must establish IP connectivity of the server to AppDirector and to the host. A physical server that provides multiple services may participate in multiple farms. In each farm, this physical server is represented by a unique farm server that provides one specific service. Each service is associated with a farm, and you can define its load balancing scheme and customized Health Checks. In this way, if one of the services provided by a physical server is not available, other services can still be used.
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 187
To configure a machine in the server farm 1.From the AppDirector menu, select Servers > Physical Servers. The Physical Servers window is displayed.
2.Select the server you want to edit. The Physical Servers Update window is displayed.
3.Set the parameters.
Parameter
Description
Server Name Physical server identification.
Admin Status User defined management status of the server. Valid values are:
• Enabled (Default) : The server is active and ready to reply to new requests for service.
• Connections-Shutdown: No new connection will be forwarded to the server, even if persistency information (client IP or Layer 7 session id) indicates this server. Traffic on existing connections is still forwarded to the server until the connection is closed or inactivity Aging Time is reached. • Sessions-Shutdown: New connections that do not belong to an existing session on the server will not be forwarded to the server. An existing session is defined by persistency information (client IP or Layer 7 session id) that indicates this server. New connections belonging to an existing session are still forwarded to the server until all connections related to this session are closed and the Layer 7 session id reaches its Aging Time. Recovery Time Period of time, in seconds, during which no data is sent to the physical server after the server recovers from a failure. When a server's operational status is changed from inactive to active (dynamically or administratively), the physical server is not eligible to receive clients for this period of time. Recovery Time applies to all servers in all farms that share the same Server Name (the physical server name that was defined above). Once this time has elapsed, the physical server becomes eligible to receive client requests.
When the Recovery Time parameter is set to 0 (default), the server is eligible to receive client requests immediately after changing its operational status from inactive to active.
Maximum Value:4294967295 seconds
Default: 0 seconds
Warmup Time (seconds)
Time, in seconds, after the server is up, during which clients are slowly sent to this physical server at an increasing rate so that the server can reach its capacity gradually. AppDirector internally raises the server weight for this period of time, until the server's weight is the 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.
Default: 0 seconds
Note: Not applicable for farm servers where load balancing decision is made using the Cyclic Dispatch Method.
AppDirector User Guide
Traffic Management and Application Acceleration
188 Document ID: RDWR-AD-V0231-UG1105
4.Click Set. Your configuration is set
Application/Farm Servers
AppDirector works with server farms rather than with individual servers. An AppDirector farm is a group of networked servers that provide the same service. Utilizing multiple servers organized in a farm accelerates the service response time and improves overall performance.
An application server (also called farm server) is identified by the name of the farm it belongs to, the IP address of the server and the server port. The server name is mandatory and identifies the physical server providing the service. A single application server can be included in a farm several times, with a different Server Port number for each instance. For example, an HTTP web server might use ports 8080, 8081, and 8082. To add or edit an Application/Farm server to a server farm 1.From the AppDirector menu, select Servers > Application Servers > Table. The Server Table window is displayed.
2.Click Create. The Server Table Create window is displayed.
Connection Limit Maximum number of simultaneous users that can be directed to the physical server. This depends on the farm’s Sessions mode (see Client Table Sessions Modes, page 291
). When the limit is reached, new requests are no longer directed to this server. All open sessions are continued.
When this is configured to 0 (default), this mechanism is disabled for this physical server and there is no user number limit.
Note: When configuring the physical server, ensure that the Connection Limit in the farm servers with the same Server Name is lower than or equal to the Connection Limit in the physical server. The total number of active sessions that run simultaneously on the farm servers must not be higher than the Connection Limit value defined on the physical server.
Maximum number of application server connections.
You can configure a trap to be sent if a certain percentage of the connection limit configured for the server is exceeded.
Default: 0, (no maximum)
Peak Load Maximal number of frames per second dispatched to server since last reset.
Attach Users The total number of currently active users attached to this server.
Frames Rate Number of Bytes load rate per second dispatched to server.
Frames Load Number of Bytes load per second dispatched to server.
Conn Limit Reached The limit for the maximal number of client sessions which can be opened on this server has been reached.
Parameter
Description
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 189
3.Set the parameters.
Parameter
Description
Server Name Application server identification, that must be unique within a Farm. Farm Name The name of the farm to which this application server belongs.
Server Address The IP address of the physical server that provides this application.
The address is defined for each application server, so that a physical server can have several IP addresses. Server Port Allows you to configure several application servers belonging to the same farm by using the same physical server with the same IP address. with a different Server Port number for each instance. For example, an HTTP web server might use ports 8080, 8081, and 8082. If Server Port is set to None, only one instance of the application associated with the Server Address is available as a farm server in the current farm.
Server Description A free text field where you can type a description for each server. Maximum Length: 80 characters.
The server description is not saved in the configuration file. If you export the configuration file and upload it, the server description is not saved.
Admin Status Admin Status is the user defined management status of the server that you can change at any stage of server’s configuration or operation. The following options are available:
• Enabled: The server is enabled to receive new requests.
• Disabled: The server is not active. When setting the Admin Status to Disabled, AppDirector removes all entries relevant to this server from the Client Table, stops sending new requests to this server, and disconnects all connected clients.
• Connections-Shutdown: No new connection will be forwarded to the server, even if persistency information (client IP or Layer 7 session id) indicates this server. Traffic on existing connections is still forwarded to the server until the connection is closed or inactivity Aging Time is reached. • Sessions-Shutdown: New connections that do not belong to an existing session on the server will not be forwarded to the server. Existing session is defined by persistency information (client IP or Layer 7 session id) that indicates this server. New connections that belong to an existing session are still forwarded to the server until all connections related to this session are finished and Layer 7 session id reaches its Aging Time. Before performing maintenance procedures, set Admin Status to either Connections-Shutdown or Sessions-Shutdown. Start maintenance procedures when there are no more active connections on the server.
Operational Status Operational status of application on server.
• Active: server is active • Not In Service: server is or will become inactive. Existing sessions will be redirected to other servers. • No New Sessions: server will receive no new sessions. Existing sessions are allowed to complete.
Physical Server Name Name of the physical server to which the server belongs.
AppDirector User Guide
Traffic Management and Application Acceleration
190 Document ID: RDWR-AD-V0231-UG1105
Forwarding Parameters
Farm Name for Local Farm
This allows you to configure the farm whose load and availability should be the load and availability of this server. This parameter is mandatory for servers of type Local Farm and it is not configurable for any other type of server. You must configure the correct Farm Name in the local farm server. If no Farm Name is configured the server is Not In Service. Redirect To URL The URL to which traffic is redirected when HTTP, RTSP or SIP redirection by name is performed (Redirection by Name must be configured in the farm redirection settings). This option is available for:
• Global License
• Redirect to Self capability.
Type Server types are:
• Regular (Default): A local server. • Local Triangulation: A local server that sends response directly to client, bypassing AppDirector. Sending responses in this way reduces the number of hops through which the reply packet passes, improving the response time. In addition, the traffic passing through AppDirector is reduced, since most incoming requests are rather small and outbound traffic represents the bulk of data exchanged between clients and servers. When working in the Local Triangulation mode, the inbound traffic must flow through AppDirector as in the regular configuration. The response from server to client, however, is sent directly to the client, without passing through AppDirector. The client can be located on the same network as AppDirector and the server, or it can be located behind the router. Server Port must be set to None for Local Triangulation servers. Local Triangulation servers are also known as Loopback servers. • Distributed AppDirector (Global License Only): A remote AppDirector which manages another server farm providing the same service in another location. AppDirector devices exchange dynamic information about the load. Clients’ requests are redirected to the nearest and most available site using various redirection methods.
Note: The Server Port must be set to None for Distributed AppDirector servers.
• Local Farm: The server is a farm configured on this AppDirector. AppDirector utilizes the Redirect to Self feature. The farm regards the Local Farm as a regular server, except that clients can be sent to the Local Farm only using the HTTP and DNS redirection.
• Remote Server (Global License Only): A stand-a-lone server that is placed at a different site than AppDirector. Traffic is redirected to a Remote Server using all redirection methods except for Global Triangulation. The server port can be set to a value other than None for remote servers only if the farm’s redirection mode includes HTTP, SIP or RTSP. Otherwise all the remote servers with the same IP are considered a single server.
Parameter
Description
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 191
Load Balancing Parameters
Weight The weight of the server in a farm is the server’s priority or importance relative to the other servers in the farm. You can define that a particular server in a farm has more weight than other servers, so more traffic is forwarded to this server than to other servers. Server weights operate as ratios. For example, when the Dispatch Method is set to Least Number of Users, the weights determine the ratio of the number of users between the servers. If the Least Amount of Traffic method is used, the weights determine the ratio of the amount of traffic between the servers. A server with weight 2 receives twice the amount of traffic as a server with weight 1. Values: 1(default) - 10,000
Response Threshold This defines the number of milliseconds where the server may reply to the GET command. When the server's reply takes longer, the status of the logical server is set to No New Sessions.
Default: 0
Bandwidth Limit Maximum amount of bandwidth in Kbps allowed for this application server. If traffic through the server exceeds the configured limit for any given second, AppDirector drops excess packets. Note: Bandwidth Limit is measured in Kbps, so 1Mbps is represented with a bandwidth limit of 1000. A value of 0 = no bandwidth limit.
Default: 0 (No 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.
Connection Limit This is the maximum number of users that can be directed to the application server. The number of users allowed depends on the Sessions Mode selected: • When the Entry Per Session or Server Per Session modes are selected, the number of users is the number of sessions on this server.
• When the Regular mode is selected, the number of users is the number of client IPs whose sessions were forwarded to this server. Default: 0 (disabled for this server and no user number limit).
Values: 0 - No maximum Note: The Connection Limit parameter can be exceeded when an existing client opens a new session and, according to the Sessions mode, the session uses the same server. This applies when using the Entry Per Sessions mode. To allow exceeding the Connection Limit parameter, you can enable the Connection Limit Exception parameter, which defines how AppDirector behaves when there is a conflict between Connection Limit and persistency scheme. The Connection Limit Exception parameter is defined for each farm.
Parameter
Description
AppDirector User Guide
Traffic Management and Application Acceleration
192 Document ID: RDWR-AD-V0231-UG1105
4.Click Set. Your configuration is set.
Tracking Farm Servers
To enable tracking of all the farm servers associated with the specific physical server, farm servers are organized in groups, identified by the server name. All farm servers with the same server name are considered by AppDirector as running on the same physical server. Farm server parameters are configured per farm and per server, and control the process of providing a particular service. Physical server configuration is performed for each server name, and applies to all farm servers on the same AppDirector with the same name, implying they all run on the same machine. Notes:
>> For Local Farm servers, the server IP address must be the Layer 4 Policy VIP that points to the local farm.
>> FTP traffic cannot be load balanced between multiple instances of the application. The Server Port parameter of an FTP server must be set to 0.
>> All farm servers with the same IP and belonging to the same farm must have the same server type. Redundancy Parameters
Operation Mode Determines whether the server is a backup server or not.
Regular (Default): The server's health is checked, as long as it is available the server is eligible for receiving client requests. Backup: The server's health is checked, but the server does not receive any client requests. The server becomes eligible for client requests when all the servers in the Regular mode have failed.
Backup Preemption Determines when the failover mode between the server and its specific backup address, after the specific backup server took over.
• Enabled (default): Once the server becomes active again, it takes over from the specific backup server.
• Disabled: Specific backup server remains active as long as it is available, even after this server recovers from failure.
This is relevant only when a Backup Server Address is configured.
Backup Server Address
Defines another server in this farm that specifically backs up this application server. If this application server fails, the dedicated backup server is used for all sessions of the failed server.
Default : 0.0.0.0, indicating that no specific backup server is defined.
Note: A Backup Server Address can be used with Backup Preemption. Client NAT
Client NAT Defines whether Client NAT should be performed on sessions to this server. • Enable
• Disable
Client NAT Address Range
Defines the Client NAT IP range to be used for NATting sessions to this server. Also see Client NAT Quick Setup, page 300
.
Parameter
Description
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 193
>> If the server type of one of these farm servers is changed, the server type of all farm servers sharing the same IP and farm name as the changed server will also automatically change.
>> The server port must be specified for AppDirector to recognize which port the application is running. >> If the server port is disabled then AppDirector cannot change the destination port and automatically uses the Layer 4 VIP port instead
Dispatch Methods
Dispatch Methods are the load balancing algorithms that determine how client requests are distributed between servers in a farm. AppDirector receives requests for service from clients and decides to which server to direct each request. During this process, AppDirector finds the best server to provide the requested service. The criterion according to which AppDirector selects the best server is defined by the Dispatch Method.
You can define the Dispatch Method during the process of AppDirector Farm configuration, according to the farm characteristics and users’ needs. This may differ between applications, depending on the service that the particular farm provides. For example, the number of users is a significant factor for a Web farm, while the amount of traffic can be more important for an FTP farm. The following Dispatch Methods are available:
Cyclic
When this is selected, AppDirector forwards traffic dynamically to each sever in a round-robin fashion.
Weighted Cyclic
This method combines the Cyclic dispatch method with server weight considerations. The weight of a server in a farm is the server’s priority, or the server’s importance. You can define that a particular server in a farm has more weight than other servers. Therefore, more requests for service are forwarded to this server than to servers with a lower weight. When the Weighted Cyclic dispatch method is selected, AppDirector distributes clients’ requests for service in the round-robin manner, taking into consideration the weight of servers in that farm. Explicitly, every new session is distributed to the next server up to the server weight. For example, if one server has a weight of 2 and another server has weight of 5, the first two sessions are sent to #1, the next five are sent to #2, sessions eight and nine are sent to #1 again, and ten to fourteen are sent to #1 etc. For more information about servers’ weight, see Configuring Servers, page 186
.
Fewest Number of Users
This is used when a new request for service is sent to an AppDirector Virtual IP address. It is directed to the server with the least number of sessions at that given time. Server weight is also considered.
Note:The number of sessions is defined by the number of active Client Table entries that contain information about the sessions in which this server participates (see Client Table Management, page 287
).
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.
AppDirector User Guide
Traffic Management and Application Acceleration
194 Document ID: RDWR-AD-V0231-UG1105
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 AppDirector’s Client Table for all traffic forwarded to that server.
Least Amount of Traffic - Local
This method is used when the same servers participate in multiple farms. AppDirector looks for the server with the least amount of traffic only within the farm that is currently addressed by the client. Traffic of other farms is not considered. Server weight is also considered. Response Time
This method allows AppDirector to select the fastest server in the farm. When this method is used, the load balancing process is based on choosing the least loaded server as calculated by the Response Level measured by the Health Monitoring module.
The Health Monitoring module enables users to track the round trip time of Health Checks. The device keeps a Response Level indicator for each check. The Response Level is the average ratio between the response time and the configured Timeout. This average is calculated over a number of samples as defined in the Response Level Samples parameter. A value of 0 in the Response Level Samples parameter disables the parameter; any other value between 1-9 defines the number of samples. The Response Level Samples parameter can be used in the Health Checks in which the Measure Response Time parameter is enabled. Server weight is also considered.
Note:If all servers in the farm have the same response level, AppDirector will choose one of the servers all the time according to its IP address. To configure Response Time Dispatch Method 1.Enable the Health Monitoring module for this farm, and set the Response Level Samples parameter and the Measure Response Time parameter for each Health Check.
2.Set the farm’s Dispatch Method parameter to Response Time.
Hashing
When this method is applied, AppDirector selects a server for a session using a static Hash function. This method enables AppDirector to repeatedly direct requests from the same client to the same server within a farm even after the client entry has aged, as long as the server is still in service. This Dispatch Method also provides support for reverse proxy Web farms, avoiding data replication among the proxy servers.
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 195
A static Hash function enables AppDirector to choose the server for a session on the basis of the session’s information. The input for the Hash function is usually the Client IP only. A formula is applied to this IP address. The output that is received is a numeric value. Note:When a Hash result indicates to use a server with the status of Not in Service, a second Hash is used to select an available server for the session.
SNMP Based Dispatch Global Settings
You can use the Load Balancing Algorithms Global Settings window to set the Server SNMP port.
To define the SNMP Based Dispatch Global Settings 1.From the AppDirector menu select SNMP Based Dispatch > Global. The Load Balancing Algorithms Global Settings window is displayed.
2.Set the parameter.
3.Click Set. Your preference is recorded.
Private Parameters (Private-1 and Private-2)
This dispatch method could be called "Load Balancing by any parameter that you want". You only require an SNMP agent running on your servers that can respond with whatever information you need to load balance. This can be CPU utilization, memory utilization, a number of active TCP connections or disk free space, for example.
Private 1 and Private-2 work in a similar fashion. They allow more than a single set of SNMP OIDs without making a dynamic table. Therefore, you can define Private-1 and use it in one farm and then define Private-2 and use it in another.
AppDirector polls each server in a farm that uses Private-1 or Private-2 with SNMP GET for the OID(s) that you defined. The replies are normalized into a percentage scale 0.100% and applied as a dynamic weight to the server's number of client table entries when the load balancing decision is made. This means that when Private-1 or Private-2 are used, AppDirector uses the Least Number of Users dispatch method.
When the Private-1 or the Private-2 Dispatch Method is selected, AppDirector queries the farm’s 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.
Parameter
Description
Server SNMP Port Server SNMP Port used to poll the relevant statuses from the servers.
Default: 161
AppDirector User Guide
Traffic Management and Application Acceleration
196 Document ID: RDWR-AD-V0231-UG1105
To configure private parameters load balancing 1.From the AppDirector menu, select SNMP Based Dispatch > Private Parameters. The Private Parameters window is displayed.
2.Set the parameters. 3.When updating Private Parameters, select the desired server. The Private Parameters Update window is displayed which contains the above parameters:
Windows NT Load Balancing Parameters
There are two Windows NT servers load balancing algorithms. These parameters are used to load balance the users of the farms that are configured with nt-1 or nt-2 dispatch methods. You use the Windows NT Parameters window to configure the Windows NT load balancing algorithm. Parameter
Description
Serial Number Serial no. of the scheme. Scheme no. 1 is used for dispatch method private-1, etc.
Check Period {sec} Time interval between queries for the requested parameters.
Var 1 Object ID SNMP ID of the first private variable to check.
Var 1 Weight Relational weight for considering value of first parameter.
Var 2 Object ID SNMP ID of the second private variable to check.
Var 2 Weight Relational weight for considering value of second parameter.
Retries Describes how many unanswered requests for a variable will make it be ignored in the load balancing decision.
Community Community name to use when addressing the server. Var 1 Mode Measuring percentage free or percentage busy of first parameter.
• Percent Free: Variable value specified in Var1 Object ID describes the percentage still free.
• Percent Busy: Variable value specified in Var1 Object ID describes percentage currently busy. Var 2 Mode Measuring percentage free or percentage busy of the first parameter.
• Percent Free: Variable value specified in Var2 Object ID describes the percentage still free.
• Percent Busy: Variable value specified in Var2 Object ID describes percentage currently busy. AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 197
To configure Windows NT load balancing 1.From the AppDirector menu, select SNMP Based Dispatch > Windows NT Parameters. The Windows NT Parameters window is displayed.
2.Set the parameters.
3.When updating Windows NT Parameters, select the desired server. The Windows NT Parameters Update window is displayed which contains the above parameters.
4.Click Set. The algorithm is set.
Local Triangulation
The Local Triangulation mode provides the ability to send server’s responses directly to the client. Sending responses that way reduces the number of hops through which the reply packet passes, improving the response time. In addition, the traffic passing through AppDirector is reduced, since most incoming requests are rather small and outbound traffic represents the bulk of data exchanged between clients and servers. 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. Parameter
Description
Serial Number Serial number of the scheme. Scheme number 1 is used for dispatch method nt-1, etc.
Check Period Time interval between queries for the frequently updating parameters (number of open sessions, amount of traffic).
Open Session Weight Relational weight for number of active sessions on the server.
Incoming Traffic Weight
Relational weight for amount of traffic coming into the server.
Outgoing Traffic Weight
Relational weight for amount of traffic going out of the server.
Regular Check Period Time interval between queries for other less dynamic parameters (average response time, limits on users and TCP connections).
Response Weight Relational weight for average response time of the server.
Users Limit Weight Relational weight for limit on number of logged in users on server.
TCP Limit Weight Relational weight for limit of TCP connections to the server.
Retries Defines how many unanswered requests for a variable will make it be ignored in the load balancing decision.
Community Community name to use when addressing the server.
AppDirector User Guide
Traffic Management and Application Acceleration
198 Document ID: RDWR-AD-V0231-UG1105
Note:Layer 7 Switching, which requires Delayed Binding, is not supported when using Local Triangulation. When using Delayed Binding, AppDirector acts as a reverse proxy between clients and server.
Note:AppDirector determines the VLAN tag that is used according to the destination IP of the packet after AppDirector has made all the required modifications to the packet. When using Local Triangulation, AppDirector forwards packets to servers with the destination IP of the farm. However, the tag must be set according to the subnet of the servers.
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 199
Configuring Local Triangulation
Configuring the Local Triangulation mode involves the following steps:
1.Setting up farm servers to operate in Local Triangulation mode.
2.Enabling this capability in the servers themselves.
Farm servers can be configured to operate as Local Triangulation type servers. You can add Local Triangulation type servers and Regular type servers to the same farm. Local Triangulation is effective for one-leg topologies and reduces traffic on the AppDirector interface. The process of defining Local Triangulation is dependent on the operating system installed on the farm servers.
Setting up Local Triangulation on the physical servers requires adding a loopback adapter. A loopback address is a valid IP address assigned to a server. The server does not respond to ARP requests destined to the loopback address. The address assigned to the loopback adapter is the address of the Virtual IP. The server responds directly to the client with the AppDirector virtual address, eliminating the need for server-to-client traffic to flow through AppDirector. Farm Connectivity Checks for Local Triangulation Servers
Farm connectivity checks defined for Local Triangulation servers use the Layer 4 Policy VIP as the Destination IP. When a farm that includes a Local Triangulation server is associated with more than one Layer 4 Policy VIP, AppDirector checks the server using the first VIP that was found in the Layer 4 Policy. Do not include the same Local Triangulation server in a farm associated with multiple VIPs. If the same servers serve multiple VIPs, include these servers in multiple farms, and associate each farm with a single Layer 4 Policy VIP. Health Monitoring Checks for Local Triangulation Servers
When defining Health Monitoring checks for a Local Triangulation server, you can set the Destination IP for a check to the Layer 4 Policy VIP. When a farm that includes a Local Triangulation server is associated with more than one Layer 4 Policy VIP, you can define multiple Health Checks using different VIPs. If there is a problem, since the relations between check definitions can be only AND or OR, it is impossible to identify the service (which Layer 4 Policy VIP) in which the problem occurred from the check results. Therefore, when a single server is available via multiple VIPs, multiple Health Checks are associated with the server, but there is no association between the Health Checks and the VIPs. For further information regarding Health Monitoring checks, see Health Monitoring Check Table, page 355
.
Traffic Management Policies
This section discusses how AppDirector Traffic Management enhances application delivery via Server Load Balancing and Application Acceleration and includes these topics:
• Layer 4 Policies, page 200
• Layer 4 Policies Lookup Mechanism, page 203
• Layer 4 Policy Statistics, page 204
• HTTP Policies, page 204
AppDirector User Guide
Traffic Management and Application Acceleration
200 Document ID: RDWR-AD-V0231-UG1105
Layer 4 Policies
A Layer 4 Policy allows you to set a single point of entry, i.e., a single Virtual IP address, for a variety of application services, allowing different groups of users to receive services according to their individual needs.
All the VIPs managed by AppDirector are defined under Layer 4 Policies. When AppDirector receives the first packet of a session destined to a Virtual IP address, it searches for a Layer 4 Policy that matches the Layer 4 Protocol, Destination port, Source IP, etc. Then, based on this information, AppDirector selects the farm allocated to this service and the best server for the task from that farm, and forwards the packet to that server.
AppDirector supports both IPv4 and IPv6 VIPs. Any type of VIP can be attached to farm or farms with either IPv4, IPv6 or mixed IPv4 and IPv6 servers. When the IP version of the VIP is different than the IP version of a server attached to it (via a farm) AppDirector performs IP gateway functionality and translates IPv6 front-end session to an IPv4 back-end session or vice-versa.
Note:For FTP, there is no need to create a port 20 Layer 4 policy for the active FTP-data connections. AppDirector handles active and passive data connections to the same VIP as the FTP-control Layer 4 policy automatically. FTP-data exists as an application if a direct active FTP-data connection to a port other than 20 occurs. In addition to farm selection, the Layer 4 policy also defines application acceleration policies to be applied on traffic matching the Layer 4 policy, when required. Application acceleration policies include SSL offload configuration, compression and caching rules and HTTP multiplexing activation.
To set up or update a Layer 4 Policy 1.From the AppDirector menu, select Layer 4 Traffic Redirection > Layer 4 Policies. The Layer 4 Policies window is displayed.
2.Click Create, OR select the Layer 4 Policy Name if you wish to update. The Layer 4 Policy Create window is displayed
3.Set the parameters.
Parameter
Description
Layer 4 Policy Name A unique name identifying the Layer 4 Policy.
Policy Classifiers
Virtual IP Type (Read Only)
The Virtual IP type on which AppDirector intercepts distributed traffic using the triangulation method.
Values: IPv4 or IPv6.
Virtual IP The IP address through which clients access the application service/s that this Layer 4 policy processes.
Notes:
• When you enter a Virtual IP address in IPv4 format, the parameters Source IP From/To accept IPv4 type addresses.
• When you enter a Virtual IP address in IPv6 format, the parameters Source IP From/To accept IPv6 type addresses.
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 201
Layer 4 Protocol Layer 4 protocol for which the policy provides services. Values include:
• TCP (Default)
• UDP
• ICMP
• SCTP
• Any: Any IP protocol, including TCP, UDP and ICMP
• Other: Any IP traffic that is not TCP, UDP or ICMP
Layer 4 Port Destination Layer 4 port for the configured Layer 4 Protocol.
Default: Any.
Application The Application parameter allows using custom TCP or UDP ports for applications that require special handling, such as HTTP, HTTPS, FTP, SIP, etc. For example, use port 2100 for FTP Control Channel. For well-known protocols, such as 80 for HTTP, there is no need to specify the application. 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.
Applications supported include:
• Any (Default)
• FTP Control
• HTTP
• HTTPS
• PING
• REXEC
• RSH
• SCTP
• SIP
• RTSP
• TS COOKIE
• RADIUS
• TCP
• TFTP
• UDP
• Virtual IP Interface
• MH-SCTP (MultiHoming SCTP)
• Generic-SSL (with Layer 4 Port defined)
Source IP From Starting address of range of client IPs for which policy provides services.
Source IP To Last address of range of client IPs for which policy provides services.
Segment Name Name of segment to which this Layer 4 policy belongs. Also see Segmentation with AppDirector, page 416
.
Policy Actions
Farm Name Farm providing services for traffic matching this policy. If a Layer 7 policy is configured, this parameter is not available.
Default: None.
Layer 7 Policy Name Select from predefined policy. Determines that Layer 7 farm selection must be applied to the traffic that matches the Layer 4 Policy. Default: None.
Note: This feature is HTTP dependent and cannot be used with Generic-SSL offloading, if selected in the Layer 4 Policy Application. Parameter
Description
AppDirector User Guide
Traffic Management and Application Acceleration
202 Document ID: RDWR-AD-V0231-UG1105
4.Click Set. Your configuration is set.
HTTP Policy Defines HTTP traffic related parameters both in terms of classification and traffic handling. A default HTTP policy is automatically linked to any new L4 policy. Also see HTTP Policies, page 204
.
TCP Policy Select a predefined TCP Policy to enable back-end connection pooling for a generic TCP. This enables you to reuse existing TCP connections to back-end application servers, reducing both the handshake time and processing overhead of establishing new TCP connections on the back-
end application server to serve subsequent requests.
Default: None.
SSL Policy Select a predefined SSL policy to enable SSL offload for traffic matching the Layer 4 policy. An SSL policy specifies SSL related behavior such as service server certificate, allowed Cipher suites and more. See SSL Policies, page 211
for details.
Default: None. Caching Policy Select a predefined Caching policy to enable caching for HTTP traffic matching the Layer 4 policy. See Caching Policies, page 238
for details.
Default: None
Note: This feature is HTTP dependent and cannot be used with Generic-SSL offloading, if selected in the Layer 4 Policy Application. Compression Policy Select predefined Compression policy to enable compression on the HTTP traffic matching the Layer 4 policy. Also see Compression Policies, page 244
.
Default: None
Note: This feature is HTTP dependent and cannot be used with Generic-SSL offloading, if selected in the Layer 4 Policy Application. Client Authentication Policy
Select predefined Client Authentication policy to enable Client authentication for SSL offload on HTTPS traffic matching the Layer 4 policy. For details, see Client Authentication Policies, page 215
.
Default: None
Policy Settings
Redundancy Status Defines whether this policy is active for main or backup device. Values: Primary (default) or Backup.
Notes:
• This is not relevant when operating in an Active-Backup VRRP redundant configuration.
• The Layer 4 policy redundancy status has no affect on VRRP configurations. In these configurations, the status is derived from devices associated with the VRID which is bound to the policy.
Backend Encryption Port (AppXcel Users)
For users who also have an AppXcel device, this parameter sets the port to which an AppXcel device sends the backend host encrypted traffic. The Backend Encryption Port must be set to the same value as the Server Port in the tunnel defined on AppXcel.
Parameter
Description
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 203
Layer 4 Policies Lookup Mechanism
When AppDirector receives a packet where the Destination IP address is a Virtual IP address, AppDirector performs the following steps:
• AppDirector searches its Client Table for a matching entry. The match can be either a full Layer 4 match for a farm whose Sessions mode is different than Regular mode, or a match of Source IP, Destination VIP and Destination port. If a matching entry is found, the packet is forwarded according to the existing server selection. If no matching entry is found, AppDirector performs Step 2.
• AppDirector searches its Layer 4 Policies to find an entry that matches the traffic This is performed according to existing farm selection in the following order:
1.First AppDirector searches for a full match between the Destination IP, Destination IP Protocol and Destination Port fields of the incoming packet parameters and Layer 4 Policy Virtual IP, Layer 4 Protocol, and Layer 4 Port parameters.
2.If no match is found, AppDirector re-scans the Layer 4 Policies again, looking for a full match between the Destination IP address and Destination IP Protocol fields of the incoming packet, and Layer 4 Policy Virtual IP and Layer 4 Protocol parameter, which include TCP, UDP, ICMP, Any or Other. 3.If no match is found, AppDirector re-scans the Layer 4 Policies looking for a match between the Destination IP address of the incoming packet and the Layer 4 Policy Virtual IP parameter.
4.If there is no match, the packet is discarded.
5.If the entry is matched, AppDirector performs an additional search in the Layer 4 Policies Table, checking whether the incoming packet’s Source IP fits into the Layer 4 client IP address range.
6.This search is applied only to entries that were matched in Step 2. 7.The Layer 4 policy redirects the traffic to the proxy if SSL/Cache/Compression/Client Authentication policies are attached to it.
8.The traffic from the Proxy is then redirected back to the AppDirector to an internal Layer 4 policy and from there to a farm and server.
9.After a policy is matched, a server is selected within the farm associated with the matched policy, and the packet is forwarded to that server.
10.If the Layer 4 Policy is mapped to a Layer 7 Policy, the Delayed Bind is activated. When AppDirector receives enough information from the HTTP Header, a farm can be selected according to that Layer 7 Policy. Note:The order of configured policies has no impact; the most specific policy is always matched, using the above logic.
AppDirector User Guide
Traffic Management and Application Acceleration
204 Document ID: RDWR-AD-V0231-UG1105
Layer 4 Policy Statistics
A Layer 4 Policy is a single point of entry into your network that provides you with a variety of the application services allowing different groups of users to receive services according to their individual needs. The Statistics window allows you to view the statistics of a particular policy. To view statistics for Farms 1.From the AppDirector menu, select Layer 4 Traffic Redirection > Statistics. The Layer 4 Policy Statistics window is displayed.
2.You can view these read-only parameters:
3.Click a Virtual IP of the desired policy. The Layer 4 Policy Statistics Update window is displayed with the statistics on the policy.
HTTP Policies
Serving high numbers of concurrent users requires Web Servers to handle large volumes of connections, which can exhaust Server connection capacity, and affect clients Quality of Experience (QoE). To lower the connections volumes AppDirector offers the option for multiplexing HTTP connections, thus serving multiple clients over much smaller number of server connection and ensuring short response time by Server's, which leads to improving clients QoE.
Since HTTP policy is compulsory in most Layer 4 policies (any policy that is port 80 or 443 or application HTTP or HTTPS), there is a "Default" HTTP policy that you can configure that is attached to any new Layer 4 policy created.
HTTP Multiplexing
HTTP request multiplexing (connection reuse) inspects and load balances HTTP requests and provides server offload via request multiplexing. You can use the HTTP multiplexing approach to distribute HTTP requests more intelligently across a farm. Parameter
Description
Virtual IP A single point of entry through which clients can access a variety of application services is called Virtual IP address (VIP).
Layer 4 Protocol The Layer 4 protocol used by the relevant policy. Values include:
• TCP (Default)
• UDP
• ICMP
• SCTP
• Any: Any IP protocol, including TCP, UDP and ICMP
• Other: Any IP traffic that is not TCP, UDP or ICMP
Layer 4 Port Destination Layer 4 port for the configured Layer 4 Protocol.
Default: Any.
Source IP From Starting address of range of client IPs for which policy provides services.
Total Matches Displays total number of packets that matched the Layer 4 Policy.
Last Second Matches
Up to the second update on policy matches. AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 205
HTTP Multiplexing as defined here, includes a pool of Back-End connections utilized to serve the Front-End connection. These connections are re-used whenever an idle connection is available for the required server. If there is no idle connection at the request time, a new connection with the Back-End server is set. Persistent Layer 7 Switching Process
Using HTTP 1.1, a client can send multiple requests for service over a single TCP connection. AppDirector with Persistent Layer 7 Switching supports full inspection of all HTTP requests within the same TCP connection. The requests for service sent using HTTP 1.1 can be forwarded by AppDirector to the required farms and servers. AppDirector with Persistent Layer 7 Switching has the ability to forward requests for service to different servers without closing the TCP connection with the client when using the following AppDirector mechanisms:
• Layer 7 Policies for farm selection.
• Session IDs for server persistency.
During persistent Layer 7 Switching, AppDirector constantly inspects all HTTP requests and ensures that an appropriate farm/server handles each request. This is transparent to the client and saves system resources because AppDirector keeps a single TCP connection with the client. The process includes the following steps:
1.A client sends SYN towards AppDirector Layer 4 Policy VIP.
2.AppDirector performs a TCP handshake with the client to receive the HTTP request. 3.AppDirector analyzes the GET request’s data and selects a farm/server according to the first request. 4.AppDirector initiates a TCP handshake with the server and forwards the traffic to it.
5.AppDirector inspects further requests over the same TCP connection. 6.When a new farm or server is required, AppDirector opens a new TCP connection with the server. Note:Persistent Layer 7 Switching sessions are not mirrored to a redundant AppDirector.
Persistent Layer 7 Switching and NAT
When Persistent Layer 7 Switching is configured for the Layer 4 Policy in the Complete and Overwrite or Complete and Maintain modes, the same physical server can reside in more than one farm under the same Layer 4 Policy. In such a case, Client NAT must be used on each farm
Persistent Layer 7 Switching - Per Transaction Persistent Layer7 switching can also be used to distribute individual requests from the long lived TCP sessions across multiple servers. This is configurable using a farm configuration flag: Select Server Per Transaction. • When Select Server Per Transaction is set to Enabled: AppDirector selects a new server for each transaction in the same connection. Explicitly -when server persistency is not used or when the Persistency Parameter is not present in the request. • When Select Server Per Transaction is set to: Disabled (default): AppDirector uses the same server for a connection, unless a different farm is selected by Layer 7 policy, or a different server is required according to server persistency (DSID). The flag is applicable only when Sessions Mode is set to Select Server Per Session, and is ignored otherwise. You should use Select Server Per Transaction in cases where there is very little number of long TCP connections. AppDirector User Guide
Traffic Management and Application Acceleration
206 Document ID: RDWR-AD-V0231-UG1105
Configuring HTTP Policies
The HTTP Policy defines the following parameters 1.HTTP Layer 7 classification parameters - relevant only when a Layer 7 policy is attached to the Layer4 policy.
2.HTTP Connection Handling parameters:
a.How to handle back-end connections when performing Layer 7 processing on HTTP 1.1 traffic (multiple requests per connection on the client side) - Layer 7 Persistent Switching
b.Whether to activate HTTP multiplexing
A default HTTP policy is automatically attached to any Layer 4 Policy.
Note:To enable multiplexing in a HTTP Policy, you must first configure Client NAT, page 297
.
To configure HTTP Policy 1.From the AppDirector menu, select Layer 4 Traffic Redirection > HTTP Policies. The AppDirector HTTP Policies window is displayed.
2.Set the parameters.
Parameter
Description
Policy Name (Mandatory)
A unique policy name.
Default: empty.
Classification
POST Classification Input
Defines whether AppDirector inspects the HTTP header or body for the content-based farm selection. HTTP POST Classification Input can have the following values: • Header (Default): Information only from HTTP Header is used for farm selection using Layer 7 Policies. This mode can be used when all requests, including POST, are classified according to the HTTP Header only, not by message body. • Body: For POST requests, message body is used for farm selection using Layer 7 Policies. This is recommended when traffic needs to be classified according to information in the message body only, as it provides better performance (as only the relevant part of the request is classified). • Header and Body: For POST requests, message body and header are used. Note: For all HTTP methods except POST, only the HTTP header is used.
Bytes of Request to Read
Specifies how deep into the HTTP request AppDirector searches for the content specified in the predefined Layer 7 Policy methods. AppDirector searches for defined methods until the end of the HTTP Header.
Maximum: 64 Kbytes (default)
Note: This parameter is also related to the response (when learning DSIDs).
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 207
HTTP Normalization Enables or disables normalization of URLs in HTTP requests, before parsing the HTTP request itself. It includes these options: • Disable (Default)
• Decode% (Hexadecimal) - For example, http://
%77%77%77%2e%72%61%64%77%61%72%65%2e%63%6f%6d
/ would be www.radware.com. • Normalize directory traversals ('.' and './')
• Remove double slashes - '//'
• Convert DOS '\' to '/'
• Remove NULL characters '%00'
Note: AppDirector uses the normalized request for the Layer 7 classification, but forwards the client's original request to the server. Connection Handling
Layer 7 Persistent Switching Mode
Used when AppDirector receives an HTTP 1.1 request allowing multiple client requests over the same TCP connection. Setting the status of the Persistent Layer 7 switching:
• First: AppDirector inspects the first request in each TCP connection, selects a server, and forwards the request. During the rest of the TCP connection, AppDirector forwards all further requests to that server. • Overwrite: AppDirector inspects all requests over a single TCP connection. If a new server is required for additional client requests, AppDirector closes the connection with the server that was selected for the first request and opens a new connection with the new server. Note: Mirroring is not supported when delayed binding is used with Layer 7 Persistent Switching Mode and configured to either overwrite or maintain. Mirroring is however supported for when Layer 7 Persistent Switching Mode is set to First.
Caution:Radware does not recommend using this mode.
• Maintain (Default): AppDirector inspects all requests over a single TCP connection. If a new server is required for additional client requests, AppDirector opens a new connection with the new server without closing the connections to all previously used backend servers. Note: Using Layer 7 persistency switching mode with value maintain or overwrite modifies sessions mode behavior in the client table to remove the entry on session end even if the user has not configured the farm in this way.
AppDirector User Guide
Traffic Management and Application Acceleration
208 Document ID: RDWR-AD-V0231-UG1105
3.Click Set. Your configuration is set.
Note:
>> AppDirector does not send X-Forwarded-For to the server when the HTTP policy is set to First. This does not apply when it is set to Maintain. >> In First switching mode, the backend connection uses HTTP 1.1 with keep-alive enabled.
TCP Policies
Configuring TCP policies enables you to provide connection pooling for generic TCP protocols (non-
HTTP).
In a connection pooled environment, a pool of server connections is maintained for servicing client connections. When a client requests a connection, an unused connection is selected from the server pool and used to service the request. When the client request is complete, the server connection is returned to the pool and the client connection dropped.
This has the effect of reducing the overhead imposed by establishing and tearing down the TCP connection with the server, improving the responsiveness of the application.
Notes:
>> This feature cannot work for HTTP as this requires additional Layer 7 protocol intervention. For HTTP, AppDirector provides HTTP-level multiplexing activated via HTTP Policy.
Multiplex Back-End Connections
TCP multiplexing is a technique used primarily by load balancers and application delivery controllers (but also by some stand-alone web application acceleration solutions) that enables the device to "reuse" existing TCP connections. This is similar to the way in which persistent HTTP 1.1 connections work in that a single HTTP connection can be used to retrieve multiple objects, thus reducing the impact of TCP overhead on application performance. TCP multiplexing allows the same thing to happen for TCP-based applications (usually HTTP / web) except that instead of the reuse being limited to only 1 client, the connections can be reused over many clients, resulting in much greater efficiency of web servers and faster performing applications. AppDirector establishes a number of connections to the servers in its pool and keeps the connections open. When a request is received by the AppDirector from the client, the request is evaluated and then directed to a server over an existing connection. This has the effect of reducing the overhead imposed by establishing and tearing down the TCP connection with the server, improving the responsiveness of the application.
Values: enable/disable (default)
Note: The Multiplex Back-End Connections feature is HTTP dependent and cannot be used with Generic-SSL offloading, if selected in the Layer 4 Policy Application. See Layer 4 Policies, page 200
.
Back-End Connection Close idle timeout
Defines maximum idle time after which connection to the back-end server is closed. This is not available when multiplexing is disabled
Default: 3600 seconds.
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 209
>> When enabling back-end connection pooling for a Layer 4 policy, you must configure Client NAT on the farms attached to that Layer 4 policy. For details, see Client NAT, page 297
.
>> Layer 7 farm selection and server persistency is not available for generic TCP.
>> To associate a TCP Policy with a Layer 4 Policy, the Layer 4 Policy protocol should be TCP and the Application should be either TCP or generic SSL.
>> When a generic SSL Application is selected, an SSL Policy also needs to be attached to the Layer 4 Policy to allow SSL offloading.
To configure TCP policies
1.From the AppDirector menu, select Layer 4 Traffic Redirection > TCP Policies. The TCP Policies window is displayed.
2.Set the parameters.
3.Click Set. Your configuration is set.
SSL Offloading and Authentication
Implementing SSL offloading alleviates strain placed on servers while optimizing not only SSL duties, but also overall servers network performance. This section covers the following topics:
• SSL Policies, page 211
• Authentication Policies Overview, page 215
• Client Authentication Policies, page 215
• Trust-service Status List (TSL) Authentication Policies, page 223
• Certificate Validation Policies, page 230
SSL Offloading utilizes a strategy implemented within an organization’s data center to handle the encryption, decryption and verification of Secure Sockets Layer (SSL) transmissions across a business network. SSL acceleration is the method used for offloading the processor-intensive public key encryption algorithms involved in SSL transactions to a dedicated device thereby freeing up server resources that can be devoted to other tasks. AppDirector acts as proxy and offloads all SSL operations, leaving the software servers to process the clear text which is significantly less intense.
Parameter
Description
Policy Name Unique policy name.
Default: empty.
Connections Pool Size The maximum number of connections that AD holds in the connection reuse pool. If the pool is already full, then a server-side connection closes after the response is completed.
Back-End Connection Idle Timeout (seconds)
The maximum time a back-end connection must be idle before it can be closed, once its lifetime has passed.
TCP Pooling Back-End Connections
You can enable or disable the back-end connections pooling capability.
Values: Enabled/Disabled
AppDirector User Guide
Traffic Management and Application Acceleration
210 Document ID: RDWR-AD-V0231-UG1105
The offloading process also provides added security to business networks by identifying malicious traffic disguised as normal SSL encrypted files. Because offloading devices are devoted to SSL activities, they have a better ability to discover these hidden attacks than normal intrusion prevention systems.
SSL Offloading serves 4 main purposes that contribute together to establishing a secure communication channel:
• Authentication: Each communicating partner should be able to verify that the other is who it claims to be and not an impostor.
• Privacy: A third party should not be able to eavesdrop on a private communication.
• Integrity: Protocol should automatically or easily detect any tampering with the transmission.
• Non-repudiation: Sender should not be able to claim that they did not send what the receiver received.
Notes:
>> SSL can encapsulate any protocol and AppDirector can support this. However, some supporting capabilities for SSL offloading leverage HTTP protocol capabilities and are therefore are not available when AppDirector is used for generic protocol SSL offloading.
>> Protocols that include special commands for SSL initiation and behavior (FTP, POP3 or SMTP), require special support and are not guaranteed to work flawlessly in any SSL environment. >> The HTTP protocol provides widespread support for SSL offloading but some HTTP dependent features cannot be used with Generic-SSL over other protocols.
>> For non-HTTP traffic, a generic offloading capability is supported including encryption and decryption but not parsing or other services. You can select this option from the Layer 4 Policy application parameter. See Layer 4 Policies, page 200
.
Online Certificate Status Protocol (OCSP) OCSP authenticates network traffic by checking the revocation status of a client certificate using data stored on a remote OCSP server. Client credentials are based on SSL certificates. See OCSP configurable parameters in:
• To configure AppDirector Client Authentication Policy, page 218
• To configure TSL files chain, page 226
• To set TSL Authentication Policies, page 229
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 211
SSL Policies
When AppDirector manages SSL encrypted traffic, the necessary certificates and ciphers must be defined to allow SSL handshake.
To configure AppDirector SSL Policies 1.From the AppDirector menu, select Layer 4 Traffic Redirection > SSL Policies. The AppDirector SSL Policies window is displayed.
2.Set the parameters.
Parameter
Description
Policy Name (Mandatory)
Name of the SSL Policy. The SSL Policy defines the certificates and ciphers necessary for an SSL handshake.
Front End SSL
Certificate (Mandatory)
Server certificate to use for SSL connections. The certificate needs to be defined prior to setting the SSL policy in Security > Certificates.
AppDirector User Guide
Traffic Management and Application Acceleration
212 Document ID: RDWR-AD-V0231-UG1105
Cipher Suite (Mandatory)
Enables you to control which cipher suites are allowed by AppDirector during SSL handshake. From the drop-down list select the cipher suite to be associated or type in a requested cipher of your choice.
• RSA (Default): Cipher suite using RSA key exchange.
• ALL: All cipher suites. • PCI DSS Compliance: Payment Card Industry Data Security Standard
• ALL Non-Null Ciphers: All cipher suites except the NULL ciphers and ciphers offering no authentication, which must be explicitly enabled.
• SSLv3: SSL v3.0 cipher suites.
• TLSv1: TLS v1.0 cipher suites
• Export: Export encryption algorithms including 40 and 56 bit.
• Low: “Low” exception cipher suites, currently using 64 or 56 bit encryption algorithms but excluding export cipher suites.
• Medium: “Medium” encryption cipher suites, currently using 128 bit encryption
• High: “High” encryption cipher suites. Currently key lengths are larger than 128 bits.
• RSA:RC4-128:MD5: Cipher suites using RSA key exchange, 128 bit RC4 for encryption and MD5 for MAC.
• RSA:RC4-128:SHA1: Cipher suite using RSA key exchange, 128 bit RC4 for encryption and SHA1 hash for MAC.
• RSA:DES:SHA1:Cipher suite using RSA key exchange, 3DES for encryption and SHA1 hash for MAC.
• RSA:3DES:SHA1:Cipher suite using RSA key exchange, 3DES for encryption and SHA1 hash for MAC.
• RSA:AES-128:SHA1: Cipher suite using RSA key exchange, 128-bit AES for encryption and SHA1 hash for MAC.
• RSA:AES-256:SHA1: Cipher suite using RSA key exchange, 256-bit AES for encryption and SHA1 hash for MAC.
• MSIE Export56: 56 bit export version of Microsoft Internet Browser v 5.
• User Defined - AppDirector supports all ciphers supported by the accepted OpenSSL format and more information can be found in OpenSSL documentation.
Notes:
• In order to support SSLv2 clients, select User Defined and in the User Defined Cipher field insert RSA:SSLv2.
• For a comprehensive list of all front-end and back-end ciphers used by AppDirector, see Complete List of the Content Of All Cipher Suites (Front-end and Back-end), page 631
.
User-Defined Ciphers If the predefined list does not suit your needs, you can specify allowed ciphers. The OpenSSL convention for specifying ciphers must be followed. This field is non-active even if defined unless User Defined is selected in Cipher Suite. Parameter
Description
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 213
Intermediate Certificate
Specify if server certificate used was not provided by a root CA (Certificate Authority). This is a chain of certificates of the CA-s up to a root CA. Values: Select from list of Intermediate CA certificate imported into AppDirector.
Note: If a chain of CAs needs to be sent with the server's certificate, they should all be imported together to AppDirector as a single Intermediate CA object. To perform this action, open each Intermediate CA certificate (PEM format) in text editor, copy all certificate texts into a single text chain and then paste it into the Import Certificate text box
Listening Server port Enables you to define the port where the backend server is listening. When changing from HTTPS (port 443) to HTTP (port 80) traffic often needs to be sent to a different port than where it was originally destined. Default: 80
Note: If the Back End listening port is not configured, the Layer 4 policy port is used to access the back end servers.
Pass SSL info in Headers
Select type of information that you need to pass to Back-End servers in HTTP headers. See step 3
.
Note: This feature is HTTP dependent and cannot be used with Generic-SSL offloading, if selected in the Layer 4 Policy Application. See Layer 4 Policies, page 200
Protocol Redirection
HTTP Redirection Conversion State
See HTTP to HTTPS Protocol Redirection, page 343
When Backend SSL is working, this feature is not needed and you cannot configure them together. Values: Enable/Disable (Default).
Notes:
• When enabled, conversion is always done when hostname in response matches hostname in request.
• When SSL Policy Protocol Redirection and Layer 7 Header and Body Modifications are enabled on the same service, and the server sends a 302 Redirect response, the new location protocol is always set to HTTPS to enable the redirect location to work for the clients, (despite the setting in the Layer 7 Modification method).
• This feature is HTTP dependent and cannot be used with Generic-
SSL offloading, if selected in the Layer 4 Policy Application. See Layer 4 Policies, page 200
Also Redirect When Host Match The Following Regular-
Expression If HTTP to HTTPS conversion is required for additional hosts besides service default, you can use this field to define them by Regular Expression.
Default: Empty.
Note: This feature is HTTP dependent and cannot be used with Generic-SSL offloading, if selected in the Layer 4 Policy Application. See Layer 4 Policies, page 200
.
Parameter
Description
AppDirector User Guide
Traffic Management and Application Acceleration
214 Document ID: RDWR-AD-V0231-UG1105
3.For passing SSL information in Headers, click ... alongside this field. The Passing SSL information to Back-End servers in HTTP Headers dialog window opens.
Note:When using Generic-SSL offloading, you cannot use HTTP headers to forward data to servers. 4.Mark the Information Type that you wish to select and the accompanying Header Name field is enabled for you to add or edit the appropriate header name. Select from:
The dialog window is shown here.
Back End SSL
Backend SSL State Backend SSL provides the ability to re-encrypt traffic between AppDirector and the Web Servers in environments where enhanced security is required.
Values: Enable/Disable (Default).
Backend SSL Cipher This enables you to define the strength of your Backend SSL cipher.
Values: Low, Medium, High, User Defined
Backend SSL User Defined Ciphers
User defined ciphers in OpenSSL format. This must be specified when the Backend SSL Cipher parameter is set to User Defined.
Parameter
Description
Cipher Suite Defines which Cipher suite is to be used during the SSL handshake. The cipher suite used by the client, for example RC4-MD5.
SSL Version The SSL version used by the client, for example SSLv3.
Cipher Bits The number of bits used for encryption by the cipher, for example 128 Bit
Add “Front-End HTTPS” Header
Adds a special header to requests sent to the server signaling them that an SSL offloading device is being used. Servers that support this will send redirect messages (HTTP 302) with the location set to HTTPS instead of HTTP (see HTTP Redirection Conversion State parameter above for more information). Example When working with HTTPS to a backend Outlook Web-Access (OWA) server the responses are not presented properly in a Firefox browser. This can be worked around using AppDirector SSL information headers and adding the Add Front-End HTTPS Header to the SSL policy.
Parameter
Description
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 215
5.Click Set. Your configuration is set.
Authentication Policies Overview
SSL authentication allows a server to confirm a client’s identity as part of public-key cryptography, that a client’s certificate and public ID are checked to be valid and that they were issued by a trusted certificate authority (CA). An authentication policy is a set of settings applied to the authentication process and to the verification of authentication data. AppDirector supports two mutually exclusive authentication policies types, they are:
— Client Authentication Policies, page 215
Or
— Trust-service Status List (TSL) Authentication Policies, page 223
Client Authentication Policies
Client certificates enable network administrators to authenticate clients via a certificate generated by a central Certificate Authority (CA). When it is necessary to authenticate a client during the handshake process of the SSL, AppDirector sends a client certificate request to the client. To complete the handshake, the client then sends the client certificate to AppDirector to be validated. If the certificate is valid then the handshake process is complete on both sides and can start sending data. If the certificate is not valid then the session is terminated.
AppDirector User Guide
Traffic Management and Application Acceleration
216 Document ID: RDWR-AD-V0231-UG1105
Figure 8: Performing Client Authentication
Authentication Setup
1. An Administrator sets up an Organizational CA. As part of this process, the CA has a self-signed (or 3rd party) Certificate installed on it to identify it.
2. The CA server generates Client Certificates for the Clients. Clients install certificates into their Browser repository.
3. To create trust between the CA and the Authentication Server (AppDirector), the Client CA certificate is imported into AppDirector.
4. The Administrator then sets up an OCSP server (may be the same CA, or a central OCSP of a few organizational CAs). 5. An OCSP URL for sending the OCSP validation requests is set up on the OCSP server
6. The OCSP URL is updated as a field inside the Client Certificate and/or AppDirector.
7. Optionally, the OCSP server receives a certificate for signing OCSP responses or the OCSP certificate is imported into AppDirector to validate OCSP response
9. CRLs are generated by Clients CA and updated regularly for the OCSP server.
Automated Authentication Flow
1.As part of the SSL handshake, the Client sends a Client Certificate to AppDirector.
2.AppDirector matches the Client CA “issuer” field against the Client CA that is trusted according to its configuration. 3.AppDirector checks the Certificate’s valid dates.
4.AppDirector then sends an OCSP validation request to the OCSP server URL.
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 217
5.The OCSP Server generates a response (valid/invalid), signs it with its own certificates and returns it to AppDirector.
6.AppDirector now validates the response with the OCSP Certificate.
7.If all is verified, a SSL tunnel is established.
Certificates
The certificate is a digitally signed indicator which identifies the server or user. This is usually provided in the form of an electronic key or value. The digital certificate represents the certification of an individual business or organizational public key. It can also be used to show the privileges and roles for which the holder has been certified. It also includes information from a third party verifying identity and authentication is needed to ensure that persons in a communication or transaction are who they claim to be.
A basic certificate includes:
• The certificate holders identity.
• The certificate‘s serial number.
• The certificate holders expiry date.
• A copy of the certificate holder’s public key.
• The identity of the Certificate Authority (CA) and its digital signature to affirm the digital certificate was issued by a valid agency.
To certify a public key, prospective subscribers requesting the certificate must register their public key with a CA. Once this is done and the CA approves the request, a certificate is generated and issued to the subscriber.
To authenticate the client’s identity a CA certificate has to be imported into AppDirector. This CA certificate is used when the AppDirector receives a client certificate and attempts to validate it. The client certificate is valid only when its issuer conforms to the CA certificate that was imported into the AppDirector. Client certificates must be installed on the client browsers by the organization or by the clients. You can check if a valid client's certificate was revoked by the CA by configuring AppDirector to check its status using OCSP (Online Certificate Status Protocol). Certificate Revocation List (CRL)
AppDirector supports downloading CRLs from CDPs using CDP URI embedded in client certificates or URI statically configured in AppDirector authentication policy.
This means that Multiple CDPs can be used for a single service. For example, if a single web site supports Client Certificates from multiple CAs (for example, the web site of a central bank that supports users using Client Certificates from different regional banks), then various CDP URI locations will be extracted from the client’s certificates. As the downloaded CRL files include validity period in which the list is valid and after which it should be updated, AppDirector will automatically fetch a new copy of the list when validity requires it.
When using CDP, Client Certificate verification is performed in the same way as importing CRLs manually. Once a CRL is downloaded using CDP, all clients that arrive at the SSL tunnel are requested to present a Client Certificate and then AppDirector checks if they appear in the CRL. If the Certificate is displayed in the CRL, then the request is denied.
The CRL authorizes the client and specifies which customers must be denied access to the web server when this feature is enabled. This list must be updated periodically by importing it into AppDirector. To add a newly revoked certificate to the CRL, it must be added to the list of existing revoked certificates and then the file must be imported to the device. For example, a bank main office might need to revoke a certificate of one of its customers. The bank must add this customer’s certificate to the CRL. Once the CRL file is modified, it must be imported into AppDirector so that requests received from the revoked certificate are denied access.
Note:Supported formats for CRL (the *.crl extension) are currently PEM and DER. AppDirector User Guide
Traffic Management and Application Acceleration
218 Document ID: RDWR-AD-V0231-UG1105
1.When a CRL is selected as a mode of verification in an Authentication policy, a CRL file must be uploaded to AppDirector.
2.Upon receiving a new CRL file (manually or by CDP) the following validations are performed:
a.The signature is validated to ensure that it was not altered. b.If the signature is OK, another check is performed to ensure that the file is in its validity period. 3.When the Client certificate is presented to AppDirector, its serial number is looked-up in the CRL and if it is displayed, then authentication is rejected.
Certificate Distribution Point (CDP)
Certification Authorities (CA) are responsible for the distribution and availability of CRLs (Certificate Revocation Lists) to the community (clients/organizations) that they serve.
Often this is achieved by posting the CRL to an X.500 directory server managed by the CA. It is then the responsibility of the end user, or the end user's software application to retrieve the CRL from the X.500 directory. There are alternative distribution methods such as e-mailing the CRL to all end users or posting the CRL to a Web site so that end users can download the file.
The locations where you can find posted CRLs are called CDPs (Certificate Distribution Points). CRLs posted in CDPs can be accessed by LDAP and HTTP. Each CDP is characterized with a complete URI, which is used to access the CRL, for example; http://www.example.com/crl/crl-site.txt.
Online Certificate Status Protocol (OCSP)
Instead of using CRLs, AppDirector can verify the revocation status of Client Certificates by using the on-line method of OCSP (Online Certificate Status Protocol), defined in RFC 2560.
OCSP eliminates problems related to CRL management and distribution, such as CRL updates. Each Client Certificate is tested when a new connection is established. This method is slower yet extremely safe. The client is blocked at the moment that the Client Certificate is revoked, not only when a new CRL is received. When a request is sent to an OCSP responder for certificate status information, it receives a digitally signed response which can have one of the following three states:
• A good certificate status indicates that the certificate is not revoked at the time of the request, according to the OCSP responder's knowledge of the certificate's status. This does not mean that the certificate was ever issued, or that the time of the response was within the certificate's validity interval.
• A revoked certificate status indicates that the certificate is either permanently revoked or temporarily suspended.
• An unknown certificate status indicates that the responder does not know about the certificate requested.
To configure AppDirector Client Authentication Policy 1.From the AppDirector menu, select Layer 4 Traffic Redirection > Authentication > Client Authentication Policies. The Authentication Policies window is displayed.
2.Set the parameters.
Parameter
Description
Policy Name Name of the Policy.
General Settings
Trusted CA Client CA certificate(s) to be used
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 219
CA Depth
Defines the maximum intermediate CAs in the CAs chain that AppDirector will search to validate the link between the client's certificate to the specified Client CA certificate.
Default: 2
CA Required Defines whether AppDirector verifies that the specified CA in the Client CA Certificate field has signed the client certificate. When disabled, any certificate that the client presents is accepted, regardless of whether it was issued by the trusted CA.
If OCSP is enabled then the revocation test is performed.
Values: enabled (default)/disabled.
Redirection URL Defines the URL to redirect clients to when Client Authentication fails and you wish to notify this to users in a graceful way rather than by default browser message.
Default: Empty
Certificate Revocation Check Defines whether AppDirector verifies that the client's certificate has not been revoked by the CA (Certificate Authority) before completing the SSL/TLS handshake. The revocation check can be performed using OCSP.
Values: OCSP, CRL, CDP, Disable (default).
Certificate Validation Policy
Defines the Client's certificate field validation policy to be used during Authentication. For more information about Certificate Validation Policy see Certificate Validation Policies, page 230
.
Pass Certificate info in Headers
Allows forwarding Client Certificate information to the application servers using HTTP headers. For more information see Certificate Information Headers, page 222
.
Note: When full certificates are sent in HTTP headers, they are encoded in PEM format.
OSCP Parameters (when Certificate Revocation Check is set to OCSP)
OCSP URI Specify a URI for OCSP certificate status check.
Response Allowed Signing Algorithm
Defines the specific signature algorithms allows for signing OCSP responses.
Values: All (default), MD5, SHA1, SHA256, SHA384, SHA512
Verify Certificate Chain
When enabled, an OCSP request is sent for every certificate in the chain, when disabled, an OCSP request is sent to client certificate only.
Response Time Deviation (Seconds)
Allows for overlooking small deviations between AppDirector and OCSP server timestamps for OCSP signatures verification.
Values: 0 (default) - 3600 in seconds
Note: For correct time validation, it is recommended to use NTP, and you must define the AppDirector Time-Zone. See Time Settings, page 457
.
Parameter
Description
AppDirector User Guide
Traffic Management and Application Acceleration
220 Document ID: RDWR-AD-V0231-UG1105
OCSP Cache Time (Minutes)
Defines the time for which validated OCSP responses are cached. Since CA servers update the CRLs on the OCSP parochially (every 12 hours or 24 hours), there is no need to overload the OCSP server with repetitive OCSP requests for the same certificate. The Cache is per Client Authentication or TSL Authentication policy and entries are not shared between policies. The OCSP cache time is defined in minutes.
Values: 0 (default) - 180000 minutes
Note: When set to 0, OCSP Cache is disabled.
Send Nonce An OCSP nonce offers an optional tool for a relying party to determine that it is receiving up-to-date certificate status information from a responder. A nonce is a random sequence of 20 bytes placed in an OCSP request. The responder must use its secret key to sign a response containing this nonce.
Values: Enabled/Disabled
OCSP URI Precedence Controls OCSP URI precedence, whether to use the user-configured URI or the URI that is embedded in the client's certificate.
CDP (when Certificate Revocation Check is set to CDP)
CDP Backup URI LDAP or HTTP URI to be used to fetch CRL files as alternative to the URI that appears inside the client’s certificates CRL location extension.
CDP Backup Password Password to be used when accessing CDP to fetch new CRL.
CDP Backup1 Username
Username to be used when accessing CDP to fetch new CRL.
CDP Backup Update Interval (Minutes)
Defines (in minutes) the time for periodical access to fetch CRL from CDP. When set to 0 (zero) the updates are done according to NextUpdate field in the current CRL.
CDP General Grace Time (Minutes)
Defines for how long a CRL may be used beyond the NextUpdate value that appears inside the CRL indicating when it needs to be updated.
Last successful CRL fetch
Last successful download of CRL.
Last unsuccessful CRL1 fetch
Last unsuccessful download of CRL.
CRL (when Certificate Revocation Check is set to CRL)
CRL File Name
Latest CRL file name.
Parameter
Description
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 221
3.Click Set. Your configuration is set.
4.Go to Layer 4 Policies, page 200
.
5.In the required Layer 4 policy, select the Client Authentication policy that you configured.
Purge OCSP Cache
You can purge None of the OCSP cache information or ALL (for all the Authentication policies).
To purge OCSP Cache
1.Select a policy name from the drop down list with policies names. 2.Click Purge. The Cache is purged.
Purge CDP Cache
You can purge None of the CDP cache information or ALL (for all the Authentication policies).
To purge CDP Cache
1.Select a policy name from the drop down list with policies names.
2.Click Purge. The CDP is purged.
Notes:
>> With Generic-SSL offloading, you cannot use HTTP headers to forward data to servers. AppDirector User Guide
Traffic Management and Application Acceleration
222 Document ID: RDWR-AD-V0231-UG1105
>> With each Certificate of Client CA you can bind multiple CA Certificates to a single Client Authentication policy by concatenating multiple certificates into a single import operation. To use multiple client CA certificates on the same Client Authentication policy: open the CA’s PEM certificate files with a text editor and copy the content. In the AppDirector certificate import, paste the certificates text into the text box together one after the other. During the import they are concatenated.
Certificate Information Headers
In a regular SSL transaction, AppDirector strips off all the client certificate’s information and issues an HTTP GET request to the web server. The server cannot log the client information for statistics and cannot perform any user authorization without relying on the SSL authentication mechanism. Click and the Pass certificate info in Headers window is displayed with a matching checkbox. The following HTTP header types are displayed, (each information type is shown below with corresponding parameter name in square brackets).
Note: The CCRT-XXXX in each row below is the default HTTP header name under which information is sent. This can be changed. • Version - CCRT-Version: [version]
• Serial Number - CCRT-SN: [serial]
• Signature Algorithm - CCRT-SignatureAlgo: [algo]
• Issuer - CCRT-Issuer: [issuer]
• Validity Dates - CCRT-NotBefore: [before], CCRT-NotAfter: [after]
• Subject - CCRT-Subject: [subject]
• Public Key Type - CCRT-PublicKeyType: [type]
• Certificate - CCRT-Certificate: [certificate]
• MD5 Hash - CCRT-MD5Hash: [hash]
If you want to add a given header, check the matching box.
The Certificate Header has two options:
1.Certificate Header Lines Format - Multi Lines (default)/Single Line.
a.Multi line format is equivalent to esc_ctrl, esc_msb, sep_multiline, spc_eq and lname. Comments start with /* and end with */.
b.Single line format is equivalent to specifying the esc_2253, esc_ctrl, esc_msb, utf8, dump_nostr, dump_der, use_quote, sep_comma_plus_spc, spc_eq, and sname options. Comments start with //.
2.Information Character Set - ASCII/Unicode - When Using ASCII encoding for sending certificate details AppDirector uses slash (/) as delimiter between information fields. When using Unicode encoding for sending the certificates details AppDirector uses commas (,) as delimiter.
Once you click OK, the window generates the argument list separated by the | delimiter. When Pass Certificate Info in Headers is used, AppDirector can pass required fields of the client certificate to the web server in the GET requests. An application on the web server then extracts this information from the GET request's HTTP headers and uses it for proprietary purposes.
A client certificate field is passed on, as is, to the web server. If, for any reason, a field carries no information, then that field is not passed on to the web server. However, if a field carries some information, but one or more sub fields do not carry any, for example, the “E=” sub field in the Subject field, then that field (Subject) is copied to the HTTP header as is.
To configure AppDirector support for forwarding Client Certificate fields to the back-end web server, see To configure AppDirector Client Authentication Policy, page 218
.
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 223
Trust-service Status List (TSL) Authentication Policies
Trust-service Status List (TSL) is an ETSI standard (TS 102 231). ETSI is recognized as an official European Standards Organization by the European Commission (EC). TSL defines how you can query the latest, most up-to-date CA information from a central location (for example, the government). To read more about TSL, see the following topics:
• TSL Structure, page 223
• TSL Information, page 224
• Trusting a TSL, page 225
• TSL Configuration Workflow, page 225
• TSL File Import, page 225
• Configuring TSL Files Chain, page 226
• Configuring TSL Authentication Policies, page 228
• Configuring TSL Files Repository, page 230
In practice, the TSL standard handles situations where one organization is responsible for the creation, distribution and management of electronic ID cards (for example, Government), and other organizations need to authenticate users based on the e-IDs (for example, Tax management, Health Insurance, Financial institutes, employers, etc.). In these cases, all organizations using the e-IDs infrastructure need to be aware of changes performed by the managing organization (i.e. new servers added to host more user identities).
AppDirector provides support of the TSL standard allowing automatic fetching and updating of client authentication configuration in compliance with the TSL standard
TSL Structure
The TSL contains four major components, structured as follows:
• Scheme information: provides information on the issuing scheme;
• List of TSPs: identifies the TSPs recognized by the scheme;
• List of recognized Services provided by each TSP: indicates the service(s) provided by these TSPs and the current recognition status of these service(s);
• History information: indicates the status history of each service.
The logical model of the TSL is shown here.
AppDirector User Guide
Traffic Management and Application Acceleration
224 Document ID: RDWR-AD-V0231-UG1105
Figure 9: TSL Logical Model
Note:A Free TSL editing tool is available at http://www.osor.eu/projects/tsledit
TSL Information
The TSL contains structured information. Some of the information is necessary to identify the TSL itself or to facilitate its search: a first category of these fields such as TSL tag (to facilitate locating the TSL with a search engine), scheme information (such as version identifier, scheme operator name, etc.), are used as header information, to be able identify the correct TSL to be used.
The other data that forms part of the TSL body includes a sequence of fields holding information on the TSPs that the scheme oversees. Additionally, for each TSP, a sequence of fields holds information on the service(s) provided by that TSP. For each service, a sequence of fields holds information on the status history of that service.
Finally, a signature is computed over all fields of the TSL. The logic of the list is that, once the assessment scheme operator has accredited, or become aware of the existence of, a TSP and of its services, for each of them the current status, as determined according to the scheme rules, is indicated in the TSL. AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 225
Trusting a TSL
A TSL is a signed electronic document. To verify the signature, relying parties need to be able to access the applicable public key. Since the scheme issuing the TSL is more hierarchical than the TSPs governed by that scheme, the authenticity of the public key should not be certified by any TSP inside or outside the scheme. Providing the scheme's public key is a similar problem to providing the public key of a CA service. The key used for signing the TSL must have a public-key certificate published. TSL Configuration Workflow
In order to setup AppDirector for TSL based clients authentication the following steps are required:
1.Upload a Root TSL Certificate. This is imported into the regular Security feature - Importing Certificates, page 395
. 2.Upload an original TSL file and create a TSL files chain entry associated with the above Root TSL and TSL file. See To configure TSL files chain, page 226
.
3.Create a TSL authentication policy that is associated with the above TSL file chains. See To set TSL Authentication Policies, page 229
.
4.Create a Certificate Validation Policy. See Certificate Validation Policies, page 230
.
5.Create a Layer 4 Policy that is associated with the TSL authentication policy, SSL Policy, Farm, Servers. See To set up or update a Layer 4 Policy, page 200
.
6.To ensure that OCSP response time stamps are validated correctly, check that AppDirector time and time-zone are configured, preferably using NTP. See Time Settings, page 457
.
TSL File Import
The TSL File Import feature is designed to add TSL xml files to the TSL repository as part of the configuration process. The first file import is performed manually and then subsequently, automatically.
An imported original TSL xml file will usually include:
• Trusted Client’s CAs
• OCSP URLs per trusted CA
• Trusted OCSP responders certificates
• Main and Backup URL for next TSL file fetching
• Max validity time for using the TSL file
On every TSL file import (manual/automatic) a list of validations are performed to ensure its integrity and currency. These include File signature verification and sequential number progress.
To import a TSL File
1.From the AppDirector menu, select Layer 4 Traffic Redirection > Authentication > TSL File Import. The TSL File Import window is displayed.
2.In the File field, click Browse and locate the file that you want to import. Alternatively, click Browse to search the directory tree for the file. 3.Click Import. An Import Finished message is displayed and a Create Chain button is displayed.
4.Click Create Chain. The TSL Files Chain window is displayed. See Configuring TSL Files Chain, page 226
.
AppDirector User Guide
Traffic Management and Application Acceleration
226 Document ID: RDWR-AD-V0231-UG1105
Configuring TSL Files Chain
The TSL Files Chain is the chain of related files created by the continuous updating of TSL files. It holds TSL files chains with their related updating attributes.
Need for TSL Proxy
In cases where there is no access to the external internet cloud, but the TSL files server is located externally, you need to define a Proxy server where AppDirector can perform the TSL update requests. To configure TSL files chain
1.From the AppDirector menu, select Layer 4 Traffic Redirection > Authentication > TSL Files Chain. The TSL Files Chain window is displayed.
2.Set the parameters.
Note:Proxy, username and password fields support UTF-8 characters.
Parameter
Description
Chain Name Identifying name of TSL Files Chain.
TSL Parameters
TSL Root CA Name of the TSL Root certificate to be used from the certificate table. The TSL Root Certificate should be first imported into the Certificates Table. For more information about importing certificates see Importing Certificates, page 395
.
Values: Null (default), TSL Root Certificate.
Original File Name of the original manually uploaded TSL file. For more information on uploading this TSL file to AppDirector see TSL File Import, page 225
. Automatic Update Hours
Defined time (hours and minutes) when AppDirector checks and fetches an updated TSL File, (for example, 02:00).
Values: HH:MM (in 24hr format with multiple values separated by commas without spaces).
Examples:
• 14:35 will make the update run at 2:35 PM
• 02:00,14:15, 18:00 will make updates run at 2:00AM, 2:15PM and 6:00PM
Notes:
• Setting Update to none causes automatic updates to be turned off.
• When you change the time, by NTP or daylight saving (see Time Settings, page 457
), TSL updates set before the change will still occur, ignoring this time change in the pre-scheduled update. But, after one upgrade, they will reschedule and align to the correct clock.
TSL Proxy
Proxy URI Proxy URL Address
Proxy Username User name for the proxy server.
Proxy Password Password for the proxy server.
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 227
3.Once you have established TSL Files chains, you can review them on the TSL File Chain window. The following parameters will be displayed.
4.Click Set. Your configuration is set.
5.If you want to retrieve TSL Chain files or All - use the Fetch Now command and click Set.
Parameter
Description
Chain Name Identifying name of TSL Files Chain.
TSL Parameters
TSL Root CA Name of the current used TSL Root certificate from the certificate table. This is the current TSL file chain in use that was added manually or the one replaced via the new TSL file.
Values: Null (default), TSL Root Certificate.
Original File Name of the original manually uploaded TSL file.
Active File After initial definition is performed, this field shows the name of the active TSL file at any time. This is not visible during initial configuration.
Automatic Update Hours
Defined time (hours and minutes) when AppDirector attempts to fetch an updated TSL File, (for example, 02:00 = 2AM).
Values: Time of day represented as HH:MM (multiple times can be defined with separating commas).
Examples:
• 14:35 will make the update run at 2:35 PM
• 02:00,14:15, 18:00 will make the updates run at 2:00AM, 2:15PM and 6:00PM
Notes:
• Setting the Update to none causes automatic updates to be turned off.
• When you change the time, by NTP or daylight saving (see Time Settings, page 457
), TSL updates set before the change will still occur, ignoring this time change in the pre-scheduled update. However, after one upgrade, they will reschedule according to the correct clock.
Last Import Time Last time the TSL file was manually or automatically updated. (DD-MM-
YYYY HH:MM format).
TSL File Active Until Time in which Active TSL file becomes obsolete (in DD-MM-YYYY HH:MM format). At this time AppDirector will generate an SNMP alert to notify the situation but will continue to work with the obsolete file's configuration. An additional alert will be issued on every update interval.
Next TSL Root
Next TSL Root If a TSL file includes a new TSL root that should replace the defined TSL Root at a given time, this field will show the name of the new TSL Root Certificate, (the Next Root TSL file).
Next TSL Root valid date
If a TSL file includes a new TSL root that should replace the defined TSL Root at a given time, this field will show the time in which the new TSL Root Certificate will become active for signing new TSL files.
AppDirector User Guide
Traffic Management and Application Acceleration
228 Document ID: RDWR-AD-V0231-UG1105
Updating for Authentication
1.Once an initial TSL configuration has been created, it will now contain the update time and the location from which to take the next TSL file (Primary and Secondary URIs for next update are embedded in the origin TSL file). As per update schedule, AppDirector requests a TSL update from the TSL URL
2.The TSL server sends a new TSL file. 3.The TSL Files are parsed by the Authentication server and the following elements are extracted: — Certificates off all trusted Client CAs (with their OCSP URLS)
— OCSP server signing certificates
— URL of TSL server for next update,
4.At the specified update time, a new TSL file will be fetched and verified. AppDirector supports TSL update fetching over the HTTP protocol. If the fetch fails, a connection to the secondary URL is attempted (up to three times to each URL). If all retrieval attempts fail, a trap is sent by AppDirector.
Figure 10: TSL Updating for Authentication
Configuring TSL Authentication Policies
The TSL Authentication Policy includes all TSL configurations and is attached to the Layer 4 policy using the same parameter as the Client Authentication Policy. This means that the Client Authentication Policy and TLS Authentication Policy are mutually exclusive. Select one or the other.
The association of a TSL Authentication Policy with a Layer 4 Policy defines the TSL service on the AppDirector. The TSL policy encapsulates all required data to support the TSL service.
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 229
To set TSL Authentication Policies
1.From the AppDirector menu, select Layer 4 Traffic Redirection > Authentication > TSL Authentication Policies. The TSL Authentication Policies window is displayed.
2.Set the parameters.
Parameter
Description
Policy Name Unique name of the TSL Authentication Policy.
CA Required Defines whether AppDirector verifies that a CA has signed the client certificate. When disabled, any certificate that the client presents is accepted, regardless of whether it was generated by a trusted CA or not.
Values: enabled (default)/disabled.
Redirection URL Defines the URL to redirect clients to when Client Authentication fails and you wish to notify this to users in a graceful way rather than by default browser message.
CA Depth
Defines the maximum intermediate CAs in the CAs chain that AppDirector will search to validate the link between the client's certificate to the received Client CA certificate.
Values: 1(default) Pass Certificate info in Headers
Allows forwarding Client Certificate information to the application servers using HTTP headers. For more information see Certificate Information Headers, page 222
.
Certificate Validation Policy Defines the Client's certificate field validation policy to be used during Authentication. For more information about Certificate Validation Policy see Certificate Validation Policies, page 230
.
TSL File Chain Select TSL Files Chain to be used in this TLS Policy. The TSL File Chain must be configured prior to configuring the TSL Policy. See Configuring TSL Files Repository, page 230
for more information. OCSP Parameters
OCSP Cache Time Defines the time for which validated OCSP responses are cached. Since CA servers update the CRLs on the OCSP parochially (every 12 hours or 24 hours), there is no need to overload the OCSP server with repetitive OCSP requests for the same certificate. The Cache is per Client Authentication or TSL Authentication policy and entries are not shared between policies. The OCSP cache time is defined in minutes.
Values: 0 (default) - 180000 minutes
Note: When set to 0, OCSP Cache is disabled.
Response Allowed Signing Algorithm
Defines the specific signature algorithms allows for signing OCSP responses.
Values: All (default), MD5, SHA1, SHA256, SHA384, SHA512
Verify Certificate Chain
When enabled, an OCSP request is sent for every certificate in the chain, when disabled, an OCSP request is sent to client certificate only.
AppDirector User Guide
Traffic Management and Application Acceleration
230 Document ID: RDWR-AD-V0231-UG1105
3.Click Set. Your configuration is set.
Configuring TSL Files Repository
The TSL Files Repository holds all the TSL original files imported manually to AppDirector, and the current Active files fetched automatically by AppDirector per TSL file chain. All Files can be downloaded from AppDirector for viewing purposes. After a TSL file goes through the validation process and is flagged as valid, it is placed in a static link per TSL Files-chain on AppDirector so that other components in the environment can use it. The link is always: https://[ip addr]/GetActiveTslFileChain?chain=[TSL_files_chain_name]
To export a TSL Authentication File
1.From the AppDirector menu, select Layer 4 Traffic Redirection > Authentication > TSL File Repository. The TSL File Repository window is displayed.
2.Lists of files appear under these categories: Active TSL Files, Original TSL Files, Failed Active, Last Active.
3.To delete a TSL file, select delete next to it. The file will be deleted unless connected to a TSL File chain.
4.To download or export a TSL file, select download next to the appropriate TSL file. A file download dialog is displayed. You can choose to open or save it to your own desktop.
Certificate Validation Policies Certificate Validation Policies allow you to define any certificate field or extension for which only specific values are allowed. They can be connected to either Client Authentication or TSL Authentication Policies. They work according to the following logic:
• All fields/extensions that appear in policy must appear in the certificate (AND)
• One of the values defined for each field/extension should match the value that appear in this field/extension in the certificate (OR), In case of multiple values in the extension’s data, AppDirector will look for ANY OF the extension’s values within the values defined in the CVP. Response Time Deviation (sec)
Allows for overlooking small deviations between AppDirector and OCSP server timestamps for OCSP signatures verification.
Values: 0 (default) - 3600 in seconds
Note: For correct time validation, it is recommended to use NTP, and you must define the AppDirector Time-Zone. See Time Settings, page 457
.
Send Nonce An OCSP nonce offers an optional tool for a relying party to determine that it is receiving up-to-date certificate status information from a responder. A nonce is a random sequence of 20 bytes placed in an OCSP request. The responder must use its secret key to sign a response containing this nonce.
Values: Enabled/Disabled
OCSP Cache Purge The OCSP cache purge operation is used for clearing OCSP cached responses. OCSP cache purging is done per client authentication policy or for all client authentication policies.
Select policy name from drop down with policies names. Parameter
Description
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 231
• If field/extension value in policy is defined as "*" (asterisk) it means that the field/extension should appear in certificate but may have any value.
• If a field/extension is marked as "Optional" in Certificate Validation Policy it may or may not appear in the certificate, but if it is displayed it must adhere to the above logic, i.e. if it exists logic=AND else logic=Ignore To configure Certificate Validation policy
1.From the AppDirector menu, select Layer 4 Traffic Redirection > Authentication > Certificate Validation Policies. The Certificate Validation Policies window is displayed.
2.Set the parameters
3.Click Set. Your configuration is set.
Certificate Validation Policies Format Specification
The tables below show specific formats and examples for each type of field and extension.
1.Commonly used formats
ORGANIZATION = C=<Country>, ST=<State>, L=<Locality>, O=<Organization>, OU=< Organization Unit>, CN=<Common Name>/emailAddress=<email address>
Sub-values that are not specified may be omitted.
GENERIC NAME = one of the following:
email:<email address>
DNS:<dns>
URI:<uri>
DirName:ORGANIZATION format
IP Address:<ip address> (sometimes <ip address>/<subnet mask>)
Registered ID:<id>
Parameter
Description
Policy Name Name of the Policy.
Certificate Field /
Extension Name
The Field name to validate. Select from the values shown in Certificate Validation Policies Values Formats per Field/Extension., page 232
or define another extension by writing in its OID.
Default: Version
Index The rule index is used as an identifier only and its numeric value has no other meaning.
Values: 0 (default) - 65000
Field/ Extension Valid Value
Define valid values per Field/Extension. for example: Signature Algorithm may have few allowed values with different indexes index1=MD5, Index2=SHA1. For valid values format per field/extension, see Certificate Validation Policies Values Formats per Field/Extension., page 232
.
Optional Extension If a field/extension is marked as "Optional" in Certificate Validation Policy it may or may not appear in the certificate, but if it is displayed it must adhere to the above logic, i.e. if it exists logic=AND else logic=Ignore. Values: Enabled/Disabled (default) AppDirector User Guide
Traffic Management and Application Acceleration
232 Document ID: RDWR-AD-V0231-UG1105
2.Certificate Fields
Only the fields listed in the table are supported.
Notes:
>> Since the match is substring-based, it is not necessary to provide values in full format. Therefore, if a configured value is a substring of the value given in a certificate, there will be a match.
>> The matching of certificate fields content is exact, partial strings matches will fail. This means that to match an issuer or subject, for example, the full DN should be specified and not CN only. i.e. CompanyCA will fail because it is CN value only, and full DN such as C=US, O=MyCompany, CN=CompanyCA will match.
Table 1: Certificate Validation Policies Values Formats per Field/Extension.
Field Name
Format
Example
Version Number (decimal) 3
Serial number Hex String 0x5057
Issuer ORGANIZATION common format C=US, ST=NY, L=NA, O=Radware, OU=CT100, CN=client_1/
emailAddress=ct100@radware.co
m
Subject ORGANIZATION common format C=DE, O=gematik LTU, CN=brk002as3.gematik.net/
serialNumber=rel234 BROKER SSL-C 515.00
Public key: Signing Algorithm
One of the following values:
• rsaEncryption
• dsaEncryption
Public key: Length Number (decimal) 1024
Signature Algorithm One of the following values:
• md2WithRSAEncryption
• md4WithRSAEncryption
• md5WithRSAEncryption
• sha1WithRSAEncryption
• dsaWithSHA
• dsaWithSHA1
• dsaWithSHA1-old
• ecdsa-with-SHA1
• mdc2WithRSA
• ripemd160WithRSA
• sha224WithRSAEncryption
• sha256WithRSAEncryption
• sha384WithRSAEncryption
• sha512WithRSAEncryption
sha1WithRSAEncryption
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 233
3.Known certificate extensions
The list below shows extensions that are known and explicitly formatted by open ssl .
Extension Name
Format
Example
Subject Key Identifier Hex String 19:71:D3:07:AD:60:88:5C:C3:A0
:3F:AE:B2:52:08:EC:47:CC:11:1
B
Key Usage One or more of the following values, comma separated
• Digital Signature
• Non Repudiation
• Key Encipherment
• Data Encipherment
• Key Agreement
• Certificate Sign
• CRL Sign, Encipher Only
• Decipher Only
Digital Signature, Non Repudiation
Subject Alternative Name
One or more of GENERIC NAME formats, comma separated (same type may appear more than once)
email:my@other.address, URI:http://my.url.org
Issuer Alternative Name See Subject Alternative Name
Basic Constraints CA:FALSE Since client certificate can never be CA, other possible formats are irrelevant
CA:FALSE Certificate Policies Policy: <Policy OID1>; Policy: <Policy OID2>; … Policy: <Policy OIDN>; User Notice:; [CPS: <cps uri>] / [User Notice: [Explicit Text: <user notice text>]/[Organization: <organisation>;Number[s]:<co
mma-separated list of notice numbers>]<user notice>] / [Unknown Qualifier: <other qualifier>]
Policy: 1.2.276.0.76.4.84; Policy: 1.2.276.0.76.4.63; User Notice:; Explicit Text: oid_policy_sf_cp
Authority Key Identifier Hex string CRL Distribution Points One or more of the GENERIC NAME formats, comma separated. (reasons and crlIssuer extension sub-fields are not supported)
URI:http://my.com/
my.crl,URI:http://oth.com/my.crl
Authority Information Access
[OCSP]/[CA Issuers] - <info> Where <info> is in GENERIC NAME format
OCSP - URI:http://ocsp.my.org/
AppDirector User Guide
Traffic Management and Application Acceleration
234 Document ID: RDWR-AD-V0231-UG1105
Extended Key Usage One or more of the following values or OIDs (dot notation), comma separated:
• Code Signing
• E-mail Protection
• Time Stamping
• Microsoft Individual Code Signing
• Microsoft Commercial Code Signing
• Microsoft Trust List Signing
• Microsoft Server Gated Crypto
• Microsoft Encrypted File System
• Netscape Server Gated Crypto • TLS Web Server Authentication
• TLS Web Client Authentication
Netscape Server Gated Crypto, Microsoft Server Gated Crypto, 2.3.4.5
Netscape Certificate Type
One or more of the following values, comma separated
• SSL Client
• SSL Server
• S/MIME
• Object Signing
• Unused
• SSL CA
• S/MIME CA
• Object Signing CA
SSL Client
Netscape Base URL String
Netscape Revocation URL
String
Netscape CA Revocation URL
String
Netscape Renewal URL String
Netscape CA Policy URL String
Netscape SSL Server Name
String
Netscape Comment String
Thawte Strong Extranet Version: <version decimal> (0x<version hex>);Zone: <zone1>, User: <user1>;Zone: <zone2>, User: <user2>;.. User: <userN>;Zone: <zoneN>
Version: 2 (0x3); Zone: zone1
Extension Name
Format
Example
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 235
4.User-Defined Certificate Extensions
Unknown certificate extensions formatting is done as follows:
— Extension Name format can only be specified as OID
— Extension Value format is list of parsed as ASN1 types separated by colon.
Example Extension Name: 1.3.36.8.3.3
Extension Value: countryName:DE:organizationName:gematik:Broker:1.2.276.0.76.4.88
Application Acceleration This section refers to when Application Acceleration features are enabled and includes these topics:
• Benefits of Application Acceleration, page 235
• Enabling and Disabling Application Acceleration, page 236
• Rule Lists, page 236
Benefits of Application Acceleration The proliferation of new web enabled applications coupled with the trend of data center consolidation put great strain on web application servers that need to cope with ever increasing transactions volume. Growing portion of these applications use SSL (Secure Socket Layer) encryption as mean to secure and protect the privacy of sensitive information, common examples are e-commerce shopping carts, e-banking, and more. However, servers are very inefficient in processing encrypted transactions. Processing encrypted transactions require a much higher allocation of CPU resources than do simple Web page serving, in some cases, as seen in figure 3 performing SSL encryption/ decryption is 100 times more demanding than handling the same request as clear text. Performing these SSL calculations slow Web server performances, leading to inconsistent user experience, and even downtime.
Subject Information Access
See Authority Information Access
Proxy Certificate Information
Path Length Constraint: [<Number>]/[infinite]; Policy Language: <language>;Policy Text: <policy data>
Inhibit Any Policy Number (decimal)
Name Constraints Permitted:<list of permitted entities GENERIC NAME format, separated by semicolon>;
Excluded: <list of permitted entities in GENERIC NAME format, separated by semicolon>
Extension Name
Format
Example
AppDirector User Guide
Traffic Management and Application Acceleration
236 Document ID: RDWR-AD-V0231-UG1105
AppDirector’s application acceleration features relieve Web servers from performing CPU intensive SSL calculations by handling all the associated encryption, decryption, session and certificate management tasks. Unlike Web servers, AppDirector is optimized to perform SSL calculations, using dedicated ASIC-based hardware and software. Offloading these SSL calculations relieves Web server CPUs allowing it to serve the application in a greater efficiency.
Acceleration Policies
AppDirector provides end-to-end performance acceleration of Web-based applications for all end-
users types such as desktops, PDAs and smart-phones. AppDirector also uses advanced and granular application intelligence (Layer 7 load balancing) for end-to-end business-smart networking. Enabling and Disabling Application Acceleration To access these AppDirector features you need the Application Acceleration Engine set to Enabled.
To enable Acceleration and Compression
1.From the AppDirector menu, select Global > Tweaks. The Tweaks window is displayed.
2.Within the Tweaks window, ensure that you select the Acceleration Engine parameter and mark as Enabled.
3.This process will require a device reboot.
To disable Acceleration and Compression
1.From the AppDirector menu, select Global > Tweaks. The Tweaks window is displayed.
2.Within the Tweaks window, ensure that you select the Acceleration Engine parameter and mark as Disabled.
3.This process will require a device reboot.
Caution:You will not be able to upload a configuration file with Application Acceleration Enabled when the device is in Application Acceleration Disabled mode
Rule Lists
To assist configurable compression and caching, Radware has developed Rule - Lists (lists of rules) that match defined patterns on a set of HTTP headers (User Agent, MIME Type) or URI and determine whether to perform an action (compress or cache). Rule-Lists are scanned for a match until the first match is found. Therefore, rules priorities that determine rule order are important.
Leveraging Rule List Behavior
Rule-Lists behavior is where rules are scanned from top to bottom according to their set priority, and once a match is found, the action designated in this rule is performed, and the Rule-List will not be scanned for further matches. This allows you to create exceptions for exceptions within the same Rule-List. For Example, if you have a folder containing cacheable objects (for example, Images folder) and within a folder containing non-cacheable objects (for example, content updating, reports, graph images), you can set a rule of priority 1 that will match the Non-Cacheable objects folder (Graphs folder), followed by a more general rule with priority 2 to cache all father-folder AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 237
objects (images folder). When the Rule-List is scanned for a match, the more specific exception is matched first, without continuing to match again on the more general expectation, thus receiving the required behavior.
Copy Rule Lists
Since Rule-Lists may contain many rules, and often the same list can be required but with only minor changes, AppDirector allows you to copy Rule-Lists into a new Rule-List. To duplicate an entire rule list, you need:
• to define name of source rule list (source for Copy)
• to define name of target rule list from list of existing Rule-lists or new (Destination of Copy)
When Set is pressed, all rules are copied from Source to Destination.
Notes:
>> If rules already exist in the Destination policy, you will receive the following message: "
The target Rule List already contain rules. To avoid accidental overwrite, please delete rules or entire Rule-List and retry."
>> Overwrite of existing Rule-List using Copy Rule List is not allowed.
To use the AppDirector Copy Rule Lists 1.From the AppDirector menu, select Layer 4 Traffic Redirection > Copy Rule Lists. The AppDirector Copy Rule List window is displayed.
2.Set the parameters.
3.Click Set. Your configuration is set.
Caching
Web pages are composed of a series of objects. Many of these objects are static objects that are the same from page to page. Radware AFE can automatically recognize requests for such objects and retrieve them directly from the device’s local cache without fetching them from the web server. This capability offloads the server from dealing with unnecessary requests and as the same time accelerates objects delivery to the end-user.
Parameter
Description
Rule-List Type Type of Rule-List to be copied. • None (default)
• Compression Browser Exception List
• Compression URL Exception List
• Cache URL Policy List Source Rule List Name Select from already defined rule lists of defined type above.
Default: none
Destination Rule List Name
Define name of new Rule-List to which all rules in Source Rule-List are copied.
Default: none
AppDirector User Guide
Traffic Management and Application Acceleration
238 Document ID: RDWR-AD-V0231-UG1105
Caching can also save transformed objects at the cache such as different versions of a given image that has been compressed and optimized differently for various end users and end users' devices (as it was explained in the Image optimization section).
Radware’s caching is fully compliant with RFC 2616 of HTTP 1.1. It respects all relevant HTTP Headers (such as: Cache-control, Expires, Authorization, and Pragma), which are the Web Application means of dictating which content is to be cached and when it should be refreshed.
AppDirector has options to determine its Cache behavior, both in terms of which content to cache, and in terms of which content to serve to clients from Cache or from Servers. AppDirector Cache policy includes the option to define per URL caching behavior and cache maximum time, and the option to better leverage client Browser's cache to improve response times and QoE.
Caching Policies
AppDirector supports caching of HTTP traffic. Caching improves the overall network performance. Using caching, backend servers are required to serve less content, which can save on fetching data and creating dynamic HTML pages. Caching can also decrease the number of required TCP connections to the backend servers. It allows a more efficient use of compression features, as AppDirector can cache compressed objects, and save the need to re-compress the same object for each client request. Caching is memory based. Once Caching is enabled for one Layer 4 Policy or more, up to 50% of available Acceleration Engine memory is used for cache. The amount of memory used depends on traffic and the cached objects and is configurable from 1 % - 50% (default 20%) in the Tuning Table.
Note:If a Caching policy is defined, by default the action is cache all the content.
Caching and Layer 7 Modification
The objective of caching is acceleration whereas the target of Layer 7 modification is to select the correct content from the correct server. Unfortunately, configuring an URL exception list does not always solve the problem.
Layer 7 modification should take precedence over caching as caching is at the client end of the flow. This means that when a request arrives it will be considered for serving from cache before all other application services (e.g. HTTP modifications). On the other hand, when a server response reaches an Application Services Engine it will undergo compression and HTTP modification before being cached.
Caching Decisions
Caching depends on the following decision making process:
1.Which object do we want to cache?
2.Can it be optimized?
3.Seven Qualifications (see Identifying Optimizable from Non-Optimizable Objects, page 239
.)
4.Once an object is encountered caching will now act as defined.
Dynamic Caching There are several issues to consider when caching. Deciding which content is private (user specific) or public, static or changeable. More than 40% of web content is not marked with caching directives and yet could be optimized. Two factors to keep in mind when considering whether to cache dynamic pages include the frequency of web content changes and the demand level for current content (hit count). Anticipated hit count determines the prioritization of web pages to be cache. More popular web pages take precedence over less frequently accessed pages.
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 239
AppDirector’s Dynamic Caching helps increase your server performance, improving response times by fetching content from cache rather than from the servers for dynamic as well as static content, and in addition simplifies control of the caching configuration.
This is achieved by:
• identifying static objects from dynamic objects
• defining optimal caching times
• optimizing Dynamic objects caching in browser
• avoiding caching users private content
Notes:
>> URL exception rules can override dynamic caching decisions, enabling an administrator to control caching even when dynamic caching is selected.
>> The expiration time defined in the policy is an upper limit for cache aging, even if the object is not actually cached.
Identifying Optimizable from Non-Optimizable Objects
AppDirector identifies whether an object is optimizable by checking a series of criteria as follows:
1.The Object should not have a cache time specified.
2.The Object must be one of the following content types:
a.application/*
b.image/*
c.audio/* (?)
d.video/* (?)
e.text/: plain, css, richtext, tab-separated-values, "x-*" (x-c, x-fortran etc.)
3.The Object name should be persistent over time to rule out an object with dynamic names usually created per-user request for single use - 4.The Object should not have caching restrictions in its headers (like Private) that contradicts dynamic caching logic. In addition, an object should not have any restriction in the device's caching policy (URL exception rule list) preventing its caching.
5.Object access should not require authentication - objects that need authentication access are usually unique to the authenticated user.
6.The Object should have a valid Last-Modified header allowing its content to be traceable and to be checked with a server if it was changed.
7.The Object does not have a Vary header limiting its validity for caching only in specific cases.
When an object meets all the above criteria, it is marked as eligible for caching optimization.
Defining Optimal Caching Times
When an object is identified as eligible for caching, but with no caching time (according to its max-
age or expires headers), AppDirector will define an estimated caching time.
Optimizing Dynamic objects caching in browser (Object Versioning)
AppDirector can optimize the caching of objects by browsers. The algorithm for this action is based on controlling object names in the original HTML the references them. This allows AppDirector to check if objects were modified every time that the HTML was recalled and force the browser to update them when needed. AppDirector User Guide
Traffic Management and Application Acceleration
240 Document ID: RDWR-AD-V0231-UG1105
Avoiding caching users private content
During caching actions, AppDirector is careful to avoid any caching of user personal data, including:
• Not caching any object marked as Cache-Control: private.
• Not caching any object that requires Authentication to be accessed.
• Stripping objects from set-cookie headers before caching to avoid different users receiving other users session information.
Invalidating cache content changed by clients
AppDirector allows a cached object to be invalidated following a user action that modifies it. This is performed according to HTTP cache RFC (section 13.10). This defines that any object request with HTTP method POST, PUT or DELETE must cause the object's invalidation. This invalidation occurs only after the server has approved the operation as successful (i.e. responds with a 200OK)
This enables caching dynamic content like blog pages, while ensuring that every new posting will invalidate the cached version of the page.
Using Leverage Browser Cache parameter
When cached content is served by AppDirector to a clients browser, the client experiences better Quality of Service (QoS) than if it was served from the server. Further enhancement to client QoS is achieved when the clients Browser caches the content for reusing on the next request that will need it. However, not all content is optimally cached by browsers thus failing to provide the best possible QoS. AppDirector can optimize the browser caching by updating the Cache-Control directives on every cache-served object. The object headers are updated to reflect the future time it can be cached for by the browser according to the AppDirector cache time (whether from server headers or AppDirector Cache URL Exceptions Rule-List). AppDirector will also ensure that the content will not be served from the browser cache after it is considered stale. AppDirector will provide the browser with the time that already exists in the AppDirector Cache, so that the browser can calculate the remaining time correctly.
To configure AppDirector Caching Policy 1.From the AppDirector menu, select Layer 4 Traffic Redirection > Caching Policies. The AppDirector Caching Policy window is displayed.
2.Set the parameters.
Parameter
Description
Policy Name (Mandatory)
Name of the Policy.
Default: Empty
Dynamic Caching Helps increase your server performance, improving response times by fetching content from cache rather than from the servers for dynamic as well as static content.
Values: Disabled (default)/Enabled
Minimum Object Size [Bytes]
Minimum size of object in bytes to be stored.
Default: 1024 bytes
Maximum Object Size [Bytes]
Maximum size of objects in bytes to stored.
Default: 4,199,999,999 bytes
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 241
3.Click Set. Your configuration is set.
4.In the required Layer 4 policy, select the Cache policy that you configured.
Expiration [seconds] Maximum time that an object is kept, even if the object header is specified longer. If the object header or configuration via Cache URL Rule-List is specified less, it is purged according to its header / configuration.
Default: 86,400 (24 hours)
Leverage Browser Cache
You can modify caching headers to leverage client side (browser) cache:
Values: Enabled (default), Disabled
For objects marked for caching: • Add/modify objects' HTTP headers to include Cache-control: public, max-age=X. • X is derived from general cache settings or from the URI rule responsible for caching the specific object. Respect Server Headers
Specifies how Server Response cache headers are treated.
• Respect-All (for example, RFC behavior) - If no header is sent by the server specifying the cacheability of the object, AppDirector caches the object.
• Cache-All - caches everything regardless of headers.
In both modes, Cache URI rules override and allow for Exception.
Values: Respect All (default), Cache All .
Note: If a Caching policy is defined by default, the action is cache all the content.
Respect Client Headers Specifies how Client request cache headers are treated:
• Respect-All (i.e. RFC behavior) - in this mode must-validate, if-
modified, etc. headers are enforced as "get fresh from Server" and request is forwarded to server. • Respect Refresh headers only - causes only the following headers in client requests to be respected: "max-age=0", "no-cache", "pragma:no-cache". All other content is served from cache if it exists there.
• Serve All from Cache - ignores all client side headers serving from cache anything that exists there.
Values: Respect All (default), Respect Refresh headers only, Serve All from Cache.
URL Exceptions Rule List
Disable or select from list of Cache URL Rule lists.
Default: Disable
You can define Domain without anything in the URL field to support use-cases of different behavior per domain. However, if Domain is not defined (Domain_type=none) then the URL field is mandatory.
Ignore Query Parameters
Specifies whether query parameters added to object URL should be ignored when saving/serving object from cache.
Values: Enabled/Disabled (default).
Parameter
Description
AppDirector User Guide
Traffic Management and Application Acceleration
242 Document ID: RDWR-AD-V0231-UG1105
Purging Cache
In some cases you may want to purge cache content of HTTP responses. Enter the caching policy ID to purge the cache for a particular caching policy, or ALL to purge the cache for all caching policies, or the object's URL to purge only specific objects from a specific policy or from all policies
To purge cache 1.From the AppDirector menu, select Layer 4 Traffic Redirection > Caching Policies. The AppDirector Caching Policy window is displayed.
2.Select any Layer 4 policy or All, and optionally add a specific object's URL.
3.Click Set. Cache is purged.
Cache Content Invalidation
AppDirector allows you to remove objects from cache by specific object URL or URL with wildcard in it (*). HTTP Cache RFC2616 requires that HTTP requests of certain methods will invalidate cache content related to these requests. • An HTTP request using methods POST, PUT or DELETE causes invalidation of the requested object in the cache. The invalidation can be performed for a specific URL match of the object, i.e. full match of baseURL only when ignore query parameters is enabled, or of BaseURL+parameters when ignore query parameters is disabled. • When the URL ends with an asterisk (*) it will be interpreted as a wildcard, and will cause the entire objects "tree" under the specified URL to be invalidated.
• The wildcard is interpreted in a wide sense; meaning anything that is displayed in URL after that point will be invalidated including multiple page instances differentiated by parameters indicated with them.
• If the URL includes a page name and/or page suffix and then an asterisk, only various instances of the specific page with different parameters (specified after the question mark sign) will be invalidated.
Note:The same functions can be also performed from AppDirector's WBM interface.
To remove objects from cache by specific object URL or URL with wildcard in it (*)
1.From the AppDirector menu, select Layer 4 Traffic Redirection > Caching Policies. The AppDirector Caching Policy window is displayed.
2.Select any Layer 4 policy or All. 3.Enter the Object URL or URL with wildcard in it (*). Using this method means that the wildcard can appear in the middle of the URL as well, to replace any characters.
4.Click Set. The objects are removed from cache.
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 243
Caching URL Rule Lists
AppDirector allows you to define Cache behavior in terms of caching responses and serving requests from cache. You can define rules that determine whether to cache on top of the RFC headers decision. If rules specify caching, you can then configure the time (in seconds) of the object to be cached. The Cache URL Exception Rule-List is used to create exceptions to the set responses caching behavior and can be used alternatively as in a positive model or negative model.
Using Cache URL Rule-List in Negative model
When Cache Policy “Respect Server Headers” parameter is set to “Cache All”, AppDirector does not inspect HTTP responses Headers for “Cache-Control” directives. Whenever a received object is within the size limits (Minimum size-Maximum Size) set in the Cache Policy, it is Cached. This mode assumes that the Web Server was not configured to send correct Cache-Control directives. Here, you need to provide, in the URL Exception Rule-List, a list of all objects URIs that should not be cached.
Using Cache URL Rule-List in Positive model
When Cache Policy “Respect Server Headers” parameter is set to “Respect All” AppDirector inspects every response HTTP headers and caches them according to “Cache-Control” headers directives. This mode assumes that the Web Server was configured correctly to provide the right Cache-Control directives for every object. However, you may want to make exceptions to caching behavior and configure using the server headers, where you can use the URL exceptions Rule-List. In this model the Rule-List will include mainly positive (Cache) expectations to server received behavior per URI. To configure the AppDirector Caching URL Rule List 1.From the AppDirector menu, select Layer 4 Traffic Redirection > Caching URL Rule Lists. The AppDirector Caching URL Rule List window is displayed.
2.Set the parameters.
Parameter
Description
Rule-List Name There are multiple rule-lists. Each is a policy that contains multiple rules.
Default: none
Rule Priority Location of the rule in the Rule-List. Since Rule-Lists are scanned for a match from top (priority 1) to bottom (priority ~65000) this enables you to set the location of the rule in the rule-list. See Leveraging Rule List Behavior, page 236
.
Rule Name Name of each rule in the Rule-List used to identify it.
Default: Empty
Domain Comparison Method
Defines whether should be evaluated as a String or Regular Expression
Values: None (default)/Text Match/Regular-Expression
Domain Defines the Virtual Host for which this rules applies
Note: When the Domain Comparison Method is defined as "None" this field cannot be used. If Domain Comparison Method is defined as Text Match or RegEx, it must be defined.
URL Comparison Method
Defines whether URL field should be evaluated as String or Regular Expression
Values: Text Match (default)/Regular-Expression
AppDirector User Guide
Traffic Management and Application Acceleration
244 Document ID: RDWR-AD-V0231-UG1105
3.Click Set. Your configuration is set.
Compression
Today’s Web-based applications which are richer in their textual and visual content still run over non-optimized HTTP protocol, which was originally designed for dial-up speed applications and one way transfers of data between two machines, and is therefore less efficient at dealing with the new types of multi sequence and high bandwidth web traffic. This “chatty” nature of HTTP and the growing volume of each transaction, due to the richer content, slow response time considerably and consume expensive bandwidth.
A Radware hardware-based compression solution can ensure optimal application delivery and bandwidth savings, as can be seen in figure 4, through compression of web pages such as HTML and JavaScript in real-time before transmission on the network. This is important especially for small remote offices and home offices users where bandwidth may be limited. This dynamic HTML compression accelerates traffic by reducing the payload using an open compression standard (gzip and Deflate), providing a powerful performance boost since HTML is an ASCII text, which is highly compressible. The support of industry-standard gzip algorithm (as well the Deflate algorithm) ensures compatibility with virtually all popular web browsers without requiring any special software installation on the end-user machine.
AppDirector offers options to control compression behavior. These capabilities include the ability to define whether objects should be compressed for Browser, Content-Type or URL specific behavior, and view and use Predefined exceptions of the default compression behavior based on known Browsers limitations. Compression Policies
HTTP Compression is a publicly defined way to compress content (mostly textual) transferred from Web servers across the world wide Web to browsers. The impact of compression is that the number of transmitted bytes is reduced and thus a higher performance is gained. HTTP Compression uses public domain compression algorithms to encode HTML, XML, JavaScript, CSS and other file formats at the server-side. AppDirector Compression policy includes 3 levels of optional exceptions. The First level is a list of known problems (bugs) in commonly used browsers that cause them to mishandle specific types of compressed content and thus predefined expectations exists to avoid these problems. This list can be viewed as the in the Browsers Exceptions Rule-List screen as the “Predefined Browser Limitation Rule-List”. The “Predefined Browser Limitation Rule-List” can be customized by copying it using the Copy Rule-Lists into a new Browser Exceptions rule list. The second level of exceptions provided in the form a customized Browser exceptions Rule-List that can define compression behavior in term of browser type (User-Agent) and Content-Type (File type as it is displayed in Object headers). The third level of exceptions allows defining very specific compression behavior per URI, similarly to URL Define URL of specific object (file/folder) to be matched by this rule.
Default: empty
Cache Values: Enable/Disable (Default)
Expiration Time Values: 0 - 86400 (24hr)- default.
Note: Time is accepted only if Cache is enabled.
If Value is set to 0 then cache time is set according to the minimum between time from server header (Expires or Max-Age headers) and the Cache policy Max-time-to-cache parameter. This allows you to create rules that force caching without affecting the time set by the servers. This is useful when you create a general rule for No-Cache and want to create an exception within it. For more information on these exceptions see Leveraging Rule List Behavior, page 236
.
Parameter
Description
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 245
Cache URL exception Rule-List. Exceptions are evaluated from most granular (URL Exceptions) through to more gross ones (Browser Exceptions) to the most general ones (Predefined Browser Limitations) to allow user to use them a narrowing series of filters.
You can configure compression of HTTP content from AppDirector to the client. AppDirector supports either Gzip or Deflate algorithms. AppDirector has a default compression by software service. The compression level indicates how much the file is compressed. It does not indicate the compressed file size, this depends on the file content itself. To configure the AppDirector Compression Policy 1.From the AppDirector menu, select Layer 4 Traffic Redirection > Compression Policies. The AppDirector Compression Policy window is displayed.
2.Set the parameters.
Parameter
Description
Policy Name (Mandatory)
Name of Policy.
Default: Empty
Algorithm Used for defining the preferred compression algorithm which is used by AppDirector if client can receive both Gzip and Deflate compressed content.
Values: Gzip (default), Deflate Engine Defines the type of compression engine used and enables you to choose software compression or hardware compression. Default: Software (if Hardware card is installed, default becomes Hardware. If not installed Hardware is not allowed).
Minimum Content Length (Bytes)
Minimum file size to be compressed to avoid wasting resource on files that are already small. Default: 10240 Bytes
Note: If content length header is not specified, limit does not apply
Maximum Content Length (Bytes)
Maximum value of Content Length header in K-bytes of the object to be compressed. Values: From size configured in Minimum Content Length to 104857600 Bytes
Default: 104857600 Bytes
Notes: • If content length header is not specified, then limit does not apply.
• Value is 0 (unlimited) following upgraded Compression policies.
Compression Level Used for setting the Gzip compression level.
Values: Low <1 (default) > 9 High. ( Gzip software compression only).
Note: Changing the compression level to > 1 has a severe impact on throughput and only a minor reduction in compressed file size.
Allow Compression By Server
This deletes the Accept Encoding Header from requests sent to the server to prevent it from performing compression.
Values: Disabled (default)/enabled
AppDirector User Guide
Traffic Management and Application Acceleration
246 Document ID: RDWR-AD-V0231-UG1105
3.Click Set. Your configuration is set.
4.Go to Layer 4 Policies, page 200
.
5.In the required Layer 4 policy, select the compression policy that you configured
Compression Browsers Exception Rule Lists
This enables you to define Rule-Lists of Compression exceptions based on User-Agent (Browser type) or Content-type (file type). These exceptions are evaluated after the Compression URL exceptions, so they can be overrided by them, if needed. Use Predefined Browser Exceptions
Enable or Disable workarounds for browser limitations for compression according to their type.
Values:
• Predefined Browser Limitations List (default)
• None
Note: Predefined Browser Exceptions are defined in the Predefined Browser Limitations Rule-List that can be found in the Compression Browsers Exception Rule Lists, page 246
.
Browser Exceptions Rule List
Helps to skip compression of certain objects that create a problem when uncompressed or require too much resource with little benefit (for example, PDFs & PPT folder).
Values: None (default)/Specific URL
URL Exceptions Rule List
Define specific URLs (files/folders) for which all other settings should be overridden and compression or no-compression should be done.
Values: None (default)/Specific URL
Notes:
• You can define Domain without anything in the URL field to support use-cases of different behavior per domain. • However, if the Domain is not defined (Domain_type=none), then the URL field is mandatory.
Parameter
Description
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 247
To configure the AppDirector Compression Browser Exceptions Rule List 1.From the AppDirector menu, select Layer 4 Traffic Redirection > Compression Browsers Exceptions Rule Lists. The AppDirector Compression Browser Rule List window is displayed.
2.Set the parameters.
3.Click Set. Your configuration is set.
Note:To manage Rule-Lists efficiently, use the filter boxes at the top of the Rules table.
Compression URL Rule-Lists
This enables you to define Rule-Lists of Compression exceptions based on object URL (file/folder). These exceptions are first evaluated making them the most granular means of defining compress/
don't-compress behavior.
Parameter
Description
Rule List Name Rule-List name. There are multiple rule-lists. Each Rule-List is a policy that contains multiple rules.
Default: Empty
Rule Priority Location of the rule in the Rule-List. Since Rule-Lists are scanned for a match from top (priority 1) to bottom (priority ~65000).
Default: 200
This enables you to set the location of the rule in the rule-list. See Leveraging Rule List Behavior, page 236
.
Rule Name Name of each rule in the Rule-List used to identify it.
Default: Empty
User Agent Comparison Method
Defines whether the User Agent parameter should be evaluated, as a String or Regular Expression.
Values: Text Match (default), Regular Expression
User Agent Client program used to access servers on a network.
Values: Empty (default), Regular, Regex
Content Type Comparison Method Defines whether this should be evaluated as String or Regular Expression
Values: Text Match, Regular Expression
Content Type Define Content Type string to match for this rule
Default: text/html
Compress Values: Enabled (Default), Disabled AppDirector User Guide
Traffic Management and Application Acceleration
248 Document ID: RDWR-AD-V0231-UG1105
To configure the AppDirector Compression URL Rule List 1.From the AppDirector menu, select Layer 4 Traffic Redirection > Compression URL Rule-
Lists. The AppDirector Compression URL Rule List window is displayed.
2.Set the parameters.
3.Click Set. Your configuration is set.
Note:To manage Rule-Lists efficiently, use the filter boxes at the top of the Rules table.
Parameter
Description
Rule-List Name Rule-List name. There are multiple rule-lists. Each Rule-List is a policy that contains multiple rules.
Default: Empty
Rule Priority Location of the rule in the Rule-List. Since Rule-Lists are scanned for a match from top (priority 1) to bottom (priority ~65000) this enables to set the location of the rule in the rule-list. See Leveraging Rule List Behavior, page 236
.
Default: 1
Rule Name Name of each rule in the Rule-List used to identify it.
Default: Empty
Domain Comparison Method
Allows defining different behavior for specific URLs within different virtual hosts on the same server. Defines whether used at all (None), or to be evaluated as a String or Regular Expression
Values: None (default)/Text Match/Regular-Expression
Domain Defines the Virtual Host for which this rules applies
Notes:
• When Domain Comparison Method is defined as None this parameter cannot be used. • If Domain Comparison Method is defined as Text Match or RegEx it must be defined.
URL Comparison Method
Defines whether URL field is to be evaluated as String or Regular Expression
Values: Text Match (default)/Regular-Expression
URL Define URL of specific object (file/folder) to be matched by this rule.
Default: Empty
Compress Values: Enable/Disable (Default)
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 249
Layer 7 Traffic Management
This section describes the different capabilities available for application-aware traffic management and includes these topics:
• Layer 7 Methods, page 249
• Layer 7 Farm Selection, page 256
• Layer 7 Statistics, page 259
• Layer 7 Modification, page 259
• Layer 7 Server Persistency, page 275
Layer 7 Methods
A Layer 7 Method defines a specific criteria (namely the existence or non existence of certain specific content within the message), evaluated on a specific part of each handled message. Layer 7 Methods are used in load balancing and modification decisions. A condition will evaluate to TRUE only if all values specified in the method match values appearing in the specified part of the message. In addition, Layer 7 Methods are used to define the modification required on the traffic (different Layer 7 method is used to identify the traffic where modification is necessary).
AppDirector User Guide
Traffic Management and Application Acceleration
250 Document ID: RDWR-AD-V0231-UG1105
The following table shows the available Layer 7 methods and where they can be used:
Note:
>> All content settings of the Methods are case sensitive.
>> * - Only URL methods that have Path argument but no Host argument can be used. To configure Layer 7 methods 1.From the AppDirector menu, select Layer 7 Farm Selection > Methods. The Method Table window is displayed.
2.Click Create. The Method Table Create window is displayed.
Method Type
Identifies
Available for Layer 7 Farm selection
Available for Layer 7 modifications
Identify traffic (Match)
Modify traffic (Action)
URL Hostname and/or path in Host header or in URL for proxy requests
x Insert, Remove*, Replace
Insert*, Replace
File Type File type in URL x Insert, Replace, Remove Replace
Header Field Header field x Insert, Remove, Replace, Replace All
Insert, Replace, Replace All
Cookie Cookie header in request message x Insert, Remove, Replace
Insert, Replace
Regular Expression
String anywhere in message (for Layer 7 modifications only in header area)
x Insert, Remove, Replace
Text String anywhere in message (for Layer 7 modifications only in header area)
x Insert (Header Only), Remove, Replace
Insert (Header Only) Replace (Header and Body)
Status Line Status Line Insert, Replace Replace
Set Cookie Set Cookie Header Insert, Remove, Replace
Insert, Replace
Advanced URL Condition
URL in request message or HREF in response body
Replace
Advanced URL Modification
URL in request message or HREF in response body
Insert, Replace
RADIUS Attribute
Specified RADIUS attribute value x
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 251
3.Set the parameters.
4.To define the arguments relevant to the selected method, click the option button alongside. The arguments window for the selected Method type is displayed. Note:In the case of “Advance URL Condition” and “Advance URL Modification”, arguments appear as fields in the Method Create/Edit window and not as separate windows.
This table describes the various arguments for available Method Types.
Parameter
Description
Method Name Name that you want the method to be recognized as.
Example: Method Name = Test 1
Method Type Select one of the method types shown in Table 2 - Layer 7 Method Arguments, page 251
.
Example: Method type = Header Field
Arguments Appropriate argument type will appear when clicking the file selection icon. Select according to Hostname and Path. Table 2: Layer 7 Method Arguments
Method Type
Method Specific Parameters
Description
Example
URL Host Name Host name part of URL in the header.
Values: None (default), define string. String should be according to hostname limitations.
Host Name = www.a.com Path Path part of URL in the header indicates matching/action on path
Values: None (default), string up to 256 characters. String can contain only characters allowed in path.
Path = cgi-bin
File Type File Type Type of file in the URL TYP=html
Header Field Header Field Specific header field (mandatory)
Note: If the value of header field is null (no value) then it acts as a wildcard so that there is a match for any packet with such a header with any value. HDR=Accept-
Language|TKN=en
-us
Token Value inside the specific header field TKN=en-us
Token Match Specify whether the configured token value should be exact packet token value or be contained in the packet token value.
Values: Equal, Contain
TMATCH=EQ
AppDirector User Guide
Traffic Management and Application Acceleration
252 Document ID: RDWR-AD-V0231-UG1105
Cookie
Available only if you have Cookie Persistency License.
Cookie Key Specific Cookie Key in the request Cookie header (mandatory)
KEY= server|VAL=red
Cookie Value Specific Cookie value VAL=red
Regular Expression Regular Expression
Regular Expression (string pattern matching)
EXP=.abc
Set Cookie Key A specific Cookie Key in the reply Set Cookie header (mandatory)
KEY=server
Value Specific Cookie value VAL=red
Path Path part of URL P=cgi-bin
Domain Domain to be added to the cookie DMN=service.com
Expire After This determines for how long the client can use this Cookie. This value is added to the system time at the moment of insertion and included in the cookie, to determine the exact time when this cookie expires. The value is followed by a letter that determines the time unit used as follows:
S = seconds
M = no letter for minutes
H = hours
D = days For example:
24H for 24 hours
60M for 60 minutes
1440S for 1440 seconds
1D for 1 day.
EA=3H.
Status Line Status Code Reply Status Code SCD=404
Status Text Text accompanying status code.SPHS=Not Found
Text Text String TXT=abcdefg
Table 2: Layer 7 Method Arguments
Method Type
Method Specific Parameters
Description
Example
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 253
Radius Attribute Attribute Number RADIUS attribute number (AVP) AN=1
Vendor ID Vendor ID for Vendor Specific attribute (VSA). Only relevant when Attribute Number is 26.
VI=311
Vendor Specific Attribute Type Vendor specific attribute type allows to search for a specific sub-attribute inside a vendor specific attribute. Relevant only when Attribute Number is 26.
VT=6
Attribute Value Values of type string (ASCII), integer or IP address only are supported. For Vendor Specific attributes only values of type string are supported.
AV=domain.com
Match Type Defines how requested attribute value is searched within the packet attribute value. Applies to “string” values, only.
Values:
• Equal (EQ)
• Contain (CT)
• Prefix (P)
• Suffix (S)
M=S
Advanced URL Condition
Protocol Type of protocol selected:
Values: None (default)/HTTP /HTTPS
for example, HTTP.
Host Name Host name part of URL in HTTP header.
Values: Empty (default), define string. String according to hostname limitations.
Host Name = www.a.com Hostname Match Type
Indicates how hostname matching of sting is performed. Values: None (default), Equal, Contain, Prefix, Suffix Table 2: Layer 7 Method Arguments
Method Type
Method Specific Parameters
Description
Example
AppDirector User Guide
Traffic Management and Application Acceleration
254 Document ID: RDWR-AD-V0231-UG1105
Port Indicates matching/action on Port.
Values: 0 (default), Port number Path Path part of URL in HTTP header indicates matching/action on path
Values: Empty (default), string up to 256 characters. String can contain only characters allowed in path.
Note: if there is no dot in the last element of a path, the entire string, until the end of URL or first non-
alphanumeric char is called a Path and there is no page element there. Therefore in these examples:
http://abc.com/XXXX/
YYY?param
http://abc.com/XXXX/YYY Radware refers to the path as “XXXX/YYY” .
Path = cgi-bin
Page Name Indicates matching/action on Page name.
Values: Empty (default), define string
Page Type Indicates matching/action on page type
Values: Empty (default), define string of file extension
Path Match Type
Indicates how path matching of sting is done Values: None (default), Equal Contain, Prefix, Suffix Table 2: Layer 7 Method Arguments
Method Type
Method Specific Parameters
Description
Example
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 255
5.Select the options as shown in the table above and click Set. You are returned to the main Method Table window.
6.Click Set. Your configuration is set.
Advanced URL Modification
Protocol Type of protocol selected:
Values: None (default)/HTTP /HTTPS
for example, HTTP.
Host Name Host name part of URL in HTTP header.
Values: Empty (default), define string. String should be according to hostname limitations.
HN=
www.a.com or HN=www.a.com|P
=cgi-bin
Port Indicates matching/action on Port.
Values: 0 (default), Port number Hostname ActionType
Indicates action to be taken on hostname
Values: None (default), insert before, insert after, remove, replace
Path Path part of URL in HTTP header indicates matching/action on path
Values: Empty (default), string up to 256 characters. String can contain only characters allowed in path P=cgi-bin
Path Action Type
Indicates matching/action on page type
Values: None (default) or define string of file extension. Page Type Indicates matching/action on page type
Values: Empty (default), define string of file extension
Table 2: Layer 7 Method Arguments
Method Type
Method Specific Parameters
Description
Example
AppDirector User Guide
Traffic Management and Application Acceleration
256 Document ID: RDWR-AD-V0231-UG1105
Dynamic Values for Method Parameters (Tokens)
When Layer 7 methods are used to modify HTTP, AppDirector can define the value to be used to insert or update a Layer 7 header (Layer 7 method argument) as dynamic information taken from the traffic. The following values can be used:.
The variables can be used in conjunction with static text; for example, 'External-IP-port: $VIP:$VIP_Port'. To indicate a $ in the text, use $$.
Layer 7 Farm Selection
The Layer 7 content aware decision making mechanism allows providing multiple services via a single entry point (IP and application port). For example:
• Providing content to end users based on language and/or type of browser (PC or mobile).
• Providing differentiated service to e-commerce customers based on what they want to buy (URL). Layer 7 farm selection is available for:
• HTTP or other HTTP-like (has HTTP-like header) TCP protocols.
• UDP protocols. Notes:
>> When performing Layer 7 farm selection for UDP traffic, AppDirector inspects each packet separately and selects the appropriate farm and server.
>> Layer 7 farm selection is NOT available for dynamic protocols, such as FTP and TFTP. Layer 7 Farm Selection Flow
1.When AppDirector receives the first packet of a session destined to a Virtual IP address, it searches for a Layer 4 Policy that matches the Layer 4 Protocol, Destination Port, Source IP, etc. (see Layer 4 Policies Lookup Mechanism, page 203
).
2.If the matched Layer 4 Policy is for TCP traffic and is linked to a Layer 7 Policy, Delayed Binding is activated. 3.AppDirector performs a TCP handshake with the client to receive the application request.
4.When AppDirector receives enough information, it matches the data in the request with each one of the entries of the Layer 7 Policy attached to that specific Layer 4 Policy. If traffic is UDP, the matching process is performed for each packet. Value
Description
$Blank Used when you want 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 to remove any expiration from cookie).
$Client_IP Original client IP as it is displayed in the request from AppDirector.
$Client_Port Original client port as it is displayed in request from AppDirector.
$VIP_IP Original destination IP as it is displayed in the request that arrives from AppDirector.
$VIP_Port Original destination port as it is displayed in request 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.
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 257
5.Once a match is found, AppDirector load balances the traffic to the farm defined in the matched entry. For HTTP, HTTPS and SIP, the action of a Layer 7 policy can be to redirect the traffic, instead of load balancing it to a farm.
6.AppDirector selects the best server for the task from the farm providing the requested service.
7.With TCP traffic, AppDirector initiates a TCP handshake with the server and forwards traffic, once connected. For UDP, AppDirector just forwards the traffic to the selected server.
Configuring Layer 7 Farm Selection
Layer 7 farm selection is configured by defining Layer 7 policies and attaching each Layer 7 policy to a Layer 4 policy. Each Layer 7 policy can include a number of entries. Each entry defines Layer 7 condition and the action - load balancing to a specific farm or redirection to a specific destination (host name or IP). For example, a Layer 7 Policy can send an English request for www.a.com to one farm, and a German request to a .gif file to another farm. When AppDirector matches new session data to a Layer 7 policy, the entries are matched according to their index (from lower to higher index) and the first matching entry is used. For this reason when there are overlapping conditions, the most specific condition should have the lowest index.
Note:If no matching Layer 7 Policy entry is found, the session is discarded - if it is TCP, a RST is sent to client.
To configure Layer 7 policies 1.From the AppDirector menu, select Layer 7 Farm Selection > Policies. The Layer 7 Policy Table window is displayed.
2.Click Create. The Layer 7 Policy Table Create window is displayed.
3.Set the parameters.
Parameter
Description
Policy Name Name of the policy. Policy Index Order in which policy entries are matched. You cannot update the Index once it is defined. First Method This is the first Layer 7 method used for classification, to select a specific farm. Each Layer 7 Policy entry can use up to two Layer 7 criteria, (Layer 7 Methods) such as URL or HTTP Header, and the criteria is combined with AND logic. Also see Layer 7 Methods, page 249
.
Second Method This is the second Layer 7 method used for classification to select a specific farm. Classification is according to logical AND of first and second methods. Each Layer 7 Policy entry can use up to two Layer 7 criteria, (Layer 7 Methods) such as URL or HTTP Header, and the criteria is combined with AND logic. Also see Layer 7 Methods, page 249
.
Farm Name Farm to which the traffic must be load balanced when this entry’s criteria is matched.
Note: You can define an empty string as the farm name. When such rules are matched, AppDirector resets the TCP connection, effectively blocking access.
AppDirector User Guide
Traffic Management and Application Acceleration
258 Document ID: RDWR-AD-V0231-UG1105
4.A policy can have a number of arguments (optional). To select an Argument, click the option button alongside. The Arguments for Policy window is displayed.
5.Select the options as shown in the table below and click Set. You are returned to the main Layer7 Policy Table window. In the Arguments field, you can view all configured arguments in string format. Each argument has its own code displayed in string format.
Note:The arguments are case sensitive, meaning that when you configure the Arguments string directly, the arguments keys must be defined in upper case.
6.Click Set. Your configuration is set.
Parameter
Description
Arguments Retain HTTP Persistency (PRSST): If the argument is ON (or undefined), AppDirector maintains HTTP 1.1 persistency as follows:
• The HTTP version is not changed and the connection header is not changed
If the argument is OFF, AppDirector breaks HTTP 1.1 persistency as follows:
• HTTP 1.1 requests with header connection: keep-alive are modified before being sent to the server, the version is changed to 1.0 and the connection header is changed to “connection: close”.
HTTP Redirect To (RDR): Performs HTTP redirection to the specified name or IP. • When using this argument, leave the Farm Name field empty. Values are case sensitive.
• All arguments in Layer 7 Policy can use up to 255 characters, including parameter names and segment markers.
Note: To avoid appending the URI requested by the client at the end of the Redirect-To string, you can set @ as the first character of the Redirect-To parameter. For example, when the user requests www.site.com/index.htm and the Redirect-To of the selected server is @www.a1.com, the user is redirected to www.a1.com rather than to www.a1.com/index.htm.
HTTPS Redirect To (RDRS): AppDirector redirects the HTTP request to the specified name or IP and modifies the request to a HTTPS request.
Redirection Code (RDRC): Defines the code to be used for redirection. Options are:
• 302 Moved Temporarily (uses 302 code irrespective of HTTP version)
• RFC Moved Temporarily (the redirection code is according to the RFC, for HTTP1.0- 302 and for HTTP1.1 - 307)
• Moved Permanently (code 301)
SIP Redirect To (RDRSIP): Performs SIP redirection to the specified name or IP.
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 259
Layer 7 Statistics
You can view statistics for Layer 7 Policies. For each policy, you can view the total number of matched HTTP GET requests and the number of HTTP GET requests per second. To view statistics for farms 1.From the AppDirector menu, select Layer 7 Farm Selection > Statistics. The Layer 7 Policy Statistics Table window is displayed, which contains the following read-only parameters:
2.Click on a Policy Name. Statistics on that policy appear.
To reset Layer 7 statistics
Click Set. The Layer 7 statistics counters have been reset.
To view statistics for farms via CLI
Use the command appdirector l7 farm-selection statistics
.
Layer 7 Modification
You may often need to change the headers or body of a HTTP session, for a variety of reasons. Some of the examples are:
• Inserting a HTTP Header X-Forwarded-For when redirecting traffic, to convey to the Destination server who was the originator of the communication.
• Removing a HTTP Header from server replies to clients to hide server identity.
• Inserting cookies for persistency purposes.
AppDirector:
• provides extensive Layer 7 modifications capabilities including, inserting, removing and updating Layer 7 headers.
• 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. • allows you to change URLs in HTTP headers and body.
Layer 7 modifications support HTTP traffic and SIP/UDP traffic only.
Parameter
Description
Policy Name Name of the policy.
Policy Index Search order of your policy, for example, one will make the policy appear first. Total Matches Total number of matched requests.
AppDirector User Guide
Traffic Management and Application Acceleration
260 Document ID: RDWR-AD-V0231-UG1105
Note:What is considered “a Path” ?
if there is no dot in the last element of a path, the entire string, until the end of URL or first non-
alphanumeric char is called a Path and there is no page element there. Therefore in these examples:
http://abc.com/XXXX/YYY?param
http://abc.com/XXXX/YYY Radware refers to the path as “
XXXX/YYY
” .
Layer 7 Modification Rules
Layer 7 Modifications rules are attached to farms, indicating modifications to requests and responses that are being forwarded by AppDirector. A number of different rules can be performed on traffic to the same farm, where the order of execution is given by the rule index.
Each rule defines the traffic that needs to be modified, the modification type that is performed and the modification itself. To define traffic modification criteria and the modification itself, Layer 7 Methods
are used.
Note:When multiple rules are configured for the same farm, they should not define modifications on the same section. If such modification rules are configured, only the first one, (with the lowest index), will be performed. To create a Layer 7 Modification Rule 1.From the AppDirector menu select Layer 7 Modification > Rules. The Layer 7 Modification Table window is displayed.
2.Select Create. The Layer 7 Modification Table Create window is displayed.
3.Set the parameters.
.
Parameter
Description
Name Key name.
Index Sets the order in which AppDirector matches traffic to the modification rules and performs the modification.
Default: 1
Farm Name Unique identifier. The farm where this rule is applied.
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 261
Modification Scope Indicates the part of the message upon which modifications are performed.
Values:
• Header Only (default): Modification is performed on the message header only.
• Header and Body: Modification is performed on the message header and body. URL Rewrite is the only modification possible in this mode. Also see Content Types that Layer 7 Header and Body Modification can process, page 265
.
Note: When SSL Policy Protocol Redirection and L7 Header & Body Modifications are enabled on the same service, and the server sends a 302 Redirect response, the protocol of the new location is always set to HTTPS to enable the redirect location to work for the clients. This is regardless of the setting in the L7 Modification method.
Direction Indicates if modification is done only on users' requests, only on server responses or on both users' requests and servers' response. Values: Request (default), Response, Bidirectional Notes:
• In "Headers Only" mode this field will show "Request" and "Reply".
• Bidirectional latency means AppDirector allows modification to the header and body on responses as part of URL obfuscation.
Admin Status Allows disabling a rule without removing it.
• Enabled (default)
• Disabled Parameter
Description
AppDirector User Guide
Traffic Management and Application Acceleration
262 Document ID: RDWR-AD-V0231-UG1105
4.The rest of the parameters depend on the value of the Modification Scope.
a.When Modification Scope is set to Header only:
b.When Modification Scope is set to Header and Body:
5.Click Set. Your configuration is set.
Parameter
Description
Modification Type Defines the Layer 7 modification:
• Insert (default): Inserts a Layer 7 parameter • Replace: Replaces a Layer 7 parameter
• Remove: Removes a Layer 7 parameter
• Replace All — Replaces multiple instances of tokens that may exist in the header field (up to 3) in all instances of the header field.
Note: This option is relevant only when the Match Condition value and the Modification value specify Layer 7 methods with Method Type set to Header Field, otherwise the Replace All option functions in the same way as the Replace option.
Match Condition Layer 7 method that defines sessions where a modification is made. When the Modification Scope is Header Only, this field is mandatory when Modification Type is set to Remove, optional if Modification Type is set to Insert and mandatory when Action is set to Update (unless it is a Status Line or URL method).
To view details of Layer 7 methods, or to define a new Layer 7 method, click the Layer 7 Methods button to display the Layer 7 Methods table. You can select a Layer 7 method in the Layer 7 Methods table, then click OK to close the table. Click Cancel to close the table without selecting a Layer 7 method.
Modification Layer 7 method that defines the modification that is made. When the Modification Scope is Header Only, this field is mandatory when Modification Type is set to Insert or Update, and redundant if Modification Type is set to Remove.
To view details of Layer 7 methods, or to define a new Layer 7 method, click the Layer 7 Methods button to display the Layer 7 Methods table. You can select a Layer 7 method in the Layer 7 Methods table, then click OK to close the table. Click Cancel to close the table without selecting a Layer 7 method.
Parameter
Description
Header and Body Condition
This allows you to select from defined Layer 7 Methods of type “Advanced URL condition”.
This defines the condition upon which modification is performed and what is modified.
Header and Body Modification
This allows you to select from defined Layer 7 Methods of type “Advance URL Modification”.
This defines the condition upon which modification is performed and the modification action and data.
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 263
Header Only Modification Type Behavior
Configuration
Behavior *
Insert Match Condition:
Methods that can be used are: • URL
• File Type
• Header Field
• Cookie
• Set Cookie
• Regular Expression
• Text
Modification (Mandatory): Methods that can be used are (with no restriction to the method used for Match Condition): • URL - with Path argument only
• Header Field
• Cookie
• Set Cookie
• Text
The Match Condition, when present, defines the traffic where the Insert action must be performed.
The result of the Insert action depends on the method used as Modification:
URL: Appends the text configured in the path argument at the end of the original requested path in the Host header or, in case of proxy requests, from URL.
Header Field: Inserts the header field at the beginning of the header area
Cookie: Inserts cookie header at the beginning of the header area, after the request line. Relevant to Request direction only.
Text: Inserts text at the beginning of the header area
Set Cookie: Inserts Set Cookie header at the beginning of the header area. Relevant to Reply direction only.
Remove Match Condition (Mandatory): Methods that can be used are: • URL (with Path argument only)
• File Type
• Header Field
• Cookie
• Set Cookie
• Regular Expression
• Text
Note: Modification cannot be defined for Remove action.
The result of the Remove action depends on the method used as Modification:
URL: Removes path from Host header or, in case of proxy requests, from URL. In case that the match is on part of the path, then only the matched part is removed.
File Type: Removes file type in the URL. Relevant to Request direction only.
Header Field: The entire matching header field is removed, not only the argument specified in Match Condition. Only the first encountered matching header field in the message is removed. To remove part of a header field value, the Text method can be used, but it requires that the removed value is quite unique in the packet.
Cookie: The entire key=value pair is removed form the Cookie header, not only the argument specified in Match Condition. Relevant to Request direction only.
Regular Expression: Any string matching the condition is removed.
Text: The string matching the condition is removed.
Set Cookie: The entire Set Cookie header is removed, not only the arguments specified in Match Condition. Relevant to Reply direction only.
AppDirector User Guide
Traffic Management and Application Acceleration
264 Document ID: RDWR-AD-V0231-UG1105
Replace Match Condition (Optional):
When Match Condition is not defined the only Modification methods allowed are URL and Status Line.
When Match Condition is defined the Match Condition and Modification methods must be of the same type. The only exceptions are:
• When using Text as Modification method either a Text or Regular Expression can be used as Match Condition. • When using Advanced URL Modification as Modification method, Advanced URL Condition must be the Match Condition.
The Match Condition, when present, defines the traffic and the object where the Replace action must be performed.
Action performed by Replace action can be:
• Update of arguments specified in the Modification method
• Removal of arguments - when the update value in the Modification method is set to $Blank
• Insert of arguments (only for Set Cookie and Status Line methods) - when the argument defined in the Modification method, does not appear in the original message.
The whole argument is being updated and not only the match area. To replace only part of an argument use text or Regular Expression as Match Condition and Text as Modification.
The result of the Replace action depends on the method used as Modification:
URL: Replaces hostname and/or path in Host header or, for proxy requests, in URL. File Type: Replaces file type specified by Match Condition with the one specified in Modification method.
Header Field: Replaces values defined in Modification method in header field specified by Match Condition. Replaces only the first encountered matching header field in the message.
Cookie: Replaces values defined in Modification method in cookie pair specified by Match Condition. Relevant to Request direction only.
Text: Replaces the string specified by Match Condition with the one specified in Modification method.
Status Line: Replaces values defined in Modification method for Status Line arguments specified by Match Condition. If arguments specified in Modification method are not present in message, they are added. Relevant to Reply direction only.
Set Cookie: Replaces values defined in Modification method for Set Cookie arguments specified by Match Condition. If arguments specified in Modification method are not present in message, they are added. Relevant to Reply direction only.
Configuration
Behavior *
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 265
Note:* Only methods supported for each Action type are mentioned.
Common Layer 7 Modifications
This table shows configuration examples of common Layer 7 modifications:
Content Types that Layer 7 Header and Body Modification can process
The following content types expressed as content-type text/......
can be processed by Layer 7 Header and Body Modification:
Advanced URL Modification: Replaces the URL parameters specified by Match Condition in both header and body URLs (depending on Direction parameter).
Replace All
Header Field Method must be used for both Match Condition and Modification method.
Replaces multiple instances of tokens that may exist in the header field (up to 3) in all instances of the header field.
Example
Modific
ation Type
Direction
Match Condition
Modification
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
asp vnd.wap.wml x-script.csh x-server-parsed-html
css vnd.wap.wmlscript x-script.elisp x-setext
html webviewhtml x-script.guile x-sgml
mcf x-asm x-script.ksh x-speech
pascal x-audiosoft-intra x-script.lisp x-uil
plain x-c x-script.perl x-vcalendar
Configuration
Behavior *
AppDirector User Guide
Traffic Management and Application Acceleration
266 Document ID: RDWR-AD-V0231-UG1105
Layer 7 Modification Rules Automatic Configuration There are two cases where AppDirector automatically generates Layer 7 modification rules.
1.When the Add X-Forwarded-For to HTTP request parameter is enabled in a farm, AppDirector automatically generates a Layer 7 modification rule that inserts the X-Forwarded-For header with the value of the original client IP in packets sent to the server. This capability is useful when AppDirector performs Client NAT on traffic sent to servers - it allows server visibility of the original clients. 2.When the Insert Cookie for HTTP Persistency parameter is enabled in a farm, if the value of this parameter is set to Enabled, AppDirector automatically generates the necessary configuration to insert a cookie that contains the server identifier in the reply and keep persistency for subsequent requests from the same client according to inserted value. A different value is created for each client. The value is encoded using base64 encoding. The device generates the following automatic configuration:
The following entry in Layer 7 methods:
• Name Auto-G <Cookie> Farm Name
• Method Set-cookie
• Key <key>
• Value $Dyn_Cookie_Value (Minimum length is 1 character)
A Layer 7 modification rule for the farm:
• Index (The lowest available character)
• Action Insert
• Direction Server Replies
• Layer 7 Method for Match Empty
• Layer 7 Method for Action Auto-G <Cookie> Farm Name
AppDirector also creates the appropriate Text Match Session ID Persistency entry from the server, before forwarding it to the client.
If Insert Cookie for HTTP Persistency is set to “Enable and remove on return path" AppDirector automatically generates two Layer 7 modification rules, one that inserts a cookie that contains the server identifier and one that removes this identifier from subsequent requests before forwarding them to the server. The Layer 7 methods and modification rules that are automatically generated are read-only. If a user deactivates the capability in the farm configuration, the Layer 7 Modification rule and Layer 7 method automatically generated for this capability are removed.
The following scenarios show the configurations for rewriting different parts of a URL. Configuring URL rewriting policies is performed in the Edit URL Rewrite Policy window.
For all scenario examples, configuration that is not specified means default values are used.
In general, it is recommended to be as specific as possible in the Rewrite configuration. For example, always specify the Domain Name, even when it is not changed.
richtext x-component x-script.perl-module xml
scriplet x-fortran x-script.phyton javascript
sgml x-h x-script.rexx x-javascript
tab-separated-values x-java-source x-script.scheme application/x-javascript
uri-list x-la-asf x-script.sh
vnd.abc x-m x-script.tcl
vnd.fmi.flexstor x-pascal x-script.tcsh
vnd.rn-realtext x-script x-script.zsh
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 267
Layer 7 Modification Examples
Insert X-Forwarded-For
The following scenario displays the modification rule for inserting X-Forwarded-For header with Client IP value in all requests. This is useful for providing servers with the identity of the original client when Client NAT is performed.
Cookie Insert/Rewrite
The following scenarios display the modification rule for inserting or rewriting cookie for persistency purposes. AppDirector can insert a cookie in server reply, if the application does not do it, to ensure subsequent requests from same client are forwarded to the same server. In certain cases the application inserts a cookie in reply, but with the same value for all servers - in such cases AppDirector can rewrite the value with a value that will identify the server.
To insert a Set Cookie header in server reply, with key MyKey and value representing the replying server
To change in server reply the cookie value in a Set Cookie header (Rewrite) with value representing the replying server
Append cookie to URL
Match Condition
Modification
Modification Type
Direction
Optional Header Field method:
• Name=X-Forwarded-For
• Token=$Client_IP
Insert Request
Match Condition
Modification
Modification Type
Direction
Optional Set Cookie method:
• Key=MyKey
• Value= $Server_SID_Cookie or $Dyn_Cookie_Value
Insert Reply
Match Condition
Modification
Modification Type
Direction
Set Cookie-
Key=AppKeyl
Set Cookie method:
• Value=$Server_SID_Cookie or $Dyn_Cookie_Value
Replace Reply
Match Condition
Modification
Modification Type
Direction
Optional URL method:
• Path=?Mykey=MyCookie
Insert Request
AppDirector User Guide
Traffic Management and Application Acceleration
268 Document ID: RDWR-AD-V0231-UG1105
Protocol Rewrite
The following scenarios display the URL Rewriting policy for rewriting the URL protocol in all requests and replies, and in requests and replies of a specific domain:
To change all front-end HTTPS requests to back-end HTTP requests and all HTTP links to HTTPS links: To change HTTPS://www.site.com to HTTP://www.site.com and back:
Examples Domain Name Rewrite
The following examples display the URL Rewriting policy for rewriting the URL domain name:
To change HTTPS://www.front-site.com to HTTP://www.back-server.com
:
Parameter
Match Method for URL
URL Modification Method
Additional Parameters
Protocol HTTPS HTTP
Parameter
Match Method for URL
URL Modification Method
Additional Parameters
Protocol HTTPS HTTP
Domain Name www.site.com www.site.com Comparison- n Type: Equal Operation: Replace
Parameter
Match Method for URL
URL Modification Method
Additional Parameters
Protocol HTTPS HTTP
Domain Name www.front-site.com www.back-server.com • Comparison Type: Equal • Operation: Replace
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 269
To change HTTPS://site.com to HTTP://my.site.com:
Or, alternatively
Note:Setting the back-end Domain Name to "my" instead of "my." results in changing site.com to mysite.com.
To change HTTPS://*.front-site.com/*.* to HTTP://*.back-server.com/*.*:
Note:With Operation Replace, the exact text that is displayed in the Front-end Domain Name is replaced with the text that is displayed in Back-end Domain Name. For example, the URL www.front-site.com/path/page.type with the above configuration is rewritten to www.back-server/path/page.type, and the URL www1.front-site.com/path/page.type is rewritten to www1.back-server.com/path/page.type.
Parameter
Match Method for URL
URL Modification Method
Additional Parameters
Protocol HTTPS HTTP
Domain Name site.com my.site.com • Comparison Type: Equal • Operation: Replace
Parameter
Match Method for URL
URL Modification Method
Additional Parameters
Protocol HTTPS HTTP
Domain Name site.com my.• Comparison Type: Equal • Operation: Add Before
Parameter
Match Method for URL
URL Modification Method
Additional Parameters
Protocol HTTPS HTTP
Domain Name front-site.com back-server.com • Comparison Type: Ends With • Operation: Replace
AppDirector User Guide
Traffic Management and Application Acceleration
270 Document ID: RDWR-AD-V0231-UG1105
Port Rewrite
When the client sends a request to destination port 80 for the URL HTTP://www.site.com, or to HTTP://www.site.com:80 AppDirector rewrites the request to HTTP://www.site.com:8080. For the reply, AppDirector rewrites URLs of HTTP://www.site.com:8080 to HTTP://www.site.com:80.
Note:When the back-end server is listening on port 8080 and there is no port number specified explicitly in the URL, then there is no need for AppDirector to change the port and both Front-End and Back-end Ports must be set to 80. When the Front-End Port is the same as the Back-end Port, the device does not change the port specified in the request. If no port is specified in the client's request or in server's reply, then the device treats it as port 443 for encrypted traffic, and as port 80 for clear text traffic.
Path Rewrite
The following scenarios display the URL Rewriting policy for rewriting the URL path:
To change HTTPS://www.site.com/aaa/*.* to HTTP://www.site.com/mypath/aaa/
*.*
:
Note:Setting the back-end Path to "/mypath" instead of "mypath/" as above, where the operation is "Add Before", results in changing the URL HTTPS://www.site.com/aaa/ to HTTPS://www.site.com//mypathaaa/.
Parameter
Match Method for URL
URL Modification Method
Additional Parameters
Protocol HTTPS HTTP
Domain Name www.site.com www.site.com • Comparison Type: Equal • Operation: Replace
Path aaa mypath/• Comparison Type: Equal • Operation: Add Before
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 271
To change HTTPS://www.front-site.com/aaa/*.* to HTTP://www.back-server.com/
aaa/mypath/*.*:
To change HTTP://www.front-site.com/*aaa*/*.* to HTTP://www.front-site.com/
mypath/*aaa*/*.*:
Note:When Comparison Type is set to ‘Contain’, then Operation ‘Add Before’ implies the additional text is added at the beginning of the path. Similarly, when Operation is set to ‘Append After’, the additional text is added at the end of the path.
Page Rewrite
The following scenarios display the URL Rewriting policy for rewriting the URL page:
Parameter
Match Method for URL
URL Modification Method
Additional Parameters
Protocol HTTPS HTTP
Domain Name www.front-site.com www.back-server.com • Comparison Type: Equal • Operation: Replace
Path aaa/mypath • Comparison Type: Equal • Operation: Append After
Parameter
Match Method for URL
URL Modification Method
Additional Parameters
Protocol HTTP HTTP
Domain Name www.front-site.com www.front-site.com • Comparison Type: Equal • Operation: Replace
Path aaa mypath/• Comparison Type:Contain • Operation: Add Before
AppDirector User Guide
Traffic Management and Application Acceleration
272 Document ID: RDWR-AD-V0231-UG1105
To change HTTPS://www.site.com/aaa/page.type to HTTP://www.site.com/
mypath/newpage.type
:
Note:The Path is defined as the part of the URL between the first slash to the last slash. For a URL like www.site.com/aaa/page.type/ (with a slash at the end) all directories are used as the path, and not as page and page type.
Real Life Examples
The following scenarios of URL rewriting policies combine the rewriting of different parts of a URL in a single policy.
To rewrite the URL HTTPS://www.front-site.com/mypath/*.* to HTTP://www.back-
server.com/*.* use the following configuration
:
Parameter
Match Method for URL
URL Modification Method
Additional Parameters
Protocol HTTPS HTTP
Domain Name www.site.com www.site.com • Comparison Type: Equal • Operation: Replace
Path aaa mypath • Comparison Type: Equal • Operation: Replace
Page page newpage
Parameter
Match Method for URL
URL Modification Method
Additional Parameters
Protocol HTTPS HTTP
Domain Name www.front-site.com www.back-server.com • Comparison Type: Equal • Operation: Replace
Path mypath • Comparison Type: Starts With • Operation: Remove
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 273
To rewrite the URL HTTPS://www.front-site.com/*.* to HTTP://www.back-
server.com/mypath/*.* use the following configuration:
To rewrite the URL HTTPS://www.front-site.com/front-path/*.* to HTTP://
www.back-server.com/mypath/front-path/*.* use the following configuration:
Example Modification Type Replace and Replace All
Assume the following:
— Match Condition specifying a Layer 7 Method HDR=via
and TKN=2.2.2.2
— Modification specifying a Layer 7 Method HDR=via
and TKN=3.3.3.3
— The device receives the following header:
Via: 2.2.2.2:5080;branch=z9hG4bK-3359-354-6-2; 2.2.2.2:5090\r\n
Call-id: abc@cba\r\n
Via: 2.2.2.2:5080;branch=z9hG4bK-3359-354-6-2; 2.2.2.2:5090\r\n
When the Modification Type is Replace, the device changes the header only once, to:
Via: 3.3.3.3:5080;branch=z9hG4bK-3359-354-6-2; 2.2.2.2:5090\r\n
Call-id: abc@cba\r\n
Via: 2.2.2.2:5080;branch=z9hG4bK-3359-354-6-2; 2.2.2.2:5090\r\n
When the Modification Type is Replace All, the device changes the header to:
Via: 3.3.3.3:5080;branch=z9hG4bK-3359-354-6-2; 3.3.3.3:5090\r\n
Call-id: abc@cba\r\n
Via: 3.3.3.3:5080;branch=z9hG4bK-3359-354-6-2; 3.3.3.3:5090\r\n
Parameter
Match Method for URL
URL Modification Method
Additional Parameters
Protocol HTTPS HTTP
Domain Name www.front-site.com www.back-server.com • Comparison Type: Equal • Operation: Replace
Path mypath • Comparison Type: Contain • Operation: Add Before
Parameter
Match Method for URL
URL Modification Method
Additional Parameters
Protocol HTTPS HTTP
Domain Name www.front-site.com www.back-server.com • Comparison Type: Equal • Operation: Replace
Path front-path mypath/• Comparison Type: Contain • Operation: Add Before
AppDirector User Guide
Traffic Management and Application Acceleration
274 Document ID: RDWR-AD-V0231-UG1105
Configuring SIP TCP Header Adaptation
SIP Header Adaptation is used to replace the VIP and server IP addresses in selected SIP TCP header fields. For all SIP TCP requests from clients, AppDirector searches all the header fields that you specify and replaces the VIP with selected server IP address. For SIP TCP requests from servers back to the clients, in the same header fields, AppDirector replaces server IP address with the VIP.
SIP Header Adaptation Use-Case
1.Farm connected to a single VIP.
2.Farm connected to a multiple VIPs.
Match Condition
Modification
Modification Type
Direction
Header Field method:
•"Header = VIA
•"Token = 3.3.3.3 (VIP)
•"Token Match = Contain
Header Field method:
•"Header = VIA
•"Token = $Server_IP
•"Token Match = Contain
Replace All Request
Header Field method:
• Header = VIA
• Token = $Server_IP
• Token Match = Contain
Header Field method:
•"Header = VIA
•"Token = 3.3.3.3 (VIP)
•"Token Match = Contain
Replace All Reply
Match Condition
Modification
Modification Type
Direction
Header Field method:
•"Header = VIA
•"Token = 3.3.3.3 (VIP)
•"Token Match = Contain
Header Field method:
•"Header = VIA
•"Token = $Server_IP
•"Token Match = Contain
Replace All Request
Note: A Layer 7 modification rule for Request direction must be defined for each VIP Header Field method:
• Header = VIA
• Token = $Server_IP
• Token Match = Contain
Header Field method:
•"Header = VIA
•"Token = 3.3.3.3 (VIP)
•"Token Match = Contain
Replace All Reply
Note: For modifications on request, a request Layer 7 modification rule must be defined for each VIP.
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 275
Layer 7 Modification Statistics
Layer 7 modification rules are configured at the farm level. Multiple rules can be configured for each farm. From the Layer 7 Modification Statistics window the Layer 7 modification statistics are viewed.
To create a Layer 7 Modification Table From the AppDirector menu select Layer 7 Modification > Statistics. The Layer 7 Modification Statistics window is displayed which contains the following read-only parameters:
Layer 7 Modification Reset Statistics
You can reset Layer 7 modification statistics from the Layer 7 Modification Reset Statistics window.
To Reset the Layer 7 Modification Statistics 1.From the AppDirector menu, select Layer 7 Server Modification > Reset Statistics. The Modification Reset Statistics window is displayed.
2.Press Set. The global statistics of Layer 7 modification rules are reset.
Layer 7 Server Persistency
This describes persistency from the IP level up to Layer 7, providing application aware server persistency.
Session ID Persistency
When it is necessary to establish multiple connections from the same user to the same server in a farm, these sessions can be identified by application layer information found in the client's requests. AppDirector is able to detect / inspect the Session ID information in the traffic and use it for server selection in further connections, providing application aware server persistency. You can configure different persistency schemes for different applications and for different farms. The Layer 7 server persistency mechanism consists of two major blocks:
1.The packet parser: used to identify the persistency parameter in the traffic.AppDirector allows searching for any Persistency Parameter within a packet in a text or binary format. AppDirector searches for Session ID using the following:
— Text Match Session ID Persistency: AppDirector searches for text strings within the packet. The search can be for any Persistency Parameter anywhere in the packet. — Pattern Match Session ID Persistency: AppDirector matches binary patterns within packets. Binary Session ID Matching is done using pattern matching. You can configure the offset where the pattern begins and a mask to apply to the pattern, before checking if it is in the Session ID Table.
2.Session IDs Management - manages the link between the persistency parameter values and servers to which they apply. There are 2 options:
— Static Session IDs. The user configures persistency parameter values attached to each server farm and also has to configure a Text Match or Pattern Match entry that defines where in the message to search for the statically configured persistency parameter.
Parameter
Description
Modification Name Key name.
Hits since Reset Number of rules matched/changed per rule since the last reset.
AppDirector User Guide
Traffic Management and Application Acceleration
276 Document ID: RDWR-AD-V0231-UG1105
— Dynamically learned values. AppDirector learns persistency parameter values for farm servers from the traffic passing through it and ensures future transactions with the same persistency parameter value are sent to the same farm server. In this case, an aging mechanism is employed to manage the lifetime of each persistency parameter value.
— Hashing. Persistency is ensured by performing hash using the persistency parameter value as input. No values are recorded. This method is especially useful in ensuring URL based persistency for reverse proxy applications. Session ID persistency is available for the following types of traffic:
• HTTP or other HTTP-like (has HTTP-like header) TCP protocols. • UDP protocols. • IP traffic in general (using pattern match). Session ID persistency is NOT available for dynamic protocols, for example, FTP, TFTP.
Notes:
>> When using Session ID Persistency for UDP traffic, AppDirector inspects each packet separately and selects the appropriate server.
>> The Cookie Persistency License allows AppDirector to search the HTTP headers for Session ID Persistency. Without it, AppDirector inspects only the URI and no other HTTP headers.
>> When DSID and Layer 7 Modifications are configured together (when applied to the same request/response) , DISD parsing is performed first, then Layer 7 Modifications. This means that when the modification changes the part in the header to which DISD is referred, the DISD server selection and learning is performed according to the original data, prior to the modifications. General Flow
The general flow is as follows:
Parse Layer 7 data and find the session ID value in request.
1.If found, search the value in the internal session ID table (the internal table includes both statically configured and dynamically learned values).
a.If found, traffic is forwarded to the server indicated in the table.
b.If not found select a server according to farm Dispatch Method if learning is enabled for this farm, learn the new value, either from request or from reply, depending on persistency parameter configuration.
2.If not found, select a server and forward packet normally.
Parameters for All Farms
Persistency method is configured per farm, however the following parameters apply to all farms:
1.Session ID Sharing. With Session ID Sharing, you can share Session ID information among multiple farms, when the same Persistency Parameter is used for the farms. When a specific Session ID is configured or learned through one farm, the same Session ID may also be used for server selection in other farms that use the same Persistency Parameter and the same servers.
2.DSID reply Learning in "First" mode. When using dynamically learned session IDs, this option defines whether the device should inspect each reply of each transaction, on the same TCP session, even if Layer 7 Persistent Switching Mode is set to FIRST for the Layer 4 policy the traffic matched. The default and recommended value is Inspect First Reply. Inspect All Server Replies should only be used if required for compatibility with previous version. AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 277
Configuring Text Match Session ID Persistency
Text Match Session ID persistency mechanism allows identifying persistency parameter by parsing the message and looking for specified text anywhere in the message. To search for Session ID according to Text Match Session ID Persistency 1.From the AppDirector menu, select Layer 7 Server Persistency > Text Match. The Text Match Session ID Persistency window is displayed.
2.Click Create. The Text Match Session ID Persistency Create window is displayed.
3.Set the parameters.
Parameter
Description
Farm Name Name of farm for which session ID persistency is used.
Layer 4 Protocol Layer 4 Protocol for which traffic is intercepted for Session IDs. Values: TCP (Default), UDP or other
Application Port Port for which traffic is intercepted for Session IDs. A value of 0 indicates that all ports must be inspected. Default: 0
AppDirector User Guide
Traffic Management and Application Acceleration
278 Document ID: RDWR-AD-V0231-UG1105
Lookup Mode Defines location within the request where Session ID is displayed. Values:
• Cookie: The device looks within the Cookie header for the value following Persistency Parameter=. The Persistency Parameter is case sensitive.
• Header: The device looks for the value following "Header Name:", if Persistency Parameter is not defined, or within the Header Name for the value following "Persistency Parameter=" when Persistency Parameter is defined . The Header Name and Persistency Parameter are case insensitive.
• RegExp: The device looks anywhere in the packet for the value following "Persistency Parameter=". The identifier is case-
insensitive (unless indicated specifically in the expression).
• URL cookie: The device looks within request-URI for value following "Persistency Parameter=". The Persistency Parameter is case sensitive.
Note: URL cookie cannot be set with a Learning Direction of Server Reply.
• Text: The device looks anywhere in the packet for the value following "Persistency Parameter=". The identifier is case-sensitive.
• XML Tag: The device looks for the specified XML tag value or tag attribute. This enables you to maintain persistency based on a XML request tag/attribute and/or XML response tag/attribute.
• Radius Attribute: Stores the RADIUS Attribute and server, to ensure persistency for traffic sessions. The Persistency Parameter can only be a number (RADIUS attribute), and the attribute number must be searched not until a stop character, but according to the attribute length mentioned in the configured RADIUS attribute.
Notes: • Using Cookie Persistency License allows AppDirector to search the HTTP headers for Session ID Persistency. Without the License, AppDirector inspects only the URI and not further HTTP headers. This applies to the all options listed above.
• URL cookie cannot be set with a Learning Direction of Server Reply.
Persistency Parameter Key of the persistency parameter, up to 64 characters. For example, persistency parameter can be "Call-ID" in SIP, or “Accept-
Language” in HTTP.
Persistency Parameter for Reply
This parameter is only available for XML – in cases where the same value is displayed in parameter X in request and in parameter Y in reply. Persistency Method Defines whether the persistency parameter defined in this entry should be used to ensure persistency based on the regular Session ID table mechanism or via hashing.
Values:
• Use Table (default): Use this persistency parameter via the Dynamic Session ID table to ensure server persistency.
• Hash: Use this persistency parameter as input for the hash function to select a server. The farm Dispatch Method must be set to hashing.
Parameter
Description
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 279
Header Name (when Header Lookup Mode is selected)
Name of the header where the persistency parameter is displayed. Relevant only when Lookup Mode is Header Field.
Note: This parameter does not appear when XML Tag Lookup Mode is selected.
Parameter Match Values: • Exact (Default): Indicates that the configured Persistency Parameter value must exactly match the received Persistency Parameter value. • Prefix: Indicates that the configured value is displayed 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, ‘=’, ‘:’.
Value Max Length Maximum length of the Session ID value if there is no stop character. Values: 1 - 256(default)
Value Offset The offset where the Session ID value resides, within the value following the Persistency Parameter name. Default is 0, meaning value location is right after the Persistency Parameter name and value separator. Value Offset is used when the value of the Persistency Parameter is composed of a dynamic value that changes during the session, followed by a static value that identifies the session, so that AppDirector ignores the dynamic prefix of the value for server persistency. For example, the value is a timestamp followed by client ID, where persistency is based on client ID only.
Default: 0 Stop Chars Characters that indicate the end of the Session ID value. Up to 10 characters can be defined. No delimiters are required in this field. Tab, CR (carriage return), LF (line feed), and so on, are considered as Stop Characters.
Default: ";" Learning Direction Indicates which traffic is inspected by AppDirector to gather persistency information and to use that information for a specific session:
• Server Reply (Default): AppDirector dynamically learns which session IDs are to be associated with each server, according to information in replies from servers. AppDirector inspects also client requests, to find if they contain a session ID that was already learned by AppDirector, to forward them to the correct server accordingly.
• Client Request: Can be used when Session IDs appear only in requests from clients, and means that AppDirector does not inspect replies from servers. This can be used, for example, when persistency is based on client IP that is displayed in X-Forwarded-
For HTTP header, or when only static values of Session IDs are used, as manually configured in the Static Session ID Persistency Table.
• Both Directions: AppDirector inspects both client requests and servers replies to learn about persistency identifiers.
• No Learning: Persistency information is not gathered. You should define this value when Static Session ID Persistency is used.
Parameter
Description
AppDirector User Guide
Traffic Management and Application Acceleration
280 Document ID: RDWR-AD-V0231-UG1105
4.Click Set. Your configuration is set.
Configuring Session ID Hash Persistency
To ensure persistency based on hash of a Layer 7 Session ID
1.Set Dispatch Method to Hashing in the farm configuration (link to farm parameters).
2.Configure the desired persistency parameter as Text Match Session ID, with the Persistency Method set to Hash.
Configuring Pattern Match Session ID Persistency
When the Pattern Match Session ID Persistency mechanism is used, AppDirector matches binary patterns within the packets. Inactivity Timeout [sec] Defines how long the association of Session ID values to servers should be kept when no traffic with this Session ID value is passing through AppDirector. This mechanism is similar to Aging Time in the Client Table. Values: 1 - 86,400 seconds (24 hours)
Default: 60 seconds Ignore Server Reply Used to enhance AppDirector performance when Session ID values can be learned from server reply, when Learning Direction is set to Server Reply or to Both Directions. Values:
• Never (Default): AppDirector searches even if AppDirector already found a Session ID for this session. Here, AppDirector updates the Session ID Persistency table according to data in the server’s reply.
• When ID is in Request: AppDirector performs this way when the Learning Direction parameter is set to Server Reply or to Both Directions. When AppDirector has already found a Session ID in a client's request, it does not further inspect the server reply. When a Session ID already exists in the client's request, and it can be guaranteed that the server does not change that Session ID, you can set this field to When ID is in Request. Tip: Use this option when Static Session IDs are used.
Ignore Source IP When Ignore Source IP is set, only the Session ID info is used for persistency. Sessions with the same session ID are always forwarded to the same server.
Disabling this parameter, forces AppDirector to also use the source IP where there is a session ID match. Two sessions with the same session ID, but with a different source IP address can be forwarded to different servers. This mode is relevant only for dynamic entries.
Default: Enabled.
Parameter
Description
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 281
To search for Session ID according to Pattern Match Session ID Persistency 1.From the AppDirector menu, select Layer 7 Server Persistency >Pattern Match. The Pattern Match Session ID Persistency window is displayed.
2.Click Create. The Pattern Match Session ID Persistency Create window is displayed.
3.Set the parameters.
Parameter
Description
Farm Name Name of farm for which session ID persistency is used.
Application Port Port for which traffic is intercepted for Session IDs. A value of 0 indicates that all ports are inspected. For example, to inspect HTTP Traffic, set Layer 4 Protocol to TCP and Application Port to 80.
Values: Any (default), DNS, FTP, HTTP, HTTPS, NNTP, SMTP.
Layer 4 Protocol Layer 4 protocol for which traffic is intercepted for Session IDs. Can be Values: TCP (Default), UDP or other.
Pattern Mask Mask for the search pattern, also defines length of the pattern matched. This is a hexadecimal field.
Default: 0xffffffff, meaning a 4 bytes long pattern is used for exact match. Max pattern length is 8 bytes.
Maximum pattern length is 128 bits (16 octets).
Inactivity Timeout Defines how long the association of Session ID values to servers should be kept when no traffic with this Session ID value is passing through AppDirector. The mechanism is similar to Aging Time in the Client Table. Values: 1 to 86,400 seconds (24 hours).
Default: 60 seconds Pattern Offset Offset in the packet, where the search starts.
Default: 0
Offset Relative To Administrators can specify from which part of the packet the offset is referring to. The size of the Offset Relative To parameter, must be greater or equal to the value of the Pattern Offset parameter plus the length (determined by the Pattern Mask parameter).
Values: IP header (Default); IP data, Layer 4 header or Layer 4 data. Ignore Source IP • Enabled (Default): When enabled, only the Session ID information is used for persistency. Sessions with the same Session ID are always forwarded to the same server. • Disabled: AppDirector also uses the Source IP when there is a Session ID match. Two sessions with the same Session ID but a different Source IP address can be forwarded to different servers.
AppDirector User Guide
Traffic Management and Application Acceleration
282 Document ID: RDWR-AD-V0231-UG1105
4.Click Set. Your configuration is set. Configuring Static Session ID Persistency
Static Session ID Persistency allows AppDirector to send traffic with specified Session IDs to specified servers. To configure Session ID tracking 1.From the AppDirector menu, select Layer 7 Server Persistency> Static Session ID Persistency. The Static Session ID Persistency Table window is displayed.
2.Click Create. The Static Session ID Persistency Create window is displayed.
3.Set the parameters:
Learning Direction Indicates which traffic is inspected by AppDirector to gather persistency information and to use that information for a specific session:
• Client Request (Default): Used when Session IDs appear only in requests from clients, so that AppDirector does not inspect replies from servers. This can be used, when persistency is based on a client IP that is displayed in the X-Forwarded-For HTTP header, or when only static values of Session IDs are used, as manually configured in the Static Session ID Persistency Table.
• No Learning: Persistency information is not gathered. Define this value when Static Session ID Persistency is used.
Persistency Method Defines whether the persistency parameter defined in this entry should be used to ensure persistency based on the regular Session ID table mechanism or via hashing.
Values:
• Use Table (default): Use this persistency parameter via the Dynamic Session ID table to ensure server persistency.
• Hash: Use this persistency parameter as input for the hash function to select a server. The farm Dispatch Method must be set to hashing.
Data Format Defines the type of data to look for according to the Session ID parameter.
Values: Binary, ipString
Parameter
Description
Farm Name Name of the server farm.
Session ID Value Session ID value identifying a specific server in a farm.
Server Name The server within the farm that is identified by the Session ID Value. Value Type • Text (default): Find the session ID value in the processed traffic using the text match mechanism.
• Pattern: Find the session ID value in the processed traffic using the pattern match mechanism.
Parameter
Description
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 283
4.Click Set. The Static Session ID Persistency Create window closes and a new entry is created.
HTTP Persistency
AppDirector can support HTTP persistency according to any parameter by using the Session ID mechanism. However the most popular persistency mechanism for HTTP is cookie persistency - server inserts cookie that identifies it in the reply to client, and the client uses the cookie in all its subsequent requests. AppDirector support several mechanisms for HTTP cookie persistency:
Cookie Learning
By learning the cookie from server initial reply, AppDirector can ensure that all subsequent requests from that client reach the same server. For this purpose a Text Match Session ID entry that looks for cookie key inserted by the server needs to be configured for the farm in question.
Cookie Insert
When servers do not insert cookies, AppDirector can insert a cookie that identifies the server used in the server reply, before forwarding the reply to the client. To insert a cookie, AppDirector uses its Layer 7 modification capabilities. When you set the Insert Cookie for HTTP Persistency to Enable for the farm in question, AppDirector automatically generates the required configuration - see Layer 7 Modification Rules Automatic Configuration, page 266
. This can also be manually defined.
Cookie Insert and Remove
Some application servers utilize cookies to associate server or application instances, and their default behavior involves searching their Database/Datastore for any application/instance associated with cookies. When unknown cookies appear, it attempts a lengthy search delaying the response. This can be solved by inserting the cookie on Reply, but removing it in subsequent Requests (on the way to server). When you set the Insert Cookie for HTTP Persistency to "Enable and remove on return path" for the farm in question, AppDirector automatically generates the required configuration - see Layer 7 Modification Rules Automatic Configuration. Cookie Rewrite
When all servers insert the same cookie value, AppDirector can replace the cookie value that arrives from the server with a value that enables identification of that server, (the Layer 7 modification capability called Replace). The required configuration includes:
• Set Cookie Layer 7 method that identifies the cookie inserted by server
• Set Cookie Layer 7 method that defines the cookie cookie value that should replace the server inserted value on the reply
• Replace Layer 7 modification rule
• Text Match Session ID entry that searches for cookie values inserted by server in subsequent requests
• Static Session ID entries that map the cookie value inserted for each server to that server. Note:For Cookie / Insert Rewrite, you need the Cookie Persistency License.
URL Hash When load balancing reverse proxies it is required to maintain persistency for the URL, and particularly include the object, so that objects are not duplicated between the reverse cache servers. In cases were huge numbers of objects exist persistency can be ensured by hashing mechanism.
AppDirector User Guide
Traffic Management and Application Acceleration
284 Document ID: RDWR-AD-V0231-UG1105
To achieve URL Hash Persistency
1.Set Dispatch Method to Hashing in the farm configuration, (see Farm Parameters, page 177
).
2.Configure URL persistency parameter as Text Match Session ID, with the Persistency Method set to Hash.
Note:This mechanism can be used to ensure persistency via hashing mechanism using any HTTP persistency parameter, not only URL.
SSL Persistency
SSL ID Tracking ensures that all TCP sessions of a SSL session are forwarded to the same server. When SSL ID Tracking is enabled, AppDirector uses Delayed Binding, and waits to receive the packet with the SSL ID before choosing a server. If the SSL ID is found in the internal Session IDs table, traffic is forwarded to the specified server, if not the SSL ID value is learned (added to the internal Session IDs table). The SSL ID Session ID entries are aged according to the aging of corresponding entries in the Client Table. The Client Table is used to maintain the session data.
SSL ID tracking can only be enabled on a farm whose Sessions Mode is set to Server Per Session. By default, SSL Tracking is disabled. For farms that use the Server Per Sessions mode where the SSL ID Tracking parameter is disabled, AppDirector automatically uses the Entry Per Sessions mode for the SSL traffic (port 443). Other traffic is shown in the Client Table using the Server Per Sessions mode. Notes:
>> SSL ID cannot be learnt for servers of type Local Triangulation.
>> SSL Session IDs are mirrored as they are kept in the Session ID table.
SIP Persistency
AppDirector also enables you to load balance and maintain client-server persistency for SIP servers. Persistency of SIP over UDP sessions is maintained by searching for Layer 7 information, like Call-
ID, within SIP headers. Administrators can use one or both of the following methods to maintain client - server persistency:
1.Using Hashing as a dispatch method: AppDirector searches either the Call-ID header or the Request-URL header in the SIP (Hash Parameter for SIP) and selects one available server based on a hashing algorithm performed on the specified parameter. By using Dispatch Method hashing on Request-URI, while simultaneously tracking Call-ID via dynamic leaning mechanism, AppDirector provides persistency for multi-party calls and conference calls.
2.Using Dynamic Session IDs: AppDirector maintains persistency based on any field within the SIP header (for example, branch tag). When using the Dynamic Session ID for persistency, it is recommended to use an inactivity timeout longer than the call's expected duration. To provide easy SIP persistency configuration when a Layer 4 policy is defined with Application set to SIP (Layer 4 protocol must be UDP), AppDirector automatically creates a Layer 7 Server Persistency Text Match entry looking for SIP Call-ID for all the farms connected to this Layer 4 policy. Radware recommends setting farms Sessions Mode to RemoveOnSessionEnd. AppDirector will age the Dynamic Session ID entry and the Client Table entry when a SIP BYE or CANCEL message is received for that Call-ID.
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 285
RADIUS Persistency
AppDirector supports server persistency for RADIUS traffic as well as using the RADIUS Attribute values learnt from RADIUS sessions to maintain persistency in other application sessions (for example, HTTP).
Remote Authentication Dial-In User Server (RADIUS) attributes are used to define specific authentication, authorization, and accounting (AAA) elements in a user profile, which is stored on the RADIUS daemon.
Administrators can use one of the following methods to maintain client server persistency for RADIUS using RADIUS Attribute number.
• Hashing - AppDirector selects an available server based on a hashing algorithm performed on the value of the specified RADIUS Attribute. You can configure hash persistency via the Text Match Session ID mechanism or for a simplified configuration • Dynamic Session ID learning mechanism (Text Match) - if no RADIUS Attribute persistency rule is configured, persistency will be kept using a RADIUS Identifier.
You can configure the RADIUS Attribute parameter at the farm configuration with the required RADIUS Attribute value. A Text Match Session ID persistency with Hash Persistency Method rule will be automatically generated.
RADIUS attributes are used to define specific authentication, authorization, and accounting (AAA) elements in a user profile, which is stored on the RADIUS daemon. You can configure the RADIUS Attribute parameter at the farm configuration with the required RADIUS Attribute value. The default is 0, indicating that AppDirector will not look for RADIUS attributes in order to maintain persistency.
In order to maintain persistency for RADIUS traffic (UDP ports 1812, 1813, 1645, 1646 or Layer 4 Policy Application parameter set to RADIUS), AppDirector searches the attribute within the RADIUS packets & learns its value for the following requests. The learnt values may be used in order to maintain persistency for other applications (for example, HTTP).
Persistency can be maintained on any Dispatch Method, but when using Hashing, (<blue>page 4-194), the behavior is different although persistency is still preserved:
• the hash function will be used in order to select a server.
• in case the hash function selects a server which is not available, another server will be selected and the selection will be recorded in the Layer 7 Server Persistency Table (the reason for this is the natural server selection has to be overridden) You should set the Session ID Table size as necessary.
Values range from 0 (default - no RADIUS attribute will be learnt) to 255.
The Sessions Mode must be Server Per Session. No additional configuration is required. The same mechanism is used for sessions originating from AppDirector managed servers to a remote RADIUS server that are NATed using Server NAT.
The RADIUS Attribute is used for any RADIUS message types (Authentication, Accounting, Authorization). If a server is not available, AppDirector selects another server and stores the RADIUS Attribute and selected server in the Layer 7 Server Persistency Table, to ensure persistency for the following sessions.
RADIUS Proxy Support
With RADIUS Proxy Support. When AppDirector manages RADIUS proxy servers that forward access/accounting requests from clients to another RADIUS server, it is required to ensure that the request and reply are sent via the same RADIUS server. AppDirector User Guide
Traffic Management and Application Acceleration
286 Document ID: RDWR-AD-V0231-UG1105
For this purpose you need a RADIUS proxy server that can add a special attribute that includes its IP address in decimal format to the request. When this is present, AppDirector extracts the first 4 bytes of its value, ensures that this is an IP address of an available server and forwards the reply to it.
Notes:
>> Configuring the RADIUS Proxy Support parameter overrides persistency according to the defined RADIUS Attribute in the farm.
>> To work with RADIUS, you must first enable UDP tracking.
This behavior can be defined per farm using the RADIUS Proxy Support parameter. When set to 0, the capability is disabled. To enable the capability, define the number of the RADIUS attribute that contains the persistency value. Layer 7 Server Persistency Statistics
To view the Statistics window From the AppDirector window, select Layer 7 Server Persistency > Statistics. The Dynamic SID Statistics window is displayed with the following read-only parameters:
Parameter
Description
Persistency Identifier matches Number of times a packet (both requests and responses) matched a Persistency Parameter configured in the Dynamic Session ID table.
Default: 0
Successfully parsed Dynamic SID values Number of times a Dynamic SID value found following the configured Persistency Identifier
Default: 0
Dynamic SID Value Learned from Server Number of times that Session ID value was learned from the Server’s request.
Default: 0
Dynamic SID Value Learned from Client Number of times that Session ID value was learned from the client's request.
Default: 0
Reset Dynamic SID Statistics Resets the Dynamic SID Statistics.
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 287
Client Table Management
This section discusses the Client Table, which stores data about sessions managed by AppDirector and also describes how to manage and present the Client Table. It includes the following topics: • Types of Client Table Entries, page 287
• Static Client Table, page 288
• View Filtered Clients, page 289
• Client Table Views, page 290
To maintain client-server persistency in an AppDirector farm, AppDirector uses the Client Table. This monitors which clients are connected to which servers for each Local Farm. When a client first approaches a farm, AppDirector checks whether there is an existing client entry in the Client Table:
• If the appropriate entry is found, the client is directed to the server that is displayed in the Client Table. In that case, there is no need to make a load balancing decision.
• If an entry does not exist, a farm is selected according to the service requested. A server is then selected according to load balancing considerations defined by the Dispatch Method or according to the Layer 7 Persistency information, where applicable. An entry is then added to the Client Table, indicating which server was selected. Once an entry is created in the Client Table, all subsequent packets that arrive from the client to a farm are forwarded to the server indicated in the Client Table entry. The traffic in the opposite direction, from the server to the client, is sent using the Virtual IP address with which the requested service is associated. This VIP address is used as the Source IP address of the outgoing traffic, which is also reflected in the Client Table entry. The Client Table also provides information about the way a client is sent to the server; for example, whether the selected server is a local server, whether the server is on a separate site, or if Port Multiplexing is used. Here is an example of a Client Table: Client Table Configuration Guidelines:
The configuration of the Client Table involves the following steps:
1.Set up the Sessions Modes 2.Set up the Client Table Global Parameters Now you can view the Client Table information using various view options.
Types of Client Table Entries
There are different types of entries in the Client Table. Each depends on the conditions in which the session occurs, such as: who initiated the session, the structure of the network, the needs of the specific clients, etc. Entries include:
• Static Client: clients that are always assigned to the same server within the farm.
• Dynamic Client: Dynamic clients are forwarded to a server that is available during the connection establishment process. AppDirector selects the best available server according to the load balancing definitions, as configured in the Dispatch Method or according to persistency.
Source Address
Source Port
Requested Address
Requested Port
Farm Name
Server Address
Server Port
100.1.1.1 1062 100.1.1.100 80 Farm A 10.1.1.2 8080
100.1.1.2 1011 100.1.1.100 80 Farm B 10.1.1.2 8080
100.1.1.3 1079 100.1.1.100 80 Farm C 10.1.1.1 8080
AppDirector User Guide
Traffic Management and Application Acceleration
288 Document ID: RDWR-AD-V0231-UG1105
• NAT: NAT entries in the Client Table are created for sessions initiated by the servers when Server Network Address Translation (NAT) is used. NAT is used in this case to translate the server’s IP address to the Virtual IP address that is used to access the farm. Note:When the server is disabled, the Client Table entries belonging to that server remain active to allow NAT for outgoing sessions originating from the server. Only when the server is removed are its sessions deleted from the Client Table.
• Client NAT: Client NAT entries are created for sessions in which Client NAT is used. Using the Client NAT capability, AppDirector hides the IP addresses of the clients from the servers. The original Source IP of a request is replaced by AppDirector with the configured NAT IP and port before forwarding the request to the server. The Client NAT feature is used when, for example, the client and the server are on the same subnet, so that the client IP address must be hidden. If not, servers may send replies directly to clients, instead of sending them through AppDirector. • Outbound NAT: Outbound NAT client entries are created for sessions in which the Outbound NAT capability is used. The Outbound NAT capability allows AppDirector to hide servers or other local hosts when sending traffic through AppDirector. Using the Outbound NAT capability, AppDirector replaces the original Source IP of a packet that is routed or bridged by AppDirector with the configured NAT IP before forwarding the request. It also replaces the Source port. Static Client Table
You may need to ensure that certain clients always access a specific server on the server farm, regardless of load balancing; for example, if you always need to access a specific server for management purposes by an administrator. Static clients are clients that are always assigned to the same server within the farm. Note:If a client is configured to statically use a specific server in a farm and server is down, AppDirector does not select a new. Also see Application/Farm Servers, page 188
.
To add static clients to the Client Table 1.From the AppDirector menu, select Clients > Static Client Table. The Static Client Table window is displayed.
2.Click Create. The Client Table Create window is displayed
3.Set the parameters.
4.Click Set. The client is added to the list as a static client. Parameter
Description
Client Address IP address of the client. (Address from which the request is sent).
Farm Name Name of farm providing the requested service.
Server Name Name of server currently serving this client.
Attach Time (Read Only)
Indicates when the client was attached. Measured in seconds since device re-initialization
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 289
View Filtered Clients
The Client Table stores information about every client request handled by AppDirector. The size of the table makes it difficult to view. To generate reliable and useful reports and to prevent system failures, use Client Table filters to present information from the table. To view filtered Clients
From the AppDirector menu, select Clients > Filtered Client Table. The Filtered Client Table window is displayed, displaying these read only parameters:
Parameter
Description
Client Address The IP source address of the client.
Client Port The source port of the client.
Default: 0
Requested Address VIP of the farm that contains the required server.
Requested Port Port of the requested TCP/UDP server.
Default: 0
Farm Name Name of the farm that provides the requested service.
Server Address IP address of server to which client is connected.
Server Port TCP/UDP Port of server currently serving this client
NAT Address Type NAT IP Address type of the client.
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, (gap between the Aging Time value (see Close Session At Aging, page 291
), 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 287
.
Client Mode This variable indicates how a single client's sessions are handled in the client table.
Values: Regular, Entry Per Session, Server Per Session, Remove on Session End, Remove Entry In Select Server.
AppDirector User Guide
Traffic Management and Application Acceleration
290 Document ID: RDWR-AD-V0231-UG1105
Client Table Views
Since the Client Table stores information about every client request handled by AppDirector, it is too large to view without filtering the data. Use Client Table filters to retrieve and view a subset of table entries. To generate reliable and useful reports and to prevent system failures, use Client Table filters to present information from the table. You can define up to five different filters, where the logical condition between the filters is an OR condition. The condition between the different parameters within a filter is an AND condition. Each of the filters can be active or inactive. By default, all filters are inactive and when all filters are inactive, an empty table is displayed.
The View Filters Create window allows you to set up to 5 different filters, where the logical condition between the filters is an OR condition. The condition between the different parameters within a filter is an AND condition. It is also possible to activate and deactivate each of the filters, by default the filters are inactive, which means that the whole Client Table is presented.
To configure the View Filters window 1.From the AppDirector menu, select Clients > View Filters. The View Filters window is displayed.
2.Select the relevant filter from the table or Select Create. The View Filters Create window is displayed.
3.Set the parameters.
Parameter
Description
Index Shows Filter Index number currently selected. Values: 1 - 5
Status Administrative status of the view entry Values: • Active: enables the view
• Inactive: disables the view
Source IP From/To Range of clients’ addresses.
Requested IP From/To Range of addresses of servers providing requested service.
Source Port From/To Similar to destination port, the source port that a packet should carry to match the filter can be configured.
Requested Port From/
To
Destination port number for that protocol. For example, for HTTP, the protocol can be configured as TCP and the destination port as 80. The port configuration can also allow for a range of ports to be configured.
Farm Name Name of the farm on the Remote AppDirector.
Server Address IP address of server where Remote AppDirector is located, and reports its load to distributing AppDirector.
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 291
4.Click Set. Your configuration is set.
Reset Client on Server Failure
When a server goes down, AppDirector redirects client requests to another available server. To provide quicker server failover, AppDirector can close the connection with the client as soon as the server is detected to be down. This will cause the client to immediately establish a new session to another server, ready to deliver data. This functionality can be activated per farm using the Reset Client on Server Failure feature. The Reset Client on Server Failure parameter is disabled by default.
When Reset Client on Server Failure is enabled and the farm server is detected as not in service, AppDirector evaluates the client entries associated with the server and closes all the open TCP connections and clears the Client Table entry from the Client Table.
Note:The Reset Client on Server Failure cannot be activated for farms with the Sessions Mode set to Regular.
Close Session At Aging
When the Client Aging on the device expires for a specific session, the device removes the Client Table entry for this session. AppDirector can also send a RESET to the server to close the associated port on the server, so the server can release the resources that were allocated for this session. This behavior is applicable for TCP sessions. This behavior is configurable with the Close Session at Aging farm parameter.
Client Table Sessions Modes
To achieve maximum flexibility, AppDirector allows the Client Table to work in several modes. These modes are configured per AppDirector farm, during the farm configuration process. The AppDirector farm configuration example shown here is used in the following explanation of the Sessions Modes. Client Type From the drop-down list, select the relevant Client Type:
• Any (Default)
• Client NAT
• Dynamic
• Server NAT
• Static
• Outbound NAT
Action Select from:
• No Action
• Delete All Matching (Selected Filters)
• Count All Matching (Selected Filters)
VLANTag VLAN Tag information is used to generate reports for each customer by using the customer's VLAN Tag value. A value of 0 in this field indicates that the VLAN Tag is not available.
Parameter
Description
AppDirector User Guide
Traffic Management and Application Acceleration
292 Document ID: RDWR-AD-V0231-UG1105
Figure 11: Typical AppDirector Application
Note:Definitions of Sessions Modes per farm can be overwritten using global parameters.
Entry Per Sessions Mode
When Entry Per Session is used as the Sessions mode, AppDirector maintains Layer 3 persistency. In the Entry Per Sessions mode, a new entry is added to the Client Table for each new session, allowing you to define one server to be part of multiple farms. In the Entry Per Sessions mode, clients can send requests directly to a server’s IP address and to a farm’s 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 server’s IP address to the client’s IP address. Note:When a client sends HTTPS requests, it will work in Entry Per Sessions mode regardless of the Sessions Mode selected by the user.
The Entry Per Sessions mode identifies an entry by the following parameters:
• Farm Name
• VIP Address
• Client IP Address
• Server IP Address
• Source Port Used from the Client to the Server
• Destination Port Used from the Client to the Server
If, the client approaches the AppDirector Virtual IP address through HTTP, then for this client AppDirector selects Server 1 with a 10.1.1.1 IP address. In this case, the Client Table entry looks as follows: 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.
Source IP Address
Source Port
Requested Address
Requested Port
Farm Name
Server IP Address
Source Port
100.1.1.1 1234 100.1.1.100 80 Farm 1 10.1.1.1 1234
AppDirector
Server 1
Server 2
Client
100.1.1.
VIP Address
100.1.1.100
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 293
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 entry’s age is reset only when AppDirector receives a new packet from the specific session, which is already reflected in the Client Table. Once a Client Table entry is established between the client and the server, all subsequent packets that match this entry are forwarded to the same server. Moreover, as long as there is an open session between the client IP and the VIP, all subsequent sessions from that client IP to that VIP and Destination Port are sent to the same server, even when different sessions (different Source ports) use different Client Table entries. Note:Once an entry is made from a client to a server within a farm, the client continues to approach the same server, regardless of application (provided the same farm is used).
Since a new table entry is made into the Client Table for every new session, the Client Table has many entries. You can increase the Client Table to accept more entries based on the amount of RAM available on the AppDirector unit (see Client Table Settings Tuning, page 73
).
Layer 3 Client Table
AppDirector finds entries in the Client Table by running the Hash function. The input for this function is the client’s IP address, where AppDirector performs calculations for finding the index number of the required entry. The Layer 3 Client Table is always used when Entry Per Session is used. AppDirector uses the Layer 3 Client Table to ensure Layer 3 persistency. This table contains information about the server selected for each client (Source IP address) in each farm, and 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 Mode
In Regular mode, AppDirector maintains Layer 3 persistency. In this mode, each entry is identified by the following parameters:
• Layer 4 Policy VIP Address
• Client IP Address
• Destination TCP/UDP Port Used from the Client to the Server
If, the client approaches the AppDirector Virtual IP address through HTTP, then for this client AppDirector selects Server 1 with 10.1.1.1 IP address. Here, the Client Table entry looks as follows: While active, this entry instructs AppDirector to perform the following tasks:
Source IP Address
Source Port
Requested Address
Requested Port
Farm Name
Server IP Address
100.1.1.1 – 100.1.1.100 80 Farm 1 10.1.1.1
AppDirector User Guide
Traffic Management and Application Acceleration
294 Document ID: RDWR-AD-V0231-UG1105
• Request for service: All packets from client 100.1.1.1 to farm associated with VIP 100.1.1.100 and with Destination port 80 are forwarded to server 10.1.1.1.
• Response: All packets from server 10.1.1.1 to client 100.1.1.1 with Source port 80 are sent from AppDirector using Source address 100.1.1.100. Global (Per Device) Sessions Mode
To configure AppDirector Global Parameters 1.From the AppDirector menu, select Global > Global Parameters. The Global Parameters window is displayed.
2.Set the parameters.
Note:Open New Entry When Source Port Different and Select New Server When Source Port Different can override the per farm configuration if set to Enable. You can also configure both under each farm. However, if you enable them in the global configuration it will override what has been configured in a farm.
3.Click Set. Your configuration is set.
Parameter
Description
Open New Entry When Source Port Different
• Enable: Each session that a client opens, is recorded in the Client Table separately.
• Disable (default): All client sessions are considered a single session, providing better performance.
Select New Server When Source Port Different
• Enable: Different sessions opened by a client's application are served by different servers, according to the load balancing algorithms. • Disable (default) Note: This provides more accurate minimum-user load balancing, but may hinder some applications dependent on the same server. It also may overload AppDirector`s internal tables. This option overrides the New Entry On Source Port option.
Parameter
Description
Load Report Interval Interval (in seconds) for sending dynamic updates of the local load to other AppDirector's devices that are served by this AppDirector. Also see Configuring Local Report Protocol, page 326
.
Load Report Timeout The time (in seconds) this device will wait to receive load reports from a remote device. After this timeout, the remote device is not considered to be responding.
According to the number of retries configured in the farm, the remote AppDirector becomes inactive, similar to the connectivity checks of regular servers.
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 295
Changing Sessions Modes Using Global Parameters
Using Global Parameters, you can set AppDirector farms to operate in Entry Per Sessions mode or Server Per Sessions mode. The equivalents of a farm’s Session modes in Global Parameters are:
• Entry Per Session - the Open New Entry When Source Port Different parameter. • Server Per Session - the Select New Server When Source Port Different parameter. The difference between individual farm and global configuration is that global configuration applies to all the farms on AppDirector, and can override the configuration of the individual farm.
By default, global parameters are disabled, meaning that all the farms are in the Entry Per Sessions mode, unless a different mode was defined during the farm configuration process. Enabling the Open New Entry When Source Port Different parameter automatically sets all AppDirector farms to Entry Per Sessions mode, except for the farms where Server Per Sessions mode is already defined. Enabling the Select New Server When Source Port Different parameter automatically sets all AppDirector farms to Server Per Sessions mode. Tip: Radware recommends disabling the Open New Entry When Source Port Different parameter and the Select New Server When Source Port Different parameter before setting Sessions modes for individual farms.
The table below shows the relationship between farm settings and global settings. The top row shows Farm Modes and the left column shows Global Parameters. The value within each table cell represents the effective AppDirector behavior when the global setting is the value on the left and the farm level setting is as above. Server Per Session
In the Server Per Sessions mode, multiple sessions from the same client are load balanced separately. This mode is recommended when an application represents a large number of users by a single IP address as a client to AppDirector; for example, if many clients trying to reach AppDirector are located behind a proxy server. The Server Per Sessions mode identifies an entry as follows:
• By VIP Address
• By Client IP Address
• By Source Port used from the Client to the Server
• By Destination Port used from the Client to the Server
In Figure 11 - Typical AppDirector Application, page 292
, the client opens six sessions to the AppDirector virtual address of 100.1.1.100 a Web page, with all sessions destined to port 80. As the table shows, both servers 10.1.1.1 and 10.1.1.2 are being used for client 100.1.1.1. Global Parameters
Farm Parameters
Regular
Entry Per Session
Server Per Session
Regular Regular Entry Per Session Server Per Session
Open New Entry When Source Port Different
Entry Per Session Entry Per Session Server Per Session
Select New Server When Source Port Different
Server Per Session Server Per Session Server Per Session
AppDirector User Guide
Traffic Management and Application Acceleration
296 Document ID: RDWR-AD-V0231-UG1105
Note:The Server Per Sessions mode is similar to the Entry Per Sessions mode, as new entries are added in the Client Table for new sessions. The difference is that the sessions from the same client can be forwarded to different servers. As in the Entry Per Sessions mode, the considerations of the Client Table size should be taken into account. UDP Session Tracking
When traffic is transmitted using the UDP protocol, each UDP request is represented by a single packet. Here, all packets from the same client IP have the same Source IP, Source port, Destination IP, and Destination port numbers. It is therefore impossible to create a new entry in the Client Table for each request. Using the UDP Session Tracking parameter, AppDirector load balances requests for service of that type. By default, the UDP Session Tracking parameter is enabled and AppDirector tracks all the TCP/UDP sessions using the Client Table. If you disable tracking, only TCP sessions are included in the Client Table. Persistency is not maintained and each packet of the session can be forwarded to a different server. When the UDP Session Tracking parameter is disabled, individual UDP packets are load balanced packet by packet. and client NAT cannot be used for UDP sessions, since UDP sessions are not inserted into the Client Table.
Note:If UDP Session Tracking is disabled, each UDP server can participate in only one farm.
Remove on Session End
The Remove on Session End mode allows AppDirector to remove entries from the Client Table before Aging Time expires. This mode is used to clear entries representing the TCP sessions closed before the end of the Aging Time. AppDirector keeps track of the number of users attached to each server using the Client Table. This information is important when using the “least amount of users” dispatch method. AppDirector enhances server statistics by decreasing the number of users once a FIN is detected.
The Remove on Session End mode operates like the Entry Per Sessions mode, except: • AppDirector marks the entry for deletion from the Client Table when it detects a RST or FIN packet between server and client, as the RST/FIN packets indicate that the session is closed. • The entry is aged in five seconds and subsequently removed. • For SIP/UDP traffic, AppDirector checks the SIP messages for the BYE or CANCEL command and applies the rapid Client Table entry aging mechanism when such a command is detected. The rapid aging period for SIP connections can be defined via the SIP Aging on Session End parameter. The default, according to SIP standard, is 32 seconds.
Source IP Address
Source Port
Requested Address
Requested Port
Farm Name
Server IP Address
100.1.1.1 1234 100.1.1.100 80 Farm 1 10.1.1.1
100.1.1.1 1235 100.1.1.100 80 Farm 1 10.1.1.2
100.1.1.1 1236 100.1.1.100 80 Farm 1 10.1.1.1
100.1.1.1 1237 100.1.1.100 80 Farm 1 10.1.1.2
100.1.1.1 1238 100.1.1.100 80 Farm 1 10.1.1.1
100.1.1.1 1239 100.1.1.100 80 Farm 1 10.1.1.2
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 297
Remove Entry in Select Server When used in conjunction with the Server Per Sessions mode, the Remove Entry in Select Server mode allows AppDirector to remove entries from the Client Table before Aging Time expires. This mode is used to clear entries representing TCP sessions that were closed before the end of the Aging Time. This mode operates like the Server Per Sessions mode except for the following: • AppDirector marks the entry for deletion from the Client Table when it detects a RST or FIN packet between server and client, as the RST/FIN packets indicate that the session is closed. • The entry is aged in five seconds and subsequently removed.
Network Address Translation (NAT)
This section discusses Network Address Translation (NAT) features and contains these topics:
• Client NAT, page 297
• Server NAT, page 302
• Outbound NAT, page 304
Network Address Translation (NAT) is the translation of an IP address used within one network to a different IP address known within another network. One network is usually the inside network and the other is the outside. NAT hides the Source IP address. AppDirector uses these NATs.
Client NAT
Using the Client NAT parameter, you can enable the Client NAT capability for the given farm server. Using Client NAT for a server means that AppDirector hides the Source IP addresses of clients that access the server in the farm. For more information on Client NAT capability,.
Note:Client NAT cannot be used for UDP sessions when UDP Session Tracking is disabled, as UDP sessions are not inserted into the Client Table.
Client NAT enables AppDirector to hide client IP addresses when forwarding traffic to servers in farms. During this process, AppDirector uses Dynamic NAT to replace the original Source IP of a request with a predefined NAT IP address and dynamically selected ports, before forwarding the request to the server.
Configuring Client NAT
The process of Client NAT configuration has several stages. Before configuring the Client NAT parameters, you need to:
• enable the Client NAT capability
• set the Client NAT Tuning parameters globally on AppDirector. Parameter
Description
Server NAT Server NAT allows AppDirector to hide the server’s IP address for outbound traffic in sessions initiated by servers. Server NAT uses StaticNAT, which means that only the IP address is changed without port translation. Server NAT is used for servers positioned behind AppDirector. Outbound NAT Hides IP addresses of hosts behind AppDirector and sends traffic through AppDirector. The IP address and the port are translated.
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
Traffic Management and Application Acceleration
298 Document ID: RDWR-AD-V0231-UG1105
Once the Client NAT feature is enabled on AppDirector, you can start configuring the Client NAT parameters. • First, you need to specify the ranges of the Source IP addresses in the incoming traffic that you want to NAT. This is done in the Client NAT Intercept Addresses table. This table defines clients whose source addresses are NATed.
• Next, you need to configure the IP addresses that AppDirector uses to translate the Source IP addresses of clients' requests. These are configured in the Client NAT Address table. This table defines the addresses that are used to perform NAT. The NAT addresses are also configured in ranges. The maximum number of configurable NAT addresses depends on the tuning value of the NAT Addresses table parameters, (see NAT Settings Tuning, page 73
). For each farm, you can select a single NAT address range and for each server in the farm, you need to enable the Client NAT capability and optionally, select NAT addresses.
AppDirector allows you to configure different NAT address ranges for different servers in the farm. When no NAT address range is configured for the server, AppDirector uses the NAT address range configured for the farm.
When a client with an IP address within one of the Client NAT Intercepted address ranges approaches a farm, a server is selected. If the Client NAT parameter is Enabled in the selected server’s 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.
Notes:
>> When no NAT addresses are configured, no Client NAT is performed. >> You can use the Client NAT capability only for Regular Servers, and not for Remote Servers, Distributed AppDirectors, Local Farm, or Loopback Servers. If Client NAT is required for a Remote Server, you need to configure this server as a Local Server in the farm, with Client NAT enabled. This ensures that traffic is forwarded to that server rather than redirected.
>> When Client NAT is used in a farm where the Sessions mode is set to Regular, AppDirector uses the Entry Per Sessions mode for the Client NAT sessions.
>> In a redundant AppDirector scenario, the same NAT Addresses and Client NAT intercept addresses must be configured on both AppDirector devices.
Client NAT Global Parameters
Client NAT conceals various network elements located behind AppDirector . When sending traffic through AppDirector with Client NAT, AppDirector replaces the original source IP of a packet that is routed or bridged by AppDirector with the configured NAT IP before forwarding the request, and replacing the source port.
Note:Client NAT is supported for TCP/UDP/ICMP traffic
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 299
To enable Client NAT 1.From the AppDirector menu, select NAT > Client NAT > Global Parameters. The Client NAT Global Parameters window is displayed,.
2.Set the Client NAT to Enable. Client NAT is now enabled.
3.Click Set. Your configuration is set.
Client NAT Addresses
The Client NAT Addresses option for the farm specifies the NAT Addresses that are used to hide IP addresses of clients accessing this farm. For each farm you can select a single NAT Addresses range. Notes:
>> When AppDirector uses Static NAT, you need to configure this in Additional Farm Parameters, page 181
where you must enter a NAT address range.
>> When no Client NAT Address Range is selected for a farm, AppDirector uses configured Client NAT Address Range when performing Client NAT for servers in this farm.
To create a NAT Address Range 1.From the AppDirector menu, select NAT > Client NAT > NAT Addresses. The Client NAT Address Table window is displayed.
2.Click Create. The NAT Addresses Ranges Create window is displayed.
3.Set the parameters.
4.Click Set. Your configuration is set.
Client NAT Intercept Addresses
The Client NAT Intercept Addresses window allows you to specify ranges of the source IP addresses in the incoming traffic that you want to NAT. This defines clients whose source addresses are NATed.
Note:To set the parameters of the Client NAT Intercept Addresses Table window, you must initially enable Client NAT.
Parameter
Description
Client NAT Enable/ Disable.
Client NAT hides client IP addresses approaching AppDirector farms, to solve routing issues. Both client IP and port are changed using Client NAT. Parameter
Description
From IP Address The first NAT address in the required range.
To IP Address The last NAT address in the required range.
AppDirector User Guide
Traffic Management and Application Acceleration
300 Document ID: RDWR-AD-V0231-UG1105
To set the parameters of the Client NAT Intercepted Addresses Table 1.From the AppDirector menu select NAT > Client NAT > Intercept Addresses. The Client NAT Intercept Table window is displayed.
2.Click Create. The Client NAT Intercept Table Create window is displayed.
3.Set the parameters.
4.Click Set. Your configuration is set.
Client NAT Quick Setup
The Client NAT Address Range defines a specific NAT range to use to hide client IP addresses when forwarding traffic to this server
As part of HTTP policy there is a link to the Client NAT Quick Setup. This lists all defined Client NAT ranges and Farms and enables you to set a client NAT range on multiple farms. It also includes the option to define a new Client NAT range and to set X-Forwarded-For header automatically on a farm with the client NAT. You can run the Wizard while selecting client NAT range 0.0.0.0 to reverse the setting on all farms to No Client NAT and/or No X-Forwarded for.
To configure Client NAT Address Range 1.From the AppDirector menu select NAT. The NAT Settings window is displayed.
2.Click the Client NAT Quick Setup button below. The Client NAT Quick Setup window is displayed.
3.Set the parameters.
Parameter
Description
From Client IP The first NAT address in the required range.
To Client IP The last NAT address in the required range.
Parameter
Description
Client NAT Range Select from list of defined Client NAT ranges.
Note:You can enter IPv4 or IPv6 addresses.
New Client NAT Range From IP Address Defines new client NAT range: from IP address.
To IP Address Defines new client NAT range: to IP address.
Select All Farms This changes all Farms check-boxes state to "selected".
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 301
4.List all farms defined in the system. Each farm should have an accompanying check-box marked to select it.
5.Click OK. Your configuration is set.
Notes:
>> Once you have set the paramaters and at least one NAT range was allocated, AppDirector will check that there is at least one Intercept range configured, if not, it will automatically configure a 0.0.0.0 to 255.255.255.255 range >> If you want to fine tune the ranges, you can do this through Client NAT Addresses, page 299
.
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: Enable X-Forwarded-
For Header on Selected Farms
Mark the checkbox.
Apply for all client source IP addresses
For all client source IP addresses, mark the checkbox.
Note: When no client NAT address range is selected for a farm, AppDirector uses any of the configured client NAT address ranges when performing Client NAT forservers in the farm.
Parameter
Description
Index The lowest available
Name Auto-G <Farm-Name>
Action Insert
Direction Client Requests
Layer 7 Method for Match (empty)
Layer 7 Method for Action Auto-G <Farm Name> X-Forwarded-For
Parameter
Description
Name Auto-G <Farm Name> X-Forwarded-For
Method Header Field
Header Field X-Forwarded-For
Token $Client_IP
Parameter
Description
AppDirector User Guide
Traffic Management and Application Acceleration
302 Document ID: RDWR-AD-V0231-UG1105
Server NAT
Server NAT allows AppDirector to hide the server’s IP address for outbound traffic in sessions initiated by servers. Server NAT uses StaticNAT, which means that only the IP address is changed without port translation. Server NAT is used for servers positioned behind AppDirector. When a session is initiated by a server, the server’s request for service is sent using its IP address as the source address. If the server’s IP address is a private IP address, the server’s address must be translated to a public IP address. This ensures proper routing of the reply back across the Internet to the NATing device and back to the server. To enable servers with private IP addresses to initiate sessions out of their private network, you can use the Server NAT feature (or the Outbound NAT feature). When enabled, the server’s IP is translated to the Layer 4 Policy’s 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:For Server NAT, the aging is taken from the farm to which the server belongs. If the server belongs to several farms, one is selected randomly (usually the first farm this server was attached to). You can configure remove On Session End for Server NAT (and also Outbound NAT).
Notes:
>> Server NAT sessions always use the Entry Per Sessions mode. >> When Server NAT is disabled, AppDirector forwards traffic with the server’s original source address. No address translation is done, and no entries are added to the Client Table.
>> When Server NAT is enabled, you can define the Use Specific NAT Address parameters for all server NAT sessions. When the default of the Use Specific NAT Address parameters is 0.0.0.0, AppDirector selects the address according to the VIP of the Layer 4 Policy that is associated with the farm in which the server is included. >> If no servers are defined, you can define an "empty" farm, associate this farm with a Layer 4 Policy, and use its VIP address as the specific NAT address.
>> If the traffic is received from a server with ‘Not In Service’ status, the traffic is handled according to the definitions of the When Server Is Not-In-Service parameters. >> When a server participates in multiple farms, outgoing server sessions are translated to the VIP address of the first found Layer 4 Policy associated with the farm in which this server is included.
>> Use of a specific server NAT address impacts the NAT address used for all servers.
This figure shows how the server’s Source IP is replaced with the Layer 4 Policy’s VIP.
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 303
Server NAT Global Parameters
This enables you to configure the Server NAT. Server NAT replaces original IP addresses of AppDirector servers with AppDirector farm VIP addresses for outgoing traffic. Only the IP addresses are translated, without a change of ports. When using Server NAT with the regular VLAN, you can disable Server NAT for traffic on the regular VLAN. This is configurable using the Server in Regular VLAN flag. When set to Bridge Only, AppDirector does not create Server NAT entries in the Client Table for traffic between VLAN ports, but bridges such traffic. The default is NAT and Bridge, which maintains the previous behavior where all traffic from servers uses Server NAT.
Note:Mirroring cannot be used in Server NAT.
To configure the Global Server NAT parameters 1.From the AppDirector menu, select NAT > Server NAT > Global Parameters. The Server NAT window is displayed.
2.Set the parameters
.
3.Click Set. Your configuration is set.
Parameter
Description
Server NAT Enable or Disable (Default) the Server NAT feature. Server NAT hides IP addresses of clients approaching AppDirector farms, to solve routing issues. Both client IP and port are changed during Client NAT.
Use Specific NAT IPv4 Address
You can choose a VIP to be used as a IPv4 NAT address for all servers in all the farms, when required.
Use Specific NAT IPv6 Address
A specific farm IPv6 address that will be used as a NAT IPv6 address for all of the servers in all the farms, when required.
Remove at Session End
Whether to delete session entry from the session table at the session end. Otherwise the entries will be deleted by the aging of the farm assigned to the used VIP.
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
Traffic Management and Application Acceleration
304 Document ID: RDWR-AD-V0231-UG1105
Server NAT Parameters
This allows you to configure how traffic received from a server with status Not In Service should be handled when Server NAT is Enabled. When using Server NAT in conjunction with the regular VLAN, you can disable Server NAT for traffic on the regular VLAN. This is configurable using the Server in Regular VLAN flag. When set to Bridge Only, AppDirector does not create Server NAT entries in the Client Table for traffic between VLAN ports, but bridges such traffic. To set the Server NAT parameters 1.From the AppDirector menu select NAT > Server NAT > NAT Parameters. The Server NAT Parameters window is displayed.
2.Set the parameters.
3.Click Set. Your configuration is set.
Server NAT VIP Selection per Server and dynamic NAT Advanced server NAT implementations, including defining a specific VIP as NAT address per server, or using a VIP as a NAT address but with both source IP and source port replacement (Dynamic NAT), can be performed using the Outbound NAT feature.
Outbound NAT
Outbound NAT enables AppDirector to hide various network elements located behind AppDirector. Using this feature, AppDirector implements Dynamic NAT, which replaces the original Source IP and source port of a packet that is routed or bridged with the configured NAT IP, before forwarding the request.
Note:Outbound NAT is supported for TCP/UDP/ICMP/SCTP traffic.
Using Outbound NAT, AppDirector can NAT not only traffic from IP addresses of servers managed by AppDirector, but also from any IP address behind AppDirector. The network elements whose addresses are NATed can be servers or other local hosts. You can set different NAT addresses for different ranges of Intercepted Addresses. Parameter
Description
When Server is Not-
In Service • NAT(default): Use Server NAT.
• Forward: Forward packets using routing, without Server NAT and without adding entries to Client Table.
• Discard: Drop packets received from a server in Not In Service status.
Server in Regular VLAN
Disables Server NAT for traffic on regular VLAN:
• NAT and Bridge (Default): Keeps the previous behavior, where all traffic from servers uses Server NAT.
• Bridge Only: AppDirector bridges traffic and does not perform NAT. No Server NAT entries are created in the Client Table for traffic between VLAN ports.
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 305
Outbound NAT applies only to traffic routed or bridged by AppDirector. Traffic destined for a Layer 4 Policy VIP address is not NATed using Outbound NAT, even if the element’s IP is displayed in the Outbound NAT Intercept Addresses table. For NAT traffic to Layer 4 Policy VIPs, use Client NAT, page 297
. Note:Outbound NAT entries in the Client Table always use the Entry Per Sessions mode. Figure 12: Outbound NAT Operation
The AppDirector Outbound NAT operation (as shown here) proceeds as follows:
1.A network element located behind AppDirector sends a request for service to an IP. The request is intercepted by AppDirector, which replaces the intercepted source address 10.1.1.11 and port 7777 with the Outbound NAT address 100.1.1.100 and port 8888.
2.AppDirector receives the reply packet, replaces the destination address 100.1.1.100 and port 8888 with the element’s original address 10.1.1.11 and port 7777, and returns it to the originating network element. Next Hop Routers
Each host or router that handles a packet examines the Destination Address in the IP header, computes the next hop that will bring the packet one step closer to its destination, and delivers the packet to the next hop, where the process is repeated. A Next Hop Router (NHR) is a network element and is used for outbound traffic in Multi Homing configurations. NAT addresses can be AppDirector
Network Outbound NAT Address
100.1.1.100
10.1.1.11 10.1.1.12
10.1.1.1
1 Request
2 Return
Destination Address 10.1.1.11
Source Address 10.1.1.11
Elements
Src Address 100.1.1.100
Dest. Address 100.1.1.100
Port 8888
Port 8888
Destination Port 7777
Source Port 7777
Internet
AppDirector User Guide
Traffic Management and Application Acceleration
306 Document ID: RDWR-AD-V0231-UG1105
associated with Next Hop Routers (NHRs), similar to the way VIPs are associated with NHRs. This provides a backup NHR for NAT Addresses, or for the simultaneous use of two NHRs with Hashing for the outbound traffic.
Setting Up Outbound NAT
This process has several stages. Before configuring Outbound NAT, you need to: 1.Set the Outbound NAT Tuning parameters (see NAT Settings Tuning, page 73
).
2.Globally enable the Outbound NAT feature on AppDirector.
3.Configure the Outbound NAT Intercept entry from the Outbound NAT Intercept Table.
Outbound NAT Global Parameters
When sending traffic through AppDirector with Outbound NAT, AppDirector replaces the original source IP of a packet that is routed or bridged by AppDirector with the configured NAT IP before forwarding the request, and replacing the source port.
Note:Outbound NAT is supported for TCP/UDP/ICMP/SCTP traffic.
To enable Outbound NAT 1.From the AppDirector menu, select NAT > Outbound NAT > Global Parameters. The Outbound NAT Global Parameters window is displayed
2.Set the parameters.
3.Set the Outbound NAT to Enable.
4.Click Set. Outbound NAT is now enabled.
Outbound NAT Addresses
Outbound NAT Addresses are the IP addresses that must be used to translate source IP of outbound traffic. To define which source IPs are to be translated and to what Outbound NAT address configure Outbound NAT Intercept Addresses.
To tune the Outbound NAT settings 1.From the Services menu select Tuning > Device. The Device Tuning window is displayed.
2.Set the Outbound NAT Addresses After Reset and Outbound NAT Intercept Ranges After Reset parameters to the required number of entries.
3.Click Set.
Parameter
Description
Outbound NAT Enable/ Disable(Default): Outbound NAT hides the IP addresses of clients approaching AppDirector farms, to solve routing issues. Both client IP and port are changed in the process of Client NAT.
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 307
To set the parameters of the Outbound NAT Address Table 1.From the AppDirector menu, select NAT > Outbound NAT > NAT Addresses. The Outbound NAT Address Table window is displayed.
2.Click Create. The Outbound NAT Address Table Create window is displayed.
3.Set the parameters
4.Click Set. Your configuration is set.
Outbound Intercept Addresses
You can associate Outbound NAT Intercept Addresses with Outbound NAT Addresses, to indicate which NAT addresses are to be used for different Intercept addresses. When no Outbound NAT Addresses are associated with an Outbound NAT Intercept Range, then AppDirector selects any of the configured Outbound NAT Addresses when NATing traffic from that range. Notes:
>> When an Outbound NAT Intercept Range includes servers managed by AppDirector, Outbound NAT is performed for traffic from the servers even if Server NAT is enabled.
>> By default, the intercept from and intercept to addresses are 0.0.0.0 - to make the outbound NAT work, the intercept range must be changed" To set the parameters of Outbound NAT Intercept Addresses 1.From the AppDirector menu select NAT > Outbound NAT > Intercept Addresses. The Outbound NAT Intercept Table window is displayed.
2.Click Create. The Outbound NAT Intercept Table Create window is displayed
Parameter
Description
From IP Address The first address in the NAT Addresses range. To IP Address The last address in the NAT Addresses range.
Note: The maximum number of IP addresses that can be defined in the Outbound NAT IP Addresses table must not be higher than the value of Outbound NAT Addresses Table specified in Tuning Table.
Redundancy Mode For redundancy operation: Active (Default): Farm is operating regularly on AppDirector. Backup: Farm is not operational, and it backs up another farm on another AppDirector device. When other AppDirector fails, this farm takes over and becomes operational.
Segment Name Segment providing the traffic that arrives from the configured segment.
NAT Mode Defines whether this NAT address range is used to perform regular dynamic NAT on outbound traffic (source IP and port translation) or static NAT using VIP (N to 1 source IP translation only) or static NAT for SCTP NAT for SCTP (N to N source IP translation only).
Values: Dynamic (default), SCTP NAT, Static
AppDirector User Guide
Traffic Management and Application Acceleration
308 Document ID: RDWR-AD-V0231-UG1105
3.Set the parameters.
4.Click Set. Your configuration is set.
Outbound NAT using VIP
This feature enables you to use a VIP address as a NAT address in outbound NAT.
Notes:You need to configure the outbound parameters as follows:
>> 2.2.2.1-2.2.2.10 is the range of the servers needs to use NAT.
>> 2.10.10.10 is a VIP on the device.
>> When a server from this range sends outbound traffic, NAT will be used, regardless of the port\protocol of the server.
>> You cannot configure more than one VIP for the same range of servers.
>> Since we use high ports, you must configure more than 15,000 ports for the tuning of outbound NAT.
Server NAT VIP Selection per Server for Outbound Traffic
Using the Outbound NAT configuration we want to support static and dynamic NAT using VIP and non-VIP addresses per intercept range.
To perform this, you need the following:
1.Add NAT type to your Outbound NAT Intercept configuration. The values are Dynamic (default) and Static.
2.When the Outbound NAT address is VIP
a.NAT is not performed for intercept addresses that are not servers managed by AppDirector.
b.When NAT type is Static - perform static NAT (server NAT). In this case the Server NAT global settings (for VIP not in service and VLAN) are relevant.
3.When Outbound NAT address is not VIP
a.When NAT type is Dynamic - perform regular Outbound NAT
b.When NAT type is Static - perform static NAT like was implemented for SCTP, but for TCP and UDP. In this case the Intercept Range and NAT range must be equal.
Parameter
Description
Intercept From IP First address in the Outbound NAT Intercept addresses range.
To IP Last address in the Outbound NAT Intercept addresses range.
Aging Time Period of idle time after which the Client Table entries associated with this range are removed. Aging Time for Outbound NAT entries is determined according to the aging time set by the user in the Outbound NAT Intercept table.
Default: 60 seconds.
Outbound NAT Addresses
Associates a specific NAT address with selected intercepted range of addresses. Default: 0.0.0.0.
Remove Entry at Session End
Whether to delete session entry from the session table at the session end. If not - the entries will be deleted by aging.
Values: Disabled (default)/Enabled
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 309
4.First configure an Outbound NAT address that represents "regular" Server NAT behavior (the first VIP configured attached to the transmitting server is used) - for example 255.255.255.255 or 0.0.0.0. 5.Upon upgrading, translate the configuration as follows:
a.If your Server NAT is enabled and the specific VIP is 0.0.0.0 then for all servers you need to configure the special IP as an Outbound NAT
b.If your Server NAT is enabled and a specific VIP is configured then for all the servers that you need to configure, set this IP as an Outbound NAT.
Configurations for a Server NAT VIP Solution
1.Non-VIP Dynamic NAT - like traditional Outbound NAT, the NAT Type field is set to Dynamic (default).
Note:In AppDirector 2.x versions, the NAT Type parameter will be in the Outbound NAT range and not in the intercepted range.
2.Non-VIP Static NAT appdirector nat outbound address-range
From IP Address 192.10.10.1
To IP Address (-t ) 192.10.10.2
appdirector nat outbound range-to-nat
Intercept From IP 2.2.2.1
To IP (-t ) 2.2.2.254
Outbound NAT Addresses (-nf) 192.10.10.1
NAT Type (-nt) Dynamic
appdirector nat outbound address-range
From IP Address 192.10.10.1
To IP Address (-t ) 192.10.10.10
appdirector nat outbound range-to-nat
Intercept From IP 2.2.2.1
To IP (-t ) 2.2.2.10
Outbound NAT Addresses (-nf) 192.10.10.1
NAT Type (-nt) Static or Dynamic
AppDirector User Guide
Traffic Management and Application Acceleration
310 Document ID: RDWR-AD-V0231-UG1105
Notes:
>> The intercept range and NAT address range must be equal in size - otherwise error: "The NAT addresses range must be equal in size to the intercepted addresses range" will be displayed.
>> In AppDirector 2.x versions, the NAT Type parameter will be in the Outbound NAT range and not in the intercepted range.
3.VIP Dynamic NAT.
Notes:
>> If the NAT address range includes VIP, the range size must be 1.
>> In AppDirector 2.x versions, the NAT Type parameter will be in the Outbound NAT range and not in the intercepted range.
4.VIP Static NAT Notes:
>> In AppDirector 2.x versions, the NAT Type parameter will be in the Outbound NAT range and not in the intercepted range.
>> Traffic from server X will always be NATted using the same VIP (configured in the Outbound Intercept NAT entry that includes server X in the intercept range), regardless of the protocol/port used.
>> You cannot configure more than one VIP to the same range of servers.
The Outbound NAT Ports per Address tuning parameter must be set to at least 15,000 because this requires that NAT ports over 10,000 will be used to minimize the possibility of conflict with inbound sessions. The availability of each port will be checked before it is used for Outbound NAT.
appdirector nat outbound address-range
From IP Address 192.10.10.1
To IP Address (-t ) 192.10.10.1
appdirector nat outbound range-to-nat
Intercept From IP 2.2.2.1
To IP (-t ) 2.2.2.10
Outbound NAT Addresses (-nf) 192.10.10.1
NAT Type (-nt) Static
AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 311
Configuring AppDirector Advanced Global Parameters
The AppDirector Global Parameters window allows you to configure advanced system level settings.
To configure global information 1.From the AppDirector menu, select Global > Global Parameters. The Global Parameters window is displayed.
2.Set the parameters.
3.Click Set. Your configuration is set.
Parameter
Description
Open New Entry When Source Port Different When enabled, different sessions from the same client to the same destination are counted separately, but all use the same firewall
Enabling this option can produce finer load balancing and ensure that all sessions from the same client to the same server use the same firewall. When disabled, all the sessions of one application are considered a single session, to enable better performance.
Select New Server When Source Port Different When enabled, different sessions opened by a client's application are served by different servers, according to the load balancing algorithms
This option provides a more accurate minimum-user load balancing, but may hinder some applications that depend on being served by the same server. It also may overload the device's internal tables. This option overrides the New Entry On Source Port option.
Values: Enable/disable Load Report Interval Interval (in seconds) for sending dynamic updates of local load to other AppDirectors served by this AppDirector.
Load Report Timeout The time (in seconds) this device will wait to receive load reports from a remote device. After this timeout, the remote device is not considered to be responding.
According to the number of retries configured in the farm, the remote AppDirector becomes inactive, similar to the connectivity checks of regular servers.
AppDirector User Guide
Traffic Management and Application Acceleration
312 Document ID: RDWR-AD-V0231-UG1105
Tweaks
The AppDirector Global Parameters Tweaks window allows you to further refine your advanced system level settings including the enabling and disabling of the Acceleration Engine.
To refine global information 1.From the AppDirector menu, select Global > Tweaks. The Tweaks window is displayed.
2.Set the parameters.
Parameter
Description
IPv4 Client Grouping Suffix Length
The IPv4 mask suffix length that defines a group of IPv4 clients for which the same farm server should be selected.
IPv6 Client Grouping Suffix Length
The IPv6 mask suffix length that defines a group of IPv6 clients for which the same farm server should be selected.
UDP Sessions Tracking Whether UDP sessions are recorded in the Client Table. Values: Enable (default)/ Disable. One Trap Determines how traps are issued when a server fails. Values: Enable (default)/ Disable. User Configured Timeout After TCP Failure If this option is enabled, AppDirector will wait the amount of time specified in the connectivity interval of the farm before rechecking the server after a TCP connectivity check is not responded to. When enabled, the default period is 3.5 seconds.
Default: Disable
No Slash After GET in Extended HTTP Check
In the extended HTTP check, AppDirector issues the request to the server in the format GET /<home page>. Enabling this option omits the slash.
Default: Disable.
Extended Check Host Mode By default, AppDirector uses the server's IP address in the HTTP request of the extended HTTP check. This allows the use of the farm name instead. Default: Server IP.
Extended LRP Security When the Triangulation redirection method is used (see Global Triangulation Redirection, page 346
), the Triangulation VIP address must be on the same subnet as the Virtual IP address, for security reasons. To ensure that the Triangulation VIP address configured for a farm is on the same subnet as that farm, the Extended LRP Security option must be enabled.
Session ID Sharing Enables or disables sharing of the Session ID information among multiple farms using the same Session ID. When a specific Session ID value is learned through one farm, the same Session ID value can be used also for server selection in other farms.
Default: Disable
Note: When a Session ID value is learned through a client's session with one farm (farm1) and then is seen in a client request for another farm (farm2), AppDirector checks that the server indicated by the Session ID value (a server in farm1) is also in farm2. If not, then AppDirector uses load balancing to select a server in farm2. AppDirector User Guide
Traffic Management and Application Acceleration
Document ID: RDWR-AD-V0231-UG1105 313
3.Click Set. Your configuration is set.
Note:Status changes including enabling/disabling the acceleration engine are not exported to the configuration file when the device configuration is saved. When copying configurations between AppDirector devices, ensure that their statuses are aligned before importing a configuration.
DSID reply Learning in 'First' mode
When using a DSID policy, this option will cause the device to inspect each reply of each transaction, on the same session, even if Layer 7 Persistent Switching Mode is set to FIRST. AppDirector inspects the first request in each TCP connection, selects a server, and forwards the request. During the rest of the TCP connection, AppDirector forwards all further requests to that server.
If you need to learn from each response, you should configure one of the 'complete' Persistent Layer 7 Switching modes (Overwrite or Maintain).
• Inspect first reply – disabled (default)
• Inspect all server replies – provides backwards compatibility with previous AppDirector versions.
Note: DSID is HTTP dependent and cannot be used with Generic-
SSL offloading selected in the Layer 4 Policy Application, therefore Inspect First (disabled) is used. See Layer 4 Policies, page 200
.
SIP Aging on Session End
Defines the length of time, in seconds, for which the SIP connection data is still present in the device (Client Table) after a BYE or CANCEL command was received. Default (according to SIP standard): 32 seconds.
Acceleration Engine (requires reboot)
Controls the Application Acceleration Engine. Values:
• Enable (default) • Disable
Outbound Inquiries Time-Out
Aging time for TCP outbound inquiries in seconds.
AppDirector User Guide
Traffic Management and Application Acceleration
314 Document ID: RDWR-AD-V0231-UG1105
AppDirector User Guide
Configuring Global Load Balancing
Document ID: RDWR-AD-V0231-UG1105 315
Chapter 4 – Configuring Global Load Balancing This chapter describes the methods used in the global application switching schemes for global traffic management. This chapter includes the following sections:
• Global Traffic Management
, page 315
• Proximity
, page 319
• Configuring Local Report Protocol
, page 326
• Redirection
, page 341
Global Traffic Management
This section introduces global traffic management methods and devices and includes these topics: • IP Traffic Management
, page 315
• Global Solution Configuration Guidelines
, page 318
IP Traffic Management
The global IP traffic management solution is intended for companies with server sites in multiple locations. Distribution of server sites at different locations ensures high availability while maintaining multiple level redundancy. If there is damage to a single server, farm, or site, business continuity is maintained since switching from one server site to another is transparent to the users. Globalization of business requires global server sites that ensure availability and efficiency over great geographical distances. Organizations can increase productivity through resource sharing among different branches placed in various locations. For example, in a company, that has multiple data centers located all over the world, each data center may act as an independent business unit. Global traffic management leads to better administration and provides all employees, business partners and customers with critical resources, 24/7 availability, and optimal content delivery.
This figure illustrates an example of a global load balancing scheme.
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. LondonNew York AppDirector User Guide
Configuring Global Load Balancing
316 Document ID: RDWR-AD-V0231-UG1105
Transactional Flow
Before considering a global solution it is essential to understand the flow of transactions over the web and the challenges posed when multiple sites are used. • DNS resolution. To access Internet services the first basic step regardless of the application is host name resolution; finding the IP address for the service name, using the DNS (Domain Name System) protocol. • Application Transaction. Once the client receives the IP address of the target host name the application transaction starts. A common client transaction involves multiple steps and often multiple TCP connections. During the transaction a client may perform name resolution a few times, work behind proxies or experience disconnections and resets. Therefore, the IP address of the client may not be consistent.
AppDirector Global solution follows the transaction flow to provide availability and continuity throughout the entire transaction life:
• DNS Redirection - AppDirector functions as authoritative domain name server for the services it load balances. When an AppDirector device receives a DNS A record query it selects the best site for the service and answers with that site VIP.
• Application Redirection - is required in the following cases:
— During the transaction life, the site selected by the DNS redirection mechanism becomes unavailable or overloaded.
— During an HTTP transaction life, a new TCP connection arrives at a different site than the one where the transaction started.
— Protocols that do not use DNS as a first step.
AppDirector supports specific protocol redirection mechanisms (HTTP/S, RTSP and SIP) and generic mechanisms (Proxy and Radware patented Global Triangulation).
Site Selection
AppDirector selects the best site based on availability, load and network proximity.
• Load & Availability. Any AppDirector with site selection privileges must know the condition of every other site to make the appropriate decisions, based on the real-time dynamic load. This is achieved via Radware proprietary protocol called LRP (Load Report Protocol).
• Proximity. Network proximity indicates the network distance or time distance between a user and a data resource. For example, if a user is geographically closer to the New York site than to the Chicago site, yet can access the Chicago site faster when the network path to the New York site is overloaded. To measure network proximity AppDirector devices perform proximity checks to the client subnet. In addition any AppDirector with site selection privileges must know the network proximity of the client to every other site to make the appropriate decisions. This is achieved via Radware proprietary protocol called PRP (Proximity Report Protocol).
Caution:All devices in a Global configuration must run the same software version to ensure that LRP and PRP algorithms can run between the sites.
Load Balancing Scheme
AppDirector-Global balances traffic between multiple distributed sites according to the load present at each site. However the AppDirector Global device selects itself as the best site as long as the load on its local servers is lower than the Distribution Threshold configured for the specific farm and local servers are available. An AppDirector Global device starts distributing immediately in the following cases:
• All local servers are inactive, either operationally or administratively (disabled or in backup mode).
• The Distribution Threshold is set to 0.
AppDirector User Guide
Configuring Global Load Balancing
Document ID: RDWR-AD-V0231-UG1105 317
The maximum number of users that an AppDirector device can receive from other AppDirectors is determined by the configured Farm Capacity Threshold. Once reached, the AppDirector device uses LRP to inform all other AppDirectors sending traffic to this farm that it can no longer handle directed traffic. You can define the Distribution Threshold parameters and the Capacity Threshold parameters per farm within AppDirector-Global. These parameters are measured in number of Client Table entries for this farm. You can also define the Capacity Threshold for the farms of AppDirector devices.
Radware Devices Used in Global Solution
To implement the global traffic management solution, you need to work with an AppDirector-Global device - an AppDirector device where a Global Traffic Management license is installed. An AppDirector Global device supports both local traffic management and global traffic management - best site selection. A distributed site can be a remote server or another AppDirector site. The table below describes the differences between AppDirector and AppDirector global solutions for functionality.
Table 3: AppDirector: Regular versus Global Functionality
Functionality
AppDirector
AppDirector Global
Server types supported Regular
Local Triangulation
Local Farm
Regular
Local Triangulation
Local Farm
Remote Server
AppDirector
LRP Send Send and Receive
PRP Answer PRP queries Answer and Initiate PRP queries
Redirects traffic to other locations No Yes
Redirection Type Supported DNS, HTTP & RTSP for Local Redirection
DNS, HTTP & RTSP & Global Triangulation.
DNS Server Functionality (DNS Resolution)
Yes Yes
VIP Anycast advertisement Yes Yes
BWM and IPS and DoS functionality
With proper license With proper license
Cookie Persistency
(Requires Special License)
Yes* Yes*
AppDirector User Guide
Configuring Global Load Balancing
318 Document ID: RDWR-AD-V0231-UG1105
Global Solution Configuration Guidelines
To achieve a globally distributed solution, the following steps should be performed:
On a device without site selection privileges (AppDirector or AppDirector Global):
• Configure provided services as for local load balancing (farms including local servers, Layer 4 policies, host names, etc.)
• Configure an LRP entry for each combination of a farm that is part of a distributed service and a site with distribution privileges.
• Configure the proximity checks that you want the device to perform. On a device with site selection privileges (must be AppDirector Global) you need to:
• Define a farm for each distributed service. Each farm includes local servers plus Distributed AppDirector servers for all distributed sites (the server address is the VIP address of the service on the distributed AppDirector or a public NAT address of that VIP) and/or remote servers.
Note:If a distributed site is connected via multiple WAN links (multi-homing), it is displayed in the distributing site farm as multiple servers - one for each WAN link (each server address is the public NAT address for the distributed site VIP via a different WAN link).
• For each farm the redirection methods must be configured.
• Configure the rest of the service configuration as for local load balancing (Layer 4 policies, host names, etc.)
• Configure proximity, including static proximity if required.
• Configure DNS persistency, if required.
When the solution includes multiple sites with distribution privileges, LRP entries must be configured to report local load to the other distributing sites.
Caution:All devices in a Global configuration must run the same software version to ensure that LRP and PRP algorithms can run between the sites.
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: RDWR-AD-V0231-UG1105 319
Proximity
This section provides information about the methods AppDirector uses to measure proximity to redirect traffic and includes the following topics: • Proximity Parameters
, page 319
• Proximity DNS Address
, page 320
• Proximity Checks
, page 321
• Proximity Report Protocol (PRP)
, page 322
• Static Proximity Database
, page 323
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 Proximity Parameters
Before you configure proximity checks, you need to set up the Proximity Parameters. To configure Proximity Parameters 1.From the AppDirector menu, select Proximity > Parameters > General. The Proximity Parameters window is displayed.
2.Set the parameters.
Parameter
Description
Proximity Mode You can determine the proximity mode as either:
• No Proximity (default): No proximity is operated.
• Static Proximity: AppDirector will only use redirections according to static proximity table. Dynamic auto learning mechanism is off.
• Full Proximity: AppDirector will redirect according to the static redirections, and will use auto learning for subnets which are not defined as static entries.
Proximity Aging Period
Period of time, in minutes, in which a dynamic entry is kept in the database. When this time is about to expire and a new request is received from a client IP within this range, AppDirector -Global refreshes the information of that entry by re-executing the proximity checks.
Values: 0 - 10080 minutes (a week)
Default: 2880 minutes (2 days).
Hops Weight Emphasis to put on the number of hops between client and farms when determining proximity. The number of hops affects the load balancing decision based on proximity considerations.
Values: 1 (default) - 100
AppDirector User Guide
Configuring Global Load Balancing
320 Document ID: RDWR-AD-V0231-UG1105
3.Click Set. The proximity parameters are recorded.
Proximity DNS Address
You must define local DNS servers (DNS servers located near the AppDirector) to avoid unnecessary proximity calculations for traffic coming from these servers. DNS requests received from these DNS servers are resolved using load and availability considerations only. Up to two servers can be configured.
To configure Proximity Parameters 1.From the AppDirector menu, select Proximity > Parameters > Local DNS Servers. The Proximity DNS Address window is displayed.
2.Set the parameters.
3.Click Set. The proximity parameters are recorded.
Latency Weight Emphasis to put on the time between client and farms when determining proximity. The number effects the load balancing decision based on proximity considerations.
Values: 1 (default) - 100
Load Weight Emphasis to put on the load of remote server farm between client and farms when determining proximity. The number effects the load balancing decision based on proximity considerations.
Values: 1 (default) - 100 Proximity Table Cleanup
Frequency of the Proximity Table cleanup.
Default: 0
Proximity IPv6 Client Grouping Prefix Length
Sets the prefix length for grouping of ipv6 clients in the dynamic proximity table. One dynamic proximity entry will be maintained for all clients within the same subnet as defined by this prefix.
Parameter
Description
DNS Server Address IP address of the local primary DNS server. AppDirector avoids unnecessary proximity calculations in case the DNS server is located near AppDirector. DNS requests that are received from this DNS server are replied using load considerations only.
Parameter
Description
AppDirector User Guide
Configuring Global Load Balancing
Document ID: RDWR-AD-V0231-UG1105 321
Proximity Checks
AppDirector has a sophisticated mechanism to detect network proximity using a dynamic database of clients and their proximate sites. This is constantly updated by an auto-learning mechanism.
To get accurate network proximity results, the checking method should be configured to cross all obstacles en route to the client. AppDirector uses several methods to detect the number of hops and the latency from the client to each of the sites. These methods ensure that the proximity check will go through any router and firewall with maximum accuracy.
When a client approaches AppDirector, a proximity check is performed by each site and the results are communicated using the Proximity Report Protocol (PRP). Now AppDirector can redirect the client to the closest site. When another client from the same network approaches AppDirector, later, the nearest site is now known, and the client is immediately redirected there.
To configure Proximity checks 1.From the AppDirector menu, select Proximity > Parameters > Proximity Checks. The Proximity Checks window is displayed.
2.Set the parameters.
3.Click Set. The proximity checks are recorded.
Parameter
Description
Proximity Checks Sets whether the AppDirector device is allowed to perform proximity checks for AppDirector-Global. The proximity probes themselves are a combination of IP,TCP and application layer probes (Including TCP ACKs and ICMP Echo requests) to ensure accurate measurements.
You can determine one of the following options:
Enabled (Default): AppDirector/AppDirector-Global can serve as a Distributed server for other AppDirector-Global devices and can perform proximity checks for them. These AppDirector devices appear in the Distributed Sites definitions.
Disabled: No proximity checks are done for other AppDirector devices.
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: 2
Check Interval An interval in seconds during which AppDirector -Global sends a PRP request packet to another AppDirector. If no answer is received within this period, AppDirector-Global resends the PRP request packet. Default: 5
Application UDP Traceroute Check
Using the traceroute tool for the proximity check in the example above, AppDirector can measure latency and the number of hops to the last router. The traceroute proximity check is implemented using the UDP protocol to port 37853.
Default: Enabled.
Failure Notification Enables or disables the application aware proximity check (TCP).
AppDirector User Guide
Configuring Global Load Balancing
322 Document ID: RDWR-AD-V0231-UG1105
Proximity Report Protocol (PRP)
AppDirector-Global can redirect traffic to distributed locations over the Internet, if the distributed site provides better service to the client (in terms of availability, load and proximity). These distributed sites can have a standalone server or a server farm managed by another AppDirector. Information on the proximity of these distributed sites to the client enables AppDirector-Global to make such decisions. When a distributed site is equipped with an AppDirector that manages a server farm, a proprietary inter-AppDirector protocol, called PRP (Proximity Reporting Protocol), is used by AppDirector-Global to query other remote AppDirectors about their proximity to a client (can be client or DNS server). PRP is a simple UDP-based protocol that uses port UDP port 2091.
To select the closest site for a specific client, AppDirector-Global finds out how “far” this client is from all the AppDirectors in the system. To do this, AppDirector-Global calculates the number of router hops and latency between itself and the client. Then, AppDirector-Global requests all other AppDirectors to do the same and receives a report from each indicating router hops and latency between each of them and the client. To “ask” other AppDirectors about the proximity information, AppDirector-Global uses the Proximity Report Protocol (PRP), which is a UDP-based protocol. When AppDirector-Global needs to gather proximity information about a client, it sends PRP requests to all AppDirectors in the system. Each AppDirector then calculates router hops and latency between itself and the client and reports back to AppDirector-Global, using a PRP response packet. PRP uses UDP port 2091. Notes:
>> AppDirector can also send PRP reports. Only AppDirector-Global can send PRP requests for proximity information. In addition, AppDirector-Global receives and uses the PRP responses to distribute traffic globally according to proximity considerations.
>> An AppDirector which receives the request from the client and is initiating the PRP queries must always be an AppDirector-Global. >> An AppDirector device that receives PRP queries and responds can be either AppDirector or AppDirector-Global and proximity checks must be configured
.
When a client request arrives from a class C network for which there is no proximity data, AppDirector gathers proximity information for the class C network of the client. To gather this data the Initiator AppDirector performs the following:
• Sends proximity checks to this new class C network.
• Sends PRP queries to all distributed servers (Distributed AppDirector type servers) in the farm servicing this client request, asking them to perform proximity checks to this class C network.
• An AppDirector that initiates PRP queries saves both its own proximity results and those received from AppDirectors receiving PRP queries in its Dynamic Proximity table for future requests from this class C network.
PRP in a Multi-Homed Environment
When an AppDirector is installed behind a NAT device that load balances inbound and outbound traffic between multiple WAN links it is operating in a multi-homed environment. Here, an AppDirector service (VIP) is accessible via a number of public IP addresses - one for each WAN link load balanced by the multi-homing device. AppDirector User Guide
Configuring Global Load Balancing
Document ID: RDWR-AD-V0231-UG1105 323
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 a client in a Global solution, either in the DNS stage or later (HTTP, RTSP, etc.).
Each server can be:
• An IP of a Distributed AppDirector type server in the relevant farm • An IP of a Remote Server type server in the relevant farm
• A VIP of a Layer 4 policy associated with the relevant farm Notes:
>> You need to enter the VIP 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 and 5000. >> After setting the new values, the device must be rebooted.
>> You can configure for a known range of clients, the three nearest sites that will provide the service. Only if all the configured sites are down or overloaded will the next most convenient site be selected to provide the service.
You use the Static Proximity Table window to configure this feature. This window manages the ranges of static proximity redirections. You can configure ranges of IP addresses of clients for each farm address with a list of the three preferred sites for this range. If the range should be handled in the local site, the local site farm name should be entered. For the predefined range, you can list up to three IP addresses in order of priority. The priority defines which IP should server the client request. This is used when redirecting client in a Global solution, either in the DNS stage or later (HTTP, RTSP, etc.). The Static Proximity window allows you to insert a new static client.
To define the static proximity parameters 1.From the AppDirector menu, select Proximity > Static Proximity. The Static Proximity window is displayed.
2.Click Create/Update. The Static Proximity Create/Update window is displayed.
3.Set the parameters.
Parameter
Description
Farm Name Name of the farm to which the entry is applied.
Default: None
From Address IP address of the first client IP in the range.
To Address IP address of the last client IP in the range.
AppDirector User Guide
Configuring Global Load Balancing
324 Document ID: RDWR-AD-V0231-UG1105
4.Click Set. The client is added to the list.
Default Redirection
Default Redirection is applicable only for remote or distributed servers. When proximity is used and a client for whom no proximity settings are defined approaches AppDirector, a server is selected for that client based on load considerations only. When no proximity information is available for a client, Default Redirection enables you to define which servers to use and in which order of priority. The table below presents the parameters you need to set for each farm in which you want to employ Default Redirection
.
To configure Default Redirection 1.From the AppDirector menu, select Distributed System > Default Redirection. The Default Redirection window is displayed.
2.Click Create. The Default Redirection Create window is displayed.
3.Set the parameters.
Server 1 • 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 Layer 4 policy which is associated with the relevant farm • Local Service: The first priority server that this range of clients will be redirected to.
Server 2 • 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 Layer 4 policy which is associated with the relevant farm • Local Service: The second priority server that this range of clients will be redirected to.
Server 3 • 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 Layer 4 policy which is associated with the relevant farm • Local Service: The third priority server that this range of clients will be redirected to.
Parameter
Description
Farm Name Name of farm to use Default Redirection.
Priority Order in which servers are used, where 0 indicates the highest priority.
Default: 0
Server Address Default server IP address used when no proximity information available for client approaching this farm.
Values: Remote or distributed servers configured for this farm. No default.
Server Port Zero (0) if no application port has been specified.
Admin Status Enables (default) or disables default redirection for the farm.
Parameter
Description
AppDirector User Guide
Configuring Global Load Balancing
Document ID: RDWR-AD-V0231-UG1105 325
4.Click Set. Your configuration is set.
AppDirector User Guide
Configuring Global Load Balancing
326 Document ID: RDWR-AD-V0231-UG1105
Configuring Local Report Protocol
This section describes methods used to provide an AppDirector-Global device with load and availability information for other AppDirector sites to redirect traffic according to load and availability. The following topics are included:
• Introducing the Load Report Protocol (LRP)
, page 326
• Local Load Report Protocol (Local LRP)
, page 329
Introducing the Load Report Protocol (LRP)
AppDirector-Global can redirect traffic to distributed locations over the Internet, if the distributed site provides better service to the client (in terms of availability, load and proximity). These distributed sites can have a standalone server or a server farm managed by another AppDirector. AppDirector-Global needs information on the load and availability of these distributed sites to be able to make such decisions. When a distributed site is equipped with an AppDirector that manages a server farm, a proprietary inter-AppDirector protocol, called LRP (Load Report Protocol), is used by distributed AppDirectors to report the availability and load of their farms to other AppDirectors. LRP is a simple UDP-based protocol using UDP port 2090.
An AppDirector running this version will be able to communicate via LRP only with AppDirector devices running version 2.14 or higher or devices running AppDirector 1.07 versions from 1.07.15 and higher.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 than 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 is displayed 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.
AppDirector User Guide
Configuring Global Load Balancing
Document ID: RDWR-AD-V0231-UG1105 327
The configuration of a Report Table entry depends on the environment at the Local AppDirector site. The factors that influence it are:
• Whether the Global Triangulation method can be used to redirect traffic to this Local AppDirector farm.
• Whether any NAT device is installed in front of the Local AppDirector device and/or Remote AppDirector device.
• Whether any multi-homing NAT device (such as LinkProof) is installed in front of the Local AppDirector device
The following figure describes a configuration in which SF-Farm from San Francisco (Local AppDirector) is displayed 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). Figure 13: Load Reporting
To configure Load Report for Local AppDirector 1.From the AppDirector menu, select Distributed System > Report Configuration. The Load Report window is displayed.
2.Click Create. The Load Report Create window is displayed.
AppDirector User Guide
Configuring Global Load Balancing
328 Document ID: RDWR-AD-V0231-UG1105
3.Set the parameters.
4.Click Set. Your configuration is set.
5.Adjust Load Report Interval and Load Report Timeout fields in the Global Configuration window, as described in the Global Configuration section.
Parameter
Description
Distributed Farm Name
Name of farm in the Remote device that includes the Local AppDirector farm as a distributed server - in the example above, 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.
Farm Name Name of the local farm whose load we are reporting - in the example above, SF-Farm. This is required if the Layer 4 policy configured for this entry points to a Layer 7 policy (otherwise it s automatically set to the farm name used in the Layer 4 policy). Note: If no farm name configured, no report is sent.
L4 Policy Name Layer 4 policy configured in the Local device, that points to the farm whose load we are reporting - in the example above, SF-Policy.
Triangulation VIP Virtual IP address for global triangulation on the Local AppDirector - in the example above, 200.1.1.220. This parameter is relevant only when Global Triangulation is used.
Triangulation VIP NAT Public IP address for Triangulation VIP, required only when Global Triangulation with NAT is used - in the example above 250.1.1.220.
Destination Address IP interface of the Remote AppDirector device, or NAT IP for this interface, to which load and availability reports for local farms are sent - in the example above 100.1.1.10, or 163.1.1.10 if NAT device is present. Redundant Destination 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.
Operation Status
Values: Active /Inactive.
(Read Only) in Update mode.
Original VIP Original VIP (on the Remote AppDirector) to which the client sent the request, required when Global Triangulation is used- in the example above 100.1.1.100, or 163.1.1.100 if NAT device is present. This is the address that the Local AppDirector device uses as source IP for triangulated traffic.
AppDirector User Guide
Configuring Global Load Balancing
Document ID: RDWR-AD-V0231-UG1105 329
Local Load Report Protocol (Local LRP)
Large companies may have large networks, including multiple sites and broad internal networks. Handling these networks might require a layer of devices, consisting of global, local, or centralized AppDirectors. This is emphasized when security devices such as firewalls are connected in front of the internal LAN. Since firewalls usually perform NAT and policy management on internal clients, connecting one AppDirector on the external side of the firewall entails complicated IP management. Connecting one AppDirector on the internal side of the firewall does not solve the problem if there are global sites to be handled; the solution is a two-tiered AppDirector setup. Global AppDirectors handle traffic redirection between two sites, while Local AppDirectors handle local servers. From the Global AppDirector view, the farm of the Local AppDirector is a local server handling all traffic to the internal network. The solution is to use LRP messages between the two AppDirector devices using the Local AppDirector server type. Traffic is forwarded to the Local AppDirector devices and not redirected, as in the global solution with Distributed AppDirectors. In a Global Triangulation scheme, the local AppDirector is configured as a farm of the Global AppDirector, causing the Global AppDirector to load balance traffic to the local AppDirector as if it was a regular server. To configure Local LRP
1.On the global AppDirector, define the local AppDirector as a local AppDirector server in the relevant farm's Remote Server Table.
2.On the local AppDirector, define the relevant LRP reporting entries to accommodate the relationship between the global and local AppDirectors.
To configure AppDirector Local LRP
1.From the AppDirector menu, select Global > Global Parameters. The Global Parameters window is displayed.
2.Set the parameters.
Parameter
Description
Open New Entry When Source Port Different
• Enable: Each session that a client opens, is recorded in the Client Table separately.
• Disable (default): All client sessions are considered a single session, providing better performance.
Select New Server When Source Port Different
• Enable: Different sessions opened by a client's application are served by different servers, according to the load balancing algorithms. • Disable (default) Note: This option provides a more accurate minimum-user load balancing, but may hinder some applications that depend on the same server. It also may overload AppDirector`s internal tables. This option overrides the New Entry On Source Port option.
AppDirector User Guide
Configuring Global Load Balancing
330 Document ID: RDWR-AD-V0231-UG1105
3.Click Set. Your configuration is set.
LRP in Multi-Homed Environments
When an AppDirector is installed behind a NAT device that load balances inbound and outbound traffic between multiple WAN links it means it operates in a multi-homed environment. The most obvious example of such a NAT device is Radware's LinkProof.
In such an environment an AppDirector service (VIP) is accessible via a number of public IP addresses - one for each WAN link load balanced by the multi-homing device. When a Local AppDirector site is multi-homed, it affects the LRP in the following way:
1.The Local AppDirector must send multiple reports for each "local farm-Remote AppDirector" combination - one report for each WAN link managed by the multi-homing device. For example, if the site has 3 WAN links, 3 Report Table entries are configured for each "local farm-Remote AppDirector" combination.
2.The Remote AppDirector farm must also have multiple distributed servers representing the same Local AppDirector farm. In the above example, 3 distributed servers that represent Local AppDirector must be configured in the Remote AppDirector farm.
3.The Local AppDirector needs to split the actual load of the local farm between the multiple reports it sends to the same Remote AppDirector. In the above example, if the current load is 1500 users, each of the three reports Local AppDirector is sending will report 500 users.
4.The reports Local AppDirector is sending must also take into consideration the availability of the WAN links - if one of the WAN links is unavailable, Local AppDirector cannot send the relevant report for this entry. For the example in figure 2, if link A is down, Local AppDirector should not send a report for distributed server 250.1.1.200 - the Remote AppDirector will understand that this server is unavailable.
To allow Local AppDirector to check WAN links availability and send LRP messages accordingly, health checks must be configured for each WAN link on Local AppDirector. The health check of each link must be bound to the respective Load Report entry. In the Health Monitoring Bind table (page ….) the Load Report entry is identified by its Health Monitoring ID field (a string identifier must be configured in this field when the Load Report entry is defined).
To ensure that each health check configured on Local AppDirector will indeed check the required link there are two options:
• The destination IP of the health check is the internal interface of the access router for that link - in this case LinkProof routes the health check request to the proper router.
• The destination IP of the health check is an external address from the respective link provider (DNS server, etc). The address used for each health check must be different. The LinkProof must be configured to send each health check through the appropriate link by using traffic routing policies (grouping or flow policies according to LinkProof version) to ensure the correct WAN link is checked - for details please see LinkProof user guide.
Load Report Interval Interval (in seconds) for sending dynamic updates of the local load to other AppDirector's devices that are served by this AppDirector. Also see Configuring Local Report Protocol
, page 326
.
Load Report Timeout The time (in seconds) a Remote AppDirector waits to receive load reports from the Local AppDirector is configured via the Load Report Timeout parameter in the Remote AppDirector. Also see Configuring Local Report Protocol
, page 326
.
Parameter
Description
AppDirector User Guide
Configuring Global Load Balancing
Document ID: RDWR-AD-V0231-UG1105 331
Example The following is an example of the configuration required on a Local AppDirector that is installed behind a LinkProof (Figure 2). Step 1. Configure the appropriate entries in the Report Table.
Step 2. Configure health checks for each WAN link. This example shows configuration of simple health checks, but a health check group can also be bound to a Load Report entry.
Step 3. Bind each health check with the corresponding Load Report entry.
Domain Name System (DNS)
This section discusses host names and persistency and contains the following topics:
• Host Names
, page 332
• DNS Server Parameters
, page 336
• Static DNS Persistency
, page 339
• DNS Statistics
, page 341
Parameter
Entry 1
Entry 2
Entry 3
Distributed Farm NY-Farm NY-Farm NY-Farm
Distributed Server 250.1.1.200 192.1.1.200 176.1.1.200
L4 Policy SF-Policy SF-Policy SF-Policy
Farm Name SF-Farm SF-Farm SF-Farm
Triangulation VIP 200.1.1.220 200.1.1.220 200.1.1.220
Triangulation VIP NAT 250.1.1.220 192.1.1.220 176.1.1.220
Report Destination Address
100.1.1.10 100.1.1.10 100.1.1.10 Backup Report Destination Address
Health Monitoring ID SF-link1 SF-link2 SF-link3
Origin IP Address 100.1.1.100 100.1.1.100 100.1.1.100
Health Check Name
WAN1
WAN2
WAN3
Method/Arguments As required As required As required
Destination Host 250.1.1.11 192.1.1.31 176.1.1.53
Next Hop Router 200.1.1.10 200.1.1.10 200.1.1.10
Health Check Name
WAN1
WAN2
WAN3
Server/NHR/Report Report-SF-link1 Report-SF-link2 Report-SF-link3
AppDirector User Guide
Configuring Global Load Balancing
332 Document ID: RDWR-AD-V0231-UG1105
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 user’s machine to communicate through IP with the machine that hosts the website of www.radware.com.
The DNS server consists of two main components:
• The resolver: Component responsible for asking a DNS question about the IP address, associated with the URL representing this address. • The name server: Component responsible for answering a DNS query. This is the agent present in DNS servers. When asked "What is the IP address of www.company.com?", the name server answers to the best of its ability.
All basic Internet hosts and TCP/IP stacks contain the resolver, while DNS servers contain both components: resolver and name server. The resolver is necessary if there is a question that the DNS server cannot answer. There are two kinds of DNS questions, or DNS "queries," that can be asked:
• Iterative: An iterative query CAN be answered with an absolute answer (IP address) or a referral.
• Recursive: A recursive query MUST be answered with an absolute answer (IP address).
Client resolvers cannot handle referrals and therefore, can only ask recursive questions. Server resolvers, on the other hand, can handle referrals and can ask recursive or iterative questions. Although it is more common for server resolvers to make iterative queries, they may at times make recursive queries. When a name server is asked a recursive question, it must answer the question. If it does not know the answer, it finds it. When a name server is asked an iterative question, it answers the question to the best of its ability. If a name server knows the answer, the response is the requested IP address; if a name server does not know the answer, the response is a referral answer that includes the DNS and IP address of one or more name server(s) that may know the answer.In the DNS, the IP world is divided into domains. Each domain contains hosts. For example, a host known as www.radware.com is a host in the radware.com domain. Radware.com is a sub-
domain of the.com domain. Each domain in the Internet community has one or more “authoritative” name servers. An authoritative name server for a domain is responsible for all sub-domains and hosts within the domain or any of the sub-domains.
Host Names
This DNS table is used to define the relationships between hostnames and farms. You configure the Host Names Table by defining the IP of the farm which handles the URL. You can define wildcard host names using the RegExp Host Name Table. In addition to the definition of explicit URLs in the Host Names Table. This allows you to set a single definition for many similar URLs that are hosted on the same farm. When a DNS request arrives AppDirector first looks for an exact match in the Host Name Table. If such a match is not found, AppDirector looks for a match in the RegExp Host Name Table according to the configured order of entries. When no match is found, AppDirector discards the DNS request.
AppDirector User Guide
Configuring Global Load Balancing
Document ID: RDWR-AD-V0231-UG1105 333
To set/update the parameters of the Host Names Table 1.From the AppDirector menu, select DNS > Host Names. The Host Names Table window is displayed.
2.Set the parameters.
Parameter
Description
Host Name (Read-
Only Parameter for Update mode)
Verifies that the farm name is bound to a Layer 7 policy. IPv4 Entry
Layer 4 Policy Name IPv4
Layer 4 Policy Name associated with Host Name entry provides information about the relevant farm, and Virtual IP to be used in reply. The farm is used to consider the servers’ load and can optionally use Remote Servers or Distributed AppDirector in the farm for the DNS resolution process.
If the Layer 4 policy selected for host name entry is connected to a Layer 7 policy, then you need to select the appropriate farm in the Farm Name field. If no farm is selected, DNS queries to this host name will not be answered and the Farm Name from the Layer 4 Policy is automatically selected.
Note: System administrators need to configure the appropriate farm, on whose availability the decision for DNS resolution of this host name is made.
Preferred Resolve IP IPv4
Chooses how to resolve for the best available IP.
• 0.0.0.0 (default): Here the host name is resolved to the best available IP without taking Operation Mode into account. • The VIP of the Layer 4 policy defined for this host name (default): Here the host name is resolved to the best available IP while taking Operation Mode into account. If a local server in Regular Operation Mode is available and the Farm distribution threshold was not reached, the device answers with the Layer 4 policy VIP, if not it selects the IP of one of the remote and distributed server's IPs according to availability, load and proximity.
• The IP of a Distributed AppDirector server or a Remote server in the farm attached to the Layer 4 policy defined for this host name. While the specified server is available, the host name is resolved to its IP.
Farm Name IPv4
(Read-Only Parameter for Update mode)
Farm that you want to include in this policy, for example, Main Farm.
Notes:
• When a host name entry is created, if the Layer 4 Policy defined for this host name entry has the Farm Name field configured (does not include a Layer 7 policy), that farm name is displayed in the host name entry Farm Name field by default.
• System administrators need to configure the appropriate farm, whose availability the decision for host name DNS resolution is made.
External NAT Address IPv4
Required when AppDirector is located behind a NAT device that NATs the VIP address for the host name. AppDirector must use External NAT Address in its DNS reply for DNS queries for host names.
AppDirector User Guide
Configuring Global Load Balancing
334 Document ID: RDWR-AD-V0231-UG1105
3.When creating, in the Host Names Table window, click Create. The Host Names Table Create window is displayed, which contains the above parameters:
4.When updating, in the Host Names Table window, select the desired Host Name. The Host Names Table Update window is displayed.
5.Set the parameters.
6.Click Set. Your configuration is set.
IPv6 Entry
Layer 4 Policy Name IPv6
Layer 4 Policy Name associated with Host Name entry provides information about the relevant farm, and Virtual IP to be used in reply. The farm is used to consider the servers’ load and can optionally use Remote Servers or Distributed AppDirector in the farm for the DNS resolution process.
If the Layer 4 policy selected for host name entry is connected to a Layer 7 policy, then you need to select the appropriate farm in the Farm Name field. If no farm is selected, DNS queries to this host name will not be answered and the Farm Name from the Layer 4 Policy is automatically selected.
Note: System administrators need to configure the appropriate farm, on whose availability the decision for DNS resolution of this host name is made.
Preferred Resolve IP IPv6
Chooses how to resolve for the best available IP.
• 0.0.0.0(default): Here the host name is resolved to the best available IP without taking Operation Mode into account. • The VIP of the Layer 4 policy defined for this host name (default): Here the host name is resolved to the best available IP while taking Operation Mode into account. If a local server in Regular Operation Mode is available and the Farm distribution threshold was not reached, the device answers with the Layer 4 policy VIP, if not it selects the IP of one of the remote and distributed server's IPs according to availability, load and proximity.
• The IP of a Distributed AppDirector server or a Remote server in the farm attached to the Layer 4 policy defined for this host name. While the specified server is available, the host name is resolved to its IP.
Farm Name IPv6
(Read-Only Parameter for Update mode)
Farm that you want to include in this policy, for example, Main Farm.
Notes:
• When a host name entry is created, if the Layer 4 Policy defined for this host name entry has the Farm Name field configured (does not include a Layer 7 policy), that farm name is displayed in the host name entry Farm Name field by default.
• System administrators need to configure the appropriate farm, whose availability the decision for host name DNS resolution is made.
External NAT Address IPv6
Required when AppDirector is located behind a NAT device that NATs the VIP address for the host name. AppDirector must use External NAT Address in its DNS reply for DNS queries for host names.
Parameter
Description
AppDirector User Guide
Configuring Global Load Balancing
Document ID: RDWR-AD-V0231-UG1105 335
To update the parameters of the RegExp Host Name Table 1.From the AppDirector menu select DNS > Host Names. The Host Names window is displayed.
2.Select the desired Host Name. The RegExp Host Names Update window is displayed.
3.Set the parameters.
Parameter
Description
RegExp Host Name Displays the Regexp Host Name for the Farm table.
Enter in the URL type. For example any URL that begins with the string “www.abc.”, followed by any text using letters and then followed by “.com” is resolved to the IP of the related farm or to the Layer 4 policy, when defined.
Index Regular expression evaluation order.
Default: 0
Layer 4 Policy Name
The Layer 4 Policy Name associated with a Host Name entry provides information about the relevant farm, and Virtual IP to be used in reply.
The farm is used to consider the servers’ load and can optionally use Remote Servers or Distributed AppDirector in the farm for the DNS resolution process.
If the Layer 4 policy selected is connected to a Layer 7 policy, then you need to select the appropriate farm in the Farm Name field. If no farm is selected, DNS queries to this host name will not be answered and the Farm Name from the Layer 4 Policy is automatically selected.
Note: System administrators need to configure the appropriate farm, whose availability the decision for host name DNS resolution is made.
Farm Name
(Read-Only Parameter for Update mode)
Farm that you want to include in this policy, for example, Main Farm.
Default: None
Notes:
• When a host name entry is created, if the Layer 4 Policy defined for this has the Farm Name field configured (without a Layer 7 policy), the farm name is displayed in the host name entry Farm Name field by default.
• System administrators need to configure the appropriate farm, whose availability is decided for host name DNS resolution.
External NAT Address
Required when AppDirector is located behind a NAT device that NATs the Virtual IP address for the host name. Here, AppDirector must use the External NAT Address in DNS reply for DNS queries for host names.
AppDirector User Guide
Configuring Global Load Balancing
336 Document ID: RDWR-AD-V0231-UG1105
4.Click Set. Your configuration is set.
Notes:
>> Host Name field (Host Name and RegExp Host Name Table) is case insensitive.
>> Total number of entries in Host Name Table and RegExp Host Name Table is determined by the value of Host Names parameter in Tuning settings. >> A “.” In a regular expression means any single character, to indicate a “.”, a“\” must be used before the “.”.
DNS Server Parameters
You can provide multiple a Virtual IP Interface address that can be backed up by the redundant device. If the main device fails, DNS requests are handled seamlessly and transparently by the redundant device.
To configure a Virtual IP Interface address to be backed up 1.From the AppDirector menu, select DNS > Server. The DNS Server Parameters window is displayed.
2.Set the parameters.
3.Click Set. Your configuration is set.
Preferred Resolve IP
Chooses how to resolve for the best available IP.
• 0.0.0.0 (default): The host name is resolved to the best available IP (either local VIP or VIP of a distributed site as part of local farm). AppDirector selects a Non-Backup server local or distributed (if the farm reaches the threshold) and there is no Non-Backup, it will choose a Backup server but it will treat the Backup Distributed server as a regular distributed server.
• The Local VIP - The VIP of the Layer 4 policy defined for this host name. If a local server is available, the device answers with the Layer 4 policy VIP. it selects the IP of one of the remote and distributed server's IPs according to availability, load and proximity. AppDirector selects a Non-Backup server local or distributed (if the farm reaches the threshold), if there is no Non-Backup it will choose a Backup server.
• Remote VIP - IP of a Distributed AppDirector server or a Remote server (not recommended, but possible) in the farm attached to the Layer 4 policy defined for this host name. If the distributed server is active it will ALWAYS be chosen regardless of the other servers.
Parameter
Description
DNS Service Enable or Disable (Default) the DNS service.
Two Records in DNS Reply
Enable or Disable (Default) return of two A records in the DNS response. Enable returns two A records, disable returns one.
Parameter
Description
AppDirector User Guide
Configuring Global Load Balancing
Document ID: RDWR-AD-V0231-UG1105 337
DNS Persistency
AppDirector maintains persistency for consecutive DNS queries received from the same DNS client IP address. For example, if a DNS server honors the low TTL that the AppDirector assigned to DNS replies, it sends queries for the same farm every few seconds. If the client does not cache the replies, or caches them for a short period, consecutive connections for the same session may end up on two different sites.
When AppDirector receives a DNS request for a host name, for example www.a.com, it first searches for the host name in the Host Name Table; and if the host name is not found, AppDirector searches the RegExp Host Name Table. Once an entry is matched, the relevant Layer 4 Policy that serves this host name is determined. If DNS Persistency is configured for this Layer 4 Policy, AppDirector searches the static and dynamic tables to determine the IP address used in the DNS reply. When AppDirector devices are used in multiple sites to provide a global solution, Hashing can be used to provide consistent DNS replies from different AppDirector devices to the same DNS client IP. DNS Persistency can be configured for each farm using:
• DNS Persistency: When AppDirector answers a DNS request, it creates an entry in the DNS Persistency Table, indicating the requester's IP address and the VIP that was sent as a response. AppDirector provides the same reply to that requester as long as there is a record in the table.
• Static DNS Persistency: You can statically set VIPs to be used for a range of DNS IP addresses.
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 S
tatef
u
l Failover (Mirroring
)
, page 158
).
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 339
).
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.
AppDirector User Guide
Configuring Global Load Balancing
338 Document ID: RDWR-AD-V0231-UG1105
• When Hashing is used for DNS Persistency, Capacity Threshold and Distribution Threshold are ignored. DNS Grouping Mask
DNS Persistency can be maintained for groups of DNS client IP addresses, both when using Load Balancing or Hash. For example, when the DNS Grouping Mask is set to 255.255.255.0, the same DNS replies are sent to IP address 1.1.1.1 and 1.1.1.66. To define DNS persistency 1.From the AppDirector menu, select Farms > DNS Persistency Parameters. The DNS Persistency Parameters Table window is displayed.
2.Select the farm where you want to define DNS persistency. The DNS Persistency Parameters Table Update window is displayed.
3.Set the parameters.
4.Click Set. The DNS Persistency Parameters Table Update window closes.
Parameter
Description
Farm Name (Read Only)
Name of the farm for which DNS persistency is used. Status • Disabled (Default): Disables DNS Persistency.
• Enabled: Enables DNS Persistency.
Mode AppDirector selects VIP used in DNS replies for the farm using these modes:
• Load Balancing (Default): Load Balancing algorithms are used, considering load and proximity information. • Hash: Hash on client IP address. This can be used when AppDirector devices are in a multiple site and global DNS persistency is required. Static Mode • Disabled (Default): Disables Static DNS Persistency.
• Enabled: Enables Static DNS Persistency.
Aging Mode Entries in DNS Persistency Table can be aged based on these modes:
• Fixed: Entry is removed from the table after the period of time defined by the Aging Time parameter.
• Inactivity (Default): Entry is removed from table if during the period defined by the Aging Time parameter no additional DNS queries are received from the same DNS client IP address. Aging Time Defines how many seconds an entry remains in the DNS Persistency Table. Values: 1 - 4,234,967,295 seconds (136 years). Default: 60 seconds
Grouping Suffix Length
The suffix length for a group of DNS client IP addresses. This is the IPv6 mask suffix length that defines a group of IPv6 clients for which the same farm server should be selected.
Grouping Suffix Type
The suffix type for a group of DNS client IP addresses. Values: IPv4, IPv6
AppDirector User Guide
Configuring Global Load Balancing
Document ID: RDWR-AD-V0231-UG1105 339
Aging Mode
Entries in the DNS Persistency Table can be aged by the Fixed or Inactivity modes. When Fixed mode is used, the entry is removed from the table after the period of time defined by the Aging Time parameter. When Inactivity mode is used, the entry is removed from the table if no additional DNS queries are received from the same DNS client IP address during the period defined by the Aging Time parameter.
Static DNS Persistency Static DNS Persistency operates at the farm level based on Client IP Range. This means that requests from client IP addresses in the same range to different hostnames that are mapped to the same farm are replied using the same VIP. This VIP is called Preferred VIP and can be defined using the Static DNS Persistency table.
You can also set an Alternate VIP to be used when the Preferred VIP is not available or overloaded. When the Preferred VIP is not available and the Alternate VIP is set to Any, then AppDirector dynamically selects the VIP for the DNS reply.
Note:To use static DNS, you need to first set the tuning on the device.
To define static DNS persistency 1.From the AppDirector menu, select DNS > Persistency Table. The Static DNS Persistency Table window is displayed.
2.Click Create. The Static DNS Persistency Table Create window is displayed. Caution:Before adding entries to the Static DNS Persistency table, you must enable DNS Persistency and Static DNS Persistency.
3.Set the parameters.
Parameter
Description
Farm Name Select the name to describe the AppDirector farm.
From Client IP Address First IP address in client IP range for static DNS resolution.
To Client IP Address Last IP address in client IP range for static DNS resolution.
Preferred VIP IPv4 IP address to be used for DNS replies for host names managed by this farm. This address is usually set to the Virtual IP address associated to Layer 4 Policy, or one of that farm's servers, of type Remote Server, Distributed Server, or Local Farm.
Note: AppDirector uses this IP address only if the corresponding farm server is available.
AppDirector User Guide
Configuring Global Load Balancing
340 Document ID: RDWR-AD-V0231-UG1105
4.Click Set. The DNS Persistency Parameters Table Update window closes and the new parameters appear in the DNS Persistency Parameters Table window.
Alternate VIP IPv4 Alternate VIP can be set to one of the following values:
• None (default): AppDirector does not reply to DNS query if the preferred server is not available.
• Any: When the preferred server is not available, AppDirector selects a VIP according to the configuration of the DNS Persistency Mode parameter using Load Balancing algorithm or using Hash.
Note: AppDirector uses the IP address configured as Alternate VIP for DNS replies only when the corresponding farm or server is available.
Preferred VIP IPv6 IP address to be used for DNS replies for host names managed by this farm. This address is usually set to the Virtual IP address associated to Layer 4 Policy, or one of that farm's servers, of type Remote Server, Distributed Server, or Local Farm.
Note: AppDirector uses this IP address only if the corresponding farm server is available.
Alternate VIP IPv6 Alternate VIP can be set to one of the following values:
• None (default): AppDirector does not reply to DNS query if the preferred server is not available.
• Any: When the preferred server is not available, AppDirector selects a VIP according to the configuration of the DNS Persistency Mode parameter using Load Balancing algorithm or using Hash.
Note: AppDirector uses the IP address configured as Alternate VIP for DNS replies only when the corresponding farm or server is available.
Parameter
Description
AppDirector User Guide
Configuring Global Load Balancing
Document ID: RDWR-AD-V0231-UG1105 341
DNS Statistics
You can generate statistics regarding DNS requests.
To view the DNS Statistics From the AppDirector menu, select DNS > Statistics. The DNS Statistics window is displayed, which contains the following read-only statistics:
Redirection
This section describes methods used to redirect traffic in the global traffic management solution and includes the following topics:
• DNS Redirection
, page 342
• HTTP Redirection
, page 342
• HTTP to HTTPS Protocol Redirection
, page 343
• RTSP Redirection
, page 345
• SIP Redirection
, page 345
• Proxy Redirection
, page 346
• Global Triangulation Redirection
, page 346
• Setting Redirection Parameters
, page 348
• Anycast Advertise
, page 350
When using the global traffic management solution, several Redirection methods can help to define how service requests are redirected.
When a client sends a new request for service, AppDirector selects the best available server. If the required server is at the local site, AppDirector forwards the service request to that server. If the required server is at a remote site, AppDirector redirects the service request using one of the methods.
Multiple redirection modes can be enabled per farm. Exceptions include Global Triangulation and Proxy (Client NAT) which cannot be enabled simultaneously. When an application-specific redirection process (HTTP, RTSP, SIP) and a Global Triangulation or Proxy mode are enabled in a farm, traffic belonging to an application for which a specific redirection mode is enabled (HTTP, RTSP or SIP) is redirected accordingly, while other applications are redirected using the Triangulation or Proxy methods.
Parameter
Description
DNS Requests Last Second Number of DNS requests in the last second. Default: 0
DNS Replies Last Second Number of DNS replies in the last second.
Default: 0
Failed DNS Requests Last Second Number of DNS failed requests in the last second.
Default: 0
AppDirector User Guide
Configuring Global Load Balancing
342 Document ID: RDWR-AD-V0231-UG1105
DNS Redirection
The DNS Redirection method is based on the DNS process (see DNS Persistency
, page 337
). When a client sends a DNS query to find the IP address of the host name of the requested service, AppDirector operates as a DNS server. When a DNS query is made, AppDirector responds with the IP address of the best site for the client. If the local AppDirector decides that the current site is best suited for handling the client, it sends the query to its own VIP address. Otherwise, AppDirector resolves the DNS query using the IP address of a remote farm or server. Redirection is only performed during the DNS query/answer stage. Therefore, if DNS Redirection is enabled on a farm, any packet destined to the Virtual IP address is handled by the local servers of this farm. The DNS Redirection process involves the following steps:
1.The DNS request reaches the AppDirector-Global physical IP Interface or Virtual IP Interface from a DNS server. The request is to resolve a host name to an IP address.
2.No search of the Client Table is made. AppDirector-Global searches the Static Proximity Table for a range fitting the asking DNS server. If a match is made, the top priority server from the active AND not overloaded servers is selected. AppDirector-Global resolves the name to the IP address of the chosen server, which can be a local Layer 4 VIP or a VIP configured on a remote AppDirector.
3.If there is no match in the Static Proximity Table, the Dynamic Proximity Table is searched. If there is a match, AppDirector-Global resolves the request to the Layer 4 VIP address of the highest priority site (currently active and not overloaded), accounting for the hops weight, latency weight, and the load weight variables.
4.If there is no match, AppDirector-Global resolves the request to the IP address of the least loaded site, while calculating proximity information for the querying DNS server (if proximity is enabled). Then AppDirector-Global sends PRP requests to other AppDirectors to do the same.
5.AppDirector-Global resolves the query to the IP address of the least loaded site.
Notes:
>> DNS answers are made with a DNS TTL of 0,(default) to reduce Internet caching and to keep the system dynamic. >> You can set DNS TTL to a higher value and you can set different DNS TTL values for different farms.
Using AppDirector-Global, DNS Redirection works best if DNS servers from all over the Internet make queries to AppDirector-Global. If the DNS servers local to AppDirector-Global or responsible for the “super-domain” make queries to AppDirector-Global, their proximity calculations result in inaccurate data. AppDirector-Global allows you to configure up to two DNS servers with requests that are resolved to the least loaded site; no proximity calculations are made if a request comes from either of these two DNS servers. HTTP Redirection
The HTTP redirection method is used to redirect the HTTP traffic as follows:
1.The client sends the GET request using the HTTP protocol to a VIP address of AppDirector.
2.AppDirector receives the request and selects the best server for the task.
3.If AppDirector decides that a distributed site or remote server is the most appropriate, then it issues an HTTP redirect to the user indicating that the user has been redirected. Here, AppDirector replies to the HTTP request using an HTTP code redirection code (Moved Temporarily or Moved Permanently) and redirects the client to the relevant server.
AppDirector User Guide
Configuring Global Load Balancing
Document ID: RDWR-AD-V0231-UG1105 343
HTTP redirection can be done by IP address or by name. HTTP redirection by IP redirects the request for service to the IP of the remote server or the VIP of the Distributed AppDirector. When using HTTP redirection by name, AppDirector redirects the client to another URL. The URL used for redirection is configured using the Redirect To URL parameter in the server to which redirection is performed. Note:When redirect by name is enabled and the redirect to URL field is empty, AppDirector uses server name for redirection. HTTP to HTTPS Protocol Redirection
HTTP to HTTPS protocol redirection is based on the location field in HTTP headers where AppDirector handles SSL for backend servers, and the backend server performs a redirect using HTTP headers specifying URL with HTTP:// instead of HTTPS://. AppDirector can redirect HTTP traffic to HTTPS. Using this method, you can configure AppDirector to redirect clients to secure access to the site. You can set AppDirector to indicate to a client to access the site using HTTPS rather than HTTP when redirecting a client using HTTP redirection.
HTTP Persistency in Global Environment In order to ensure transaction stickiness at all times in a global environment it is recommended to use the Insert cookie capability, together with HTTP Redirection, for all farms involved.
AppDirector can identify the cookie used by client belongs to a different site (was inserted at the beginning of the transaction by an AppDirector at that site) and employ HTTP redirection to transfer the new request to the original site.
To maintain site and server persistency in a global environment: • Ensure that the automatically generated Set-Cookie method uses the same cookie key in all sites; this can be achieved either by using the same Farm Name in all sites, or by editing the automatically generate cookie key. • If HTTP redirection is used:
— Redirection must be by name — Hostnames for all sites must belong to the same domain (for example www.a.com for the main service, www.site1.a.com for site 1 and www.site2.a.com for site 2). — Set the domain value of the automatically generated Set-Cookie method to the service domain (in the example above a.com)
• Site and server persistency based on cookie can be supported also when application redirection is performed using proxy or global triangulation methods instead of HTTP redirection.
When AppDirector performs SSL for Back End servers the servers receives the requests in HTTP (clear), therefore, when servers perform redirect to another page/site (using HTTP headers in response with location field), it can now also use HTTP. If the clients receive this header they will initiate the new connection over HTTP instead of over HTTPS and is dropped. Therefore the AppDirector, that sends the response back to the clients must change the server's redirection location URL appearing in the HTTP header from HTTP:// to HTTPS://. This modifies the location header of any HTTP header in server's responses from HTTP:// to HTTPS:/
/, and the target port. The modification is performed where the host name in the client's request matches the host name in the server's response, or where matching criteria are met. Matching criteria can consist of one Regex that represent hostnames.
AppDirector User Guide
Configuring Global Load Balancing
344 Document ID: RDWR-AD-V0231-UG1105
Notes:
>> For HTTPS redirection - if the Layer 4 policy port is different than port 443, the Layer 4 policy port is appended after a colon to the URL.
>> For HTTP redirection - If the Layer 4 policy port is different than port 80, the Layer 4 policy port is appended after a colon to the URL
>> When Backend SSL is working, you do not need to use HTTP to HTTPS protocol redirection and you cannot configure them together.
Protocol Redirection
If a user requests the www.ab.com/base_redirect.html page, the page is redirected to www.bb.com/
Redirect/Path/redirect_page.html.
If the redirect was from ab.com to ab.com/some-other-path, no regular expression
is needed since this is the same host.
In this example, the redirect was from ab.com to bb.com and this works only when the regular expression matches the host (the new host). Thus, when the regular expression is www.ab.com, it does not match bb.com (which is the real location of the page).
The redirection works as follows:
• AppDirector changes http to https for the following regular expressions:
"www.bb.com"
"www.b*.com"
"/*"
"bb.com"
"bb"
"www"
".com"
"."
".c"
"bb.com/Redirect/"
"www.bb.com/Redirect/Path/redirect_page.html"
"/"
• AppDirector does not change to https for the following regular expressions:
"www.ab.com"
"www.bb.com/main"
""
" "
"ab.com"
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. AppDirector User Guide
Configuring Global Load Balancing
Document ID: RDWR-AD-V0231-UG1105 345
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 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.
The RTSP redirection and the HTTP redirection methods work similarly as shown here maintaining persistency in a global environment.
To maintain RTSP site and server persistency in a global environment: • Ensure that the automatically generated Set-Cookie method uses the same cookie key in all sites; this can be achieved either by using the same Farm Name in all sites, or by editing the automatically generate cookie key. • Site and server persistency based on cookie can be supported also when application redirection is performed using proxy or global triangulation methods instead of RTSP redirection.
RTSP redirection can be done by an IP address or by name. The name is taken from the Redirect To URL parameter of the server. If the Redirect To URL parameter is not configured, the Server Name is used instead (see HTTP Redirection
, page 342
). 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 414
). Note:RTSP redirection preserves the client-server persistency of RTSP sessions when the Client Table mode Select Server When Source Port is Different is used.
SIP Redirection
The Session Initiation Protocol (SIP) is an IETF standard for a signaling protocol used for establishing sessions between two or more end users. The SIP redirection method is used to redirect SIP session invitations to external domains, such as a distributed or remote server.
The SIP redirection process involves the following steps:
1.The client sends the SIP request to an AppDirector’s 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 AppDirector’s 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. AppDirector User Guide
Configuring Global Load Balancing
346 Document ID: RDWR-AD-V0231-UG1105
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 client’s identity and therefore AppDirector has a service entry point where the client can insert the X-Forwarded-For Header in the traffic it redirects. Global Triangulation Redirection
To handle the distribution of IP protocols (for example, 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 AppDirector’s VIP. If the main AppDirector has reached its Distribution Threshold and decides to send this user to a Remote AppDirector, a simple delivery of the user’s packets to the Remote AppDirector’s VIP will not succeed. Since the user attempted to open the FTP session with main AppDirector, if the reply comes from Remote AppDirector, the session fails. For a successful FTP session, the reply to the user must be sent using the main AppDirector VIP as the Source IP address.
Notes:
>> You cannot use Global Triangulation when any Acceleration Engine related capability (i.e. SSL, Cache, Compression, and Authentication) is used.
>> The Triangulation redirection method is not applicable in a global solution configuration that uses remote servers.
To overcome this issue, AppDirector utilizes a process called VIP Mapping, which is used at the receiving AppDirector’s end (in this example, Remote AppDirector). The process consists of the mapping of three parameters:
main AppDirector
main VIP
Triangulation VIP
Address
Remote AppDirector
Remote VIP
User
AppDirector User Guide
Configuring Global Load Balancing
Document ID: RDWR-AD-V0231-UG1105 347
This mappingis achieved via the LRP mechanism. When Remote AppDirector receives packets destined for the Triangulation VIP address, it selects a server in the relevant farm and forwards the request to it. The difference is that for the reply from the server to the user, Remote AppDirector replaces the source address of the packet with the Origin VIP Address, in this example, the main VIP. This way, the user receives replies from the same address with which it tried to open the IP session. Notes:
>> Global Triangulation does not work with persistent Layer 7 switching.
>> Layer 7 with Global Triangulation assumes all sites have the same configuration.
>> In Layer 7 with Global Triangulation, the main device sends the request to the distributed site with no TCP handshake, just the GET. The Global Triangulation redirection process involves the following stages: 1.User sends a new service request to VIP of main AppDirector (main VIP).
2.Main AppDirector receives the request for service and selects the best server for the task in the relevant farm. 3.Main AppDirector decides to send the user to a distributed site. The request for service is sent using the Triangulation VIP address associated with the Remote AppDirector VIP.
4.Remote AppDirector sends the packet to one of its local servers. The reply to the user is sent using the Origin VIP Address as the source address. 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. Parameter
Description
Distributed Server VIP address of the Remote AppDirector. The Remote VIP address is configured as a distributed server in the farm on the main AppDirector.
Triangulation VIP Address
Virtual address on the Remote AppDirector associated with the main AppDirector farm. This indicates that Remote AppDirector must send the reply to the user using the main AppDirector VIP as the source address. Origin VIP Address VIP address of the main AppDirector farm that directed the user to this AppDirector. The Origin VIP Address in the example is the virtual address of the main VIP.
Main VIP
Triangulation VIP
Address
Main VIP
User IP
User IP
AppDirector User Guide
Configuring Global Load Balancing
348 Document ID: RDWR-AD-V0231-UG1105
AppDirector automatically creates, updates, and deletes the corresponding Layer 4 entries. These entries appear in Layer 4 policies. They are:
• Layer 4 Policy Name parameters is Auto_Triangulation.
• Policy Defined By parameter is System, for internally managed Layer 4 policies.
Extended LRP Security
When the Triangulation redirection method is used (see Global Triangulation Redirection
, page 346
), the Triangulation VIP address must be on the same subnet as the Virtual IP address, for security reasons. To ensure that the Triangulation VIP address configured for a farm is on the same subnet as that farm, the Extended LRP Security option must be enabled. Note:The Triangulation VIP address and the Layer 4 Virtual IP address cannot be configured on different subnets when Extended LRP Security is enabled. Extended LRP Security is defined globally for each AppDirector and enabled by default. To place them on different subnets, you must disable this option.
Setting Redirection Parameters
When using the global traffic management solution, several Redirection methods are available to define how service requests are redirected to their required destinations. When a client sends a new request for service, AppDirector selects the best available server for the task. If the required server is placed at the local site, AppDirector forwards the request for service to that server. If the required server is located at the remote site, AppDirector redirects the request for service using one of the redirection methods. The redirection methods are configured at farm level. Multiple redirection methods can be configured for each farm.
To set Redirection Parameters 1.From the AppDirector menu, select Farms > Redirection. The Redirection Table window is displayed.
2.Select the farm where you want to define redirection. The Redirection Table Update window is displayed.
3.Set the parameters.
Parameter
Description
Farm Name Name of farm for which redirection is configured. Read-only parameter. DNS Redirection Enables the DNS redirection method.
Based on the DNS mechanism. When a client sends a DNS query to find an IP address of requested service host name, AppDirector operates as a DNS server.
DNS Response TLL Number of seconds in which DNS responses are cached. Default: 0
AppDirector User Guide
Configuring Global Load Balancing
Document ID: RDWR-AD-V0231-UG1105 349
HTTP Redirection Enables HTTP redirection method and is used to redirect HTTP traffic.
Values:
• 302 Moved Temporarily
• Disabled (default)
• Moved Permanently
• RFC Moved Temporarily
Redirect To HTTPS Enables the HTTPS redirection method.
Values:
• Disabled
• Enabled (default)- both HTTP and HTTPS traffic that arrives at this farm will be redirected to HTTPS, in case redirection is necessary.
• HTTPS only - only HTTPS is redirected (HTTP is not redirected to HTTPS).
RTSP Redirection Enables the RTSP redirection method where AppDirector can redirect RTSP sessions to a remote site.
Default: Disabled
SIP Redirection Enables the SIP redirection method.
Default: Disabled
AppDirector can redirect Session Initiation Protocol (SIP) sessions (UDP) using the redirection option (302) within the SIP protocol.
Global Triangulation Enables the Global Triangulation method.
Default: Disabled
Global Triangulation uses a Radware proprietary scheme to redirect traffic to a remote AppDirector.
Proxy Redirection (Client NAT)
Enables the Proxy redirection method.
Default: Disabled
This method uses Client NAT to redirect traffic to another server or site. When selected, the Client NAT ranges must also be configured.
Redirect By Name Server's Redirect To parameter is used as the host name to which redirect is performed (for HTTP/HTTPS/RTSP/SIP). Or you can use the server IP.
Farm Distribution Threshold
Local load balancing is performed between local servers until the farm reaches the Distribution Threshold limit. Then the distribution algorithm allows AppDirector to redirect users to other servers.
Default: 2,500
Farm Capacity Threshold
Maximum number of connections that farm's local servers may accept. When this threshold is reached, LRP reports from the farm inform you that no more redirects can be accepted from distributed AppDirectors.
Default: 5,000
Parameter
Description
AppDirector User Guide
Configuring Global Load Balancing
350 Document ID: RDWR-AD-V0231-UG1105
4.Click Set. The Redirection Table Update window closes and the new parameters appear in the Redirection Table window.
Anycast Advertise Anycast is the process that allows a single IP address to be announced from multiple locations. It’s a simulation of a situation where a routing domain may have multiple routes that lead to a certain destination. Such an application is useful if a service is required globally, and there are multiple service points that should be totally transparent to the user.
Once a packet has the Anycast address as a destination, the routing domain will control the flow of that packet towards one of the destinations.
A global system may use the Anycast to announce multiple service points. There are two types of Anycast service:
• Global Anycast: The global Anycast addresses are equally announced from multiple locations allowing users to connect to these points concurrently. The routing logic creates the load distribution between the different service points. This type of Anycast is suitable for stateless applications only, such as DNS. This type of Anycast can be used to select the DNS resolver in a global solution. • Local Anycast: The local Anycast addresses are not concurrently active in more than a single primary site. Secondary sites use these addresses only to provide a transparent backup to the primary site. For the routing logic there should be a single location that serves each IP address. This type of Anycast is suitable for all protocols – as long as the primary site is active persistency is maintained. Note:Anycast currently only supports IPv4 format IP addresses.
Static Proximity Entries
Number of entries in Static Proximity Table. If you configure more entries than memory allows, AppDirector prints a message to the terminal and writes it to the log file. User defined Static Proximity table displays proximity subnets per farm. Each table row displays the accompanying farm and a range of IP addresses. Values: 1 - 5000
Default: 500 Application Redirection Mode
Defines whether DNS redirection is:
• only redirection method for this farm
• primary method: backup redirection methods can be configured where the application request (after DNS resolution) reaches a site where there are no servers available
• one of the farm redirection methods. The following values are available:
• Disabled (Default): Farm can only use DNS redirection. • Enabled: Application redirection is performed using redirection methods enabled for this farm. • DNS Fallback Redirection: Application redirection is used only if DNS Redirection is enabled and availability problems exist. The method used depends on methods enabled for this farm. Parameter
Description
AppDirector User Guide
Configuring Global Load Balancing
Document ID: RDWR-AD-V0231-UG1105 351
To create an entry in the Anycast Advertise Table 1.From the AppDirector menu, select Distributed System > Anycast Advertise Table. The Anycast Advertise Table window is displayed.
2.Click Create. The Anycast Advertise Table Create window is displayed.
3.Set the parameters
4.Click Set. Your configuration is set.
Parameter
Description
Layer 4 Policy Name Name that provides AppDirector with information on the IP that must be advertised (Layer 4 Policy VIP).
The value that is displayed in this field depends on the type of the Layer 4 policy, whether this is a Virtual IP Interface (VIPI) or not and if not what is the farm on whose status the advertisement depends: Note: The advertisement does not depend on farm status (it depends on device status up/down)
Host Route Metric VIP Advertisement via Dynamic Routing is used to advertise a Farm's VIP or any other configured IP address via RIP or OSPF. You can configure the route metric to be used when adding the route to the routing table. This can be used when two devices are used on different sites for site redundancy. When the main site is available, the device adds the VIP to the routing table with the configured metric, then removes the entry from the routing table when the servers are unavailable. When the farms in both sites are available, clients are routed to the selected device based on the route metric. Enter the required metric value.
Default: 1
Advertised VIP Farm Name
Name of farm on whose availability this advertisement is made. Layer 4 Policy VIP is only advertised if this farm is available. If Layer 4 policy Application is set to Virtual IP Interface, this field is obsolete.
External NAT Address
If AppDirector is installed behind a NAT device, the advertised IP must be not the VIP, but rather its public (NAT) address. When a NAT address is defined in the relevant entry, AppDirector responds with the External NAT IP Address.
AppDirector User Guide
Configuring Global Load Balancing
352 Document ID: RDWR-AD-V0231-UG1105
AppDirector User Guide
Configuring Health Monitoring
Document ID: RDWR-AD-V0231-UG1105 353
Chapter 5 – Configuring Health Monitoring
This chapter describes the Health Monitoring module, a component of the Radware APSolute OS architecture and includes the following sections:
• Health Checks, page 355
• AppDirector Farm Connectivity Checks, page 370
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. It determines which network elements are available for service, enabling the IAS 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 AppDirector 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.
Health Monitoring Workflow
1.Set Health monitoring >Global Parameters >Health Monitoring Status - to Enable.
2.Set Health monitoring >Global Parameters > Response Level Samples - to non zero value.
3.Create Health Monitoring > Check Table and set Measure Response Time - to Enable for All servers in the farm.
4.Create Health Monitoring > Binding Table for All servers in the farm. Checked Element
A Checked Element is a network element that is managed and load balanced by the AppDirector. 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 does not load balance. For example, the health of a server managed by AppDirector may depend on the health of a database server, or other application servers, which are not load balanced by the AppDirector, or the health of a Next Hop Router managed by LinkProof may depend on the availability of the service provider. Health Check
A Health Check defines how to test the health of any network element (not necessarily a Checked Element). A check configuration includes such parameters as the Check Method, the TCP/UDP port to which the test is sent, the time interval for the test, its timeout, the number of retries, and more. These parameters are explained in detail in the Health Checks
section. A network element can be tested using one or more Health Checks. AppDirector User Guide
Configuring Health Monitoring
354 Document ID: RDWR-AD-V0231-UG1105
Health Monitoring Global Parameters The Health Monitoring module enables extensive health monitoring of all network devices, for example, server farms. The module enables the AppDirector to optimize load balancing by making sure which network elements are available and active. The Health Monitoring menu's Global Parameters window allows you to configure the Health Monitoring mode.
To configure Health Monitoring Global Parameters 1.From the Health Monitoring menu select Global Parameters. The Health Monitoring Global Parameters window is displayed.
2.Set the parameters.
3.Click Set. Your configuration is set.
Note:SSL certificate file and SSL private keys are not exported as part of the AppDirector configuration export.
Parameter
Description
Health Monitoring Determines whether to use the Health Monitoring module or the AppDirector's connectivity checks.
Default: Disabled.
Response Level Samples
Number of Response Level samples serving as basis for calculating average Response Level. AppDirector keeps a Response Level indicator for each check. This is the average ratio between response time and configured Timeout. Default: 0 Notes:
• A value of 0 disables this parameter and no sample is taken.
• Any other value between 1 - 9 defines the number of samples.
SSL Certificate Entry Name
This is used by the AppDirector when the Web server requires a client certificate during the SSL handshake. Default: Client certificate generated by the AppDirector.
AppDirector User Guide
Configuring Health Monitoring
Document ID: RDWR-AD-V0231-UG1105 355
Health Checks
This section discusses Health Checks and contains the following topics:
• Group Health Checks, page 355
• Single Health Checks, page 355
• Health Monitoring Check Table, page 355
• Binding, page 364
• Packet Sequence Table, page 365
• Server Table, page 366
• Diameter Argument List and Additional Method Arguments, page 367
• Uploading, Downloading and Deleting the Diameter File using Binary File Transfer, page 369
• User Defined Methods, page 369
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 AppDirector sends notification messages (SNMP Traps, Syslog messages or mail messages), indicating the failure of the check.
Quantity of Health Checks
There is no radware recommended number of heath checks as this depends on many variables. For example:
• Frequency of checks (interval)
• Timeout for each check
• Load on the AppDirector (without Health Monitoring running)
• Other generic applications configured to run
For example, having 5000 checks with a large interval of two days could perform better than 200 checks with in interval of 2 seconds.
Group Health Checks
Using group health checks enables the creation of complex health conditions for the Checked Elements. For instance, consider a Web server that communicates with one of two database servers and uses one of two routers to provide service. This Web server is bound using three different binding groups: one group contains Health Checks for the two routers (each check is 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. You can also configure groups of health checks. Health Check Binding can also be grouped for complex conditioning of tests, using the logical conditions AND/OR.
Single Health Checks
You can add or edit health check parameters in the Check Table. The Check Table lists the configured Health Checks. Health Monitoring Check Table
The Checks Table window contains user-configurable checks, based on the Health Check Methods.
AppDirector User Guide
Configuring Health Monitoring
356 Document ID: RDWR-AD-V0231-UG1105
To create/update an entry in the Checks Table
1.From the Health Monitoring menu select Checks Table. The Health Monitoring Check Table window is displayed.
2.Click Create/Update. The Checks Table Create/Update window is displayed.
3.Set the parameters.
Parameter
Description
Check Name Connectivity check's health check name.
Check IP Version IPv4 or IPv6
Method See Table 4 - Predefined Health Check Methods, page 357
.
Destination Host (Mandatory) Destination IP address or hostname of network server to be checked. The destination host can also accept hostnames and not only ip addresses.
Next Hop Address IP address of the next hop on the network for this check. This is needed to direct the health check session to a network element's MAC address.
Destination Port The destination's TCP\UDP port number.
Arguments: The additional argument for the relevant health check method. Possible arguments are based on the Method, and may be one, or a combination of, the following:
The arguments are entered in the following format: Argument1=value1| Argument2=Value2. For example, the following is an argument for a FTP check: USER=JohnSmith| PASS=ABC
Arguments Depending on the Check Method that you select, a separate Arguments window is displayed listing the associated arguments for this method.
Enter name of your argument and click Set. The argument is set for the Health Check Method and you are returned to the Health Monitoring Check Table window.
Interval This interval defines the health check’s execution interval in seconds. This field accepts only integers, and its value must be greater than the timeout value. Maximum value: 2^32-1 seconds.
Retries Number of times that a health check must fail before the Health Monitoring module reevaluates the element’s availability status. Note: This field accepts only integers.
Timeout Maximum number of seconds that the AppDirector waits for response to the Health Check. This field accepts only integers. Maximum value: 2^32-2 seconds. No New Session Timeout Amount of time to pass, since initiating a check, until AppDirector recognizes this element as heavily loaded and does not send any new sessions to it. AppDirector User Guide
Configuring Health Monitoring
Document ID: RDWR-AD-V0231-UG1105 357
Table 4 on page 357 describes the predefined Health Check Methods with the configurable parameters.
4.Click Set. Your configuration is set.
This table lists the additional configurable method arguments for each Check Method, and details mandatory arguments, default values, and more.
Table 4: Predefined Health Check Methods
Measure Response Time Determines whether the response time of the check is being used for load balancing decisions. Applicable only when Dispatch Method is set to Response Time LB. The Response Time is measured in milliseconds.
Default: Disabled
Also see Dispatch Methods, page 193
.
Note: There are several parameters that must be configured in health monitoring, for the Response Time Dispatch method or all traffic will be directed only to first server.
1. Configure Health monitoring -->Global Parameters -->Health Monitoring Status - to Enable
2. Configure Health monitoring -->Global Parameters --> Response Level Samples - to non zero value
3. Create Health Monitoring --> Check Table and configure Measure Response Time - to Enable for All servers in
the farm
4. Create Health Monitoring --> Binding Table for All servers in the farm Reverse Check Result Indicates whether the check fails when reply is received according to the check arguments or the check passes when no reply received. Default: Disable (the check fails when the server does not reply).
Update Mode Only
Uptime % Connectivity check's health check uptime percentage
Default: 0%
Success Counter Connectivity check's health check success count
Default: 0 Failure Counter Connectivity check's checked element failure count.
Default: 0
Average Duration Connectivity check's health check average duration.
Default: 0 seconds
Method Name (and ID)
Argument Name
Argument Description
Mandatory
Additional Info
Default
ARP No arguments
Citrix Application 1 Application 2 Application 3 Application 4 for Application browsing
No
Parameter
Description
AppDirector User Guide
Configuring Health Monitoring
358 Document ID: RDWR-AD-V0231-UG1105
Citrix ICA No arguments
DHCP IP Address
Subnet Mask 255.255.255.255
Default Gateway
DNS Server
WINS Server
Domain
MAC Address
Relay Agent
DHCPv6 Interface ID
IP Address
Prefix Length
DNS Server
Domain
Diameter Diameter Argument List Name
DNS Hostname Host name to query.Yes
Host Address Address to be received.
No Validate only the DNS return code.
FIX TESTREQID
SENDERCOMP
ID
TARGETCOMPI
D
FIX Version
FTP Username Username.Yes
Password Password.Yes
Filename The file to search on the FTP server.
No
Method Name (and ID)
Argument Name
Argument Description
Mandatory
Additional Info
Default
AppDirector User Guide
Configuring Health Monitoring
Document ID: RDWR-AD-V0231-UG1105 359
HTTP Path Path of file on Web server to be requested.
No Any configured value must begin with a/.
/
Hostname Host name.No
HTTP Method HTTP method to submit.
No • GET, • POST
• HEAD
GET
Proxy HTTP Use proxy HTTP.No • Yes = Use proxy HTTP, • No = Use Web server HTTP.
No
Pragma Nocache
Use pragma: no-
cache.
No • Yes= Use pragma: no-
cache, • N0=Do not use pragma: no-cache.
No
Authentication Type
Authentication Type No Basic, NTLM BASIC
Username Username for basic authentication.
No
Password Password for basic authentication.
No
Match Search string
Content match pattern is either present or absent.
No • Yes =Fail check if pattern not found
• No =Fail check if pattern is found.
Yes
Match Mode Pattern for content match.
No • String exists
• String is absent
Wildcards not supported.
HTTP Return Code
Valid http code 1 No
HTTP Return Code
Valid http code 2 No
HTTP HTTP Return Code
Valid http code 3 No
HTTP Return Code
Valid http code 4 No
Method Name (and ID)
Argument Name
Argument Description
Mandatory
Additional Info
Default
AppDirector User Guide
Configuring Health Monitoring
360 Document ID: RDWR-AD-V0231-UG1105
HTTPS HTTPS Method HTTPS method to submit.
No • GET, • POST
• HEAD
GET
Username Username for basic authentication.
No
Password Password for basic authentication.
No
Match Search string
Content match pattern is either present or absent.
No • Yes =Fail check if pattern not found
• No =Fail check if pattern is found.
Yes
Match Mode Pattern for content match.
No • String exists
• String is absent
Wildcards not supported.
HTTPS Return Code
Valid https code 1 No
HTTPS Return Code
Valid https code 2 No
HTTPS Return Code
Valid https code 3 No
HTTPS Return Code
Valid https code 4 No
IMAP4 Username Username Yes
Password Password Yes
Method Name (and ID)
Argument Name
Argument Description
Mandatory
Additional Info
Default
AppDirector User Guide
Configuring Health Monitoring
Document ID: RDWR-AD-V0231-UG1105 361
LDAP Username Username
Password Password Base Object Location in directory from which the search starts. No If you configure Base, then Attribute is mandatory.
Attribute name
The attribute to look for. For example, CN - Common Name.
Search value The value to search No
Search Scope • baseObject
• singleLevel
• wholeSubtree
Search Deref Aliases
• neverDerefAliases
• dereflnSearching
• derefFindingBaseOb
j
• derefAlways LDAPS Username Username
Password Password Base Object Location in directory from which the search starts. No If you configure Base, then Attribute is mandatory.
Attribute name
The attribute to look for. For example, CN - Common Name.
Search value The value to search No
Search Scope • baseObject
• singleLevel
• wholeSubtree
Search Deref Aliases
• neverDerefAliases
• dereflnSearching
• derefFindingBaseOb
j
• derefAlways Neighbor Discovery
No arguments
NNTP No arguments
Physical Port
Port Number Physical port number.Yes
Method Name (and ID)
Argument Name
Argument Description
Mandatory
Additional Info
Default
AppDirector User Guide
Configuring Health Monitoring
362 Document ID: RDWR-AD-V0231-UG1105
PING Fail Check fails when reply is received or not received.
No Yes = Fail when server replies,
No =Fail when server does not reply.
No
Ping Data Size Packet size No =1 - 1024 bytes
POP Username Username Yes
Password Password No
Radius Accounting
Username Username Yes
Password Password Yes
Secret Radius Secret No
Radius Authenticatio
n
Username Username Yes
Password Password Yes
Secret Radius Secret No
RTSP Hostname Host name to use in request.
No IP address of server.
Path Path of file on RTSP server to be requested.
Yes
SIP TCP Request URI
From
Max Forward
Match search string
Match mode SIP return code SIP return code SIP return code SIP return code Method Name (and ID)
Argument Name
Argument Description
Mandatory
Additional Info
Default
AppDirector User Guide
Configuring Health Monitoring
Document ID: RDWR-AD-V0231-UG1105 363
SIP UDP Request URI
From
Max Forward
Match search string
Match mode SIP return code SIP return code SIP return code SIP return code SMTP HELO At the start of all SMTP transactions, the calling machine identifies itself, literally by saying "HELO" with its computer name.
SNMP OID Object ID to be used by the check.
Yes
Community Community used by the AppDirector.
Yes
Min. value Minimum value for check to pass. If the minimum is lower than the configured value, the check fails.
Yes
Max value Maximum value for check to pass. If the maximum is higher than the configured value, the check fails.
Yes
No New Sessions value
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
Use Results For Load Balancing
Measured response time for the check.
Yes No No
Method Name (and ID)
Argument Name
Argument Description
Mandatory
Additional Info
Default
AppDirector User Guide
Configuring Health Monitoring
364 Document ID: RDWR-AD-V0231-UG1105
Binding
Using the health checks, you can associate, or bind, a health check with a checked element. You can also define whether the check is mandatory and set the group number. When several groups are associated with a single Checked Element, they are evaluated with a logical AND between them. Non-Mandatory checks in a group are evaluated with a logical OR between them, so that when there is more than one Non-Mandatory check in a group, a failure of one check does not fail the server. To bind a health check to a network element 1.From the Health Monitoring menu, select Binding Table. The Health Monitoring Binding Table window is displayed.
2.Click Create. The Health Monitoring Binding Table Create window is displayed.
3.Set the parameters.
SSL Hello SSL Version v2.3 or v3.0. SSL v3.0 indicates that pure SSLv3 is used.
SSLv2.3 indicates 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 v2.3
TCP Port (1) Complete TCP Handshake
Sets whether check sends ACK packet before the RST packet.
No Yes
Complete with FIN
When enabled, the AppDirector ends the TCP check with a FIN Packet.
Yes
TCP User-
Defined (8)
Sequence ID Packet sequence to submit.
Yes
TFTP File Full Path
UDP Port (9) No arguments
UDP User Defined
Sequence ID Packet sequence to submit.
Yes
Parameter
Description
Check Name of the health check as defined by the user in the Checks Table.
Server/NHR/Report/ The Health Monitoring module binds health checks to NHRs/Servers/
LRP and PRP reports, which determine the availability of those elements. Select the type of report/server/NHR to perform health monitoring checks.
Method Name (and ID)
Argument Name
Argument Description
Mandatory
Additional Info
Default
AppDirector User Guide
Configuring Health Monitoring
Document ID: RDWR-AD-V0231-UG1105 365
4.Click Set. The specified health check is bound to the selected element.
Packet Sequence Table
The Packet Sequence Table window enables the user to define a packet sequence for a specific, TCP\UDP, health check. The user defines a sequence of Send and Receive packets, containing a configurable string. AppDirector then transmits the Send packets and verifies that the string in the reply matches the string configured for the Receive packets.
Notes:
>> In order to define a packet, you need to add 0x before the packet itself; for example: 0x00016e69722e747874006f6374657400
>> In a regular expression, a hex string cannot be used.
To create a packet sequence 1.From the Health Monitoring menu, select Packet Sequence Table. The Health Monitoring Packet Sequence Table window is displayed.
2.Click Create. The Health Monitoring Packet Sequence Table Create window is displayed.
Group Group number to which check belongs. • allows you to combine different health checks with the same checked element.
• uses logical AND/OR depending on the Mandatory field. • Group number is only relevant for a given specific checked element.
Mandatory Defines if Health Check is mandatory for Checked Element’s health. The Non- Mandatory status for checks within a group is equal to an OR relationship between the Health Checks, while the Mandatory status is equal to an AND condition.
Values: Mandatory (Default), Non-Mandatory.
Note: When mixing Mandatory and Non-mandatory health check bindings, there is a logical AND between the Mandatory & Non-Mandatory groups. This means that if a Non-Mandatory health check binding fails a certain element, even if all Mandatory bindings pass, the element will be reported as Unavailable (Not In Service).
Parameter
Description
AppDirector User Guide
Configuring Health Monitoring
366 Document ID: RDWR-AD-V0231-UG1105
3.Set the parameters.
4.Click Set. Your configuration is set.
Server Table
This table is a read-only table and displays each server configured for the AppDirector, in the Application Server Table, and its status.
To access the Server Table 1.From the Health Monitoring menu, select Server Table. The Health Monitoring Server Table window is displayed.
2.Select the desired server, and the HM Server Table View Details window is displayed.
3.View these read-only parameters:
Parameter
Description
Seq ID (Sequence ID)
ID number of entire packet sequence. Each sequence defines a new user-
defined check. All packets with same Sequence ID belong to same check. Default: 0
PKT ID (Packet ID) ID number of the specific packet within the sequence.
Default: 0
Note: The first Packet ID of each sequence must always be 0. Packet ID numbers of a sequence must be consecutive.
Type Type of packet.
Values: Send/Transmit (Default), or Receive.
String Content of packet for verification process. This is the string that is either sent within the packet or the string to match when the packet is received. For Receive type packets, it can include a regular expression.
Description Description of the specific packet in the sequence.
Compare Method Used for comparing between content of received packet and content configured in the String parameter. The following possibilities are available:
• Regular Expression (Default): String that matches a regular expression rule.
• Binary: The exact String that is matched when the packet is received.
Parameter
Description
Server Index number of the element attached by the AppDirector in the Application Server Table
Description Description of the network server, for example, Cache.
Farm Name Name of the farm in which the server is included.
Availability Status Availability status of the element, Available or Unavailable. Inet Address IP address of the network server.
Inet Address Type IPv4 or IPv6.
AppDirector User Guide
Configuring Health Monitoring
Document ID: RDWR-AD-V0231-UG1105 367
Diameter Argument List and Additional Method Arguments
You can configure additional arguments specific to each Health Check Method.
When using Web Based Management, CLI, Telnet or SSH, you can configure the additional arguments using a string with this format:
ARG=VAL|ARG=VAL|.
Following each argument, the equal sign is displayed, then the required value. A “|” sign is used as a delimiter between the arguments. No extra spaces are allowed.
The Diameter Argument Lists Configuration window allows you to configure additional arguments specific to each Health Check Method.
To set the parameters of the Diameter Argument List 1.From the Health Monitoring window, select Diameter > Arguments List. The Diameter Argument Lists Configuration window is displayed.
2.Click Create. The Diameter Argument Lists Configuration Create window is displayed.
3.Set the parameters.
Response Level Response Level is a normalized grade, given to the check, based on the response times of each successful check over the configured Response Level Sample rate and the configured timeout. Uptime% Ratio (in presents) of the number of the success checks and the total number of checks (successful and failures). Success Counter Total number of successful checks. Failure Counter Total number of unsuccessful checks.
Parameter
Description
Argument List Name
The name that you define for this Argument List.
Description The user defined description of this argument list. Binary File Provided Defines whether a user-defined message has been provided.
Values: Yes/No/Not Applicable
Origin-Host Host name FQDN that identifies the end point that created the Diameter message and is present in all Diameter messages.
Note: The Origin-Host AVP may resolve to more than one address.
Origin-Realm Contains the realm of the originator of the Diameter message and is present in all Diameter messages.
Vendor ID Value assigned to vendor of Diameter application by IANA. Default is the value identifying 3GPP.
Product-Name assigned name for the product.
Parameter
Description
AppDirector User Guide
Configuring Health Monitoring
368 Document ID: RDWR-AD-V0231-UG1105
4.Click Set. Your configuration is set.
Application Message Type
Defines the application message that is sent after the Diameter connection is established. Values:
Binary File: Associate a binary file as the Diameter data for the health check packet. The maximum size for the binary file is 1K.
None: No application message is sent.
Auth-Application-Id The Auth-Application-Id AVP (AVP Code 258) is used to advertise support of the Authentication and Authorization portion of an application.
Auth-Session-State Specifies which state is maintained for a particular session. The following values are supported:
• State Maintained (0) (default): Used to specify that a session state is being maintained, and the access device must issue a session termination message when service to the user is terminated. • No State Maintained (1): Used to specify that no session termination messages is sent by the access device upon expiration of the Authorization-Lifetime.
Destination-Realm Contains realm (FQDN) to which message is routed.
Destination-Host Host name of the destination Diameter server. Absence of the Destination-Host AVP causes a message to be sent to any Diameter server supporting the application within the realm specified in Destination- Realm AVP. When no value is specified, this AVP is not used. When set to 0.0.0.0 the value is taken from the Checked Element IP.
Public Identity Public identity of user referred to in LIR request.
Disconnect Cause A Diameter node must include this AVP in the Disconnect-Peer-Request message to inform the peer of the reason for its intention to shutdown the transport connection. The following values are supported:
• Rebooting (): A scheduled reboot is imminent.
•: The peers internal resources are constrained, and it has determined that the transport connection needs to be closed.
• Do Not Want to Talk to You: The peer has decided to terminate the transport connection since it does not expect any messages to be exchanged in the near future.
Accepted Result Codes
List of acceptable codes that can be received in a CEA, DPA and LIA messages. These codes are separated by commas (,)or semi colons (;). The default is 2001, 2002, 2003, 2004, 2005.
• Diameter First Registration (2001)
• Diameter Subsequent Registration (2002)
• Diameter Unregistered Service (2003)
• Diameter Success Server Name Not Served (2004)
• Diameter Server Selection (2005)
Parameter
Description
AppDirector User Guide
Configuring Health Monitoring
Document ID: RDWR-AD-V0231-UG1105 369
Uploading, Downloading and Deleting the Diameter File using Binary File Transfer
Binary File Transfer involves sending a file from one location to another in which all eight bits of the byte are transmitted either intact or via some encoding scheme. The Diameter Binary File Transfer window allows you to upload or download the diameter file to the AppDirector.
To upload the diameter file 1.From the Health Monitoring menu, select Diameter > Binary File Transfer. The Diameter Binary File Transfer window is displayed.
2.Browse to find the diameter file Or, Choose a diameter file from the Diameter Argument List Name dropdown list.
3.Set the parameters.
4.Click Set. Your configuration is set.
To download the diameter file 1.From the Health Monitoring menu, select Diameter > Binary File Transfer. The Diameter Binary File Transfer window is displayed.
2.To download from the Download Diameter File option, select the Diameter Argument List Name from a drop-down list. 3.Click Set. The file is downloaded.
Deleting the Diameter File
The Diameter Binary File Transfer window also allows you to delete the diameter file.
To delete the diameter file 1.From the Health Monitoring menu, select Diameter > Binary File Transfer. The Diameter Binary File Transfer window is displayed.
2.To delete from the Delete Diameter File option, select the Diameter Argument List Name from a drop-down list. 3.Click Set. The file is deleted.
User Defined Methods
If you require a specific Health Check Method not provided by the module, you can configure the Health Check protocol manually by defining a stream of send and receive packets for every packet sequence, each with a string to send or receive. The module sends the packets, and verifies that the received packets contain the predefined string. Packet sequences are defined in the Packet Sequence Table. Once defined, the check can be used in Health Check configurations. User-defined Checks are available for TCP checks only.
AppDirector User Guide
Configuring Health Monitoring
370 Document ID: RDWR-AD-V0231-UG1105
AppDirector Farm Connectivity Checks
This section describes additional options for server monitoring included in the Farm configuration process and includes the following topics:
• Ping Connectivity Method, page 370
• TCP Port Connectivity Method, page 371
• UDP Port Connectivity Method, page 372
• HTTP Page Connectivity Method, page 372
• Disabled Connectivity Method, page 373
To load balance traffic reaching an AppDirector farm, the farm servers must be checked. AppDirector periodically checks server health. A successful check shows that the service is available on the server. Failure to connect causes AppDirector to term the server unavailable although AppDirector continues to check its availability and generates a Syslog, E-mail, SNMP or CLI trap to indicate that the server is "Not In Service." AppDirector also monitors the server status in its farms ensuring that they are available and can handle the request. You can perform a Health Check of the servers using these methods:
• Basic: Farm Connectivity Check.
• Advanced: Health Monitoring module.
Notes:
>> You can use either Connectivity Checks or Health Monitoring Checks with Farms regardless of the Health Monitoring Status. However, when both are used, one will override the other, which means that if a Connectivity Check is set, it will override a Health Monitoring Report. >> If there is a need for a large number of concurrent checks, Radware recommends using Health Monitoring instead of Connectivity checks.
This table describes parameters to configure the Connectivity Methods.
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.
Parameter
Description
Connectivity Check Port Specific port where to conduct connectivity check. It can be TCP or UDP, depending on Connectivity Method selected. Note: When the Connectivity Method is HTTP Page, a TCP port is checked.
Values: FTP, HTTP (default), SMTP, DNS, NNTP, HTTPS, RTSP, RADIUS_1645, RADIUS_1812, or any port number you enter manually. For example, HTTP automatically checks port 80. Connectivity Interval How often AppDirector polls the servers (secs). Default: 10
Connectivity Retries Number of polling attempts made before server is deemed inactive. Default: 5
AppDirector User Guide
Configuring Health Monitoring
Document ID: RDWR-AD-V0231-UG1105 371
TCP Port Connectivity Method
When this method is selected, AppDirector attempts to connect to the specified application port by completing the TCP three-way handshake, which includes the following steps:
1.AppDirector initiates a request by sending a SYN packet. 2.The server sends a SYN-ACK packet back to AppDirector. 3.AppDirector sends a FIN-ACK packet to the server, completing the TCP 3 way handshake and requesting to terminate the connection.
4.The server replies with an ACK packet followed by a FIN-ACK packet.
5.To close the connection, AppDirector sends an ACK packet to the server.
When connection between a server and AppDirector cannot be established, AppDirector automatically sends connectivity checks every 3.5 seconds, regardless of Connectivity Interval value. You can configure the Timeout for connectivity checks by setting the Timeout After TCP Failure parameter. When this is enabled, AppDirector sends connectivity checks according to the Connectivity Interval parameters in the farm configuration. Note:Configurations established in the Advanced Settings window apply to all AppDirector farms that use the TCP Port connectivity check method. 6.To enable the user-defined timeout for the connectivity check specified in the Connectivity Interval parameter (even after a TCP check failure), select Timeout After TCP Failure. AppDirector User Guide
Configuring Health Monitoring
372 Document ID: RDWR-AD-V0231-UG1105
UDP Port Connectivity Method
When UDP Port Connectivity Method is selected, AppDirector attempts to connect to the specified application port, according to the UDP protocol. If the predefined port is not available, AppDirector receives a message “Destination Unreachable.” If the port is available, no answer is sent. It is impossible to know whether the answer was not sent because the server is available, or because the host computer is not working and is unable to send a response of any kind. To get a clear indication as to whether the server is available or not, AppDirector pings the server when no answer is received.
Note:A server is active only when no answer is received from the server during attempts to connect using the UDP protocol, AND AppDirector receives a successful ping reply.
HTTP Page Connectivity Method
For HTTP Page checking, AppDirector periodically performs HTTP GETs for a predefined URL. If the requested Web page is unavailable, the server is considered down. The URL is defined in the Home Page parameters. You can define a Home Page URL that is up to 80 characters long.
The Retrieval Frequency saves unnecessary Web page requests by performing only periodical Web page retrieval. The Web page is requested only once in a number of requests, according to the predefined Retrieval Frequency. Otherwise, a simple TCP check occurs on port 80, or a user-defined port. AppDirector examines the HTTP header of the server response and considers responses with the user-defined HTTP status code to indicate a healthy server. You can configure HTTP status codes to be used as acceptable responses. By default, an HTTP code of 200 indicates that the service is available.
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 (for example, 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 server’s IP address. You can change the Host name used in the HTTP request to the AppDirector farm name, using the Extended Check Host Mode parameters.
Long URL Checks
When using the HTTP Farm Connectivity Check, URLs of more than 80 characters can be configured. The Long Extended Check URL window allows you to enter and view Long URLs for an HTTP Farm Connectivity Check. When using Configuration Download from the AppDirector, this configuration is not sent as part of the configuration file. However, this configuration is saved in the compact flash and is not erased when the AppDirector is reset
AppDirector User Guide
Configuring Health Monitoring
Document ID: RDWR-AD-V0231-UG1105 373
To enter a Long URL for an HTTP Farm Connectivity Check 1.From the AppDirector menu, select Farms > Long URL Check. The Long Extended Check URL window is displayed.
2.Set the parameters.
3.Click Set. Your configuration is set.
To view a Long URL for a specific HTTP Farm Connectivity Check
1.From the Long Extended Check URL window, select the required farm.
2.Click Get. The URL is displayed and can be edited.
Response Threshold
Using Farm connectivity checks with HTTP Page check, the Response Threshold parameter defines the number of milliseconds the server has to reply to the GET command. When the server's reply takes longer, the status of the logical server is set to “No New Sessions.” The default is 0.
Disabled Connectivity Method
Connectivity checking is disabled. If no farm connectivity checks are performed, AppDirector considers all servers to be available by default. If farm connectivity checks were performed and then the Connectivity Method becomes disabled, the status of the servers remains the same as it was the moment the checks were disabled. If connectivity checks are disabled, and a server renews its activity after a failure, this server is still regarded by the AppDirector as not available.
Parameter
Description
Farm Name of the required farm.
Long Extended Check URL URL of more than 80 characters to be checked. AppDirector User Guide
Configuring Health Monitoring
374 Document ID: RDWR-AD-V0231-UG1105
AppDirector User Guide
Classes and Bandwidth Management
Document ID: RDWR-AD-V0231-UG1105 375
Chapter 6 – Classes and Bandwidth Management
This describes Classes and Bandwidth Management and includes these sections:
• Bandwidth Management and Classifier Settings
, page 378
• Configuring Bandwidth Managemen
t
, page 379
• Services
, page 394
Bandwidth management, in general, is a simple concept. The idea is to be able to differentiate orclassify user traffic according to a wide array of criteria and then assign various priorities to eachclassified packet or session. For example, bandwidth management allows an administrator to give HTTP traffic a higher priority over SMTP traffic, which in turn may have higher priority overFTP traffic. A bandwidth management solution can also track the bandwidthused by each application and set limits as to how much each classified traffic pattern can utilize. There are a variety of methods used to enforce the bandwidth management policies configured by an administrator. The simplest method would be to discard packets when certain thresholds are reached or when certain pre-
allocated session buffers are overflowing. More complex mechanisms include TCP rate shaping and priority based queuing.
TCP rate shaping uses the inherent flow control mechanisms of the TCP protocol. By adjusting parameters in the packets’ TCP headers, a bandwidth management solution can signal the end nodes to throttle the rate at which to transmit packets. Needless to say, the mechanism only works with TCP sessions. TCP rate shaping also has some uncertainties associated with it, as the amount of bandwidth associated with sessions can rarely be exactly enforced. Rate shaping also does not work well with protocols that use short lived sessions (such as HTTP), since such sessions usually end before the bandwidth manager has decided how to shape the rate of the session.
Priority based queuing is a means by which all classified packets are placed in packet queues,each with its own preset priority. A number of queues are available and when it comes to traffic forwarding, packets are forwarded from the higher priority queues first. This is an oversimplified version of what really happens, but it presents the general concept. Various algorithms and safety measures should be deployed to ensure methodical packet forwarding and protection against “starvation”, where lower priority packets wait in queues for intolerably long amounts of time. Radware’s bandwidth management solution uses priority queues as the fundamental framework behind its operation. Radware Implementation of Bandwidth Management
Although the general concept of bandwidth management is simple, the complexity lies within the implementation and the intricacies. The following diagram describes the general components and tasks that make up Radware’s bandwidth management mechanism.
AppDirector User Guide
Classes and Bandwidth Management
376 Document ID: RDWR-AD-V0231-UG1105
Figure 14: Radware’s Implementation of Bandwidth Management
The Bandwidth Management module includes a feature set that allows you to have full control over the available bandwidth. Using these features, applications can be prioritized according to a wide array of criteria, while taking the bandwidth used by each application into account. For example, Bandwidth Management allows you to give HTTP traffic a higher priority than SMTP traffic, which in turn, may have higher priority than FTP traffic. The Bandwidth Management solution can also track the total bandwidth used by each application, ensuring a guaranteed bandwidth for certain applications and setting limits for each classified traffic pattern. AppDirector’s Bandwidth Management capability allows you to define policies that restrict or maintain the bandwidth that can be sent or received by each application, user, or segment. Controlling the maximal bandwidth of corporate resources that DoS attacks can consume limits the attack spread, ensuring that other mission critical operations continue to enjoy the bandwidth and service level required to guarantee smooth business operation. Carriers can also ensure that a customer's Service License Agreement (SLA) is not compromised due to a DoS attack launched by another customer. Using the Bandwidth Management module, Radware devices classify traffic according to pre-defined criteria and enforce a set of actions on that traffic. A comprehensive set of user-configurable policies controls how the device identifies and acts upon each packet. There are 4 major components in the system: the classifier, the queues, the scheduler and the Policy Database.
Classifier
The packet first flows into the system through the classifier. It’s the classifier’s duty to decide what to do with the packet. A very comprehensive set of user-configurable policies that make up the policy database control how the classifier identifies each packet and what it does with each packet. When the classifier sees the packet, it can do one of three things:
• Discards the packet - This allows the Bandwidth Management module to provide packet filtering. If configured, a reset packet is sent to the server and/or the client.
AppDirector User Guide
Classes and Bandwidth Management
Document ID: RDWR-AD-V0231-UG1105 377
• Forwards the packet in “real time” - This means the packet bypasses the entire bandwidth management system and is immediately forwarded by the device. The end result is effectively the same as if bandwidth management was not enabled. • Prioritizes the packet - This allows the device to prioritize services. How the classifier treats the packet is governed by the policy that best matches the packet. If the classifier prioritizes the packet it places it into a queue, which. then gets a priority from 0-7, with 0 being the highest priority and 7 the lowest. Each policy gets its own queue. So, the number of queues is equal to the number of policies in the policy database, but each queue is labeled with one of the 8 priorities 0- 7. This means that there could be 100 queues (if there are 100 policies), with each queue having a label from 0- 7.
Scheduler Algorithm
The scheduler takes packets from the queues and forwards them according to CBQ (Class Based Queuing) algorithm. With the CBQ 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 is also aware of a predefined bandwidth configured per policy. Each policy can be configured with a guaranteed bandwidth and a maximum bandwidth. Application Classification
The Application Classification parameter defines whether the device classifier when processing traffic for BWM will classify the traffic in Per Packet or Per Session mode. In Per Packet mode the device classifies every packet that flows through the device. In Per Session mode an intricate algorithm is used to classify all packets in a session until a best fit policy is found, fully matching the session. Once the session is fully classified, all packets that match that client table entry are processed according to the classification of the session.
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.
Bandwidth Borrowing
The scheduler can forward packets from queues, considering the maximum bandwidth configured by that queue’s policy. If borrowing is enabled and the scheduler visits a queue whose bandwidth has been exceeded (or is about to be exceeded), then the scheduler will see if any other policy has “left over” bandwidth. If such a policy is found, bandwidth is borrowed from that policy and allocated to the policy whose bandwidth limit was about to be violated. This allows a scheduling scheme where available bandwidth can be used from other queues, if the queue in question has exceeded its configured limit.
Maximum Bandwidth
Each policy in the policy database can be configured with its own maximum allowed bandwidth. Aside from per-policy configurations, the device can also be configured with a global bandwidth limit. This is the bandwidth limit for the entire device, regardless of individual policy configurations. AppDirector User Guide
Classes and Bandwidth Management
378 Document ID: RDWR-AD-V0231-UG1105
This limit is the sum of per-physical-port maximum bandwidth configuration. Each physical port for the device can be configured with its own maximum allotted bandwidth, the sum of which will make up the global device bandwidth limit. Note that if borrowing is enabled, bandwidth can not be borrowed beyond the configured maximum bandwidth.
Bandwidth Management and Classifier Settings
Bandwidth Management policy settings enable you to classify and manage traffic passing through the Radware device.
A policy is a set of conditions (classification criteria) and the actions that apply as a consequence of the conditions being satisfied. The policy database has two sections, active and inactive. The temporary, or inactive, policy database contains policies that can be altered and configured without affecting the current operation of the device. Changes to these policies are not effected until the inactive database is activated. Activation updates the active policy database, which sorts the packets that flow through it.
The second section of the Policy Database is the polices, by which the device classifies the traffic. To activate the inactive database, administrators need to manually update the policiy database.
When the classifier classifies the traffic it scans the entire policy database until there is a match between the packet/session to one of the policies. Once there is a match the classifier stops the scan. Hence it is important to set the order of the policy according to the volume of the traffic, and set the most common protocol first.
• Default Policy - The last policy in the policy database is the default policy. All traffic that is not matched by the user defined policy is matched by the default policy. By default, the default policy forward traffic is assigned a priority 4.
Bandwidth Management Classification Criteria
A policy has two main functions:
• To define how traffic should be classified to match the policy
• To define which action is to be applied on the classified traffic
A policy includes the following traffic classification criteria:
• Source: Defines the source of traffic. • Destination: Defines the destination of the traffic. • Direction: Defines traffic direction. • Service: Defines the traffic type. • VLAN Tag Group: VLAN ID tags. Bandwidth Management Rules
Once traffic is classified and matched to a policy, Bandwidth Management rules are applied to the policy. The following actions are available:
• Traffic prioritization
• Bandwidth limitation - guaranteed (minimum) and maximum allotted bandwidth
• Traffic flow limits - allows to set constraints for bandwidth used by each session or user as well as concurrent sessions per user.
• Marking each packet with a configured Differentiated Services Code Point (DSCP) or Diffserv. AppDirector User Guide
Classes and Bandwidth Management
Document ID: RDWR-AD-V0231-UG1105 379
Configuring Bandwidth Management
You can configure the bandwidth for your device according to your needs by using Radware's Quality of Service (QoS) tool. This enables you to classify user traffic according to a wide array of criteria, then traffic is handled according to the matching policy. A Bandwidth Management solution can also track the bandwidth used by each application and set limits as to how much bandwidth is used.
Note:The Bandwidth Management module is only available with a BWM license.
The BWM Global Parameters window specifies the BWM functionality of the device.
To configure Bandwidth Management 1.From the BWM menu, select Global Parameters. The Global Parameters window is displayed.
2.Set the parameters.
Parameter
Description
Classification Mode Values:
• Disable: No classification. The BWM management feature is disabled.
• Policies: The device classifies each packet by various policies configured by the user. The policies can use various parameters, such as source and destination IP addresses, application, and so on. If required, the DSCP field in the packets can be marked according to the policy the packet matches. • 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's value.
Note: After changing the Classification Mode, you must reset the device.
Application Classification
From the drop-down list, select whether classification is performed per session (Enable), or per packet (Disable).
There are two types of application classification:
• Per Packet: The 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.
BW per Traffic Flow Aging
Time, in seconds, a non-active traffic flow is kept in the flow table used by the Bandwidth Management module.
AppDirector User Guide
Classes and Bandwidth Management
380 Document ID: RDWR-AD-V0231-UG1105
3.Click Set. Your configuration is set.
Modify Policies
You can add, modify and delete policies in the Modify Policies Table window, according to your requirements. In addition, you can edit the default policy of the device. A default policy exists, which can be matched to any traffic that does not match a user-defined policy. You can change the action and the priority of the default policy only.
To create a new policy
1.From the BWM menu, select Modify Policies. The Modify Policies Table window is displayed.
2.Click Create. The Modify Policies Table Create window is displayed.
3.Set the parameters.
Max packets for Session Classification
When Application Classification mode is set to Per Session and one of the policies is configured to search for content, this parameter displays the maximum number of packets that the device searches through for the configured content.
If the device cannot find the content after searching the number of packets defined in the parameter, the device will stop searching. Values: 0 (Disabled - the device will search for the content in all the packets belonging to the session) - 100. Default:5
Parameter
Description
Name The user defined name of the policy. When hierarchical policies are defined the children policies must begin with the name of the parent policy, followed by a dot (‘.’) for example:
Parent, Parent.child1, Parent.childr2, Parent.child2.a, Parent.child2.b
Index The index number of the policy. Policies are searched by their index from the lower index to the higher index. 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.
Destination The destination address of the packet being matched by the policy. Note: The destination can be an IP address or a network class.
Source The source address of the packet being matched by the policy. The source can be an IP address or a network class.
Parameter
Description
AppDirector User Guide
Classes and Bandwidth Management
Document ID: RDWR-AD-V0231-UG1105 381
Direction The direction of the policy can be one of the following:
• OneWay: Setting the direction to OneWay enables asymmetric Bandwidth Management. When a policy is set to OneWay, the classifier searches for traffic in one direction only and the device classifies only one direction of the traffic; the return traffic is not classified.
• TwoWay: When a policy is set to TwoWay, the classifier searches for traffic in both directions and the device replaces the source and destination IP addresses and ports (in case the policy is a Layer 4 or Layer 7 Policy) of the return traffic.
• Session: — TCP/UDP traffic - Any session opened by user A (with source IP AIP and source port Aport) to user B (with destination IP BIP and destination port Bport) is allowed, as well as the reply traffic with source IP BIP, source port Bport to destination IP AIP, destination port Aport User B is not permitted to establish a new session with A. — Non TCP/UDP traffic - Any session opened by user A (with source IP AIP) to user B (with destination IP BIP) using a specific IP protocol is allowed, as well as the reply traffic with source IP BIP to destination IP AIP, as long as it uses the same IP protocol as the packet that opened the session from A to B. User B is not permitted to establish a new session with A.
Priority The priority attached to the packet by which it is forwarded is either Real-time or a value of 0-7, 7 being the lowest priority. Priority is only applicable if the action is forward.
Guaranteed Bandwidth
The reserved bandwidth for packets matching this policy. Note: A Child Policy cannot be configured with Maximum Bandwidth and Guaranteed Bandwidth higher than its Parent Policy, however, the sum of maximum bandwidth can be higher than the Parent Policy and the sum of all Guaranteed Bandwidth must be smaller or equal to the Guaranteed Bandwidth of the Parent Policy. Maximum Bandwidth The maximum amount of bandwidth that can be forwarded for traffic that matches this policy. The scheduler can borrow bandwidth from other queues, to forward packets from this policy queue that has exceeded, or are about to exceed, their allotted amount of bandwidth (guaranteed bandwidth) up to this Maximum Limit. If this value is set to 0 this policy is burstable up to the maximum available bandwidth with no limit. When hierarchical policies are configured, if one of the Children does not consume all of its allocated Bandwidth, another Child, belonging to the same Parent may use the spare bandwidth, which is limited by the Parent Maximum Bandwidth value. Note: A Child Policy cannot be configured with Maximum Bandwidth and Guaranteed Bandwidth higher than its Parent Policy, however, the sum of maximum bandwidth can be higher than the Parent Policy and the sum of all Guaranteed Bandwidth must be smaller or equal to the Guaranteed Bandwidth of the Parent Policy.
Service Type Type of service: None, Basic Filter, Advanced Filter or Filter Group.
Parameter
Description
AppDirector User Guide
Classes and Bandwidth Management
382 Document ID: RDWR-AD-V0231-UG1105
4.Click Set. Your preferences are recorded.
Modify Policy Extensions
In the Modify Policies Extensions window you can modify policy extensions according to your requirements.
To Modify Policies Extensions
1.From the BWM menu, select View Active > Modify > View Active Policy Extensions. The Active Policies Extensions window is displayed.
2.Set the parameters.
Service Name of the service required for this policy, based on the Service Type.
Operational Status Specifies the operational status of the policy, Active or Inactive. Note: If you select inactive, when policies are updated, this policy is not used to be matched against packets.
Inbound Physical Port Group
Enables you to set different policies for identical traffic classes that are received on different interfaces of the device. For example, you can allow HTTP access to the main server only to traffic entering the device via physical interface 3. This provides greater flexibility in configuration. The user should first configure Port Groups.
VLAN Tag Group Allows classification of different types of traffic classes based on the value of the VLAN Tag. When configured, only traffic with VLAN Tag which is part of the VLAN Tag group is classified.
Parameter
Description
Name The name of the policy (read-only).
Best Fit This flag allows to control classification precision versus performance.
When traffic is classified according to data in the TCP/UDP payload, even though a match is found for the first session packet, device will continue to look for a best match for subsequent packets.
The Best Fit flag allows to ask the device to stop the classification of the following packets, belonging to the same session once the first packet matched the policy and process the entire session according to the first matched policy - this obviously provides better performance.
When hierarchical policies are configured, if this flag is enabled on a Parent Policy, and a packet is matched on that policy, the device searches for best fit only among the Children Policies of that Parent Policy.
Note: Note: Best Fit is relevant only when the classification mode is “Per-Session”.
Values:
• False (default): Device does not try to find best fit policy for subsequent session packets
• True: Device will try to find best fit policy for subsequent policy packets.
Parameter
Description
AppDirector User Guide
Classes and Bandwidth Management
Document ID: RDWR-AD-V0231-UG1105 383
Activation Schedule The policy can be activated on a defined time by selecting here a pre-
defined Event Schedule (see Event Scheduler).
Inactivation Schedule The policy can be deactivated on a defined time by selecting here a pre-defined Event Schedule (see Event Scheduler).
Packet Marking Type Marks the packet with a range of bits displayed in the drop-down list.
Values:
• DSCP: Differentiated Services Code Point
• None (default): No marking
• ToS: Type of Service
Packet Marking Value The Packet Marking value. Values:
• None (default)
• For DCSP, a value between 0 – 63
• For ToS, a value between 0 – 7
Traffic Flow Identification
The type of traffic flow that this policy limits.
Values:
• None (default)
• Client—source IP
• Session—source IP and port
• Connection—source IP and destination IP
• FullL4Session—source and destination IP and port
• SessionCookie—must configure cookie identifier
• SipCallID—SIP Call ID
Traffic Flow Max BW (kbps)
The maximum bandwidth allowed per traffic flow.
Default: 0
Max Concurrent Sessions
The maximum number of concurrent sessions allowed for a client.
Default: 0
Note: This option is not available if the Traffic Flow Identifier is set to Session or FullL4Session.
Max HTTP Rqts Per Second
When the Traffic Flow Max BW parameter is configured, and the Traffic Flow Identification parameter is set to Session Cookie, the device can track and limit the number of requests, such as HTTP GET or Post or HEAD per Cookie.
Default: 0
Parameter
Description
AppDirector User Guide
Classes and Bandwidth Management
384 Document ID: RDWR-AD-V0231-UG1105
3.Click Set. Your preferences are recorded.
Modify Policy Trees The Policy Trees window allows the modification of hierarchies between bandwidth management policies. Using the Modify Policies Tree it is possible to change the hierarchies between policies by moving and copying parent and child policies.
To set the Action window parameters
1.From the BWM menu, select Modify Policies > Policy Trees. The Policy Trees window is displayed.
2.Set the parameters.
3.Click Set. Your preferences are recorded.
Viewing Active BWM Policies
You can view active policies, and configure new ones. The Bandwidth Management module uses a policy database. The policies in a database can be altered and configured without affecting the current operation of the device. As these policies are adjusted, the changes are not in effect unless the inactive database is activated. The activation updates the active policy database, which is what the classifier uses to sort through the packets that flow through it.
You can modify these policies according to your requirements at any given time. Cookie Field Identifier String that identifies the cookie field whose value must be used to determine the different traffic flows.
Classification Point Defines whether this policy should be matched to the original packet received, before processing, or matched to the modified packet. In AppDirector for example, client traffic is forwarded to the Layer 4 Policy VIP, but AppDirector makes a load balancing decision and forwards the packet to the selected server, requiring a change to the destination IP address for the server's real IP address.
The Values are:
• Before change - original packet
• After change - modified packet
Parameter
Description
Policy Name The user defined name of the policy, which is going to be moved or copied.
Parent Name Select the relevant new Parent Name from the drop down list to be moved or copied.
Action You can move or copy policies from one place to another.
A child policy can be moved to a higher position in the hierarchy and a parent policy with all its children can either be moved or copied to a position under another policy (either under a parent or another child.
Note: A parent policy can not be moved or copied to a position under a child.
Parameter
Description
AppDirector User Guide
Classes and Bandwidth Management
Document ID: RDWR-AD-V0231-UG1105 385
To view active policies
1.From the BWM menu, select View Active Policies. The Active Policies Table window is displayed.
2.From the Active Policies Table window, select the policy you wish to view. The table displays the parameters of the active policy.
Parameter
Description
Name The user defined name of the policy. Children policies must begin with the name of the parent policy, followed by a dot (‘.’) for example:
Parent, Parent.child1, Parent.childr2, Parent.child2.a, Parent.child2.b
Each child inherits his parent properties. Up to five hierarchies are supported.
Note: Using the Policy Trees window it is possible to change the hierarchies between policies by moving and copying parent and child policies.
Index The index number of the policy. Policies are searched by their index from the lower index to the higher index.
Destination The destination address of the packet being matched by the policy. Note: The source or destination can be an IP address or a network address.
Source The source address of the packet being matched by the policy.
Action The action determines the access given to traffic. Values:
• 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 client and server.
AppDirector User Guide
Classes and Bandwidth Management
386 Document ID: RDWR-AD-V0231-UG1105
Direction The direction of the policy can be one of the following:
• OneWay: Setting the direction to OneWay enables asymmetric Bandwidth Management. When a policy is set to OneWay, the classifier searches for traffic in one direction only and the device classifies only one direction of the traffic; the return traffic is not classified.
• TwoWay: When a policy is set to TwoWay, the classifier searches for traffic in both directions and the device replaces the source and destination IP addresses and ports (in case the policy is a Layer 4 or Layer 7 policy) of the return traffic.
• Session: — TCP/UDP traffic - Any session opened by user A (with source IP AIP and source port Aport) to user B (with destination IP BIP and destination port Bport) is allowed, as well as the reply traffic with source IP BIP, source port Bport to destination IP AIP, destination port Aport User B is not permitted to establish a new session with A. — Non TCP/UDP traffic - Any session opened by user A (with source IP AIP) to user B (with destination IP BIP) using a specific IP protocol is allowed, as well as the reply traffic with source IP BIP to destination IP AIP, as long as it uses the same IP protocol as the packet that opened the session from A to B. User B is not permitted to establish a new session with A.
Priority The priority attached to the packet by which it is forwarded is either Real-
time or a value of 0-7, 7 being the lowest priority. Priority is only applicable if the action is forward.
Description A description of the policy. Guaranteed Bandwidth
The reserved bandwidth for packets matching this policy. For a child policy the sum of all the guaranteed bandwidth must not exceed the parent policy.
Note: A Child Policy cannot be configured with Maximum Bandwidth and Guaranteed Bandwidth higher than its Parent Policy, however, the sum of maximum bandwidth can be higher than the Parent Policy and the sum of all Guaranteed Bandwidth must be smaller or equal to the Guaranteed Bandwidth of the Parent Policy. Maximum Bandwidth
The maximum amount of bandwidth that can be forwarded for traffic that matches this policy. In hierarchical BWM (APSolute 10.40 and later), When one of the Children does not consume all of its allocated Bandwidth, another Child, belonging to the same Parent may use the spare bandwidth, which is limited by the Maximum Bandwidth value. Note: A Child Policy cannot be configured with Maximum Bandwidth and Guaranteed Bandwidth higher than its Parent Policy, however, the sum of maximum bandwidth can be higher than the Parent Policy and the sum of all Guaranteed Bandwidth must be smaller or equal to the Guaranteed Bandwidth of the Parent Policy.
Service Type Type of service: None, Basic Filter, Advanced Filter or Filter Group.
Service Name of the service required for this policy, based on the Service Type.
Parameter
Description
AppDirector User Guide
Classes and Bandwidth Management
Document ID: RDWR-AD-V0231-UG1105 387
View Active Policy Extensions
You can view the additional policy parameters in the Active Policies Extensions window.
To view Active Policies Extensions
1.From the BWM menu, select View Active > Policy Extensions. The Active Policies Extensions window is displayed, which contains the following read-only parameters.
.
Packet Marking Refers to Differentiated Services Code Point (DSCP) or Diffserv. Enables you to mark the packet with a range of bits displayed in the drop down list.
Inbound Physical Port Group
You can set policies for identical traffic classes that are received on different interfaces of the device. For example, the user can allow HTTP access to the main server only to traffic entering the device via physical interface 3. This provides greater flexibility in configuration. VLAN Tag Group Allows classification of different types of traffic classes based on the value of the VLAN Tag. When configured, only traffic with VLAN Tag which is part of the VLAN Tag group is classified.
Parameter
Description
Name The user-defined name of the policy.
Activation Schedule You can schedule the activation of specific Bandwidth Management policies. Using Event Scheduler you can create "events" which can then be attached to a policy's configurations. "Events" define the date and time in which an action must be performed.
Index The index number of the policy. Policies are searched by their index from the lower index to the higher index.
Traffic Flow Max BW The maximum bandwidth allowed per traffic flow.
Traffic Flow Identification
Defines what type of traffic flow we are going to limit via this policy. The available options are:
• Client (source IP).
• Session (source IP and port).
• Connection (source IP and destination IP).
• FullL4Session (source and destination IP and port).
• SessionCookie (must configure cookie identifier).
Packet Marking Value Enter in the Packet Marking value accordingly:
• DCSP: Enter a value between 0-63
• ToS: Enter a value between 0-7
Packing Marking Type Refers to Differentiated Services Code Point (DSCP) or ToS. Enables you to mark the packet with a range of bits displayed in the drop-down list.
Inactivation Schedule You can schedule the inactivation of specific Bandwidth Management policies. Using Event Scheduler you can create "events" which can then be attached to a policy's configurations. "Events" define the date and time in which an action must be performed.
Parameter
Description
AppDirector User Guide
Classes and Bandwidth Management
388 Document ID: RDWR-AD-V0231-UG1105
Viewing Active Policy Groups
You can view the active policy groups in the Active Policies Table window. This table displays all the active policy groups. You cannot add or remove policy groups from this table.
Differentiated Services
Differentiated Services (Diffserv) provides differentiated classes of service to Internet traffic, supporting various types of applications, as well as specific business requirements. The problem in providing different classes of service to different types of traffic is that each network device must examine various parameters in each packet, in order to identify the class of service it should receive. Diffserv uses a small bit-pattern in each packet to identify the type of service it should receive.
Radware support for Diffserv can act as either a classifier, marking each packet as it enters the network and providing the appropriate type of service, or as a network node, which reads the Type of Service (ToS) bits in order to provide the appropriate type of service as indicated by the bits.
Note:In order to view the DiffServ menu, Diffserv must be selected as the Classification mode in the BWM Global Parameters window.
Modify Diffserv Policies
To modify DiffServ Policies:
1.From the BWM menu, select DiffServ > Modify DiffServ Policies. The Modify DiffServ Policies Table window is displayed.
2.Double click on the relevant policy from the table. The Modify DiffServ Policies Table Update window is displayed.
Force Best Fit When Bandwidth Management policies, contain Content Filters or OMPC (Offset Mask Pattern Condition) Filters, the classification is done according to Best Fit (as oppose to First Fit). In such cases, the device keeps classifying the traffic until there is a Best Fit between the packet pattern and the configured policy.
The classifier classifies the traffic until there is a First Fit matching.The classifier stops searching for matching policies the moment there is a match between the packet pattern and the configured policy.
The following is displayed according to what was defined in the Modify Policy Extensions window:
• False: Means that the traffic is classified per packet instead of per session.
• True: Means that the traffic is classified directly from the policy from which this flag is enabled (Force Best Fit)
Destination The destination address of the packet being matched by the policy. Note: The source or destination can be an IP address or a network address.
Source The source address of the packet being matched by the policy. Note: The source or destination can be an IP address or a network address.
Parameter
Description
AppDirector User Guide
Classes and Bandwidth Management
Document ID: RDWR-AD-V0231-UG1105 389
3.Set the parameters.
4.Click Set. Your preferences are recorded.
View Active Diffserv Policies
To view active DiffServ Policies
1.From the BWM menu, select DiffServ > View Active DiffServ Policies. The View Active DiffServ Policies Table window is displayed.
2.View the parameters.
Parameter
Description
DSCP Refers to Differentiated Services Code Point, which is the Diffserv value.
Priority The priority attached to the packet carrying the Diffserv value, by which it is forwarded is either Real time or a value of 0-7, 7 being the lowest priority. Default: 4
Guaranteed Bandwidth (kbps)
This defines the bandwidth limitation for packets matching this policy. This option is used in conjunction with CBQ, not WWR.
Maximum Bandwidth (kbps)
The maximum amount of bandwidth that can be used by a policy.
Parameter
Description
DSCP Refers to Differentiated Services Code Point, which is the Diffserv value.
Priority The priority attached to the packet carrying the Diffserv value, by which it is forwarded is either Real time or a value of 0-7, 7 being the lowest priority. Default: 4
Guaranteed Bandwidth (kbps)
This defines the bandwidth limitation for packets matching this policy. This option is used in conjunction with CBQ, not WWR.
Maximum Bandwidth (kbps)
The maximum amount of bandwidth that can be used by a policy.
AppDirector User Guide
Classes and Bandwidth Management
390 Document ID: RDWR-AD-V0231-UG1105
Modifying ToS Policies
The Modify ToS Policies Table window enables you to prioritize and allocate bandwidth for ToS policies. When the Classification mode is set as ToS the device classifies packets only by the ToS (Type of Service) bit`s value.
Note:This window is only available when ToS is selected as the classification mode in BWM Global Parameters.
1.From the BWM menu, select ToS > Modify ToS Policies. The Modify ToS Policies Table window is displayed.
2.Select the relevant policy from the table. The Modify ToS Policies Table window is displayed.
3.Set the parameters.
4.Click Set. Your preferences are recorded.
View Active DiffServ Policies
The View Active DiffServ Policies window enables you to view the Active DiffServ Policies created in the Modify DiffServ Policies window.
To view Active DiffServ Policies
1.From the BWM menu, select DiffServ > View Active DiffServ Policies. The View Active DiffServ Policies Table window is displayed.
2.Double click the relevant policy. The View Active DiffServ Policies Table window is displayed, which contains the following read only parameters.
Parameter
Description
Policy This refers to the Type of Service policy, which is the ToS value.
Priority The priority attached to the packet carrying the Diffserv value, by which it is forwarded is either Real time or a value of 0-7, 7 being the lowest priority. Default: 4
Guaranteed Bandwidth (kbps)
This defines the bandwidth limitation for packets matching this policy. This option is used in conjunction with CBQ, not WWR.
Maximum Bandwidth (kbps)
The maximum amount of bandwidth that can be used by a policy.
Parameter
Description
DSCP Refers to Differentiated Services Code Point, (the Diffserv value).
Priority Priority attached to the packet carrying the Diffserv value, by which it is forwarded is either Real time or a value of 0-7, (7 is the lowest priority). Default: 4
Guaranteed Bandwidth (kbps)
This defines the bandwidth limitation for packets matching this policy. This option is used in conjunction with CBQ, not WWR.
Maximum Bandwidth (kbps)
The maximum amount of bandwidth that can be used by a policy.
AppDirector User Guide
Classes and Bandwidth Management
Document ID: RDWR-AD-V0231-UG1105 391
View Active ToS Policies
The View Active ToS Policies Table window allows you to view the ToS Polices created in the Modify ToS Policies window.
To view the Active ToS Policies
From the BWM menu, select ToS > View Active ToS Policies. The View Active ToS Policies Table window is displayed, which contains the following read only parameters.
Bandwidth Management and Classes Update Policies
You can activate the latest changes made in Bandwidth Management or Classes. You use the Activate Latest Changes window to activate the Inactive Policies.
To activate inactive policies 1.From the BWM or Classes menu, select Update Policies. The Activate Latest Changes window is displayed.
2.Click Set to implement the latest policy changes.
Parameter
Description
Policy This refers to the Type of Service policy, which is the ToS value.
Priority Priority attached to the packet carrying the Diffserv value, by which it is forwarded is either Real time or a value of 0-7, 7 being the lowest priority. Default: 4
Guaranteed Bandwidth (kbps)
This defines the bandwidth limitation for packets matching this policy. This option is used in conjunction with CBQ, not WWR.
Maximum Bandwidth (kbps)
The maximum amount of bandwidth that can be used by a policy.
AppDirector User Guide
Classes and Bandwidth Management
392 Document ID: RDWR-AD-V0231-UG1105
Traffic Classes
Several types of traffic classes can be defined for use in Bandwidth Management and Security policies. Classes available include:
• Configuring Networks
, page 392
• Services
, page 394
• Basic Filters
, page 397
• A
pplication Port Groups
, page 402
• Physical Port Groups
, page 403
• VLAN Tag Groups
, page 404
• MAC Groups
, page 405
Configuring Networks
The Bandwidth Management module allows multiple Networks to have the same configured “name.” This allows a Network with the name “net1” to encompass multiple, disjointed IP address ranges. This makes the Network “name” a logical pointer to all ranges configured with that name and further facilitates the configuration and management of the system. You can view active networks, and configure new ones. You can define networks used by the device (active) and you can define networks kept in a separate database until they are required (inactive). You can add, modify and delete these networks according to your requirements.
To create a new network 1.From the Classes menu, select Modify > Networks. The Modify Network Table window is displayed.
2.Click Create. The Modify Network Table Create window is displayed.
3.Set the parameters.
4.Click Set. Your configuration is set.
Parameter
Description
Name The user-defined network name.
Sub Index Unique index number of the subnet. Each network can have several subnets. Sub Indexes for the subnets within the same network must be unique.
Address The IP address of the subnet. Mask The mask address of the subnet.
From IP The first IP address in the range of addresses.
To IP The last IP address in the range of addresses. Mode The network mode is either IP Mask or IP Range.
AppDirector User Guide
Classes and Bandwidth Management
Document ID: RDWR-AD-V0231-UG1105 393
Notes:
>> Default networks created by AppDirector can be configured as follows:
•"any" network include all traffic from IPv4 and IPv6
•"any_ipv4" network include all traffic from IPv4 to IPv4
•"any_ipv6" network include all traffic from IPv6 to IPv6
>> To simplify configuration, a network can consist of a combination of network subnets and ranges. For example:
• Range = 176.200.100.0: 176.200.100.255
• Subnet = 172.0.0.0: 255.0.0.0
Viewing Active Networks
The View Active Networks window enables you to view and modify active networks and to configure new ones. You can define networks to be used by the device, which are kept in the active part of the database, and you can define networks that will kept in a separate, temporary database until they are required. A network can be a range or subnet/mask, or IP address range combination of few ranges, subnet masks and IP addresses. Use the same network name for multiple entries in the table to create such combination.
You can add, modify and delete these networks according to your requirements.
To view active networks From the Classes menu, select View Active Networks. The Active Network Table window is displayed with these read-only parameters.
Parameter
Description
Name The user-defined network name.
Sub Index Unique index number of the subnet. Each network can have several subnets. Sub Indexes for the subnets within the same network must be unique.
Address The IP address of the subnet. Mask The mask address of the subnet.
From IP The first IP address in the range of addresses.
To IP The last IP address in the range of addresses. Mode The network mode of entry, either IP Mask or IP Range.
AppDirector User Guide
Classes and Bandwidth Management
394 Document ID: RDWR-AD-V0231-UG1105
To edit a network 1.From the Modify Network Table window, select the network you require to edit. The Modify Network Table Update window is displayed.
2.Adjust the values of the appropriate fields.
3.Click Set. Your configuration is set.
To delete networks 1.From the Modify Network Table window, select the network you want to delete.
2.Click Delete. The network is deleted.
Services
Services can be configured within the Bandwidth Management system and are configured separately from policies. As each policy is configured, it can be associated with a configured Service. The Service associated with a policy in the policy database can be a basic filter, an advanced filter or a filter group. Basic Filters
A basic filter has the following components:
• Protocol: The specific protocol that the packet carries. The possible choices are IP, TCP, UDP, ICMP, and Other. If the protocol is configured as IP, all IP packets (including TCP and UDP) are considered. When configuring TCP or UDP protocol, some additional parameters are also available:
— Destination Port (From-To) - Destination port number for the protocol. For example, for HTTP, the protocol is configured as TCP and the Destination port as 80. The port configuration can also allow for a range of ports to be configured.
— Source Port (From-To) - Similar to the Destination port; the Source port that a packet carries to match the filter. • Offset Mask Pattern Condition (OMPC): The OMPC is a condition where any bit pattern can be located for a match at any offset in the packet. This helps to locate specific bits in the IP header. You do not have to configure an OMPC per filter. However, when an OMPC is configured, the packet needs to match the configured protocol (and Source/Destination ports) AND the OMPC.
Parameter
Description
Name The user-defined network name.
Sub Index Unique index number of the subnet. Each network can have several subnets. Sub Indexes for the subnets within the same network must be unique.
Address The IP address of the subnet. Mask The mask address of the subnet.
From IP The first IP address in the range of addresses.
To IP The last IP address in the range of addresses. Mode The network mode is either IP Mask or IP Range.
AppDirector User Guide
Classes and Bandwidth Management
Document ID: RDWR-AD-V0231-UG1105 395
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. Pre-Defined Filters This table lists pre-defined Bandwidth Management filters for each service.
Table 5: Pre-Defined 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
AppDirector User Guide
Classes and Bandwidth Management
396 Document ID: RDWR-AD-V0231-UG1105
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
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 5: Pre-Defined Filters
Service Name
Description
Filter Name
AppDirector User Guide
Classes and Bandwidth Management
Document ID: RDWR-AD-V0231-UG1105 397
Basic Filters
The Active Basic Filters window allows you to view the basic filters of the active services.
To view a basic filter 1.From the Classes menu select Modify Services > Basic Filters. The Active Basic Filters window is displayed.
2.Select the required name. The Active Basic Filters Update window is displayed with these read-
only parameters. Parameter
Description
Name The name of the filter as you define it
Protocol Values: IP, UDP, TCP, ICMP. NonIP, SCTP
Destination App. Port
Last port in the range of destination ports for UDP and TCP traffic only. Values: 0 (default) - 65535. Defined value must be greater than Destination Port Range: From value.
Source App. Port Last port in the range of source ports for UDP and TCP traffic only. Values: 0 (default) - 65535. Defined value must be greater than the Source Port Range: From value.
OMPC Offset Location in the packet from which the checking of data is started to find specific bits in the IP/TCP header. Values: 0 (default) - 1513
OMPC Offset Relative to
Indicates to which OMPC offset the selected offset is relative to. If the IP/UDP/ICMP protocols are selected, you can configure:
• None (Default), IP Header, IP Data. If the TCP protocol is selected, you can set these values: • None (Default), IP Header, IP Data, TCP Data.
OMPC Mask Mask for OMPC data. Values: a combination of hexadecimal numbers (0-
9, a-f). Value must be defined according to the OMPC Length parameter. OMPC Pattern Fixed size pattern within the packet that OMPC rule attempts to find. Values: a combination of hexadecimal numbers (0-9, a-f). The value must be defined according to the OMPC Length parameter. OMPC Pattern parameter definition must contain 8 symbols. If the OMPC Length value is lower than fourBytes, you need complete it with zeros.
For example, if OMPC Length is twoBytes, OMPC Pattern can be:abcd0000.
Default: 00000000.
OMPC Condition Values: N/A (Default), equal, notEqual, greaterThan or lessThan.
OMPC Length Values: N/A (Default), oneByte, twoBytes, threeBytes or fourBytes.
Content Offset Location in packet from which the checking of content is started. Values: 0 (default) - 1513
Content Contains the value of the content search. 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 { | } ~ .
AppDirector User Guide
Classes and Bandwidth Management
398 Document ID: RDWR-AD-V0231-UG1105
3.Click Set. The new Basic Filter is added to the Basic Filters Table.
Content Type Enables you to search for a specific content type from these values:
• N/A (Default)
• URL: In the HTTP Request URI • Host Name: In the HTTP Header • Text: Anywhere in the packet • HTTP Header Field: In the HTTP Header • Mail Domain: In the SMTP Header • Mail To: In the SMTP Header • Mail From: In the SMTP Header • Mail Subject: In the SMTP Header • Regular Expression: Anywhere in the packet • Header Type: HTTP Header field. The "Content" field includes the header field name, and the "Content data" field includes the field value
• File Type: The type of the requested file in the http GET command (jpg, exe etc.)
• Cookie Data: HTTP cookie field. The "content" field includes the cookie name, and the "content data" field includes the cookie value.
Content End Offset Location in the packet from where the checking of content ends.
Content Data Refers to search for content within the packet. Values: None, URL or Text.
Content Coding Application Security can search for content in languages other than English, for case sensitive/insensitive text and hexadecimal strings. Values: • None (Default)
• Case Insensitive • Case Sensitive • HEX • International
Content Data Coding Application Security can search for content in languages other than English, for case sensitive/insensitive text and hexadecimal strings. Values: • None (Default)
• Case Insensitive • Case Sensitive • HEX • International
Description Description of the filter.
Values: Priority, Immediate.
Parameter
Description
AppDirector User Guide
Classes and Bandwidth Management
Document ID: RDWR-AD-V0231-UG1105 399
Note:If you edit the parameters of the filter, which is bound to the existing policy, you need to activate the latest changes
AND Group Filters and OR Group Filters
An AND Group Filter is a combination of basic filters with a logical AND between them. Let's assume filters F1, F2, and F3 have been individually configured. Advanced filter AF1 can be defined as:
AF1= {F1 AND F2 AND F3}. In order for AF1 to be a match, all three filters (F1, F2, and F3) must match the packet being classified. An OR Group Filter is a combination of basic filters and/or advanced filters with a logical OR between them. To continue the example above, filter group FG1 can be defined as: FG1 = {AF1 OR F4 OR F6}. In order for FG1 to be a match, either advanced filter AF1, basic filter F4, or basic filter F6 have to match the packet being classified.
Radware devices are pre-configured with a set of basic filters and group filters that represent applications commonly found in most networks. Creating and Modifying AND Group Tables
AppDirector enables you to view active services and to configure new services. You can define services used by the device, which are kept in the active part of the database, and you can define services kept in a separate, temporary database until they are required.
You can create basic filters and then combine them with logical conditions to achieve more sophisticated filters, as shown in the Modify AND Group Table window. Use filter groups (for logical OR between filters) and advanced filters (for logical AND between filters). The Modify AND Group Table window allows you to modify an advanced filter.
To create or modify an AND Group table 1.From the Classes menu, select Modify > Services > AND Groups. The Modify AND Groups Table window is displayed.
2.Select the required advanced name. The Modify AND Groups Update Table window is displayed, with these read-only parameters:
3.Click Set. Your configuration is set.
Note:If you edit the parameters of the advanced filter, which is bound to the existing policy, you need to activate the latest changes.
Creating and Modifying OR Groups Table You can also add, modify and delete the filters that build the services according to your requirements. The Modify OR Groups Table window allows you to modify an existing filter group.
Parameter
Description
AND Group Name The user-defined AND Group name.
Basic Filter Name The name of the basic filter that is to be added to the Advance Filter.
AppDirector User Guide
Classes and Bandwidth Management
400 Document ID: RDWR-AD-V0231-UG1105
To add/modify a new OR Group 1.From the menu select Classes > Modify > Services > OR Groups. The Modify OR Groups Table window is displayed.
2.Click Create. The Modify OR Groups Table Create window is displayed.
3.Set the parameters. 4.Click Set. Your configuration is set.
Viewing Active Services
AppDirector enables you to view active services, and configure new ones.
To view active services From the Classes menu, select View Active > Services > Basic Filters or AND Groups, or OR Groups. Parameter
Description
OR Group Name The name of the Filter Group that you define
Filter Type Basic: The basic building block of a Service is a basic filter which is made up of the following components:
• Protocol: • Destination Port (From-To) • Source Port (From-To) • Offset Mask Pattern Condition (OMPC)
• Content
AND Group: Combination of basic filters with a logical AND between them. Note: A Filter Group is a combination of basic filters and/or advanced filters with a logical OR between them. To continue the example above, filter group FG1 can be defined as FG1 = {AF1 OR F4 OR F6}
Filter Name Name of entry assigned to a specific filter group.
Parameter
Description
Name The name of the filter as you define it
Protocol Values: IP, UDP, TCP, ICMP. NonIP, SCTP
Destination App. Port Last port in the range of destination ports for UDP and TCP traffic only. Values: 0 (default) - 65535. Defined value must be greater than Destination Port Range: From value.
Source App. Port Last port in the range of source ports for UDP and TCP traffic only. Values: 0 (default) - 65535. Defined value must be greater than the Source Port Range: From value.
AppDirector User Guide
Classes and Bandwidth Management
Document ID: RDWR-AD-V0231-UG1105 401
OMPC Offset Location in the packet from which the checking of data is started to find specific bits in the IP/TCP header. Values: 0 (default) - 1513
OMPC Offset Relative to
Indicates to which OMPC offset the selected offset is relative to. If the IP/UDP/ICMP protocols are selected, you can configure:
• None (Default), IP Header, IP Data. If the TCP protocol is selected, you can set these values: • None (Default), IP Header, IP Data, TCP Data.
OMPC Mask Mask for OMPC data. Values: a combination of hexadecimal numbers (0-9, a-f). Value must be defined according to the OMPC Length parameter. OMPC Pattern Fixed size pattern within the packet that OMPC rule attempts to find. Values: a combination of hexadecimal numbers (0-9, a-f). The value must be defined according to the OMPC Length parameter. OMPC Pattern parameter definition must contain 8 symbols. If the OMPC Length value is lower than fourBytes, you need complete it with zeros.
For example, if OMPC Length is twoBytes, OMPC Pattern can be:abcd0000.
Default: 00000000.
OMPC Condition Values: N/A (Default), equal, notEqual, greaterThan or lessThan.
OMPC Length Values: N/A (Default), oneByte, twoBytes, threeBytes or fourBytes.
Content Offset Location in packet from which the checking of content is started. Values: 0 (default) - 1513
Content Contains the value of the content search. 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 Type Enables you to search for a specific content type from these values:
• N/A (Default)
• URL: In the HTTP Request URI • Host Name: In the HTTP Header • Text: Anywhere in the packet • HTTP Header Field: In the HTTP Header • Mail Domain: In the SMTP Header • Mail To: In the SMTP Header • Mail From: In the SMTP Header • Mail Subject: In the SMTP Header • Regular Expression: Anywhere in the packet • Header Type: HTTP Header field. The "Content" field includes the header field name, and the "Content data" field includes the field value
• File Type: The type of the requested file in the http GET command (jpg, exe etc.)
• Cookie Data: HTTP cookie field. The "content" field includes the cookie name, and the "content data" field includes the cookie value.
Content End Offset Location in the packet from where the checking of content ends.
Parameter
Description
AppDirector User Guide
Classes and Bandwidth Management
402 Document ID: RDWR-AD-V0231-UG1105
Application Port Groups
Application Port Groups represent the Layer 4 ports for UDP and TCP traffic. Each group is identified by its unique name. Each group name can be associated with a number of entries in the Application Port Groups table. The values can be: 0 - 65535.
To Create or Modify Application Port Groups 1.From the Classes menu, select Modify > Application Port Groups. The Modify Application Port Groups Table window is displayed.
2.Click Create. The Modify Application Port Groups Table Create window is displayed.
3.Set the parameters. Content Data Refers to search for content within the packet. Values: None, URL or Text.
Content Coding Application Security can search for content in languages other than English, for case sensitive/insensitive text and hexadecimal strings. Values: • None (Default)
• Case Insensitive • Case Sensitive • HEX • International
Content Data Coding Application Security can search for content in languages other than English, for case sensitive/insensitive text and hexadecimal strings. Values: • None (Default)
• Case Insensitive • Case Sensitive • HEX • International
Description Description of the filter.
Values: Priority, Immediate.
Parameter
Description
Name A user defined group name
From Port Define the first port in the range.
Notes:
• To define a group with a single port, set the same value for the From Port and To Port parameters.
• To associate a number of ranges with the same port group, use the same group name for all the ranges that you want to include in one group.
Parameter
Description
AppDirector User Guide
Classes and Bandwidth Management
Document ID: RDWR-AD-V0231-UG1105 403
4.For Updating, in the Modify Application Port Groups Table window, click on the application name. The Modify Appl. Port Groups Table Update window is displayed
5.Click Set. Your configuration is set.
To view Application Port Groups 1.From the Classes menu, select View Active > Appl Port Groups. The Active Application Port Groups Table window is displayed.
2.Select the desired name. The Active Application Port Groups Table Update window is displayed which contains the following read-only parameters.
Physical Port Groups
You can set different policies to identical traffic classes that are received on different interfaces of the device. For example, you can allow access to the main server only to traffic entering the device via physical interface 3. This provides greater flexibility in configuration. You must first configure Port Groups, which are collections of Physical Interfaces of the device, and then associate a Port Group to the required policies. The Modify Physical Port Groups Table window allows you to modify an existing port group.
To modify a port group 1.From the Classes menu, select Modify > Port Groups. The Modify Physical Port Groups Table window is displayed.
2.Select a group name. The Modify Physical Port Groups Table Update window is displayed.
To Port Define the last port in the range.
Group Type (Update mode only)
Defines the group type as either static or regular.
Parameter
Description
Name A user defined group name
From Port Define the first port in the range.
Notes:
• To define a group with a single port, set the same value for the From Port and To Port parameters.
• To associate a number of ranges with the same port group, use the same group name for all the ranges that you want to include in one group.
To Port Define the last port in the range.
Group Type Defines the group type either static or regular.
Parameter
Description
AppDirector User Guide
Classes and Bandwidth Management
404 Document ID: RDWR-AD-V0231-UG1105
3.Set the parameters.
4.Click Set. The Port Group is configured.
VLAN Tag Groups VLAN Tag Groups enable you to set different policies for identical traffic classes received with different values of 802.1q VLAN Tags; for example, you can allow SMTP access to the Internet only to traffic tagged with a specific value VLAN Tag. This provides configuration flexibility but you must first configure the VLAN Tag Groups.
To modify VLAN tag groups 1.From the Classes menu select Modify > VLAN Tag Groups. The Modify VLAN Tag Groups Table window is displayed
2.Set the parameters. 3.Click Set. Your configuration is set.
Note:This feature is applicable only when the 802.1q parameter is set to Enabled. Classifications performed according to the tag of the received packet
To view VLAN tag groups 1.From the Classes menu select View Active > VLAN Tag Groups. The Modify VLAN Tag Groups Table window is displayed
2.Set the parameters. Parameter
Description
Group Name The user-configured name of the port group.
Inbound Port Inbound port for this group. Values can be a port number or Any.
Parameter
Description
Group Name The name of the group of VLAN Tags.
VLAN Tag A VLAN Tag number.
VLAN Tag Range From Lowest value in range of VLAN Tags that you want to define.
VLAN Tag Range To Highest value in range of VLAN Tags that you want to define.
Group Mode Mode of the group that you want to define is Discrete if you define a single VLAN Tag number, OR Range if you define range of the group.
Parameter
Description
Group Name The name of the group of VLAN Tags.
VLAN Tag A VLAN Tag number.
VLAN Tag Range From Lowest value in range of VLAN Tags that you want to define.
AppDirector User Guide
Classes and Bandwidth Management
Document ID: RDWR-AD-V0231-UG1105 405
3.Click Set. Your configuration is set.
MAC Groups
To view or modify MAC Groups 1.From the Classes menu select Modify > MAC Groups. The Modify MAC Address Groups Table is displayed.
2.Click Create. The Modify MAC Address Groups Table Create window is displayed.
3.Set the parameters.
4.Click Set. Your configuration is set.
Protocol Discovery
This describes the Protocol Discovery feature that allows you to recognize different applications running on your network by creating Protocol Discovery Policies. To use the Bandwidth Management module optimally, network administrators must be aware of the different applications running on their networks and the amount of bandwidth they consume. The Protocol Discovery feature provides a full view of the different protocols running on the network. This feature can be activated on the entire network or on separate sub-networks by defining Protocol Discovery policies.
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 traffic destination. It can be specific IPs, a range of IP addresses, or an IP subnet address. The default value is any, which covers traffic to any destination.
• Source MAC Address Group: Views applications and protocols present in the traffic sent by a transparent network device (firewall, router).
• Destination MAC Group: Views applications and protocols present in the traffic sent to a transparent network device (firewall, router). • Inbound Physical Port Group: Classifies only traffic received on certain interfaces of the device. Enables you to set different policies for identical traffic classes that are received on different device interfaces. VLAN Tag Range To Highest value in range of VLAN Tags that you want to define.
Group Mode Mode of group that you want to define is Discrete if you define a single VLAN Tag number, OR Range if you define range of the group.
Parameter
Description
Group Name The name of the MAC address group.
MAC Address A MAC Address number.
Parameter
Description
AppDirector User Guide
Classes and Bandwidth Management
406 Document ID: RDWR-AD-V0231-UG1105
• VLAN Tag Group: Defines VLAN traffic classification according to VLAN ID tags.
• Classification Point: Defines the point where traffic redirection occurs. The device modifies packets by changing the Destination IP from the Virtual IP to the server’s real IP address. The traffic can be classified as before packet changes, or after packet changes, After Changes.
• Direction: Defines the direction of the traffic. It can be One Way (from Source to Destination) or Two Way.
• Operational Status: Determines whether Policy is active or not. Select from Active or Inactive.
Interface Classification
This describes the process of interface classification, which enhances Bandwidth performance Editing Port Bandwidth
To optimize the queuing algorithm, it is essential for the BWM module to be aware of the maximum available ports’ bandwidth. This can be configured via the BWM Port Bandwidth table. By default, the maximum available is determined by the port type - 100 Mbps for FE ports and 1Gbps for Giga ports. The queuing filter only starts functioning upon link saturation. Configuring the maximum is the only way to determine if the link is saturated.
To edit Port Bandwidth
1.From the BWM menu select Miscellaneous > Port Bandwidth Table. The Port Bandwidth Table window is displayed.
2.Select the port where you need to edit the bandwidth. The Port Bandwidth Table Update window is displayed.
3.Set the parameters.
4.Click Set. Your preferences are recorded.
Cancel Classification Per Port
This feature enables the user to configure ports where classification is not performed. In this way valuable processing time can be saved while enabling a simpler method of configuring the device. Cancel Classification Per VLAN is also available for a VLAN configuration.
Parameter
Description
Port Index The port number.
Port Bandwidth (kbps) The bandwidth available to the specific port.
Port Used Bandwidth (kbps)
The amount of bandwidth used on the specific port. AppDirector User Guide
Classes and Bandwidth Management
Document ID: RDWR-AD-V0231-UG1105 407
To cancel classification for a port
1.From the BWM menu select Miscellaneous > Cancel Classification Per Port. The Cancel Classification Per Port window is displayed.
2.Set the parameters.
3.Click Set. Your preferences are recorded.
Modifying Application Port Groups
Application Port Groups represent the Layer 4 ports for UDP and TCP traffic. Each group is identified by its unique name and each group name can be associated with a number of entries in the Application Port Groups table.
To create the Modify Appl. Port Groups Table parameters
1.From the Classes menu, select Modify Appl Port Groups. The Modify Appl. Port Groups Table window is displayed.
2.Click Create. The Modify Appl. Port Groups Table Create window is displayed.
3.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 Set. Your preferences are recorded.
Parameter
Description
Inbound Port The number of the required port for inbound traffic.
Outbound Port The number of the required port for outbound traffic.
Direction Direction of traffic flow through each port. Values:
• Oneway: the traffic flows in through the Inbound Port and out through the Outbound Port.
• Twoway: the traffic flows both ways through both ports.
Parameter
Description
Name A user defined group name.
From Port Define the first port in the range. (Values from 0)
To Port Define the last port in the range.(Values to 65535)
Group Type Defines the group type either static or regular.
AppDirector User Guide
Classes and Bandwidth Management
408 Document ID: RDWR-AD-V0231-UG1105
To update the parameters of the Modify Appl. Port Groups Table
1.From the Classes menu, select Modify Appl Port Groups. The Modify Appl. Port Groups Table window is displayed.
2.Click on the application name. The Modify Appl. Port Groups Table Update window is displayed. Proceed from step 3
.
Viewing Application Port Groups
To view active application port groups
1.From the Classes menu, select View Active > Appl Port Groups. The Active Application Port Groups Table window is displayed.
2.Select the desired name. The Active Application Port Groups Table Update window is displayed with read-only parameters. See To create the Modify Appl. Port Groups Table parameters
, page 407
.
Modify MAC Groups
To modify MAC Groups
1.From the Classes menu select Modify > MAC Groups. The Modify MAC Address Groups Table is displayed.
2.Click Create. The Modify MAC Address Groups Table Create window is displayed.
3.Set the parameters.
4.Click Set. Your preferences are recorded.
View Active MAC Groups
To classify traffic according to Mac addresses, you can create groups of Mac addresses.
To view the Active MAC Groups:
From the Classes menu select View Active MAC Groups. The Active MAC Address Groups Table window is displayed with read-only parameters. See To modify MAC Groups
, page 408
. Parameter
Description
Group Name The name of the MAC address group.
MAC Address A MAC address number.
AppDirector User Guide
Classes and Bandwidth Management
Document ID: RDWR-AD-V0231-UG1105 409
View Active VLAN Tag Groups
The Active VLAN Tags Table Update window allows you to view the active VLAN tag groups.
To view the Active VLAN Tag Groups
1.From the Classes menu select View Active VLAN tag Groups. The Active VLAN Tags Table window is displayed.
2.Select a group name. The Active VLAN Tags Table Update window is displayed which contains the following read-only parameters.
Note:This is applicable only when the 802.1q parameter is set to Enabled. Classifications performed according to the tag of the received packet.
Modify Port Groups
You can set different policies to identical traffic classes that are received on different interfaces of the device. For example, you can allow access to the main server only to traffic entering the device via physical interface 3. This provides greater flexibility in configuration.
You must first configure Port Groups, which are collections of Physical Interfaces of the device, and then associate a Port Group to the required policies. The Modify Physical Port Groups Table window allows you to modify an existing port group.
To modify a port group
1.From the Classes menu, select Modify Port Groups. The Modify Physical Port Groups Table window is displayed.
2.Select a group name. The Modify Physical Port Groups Table Update window is displayed.
3.Set the parameters.
4.Click Set. The Port Group is configured.
Parameter
Description
Group Name The name of the group of VLAN Tags.
VLAN Tag A VLAN Tag number.
VLAN Tag Range From The lowest value in the range of VLAN Tags that you want to define.
VLAN Tag Range To The highest value in the range of VLAN Tags that you want to define.
Group Mode The group mode that you want to define is:
• Discrete: when you define a single VLAN Tag number, OR • Range: when you define the range of the group.
Parameter
Description
Group Name The user-configured name of the port group.
Inbound Port The inbound port for this group. Values can be a port number or Any.
AppDirector User Guide
Classes and Bandwidth Management
410 Document ID: RDWR-AD-V0231-UG1105
To create a new port group
1.From the Classes menu select Modify >Port Groups. The Modify Physical Port Groups Table window is displayed.
2.Select Create. The Physical Port Groups Table Create window is displayed. Proceed as step 3
. AppDirector User Guide
Advanced Capabilities
Document ID: RDWR-AD-V0231-UG1105 411
Chapter 7 – Advanced Capabilities
This chapter displays AppDirector advanced capabilities and includes the following sections:
• Multihoming, page 411
• Segmentation, page 415
• Session Initiation Protocol (SIP), page 422
• Stream Control Transmission Protocol (SCTP), page 424
• Performance Statistics, page 427
• Statistics Monitor, page 455
• Utilities, page 456
Multihoming
This section explains AppDirector Multihoming capability as a solution to load balancing between servers and routers of different ISPs and includes the following topics:
• Default Router Per Virtual IP, page 411
• Using Redirect to Self in Multi-Homed Environments, page 414
The AppDirector Multihoming solution is intended for networks in which AppDirector is connected to multiple ISPs. Using Multihoming, AppDirector can simultaneously use multiple ISPs for inbound traffic. To achieve multihoming AppDirector uses the ability to configure a default router per Virtual IP (VIP NHR) and to redirect to self. Default Router Per Virtual IP
AppDirector allows defining a different default router, and a backup one, for each Virtual IP (including Virtual IP Interfaces) and Outbound NAT addresses. Load sharing can be enabled between the two routers to enable multihoming. The VIP's default router is used for any type of traffic forwarded by the AppDirector from this VIP, or generated by the AppDirector in respect to this VIP, such as: • DNS answers.
• LRP/PRP communication.
• Client proximity checks.
• HTTP redirection instructions.
• Triangulated packets. Note:Static routes cannot be configured per Virtual IP, only the default router can be configured individually for each Virtual IP. Specific static routes are configured globally for AppDirector and take precedence over the default route.
You can set a backup default router for AppDirector. This enables using a backup router for traffic generated by AppDirector that is not farm-related, such as ping, SNMP, or DNS requests, and for traffic related to farms that do not have a default router configured.
AppDirector User Guide
Advanced Capabilities
412 Document ID: RDWR-AD-V0231-UG1105
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 AppDirector using the VIP NHR table. Note:The VIP NHR table is enabled only when the packet is destined for the default gateway of the box but because of the static route, the packet was not destined for the default gateway so in these instances the VIP NHR table is not enabled. The NHR per VIP feature works only for traffic that matches AppDirector's default gateway.
Before defining the VIP NHR table, you need to add a new NHR to the network and set up the general NHR parameters.
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.
Parameter
Description
NHR IP Address Address of the selected NHR.
Administrative Status Enabled
The user-defined management status of the NHR:
• Enabled (Default): NHR is active and ready • Disabled: The NHR is not active.
Check Method The following methods are available:
• Ping: AppDirector pings the desired Path Health Check IP according to the predefined Check Interval and Retries.
• Disabled (Default): When the router Health Check is disabled, AppDirector still checks by sending ARPs to the router's MAC address.
• Health Monitoring Module: NHR is checked using the Health Monitoring module. AppDirector continually sends ARP requests to the NHR to ensure its MAC is correct. If the ARP requests fail, the NHR is labeled ‘Not-in-Service’.
Path Health Check IP AppDirector pings the remote IP via the specified router to make sure the router is healthy and connected to its uplink. If a Path Health Check fails, the relevant router is considered Not in Service.
Default: 0.0.0.0
Check Interval How often AppDirector polls the NHR (in seconds).
Default: 10
Check Retries Number of polling attempts that are made before a NHR is considered inactive.
Default: 3
AppDirector User Guide
Advanced Capabilities
Document ID: RDWR-AD-V0231-UG1105 413
Once the general NHR parameters are defined, you can set up the VIP NHR table parameters. For each Virtual IP, you can configure a default router and a backup router, as shown here. When a default router and a backup router are configured, you can send outgoing traffic through both NHRs simultaneously. AppDirector performs load sharing between the NHRs of the traffic that arrives from the farms, using Hashing on the Source and Destination IP addresses. This ensures that each session uses a single NHR. Note:When a server participates in multiple farms, each with a different NHR, AppDirector makes sure to use a NAT address, which is a VIP address that has an active NHR. This means AppDirector keeps a list of up to three VIPs to which a server belongs. When a NAT address for the server is needed, AppDirector uses only VIPs with an active NHR.
Parameter
Description
VIP Address VIP address on AppDirector for which default gateway is set. This includes Layer 4 Policy addresses, Virtual IP Interface Addresses, etc.
A special entry for Virtual IP 0.0.0.0 is automatically inserted into the VIP NHR table, reflecting the AppDirector default router from the Routing Table.
Default: 0.0.0.0
NHR Weight Weight that AppDirector considers when distributing sessions of the Virtual IP among the NHRs, ensuring that each session uses a single NHR.
Default: 1
Backup NHR IP Address The backup router for this Virtual IP. Default: 0.0.0.0, no NHR is set.
Backup NHR Weight Backup weight that AppDirector considers when it distributes sessions of Virtual IP among the NHRs.
Default: 1
No Route Action If both routers set for a VIP are down, AppDirector behaves as follows:
• Discard: Discards the packet.
• Use Regular Routing (Default): Uses the Routing Table.
NHR Load Sharing Enables/disables load sharing between the primary and backup NHRs, as follows:
• Layer 3 Hashing: Traffic is sent through both primary NHR and backup NHR. Load sharing is based on Layer 3 information (IP addresses).
• Layer 4 Hashing: Traffic is sent through both primary NHR and backup NHR. Load sharing is based on Layer 4 information (IP addresses and ports).
• Disabled (Default): Traffic is sent through primary NHR only.
AppDirector User Guide
Advanced Capabilities
414 Document ID: RDWR-AD-V0231-UG1105
Using Redirect to Self in Multi-Homed Environments Redirect to Self is the ability to redirect clients accessing a VIP to another VIP on the same AppDirector device. The Redirect to Self capability can be used in various configurations and serve various needs. Take, for example, a Multi-homed environment. Farm 1 can redirect requests for service to Farm 2, while Farm 2 redirects to Farm 1, where Farm 1 and Farm 2 are on the same AppDirector, each accessible via a different ISP. Configuration of the Redirect to Self capability in AppDirector is based on defining farms as servers. You can set up a farm using other farms as servers in your farm. The type of server used in this configuration is the LocalFarm server type. The LocalFarm server is another farm on the same AppDirector. When using redirection based on IP addresses, the IP representing the LocalFarm is an IP address that can be accessed by the clients; usually a public IP address. The Redirect to Self capability works with the following redirection methods: DNS, SIP, HTTP, and RTSP. Note:Redirect to Self cannot be used with Global Triangulation. In a Multi-homed environment, the Redirect to Self capability can be utilized to share traffic between multiple ISPs, where AppDirector is directly connected to the access routers of these ISPs. Using this configuration, you can load balance not only between servers, but also between ISP routers. Note:This configuration requires the NHR per VIP feature (see Default Router Per Virtual IP, page 411
).
Example Redirect to Self
For example, AppDirector is connected to two ISPs, where Router 1 is connected to ISP 1, and Router 2 is connected to ISP 2. Two identical farms (containing the same servers) are configured on the AppDirector device, each associated with an IP address that belongs to one of the ISPs and with a default router which is the router of the ISP. Router 1 is the default router of Farm 1, and Router 2 is the default router of Farm 2. Then, Farm 1 is added as a server for Farm 2, and Farm 2 as a server for Farm 1. This enables Farm 1 to redirect clients to VIP 2 representing Farm 2, and vice versa. When a client accesses Farm 1, a server is selected in this farm using the predefined Dispatch Method.
If the server Farm 2 is selected, redirection takes place. Using this configuration, you can achieve load balancing not only between the servers, but also between the routers of the ISPs. This figure illustrates this configuration.
AppDirector User Guide
Advanced Capabilities
Document ID: RDWR-AD-V0231-UG1105 415
Example Multi-homed Environment
This figure presents a regular configuration of a Multi-homed environment where AppDirector is connected to multiple ISPs.
Figure 15: 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.
Segmentation
This section discusses network segmentation using AppDirector and incudes these topics:
• Using Segmentation, page 415
• Segmentation with AppDirector, page 416
Using Segmentation A network segment is a portion of a computer network separated from the rest of the network by a repeater, hub, bridge, switch or router. Each segment can contain one or multiple computers or other hosts. The type of segmentation differs according to the AppDirector used. For example, a bridge separates collision domains, while a router separates both collision domains and broadcast domains. Each network segment supports a single medium access protocol and a predetermined bandwidth. The more hosts on a network segment, the more divided the bandwidth. Crowded network segments lead to congestion, leading to degraded performance. 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.10
AppDirector
VIP:202.2.2.10
VIP:201.1.1.10
201.1.1.20
202.2.2.20
Router 1
Router 2
AppDirector User Guide
Advanced Capabilities
416 Document ID: RDWR-AD-V0231-UG1105
Each network segment can have its own hub or switch. In most cases a contiguous range of IP addresses are assigned to each segment. Segmentation Benefits
• Multiple segments avoid the need to keep hosts on a single, large segment. This can increase the amount of traffic that a network can carry. • Security is another benefit. If an attacker successfully compromises a single computer in a network segment, every computer in that segment is at risk. • You can keep all your hosts on a single network while insulating each part of the network from unauthorized entry. Each segment can be protected from the other segments by using firewalls. Examples of situations in which networks are typically segmented include businesses (e.g., payroll and personnel data are not accessible to ordinary employees), educational institutions (e.g., students are not able to access data about other students or change their grades) and co-location companies (which must keep the networks of the various web sites they host separate). Using Firewalls with Segmentation
Firewalls are used within the infrastructure to protect different segments of the network such as finance, HR and engineering. Using firewalls:
• provides additional layers of access control. • assists attack containment. • protects specific resources, forcing users to authenticate themselves as they move from network to network.
Effective use of network segmentation includes wireless LANs and customer extranets. Setting users in their own segment, behind their own policy-based firewall, allows you to contain the users and limit any potential damage. Segmentation with AppDirector
AppDirector defines a type of logical network entity known as a segment where a single AppDirector load balances the traffic for all segments, but traffic between segments is always inspected by a external inspection device (for example, firewalls, anti-virus device etc.) These logical entities (segments) can be associated either with physical ports (including VLANs and Trunks) or with VLAN Tags. A NHR must be associated with each segment; typically this would be the Firewall interface of that segment. A backup NHR can also be configured for each segment.
Layer 4 policies are also associated with segments, to define the logical location of each VIP. Segmentation is performed when there is a conflict between the segment to which the client belongs and the segment to which the Layer 4 policy belongs. AppDirector directly redirects traffic for a Layer 4 Policy’s VIP only when the traffic arrives from a client in the same segment where this policy resides.
Segmentation can also be performed when there is a conflict between the segment to which the Layer 4 policy belongs and the segment to which the server belongs. This conflict (whether to perform segmentation or not) is configurable by the user.
When AppDirector receives traffic that cannot be handled due to segment conflicts, (meaning the segment over which traffic was received does not match the Layer 4 Policy segment) AppDirector sends this traffic to the NHR of the receiving (clients) segment, while reply traffic is forwarded from the server to the NHR of the Layer 4 policy segment. Using Segmentation, a single AppDirector device connects to multiple segments around the firewall (see Figure 16 - Physical Port Segmentation, page 419
). 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 residing on the same AppDirector. AppDirector User Guide
Advanced Capabilities
Document ID: RDWR-AD-V0231-UG1105 417
Note:On the reply path, the behavior is determined by the non-segment-action parameter.
Default Segments
Physical ports, Trunks and 802.1q VLAN Tags that are not part of any segment are considered to be members of a default segment. No specific NHR is defined for the default segment, but the default gateway belongs to the default segment.
Traffic from a client belonging to segment A to a destination belonging to the default segment (server or VIP) will be redirected via segment A NHR. However the reply will be redirected according to the Default Segment Operating Method. This can cause undesirable asymmetric routing so please check your parameter configuration.
Note:If you want to allow asymmetric routing, on an OnDemand Switch 3 platform, the Session Table must be disabled in order for the traffic to be correctly routed.
To configure Segmentation
1. Enable Segmentation and configure default segment behavior
2. Configure Segments and attach NHRs.
Note:The AppDirector default gateway can only belong to the default segment.
Segmentation Configuration To set the Segmentation Global Parameters 1.From the AppDirector menu, select Segmentation > Global Parameters. The Segmentation Global Parameters window is displayed.
2.Set the parameters.
Parameter
Description
Segmentation Operating Method
Select the operating method, from one of the following:
• Ports: Segmentation is enabled and is based on the devices physical ports, trunks or VLAN interfaces.
• VLAN Tag: Segmentation is enabled and based on the 802.1q environment. When the VLAN Tag mode is in use, the 8021q environment must be enabled and the VLAN Tag Handling parameter must be set to Overwrite.
• Disable (default): The feature is disabled.
Shared Ports The shared ports list. The device will not perform segmentation on any sessions from or to these ports.
AppDirector User Guide
Advanced Capabilities
418 Document ID: RDWR-AD-V0231-UG1105
3.Click ...
next to Shared Ports. The Arguments for Port List window is displayed as shown here.
4.Mark port check boxes as required.
5.Click Set. You are returned to the Segment Table window.
6.Click Set. Your configuration is set.
Segment Table
Segmentation is the division of a network into logical segments, where a single AppDirector load balances the traffic so that all segments can be inspected by a firewall. The Segment Table allows you to create segments and associating physical ports, VLANs Trunks or 802.1q VLAN Tags to the segment. Physical Port Segmentation
Segmentation can be configured using physical ports, as shown here.
Default Segment Operating Method
Physical ports, Trunks and 802.1q VLAN Tags that are not part of any segment are considered to be members of a default segment. You can configure the behavior of traffic from a port/tag that is not a member of any segment and is destined to a port/tag that is a segment member. Select the Default Segment Operating Method, from one of these:
• Forward (Handling without Segmentation): Forwards traffic to destination (not via Firewall)- as if Segmentation was disabled.
• Discard: Discards the traffic.
• Default Gateway (Handling with Segmentation if necessary)- (Default): Forwards the traffic to the AppDirector Default gateway with Segmentation if necessary.
Notes:
• Traffic from a shared port to a VIP (LB) or directly to a server (Routing) will be sent directly.
• Load balancing to a VIP and the selected server is on a shared port - the shared port is unrelated in this scenario. Default Segment Shared VIP
When this parameter is enabled, segmentation is not performed for traffic from clients belonging to different segment to VIPs belonging to the default segment. However segmentation will be always performed on traffic from clients belonging to different segment to servers belonging to the default segment (routed traffic).
AppDirector User Guide
Advanced Capabilities
Document ID: RDWR-AD-V0231-UG1105 419
Figure 16: Physical Port 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
AppDirector User Guide
Advanced Capabilities
420 Document ID: RDWR-AD-V0231-UG1105
VLAN Tag Segmentation
Segmentation can be also be configured using VLAN tags, as shown here. Figure 17: VLAN Tag Segmentation
Note:Sometimes you need to use a single AppDirector device to load balance multiple farms, each located on a different segment around a firewall. In such cases, AppDirector must ensure that all traffic between segments passes through the firewall. Backend Segmentation
Backend Segmentation is an override that should be used when the server is not within the same segment that is associated with the Layer 4 Policy and the client sends traffic to the VIP (for load balancing).
To define the parameters of the Segment Table
1.From the AppDirector menu select Segmentation > Segment Table. The View Filters window is displayed.
2.Click Create. The Segment Table Create window is displayed.
3.Set the parameters.
Parameter
Description
Segment Name Enter a name for the new segment.
Port List Allows you to associate physical ports, Trunk Interfaces and/or VLAN interfaces with the segment.
VLAN Tag List VLAN Tags associated with this segment.
Shared VIP When this parameter is enabled, segmentation is not performed for traffic from clients belonging to different segment to VIPs belonging to this segment. However segmentation will be always performed on traffic from clients belonging to different segment to servers belonging to this segment (routed traffic).
Firewall
Clients
DMZ 1
VIP 1
DMZ 2
VIP 2
Tag 20
Tag 10
AppDirector
AppDirector User Guide
Advanced Capabilities
Document ID: RDWR-AD-V0231-UG1105 421
4.Click ...
next to Port List. The Arguments for Port List window is displayed as shown here.
5.Mark port check boxes as required.
6.Click Set. You are returned to the Segment Table window.
7.Click Set. Your configuration is set.
Segmentation NHR
The Segmentation NHR Table is used to assign and update next hop routers to segments. A NHR must be associated with each segment; typically this would be the Firewall interface of that segment. When AppDirector receives traffic that cannot be handled due to segment conflicts (i.e., the segment over which traffic was received does not match the segment over which traffic should be forwarded), AppDirector sends this traffic to the NHR of the receiving segment
To assign a NHR to a segment
1.From the AppDirector menu select Segmentation > Segment NHR. The Segmentation NHR window is displayed.
2.Click Create. The Segment NHR Table Create window is displayed
3.Set the parameters.
Backend Segmentation
This parameter defines behavior when Layer 4 Policy (VIP) and server providing service to this VIP belong to different segments.
• Enabled (default): Performs segmentation (forward traffic to Layer 4 Policy segment NHR).
• Disabled: Forwards traffic directly to server. Parameter
Description
Segment Name Select the segment name from the dropdown list.
No Route Action Allows you to configure AppDirector behavior when both the main and backup NHRs are down. Values:
• Discard (default): Discards the traffic
• Use Regular Routing: Sends traffic according to the regular route
NHR Weight Configure a weight for each NHR.
Default: 1
Backup NHR Weight Define a backup weight for the NHR.
Default: 1
NHR IPv4 Address The IP V4 address type of Next Hop Router.
AppDirector User Guide
Advanced Capabilities
422 Document ID: RDWR-AD-V0231-UG1105
4.Click Set. Your configuration is set.
To update a segment NHR
1.From the AppDirector menu select Segmentation > Segment NHR. The Segmentation NHR window is displayed.
2.Select the desired segment name. The Segment NHR Table Update window is displayed
3.Set the parameters as shown above.
4.Click Set. Your configuration is set.
Session Initiation Protocol (SIP)
This explains SIP server load balancing and client-server persistency and includes these topics:
• SIP Load Balancing with AppDirector, page 423
• Farm Selection Based on SIP Parameters, page 423
• Load Balancing SIP Servers, page 423
• Outbound SIP Sessions, page 423
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, for example what IP ports to use, the codec being used etc. All voice/video communications are done over separate session protocols, usually RTP.
NHR IPv6 Address The IP V6 address type of Next Hop Router.
Backup NHR IPv4 Address
The IP V4 address of the Backup to Next Hop Router
Backup NHR IPv6 Address
The IP V4 address of the Backup to Next Hop Router
NHR Load Sharing Enabling NHR Load Sharing sends outgoing traffic through both NHRs at the same time.
Default: Disabled
Parameter
Description
AppDirector User Guide
Advanced Capabilities
Document ID: RDWR-AD-V0231-UG1105 423
SIP Load Balancing with AppDirector
AppDirector provides the following support for load balancing SIP traffic:
• Application-aware farm selection for SIP over UDP (Layer 7 policies).
• Application-aware server persistency for SIP over UDP, see SIP Persistency, page 284
.
Note:For SIP over TCP, AppDirector offers Layer 4 farm selection and server persistency, and application specific health check
Farm Selection Based on SIP Parameters
AppDirector can be used to provide Layer 7 farm selection based on SIP header data for SIP over UDP. The same Layer 7 methods for HTTP can be used for SIP. Using Layer 7 policies, you can select different farms based on different parameters.
For example, one farm can handle all the SIP Registration and a second farm handles the SIP call setup and termination. Layer 7 policies allow redirection of the session when a specific policy is matched. This can be done using the 302 return status code.
Load Balancing SIP Servers
In SIP protocol, IP addresses can be embedded in SIP headers and SDP data. This poses a problem when load balancing SIP traffic. The SIP server that handles the traffic will respond using its own IP address in the SIP data. Since the client who sent the traffic to AppDirector expects an answer at the SIP level (not UDP level) from VIP, this will cause the SIP session to fail.
Here are a few available options for solving this issue:
1.Define the SIP servers as Local Triangulation servers in AppDirector.
a.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.
Note:The network configuration does not need to be Local Triangulation - response traffic can return via AppDirector, (AppDirector must be the default gateway for the servers).
2.Define the SIP servers as Regular servers in AppDirector.
a.On each SIP server, there is a physical IP interface. Configure a second IP interface using the SIP service VIP. This can be configured on the physical adapter, a loopback adapter or a virtual adapter.
b.Bind the SIP application to this interface, instead of the physical IP interface.
c.AppDirector sends traffic to the physical address of the server and the server will use this address inside the SIP payload in the answer.
SIP sessions always load balance with servers per session, even if you define eps/regular sessions mode on the farm. Outbound SIP Sessions
Outbound SIP sessions must use Server NAT to hide server IP address behind service IP (VIP). Since all sessions from servers within the SIP farm are forwarded using the same IP address as a Source IP and the same source port, AppDirector needs a special process to return the traffic to the initiator server. AppDirector User Guide
Advanced Capabilities
424 Document ID: RDWR-AD-V0231-UG1105
Dynamic Sessions ID must be used, and the Learning Direction must be set to “Both Directions.” Then, AppDirector returns the traffic based on any of the SIP headers, such as Call-ID. All traffic is routed via AppDirector when using such configurations. Support for Outbound SIP sessions has a performance impact. To prevent this, the feature must be activated by flagging Outbound SIP only when required (disabled by default). This flag is available in WBM via AppDirector/Global/Tweaks window, (see Configuring AppDirector Advanced Global Parameters, page 311
) and in CLI via appdirector global outbound-sip
command.
The Layer 4 Policy can either use port 5060 and UDP as the Layer 4 Protocol or specify SIP as the application. Notes:Please note that when Outbound SIP traffic needs to be supported the following requirements must be met:
>> Servers from which outbound traffic is sent can only belong to farms that are attached to a SIP Layer 4 policy - to ensure a SIP service VIP is used as Server NAT. >> If Layer 7 load balancing is used (for the inbound SIP Layer 4 policies), DSID must be
enabled for all the farms that belong to that Layer 7 policy.
Stream Control Transmission Protocol (SCTP)
Stream Control Transmission Protocol (SCTP) is a Transport Layer protocol, serving in a similar role to the popular protocols Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). It provides some of the same service features, ensuring reliable, in-sequence, transport of messages with congestion control. In the absence of native SCTP support in operating systems you can tunnel SCTP over UDP, and map TCP API calls to SCTP ones.
SCTP is a reliable transport protocol operating on top of a potentially unreliable connectionless packet service such as IP. It offers acknowledged error-free non-duplicated transfer of datagrams (messages). Detection of data corruption, loss of data and duplication of data is achieved by using checksums and sequence numbers. A selective retransmission mechanism is applied to correct loss or corruption of data.
The decisive difference from TCP is multi-homing and the concept of several streams within a connection. In TCP, a stream is referred to as a sequence of bytes, but in a SCTP, a stream represents a sequence of messages (and these may be very short or long).
SCTP can be used as the transport protocol for applications where monitoring and detection of loss of session is required. For such applications, the SCTP path/session failure detection mechanisms, especially the heartbeat, will actively monitor the connectivity of the session. An SCTP association looks like this, so the services of SCTP are naturally at the same layer as TCP or UDP services
AppDirector User Guide
Advanced Capabilities
Document ID: RDWR-AD-V0231-UG1105 425
Figure 18: Diagram showing the concept of an SCTP association
:
We define a single-home SCTP association as a connection between two single IP addresses. A multi-home SCTP association is a connection between multiple addresses. Both client and server can supply additional addresses on top of the one that is carried in the L3 header.
The client sends the additional IP addresses in the INIT packet while the server sends the additional IP addresses in the INIT-ACK packet. When NAT is performed for SCTP the INIT and INIT-ACK packets should be updated and the SCTP association should be supported.
SCTP Load Balancing with AppDirector
AppDirector supports Layer 4 load balancing for SCTP. The following SCTP communication types are supported:
• Single-homed SCTP
• Multi-homed SCTP
• NAT for outbound SCTP
Note:Layer 7 load balancing is not supported for SCTP. Single-homed SCTP
A single-home SCTP association is a connection between two single IP addresses.
To support single-homed Layer 4 load balancing, the following configuration is required in the Layer 4 policy:
• Protocol set to SCTP
• Application set to SCTP
Multi-homed SCTP
A multi-homed SCTP association is a connection between multiple addresses belonging to the same entities. Both client and server can supply additional addresses on top of the one that is carried in the L3 header.
AppDirector User Guide
Advanced Capabilities
426 Document ID: RDWR-AD-V0231-UG1105
The client sends the additional IP addresses in the INIT packet while the server sends the additional IP addresses in the INIT-ACK packet.
To support multi-homed association for inbound traffic the following configuration is required:
• A farm with with one regular server and one backup server for each external link
• Layer 4 policy with VIP for each external link:
— Protocol set to SCTP
— Application set to MH-SCTP
The SCTP server answers with multiple internal IP addresses in the INIT-ACK message (a server IP from each farm). AppDirector must NAT all addresses to their respective VIPs (VIP to each each server is associated).
Note:Sessions Mode Regular and Client NAT cannot be used for multi-homed SCTP associations.
Outbound SCTP
For outbound SCTP traffic AppDirector can NAT all the IP addresses that appear in the INIT message. See also Outbound NAT Addresses, page 306
.
To configure NAT for outbound SCTP
1.Configure Outbound NAT range with NAT Mode set to SCTP NAT.
2.Configure Outbound NAT Intercept range that includes the SCTP servers and connect to the appropriate Outbound NAT range. The two ranges must have the same size.
Note:Outbound NAT is performed only for SCTP traffic initiated by servers that are defined as farm servers on AppDirector.
AppDirector User Guide
Advanced Capabilities
Document ID: RDWR-AD-V0231-UG1105 427
Performance Statistics
This section discusses general performance indicators (statistics) and includes the following topics: • Acceleration Engine Statistics, page 427
• Last Second Statistics, page 443
• Element Statistics, page 444
• IP Interface Statistics, page 447
• Servers, page 449
• AppDirector Statistics, page 452
• Protocol Statistics, page 453
Acceleration Engine Statistics
You also have the ability to take a comprehensive view of monitoring and statistics information through the WBM. Acceleration engine data is shown in aggregated tables that facilitate a quick check on the Acceleration Engine status and value. Using these statistics tables, you can drill down to a specific interface, Layer 4 Policy or Rule-list rules. Notes:
>> All Views are set to refresh automatically according to the refresh rate specified in configuration view.
>> In WBM, all statistics pages allow you to filter for viewing only specific items.
>> The configurable statistics measuring period and WBM view Auto-refresh time are shown at the bottom of each statistics window. To edit go to Configuration, page 441
.
Throughput Summary
From the Performance menu, select Acceleration > Throughput> Summary. The Acceleration Engine Throughput Summary window is displayed with these read-only parameters:
Parameter
Description
Client Side Throughput • Mbits In - Average of incoming traffic from clients into the Acceleration Engine per second.
• Mbits Out - Average of outgoing traffic towards clients from the Acceleration Engine per second.
• Total (In + Out) - Average of total clients related traffic going in both ways through the Acceleration Engine per second.
Server Side Throughput • Mbits In - Average of incoming traffic from servers into the Acceleration Engine per second.
• Mbits Out - Average of outgoing traffic towards servers from the Acceleration Engine per second.
• Total (In + Out) - Average of total servers related traffic going in both ways through the Acceleration Engine per second.
AppDirector User Guide
Advanced Capabilities
428 Document ID: RDWR-AD-V0231-UG1105
Throughput per Layer 4 Policy
From the Performance menu, select Acceleration > Throughput> Per L4 Policy. The Acceleration Engine Throughput Per L4 Policy window is displayed with these read-only parameters:
Notes:
>> Statistics shown for all Layer 4 policies also include their Acceleration capabilities, i.e. their traffic flows through Acceleration Engine. A Layer 4 policy that does not include xny Acceleration policy (SSL, Cache, compression, Multiplexing) will not show this view.
>> When more then one Layer 4 Policy shares a farm, the Layer 4 Policy statistics are not accurate because they are taken per farm and not per Layer 4 Policy.
Total Throughput • Mbits In - Average of incoming traffic coming into the Acceleration Engine per second.
• Mbits Out - Average of outgoing traffic from the Acceleration Engine per second.
• Total (In + Out) - Average of total traffic going in both ways through the Acceleration Engine per second.
Parameter
Description
Client Side Throughput • Mbits In - Average of incoming traffic from clients into the Acceleration Engine per second per Layer 4 policy.
• Mbits Out - Average of outgoing traffic towards clients from the Acceleration Engine per second per Layer 4 policy.
• Total (In + Out) - Average of total clients related traffic going in both ways through the Acceleration Engine per second per Layer 4 policy.
Server Side Throughput • Mbits In - Average of incoming traffic from servers into the Acceleration Engine per second per Layer 4 policy.
• Mbits Out - Average of outgoing traffic towards servers from the Acceleration Engine per second per Layer 4 policy.
• Total (In + Out) - Average of total servers related traffic going in both ways through the Acceleration Engine per second per Layer 4 policy.
Total Throughput • Mbits In - Average of incoming traffic coming into the Acceleration Engine per second per Layer 4 policy.
• Mbits Out - Average of outgoing traffic from the Acceleration Engine per second per Layer 4 policy.
• Total (In + Out) - Average of total traffic going in both ways through the Acceleration Engine per second per Layer 4 policy.
Parameter
Description
AppDirector User Guide
Advanced Capabilities
Document ID: RDWR-AD-V0231-UG1105 429
Connections Summary
From the Performance menu, select Acceleration > Connections> Summary. The Acceleration Engine Connections Statistics Summary window is displayed. Parameter
Description
Client Side Concurrent Connections Current Number of clients concurrent connections held by Acceleration Engine.
Client Side New Connections Counted Number of new clients connections opened by Acceleration Engine every measuring period.
Server Side Concurrent Connections Current Number of concurrent servers connections held by Acceleration Engine.
Server Side New Connections Counted Number of new servers connections opened by Acceleration Engine every every measuring period.
Total Concurrent Connections Total Counted Number of clients connections opened by Acceleration Engine every second.
Total New Establish Connections Total Counted Number of new clients connections opened by Acceleration Engine every second.
Connections Multiplexing Percentage (Server/Client Connections) Percentage of number of clients connections and server connections that shows how well the Acceleration Engine decreases the connection load on servers at the time of measuring (instantaneous measuring).
New Connections Establishing Rate (Conn/Sec) Average number of connections opened to/ by Acceleration Engine per second.
AppDirector User Guide
Advanced Capabilities
430 Document ID: RDWR-AD-V0231-UG1105
Connections per Layer 4 Policy
From the Performance menu, select Acceleration > Connections> Summary. The Acceleration Engine Connections Statistics Per L4 Policy window is displayed.
Note:Statistics shown for all Layer 4 policies also include their Acceleration capabilities, i.e. their traffic flows through Acceleration Engine. A Layer 4 policy that does not include any Acceleration policy (SSL, Cache, compression, Multiplexing) will not show this view.
HTTP Requests Summary
From the Performance menu, select Acceleration > HTTP> Requests And Responses >Summary. The Acceleration Engine HTTP Requests Summary window is displayed.
Parameter
Description
Client Side Connections Concurrent Current Number of clients concurrent connections held by Acceleration Engine per Layer 4 policy.
New Counted Number of new clients connections opened by Acceleration Engine every second per Layer 4 policy.
Server Side Connections Concurrent Current Number of concurrent servers connections held by Acceleration Engine per Layer 4 policy.
New Counted Number of new servers connections opened by Acceleration Engine every second per Layer 4 policy.
Total Connections Concurrent Total Counted Number of clients connections opened by Acceleration Engine every second per Layer 4 policy.
New Total Counted Number of new clients connections opened by Acceleration Engine every second per Layer 4 policy.
Multiplexing Percentage Percentage of the number of clients connections and server connections that shows how well the Acceleration Engine decreases the connection load on servers at the time of measuring (instantaneous measuring) per Layer 4 policy.
New Connections/Sec Average number of new connections opened by Acceleration Engine per second per Layer 4 policy.
Parameter
Description
Requests - Clients > AppDirector Number of clients requests from AppDirector done in the measuring period.
Requests - AppDirector > Servers Number of AppDirector requests from Servers done in the measuring period .
Responses - Servers > AppDirector Number of Servers responses to AppDirector in the measuring period.
Responses - AppDirector > Clients Number of AppDirector responses to Clients in the measuring period.
HTTP Transaction Rate Transactions per seconds rate calculated by total number of transactions divided by measuring period.
AppDirector User Guide
Advanced Capabilities
Document ID: RDWR-AD-V0231-UG1105 431
HTTP Requests per Layer 4 Policy
From the Performance menu, select Acceleration > HTTP> Requests And Responses >Per L4 Policy. The Acceleration Engine HTTP Requests Per L4 Policy window is displayed.
Note:Statistics shown for all Layer 4 policies also include their Acceleration capabilities, i.e. their traffic flows through Acceleration Engine. A Layer 4 policy that does not include any Acceleration policy (SSL, Cache, compression, Multiplexing) will not show this view.
Parameter
Description
L4 Policy Name of L4 Policy for which this row shows statistics. Requests Clients -> AE Number of clients requests from AppDirector done in the measuring period per Layer 4 policy.
AE -> Servers Number of AppDirector requests from Servers done in the measuring period per Layer 4 policy.
Responses Clients -> AE Number of Servers responses to AppDirector in the measuring period per Layer 4 policy.
AE -> Servers Number of AppDirector responses to Clients in the measuring period per Layer 4 policy.
Transaction/Sec.Transactions per seconds rate calculated by total number of transactions divided by measuring period per Layer 4 policy.
AppDirector User Guide
Advanced Capabilities
432 Document ID: RDWR-AD-V0231-UG1105
HTTP Statistics Summary
From the Performance menu, select Acceleration > HTTP> Statistics >Summary. The Acceleration Engine HTTP Statistics Summary window is displayed.
Parameter
Description
Clients Using Keep-Alive Number of clients counted sending "Connection: Keep-
Alive" HTTP Header or Using HTTP 1.1.
HTTP 1.0 Percentage Percent of requests done using HTTP 1.0 during measuring period.
HTTP 1.1 Percentage Percent of requests done using HTTP 1.1 during measuring period.
Number of HTTP to HTTPS redirections Number of HTTP redirect location headers updated from HTTP to HTTPS by AppDirector.
Average Number of Requests per Connection Average number of requests done over each client connection calculated by total number of client request divided by number of clients side connections.
Number of responses smaller than 1KB Number of Responses for which content size reported smaller than 1KB.
Number of responses 1KB - 10KB Number of Responses for which content size reported between 1KB and 10KB.
Number of responses 11KB - 50KB Number of Responses for which content size reported between 11KB and 50KB.
Number of responses 51KB - 100KB Number of Responses for which content size reported between 51KB and 100KB.
Number of responses larger than 100KB Number of Responses for which content size reported larger than 100KB.
AppDirector User Guide
Advanced Capabilities
Document ID: RDWR-AD-V0231-UG1105 433
HTTP Statistics per Layer 4 Policy
From the Performance menu, select Acceleration > HTTP> Statistics >L4 Per Policy. The Acceleration Engine HTTP Statistics Per L4 Policy window is displayed.
Note:Statistics shown for all Layer 4 policies also include their Acceleration capabilities, i.e. their traffic flows through Acceleration Engine. A Layer 4 policy that does not include any Acceleration policy (SSL, Cache, compression, Multiplexing) will not show this view.
SSL Statistics Summary
From the Performance menu, select Acceleration > SSL> Statistics Summary. The Acceleration Engine SSL Statistics Summary window is displayed.
Parameter
Description
L4 Policy Name of Layer 4 Policy for which this row shows statistics.
Clients Using Keep Alive Number of clients counted sending "Connection: Keep-
Alive" HTTP Header or Using HTTP 1.1 per Layer 4 Policy.
HTTP 1.0 v 1.1 Percentage Percentage of the number of HTTP statistics per Layer 4 policy.
HTTP to HTTPS Redirections Number of HTTP redirect location headers updated from HTTP to HTTPS by AppDirector per Layer 4 policy.
Average Requests/Connection Average number of requests done over each client connection calculated by total number of client request divided by number of clients side connections per Layer 4 policy.
Number of responses per Content size Smaller than 1KB
Number of Responses for which content size reported smaller than 1KB per Layer 4 policy.
1KB - 10KB Number of Responses for which content size reported between 1KB and 10KB per Layer 4 policy.
11KB - 50KB Number of Responses for which content size reported between 11KB and 50KB per Layer 4 policy.
51KB -
100KB Number of Responses for which content size reported between 51KB and 100KB per Layer 4 policy.
Larger than 100KB Number of Responses for which content size reported larger than 100KB per Layer 4 policy.
Parameter
Description
New SSL handshake (Session/Sec) Number of New SSL handshakes between Clients and AppDirector per second.
Reused SSL sessions (Session/
Sec) Number of Existing SSL Handshakes reused by clients to communicate with AppDirector per second.
Reused SSL sessions (%) Percentage of SSL session reusing keys.
SSLv2 Percentage Percentage of session using SSLv2 out of all session during measuring period.
AppDirector User Guide
Advanced Capabilities
434 Document ID: RDWR-AD-V0231-UG1105
SSL Statistics per Layer 4 Policy
From the Performance menu, select Acceleration > SSL> Statistics per L4 Policy. The Acceleration Engine SSL Statistics Per L4 Policy window is displayed.
Note:Statistics displayed for all Layer 4 policies also includes their Acceleration capabilities, (their traffic flows through Acceleration Engine). A Layer 4 policy that does not include any Acceleration policy (SSL, Cache, compression, Multiplexing) does not show this view.
Cache Summary
From the Performance menu, select Acceleration > Cache > Summary. The Cache Summary window is displayed.
SSLv3 Percentage Percentage of session using SSLv3 out of all session during measuring period.
TLS Percentage Percentage of session using TLS out of all session during measuring period.
Parameter
Description
Name Name of L4 Policy for which this row shows statistics.
New Handshakes/Sec Number of New SSL handshakes between Clients and AppDirector per second per Layer 4 policy.
Reused Sessions /Sec Number of Existing SSL Handshakes reused by clients to communicate with AppDirector per second per Layer 4 policy.
Reused Session Percentage Percentage of SSL session reusing keys per Layer 4 policy.
SSL V2 Percentage Percentage of session using SSLv2 out of all session during measuring period per Layer 4 policy.
SSL V3 Percentage Percentage of session using SSLv3 out of all session during measuring period per Layer 4 policy.
TLS Percentage Percentage of session using TLS out of all session during measuring period per Layer 4 policy.
Parameter
Description
Number of Objects Served from Cache Number of Objects served by cache within the measuring period.
Cache Hits Percentage Percent of HTTP requests served by objects from cache.
Cache Serving Rate (Requests/
Second) Rate of requests served by cache every second, calculated by total number of requests served by cache divided by measuring period.
Number of New Cached objects Amount of new objects cached by size during the measuring period.
Object Caching Rate (Requests/
Second) Average number of objects cached by size every second calculated by amount of new cached objects divided by measuring period.
Parameter
Description
AppDirector User Guide
Advanced Capabilities
Document ID: RDWR-AD-V0231-UG1105 435
New Cached Bytes Amount of new bytes cached by size during the measuring period.
Byte Caching Rate (Bytes/
Second) Average number of bytes cached every second calculated by amount of new bytes objects divided by measuring period.
Objects of Size Smaller than 10KB Amount of objects cached by size during last measuring period of Average size smaller than 10KB.
Objects of Size 11KB-100KB Amount of objects cached by size during last measuring period of Average size between 11KB and 100KB.
Objects of Size 101KB-1MB Amount of objects cached by size during last measuring period of Average size between 101KB and 1MB
Objects of Size Larger than 1MB Amount of objects cached by size during last measuring period of Average size larger than 1MB.
Number of Pages Processed for Dynamic Caching Number of pages processed for dynamic caching. Number of Objects Set for Dynamic Caching Number of objects set for dynamic caching. Number of Objects Revalidated with Server Number of objects revalidated with server. Parameter
Description
AppDirector User Guide
Advanced Capabilities
436 Document ID: RDWR-AD-V0231-UG1105
Cache Rates per Layer 4 Policy Summary
From the Performance menu, select Acceleration > Cache > Rates per L4 Policy. The Cache Rates Per L4 Policy window is displayed.
Note:Statistics shown for all Layer 4 policies also include their Acceleration capabilities, i.e. their traffic flows through Acceleration Engine. A Layer 4 policy that does not include any Acceleration policy (SSL, Cache, compression, Multiplexing) will not show this view.
Parameter
Description
Name Name of L4 Policy for which this row shows statistics.
Number of Objects Served Number of Objects served by cache within the measuring period per Layer 4 Policy.
Cache Hits% Percent of HTTP requests served by objects from cache per Layer 4 Policy.
Cache Requests/Sec Rate of requests served by cache every second, calculated by total number of requests served by cache divided by measuring period per Layer 4 Policy.
New Cached Objects Amount of new objects cached during the measuring period per Layer 4 Policy.
Objects/sec Cached Average number of objects cached every second calculated by amount of new cached objects divided by measuring period per Layer 4 Policy.
New Cached Bytes Amount of new bytes cached during the measuring period per Layer 4 Policy.
Bytes/Sec Cache Average number of bytes cached every second calculated by amount of new bytes objects divided by measuring period per Layer 4 Policy.
Pages Processed for Dynamic Caching
Number of pages processed for dynamic caching.
Objects Set for Dynamic Caching Number of objects set for dynamic caching.
Objects Revalidated with Server Number of objects revalidated with server.
AppDirector User Guide
Advanced Capabilities
Document ID: RDWR-AD-V0231-UG1105 437
Cache Statistics per Layer 4 Policy
From the Performance menu, select Acceleration > Cache > Statistics per L4 Policy. The Cache Statistics per L4 Policy window is displayed.
Note:Statistics shown for all Layer 4 policies also include their Acceleration capabilities, i.e. their traffic flows through Acceleration Engine. A Layer 4 policy that does not include any Acceleration policy (SSL, Cache, compression, Multiplexing) will not show this view.
Cache URL-Exceptions Rule-Lists
From the Performance menu, select Acceleration > Cache > URL- Exceptions > Rule-Lists Statistics. The Cache URL-Exceptions Rule-Lists Statistics window is displayed.
Cache URL Rule-List per Rule From the Performance menu, select Acceleration > Cache > URL- Exceptions > Rule-Lists per-
Rule Statistics. The Cache URL-Exceptions Rule-Lists per-Rule Statistics window is displayed.
Parameter
Description
Name Name of L4 Policy for which this row shows statistics.
Objects of Average Size Smaller than 10K Amount of objects cached by size during last measuring period of Average size smaller than 10KB per Layer 4 policy.
11KB - 100KB Amount of objects cached by size during last measuring period of Average size between 11KB and 100KB per Layer 4 policy.
101KB - 1MB Amount of objects cached by size during last measuring period of Average size between 101KB and 1MB per Layer 4 policy.
Larger than 1MB Amount of objects cached by size during last measuring period of Average size larger than 1MB per Layer 4 policy.
Parameter
Description
Name Name of Layer 4 Policy for which this row shows statistics.
Cached Objects Number of objects cached per URL Exceptions policy.
Cached Bytes Number of bytes cached per URL Exceptions policy.
Parameter
Description
Rule List Name There are multiple rule-lists. Each is a “policy” that contains multiple rules.
Rule Name Name of each rule in the Rule-List used to identify it.
Rule Priority Location of the rule in the Rule-List. Since Rule-Lists are scanned for a match from top (priority 1) to bottom (priority ~65000) this enables to set the location of the rule in the rule-list. See Leveraging Rule List Behavior, page 236
on how to use the priority efficiently.
Cached Objects
Number of objects cached as a result of matching the rule.
Cached Bytes Number of bytes cached as a result of matching the rule.
AppDirector User Guide
Advanced Capabilities
438 Document ID: RDWR-AD-V0231-UG1105
Notes:
>> You can use URL files to specify folders or file types to be cached or not cached. You can do this by entering a string in the URL filed containing only the file extension or folder name. >> If these strings appear elsewhere in the URL, they will also be matched.
Cache Content You can download a file containing the entire list of objects residing in cache at download time.
1.From the Performance menu, select Acceleration > Cache > Cache Content. The Acceleration Engine Cache Object-List window is displayed.
2.To save the file listing all cache content, select Save Cache Dump file.
3.A dialog box is displayed asking you if you wish to open or save the Cache Dump file.
4.If you click Open, a Microsoft Excel .csv file will open displaying the following parameters:
5.If you click Save, you are prompted to save a .csv file in the following default format:
yyyy-mm-dd-hh-mm-ss_cache_dump_file.csv
based on your current device system time.
Compression Summary
From the Performance menu, select Acceleration > Compression > Summary. The Compression Summary window is displayed.
Parameter
Description
URL Object’s full URI path.
Size (KB) Size of the cached object.
Chunked Is the stored object chunked?
Values: Yes/No.
The same object can be cached more than once in a chunked copy and unchunked copy.
Compressed Is the stored object compressed?
Values: Yes/No.
Last Access Date/Time of last access to objects.
Parameter
Description
Uncompressed Throughput (Kbps) Total Throughput of compressible objects before compression counted during measuring period. Average Uncompressed Object Size (Kbps) Average object size before compression.
Compressed Throughput (Kbps) Total Throughput of compressible objects after compression counted during measuring period.
Average Compressed Object Size (Kbps) Average object size after compression.
Average Compression Percentage (%)
Average compression percentage during measuring period calculated by average uncompressed size divided by average compressed size.
AppDirector User Guide
Advanced Capabilities
Document ID: RDWR-AD-V0231-UG1105 439
Compression Statistics per Layer 4 Policy From the Performance menu, select Acceleration > Compression > Statistics per L4 Policy. The Compression Statistics Per L4 Policy window is displayed.
Note:Statistics shown for all Layer 4 policies also include their Acceleration capabilities, i.e. their traffic flows through Acceleration Engine. A Layer 4 policy that does not include any Acceleration policy (SSL, Cache, compression, Multiplexing) will not show this view.
Compression URL- Exceptions Rule-Lists From the Performance menu, select Acceleration > Compression > URL - Exceptions > Rule-
Lists Statistics. The Compression URL-Exceptions Rule-Lists Statistics window is displayed.
Parameter
Description
Name Name of Layer 4 Policy for which this row shows statistics.
Uncompressed Throughput (Kbps)
Total Throughput of compressible objects before compression counted during measuring period per Layer 4 Policy.
Average Uncompressed Size (Kbps)
Average object size before compression per Layer 4 Policy.
Compressed Throughput (Kbps) Total Throughput of compressible objects after compression counted during measuring period per Layer 4 Policy.
Average Compressed Size (Kbps)
Average object size after compression per Layer 4 Policy
Compression Percentage The compression percentage is measured by ((Server Side Objects accumulative size) – (Client Side Objects accumulative size))*100/(Server Side Objects accumulative size); for example 1MB received from server 400KB sent to client = 60% compression by (1000-400)*100/1000.
Parameter
Description
Name Name of Compression’s URL Exception Policy for which this row shows statistics.
Matched Objects Number of objects matched during measuring period by the URL Exception Policy for which this row shows statistics.
Size Before Compression Total uncompressed size of objects matched during measuring period by the URL Exception Policy for which this row shows statistics.
Size After Compression Total compressed size of objects matched during measuring period by the URL Exception Policy for which this row shows statistics.
AppDirector User Guide
Advanced Capabilities
440 Document ID: RDWR-AD-V0231-UG1105
Compression URL- Exceptions Rule-List per Rule From the Performance menu, select Acceleration > Compression > URL- Exceptions > Rule-
List per Rule Statistics. The Compression URL-Exceptions Rule-List per Rule Statistics window is displayed.
Notes:
>> You can use URL files to specify folders or file types to be compressed or not compressed. You can do this by entering a string in the URL filed containing only the file extension or folder name. >> If these strings appear elsewhere in the URL, they will also be matched.
Compression Browser-Exceptions Rule-Lists From the Performance menu, select Acceleration > Compression > Browser - Exceptions > Rule-Lists Statistics. The Compression Browser-Exceptions Rule-Lists Statistics window is displayed.
Parameter
Description
Rule List Name There are multiple rule-lists. Each Rule-List is a “policy” that contains multiple rules.
Rule Name Name of each rule in the Rule-List used to identify it.
Rule Priority Location of the rule in the Rule-List. Since Rule-Lists are scanned for a match from top (priority 1) to bottom (priority ~65000) this enables to set the location of the rule in the rule-list. See Leveraging Rule List Behavior, page 236
on how to use the priority efficiently.
Matched Objects Number of objects matched by this rule during measuring period.
Size Before Compression
Total size of all matched objects before compression.
Size After Compression Total size of all matched objects after compression.
Compression Percentage Compression percentage per rule.
Parameter
Description
Name Name of Compression’s URL Exception Policy for which this row shows statistics.
Matched Objects Number of objects matched during measuring period by the URL Exception Policy for which this row shows statistics.
Size Before Compression Total uncompressed size of objects matched during measuring period by the URL Exception Policy for which this row shows statistics.
Size After Compression Total compressed size of objects matched during measuring period by the URL Exception Policy for which this row shows statistics.
AppDirector User Guide
Advanced Capabilities
Document ID: RDWR-AD-V0231-UG1105 441
Compression Browser-Exceptions Rule-List per Rule From the Performance menu, select Acceleration > Compression > Browser- Exceptions > Rule-List per Rule Statistics. The Compression Browser-Exceptions Rule-List per Rule Statistics window is displayed.
Configuration 1.From the Performance menu, select Acceleration > Compression > Configuration. The Acceleration Engine Configuration window is displayed.
2.Click Set. Your configuration is set.
Parameter
Description
Rule List Name There are multiple rule-lists. Each Rule-List is a “policy” that contains multiple rules.
Rule Name Name of each rule in the Rule-List used to identify it.
Rule Priority Location of the rule in the Rule-List. Since Rule-Lists are scanned for a match from top (priority 1) to bottom (priority ~65000) this enables to set the location of the rule in the rule-list. See Using Leverage Browser Cache parameter, page 240
on how to use the priority efficiently.
Matched Objects Number of objects matched by this rule during measuring period.
Size Before Compression Total uncompressed size of all objects matched by this rule.
Size After Compression Total compressed size of all objects matched by this rule.
Compression Percentage Percentage of compressed and uncompressed size of all objects matched by this rule.
Parameter
Description
Statistics measuring period (Sec) Defines time period in which values are being collected. Data always shows results of previous measuring period.
All measuring and statistics are performed within a defined time-frame. This parameter allows controlling this time frame. Since numbers are updated at the end of every measuring period, a longer period will give better Averages results but will lower the ability to see real time monitoring values.
Default: 5 seconds.
WBM Statistics display auto-refresh (Sec) Defined the period after which the WBM display will automatically refresh to show recently measured values.
AppDirector User Guide
Advanced Capabilities
442 Document ID: RDWR-AD-V0231-UG1105
Bandwidth Management Statistics
The following are relevant when running a Bandwidth Management policy.
Policy Statistics Global Parameters Status
You can enable or disable the monitoring of policy statistics and adjust the monitoring period, using the Policy Statistics Global Parameters window.
To configure Policy Statistics Global Parameters
1.From the Performance menu, select BWM Policy Statistics Global Parameters. The Policy Statistics Global Parameters window is displayed.
2.Set the parameters.
3.Click Set. Your preferences are recorded.
Parameter
Description
Statistics measuring period (Sec) Defines the time period in which values are being collected. Presented data always shows results of previous measuring period.
All measuring and statistics are performed within a defined time-frame. This parameter allows controlling this time frame. Since numbers are updated at the end of every measuring period, a longer period will give better Averages results but will lower the ability to see real time monitoring values.
Default: 5 seconds.
WBM Statistics display auto-refresh (Sec) Defined the period after which the WBM display will automatically refresh to show recently measured values.
Parameter
Description
Policy Statistics Monitoring
Enables or disables (default) the monitoring of policy statistics by AppDirector.
Policy Statistics Reporting Period
Amount of time, in seconds, that policy statistics should be monitored.
Default: 60
SRP Enables or disables (default) SRP.
AppDirector User Guide
Advanced Capabilities
Document ID: RDWR-AD-V0231-UG1105 443
Last Second Statistics
The Policy Statistics window enables you to view the policy statistics.
Note:To view this table, Application Servers Statistics, page 449
must be enabled.
To view Policy Statistics for the last second
From the Performance menu, select BWM Policy Statistics > Last Second Statistics. The Policy Statistics Table window is displayed with the following parameters.
Last Period Statistics
To view Policy Statistics for the last period
1.From the Performance menu, select BWM Policy Statistics > Last Period Statistics. The Policy Statistics Table window is displayed, which contains the following parameters.
2.Select the name of a specific Policy. The Policy Statistics Table window is displayed, which contains the following read-only parameters.
Parameter
Description
Policy Name The name of the displayed policy.
Packets (sec) The number of packets matching the policy during the last second.
Matched BW (Kbits) The amount of matched bandwidth.
Sent BW (Kbits) The amount of bandwidth sent during the last second.
Parameter
Description
Policy Name The name of the displayed policy.
Packets (sec) The number of packets matching the policy during the last period.
Matched BW (Kbits) The amount of matched bandwidth.
Sent BW (Kbits) The amount of bandwidth sent during the last period.
AppDirector User Guide
Advanced Capabilities
444 Document ID: RDWR-AD-V0231-UG1105
Element Statistics
Element statistics contains several indicators for viewing AppDirector performance. They include:
• IP Packet Statistics, page 444
• SNMP Packet Statistics, page 444
• IP Router Statistics, page 445
• OSPF Packet Statistics, page 446
• Resource Utilization Statistics, page 447
IP Packet Statistics
The IP Packets Statistics window allows you to view statistics for the IP elements of AppDirector.
To view IP Packet statistics From the Performance menu, select Element Statistics > IP. The IP Packets Statistics window is displayed.
SNMP Packet Statistics
The SNMP Packet Statistics window enables you to view statistics for SNMP elements of AppDirector.
To view SNMP packet statistics From the Performance menu select Element Statistics > SNMP. The SNMP Packets Statistics window is displayed.
Parameter
Description
IP Receives Total number of input datagrams received from interfaces, including those received in error.
IP Header Errors Number of input datagrams discarded due to header error due to errors in their IP headers, including bad checksums, version number mismatch, other format errors, time-to-live exceeded, errors discovered in processing their IP options, etc.
IP Discarded Total number of input datagrams discarded. Note: This counter does not include any datagrams discarded while awaiting re-assembly.
IP Successfully Delivered
Total number of input datagrams successfully delivered to IP user- protocols (including ICMP).
IP Out Requests Total number of IP datagrams, which local IP user-protocols (including ICMP) supplied to IP in requests for transmission.
IP Out Discard Number of output IP datagrams for which no problem was encountered to prevent their transmission to their destination, but which were discarded (for example, for lack of buffer space).
Parameter
Description
SNMP Received Packets Total number of messages delivered to the SNMP entity from the transport service. SNMP Sent Packets Total number of SNMP messages passed from the SNMP protocol entity to the transport service.
AppDirector User Guide
Advanced Capabilities
Document ID: RDWR-AD-V0231-UG1105 445
IP Router Statistics
The IP Router Statistics window allows you to view statistics for the IP Router elements of AppDirector.
To view IP Router statistics From the Performance menu select Element Statistics > IP Router. The IP Router Statistics window is displayed and contains these read-only parameters:
SNMP Successful 'Get' Requests
Total number of MIB objects retrieved successfully by the SNMP protocol entity as the result of receiving valid SNMP Get-Request and Get-Next PDUs.
SNMP Successful 'Set' Requests
Total number of MIB objects altered successfully by the SNMP protocol entity as the result of receiving valid SNMP Set-Request PDUs.
SNMP 'Get' Requests Total number of SNMP Get-Request PDUs processed PDUs accepted and processed by the SNMP protocol entity.
SNMP 'Get-next' Requests
Total number of SNMP Get-Request PDUs accepted and processed by the SNMP protocol entity.
SNMP 'Set' Requests Total number of SNMP Set-Request PDUs accepted and processed by the SNMP protocol entity.
SNMP Out 'TooBig'Total number of SNMP PDUs generated by the SNMP protocol entity and for which the value of the error-status field is 'tooBig.'
SNMP Out 'NoSuchName' Total number of SNMP PDUs generated by the SNMP protocol entity and for which the value of the error-status is 'noSuchName.'
SNMP Out 'BadValue'Total number of SNMP PDUs generated by the SNMP protocol entity and for which the value of the error-status field is 'badValue.'
SNMP Out 'GenErrs'Total number of SNMP PDUs generated by the SNMP protocol entity and for which the value of the error-status field is 'genErr.'
SNMP Out 'Get-
Responses'
Total number of SNMP Get-Response PDUs generated by the SNMP protocol entity.
SNMP Out Traps Total number of SNMP Trap PDUs generated by the SNMP protocol entity.
Parameter
Description
RIP - Changes Made to IP Route Database
Number of changes made to the IP Route Database by RIP.
RIP - Global Responses Sent to RIP Queries
Number of responses sent to RIP queries from other systems.
IP Forwarded Number of input datagrams for which this entity was not their final IP destination, as a result of which an attempt was made to find a route to forward them to that final destination. In entities, which do not act as IP Gateways, this counter will include only those packets that were Source - Routed via this entity, and the Source - Route option processing was successful.
IP Unknown Protocol Number of locally-addressed datagrams received successfully but discarded because of an unknown or unsupported protocol.
Parameter
Description
AppDirector User Guide
Advanced Capabilities
446 Document ID: RDWR-AD-V0231-UG1105
OSPF Packet Statistics
Open Shortest Path First (OSPF) is an interior gateway routing protocol developed for IP networks. OSPF is based on the shortest path first or link-state algorithm. Routers use link-state algorithms to send routing information to all nodes in a network by calculating the shortest path to each node, based on a topography of the internet constructed by each node. After sending the routing information, each router sends the portion of the Routing Table (keeps track of routers to particular network destinations) that describes the state of its own links, and the complete routing structure (topography). Shortest path first algorithms allow for more frequent updates.
With OSPF, you can build a more stable network as fast convergence prevents such problems as routing loops and Count-to-Infinity (when routers continuously increment the hop count to a particular network).
The OSPF Packet Statistics window allows you to view statistics for the OSPF packet statistics elements of AppDirector.
To view OSPF packet statistics From the Performance menu select Element Statistics > OSPF. The OSPF Packet Statistics window is displayed, which contains the following read-only parameters:
IP Out No Routes Number of IP datagrams discarded because no route could be found to transmit them to their destination. This counter includes packets counted in ipForwDatagrams which meet this `no-route' criterion. Notes: • This includes datagrams, which a host cannot route as all its default gateways are down. • This counter includes any packets counted in ipForwDatagrams, which meet the `no-route' criterion. It also includes datagrams that cannot be routed as all its default gateways are down.
Parameter
Description
OSPF - New LSAs originated
Reports the number of originating OSPF link-state advertisements in the link-state database.
OSPF - LSAs received - new instantiations
The number of link-state advertisements received that are determined to be new instantiations. This number does not include newer instantia- tions of self-originated link-state advertisements
Parameter
Description
AppDirector User Guide
Advanced Capabilities
Document ID: RDWR-AD-V0231-UG1105 447
Resource Utilization Statistics
The Resource Utilization window allows you to view statistics for the AppDirector's average resource utilization.
To view resource utilization statistics From the Performance menu, select Element Statistics > Resources. The Resource Utilization window is displayed, which contains the following read-only parameters:
Acceleration-Engine Cores
These statistics measure CPU utilization per accelerator.
Enhanced Acceleration IP Interface Statistics
The IP Interface Statistics window allows you to monitor the number of packets discarded and ignored, enabling you to quickly summarize the state of network congestion from a given interface.
To view IP statistics 1.From the Performance menu select; IP Statistics. The IP Statistics window is displayed. 2.Select the desired interface entry. The IP Statistics Update window is displayed.
Parameter
Description
Resource Utilization Percent of device's CPU currently utilized.
RS Resource Utilization Percent of device's RS resource currently utilized.
RE Resource Utilization Percent of device's RE resource currently utilized.
Last 5 sec. Average Utilization
Average resources utilization in the last 5 seconds.
Last 60 sec. Average Utilization
Average resources utilization in the last 60 seconds.
Parameter
Description
Accel-Engine System Total Memory
Percentage of Acceleration engine RAM allocated for cache occupied on measuring time. Also see Caching Policies, page 238
.
Values: 1 - 50%
Default: 20%
Acceleration-Engine id 1 % CPU Utilization per accelerator
Acceleration-Engine id 2 % CPU Utilization per accelerator
Acceleration-Engine id 3 % CPU Utilization per accelerator
AppDirector User Guide
Advanced Capabilities
448 Document ID: RDWR-AD-V0231-UG1105
3.Set the parameters.
4.Click Set. The status is changed.
Parameter
Description
Interface Address IP address of the selected interface.
RIP - Response Packets Discarded
Number of RIP responses received by RIP process which were subsequently discarded for any reason. Discard Examples:
• version 0 packet
• unknown command type
• packet was smaller than the minimum size allowed for IPRIP packets. • received a packet with an invalid version in its header. • received a packet with an invalid header. • discarded a response packet from a neighbor with IP address: %1. IPRIPv2 is not configured to accept packets from this neighbor. • discarded a version: %1 packet received on the interface with IP address: %2 from a neighbor with IP address: %3. The above interface is configured to accept only version: %4 packets. • discarded a packet received on the interface with IP address: %1 from a neighboring router with IP address: %2, because the packet failed authentication. • discarded a response packet from a neighbor with IP address: %1. The packet was not sent from the standard IP RIP port (520). RIP - Routes Ignored
Number of routes, in valid RIP packets, ignored for any reason.
Ignore Examples:
• unknown address family.
• invalid metric.
• discontiguous networks (major nets separating other major nets).
• new route is inferior to previous one prior to update.
• certain RIP implementations set up to ignore host routes.
• response did not originate from a RIP port.
RIP - Updates Sent Number of triggered RIP updates sent on this interface. This explicitly does NOT include full updates sent containing new information.
Status Values: Valid (default), Invalid
AppDirector User Guide
Advanced Capabilities
Document ID: RDWR-AD-V0231-UG1105 449
Servers
As part of AppDirector’s toolset, you can monitor server performance including server status, traffic load and numbers of connections and disconnections.
Application Servers Statistics
The Application Server Statistics window allows you to view performance statistics of the all the farms and the application servers that belong to them.
To monitor application server statistics 1.From the Performance menu, select Server > Application Server Statistics. The Application Server Statistics window is displayed.
2.From the Farm drop down list, select the farm for which you want to present the servers summary. The Application Servers Summary table displays the following read-only statistics:
Parameter
Description
Status The status of the farm/server:
• Active: The farm/the server is up and running. A farm is active when it has at least one server up and running. • No New Sessions: No new sessions can be forwarded to the farm/server due to overload. • Not in Service: This farm/server is not available. A farm is not available when all its servers are Not In Service. Farm/Server Name of farm/server, (click the farm or server name to read the confirmation go to the respective farm/server configuration window).
Kbits Amount of traffic in kbits forwarded to/from the farm/server in the last second. Packets Amount of packets forwarded to/from the farm/server in the last second.
Connections Number of concurrent connections established with the farm/server.
• Current - displays the current number of concurrent connections active on the farm/server.
• Peak - displays the maximum number of concurrent connections active on the farm/server since device reboot or statistics reset.
• Total - displays the total number of all connections that were opened to the farm/server since device reboot or statistics reset.
TCP Disconnections Number of disconnections in the TCP sessions established with the farm/server.
• Current - displays the number of TCP connections to the farm/
server terminated during the last second. • Peak - displays the maximum number of TCP connections to the farm/server terminated per second since device reboot or statistics reset.
• Total - displays the total number of TCP connections to the farm/
server terminated since device reboot or statistics reset.
AppDirector User Guide
Advanced Capabilities
450 Document ID: RDWR-AD-V0231-UG1105
3.To define the frequency in which the summary is refreshed, in the Refresh Interval text box, type the number of seconds and click Set.
4.To reset statistics, click Set.
New TCP Connections Number of TCP connections with the farm/server.
• Current - displays the number of new TCP connections opened to the farm/server during the last second. • Peak - displays the maximum number of TCP connections per second opened to the farm/server since device reboot or statistics reset.
• Total - displays the total number of TCP connections opened to the farm/server since device reboot or statistics reset.
Parameter
Description
AppDirector User Guide
Advanced Capabilities
Document ID: RDWR-AD-V0231-UG1105 451
Physical Servers Statistics
The Physical Server Statistics window allows you to view performance statistics of the physical servers.monitor physical server statistics 1.From the Performance menu, select Server > Physical Server Statistics. The Physical Server Statistics window is displayed.
2.The Physical Servers Summary table displays these read-only statistics.
Parameter
Description
Status The status of the farm/server:
• Active: the server is up and running
• No New Sessions: No new sessions can be forwarded to the farm/
server.
• Not in Service: This server is not available. Physical Server Name of farm/server, (click the farm or server name to read the confirmation window).
Kbits Amount of traffic in kbits forwarded to/from farm/server. Packets Amount of packets forwarded to/from farm/server.
Incoming Connections
Number of outgoing connections established with the farm/server.
• Current - displays the current number of concurrent incoming connections active on the farm/server.
• Peak - displays the maximum number of concurrent incoming connections active on the farm/server since device reboot or statistics reset.
• Total - displays the total number of all incoming connections that were opened to the farm/server since device reboot or statistics reset.
Outgoing Connections
Number of outgoing connections established with the farm/server.
• Current - displays the current number of concurrent outgoing connections active on the farm/server.
• Peak - displays the maximum number of concurrent outgoing connections active on the farm/server since device reboot or statistics reset.
• Total - displays the total number of all outgoing connections that were opened to the farm/server since device reboot or statistics reset.
AppDirector User Guide
Advanced Capabilities
452 Document ID: RDWR-AD-V0231-UG1105
Note:Incoming connections are those accepted by the server. Outgoing connections are those initiated by the server.
3.To define the frequency in which the summary is refreshed, in the Refresh Interval text box, type the number of seconds and click Set.
4.To reset statistics, click Set.
AppDirector Statistics
The AppDirector statistics window enables you to monitor specific AppDirector elements providing you with a picture of how well AppDirector is performing using measures of Client table and Proximity table fillup or Redundancy failure. To monitor AppDirector statistics From the Performance menu, select AppDirector Statistics. The AppDirector Statistics window is displayed, which contains the following read-only parameters:
TCP Disconnections Number of disconnections in the TCP sessions established with the farm/
server.
• Current - displays the number of TCP connections to the farm/server terminated during the last second. • Peak - displays the maximum number of TCP connections to the farm/server terminated per second since device reboot or statistics reset.
• Total - displays the total number of TCP connections to the farm/
server terminated since device reboot or statistics reset.
New TCP Connections
Number of TCP connections with the farm/server.
• Current - displays the number of new TCP connections opened to the farm/server during the last second. • Peak - displays the maximum number of TCP connections per second opened to the farm/server since device reboot or statistics reset.
• Total - displays the total number of TCP connections opened to the farm/server since device reboot or statistics reset.
Parameter
Description
Redundancy Failure Indicates that the AppDirector failed.
Redundancy Takeover Indicates that the AppDirector failed.
Client Table Full Indicates that the client table filled up.
Proximity Table Full Indicates how many times the proximity redirection method was reached.
DNS Request (last second)
Number of DNS queries received in last second
DNS Replies (last second)
Number of DNS queries answered in last second.
Parameter
Description
AppDirector User Guide
Advanced Capabilities
Document ID: RDWR-AD-V0231-UG1105 453
Protocol Statistics
You can display complete protocol statistics information using this feature. If enabled, Protocol Discovery classification is performed only on traffic to/from the configured default gateway.
Protocol Statistics Global Parameters
You can configure the global parameters of protocol statistics using the Protocol Statistics Global Parameters window.
To configure Protocol Statistics Global Parameters 1.From the Performance menu, select Protocol Statistics > Global Parameters. The Protocol Statistics Global Parameters window is displayed.
2.Set the parameters. 3.Click Set. Your configuration is set.
Protocol Discovery Policies
You need to be aware of the different applications running on your network and the amount of bandwidth they consume. To allow a full view of the different protocols running on the network there is a protocol discovery feature that can be activated on the entire network or on separate sub-
networks by defining Protocol Discovery policies in the Protocol Discovery Policies window.
To set the Protocol Discovery Policies 1.From the Performance menu select, Protocol Statistics > Protocol Discovery Policies. The Protocol Discovery Policies window is displayed.
2.Click Create. The Protocol Discovery Policies Create window is displayed.
3.Set the parameters.
Parameter
Description
Protocol Monitoring Status
This indicates whether AppDirector will gather protocols statistics
Default: Enable/Disable
Protocol Statistics Reporting Period [secs.]
Amount of time that protocol statistics should be monitored.
Default: 60
Protocol Statistics Reporting (SRP)
Enables or disables (default) SRP.
Protocol Statistics Aging
Period in which table entries are kept until removed.
Default: Entries Lifetime
Parameter
Description
Name User-defined name of the policy. Index Location of policy in protection table that reflects the order in which the classification is performed.
AppDirector User Guide
Advanced Capabilities
454 Document ID: RDWR-AD-V0231-UG1105
4.Click Set. Your configuration is set.
View Protocol Statistics
The Protocol Statistics Table window enables you to view the protocol statistics.
Note:To view this table, Protocol Statistics Monitoring must be enabled. See Protocol Statistics Global Parameters, page 453
. To view the Protocol Statistics Table From the Statistics menu, select Protocol Statistics and then choose View Protocol Statistics. The Protocol Statistics Table window is displayed, which contains the following parameters:
Destination Defines destination of the traffic. Can be specific IPs, or a range of IP addresses or IP Subnet address. Default is “any” which covers traffic to any destination.
Source Defines source of traffic. Can be specific IPs, or a range of IP addresses or IP Subnet address. Default is “any” which covers traffic from any source.
Destination MAC Address Group
Enables you to discover applications and protocols present in traffic sent to a transparent network device.
Default: None
Source MAC Address Group
Enables you to discover applications and protocols present in the traffic sent by a transparent network device (firewall, router).
Default: None
Inbound Physical Port Group
Classifies only traffic received on certain interfaces of AppDirector. Enables you to set different policies to identical traffic classes received on different interfaces of AppDirector.
Default: None
VLAN Tag Group Defines VLAN traffic classification according to VLAN ID (VLAN Identifier) tags.
Default: None
Direction Defines the direction of the traffic. Values One Way (from Source to Destination) /Two Way (Default)
Operational Status Select either Active (Default) or Inactive.
Classification Point Indicates whether classification is done before or after packet modification.
• After Changes (Default): Classifies AppDirector after the packet changes.
• Before Changes: Classifies AppDirector before the packet changes.
Parameter
Description
Policy Name Name of the policy.
Protocol IP protocol.
Parameter
Description
AppDirector User Guide
Advanced Capabilities
Document ID: RDWR-AD-V0231-UG1105 455
Statistics Monitor
This section shows you how to configure and send statistics to/from the Statistics Monitor. Statistics Monitor SRP The SRP (Statistics Reporting Period) Management Host IP Address window is used to create statistics files on a remote machine. To send statistics from/to the Statistics Monitor 1.From the Services menu, select Statistics Monitor > SRP. The SRP Management Host IP Address window is displayed.
2.Type the SRP Management Host IP Address: The IP address of the machine where to create the statistics files. This is normally the machine where either the web-based software is running.
3.Click Set. The statistics are sent to the statistics monitor.
Statistics Monitor Configuration
The Statistics Monitor window is used to create statistics files on a remote machine. To send statistics from the AppDirector to the Statistics Monitor 1.From the Services menu, select Statistics Monitor > Configuration. The Statistics Monitor Configuration window is displayed.
2.Set the parameters.
3.Click Set. Your configuration is set.
Port TCP/UDP port used by the protocol.
Bandwidth Total bandwidth per second used for this protocol during last period.
Peak Bandwidth Peak bandwidth per second used for this protocol during last period.
Parameter
Description
Statistic Reporting Mode
Enables or disables the creation of statistics files. Select what kind of statistics to broadcast:
• Full: Broadcasts all statistics
• Disable (Default): Disables broadcasting
• Flow: Broadcasts statistics concerning flow
• Health: Broadcasts statistics concerning health
Flow Statistics Polling Time [sec] How often, in minutes and seconds, to update the statistics file with new flow rate data. The file is cumulative, and new data is added to existing data.
Health Statistics Polling Time [sec]
How often, in minutes and seconds, to update the statistics file with new health data. The file is cumulative, and new data is added to existing data.
Parameter
Description
AppDirector User Guide
Advanced Capabilities
456 Document ID: RDWR-AD-V0231-UG1105
Note:Since the statistics files are cumulative, you must ensure that you disable the Statistic Reporting Mode before you create files larger than you desire. Failure to do so can result in creating files that fill all available memory.
Utilities
This section contains additional device-related AppDirector utilities and includes these topics:
• DNS Client, page 456
• Time Settings, page 457
• Event Scheduler, page 459
DNS Client You can configure AppDirector to operate as a DNS client. When the DNS client is disabled, IP addresses cannot be resolved. When the DNS client is enabled, you need to configure servers for which AppDirector will send out queries for host name resolving.
You can set the Domain Name Service parameters in the DNS Client Parameters window. You can define the primary and the alternate DNS servers for dynamic DNS. In addition you can set static DNS parameters.
You can configure AppDirector to operate as a DNS client. When the DNS client is disabled, IP addresses cannot be resolved. When the DNS client is enabled, you need to configure servers for which AppDirector will send out queries for host name resolving.
You can set the Domain Name Service parameters in the DNS Client Parameters window. You can define the primary and the alternate DNS servers for dynamic DNS. In addition you can set static DNS parameters.
To define DNS servers 1.From the Services menu, select DNS. The DNS Client Parameters window is displayed. with parameters shown below.
2.To define the primary DNS server, in the Primary DNS server box type the IP address of the primary DNS server and click Set.
3.To define the alternate DNS server, in the Alternate DNS server box type the IP address of the alternate DNS server and click Set.
Parameter
Description
DNS Client Status of DNS Client.
Enabled/Disabled (default) DNS client functionality.
Primary DNS Server The primary DNS server address that should be used by AppDirector for DNS
Alternate DNS Server
The alternate DNS server address that should be used by AppDirector for DNS
AppDirector User Guide
Advanced Capabilities
Document ID: RDWR-AD-V0231-UG1105 457
Note:Primary and alternate DNS server addresses contain the default value 0.0.0.0. If you decide to delete primary or secondary DNS server addresses, which are already configured with a different value, you can reset them back to this default value - 0.0.0.0
To set static DNS 1.From the Services menu, select DNS. The DNS Client Parameters window is displayed.
2.Click Create. The Static DNS Table Create window is displayed.
3.Set the parameters.
4.Click Set.Your configuration is set.
Time Settings
This collection of utilities helps you to synchronize and configure devices for appropriate daylight saving periods. Utilities included are:
• Configuring Network Time Protocol, page 457
.
• Daylight Saving, page 458
.
• Date and Time, page 459
.
Configuring Network Time Protocol
Network Time Protocol (NTP) enables users to synchronize devices by distributing an accurate clock across the network. In predefined intervals, a device sends “time query” messages to the Network Time Server. The server returns the date and time to AppDirector. Enabling or disabling the NTP feature results in different levels of accuracy. When NTP is disabled, AppDirector’s time and date have to be set manually. When NTP is enabled, several parameters need to be configured: the IP address of the Network Time Server, the polling interval (in seconds), the time zone offset from GMT, and the NTP server port (default 123).
To define the NTP parameters 1.From the Services menu select Time Settings > NTP. The Network Time window is displayed
2.Set the parameters.
Parameter
Description
Host Name Domain name for the specified IP address.
IP Address IP address for the specified domain name.
IPv6 Address IPv6 address for the specified domain name.
Parameter
Description
NTP Server IP address of the NTP server. NTP Polling Interval [sec]
Amount of time between sending of requests to the NTP server.
AppDirector User Guide
Advanced Capabilities
458 Document ID: RDWR-AD-V0231-UG1105
3.Click Set. Your configuration is set.
Daylight Saving
Radware devices support daylight saving time. You need to configure the start and end date of the daylight saving time. During the daylight saving time period, AppDirector automatically adds one hour to the system clock. AppDirector also indicates whether it is on standard time or daylight saving time using the Daylight Saving Designations indicator.
To configure the Daylight Saving hours
1.From the Services menu, select Time Settings > Daylight Saving. The Daylight Saving window is displayed with the following parameters:
2.Set the parameters.
NTP Time Zone Time zone in which AppDirector is located, in correlation to GMT (-12:00 to + 12:00 hours).
NTP Server Port Access port number for the NTP server.
NTP Status Status of NTP function, either Enable or Disable (Default). When this feature is disabled the time and date must be set manually.
Parameter
Description
Starts [dd/mm:hh] Click ...
alongside. A pop-up is displayed. Enter the date and time from which Daylight Saving starts with these parameters:
• Mode: Date - an absolute date to configure OR
• Recurring: - if it is the same instance for start or/and end (for example, DST always starts on the 1st Sunday in April)
• Month: January-December
• Day: 1-31
• Hour:0-22
Start Date and Time (Read Only)
Shows the Start date and time in full as follows for example, TUE JUL 01 02:00:00 2007. Ends[dd/mm:hh] Click ...
alongside. A pop-up is displayed. Enter the date and time when Daylight Saving ends as follows:
• Mode: Date - an absolute date to configure OR
• Recurring: - if it is the same instance for start or/and end (for example, DST always starts on the 1st Sunday in April)
• Month: January-December
• Day: 1-31
• Hour:1-23
End Date and Time (Read Only)
Shows the End date and time in full as follows for example, TUE JAN 01 02:00:00 2008.
Daylight Saving Designations (Read-
only) States the Daylight Saving Designation zone Parameter
Description
AppDirector User Guide
Advanced Capabilities
Document ID: RDWR-AD-V0231-UG1105 459
3.Click Set. Your configuration is set.
Date and Time
To configure the Date and Time
1.From the Services menu, select Time Settings > Date and Time. The Daylight Saving System date and Time window is displayed with the following parameters.
2.Set the parameters according to the explanations providedparameters.
3.Click Set. Your configuration is set.
Event Scheduler
Some network policies remain inactive during specific hours of the day and are activated during others. For example, an enterprise may give high priority to mail traffic between 08:00 - 10:00. Sometimes within networks we need specific policies to remain inactive during certain hours of the day, or for a certain policy to be activated in the middle of the night. For example - a school's library, may want to block instant messaging during school hours, but allowing instant messages after school hours or an enterprise may give high priority for mail traffic between 08:00 - 10:00. You can schedule the activation and inactivation of specific Bandwidth Management policies using the Event Scheduler, which can then be attached to a policy's configurations. Events define the date and time in which an action must be performed.
To configure the Event Scheduler 1.From the Services menu, select Event Scheduler. The Event Scheduler window is displayed.
2.Click Create. The Event Scheduler Create window is displayed.
3.Set the parameters.
Daylight Saving Admin Status Enables and disables (default) Daylight Saving feature.
Delta Difference between Daylight Savings Time and Standard Time Setting. The number of hours by which the clock is to be adjusted is configurable using the Delta parameter. (Default is 1 hour).
Parameter
Description
System Time [hh:mm:ss] Manages AppDirector's system time, in the format hh:mm:ss.
System Date [dd/mm/
yyyy]
Manages AppDirector's system date, in the format dd/mm/yyyy.
Parameter
Description
Name A user defined name for the event.
Frequency Defines the event frequency, whether it occurs once, daily or weekly.
Parameter
Description
AppDirector User Guide
Advanced Capabilities
460 Document ID: RDWR-AD-V0231-UG1105
4.Click Set. Your configuration is set.
Time(HHMM) The time on the designated day. Note: If multiple days are selected, then the "Time" value is the same for all the configured days in which the event occurs. Default: 12:00 am (0000).
Days If Weekly Frequency is selected, you must configure where day the event occurs.
Date (DDMMMYY) If Frequency selected is once, then you need to configure the date where the event occurs.
Parameter
Description
AppDirector User Guide
Security
Document ID: RDWR-AD-V0231-UG1105 461
Chapter 8 – Security
This chapter discusses Security and contains these sections:
• AppDirector Device Security, page 461
• Keys and Certificates, page 466
• Stateful ACL (Access Control Lists), page 478
• SYN Protection, page 487
• DoS Protection, page 498
AppDirector Device Security
This section describes AppDirector device security interfaces and methods and includes these topics:
• Management Ports (Setting Physical Management Ports Restrictions), page 461
• Ports Access, page 462
• User Table and Authentication, page 463
Caution:All Radware devices include security features and settings that help prevent unauthorized access and unit tampering. Management Ports (Setting Physical Management Ports Restrictions)
On AppDirector devices, network traffic to the management port is fully isolated from traffic ports and therefore no network traffic is forwarded between management and traffic ports. Radware devices provide a packet-filtering database, which can be configured to control access to and through the unit, based on various factors, for example, protocol, port, and source or destination addresses.
Access to devices can be limited to specified physical interfaces. Interfaces connected to insecure network segments can be configured to discard some or all management traffic directed at AppDirector itself. Administrators can allow certain types of management traffic to a device (for example; SSH), while denying others such as SNMP. If an intruder attempts to access AppDirector through a disabled port, the Radware unit denies access, and generates syslog and CLI traps as notification.
This option enables you to define the permissible management ports using WBM and Telnet.
To configure the Management Ports 1.From the Security menu, select Management Ports. The Management Ports Table window is displayed.
2.Select a Port. The Management Ports Table Update window is displayed.
AppDirector User Guide
Security
462 Document ID: RDWR-AD-V0231-UG1105
3.Set the parameters.
4.Select the state from the dropdown lists, Enable or Disable, for each management option.
5.Click Set. Your configuration is set.
Ports Access
You can define which physical interfaces can be pinged. When a ping is sent to an interface for which ping is not allowed, the packet is discarded. By default, all the interfaces of AppDirector allow pings.
To configure physical ports to allow ping 1.From the Security menu, select Ports Access. The Ports Access window is displayed.
2.Select a Port Number link. The Ping Ports Access Update window is displayed.
3.In the Ping Device field, select Enabled or Disabled.
4.Click Set. The configuration is updated.
Parameter
Description
Port Number Displays the ID number of each physical port.
SNMP Displays access permission for SNMP configuration for each management port. Values: Enabled (Default) or Disabled.
Telnet Displays access permission for Telnet configuration for each management port. Values: Enabled (Default) or Disabled.
SSH Displays access permission for SSH configuration for each management port. Values: Enabled (Default) or Disabled.
SSL Displays access permission for SSL configuration for each management port. Values: Enabled (Default) or Disabled.
Web Displays access permission for Web Based configuration for each management port. Values: Enabled (Default) or Disabled.
Parameter
Description
Port Number Displays the ID number of each physical port.
Ping Device • Enabled (default) - accept Ping operations on the physical port.
• Disabled - ignore Ping operations on the physical port. AppDirector User Guide
Security
Document ID: RDWR-AD-V0231-UG1105 463
User Table and Authentication
This feature enables you to define additional users to access via Telnet, SSH and Web services (Web-
based management and SOAP). This option is password protected with an individual password configurable for each user, and also may be configured to alert the user to errors in the system via e-mail. Up to 20 users can be defined.
To configure the method of authenticating the user's access 1.From the Security menu, select Users. The User Table and Authentication window is displayed. 2.Set the parameters.
3.Select the appropriate Authentication Method and click Set. The Authentication Method is set.
To configure the Users Table 1.From the Security menu, select Users. The User Table and Authentication window is displayed.
2.Click Create. The User Table Create window is displayed.
3.Set the parameters.
Parameter
Description
Authentication Method
Method of authenticating a user's access to configuration tool. • Local User Table (Default): Device uses the User Table to authenticate access. • Radius and Local User Table: Device uses Radius server(s) to authenticate access. If request to Radius server is timed out, then AppDirector uses the User Table to authenticate access.
Note: At least one user with read-write access level must be configured in the local User Table, to enable device access, even if RADIUS servers are unavailable.
Parameter
Description
User Name The name of the user.
Password The text password for this user.
Email The e-mail address for this user
Severity Level of warning required by user. Options are as follows:
• None (Default): AppDirector will not send warning messages to user. • Fatal: AppDirector sends only Fatal messages to User.
• Error: AppDirector sends Fatal and Error messages to User.
• Warning: AppDirector sends Fatal, Error, Warning messages to User.
• Info: AppDirector sends Fatal, Error, Warning, Info messages to User.
AppDirector User Guide
Security
464 Document ID: RDWR-AD-V0231-UG1105
4.Click Set. Your configuration is set.
RADIUS Authentication
RADIUS (Remote Authentication Dial In User Service), defined in RFC 2865, is a protocol for remote user authentication and accounting. RADIUS enables centralized management of authentication data, such as user names and passwords.
When a user attempts to login to a RADIUS client, such as a router, the router send the authentication request to the RADIUS server. The communication between the RADIUS client and the RADIUS server are authenticated and encrypted through the use of a shared secret, which is not transmitted over the network.
RADIUS utilizes the MD5 algorithm for secure password hashing.
Radware and RADIUS Authentication
Radware devices provide additional security by authenticating users accessing AppDirector for management purposes. Before a management session starts, AppDirector can authenticate the user with a RADIUS server. These servers determine whether a user can access AppDirector management, using CLI, Telnet, SSH, or WBM. If a RADIUS server is not available, then AppDirector uses the User Table to authenticate access. Therefore, at least one user with a read-write access level must be configured in the local User Table, to enable device access, even if RADIUS servers are unavailable.
If the remote user is successfully authenticated by the authentication server, AppDirector verifies the privileges of the remote user and authorizes the appropriate access. Access Level Sets the user’s level of access to the WBM and CLI interfaces. Values: Read-Write, Read-Only, None.
SSH Public Key Name
Public-key authentication is based on the use of digital signatures and provides the best authentication security. Please note that public-key authentication works only with local user accounts. Local accounts are unable to access the network resources (such as computers or printers) of any domain. To use public-key authentication, the public key must be first created on the client, and uploaded to the server, and the authorization file must be modified. The SSH Secure Shell Windows client takes care of these steps automatically. The location of public keys and the authorization file on the server can be specified on the User Authentication page of the Configuration utility. The user's public keys must be located under the user's profile directory (use the %D pattern string when specifying the user key directory). The recommended location is a directory called .ssh2 in the user's profile directory. This location reflects the standard UNIX usage, works with the default settings of SSH Secure Shell client, and the user's profile directory has the appropriate access permissions (set by the operating system during the account creation). The user key directory can be specified on the User Authentication page of the Configuration utility. Select from the drop-down list, the name of the SSH public key relevant for this user. This is the name of the certificate table entry where the SSH public key resides
Note: This public key must have been previously imported into AppDirector via the Certificates management capability.
Parameter
Description
AppDirector User Guide
Security
Document ID: RDWR-AD-V0231-UG1105 465
For this purpose, AppDirector searches for Service-Type attribute (AVP 6), built into all RADIUS servers, in the Access-Accept response.
• Read-Write (administrator) user privilege is built into all Radius servers (Service-Type value 6). • Read-Only user privilege (Service-Type value 255) has to be defined in the RADIUS dictionary. Table 6: RADIUS dictionary sample:
To configure RADIUS authentication parameters
1.From the Services menu, select Management Interfaces > Admin RADIUS Authentication. The Radius Parameters window is displayed.
2.Set the parameters.
ATTRIBUTE Service-Type 26 [vid=89 type1=26 len1=+1 data=integer] R
VALUE Service-Type Read-Only 255
Parameter
Description
Main RADIUS IP Address
IP address of the primary RADIUS server.
Main RADIUS Port Number
Access port number of the primary Radius server. Access port numbers can be either 1645 (default) or 1812.
Main RADIUS Secret
Authentication password for primary RADIUS server.
Backup RADIUS IP Address
IP address of the backup RADIUS server. Backup RADIUS Port Number
Access port number of the backup Radius server. Access port numbers can be either 1645 (default) or 1812.
Backup RADIUS Secret
Authentication password for backup RADIUS server.
RADIUS Timeout Time that device waits for reply from RADIUS server before a retry, or (if the value RADIUS Retries is exceeded) before AppDirector acknowledges that the server is offline. Default: 5
RADIUS Retries Number of connection retries to RADIUS server, when the RADIUS server does not respond to first connection attempt. If RADIUS Retries is exceeded, and if all connection attempts fail (RADIUS Timeout), the backup RADIUS server is used. Default: 3
AppDirector User Guide
Security
466 Document ID: RDWR-AD-V0231-UG1105
3.Click Set. The Radius authentication parameters are configured.
Note:Radware devices must have access to the RADIUS server.
Keys and Certificates
This section covers keys and certificates management and includes these topics:
• Certificates, page 466
• Keys, page 467
• Certificates Workflows, page 468
• Configuration of Keys and Certificates, page 470
Certificates
Certificates are digitally signed indicators which identify the server or user. They are usually provided in the form of an electronic key or value. The digital certificate represents the certification of an individual business or organizational public key but can also be used to show the privileges and roles for which the holder has been certified. It also includes information from a third party verifying identity. Authentication is needed to ensure that users in a communication or transaction are who they claim to be. A basic certificate includes:
• The certificate holders identity
• The certificate‘s serial number
• The certificate holders expiry date
• A copy of the certificate holder’s public key
• The identity of the Certificate Authority (CA) and its digital signature to affirm the digital certificate was issued by a valid agency.
RADIUS Client Life Time Duration (in seconds) of client's authentication. After RADIUS Client Lifetime expires, AppDirector re-authenticates the user. Default: 30
Default Authorization
This defines the access level to be provided to a user authenticated by a RADIUS server, but where user privileges were not provided (or unknown user privileges were provided). Values:
• Read-Write (default)
• Read-Only
• No Access (user is denied access)
Parameter
Description
AppDirector User Guide
Security
Document ID: RDWR-AD-V0231-UG1105 467
Keys
A key is a variable set of numbers that the sender applies to decrypted data to produce encrypted data, to be sent via the internet. Usually a pair of public and private keys is used. A private key is kept secret and used, only by its owner, to encrypt and decrypt data. A public key has a wide distribution and is not secret. It is used for encrypting data and for verifying signatures. One key is used by the sender to encrypt or interpret the data. The recipient also uses the key to authenticate that the data comes from the sender.
The use of keys ensures that unauthorized personnel cannot decipher the data. Only with the appropriate key can the information be easily deciphered or understood. Stolen or copied data would be incomprehensible without the appropriate key to decipher it and prevent forgery. AppDirector supports the following key size lengths - 512, 1024 or 2048 bytes.
SSH Public Keys
The SSH Public Keys window enables the configuration of SSH public keys. Secure Shell (SSH) public key authentication can be used by a client to access servers, if properly configured. SSH can be set up with public/private key pairs so that you don't have to type the password each time. Because SSH is the transport for other services such as SCP (secure copy), SFTP (secure file transfer), and other services (CVS, etc), this can be very convenient and save you a lot of typing.
To configure public key authentication over SSH using CLI
1.Generate a key on a local machine
ssh-keygen -t rsaIt will ask you for a password but you can leave it blank.
Note:You could also pick -t dsa if you prefer.
2.Ensure that the remote server has a .ssh directory
3.Ensure that the server you are connecting to has a .ssh directory in your home directory. If it does not exist, you can run the ssh-keygen command above, and it will create one with the correct permissions.
4.Copy your local public key to the remote server
5.If your remote server does not have a file called ~/.ssh/authorized_keys2 then you can create it. If that file already exists, you need to append to it (instead of overwriting it), which the command below would do:
scp ~/.ssh/id_rsa.pub remote.server.com:.ssh/authorized_keys2Now ssh to the remote server
6.Now you can ssh to the remote server without entering your password.
Note:When both a password and a public key are configured for a user, the Authentication Method configured in the client’s software will dictate which authentication is selected.
AppDirector User Guide
Security
468 Document ID: RDWR-AD-V0231-UG1105
To configure SSH Public Keys 1.From the Services menu, select Management Interfaces > SSH > Public Keys. The SSH Public Keys window is displayed.
2.Select the required User from the drop-down box.
3.Enter the required key in the Public Key area and click Set. The SSH public key is configured.
To import and use a SSH certificate
1.Create the certificate using your client or any software that you want (generating private and public keys).
2.From the public key, copy the base64 part (copy only this part). 3.From the Security Menu, select Certificates > Import. The Import PKI Components window is displayed.
4.Each SSH certificate is coupled with a user from the user table. therefore the name of the SSH certificate should match the desired user name.
5.Select SSH public key from the drop down menu.
6.Paste the base64 date you copied from section 2 to the text box (Alternatively you may paste the base64 to a file on your hard-drive and choose this file in the filebox below the text box).
7.Click Ok.
8.From the Security Menu, select Users. The User Table and Authentication window is displayed.
9.Create the needed user/ edit the relevant user
10.Choose the newly uploaded certificate in the relevant drop down menu.
11.Using your software (SecureCrt for example) choose "public key" as the authentication method, type the username (from the user table) at the relevant textbox and hit connect.
12.The certificate password will be requested, (this is the password that was used in order to create the certificate and not the password that was entered when the user was created at AppDirector's user table).
Certificates Workflows
To create a Certificate Signing Request (CSR)
When a new Certificate is needed, this process should be followed
1.Create a certificate (see Certificates Table) and select CSR.
2.Complete the relevant fields (or update the defaults before you start)
3.Click OK. The Key and CSR are created
4.Move to the Export Certificates window. Export the CSR to file or Text and send to a Certificate Signing Authority such as Varisign.
5.After receiving the signed certificate back from CA, use the Import Certificates window to import it into the CSR and convert it to a Key and a Certificate.
AppDirector User Guide
Security
Document ID: RDWR-AD-V0231-UG1105 469
To create a Self-Signed Certificate
If the certificate does not need to be trusted by users (for example, lab environment or other internal only cases), AppDirector can create a certificate on its own.
1.Create a Certificate and select Certificate
2.Complete the relevant fields (or update the defaults before you start)
3.Click OK. Key and Certificate are created
To move a Key and Certificate pair from Web server to AppDirector or between AppDirectors (in redundancy configuration)
1.On the 1st AppDirector machine go to Export Certificates window and select Export Key.
2.On the 1st AppDirector machine go to Export Certificates window and export a Certificate, (if you have web servers you can export in one PKCS12 unified file).
3.On the 2nd AppDirector machine go to Import Certificates window and select Import Key.
4.On the 2nd AppDirector machine go to Import Certificates window and import Certificate.
To use an Intermediate CA for Signed Certificate
1.In the Import Certificates window, import the Intermediate CA server certificate.
2.In the AppDirector SSL Policy w
Автор
ADC
Документ
Категория
Информационные технологии
Просмотров
7 614
Размер файла
4 294 Кб
Теги
ADC, appdirector, load balancer, radware
1/--страниц
Пожаловаться на содержимое документа