Radware LLB

LinkProof User Guide
Software Version 6.12

Document ID: RDWR-LP-V0612_UG1010
September, 2010
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. 20062010. 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. 20062010. Tous droits rservs. Le copyright ainsi que tout autre droit li la proprit intellectuelle et aux secrets industriels contenus dans ce guide sont la proprit 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 dcrits dans ce document et ne pourra tre utilis dans un but autre que celui pour lequel il a t conu. Les informations rpertories dans ce document restent la proprit de Radware et doivent tre conserves de manire confidentielle. Il est strictement interdit de copier, reproduire ou divulguer des informations contenues dans ce manuel sans avoir obtenu le consentement pralable crit de Radware.
Wichtige Anmerkung
Dieses Handbuch wird vorbehaltlich folgender Bedingungen und Einschrnkungen ausgeliefert: Copyright Radware Ltd. 20062010. Alle Rechte vorbehalten. Das Urheberrecht und alle anderen in diesem Handbuch enthaltenen Eigentumsrechte und Geschftsgeheimnisse sind Eigentum von Radware Ltd. Dieses Handbuch wird Kunden von Radware mit dem ausschlielichen Zweck ausgehndigt, Informationen zu Montage und Benutzung der in diesem Dokument beschriebene Produkte von Radware bereitzustellen. Es darf fr keinen anderen Zweck verwendet werden. Die in diesem Handbuch enthaltenen Informationen sind Eigentum von Radware und mssen streng vertraulich behandelt werden. Es ist streng verboten, dieses Handbuch oder Teile daraus ohne vorherige schriftliche Zustimmung von Radware zu kopieren, vervielfltigen, reproduzieren oder offen zu legen.
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. 2. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 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. 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.
3.
This product includes software developed by Markus Friedl This product includes software developed by Theo de Raadt This product includes software developed by Niels Provos This product includes software developed by Dug Song This product includes software developed by Aaron Campbell This product includes software developed by Damien Miller This product includes software developed by Kevin Steves This product includes software developed by Daniel Kouril This product includes software developed by Wesley Griffin This product includes software developed by Per Allansson This product includes software developed by Nils Nordman This product includes software developed by Simon Wilkinson
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 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 dvelopps dans le cadre du projet OpenSSL. Ce produit inclut un logiciel dvelopp dans le cadre du projet OpenSSL. Pour un usage dans la bote outils OpenSSL (http://www.openssl.org/). Copyright (c) 1998-2005 Le projet OpenSSL. Tous droits rservs. Ce produit inclut la catgorie de chiffre Rijndael. L'implmentation de Rijindael par Vincent Rijmen, Antoon Bosselaers et Paulo Barreto est du domaine public et distribue sous les termes de la licence suivante : @version 3.0 (Dcembre 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 auprs de Radware. Une copie de la licence est rpertorie 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 dvelopps dans le cadre du projet OpenSSL. Copyright (c) 1983, 1990, 1992, 1993, 1995 Les membres du conseil de l'Universit de Californie. Tous droits rservs. La distribution et l'usage sous une forme source et binaire, avec ou sans modifications, est autorise pour autant que les conditions suivantes soient remplies : 1. La distribution d'un code source doit inclure la notice de copyright mentionne 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 matriel fourni la notice de copyright mentionne 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 utiliss pour approuver ou promouvoir un produit driv de ce programme sans l'obtention pralable d'une autorisation crite. Ce produit inclut un logiciel dvelopp par Markus Friedl
Ce produit inclut un logiciel dvelopp par Theo de Raadt Ce produit inclut un logiciel dvelopp par Niels Provos Ce produit inclut un logiciel dvelopp par Dug Song Ce produit inclut un logiciel dvelopp par Aaron Campbell Ce produit inclut un logiciel dvelopp par Damien Miller Ce produit inclut un logiciel dvelopp par Kevin Steves Ce produit inclut un logiciel dvelopp par Daniel Kouril Ce produit inclut un logiciel dvelopp par Wesley Griffin Ce produit inclut un logiciel dvelopp par Per Allansson Ce produit inclut un logiciel dvelopp par Nils Nordman Ce produit inclut un logiciel dvelopp par Simon Wilkinson. La distribution et l'usage sous une forme source et binaire, avec ou sans modifications, est autorise pour autant que les conditions suivantes soient remplies : 1. 2. La distribution d'un code source doit inclure la notice de copyright mentionne ci-dessus, cette liste de conditions et l'avis de non-responsabilit suivant. La distribution, sous une forme binaire, doit reproduire dans la documentation et/ou dans tout autre matriel fourni la notice de copyright mentionne ci-dessus, cette liste de conditions et l'avis de non-responsabilit suivant.
LE LOGICIEL MENTIONN CI-DESSUS EST FOURNI TEL QUEL PAR LE DVELOPPEUR ET TOUTE GARANTIE, EXPLICITE OU IMPLICITE, Y COMPRIS, MAIS SANS S'Y LIMITER, TOUTE GARANTIE IMPLICITE DE QUALIT MARCHANDE ET D'ADQUATION UN USAGE PARTICULIER EST EXCLUE. EN AUCUN CAS L'AUTEUR NE POURRA TRE TENU RESPONSABLE DES DOMMAGES DIRECTS, INDIRECTS, ACCESSOIRES, SPCIAUX, EXEMPLAIRES OU CONSCUTIFS (Y COMPRIS, MAIS SANS S'Y LIMITER, L'ACQUISITION DE BIENS OU DE SERVICES DE REMPLACEMENT, LA PERTE D'USAGE, DE DONNES OU DE PROFITS OU L'INTERRUPTION DES AFFAIRES), QUELLE QU'EN SOIT LA CAUSE ET LA THORIE DE RESPONSABILIT, QU'IL S'AGISSE D'UN CONTRAT, DE RESPONSABILIT STRICTE OU D'UN ACTE DOMMAGEABLE (Y COMPRIS LA NGLIGENCE OU AUTRE), DCOULANT DE QUELLE QUE FAON QUE CE SOIT DE L'USAGE DE CE LOGICIEL, MME S'IL A T AVERTI DE LA POSSIBILIT D'UN TEL DOMMAGE.
Copyrightvermerke
Dieses Produkt enthlt einen vom OpenSSL-Projekt entwickelten Code Dieses Produkt enthlt 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 enthlt die Rijndael cipher Die Rijndael-Implementierung von Vincent Rijndael, Anton Bosselaers und Paulo Barreto ist ffentlich zugnglich und wird unter folgender Lizenz vertrieben: @version 3.0 (December 2000) Optimierter ANSI C Code fr 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 mglicherweise Software, die im Rahmen der DNU Allgemeine ffentliche Lizenzvereinbarung Version 2 (GPL v.2) lizensiert sind, einschlielich LinuxBios und Filo Open Source-Projekte. Der Quellcode von LinuxBios und Filo ist bei Radware auf Anfrage erhltlich. Eine Kopie dieser Lizenz kann eingesehen werden unter: http://www.gnu.org/licenses/old-licenses/gpl-2.0.html Dieser Code wird hiermit allgemein zugnglich gemacht. Dieses Produkt enthlt einen vom OpenBSD-Projekt entwickelten Code
Copyright (c) 1983, 1990, 1992, 1993, 1995 The Regents of the University of California. Alle Rechte vorbehalten. Die Verbreitung und Verwendung in Quell- und binrem Format, mit oder ohne Vernderungen, 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 binrem 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 Universitt noch die Namen der Beitragenden drfen ohne ausdrckliche vorherige schriftliche Genehmigung verwendet werden, um von dieser Software abgeleitete Produkte zu empfehlen oder zu bewerben. Dieses Produkt enthlt von Markus Friedl entwickelte Software Dieses Produkt enthlt von Theo de Raadt entwickelte Software Dieses Produkt enthlt von Niels Provos entwickelte Software Dieses Produkt enthlt von Dug Song entwickelte Software Dieses Produkt enthlt von Aaron Campbell entwickelte Software Dieses Produkt enthlt von Damien Miller entwickelte Software Dieses Produkt enthlt von Kevin Steves entwickelte Software Dieses Produkt enthlt von Daniel Kouril entwickelte Software Dieses Produkt enthlt von Wesley Griffin entwickelte Software Dieses Produkt enthlt von Per Allansson entwickelte Software Dieses Produkt enthlt von Nils Nordman entwickelte Software Dieses Produkt enthlt von Simon Wilkinson entwickelte Software Die Verbreitung und Verwendung in Quell- und binrem Format, mit oder ohne Vernderungen, 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 binrem 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. SMTLICHE VORGENANNTE SOFTWARE WIRD VOM AUTOR IM IST-ZUSTAND ("AS IS") BEREITGESTELLT. JEGLICHE AUSDRCKLICHEN ODER IMPLIZITEN GARANTIEN, EINSCHLIESSLICH, DOCH NICHT BESCHRNKT AUF DIE IMPLIZIERTEN GARANTIEN DER MARKTGNGIGKEIT UND DER ANWENDBARKEIT FR EINEN BESTIMMTEN ZWECK, SIND AUSGESCHLOSSEN. UNTER KEINEN UMSTNDEN HAFTET DER AUTOR FR DIREKTE ODER INDIREKTE SCHDEN, FR BEI VERTRAGSERFLLUNG ENTSTANDENE SCHDEN, FR BESONDERE SCHDEN, FR SCHADENSERSATZ MIT STRAFCHARAKTER, ODER FR FOLGESCHDEN EINSCHLIESSLICH, DOCH NICHT BESCHRNKT AUF, ERWERB VON ERSATZGTERN ODER ERSATZLEISTUNGEN; VERLUST AN NUTZUNG, DATEN ODER GEWINN; ODER GESCHFTSUNTERBRECHUNGEN) GLEICH, WIE SIE ENTSTANDEN SIND, UND FR JEGLICHE ART VON HAFTUNG, SEI ES VERTRGE, GEFHRDUNGSHAFTUNG, ODER DELIKTISCHE HAFTUNG (EINSCHLIESSLICH FAHRLSSIGKEIT ODER ANDERE), DIE IN JEGLICHER FORM FOLGE DER BENUTZUNG DIESER SOFTWARE IST, SELBST WENN AUF DIE MGLICHKEIT 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.
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.
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-411For 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
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. 2. 3. 4. 5. 6. This equipment is designed to permit connection between the earthed conductor of the DC supply circuit and the earthing conductor equipment. See Installation Instructions. All servicing must be undertaken only by qualified service personnel. There are not user serviceable parts inside the unit. DO NOT plug in, turn on or attempt to operate an obviously damaged unit. Ensure that the chassis ventilation openings in the unit are NOT BLOCKED. 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. Do not operate the device in a location where the maximum ambient temperature exceeds 40C/104F.
10
7. Be sure to unplug the power supply cord from the wall socket BEFORE attempting to remove and/or check the main power fuse. CLASS 1 LASER PRODUCT AND REFERENCE TO THE MOST RECENT LASER STANDARDS IEC 60 825-1:1993 + A1:1997 + A2:2001 AND EN 60825-1:1994+A1:1996+ A2:2001 AC units for Denmark, Finland, Norway, Sweden (marked on product): Denmark - Unit is class I - unit to be used with an AC cord set suitable with Denmark deviations. The cord includes an earthing conductor. The Unit is to be plugged into a wall socket outlet which is connected to a protective earth. Socket outlets which are not connected to earth are not to be used! Finland - (Marking label and in manual) - Laite on liitettv suojamaadoituskoskettimilla varustettuun pistorasiaan Norway (Marking label and in manual) - Apparatet m tilkoples jordet stikkontakt Unit is intended for connection to IT power systems for Norway only. Sweden (Marking label and in manual) - Apparaten skall anslutas till jordat uttag.
To connect the power connection: 1. Connect the power cable to the main socket, located on the rear panel of the device. 2. Connect the power cable to the grounded AC outlet. CAUTION Risk of electric shock and energy hazard. Disconnecting one power supply disconnects only one power supply module. To isolate the unit completely, disconnect all power supplies.
Instructions de scurit
AVERTISSEMENT Un dispositif de dconnexion facilement accessible sera incorpor au cblage du btiment. En raison des risques de chocs lectriques et des dangers nergtiques, mcaniques et d'incendie, chaque procdure impliquant l'ouverture des panneaux ou le remplacement de composants sera excute par du personnel qualifi. Pour rduire les risques d'incendie et de chocs lectriques, dconnectez le dispositif du bloc d'alimentation avant de retirer le couvercle ou les panneaux. La figure suivante montre l'tiquette d'avertissement appose sur les plateformes Radware dotes 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 SCURIT POUR LES SYSTMES DOTS DE DEUX SOURCES D'ALIMENTATION LECTRIQUE (EN CHINOIS) La figure suivante reprsente l'tiquette d'avertissement pour les plateformes Radware dotes de deux sources d'alimentation lectrique.
11
Figure 6: Avertissement de scurit pour les systmes dotes de deux sources d'alimentation lectrique (en chinois)
Traduction de la Figure 6 - Avertissement de scurit pour les systmes dotes de deux sources d'alimentation lectrique (en chinois), page 12: Cette unit est dote de plus d'une source d'alimentation lectrique. Dconnectez 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 rpertoris dans le manuel d'instructions, moins d'tre qualifi en la matire. Aucune pice l'intrieur de l'unit ne peut tre remplace ou rpare. HAUTE TENSION Tout rglage, opration d'entretien et rparation de l'instrument ouvert sous tension doit tre vit. Si cela s'avre indispensable, confiez cette opration une personne qualifie et consciente des dangers impliqus. Les condensateurs au sein de l'unit risquent d'tre chargs mme si l'unit a t dconnecte 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 relies au systme de mise la terre du btiment. 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 spcifi sont utiliss en remplacement. L'usage de fusibles rpars et le court-circuitage des porte-fusibles doivent tre vits. Lorsqu'il est pratiquement certain que la protection offerte par les fusibles a t dtriore, l'instrument doit tre dsactiv et scuris contre toute opration involontaire. TENSION DE LIGNE Avant de connecter cet instrument la ligne lectrique, vrifiez que la tension de la source d'alimentation correspond aux exigences de l'instrument. Consultez les spcifications propres l'alimentation nominale correcte du dispositif. Les plateformes alimentes en 48 CC ont une tolrance d'entre comprise entre 36 et 72 V CC. MODIFICATIONS DES SPCIFICATIONS Les spcifications sont sujettes changement sans notice pralable. Remarque: Cet quipement a t test et dclar conforme aux limites dfinies pour un appareil numrique de classe A, conformment au paragraphe 15B de la rglementation 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 fixes pour fournir une protection raisonnable contre les interfrences nuisibles, lorsque l'quipement est utilis dans un environnement commercial. Cet quipement gnre, utilise et peut mettre des frquences radio et, s'il n'est pas install et utilis conformment au manuel d'instructions, peut entraner des interfrences nuisibles aux communications radio. Le fonctionnement de cet quipement dans une zone rsidentielle est susceptible de provoquer des interfrences nuisibles, auquel cas l'utilisateur devra corriger le problme ses propres frais. DCLARATIONS SUR LES INTERFRENCES LECTROMAGNTIQUES VCCI
12
Figure 7: Dclaration pour l'quipement de classe A certifi VCCI
Traduction de la Figure 7 - Dclaration 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 radiolectriques sont susceptibles d'apparatre. Si tel est le cas, l'utilisateur sera tenu de prendre des mesures correctives.
Figure 8: Dclaration pour l'quipement de classe B certifi VCCI
Traduction de la Figure 8 - Dclaration 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 tlvision dans un environnement domestique, il peut entraner des interfrences radio. Installez et utilisez l'quipement selon le manuel d'instructions. NOTICE SPCIALE POUR LES UTILISATEURS NORD-AMRICAINS Pour un raccordement lectrique en Amrique du Nord, slectionnez un cordon d'alimentation homologu UL et certifi CSA 3 - conducteur, [18 AWG], muni d'une prise moule son extrmit, de 125 V, [5 A], d'une longueur minimale de 1,5 m [six pieds] et maximale de 4,5m...Pour la connexion europenne, choisissez un cordon d'alimentation mondialement homologu et marqu "<HAR>", 3 - conducteur, cble de 0,75 mm2 minimum, de 300 V, avec une gaine en PVC isole. La prise l'extrmit du cordon, sera dote d'un sceau moul indiquant: 250 V, 3 A.". ZONE A ACCS RESTREINT L'quipement aliment en CC ne pourra tre install que dans une zone accs restreint. CODES D'INSTALLATION Ce dispositif doit tre install en conformit avec les codes lectriques nationaux. En Amrique du Nord, l'quipement sera install en conformit avec le code lectrique national amricain, articles 110-16, 110 -17, et 110 -18 et le code lectrique canadien, Section 12. INTERCONNEXION DES UNTES. Les cbles de connexion l'unit RS232 et aux interfaces Ethernet seront certifis UL, type DP-1 ou DP-2. (Remarque- s'ils ne rsident pas dans un circuit LPS) PROTECTION CONTRE LES SURCHARGES. Un circuit de drivation, facilement accessible, sur le dispositif de protection du courant de 15 A doit tre intgr au cblage du btiment pour chaque puissance consomme. BATTERIES REMPLAABLES
13
Si l'quipement est fourni avec une batterie, et qu'elle est remplace par un type de batterie incorrect, elle est susceptible d'exploser. C'est le cas pour certaines batteries au lithium, les lments suivants sont donc applicables : Si la batterie est place dans une zone d'accs oprateur, une marque est indique sur la batterie ou une remarque est insre, aussi bien dans les instructions d'exploitation que d'entretien. Si la batterie est place ailleurs dans l'quipement, une marque est indique sur la batterie ou une remarque est insre dans les instructions d'entretien.
Cette marque ou remarque inclut l'avertissement textuel suivant : AVERTISSEMENT RISQUE D'EXPLOSION SI LA BATTERIE EST REMPLACE PAR UN MODLE INCORRECT. METTRE AU REBUT LES BATTERIES CONFORMMENT AUX INSTRUCTIONS. Attention - Pour rduire les risques de chocs lectriques et d'incendie 1. 2. 3. 4. 5. 6. 7. Cet quipement est conu 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. Tout entretien sera entrepris par du personnel qualifi. Aucune pice l'intrieur de l'unit ne peut tre remplace ou rpare. NE branchez pas, n'allumez pas ou n'essayez pas d'utiliser une unit manifestement endommage. Vrifiez que l'orifice de ventilation du chssis dans l'unit n'est PAS OBSTRUE. Remplacez le fusible endommag par un modle similaire de mme puissance, tel qu'indiqu sur l'tiquette de scurit adjacente l'arrive lectrique hbergeant le fusible. Ne faites pas fonctionner l'appareil dans un endroit, o la temprature ambiante dpasse la valeur maximale autorise. 40C/104F. Dbranchez le cordon lectrique de la prise murale AVANT d'essayer de retirer et/ou de vrifier le fusible d'alimentation principal.
PRODUIT LASER DE CLASSE 1 ET RFRENCE AUX NORMES LASER LES PLUS RCENTES : IEC 60 825-1:1993 + A1 :1997 + A2 :2001 ET EN 60825-1:1994+A1 :1996+ A2 :2001 Units CA pour le Danemark, la Finlande, la Norvge, la Sude (indiqu sur le produit) : Danemark - Unit de classe 1 - qui doit tre utilise avec un cordon CA compatible avec les dviations du Danemark. Le cordon inclut un conducteur de mise la terre. L'unit sera branche une prise murale, mise la terre. Les prises non-mises la terre ne seront pas utilises ! Finlande - (tiquette et inscription dans le manuel) - Laite on liitettv suojamaadoituskoskettimilla varustettuun pistorasiaan" Norvge (tiquette et inscription dans le manuel) - "Apparatet m tilkoples jordet stikkontakt" L'unit peut tre connecte un systme lectrique IT (en Norvge uniquement). Sude (tiquette et inscription dans le manuel) - "Apparaten skall anslutas till jordat uttag." Branchez le cble d'alimentation la prise principale, situe sur le panneau arrire de l'unit. Connectez le cble d'alimentation la prise CA mise la terre. AVERTISSEMENT
1. 2.
Pour brancher l'alimentation lectrique :
Risque de choc lectrique et danger nergtique. La dconnexion d'une source d'alimentation lectrique ne dbranche qu'un seul module lectrique. Pour isoler compltement l'unit, dbranchez toutes les sources d'alimentation lectrique. ATTENTION Risque de choc et de danger lectriques. Le dbranchement d'une seule alimentation stabilise ne dbranche qu'un module "Alimentation Stabilise". Pour Isoler compltement le module en cause, il faut dbrancher toutes les alimentations stabilises.
14
Attention: Pour Rduire Les Risques d'lectrocution et d'Incendie 1. Toutes les oprations d'entretien seront effectues UNIQUEMENT par du personnel d'entretien qualifi. Aucun composant ne peut tre entretenu ou remplace par l'utilisateur. 2. NE PAS connecter, mettre sous tension ou essayer d'utiliser une unit visiblement dfectueuse. 3. Assurez-vous que les ouvertures de ventilation du chssis NE SONT PAS OBSTRUES. 4. Remplacez un fusible qui a saut SEULEMENT par un fusible du mme type et de mme capacit, comme indiqu sur l'tiquette de scurit proche de l'entre de l'alimentation qui contient le fusible. 5. NE PAS UTILISER l'quipement dans des locaux dont la temprature maximale dpasse 40 degrs Centigrades. 6. Assurez vous que le cordon d'alimentation a t dconnect AVANT d'essayer de l'enlever et/ou vrifier le fusible de l'alimentation gnrale.
Sicherheitsanweisungen
VORSICHT Die Elektroinstallation des Gebudes muss ein unverzglich zugngliches Stromunterbrechungsgert integrieren. Aufgrund des Stromschlagrisikos und der Energie-, mechanische und Feuergefahr drfen Vorgnge, in deren Verlauf Abdeckungen entfernt oder Elemente ausgetauscht werden, ausschlielich von qualifiziertem Servicepersonal durchgefhrt werden. Zur Reduzierung der Feuer- und Stromschlaggefahr muss das Gert 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 FR SYSTEME MIT DOPPELSPEISUNG Die folgende Abbildung ist die Warnung fr Radware-Plattformen mit Doppelspeisung.
Figure 10: Sicherheitshinweis in chinesischer Sprache fr Systeme mit Doppelspeisung
bersetzung von Figure 10 - Sicherheitshinweis in chinesischer Sprache fr Systeme mit Doppelspeisung, page 15:
15
Die Einheit verfgt ber mehr als eine Stromversorgungsquelle. Ziehen Sie zur Verhinderung von Stromschlag vor Wartungsarbeiten smtliche Stromversorgungsleitungen ab. WARTUNG Fhren Sie keinerlei Wartungsarbeiten aus, die nicht in der Betriebsanleitung angefhrt sind, es sei denn, Sie sind dafr qualifiziert. Es gibt innerhalb des Gertes keine wartungsfhigen Teile. HOCHSPANNUNG Jegliche Einstellungs-, Instandhaltungs- und Reparaturarbeiten am geffneten Gert unter Spannung mssen so weit wie mglich vermieden werden. Sind sie nicht vermeidbar, drfen sie ausschlielich von qualifizierten Personen ausgefhrt werden, die sich der Gefahr bewusst sind. Innerhalb des Gertes befindliche Kondensatoren knnen auch dann noch Ladung enthalten, wenn das Gert von der Stromversorgung abgeschnitten wurde. ERDUNG Bevor das Gert an die Stromversorgung angeschlossen wird, mssen die Schrauben der Erdungsleitung des Gertes an die Erdung der Gebudeverkabelung angeschlossen werden. LASER Dieses Gert 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 Stromstrke und der angefhrten Art verwendet werden. Die Verwendung reparierter Sicherungen sowie die Kurzschlieung von Sicherungsfassungen muss vermieden werden. In Fllen, in denen wahrscheinlich ist, dass der von den Sicherungen gebotene Schutz beeintrchtigt ist, muss das Gert abgeschaltet und gegen unbeabsichtigten Betrieb gesichert werden. LEITUNGSSPANNUNG Vor Anschluss dieses Gertes an die Stromversorgung ist zu gewhrleisten, dass die Spannung der Stromquelle den Anforderungen des Gertes entspricht. Beachten Sie die technischen Angaben bezglich der korrekten elektrischen Werte des Gertes. Plattformen mit 48 V DC verfgen ber eine Eingangstoleranz von 36-72 V DC. NDERUNGEN DER TECHNISCHEN ANGABEN nderungen der technischen Spezifikationen bleiben vorbehalten. Hinweis: Dieses Gert wurde geprft und entspricht den Beschrnkungen von digitalen Gerten 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 fr Konformitt mit der CE-Bezeichnung. Diese Beschrnkungen dienen dem angemessenen Schutz vor schdlichen Interferenzen bei Betrieb des Gertes in kommerziellem Umfeld. Dieses Gert erzeugt, verwendet und strahlt elektromagnetische Hochfrequenzstrahlung aus. Wird es nicht entsprechend den Anweisungen im Handbuch montiert und benutzt, knnte es mit dem Funkverkehr interferieren und ihn beeintrchtigen. Der Betrieb dieses Gertes in Wohnbereichen wird hchstwahrscheinlich zu schdlichen Interferenzen fhren. In einem solchen Fall wre der Benutzer verpflichtet, diese Interferenzen auf eigene Kosten zu korrigieren. ERKLRUNG DER VCCI ZU ELEKTROMAGNETISCHER INTERFERENZ
Figure 11: Erklrung zu VCCI-zertifizierten Gerten der Klasse A
16
bersetzung von Figure 11 - Erklrung zu VCCI-zertifizierten Gerten 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 Gert in einem Wohnbereich benutzt, knnen elektromagnetische Strungen auftreten. In einem solchen Fall wre der Benutzer verpflichtet, korrigierend einzugreifen.
Figure 12: Erklrung zu VCCI-zertifizierte Gerte der Klasse B
bersetzung von Figure 12 - Erklrung zu VCCI-zertifizierte Gerte 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 Gert in einem Wohnbereich benutzt, knnen elektromagnetische Strungen auftreten. Montieren und benutzen Sie das Gert laut Anweisungen im Benutzerhandbuch. BESONDERER HINWEIS FR BENUTZER IN NORDAMERIKA Whlen Sie fr den Netzstromanschluss in Nordamerika ein Stromkabel, das in der UL aufgefhrt und CSA-zertifiziert ist 3 Leiter, [18 AWG], endend in einem gegossenen Stecker, fr 125 V, [5 A], mit einer Mindestlnge von 1,5 m [sechs Fu], doch nicht lnger als 4,5 m. Fr europische Anschlsse verwenden Sie ein international harmonisiertes, mit "<HAR>" markiertes Stromkabel, mit 3 Leitern von mindestens 0,75 mm2, fr 300 V, mit PVC-Umkleidung. Das Kabel muss in einem gegossenen Stecker fr 250 V, 3 A enden. BEREICH MIT EINGESCHRNKTEM ZUGANG Das mit Gleichstrom betriebene Gert darf nur in einem Bereich mit eingeschrnktem Zugang montiert werden. INSTALLATIONSCODES Dieses Gert muss gem der landesspezifischen elektrischen Codes montiert werden. In Nordamerika mssen Gerte 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 GERTEN Kabel fr die Verbindung des Gertes mit RS232- und Ethernetmssen UL-zertifiziert und vom Typ DP-1 oder DP-2 sein. (Anmerkung: bei Aufenthalt in einem nicht-LPS-Stromkreis) BERSTROMSCHUTZ Ein gut zugnglicher aufgefhrter berstromschutz mit Abzweigstromkreis und 15 A Strke muss fr jede Stromeingabe in der Gebudeverkabelung integriert sein. AUSTAUSCHBARE BATTERIEN Wird ein Gert mit einer austauschbaren Batterie geliefert und fr diese Batterie durch einen falschen Batterietyp ersetzt, knnte dies zu einer Explosion fhren. Dies trifft zu fr manche Arten von Lithiumsbatterien zu, und das folgende gilt es zu beachten: Wird die Batterie in einem Bereich fr Bediener eingesetzt, findet sich in der Nhe der Batterie eine Markierung oder Erklrung sowohl im Betriebshandbuch als auch in der Wartungsanleitung. Ist die Batterie an einer anderen Stelle im Gert eingesetzt, findet sich in der Nhe der Batterie eine Markierung oder einer Erklrung in der Wartungsanleitung.
Diese Markierung oder Erklrung enthlt den folgenden Warntext: VORSICHT
17
EXPLOSIONSGEFAHR, FALLS BATTERIE DURCH EINEN FALSCHEN BATTERIETYP ERSETZT WIRD. GEBRAUCHTE BATTERIEN DEN ANWEISUNGEN ENTSPRECHEND ENTSORGEN. Denmark - "Unit is class I - mit Wechselstromkabel benutzen, dass fr die Abweichungen in Dnemark 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 liitettv suojamaadoituskoskettimilla varustettuun pistorasiaan Norway - (Markierungsetikett und im Handbuch) - "Apparatet m tilkoples jordet stikkontakt Ausschlielich fr Anschluss an IT-Netzstromsysteme in Norwegen vorgesehen Sweden - (Markierungsetikett und im Handbuch) - "Apparaten skall anslutas till jordat uttag." Schlieen Sie das Stromkabel an den Hauptanschluss auf der Rckseite des Gertes an. Schlieen Sie das Stromkabel an den geerdeten Wechselstromanschluss an.
1. 2.
Anschluss des Stromkabels:
VORSICHT Stromschlag- und Energiegefahr Die Trennung einer Stromquelle trennt nur ein Stromversorgungsmodul von der Stromversorgung. Um das Gert komplett zu isolieren, muss es von der gesamten Stromversorgung getrennt werden. Vorsicht - Zur Reduzierung der Stromschlag- und Feuergefahr 1. Dieses Gert ist dazu ausgelegt, die Verbindung zwischen der geerdeten Leitung des Gleichstromkreises und dem Erdungsleiter des Gertes zu ermglichen. Siehe Montageanleitung. Wartungsarbeiten jeglicher Art drfen nur von qualifiziertem Servicepersonal ausgefhrt werden. Es gibt innerhalb des Gertes keine vom Benutzer zu wartenden Teile. Versuchen Sie nicht, ein offensichtlich beschdigtes Gert an den Stromkreis anzuschlieen, einzuschalten oder zu betreiben. Vergewissern Sie sich, dass sie Lftungsffnungen im Gehuse des Gertes NICHT BLOCKIERT SIND. Ersetzen Sie eine durchgebrannte Sicherung ausschlielich mit dem selben Typ und von der selben Strke, die auf dem Sicherheitsetikett angefhrt sind, das sich neben dem Stromkabelanschluss, am Sicherungsgehuse. Betreiben Sie das Gert nicht an einem Standort, an dem die Hchsttemperatur der Umgebung 40 C berschreitet. Vergewissern Sie sich, das Stromkabel aus dem Wandstecker zu ziehen, BEVOR Sie die Hauptsicherung entfernen und/oder prfen.
2. 3. 4. 5.
6. 7.
18
Document Conventions
The following describes the conventions and symbols that this guide uses:
Item
Description
An example scenario
Description (French)
Un scnario d'exemple
Beschreibung (German)
Ein Beispielszenarium
Example
Possible damage to equipment, software, or data Caution: Additional information Note: A statement and instructions To A suggestion or workaround Tip: Possible physical harm to Blessure possible de the operator l'oprateur Warning: Verletzungsgefahr des Bedieners Une suggestion ou solution Ein Vorschlag oder eine Umgehung Rfrences et instructions Eine Erklrung und Anweisungen Endommagement Mgliche Schden an possible de l'quipement, Gert, Software oder des donnes ou du Daten logiciel Informations complmentaires Zustzliche Informationen
19
20
LinkProof User Guide Table of Contents
Table of Contents
Important Notices .......................................................................................................... 3 Copyright Notices .......................................................................................................... 4 Safety Instructions ......................................................................................................... 7 Document Conventions ............................................................................................... 19
Chapter 1 Introduction......................................................................................... 29
LinkProof Overview ..................................................................................................... 29 Supported Radware Platforms .................................................................................... 30 Basic LinkProof Concepts ........................................................................................... 30
Multihoming Overview ......................................................................................................... 30 Multihomed Network ............................................................................................................ 31 Farms ................................................................................................................................... 31 Servers ................................................................................................................................ 31 Content Rules ...................................................................................................................... 31 NAT ...................................................................................................................................... 31 Proximity .............................................................................................................................. 32 DNS Load Balancing ........................................................................................................... 32 Redundancy ......................................................................................................................... 32
LinkProof Modules ....................................................................................................... 32

Health Monitoring Module .................................................................................................... Traffic Redirection Module ................................................................................................... Bandwidth Management Module ......................................................................................... Security Module ................................................................................................................... 33 33 33 33
Management Tools ...................................................................................................... 34
Chapter 2 Device Management ........................................................................... 35

Device IP Host Parameters and Generic Startup Configuration Menu ........................ 36 CLI Installation Wizard ................................................................................................. 40 Device Interfaces ......................................................................................................... 49
Interface Numbering Conventions and Parameters ............................................................. Managing Physical Interface Parameters ............................................................................ Logical Interface Numbering ................................................................................................ Trunk Management .............................................................................................................. OnDemand Switch Management Ports Redundancy .......................................................... OnDemand Switch Management Ports Isolation ................................................................. VLAN Interface Numbering .................................................................................................. Managing Interface Status and PropertiesL2 Interface Table ......................................... 49 49 51 51 51 51 51 51
Erasing the Configuration File ..................................................................................... 52 Updating Device Software ........................................................................................... 53 Software Versions List ................................................................................................. 54
21
Licensing and Upgrading Licenses ............................................................................. 54 Managing Configuration Files ..................................................................................... 56

Sending a Configuration File to the Device ......................................................................... 57 Downloading a Configuration File ....................................................................................... 57 Configuration Error Log Files .............................................................................................. 58
Updating PoliciesActivating the Latest Changes .................................................... 59 Resetting the Device .................................................................................................. 59 Configuring Global Device Parameters ...................................................................... 60 Device Information ...................................................................................................... 60 Device Monitoring ....................................................................................................... 61 Session Table ............................................................................................................. 62
Session Table Global Parameters ....................................................................................... 62 Session Table Entries ......................................................................................................... 64
Bridging Support ......................................................................................................... 65

Bridge Operating Parameters .............................................................................................. 65 Bridge Forwarding Table ..................................................................................................... 66 Static Forwarding Table ...................................................................................................... 66
LinkProof Global Configuration General ..................................................................... 67 Virtual IP Addresses ................................................................................................... 69

Creating Virtual IP Addresses ............................................................................................. 70 Virtual IP Translation Ports Exclusion ................................................................................. 70
Mapping NAT Addresses to Virtual IP Addresses ...................................................... 71 Device Tuning ............................................................................................................. 71

Tuning Statistics Parameters .............................................................................................. Tuning Memory Check ........................................................................................................ Tuning BWM Parameters .................................................................................................... Tuning Classifier Parameters .............................................................................................. Tuning Device Table Parameters ........................................................................................ Tuning SYN Protection Parameters .................................................................................... Tuning Diagnostics Parameters .......................................................................................... Tuning Security Parameters ................................................................................................ Tuning Virtual Tunneling Parameters .................................................................................. CLI Traps ............................................................................................................................ Syslog Reporting ................................................................................................................. SMTP E-mail Notifications ................................................................................................... Configuration Trace ............................................................................................................. 72 72 72 73 75 80 81 81 83 85 85 86 87
Device Notifications .................................................................................................... 84
DNS-Client Utility ........................................................................................................ 88 Show Tech-Support .................................................................................................... 89 Diagnostics ................................................................................................................. 90

Traffic Capture Tool ............................................................................................................ 90 Trace-Log ............................................................................................................................ 91
22
Diagnostic Tools Files Management .................................................................................... 95 Diagnostics Policies ............................................................................................................. 95
Management Interfaces ............................................................................................... 97

Configuring a Telnet Management Interface ....................................................................... 97 Configuring Web Server Management Interfaces ................................................................ 98 Configuring an SSH Interface for Management ................................................................ 100 Configuring an FTP Interface for Management ................................................................ 101
RADIUS Authentication for Management ................................................................. 101 Logging ..................................................................................................................... 103

Event Log .......................................................................................................................... 103 SMTP Logging .................................................................................................................. 103 Power Supply Traps ......................................................................................................... 104
APSolute API ............................................................................................................ 104
Chapter 3 Basic Switching and Routing .......................................................... 105

Port Settings ............................................................................................................. 105
Port Mirroring .................................................................................................................... Link AggregationPort Trunking ..................................................................................... Port Rules ......................................................................................................................... Rules Table ....................................................................................................................... Port Load Balancing Status .............................................................................................. Virtual LANs ...................................................................................................................... Supported VLAN Types .................................................................................................... IPv6 Pass-through ............................................................................................................ Bridging ............................................................................................................................. VLAN Example Configuration ........................................................................................... Configuring VLANs ........................................................................................................... Redundancy with VLANs .................................................................................................. VLAN Tagging .................................................................................................................. IP Addressing ................................................................................................................... Routing ............................................................................................................................. Routing Information Protocol ............................................................................................ Configuring ARP Parameters ........................................................................................... IP Router Operating Parameters ...................................................................................... IP Router Interface Parameters ........................................................................................ Open Shortest Path First (OSPF) ..................................................................................... 105 106 110 111 111 112 112 113 115 115 116 118 118 122 122 124 126 127 128 130
Virtual LAN ............................................................................................................... 112
IP Addressing and Routing ....................................................................................... 122
Chapter 4 Basic Application Switching ........................................................... 135

LinkProof Multihoming Overview .............................................................................. 135 Farm Management ................................................................................................... 138
LinkProof Farms ............................................................................................................... 138 Farm Load Balancing ........................................................................................................ 144
23
Default Farm ..................................................................................................................... 153 Farm Connectivity Checks ................................................................................................ 154
Server Management ................................................................................................. 155

Servers Overview .............................................................................................................. Configuring a Logical Router ............................................................................................. Configuring a Logical Firewall ........................................................................................... Physical Servers ............................................................................................................... Cluster Servers ................................................................................................................. Full Path Health Monitor .................................................................................................... Server Statistics ................................................................................................................ Network Address Translation (SmartNAT) ........................................................................ Dynamic NAT .................................................................................................................... Static NAT ......................................................................................................................... No NAT ............................................................................................................................. Basic NAT ......................................................................................................................... One-IP-for-NAT Support .................................................................................................... Static Port Address Translation (Static PAT or SPAT) ...................................................... NAT Parameters Summary and Miscellaneous Parameters ............................................. 155 156 159 161 164 166 167 167 168 169 170 170 171 172 175
Network Address Translation ................................................................................... 167
Proximity ................................................................................................................... 176

Proximity Introduction ........................................................................................................ 176 Proximity Configuration ..................................................................................................... 177
DNS .......................................................................................................................... 182

DNS Introduction ............................................................................................................... Mapping URLs to Local IP Addresses ............................................................................... DNS Response Parameters .............................................................................................. DNS for Local Users .......................................................................................................... DNS Redundancy ............................................................................................................. Simple Router Load Balancing Configuration ................................................................... Simple Router Load Balancing Configuration With VLAN ................................................. Simple One-Leg (Lollipop) Configuration .......................................................................... Sandwich Configuration .................................................................................................... Single Device Installation .................................................................................................. 182 182 184 185 187 189 190 191 192 193
Basic Load Balancing ............................................................................................... 188
Load Balancing Weights ........................................................................................... 194 Flow Management .................................................................................................... 194

About Flows and Flow Management ................................................................................. Default Flow ...................................................................................................................... Configuring Flow Management ......................................................................................... Flow Policies ..................................................................................................................... Typical Flow Configurations .............................................................................................. 194 195 195 196 199
Client Table .............................................................................................................. 200

Client Table Mechanism .................................................................................................... 200 Managing Client Tables .................................................................................................... 203 Client-Table Logging ......................................................................................................... 208
24
Viewing Client Table Entries Using CLI ............................................................................ Client Table View Filters ................................................................................................... Filtered Client Table .......................................................................................................... Clearing the Client Table Manually ................................................................................... Network Topology with LinkProof Devices Through Firewalls .......................................... Multicast Dispatch ............................................................................................................. Clear Client Table (VPN Load Balancing Feature) ........................................................... Client Table Overwrite ......................................................................................................
215 215 217 217 218 219 220 222
VPN Load Balancing ................................................................................................ 218
Chapter 5 Advanced Features .......................................................................... 225

Content Load Balancing ........................................................................................... 225
Content Load Balancing Overview ................................................................................... Layer 7 Policies ................................................................................................................ Content Rules ................................................................................................................... Hostname Lists ................................................................................................................. Layer 2 Tunneling Protocol (L2TP) ................................................................................... Generic Routing Encapsulation (GRE) ............................................................................. GPRS Tunneling Protocol (GTP) ...................................................................................... Multiprotocol Label Switching (MPLS) .............................................................................. 225 228 230 233 235 235 236 236
Tunneling .................................................................................................................. 234
Virtual Tunneling ...................................................................................................... 237

Virtual Tunneling Introduction ........................................................................................... 237 Virtual Tunneling Configuration ........................................................................................ 239
Cost-based Load Balancing ..................................................................................... 247

Configuring Cost Global Parameters ................................................................................ 247 Configuring the Cost Parameters for a Link ...................................................................... 247
Event Scheduler ....................................................................................................... 248 Miscellaneous ParametersTweaks ....................................................................... 249 Performance Statistics .............................................................................................. 251
BWM Policy Statistics ....................................................................................................... Element Statistics ............................................................................................................. IP Interface Statistics ........................................................................................................ NHR Statistics ................................................................................................................... 251 254 258 258
Statistics Monitor SRP Management Host IP Address ............................................. 260 Configuration Auditing .............................................................................................. 261 NTP Service ............................................................................................................. 262 RADIUS Service ....................................................................................................... 263
25
Chapter 6 Redundancy...................................................................................... 265

LinkProof Redundancy ............................................................................................. 265
Introducing LinkProof Redundancy ................................................................................... Active/Backup Setup ........................................................................................................ Copying a Device Configuration for a Redundant Environment ........................................ Global Redundancy Configuration .................................................................................... IP Redundancy Table ........................................................................................................ Interface Grouping ............................................................................................................ Mirroring the Client Table .................................................................................................. Proprietary ARP ................................................................................................................ Backup Fake ARP ............................................................................................................. Backup Device in VLAN .................................................................................................... Advanced Forwarding ....................................................................................................... Introducing VRRP ............................................................................................................. Direct Server Connection with VRRP ................................................................................ Configuring Basic VRRP Redundancy .............................................................................. VRRP Associated IP Addresses ....................................................................................... 265 266 267 267 268 269 271 274 274 275 276 277 283 285 286
Proprietary ARP Redundancy .................................................................................. 274
VRRP Redundancy .................................................................................................. 277
Remote Virtual IP Addresses ................................................................................... 287
Chapter 7 Security ............................................................................................. 289

Security Introduction ................................................................................................. 289
SYN Floods ....................................................................................................................... 289 TCP-Handshake-Timeout .................................................................................................. 290
Update Security Policies ........................................................................................... 290 Configuring Access for Physical Ports ...................................................................... 290 SNMP ....................................................................................................................... 291
SNMP Global Parameters ................................................................................................. SNMP User Table ............................................................................................................. SNMP Community Table ................................................................................................... SNMP Groups Table ......................................................................................................... SNMP Access Table ......................................................................................................... SNMP View Table ............................................................................................................. SNMP Notify Table ............................................................................................................ Target Parameters Table .................................................................................................. Target Address Table ........................................................................................................ Creating an SNMP User .................................................................................................... 292 292 293 293 294 294 295 295 296 297
Ping Physical Ports ................................................................................................... 298 Configuring the Users Table and Authentication Method ......................................... 298
Configuring the Authentication Method ............................................................................. 298 Configuring a User in the User Table ................................................................................ 299
26
SYN Protection ......................................................................................................... 299

SYN Flood Global Parameters ......................................................................................... SYN Flood Protection Policies .......................................................................................... SYN Flood Statistics ......................................................................................................... Active Triggers .................................................................................................................. Certificates ........................................................................................................................ Keys .................................................................................................................................. Configuration .................................................................................................................... Certificates Workflows ...................................................................................................... Certificates Table .............................................................................................................. Export Certificates from a Device ..................................................................................... Import Certificates to a Device .......................................................................................... Default Values for Certificates .......................................................................................... 300 301 302 304 304 305 305 305 307 308 309 309
Keys and Certificates ................................................................................................ 304
Chapter 8 Bandwidth Management .................................................................. 311

Bandwidth Management Overview ........................................................................... 311
Scheduler Algorithms ........................................................................................................ Application Classification .................................................................................................. Classification Mode ........................................................................................................... Random Early Detection ................................................................................................... 312 312 312 312
Managing Bandwidth Management Global Parameters ........................................... 313 Bandwidth Management Policies ............................................................................. 315
Bandwidth Management Policy Mechanism ..................................................................... Bandwidth Management Classification Criteria ................................................................ Bandwidth Management Rules ......................................................................................... Managing Bandwidth Management Policies ..................................................................... Basic Filters ...................................................................................................................... AND Group Filters ............................................................................................................ OR Group Filters ............................................................................................................... Viewing Active Services .................................................................................................... 316 316 318 319 329 335 336 337
Services .................................................................................................................... 328
Networks .................................................................................................................. 338

Configuring Networks ....................................................................................................... 338 Viewing Active Networks .................................................................................................. 339
Port Groups .............................................................................................................. 339

Configuring Port Groups ................................................................................................... 340 Viewing Active Port Groups .............................................................................................. 340
Application Port Groups ............................................................................................ 340

Configuring Application Port Groups ................................................................................ 340 Viewing Active Application Port Groups ........................................................................... 341
VLAN Tag Groups .................................................................................................... 341

Configuring VLAN Tag Groups ......................................................................................... 342 Viewing Active VLAN Tag Groups .................................................................................... 342
27
MAC Groups ............................................................................................................. 343

Configuring MAC Groups .................................................................................................. 343 Viewing Active MAC Groups ............................................................................................. 343
Updating PoliciesClasses ..................................................................................... 344 Discrete Networks .................................................................................................... 344

CLI Commands for the Discrete Networks Feature ........................................................... 345 Configuring the Discrete Network Parameters Exposed in Web Based Management ...... 346
Protocol Discovery .................................................................................................... 347

Protocol Discovery Overview ............................................................................................ Protocol Statistics Global Parameters ............................................................................... Protocol Discovery Policies ............................................................................................... Viewing the Protocol Discovery Statistics ......................................................................... 347 348 348 350
Port Bandwidth ......................................................................................................... 350 Cancelling Interface Classification ............................................................................ 350 Example Time-based BWM Policy ........................................................................... 351
Configuring the Example BWM Policy ............................................................................... Configuring the Example Start-Event Schedule ................................................................ Configuring the Example Finish-Event Schedule .............................................................. Associating the Start- and Finish-Event Schedules with the Example BWM Policy .......... Activating the Latest Changes for the Example BWM Policy ............................................ 352 352 353 353 354
Chapter 9 Health Monitoring............................................................................. 355

Health MonitoringIntroduction .............................................................................. 355
Health Monitoring Module ................................................................................................. Response Level ................................................................................................................ Checked Elements ............................................................................................................ Health Checks ................................................................................................................... Methods ............................................................................................................................ Binding and Groups .......................................................................................................... Configuring Health Monitoring Global Parameters ............................................................ Managing the Health Checks in the Check Table ............................................................. Bindings and Groups ......................................................................................................... User-Defined Health Check MethodsPacket Sequence Table ..................................... 355 355 356 356 356 356 357 358 374 375
Health Check Configuration ...................................................................................... 357
Health Monitoring Server Table ................................................................................ 377

Configuring a Diameter Health Check ............................................................................... 378
Farm Health Checks ................................................................................................. 381
Appendix A Regular Expressions .................................................................... 383 Appendix B Predefined Basic Filters ............................................................... 385 Appendix C Glossary......................................................................................... 395
28
Chapter 1 Introduction
This guide describes Radware LinkProofand how to use it. Unless specifically stated otherwise, the procedures described in this guide are performed using Web Based Management (WBM).
Note: The term device refers to the physical platform and the LinkProof product. This chapter provides a general overview of the main features of LinkProof, and includes the following main sections: LinkProof Overview, page 29 Supported Radware Platforms, page 30 Basic LinkProof Concepts, page 30 LinkProof Modules, page 32 Management Tools, page 34
LinkProof Overview
LinkProof is an intelligent application switch that manages all links across multihomed networks, enabling full link availability, highest link performance, and complete link security for uninterrupted user access to web-enabled applications and cost effective connectivity at main offices and data centers. LinkProof eliminates link bottlenecks and failures from enterprise multihomed networks, for faulttolerant connectivity and continuous user access to IP applications, web-enabled databases, online services, corporate Web sites, and e-commerce. By intelligently routing traffic and moderating bandwidth levels across all enterprise links, LinkProof maximizes link utilization, driving application performance, economically scaling link capacities and controlling connectivity service costs. Securing all enterprise entry points and cleansing all link traffic, LinkProof delivers Denial of Service protection and intrusion prevention to protect distributed applications, resources, and users. LinkProof performs load balancing of the outgoing and incoming traffic through the access routers and via the firewall. During this process, LinkProof is responsible for the following: Forwarding the traffic to a server (router or firewall) that can provide the required service. Selecting the most available server from the servers that provide each required service. Ensuring that all the packets of a single request for service are forwarded to the same server.
LinkProof is installed in the path of a user community to the Internet. LinkProof must be defined as the default gateway for both inbound and outbound traffic. LinkProof can be installed into a network as a bridge or as a router. When installed as a router, LinkProof supports the following protocols: Routing Information Protocol (RIP) Routing Information Protocol 2 (RIP2) Open Shortest Path First (OSPF) Virtual Router Redundancy Protocol (VRRP)
29
LinkProof User Guide Introduction
Supported Radware Platforms

LinkProof runs on the following Radware platforms: OnDemand Switch VL OnDemand Switch 2 OnDemand Switch 3
Note: For more information on the platforms, see the Radware Installation and Maintenance Guide. The Radware Installation and Maintenance Guide contains instructions for installation, configuration, upgrade, recovery, and troubleshooting. The guide also includes technical descriptions and specifications for each platform.
Basic LinkProof Concepts

The following sections briefly describe major LinkProof concepts and features: Multihoming Overview, page 30 Multihomed Network, page 31 Farms, page 31 Servers, page 31 Content Rules, page 31 NAT, page 31 Proximity, page 32 DNS Load Balancing, page 32 Redundancy, page 32
Multihoming Overview
The term multihoming generally refers to a network that utilizes multiple connections to the Internet, usually through multiple ISPs. Multihomed networks are increasing in popularity because they provide networks with better reliability and performance. Better reliability comes from having more stable networks that are protected in case one of the Internet links or access routers fails. The performance gain is a result of the networks bandwidth to the Internet, which is the sum of the bandwidths available through each of the access links. It should be noted that better performance is only achieved if all the links are used collectively. However, a multihomed network creates various design complexities that involve addressing schemes, routing protocols, and DNSs. Multihoming also provides for some benefits that are never fully utilized, such as: Even with the most sophisticated routing protocols, true load balancing will never be achieved through the multiple links for outbound traffic. Any load balancing decisions that a routing protocol makes will be crude at best, and can be classified as load sharing, but nothing more. Some Internet resources are better accessible through one ISP rather than another. Routing protocols may know basic proximity information, but they generally have no knowledge of dynamic link conditions. For inbound traffic, for example, Internet hosts trying to access a Web server on the multihomed network, one ISP may provide a better path into the network than another ISP. Again, there is no way to factor in dynamic link conditions for choosing the best path into the network at any given time.
30
LinkProof User Guide Introduction LinkProof eliminates all complexities of the multihoming design, providing a single, easy-to-manage appliance that intelligently optimizes and utilizes all Internet links.
Multihomed Network
LinkProof provides the following advantages for a multihomed network: LinkProof intelligently manages the IP address ranges assigned to the network from various ISPs. LinkProof ensures that all ISP links are optimized by intelligently load balancing all outgoing traffic through the available links, while at the same time managing the address spaces used for the outgoing traffic. LinkProof uses Radwares patented proximity detection algorithms to choose the best ISP for outbound traffic. LinkProof ensures that all ISP links are used for all incoming traffic, and no address from a failed ISP link is ever advertised to the Internet. The proximity detection that LinkProof supports can also be used to ensure that the optimal path is used for inbound traffic.
In essence, LinkProof becomes a single, easy-to-administer, traffic manager for the multihomed network, eliminating the complexities of routing protocols and uncertain traffic patterns. LinkProof also optimizes the multiple ISP connections of the multihomed network to ensure that all links are used to the best of their potential, thereby making the entire network more efficient, for inbound and outbound traffic. In addition to the multihoming, LinkProof can also load balance firewalls/VPN gateways, thus providing not only continuous, but secure connectivity.
Farms
A farm is a group of servers that collectively provide the same service. Servers are grouped in farms according to the type of service that they provide. For each service, you can define a farm on LinkProof. When a new request for service arrives, LinkProof identifies the required service and selects the most available server within the farm that provides this service. In that manner, LinkProof optimizes the server operation and improves the level of the service.
Servers
LinkProof load-balances traffic that must pass via routers and firewalls in order to optimize their operation. To achieve this, LinkProof works with farms of servers. In this way, each service provided by the physical server is represented by a logical entity on LinkProof and each logical entity participates in a farm.
Content Rules
A Content Rule is an entity that enables LinkProof to load balance among different farms of the same type or different servers within the same farm based on HTTP contentMIME type, URLs, cookies, and so on.
NAT
To save public IP addresses, LinkProof uses Network Address Translation (NAT), which is the translation of an IP address used within one network to a different IP address known within another network. NAT is typically used to translate private IP addresses into public IP addresses. The purpose of NAT is to hide the source IP address.
31
LinkProof User Guide Introduction LinkProof includes the following NAT options: Static NATIs used to ensure delivery of specific traffic from the WAN to a particular server on the internal network and hide server IP addresses for outgoing traffic. This allows all ISP links to be used for all incoming traffic, and no address from a failed ISP link to ever be advertised to the Internet. Dynamic NATIs used to hide IP addresses of internal hosts for outbound traffic. LinkProof will choose an IP address that is associated with the router/ISP that was selected for this session. By choosing translated source IP addresses according to the selected router, return delivery issues will not be encountered.
Proximity
To optimize outbound and inbound traffic, LinkProof can also optionally perform proximity calculations. If an internal host wants to access a specific Web site, it is possible that the route through one ISP is more efficient than the route through the other ISP for that specific content. So, LinkProof performs proximity calculations through all available ISPs to the destination. For future traffic to this destination, LinkProof will choose the best ISP connection, according to the results derived from these proximity calculations. Similarly, if an Internet host needs to access an internal resource then it is likely that this Internet host can get to the multihomed network more efficiently through one ISP versus the other. To accomplish this, LinkProof calculates proximity from its network to all networks with hosts trying to access internal resources.
DNS Load Balancing

To provide load balancing for inbound traffic, LinkProof can take control of particular URLs. To achieve this, LinkProof must become the authoritative name server for a particular URL through proper configuration in an organizations master DNS servers. This causes all DNS queries from the Internet for the particular URL to arrive at LinkProof. When LinkProof receives a DNS query asking it to resolve a particular URL to an IP address, it resolves the query to the Static NAT address corresponding to the best link available for the users request. This means that different responses may be provided to different clients requesting the same URL.
Redundancy
The LinkProof redundancy mechanism enables you to define a backup LinkProof in case of failure. Each pair of LinkProof devices can function in an active/backup setup. To achieve redundancy between LinkProof devices, the following methods can be used: Proprietary Address Resolution Protocol (ARP) VRRP
LinkProof Modules
To provide high availability, optimal performance and maximum security levels, LinkProof offers a solution that successfully combines powerful functional modules. LinkProofs advanced Health Monitoring guarantees availability of the entire transaction path. The Traffic Redirection module works closely with the Health Monitoring module and performs Layer 47 switching based on resource availability. Traffic Redirection optimizes the usage of the routers by applying intelligent dispatching algorithms. In case of failures of any of the network elements,
32
LinkProof User Guide Introduction Traffic Management allows the traffic to bypass faulty elements. Optimization and full utilization of the existing resources guarantee 24/7 application availability, security, provide high performance, and translate into better return on investment. Further optimization of network resources is performed by the means of Bandwidth Management. This module allows you to translate your business strategy and priorities into Bandwidth Management policies. For example, you can assign high priority to mission-critical applications such as ERP and CRM, while limiting the bandwidth consumption of non-business applications like BitTorrent and eMule. The explosion in the number of application-level attacks that are tunneling their way into organizations networks through firewalls cause severe losses by compromising the availability and the performance of mission-critical applications. The advanced Security modules constitute an integral part of the LinkProof intelligent application switching process, providing protection against various attacks, worms, and viruses.
Health Monitoring Module

The Health Monitoring module constantly checks the health of the entire transaction path. This includes the availability of all the network elements required for the successful transaction completion, such as routers, servers, applications, and so on. The Health Monitoring module provides you the flexibility to create any type of a Layer 2Layer 7 health check on any network element. Using the wide variety of predefined health checks enables easy customization to meet the requirements of your network.
Traffic Redirection Module

The Traffic Redirection module provides Layer 4Layer 7 switching capability. This module performs server selection in a local farm on the basis of availability, load and content considerations. To select a server within a local farm, LinkProof uses various dispatch algorithms based on the traffic load of the servers and available server resources. When it is required, you can define server persistency. When you define server persistency, all the sessions with same predefined characteristics are forwarded to the same server. A variety of traffic settings available in the Traffic Redirection module enables you to optimize the process according to the conditions of your network environment and to maximize utilization of the existing resources. With Traffic Redirection, you can add network elements without any service interruption, and in that manner achieve transparent scalability.
Bandwidth Management Module

The Bandwidth Management module allows administrators to have full control over their available bandwidth. Using the Bandwidth Management module Radware devices can classify traffic that passes through them according to predefined criteria and can enforce a set of actions on that traffic. Bandwidth Management enables you to differentiate or classify user traffic according to a wide array of criteria and then apply the user-defined action to each classified packet or sessioneither block traffic or shape traffic. For example, Bandwidth Management allows you to give HTTP traffic a higher priority over SMTP traffic, which, in turn, may have higher priority over FTP traffic. At the same time, the device can track the actual bandwidth used by each application and set limits as to how much each classified traffic pattern can utilize (see Bandwidth Management, page 311).
Security Module
The Security modules detect, block, and prevent application attacks, thereby protecting against viruses, worms, DoS, and intrusions for immediate high-capacity application security. These modules provide secure Internet connectivity with high performance, maintaining the legitimate traffic of end users and customers.
33
LinkProof User Guide Introduction Using the Security modules, LinkProof performs deep packet inspection at multi-gigabit speed, to provide security from the network layer up to the application layer (see Security, page 289). The multi-layer security approach combines a set of security services for attack detection with advanced mitigation tools, such as: Application Security DoS Shield SYN Flood Protection
Management Tools
You can manage a LinkProof device using the following: Web Based Management (WBM), using HTTP or HTTPS. Command line interface (CLI), using Telnet, SSH, or console access.
34
Chapter 2 Device Management

This chapter describes the LinkProof management and maintenance processes, including the management interfaces and methods by which you access, configure, and operate LinkProof devices. The maintenance procedures presented here include information about upgrading and tuning of LinkProof devices. Also provided in this chapter is a description of system notifications regarding possible system failures. For more information on LinkProof management and maintenance processes, see the Radware Installation and Maintenance Guide. This chapter contains the following sections: Device IP Host Parameters and Generic Startup Configuration Menu, page 36 CLI Installation Wizard, page 40 Device Interfaces, page 49 Erasing the Configuration File, page 52 Updating Device Software, page 53 Software Versions List, page 54 Licensing and Upgrading Licenses, page 54 Managing Configuration Files, page 56 Updating PoliciesActivating the Latest Changes, page 59 Resetting the Device, page 59 Configuring Global Device Parameters, page 60 Device Information, page 60 Device Monitoring, page 61 Session Table, page 62 Bridging Support, page 65 LinkProof Global Configuration General, page 67 Virtual IP Addresses, page 69 Mapping NAT Addresses to Virtual IP Addresses, page 71 Device Tuning, page 71 Device Notifications, page 84 DNS-Client Utility, page 88 Show Tech-Support, page 89 Diagnostics, page 90 Management Interfaces, page 97 RADIUS Authentication for Management, page 101 Logging, page 103 APSolute API, page 104
35
LinkProof User Guide Device Management
Device IP Host Parameters and Generic Startup Configuration Menu

The device IP host parameters enable you to establish communication with the device using any of the following interfaces: Web Based Management SNMP (Simple Network Management Protocol) Telnet Secure SHell (SSH) client
You can use the generic Startup Configuration menu to configure the device IP host parameters.
Note: LinkProof additionally provides a CLI Installation Wizard for the initial installation. The installation program enables you to install and configure LinkProof without any specific networking knowledge. For more information, see CLI Installation Wizard, page 40.
To manually configure the device IP host parameters for the first time 1. 2. Connect the serial console to the platform. Open a terminal-emulation application with the following parameters:
Parameter
Bits per second Data bits Parity Stop bits Flow Control
Value
19200 8 None 1 None
36
LinkProof User Guide Device Management 3. Turn on the power to the platform. After the boot process is complete, the Startup Configuration menu is displayed.
Note: An initial default configuration is provided. When a device boots up for the first time, if the startup is not used for 30 seconds, and a boot-up server is not found within another 30 seconds, default settings are assigned to the device. The initial default configuration consists of the following: Private IP address (192.168.1.1) Subnet mask (255.255.255.0) Port number for management. The port number depends on the platform. For OnDemand Switch platforms, the default is G-1. NMS IP address (0.0.0.0, allowing any station to manage the device using SNMP). Community string public. Telnet, SSH, SSL and WBM are enabled with a default user of radware with password radware. 4. Type @ and press Enter. The device displays the following message:
Would you like to use new CLI configuration wizard (y/n) [y]:
5. Enter n. The Startup Configuration menu is displayed. 6. Enter the values for the menu items according to Table 1 - Startup Configuration Menu, page 37 and Table 2 - SNMP Startup Configuration Submenu, page 39. The device enters a default value for the incomplete parameters, with the exception of the IP address, which is mandatory. A validity check of all the parameters is then performed. 7. When you are finished configuring the menu items, the configuration program prompts you to save the configuration.
Continue with the new configuration (y/n)[y]

8. If the configuration is acceptable, type y and press Enter.
Table 1: Startup Configuration Menu
Item
Enable management port IP Address IP subnet mask Port number
Additional CLI Text

(y/n) [n]
Remark
For OnDemand Switch VL platforms only, this parameter specifies whether the port labeled G6 / MNG1 is configured for management purposes. The IP address of the interface is the only mandatory parameter. This address is used to access the device. The IP subnet mask address of the device. Default: The mask of the IP address class Device port number to which the IP interface is defined. For a list of available ports per platform, see Table 7 Interface Numbering Conventions, page 49. Default: MNG-1 Note: The value is case-sensitive.
Default router IP address
The IP address of the router through which the NMS can be reached. Default: 0.0.0.0That is, no default router is configured.
37
Table 1: Startup Configuration Menu
Item
RIP version Enable OSPF
Additional CLI Text

(0,1,2) [0] (y/n) [n]
Remark
The RIP version used by the network router. Default: 0Specified disabled Enables or disables the Open Shortest Path First protocol. Default: nSpecifies disabled When the OSPF protocol is enabled, you can enter an area ID other than the default value. The ID is in the form of an IP address. Default: 0.0.0.0 A user name which is added to the Users Table. Default: radware The password used to access the device remotely using Web Based Management, Telnet or SSH. Default: radware
OSPF aread ID
User Name User Password
Enable Web Access Enable Secure Web Access Enable Telnet Access Enable SSH Access SNMP Configuration
(y/n) [n] (y/n) [n]
Enables or disables Web access to the device. Default: nNo Indicates whether Secure Web access to the device is enabled. Default: nNo Indicates whether Telnet access to the device is enabled. Default: nNo Indicates whether Web access to the device is enabled. Default: nNo Accesses the SNMP Startup Configuration submenu, which is described in Table 2 - SNMP Startup Configuration Submenu, page 39.
(y/n) [n]
(y/n) [n]
38
Table 2: SNMP Startup Configuration Submenu
#
0
Item
Supported SNMP versions
Additional CLI Text

[1 2 3]
Description
Indicates which versions of the SNMP protocol are supported by the device. Values: 1, 2, 3 Default: 1 2 3That is, 1 and 2 and 3
1 2 3
Community SNMP root user Privacy Protocol
[public]
Device Community name. Default: public Specifies the use for SNMPv3. Default: radware
(NONE/DES) [DES]
Specifies whether to enable privacy or disable. Values: NONE, DESi Default: DES
4 5
Privacy Password Authentication Protocol
The password for the SNMPv3 User. Default: No password (NONE/SHA/MD5 [MD5] Specifies whether to use authentication and the authentication protocol. Must be used in conjunction with privacy. Values: NONE, SHAii , MD5iii Default: MD5
6 7
Authentication Password NMS IP Address
The password for the SNMPv3 authentication. Default: No password The required NMS IP address. Enter a value if you require to limit the device to a single specified NMS. Default: 0.0.0.0Specifies any NMS The name of the file, in a format required by the server, which contains the configuration. Select this parameter when you need to download a configuration file as NMS. The file must be located on the NMS, and the NMS must be located on a TFTP server. When you exit the Startup Configuration window, the device loads the configuration file from the NMS, resets and starts operating with the new configuration. Default: cfg1
Configuration file name
i Data Encryption Standard ii Secure Hash Algorithm iii Message-Digest algorithm 5
39
CLI Installation Wizard

You can use the CLI Installation Wizard for the initial installation. The installation program enables you to install and configure LinkProof without any specific networking knowledge.
Examples CLI Installation Wizard Configuration Examples

The following examples are possible configurations using the CLI Installation Wizard.
Figure 1: Three ISPs connected
Three (3) ISPs connected Three (3) ISPs configured per router Different interface per ISP Four (4) different subnets (one per interface)
CLI Wizard supported network configuration:
40
Figure 2: Regular VLAN (bridge)
Regular VLAN (bridge) Two (0) ISP configured per router Both ISP 1 (LP Interface 2, 192.168.10.0/24) and internal LAN (Interface 1)subnet 192.168.10.0/24 are on the same subnet ISP on LP Interface 3subnet 192.168.30.0/24
CLI Wizard Supported Network Configuration:
41
To install and configure LinkProof using the CLI Installation Wizard 1. 2. Connect the serial console to the platform. Open a terminal-emulation application with the following parameters:
Parameter
Bits per second Data bits Parity Stop bits Flow Control 3.
Value
19200 8 None 1 None
Turn on the power to the device. After the boot process is complete, the start-up menu is displayed.
Note: An initial default configuration is provided. When a device boots up for the first time, if the startup is not used for 30 seconds, and a boot-up server is not found within another 30 seconds, default settings are assigned to the device. The initial default configuration consists of the following: Private IP address (192.168.1.1) Subnet mask (255.255.255.0) Port number for management. The port number depends on the platform. For OnDemand Switch platforms, the default is G-1. NMS IP address (0.0.0.0, allowing any station to manage the device using SNMP). Community string, public Telnet, SSH, SSL and WBM are enabled with a default user of radware with password radware. 4. 5. Type @ and press Enter. The device displays the following message:
Would you like to use new CLI configuration wizard (y/n) [y]:
Enter y. The CLI Wizard Configuration menu is displayed.
Note: If you enter n, the CLI wizard returns to the original configuration wizard where you can configure the device with an IP address for initial access only. 6. Enter the values for the menu items according to Table 3 - CLI Wizard Configuration, page 43. The device enters a default value for the incomplete parameters, with the exception of the IP address, which is mandatory. A validity check of all the parameters is then performed. Some menu items may relate to additional information, which you can find in Table 4 - Inbound Traffic Startup Configuration, page 45, Table 6 - ISP Startup Configuration, page 47, and Table 7 - Interface Numbering Conventions, page 49.
42
LinkProof User Guide Device Management 7. Press Enter. Static Port Address Translation (Static PAT) is an option, and offers the following inbound services:
Service
Web (HTTP) Web SSL (HTTPS) FTP Mail (SMTP) VPN (IPsec)
Default
TCP port 80 TCP 443 TCP port 21 and 20 TCP port 25 UDP and TCP port 500 plus AH/ESP L3
Static PAT allows you to configure up to three servers, each with up to five services with the following limitation: starting from one server with all the five services or five servers (with different IP addresses) with one service each, or a combination of the above. 8. Press Enter. When using inbound services with Static PAT, management ports have to be disabled in order to prevent a conflict with inbound services. The following ports have been chosen by Radware using RFC 4340. You can alternatively use an optional port recommended by IANA (Internet Assigned Numbers Authority) http://www.iana.org/assignments/port-numbers.
Service
Web SSL (HTTPS) FTP
Port Selected by Radware

TCP 9062 TCP port 9061
Notes: >> A message is sent to the use to inform the user that the configuration was successful. >> An error message is displayed if the ports used were in conflict and the configuration was unsuccessful. >> If the IP address of the inbound port and the outbound port belong to the same subnet, the following configuration is derived from the topology: Inbound and outbound ports become members of the 1 VLAN Bridge group. Radware ensures that all IP addresses belong to the same subnet mask.
Table 3: CLI Wizard Configuration
Item
Enable management port
CLI Description
(y/n) [n]
Remark
For OnDemand Switch VL platforms only, this parameter specifies whether the port labeled G6 / MNG1 is configured for management purposes. Default: n The IP address of the interface is the only mandatory parameter. This address is used to access the device. Default: 255.255.0.0 The IP subnet mask address of the device. Default: The mask of the IP address class
IP Address
IP subnet mask
43
Item
Port number
CLI Description
Remark
Device port number to which the IP interface is defined. For a list of available ports per platform, see Table 7 Interface Numbering Conventions, page 49. Default: 1 Note: The value is case-sensitive.
User name User password
A user name which is added to the Users Table. Default: radware The password used to access the device remotely using Web Based Management, Telnet or SSH. Default: radware (y/n) [y] Specifies whether Web access to the device is enabled. Values: y, n Default: y (y/n) [y] Specifies whether to enable SSH access for device management. Specifies whether to enable Web SSL access for device management. Specifies whether to enable a ping response on all router ports of the device.
Enable management port SSH Access
Enable management port Secure Web Access Enable management port SNMP Access Enable ping response on all NHR ports
(y/n) [y] (y/n) [n]
Set Client Table size [<Recommended Specifies the Client Table Size with values between 1000 between 1000 and size>] and the maximum recommended value for your specific <MaxClientTableSize> physical platform. Default: The recommended size, which is the approximate average between 1000 and the maximum size of the client table. The maximum size of the client table depends on the memory of the device.
Caution: It is not recommended to set the Client Table Size to maximum, because it might render the device without operational memory. If you configure higher values, you should check the memory consumption using Web Based Management (Service > Tuning > Memory Check) or CLI (using the command system tune check-memorycapacity). Remote management IP address (0 for none) [0] Specifies the IP address for the remote management port.
44
Item
ISP configuration
CLI Description
(press <Enter> to configure)
Remark
Accesses the ISP Startup Configuration submenu to configure routers NAT by defining the IP address of the routers as well as the IP addresses of the LinkProof interfaces. For a description of the ISP Startup Configuration submenu items, see Table 6 - ISP Startup Configuration, page 47.
Inbound Traffic configuration
Accesses the Inbound Traffic Startup Configuration submenu. This enables you to configure Static Port Address Translation (Static PAT) options. Static PAT allows you to configure up to three servers, each with up to five services with the following limitation: starting from one server with all the five services or five servers (with different IP addresses) with one service each, or a combination of the above. When using inbound services with Static PAT, management ports have to be disabled in order to prevent a conflict with inbound services. For a description of the Inbound Traffic Startup Configuration menu items, see Table 4 - Inbound Traffic Startup Configuration, page 45.
SNMP configuration
Accesses the SNMP Startup Configuration submenu. For a description of the SNMP Startup Configuration submenu items, see Table 2 - SNMP Startup Configuration Submenu, page 39.
Table 4: Inbound Traffic Startup Configuration
#
0
Item
Internal Web server IP address Internal Web server domain name
CLI Description Remark

(0 for none) [0] Optionally specifies an internal Web (HTTP) server with an IP address. TCP port is 80. Default: 0 When item 0 has a value other than 0, this parameter specifies the relevant domain name. Default: 0 Optionally specifies an internal FTP server with an IP address. When specified, the device sets the TCP port 9061 to instead of the well known TCP port 21 and 20.i Default: 0 When item 2 has a value other than 0, this parameter specifies the relevant domain name. Default: 0 Optionally specifies an internal Mail (SMTP) server with an IP address. TCP port 25. Default: 0
(0 for none) [0]
Internal FTP server IP (0 for none) [0] address
Internal FTP server domain name Internal SMTP server IP address
(0 for none) [0]
(0 for none) [0]
45
Table 4: Inbound Traffic Startup Configuration
#
5
Item
Internal SMTP server domain name
CLI Description Remark

(0 for none) [0] When item 4 has a value other than 0, this parameter specifies the relevant domain name. Default: 0 Optionally specifies an internal Web SSL (HTTPS) with an IP address. When specified, the device sets the TCP port 9062 to instead of the well known 443.i Default: 0 When item 6 has a value other than 0, this parameter specifies the relevant domain name. Default: 0 Optionally specifies an internal VPN (IPsec) server with an IP address. UDP and TCP port 500 plus AH/ ESP L3. Default: 0 When item 8 has a value other than 0, this parameter specifies the relevant domain name. Default: 0
Internal HTTPS server (0 for none) [0] address
Internal HTTPS server (0 for none) [0] domain name Internal IPSec server (0 for none) [0] IP address
Internal IPSec server (0 for none) [0] domain name
i Radware has chosen this port using RFC 4340. You can alternatively use an optional port recommended by IANA (Internet Assigned Numbers Authority) http://www.iana.org/assignments/port-numbers.
#
0
Item
Supported SNMP versions
Additional CLI Text Description

[1 2 3] Indicates which versions of the SNMP protocol are supported by the device. Values: 1, 2, 3 Default: 1 2 3that is, 1 and 2 and 3
1 2 3
Community SNMP root user Privacy Protocol
[public]
Device Community name. Default: public Specifies the use for SNMPv3. Default: radware
(NONE/DES) [DES]
Specifies whether to enable privacy or disable. Values: NONE, DESi Default: DES
Privacy Password
The password for the SNMPv3 User. Default: No password
46
#
5
Item
Authentication Protocol
Additional CLI Text Description

(NONE/SHA/MD5 [MD5] Specifies whether to use authentication and the authentication protocol. Must be used in conjunction with privacy. Values: NONE, SHAii , MD5iii Default: MD5
6 7
Authentication Password NMS IP Address
The password for the SNMPv3 authentication. Default: No password The required NMS IP address. Enter a value if you require to limit the device to a single specified NMS. Default: 0.0.0.0That is, any NMS The name of the file, in a format required by the server, which contains the configuration. Select this parameter when you need to download a configuration file as NMS. The file must be located on the NMS, and the NMS must be located on a TFTP server. When you exit the Startup Configuration window, the device loads the configuration file from the NMS, resets and starts operating with the new configuration. Default: cfg1
Configuration file name
i Data Encryption Standard ii Secure Hash Algorithm iii Message-Digest algorithm 5
Table 6: ISP Startup Configuration
#
0 1 2 3 4 5
Item
Router IP address of ISP 1 Mask address for ISP 1 LinkProof IP interface address for ISP 1 LinkProof physical port numbers facing ISP 1 Set operating mode for the ISP server
CLI Description
Remark
Default: 255.0.0.0
(regular or backup) (r/b) [r]
Regular is for load balancing. Backup is for high availability. Specifies whether Dynamic NAT is used. If yes, you must specify the IP Interface of that specific Interface, the NAT Address. Default: y
Do you want to use Dynamic- (y/n) [y] NAT for the ISP
6 7
Router IP address of ISP 2 Mask address for ISP 2
(no to skip this ISP definition) Default: no [no]
47
Table 6: ISP Startup Configuration
#
8 9 10
Item
LinkProof IP interface address for ISP 2 LinkProof physical port numbers facing ISP 2 Set operating mode for the ISP server
CLI Description
Remark
(regular or backup) (r/b) [r]
Regular is for load balancing Backup is for high availability. Default: r
11 12 13 14 15 16 17 18
Do you want to use Dynamic- (y/n) [y] NAT for the ISP Router IP address of ISP 3 Mask address for ISP 3 LinkProof IP interface address for ISP 3 LinkProof physical port numbers facing ISP 3 Set operating mode for the ISP server (regular or backup) (r/b) [r] (no to skip this ISP definition) [no]
Do you want to use Dynamic- (y/n) [y] NAT for the ISP Load Balancing Method (use up/down keys) [Least amount of traffic] Values: Least amount of traffic Cyclic Least number of bytes Fewest number of Users Hashing Response time Default: Least amount of traffic For more information, see Dispatch Methods, page 144.
48
Device Interfaces
This section describes LinkProof device interfaces and how to configure them.
Interface Numbering Conventions and Parameters

The following table describes the physical ports on the platforms that support LinkProof.
Table 7: Interface Numbering Conventions
Physical Interface Type OnDemand Switch VL OnDemand Switch 2 Port Index Rangei Port Index Rangei
RJ-45 port for management GbE RJ-45 ports G6/MNG1ii G1G5iv G78v G1316v MNG 12iii G1G12v
OnDemand Switch 3 Port Index Rangei

MNG 12iii G1G8v G9G12v
SFP GbE ports Dual (SFP or RJ-45) GbE portsvi 10GbE XFP ports
XG-1XG-4v
i The value is case-sensitive using CLI. ii Must be configured manually by means of the Startup Configuration Menu. iii For management only. iv For traffic. The port that is labeled on the platform G6/MNG1 is configured for management. v For traffic or management. vi Only one side of a dual port can be active at the same time.
Managing Physical Interface Parameters
To view the parameters of the physical interfaces using Web Based Management Select Device > Physical Interface. The Physical Interface Table pane is displayed. The table in the Physical Interface Table pane comprises the following columns: Port IndexThe index number of the port. SpeedThe speed of the port. This option is available only when Auto-negotiation mode is off. DuplexWhether the port allows both inbound and outbound traffic (Full Duplex) or one way only (Half Duplex). This option is available only when Auto-negotiation mode is off. Auto NegotiateWhether the interface allows the two interfaces on the link to select the best common mode automatically.
49
To set interface properties using CLI Enter the following command:
net physical-interface set <port index> -<switch> <switch value>

where switch can have the following values:
a for auto negotiation. Switch values: 1=On, 2=Off. s for speed. This parameter cannot be changed for Gigabit Ethernet ports. Switch values: 1=10 Mbit/s, 2=100 Mbit/s, 3=1000 Mbit/s. d for duplex mode. Switch values: 1=half, 2=full.
Example: net physical-interface set g-3 -a 2 -d 2
To modify the parameters of a physical interface using Web Based Management 1. 2. 3. Select Device > Physical Interface. The Physical Interface Table pane is displayed. From the Port Index column, select the required interface. The Physical Interface Table Update pane is displayed. Configure the parameters; and then, click Set.
Table 8: Physical Interface Parameters
Parameter
Speed
Description
The speed for the interface. Values: Ethernet Fast Ethernet Giga EthernetGigabit Ethernet (GbE) Note: According to standards, this parameter can be changed only for copper ports. Once this parameter is changed, the Auto Negotiate parameter is set to Off.
Duplex
Specifies whether the port allows both inbound and outbound traffic (Full Duplex) or one-way only (Half Duplex). Values: Full, Half Note: According to standards, this parameter can be changed only for copper ports with a speed lower than Gigabit Ethernet. Once this parameter is changed, the Auto Negotiate parameter is set to Off.
Auto Negotiate
Specifies whether the device automatically detects and configures the speed and duplex required for the interface. Values: On, Off
50
Logical Interface Numbering

There are two types of logical interfaces: trunks (for Link Aggregation) and VLANs.
OnDemand Switch VL
Trunk T-1, T-2, T-3, T-4, T-5
OnDemand Switch 2
T-1, T-2, T-3, T-4, T-5, T-6, T-7, T-MNG
OnDemand Switch 3
T-1, T-2, T-3, T-4, T-5, T-6, T-7, T-MNG
Trunk Management
Trunk management will only use the management port, and the management port cannot be a part of any other trunk. The management trunk is a special trunk only for OnDemand Switch devices and will always be the last trunk in the list.
OnDemand Switch Management Ports Redundancy

On platforms that support two management ports, you can define the management ports to be a part of the same trunk (T-MNG). If this is the case, one port is active while the other port is in backup. Failure of the active port will seamlessly activate the backup port. The two management ports will share the same IP address.
OnDemand Switch Management Ports Isolation

Network traffic to the management port is fully isolated from the traffic ports, and therefore, no network traffic will be forwarded between the management and traffic ports.
VLAN Interface Numbering

LinkProof devices support up to 64 VLANs. VLAN numbers are from 100000 through 1000063. Two VLANs are predefined, 100000 and 100001.
Managing Interface Status and PropertiesL2 Interface Table

You can view the status and settings for interfaces using all management tools. The status information comprises the following: Interface IndexThe index value of the physical interface. MAC AddressThe MAC address of the interface. Interface Admin StatusEither up or down. Operational StatusEither Up or Down.
To display the interfaces and their configuration using CLI Use the command net l2-interface.
51
To display the interfaces and their configuration using Web Based Management Select Device > L2 Interface.
Note: Device MAC to Port Correlation specifies whether the device correlates the first 42 bits of the destination MAC address of incoming packets or all 48 bits. The MAC address of each port on the platform is the base MAC address plus the port index. Values: ShareThe device correlates only the first 42 bits of the destination MAC address of incoming packets. This value may improve performance. EnforceThe device correlates all 48 bits of the destination MAC address of incoming packets to those of the port. This is considered a a more secure MAC-to-port correlation method. Default: Share
To display current settings for the interfaces using CLI Use the command net physical-interface.
To display current settings for the interfaces using Web Based Management Select Device > Physical Interface.
Erasing the Configuration File

You may need to erase the configuration to restore the factory default configuration.
To erase the configuration file 1. 2. 3. 4. 5. Reboot the device and press any key to stop the auto-boot process. Type q0 and press Enter. Type q1 and press Enter. Press @ to reboot the device. The following line is displayed: Would you like to use new CLI configuration wizard (y/n) [y]: Do one of the following: 6. Type n and press Enter. The Startup Configuration menu is displayed. Enter y and press Enter. The CLI Wizard Configuration menu is displayed.
Set the required parameters.
52
Updating Device Software

You can upgrade your device software with newer software releases from Radware. Your maintenance contract determines whether you are entitled to new software versions with new features or only maintenance versions. To upgrade, download the software file and obtain a special upgrade password from http://www.radware.com/content/support/Software_upgrade/default.asp. The upgrade password is based on the Base MAC address (that is, the address of the first interface) of your device and on the version software file size. You will be asked for that password during the upgrade of your device.
Caution: Before upgrading to a newer software version, save the existing configuration file.
Caution: Before uploading in Regular VLAN mode, disable redundancy.
To update device software 1. Select File > Software Update. The Software Update pane is displayed. 2. In the Password text box, type the password that you received with the new software version.
Note:The password is case-sensitive. 3. In the Software version text box, type the software version number as specified in the new software documentation. 4. In the File text box, type the name of the file, or click Browse and navigate to the required file. 5. Do one of the following: If you want the device to operate according to the new version after the software download process is complete, select the Enable New Version checkbox (default). If you want the device to operate according to the previous version, clear the Enable New Version checkbox.
6. Click Set. The device reboots, which takes a few minutes. 7. Verify that the console message shows the upgraded version.
Caution:
53
Software Versions List

LinkProof can simultaneously maintain two different software versions their respective configuration files. You can set which one of the existing versions is currently active. In addition, you can delete an inactive version.
To view the software versions on the device Select File > Software List. The Software Versions Table pane is displayed with the list of versions that the device currently contains.
Table 9: Software Versions Table Columns
Parameter
Name Index Valid Active Version
Description
The name of the version The index of the version in the Software List. The validity of the version. Values: TRUE, FALSE The current status of the version. Values: TRUE, FALSE The version number.
To delete a software version from the Software Versions Table 1. 2. Select File > Software List. The Software Versions Table pane is displayed with the list of versions that the device currently contains. In the row of the version to delete, select the checkbox and click Delete.
To activate a version using the Software Versions Table 1. 2. 3. 4. 5. Select File > Software List. The Software Versions Table pane is displayed with the list of versions that the device currently contains. Click the name of the version to activate. The Software Versions Table Update is displayed. From the Active drop-down list, select TRUE. Click Set. To implement the version activation, from the Device menu, select Reset Device; and then, click Set.
Licensing and Upgrading Licenses

You can upgrade the capabilities of LinkProof devices using the licensing mechanism, for example, to add APSolute OS support.
54
LinkProof User Guide Device Management For more information on licenses, contact Radware Technical Support. When you order a part number for the license upgrade, you receive from Radware a new license code and depending on the type of upgrade, a RAM extension that you should physically install in the device. To change the license, you need to insert a new license code. The license provided to you, is a onetime license, meaning that once this license is changed, the old license code cannot be re-used. For example, if an APSolute OS license was given to you on a trial basis and not purchased, Radware provides you with another license. The old license cannot be reused without APSolute OS support. The license is based on the MAC address of the device, and on a license ID that is changed every time a new license is inserted. To get a license upgrade, you need to send the MAC address and the current license ID of the device. To perform a license downgrade, send the MAC address and the current license ID of the device. Once you receive and insert this new license, a screen capture of the License Upgrade pane, or the output of system license get CLI command, must be sent to Radware to prove that you are using the new license.
To upgrade a software license using the CLI 1. Enter the following command:
system license
The current license code is displayed. 2. Enter the following command:
system license set <new license code>

A license updated message is displayed in the command line. 3. Enter the following command:
reboot
4. Enter yes to confirm the reset.
To view the device-license information using Web Based Management Select Device > License Upgrade. The License Upgrade pane is displayed.
Table 10: License Upgrade Parameters
Parameter
Base MAC Address License ID Insert your License Code
Description
The MAC address of the first port on the device. Reports the device software license ID and must be provided to the Radware ordering department when a new license is required. The device software license allows you to activate advanced software functionality. The value is case-sensitive. Manages the device throughput license ID and must be provided to the Radware ordering department when a new throughput license is required. Manages the device throughput level license.
Throughput License ID
Insert your Throughput License Code
55
To upgrade a license using Web Based Management 1. 2. Select Device > License Upgrade. The License Upgrade pane is displayed. The current license string is displayed in the Insert Your License Code field. Do the following: 3. 4. In the Insert Your License Code text box, type the new license code. In the Insert your Throughput License Code text box, type the device throughput level license.
Click Set. The Reset the Device pane is displayed. You must reset the device to validate the license. Click Set. The reset may take a few minutes. A success message is displayed upon completion.
Table 11: License Upgrade Parameters
Parameter
Base MAC Address License ID Insert your License Code
Description
The MAC address of the first port on the device. Reports the device software license ID and must be provided to the Radware ordering department when a new license is required. The device software license allows you to activate advanced software functionality. The value is case-sensitive. Manages the device throughput license ID and must be provided to the Radware ordering department when a new throughput license is required. Manages the device throughput level license.
Throughput License ID
Insert your Throughput License Code
Managing Configuration Files

This section contains the following topics: Sending a Configuration File to the Device, page 57 Downloading a Configuration File, page 57 Configuration Error Log Files, page 58
56
Sending a Configuration File to the Device
To send a configuration file to the device 1. Select File > Configuration > Send To Device. The Upload Configuration File to Device pane is displayed. 2. From the Upload Mode drop-down list, select one of the following: Replace configuration fileReplaces the configuration file with a new configuration file. This action requires rebooting the device. With this option, you can upload the file to the device in CLI format or BER format. Append commands to configuration fileAdds parts of a configuration into the device. For example, you can add a specific farm and its servers into a device configuration. This option also enables simple multi-device management, for example, pushing the same BWM policy to multiple devices at once. This option can only append commands that do not require rebooting the device for the commands to take effect. With this option, if a command that requires reboot is pasted/uploaded to the device, the command is not implemented. Append commands to configuration file with rebootAdds parts of a configuration into the device and reboots the device. Use this option if the commands in the file require rebooting the device to take effect. This includes commands like enabling BWM or modifying a tuning value. With this option, implementation takes place as follows: a. b. c. All commands that require rebooting the device are implemented. The device reboots. All commands that do not require rebooting the device are implemented.
3. In the Configuration File text box, type the path of the required file or click Browse to navigate to the required file. 4. Click Set. The file is uploaded to the device. 5. If you selected Replace configuration file or Append commands to configuration file, from the Device menu, select Reset Device and then Set in the Reset the Device pane.
Downloading a Configuration File

Note: If you are downloading a configuration file using Web Based Management, you cannot download to a device configured to use only SNMPv3.
57
To download a configuration file 1. 2. Select File > Configuration > Receive from Device. The Download Configuration File pane is displayed. From the Configuration Type drop-down list, select one of the following: RegularYou receive the device configuration file. Backup (Active-Backup)You receive the device configuration file created for the backup deviceto support configuration synchronization in an Active-Backup topology. You upload this configuration to the backup device. To enable the device to create such a configuration, you need to specify the IP address for the same interface on the backup device for each IP interface that you configured on this device (Router > IP Router > Interface Parameters > Create > Peer Address).
3. 4. 5. 6.
If you want the file to include private keys, select the Include Private Keys checkbox. Click Set. The Opening DeviceConfigurationFile<yyyy-MM-dd-hh-mm-ss> dialog box is displayed. Configure the file location and name as required. Click OK.
Configuration Error Log Files

LinkProof automatically generates a log of configuration errors.
Viewing the Configuration Error Log File

You can view the log file with the configuration errors.
To view the log file with the configuration errors Select File > Configuration > Logfile > Show. The Configuration Error Log pane is displayed with the configuration errors.
Clearing the Configuration Error Log File

You can clear the information contained in the configuration log file.
To clear the log file with the configuration errors 1. 2. Select File > Configuration > LogFile > Clear. The Configuration Error Log pane is displayed. Click Set.
Downloading the Configuration Error Log File

You can download the information contained in the configuration log file.
58
To download the log file with the configuration errors 1. Select File > Configuration > LogFile > Download. The Configuration Error Log pane is displayed. 2. Click Set.
Updating PoliciesActivating the Latest Changes

You need to explicitly activate changes to the device configuration at the following times: When you modify the configuration of a flow-management policy. When you modify the configuration of a filter that is used in an existing bandwidth-management (BWM) policy. When you modify the configuration of a class that is used in an existing policy.
You activate the latest changes from the Activate Latest Changes pane. The Activate Latest Changes pane is displayed regardless of the configuration path and its functionality is the same. Open the Activate Latest Changes pane by selecting one of the following: LinkProof > Flow Management > Update Policies BWM > Update Policies Classes > Update Policies
To activate the latest changes In the Activate Latest Changes pane, click Set.
Resetting the Device

After certain configuration changes, you need to reset the device for the changes to take effect.
To reset the device 1. Select Device > Reset Device. The Reset the Device pane is displayed. 2. Click Set.
59
Configuring Global Device Parameters

To configure the global parameters of the device 1. 2. Select Device > Global Parameters. The Device Global Parameters pane is displayed. Configure the parameters; and then, click Set.
Table 12: Device Global Parameters
Parameter
Description Name Location Contact Person System Up Time System Time System Date Bootp Server Address Bootp Threshold Software Version Hardware Version
Description
General description of the device (read only). User-assigned name of the device, which appears in the panes describing the device. Geographic location of the device. The person or people responsible for the device. Time elapsed since the last reset (read only). Current user-defined device time. Current user-defined device date. The IP address of the BootP server. The device forwards BootP requests to the BootP server and acts as a Bootp relay. How many seconds the device will wait before relaying requests to the BootP server. This delay allows local BootP Servers to answer first. The software version (read only). The hardware version (read only).
Device Information
You can view information on your LinkProof platform and software.
Note: Please quote this information when you seek assistance from Radware Technical Support.
To view device information Select Device > Device Information. The Device Information pane is displayed.
60
Table 13: Device Information Parameters
Parameter
Platform Ports Hardware Version Software Version Build Version State ApSolute OS Network Driver Active Boot Secondary Boot RAM Size (MB) CM Flash Size (MB) Flash Size (MB) Hard Disk(s) Serial Number System Up Time Base MAC Address CPUs Number Cores Number Power Supply Status
Description
The platform type. The quantity and types of physical ports on the platform. The hardware version. The LinkProof software version. The timestamp and the build number of the software. The state of this software version. Values: Open, Closed The versions of Bandwidth Management and Application Security modules for this software. The version of network driver. The time, in days, since the active boot commenced. The time, in days, since the secondary (redundant) boot commenced. The amount of RAM, in megabytes. The size, in megabytes, of the CompactFlash. The size, in megabytes, of the flash (permanent) memory. The number of hard disks on the device. The serial number of the device. The elapsed time since the last reboot. The MAC address of the first physical port on the device. The number of CPUs on the platform. The total number of cores on the platform. Values: Single Power Supply OK Dual Power Supply OK One Power Supply Failed
Device Monitoring
To view the Device Monitoring information Select Device > Device Monitoring. The Device Monitoring pane is displayed.
61
Table 14: Device Monitoring Categories
Category
Redundancy Logical Servers
Description
Contains a link to the backup device and the Redundancy Status. Contains a table with the following columns: Logical Server Status IP Address Type Mode In Rate Out Rate MAC Address
Farms
Contains a table with the following columns: FarmThe names of the farms configured on this device. To view or update the configuration of a farm, click the relevant link. TypeThe type of the farms. ServersThe servers in the farm and the status of each: Active, No New Sessions, or Not in Service. To view or update the configuration of a server, click the relevant link.
Device Information
Displays the following read-only information: NameThe user-defined name of the device. System Up TimeThe elapsed time since the last reboot. Software VersionThe LinkProof software version Base MAC AddressThe MAC address of the first physical port on the device.
Refresh Rate
Specifies the rate at wish the Device Monitoring information refreshes and update. To change the rate, enter the value in the field, and click Submit.
Session Table
The Session Table enables LinkProof to efficiently process traffic that the LinkProof device only routes or bridges and does not load balance. The Session Table mechanism is similar to the Client Table, but tracks sessions that are not recorded in the Client Table.
Session Table Global Parameters
To configure the Session Table global parameters 1. 2. Select Device > Session Table > Global Parameters. The Session Table Parameters pane is displayed. Configure the parameters; and then, click Set.
62
Table 15: Session Table Global Parameters
Parameter
Session Table Status
Description
If the device does not need to provide high performance for routed or bridged traffic, Radware recommends to disable the Session Table. Values: Enabled, Disabled Default: Disable
Session Table Aging Time
The time, in seconds, the LinkProof device keeps a non-active session the Session Table. Values: Must be greater than the TCP Handshake Timeout Default: 100
Session Table Lookup Mode
Indicates what layer of address information will be used to categorize packets in the Session Table. Values: Full Layer3An entry exists in the Session Table for each source IP and destination IP combination of packets passing through the device. This mode is recommended for higher performance, unless traffic classification on layer 4 or 7 is required. Full Layer4An entry exists in the Session Table for each source IP, source port, destination IP and destination port combination of packets passing through the device. This mode is the default mode for Session Table and it is recommended when traffic classification on layer 4 or 7 is required. Default: Full Layer 4
Remove Session Table Entry at Session End
Enable this feature to remove sessions from the Session Table when the session ends (only valid for Full Layer 4 Lookup Mode). Recommended to free resources when the aging time of the session table is set at a high value, however it can cause slight performance degradation. The size of the Session Table and the Session Passive Protocols Table (used to track sessions for protocols like passive FTP) is tunable using the Device Tuning pane or using the system tune CLI command. Values: Enabled, Disabled Default: Enabled
Send Reset To Server Status
Checks whether Session Table sends reset to server in case no data is transmitted through the session, because it can be a SYN attack. Values: Enabled, Disabled Default: Disabled
63
Session Table Entries

Use the View Table Query Results pane to do the following: View the Session Table entries. Set the maximum entries displayed in the Session Table Entries table. View the number of used entries. Configure the filter for the display of the Session Table entries in the View Table Query Results pane.
To view the Session Table entries Select Device > Session Table > View Table Query Results. The View Table Query Results pane is displayed; and the filtered Session Table entries are displayed in the Session Table Entries table.
Table 16: Session Table Entries Parameters
Parameter
Source IP Destination IP Source Port Destination Port Lifetime Aging Type SYN Protection Status
Description
The source IP address from which the traffic arrives. Default: 0.0.0.0 The destination IP address. Default: 0.0.0.0 The source port of the session. Default: 0 The destination port. Default: 0 The lifetime of the entry. The aging type of the entry. The SYN Flood Protection status of the entry.
To set the maximum entries displayed in the Session Table Entries table 1. 2. 3. Select Device > Session Table > View Table Query Results. The View Table Query Results pane is displayed. In the Maximum Displayed Entries text box, type the maximum number of Session Table entries to display. Values: 110,000. Default: 100. Click Set.
To view the number of used entries Select Device > Session Table > View Table Query Results. The View Table Query Results pane is displayed; and the Number of Used Entries parameter displays the number of used entries.
64
To configure the filter for the display of the Session Table entries in the View Table Query Results window 1. Select Device > Session Table > View Table Query Results. The View Table Query Results pane is displayed. 2. Click Create. The Query Filters Table Create pane is displayed. 3. Configure the parameters; and then, click Set.
Table 17: Query Filters Table Parameters
Parameter
Name Physical Port Source IP Source IP mask Dest IP Dest IP mask Source Port Dest Port
Description
The unique name of the filter, up to 19 characters. The physical port from which the request arrives. Default: 65,535 The source IP address within the defined subnet. Default: 0.0.0.0 The source IP mask. Default: 0.0.0.0 The destination IP address within the defined subnet. Default: 0.0.0.0 The destination IP mask. Default: 0.0.0.0 The source port of the session. Default: 0 The destination port. Default: 0
Bridging Support
A LinkProof device can perform bridging functionality.
Bridge Operating Parameters
To view and configure bridge operating parameters 1. Select Bridge > Operating Parameters. The Bridge Operating Parameters pane is displayed, with the following read-only parameters: Bridge AddressThe MAC Address used by the device Bridge TypeThe types of bridging the device can perform
2. Configure the parameters; and then, click Set.
65
Table 18: Query Filters Table Parameters
Parameter
Forwarding Table Aging Time
Description
The time, in seconds, the LinkProof device keeps learned entries in the Forwarding Table before deleting them. The counter resets each time the entry is used. Values: 101,000,000 Default: 3600
Delete entries when port Values: enable, disable goes down Default: enable
Bridge Forwarding Table

The Bridge Forwarding Table contains the bridging ports per destination MAC address. Use the Global Forwarding Table pane to monitor bridge forwarding nodes.
To monitor bridge forwarding nodes Select Bridge > Global Forwarding Table. The Global Forwarding Table pane is displayed.
Table 19: Bridge Forwarding Table Parameters
Parameter
Mac Address Port Status
Description
The MAC address of the node. The port through which the node has been learnedthat is, the port through which frames are received from this entry. Describes how the node entry was added to the list, and indicates status. Values: learnedThe entry was automatically learned. selfThe entry is a device port. MgmtThe entry is a static node manually entered using the Edit button. OtherThe node status cannot be described by one of the above.
Static Forwarding Table

Use the Static Bridge Forwarding Table pane you to monitor, create, and edit static bridge forwarding nodes.
To access the Static Forwarding Table Select Bridge > Static Forwarding Table. The Static Forwarding Table pane is displayed.
66
Table 20: Static Forwarding Table Parameters
Parameter
Static Mac Address Static Receive Port Status
Description
The MAC address of the static node. The port through which frames are received from this entry. Specifies how the node behaves when the device resets. Values: PermanentThe entry is remains after the device resets. Delete on ResetThe entry is deleted when the device resets.
To add a new static bridge forwarding node 1. Select Bridge > Static Forwarding Table. The Static Forwarding Table pane is displayed. 2. Click Create. The Static Forwarding Table Create pane is displayed. 3. Configure the parameters; and then, click Set.
Table 21: Static Forwarding Table Parameters
Parameter
Static Mac Address Static Receive Port Status
Description
The MAC address of the static node. The port through which frames are received from this entry. Specifies how the node behaves when the device resets. Values: PermanentThe entry is remains after the device resets. Delete on ResetThe entry is deleted when the device resets.
LinkProof Global Configuration General

Use the Global Configuration - General window to set various parameters that affect the global behavior of the LinkProof device.
To configure general LinkProof global parameters 1. Select LinkProof > Global Configuration > General. The Global Configuration - General pane is displayed. 2. Configure the parameters; and then, click Set.
67
Table 22: Global Configuration General Parameters
Parameter
Load Balancing Admin Status
Description
The status of the LinkProof device. Values: EnableThe device is active. All users are balanced between the servers. DisableThe device is inactive. Clients connecting to the device will be sent to the default server. Default: Enable Note: Typically, the value should remain Enable.
Ignore Flow Policies for Local Routes
Specifies whether the device ignores flow policies for local routes and forwards the traffic according to the routing table. Values: EnableFor each new session, the device checks whether the session is destined to be routed locally that is, the session requires routing but not through the default gateway (0.0.0.0 in the routing table). If this is the case, the flow policies are ignored and the traffic is forwarded according to the routing table. DisableFlow policies take precedence over routing. Default: Disable
Clients Connect Denials Translate Outbound Traffic to Virtual Address
Displays, read-only, the number of connection requests from clients that were denied by the dispatcher. When using virtual IP addresses, determines how addresses from the next server will behave. Values: enableChanges NAT addresses to virtual IP addresses. enableDoes not change NAT addresses. Default: disable
Fragmentation Table Aging Time
The time, in seconds, that an entry remains in the Fragmentation Table. Values: 110 Default: 1 Note: The Fragmentation Table holds the real UDP/TCP source and destination ports, the destination IP address and the Fragment ID. The device creates a new entry in the table when the first fragment arrives. The checksum of the first fragment is updated with changes to the IP addresses. Using the Fragmentation Table, the device can identify the correct source and destination ports for every fragment that arrives later, and translate (NAT) them properly. The device removes an entry from the table when the last fragment of the packet is received.
68
Table 22: Global Configuration General Parameters
Parameter
NHR Tracking Table Status
Description
Specifies whether the device uses the tracking table to make sure that traffic destined to the device is always returned via the correct server from which it arrived. Values: enable, disable Default: enable
NHR Tracking Table Aging
The time LinkProof keeps an entry in the NHR Tracking Table when no traffic matches it. Values: 13600 Default: 60
Discarded Sessions
Displays, read-only, the number of discarded sessions due to the configured limits being exceeded on servers since the device started. Specifies whether the LinkProof device provides information regarding the quality of the WAN links. For each link, the latency and relative hops distance is also displayed. You can view the information in the Link Quality Table (Performance > NHR Statistics > Link Quality Table). The table displays the best links for the top 10 destinations. Values: Enable, Disable Default: Disable
Link Quality Evaluation
Caution: Enabling this feature may negatively impact performance. Obsolete-Entry Aging Specifies whether the LinkProof device deletes obsolete entries in the Client Table that were not removed by any other process. There are cases where old Client Table entries are not removed from the Client Table even when their respective aging periods have expired. This is due to several client source-IP-addresses appearing in and disappearing from the Client Table within a very short interval. When this feature is enabled, LinkProof reviews the entire Client Table every 10 minutes (600 seconds), and deletes any entries whose aging period has expired. Values: Enable, Disable Default: Enable Note: Enabling this option has no impact on performance.
Virtual IP Addresses
69
LinkProof User Guide Device Management This section provides some basic load-balancing configuration examples, which can be implemented without using flow definitions. This section includes the following: Creating Virtual IP Addresses, page 70 Virtual IP Translation Ports Exclusion, page 70
Creating Virtual IP Addresses

You can create virtual IP addresses so that LinkProof can balance loads between NHRs where one or more use NAT addresses. You do so by creating a virtual IP address and mapping the NAT addresses of the NHRs to it. Clients destined to the virtual IP address are redirected to the appropriate NHR according to the configured Dispatch Method. You can configure up to 400 virtual IP addresses per LinkProof device. Use the Virtual IP Table pane to configure virtual IP addresses.
To configure a virtual IP address 1. 2. 3. Select LinkProof > Virtual IP > Virtual IP Table. The Virtual IPs Table pane is displayed. Select Create. The Virtual IPs Table Create pane is displayed. Configure the parameters; and then, click Set.
Table 23: Virtual IPs Table Parameters
Parameter
Virtual IP Address
Description
The IP address to which clients will connect. Virtual IP addresses must be on the same subnet as the LinkProof device. Default: 0.0.0.0 Defines the mode of the device. Values: RegularThe device is an active device. BackupThe device is a backup device. Default: Regular
Mode
Virtual IP Translation Ports Exclusion

VIP Translation Ports Exclusion enables you to have better control over the behavior of the Translate Outbound Address to Virtual Address feature. VIP Translation Ports Exclusion enables you to configure a specific application port for which this translation is excluded.
Notes: >> Up to 20 application ports can be excluded from VIP translation. >> The configuration of excluded ports applies to all VIPs configured for the device.
70
To configure port exclusion for VIP translation 1. Select LinkProof > Virtual IP > VIP Exclusion Policy. The Virtual IP Exclusion Policy pane is displayed. 2. Click Create. The Exclusion Policy Table Create pane is displayed. 3. In the Port text box, type the number of the port that you wish to exclude from VIP translation. 4. Click Set.
Mapping NAT Addresses to Virtual IP Addresses

After you create a virtual IP address, you can map NHR NAT addresses to it. You can assign each virtual IP address one NAT address from each NHR.
To map a new NAT address to a virtual IP 1. Select LinkProof > Mapped IP Table. The Mapped IPs Table pane is displayed. 2. Click Create. The Mapped IPs Table Create pane is displayed. 3. Configure the parameters; and then, click Set.
Table 24: Mapped IPs Table Parameters
Parameter
Virtual IP Address Next Hop Router Virtual NAT Address
Description
The virtual IP address to which to map the NAT address. The IP address of the NHR to map to the virtual IP address. The NAT address of the next hop router.
Device Tuning
This section describes the interfaces and methods for device tuning, and contains the following topics: Tuning Statistics Parameters, page 72 Tuning Memory Check, page 72 Tuning BWM Parameters, page 72 Tuning Classifier Parameters, page 73 Tuning Device Table Parameters, page 75 Tuning SYN Protection Parameters, page 80 Tuning Diagnostics Parameters, page 81 Tuning Security Parameters, page 81 Tuning Virtual Tunneling Parameters, page 83
71
Caution: Radware strongly recommends that you perform any device tuning only after consulting with Radware Technical Support.
Tuning Statistics Parameters

The changes to the tuning configuration take effect after a device reset.
To configure the Statistics tuning parameters 1. 2. Select Services > Tuning > Statistics. The Statistics Tuning pane is displayed. In the relevant After Reset fields, configure the parameters; and then, click Set.
Table 25: Statistics Tuning Parameters
Parameter
Protocol Discovery Policies
Description
The size of the table for Protocol Discovery Policies entries. Values: 2256 Default: 8
Protocol Discovery Report Entries
The total number of the discovered protocols that the LinkProof device can record. Values: 210000 Default: 128
Tuning Memory Check

You can check whether sufficient memory is available for the tuning you change.
To check whether the configured values will cause memory allocation problems In Web Based Management, select Services > Tuning > Memory Check. In CLI, use the command system tune test-after-reset-values.
Tuning BWM Parameters

To configure the BWM tuning parameters 1. 2. Select Services > Tuning > BWM. The BWM Tuning pane is displayed. In the relevant After Reset fields, configure the parameters; and then, click Set.
72
Table 26: BWM Tuning Parameters
Parameter
Policy Table
Description
The number entries in the BWM Policy Table. Values: 256150,000 Default: 1024
BW per Traffic Flow sessions tracking
The number of traffic flows for which the device can provide bandwidth or limit the number of sessions. Values: 16100,000 Default: 2048
Destination Table
The number of destination address entries in the Destination Table. Values: 64-128,000 Default: 256
Farms Classification Lists
Values: 110,000 Default: 64
Tuning Classifier Parameters

The changes to the tuning configuration take effect after a device reset. The BWM module uses the classifier objects (for example, networks, subnets, discrete IP address, and so on) for all the bandwidth-management policies on the device.
Example
Assume the following configuration: Network table size = 2 Subnets per network = 4 Discretes per network = 4 Object LAN1 with index 1: 192.168.10.0/24 Object LAN1 with index 2: 10.0.0.0/8 Object LAN1 with index 3: 292.167.10.0/24 Object LAN1 with index 4: 20.0.0.0/8 Object LAN1 with index 5: 2.2.2.1/32 Object LAN1 with index 6: 3.2.2.1/32 Object LAN1 with index 7: 6.2.2.1/32 Object LAN1 with index 8: 7.2.2.1/32 Object LAN2 with index 0: 20.2.3.1/32
You cannot create an object LAN3, because the network table size has been exceeded. You cannot create an object LAN1 with index 9: 9.1.1.1/32, because the discrete-per-network size has been exceeded. That is, four entries with mask 32 already exists. You cannot create an object LAN1 with index 9: 40.0.0.0/8, because the subnets-per-network size has been exceeded. That is, four entries containing a range already exists, regardless whether they were defined using a range flag or mask flag. You can create objects LAN2 with index 9 40.0.0.0/8 and LAN2 with index 9 9.1.1.1/32.
73
To configure the Classifier tuning parameters 1. 2. Select Services > Tuning > Classifier. The Classifier Tuning pane is displayed. In the relevant After Reset fields, configure the parameters; and then, click Set.
Table 27: Classifier Tuning Parameters
Parameter
Network Table
Description
The number of network entries defined by name and index. For example, for a network with two indexes, two entries are consumed. Values: 3210,000 Default: 1024
Discrete IP Addresses Per Network
The number of discrete IP addresses in the network (with a /32 subnet mask). Values: 150,000 Default: 1024
Subnets Per Network
The number of non-discrete IP subnets (with a range or mask smaller than a /32). Values: 16256 Default: 64
Dynamic Network Table
The number of dynamic network entries defined by name and index. For example, for a network with two indexes, two entries are consumed. Values: 16256 Default: 64
Discrete IP Addresses Per Dynamic Network
The number of discrete IP addresses in a dynamic network (with a /32 subnet mask). Values: 150,000 Default: 1024
Subnets Per Dynamic Network
The number of non-discrete IP subnets (with a range or mask smaller than a /32) per dynamic network. Values: 150,000 Default: 64
MAC groups Table
The number of MAC groups entries in the table. Values: 16-2048 Default: 128
Filter Table
Thee number of basic filter entries in the table. Values: 642048 Default: 512
AND Group Table
The number of AND Group entries in the table. Values: 322048 Default: 256
74
Table 27: Classifier Tuning Parameters
Parameter
OR Group Table
Description
The number of OR Group entries in the table. Values: 322048 Default: 256
Application port groups
The number of application port group entries in the table. Values: 11000 Default: 20
Content Table
The number of content entries in the table. Values: 84096 Default: 512
Tuning Device Table Parameters

The device tables store information about sessions passing through the device. Some of the tables store information for every source-destination address pair of traffic going through the device, which includes Layer 3 information. 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 sourceaddress, 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. The changes to the tuning configuration take effect after a device reset. To view a list of values for LinkProof tuning tables, log onto the Radware Web site; and then, navigate to Support > Documentation > Product (LinkProof) > Document Type (Tuning Table).
75
To configure the tuning parameters for the device tables 1. 2. Select Services > Tuning > Device. The Device Tuning pane is displayed. In the relevant After Reset fields, configure the parameters; and then, click Set.
Table 28: Device Table Tuning Parameters
Table
Flow Policies Table
Description
The maximum number of entries in the Flow Policies table. A flow policy defines the criteria used to select a specific flow for a specific type of traffic. When a new session arrives, the device scans through the flow policies list looking for a match. Once a match is found, the packet is redirected according to the flow attached to this policy. Values: 165000 Default: 64
Session Table
The maximum number of entries in the Session table. The Session Table keeps track of sessions that were not recorded in the Client Table. Values: 206,500,000 Default: 1,000,000
Session Passive Protocols The maximum number of entries in the Session Passive Protocols Table. Table The Session Passive Protocols Table records passive protocols port commands so that all related sessions will be maintained. Values: 1632,000 Default: 4096 Session Resets Table The maximum number of entries in the Session Resets Table. Values: 1 100,000 Default: 100 Bridge Forwarding Table The maximum number of entries in the Bridge Forwarding Table. The Bridge Forwarding Table contains the bridging ports per destination MAC address. Values: 2032,767 Default: 1024 IP Forwarding Table The maximum number of entries in the IP Forwarding table. The table contains the destination MAC address and port per destination IP address. Values: 20768,000 Default: 32,000 ARP Forwarding Table The maximum number of entries in the ARP Forwarding Table. The table contains the destination MAC address per destination IP address. Values: 2032,767 Default: 1024
76
Table
Client Table
Description
The maximum number of entries in the Client Table. When setting the Client table size, you must also configure the Client Extension Table size. The relationship between the two table sizes is as follows: Client Extension Table size = (Maximum number of farms in a chain, as configured on the device) (Client Table size). For example, if LinkProof load balances routers only, the Client Table Extension size should be the same as the Client Table Size. OnDemand Switch VL with 2 GB RAM and OnDemand Switch 2 with 2 GB RAM: Values: 202,000,000 Default: 500,000 OnDemand Switch VL with 4 GB RAM, OnDemand Switch 2 with 4 GB RAM, and OnDemand Switch 3 with 8 GB RAM: Values: 206,500,000 Default: 1,000,000
Client Table Extension
The maximum number of entries in the Client Table Extensions. OnDemand Switch VL with 2 GB RAM and OnDemand Switch 2 with 2 GB RAM: Values: 202,000,000 Default: 500,000 OnDemand Switch VL with 4 GB RAM, OnDemand Switch 2 with 4 GB RAM, and OnDemand Switch 3 with 8 GB RAM: Values: 206,500,000 Default: 1,000,000
Routing Table
The maximum number of entries in the Routing table. The table stores information about the destinations and how they can be reached. By default, all networks directly attached to the device are registered in this table. Other entries to the table can either be statically configured or dynamically created through the routing protocol. Values: 2032,767 Default: 512
77
Table
Farm Persistency Table
Description
The maximum number of entries in the Farm Persistency table. The Farm Persistency Table stores data for the device to use same server for packets of the same session, according to the specified sessionidentification parameter or combination of them, less than the Client Table mode (for example, source IP or destination IP if Client Table mode is Layer 3) or according to Client Table mode. The default persistency mode is Layer 4. OnDemand Switch VL with 2 GB RAM and OnDemand Switch 2 with 2 GB RAM: Values: 204,000,000 Default: 500,000 OnDemand Switch VL with 4 GB RAM, OnDemand Switch 2 with 4 GB RAM, and OnDemand Switch 3 with 8 GB RAM: Values: 2013,000,000 Default: 1,000,000
Delayed Binding Ext. Table
The maximum number of entries in the Delayed Binding Ext. Table, which stores the fragments per delayed binding sessions that LinkProof retains (in all delayed binding active sessions). OnDemand Switch VL with 2 GB RAM and OnDemand Switch 2 with 2 GB RAM: Values: 12,000,000 Default: 500,000 OnDemand Switch VL with 4 GB RAM, OnDemand Switch 2 with 4 GB RAM, and OnDemand Switch 3 with 8 GB RAM: Values: 16,500,000 Default: 1,000,000
Proximity Subnets
The maximum number of proximity entries in the proximity database. Values: 1500,000 Default: 20,000
No NAT Table
The maximum number of No NAT addresses that can be configured on the device. No NAT enables a simple configuration where internal hosts have IP addresses that belong to a range of one of the farm servers. Traffic from these hosts should not be translated if the traffic is forwarded to this farm server. Values: 6420,000 Default: 512
Static NAT Table
The maximum number of Static NAT addresses that can be configured on the device. Static NAT is used to ensure delivery of specific traffic to a particular server on the internal network.Values: 648,192 Default: 512
78
Table
Basic NAT Table
Description
The maximum number of Basic NAT addresses that can be configured on the device. Basic NAT enables a one-to-one NAT mapping for occasional users, based on local IP ranges and destination applications. Values: 208,192 Default: 512
PAT & Dynamic NAT Port Table
The maximum number of entries in the PAT & Dynamic NAT Port Table. Values: 307260,535 Default: 60534 The maximum number of entries in the Dynamic NAT Table. Values: 11024 Default: 30
Dynamic NAT Table
URL to IP Table
The limit on the number of entries in the URL to IP table. Values: 10030,000 Default: 10,000
NHR Tracking Table
The limit on the number of entries in the NHR Tracking Table. This table ensures that for inbound traffic received via a certain NHR, the related outbound traffic is sent via the same NHR. Values: 10030,000 Default: 100,000
Delayed Bind Table
The maximum number of entries in the Delayed Bind table. Delayed Bind is a process in which the device alters fields such as the sequence number of the TCP stream from the client to the destination server. The subsequent session fetches the information that was requested in the original session. The information is returned to the client through the original session only when that information is gathered. OnDemand Switch VL with 2 GB RAM and OnDemand Switch 2 with 2 GB RAM: Values: 1131,070 Default: 30,000 OnDemand Switch VL with 4 GB RAM, OnDemand Switch 2 with 4 GB RAM, and OnDemand Switch 3 with 8 GB RAM: Values: 1262,140 Default: 50,000
Delayed Bind SYN Protection Triggers Table
The maximum number of entries in the Delayed Bind SYN Protection Triggers Table. Values: 10100,000 Default: 2048
79
Tuning SYN Protection Parameters

To configure the SYN Protection tuning parameters 1. 2. Select Services > Tuning > SYN Protection. The SYN Protection Tuning pane is displayed. In the relevant After Reset fields, configure the parameters; and then, click Set.
Table 29: SYN Protection Tuning Parameters
Parameter
SYN Protection Table
Description
The number of entries in the SYN Protection Table, which stores data regarding the delayed binding process. An entry in the table exists from the time the client completes the handshake until the handshake is complete. Values: 101,000,000 Default: 16,384
SYN Protection Requests The number of entries in SYN Protection Requests Table, which stores the Table ACK or data packet that the client sends, until the handshake with the server is complete and the packet is sent to the server. Values: 132,000 Default: 100 Note: The Request Table and the SYN Protection Table must be about the same size. The value for the SYN Protection Triggers Table should be much smaller. SYN Protection Triggers Table The number of entries in SYN Protection Triggers Table, which stores the active triggersthat is, the destination IPs/ports on which the devices identifies an ongoing attack. Values: 10100,000 Default: 16,384 SYN Protection Policies Table The number of entries in the SYN Protection Policies Table, which stores policies that control the SYN protection behavior for different types of traffic. Values: 164096 Default: 64 ACK reflection IPs Table The number of entries in the ACK Reflection IPs Table. The table stores the number of SYN packets per second for the sampled and monitored source IP addresses. Values: 10100,000 Default: 16,384 SYN Protection Attack Detection Entries SYN Statistics Entries The maximum number of SYN Protection Attack Detection Entries. Values: 101,000,000 Default: 16,384 The maximum number of SYN Statistics Entries. Values: 11000 Default: 10
80
Tuning Diagnostics Parameters

To configure the Diagnostics tuning parameters 1. Select Services > Tuning > Diagnostics. The Diagnostics Tools Tuning pane is displayed. 2. In the Policies after reset field, configure the parameter; and then, click Set. Values: 1256. Default: 16.
Tuning Security Parameters

Security Tuning parameters comprise the following: Tuning Application Security parameters Tuning Behavioral DoS parameters
Tuning Application Security Parameters

The Application Security Tables store information about sessions passing through the device and their sizes, which are correlated to the actual amount of sessions. The changes to the tuning configuration take effect after a device reset.
To configure the Application Security Tuning parameters 1. Select Services > Tuning > Security > Application Security. The Application Security Tuning Parameters pane is displayed. 2. In the relevant After Reset fields, configure the parameters; and then, click Set.
Table 30: Application Security Tuning Parameters
Parameter
Maximal number of groups to be defined by user
Description
The maximum number of groups defined in the User Groups table. The Groups Table lists the number of entries of attack groups defined by the user.i Values: 1300 Default: 50
Maximal number of attacks to be defined by user
The maximum number of attack entries in the User Attacks Database Table. The Attacks Database Table contains attacks provided by Radware as well as userdefined attacks.i Values: 12000 Default: 100
81
Parameter
Maximal number of srcIPs in Suspend Table
Description
This Suspend Table allows the user to define that for certain attacks, in addition to the action defined in the attack, the device should also suspend traffic from the IP address that was the source of the attack, for a period of time.i The maximum amount of source lP addresses in the Suspend Table. All traffic from the IP address identified as source of this attack will be suspended. Values: 1000100,000 Default: 10,000
Counters Source Table
The number of sessions to check the source address. i Values: 100100,000 Default: 16,384
Counters Target Table
Then number of sessions to check the target address.i Values: 10064,000 Default: 16,384
Counters Source & Target Table
The Source & Target Table contains an attack detection mechanism, which is based on the source and destination addresses of the incoming traffic. Each entry of 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, this is identified as an attack. The Source & Target Table tuning parameter defines in how many sessions to check the source.i Values: 10064,000 Default: 16,384
Counters DHCP Table
The number of entries in the Counters 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.i The DHCP Discover tuning parameter determines for how many MAC addresses to check the number of IP requests. Values: 10064,000 Default: 16,384
82
Parameter
Maximal number of entries in NCPF table
Description
The maximal number of entries in NCPF table.i Values: 1616,000 Default: 2000
Maximal number of Anti-Scanning IP pairs The Anti-Scanning IP pairs table is an internal table Table which is not configured by the user.i Values: 10,0001,000,000 Default: 10,000
i This parameter is exposed only if the device has an IPS license.
Tuning Behavioral DoS Parameters

To modify the maximal number of Behavioral DoS policies that the device supports 1. Select Services > Tuning > Security > Behavioral DoS. The Behavioral DoS Tuning Parameters pane is displayed. 2. In the Maximal number of Behavioral DoS policies after reset field, configure the parameter; and then, click Set. Values: 11000. Default: 1.
Tuning Virtual Tunneling Parameters

Virtual Tunneling tables are used to define the Virtual Tunneling tuning parameters. The changes to the tuning configuration take effect after a device reset. To view virtual tunneling tuning parameters, you must first enable the Virtual Tunneling Admin Status option.
Caution: It is strongly advised that device tuning only be carried out after consulting with Radware Technical Support.
Note: Before activating Virtual Tunneling, ensure that Smart NAT functionality and Use Connectivity Checks are selected from the Health Monitoring Global Parameters pane.
83
To configure the virtual-tunneling tuning parameters 1. 2. Select Services > Tuning > Virtual Tunneling. The Virtual Tunneling Tuning pane is displayed. In the relevant After Reset fields, configure the parameters; and then, click Set.
The following table describes the virtual-tunneling tuning settings.
Table 31: Virtual Tunneling Settings
Table
Local Service Table
Description
The maximum number of entries in the Local Service Table. Values: 18 Default: 4
Remote Service Table
The maximum number of entries in the Remote Service Table. Values: 132 Default: 12
Tunnels per remote service
The maximum number of entries in the Tunnels per Remote Service Table. Values: 1100 Default: 12
Local Station table
The maximum number of entries in the Local Station table. Values: 132 Default: 24
Remote Station table
The maximum number of entries in the Remote Station Table. Values: 11024 Default: 250
Device Notifications
Most administrators prefer to receive a warning message about a network or server outage. To help minimize the impact of failure in devices such as firewalls, routers, or application servers, LinkProof provides a choice of notification methods: CLI traps, syslog, and e-mail. This section describes the LinkProof notification features, which distribute warning messages about failures and problems in network elements. This section contains the following topics: CLI Traps, page 85 Syslog Reporting, page 85 SMTP E-mail Notifications, page 86 Configuration Trace, page 87
84
CLI Traps
To send traps by CLI, Telnet, and SSH Use the command manage terminal traps-outputs set-on. For console only, use the command manage terminal traps-outputs set normal. 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, LinkProof generates the following error message: 10-01-2007 08:35:42 WARNING NextHopRouter 10.10.10.10 Is Not Responding to Ping. A device can send traps to all CLI users This option enables you to configure whether the device sends traps only to the serial terminal or also to SSH and Telnet clients.
Syslog Reporting
LinkProof can mirror event traps to a specified syslog server. You can also define additional notification criteria such as Facility and Severity, which are expressed by numerical values. Facility indicates the type of device of the sender, while Severity indicates the importance or impact of the reported event. The user-defined Facility value is used when the device sends Syslog messages. The default value is 21, meaning Local Use 6, which is the value used by LinkProof versions previous to 3.0. The Severity value is determined dynamically by the device for each message that the device sends.
To configure sending traps to a syslog server 1. Select Services > Syslog Reporting. The Syslog Reporting pane is displayed. 2. Configure the parameters; and then, click Set.
Table 32: Syslog Reporting Parameters
Parameter
Syslog Operation Syslog Station Address
Description
Enables or disables syslog reporting. Values: enable, disable The IP address of device running the syslog service (syslogd). Default: 0.0.0.0
85
Table 32: Syslog Reporting Parameters
Parameter
Syslog Station Facility
Description
Type of device of the sender. This is sent with syslog messages. Values: 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 Local Use 1 Local Use 2 Local Use 3 Local Use 4 Local Use 5 Local Use 6 Local Use 7 Default: Local Use 6
Syslog Source Port
The syslog source port. Default: 512
SMTP E-mail Notifications

You can configure the LinkProof device to send e-mail messages to users configured in the devices User Table. For each user, you can set the level of SNMP traps notification the user receives. You do this in the User Table; each user is assigned a level of severity and receives traps according to that severity or higher. The severity levels are Info, Warning, Error, and Fatal. When you specify the severity level Error, you receive e-mail traps of events of severity level Error and Fatal. This configuration applies both for SNMP traps and for SMTP e-mail notifications. SMTP notifications are enabled globally for the device. Using the Send E-mail on Errors option, you can configure traps to be sent by e-mail to predefined users with different levels of severity.
86
To configure e-mail notifications 1. Select Services > SMTP. The SMTP pane is displayed. 2. Configure the parameters; and then, click Set.
Table 33: SMTP Parameters
Parameter
SMTP Primary Server Address SMTP Alternate Server Address
Description
The IP address of the SMTP server. 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 the main SMTP server closed the connection. The device tries to establish connection to the main SMTP server, and starts re-using it when available. The mail address of the device. For example myname@example.com. Enables or disables the SMTP client. Values: enable, disable Default: disable Note: The SMTP Status must enable to support features that are related to sending e-mail messages.
Own Email Address SMTP Status
Send emails on Errors
Enables or disables sending e-mails on errors. To receive e-mail about errors, enable features related to e-mail, such as Send Emails on Errors; and for each user, set e-mail address and severity level in the User Table. Values: enable, disable Default: disable
Configuration Trace
LinkProof can monitor any configuration changes on the device, and report those changes by sending out e-mail notifications. Every time the value of a configuration variable changes, information about all the variables in the same MIB entry is reported to users. Configuration reports are enabled for each user in the User Table.
Note: LinkProof 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. The notification message contains the following details: Name of the MIB variable that was changed New value of the variable Time of configuration change Configuration tool that was used (Telnet, SSH, WBM) User name, when applicable
87
DNS-Client Utility
You can configure LinkProof to operate as a DNS client. When the DNS-client feature is not used, IP addresses cannot be resolved. When the DNS-client feature is enabled, IP addresses can be resolved in the following ways: Using the specified DNS servers. The DNS client sends queries on IP addresses of a hostname to the DNS servers. Using the predefined static table, which includes hostnames and IP addresses.
To display the dynamic DNS table in the CLI Enter the command services dns nslookup <hostname>. The DNS table is displayed.
To specify a primary and secondary DNS server 1. 2. Select Services > DNS. The DNS Client Parameters pane is displayed. Configure the parameters; and then, click Set.
Table 34: DNS Client Parameters
Parameter
Primary DNS Server Alternate DNS Server
Description
The IP address of the primary DNS server. The IP address of the alternate DNS server.
To configure an entry in the static DNS table 1. 2. 3. Select Services > DNS. The DNS Client Parameters pane is displayed. Click Create. The Static DNS Table Create pane is displayed. Configure the parameters; and then, click Set.
Table 35: DNS Client Parameters
Parameter
Host Name IP Address 4.
Description
The domain name for the specified IP address. The IP address for the specified domain name.
88
Show Tech-Support
A LinkProof device can generate a technical-support file, which you can save to a specified location and send to Radware Technical Support to help diagnose problems. Using the CLI, the technical-support file includes the following: The data that Radware Technical Support typically needs to diagnose a problem with a LinkProof device. The data comprises the collected output from various CLI commands. A record of each configuration change to the device (by any management interface). A device begins storing these records when the device receives its first command. The records are sorted by date in ascending order. When the size of the data exceeds the maximum allowed size (2 MB), the oldest record is overwritten. The entire data is never cleared unless you erase the device configuration.
lp_support.txt Contains the data that Radware Technical Support typically needs to
diagnose a problem with a LinkProof device. The data comprises the collected output from various CLI commands.
auditLog.log Contains record of each configuration change to the device (by any
management interface). A device begins storing these records when the device receives its first command. The records are sorted by date in ascending order. When the size of the data exceeds the maximum allowed size (2 MB), the oldest record is overwritten. The entire data is never cleared unless you erase the device configuration The structure of each record in the auditLog.log file is as follows:
<dd>-<MM>-<yyyy> <hh>:<mm>:<ss> <Event description>

Example:
06-12-2009 19:16:11 COMMAND: logout by user radware via Console
To generate and display the output of the technical-support file on the terminal using CLI Enter the following command:
manage support display
To generate a technical-support file and send it to a TFTP server using CLI Enter the following command:
manage support tftp put <file name> <TFTP server IP address> [-v]
where:
-v displays also the output of the command.
To generate and download the technical-support file using Web Based Management 1. Select File > Support. The Download Tech Support Info File pane is displayed. 2. Click Set. A File Download dialog box opens. 3. Click Open or Save and specify the required information.
89
Diagnostics
LinkProof supports the following diagnostic tools: Traffic Capture Trace-Log
Diagnostic tools are only available using CLI or Web Based Management. Diagnostic tools start working only after there is a diagnostic policy configured on the device (see Diagnostics Policies, page 95) and the relevant options are enabled. Diagnostic tools stop automatically in the following cases: You stop the relevant task. You reboot the device. That is, when the device reboots, the status of the Capture Tool reverts to Disabled.
This section contains the following topics: Traffic Capture Tool, page 90 Trace-Log, page 91 Diagnostic Tools Files Management, page 95 Diagnostics Policies, page 95
Traffic Capture Tool

The Traffic Capture tool captures packets that enter the device, leave the device, or both. The captured traffic is in TCPDUMP format. You can download the captured packets, and analyze the traffic using Unix snoop or various tools. For remote administration and debugging, you can also send captured traffic to a terminal (CLI, Telnet, and SSH). You can specify where the device captures packets to get a better understanding of the traffic flowespecially if the device manipulates the packetsdue to NAT, traffic from a VIP to a real server, and so on.
Caution: Enabling this feature may cause severe performance degradation. The Traffic Capture tool uses the following format for packet capture files:
capture_<Device Name>_ddMMyyyy_hhmmss_<file number>.cap
To configure the Capture Tool using Web Based Management 1. 2. Select Services > Diagnostics > Capture > Parameters. The Capture Tool Configuration pane is displayed. Configure the parameters; and then, click Set.
90
Table 36: Capture Tool Configuration Parameters
Parameter
Status
Description
Specifies whether the Capture Tool is enabled. Values: Enabled, Disabled Default: Disabled Note: When the device reboots, the status of the Capture Tool reverts to Disabled.
Output To File
Specifies the location of the stored captured data. Values: RAM Drive and FlashThe device stores the data in RAM and appends the data to the file on the CompactFlash drive. Due to limits on CompactFlash size, LinkProof uses two files. When the first file becomes full, the device automatically switches to the second, until it is full and then it overwrites the first file, and so on. RAM DriveThe device stores the data in RAM. NoneThe device does not store the data in RAM or flash, but you can view the data using a terminal.
Output To Terminal
Specifies whether the device sends captured data to the terminal. Values: Enabled, Disabled Default: Disabled
Capture Point
Specifies where the device captures the data. Values: On Packet ArriveThe device captures packets when they enter the device. On Packet SendThe device captures packets when they leave the device. BothThe device captures packets when they enter the device and when they leave the device.
Traffic Match Mode
Specifies how the device logically captures a session traversing a VIP. Each session sent to a device VIP has two sidesthe client side (the session between the client and the VIP) and the server side (the session between the LinkProof device and the server). This parameter has no effect on traffic that does not traverse a VIP. Values: Inbound onlyCapture the client-side session only. Inbound and OutboundCapture both the client-side and the corresponding server-side sessions. Default: Inbound only
Trace-Log
The Trace-Log tool provides data on the traffic flow within the device. The feature is intended for debugging purposes only.
Caution: Enabling this feature may cause severe performance degradation.
91
LinkProof User Guide Device Management LinkProof uses the following format for Trace-Log files:
trace_log_<Device Name>_ddMMyyyy_hhmmss_<file number>.txt

This section contains the following topics: Trace-Log Tool Configuration, page 92 Diagnostics Trace-Log Message Format, page 92 Trace-Log Modules, page 93
Trace-Log Tool Configuration
To configure the Trace-Log tool 1. 2. Select Services > Diagnostics > Trace-Log > Parameters. The Diagnostics Trace-Log Tool Configuration pane is displayed. Configure the parameters; and then, click Set.
Table 37: Trace-Log Tool Configuration Parameters
Parameter
Status
Description
Specifies whether the Trace-Log tool is enabled. Values: Enabled, Disabled Default: Disabled
Output To File
Specifies the location of the stored data. Values: RAM Drive and FlashThe device stores the data in RAM and appends the data to the file on the CompactFlash drive. Due to limits on CompactFlash size, LinkProof uses two files. When the first file becomes full, the device automatically switches to the second, until it is full and then it overwrites the first file, and so on. RAM DriveThe device stores the data in RAM. NoneThe device does not store the data in RAM or flash, but you can view the data using a terminal.
Output To Terminal
Specifies whether the device sends Trace-Log data to the terminal. Values: Enabled, Disabled Default: Disabled
Output To Syslog Server
Specifies whether the device sends Trace-Log data to a syslog server. Values: Enabled, Disabled Default: Disabled
Diagnostics Trace-Log Message Format

Use the Diagnostics Trace-Log Message Format pane to specify which parameters appear in the Trace-Log message.
92
To configure the diagnostics Trace-Log message format 1. Select Services > Diagnostics > Trace-Log > Message Format. The Diagnostics Trace-Log Message Format pane is displayed. 2. Configure the parameters; and then, click Set.
Table 38: Diagnostics Trace-Log Message Format Parameters
Parameter
Date Time Platform Name File Name Line Number Packet Id Module Name Task Name
Description
Specifies whether the date that the message was generated is included in the Trace-Log message. Specifies whether the time that the message was generated is included in the Trace-Log message. Specifies whether the platform MIB name is included in the Trace-Log message. Specifies whether the output file name is included in the Trace-Log message. Specifies whether the line number in the source code is included in the TraceLog message. Specifies whether an ID assigned by the device to each packet is included in the Trace-Log message. This enables you see the order of the packets. Specifies whether the name of the traced module is included in the Trace-Log message is included in the Trace-Log message. Specifies whether the name of the specific task of the traced module is included in the Trace-Log message.
Trace-Log Modules
To help pinpoint the source of a problem, you can specify which LinkProof modules the Trace-Log feature works on and the log severity per module. For example, you can specify that the Trace-Log feature traces only the Health Monitoring module to understand why a specific health check fails.
93
To configure the parameters of the Trace-Log modules 1. Select Services > Diagnostics > Trace-Log > Modules. The Trace-Log Modules pane is displayed. The table in the pane comprises the following columns:
Column
Name
Description
Name of the module. Values: BWM GENERIC HMM LCD
Status Severity
Current status of the traced module. The lowest severity of the events that the Trace-Log includes for this module. Values: Emergency Alert Critical Error Warning Notice Info Debug
2. 3.
Click the relevant link. The Trace-Log Modules Update pane is displayed. Configure the parameters; and then, click Set.
Table 39: Trace-Log Modules Update Parameters
Parameter
Status Severity
Description
Specifies whether the Trace-Log feature is enabled for the module. The lowest severity of the events that the Trace-Log includes for this module. Values: Emergency Alert Critical Error Warning Notice Info Debug Note: The default varies according to module.
94
Diagnostic Tools Files Management

LinkProof can store the output of the diagnostic tools in RAM and in the CompactFlash. If the device is configured to store the output in the CompactFlash, when the data size in RAM reaches its limit, the device appends the data chunk from RAM to the file on the CompactFlash drive. For each enabled diagnostic tool, LinkProof uses two temporary files. When one temporary file reaches the limit (1 MB), LinkProof stores the information in the second temporary file. When the second temporary file reaches the limit (1 MB), LinkProof overwrites the first file, and so on. When you download a CompactFlash file, the file contains both temporary files. Use the Diagnostic Tools Files Management pane to download or delete files from the RAM or CompactFlash.
To download or delete Trace-Log data 1. Select Services > Diagnostics > Files. The Diagnostic Tools Files Management pane is displayed. The pane contains two tables, Files On RAM Drive and Files On Main Flash. Each table comprises the following columns:
Parameter
File Name File Size Action
Description
The name of the file. The file size, in bytes. The action that you can take on the data stored. Values: downloadStarts the download process of the selected data. Follow the on-screen instructions. deleteDeletes the selected file.
2. From the Action column, select the action, Download or Delete, and follow the instructions.
Diagnostics Policies
In most cases, there is no need to capture all the traffic passing through the device. Using diagnostic policies, the device can classify the traffic and store only the required information.
Note: To reuse the policy, edit the policy and set it again.
To configure a diagnostics policy using Web Based Management 1. Select Services > Diagnostics > Policies. The Diagnostics Policies pane is displayed. 2. Click Create. The Diagnostics Policies Create pane is displayed. 3. Configure the parameters; and then, click Set.
95
Table 40: Diagnostics Policies Parameters
Parameter
Name Index
Description
The user-defined name of the policy up to 20 characters. The number of the policy in the order in which the diagnostics tools classifies (that is, captures) the packets. Default: 1 The user-defined description of the policy. The VLAN Tag group whose packets the policy classifies (that is, captures). The destination IP address or predefined class object whose packets the policy classifies (that is, captures). Default: anyThe diagnostics tool classifies (that is, captures) packets with any destination address.
Description VLAN Tag Group Destination
Source
The source IP address or predefined class object whose packets the policy classifies (that is, captures). Default: anyThe diagnostics tool classifies (that is, captures) packets with any source address.
Outbound Port Group Inbound Port Group Service Type Service
The port group whose outbound packets the policy classifies (that is, captures). The port group whose inbound packets the policy classifies (that is, captures). The service type whose packets the policy classifies (that is, captures). The service whose packets the policy classifies (that is, captures). Values: None Basic Filter AND Group OR Group Default: None
Destination MAC Group Source MAC Group
The Destination MAC group whose packets the policy classifies (that is, captures). The Source MAC group whose packets the policy classifies (that is, captures).
Maximal Number of Packets The maximal number of packets the policy captures. Once the policy captures the specified number of packets, it stops capturing traffic. In some cases, the policy captures fewer packets than the configured value. This happens when the device is configured to drop packets. Maximal Packet Length Capture Status The maximal length for a packet the policy captures. Specifies whether the packet-capture feature is enabled in the policy. Values: Enabled, Disabled Default: Disabled Trace-Log Status Specifies whether the Trace-Log feature is enabled in the policy. Values: Enabled, Disabled Default: Disabled
96
Management Interfaces
This section describes the management interfaces that LinkProof supports and contains the following topics: Configuring a Telnet Management Interface, page 97 Configuring Web Server Management Interfaces, page 98 Configuring an SSH Interface for Management, page 100 Configuring an FTP Interface for Management, page 101
Configuring a Telnet Management Interface

You can access LinkProof via Telnet. You can configure Telnet access using Web Based Management or CLI.
To configure a Telnet management interface 1. Select Services > Management Interfaces > Telnet. The Telnet Parameters pane is displayed. 2. Configure the parameters; and then, click Set.
Table 41: Telnet Parameters
Parameter
Telnet Port Telnet Status Telnet Session Timeout
Description
The TCP port used by the Telnet. Enables and disables the Telnet interface. The time, in minutes, that the device maintains a connection during inactive periods. Values: 0Specifies no timeout 1120 Default: 5 Note: To avoid affecting device performance, the timeout is automatically checked every 10 seconds, meaning that the actual timeout can be up to 10 seconds longer.
Telnet Authentication Timeout
Timeout, in seconds, to complete authentication process. Values: 1060 Default: 30
97
To configure the console timeouts using CLI Use the following commands as appropriate:
manage terminal session-timeout manage ssh session-timeout manage telnet session-timeout manage ssh auth-timeout manage telnet auth-timeout
Note: In order not to affect the performance of the device, a special task checks the timeout every 10 seconds. This means that the actual timeout can be up to 10 seconds longer.
Configuring Web Server Management Interfaces

You can use Web Server parameters to enable and define to which port the Web Based Management is assigned.
Web
To configure Web parameters 1. 2. Select Services > Management Interfaces > Web Server > Web. The Web Server Parameters pane is displayed. Configure the parameters; and then, click Set.
Table 42: Web Server Parameters
Parameter
Web Server Port Web Server Status
Description
Port to which the Web Based Management is assigned. Enables or disables the status of the Web server.
98
Table 42: Web Server Parameters
Parameter
Web Help Location Web Access Level
Description
Location (path) of the Web help files. The access level for Web Based Management or Secure Web Based Management. Values: Read Write Read OnlyUsers of Web Based Management or Secure Web Based Management have the following limitations: Cannot change the configuration of the device Cannot view the Community Table Cannot view the User Table Have no access to SSH Public Key Table Cannot view SSL keys and certificates Cannot send configuration files to the device Cannot receive configuration files from the device Cannot update device software Cannot reset the device
Default: Read Write Note: If you change the value of this parameter, you must restart the device.
Secure Web
You can define the parameters for obtaining secured HTTP requests.
To configure secure Web parameters 1. Select Services > Management Interfaces > Web Server > Secure Web. The Secure Web Parameters pane is displayed. 2. Configure the parameters; and then, click Set.
Table 43: Secure Web Parameters
Parameter
Secure Web Certificate Entry Name Secured Web Port Secured Web Status
Description
Specifies the Certificate file used by secure Web for encryption. Specifies the port through which HTTPS gets requests. Specifies the status of the secure Web server. Values: enable, disable Default: disable
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 the Web Services interface on APSolute API. APSolute API is an open-standards-based
99
LinkProof User Guide Device Management SOAP (XML) API. Integration with APSolute API allows customers a comprehensive view of the LinkProof devices performance including historical data analysis and trending, performance diagnostics, availability reports, and automation of maintenance operations as well as fine-tuning of LinkProof for optimal application delivery based on parameters external to LinkProof.
To configure the Web Services parameter 1. 2. 3. Select Services > Management Interfaces > Web Server > Web Services. The Web Services pane is displayed. From the Web Services Status drop-down list, select enable, or disable. Click Set.
Configuring an SSH Interface for Management

SSH (Secure Shell) is a protocol for secure remote connections and network services, over an insecure network. Using this feature enables a secure alternative to Telnet connection.
Note: Two incompatible versions of SSH exist: SSH1 and SSH2. LinkProof supports only SSH2.
To configure an SSH interface for management 1. 2. Select Services > Management Interfaces > SSH > Server. The Secure Shell Parameters pane is displayed. Configure the parameters; and then, click Set.
Table 44: Secure Shell Parameters
Parameter
SSH Port SSH Status
Description
The source port for the SSH server connection. Enables or disables the SSH feature. When disabled, an SSH connection is not possible. Values: Enable, Disable Default: Disable
SSH Session Timeout
Timeout, in minutes, required for the device to maintain a connection during periods of inactivity. Values: 1120 Default: 5
SSH Authentication Timeout
Timeout, in seconds, required to complete the authentication process. Values: 1060 Default: 30
100
Configuring an FTP Interface for Management

You can configure the LinkProof device to enable users to connect to the device using FTP and transfer files to/from the device flash memory.
Note: To access the device via an FTP service, the FTP server must be enabled.
To configure an FTP interface for management 1. Select Services > Management Interfaces > FTP Server. The FTP Server Parameters pane is displayed. 2. Configure the parameters; and then, click Set.
Table 45: FTP Server Parameters
Parameter
FTP Server Port FTP Server Status
Description
Specifies the application port to access the FTP server on the device. Default: 21 Specifies the status of the FTP server on the device. Values: enable, disable Default: disable
RADIUS Authentication for Management

Before a management session starts, LinkProof can authenticate the user with a RADIUS server. You can also select whether or not to use the User Table when a RADIUS server is not available. RADIUS Authentication is available for the following interfaces: CLI Telnet Web Based Management SSH
Note: When you enable and configure the RADIUS Authentication feature, the RADIUS server must be available and accessible to the LinkProof device.
101
To configure RADIUS Authentication for device management 1. Do the following: a. b. Select Security > Users. The User Table and Authentication pane is displayed. Set the following parameter:
Parameter
Authentication Method
Description
The method for of authenticating a users access to the device. Values: Local User TableThe device uses the User Table to authenticate access. RADIUS and Local User TableThe device uses the RADIUS servers to authenticate access. If the request to the RADIUS server times out, the device uses the User Table to authenticate access. Default: Local User Table
c. 2. a. b.
Click Set. Select Services > RADIUS. The RADIUS Parameters pane is displayed. Set the following parameters:
Do the following:
Parameter
Main RADIUS IP Address Main RADIUS Port Number Main RADIUS Secret Backup RADIUS IP Address Backup RADIUS Port Number Backup RADIUS Secret RADIUS Retries
Description
IP address of the primary RADIUS server. Access port number of the primary RADIUS server. Values: 1645, 1812 Authentication password for primary RADIUS server. IP address of the backup RADIUS server. Access port number of the backup RADIUS server. Values: 1645, 1812 Authentication password for backup RADIUS server. Defines number of connection retries to the RADIUS server, when the RADIUS server does not respond to the first connection attempt. How many seconds device waits for reply from the RADIUS server before a retry, or, if the RADIUS Retries value is exceeded, before the device acknowledges that the server is off line. Duration, in seconds, for client authentication. After the lifetime expires, the device re-authenticates the user.
RADIUS Timeout
RADIUS Client Lifetime c. Click Set.
102
Logging
This section includes details on viewing and enabling various logs for use with LinkProof, and includes these topics: Event Log, page 103 SMTP Logging, page 103 Power Supply Traps, page 104
Event Log
You can view a log of the events on the device.
To view the event log Select Services > Event Log. The Event Log pane is displayed.
To clear the event log 1. Select Services > Event Log. The Event Log pane is displayed. 2. Under Clear Event Log, click Set.
SMTP Logging
LinkProof can sends SMTP log messages asynchronously to designated locations. You must set a logging output location to view any logs. LinkProof can send SMTP traps in e-mail messages to specified users. Each user receives e-mail messages according to the specified severity level (Info, Warning, Error or Fatal), which is configured in the User Table.
To configure an SMTP client 1. Select Services > SMTP. The SMTP pane is displayed. 2. Configure the parameters; and then, click Set.
Table 46: SMTP Client Parameters
Parameter
SMTP Primary Server Address
Description
Specifies the IP address of the SMTP server.
SMTP Alternate Server Specifies the IP address of an alternative SMTP server. The alternate SMTP Address server is used when an SMTP connection cannot be established successfully with the main SMTP server, or when the main SMTP server closed the connection. The device tries to establish a connection to the main SMTP server, and starts reusing it when it available. Own Email Address Specifies the e-mail address of the device.
103
Table 46: SMTP Client Parameters
Parameter
SMTP Status
Description
Specifies the status of the SMTP client. The value must be enable to support features that are related to sending e-mail messages. Values: enable, disable Default: disable
Send Email on Errors
Specifies whether the device sends e-mail when an error occurs. Values: enable, disable Default: disable
Power Supply Traps

LinkProof can send SNMP log messages when one of the power supplies fails on or is removed from a platform with a dual power supply.
To enable or disable power-supply traps 1. 2. Select Services > Logging > SNMP Traps. The Power Supply Trap Status pane is displayed. Configure the parameter; and then, click Set.
Table 47: Power Supply Trap Status Parameter
Parameter
Power Supply Trap Status
Description
Specifies whether the device sends SNMP log messages when one of the power supplies fails on or is removed from a platform with a dual power supply. Values: enable, disable Default: enable
APSolute API
The APSolute API is a SOAP interface. It provides comprehensive access to Radware devices for third-party applications utilizing common development languages including Java, Visual Basic/C#, and Perl. This interface exposes methods that enable both device configuration as well as monitoring of status and performance statistics. For more information, see the APSolute API guide for LinkProof.
104
Chapter 3 Basic Switching and Routing

This chapter describes switching and routing in the context of LinkProof. This chapter contains the following sections: Port Settings, page 105 Virtual LAN, page 112 IP Addressing and Routing, page 122
Port Settings
This section describes LinkProof features that handle traffic and port management and contains the following topics: Port Mirroring, page 105 Link AggregationPort Trunking, page 106 Port Rules, page 110 Port Load Balancing Status, page 111
Port Mirroring
Only the OnDemand Switch 2 platform supports port mirroring. Port Mirroring enables LinkProof 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 LinkProof 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.
Notes: >> The OnDemand Switch 2 platform supports port mirroring of up to four ports. >> The OnDemand Switch VL platform does not support port mirroring. >> It is possible to copy traffic from one input port to multiple output ports, or from many input ports to one output port. >> The input port, from which traffic is mirrored must be an interface with a configured IP address, or an interface that is part of a VLAN (regular or switched) with a configured IP address. >> The output port, to which the traffic is mirrored, cannot have an IP address, or be part of a VLAN (Regular or Switched) with a configured IP address. >> When mirroring traffic from a port that is a part of a switched VLAN, traffic between hosts on this VLAN is switched by the ASICs of the device. This type of traffic is not mirrored. >> When mirroring traffic is received on a port which is a part of switched VLAN and the mirrored port is configured to mirror received broadcast packets, the packets are mirrored from all ports on the switched VLAN. >> Traffic generated by the device itself, such as connectivity checks or management traffic, is not mirrored. >> Regular VLAN traffic with a destination multicast MAC is not always mirrored.
105
LinkProof User Guide Basic Switching and Routing
To configure port mirroring 1. 2. 3. Select Device > Port Mirroring. The Port Mirroring Table pane is displayed. Click Create. The Port Mirroring Table Create pane is displayed. Configure the parameters; and then, click Set.
Table 48: Port Mirroring Parameters
Parameter
Input Port Output Port Receive/Transmit
Description
The port from which the traffic is mirrored. The port to which traffic is mirrored. Select the direction of traffic to be mirrored. Values: Transmit and Receive Receive Only Transmit Only Default: Transmit and Receive
Promiscuous Mode
Specifies whether the device copies all traffic from the input port to the output port or copies only the traffic that is destined to the input port. Values: EnabledAll traffic is copied to the output port. DisabledOnly traffic destined to the input port is copied. Default: Enabled
Backup Port
The port for output when the output port is down. Default: 0Specifies no backup port
Link AggregationPort Trunking

Link aggregation, also known as port trunking, is a method of increasing bandwidth by combining physical network links into a single logical link. Link aggregation increases the capacity and availability of the communications channel between devices (both switches and end stations) by using Fast Ethernet and Gigabit Ethernet technology. Multiple parallel physical links between two devices can be grouped together to form a single logical link. Link aggregation also provides load balancing where processing and communications activities are distributed across several links in a trunk. This prevents single link overloading. Treating multiple LAN connections as one aggregated link offers the following advantages: Higher link availability. Increased link capacity. Improvements in existing hardware. Upgrading to higher-capacity link technology is not necessary.
LinkProof supports port trunking according to the IEEE 802.3ad standard for link aggregation.
106
LinkProof User Guide Basic Switching and Routing According to the IEEE 802.3ad standard: 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. Aggregation is permitted only among links with same speed and direction. On the LinkProof device, bandwidth increments are provided in units of 100 Mbit/s and 1 Gbit/s respectively. Traffic from the same MAC client may be distributed across multiple links. To guarantee 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. LinkProof can define conversations using Layer 2, 3, or 4 information or a combination of layers (Layer 3 and 4 for example). The failure or replacement of a single link within a Link Aggregation Group will not cause failure from the perspective of the clients MAC address.
The LinkProof Link Aggregation feature allows defining up to seven trunks. Up to eight physical links can be aggregated into one trunk. All trunk configurations are static. To provide optimal distribution for different scenarios the load sharing algorithm allows decisions based on source or destination (or both) L2 address (MAC), L3 address (IP), and L4 address (TCP/ UDP port numbers). These parameters are used as input for a hashing function.
Notes: >> A port belonging to a trunk should not be copied to another port. >> A trunk cannot be mirrored. >> Ports that are part of a trunk cannot be used in port rules. The entire trunk, however, can be used in port rules. >> Radware recommends that you configure Link Aggregation using CLI. >> When choosing the Link Aggregation configuration using Web Based Management, it important for the administrator to choose the valid Link Aggregation configuration from Table 49 - Supported Link-Aggregation Configurations for OnDemand Switch 2, page 107. The following table lists combinations for link aggregation supported on the OnDemand Switch 2 platform.
Table 49: Supported Link-Aggregation Configurations for OnDemand Switch 2
Layer 1
2 3 4
4
Ignore
5
Ignore
6
Ignore
7
Ignore Source IP Source Port
8
Ignore
9
Ignore
Source Destination Both MAC MAC Ignore Ignore Ignore Ignore
Ignore Source Destination Both IP IP Ignore Ignore Ignore Ignore
Destination Both IP Destination Both Port
Note: On OnDemand Switch VL platforms, combinations for link aggregation are not limited. This section contains the following topics: Link AggregationGlobal Configuration, page 108
107
LinkProof User Guide Basic Switching and Routing Link Aggregation Trunk Table, page 108 Link Aggregation Port Table, page 109
Link AggregationGlobal Configuration
To configure link aggregation 1. 2. Select Device > Link Aggregation > Global Configuration. The Global Configuration pane is displayed. Configure the parameters; and then, click Set.
Table 50: Link Aggregation Global Configuration Parameters
Parameter
Layer 2
Description
Specifies how the MAC address is used in the traffic distribution algorithm. Values: IgnoreDo not use MAC address. Source MAC addressUse source MAC address Destination MAC addressUse destination MAC address. Both MAC addressesUse both source and destination MAC addresses. Default: Ignore
Layer 3
Specifies how the IP address is used in the traffic distribution algorithm. Values: IgnoreDo not use IP address. Source IP addressUse source IP address. Destination IP addressUse destination IP address. Both IP addressesUse both source and destination IP addresses. Default: Both IP addresses
Layer 4
Specifies how the application port is used in the traffic distribution algorithm. Values: IgnoreDo not use application port. Source application portUse source application port. Destination application portUse destination application port. Both application portsUse both source and destination application ports. Default: Both application ports
Link Aggregation Trunk Table
To view the Link Aggregation Trunk Table Select Device > Link Aggregation > Trunk Table. The Link Aggregation Trunks Table pane is displayed with the following read-only parameters.
108
Parameter
Trunk Index
Description
The trunk index identifier. Values: T-1 T-2 T-3 T-4 T-5 T-6 T-7 T-MNG
Trunk MAC Address Trunk Status
The MAC address assigned to the trunk. The status of the trunk Values: IndividualNo ports are attached to the trunk. AggregatePorts are attached to the trunk.
Link Aggregation Port Table

Use the Link Aggregation Port Table pane to attach or de-attach ports to a trunk. You can attach only ports that are connected (Link Up) and operating in full duplex mode to a trunk.
To attach or de-attach a port to a trunk 1. Select Device > Link Aggregation > Port Table. The Link Aggregation Ports Table pane is displayed with the following parameters:
Parameter
Port Index Port MAC
Description
The port index identifier. The list of identifiers depends on the platform. The MAC address of the port.
109
Parameter
Trunk Index
Description
The trunk to which the port is attached. Values: Unattached T-1 T-2 T-3 T-4 T-5 T-6 T-7 T-MNG Default: Unattached
Port Status
The status of the port Values: IndividualThe port is not attached to any trunk. AggregateThe port is attached to a trunk.
2. 3. 4.
From the Port Index column, click the relevant port. The Link Aggregation Ports Table Update pane is displayed From the Trunk Index drop-down list, select the trunk to which to attach the port. Click Set.
Port Rules
Port Rules enable LinkProof to ensure that traffic received from a specific physical port on the device exits only through another specific physical port on the same device, and vice versa. This is useful for a simplified configuration process, without flow definitions, for example, when LinkProof needs to load balance both router and firewall servers.
To configure port rules In CLI, use the command lp port-rules set <in port> <out port>.
Note: Due to security considerations, the Port Rules feature is configured only using CLI via the serial port, and not a remote connection.
110
Rules Table
Use the Rules Table pane to view what rules have been configured on the device. You cannot modify values in the table. The Rules Table pane displays a table with the following columns: Port NumberThe LinkProof port number from which the traffic enters. Leaving Port NumberThe number of the LinkProof port through which traffic entering the LinkProof device can exit. Number Of Servers On PortThe number of servers connected to the LinkProof port.
To view the Rules Table Select LinkProof > Global Configuration > Rules Table. The Rules Table pane is displayed.
Port Load Balancing Status

For each physical port on the device, you can specify whether LinkProof load balances the traffic coming in through the port. You can configure the Port Load Balancing Status using Web Based Management or CLI.
To specify the load balancing status of a port using CLI Use the following command: lp global port-lb-status
To specify the load balancing status of a port using Web Based Management 1. Select LinkProof > Global Configuration > Port LB Status. The Port Load Balancing Status pane is displayed. 2. In the Port column, click the link of the relevant port. The Port Load Balancing Status Update pane is displayed. 3. From the Admin Status drop-down list, choose the required option. Values: EnableThe device load balances traffic coming in through the port or routes the traffic according to flow policies and a destination address. DisableTraffic always routes the traffic according to flow policies and a destination address.
Default: Enable 4. Click Set.
111
Virtual LAN
This section describes the virtual LANs (VLANs) and how to configure them in the context of LinkProof and contains the following topics: Virtual LANs, page 112 Supported VLAN Types, page 112 IPv6 Pass-through, page 113 Bridging, page 115 VLAN Example Configuration, page 115 Configuring VLANs, page 116 Redundancy with VLANs, page 118 VLAN Tagging, page 118
Virtual LANs
A Virtual LAN (VLAN) is a group of devices that share the same broadcast domain within a switched network. Broadcast domains describe the extent to which a network propagates a broadcast frame generated by a device. Some switches can be configured to support single or multiple VLANs. When a switch supports multiple VLANs, the broadcast domains are not shared between the VLANs.
Notes: >> 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.
Supported VLAN Types

LinkProof VLAN includes bridging functionality among ports assigned to the same VLAN. LinkProof supports Regular VLAN and Switched VLAN. Only the OnDemand Switch 2 and 3 platforms supports the Switched VLAN option.
Regular VLAN
A Regular type VLAN can be described as an IP bridge (a software bridge) between multiple ports that incorporate all the traffic redirection of the passing traffic at all layers (Layer 2Layer 7). Two protocols can be used when configuring Regular VLANs: IP Protocol (ifIndex 100001)Must be assigned an IP address. IP VLANs are automatically assigned a MAC address. All of the traffic between the ports is intercepted transparently by LinkProof. Packets that need intelligent intervention are checked and modified by LinkProof and then forwarded to the relevant port. Other packets are simply switched by LinkProof as if they were on the same wire. Other Protocol (ifIndex 100000)Includes all protocols for which VLANs have not been defined, but it does not include an IP. A VLAN with the protocol Other cannot be assigned an IP address. This type of VLAN is used to bridge the non-IP traffic through LinkProof. You can define this option also with the Switched type VLAN (Switched VLAN protocol) for wire-speed performance.
112
Caution: For a Regular VLAN to fully support Layer-2 bridging, after creating the regular VLAN interface, you must assign an IP address to the VLAN interface.
Switched VLAN
Switched VLAN provides wire-speed VLAN capabilities implemented through the hardware switch fabric of the LinkProof device. Only the OnDemand Switch 2 and 3 platforms supports the Switched VLAN option. Depending on the protocol specified for the Switched VLAN, frames are treated as follows: Switched VLAN ProtocolFrames arriving at a VLAN port are switched according to Layer 2 data. LinkProof does not intercept any traffic. IP ProtocolFrames arriving at a VLAN port are switched according to Layer 2 data, except for frames with a Layer 2 address the same as the LinkProof port Layer 2 address. Frames with the LinkProof Layer 2 destination are processed by LinkProof and then forwarded accordingly.
IPv6 Pass-through
IPv6 will eventually replace IPv4. IPv4 is the current industry standard in TCP/IP networks today and is the de facto Internet routing protocol. IPv6 increases the IP address size from 32 bits to 128 bits, to support more levels of addressing hierarchy. The IPv6 packet header, like the IPv4 packet header, contains a Version part (bits 04). The packet header tells the network device that the packet is either IPv6 or IPv4. For devices that are not IPv6-compatible (the TCP/IP stack is IPv4), the Version part is the only part that is read by the IPv4 device. IPv6 packets can pass through the LinkProof device using a VLAN-type IP.
Note: In LinkProof versions prior to LinkProof 3.0, scenarios that involved passing IPv6 packets through the device were configured using Bridge mode with VLAN type OTHER.
113
LinkProof User Guide Basic Switching and Routing The scenario in the following figure shows the following configuration: Router 2For IPv4 deviceattached to port G-1 on the LinkProof device. Router 1For IPv6 and IPv4 Trafficattached to port G-3 on the LinkProof device. LAN connectionAttached to port G-4 on the LinkProof device.
IPv6 traffic passing inbound or outbound through Router 1 will be bridges across ports G-3 and G-4. This enables traffic to flow from the IPv6 connectivity WAN to the IPv6 server and vice versa, through the LinkProof device.
Figure 3: LinkProof Device with IPv6 Pass-Through

IPv6 Connectivity WAN
ISP 1
ISP 1
Router 2
Router 1 IPv6 capable Bi-directional IPv6 traffic G-1

Link Proof
1000 10/100
G-3
G1 G3 G5 G7 G9 G11
1000 10/100 PWR
LinkProof device
MNG 1 PWR FAN SYS OK
APSolute Application Delivery
G13
G14
G15
G16
G2
G4
G6
G8
G10
G12
RST
USB
MNG 2
CONSOLE
G-4
LAN
Server supports dual stack (IPv4 and IPv6)
114
To allow IPv6 traffic to pass through the example LinkProof device 1. Select Device > VLAN Table. The Virtual Lan Table page is displayed. 2. Do the following to create a Regular VLAN (bridge) between port G-3 and port G-4. Create a VLAN Port Table that includes VLAN Port Index G-3 and VLAN Interface Index 100001 (type IP). Create a VLAN Port Table that includes VLAN Port Index G-4 and VLAN Interface Index 100001 (type IP).
Notes: >> If the Regular VLAN is not configured, the IPv6 traffic is discarded. >> IPv6 traffic passes through the LinkProof device in Bridge mode (Regular VLAN) only; and the traffic does not participate in routing and/or load-balancing decisions.
Bridging
Once a VLAN is defined, LinkProof performs bridging among interfaces assigned to the same VLAN. Bridging within a VLAN means that LinkProof learns the MAC addresses of Ethernet frames arriving from each physical interface, and maintains a list of MAC addresses per interface. When a frame arrives from one interface, LinkProof 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 of the source address, LinkProof discards the frame. If the destination address is listed in another interface, LinkProof forwards the frame to the relevant interface. If the address is not listed in any interface, LinkProof broadcast the frame to all interfaces participating the VLAN.
LinkProof enables you to modify the address lists by registering additional MAC addresses per interface.
To add a MAC address to a port 1. Select Router > ARP Table. The ARP Table pane is displayed. 2. Select the relevant Interface Index. The Global ARP Table Update pane is displayed. 3. In the MAC Address text box, type the MAC address. 4. Click Set.
VLAN Example Configuration

In the following figure, LinkProof is configured with two VLANs: Network Side VLAN (with address 100003) and user-side VLAN (address 100005). Both VLANs are defined as a Switched type, to gain wire-speed throughput. To enable LinkProof to perform load-balancing policies on traffic destined to the Internet, the VLAN protocol is set to IP. This requires clients to configure the LinkProof device as their default router.
115
Figure 4: Example VLAN Configuration

Internet Network-side VLAN 100003
Router 192.1.1.100
Server 192.1.1.11
P1 LinkProof P3
P2
P4
User-side VLAN 100005
Client 193.1.1.1
Client 193.1.1.2
Configuring VLANs
This section describes how to configure VLANs and contains the following topics: Configuring the Ethernet Type for User-defined VLANs, page 116 Configuring the Virtual LAN Table and VLAN Port Table, page 117
Configuring the Ethernet Type for User-defined VLANs
To configure the Ethernet type for user-defined VLANs 1. 2. Select Device > VLAN Parameters. The VLan Parameters pane is displayed. Configure the parameters; and then, click Set.
Table 51: VLAN Ethernet Parameters
Parameter
VLAN Ethernet Type
Description
The Ethernet type for user-defined VLANs.
VLAN Ethernet Type Mask The mask on Ethernet type for user-defined VLANs.
116
Configuring the Virtual LAN Table and VLAN Port Table
To access the Virtual LAN table Select Device > VLAN Table. The Virtual LAN Table pane is displayed, which includes the Virtual LAN Table and the VLAN Port Table.
To add an interface to the Virtual LAN table 1. Select Device > VLAN Table. The Virtual LAN Table pane is displayed. 2. Under Virtual LAN Table, click Create. The Virtual LAN Table Create pane is displayed. 3. Configure the parameters; and then, click Set.
Table 52: VLAN Interface Parameters
Parameter
Interface Number Protocol
Description
Specifies the interface number of the VLAN to be assigned. Default: 0Specifies no VLAN. Specifies the VLAN protocol. Values: Other, IP, Switch Note: When the value in Type drop-down list is Switch, the Other option is not supported. When the value in Type drop-down list is Regular, the Switch option is not supported.
Type
Specifies the VLAN type. Values: RegularThe device acts as a bridge. SwitchThe device acts as a switch. The OnDemand Switch VL platform does not support this option.
To add a physical port to the VLAN 1. Select Device > VLAN Table. The Virtual LAN Table pane is displayed. 2. Under VLAN Port Table, click Create. The VLAN Port Table Create pane is displayed. 3. Configure the parameters; and then, click Set.
Table 53: Physical VLAN Port Parameters
Parameter
VLAN Interface Index VLAN Port Index
Description
Specifies the index number of the interface from the VLAN Table to which you need to add a port. Specifies the index number of the relevant port.
117
To change the protocol or type of an existing user-defined VLAN 1. 2. 3. Select Device > VLAN Table. The Virtual LAN Table pane is displayed. Click on the relevant interface. The Virtual LAN Table pane is displayed. Configure the parameters; and then, click Set.
Table 54: VLAN Parameters
Parameter
Interface Number Type
Description
The interface number of the VLAN to be automatically assigned. The required VLAN type. Values: RegularThe device acts as a bridge. BroadcastThe device broadcasts the VLAN table to all the ports. Switched VLANThe Switched type is a Layer 2 VLAN. Switched VLAN can be stand-alone or part of a Regular VLAN. The OnDemand Switch VL platform does not support this option.
Protocol
The required VLAN protocol. Values: IP, Other
Redundancy with VLANs

When working with VLANs, you can configure two LinkProof devices in an Active/Backup redundancy setup. For more information on LinkProof Redundancy configuration, see Redundancy, page 273.
VLAN Tagging
This section describes VLAN tagging and contains the following topics: VLAN Tagging Support, page 118 Using VLAN Tagging, page 119 Setting a VLAN Tag for an IP Interface, page 120 Configuring VLAN Tagging, page 121
VLAN Tagging Support

VLAN Tagging is 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. VLAN Tagging provides an indication in the Layer 2 header by which a switch decides through which port to connect to the VLAN on another switch. When two VLANs are configured across two different switches, usually there is a connection between each of the VLANs on one switch to the corresponding VLAN on a second switch. This is done by a single cable connecting the two switches. The ports that interconnect the switches, for example port 10 on each switch, belong to all of the VLANs on that switch. In this case, the switch needs to know to which VLAN to send traffic coming from port 10, as this port belongs to all the VLANs.
118
Using VLAN Tagging

VLAN Tagging support can be used with LinkProof where a device is connected to multiple VLANs on the same switch, and different servers are assigned to different VLANs. Because VLAN tagging support is based on the local subnet to which the traffic is sent or on the destination MAC of the packet, LinkProof cannot tag packets by the destination subnet if it is not local to the LinkProof device. The switch connected to the LinkProof device must be configured consistently with the LinkProof tagging configuration. Each IP interface can have a VLAN tag associated with it. LinkProof recognizes an IP interface as a physical port/IP address combination.
Note: LinkProof determines the tag that is used according to the destination IP address of the packet after LinkProof has made all the required modifications to the packet. For example, when using Local Triangulation, LinkProof forwards packets to servers with the destination IP address of the farm. These packets are tagged according to the tag in the configuration of the IP interface associated with the farm IP. Using LinkProof with VLAN tagging, all packets that are sent to a destination MAC address of the next-hop router (whose IP address is 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, including: All health-check packets from the LinkProof device to the next-hop routers, including Full Path Health Monitoring Status of routers ARP requests and responses from the LinkProof device to the next-hop routers Unicast ARPs between redundant LinkProof devices Gratuitous ARPs, as part of the redundancy mechanism
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 1 to 4063. LinkProof automatically sets the 802.1p portion of the tag (the first three bits) to 000.
119
LinkProof User Guide Basic Switching and Routing In the following figure, tag 101 is associated to IP interface 10.1.1.10 and tag 102 is associated to IP Interface 20.1.1.10. All traffic to 10.1.1.x servers is tagged with the VLAN tag 101, while all traffic to 20.1.1x servers is tagged with the VLAN tag 102.
Figure 5: Example VLAN Tagging Configuration
LinkProof
10.1.1.10 Tag 101
20.1.1.10 Tag 102
Servers
Servers
10.1.1.x
20.1.1.x
Setting a VLAN Tag for an IP Interface
To set a VLAN tag for an IP interface 1. 2. Select Router > IP Router > Interface Parameters. The IP Router Interface Parameters pane is displayed. Do one of the following: 3. 4. If you are specifying the VLAN tag for an existing interface, select the interface link. The Interface Parameters Update pane is displayed. If you are configuring a new interface, under the Interface Parameters table, click Create. The Interface Parameters Create pane is displayed.
In the VLAN Tag text box, type the required value for the VLAN tag. The value 0 indicates that no VLAN tag is used. Click Set.
120
Configuring VLAN Tagging

In addition to configuring which VLAN tags should be set according to destination local subnet or according to the next-hop router (NHR), you can also retain the existing VLAN tags on the incoming traffic that passes through the device. In addition, you can configure the same VLAN tag on multiple interfaces. You can also configure a VLAN tag on a VLAN interface.
Note: If a packet arrives without a VLAN tag, LinkProof sets a tag according to the destination local subnet.
To configure VLAN tagging and the VLAN Tagging handling method using CLI Enter the following command: net vlan-tag-handling set [enable|disable] Default: disable Enter the following command: vlan-tag-handling set [retain|overwrite] Default: overwrite
To configure VLAN tagging and the VLAN Tagging handling method using Web Based Management 1. Select Device > VLAN Tagging. The Virtual LAN Tagging pane is displayed. 2. Configure the parameters; and then, click Set.
Table 55: VLAN Tagging Parameters
Parameter
802.1q environment
Description
Specifies whether the device handles VLAN tags traffic according to IEEE 802.1Q. Values: EnabledThe device handles VLAN-tagged traffic according to IEEE 802.1Q. DisabledThe device drops all VLAN-tagged traffic. Default: Disabled
VLAN Tag Handling
Specifies how the device handles VLAN tags. Values: RetainThe device preserves existing VLAN tags on the ingress traffic that passes through the device. Traffic generated by the device is tagged according to the IP interface configuration. If an ingress packet has no VLAN tag, the device performs VLAN tagging on the egress packet according to the IP interface configuration. OverwriteThe device performs VLAN tagging of outgoing traffic according to the IP interface configuration. Default: Overwrite
121
IP Addressing and Routing

This section describes the configuration of VLAN IP addressing and routing and contains the following topics: IP Addressing, page 122 Routing, page 122 Routing Information Protocol, page 124 Configuring ARP Parameters, page 126 IP Router Operating Parameters, page 127 Open Shortest Path First (OSPF), page 130
IP Addressing
IP addresses are 32-bit binary numbers. Each 32-bit IP address consists of two sub-addresses, one identifying the network and the other identifying the host to the network, with an imaginary boundary separating the two. The location of the boundary between the network and host portions of an IP address is determined through the use of a subnet mask. A subnet mask is another 32-bit binary number that acts like a filter when it is applied to the 32-bit IP address. By comparing a subnet mask with an IP address, systems determine which portion of the IP address relates to the network, and which portion relates to the host. Anywhere the subnet mask has a bit set to 1, the underlying bit in the IP address is part of the network address. Anywhere the subnet mask is set to 0, the related bit in the IP address is part of the host address.
Routing
Routing is the ability of LinkProof to forward IP packets to their destination using an IP routing table. The IP table stores information about the destinations and how they can be reached. By default, all networks directly attached to a LinkProof device are registered in the IP Routing Table. Other entries to the table can either be statically configured or dynamically created through the routing protocol. When LinkProof 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 an indirect delivery (the destination is not a neighboring node), the next-hop MAC address is the address of an IP router according to the IP Routing Table. The destination IP address does not change on the path 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. LinkProof supports IP routing compliant with RFC1812 router requirements. Dynamic addition and deletion of IP interfaces is supported. This ensures that extremely low latency is maintained. The IP router supports RIP 1, RIP 2 and OSPF routing protocols. OSPF is an intra-domain IP routing protocol, intended to replace RIP in bigger or more complex networks. OSPF and its MIB are supported as specified in RFC 1583 and RFC 1850, with some limitations.
Configuring Routing
LinkProof enables the configuration of multiple default and network routes (to the same destination) through different next hop IP addresses. However, the secondary routes are not visible in the route table and they do not appear in the configuration.
122
LinkProof User Guide Basic Switching and Routing When an interface of the device is down, all related routes in the routing table become inactive (out of use). However, in scenarios where, even after an interface failure, a path to a destination network still exists, multiple entries (to that destination) in the routing table should be configured in order to ensure that the LinkProof device uses that route. Radware recommends that you use multiple default routes when next hop routers or gateways are connected to LinkProof via different physical ports.
To create a new Routing Table entry 1. Select Router > Routing Table. The Routing Table pane is displayed. 2. Click Create. The Routing Table Create pane is displayed. 3. Configure the parameters; and then, click Set.
Table 56: Routing Table Entry Parameters
Parameter
Destination Address Network Mask Next Hop Interface Index Type
Description
Specifies the destination IP address of this router. Specifies the destination network mask of this route. Specifies the address of the next system of this route, local to the interface. Specifies the interface index of the local interface through which the next hop of this route is reached. Specifies how remote routing is handled. Values: otherNot used rejectDiscards packets localAny routing that is associated with local IP interfaces remoteForwards packets
Metric
Specifies the number of hops to the destination network.
To update a Routing Table entry 1. Select Router > Routing Table. The Routing Table pane is displayed. 2. Select a Destination Address. The Routing Table Update pane is displayed. 3. Configure the parameters; and then, click Set.
Table 57: Routing Table Update Parameters
Parameter
Destination Address Network Mask Next Hop Interface Index
Description
Displays (read-only) the destination IP address of this router. Displays (read-only) the destination network mask of this route. Displays (read-only) the address of the next system of this route, local to the interface. Specifies the interface index of the local interface through which the next hop of this route is reached.
123
Table 57: Routing Table Update Parameters
Parameter
Type
Description
Specifies how remote routing is handled. Values: otherNot used rejectDiscards packets localAny routing that is associated with local IP interfaces remoteForwards packets
Protocol Metric
Displays (read-only) the specified Type read-only. Specifies the number of hops to the destination network.
Configuring a Default Gateway
Note: You can set up a backup default gateway for LinkProof.
To configure a default gateway 1. 2. 3. Select Router > Routing Table. The Routing Table pane is displayed. Click Create. The Routing Table Create pane is displayed. Configure the parameters; and then, click Set.
Table 58: Default Gateway Parameters
Parameter
Destination Address Network Mask Next Hop Interface Index Type
Value/Description
Use 0.0.0.0 for the destination IP address of the default gateway. Use 0.0.0.0 for the destination network mask of the default gateway. Address of the next system of this route, local to the interface. The IF Index of the local interface through which the next hop of this route is reached. Specifies how remote routing is handled. Values: otherNot used rejectDiscards packets localAny routing that is associated with local IP interfaces remoteForwards packets
Metric
Number of hops to the destination network.
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 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.
124
LinkProof User Guide Basic Switching and Routing Using RIP, a gateway host (with a router) sends its entire routing table, which lists all the other hosts that it recognizes, to its closest neighbor host every 30 seconds. The neighbor host then passes the information on to its next available neighbor and so on until all hosts within the network have the same knowledge of routing paths. This is known as network convergence. RIP uses a hop count as a means to determine network distance. Other protocols use more sophisticated algorithms, including timing. 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. LinkProof supports RIP versions 1 and 2.
Configuring the RIP Parameters
To configure the RIP parameters 1. Select Router > RIP > Parameters. The RIP Parameters pane is displayed. 2. Configure the parameters; and then, click Set.
Table 59: RIP Parameters
Parameter
Administrative Status Leak Static Routes
Description
The administrative status of the RIP in the router. Disabled means the process is not active on any interfaces Controls redistribution of routes from static routes to RIP. When this parameter is enabled, all static routes learned via static are advertised into RIP. Controls redistribution of routes from OSPF to RIP. When this parameter is enabled, all routes learned via OSPF are advertised into RIP. Specifies whether the device sends advertisements through the corresponding port in the Port Rules Table or to all ports. Values: EnableThe device sends advertisements through the corresponding port in the Port Rules Table. That is, the device applies port rules also to RIP advertisements. DisableThe device sends advertisements to all ports. That is, the device overrides port rules for RIP advertisement messages meaning RIP message will go through a port even if the port rule should discard the message.
Leak OSPF Routes
Use Port Rules in Advertisement
Conditional RIP Leak on NHR health
Controls whether the device will continue to leak RIP routes when all firewalls have failed (Enable) or not (Disable).
Configuring the RIP Parameters of a Specific Interface
To configure the RIP parameters of a specific interface 1. Select Router > RIP > Interface Parameters. The RIP Interface Table pane is displayed. 2. Select the interface to edit. The RIP Interface Table Update pane is displayed. 3. Configure the parameters; and then, click Set.
125
Table 60: RIP Interface Parameters
Parameter
IP Address Outgoing RIP
Description
The IP address of the current interface (read-only). The type of RIP to be sent. Values: rip1Send RIP updates compliant with RFC 1058. ripCSend RIP C updates. rip2Send multicast RIP-2 updates. ripV1Send RIP updates compliant with RFC 1058. ripV2Send multicast RIP-2 updates. doNotSendSend no RIP updates. Default: rip1
Incoming RIP
The type of RIP to be received. Values: rip1Accept RIP 1 rip2Accept RIP 2 rip1OrRip2Accept RIP 1 or RIP 2 doNotReceiveAccept no RIP updates
Default Metric
Metric for the default route entry in RIP updates originated on this interface. Values: 0Specifies that no default route is originated, and a default route via another router may be propagated. 115 Default: 0
Status
The status of the RIP in the router. Values: on, off Default: on
Virtual Distance
Virtual number of hops assigned to the interface. This enables fine-tuning of the RIP routing algorithm. Default: 1 When this parameter is enabled, the device advertises RIP messages with the default metric only. This allows some stations to learn the default router address. If the device detects another RIP message, Auto Send is disabled. Radware recommends that you enable this option to minimize network traffic when LinkProof is the only router on the network. Values: enable, disable
Auto Send
Configuring ARP Parameters
To configure ARP parameters 1. 2. Select Router > IP Router > ARP Table. The ARP Table pane is displayed. Click Create. The ARP Table Create pane is displayed.
126
LinkProof User Guide Basic Switching and Routing 3. Configure the parameters; and then, click Set.
Table 61: ARP Parameters
Parameter
Interface Index MAC Address IP Address Type
Description
The interface number on which the station resides. The MAC address of the station. The IP address of the station. The entry type. Values: otherNot used. invalidDeletes an existing ARP entry from the table. dynamicThe entry is learned from the ARP. If the entry is not active for a predetermined time (Inactive ARP Timeout parameter), the node is deleted from the table. staticThe entry has been configured by the network management station and is permanent.
Configuring the ARP Timeout
To configure the ARP timeout 1. Select Router > IP Router > Operating Parameters. The IP Router Parameters pane is displayed. 2. Specify the value for the Inactive ARP Timeout parameter. This is the maximum number of seconds that can pass between ARP requests for an entry in the ARP table. After this period, the entry is deleted from the table. 3. Click Set.
IP Router Operating Parameters
To configure IP router parameters 1. Select Router > IP Router > Operating Parameters. The IP Router Parameters pane is displayed. 2. Configure the parameters; and then, click Set.
127
Table 62: IP Router Parameters
Parameter
Inactive ARP Timeout
Description
The maximum time, in seconds, that can pass between ARP requests for an entry in the ARP table. After this period, the entry is deleted from the table. Specifies whether the device responds to ARP requests for nodes located on a different direct sub-net. The device responds with its own MAC address. Values: enableThe device responds to all ARP requests. disableThe device responds only to ARP requests for its own IP addresses. Default: disable
ARP Proxy
ICMP Error Messages
Specifies whether ICMP error messages are generated. Values: enable, disable Default: enable
Advanced Fast Forwarding Status
Specifies whether the IP Fast Forward Table is used (enabled). When enabled, the table holds MAC-address information of servers only (predefined in the LinkProof farms) and not clients. Values: Enable, Disable Default: Disable
IP Router Interface Parameters

Use the IP Router Interface Parameters pane to configure IP router interfaces and edit Internet Control Message Protocol (ICMP) parameters of an existing interface.
To configure an IP router interface 1. 2. Select Router > IP Router > Interface Parameters. The IP Router Interface Parameters pane is displayed, which list current IP interfaces. Do one of the following: 3. To create a new IP router interface, click Create. To modify the parameters of an existing IP router interface, click the link of the required interface.
Configure the parameters; and then, click Set.
Table 63: IP Router Interface Parameters
Parameter
IP Address If Number Network Mask
Description
The IP address of the interface. Default: 0.0.0.0 The interface identifier. The associated subnet mask. Default: 0.0.0.0
128
Parameter
Fwd Broadcast
Description
Specifies whether the device forwards incoming broadcasts to the interface. Values: Enable, Disable Default: Disable How the device fills the host ID in the broadcast address. ONE FILLFill with ones ZERO FILLFill with zeros Default: ONE FILL
Broadcast Addr
VLAN Tag
The VLAN tag associated with the interface. 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. Default: 0 Specifies whether the device uses the One-IP-for-NAT feature. For more information, see One-IP-for-NAT Support, page 171. Values: Enable, Disable Default: Disable
One Ip (Router Interface Only)
Peer Address
Specifies the IP address of the interface on the peer device, which is required in a redundant configuration. For more information, see Copying a Device Configuration for a Redundant Environment, page 269. Default: 0.0.0.0
To edit the ICMP parameters of an interface 1. Select Router > IP Router > Interface Parameters. The IP Router Interface Parameters pane is displayed. 2. From the ICMP Interface Parameters table, click the IP address of the relevant interface. The ICMP Interface Parameters Update pane is displayed. 3. Configure the parameters; and then, click Set.
Parameter
Advert. Address
Description
The IP destination address for multicast Router Advertisements sent from the interface. Values: 224.0.0.1That is, the all-systems multicast address 255.255.255.255That is, the limited-broadcast address Default: 224.0.0.1
Max Advert. Interval
The maximum time, in seconds, between multicast Router Advertisements from the interface. Values: any value between the Minimum Advert Interval and 1800 Default: 600
129
Parameter
Min Advert. Interval
Description
The minimum time, in seconds, between sending unsolicited multicast Router Advertisements from the interface. Values: any value between 3 and the Max Advert. Interval Default: 450This value is 75% of the default Max Advert. Interval. The maximum time, in seconds, that the advertised addresses are considered valid. Values: any value between the Max Advert. Interval up to 9000 Default: 1800This value is three times the default Max Advert. Interval
Advert. Lifetime
Advertise Preference Level Reset to Defaults
Specifies whether the device advertises the device IP address using ICMP Router Advertise. The preference level of the address as a default router address, relative to other router addresses on the same subnet. Resets the ICMP interface parameters to the default values. Values: TRUE, FALSE Default: FALSE
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 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 (keeping track of routers to particular network destinations) that describes the state of its own links, as well as 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, since fast convergence prevents such problems as routing loops and Count-to-Infinity (when routers continuously increment the hop count to a particular network).
Caution: Shortest-path-first algorithms require a large amount of CPU power and memory.
OSPF Operating Parameters
To set the OSPF Operating Parameters 1. 2. Select Router > OSPF > Operating Parameters. The OSPF Operating Parameters pane is displayed. Configure the parameters; and then, click Set.
130
Table 65: OSPF Operating Parameters
Parameter
Administrative Status
Description
Specifies the OSPF status on the device. Values: enabledThe OSPF process is active on at least one interface. disabledThe process is not active on any interfaces. Default: disabled
Router ID Leak RIP Routes
The ID number of device. To ensure uniqueness, the value should equal one of the router IP addresses. Specifies whether the LinkProof device advertises as external routes all routes inserted into the IP routing table via SNMP into OSPF. Values: enableall Routes inserted into the IP routing table via SNMP are advertised into OSPF as external routes. disableThe process is not active on any interfaces. Default: disable
Leak Static Routes
Controls redistribution of routes from static routes to RIP. Values: enableAll static routes learned via static are advertised into RIP. disable Default: enable
Leak External Direct Routes
Controls redistribution of direct routes which are external to OSPF into OSPF. Values: enableAll external routes are advertised into OSPF as external routes. disable Default: enable
Use Port Rules in Advertisement
Specifies whether the LinkProof device considers port-rule logic in the Link-state advertisements (LSAs). Values: enable, disable Default: disable
Conditional OSPF leak on NHR health
Specifies whether or not LinkProof allows NHR health information to leak via OSPF routing updates. Values: enable, disable Default: disable
OSPF Interface Parameters
To update the OSPF interface parameters 1. Select Router > OSPF > Interface Parameters. The OSPF Interface Parameters pane is displayed. 2. Select the IP Interface. The OSPF Interface Table Update pane is displayed.
131
LinkProof User Guide Basic Switching and Routing 3. Configure the parameters; and then, click Set.
Table 66: OSPF Interface Parameters
Parameter
IP Address Interface Type
Description
IP address of this OSPF interface. OSPF interface type. Values: broadcastFor broadcast LANs nbmaFor x.25 and Frame Relay pointToPointFor point-to-point LANs pointToMultipoint
Administrative Status
Administrative status of the OSPF in the router. Values: enabledThe OSPF process is active on at least one interface. disabledThe means the process is not active on any interface.
IfRtrPriority
Priority of this interface. The value 0 (zero) specifies that this router is not eligible to become the designated router on the current network. If more than one router has the same priority, the router ID is used. The time, in seconds, between Hello packets. All routers attached to a common network must have the same Hello Interval. Number of seconds that the routers Hello packets have not been seen before the routers neighbors declare that the router is 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. The interface state of the OSPF interface. Values: DownOSPF interface is down. WaitingOSPF interface is currently waiting. Point to PointOSPF interface is in point to point state. Designated RouterOSPF interface is the designated router. Backup Designated RouterOSPF interface is the backup designated router.
Hello Interval RtrDeadInterval
Interface State
Designated Router Backup Designated Router IfAuthKey AuthType
Address of designated router, if Interface state is Designated Router. Address of the backup designated router, if the Interface state is Backup Designated Router. Authentication key for the interface. Type of authentication key for the interface.
OSPF Area Parameters

An OSPF network is divided into areas that 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.
132
To configure OSPF area parameters 1. Select Router > OSPF > Area Parameters. The OSPF Area Parameters Table pane is displayed. 2. Configure the parameters; and then, click Set. When updating area parameters, in the OSPF Area Parameters Table pane, select the Area ID. When creating area parameters, in the OSPF Area Parameters Table pane, select Create.
Table 67: OSPF Area Parameters
Parameter
Area ID Import AS Extern Number of AS Border Routers Area LSA Count Area LSA Checksum Sum
Description
IP address of the area. Ability to import autonomous system external link advertisements. Total number of Autonomous System border routers reachable within this area. This is initially 0 and calculated in each SPF pass. Number of internal link-state advertisements in the link-state database. 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.
OSPF Link State Database

OSPF uses both unicast and multicast to send Hello packets and link state updates. OSPF very quickly detects changes in the topology, such as link failures, and converges on a new loop-free routing structure within seconds. For this, each OSPF router collects link-state information to construct the entire network topology of so-called areas from which it computes the shortest path tree for each route. The link-state information is maintained on each router as a link-state database (LSDB) which is a tree image of the network topology. Identical copies of the LSDB are periodically updated through flooding on all routers in each OSPF-aware area.
To manage the OSPF link-state database 1. Select Router > OSPF > Link State Data Base. The OSPF Link State Database pane is displayed. 2. Set the following parameters:
Parameter
Area ID Type Link State ID
Description
IP address of the area. Each link state advertisement has a specific format. The link can be a Router Link, Network Link, External Link, Summary Link or Stub Link. Identifies a piece of routing domain described by the advertisement. It can be a router ID or an IP address.
133
Parameter
Router ID Sequence
Description
Identifies the originating router in autonomous system. Number for link. Use this to detect old and duplicate link state advertisements. The larger the sequence number the more recent the advertisement.
3. 4.
When updating Link State Database, in the OSPF Link State Database pane, select the Area ID. Click 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. Use the OSPF Neighbor Table to access, create, and update OSPF Neighbor parameters.
To access OSPF neighbor table 1. 2. Select Router > OSPF > Neighbor Table. The OSPF Neighbor Table pane is displayed. You can view the following parameters:
Parameter
Neighbor's Address Address Less Index Router ID Options Priority 3.
Description
IP address of this neighbor. If the interface is without an IP address, index appears in this field. If there is an IP address, 0 appears. Unique identifier for the neighboring router in the autonomous system. A bit mask corresponding to the neighbor's options. Priority of this neighbor. Priority of 0 means neighbor cannot become the designated router on the network.
When updating the OSPF Neighbor Table, in the OSPF Neighbor Table pane, select the Neighbors Address.
Note: This parameter is displayed only if there is an OSPF working between network devices supporting OSPF. 4. When creating the OSPF Neighbor Table, in the OSPF Neighbor Table pane, select Create.
Note: This parameter is displayed only if there is an OSPF working between network devices supporting OSPF. 5. Click Set.
134
Chapter 4 Basic Application Switching

This chapter describes farm management farm-related features. It also provides you with examples of common configurations of application-switching and load-balancing schemes. This chapter contains the following sections: LinkProof Multihoming Overview, page 135 Farm Management, page 138 Server Management, page 155 Network Address Translation, page 167 Proximity, page 176 DNS, page 182 Basic Load Balancing, page 188 Load Balancing Weights, page 194 Flow Management, page 194 Client Table, page 200 VPN Load Balancing, page 218
LinkProof Multihoming Overview

This section describes how LinkProof manages all links across multihomed networks. LinkProof is an intelligent application switch that manages all links across multihomed networks, enabling full link availability, highest link performance and complete link security for uninterrupted user access to web-enabled applications, which provides cost effective connectivity at main offices and data centers. Load balancing of outbound and inbound traffic needs to be addressed individually as each type poses a different set of difficulties, therefore LinkProof customizes its implantation for each type of traffic as a solution to this issue.
Outbound Traffic
Outbound traffic is traffic initiated from the local network to a remote destination over the WAN. LinkProof load balances outbound traffic based on availability and performance of the available links while managing the IP address ranges assigned to the network from various ISPs.
135
LinkProof User Guide Basic Application Switching
Figure 6: Example Multihoming Outbound Traffic

NHR 1 100.1.1.20 NAT:100.1.1.21 LinkProof Via NHR1 100.1.1.10 200.1.1.10 Local 10.1.1.x NAT: 200.1.1.21 Via NHR2 NHR 2 200.1.1.20
Figure 6 - Example Multihoming Outbound Traffic, page 136 shows a scenario where a user on the local network (for example, IP 1.1.1.80) sends an outbound HTTP request to the Internet. The traffic is processed as follows: 1. 2. 3. The new user session reaches LinkProof and activates load balancing mechanism. LinkProof classifies traffic according to configured routing policies (flow policies) to select the group of WAN links (router farm) that will be used for this traffic. LinkProof selects an outbound link for this traffic from the router farm chosen in previous step. The choice is based on the following: 4. 5. Link availability measured according to user-defined criteria (health checks) Link metrics measured according to user-defined criteria (traffic amount, proximity, cost)
Once the load balancing decision is reached, it is recorded in LinkProof tables (see Client Table, page 200) for use on the rest of the session traffic. Before forwarding the traffic to the selected link, the source IP address and TCP/UDP port are replaced by NAT address allocated by the selected ISP and a new TCP/UDP port (for example src=10.1.180 is replaced by src=200.1.1.21) The reply from the Internet Web server will arrive via the same link because it is answering to the NAT IP (dst=200.1.1.21). LinkProof translates the destination IP from the NAT IP (200.1.1.21) to the user IP (10.1.1.80) and forwards the reply to the user. LinkProof ensures that subsequent packets from the user belonging to the same session will use the same WAN link to ensure persistency (as recorded in the Client Table, page 200).
6. 7. 8.
136
Inbound Traffic
Inbound traffic is traffic initiated from an external user to a service provided by the local network, such as a Web server. LinkProof load balances inbound traffic based on availability and performance of the available links and provides the external user access via the best performing link. This is implemented by configuring the LinkProof as an authoritative name server. When the external client makes a DNS request, the LinkProof responds with the IP address allocated to the internal service by the best available WAN link (ISP).
Figure 7: Example Multihoming Inbound Traffic

NHR 1 NAT:100.1.1.21 For 10.1.1.50 Via NHR1 100.1.1.20
100.1.1.10 200.1.1.10 www.radware.com 10.1.1.50 NAT: 200.1.1.21 For 10.1.1.50 Via NHR2 NHR 2 200.1.1.20
Figure 7 - Example Multihoming Inbound Traffic, page 137 shows a scenario where an external user sends a request to www.radware.com that is hosted by internal server 10.1.1.50 represented externally by 100.1.1.21 via ISP1 and 200.1.1.21 via ISP2. The traffic is processed as follows: 1. The external user sends DNS query that is forwarded by DNS servers to LinkProof. 2. If this is a domain name for which LinkProof is authoritative server, LinkProof classifies traffic according to configured routing policies (flow policies) to select the group of WAN links (router farm) that will be used for this traffic. 3. LinkProof selects an inbound link for this traffic from the router farm chosen in the previous step, based on: Link availability measured according to user-defined criteria (health checks) Link metrics measured according to user-defined criteria (traffic amount, proximity, cost)
4. Once load balancing decision is reached, it is recorded in LinkProof tables for use on the rest of the session traffic. 5. A DNS response is sent back to the external user with the IP that represents the internal server via the selected link (ISP)for example, 100.1.1.21. 6. The external user sends HTTP request to 100.1.1.21. LinkProof replaces the destination IP address with the internal server address (10.1.1.50 in our case). 7. The reply from the internal server will be forwarded via the same link the request arrived, to ensure persistency, after the source IP (10.1.1.50) is replaced by the NAT IP (100.1.1.21).
137
Multihoming Configuration Summary

The following configuration guidelines details the steps required to configure a basic multihoming solution in LinkProof.
To configure multihoming 1. 2. Configure networking definitions (IP interfaces, VLANs, routing). Configure WAN link load balancing: 3. Add a router farm. For the procedure, see Configuring a Farm, page 139. Add logical router servers. For the procedures, see Server Management, page 155. Define health checks. For more information, see Health Monitoring, page 355. Define flows and flow policiesif routing policies are required. For the procedure, see To Configuring Flow Policies, page 197.
Configure outbound NAT called Dynamic NAT in LinkProof to define for each router (WAN link) the NAT addresses to be used when forwarding. For more information, see Dynamic NAT, page 168. Do the following to configure inbound traffic load balancing (if required): a. Configure Static NAT to define for each internal server that must be available for access from the external network the IP address that will represent it via each router (WAN link), Static NAT, page 169. Map the URLs for which LinkProof is authoritative server to the internal server IP addresses, Mapping URLs to Local IP Addresses, page 182.
4.
b.
Farm Management
This section describes how LinkProof incorporates server farms into the network configuration and contains the following topics: LinkProof Farms, page 138 Farm Load Balancing, page 144 Default Farm, page 153 Farm Connectivity Checks, page 154
LinkProof Farms
LinkProof works with server farms rather than with individual servers. Using multiple servers organized in a farm eliminates downtime, accelerates the service response time, and improves overall performance. A farm is a group of network servers that provide the same service. In the context of LinkProof, a service can be an application that uses a specified TCP or a UDP port, or a complex service that combines several basic services. Servers in a farm can belong to different vendors and have different capacities. The differences between the servers within a farm are transparent to users. If all the servers within a group provide the same service managed by the device, you can configure the group as a LinkProof server farm. A LinkProof farm can contain either logical routers (access routers to the WAN) or logical firewalls/ VPN gateways, but not combination of the two.
138
Farm Policy
LinkProof operation is based on main components bound together into a Farm Policy: farm, network, and service. A farm definition includes server-farm functions, such as a load-balancing scheme for client-server persistency and connectivity check methods. When a newly arriving packet needs to be redirected to a certain farm, LinkProof selects the best available server (according to user-defined criteria). In this manner, LinkProof optimizes the server operation and improves the overall quality of service. Each LinkProof farm can be associated with a virtual IP address (VIP). This address is used by the configured clients to access the farm. Each server within a LinkProof farm is recognized by its IP address. This IP address can be hidden from the clients, making the process of server selection transparent to the users. To facilitate non-transparent operation, LinkProof provides a virtual IP address for the content farms. LinkProof intelligently directs sessions to the most available server, sending repeated requests for the same site to the same cache server when it load balances cache servers. LinkProof operation is based on traffic redirection policies, which classify user traffic redirection patterns (Layer 1Layer 7) by redirecting the traffic to a selected farm. Once the traffic is redirected to a farm, a load balancing decision is taken in order to select the most available content server. LinkProof enables you to build a Farm Policy based on a rule that combines these components (Layer 1Layer 7). For example, a rule that takes into consideration client traffic that arrives from (or is destined to) a certain network, is identified by the defined service, and then is redirected to a farm for packet or session handling.
Configuring a Farm
To configure a farm of logical routers and/or logical firewalls 1. Select LinkProof > Farms > Farm Table. The Farm Table pane is displayed. 2. Click Create. The Farm Table Create pane is displayed. 3. Configure the parameters; and then, click Set.
Table 68: Farm Parameters
Parameter
Farm Name
Description
A name, up to 20 characters, to describe the farm.
Caution: You must not use either firewall or securitydevice for the name of a farm (case-insensitive).
Caution: Due to Web-browser limitations, Radware recommends that farm names on the same LinkProof device be caseinsensitively unique. For example, a farm on a device named myfarm or MYFARM is OK, but myfarm and MYFARM on the same device may result in browser-incompatibility issues.
139
Parameter
Dispatch Method
Description
The method that the device uses for farm load balancing. For more information, see Dispatch Methods, page 144. Values: Cyclic Least Amount of Traffic Fewest Number of Users NT-1 NT-2 Private-1 Private-2 Least Number of Bytes Hashing Least Amount of Local Traffic Fewest Number of Local Users Least Number of Local Bytes Response Time Customized Hash Multicast Source IP Hashing Layer-3 Hashing Default: Cyclic
Client Aging Time
How often, in seconds, the device ages (deletes) entries in the Client Table. Value: 53600 Default: 60 Note: If you set the value to any value larger than the minimum, the device sends traffic for the farm to the platforms accelerators. If you set the value to the minimum, the device does not send traffic for the farm to the platforms accelerators, and you may expect reduced performance with large traffic volumes.
Connectivity Check Status
The status of the connectivity check. Values: DisableDisables Connectivity Checks Health Monitoring Ping Only Default: Ping Only
Connectivity Check Interval Connectivity Check Retries
The interval, in seconds, that the LinkProof device polls the servers. Default: 10 The number of polling attempts that the LinkProof device makes before a server is considered inactive. Default: 5
140
Parameter
Default Farm Action
Description
Specifies the action of the LinkProof device if the farm is unavailable (all the servers in the farm are Not in Service). Values: DropThe device drops the packet. SkipThe device bypasses the farm and forward the packet to the next farm in the flow. Default: Drop
Packet Handling
Defines the type of packet handling to be performed by LinkProof on packets that are forwarded to the farm, or received from the farm (on their way back to the source). Values: DisableLinkProof does none of the actions listed in the drop-down list. VIPTranslation to a virtual address is required when working with proxy security servers. Transform HTTP RequestsLinkProof translates packets into proxy requests packet and sets the destination address to the server address. Use this option when security servers are working in proxy mode, but clients are not configured to send traffic via the proxy. Transform POP3 RequestsLinkProof translates packets into proxy requests packet and sets the destination address to the POP3 server address. Use this option when antivirus scanners are working in proxy mode, but clients are not configured to send traffic via the proxy. Virtual TunnelingLinkProof uses Radwares Virtual Tunneling mechanism (see Virtual Tunneling, page 237). Default: Disable
NAT Mode
Species whether LinkProof does network address translation on the packets. Values: Enable, Disable Default: Disable
Transparent Proxy Port
Enables proxy requests to be sent to a port different from the default application port. This parameter is relevant only when the Packet Translation parameter is Transform HTTP Requests or Transform POP3 Requests. Values: 0Specifies that the destination port on the packet sent to the server will remain unchanged. 165,535 Default: 0
POP3 Proxy Delimiter
The delimiter used in POP3 proxy requests, which may differ between vendors. This parameter is required only when the Packet Translation parameter is Transform POP3 Requests. Default: #
141
Configuring Extended Parameters for a Farm of Logical Routers and/or Logical Firewalls
To configure extended parameters for a farm of logical routers and/or logical firewalls 1. 2. 3. Select LinkProof > Farms > Farm Extended Parameters. The Farm Extended Parameters pane is displayed. From the Farm Name column, click the relevant farm. The Farm Extended Parameters Update pane is displayed. Configure the parameters; and then, click Set.
Table 69: Extended Parameters for a Farm of Logical Routers and/or Logical Firewalls
Parameter
Farm Name Clear Client Table Condition
Description
The name of the farm (read-only). The condition for clearing the Client Table. Values: NonePrevious functionality is ignored. Any Server UpWhen a server of a particular farm goes up after having been down, all the client entries are deleted that are part of that farm. First Regular Server UpWhen a regular server goes up and it is the first regular server for that farm to go up, all the Client Table entries associated with that server of that farm are deleted. Default: None Note: For more information on supported scenarios and how this feature works, see http://www.radware.com/content/ download.asp?document=8260.
Basic Nat Fallback
What the LinkProof device does if it is configured to perform NAT for this farm using Basic NAT and all NAT IP addresses available for basic NAT are currently allocated. Values: Use Dynamic DiscardDiscard packets Use Local
142
Table 69: Extended Parameters for a Farm of Logical Routers and/or Logical Firewalls
Parameter
Persistency Mode
Description
The mode that LinkProof stores session information. Session persistency ensures that all traffic related to a single application session arrives at the same server. LinkProof can maintain persistency per farm according to any session identification parameter or combination of them that is less than the Client Table mode. For example, if Client Table Mode is Full Layer 4, you can select from Layer 3, Half Layer 4, Source IP, Destination IP, or Client Table. Values: Source IP Destination IP Layer 3 Half Layer 4 Client Table HTTP HeaderFor a Persistency String Hostname
Extended Persistency Time
The time, in minutes, that the device stores session data that is aged (deleted) from the Client Table. The timer starts when the data is aged. Extended Persistency Time ensures that session persistency is maintained even after the session is deleted from the Client Table. Radware recommends that you set this parameter when the Remove Entry at Session End option is enabled or the Client Table Aging time is very short. This configuration uses much less memory than the Client Table. Each entry that LinkProof stores includes the source IP address, destination IP address, the server, and farm chosen by the Dispatch Method. You cannot tune the memory that Extended Persistency Time uses however. Values: 01440 Default: 0
Persistency String
When the specified Persistency Mode is HTTP Header, the device stores the HTTP header, the header content, and the value specified in the Persistency String field. You can use this feature, for example, to check the browser client message, redirect the traffic from a mobile device manufactured by a certain company to only one specific content server. When the value in the Persistency String field is 0, the device stores no user-defined additional value. The total length cannot exceed 20 characters. If the specified Persistency Mode is not HTTP Header, LinkProof ignores the value in the Persistency String field.
Multicast MAC Address
If the Dispatch Method is Multicast, this parameter specifies the multicast MAC address. If the Dispatch Method is not Multicast, LinkProof ignores this parameter.
Clients Connect Denials Displays, read-only, the number of connection denials the server has encountered since last statistics reset.
143
Farm Load Balancing

Load balancing between servers of a farm is determined by a number of parameters. The most important parameters are Dispatch Method, which defines how to select a server from the farm, and persistency which defines when to select a new server. These parameters, together with the Client Aging Time, are required for the LinkProof farms. For more information, see LinkProof Farms, page 138.
Dispatch Methods
LinkProof receives requests for services from clients and decides to which server to direct (that is, dispatch) each request. During this process, LinkProof finds the best server to provide the requested service. The Dispatch Method parameter defines the criteria by which LinkProof selects the best server in the farm. LinkProof uses the specified Dispatch Method only for new sessions; LinkProof handles existing sessions using the Client Table. You can define the Dispatch Method parameter during the farm configuration, according to farm characteristics and your needs. Criteria may vary for different applications. For example, the number of users is a significant factor for a Web farm, whereas the amount of traffic can be more important for an FTP farm. The list of available Dispatch Methods depends on the specified farm type. LinkProof supports the following Dispatch Methods: Cyclic, page 144 Fewest Number of Users, page 144 Fewest Number of Local Users, page 144 Hashing, page 145 Least Local Traffic, page 145 Least Number of Bytes, page 145 Least Number of Local Bytes, page 145 Least Traffic, page 145 NT-1 and NT-2, page 146 Private-1 and Private-2, page 147 Response Time, page 148 Customized Hash, page 148 Multicast Dispatch, page 219 Source IP Hashing, page 149 Layer 3 Hashing, page 149
Cyclic
When the Cyclic Dispatch Method is specified, LinkProof forwards the traffic dynamically to each sever in a round-robin fashion.
Fewest Number of Users

When the Fewest Number of Users Dispatch Method is specified, LinkProof directs new requests for service to the server with the least number of sessions at that given time.
Fewest Number of Local Users

You can use the Fewest Number Of Local Users Dispatch Method when the same servers participate in multiple farms. When this method is specified, LinkProof 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.
144
LinkProof User Guide Basic Application Switching For example, Server 1 and Server 2 can provide service A and service B. These servers are used as part of Farm A to provide service A and as part of Farm B to provide service B. When the clients request for service A is sent to Farm A, which uses this Dispatch Method, LinkProof looks for a server with the fewest number of requests for service A. The requests for service B that exist on the same servers are not considered by LinkProof.
Note: The session number is defined by the active Client Table entries to this server.
Hashing
When the Hashing Dispatch Method is specified, LinkProof selects a server for a session using a hash function. This is a static method where the server is chosen for a session purely by the session information. The input for the hash function is source and destination IP addresses. Source and destination ports can also be taken into consideration if the Port Hashing parameter is enabled and the Client Table mode is Full Layer 4. This method is symmetric, which means that it provides the same output when the source and destination addresses are switched. For example, a packet from A to B will result in the same hash output (that is, server) as the reply packet from B to A.
Least Local Traffic

You can use the Least Amount of Local Traffic Dispatch Method when same servers participate in multiple farms. When this method is specified, LinkProof looks for the server with least amount of traffic only within the farm that is currently addressed by the client. Traffic of other farms is not considered. For example, Server 1 and Server 2 provide service A and service B. These servers are used as part of Farm A to provide service A and as part of Farm B to provide service B. When the clients request for service A is sent to Farm A, which uses this Dispatch Method, LinkProof considers only the traffic that is related to service A. The traffic that is related to service B on the same servers is not considered by LinkProof. LinkProof looks for a server with the least amount of traffic related to service A, and forwards clients request to this server.
Least Number of Bytes

When the Least Number of Bytes Dispatch Method is specified, LinkProof directs new requests for services to the server with the least amount of traffic in bytes at that given time. The amount of traffic is defined as bytes from LinkProof to the server and from the server to LinkProof, as is recorded in the devices Client Table for all traffic forwarded to that server.
Least Number of Local Bytes

You can use the Least Number of Local Bytes Dispatch Method when same servers participate in multiple farms. When this method is specified, LinkProof looks for the server with least amount of traffic only within the farm that is currently addressed by the client. Traffic of other farms is not considered. For example, Server 1 and Server 2 provide service A and service B. These servers are used as part of Farm A to provide service A and as part of Farm B to provide service B. When the clients request for service A is sent to Farm A, which uses this Dispatch Method, LinkProof considers only the traffic that is related to service A. The traffic that is related to service B on the same servers is not considered by LinkProof. LinkProof looks for a server with the least amount of traffic related to service A, and forwards clients request to this server.
Least Traffic
When the Least Traffic Dispatch Method is specified, LinkProof directs new requests for service to the server with the least amount of traffic at that given time. The amount of traffic is defined as packets per second (pps) from LinkProof to the server and from the server to LinkProof, as is recorded in the devices Client Table for all traffic forwarded to that server.
145
NT-1 and NT-2

When the NT-1 or the NT-2 Dispatch Method is specified, LinkProof queries the farm servers for Windows NT SNMP statistics. LinkProof forwards the farms clients to the least busy server according to the servers reported statistics. You can select statistics from a list. The parameters are implemented according to the weights that you define in the first Windows NT weights scheme for the NT-1, and second Windows NT weights scheme for the NT-2.
To configure NT-1 and NT-2 Dispatch Methods 1. 2. 3. Select LinkProof > Load-Balancing Algorithms > Windows NT Parameters. The Windows NT Parameters pane is displayed. Click on a parameter row. The Windows NT Parameters Update pane is displayed. Configure the parameters; and then, click Set.
Table 70: Windows NT Parameters
Parameter
Serial Number Check Period
Description
The scheme to be used, either NT-1 or NT-2. The time interval, in seconds, between queries for the frequently updated parameters (number of open sessions, amount of traffic). Values: >0 Default: 10
Open Sessions Weight
The relational weight for considering the number of active sessions on the server. Values: 110 Default: 3
Incoming Traffic Weight
The relational weight for considering the amount of traffic coming to the server. Values: 110 Default: 3
Outgoing Traffic Weight
The relational weight for considering the amount of traffic going out of the server. Values: 110 Default: 3
Regular Check Period
The time, in seconds, between queries for other less dynamic parameters (average response time, limits on users and TCP connections). Values: >0 Default: 300
Response Weight
The relational weight for considering the average response time of the server. Values: 110 Default: 3
146
Table 70: Windows NT Parameters
Parameter
User Limit Weight
Description
The relational weight for considering the limit on the number of logged in users on the server. Values: 110 Default: 3
TCP Limit Weight
The relational weight for considering the limit of TCP connections to the server. Values: 110 Default: 3
Retries
Defines how many unanswered requests for a variable cause to this variable to be ignored in the load balancing decision. Values: Any 32-bit number Default: 3
NT Community
The community name to use, up to 30 characters, when addressing the server. Default: public
Private-1 and Private-2

When the Private-1 or the Private-2 Dispatch Method is specified, LinkProof queries the farms servers for private SNMP parameters according to a predefined private weight scheme. The ratios of sessions on the servers is balanced according to the statistics. You need to define which MIB variables are queried, and then set the private weights scheme. The parameters are implemented according to the weights that you define in the first private weights scheme for the Private-1 and second private weights scheme for the Private-2.
To configure the private load-balancing parameters for the Private-1 and Private-2 Dispatch Methods 1. Select LinkProof > Load-Balancing Algorithms > Private Parameters. The Private Parameters pane is displayed. 2. Click on a parameter row. The Private Parameters Update pane is displayed. 3. Configure the parameters; and then, click Set.
Table 71: Load-Balancing Algorithms Private Parameters
Parameter
Serial number Check Period (Secs) Retries Community Var1 Object ID
Description
The serial number of the scheme. Scheme number 1 is used for Dispatch Method Private-1, and so on. The time interval between queries for the requested parameters. How many unanswered requests for a variable cause this variable to be ignored in the load balancing decision. The community name for addressing the server. The SNMP ID of the first private variable to check.
147
Table 71: Load-Balancing Algorithms Private Parameters
Parameter
Var1 Mode
Description
Specifies whether to measure the percentage available or the percentage utilized of the first parameter. Values: AscendingThe value of the variable specified in Var1 Object ID represents the percentage still available. DescendingThe value of the variable specified in Var1 Object ID represents the percentage currently utilized.
Var1 Weight Var2 Object ID Var2 Mode
The relational weight for considering the value of the first parameter. The SNMP ID of the second private variable to check. Specifies whether to measure the percentage available or the percentage utilized of the second parameter. Values: AscendingThe value of the variable specified in Var2 Object ID represents the percentage still available. DescendingThe value of the variable specified in Var2 Object ID represents the percentage currently utilized.
Var2 Weight
The relational weight for considering the value of the second.
Response Time
The Response Time Dispatch Method enables LinkProof to select the fastest server in the farm. When this method is specified, the load-balancing process is based on choosing the least loaded server as calculated by the Response Level as measured by the Health Monitoring module. The Health Monitoring module enables you 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 actual 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, from 1 through 9 defines the samples number. The Response Level Samples parameter can be used in the health checks in which the Measure Response Time parameter is enabled. Configuration of the Response Time Dispatch Method involves the following steps: Setting health checks for servers in the farm. When you configure the health-check parameters, enable the Measure Response Time option for each health check. Enabling the Health Monitoring module for this farm (see Health Monitoring, page 367). Setting the Dispatch Method parameter in the farm to Response Time. Setting the Response Level Samples parameter.
Customized Hash
The Customized Hash Dispatch Method is a variant of the Hashing Dispatch Method, which offers a different server distribution. This method enables you to define the bits in the source and destination IP to be input for the hash function. You can configure the mask for this method using either WBM or CLI.
148
To configure the mask for this method using CLI Use the following command:
lp global customized-hash-mask
The default mask is 0.0.0.255.
To configure the mask for this method using Web Based Management 1. Select LinkProof > Global Configuration > Tweaks > Customized Hash Mask. 2. Type the required value. 3. Click Set.
Multicast
When the Multicast Dispatch Method is used, after the return packet reaches the lower LinkProof device, a Multicast is sent with the return packet to both VPN gateways. The gateway that responds first, is the one with an established VPN session. LinkProof forwards the traffic to the VPN gateway and the session is not interrupted. For more information, see VPN Load Balancing, page 218.
Note: The OnDemand Switch VL platform does not support the Multicast Dispatch Method.
Source IP Hashing
When the Source IP Hashing Dispatch Method is specified, LinkProof performs the hash function on the source IP address only. This ensures that when a connection passes through the device, as long as it uses the same source IP address, the connection will remain persistent (that is, it will pass through the same NHR).
Layer 3 Hashing
When the Layer 3 Hashing Dispatch Method is specified, LinkProof performs the hash function on the source and destination IP. This ensures that when a connection passes through the device, as long as it uses the same source and destination IP address, the connection will remain persistent (that is, it will pass through the same NHR). This method is symmetric, meaning that when replacing the source with the destination IP address and vice versa, the selected NHR will be identical.
Session Persistency
Session persistency means making sure that all traffic that is related to a single application session arrives at the same server. You can configure when a new server will be selected for each farm by configuring the persistency mode configuration per farm.
Note: The default Persistency Mode within a farm is Layer 3. The default global persistency mode (that is, Client Table Mode) is Full Layer 3.
149
LinkProof User Guide Basic Application Switching LinkProof can keep the persistency per farm according to any session identification parameter or combination of them that is less than the Client Table Modefor example, source IP or destination IP if the Client Table Mode is Layer 3or according to the Client Table Mode.
Note: You cannot change the Client Table Mode if persistency for any of the device farms is on a higher level than the new Client Table mode. For example, if Client Table mode is set to Full Layer 4 and Persistency for any of the farms is set as to Half Layer 4, you cannot change the Client Table Mode to Layer 3.
Client Table Aging Time

The Client Table tracks the sessions load balanced by the device to efficiently handle the flow of traffic between the clients and the servers. The Client Aging Time parameter determines the time (in seconds) between the moment a Client Table entry becomes inactive and when the entry is removed from the Client Table. An entry is active as long as there is continuous traffic between the client and the server. Every time an incoming packet or an outgoing packet is identified by a Client Table entry, the Client Aging Time for the entry is reset.
Packet Handling
The Packet Handling parameter defines whether LinkProof must perform any address translation on packets that are forwarded to the farm, or received from the farm (on their way back to the source).
Table 72: Packet Handling Options
Option
Disable VIP
Description
No address translation required. Translation to a virtual address is required when working with proxy firewalls or to provide access to internal firewalls via firewalls that perform NAT. This option is available only for a Firewall farm. Virtual Tunneling requires NAT Mode to be enabled and is configured on packets going to a router farm and received from a farm. LinkProof translates packets into proxy request packets and sets the destination address to the server address. Use this option when security servers are working in proxy mode, but clients are not configured to send traffic via the proxy. LinkProof translates packets into proxy request packets and sets the destination address to the POP3 server address. Use this option when antivirus scanners are working in proxy mode, but clients are not configured to send traffic via the proxy.
Virtual Tunneling
Transform HTTP Requests
Transform POP3 Requests
Basic NAT Fallback

If the LinkProof is configured to perform Network Address Translation for this farm using Basic NAT, there is a risk that all NAT IP addresses available for Basic NAT are allocated at certain moment. You can specify the action LinkProof takes under this condition. The options are to use Dynamic NAT IP, local IP, or discard packets.
150
NHR Tracking Table

LinkProof uses the NHR Tracking Table to ensure that traffic destined to the device is always returned via the correct router, through which it arrived. For every session that arrives from one of the routers with the destination IP of the LinkProof device, LinkProof adds an entry to the NHR Tracking Table. The entry identifies the session (source IP and source port) and the routers from which the session arrived. When the LinkProof device sends a reply packet, LinkProof uses the NHR Tracking Table to determine the router. Additionally, LinkProof keeps entries in the NHR Tracking Table with a TTL less than or equal than 1, for which the device needs to generate an ICMP error. LinkProof adds no entries to the NHR Tracking Table for traffic with source IP belonging to the router. The device immediately knows to which router such traffic is to be sent. You can specify how long the device keeps an entry in the NHR Tracking Table when no traffic matches it.
To configure NHR Tracking Table 1. Select Services > Tuning > Device. The Device Tuning pane is displayed. 2. In the NHR Tracking Table text box, type the limit on the number of entries in the NHR Table. Default: 100,000. 3. Click Set. The values in the fields are synchronized and any changes are implemented after reset. 4. Select LinkProof > Global Configuration > General. The Global Configuration - General pane is displayed. 5. Configure the following parameters:
Parameter
NHR Tracking Table Status NHR Tracking Table Aging 6. Click Set.
Description
Specifies whether the LinkProof device uses the NHR Tracking Table. The time, in minutes, LinkProof keeps an entry in the NHR Tracking Table when no traffic matches it.
Load Balancing Proxy Firewall Farms

A firewall is a filtering application capable of stopping unwanted traffic to and from your network. The purpose of the firewall is to inspect and control all the traffic between the local network and the Internet. The traffic must be handled in such a way that all potentially dangerous traffic be detected and dropped and if necessary logged. What traffic is dangerous for the local network is determined by the security policy adopted for the site. A single firewall is a single point of failure and can become capacity bottleneck, causing an interruption in service when the firewall is busy or down. Organizations encounter numerous problems when installing multiple firewalls. First, different client groups must be configured, which is a time-consuming procedure. Furthermore, multiple points of failure are created with the addition of each firewall. Since the traffic load is not dynamically shared between units, the firewalls are not used optimally. Finally, to achieve fault tolerance and redundancy between firewalls, hot standby, or idle units must be deployed on the network. Since the firewalls task is to separate between networks, firewall servers have at least two legs, one connected to the internal network and one connected to the external network (Internet).
151
LinkProof User Guide Basic Application Switching To provide scalability and reliability, the traffic is load balanced on inbound and outbound paths through these firewalls.
Note: Firewall farms can be used to load balance firewall devices and any other devices that separate between trusted and untrusted networks and have at least two separate physical interfaces (one for each subnet), such as VPN gateways. To load balance proxy firewalls, LinkProof must provide a single IP address that will represent the firewall farm to the clients. This IP address is called a virtual IP (VIP). This is the address that will be configured as the proxy address in the client workstations. Clients will send traffic to the VIP and LinkProof, once it has selected a firewall, LinkProof replaces the packet destination IP address with the firewalls IP address. On the traffic returning from the proxy firewall to the client, LinkProof replaces the packets source IP address (that is the firewall server address) with the VIP address (see the following figure).
Figure 8: Example Proxy Firewall Configuration

Server 1 IP (SIP 1) CIP->VIP CIP->SIP1
Client
LinkProof
CIP<-SIP1
Client IP (CIP)
Virtual IP (VIP)
CIP<-VIP Server 2 IP (SIP 2)
Load Balancing Transparent NAT Firewalls Using a VIP

In many cases, the firewalls perform NAT for internal clients. In such cases, if it is required to load balance outbound traffic only, there is no need for LinkProof to perform any translations on the packets. However, if inbound load balancing to internal servers is required, the internal servers through a single public IP need to be represented. To implement such configurations, the VIP mechanism is required on the farm defined for inbound traffic load balancing (the external leg of the firewall servers). The VIP represents the public IP for the internal server. The Destination IP address on incoming traffic to the internal server (VIP address) is replaced with the Static NAT address provided by the firewall server selected for this internal server. The source IP address on reply traffic from the internal servers is changed by the firewall server to the NAT address and by the LinkProof to the VIP address (see the following figure).
152
Figure 9: Example Transparent NAT Firewall

NAT IP for Internal Server (NIP 2) CIP->VIP Server 1 IP (SIP 1)
CIP<-NIP1 Client
CIP->LIP
CIP->NIP1
CIP<-LIP
Client IP (CIP)
Virtual IP (VIP)
Internal Server
CIP<-VIP
Server 2 IP (SIP 2) NAT IP for Internal Server (NIP 2)
Translating Outbound Traffic to Virtual Addresses

LinkProof can perform source address translation to VIP on outbound sessions if the internal servers can also initiate outbound sessions and if the Translate Outbound Traffic to Virtual Address option is enabled.
To configure translation of outbound traffic to a virtual address 1. Select LinkProof > Global Configuration > General. The Global Configuration - General pane is displayed. 2. From the Translate Outbound Address to Virtual Address drop-down list, select enable to change NAT addresses to virtual IP addresses. 3. Click Set.
Default Farm
A default farm is automatically created for each server IP address configured on the LinkProof device. The default farm has the following purposes: To allow the device to select an edge (end of flow) farm according to the routing table. When the traffic does not match any configured flow, the device searches the routing table for the default gateway. If the default gateway is a server configured on the device, LinkProof forwards traffic to the default farm that was configured for this server. Otherwise, the traffic is forwarded to the default gateway without any farm being selected. When traffic arrives from a logical server that belongs to a farm that is not configured in any flow.
The first time an IP address is configured as belonging to a farm, the device automatically configures this farm as the default farm for the server IP. The farm that is automatically configured as the default farm for a server IP can be changed.
153
To modify parameters of a default farm 1. 2. 3. Select LinkProof > Farms > Default Farm Table. The Default Farm Table pane is displayed. From the Ip Address column, click the relevant farm. The Default Farm Table Update pane is displayed. Configure the parameters; and then, click Set.
Table 73: Default Farm Parameters
Parameter
Ip Address Farm Name
Description
The IP address of the farm (read-only). The farm to which the server belongs.
Caution: You must not use either firewall or securitydevice for the name of a farm (case-insensitive).
Caution: Due to Web-browser limitations, Radware recommends that farm names on the same LinkProof device be case-insensitively unique. For example, a farm on a device named myfarm or MYFARM is OK, but myfarm and MYFARM on the same device may result in browser-incompatibility issues. Server Name The physical server name. The Server Name defines the name of the farm servers group that are associated with this physical server. Adding a new server to a farm using a Server Name that was already defined in another farm, implies that it is the same physical server.
Farm Connectivity Checks

To load balance traffic that arrives at a LinkProof farm, the state of the servers in this farm must be checked. LinkProof periodically checks the health of the servers. A successful check indicates that the service is available on that server. Failure to establish a successful connection means that LinkProof considers the server unavailable for the service or farm. When a failure occurs, LinkProof continues to check for the servers availability and generates a syslog, e-mail, SNMP, or CLI trap stating that the server is not in service. LinkProof can be configured to monitor the status of servers in its farms to ensure they are available and can handle the request. During the farm connectivity checks, the farm is considered as one entity and therefore each server within the farm is checked in the same way. You can perform a health check of the servers using one of the following methods: BasicUses pings AdvancedUses the Health Monitoring module
154
LinkProof User Guide Basic Application Switching LinkProof performs pinging by sending an ICMP echo request to the server. If a server is available, this server sends an ICMP echo reply. If a ping operation fails, this means that the server is down.
Notes: >> When the basic Farm Connectivity Checks (ping) are used, the status of servers in the farm is affected by these checks only. >> Using the basic Farm Connectivity Checks (ping), LinkProof does not resume checks on farms where subnet of farm IP does not correspond to any of the configured LinkProof IP interfaces. This applies, for example, after Interface Grouping was triggered and released The following table describes the Connectivity Checks configuration parameters.
Table 74: Connectivity Check Methods
Parameter
Connectivity Interval Connectivity Retries
Description
How often, in seconds, LinkProof polls the servers. Default: 10 The number of polling attempts that LinkProof makes before a server is considered inactive. Default: 5
Identify Server by Name

This parameter enables you to determine the health status of the logical server according to the status of all the physical server interfaces. For example, when one side of the firewall is not in service, LinkProof considers all other firewalls with the same name to be out of service as well. This parameter can be used either when using LinkProof connectivity checks, or when using the Health Monitoring module.
Server Management
This section describes server management and contains the following topics: Servers Overview, page 155 Configuring a Logical Router, page 156 Configuring a Logical Firewall, page 159 Physical Servers, page 161 Cluster Servers, page 164 Full Path Health Monitor, page 166 Server Statistics, page 167
Servers Overview
In the context of LinkProof, servers are logical entities that are associated with application services provided by physical servers that run these applications. After configuring the required farms (seeFarm Management, page 138), the process of adding and configuring servers in the LinkProof farm consists of two main stages: Adding physical servers Setting up farm servers
155
LinkProof User Guide Basic Application Switching Adding physical servers means adding the hardware elements to the network and defining them as servers. You do this after the actual installation of the physical server is performed. For each service provided by a physical server, you can define a farm server and attach it to the farm that provides the service. Configuring farm servers means organizing the servers the way you use their services. A physical server that provides multiple services might 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 own load balancing scheme and customized health checks. Thus, if one of the services provided by a physical server is not available, other services can still be used. To enable tracking of all the farm servers associated with the specific physical server, farm servers are organized in groups, identified by the server name. All farm servers with the same server name are considered by LinkProof 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. You configure a physical server for each server name, which applies to all farm servers on the same LinkProof with the same name, implying they all run on the same machine. Farm (logical) servers represent applications residing on the physical server. Each application provides a particular service. LinkProof supports different farm server types, according to farm types: routers and firewalls. You configure parameters that define a servers behavior within a specified farm. The name of the farm server identifies the actual physical server that provides the service. The Server Name parameter is configured when the physical server is added to the Logical Routers table or Logical FW (firewall) table. The IP address of the farm server must also be defined. A physical server can have a few IP addresses, so different farm servers that operate on the same physical server can have different IP addresses. The same server name and server address can be used in different farms (but same type of farms).
Notes: >> LinkProof periodically sends ARP to all logical servers that have an IP address. You can disable this mechanism using the ARP to Logical Servers parameter, and set the interval between ARPs (in seconds) using the Time between ARPs parameter. >> LinkProof can select the MAC address and incoming ports of the Next Hop Router to determine the origin of the Next Hop Router traffic. When disabled, only the source MAC is selected. Typically, you enable this option only when using port rules and when Next Hop Routers use the same MAC on different physical ports.
Configuring a Logical Router
To create a logical router 1. 2. Select LinkProof > Servers > Logical Routers Table. The Logical Routers Table pane is displayed. Click Create. The Logical Routers Table Create pane is displayed.
156
LinkProof User Guide Basic Application Switching 3. Configure the parameters; and then, click Set.
Table 75: Logical Routers Parameters
Parameter
Farm Name Router Name IP Address Weight
Description
The name of the farm defined in the Router Farm Table pane. The user-defined name of the router. The IP address of the router. The weight of the server in the farm. The device forwards more traffic to a server with a higher weight. Server weights operate as ratios. For example, when the Dispatch Method is Fewest Number of Users, the weights determine the ratio of the number of users between the servers. When the Dispatch Method is Least Amount of Traffic, 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: 1100 Default: 1 Note: Server Weight is not supported when the Cyclic Dispatch Method is selected in the farm.
OperMode
The operational modes of the farm server. Values: RegularThe servers health is checked, as long as it is available the server is eligible for receiving client requests. BackupThe servers 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. Note: You can also set a server to provide backup for a specified server. Backup servers configured on the farm level are activated only when all the active servers are down.
Connection Limit
The maximum number of Client Table entries that can run simultaneously on the server. This depends on farms Sessions Mode. When the limit is reached, new requests for service are no longer directed to this server. All open sessions are continued. Values: 0The mechanism is disabled for this server, and there is no bandwidth limit. 1999,999,999 Default: 0
157
Table 75: Logical Routers Parameters
Parameter
AdminStatus
Description
The user-defined management status of the server, which you can change at any stage of servers configuration or operation. Values: EnableThe server is active and ready to reply to new requests for service. DisableThe server is not active. When setting the Admin Status to Disabled, the device removes all the entries relevant to this server from the Client Table, stops sending new requests for service to this server and disconnects all the connected clients. ShutdownThe server cannot get new requests for service. The existing sessions are completed according to the Aging Time. Default: Enable Note: Before performing maintenance procedures, set the Shutdown Admin Status. You can start maintenance procedures after completion of active sessions.
Kbps Limit
The maximum bandwidth limit (in kbit/s) that can be forwarded to the Router Server. When the limit is reached, new requests for service are no longer directed to this server. All open sessions are continued. Values: 0Specifies that the mechanism is disabled for this server, and there is no bandwidth limit. 133,554,431 Default: 0
Inbound Kbps Limit
The maximum amount of bandwidth in Kbps allowed for inbound traffic from this logical server. When the limit is reached, new requests for service are no longer directed to this server. All open sessions are continued. Values: 0Specifies that the mechanism is disabled for this server, and there is no bandwidth limit. 133,554,431 Default: 0
Outbound Kbps Limit
The maximum amount of bandwidth in Kbps allowed for inbound traffic from this logical server. When the limit is reached, new requests for service are no longer directed to this server. All open sessions are continued. Values: 0Specifies that the mechanism is disabled for this server, and there is no bandwidth limit. 133,554,431 Default: 0
158
To modify a logical router and/or view related statistics 1. Select LinkProof > Servers > Logical Routers Table. The Logical Routers Table pane is displayed. 2. Select the link to the required server. The Logical Routers Table Update pane is displayed. 3. Set or view the parameters. 4. Click Set.
Configuring a Logical Firewall
To create a logical firewall 1. Select LinkProof > Servers > Logical Firewalls Table. The Logical Firewall Table pane is displayed. 2. Click Create. The Logical Firewall Table Create pane is displayed. 3. Configure the parameters; and then, click Set.
Table 76: Logical Firewall Parameters
Parameter
Farm Name Firewall Name IP Address Weight
Description
The name of the farm defined in the FW Farm Table pane. The user-defined name of the firewall. The IP address of the firewall. The weight of the server in the farm. The device forwards more traffic to a server with a higher weight. Server weights operate as ratios. For example, when the Dispatch Method is Fewest Number of Users, the weights determine the ratio of the number of users between the servers. When the Dispatch Method is Least Amount of Traffic, 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: 1100 Default: 1 Note: Server Weight is not supported when the Cyclic Dispatch Method is selected in the farm.
OperMode
The operational modes of the farm server. Values: Regularthe Servers health is checked, as long as it is available the server is eligible for receiving client requests. BackupThe servers 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. Note: You can also set a server to provide backup for a specified server. Backup servers configured on the farm level are activated only when all the active servers are down.
159
Table 76: Logical Firewall Parameters
Parameter
Connection Limit
Description
The maximum number of Client Table entries that can run simultaneously on the Logical Server. This depends on farms Sessions Mode. When the limit is reached, new requests for service are no longer directed to this server. All open sessions are continued. Default: 0Specifies that the mechanism is disabled for this server, and there is no user number limit.
AdminStatus
The user-defined management status of the server, which you can change at any stage of servers configuration or operation. Values: EnableThe server is active and ready to reply to new requests for service. DisableThe server is not active. When setting the Admin Status to Disabled, the device removes all the entries relevant to this server from the Client Table, stops sending new requests for service to this server and disconnects all the connected clients. ShutdownThe server cannot get new requests for service. The existing sessions are completed according to the Aging Time. Default: Enable Note: Before performing maintenance procedures, set the Shutdown Admin Status. You can start maintenance procedures after completion of active sessions.
Kbps Limit
The maximum bandwidth limit (in kbit/s) that can be forwarded to the Router Server. When the limit is reached, new requests for service are no longer directed to this server. All open sessions are continued. Default: 0Specifies that the mechanism is disabled for this server, and there is no bandwidth limit.
Inbound Kbps Limit
The maximum amount of bandwidth in Kbps allowed for inbound traffic from this logical server. When the limit is reached, new requests for service are no longer directed to this server. All open sessions are continued. Default: 0Specifies that the mechanism is disabled for this server, and there is no bandwidth limit.
Outbound Kbps Limit
The maximum amount of bandwidth in Kbps allowed for inbound traffic from this logical server. When the limit is reached, new requests for service are no longer directed to this server. All open sessions are continued. Default: 0Specifies that the mechanism is disabled for this server, and there is no bandwidth limit.
To modify a logical firewall and/or view related statistics 1. 2. Select LinkProof > Servers > Logical Firewalls Table. The Logical Firewall Table pane is displayed. Select the link to the required server. The Logical Firewall Table Update pane is displayed.
160
LinkProof User Guide Basic Application Switching 3. Set or view the parameters. 4. Click Set.
Physical Servers
Physical servers are hardware units configured to operate as an integral part of the network. Before setting up a physical server, you must connect the server to the LinkProof device at the hardware level. Once hardware connections are completed, you can start adding physical servers to the Logical Routers table or Logical FW (firewall) table. The parameters of the physical server are defined globally and are applied to all the farm servers that use the physical server.
To configure a physical server and/or view related statistics 1. Select LinkProof > Servers > Physical Servers Table. The Physical Servers Table pane is displayed. 2. Select the link to the required server. The Physical Servers Table Update pane is displayed. 3. Set or view the parameters. 4. Click Set.
Table 77: Physical Server Parameters
Parameter
Server Name
Description
The physical server name. The name defines the name of the farm servers group that are associated with this physical server. Adding a new server to a farm using a Server Name that was already defined in another farm implies that it is the same physical server. The value is read-only. The number of users currently connected to the server. The value is read-only. The maximum CPU load, in percent, at peak time. The value is read-only. Total number of frames at peak time. The value is read-only. The maximum number of Client Table entries that can run simultaneously on the physical server. This depends on farms Sessions Mode. When the limit is reached, new requests for service are no longer directed to this server. All open sessions are continued. When the Connection Limit parameter is configured to 0 (default), this mechanism is disabled for this physical server and there is no user number limit. When configuring the Connection Limit for the physical server, ensure that the Connection Limit in the farm servers with the same Server name is lower 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.
Connected Users Peak Load Frames Load Connection Limit
161
Parameter
Peak Kbps Load Recovery Time
Description
The maximum Kbit/s reported at peak time. The value is read-only. The time, in seconds, during which no data is sent to the physical server since the server recovers from a failure. When a servers operational status is changed from inactive to active (dynamically or administratively), the server is not eligible to receive clients for this period of time. Recovery Time applies to all servers in all farms that share the same Server Name. Once this time is reached, the server becomes eligible for receiving clients requests. Values: 010,000,000,000 Default: 0 Note: The value 0 (zero) specifies that the server is eligible immediately after changing operational status from inactive to active.
Warm-up Time
The time, in seconds, after the server is up, during which clients are slowly sent to this physical server in increasing rate, so that the server can reach its capacity gradually. LinkProof internally raises the weight of the server for this period of time, at the end of which the servers weight is the specified Weight. Default: 0Specifies that the server performs activation at full weight upon a change in operational status from inactive to active and after waiting the Recovery Time. Note: This option is not applicable for the farm servers in which the load balancing decision is made using the Cyclic Dispatch Method.
Kbps Rate Kbits Load Kbps Limit
Reported rate on the server. The value is read-only. Traffic, inbound and outbound, in Kbits to the server, in the last second. The value is read-only. The maximum traffic (in Kbit/s) that can be sent and received from the router. When the limit is reached, new requests for service are no longer directed to this router. All open sessions are continued, unless the Discard Flag is enabled.
Admin Status
Specifies whether the device uses the server. Values: EnabledThe server is active and ready to reply to new requests for service. ShutdownThe server cannot get new requests for service. The existing sessions are completed according to the Aging Time. Default: Enabled
In Kbps Rate
In Kbit/s. The value is read-only.
162
Parameter
In Kbits Load In Kbps Limit
Description
In load. The value is read-only. The maximum traffic (in Kbit/s) that can be received from the router. When the limit is reached, new requests for service are no longer directed to this router. All open sessions are continued.
Out Kbps Limit
The maximum traffic (in Kbit/s) that can be sent to the router. The value is read-only. When the limit is reached, new requests for service are no longer directed to this router. All open sessions are continued, unless the Discard Flag is enabled.
Out Kbps Rate Out Kbps Load Bandwidth Limit Exception
Out Kbit/s. The value is read-only. Out load. The value is read-only. Determines the device behavior when outbound or total bandwidth limits are reached for routers. Values: DisableNew sessions will not be allocated to this server, but existing sessions traffic will not be dropped. EnableTraffic will be dropped when bandwidth limit is exceeded.
Discarded Packets Number Billing mode
The number of discarded packets. The value is read-only. LinkProof supports multiple billing models for the Cost feature. You can define the billing model for each router. Values: InboundInbound bandwidth OutboundOutbound bandwidth TotalInbound plus outbound bandwidth Max(in\,out)Maximum between inbound and outbound bandwidth Default: Total
ToS
The ToS value for this router. Value ranges differ according to ToS. Values: 015For ToS. 07For precedence type. 255No ToS is required for the router. Default: 255
163
Cluster Servers
In some configurations, the routers or firewalls that LinkProof load balances are actually a cluster of servers. Examples of such configurations are: VRRP or HSRP router or firewall clusters Private firewall clusters WOC devices between LinkProof and the NHR (this is not a cluster, but the behavior of the MAC addresses is the same).
Potential Issues When Not Using Cluster Support

When outside traffic coming to a LinkProof server that is connected to a cluster is correctly forwarded to the MAC address that was received as a result of an ARP to that servers IP address, traffic coming from the cluster usually has, as its source MAC, the address of the physical server in the cluster that forwarded the traffic, and not the cluster servers address, thus potentially causing the traffic to be incorrectly redirected. This following diagram illustrates the problem. Two NHRs are defined on the LinkProof device: NHRA, which is a cluster, and NHRB. LinkProof recognizes MAC A as the MAC address of NHRA (it was discovered via ARP messages to IP A), but when traffic comes from NHRA, its source MAC is either MAC11, MAC 22, or MAC 33, depending on which physical router processed this traffic.
Figure 10: Potential Issues When Not Using Cluster Support

NHRAIP A; MAC A Router 1MAC 11 Router 2MAC 22 Router 3MAC 33 LinkProof
NHRBIP B; MAC B
Resolution of Cluster Traffic Issues with Cluster Support

The Cluster Support feature enables you to configure traffic going through clusters. You do this by associating the MAC address of an NHR cluster server to recognize traffic from a physical server within one of its clusters. You do this by creating an entry in the Cluster Servers Table that includes the NHR cluster IP address, and either an additional IP or MAC address associated with the cluster server. In the example shown in Figure 10 - Potential Issues When Not Using Cluster Support, page 164, using the Cluster Support feature you can configure MAC 11, MAC 22, and MAC 33 to be associated with server NHRA, enabling the device to recognize traffic with these MAC addresses as traffic from server NHRA. When LinkProof forwards traffic to the cluster server, it uses the destination MAC address that was discovered via an ARP to the logical server IP address (MAC A in the example). However, traffic coming from the cluster will be allocated to the cluster server if the source MAC or its IP is statically configured as belonging to this server.
164
LinkProof User Guide Basic Application Switching To configure a cluster server using an IP address, the MAC address must be set to 000000000000. To configure a cluster server using a MAC address, the IP address must be set to 0.0.0.0.
Notes: >> In many cases, you may not be required to load balance traffic to the cluster, but rather to perform NAT on the traffic to and from the cluster. In this case, the cluster needs to be configured as a LinkProof server (NHR or firewall). >> The LinkProof server IP should be the Virtual IP of the cluster or, in the case of WOC devices, the IP of the router beyond the WOC device. >> For Hot Standby Router Protocol (HSRP) clusters, where the virtual IP address cannot be the IP address of any of the cluster servers, you can configure the IP addresses of the cluster servers so that their MAC address will be discovered using ARP. This allows you to replace a server in a cluster without changing the LinkProof configuration (if the new server has the same IP address as the old one). >> For VRRP clusters where the virtual IP address is usually the IP address of one of the cluster servers, you can statically configure the MAC addresses of the cluster servers. >> For WOC devices, you need to statically configure the MAC address of the WOC device.
Adding an Entry to the Clusters Servers Table

Use the Clusters Servers Table pane to configure cluster servers. The pane displays a table with the following columns: Server Address Cluster Server Address MAC Address MAC Status
To add a new cluster servers table entry using CLI Enter the command lp servers cluster-servers.
To add a new cluster servers table entry using Web Based Management 1. Select LinkProof > Servers > Cluster Servers Table. The Clusters Servers Table pane is displayed. 2. Click Create. The Clusters Servers Table Create pane is displayed. 3. Configure the parameters; and then, click Set.
165
Table 78: Clusters Server Parameters
Parameter
Server Address MAC Address
Description
The IP address of the physical server. The physical server must be configured already on the device. The multicast MAC address for the cluster server. Note: For each NHR cluster server address, set either an additional IP or MAC address, but not both.
Cluster Server Address
The virtual IP address of the cluster server. Note: For each NHR cluster server address, set either an additional IP or MAC address, but not both.
Full Path Health Monitor

The Health Monitoring module enables extensive health monitoring of all network devices that are load balanced or managed by LinkProof. The module enables the device to load balance the network by making sure which network elements are available and active. Use the Full Health Monitor Table pane to do the following: View the status of farms and associated severs. Configure a health check for a server in the servers table. This configuration is identical to the configuration process in the Health Monitoring menu, only simplified to enable the Health Monitoring configuration directly using the Server Table pane.
The Full Health Monitor Table pane displays a table with the following columns: Farm Name Server Name Check Address Oprt Status
To configure the parameters of the Full Path Health Monitor 1. 2. Select LinkProof > Servers > Full Path Health Monitor Table. The Full Health Monitor Table pane is displayed. Configure the parameters; and then, click Set. The device IP is added to the table.
Table 79: Full Health Monitor Parameter
Parameter
Farm Name Server Name Check Address
Description
The relevant farm. The relevant server. The IP address of the remote device to check.
166
Server Statistics
Use the Servers Statistics pane to view the following statistics of each server configured on the device: s_nameThe server name f_nameThe farm name connectionsThe current number of connections on the server bytesThe number of bytes the server handled at the given moment acum_bytesThe total number of bytes the server handled since its creation
To view server statistics Select LinkProof > Servers > Statistics. The Servers Statistics pane is displayed.
Network Address Translation

NAT enables translation of an IP address used within one network to a different IP address known within another network. This section contains the following topics: Network Address Translation (SmartNAT), page 167 Dynamic NAT, page 168 Static NAT, page 169 No NAT, page 170 Basic NAT, page 170 One-IP-for-NAT Support, page 171 Static Port Address Translation (Static PAT or SPAT), page 172 NAT Parameters Summary and Miscellaneous Parameters, page 175
Network Address Translation (SmartNAT)

The main issue in a multihomed network is managing the IP addressing scheme for the different providers. There are two common possibilities that can be deployed with regard to the IP scheme that the internal network uses: A single IP network number is assigned to the internal networkRequires communication and cooperation between the two ISPs in order to advertise proper routes for this single IP network to the rest of the Internet. Also, care must be taken to ensure that both links are used for incoming traffic. If only a single ISP is used to deliver inbound traffic to the network, then part of the motivation and benefits of multihoming go unrealized. Each ISP assigns the internal network a different IP address rangeTherefore, two IP address ranges will be active at the same time for the internal network.
However there is an issue of what range to use for outbound traffic. If Range1 (assigned to the network by ISP1) is used and the link to ISP1 fails, there is no way for the response traffic to return to the network, since the world knows Range1 to be accessible only through ISP1. Furthermore, if only Range1 is used, the ISP2 link will never be used for inbound traffic, again since the world knows Range1 as accessible through ISP1. Also, there is the issue of what IP addresses to advertise to the
167
LinkProof User Guide Basic Application Switching world for inbound traffic. For example, if the network has a Web server that needs to be accessed from the world, which IP range would the Web server belong to? If it belongs to only one of the ranges, the Web server is inaccessible if the ISP responsible for that range loses its link to the network. If addresses from both ranges are advertised, then DNS failover and resiliency become additional factors that need to be addressed. For intelligent address management of traffic, LinkProof utilizes an algorithm called SmartNAT. To alleviate the outbound traffic problem, LinkProof will perform smart dynamic NAT. With this feature, LinkProof will have addresses from both ISPs address ranges available for translation. Then, when a router is selected to carry an outbound session, LinkProof will choose an IP address that is associated with that router/ISP. Therefore, if LinkProof chooses Router 1 as the router to deliver a session to the Internet, it will use an IP address of ISP1 as the translated source address. Likewise, if it chooses Router 2 as the router to deliver a session to the Internet, it will use a source IP address of ISP2. By choosing translated source IP addresses according to the chosen router, return delivery issues will not be encountered. SmartNAT not only encompasses dynamic IP address allocation and translation, but it also includes, for LinkProof, the ability to statically map internal resources to external IP addresses. Individual internal resources, such as servers, are mapped to multiple outside IP addresses (one from each ISP). Statically mapped IP addresses are used for inbound traffic, from the most available ISP link. The static mapping of SmartNAT also compensates transparently for ISP link failure. If an ISP link is down, only available IP addresses are used for inbound traffic. By making an inside resource available through all available ISPs, uptime is guaranteed for that internal resource. Permanent access to the resource is available through the most available ISP link. To configure NAT, you first configure the NAT tuning parameters; and then you configure the NAT addresses.
Notes: >> LinkProof performs NAT when forwarding traffic to farms for which NAT has been enabled (security and firewall farms only). NAT will be performed only for IP addresses that are found in the Smart NAT tables. >> LinkProof can perform a single NAT per session. >> For NAT tuning parameters, see Device Tuning, page 71.
Dynamic NAT
The Dynamic NAT feature enables LinkProof to hide various network elements located behind LinkProof. Using this feature, LinkProof replaces the original source IP and source port of a packet that is with the configured NAT IP and a dynamically allocated port before forwarding the request to the farm. The network elements whose addresses are translated can be servers or other local hosts. You can set different NAT addresses for different ranges of intercepted addresses. For example, traffic from subnet A is translated using IP address 10.1.1.1 and traffic from subnet B is translated using IP address 10.1.1.3.
To configure dynamic NAT 1. 2. 3. Select LinkProof > Smart NAT > Dynamic NAT. The Dynamic NAT Table pane is displayed. Click Create. The Dynamic NAT Table Create pane is displayed. Configure the parameters; and then, click Set.
168
Table 80: Dynamic NAT Parameters
Parameter
From Local IP To Local IP Server IP Dynamic NAT IP
Description
The lowest value in the range of IP addresses of the local server. The highest value in the range of IP addresses of the local server. The IP address of the farm server. These NAT addresses are used when traffic from local addresses is sent to this farm server. The NAT IP address to be used. The IP address of the device interface can be used for NHRs on the same subnet. Note: This mode cannot be used with a range of IP addresses for Dynamic NAT per NHR.
Redundancy Mode
Specifies whether the NAT address is regular or backup. The Active mode is for the active device and the Backup mode is for the backup device.
Static NAT
Use Static NAT is ensure delivery of specific traffic to a particular server on the internal network. For example, LinkProof uses Static NAT, meaning predefined addresses mapped to a single internal host, to load balance traffic to the host among multiple transparent traffic connections. This ensures that the return traffic uses the same path, and also allows traffic to that single host to use multiple ISPs transparently. You assign multiple Static Smart NAT addresses to the internal server, typically one for each ISP address range.
Note:
Static NAT addresses cannot be part of the Dynamic NAT IP pool.
To configure Static NAT 1. Select LinkProof > Smart NAT > Static NAT. The Static NAT Table pane is displayed. 2. Click Create. The Static NAT Table Create pane is displayed. 3. Configure the parameters; and then, click Set.
Table 81: Static NAT Parameters
Parameter
From Local IP To Local IP Server IP From Static NAT IP To Static NAT IP Redundancy Mode
Description
The lowest value in the range of local IP addresses. The highest value in the range of local IP addresses. The IP address of the farm server. The NAT address will be used when traffic from local addresses is sent to this farm server. The lowest value in the range of NAT addresses to be used when forwarding to the server address above. The highest value in the range of NAT addresses to be used when forwarding to the server address above. The redundancy mode can be either Backup or Active. The Active mode is for the active device and the Backup mode is for the backup device.
169
Excluding or Enabling Static NAT for the Local Network

Traffic from a local host for which Static NAT is configured undergoes NAT when forwarded to a farm for which NAT is enabled. Traffic to a local network is not translated. However, in certain cases, mainly for security purposes, Static NAT is required for traffic to a local network from the local host.
To enable Static NAT for traffic to the local network from the local host 1. 2. 3. Select LinkProof > Smart NAT > NAT Parameters Summary. The NAT Parameters Summary pane is displayed. From the Exclude Static NAT for Local Network drop-down list, select Disable. Click Set.
Enable Ping to Multiple Static NATs

A flag allows enabling or disabling simultaneous ping functionality to multiple Static NAT addresses belonging to the same Internet host.
No NAT
No NAT enables a simple configuration where internal hosts have IP addresses that belong to a range of one of the farm servers. Traffic to and from these hosts should not be translated if the traffic is forwarded to this farm server. If you do not configure any NAT address for a host via a farm server, that farm server will not be used by inbound traffic to that host if the host IP resolution is provided through DNS. To use a farm server for traffic from the host when NAT is not required, use the No NAT configuration.
To configure No NAT 1. 2. 3. Select LinkProof > Smart NAT > No NAT. The No NAT Table pane is displayed. Click Create. The No NAT Table Create pane is displayed. Configure the parameters; and then, click Set.
Table 82: No NAT Parameters
Parameter
From Local IP To Local IP Port Number
Description
The start of the range of local IP addresses. The end of the range of local IP addresses. The destination port for which traffic is not translated. For example, all traffic to destination port 80 is not translated. Destination port 0 refers to all the ports. The IP address of the farm server. These NAT addresses will be used when traffic from local addresses is sent to this farm server.
Server IP
Basic NAT
Basic NAT enables a one-to-one NAT mapping for occasional users, based on local IP ranges and destination applications. A pool of NAT addresses for each server is configured per range of local IP addresses and destination port. Whenever a client with an IP address within the range initiates a session to any host with the relevant application port, a NAT address is allocated to this session, and
170
LinkProof User Guide Basic Application Switching is used for all further sessions for the client with this application on this destination host. Basic NAT is useful for any application that requires source ports not to be translated, and therefore cannot be used when the clients IP address is translated using Dynamic NAT. Typically, the configured local IP range includes more hosts than the IP addresses allocated for Basic NAT for the same IP range. The latter indicates that any traffic from one of the hosts in the local IP range will be NATed (translated) using one of the Basic NAT addresses configured for this local IP range. This enables the use of a pool of Static NAT addresses, for a (larger) range of local IP addresses. The destination port can be configured to a specific application port, or to All ports. You can also configure how the LinkProof should behave if all Basic NAT addresses for the specified IP address range and application are occupied.
To configure Basic NAT 1. Select LinkProof > Smart NAT > Basic NAT. The Basic NAT Table pane is displayed. 2. Click Create. The Basic NAT Table Create pane is displayed. 3. Configure the parameters; and then, click Set.
Table 83: Basic NAT Parameters
Parameter
From Local IP To Local IP Port Number
Description
The range of local IP addresses. The range of local IP addresses. The destination port for which traffic is NATed. For example, if you specify 80, all traffic to destination port 80 is NATed. Destination port 0 refers to all the ports. The IP address of the farm server. These NAT addresses will be used when traffic from local addresses is sent to this farm server. The range of NAT addresses. The range of NAT addresses. The redundancy mode can be either Backup or Regular. The Active mode is for the active device and the Backup mode is for the backup device.
Server IP From Basic NAT IP To Basic NAT IP Redundancy Mode
One-IP-for-NAT Support
You can use the One-IP-for-NAT feature to reduce the number of public IP addresses used for LinkProof configurations. When One-IP-for-NAT is enabled, you can define Smart Dynamic NAT and IP addresses that are identical to the devices IP addresses. LinkProof registers all incoming and outgoing traffic to distinguish between management traffic, Health Monitoring, or Proximity, and forwarded traffic. It is possible to enable One-IP enabled on several IP interfaces and to disable OneIP on other interfaces. When One IP is enabled, the LinkProof device uses the interface addresses to perform Dynamic SmartNAT and hide the LAN segment behind the LinkProof device. When not using One-IP configurations for incoming traffic, Web services are configured for internal servers using Static NAT.
171
Caution: If the DNAT address is not equal to the associated IP address of the device, LinkProof creates an appropriate associated IP address for the DNAT entry. In a redundant configuration, when you delete the DNAT address of a backup device, LinkProof does not delete the associated IP address that was created automatically previously for the backup device. You must delete the IP address manually.
Smart NAT Using One-IP Configuration

LinkProof uses a set of predefined IP addresses. Each router connected to a LinkProof device needs two IP addresses. One, single IP address is used for the routers internal interface, and another IP address is used for the LinkProof interfaces themselves. For example, if a LinkProof device uses two IP addresses per router in a regular configuration and there are five routers, then 10 available IP addresses are required. In most LinkProof configurations, the IP addresses used for a configuration like this are public IP addresses. When using LinkProof with SmartNAT configurations, you must assign private IP addresses (according to RFC 1918) for the internal LAN segments behind the LinkProof device, using additional public IP addresses.
To configure Smart NAT with One-IP using Web Based Management 1. 2. 3. 4. Select Router > IP Router > Interface Parameters. The IP Router Interface Parameters pane is displayed. Click Create. The Interface Parameters Create pane is displayed. From the One Ip (Router Interface Only) field, select Enable or Disable. Click Set.
To configure Smart NAT with One-IP using CLI Enter the following command:
net ip-interface set <IP Address> -oi <enable|disable>

You are required to configure Dynamic NAT (DNAT) using the SmartNAT configuration. For information on how to configure DNAT, see Dynamic NAT, page 168.
Static Port Address Translation (Static PAT or SPAT)

Static Port Address Translation (Static PAT or SPAT) allows one-to-one mapping between local and global addresses. With Static PAT, multiple internal hosts can share a single IP address for communication, thus saving public IP address usage. Static PAT is actually a subset of NAT (RFC 2663), but it is usually referred to as Static PAT when discussing Port Forwarding. With Static PAT, you can configure static mapping of UDP or TCP ports of LinkProofs IP interface to the internal hosts ports.
172
LinkProof User Guide Basic Application Switching The following figure shows an example of Static PAT, where a client initiates a connection from the Internet towards the Web Server.
Figure 11: Example Static PAT
The following two tables describe the example Static PAT configuration.
Table 84: Client to Web Server Configuration Example
Destination IP
IP B (Public)
Destination Port Destination IP

80 (HTTP)
Destination Port
Action on Web Server

Replay to Client IP
Forward to IP 8080 (Internal) Private
Table 85: Web Server to Client Configuration Example
Destination IP
Destination Port Destination IP

IP B (Public)
Destination Port
80 (HTTP)
Action on Web Server

Continue Session
Client IP (Public) 8080
173
LinkProof User Guide Basic Application Switching The LinkProof device SPAT process of translates the source IP to the destination IP as well as from destination ports to other destination ports. Multiple internal hosts can be configured and also share a single IP address on different ports.
Note: The PAT & Dynamic NAT Port Table tuning parameter sets the limit for the highest possible port for SPAT (and DNAT). The default is 60534. This limit affects the SPAT port configured manually as well as Dynamic NAT allocated ports. The PAT & Dynamic NAT Port Table parameter is exposed in the Device Tuning Table pane (Server > Tuning > Device).
To configure static PAT 1. 2. 3. Select LinkProof > Smart NAT > Static PAT Table. The Static PAT Table pane is displayed. Click Create. The Static PAT Table Create pane is displayed. Configure the parameters; and then, click Set.
Table 86: Static PAT Table Parameters
Parameter
Static PAT Name Internal IP Internal Port Protocol Server IP External IP External Port Static PAT Mode
Description
Name used for identifying the PAT rule. The internal IP of the server. The internal port used by the server. The protocol type (TCP, UDP or ICMP). The IP of the external route. The IP of the external LinkProof interface. The external port that the LinkProof device listens to. Backup and Main is used for mirroring purposes and is defined in accordance with Smart NAT redundancy settings.
Management IP Considerations with SPAT

LinkProof supports management access to the device using the following protocols: TelnetTCP Port 23 SSHTCP port 22 WebTCP Port 80 SSLTCP Port 443 FTPTCP Port 21 SNMPTCP Port 161
174
LinkProof User Guide Basic Application Switching When the One-IP-for-NAT feature is enabled (see One-IP-for-NAT Support, page 171), the LinkProof IP address for management (its own IP) will be used for SPAT. This might create a conflict with the above services if they are also used for internal servers. If you try to use any ports in conflict with the above ports, then the following error message is issued:
Can not bind port 80: Port is bound to device WEB service (UDP or TCP). Change service port first
Notes: >> SPAT is supported with TCP, UDP, and ICMP. >> SPAT with One-IP-for-NAT is supported on TCP and UDP only. >> By design, SPAT is limited to one (1) server behind the SPAT device using a single port for a single service. Only a single public service with port 80 HTTP (for example) can be exposed per public IP address. In this way, an organization using PAT and a single IP cannot run more than one of the same type of public service behind a PAT (for example, two public web servers using the default port 80). >> VPN (IPsec) Pass-through with SPAT: In order to configure VPN traffic pass-through together with SPAT, you need to define a SPAT entry with UDP port 500 (IKE). The device will allow AH, ESP protocols to undergo SPAT and pass through the device as well. >> To resolve conflicting IP addresses, SmartNAT methods have been set according to priority and are set as follows: 1NoNAT 2SNAT 3SPAT 4DNAT So, for example, if you have configured an IP to be used in 1IP and SPAT and the same IP is displayed in a SNAT range, where inbound traffic is involved, the SNAT range will take precedence over SPAT. Outbound traffic, for this session, will only use SNAT.
NAT Parameters Summary and Miscellaneous Parameters

Use the NAT Parameters Summary pane to view all Smart NAT tables, create new entries and update existing entries, and specify whether Static NAT is used for traffic from the local host to the local network. By default, traffic from a local host for which Static NAT is configured undergoes NAT when forwarded to a farm for which NAT is enabled; but the traffic to the local network is not translated. That is, by default, the value in the Exclude Static NAT for Local Network drop-down list is Enable. In certain cases, mainly for security purposes, you may also require Static NAT for traffic to the local network from the local host.
To use Static NAT for traffic to the local network from the local host 1. Select LinkProof > Smart NAT > NAT Parameters Summary. The NAT Parameters Summary pane is displayed. 1. From the Exclude Static NAT for Local Network drop-down list, select Disable. 2. Click Set.
175
To have the device always translate the Static NAT destination to the local IP address 1. 1. 2. Select LinkProof > Smart NAT > NAT Parameters Summary. The NAT Parameters Summary pane is displayed. From the Always Translate Static Nat Destination To Local IP drop-down list, select Disable. Click Set.
To configure NAT features using the NAT Parameters Summary pane Select LinkProof > Smart NAT > NAT Parameters Summary. The NAT Parameters Summary pane is displayed. For information on the tables in the NAT Parameters Summary pane, see the following: Dynamic NAT, page 168 Static NAT, page 169 No NAT, page 170 Basic NAT, page 170 Static Port Address Translation (Static PAT or SPAT), page 172
Proximity
This section describes LinkProofs ability to detect network proximity and contains the following: Proximity Introduction, page 176 Proximity Configuration, page 177
Proximity Introduction
In todays Internet environment, providing quality content is only part of the issue. Delivering content to clients as quickly as possible is a critical factor for successful e-commerce initiatives. Delivering content along the path with the least latency can reduce download times. The importance of even a small increase in performance will contribute to user satisfaction, and can have significant impacts on user loyalty, enjoyment, and commerce. Radware offers both dynamic and static (administratively configurable) proximity mechanisms to meet Internet and intranet needs. The dynamic proximity detection mechanism measures the network proximity (both latency and hop count) between the clients mouse click all the way to the content located on the providers web servers. Only through such accurate measurement can content providers be sure that their users are receiving the quality of service necessary to compete in the fast paced Internet arena. In addition, by minimizing the hops and latency between the end users and the content, Radwares redirection mechanisms will reduce the traffic on the Internet backbones. Radwares Internet Traffic Management solutions deliver content to end users from the closest site or WAN link by utilizing this proximity detection mechanism in either global or multihomed Internet environments. To get accurate network proximity results, LinkProof uses several different proximity check methods capable of passing through any router and firewall.
176
LinkProof User Guide Basic Application Switching When an internal client attempts to reach a server on the Internet, it first approaches LinkProof, and a proximity check is performed through each of the routers. The results determine which one provides the best path to the server. When another client from the same network approaches the same server at a later time, the best link is already known, and the client is immediately forwarded via that router. Conversely, when an outside client wishes to contact an internal server, LinkProof checks the proximity through each of the links, and responds to the client with the NAT IP address of the router best suited to handle the traffic. The proximity probes are a combination of IP, TCP, and application Layer probes (such as TCP ACKs and ICMP Echo requests) to ensure accurate measurements. The type of checks used for proximity is configurable to allow users more control of the device and generate maximum performance from the links.
Notes: >> LinkProof can perform proximity checks through up to 10 routers. >> In the dynamic proximity table, only the best three (3) routers are recorded for each checked subnet.
Proximity Configuration
You can configure how the LinkProof uses proximity data.
Proximity Mode
LinkProof supports the following proximity modes: No ProximityLinkProof ignores proximity data. The dynamic auto learning mechanism is off. Static ProximityLinkProof forwards traffic using the best router according to a static proximity table configured by the user. The dynamic auto learning mechanism is off. Full Proximity InboundLinkProof forwards traffic using the best router according to the static proximity table, and will use dynamic auto learning to choose the best router only for inbound traffic, for subnets that are not defined as static entries. Full Proximity OutboundLinkProof forwards traffic using the best router according to the static proximity table, and will use dynamic auto learning to choose the best router only for outbound traffic, for subnets that are not defined as static entries. Full Proximity BothLinkProof forwards traffic using the best router according to the static proximity table, and will use dynamic auto learning to choose the best router for all traffic, for subnets that are not defined as static entries.
Proximity Checks
LinkProof enables the user to select the checks used for inbound and outbound proximity calculations. The device uses a proprietary proximity checks schemes in order to find dynamically the best router for a destination subnet. In some cases, different IDS (Intrusion Detection Systems) might consider the proximity check packets as attacks on devices located behind the IDS. For each proximity test, you can configure whether it should be used for Inbound Proximity, Outbound Proximity, Both, or None.
177
LinkProof User Guide Basic Application Switching LinkProof supports the following proximity tests: BasicA basic ping test typically used to check inbound traffic. AdvancedSimulates standard applications (using UDP traffic) and is useful for both inbound and outbound proximity checks. However, on occasion, IDS devices may consider such proximity check packets as an attack. Server SideSimulates a client of an application (sends TCP SYN packets) hence it is outbound traffic oriented. Client SideSimulates the server side of an application (sends TCP ACK packets), hence it is inbound traffic oriented.
You can also define the following parameters for all proximity checks: Check RetriesDefines the number of retries that are performed when the checked destination does not respond to the first attempt. Check IntervalDefines the time interval between consecutive retries in seconds.
Proximity Aging Period

Proximity Aging Period defines the amount of time in minutes that a dynamic auto-learned entry will be kept in the database. When this time is about to expire, LinkProof refreshes the information of that entry by re-executing the proximity checks.
Weights (Hops, Latency, Load)

You can define the emphasis that the device should put on the hops parameter and on the latency parameter when making a load balancing decision. In addition you can define the weight the router load should take in the load balancing definition together with the proximity parameters. The router load is calculated according to the Dispatch Method used, for example, the number of clients when using the least amount of users.
Note: The load weight is relevant only when the Farm Dispatch Method is set to Least Amount of Traffic, Least Number of Bytes or Least Number of Users.
Main and Backup DNS Addresses

To prevent the inefficient learning of requests that arrive from the local DNS server, LinkProof can be configured to ignore requests from specific addresses in the dynamic proximity mechanism. The addresses of the primary and backup local DNS servers can be configured.
Note: If the companys DNS server are placed at the Internet provider, the main and backup DNS server should belong to different ISPs. Only two (2) such DNS servers (main and backup) can be configured.
Proximity Subnet Mask

By default, LinkProof performs proximity checks for each class C subnet. This can be changed using this parameter. When this parameter is changed, the dynamic proximity database and statistics are cleared.
Using Grouping Decisions inside Proximity

If this parameter is set to Disabled (default is Enabled) it allows the load balancing mechanism to consider routers which were defined as backup to decide whether there is proximity data for a specific destination via this router.
178
LinkProof User Guide Basic Application Switching This functionality is required when some of your WAN links are restricted (for example domestic access only).
Setting General Proximity Parameters
To configure General Proximity parameters 1. Select LinkProof > Proximity > Proximity Parameters > General. The Proximity Parameters General pane is displayed. 2. Configure the parameters; and then, click Set.
Table 87: General Proximity Parameters
Parameter
Proximity Mode
Description
Defines the proximity mode. Values: No ProximityNo proximity is operated. Static ProximityThe device forwards traffic using the best next hop router according to the static proximity table (see below). The dynamic auto learning mechanism is off. Full Proximity InboundThe device forwards traffic using the best next hop router according to the static proximity table, and will use dynamic auto learning to choose the best router ONLY for inbound traffic, for subnets that are not defined as static entries. Full Proximity OutboundThe device forwards traffic using the best next hop router according to the static proximity table, and will use dynamic auto learning to choose the best router only for outbound traffic, for subnets that are not defined as static entries. Full Proximity BothThe device forwards traffic using the best next hop router according to the static proximity table, and will use dynamic auto learning to choose the best router for all traffic, for subnets that are not defined as static entries.
Main DNS
To prevent inefficient learning of requests that arrive from the local DNS server, configure LinkProof to ignore requests from specific addresses in the dynamic proximity mechanism. Enter the IP address of the local primary DNS server. Note: If the companys DNS servers are placed at the Internet provider, the main and backup DNS servers should belong to different ISPs. Only two such DNS servers (main and backup) can be configured.
Backup DNS
To prevent inefficient learning of requests that arrive from the local DNS server, configure LinkProof to ignore requests from specific addresses in the dynamic proximity mechanism. Enter the IP address of the local secondary DNS server. Note: If the company's DNS server are placed at the Internet provider, the main and backup DNS server should belong to different ISPs. Only 2 such DNS servers (main and backup) can be configured.
179
Table 87: General Proximity Parameters
Parameter
Proximity Aging Period
Description
Defines the amount of time in minutes that a dynamic auto learned entry will be kept in the database. When this time is about to expire, LinkProof may refresh the information of that entry by re-executing the proximity checks. Set this parameter to Disabled (default is Enabled) to allow the load balancing mechanism to consider NHRs that were defined as backup in the grouping tables. This determines whether there is proximity data for a specific destination via this NHR. This functionality is required when some of your WAN links are restricted (for example domestic access only). By default, LinkProof performs proximity checks for each class C subnet. Use this parameter to change this. When this parameter is changed the dynamic proximity database and statistics are cleared.
Use Router Mode decisions inside proximity
Proximity Subnet Mask
Setting Proximity Check Parameters
To configure Proximity Checks 1. 2. Select LinkProof > Proximity > Proximity Parameters > Proximity Checks. The Proximity Checks pane is displayed. Configure the parameters; and then, click Set.
Table 88: Proximity Check Parameters
Parameter
Basic Proximity Status
Description
This is a basic test typically used to check inbound traffic. Values: NoneThis check is disabled. Inbound ProximityThis check will be used to dynamically measure proximity for inbound requests only. Outbound ProximityThis check will be used to dynamically measure proximity for outbound requests only. BothThis check will be used to dynamically measure proximity for both inbound and outbound requests.
Advanced Proximity Status
This test simulates standard applications and is useful for both inbound and outbound proximity checks. However, on occasion, IDS devices may consider such proximity check packets as an attack. Values: NoneThis check is disabled. Inbound ProximityThis check will be used to dynamically measure proximity for inbound requests only. Outbound ProximityThis check will be used to dynamically measure proximity for outbound requests only. BothThis check will be used to dynamically measure proximity for both inbound and outbound requests.
180
Table 88: Proximity Check Parameters
Parameter
Server Side Proximity Status
Description
This test simulates a client of an application, hence it is outbound traffic oriented. Values: NoneThis check is disabled. Inbound ProximityThis check will be used to dynamically measure proximity for inbound requests only. Outbound Proximitythis check will be used to dynamically measure proximity for outbound requests only. BothThis check will be used to dynamically measure proximity for both inbound and outbound requests.
Client Side Proximity Status
This test simulates the server side of an application, hence it is inbound traffic oriented. Values: NoneThis check is disabled. Inbound ProximityThis check will be used to dynamically measure proximity for inbound requests only. Outbound ProximityThis check will be used to dynamically measure proximity for outbound requests only. BothThis check will be used to dynamically measure proximity for both inbound and outbound requests.
Check Retries
Defines the number of check retries with the client or the distributed sites during the proximity mechanism, when the client doesn't respond to the first check. Defines the time interval in seconds between consecutive retries.
Check Interval
Setting Static Proximity
To configure Static Proximity 1. Select LinkProof > Proximity > Static Proximity. The Static Proximity Table pane is displayed. 2. Click Create. The Static Proximity Table Create pane is displayed. 3. Configure the parameters; and then, click Set.
Table 89: Static Proximity Parameters
Parameter
From Address To Address NHR 1 NHR 2 NHR 3
Description
The IP address of the first destination in the range. The IP address of the last destination in the range. The IP address of the best next hop router. The IP address of the second best next hop router. The IP address of the third best next hop router.
181
DNS
This section describes the concept of DNS resolution for URLs in multihomed networks and how to incorporate this into your network with LinkProof. This section contains the following: DNS Introduction, page 182 Mapping URLs to Local IP Addresses, page 182 DNS Response Parameters, page 184 DNS for Local Users, page 185 DNS Redundancy, page 187
DNS Introduction
One of the main complications of the multihomed network is which IP address to use in the DNS space for a particular URL. To solve this problem and at the same time provide load balancing for inbound traffic, LinkProof can take control of particular URLs. To achieve this, LinkProof must become the authoritative name server for a particular URL through proper configuration in an organizations master DNS servers. This causes all DNS queries from the Internet for the particular URL to arrive at LinkProof. At the same time, multiple Static NAT addresses are assigned to LinkProof, all mapped to the IP address of the server hosting the particular URL. Each Static NAT address comes from one of the address ranges associated with each link. When LinkProof receives a DNS query asking it to resolve a particular URL to an IP address, it resolves the query to the Static NAT address corresponding to the best link available for the users request. This means different responses may be provided to different clients requesting the same URL.
Notes: >> LinkProof operates as an authoritative server for A records only. If LinkProof receives queries for other types of records, the device will answer that the record type is not supported. The device will answer with Authoritative Answer 0, which specifies that the responding name server is not an authority for the domain name in question. The return code is set to 0 (No error) meaning that the request was completed successfully. >> The device will answer a DNS query only if the URL specified in the query is configured on the device. If the URL is not configured, the device will not answer. >> When answering a DNS query, the device will select only those links with Static NAT, No NAT, or SPAT, which is defined for the local IP mapped to the requested URL.
Mapping URLs to Local IP Addresses

For LinkProof to provide load balancing of inbound traffic to internal servers, you must configure the following: Host-to-local-IP mappingThe supported URLs and the local IP addresses for the servers on which the URLs reside. LinkProof can map explicit host names to a local IP address (Host to Local IP) or dynamic host nameswildcard URLs (Dynamic Host to Local IP). The dynamic host names allow you to set a single definition for many similar URLs that are hosted on the same server. To help increase performance by using a more efficient search, use the URL to IP Search Mode parameter to define whether LinkProof searches for a URL in only one of the mapping tables or in both. Static NAT or No NATFor the local IP addresses via all available routers.
182
Configuring Host-to-Local-IP Mapping
To configure host-to-local-IP mapping 1. Select LinkProof > DNS Configuration > Name to Local IP. The Name To Local IP DNS Table pane is displayed. 1. Click Create. The Name To Local IP DNS Table Create pane is displayed. 2. Configure the parameters; and then, click Set.
Table 90: Name to Local IP DNS Parameters
Parameter
Host Name Local IP Address Farm Name
Description
The URL to be mapped. The IP address of the local host. The farm name in which the router with the Static NAT or Static PAT IP address resides. Optional. Default: None
Backup In DNS Response Indicates whether the device includes backup routers for a second reply to a DNS query. A second reply is not necessarily a backup server; the reply can also include the IP address of another active server. Values: Enable, Disable Default: Enable
Configuring Dynamic-Host-to-Local-IP Mapping
To configure dynamic-host-to-local-IP mapping 1. Select LinkProof > DNS Configuration > Dynamic Host Name to Local IP. The Dynamic Host Name to Local IP DNS Table pane is displayed. 2. Click Create. The Dynamic Host Name to Local IP DNS Table Create pane is displayed. 3. Configure the parameters; and then, click Set.
Table 91: Dynamic-Host-to-Local-IP Mapping Parameters
Parameter
Dynamic Host Name Local IP Address Index
Description
The URL with wildcards to be mapped. The IP address of the local host. The index number of this dynamic host name entry.
183
Table 91: Dynamic-Host-to-Local-IP Mapping Parameters
Parameter
Farm Name
Description
The farm name in which the router with the Static NAT or Static PAT IP address resides. Optional. Default: None Indicates whether the device includes backup routers for a second reply to a DNS query. A second reply is not necessarily a backup server; the reply can also include the IP address of another active server. Values: Enabled, Disabled Default: Enabled
Backup in DNS Response
DNS Response Parameters

DNS Response parameters include the following: Response TTLSpecifies the time to live of the DNS responses that are cached by clients. A high value means less DNS traffic, but the router from whose range the response IP was selected might become unavailable during this period. A low value provides higher availability of the internal server. The default setting is 0, which means the response is not cached. Two records in DNS ReplyWhen enabled, LinkProof answers with two A records (the Static IPs of the internal server via the two best routers); when not enabled, LinkProof answers with one A record. DNS Response ModeDetermines whether or not the device answers DNS queries according to SmartNAT status. In configurations where NAT is performed by the device positioned in front of LinkProof (access routers or firewall), the SmartNAT is not available. This means that the device will answer DNS queries with the internal servers local IP address. However, to be able to perform inbound load balancing, LinkProof must be able to answer DNS queries with public IP addresses (Static NAT). LinkProof can answer DNS queries according to the following criteria: According to SmartNat mode (default)Static NAT address if SmartNAT is enabled, otherwise, local IP address Always Local IP Address Always NAT IP address Static NAT address
To configure DNS response parameters 1. 2. Select LinkProof > DNS Configuration > Response. The DNS Response Parameters pane is displayed. Configure the parameters; and then, click Set.
184
Table 92: DNS Response Parameters
Parameter
DNS Response TTL Two Records in DNS Reply
Description
The number of seconds that DNS responses are cached. The default setting is 0, which means the response is not cached. Enables the return of two A records in the DNS response. Disable to return one record. Values: enable, disable Default: disable
URL to IP Search Mode
Defines how LinkProof handles DNS requests. Values: BothLinkProof searches for the requested URL first in the Name to IP Table, and if not found, then searches for the URL in the Variable Name to IP Table. Name to Local IPLinkProof searches for the requested URL in the Name to IP Table only. Dynamic Host Name To Local IPLinkProof searches for the requested URL in the Variable Name to IP Table only. Default: Both
DNS Response Mode
This parameter enables you to define whether the device will answer DNS queries according to SmartNat status or not. In configurations where NAT is performed by a device sitting in front of LinkProof (access routers or firewall), the SmartNAT is disabled, which means the device will answer DNS queries with internal servers local IP address. However, to perform inbound load balancing, LinkProof must be able to answer DNS queries with public IP addresses (static NAT). Values: According to SmartNat ModeStatic NAT address if SmartNAT is enabled, local IP address otherwise Always NAT IP AddressStatic NAT address Always Local IP Address Default: According to SmartNat Mode
DNS for Local Users

The DNS for Local Users feature provides a solution that enables you to provide DNS resolution for internal servers while using the same DNS server for both internal and external users. The problem with this configuration is that internal users need the host name to be resolved to the local IP address of the server, while external clients need the external IP for the server, but the DNS server cannot distinguish between internal and external users. DNS for Local Users functionality is not required in the following cases: Different DNS servers provide host name resolution for internal and external users. Communication between internal users and internal servers always passes via LinkProof (both ways).
185
LinkProof User Guide Basic Application Switching The solution implemented in LinkProof depends on whether the DNS server is located internally or externally.
Caution: The DNS for Local Users functionality is resource consuming, since the device has to scan all DNS responses. It should not be enabled if not required.
External DNS Server Configuration

When the DNS server is located outside the company network the DNS for local user functionality behaves as follows: The LinkProof is the authoritative DNS for the internal servers and resolves host name to public IP address (Static NAT). User, whether external or internal, queries the DNS server for host name resolution. DNS server requests LinkProof for address resolution and receives public IP address. It sends response to users. The response to internal users passes via LinkProof. LinkProof will intercept the DNS response with internal server resolution and replace public IP with local IP address. Thus internal users will be able to communicate with internal servers directly, via the local network. External clients receive the public IP from the DNS server and will be able to access the servers.
Internal DNS Server Configuration

When the DNS server is located inside the company network the DNS for local user functionality behaves as follows: The DNS server is the authoritative DNS for the internal servers and resolves host name to local IP address. Alternatively LinkProof can be an authoritative DNS. In this case DNS Response Mode should be set to Always Local IP address. User, whether external or internal, queries the DNS server for host name resolution. DNS server answers with local IP address. Response to external users passes via LinkProof. LinkProof intercepts the DNS response and replaces the local IP with a public IP address. Thus external users will be able to communicate with servers. Internal users receive the local IP from the DNS server and are able to communicate with internal servers directly, via the local network.
LinkProof can provide DNS for Local Users functionality for the following types of DNS messages: A record reply MX record reply PTR query and reply A record inverse queries and replies
The DNS for Local Users functionality is activated using the DNS Server Location parameter. By default, the value for the parameter is Not Relevant, meaning that this feature is not enabled. To activate this feature, set this parameter to either Internal or External, depending on where your DNS server is located. For increased performance it is recommended to configure the DNS servers for which this functionality is provided.
186
Configuring a DNS for Local Clients
To configure the location of the DNS for local clients 1. Select LinkProof > DNS Configuration > DNS for Local Clients. The DNS for Local Clients Parameters pane is displayed. 2. From the DNS Server Location drop-down list, choose the required option. Values: Not RelevantThe feature is disabled. InternalThe DNS server is the authoritative DNS for the internal servers and resolves host name to local IP address. Alternatively, LinkProof can be the authoritative DNS. In this case, DNS Response Mode should be set to Always Local IP address. The user, whether external or internal, queries the DNS server for host name resolution. DNS server answers with local IP address. Response to external users passes via LinkProof. LinkProof will intercept the DNS response and replace local IP with public IP address. Thus external users will be able to communicate with servers. Internal users will receive the local IP from the DNS server and will be able to communicate with internal servers directly, via the local network. ExternalThe LinkProof device is the authoritative DNS for the internal servers and resolves host name to public IP address (Static NAT). The user, whether external or internal, queries the DNS server for host name resolution. DNS server asks LinkProof for address resolution and receives public IP address. It sends response to users. The response to internal users will pass via LinkProof. LinkProof will intercept the DNS response with internal server resolution and replace public IP with local IP address. Thus, internal users will be able to communicate with internal servers directly, via the local network. External clients will receive the public IP from the DNS server and will be able to access the servers.
Default: Not Relevant 3. Click Set.
To configure an entry DNS Servers Table 1. Select LinkProof > DNS Configuration > DNS for Local Clients. The DNS for Local Clients Parameters pane is displayed. 2. Click Create. The DNS Servers Table Create pane is displayed. 3. In the DNS IP Address text box, type the IP address for the DNS server. 4. Click Set.
DNS Redundancy
To allow DNS requests to be handled smoothly and transparently by the redundant device when the main device is down, virtual DNS (VDNS) IP address must be configured for LinkProof redundant configuration. A virtual DNS address should be configured for each provider (router). The same address is configured on both devices.
Caution: The order of configuring virtual DNS is critical. First, you must configure the VDNS; and then, you associate an IP address with it.
187
To configure DNS redundancy 1. 2. 3. Select LinkProof > DNS Configuration > DNS Virtual IP. The DNS Virtual IP pane is displayed. Click Create. The DNS Virtual IP Create pane is displayed. Configure the parameters; and then, click Set.
Table 93: DNS Virtual IP Parameters
Parameter
DNS IP Address Mode
Description
The DNS address of the device. Specifies whether the DNS address represents a main (regular) or backup device.
Basic Load Balancing

This section provides some basic load-balancing configuration examples, which can be implemented without using flow definitions. This section includes the following: Simple Router Load Balancing Configuration, page 189 Simple Router Load Balancing Configuration With VLAN, page 190 Simple One-Leg (Lollipop) Configuration, page 191 Sandwich Configuration, page 192 Single Device Installation, page 193
188
Simple Router Load Balancing Configuration

The following diagram shows a configuration of simple router load balancing.
Figure 12: Simple Router Load Balancing Configuration
Router 1 NAT:100.1.1.21 for 10.1.1.30 via Router 1
Router 2 NAT:200.1.1.21 for 10.1.1.30 via Router 2
Interface 2
100.1.1.10 200.1.1.10
LinkProof
Interface 1 Internal Server 10.1.1.30
10.1.1.10
Local Network 10.1.1.x
189
Simple Router Load Balancing Configuration With VLAN

The following diagram shows a configuration of simple router load balancing in a VLAN environment.
Figure 13: Simple Router Configuration with VLAN
Router 1 NAT: 100.1.1.21 for 10.1.1.30 via Router 1
Router 2 NAT: 200.1.1.21 for 10.1.1.30 via Router 2
Interface 2
LinkProof Interface 1
Interface 3 200.1.1.10 100.1.1.10
Internal Server 10.1.1.30
190
Simple One-Leg (Lollipop) Configuration

The following diagram illustrates a simple configuration that does not require changing the network configuration.
Figure 14: Simple One-Leg (Lollipop) Firewall Configuration
Router 1 100.1.1.20
Router 2
NAT: 200.1.1.21 for 100.1.1.30 via Router 2
200.1.1.20 Interface 2 Interface 1 100.1.1.10 LinkProof 200.1.1.10
191
Sandwich Configuration
Firewall Sandwich is a generic description for a common network topology. The example in this section describes how you can easily configure LinkProof to support it. This configuration is typical when router load balancing as well as firewall load balancing (for both inbound and outbound traffic) is required. When Static NAT is used on the firewalls, a virtual IP address is created on the external LinkProof to ensure that different NAT addresses, on different firewalls, for a single internal host, are seen as a single public address. This provides load balancing and high availability between the NAT addresses. The following diagram illustrates a LinkProof sandwich configuration.
Figure 15: Sandwich Configuration
NAT: 100.1.1.21 For 30.1.1.11 VIP For Router 1 100.1.1 Interface 2 LinkProof 100.1.1.1 200.1.1.10
NAT: 200.1.1.21 For 30.1.1.11 VIP For Router 2 200.1.1
30.1.1.10 NAT: 30.1.1.30 for 10.1.1.30 Firewall 1 20.1.1.1 20.1.1.10 LinkProof 10.1.1.10 30.1.1.1 30.1.1.2 NAT: 30.1.1.31 For 10.1.1.30 Firewall 2 20.1.1.2
10.1.1.30
192
Single Device Installation

This scenario shows a single LinkProof device using the Port Rules functionality. The same functionality as in the previous example can be achieved with a single LinkProof device using the Port Rules functionality. In this configuration, two separate farms must be configured, one on the internal interfaces of the firewalls for outbound load balancing and one on the external interfaces of the firewalls for inbound load balancing.
Figure 16: Example Single Device Installation

Router 1 Local Network 10.1.1.x Interface 1 10.1.1.10 Interface 2 20.1.1.10 Firewall 1 20.1.1.1 30.1.1.1
LinkProof Interface 4 200.1.1.20 100.1.1.10 Interface 3 30.1.1.10 Router 2 100.1.1.20 200.1.1.20
Internal
External
20.1.1.2 Firewall 2
30.1.1.2
193
Load Balancing Weights

You can specify the weight you require to apply to each of the parameters that determine which NHR is selected in the load balancing decision.
To configure the load balancing weights 1. 2. Select LinkProof > Load Balancing Weights. The Load Balancing Weights pane is displayed. Configure the parameters; and then, click Set.
Table 94: Load Balancing Weight Parameters
Parameter
Hops Weight Latency Weight Load Weight Cost Weight
Description
The weight applied to the number of hops on the network link. The weight applied to latency on the network link. The weight applied to load on the network link. The weight applied to cost parameters on the network link.
Flow Management
This section describes the flow management process for LinkProof and describes the flow concept and flow policies and also some LinkProof configuration examples. This section contains the following topics: About Flows and Flow Management, page 194 Default Flow, page 195 Configuring Flow Management, page 195 Flow Policies, page 196 Typical Flow Configurations, page 199
About Flows and Flow Management

Traffic flow designed for a packet involves the following process: A packet arrives from the client, is examined by LinkProof, load balanced within a farm, returned from the selected server to LinkProof, examined again and load balanced within a different farm, and so on. LinkProof distinguishes between clients and servers even when the servers are using spoofing, by looking at the source MAC.
Multiple flows can be defined on a device for different types of traffic. To identify the traffic for each flow the Radware classification engine is used. Policies are defined to classify traffic and attach it to a specific flow. Any number of policies can be defined for each flow.
194
Figure 17: General Flow Management Scheme on LinkProof

Clients LinkProof Router Internet
Farm 1
Farm 2
Default Flow
The LinkProof device automatically creates a default flow that is used for traffic that does not match any flow policy. The default flow does not include any farm. When traffic that must be forwarded according to the default flow is detected, the device looks in the routing table for the default gateway. If the default gateway is a farm server, the default farm of this server is selected as the farm used by the default flow. Traffic is then forwarded to one of the servers in this farm according to the farm load balancing settings. If the default gateway is not a farm server, then traffic is just forwarded to this default gateway without any load balancing.
Configuring Flow Management
To configure flow management 1. Select LinkProof > Flow Management > Farms Flow Table. The Farms Flow Table pane is displayed. 2. Click Create. The Farms Flow Table Create pane is displayed. 3. Configure the parameters; and then, click Set. 4. To configure flow policies, click Modify Policies, and then, see the procedure in Configuring Flow Policies, page 197.
Table 95: Farms Flow Table Parameters
Parameter
Flow Name Farm Name Farm Index
Description
The flow name. The farm name. The Farm index. The device scans the policies according to their index, in ascending order, so it is important that policies that look for more specific traffic have a lower index. For example, a policy that looks for HTTP traffic from local network must have a lower index than policy that looks for any traffic from the local network.
195
Flow Policies
A flow policy defines the criteria used to select a specific flow for a specific type of traffic. When LinkProof handles a new session, the LinkProof device scans through the flow-policies list looking for a match. Once a match is found, LinkProof redirects the packet according to the flow associated with the policy. The device scans the policies according to their index, in ascending order, so it is important that policies that look for a more specific traffic have a lower index (for example, a policy that looks for HTTP traffic from local network must have a lower index than policy that looks for any traffic from the local network). The flow policies include the Traffic Classification Criteria and the selection of the farm for this type of traffic. The following classification criteria are available: Source and/or Destination IP AddressesIP address or a network class (IP subnets, IP ranges, or list of discrete IP addresses can be defined as a network class). For more information, see Bandwidth Management, page 311. ApplicationUsing the Service elements it is possible to define a required application according to application port and/or additional data (see Bandwidth Management, page 311).
Note: Although the Service classes that can be configured on the device allow for definition of Layer 7 criteria (for Bandwidth Management purposes), when used for traffic classification for flow management purposes, any criteria that is not found in the first packet of the session will be ignored during the classification process.
Note: In addition to the Service classes, you can use Discrete Networks.For more information, see Discrete Networks, page 344. Traffic DirectionDifferent flows can be applied to different traffic directions. The matched traffic depends not only on the value of the Traffic Direction parameter (One Way or Two Way), but also on whether the policy is searching for Layer 3 or Layer 4 sessions. For flow policies, the traffic flows through the LinkProof device according to the index of the flow policy. When traffic matches a rule, it flows through the LinkProof device according to that rule, and no other rule can apply to it. LinkProof uses the default rule for traffic that matches no rule. When the value of the Traffic Direction parameter is Two Way, LinkProof enforces the flow policy also on the return traffic.
Policy
Layer 3 Policy
One Way
Requests from policy source to destination and the related replies from destination. Request only from policy source IP and port to destination IP and port.
Two Way
All traffic between policy source and destination. Requests from policy source IP and port to destination IP and port and related replies from destination.
Layer 4 Policy
VLAN TagClassifies traffic according to VLAN identifier tags. Inbound Physical PortClassifies only traffic received on certain interfaces of the device.
196
Configuring Flow Policies
To configure a flow policy 1. Select LinkProof > Flow Management > Modify Policies. The Flow Management Modify Policies pane is displayed. 2. Click Create. The Flow Management Modify Policies Create pane is displayed. 3. Configure the parameters; and then, click Set.
Table 96: Flow Management Policies Parameters
Parameter
Name Index Destination Source Direction Description Service Type Service Operational Status
Description
The user-defined name of the policy. The index number of the policy. The destination address of the packet being matched by the policy. Note: The destination can be an IP address or a network class. The source address of the packet being matched by the policy. Note: The source can be an IP address or a network class. Values: One Way, Two Way A description of the policy. The type of service. Values: None, Basic Filter, AND Group, OR Group The name of the service required for this policy, based on the Service Type. The operational status of the policy. Values: Activewhen policies are updated, the device uses this policy. Inactivewhen policies are updated, the device does not use this policy. Note: Changing the value takes effect when you update policies (LinkProof > Flow Management > Update Policies).
Farm Flow Inbound Physical Port Group
The farm flow to which the policy is assigned. Enables setting different policies to identical traffic classes that are received on different interfaces of the device. This provides greater flexibility in configuration. For example, you can allow HTTP access to the main server only to traffic entering the device via physical interface 3. Note: First configure Port Groups. The VLAN tag group that you want to use. Marks the packet with a range of bits displayed in the drop-down list. This refers to Differentiated Services Code Point (DSCP) for Diffserv or ToS. Values: None, 163 Default: None
VLAN Tag Group Packet Marking
197
Viewing Active Flow Policies

You can view active flow policies, as well as configure new ones. You can modify and configure policies without affecting the current operation of the device. The changes do not take effect unless the inactive database is activated. The activation updates the active policy database. The table in the Flow Management View Active Policies includes the following columns: NameThe user-defined name of the policy. IndexThe index number of the policy. Farm FlowThe farm flow to which the policy is assigned. Last sec BW (Kbit)The number of kilobits that matched this policy in the last second. Last sec PacketsThe number of packets that matched this policy in the last second.
To view active flow policies 1. 2. Select LinkProof > Flow Management > View Active Policies. The Flow Management View Active Policies pane is displayed. Select the policy. The Flow Management View Active Policies pane is displayed.
Table 97: Flow Management View Active Policies Parameters
Parameter
Name Index Destination Source Direction Description Service Type Service Farm Flow Inbound Physical Port Group
Description
The user-defined name of the policy. The index number of the policy. The destination address of the packet being matched by the policy. Note: The destination can be an IP address or a network class. The source address of the packet being matched by the policy. Note: The source can be an IP address or a network class. The direction of the flow, One Way or Two Way. A description of the policy. The type of service. The name of the service required for this policy, based on the Service Type. The farm flow to which the policy is assigned. Enables setting different policies to identical traffic classes that are received on different interfaces of the device. This provides greater flexibility in configuration. For example, you can allow HTTP access to the main server only to traffic entering the device via physical interface 3. The VLAN tag group. Marks the packet with a range of bits displayed in the drop-down list. This refers to Differentiated Services Code Point (DSCP) for Diffserv or ToS.
VLAN Tag Group Packet Marking
198
Updating Flow Management Policies
To activate the latest changes 1. Select LinkProof > Flow Management > Update Policies. The Activate Latest Changes pane is displayed. 2. Click Set.
Typical Flow Configurations

It is often required to use different WAN links for different applications and/or destinations. In the following example there are two (2) routers. Router 1 is connected to a private network and can only connect to other corporate sites (Intranet). Router 2 is connected to the public network and can be used as a backup for the private link (with VPN) and also for access to the Internet. HTTP traffic on the Intranet must use the private link as long as it is available and only use the VPN link for backup. The other applications running on the Intranet can use both links (load balanced).
Figure 18: Flow LinkProof Example Application
Router 1 NAT: 100.1.1.21 for 10.1.1.30 via Router 1 100.1.1. 20 Interface 2
Router 2 NAT: 200.1.1.21 for 10.1.1.30 via Router 2 200.1.1.20 100.1.1.10 200.1.1.10
LinkProof Interface 1
199
Client Table
To efficiently handle the flow of traffic between the clients and the servers, LinkProof uses a Client Table. The Client Table stores client session information, which is necessary to maintain session persistency. This section contains the following topics: Client Table Mechanism, page 200 Managing Client Tables, page 203 Client-Table Logging, page 208 Viewing Client Table Entries Using CLI, page 215 Filtered Client Table, page 217 Clearing the Client Table Manually, page 217
Client Table Mechanism

When a client first approaches the device, LinkProof checks whether an entry for that client already exists in the Client Table. LinkProof automatically removes the relevant entries from the Client Table in the following cases: When one of the servers within a farm becomes unavailable. When the aging time of an entry expires. The Client Aging Time parameter is set per farm. If the Remove Entry at Session End option is enabled, when the session ends.
Note: You can clear the client table manually. If LinkProof finds the relevant entry in the Client Table, LinkProof directs the client session to the farms and servers that appear in the Client Table, In such a case, there is no need to make a load balancing decision. If LinkProof finds no relevant entry in the Client Table, LinkProof classifies the traffic to identify the flow that matches the traffic. LinkProof creates an entry in the Client Table indicating the sequence of farms the traffic must pass according to the selected flow. LinkProof selects a server for each farm in the flow, as the traffic reaches it, according to the load-balancing considerations that are defined by the Dispatch Method, and records it in the Client Table.
200
Example
The following two tables illustrate Client Table examples of an HTTP outbound session for the network shown in the figure below.
Table 98: Client Table Example A
Source Address
10.1.1.2
Destination Address
202.2.2.2
Source Port
1062
Destination Port
80
Flow
http flow
Table 99: Client Table Example B
Farm Name
fw_int_farm fw_ext_farm router_farm
Server Name Idx

fw1 fw1 router2 1 2 3
Type
Regular Regular N
Action Port #
Send to Farm Send to Farm Send to Farm
Ext Idx
16 17 18
Figure 19: HTTP Outbound Session Example Configuration

Router 1 Local Network 10.1.1.x Interface 1 10.1.1.10 Interface 2 20.1.1.10 Firewall 1 20.1.1.1 30.1.1.1
LinkProof Interface 4 200.1.1.20 100.1.1.10 Interface 3 30.1.1.10 Router 2 100.1.1.20 200.1.1.20
Internal
External
20.1.1.2 Firewall 2
30.1.1.2
201
LinkProof User Guide Basic Application Switching Each entry in the Client Table provides the following information: Session parameters (source address and port, destination address and port). Flow that matches this session. Information regarding each farm in the selected flow: Server selected for each farm. If this field is empty, it means that the session has not yet reached this farm, and server selection has not yet occurred. IDXthe index of the farm in the flow. If the session was only routed, the index value is 0. Action taken for this farm or Port Number for IDS and SSL farms. The following table lists the values for the action fields:
Parameter
Select Server Send to Farm Skip Farm Discard Passive Farm
Value
A server was not yet selected for this farm. A server was selected for this farm. This farm was bypassed. Packets are dropped when they reach this stage. A server farm was selected only for use of NAT; traffic is not forwarded to this server. This can occur when a Static NAT is performed for local traffic. A passive server was not yet selected. A virtual tunnel was selected. A virtual tunnel was selected when Virtual Tunneling is operating in Packet-per-packet mode.
Passive Select Select Tunnel Select Tunnel PBP
Type. A Client Entry can have the values listed in the following table:
Parameter
Regular V DN SN VPN Rglr VPN Prvt VPNVT CT RSN RNN
Value
No packet translation. Virtual IP translation. Dynamic NAT. Static NAT. Session is encrypted, Flow mode = Basic. Session is encrypted, Flow mode = Combined Private and VPN. Session is encrypted, Flow mode = VT. Virtual Tunneling NAT using Static NAT. Virtual Tunneling NAT using No NAT.
Ext IdxExtension index. When type is other than Regular, this index points to additional information regarding this session, such as address and port - used in address translation.
When a client first approaches LinkProof, LinkProof checks whether an entry for the client exists in the Client Table. If LinkProof finds an appropriate entry, LinkProof directs the client to the farms and servers that appear in the Client Table. In this case, there is no need to make a load balancing decision.
202
LinkProof User Guide Basic Application Switching If LinkProof determines that an entry does not exist, LinkProof classifies trafficto identify the flow that matches the traffic. LinkProof makes an entry in the Client Table, which indicates the sequence of farms this traffic must pass according to the selected flow. LinkProof selects a server for each farm in the flow, as the traffic reaches it, according to the load-balancing considerations defined by the Dispatch Method. LinkProof records this information in the Client Table.
Note: The farms for each Client Table entry are displayed in the order in which they were configured in the flow.
Managing Client Tables

This section describes managing Client Tables and contains the following: Configuring Client Table Global Parameters, page 203 Client Table Modes, page 204 Remove Entry at Session End, page 206 Client Table Tuning, page 207 Aging by Application, page 207
Configuring Client Table Global Parameters

This section describes configuring the global parameters for the Client Table. Client Table global parameters apply to the LinkProof device and affect all the farms defined on the device. There are separate sections for parameters and options that require lengthy descriptions.
To configure the global parameters for the Client Table 1. Select LinkProof > Global Configuration > Client Table > General. The Global Configuration - Client Table pane is displayed. 2. Configure the parameters; and then, click Set.
Table 100: Client Table Global Parameters
Parameter
Client Table Mode
Description
Indicates which layer of address information the device uses to categorize packets in the Client Table. Values: Layer 3For more information on this option, see Layer 3 Client Table Mode, page 204 Half Layer 4For more information on this option, see Half Layer 4 Client Table Mode, page 205 Full Layer 4For more information on this option, see Full Layer 4 Client Table Mode, page 205 Default: Full Layer 4
Remove Entry at Session End
When enabled, client entries are immediately removed from the Client Table when the client session ends. Values: enable, disable Default: disable
203
Table 100: Client Table Global Parameters
Parameter
Session Limit per Hash Entry
Description
Specifies a limit on the number of sessions associated with a hash entry in the Client Table (to maintain optimal performance). The value 0 (zero) indicates no limit. For maximum performance, LinkProof uses a hash algorithm to search for a Client Table entry. The hash function is applied on the session identification parameters, as determined by the Client Table Mode. Multiple Client Table entries can be associated with the same hash entry, especially in Layer 4 modes. As having unlimited sessions associated to the same hash entry causes performance degradation, this parameter enables you to limit this number and maintain optimal performance. Default: 0
Delayed Bind Timeout
The time, in seconds, that the device waits for completion of TCP handshake. Default: 10 Specifies whether the device removes the clients for other servers in farms to load balance correctly when the Hashing Dispatch Method is configured. Typically, when the Hashing Dispatch Method is configured, and one of servers becomes enabled, the device needs to remove all clients for other servers in the farm in order to load balance correctly. Values: enable, disable Default: enable
Remove Alternative Server Clients in Hashing
Server Selection Override
Specifies whether a server can be changed after the loadbalancing selection. For example, it is possible the load-balancing decision chooses server 1, and the reply comes from server 2. Values: enable, disable Default: disable
Client Table Modes

LinkProof supports the following Client Table modes: Layer 3 Client Table Mode, page 204 Half Layer 4 Client Table Mode, page 205 Full Layer 4 Client Table Mode, page 205
Note: 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 LinkProof device.
Layer 3 Client Table Mode

In Layer 3 mode, each entry is identified by the following parameters: Source IP address Destination IP address
204
LinkProof User Guide Basic Application Switching In Layer 3 mode, all sessions between the same source and destination addresses are represented by a single Client Table entry and are forwarded to the same farm servers. LinkProof performs the search using source and destination IP address only. The protocol that is displayed will be the first protocol that initiated the session (for example, ICMP).
Half Layer 4 Client Table Mode

In Half Layer 4 mode, each entry is identified by the following parameters: Source IP address Destination IP address Destination port
In Half Layer 4 mode, all the sessions destined to the same address and port are represented by a single entry in the Client Table, regardless of the source port/s. For example, in a simple Web page retrieval, a client may open several TCP sessions with the server, using each session to transfer different parts of the page, such as text, GIF files, and so on. All of these sessions, identified by Destination port 80 and different Source ports, constitute a single entry in the Client Table. LinkProof performs the search using source and destination IP addresses, protocol, and destination port only. The source port displayed in the Client Table will be the first source port that initiated the session. Half Layer 4 mode is the minimum mode required whenever sessions to different destination ports must be tracked separatelyfor example: When different flows are configured for different applications When farms of proxy servers are defined on the device (using the VIP option of Packet Translation parameter)
Full Layer 4 Client Table Mode

In Full Layer 4 mode, each entry is identified by the following parameters: Source IP address Destination IP address Source port Destination port
In Full Layer 4 mode, a new entry is added to the Client Table for every session opened between the client and the server. For example, in the above example of a simple page retrieval, each of these sessions, identified by Destination port 80 and a unique Source port, such as 1234, 1235, 1236 and so on, constitute a new entry in the Client Table. Full Layer 4 mode is required when: NAT is enabled in any of the farms. Content-based load balancing is configured on the device. SYN Flood protection mechanism is enabled. Port Hashing is enabled.
205
Remove Entry at Session End

The Remove Entry at Session End mode allows LinkProof to remove entries from the Client Table before the Aging Time expires. This mode is used to clear entries representing the TCP sessions that were closed before the end of the Aging Time period.
Note: Because the Client Aging Time is configured per farm, to determine the Client Table entry aging time, LinkProof looks at the aging times of all the farms in the entrys flow and selects the longest period.
Tip: Removing entries from the Client Table immediately when the TCP session is closed frees the memory resources for the active sessions and therefore improves memory utilization. When the Remove Entry at Session End option is enabled, LinkProof behaves as follows: When LinkProof detects a RST or FIN packet between the source and the destination LinkProof marks the entry for deletion from the Client Table, as the RST/FIN packets indicate that the session is closed. The entry is aged in five seconds and subsequently removed.
Port Hashing
The Port Hashing option, when enabled, determines which source and destination ports are to be taken into consideration. When the Hashing Dispatch Method is selected and the Port Hashing option is enabled, LinkProof selects a server for a session using a hash function. This is a static method where the NHR is chosen for a session purely by the session information. The input for the hash function is source and destination IP addresses.
Note: You can enable the Port Hashing option only when Client Table Mode is Full Layer 4 (LinkProof > Global Configuration > Client Table > General > Client Table Mode). Port Hashing accelerates device performance and reduces memory consumption. Port Hashing is available only with the Full Layer 4 Client Mode. Port Hashing is enabled by default. Therefore, by default, all entries in L4 Full are presented by the L4 entries in the Client Table and are hashed accordingly. LinkProof manages Client Table entries according to Source IP, Destination IP, Source Port, and Destination Port. LinkProof distinguishes between two options: Client Table mode and hash function. LinkProof does the hash function on the Client Table entry to shorten the search time.
206
LinkProof User Guide Basic Application Switching The following table describes the various Client Table Modes and the hashing.
Table 101: Client Modes and Hashing
Client [Table] Mode
Client Table Information that LinkProof Uses
Layer on Which LinkProof Does Hashing

L3 Destination Port L3 L3 L4
Layer 3 Half Layer 4 Full Layer 4 Full Layer 4 + Port Hashing enabled
Source IP Source IP Source IP Source IP
Destination IP Destination IP Destination IP Destination IP Source Port Source Port
Destination Port Destination Port
Client Table Tuning

When setting the Client table size you must also configure Client Extension Table size. The relationship between the two table sizes is a MIB relationship, which is: ClientExtensionTableSize = MaxNumberOfFarmsInAFlowAsConfiguredOnTheDevice ClientTableSize For example, if LinkProof load balances routers only, the Client Table Extension size should be the same as the Client Table Size. For information on tuning procedure, see Tuning Device Table Parameters, page 75.
Aging by Application
You can assign different applications different client lifetimes. Since applications are identified by the ports they use, you assign application aging times by configuring aging times for specific ports. For example, you can assign FTP longer aging times and HTTP shorter ones. You can configure application-aging times for applications over TCP and UDP protocols. For applications not included in the UDP and TCP protocols (for example, ICMP), use port 0. Any applications for which you do not assign an aging time will age according to the farm configuration.
Note: Aging per application is available only if Client Table mode is Half Layer 4 or Full Half Layer 4.
To configure aging by application 1. Select LinkProof > Global Configuration > Client Table > Aging by Application Port. The Aging By Application Port pane is displayed. 2. Click Create. The Aging by Application Port Create pane is displayed. 3. Configure the parameters; and then, click Set.
207
Table 102: Aging by Application Port Parameters
Parameter
Application Port Aging Time
Description
The application port for which to configure the aging time. The duration, in seconds, of the device stores a client entry from this application port before removing it from the Client table. This parameter takes precedence over the Client Aging Time of the farm for the specific application. Values: 565534 Default: 60
Client-Table Logging
LinkProof can log Client Table data to the following: Files on the platforms hard diskYou can retrieve the files from the hard disk using FTP. The hard-disk Client-Table logging mechanism manages Client-Table data according to userconfigurable hard-disk management and log-file management parameters. A syslog serverLinkProof can log Client Table data to a syslog servernot a snapshot. A snapshot file on the platforms hard diskA LinkProof device can write a snapshot (that is, a copy) of the Client Table data in memory directly to the hard diskeven when the hard-disk logging feature is not enabled.
Using the information that the Client-Table logging feature provides, you can, for example, associate an IP address with a destination, or know the time a specific IP address accessed an Internet site and with which NAT IP. In addition, this feature is a powerful debugging tool.
Client-Table Log-File Directory

LinkProof writes Client-Table data to files under /hdd0:/Reporting_Log. You can retrieve Client Table files from the hard disk using FTP.
Client-Table Log-File Format

The hard-disk Client-Table logging mechanism writes data to text files in CSV ASCII format. The mechanism names closed files <yyyyMMdd>_<hhmm>_<ss>.txt for example, 20081207_1713_54.txt. The mechanism names temporary files <yyyyMMdd>_<hhmm>_<ss>_tmp.txt for example, 20081207_1713_54_tmp.txt.
208
LinkProof User Guide Basic Application Switching The files includes the following fields: Start TimeMarks the entry of the start of the client session in dd/MM/yyyy hh:mm format. End TimeMarks the entry of the last activity of the entry in dd/MM/yyyy hh:mm format. Source IP addressThe source where the connection is coming from. Destination IP addressThe destination where the connection is going to. Router/FirewallWhich gateway IP was used by the LinkProof device to access the Internet or WAN. ProtocolThe protocol used in the packet (according to RFC 5237), for example, FRAG, ICMP, IGMP, UDP, TCP OSPF, and so on. Source PortThe port that was requested internally. Destination PortThe port that was requested on the destination address. NAT AddressThe NAT address given by the LinkProof device. NAT TypeThe NAT type given by the LinkProof device. BytesThe number of bytes that have passed since the entry was opened in the Client Table.
Note: The file includes no header row (with the column names).
Example Client Table (as exported to a spreadsheet to enable better parsing and analysis) Table 103: Example Client Table
Start Time 07/12/2008 23:40 End Time Source IP 192.168.100.2 Dest. IP 6.6.6.200 Router 0.0.0.0 Protocol Type. TCP Source Dest. Port Port 1024 80 NAT Address NAT Type Bytes 71
241.226.144.124 OTHER
Hard-Disk Management and Log-File Management

The hard-disk Client-Table logging mechanism manages Client-Table data according to userconfigurable hard-disk management and log-file management parameters.
Notes: >> Hard-disk failure does not affect the principal LinkProof functionality. >> If the hard disk cannot perform the logging operations, the device sends an error message and issues an SNMP trap.
To configure the hard-disk management and log-file management parameters using CLI Modify the default values as required using the commands described in the following list.
209
LinkProof User Guide Basic Application Switching LinkProof exposes the following CLI commands for hard-disk management and log-file management:
services hard-disk logging-priority set {full|best effort}

The priority of the hard-disk Client-Table logging to manage CPU load. Equivalent parameter in Web Based Management: Logging Priority Values: Best EffortLower CPU priority. If the CPU has other tasks to perform, logging receives a lower priority. FULLLogging gets a high priority. The device logs everything, ignoring any performance impact.
Default: Best Effort Example:
services hard-disk logging-priority set best effort services hard-disk log-file-size set <Value>
The maximum size, in megabytes, of the Client-Table log files. Equivalent parameter in Web Based Management: Log File Size (MB) Values: 5250 Default: 100 Example:
services hard-disk log-file-size set 100 services hard-disk log-file-time set {1|12|24}
The number of hours the temporary file will stay open. The device will close the temporary file when this time elapses even if the file size is smaller than the specified Log File Size. Equivalent parameter in Web Based Management: Log File Open Time Values: 1, 12, 24 Default: 24 Example:
services hard-disk log-file-time set 24 services hard-disk log-switch set Switch Now
Immediately closes the temporary file regardless of the specified Log File Size and Log File Open Time. Equivalent parameter in Web Based Management: Log Switch
services hard-disk log-behavior set {Stop Logging|CYCLIC FIFO}

What the device does when there is no more space for Client-Table log data. Equivalent parameter in Web Based Management: Log Files Write Mechanism Values: CYCLIC FIFOThe device overwrites the oldest log file in the log directory. Stop LoggingThe device stops all logging activity until the hard-disk space issue is resolved.
Default: CYCLIC FIFO Example:
services hard-disk log-behavior set CYCLIC FIFO services hard-disk log-purge Purge now
Immediately purges the entire Client-Table log-file directory. Equivalent parameter in Web Based Management: Log File Purge
210
services hard-disk total-size

Displays the size, in megabytes, of the hard disk. Equivalent parameter in Web Based Management: Local Hard Disk Size
services hard-disk free-size

Displays the size, in megabytes, of the free space on the hard disk. Equivalent parameter in Web Based Management: Available Free Disk Space
services hard-disk set free-size-save {<Value>|<Value> MB|<Value> %>

The amount of space that the hard disk will keep free (high-water mark). Equivalent parameter in Web Based Management: Disk Space to Keep Free Values: Any value, in megabytes, between 0.002 and 99.8 percent the size of the hard disk. Any value with a percent sign (%) between 0.002 and 99.8.
Default: 1500 MB Example:
services hard-disk free-size-saved set 1500.00 MB Table 104: CLI Commands for Hard-Disk Management and Log-File Management
Parameter
Logging Priority
Description
Command
The priority of the hard-disk Client- services hard-disk loggingTable logging to manage CPU load. priority set {full|best effort} Values: Example: Best EffortLower CPU priority. If the CPU has other tasks to perform, logging receives a lower priority. FULLLogging gets a high priority. The device logs everything ignoring any performance impact. Default: Best Effort
services hard-disk loggingpriority set best effort
Log File Size (MB)
The maximum size, in megabytes, of the Client-Table log files. Values: 5250 Default: 100
services hard-disk log-file-size set <Value>

Example:
services hard-disk log-file-size set 100 services hard-disk log-file-time set {1|12|24}
Example:
Log File Open Time
The number of hours the temporary file will stay open. The device will close the temporary file when this time elapses even if the file size is smaller than the specified Log File Size. Values: 1, 12, 24 Default: 24
services hard-disk log-file-time set 24
Log Switch
Immediately closes the temporary file regardless of the specified Log File Size and Log File Open Time.
services hard-disk log-switch set Switch Now
211
Table 104: CLI Commands for Hard-Disk Management and Log-File Management
Parameter
Log Files Write Mechanism
Description
Command
What the device does when there is services hard-disk log-behavior set no more space for Client-Table log {Stop Logging|CYCLIC FIFO} data. Example: Values: services hard-disk log-behavior set CYCLIC FIFOThe device overwrites the oldest log file in the log directory. Stop LoggingThe device stops all logging activity until the hard-disk space issue is resolved. Default: CYCLIC FIFO
CYCLIC FIFO
Log File Purge Local Hard Disk Size (MB) Available Free Disk Space Disk Space to Keep Free
Immediately purges the entire Client-Table log-file directory.
services hard-disk log-purge Purge now
Displays the size, in megabytes, of services hard-disk total-size the hard disk. Displays the size, in megabytes, of services hard-disk free-size the free space on the hard disk. The amount of space that the hard services hard-disk set free-size-save disk will keep free (high-water {<Value>|<Value> MB|<Value> %> mark). Example: Values: services hard-disk free-size Any value, in megabytes, between 0.002 and 99.8 percent the size of the hard disk. Any value with a percent sign (%) between 0.002 and 99.8. Default: 1500 MB
saved set 1500.00 MB
To configure the hard-disk management and log-file management parameters using Web Based Management 1. 2. Select Services > Hard Disk. The Hard Disk Logging Management pane is displayed. Configure the parameters; and then, click Set.
212
Table 105: Hard Disk Logging Management Parameters
Parameter
Logging Priority
Description
The priority of the hard-disk Client-Table logging to manage CPU load. Values: Best EffortLower CPU priority. If the CPU has other tasks to perform, logging receives a lower priority. FullLogging gets a high priority. The device logs everything, ignoring any performance impact. Default: Best Effort
Log File Size (MB)
The maximum size, in megabytes, of the Client-Table log files. Values: 5250 Default: 100
Log File Open Time
How long the temporary file will stay open. The device will close the temporary file when this time elapses even if the file size is smaller than the specified Log File Size. Values: 1 hour, 12 hours, 24 hours Default: 24 hours
Log Switch
Enables immediate closing of a temporary file regardless of the specified Log File Size and Log File Open Time. Values: No Switch, Switch now Default: No Switch
Log Files Write Mechanism
What the device does when there is no more space for Client-Table log data. Values: CYCLIC FIFOThe device overwrites the oldest log file in the log directory. Stop LoggingThe device stops all logging activity until the hard-disk space issue is resolved. Default: CYCLIC FIFO
Log File Purge
Enables an immediate purge of the entire Client-Table log-file directory. Values: No purge, Purge now Default: No purge
Local Hard Disk Size Available Free Disk Space Disk Space to Keep Free
The size, in megabytes, of the hard disk. This value is read only. The size, in megabytes, of the free space on the hard disk. This value is read only. The amount of space that the hard disk will keep free (high water mark). Values: Any value, in megabytes, between 0.002 and 99.8 percent the size of the hard disk. Any value with a percent sign (%) between 0.002 and 99.8. Default: 1500 MB
213
Client-Table Reporting
Caution: Enabling the Hard-Disk Client-Table Logging feature may negatively impact performance significantly. For more information, please refer to the performance report. The device can export Client-Table data to a syslog server. To export Client-Table data to a syslog server, a syslog server must be configured for the device (Services > Syslog Reporting). A LinkProof device can write a snapshot (that is, a copy) of the Client Table in the LinkProof device RAM directly to the hard diskeven when the hard-disk logging feature is not enabled.
To enable or disable hard-disk client-table logging using CLI Enter the following command:
reporting client-table hard-disk set {enable|disable}
To enable or disable export Client-Table data to the syslog server using CLI Enter the following command:
reporting client-table syslog set {enable|disable}
To enable or disable hard-disk client-table logging and export of Client-Table data to the syslog server using Web Based Management 1. 2. Select Reporting > Clients > Parameters. The Reporting Clients Parameters pane is displayed. Do the following: From the Hard Disk Logging Mechanism drop-down list, select Enable or Disable as required. From the Syslog Logging Mechanism drop-down list, select Enable or Disable as required. To trigger a Client Table snapshot, from the Client Table Snapshot drop-down list, select Write now. When you click Set, the device writes the Client Table from RAM to disk, and the Client Table Snapshot drop-down list reverts to No write. You can retrieve the snapshot using FTP from the device file system.
3.
Click Set.
214
Viewing Client Table Entries Using CLI
To view the current entries of the Client Table Use the following commands:
lp client table to see Client Table information. lp client table-summary to see summary information.
The following options are available with the lp client table CLI command, which enable you to filter existing client entries and display only relevant entries:
-ip Print only entries with given IP address. -fl Print only entries with given flow name. -fn Print only entries with given farm name. -sn Print only entries with given server name. -vl Print only entries with forwarding type bridging. -ap Print only entries with given application port. -db Print only entries with delayed-bind information. -ed Print only entries with edge farm information. -mapped Print entries including mapped information. -ptr Print only entries with given packet translation type (VIP, Dynamic NAT, VPN, and so on)
Client Table View Filters

You can configure up to five different filters to view the types of information that the Client Table of the LinkProof device stores. Use the View Filters pane to configure the filters. 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 a Client Table filter 1. Select LinkProof > Clients > View Filters. The View Filters pane is displayed. The table comprises the following columns: Index Source IP From Destination IP From Destination Port From Status
2. Click Create. The View Filters Create pane is displayed. 3. Configure the parameters; and then, click Set.
215
Table 106: View Filter Parameters
Parameter
Index Status
Description
The Filter Index number that is currently selected. Values: 15 Specifies whether the filter is active or inactive. Values: Active, Inactive Default: Active
Source IP From Source IP To Destination IP From Destination IP To Source Port From
The start of the range of the clients addresses. The end of the range of the clients addresses. The start of the range of the addresses of the servers that provide the requested service. The end of the range of the addresses of the servers that provide the requested service. The start of the range of the source port numbers for the protocol. For example, for HTTP, the protocol would be configured as TCP and the port as 80. The end of the range of the source port numbers for the protocol. For example, for HTTP, the protocol would be configured as TCP and the port as 80. The start of the range of the destination port numbers for the protocol. For example, for HTTP, the protocol would be configured as TCP and the port as 80. The start of the range of the destination port numbers for the protocol. For example, for HTTP, the protocol would be configured as TCP and the destination port as 80. The IP address of the next-hop router. Client Types are unique to LinkProof. The CT (Client Type) value is case sensitive, and must use the exact phrases as they appear in the list. Values: anyAny client type. regularAny client of the type Regular. dynamicNatAny client receiving an dynamic NAT address. basicNatAny client receiving a NAT address from Basic NAT. virtualIPAny client destined for a virtual IP address on the device. staticNATAny client receiving a NAT address from Basic NAT. staticPAT no natAny client matching the configured NoNAT addresses. vpnAny client matching VPN policy. remoteNatStaticNatAny client matching Virtual Tunneling Policy with Static NAT address policy. remoteNatNoNatAny client matching Virtual Tunneling Policy with No NAT address policy.
Source Port To
Destination Port From
Destination Port To
Next Hop Router IP Client Types
216
Table 106: View Filter Parameters
Parameter
Action
Description
The filter action. Values: No Action Delete All Matching Count All Matching
VIP Type
The type of virtual IP the filter uses. Values: anyAny VIP. VIPThe specified IP address. DisableThe filter does not filter according to VIP.
Filtered Client Table

The Client Table stores a lot of information, which makes it very difficult to view such tables, since they may become very heavy. To generate reliable and useful reports and to avoid system failures, you can use various filters for presenting information in the Client Table.
To view the filtered Client Table 1. Select LinkProof > Clients > Filtered Client Table. The Filtered Client Table pane is displayed. The table comprises the following columns:
Parameter
Source Address Client Address Destination Address Source Port Destination Port
Description
The IP address of the source. The IP address of the client. The IP address of the destination. The source port of the client. The destination port of the client.
Clearing the Client Table Manually

Use the Clear Client Table pane to clear the Client Table.
To clear the Client Table manually 1. Select LinkProof > Clients > Clear Client Table. The Clear Client Table pane is displayed. 2. From the Clear Client Table drop-down list, select Clear. 3. Click Set.
217
VPN Load Balancing

When supporting advanced firewall configurations, there are special considerations with regards to the way the traffic flows. VPN load balancing as described in this section is supported only on the OnDemand Switch 2 and 3 platforms. This section contains the following topics: Network Topology with LinkProof Devices Through Firewalls, page 218 Multicast Dispatch, page 219 Clear Client Table (VPN Load Balancing Feature), page 220 Client Table Overwrite, page 222
Network Topology with LinkProof Devices Through Firewalls

The following diagram shows a network topology called a Firewall Sandwich. This topology reflects the inbound and outbound traffic flow as it is routed by the LinkProof devices through firewalls.
Figure 20: Firewall Sandwich Topology
Network Session Starting from Headquarters to Branch

In this case, traffic returning from the branch uses the same path. If a new traffic session originates from the branch to the headquarters, the same VPN server tunnel must be used as the one used previously by the traffic coming from the headquarters to the branch.
218
LinkProof User Guide Basic Application Switching The traffic flow is as follows: Router LAN A, Second LinkProof, VPN gateway 1, First LinkProof, VPN gateway 3, Branch LAN.
Network Session Starting from Branch to Headquarters

In this case, traffic returning from the headquarters will use the same path. If a new traffic session originates from the headquarters to the branch, the traffic should use the same VPN server tunnel as the one used before by the traffic coming from the branch to the headquarters. The traffic flow is as follows: Branch LAN, VPN gateway 3, First LinkProof, VPN gateway 1, Second LinkProof, Router LAN A. The following diagram shows two alternative VPN traffic paths.
Figure 21: VPN Alternative Traffic Paths

Branch
Branch LAN
VPN
Gateway 3
H.Q.
VPN
Gateway 1
LinkProof
VPN
Gateway 1
LinkProof Path A Path B LAN A LAN C LAN B Router
LinkProof is unable to determine which VPN gateway the tunnel uses (the tunnel is maintained via one VPN gateway only). Therefore, if traffic is routed back via the wrong path, the connection is dropped by the other VPN gateway. To avoid this happening, the Multicast Dispatch Method is available to configure a firewall farm.
Multicast Dispatch
When the network session starts from the headquarters to the branch, as shown in Figure 21 - VPN Alternative Traffic Paths, page 219, a VPN session is open along the red path.
219
LinkProof User Guide Basic Application Switching When the Multicast Dispatch Method is used, after the return packet reaches the lower LinkProof device, a Multicast is sent with the return packet to both VPN gateways. The gateway that responds first, is the one with an established VPN session. LinkProof forwards the traffic to the VPN gateway and the session is not interrupted.
Note: The OnDemand Switch VL platform does not support the Multicast Dispatch Method. For information on configuring a farm with the Multicast Dispatch Method using Web Based Management, see LinkProof Farms, page 138.
To configure multicast dispatch using CLI Use the following command:
lp farms -farms add <farm name> -dm multicast>
Clear Client Table (VPN Load Balancing Feature)

Client entries are removed from a farm using the Clear Client Table feature when specific VPN Load Balancing configurations are problematic. The following diagram shows a configuration that illustrates the two possible scenarios for which the Clear client Table feature is used.
220
Figure 22: Clear Client Table Scenarios
Clear Client TableScenario 1

In the event that switch 3 goes down, then LinkProof 4 handles the session. If Switch 3 comes up again, LinkProof 3 responds to the traffic again and sends the traffic to both VPN gateways (VPN 1 and VPN 2), as multicast mode has been set. The LinkProof 3 does not have a Client Table entry any more. LinkProof 1 however, still sends traffic to VPN 1 and this in turn creates a persistency issue because LinkProof 3 and LinkProof 1 have different entries in their Client Table. To solve this scenario, a new flag is added to the farm that indicates when a client entry as part of a farm needs to be deleted when the server of that farm comes up again. This ensures that persistency is maintained.
221
Clear Client TableScenario 2

Another problem arises when both backup and regular servers (firewalls) are configured. If both servers are active, then traffic goes through the regular server. If the regular server is not in service, all its associated Client Table entries are deleted and traffic is sent through the backup server. Once the regular server is up, the old sessions that are already in the Client Table are sent through the backup server even though the regular server is up. Only new sessions are sent through the regular server. To solve the second scenario, an additional value has been added to the field which provides an option to delete farm related client entries in the event that the first regular server is up. This assures that no session goes through the backup server if there is a regular server available.
To configure the clear-Client-Table condition using CLI Enter the following command:
lp farms -farms set <Farm Name> -tc <1|2|3>

where: 1Specifies None (default); that is, previous functionality is ignored. 2Specifies Any Server Up, that is, when a server of a particular farm goes up after having been down, all the clients that are part of that farm entries are deleted. 3Specifies First Regular Server Up, that is, when a regular server goes up and it is the first regular server for that farm to go up, all the Client Table entries associated with that server selection of that farm are deleted.
Note: You can use the values also when creating the firewall server farm. For information on configuring a farm with the clear-Client-Table condition using Web Based Management, see LinkProof Farms, page 138.
Client Table Overwrite

This feature assists in dealing with the problems associated with Clear Client TableScenario 1, page 221. To solve the problem, a flag indicates when a client entry as part of a farm needs to be deleted when the server of that farm comes up again.
Note: Because two redundant LinkProof devices may not be synchronized and might not recognize that the server is up or down at the same time, there could be persistency issues until server selection status data is overwritten. Persistency issues remain until the Client Table entry is deleted. A server that receives a packet from a different server (firewall) is not overwritten. If the new server is of a farm different from the farm of the original server, the server selection is not overridden. If IP translations (NAT) of any sort are involved for the session, the server selection is not overridden.
222
To configure Client Table overwrite using CLI Enter the following command:
lp global client-table server-selection-override set {disable|enable}
To configure Client Table overwrite once a new farm has been created using Web Based Management 1. Select LinkProof > Global Configuration > Client Table > General > Server Selection Override. 2. From the Server Selection Override drop-down list, select either disable (default) or enable. 3. Click Set.
223
224
Chapter 5 Advanced Features

This chapter describes LinkProofs advanced capabilities and provides common configuration examples. This chapter contains the following sections: Content Load Balancing, page 225 Tunneling, page 234 Virtual Tunneling, page 237 Cost-based Load Balancing, page 247 Event Scheduler, page 248 Miscellaneous ParametersTweaks, page 249 Performance Statistics, page 251 Statistics Monitor SRP Management Host IP Address, page 260 Configuration Auditing, page 261 NTP Service, page 262 RADIUS Service, page 263
Content Load Balancing

This section describes what content load balancing is and describes the methods for LinkProof load balancing. This section contains the following: Content Load Balancing Overview, page 225 Remove Proxy, page 1 Layer 7 Policies, page 228 Content Rules, page 230 Hostname Lists, page 233
Content Load Balancing Overview

Due to the reliance on networked/Web applications like ERP, CRM and CITRIX applications, there is a need for application-aware multihoming devices that can direct application traffic to the most suitable link (in terms of performance, security, and availability). To differentiate between Web-based applications, HTTP content-based decisions are required. LinkProof is application-aware and based on HTTP content, and can do the following: Load balance specific traffic to different routers or firewalls Block traffic to specific URLs or traffic that includes specific content types
This section contains the following topics: Delayed Binding, page 226 Alias Ports, page 227
225
LinkProof User Guide Advanced Features
Delayed Binding
To make a load balancing decision based on HTTP content (Layer 7 decision), LinkProof implements a mechanism referred to as Delayed Binding. When Delayed Binding is used, LinkProof does the following: 1. 2. 3. 4. 5. Performs a TCP handshake with the client in order to receive the HTTP request. Parses the data in the HTTP request, usually HTTP headers. Performs the load balancing decision according to the configured Layer 7 policies. Initiates a TCP handshake with the destination. Forwards the traffic to the selected farm server.
Note: If a POST request arrives with no content-length, LinkProof issues a reset to the client.
To change delayed binding global settings 1. 2. Select LinkProof > Global Configuration > Delayed Bind. The Global Configuration Delayed Binding pane is displayed. Configure the parameters; and then, click Set.
Table 107: Delayed Binding Global Parameters
Parameter
Search Depth In Bytes
Description
How deep in the HTTP request or reply fragment the device searches for the required criteria. This may require waiting for a number of packet fragments. Values: 146066560 Default: 4096
Max Number of Request Fragments
The maximum number of request fragments that the device gathers to look for the required criteria. If Max Number of Request Fragments is exceeded before the end-of-header is found, the device issues a reset to client. Values: 1100 Default: 10 Note: In certain LinkProof configurations, Radware recommends that you increase the value of this parameter enough to prevent a situation where the device issues a reset command to the client. LinkProof stores the end-of-header (\r\n\r\n or \n\n) in two pieces, where it is necessary to distinguish consequent requests. One case is for a POST request (because LinkProof must know where the header part of a request ended in order to account for all the body parts). The other case is when HTTP persistency is enabled, the traffic is HTTP1.1, and L7 Header Enrichment alters the packet.
226
Table 107: Delayed Binding Global Parameters
Parameter
SYN Protection Accumulate Request
Description
Specifies whether the feature is enabled or disabled. Values: enable, disable Default: disable This feature is relevant only when a Layer 7 Policy is enabled (LinkProof > Content LB Parameters > L7 Policies Table). Values: EnableThe load balancing decision will be based on the first HTTP GET message, and all the requests (all the associated objects) for the same session will pass through the same NHR. With this option, LinkProof forces the HTTP client to use HTTP/1.1 (assuming it can use HTTP/1.1) by keeping the keep-alive parameter open. DisableClients use HTTP/1.0, even if the HTTP client sent a HTTP GET with HTTP/1.1. Select disable if you cannot guarantee that a single server can serve all requests within a single TCP session. enableHeadOnlySame as enable, but works only for HTTP HEAD requests. Typically, you specify this option with an AppXcel Inline topology (LinkProof to AppXcel to HTTPS Web site). Disable as 1.0Changes HTTP/1.0 to HTTP/1.0 (client side) and forces a keep-alive to close connection (that is, cancels the keep-alive) in the first request. disableNeutralNot supported. Default: Disable
Http Persistency
Alias Ports
LinkProof devices often are installed on networks that contain proxies. The function of the proxy is to inspect the traffic before sending it out to the internet. These proxies tend to use TCP ports that do not correspond to the well-known TCP ports usually used by a certain protocol (that is, HTTP traffic may appear with port 8080 as the destination port). LinkProof uses Alias Ports, which enable you to link any destination TCP port to one of these protocols.
Caution: Any type of traffic other than HTTP and POP3 should not use aliases.
To create a new alias port 1. Select LinkProof > Global Configuration > Alias Ports. The Alias Ports pane is displayed. 2. Click Create. The Alias Ports Table Create pane is displayed. 3. Configure the parameters; and then, click Set.
227
Table 108: Alias Port Parameters
Parameter
Port Number Well Known Port Number
Description
The value of the destination TCP port. Enter a value that corresponds to the required protocol. Changes the value of the port for the protocol. Values: HTTP (80)For Web traffic usually found on port 80. POP3 (110)For mail traffic usually found on port 110. Default: HTTP (80)
To update an existing Alias Port 1. 2. 3. 4. Select LinkProof > Global Configuration > Alias Ports. The Alias Ports pane is displayed. Click on the relevant alias port from the table. The Alias Ports Table Update pane is displayed. Edit the value of the Well Known Port Number as required. Click Set.
Caution:
Layer 7 Policies
A single Layer 7 Policy (or L7 Policy) can include several Content Rules (see Content Rules, page 230), all using the same HTTP criteria, such as URL, HTTP header, and so on. For example, a Layer 7 Policy can send HTTP traffic to a certain URL via a specific router always. To select farm according to a Layer 7 Policy, LinkProof matches the packet against the entries within the Policy according to the defined order, and uses the first matching entry.
Caution: The more specific policy must appear first; otherwise; the less specific policy is always matched and used.
Example
A packet with a request to URL www.a.com/a arrives at LinkProof, which has a Layer 7 policy with the following entries: First entry with classification criteria www.a.com/ab Second entry with classification criteria www.a.com/a
Then the second entry is matched and used. The criteria according to which LinkProof classifies traffic are called Methods. The following Method Types are available for LinkProof: URLLooks For a specified hostname and/or path in the HTTP request. File Typelooks for a specified File Type in the HTTP request. Header FieldLooks for a specified Header Field in the HTTP request.
228
LinkProof User Guide Advanced Features CookieLooks for a Specified cookie in the HTTP request. Regular ExpressionLooks for a regular expression anywhere in the HTTP Header of the request. LinkProof supports Posix 1002.3 regular expressions, the string can be up to 80 characters.
Note: All content settings of the methods are case insensitive.
To configure a new Layer 7 policy 1. Select LinkProof > Content LB Parameters > L7 Policies Table. The L7 Policies Table pane is displayed. 2. Click Create. The L7 Policies Table Create pane is displayed. 3. Configure the parameters; and then, click Set.
Table 109: L7 Policy Parameters
Parameter
L7Policy Name L7PolicyIdx
Description
The name of the L7 policy. The order in the list of policiesin which LinkProof matches packets to this policy. It is not possible to update the Index once you define it. Therefore, to facilitate changes later, it may be convenient to specify non-consecutive values. For example, set the first entry with Index 10 and the second with Index 20.
Action
The action that LinkProof takes if the traffic matches this policy. Values: The farms configured on the device of the type specified in the Farm Type drop-down list. BypassBypass all farms of the type defined in this policy. DropDiscard packet. Default: Bypass
Server
If the Action is to load balance the traffic to a farm (that is, the value specified for the Action parameter is a farm), this parameter specifies whether always to select a specific server in that farm or to load balance between the servers in the farm according to the farms Dispatch Method. Values: Select-ServerLoad balances between the servers in the farm according to the farms Dispatch Method. The servers configured for the farm selected from the Action drop-down list. The drop-down list includes the servers only when the Action is a farm. Default: Select-Server Note: When a specific server is selected, the LinkProof device does not check the status of that server. If the server is unavailable, the packets that the LinkProof device sends to the sever are lost.
229
Table 109: L7 Policy Parameters
Parameter
Service Type
Description
Values: None Basic Filter AND Group OR Group Default: None
Service Hostname List
The service (traffic type) from the list. The contents of the list depend on the selected Service Type. The Hostname List (see Hostname Lists, page 233) that the device applies when trying to match a packet. Optional. Values: NoneSpecifies that the policy does not use a Hostname List. The Hostname Lists configured on the device. Default: None
Table 110: Method Types
Method Type
URL
Method-specific Parameters
Host Name
Description
Example
The host name part of the Host Name = www.a.com URL in the HTTP header (mandatory) The path part of the URI in Path = cgi-bin the HTTP header The type of file in the URI A specific header field in the HTTP request (mandatory) A value inside the specific header field Type = html Header Field + AcceptLanguage Token = en-us
Path File Type Header Field File Type Header Field
Token Cookie Cookie Key Cookie Value Regular Expression Regular Expression
A specific cookie key in the Cookie Key = server HTTP request (mandatory) The value of the cookie key Cookie Value = red
Regular Expression (string Regular Expression + .ABC pattern matching)
Content Rules
Content load balancing is integrated in flows using a Content Rule. A Content Rule allows LinkProof to load balance between different farms of the same type, or different servers in a farm, based on HTTP content. The Content Rule allows configuring traffic load balancing using Layer 7 policies. Once Content Rules are defined, they can be used in the Flow configuration as any other farm. When the first packet of a session is matched to a flow that contains a Content Rule, the LinkProof device uses
230
LinkProof User Guide Advanced Features Delayed Binding (see Delayed Binding, page 226). When the LinkProof device receives enough information from the HTTP header, a farm and then a server can be selected according to the Layer 7 Policy attached to that Content Rule. This sections contains the following topics: Configuring Content Rules, page 231 Content Rule Configuration Examples, page 233
Note: Content Rules are activated only for HTTP traffic over standard port 80.
Configuring Content Rules

Once Layer 7 policies have been defined, you can associate the Layer 7 policies to a Content Rule.
Note: The Layer 7 policies selected in the Content Rule must be polices defined for the same type of farms as the Content Rule.
To create a Content Rule 1. Select LinkProof > Content LB Parameters > Content Rules Table. The Content Rules Table pane is displayed. 2. Click Create. The Content Rules Table Create pane is displayed. 3. Configure the parameters; and then, click Set.
Table 111: Content Rule Parameter
Parameter
Content Rule Name Default Action
Description
The name of the Content Rule. The action that LinkProof takes if the request traffic does not match this policy. Values: BypassBypass all farms of the type defined in this Content Rule. DropDiscard packet. The farms of the type specified in the Farm Type drop-down list. Default: Bypass
L7Rule Name
The Layer 7 Policy that should be matched. Values: The L7 policies configured on the device associated with the farm type specified in the Farm Type drop-down list. No L7 Policy Default: No L7 Policy
231
To modify a Content Rule 1. 2. Select LinkProof > Content LB Parameters > Content Rules Table. The Content Rules Table pane is displayed. Select the link of the required Content Rule. The Content Rules Table Update pane is displayed. The panes includes the Default Action hits parameter, that is, the number of times the request traffic did not match the policy. Configure the parameters; and then, click Set.
3.
Table 112: Content Rule Update Parameters
Parameter
Default Action
Description
The action that LinkProof takes if the request traffic does not match this policy. Values: BypassBypass all farms of the type defined in this Content Rule. DropDiscard packet. The farms of the type specified in the Farm Type drop-down list.
L7 Rule Name
The Layer 7 Policy that should be matched. Values: The L7 policies configured on the device associated with the farm type specified in the Farm Type drop-down list. No L7 Policy
232
Content Rule Configuration Examples

Different WAN links are often required for different applications provided over HTTP. The following figure shows a configuration with two routers. Router 1 must always be used for the CRM application provided over HTTP and for access to the corporate intranet. For the rest of the traffic, Router 2 should be used, while Router 1 should only be used as backup in case Router 2 fails.
Figure 23: Content Rule Configuration Example
Router 1
Router 2
Interface 2
100.1.1.10 200.1.1.10
LinkProof
Interface 1
10.1.1.10
Hostname Lists
An L7 Policy can include a user-defined Hostname List to which LinkProof matches packets. That is, when an L7 Policy includes a selected user-defined Hostname List, LinkProof checks whether the host of the packet header is included in the selected Hostname List.
Note: The host names in the Hostname List of an L7 Policy are not algorithmically related to a host name configured for a basic filter.
233
Adding a Hostname to a Hostname List

Use the Hostname Lists Table pane to display the current Hostname Lists, configure new Hostname Lists, and add hostnames to existing Hostname lists.
To add a hostname to a Hostname List 1. 2. 3. Select LinkProof > Content LB Parameters > Hostname > Hostname Lists Table. The Hostname Lists Table pane is displayed. Click Create. The Hostname Lists Table Create pane is displayed. Configure the parameters; and then, click Set.
Table 113: Hostname List Parameters
Parameter
List Name Hostname
Description
Combo-box with the Hostname Lists. The name or IP address of the host.
View Hostname List Statistics

LinkProof exposes Hostname List statistics in the Hostname Lists Statistics pane. The table in the Hostname Lists Statistics pane comprises the following columns: List NameThe name of the Hostname List Number of HostnamesThe number of hostnames configured in the relevant Hostname List Number of Policy MatchesThe number of sessions that matched all the L7 Policies configured with this Hostname List
To view Hostname List statistics Select LinkProof > Content LB Parameters > Hostname > Hostname Statistics. The Hostname Lists Statistics pane is displayed.
Tunneling
Carriers, service providers, and large organizations use various tunneling protocols to transmit data from one location to another. Tunneling is done via the IP network in a way that network elements are unaware of the data encapsulated within the tunnel. This implies that routers route traffic based on source and destination IP addresses. IPS devices and load balancers, however, whose decisions are based on information located inside the IP packet at a known offset, are not able to locate relevant information, since the original IP packet is encapsulated within the tunnel. LinkProof supports the following tunneling types: Layer 2 Tunneling Protocol (L2TP), page 235 Generic Routing Encapsulation (GRE), page 235 GPRS Tunneling Protocol (GTP), page 236 Multiprotocol Label Switching (MPLS), page 236
234
LinkProof User Guide Advanced Features If a LinkProof device is positioned between two tunneled purpose border routers (which encapsulate and remove the tunneled header), LinkProof takes all the routing and farms load-balancing decisions based on the tunneled header of the packet, since the border routers (and other potential servers) are forwarding the packet based on the tunneled information which the packet carries with it. Bandwidth management (BWM) and flow-management policies can be applied on tunneled packets. Note that the policy classification is based on the payload of the tunneled packet (and not on the tunneled header), since, generally, with BWM and flow management policies, only the payload is interesting.
To enable tunneling 1. Select Device > Tunneling. The Tunneling Parameters pane is displayed. 2. From the Tunneling Parameters drop-down list, select Enabled. 3. Click Set.
Layer 2 Tunneling Protocol (L2TP)

Layer 2 Tunneling Protocol (L2TP) is an extension of Point-to-Point Protocol (PPP) and designed as replacement for two proprietary protocols: Ciscos L2F and Microsofts PPTP. L2TP, defined in RFC 2661, is an application-layer tunneling protocol, which utilizes UDP port 1701 to transmit multiprotocol packets across layer 2 links. When a packet is encapsulated using L2TP, a new IP packet is created with a new IP header with the Tunnel ID and Session ID.
Figure 24: Tunnel ID and Session ID in Packet Encapsulated Using L2TP
An example of L2TP packet looks as follows:
Table 114: Example L2TP Packet Structure

Ethernet IP UDP L2TP PPP Original IP header Original data
Generic Routing Encapsulation (GRE)

The Generic Routing Encapsulation (GRE) protocol provides a mechanism for encapsulating arbitrary packets within an arbitrary transport protocol. In the most general case, a system has a packet that needs to be encapsulated and routed (the payload packet). The payload is first encapsulated in a GRE packet, which possibly also includes a route. The resulting GRE packet is then encapsulated in some other protocol and forwarded (the delivery protocol). The IPv4 protocol 47 is used when GRE packets are encapsulated in IPv4. When a packet is encapsulated using GRE, a new IP packet is created.
235
Figure 25: IP Header in GRE Packet
GPRS Tunneling Protocol (GTP)

GPRS Tunneling Protocol (GTP) defines the protocol between GPRS Support Nodes (GSNs) in the GPRS backbone network. GTP includes both the GTP control plane (GTP-C) and data transfer (GTP-U) procedures. GTP allows multi-protocol packets to be tunneled through the UMTS/GPRS backbone between GSNs and between an SGSN and UTRAN. The GTP protocol tunnels the protocol data units through the IP backbone by adding routing information. GTP operates on top of TCP/UDP over IP. When a packet is encapsulated using GTP, a new IP packet is created.
Figure 26: IP Header in GTP Packet
Multiprotocol Label Switching (MPLS)

Multiprotocol Label Switching (MPLS) is an IETF initiative that integrates Layer 2 information concerning network links (bandwidth, latency, utilization) into Layer 3 (IP) within ISP, serviceprovider, or carrier networks. When MPLS is used, a label is added to the original packet. The label contains information about routing, available bandwidth, delays and other parameters. The MPLS header is placed between L2 and L3 headers and contains one or more labels. Each entry is 32-bits long.
Figure 27: Entry Format in MPLS Packet
If the IP packet is already an IP fragment, it cannot be fragmented again, because IP does not support multiple fragmentations. IP fragments that exceed the network MTU are discarded.
236
Virtual Tunneling
This section describes virtual tunneling and how it functions in the network in conjuction with LinkProof. This section contains the following: Virtual Tunneling Introduction, page 237 Virtual Tunneling Configuration, page 239
Virtual Tunneling Introduction

Providing high availability and load balancing over multiple WAN links for applications such as VPN (Virtual Private networks) or VoIP can be very difficult if not completely impossible with current technology. It should also be noted that Internet load balancing and high availability for IP applications are difficult to NAT. Applications, such as VoIP signaling and VPN connectivity, have difficulties in multihomed environments that are not BGP-based for reasons such as the following: The applications embed source address information in the packet payload in addition to the packet header. The destination addresses for the applications are static and not resolved via DNS.
LinkProof handles this issue by providing virtual tunneling. The virtual-tunneling feature utilizes existing SmartNAT technology. LinkProof uses NAT to encapsulate packets between sites by translating both source and destination addresses. LinkProof creates virtual tunnels between the two application servers located in different sites, allowing them to communicate via multiple and diverse WAN links. The virtual-tunneling functionality is operational only between pairs of LinkProof devices. No virtual tunnels can be provided to sites not equipped with LinkProof. The following diagram shows the encapsulation mechanism used by the virtual-tunneling feature; and it also shows how LinkProof can provide the following: High availability for traffic between the two gateways Load balancing to increase the bandwidth available to the VPN traffic
Figure 28: Virtual Tunneling Scenario

London A.0/24 C.0/24 San Francisco
Internet
L.100 B.0/24 D.0/24
S.100
High Availability
If a client in London wants to establish a VPN connection to San Francisco, the London firewall/VPN gateway (IP address L.100) initiates a connection to the internal IP address of San Francisco firewall/VPN gateway (S.100).
237
LinkProof User Guide Advanced Features LinkProof on the London side receives the packets and selects a virtual tunnel. Since both London and San Francisco have dual Internet connections there are four (4) virtual tunnels available for the London LinkProof to choose from (A-to-C, A-to-D, B-to-C, B-to-D). If tunnel A-D was chosen, the LinkProof will translate source address to its external IP (Static NAT) via router A and destination address to its external IP via router D. If link D becomes unavailable, LinkProof London chooses a new virtual tunnelfor example A-to-C and translates the source and destination addresses accordingly. LinkProof San Francisco translates the packets back to the original addresses (L.100 - S.100). This allows the connection between the two VPN gateways to be sustained, regardless of the path that the traffic takes. To achieve this functionality, the LinkProof units must be aware of the Static NAT tables, WAN links health, response time, and load at remote site. This can be achieved by using the inter-LinkProof communication protocol, called TRP (Tunneling Report Protocol) to populate and teach each participating LinkProof the relevant information.
Load Balancing
LinkProof provides an option to select a virtual tunnel per new Client Table entry or Packet by Packet. The Packet by Packet option allows to load balance a tunneled connection over multiple WAN links. Per Client Table EntryOnce connectivity is established between two VPN gateways, sessions between clients and servers behind the gateways are opened and closed, but the VPN connection is open. Since LinkProof sees communication between the same two IP addresses, the VPN gateways (L.100 and S.100 in our example), and entry in Client Table already exists, all packets are forwarded to the same virtual tunnel, as long as the virtual tunnel is active. Packet by PacketTo load balance a VPN connection between all existing virtual tunnels, LinkProof provides the option of selecting a virtual tunnel per packet instead of per new Client Table entry. Each packet is encapsulated within the chosen virtual tunnel.
Local Service and Remote Service

Virtual tunnels are created for every pair of local service and remote service. There is a tunnel for each combination of a local and a remote link. Tunnels are created automatically according to the changes in the local or remote links. A virtual tunnel is set between an IP address of the local LinkProof and an IP address of the remote LinkProof. During the load-balancing decision, LinkProof selects a virtual tunnel according to its health and additional parameters required by the configured Dispatch Method (response time, load).
TRP
TRP (Tunneling Report Protocol) is a proprietary inter-LinkProof communication protocol used to establish and maintain the virtual tunnels. The TRP protocol includes two types of messages: RegularRequires the operational and load status of their WAN links from remote LinkProof devices. ExtendedRequires WAN links status and configuration changes from remote LinkProof devices.
The interval at which these messages are exchanged is configurable.
238
Virtual Tunneling Configuration

This section describes the basic configuration of the virtual-tunneling feature, which is required for each participating LinkProof device. Before starting to configure virtual tunneling, do the following: 1. Configure each LinkProof for basic load balancing. For the router farm that will be used for virtual tunneling, set the following parameters Packet TranslationNAT and virtual tunneling Connectivity Check StatusHealth Monitoring
2. Configure Static NAT/No NAT for local stations participating in virtual tunneling. 3. Define static routes to local station subnets. 4. Define static route to external subnets of remote LinkProof devicesdestination=0.0.0.0 route covers all possible subnets.
Enabling Virtual Tunneling
To enable virtual tunneling 1. Select LinkProof > Virtual Tunneling > Global Parameters. The Global Parameters pane is displayed. 2. From the Virtual Tunneling Admin Status drop-down list, select Enable. 3. Click Set. 4. Reset the device.
Configuring Virtual Tunneling Global Parameters

You can configure all the virtual-tunneling global parameters only after you enable the virtualtunneling feature.
To configure the virtual-tunneling global parameters 1. Select LinkProof > Virtual Tunneling > Global Parameters. The Global Parameters pane is displayed. 2. Configure the parameters; and then, click Set.
239
Table 115: Virtual Tunneling Global Parameters
Parameter
Virtual Tunneling Admin Status
Remark
Specifies whether the virtual-tunneling functionality is enabled. When the feature is enabled, you can view the Virtual Tunneling submenus. When you change the status, you must reset the device for the change to take effect.
TRP Admin Status
Activates the TRP protocol used to establish and maintain the virtual tunnels. This parameter is displayed only when Virtual Tunnelling Admin Status is Enabled. Note: Radware recommends that you enable TRP communication. When the TRP Admin Status is disabled, you must configure the Advanced Configuration parameters manually.
Virtual Tunneling HM Admin Status Enables you to perform Health Monitoring of the virtual tunnels. This parameter is displayed only when Virtual Tunnelling Admin Status is Enabled.
Configuring a Virtual Tunneling Local Service

Local Service is a logical entity, which represents the service (VPN, VoIP) functionality that the LinkProof device provides. Before configuring a Virtual Tunneling Local Service, ensure the following: Smart NAT functionality is enabled. Virtual Tunnelling is enabled (LinkProof > Virtual Tunneling > Global Parameters > Virtual Tunneling Admin Status > Enable > Set). Health Monitoring is enabled on the device (Health Monitoring > Global Parameters > Health Monitoring Status > Enable > Set). For each farm that participates in the Virtual Tunnel, health monitoring is configured (LinkProof > Farms > FW Farm Table or Router Farm Table > Choose the relevant farm > Connectivity Check Status > Health Monitoring > Set).
To configure a new Local Service 1. 2. 3. Select LinkProof > Virtual Tunneling > Local Service Table. The Local Service Table pane is displayed. Click Create. The Local Service Table Create pane is displayed. Configure the parameters; and then, click Set.
Table 116: Local Service Table Parameters
Parameter
Local Service Name Password
Description
The name of the local service available to external users (other LinkProof devices). Password for the TRP communication.
240
Table 116: Local Service Table Parameters
Parameter
Host Name
Description
The host name intended for the TRP DNS resolution. You can define the LinkProof device as the authoritative name server for this domain in the organizations master DNS servers. If you do this, the DNS queries for the local service domain name arrive at the LinkProof device, which processes the query in accordance with the best NHR connection available for the users request.
Distribution Mode
How the device distributes the packets. Values: Client-TableThe device performs load balancing using the Client Table entries. Per-PacketThe device performs load balancing per packet.
Configuring a Virtual Tunneling Local Station

Once the local service is defined, you can start attaching application servers that provide the service in the Local Stations Table. Before configuring a Virtual Tunneling Local Service, ensure the following: Smart NAT functionality is enabled. Virtual Tunnelling is enabled (LinkProof > Virtual Tunneling > Global Parameters > Virtual Tunneling Admin Status > Enable > Set). Health Monitoring is enabled on the device (Health Monitoring > Global Parameters > Health Monitoring Status > Enable > Set). For each farm that participates in the Virtual Tunnel, health monitoring is configured (LinkProof > Farms > FW Farm Table or Router Farm Table > Choose the relevant farm > Connectivity Check Status > Health Monitoring > Set).
To configure Local Station Table 1. Select LinkProof > Virtual Tunneling > Local Station Table. The Local Station Table pane is displayed. 2. Click Create. The Local Station Table Create pane is displayed. 3. Configure the parameters; and then, click Set.
Table 117: Local Station Table Parameters
Parameter
Local Service Name Internal Station Address
Description
Must be the same as the name defined in the Local Service Table. Internal IP of station participating in this servicefor example, the station for a VPN service is a VPN gateway. A local station can be attached only to one local service.
Configuring a Virtual Tunneling Remote Service

For each Local Service, you need to define the Remote Services to which virtual tunneling is available.
241
LinkProof User Guide Advanced Features Before configuring a Virtual Tunneling Local Service, ensure the following: Smart NAT functionality is enabled. Virtual Tunnelling is enabled (LinkProof > Virtual Tunneling > Global Parameters > Virtual Tunneling Admin Status > Enable > Set). Health Monitoring is enabled on the device (Health Monitoring > Global Parameters > Health Monitoring Status > Enable > Set). For each farm that participates in the Virtual Tunnel, health monitoring is configured (LinkProof > Farms > FW Farm Table or Router Farm Table > Choose the relevant farm > Connectivity Check Status > Health Monitoring > Set).
To define a new Remote Service 1. 2. 3. Select LinkProof > Virtual Tunneling > Remote Service Table. The Remote Service Table pane is displayed. Click Create. The Remote Service Table Create pane is displayed. Configure the parameters; and then, click Set.
Table 118: Remote Service Table Parameters
Parameter
Remote Service Name Password Host Name
Description
The name of the Remote Service must be the same as Local Service name defined in the remote device. The password required for the TRP communication. The host name of the remote site. A DNS resolution is performed by the local LinkProof to find out the remote LinkProof address. Then, the TRP requests are sent to the resolved address. In case the value is not defined, the customer must set the addresses manually in the Remote Link Table. The value must be the same as defined in remote LinkProof Local Service Table. The name of the relevant Local Service must be the same as the value defined in the Local Service Table. Specifies whether or not the device initiates any TRP communication. Values: EnableEnables TRP traffic from device. Disable
Local Service Name TRP Admin Status
HM Admin Status
Specifies whether or not the Health Monitoring (HM) functionality is available for the selected Remote Service. This parameter is ignored if the value for Virtual Tunneling HM Admin Status is Disabled in the Virtual Tunneling Global Parameters pane.
242
Notes: When you edit an existing remote service, the GUI displays the following read-only parameters in addition to the configurable parameters: >> Load Balance MethodThe Load Balance method used by the remote LinkProof device. This data is received via TRP. The algorithm can be either Cyclic (selecting another link for every new flow) or Weighted (using local LB decision, remote Load Balancing decision, and combined tunnel decision by weighing all the parameters). >> Remote Service StatusActive when the TRP communication is established, NotInService if the Remote Service is not responding to the TRP communication.
Configuring Virtual Tunneling Advanced Tables

You can configure the following advanced virtual-tunneling tables: Remote Link Table Remote Station Table Virtual Tunnels Table Service-NHR Bind Table
You need to configure advanced virtual-tunneling tables in the following cases: TRP communication is disabled. If TRP communication is disabled, you must configure the Remote Stations Table and Remote Link Table manually. TRP communication is enabled, but you want to modify advanced parameters.
Configuring the Virtual-tunneling Remote Link Table

Setting up Remote Links involves specifying IP addresses of remote LinkProof devices. You can specify Remote Links for the Remote Services using the Remote Link Table.
To configure the virtual-tunneling Remote Link Table 1. Select LinkProof > Virtual Tunneling > Advance Configuration > Remote Link Table. The Remote Link Table pane is displayed. 2. Click Create. The Remote Link Table Create pane is displayed. 3. Configure the parameters; and then, click Set.
Table 119: Remote Link Parameters
Parameter
Remote Service Name Remote Link Address
Description
The name of the Remote Service as defined in the Remote Service Table. An IP address of the remote LinkProof device. The address can be Virtual DNS address (preferable), Virtual IP Address, or external IP interface (that is, the interface to the NHRs) of the remote LinkProof device. This parameter is displayed only if there is a virtual tunnel between two devices configured.
Remote Link Operational Status The status of the remote link.
243
Table 119: Remote Link Parameters
Parameter
Remote Link Name
Description
The name of the Remote Link. This parameter is displayed only if there is a virtual tunnel between two devices configured.
Remote Link Mode
Specifies whether the Remote Link functions in Regular mode or Backup mode.
Configuring the Virtual-tunneling Remote Station Table

You can configure stations attached to the Remote Service using the Remote Station Table (for example, VPN gateways).
To configure the virtual-tunneling, advanced Remote Station Table 1. 2. 3. Select LinkProof > Virtual Tunneling > Advance Configuration > Remote Station Table. The Remote Station Table pane is displayed. Click Create. The Remote Station Table Create pane is displayed. Configure the parameters; and then, click Set.
Table 120: Remote Station Parameters
Parameter
Remote Service Name Remote Link Address Remote Internal Address
Description
The name of the Remote Service as defined in the Remote Service Table. An IP address of the remote LinkProof device as defined in the Remote Link Table. Internal IP address of the Remote Station. For example, the Remote Station for a VPN service is a VPN gateway.
Remote External Address (NAT) The Static NAT address associated with the Remote Station via the remote link.
Viewing the Virtual-tunneling Virtual Tunnels Table

You can view the existing virtual tunnels and their status in the Virtual Tunnels Table pane. This table is read only.
To view the Virtual Tunnels Table Select LinkProof > Virtual Tunneling > Advance Configuration > Virtual Tunnels Table. The Virtual Tunnels Table pane is displayed.
Table 121: Virtual Tunnels Table Parameters
Parameter
Remote Service Name Remote Link Address
Description
The name of the Remote Service as defined in the Remote Service Table. An IP address of the remote LinkProof device as defined in the Remote Link Table.
244
Table 121: Virtual Tunnels Table Parameters
Parameter
Local NHR Address Operational Status VT Mode (Local-Remote)
Description
The IP address of a local NHR that can be used to reach the Remote Service. The operational status of this tunnel. Values: Active, NotInService The mode of the Virtual Tunnel. The mode depends on the Remote Link Mode and the local NHR Bind Mode. This parameter is displayed only after there is an entry for Entry mode. Values: Regular-Regular Regular-Backup Backup-Regular Backup-Backup Note: If there are Regular-Regular virtual tunnels available, only they participate in the load-balancing decision. If no Regular-Regular tunnels are available, Regular-Backup tunnels are the next to consider, then Backup-Regular and finally Backup-Backup.
Configuring the Virtual-tunneling Service-NHR Bind Table

You can configure local NHRs available for each Remote Service using the Service-NHR Bind Table. LinkProof populate the table automatically, but you can edit the parameters within the table.
To modify the virtual-tunneling, advanced Service-NHR Bind Table 1. Select LinkProof > Virtual Tunneling > Advance Configuration > Service-NHR Bind Table. The Service-NHR Bind Table pane is displayed. 2. Configure the parameters; and then, click Set.
Table 122: Virtual-tunneling Service-NHR Bind Parameters
Parameter
Remote Service Name Local NHR Address NHR Bind Mode
Description
The name of the Remote Service as defined in the Remote Service Table. The IP address of a local NHR that can be used to reach the Remote Service. Specifies whether the NHR is functioning in Regular mode or Backup mode regarding the Remote Service.
245
Table 122: Virtual-tunneling Service-NHR Bind Parameters
Parameter
NHR Bind Status Entry Mode
Description
Specifies whether the NHR is available for the Remote Service. The Entry Mode. Value: DynamicThe device automatically fills up the entry in accordance with other virtual-tunneling settings. StaticIf you modify the entry, the mode of the entry changes to Static. Once the mode becomes Static, the device does not automatically update the parameters of this entry.
Configuring Virtual-Tunneling Tweaks
To configure virtual-tunneling tweaks 1. 2. Select LinkProof > Virtual Tunneling > Tweaks. The Tweaks pane is displayed. Configure the parameters; and then, click Set.
Table 123: Virtual-Tunneling Tweaks
Parameter
TRP Port
Description
The port used by the TRP communication. If there other network devices on the same network that use the same port, this port number must be changed. The same TRP port must be configured on all the LinkProof devices that communicate via TRP. Default: 2090 The number of times this device tries to initiate the TRP communication with remote LinkProof devices. The time, in seconds, at which the Regular TRP messages are initiated. The time, in minutes, at which the Extended TRP messages are initiated. The time interval, in seconds, at which the tunnel health is checked. The number of times that the tunnel health checks are attempted. The time, in seconds, after which the operational status of a tunnel that does not respond to health checks is set to NotInService. The weight applied to tunnel latency values in the load-balancing decision. Values: 1100 The weight applied to a local link load value in the load-balancing decision. Values: 1100
TRP Retries TRP Regular Interval TRP Extended Interval Tunnel Check Interval Tunnel Check Retries Tunnel Check Timeout Tunnel Weight
Local Link Weight
246
Cost-based Load Balancing

Companies that have more than one ISP link and use the links for load balancing, need to take into account both the load on the link, the capacity of the link, as well as the cost of each link. When making a load-balancing decision, LinkProof can take the link cost into consideration along with other load-balancing factors (such as Dynamic Proximity and load). When buying or leasing a link, network administrators should take into account not only the capacity of the link but also the price. The the service provider calculates the price according to a cost model. Service providers may use the following cost models: Flat RateUnlimited usage with a set fee for a specified bandwidth, for example, $1500/month for a 1.5-Mbit/s line. Usage-basedUsers pay according to received data, for example, $1/MB. TieredA combination of the flat-rate and usage-based models. Users pay a flat rate for received data up to a threshold and an additional charge for additional received data, for example, $10 for up to 150 MB received data and $2 for every additional MB received.
Configuring Cost Global Parameters
To configure cost global parameters 1. Select LinkProof > Cost > Cost Global Parameters. The Cost Global Parameters pane is displayed. 2. From the Cost Admin Status drop-down list, select Enabled. 3. In the in the Load Calculation Window text box, type the number of seconds for which the average load per link is calculated. Default: 1 sec.
Note: Use the Load Calculation Window parameter to moderate the impact of traffic spikes. 4. Click Set.
Configuring the Cost Parameters for a Link

Use the NHR Cost Table pane to configuring the cost parameters for a link. When the network implements a ladder or combined method, repeat the following procedure for each cost-per-bandwidth level.
To configure an entry in the NHR Cost Table 1. Select LinkProof > Cost > NHR Cost Table. The NHR Cost Table pane is displayed. 2. Click Create. The NHR Cost Table Create pane is displayed. 3. Configure the parameters; and then, click Set.
247
Table 124: NHR Cost Table Parameters
Parameter
NHR Bandwidth Threshold
Description
The IP address of the links NHR. An integer that specifies the upper limit of the line according to the Bandwidth Unit value. You can configure the cost of a link with a tiered cost model by defining several entries for the same NHR with ascending Bandwidth Thresholds. It is possible that packets that belong to an open session cause the bandwidth used to exceed the bandwidth limit for this NHR. If the Cost feature is disabled, the NHRs bandwidth limit is represented by the Kbit/s limit value (set via the NHR table); otherwise, it is determined by the lower value between Kbit/s limit and the Bandwidth Threshold of the highest cost level. System administrators can configure, for each NHR, whether packets are discarded once this bandwidth limit is reached. You do this by setting the Bandwidth Limit Exception flag to Enabled in the NHR table.
Method
Specifies the pricing method. Values: AbsoluteFor flat-rate cost models Per KbpsFor usage-based cost models
Bandwidth Unit
The unit for bandwidth pricing. This determines the unit of the Bandwidth Threshold parameter. This parameter is not relevant when the Absolute pricing method is selected. Values: 10 Kbps 100 Kbps 1000 Kbps
Price
The price per bandwidth unit. LinkProof looks at the available links and chooses the less expensive. For the Absolute pricing method, the value represents a flat rate.
Event Scheduler
Sometimes, it is necessary for a specific policy to be inactive during certain hours of the day or activate in the middle of the night. For example, a school library may want to block instant messaging during school hours but allow instant messages after school hours. Alternatively, an enterprise may give high priority for mail traffic between 08:0010:00. An event schedule can be a daily, weekly, or one-time event. You can associate an event schedule with a Bandwidth Management policy to activate or deactivate the policy. When the event occurs, the device activates or deactivates the Bandwidth Management policy and then performs the Update Policy action.
248
To configure an event schedule 1. Select Services > Event Scheduler. The Event Scheduler pane is displayed. 2. Click Create. The Event Scheduler Create pane is displayed. 3. Configure the parameters; and then, click Set.
Table 125: Event Scheduler Parameters
Parameter
Name Frequency Time
Description
A user-defined name for the event. After creation, this value is read-only. The frequency of the event. Values: Once, Daily, Weekly The time, in hhHHMM format, on the designated day or days. If you specify multiple days, the time for the event is the same for all the specified days. Default: 000012:00 AM The day or days on which the event occurs when the specified Frequency is Weekly. If the Frequency is not Weekly, the Days checkboxes must be cleared. The date, ddMMyyyy format, on which the event occurs when the specified Frequency is Once. If the Frequency is not Once, the value in the Date text box must be 00000000.
Days
Date
Miscellaneous ParametersTweaks
Use the Global Configuration - Tweaks pane to configure miscellaneous parameters of the device.
To configure miscellaneous parameters 1. Select LinkProof > Global Configuration > Tweaks. The Global Configuration - Tweaks pane is displayed. 2. Configure the parameters; and then, click Set.
249
Table 126: Global Configuration Tweaks Parameters
Parameter
Identify Next Hop Router by Port
Description
Specifies whether the device selects the MAC address and incoming ports of the Next Hop Router to determine the origin of the Next Hop Router traffic. Values: enableThe device selects the MAC address and incoming ports of the Next Hop Router to determine the origin of the Next Hop Router traffic. disableThe device selects only the source MAC. Default: enable
FTP Data Port
Specifies whether the device displays the default settings for this port. You may however change the default settings by entering in a relevant port number. Specifies whether the device displays the default settings for this port. You may however change the default settings by entering in a relevant port number. The IP header that the ToS marking is applied to. Values: tos, precedence, disable Default: disable
FTP Control Port
ToS Type
One Trap
Specifies whether the device sends only one single trap for an event. Values: enable, disable Default: enable
ARP to Logical Servers
Specifies whether the device sends periodic ARP messages to firewalls and remote IDS servers to find their MAC address. Values: Enable, Disable Default: Enable
Time Between Arps
The time, in seconds, between retransmissions of ARP request to Firewalls and remote IDS servers. Values: 53600 Default: 300
Customized Hash Mask
When using the Customized Hash Dispatch Method, this parameter allows you to define the bits in the source and destination IP to be input for the hash function. Default: 0.0.0.255 LinkProof allows you to configure the same name for both sides of the same server. When one side of the server is not in service, LinkProof considers all other servers with the same name to be out of service as well. This is required when using a single LinkProof device as two logical devices using port rules, to make sure all server interfaces are available. Values: Enable, Disable Default: Disable
Identify Server by Name
250
Performance Statistics
This section describes the performance statistics that LinkProof supports. This section includes the following: BWM Policy Statistics, page 251 Element Statistics, page 254 IP Interface Statistics, page 258 NHR Statistics, page 258
BWM Policy Statistics

This section includes the following: BWM Policy StatisticsGlobal Parameters, page 251 BWM Policy Statistics, page 251
BWM Policy StatisticsGlobal Parameters
To configure Policy Statistics global parameters 1. Select Performance > BWM Policy Statistics > Global Parameters. The Policy Statistics Global Parameters pane is displayed. 2. Configure the parameters; and then, click Set.
Table 127: BWM Policy Statistics Global Parameters
Parameter
Policy Statistics Monitoring
Description
Enables or disables the monitoring of policy statistics by the device. Values: Enabled, Disabled Default: Disabled
Policy Statistics Reporting Period Policy Statistics Reporting (SRP)
The time, in seconds, that the device monitors policy statistics. Enables or disables the Statistics Reporting Protocol (SRP). SRP is a proprietary Radware protocol for efficient transmission of statistical data from the device to the Configware Insite management station. Values: Enabled, Disabled Default: Disabled Note: If you enable the SRP, you must enter the SRP Management Host IP address.
BWM Policy Statistics

You can view statistics for the bandwidth-management policies. This section includes the following: BWM Policy StatisticsLast-Second Statistics, page 252 BWM Policy StatisticsLast Period Statistics, page 253
251
BWM Policy StatisticsLast-Second Statistics

To view the information from the Policy Statistics (Last Second) pane, Policy Statistics Monitoring must be enabled.
To view BWM Policy Statistics for the last second 1. Select Performance > BWM Policy Statistics > Last Second Statistics. The Policy Statistics (Last Second) pane is displayed with a table containing the following columns: 2. Policy Name Packets Matched BW (Kbits) Sent BW (Kbits)
To view the statistics for a policy, from the Policy Name column, select the relevant policy.
Table 128: Last-Second Statistics
Parameter
Policy Name Packets Matched BW (Kbits) Sent BW (Kbits) Full Queue BW (Kbits) Aged Packets BW (Kbits) Guar. BW reached
Description
The name of the displayed policy. The number of packets matching the policy during the last second. The traffic bandwidth, in Kbits, matching the policy during the last second. The volume of sent traffic, in Kbits, in any direction, in the last second. The bandwidth, in Kbits, discarded during the last second, due to a full queue. The amount of discarded bandwidth, in Kbits, during the last second, due to the aging of packets in the queue. Specifies whether the guaranteed bandwidth was reached, during the last second. Values: true, false Specifies whether the maximum bandwidth was reached during the last second. Values: true, false The number of inbound packets in the last second. The number of outbound packets in the last second. The volume of inbound traffic, in Kbits, in the last second that matched the policy.
Max. BW reached
Inbound Packets Outbound Packets Inbound Matched BW (Kbits)
Outbound Matched BW The volume of outbound traffic, in Kbits, in the last second that matched (Kbits) the policy. Inbound Sent BW (Kbits) Outbound Sent BW (Kbits) New TCP Sess New UDP Sess The volume of inbound sent traffic, in Kbits, in the last second. The volume of outbound sent traffic, in Kbits, in the last second. The number of new TCP sessions the device detected in the last second. The number of new UDP sessions the device detected in the last second.
252
BWM Policy StatisticsLast Period Statistics

To view the information from the Policy Statistics (Last Period) pane, Policy Statistics Monitoring must be enabled. The parameter determines the period for the statistics in the Policy Statistics (Last Period) pane.
To view BWM Policy Statistics for the last specified period 1. Select Performance > BWM Policy Statistics > Last Period Statistics. The Policy Statistics (Last Period) pane is displayed with a table comprising the following columns: Policy Name Packets Matched BW (Kbits) Sent BW (Kbits)
2. To view the statistics for a policy, from the Policy Name column, select the relevant policy.
Table 129: Last-Period Statistics
Parameter
Policy Name Packets Matched BW (Kbits) Sent BW (Kbits) Full Queue BW (Kbits) Aged Packets BW (Kbits) Guar. BW reached Max. BW reached Inbound Packets Outbound Packets Inbound Matched BW (Kbits)
Description
The name of the displayed policy. The number of packets matching the policy during the last specified period. The traffic bandwidth, in Kbits, matching the policy during the last specified period. The volume of sent traffic, in Kbits, in the last specified period. The discarded bandwidth, in Kbits, during the last specified period, due to a full queue. The amount of discarded bandwidth, in Kbits, during the last specified period, due to the aging of packets in the queue. Specifies whether the guaranteed bandwidth was reached, during the last specified period. Specifies whether the maximum bandwidth was reached during the last specified period. The number of inbound packets in the last specified period. The number of outbound packets in the last specified period. The volume of inbound traffic, in Kbits, in the last specified period that matched the policy.
Outbound Matched BW The volume of outbound traffic, in Kbits, in the last specified period that (Kbits) matched the policy. Inbound Sent BW (Kbits) Outbound Sent BW (Kbits) New TCP Sess The volume of inbound sent traffic, in Kbits, in the last specified period. The volume of outbound sent traffic, in Kbits, in the last specified period. The number of new TCP sessions the device detected in the last specified period.
253
Table 129: Last-Period Statistics
Parameter
New UDP Sess
Description
The number of new UDP sessions the device detected in the last specified period.
Peak Bandwidth (Kbits) The peak bandwidth in the last specified period.
Element Statistics
This section includes the following: IP Packet Element Statistics, page 254 SNMP Element Statistics, page 255 IP Router Element Statistics, page 256 OSPF Element Statistics, page 257 Resource Utilization Element Statistics, page 257 Accelerator Element Statistics, page 257
IP Packet Element Statistics
To view IP packet element statistics Select Performance > Element Statistics > IP. The IP Packet Statistics pane is displayed.
Table 130: IP Packet Statistics
Parameter
IP Receives IP Header Errors
Description
The total number of input datagrams received from interfaces, including those received in error. The number of input datagrams discarded 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, and so on. The total number of input datagrams discarded. Note: This counter does not include any datagrams discarded while awaiting re-assembly.
IP Discarded
IP Successfully Delivered IP Out Requests IP Out Discards
The total number of input datagrams successfully delivered to IP userprotocols (including ICMP). The total number of IP datagrams that local IP user-protocols (including ICMP) supplied to IP in requests for transmission. The 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).
254
SNMP Element Statistics
To view SNMP packet element statistics Select Performance > Element Statistics > SNMP. The SNMP Packet Statistics pane is displayed.
Table 131: SNMP Packet Statistics
Parameter
SNMP Received Packets SNMP Sent Packets SNMP Successful 'get' Requests
Description
The total number of messages delivered to the SNMP entity from the transport service. The total number of SNMP messages that were passed from the SNMP entity to the transport service. The total number of MIB objects that were retrieved successfully by the SNMP entity as the result of receiving valid SNMP Get-Request and Get-Next PDUs. The total number of MIB objects that were altered successfully by the SNMP protocol entity as the result of receiving valid SNMP Set-Request PDUs. The total number of SNMP Get-Request PDUs processed PDUs that were accepted and processed by the SNMP protocol entity. The total number of SNMP Get-Request PDUs that were accepted and processed by the SNMP entity. The total number of SNMP Set-Request PDUs that were accepted and processed by the SNMP entity. The total number of SNMP PDUs that were generated by the SNMP entity and for which the value of the error-status field is 'tooBig'. The total number of SNMP PDUs that were generated by the SNMP entity and for which the value of the error-status is 'noSuchName'. The total number of SNMP PDUs that were generated by the SNMP entity and for which the value of the error-status field is 'badValue'. The total number of SNMP PDUs that were generated by the SNMP entity and for which the value of the error-status field is 'genErr'. The total number of SNMP Get-Response PDUs that were generated by the SNMP entity. The total number of SNMP Trap PDUs that were generated by the SNMP entity.
SNMP Successful 'set' Requests
SNMP 'get' Requests
SNMP 'get-next' Requests SNMP 'set' Requests SNMP Out 'TooBig'
SNMP Out 'NoSuchName'
SNMP Out 'BadValue'
SNMP Out 'GenErrs'
SNMP Out 'GetResponses' SNMP Out Traps
255
IP Router Element Statistics
To view IP router element statistics Select Performance > Element Statistics > IP Router. The Ip Router Statistics pane is displayed.
Table 132: IP Router Statistics
Parameter
IP Forwarded
Description
The 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 the final destination. In entities that do not act as IP gateways, this counter includes only those packets that were Source - Routed via this entity, and the Source - Route option processing was successful. The number of locally addressed datagrams received successfully but discarded because of an unknown or unsupported protocol. The number of IP datagrams discarded because no route could be found to transmit them to their destination. This counter includes any packets counted in ipForwDatagrams that meet this `no-route' criterion. This includes any datagrams that a host cannot route because all of its default gateways are down. Note: This counter includes any packets counted in ipForwDatagrams that meet this `no-route' criterion. It also includes any datagrams that a host cannot route because all its default gateways are down.
IP Unknown Protocol
IP Out No Routes
IP Fragments Received IP Fragments successfully reassembled IP Fragments failed reassembly
The number of IP fragments received that needed to be reassembled at this entity. The number of IP datagrams successfully reassembled. The number of failures detected by the IP reassembly algorithm (for whatever reason: timed out, errors, and so on). Note: This is not necessarily a count of discarded IP fragments, because some algorithms (notably the algorithm in RFC 815) can lose track of the number of fragments by combining them as they are received.
IP datagrams successfully fragmented IP datagrams discarded - failed fragmentation IP datagram fragments generated Valid routing entries discarded RIP - changes made to IP Route Database
The number of IP datagrams that were successfully fragmented at this entity. The number of IP datagrams that were discarded because they needed to be fragmented at this entity but could not be, for example, because their Don't Fragment (DF) flag was set. The number of IP datagram fragments that were generated as a result of fragmentation at this entity. The number of valid routing entries that were discarded. The number of changes made to the IP Route Database by RIP.
256
Table 132: IP Router Statistics
Parameter
RIP - global responses sent to RIP queries IP Fragments successfully reassembled
Description
The number of responses sent to RIP queries from other systems. The number of IP datagrams successfully reassembled.
OSPF Element Statistics
To view OSPF element statistics Select Performance > Element Statistics > OSPF. The OSPF Packet Statistics pane is displayed.
Table 133: OSPF Packet Statistics
Parameter
OSPF - new LSAs originated OSPF - LSAs received- new instantiations
Description
The number of originating Link-State Advertisements in the link-state database. The number of received Link-State Advertisements in the link-state database.
Resource Utilization Element Statistics
To view resource utilization statistics Select Performance > Element Statistics > Resources. The Resource Utilization pane is displayed.
Table 134: Resource Utilization Statistics
Parameter
Resource Utilization RS Resource Utilization RE Resource Utilization Last 5 sec. Average Utilization
Description
The percent of the devices CPU currently utilized. The percent of the devices RS resource currently utilized. The percent of the device's RE resource currently utilized. Average resources utilization in the last 5 seconds.
Last 60 sec. Average Utilization Average resources utilization in the last 10 seconds.
Accelerator Element Statistics

Only devices that support an accelerator expose accelerator element statistics.
To view accelerator element statistics Select Performance > Element Statistics > Accelerator. The Accelerator Utilization pane is displayed.
257
LinkProof User Guide Advanced Features Each table in the Accelerator Utilization pane comprises the following columns: AcceleratorThe accelerator. CPUThe CPU core identifier, starting from 0. ForwardingThe relative amount of time the accelerator core is forwarding traffic, which is the main task of the accelerator. OtherThe relative amount of time the accelerator core is handling things other than trafficMainly managing the accelerator flow database and communicating with the master. IdleThe relative amount of time that the accelerator core is idle.
IP Interface Statistics
To view IP interface statistics Select Performance > IP Statistics. The IP Statistics pane is displayed.
Table 135: IP Interface Statistics
Parameter
Interface Address
Description
The IP address of the selected interface.
RIP - response packets The number of RIP response received by the RIP process that were discarded subsequently discarded for any reason (for example, a version 0 packet or an unknown command type). RIP - routes ignored RIP - updates sent Status The number of routes, in valid RIP packets, that were ignored for any reason (for example, an unknown address family or an invalid metric). The number of triggered RIP updates actually sent on this interface. This explicitly excludes full updates sent containing new information. The status of the interfaces IP statistics. Values: valid, invalid
NHR Statistics
LinkProof exposes the following additional statistics panes: Daily Discarded Sessions Table Daily NHR Statistics Table Daily NHR Cost Statistics Table Link Quality Table
Daily Discarded Sessions Table
To view the Daily Discarded Sessions Table Select Performance > NHR Statistics > Daily Discarded Sessions Table. The Daily Discarded Sessions Table pane is displayed.
258
Table 136: Daily Discarded Sessions Table Parameters
Parameter
Month Day Discarded Sessions Number
Description
The month of the current year. The day of the displayed month. The number of discarded sessions on the displayed date.
Daily NHR Statistics Table
To view the Daily NHR Statistics Table 1. Select Performance > NHR Statistics > Daily NHR Statistics Table. The Daily NHR Statistics Table pane is displayed with a table comprising the following columns: Policy Name Packets Matched BW (Kbits) Sent BW (Kbits)
2. To view additional statistics for a server on a day, from the Month column, select the relevant link.
Table 137: Daily NHR Statistics Table Parameters
Parameter
Month Day Server Name Discarded Zone Percent Minimum Bandwidth [Kbps] Maximum Bandwidth [Kbps] Forwarded Packet Number [KB] Discarded Packet Number Forwarded Bytes Number [MB] Forwarded Sessions Number [KB]
Description
The month of the current year. The day of the displayed month. The name of the server. The percentage of time during the day that the devices upper resource-consumption threshold was reached. The minimum bandwidth for the server on the day. The maximum bandwidth for the server on the day. The number for packets that the server forwarded. The number for packets that the server discarded. The number of megabytes that were forwarded. The number of sessions that were forwarded.
Daily NHR Cost Statistics Table

The Daily NHR Cost Statistics Table displays statistics related to the Cost-based Load-balancing feature. For information on the feature, see Cost-based Load Balancing, page 247.
To view the Daily NHR Cost Statistics Table Select Performance > NHR Statistics > Daily NHR Cost Statistics Table. The Daily NHR Cost Statistics Table pane is displayed.
259
Table 138: Daily NHR Cost Statistics Table Parameters
Parameter
Month Day NHR Name Bandwidth Threshold Level Percent
Description
The month of the current year. The day of the displayed month. The name of the NHR. The upper limit of the line according to the Bandwidth Unit value. The percentage of time during the day that the Bandwidth Threshold was reached.
Link Quality Table

The Link Quality Table displays information regarding the quality of the WAN links. For each link, the latency and relative hops distance is also displayed. The table displays the best links for the top 10 destinations.
Notes: >> To enable feature, select LinkProof > Global Configuration > General > Link Quality Evaluation > Enable. >> Enabling this feature may negatively impact performance.
To view the Link Quality Table Select Performance > NHR Statistics > Link Quality Table. The Link Quality Table pane is displayed.
Table 139: Link Quality Table Parameters
Parameter
Destination Subnet Best Link Second Link Option Third Link Option
Description
The address of the destination subnet Displays the best link option. Displays the second-best link option. Displays the third-best link option.
Statistics Monitor SRP Management Host IP Address

If you use Statistics Reporting Protocol (SRP) to transmit statistical data from the LinkProof device to the Configware Insite management station, you need to first specify the IP address of the SRP management host.
Note: Statistics Reporting Protocol (SRP) is a proprietary Radware protocol for efficient transmission of statistical data from the device to the Configware Insite management station.
260
To specify the IP address of the SRP management host 1. Select Services > Statistics Monitor > SRP. The SRP Management Host IP Address pane is displayed. 2. In the SRP Management Host IP Address text box, type the IP address of the machine on which to create the statistics files. This is normally the machine on which the web-based software is running. 3. Click Set.
Caution: Since the statistics files are cumulative, you must disable the Statistic Reporting Mode before files consume too much disk space. Failure to do so can result in the creation of files that fill all available disk space.
Configuration Auditing
Configuration Auditing is the process of logging every configuration change and activity for auditing and regulation compliance purposes. When Configuration Auditing is enabled, the device keeps track of all the changes made to the configuration by sending a SNMP trap and syslog message (if syslog is enabled and configured). The device reports the following type of events: A new configuration object is createdsuch as a new farm, a server added to a farm, a newly created routing entry, and so on. For such an event, the device sends a trap that contains the CLI format of the equivalent operation (if the user created the object via Web Based Management). Edited existing configuration objectsthe device additionally reports what the old and new values of the changed parameter are. Deleted configuration objectsreported in the same CLI format.
Enabling and disabling Configuration Auditing is done using the Services menu in Web Based Management or using the CLI command services auditing status set.
Notes: >> In some cases, there is no CLI equivalent to a Web Based Management command. In such cases, the device reports the MIB name of the parameter. >> In some cases, there is no MIB parameter equivalent to a CLI command. In this case, the trap may contain the actual CLI command. Configuration audit traps will be sent when such commands are performed even if there are GET commands. >> Configuration Auditing makes the Configuration Trace feature obsolete. >> You can retrieve Configuration Auditing messages via e-mail by enabling e-mail reporting. >> You can enable or disable Configuration Auditing for all users and all management interfaces. By default, Configuration Auditing is disabled.
261
To enable configuration auditing using Web Based Management 1. 2. 3. Select Services > Auditing. The Auditing Status pane is displayed. Select enable. Click Set.
To disable configuration auditing using Web Based Management 1. 2. 3. Select Services > Auditing. The Auditing Status pane is displayed. Select disable. Click Set.
To enable configuration auditing using CLI Enter the following command:
manage auditing status set
NTP Service
Network Time Protocol (NTP) can synchronize devices by distributing an accurate clock across the network. LinkProof supports Network Time Protocol (NTP) version 4. When the NTP feature is feature is disabled, the device time and date must be set manually. When the NTP feature is enabled: The LinkProof device queries an NTP network time server for the date and time. The time zone in which the device is located is not configurable, since the device uses UTC time, meaning its internal clock is always in GMT time. The date and time provided (the network time server) affect all the device operations that require date and time validationsuch as, checking the expiration date of a client certificate (as part of its validation) or performing Certificate Revocation List (CRL) updates.
To configure the NTP parameters 1. 2. Select Services > NTP. The Network Time Protocol pane is displayed. Configure the parameters; and then, click Set.
262
Table 140: Network Time Protocol Parameters
Parameter
NTP Server Address NTP polling Interval
Description
The IP address of the NTP server. Default: 0.0.0.0 The time, in seconds, between time queries. Default: 172,800 Note: 172,800 seconds is 48 hours.
NTP Timezone
The time zone in which the device is located, relative to GMT. Values: -12:00 through +12:00 Default: 00:00 Note: The value +12:00 resolves to 12:00.
NTP Server Port NTP Status
The access port number for the NTP server. Default: 123 Enables or disables the NTP feature. Values: enable, disable Default: disable
RADIUS Service
To specify the parameters of a RADIUS Authentication server 1. Select Services > RADIUS. The RADIUS Parameters pane is displayed. 2. Configure the parameters; and then, click Set.
Table 141: RADIUS Parameters
Parameter
Main RADIUS IP Address Main RADIUS Port Number
Description
The IP address of the primary RADIUS server. Default: 0.0.0.0 The access port number of the primary RADIUS server. Values: 1645, 1812 Default: 1645
Main RADIUS Secret Backup RADIUS IP Address Backup RADIUS Port Number
The password for primary RADIUS server. The IP address of the backup RADIUS server. Default: 0.0.0.0 The access port number of the backup RADIUS server. Values: 1645, 1812 Default: 1645
Backup RADIUS Secret
The password for backup RADIUS server.
263
Table 141: RADIUS Parameters
Parameter
RADIUS Timeout
Description
The time, in seconds, that the device waits for a reply from the RADIUS server before a retry, or, if the RADIUS Retries value is exceeded, before the device acknowledges that the server is off line. Values: 110 Default: 1
RADIUS Retries
Defines number of connection retries to the RADIUS server, when the RADIUS server does not respond to the first connection attempt. Values: 13 Default: 2
RADIUS Client Lifetime
Duration, in seconds, for client authentication. After the lifetime expires, the device re-authenticates the user. Values: 153600 Default: 30
264
Chapter 6 Redundancy
This chapter describes redundancy features and provides common examples of the different LinkProof redundancy configurations. This chapter contains the following sections: LinkProof Redundancy, page 265 Proprietary ARP Redundancy, page 274 VRRP Redundancy, page 277 Remote Virtual IP Addresses, page 287
LinkProof Redundancy
This section introduces LinkProof redundancy capabilities and describes polling and teaching and how these redundancy schemes are incorporated into the LinkProof configuration. This section contains the following: Introducing LinkProof Redundancy, page 265 Active/Backup Setup, page 266 Global Redundancy Configuration, page 267 Interface Grouping, page 269 Mirroring the Client Table, page 271
Introducing LinkProof Redundancy

To provide fault tolerance in the case of device failure, Radware recommends installing LinkProof devices in pairs. LinkProof devices support a polling mechanism that allows the backup device to constantly mirror the main device and to ensure the main device is alive. A teaching mechanism is used by the backup device when the main device is down. This is how the takeover takes place. This way, one LinkProof device can always recognize whether another LinkProof device is up or down. In LinkProof, physical IP addresses are configured to poll other LinkProof physical IP addresses. In Figure 29 - LinkProof Redundancy Scheme, page 266, the interface addresses of LinkProof 2 are configured to poll the addresses of LinkProof 1 and the interface addresses of LinkProof 1 are configured to poll the addresses of LinkProof 2. The teaching process works as follows: once a LinkProof interface considers the other LinkProof interface to be down, it assumes responsibility for the failed IP address. For example, in Figure 29 LinkProof Redundancy Scheme, page 266, if LinkProof 1 fails and LinkProof 2 decides to take over operation, LinkProof 2 assumes responsibility for IP addresses of LinkProof 1. Each pair of LinkProof devices can function in an Active/Backup setup. To achieve redundancy between pairs of devices, LinkProof supports the following methods: Proprietary ARPThe device uses Address Resolution Protocol (ARP) to monitor the other device in the pair and check its availability. With Proprietary ARP redundancy, when failing over, the IP addresses of the main device are managed by the backup device and are associated with the backup devices MAC address. VRRPThe device uses Virtual Router Redundancy Protocol (VRRP), which enables maintaining dynamic redundancy using a virtual router. With VRRP redundancy, IP addresses are associated with the virtual MAC addresses owned by the main device, and when failing over, the backup device takes ownership of the IP addresses.
265
LinkProof User Guide Redundancy
Caution: If the DNAT address is not equal to the associated IP address of the device, LinkProof creates an appropriate associated IP address for the DNAT entry. In a redundant configuration, when you delete the DNAT address of the backup device, LinkProof does not delete the associated IP address that was created automatically previously for the backup device. You must delete the IP address manually.
Figure 29: LinkProof Redundancy Scheme
Router 1 Network B&C IP B 1 Port 2 MAC D
Router 2
Port 2 MAC B
IP B 2
Port 1 MAC A Network A
IP A 1
Port 1 MAC C
IP A 2
Users
Active/Backup Setup
In an Active/Backup configuration, the main LinkProof device performs regular LinkProof operation, handling all the inbound sessions to the virtual addresses and distributing traffic among the servers in the farm. The backup LinkProof device is configured with identical forms containing the exact same servers and farm settings. This device acts as a hot standby and does not perform load balancing as long as the main device is active. The backup LinkProof periodically verifies that the main device is available. When the backup LinkProof detects that the main LinkProof fails, the backup device resumes control for the IP address of its main partner, letting all devices on the network know that the backup device is now responsible for the services of the main device. When the backup device takes control over the services, it continues to monitor the main device. As soon as the main device is back online, the backup device releases the services.
266
Copying a Device Configuration for a Redundant Environment

Running LinkProof in a redundant configuration requires configuring the two peer devices almost identically. To facilitate the configuration, a LinkProof device can generate a configuration file for the peer device. And then, you can upload the configuration file to the peer. Copying a device configuration in a redundant environment involves the following: Specifying the Peer Address for each IP interface to enable redundancy on (Router > IP Router > Interface Parameters > Peer Address). Specifying the appropriate Configuration Type, Regular or Backup (File > Configuration > Receive from Device > Configuration Type). In the Download Configuration File pane, you can select the Include Private Keys check box to download the Private Key for SSH/SSL configuration, so that both devices will use the same private key. For more information, see Downloading a Configuration File, page 57.
Global Redundancy Configuration

Use the Redundancy Configuration pane to configure the redundancy parameters on the device as a whole.
To configure the global redundancy parameters 1. Select Redundancy > Global Configuration. The Global Redundancy Configuration pane is displayed. 2. Configure the parameters; and then, click Set.
Table 142: Global Redundancy Configuration Parameters
Parameter
IP Redundancy Admin Status
Description
Allows this device to function as part of a backup configuration. Values: Proprietary, Disable, VRRP Default: Disable Note: You must select VRRP to enable mirroring. For more information, see Mirroring the Client Table, page 271.
Interface Grouping
Specifies whether Interface Grouping is enabled. When Interface Grouping is enabled, if one port fails, the device takes down the other ports also, and the backup device becomes the active one only when all the interfaces of the main device are down. Values: enable, disable Default: disable Note: For more information, see Interface Grouping, page 269.
ARP with Interface Grouping
Specifies whether the device can send ARP requests with the active interface grouping. Values: Send, Avoid Default: Send
267
Table 142: Global Redundancy Configuration Parameters
Parameter
Backup-In-Vlan
Description
Specifies role of the device in a VLAN. If the main device is active, no traffic is forwarded by this redundant or backup device, Values: Active, Backup Note: If your network is set up as a VLAN, configure the backup device before you configure the main device.
Backup Fake ARP
Enables the backup device to perform a fake ARP. Values: enable, disable Default: enable Note: In networks with Layer 3 switches, the Fake ARP confuses the switch during the redundancy process. In this case, disable this option.
Backup Interface Grouping
When enabled, the backup device becomes active only when all the IP interfaces defined in the Redundancy Table fail. Values: enable, disable Default: enable
Force Down Ports Status
The status of the Force Down Ports mechanism. Values: Enable, Disable Default: Disable
Force Down Ports Time
How long, in seconds, the device keeps the ports down after a failover. Default: 5 Sends an SNMP trap with the VRRP Associate failover. Values: On, Off, Summary Default: Off
Trap VRRP Associate Addresses
IP Redundancy Table
In redundancy configurations, both LinkProof devices, the main and the backup, must be defined to work with virtual and physical addresses. The virtual IP addresses are defined on the backup LinkProof in the same manner as on the main LinkProof and the main device makes sure that the backup LinkProof supports virtual addresses. Different physical IP addresses are used for the main and backup devices, and, typically, an additional configuration is required on the redundant LinkProof to support backup for the physical IP addresses of the main device. Use the IP Redundancy Table pane to set up IP router redundancy. The IP Redundancy table is only relevant for proprietary redundancy. The following table describes the columns of the IP Redundancy table.
Table 143: IP Redundancy Table
Parameter
Interface IP Address Main Router Address
Description
The IP address of the backup interface. IP address on the main LinkProof interface, which this LinkProof is backing up.
268
Table 143: IP Redundancy Table
Parameter
Operating Status
Description
The redundancy status. Values: ActiveThe backup LinkProof is now active on this interface. InactiveThe backup LinkProof is not active.
Poll Interval Time Out
The polling interval, in seconds, for the main LinkProof interfaces. The value 0 (zero) specifies that the LinkProof device is not polled. The interval, in seconds, during which the LinkProof device must respond. If the main LinkProof does not respond within this interval, it is considered inoperative. If Time Out is 0, the backup LinkProof ignores the row.
To configure IP router redundancy 1. Select Redundancy > IP Redundancy Table. The IP Redundancy Table pane is displayed. 2. Click Create. The IP Redundancy Table Create pane is displayed. 3. Configure the parameters; and then, click Set.
Table 144: IP Router Redundancy Parameters
Parameter
Interface IP Address Main Router Address Poll Interval
Description
The IP address of the backup interface. The IP address on the main LinkProof interface, which this LinkProof is backing up. Polling interval, in seconds, for the main LinkProof interfaces. If the interval is 0, the LinkProof is not polled. Default: 3 The time, in seconds, during which the LinkProof device must respond. If the main LinkProof does not respond within this time, it is considered inoperative. Default: 12 Note: The value 0 (zero) specifies that the backup LinkProof device ignores the row.
Time Out
Interface Grouping
To provide a complete solution for redundancy against all failures, LinkProof employs a mechanism called Interface Grouping. If LinkProof notices that one of its physical ports is down, it intentionally brings all other active ports down.
269
LinkProof User Guide Redundancy When a physical port on LinkProof goes down, because of a cable failure, switch port failure, hub failure, or other problems, LinkProof performs the following tasks: 1. 2. 3. LinkProof examines the configuration to see if any IP addresses were configured on the port that just went down. If there were IP addresses configured on the port that went down, LinkProof deactivates all other active ports. If there were no IP addresses configured on the port that went down, nothing happens and normal operation continues.
Notes: >> Using Regular VLAN, when any of the ports associated with a VLAN is down, Interface Grouping is triggered. >> Using Switched IP VLAN, Interface Grouping is triggered only when all ports on a Switched IP VLAN are down. >> When using VLAN with interface groupings, a group may go down as a result of a failing interface. In such an event, all traffic to the interfaces belonging to the group will be discarded including management traffic.
Selective Interface Grouping

One of the common installations of LinkProof is the LinkProof redundancy installation. In many installations of this kind, both the main and redundant LinkProof have a separate interface for management, which is used solely for management purposes and not for handling actual traffic. A problem may occur if the management interface goes down, since it causes Interface Grouping on the main device to become activated, resulting in the backup device taking control. This issue occurs since the management interface is an IP interface, which when down, affects Interface Grouping. Using the Master Interface Grouping table, LinkProof can define which interfaces initiate interface grouping and which do not. In the Master Interface Grouping table, for each interface, you specify whether the interface initiates Interface Grouping if it goes down (interfaces Port Status is set to Included), or not.
Notes: >> If an interface, which is part of a VLAN, goes down and its Port Status is set to Included, it does not initiate Interface Grouping. >> When an interface, which has its Port Status set to Included, goes up after it goes down, Interface Grouping is turned off immediately, and the device regains control (becomes the main device). No reboot is required.
To configure the Master Interface Grouping Table 1. Select Redundancy > Master Interface Grouping Table. The Master Interface Grouping Table pane is displayed, which contains the following parameters:
Parameter
Port Number Port Status
Description
The port number (read only). Specifies whether to include or exclude the port in interface grouping.
270
LinkProof User Guide Redundancy 2. Select the relevant port number. The Master Interface Grouping Table Update pane is displayed. 3. From the Port Number Status drop-down list, select Included. 4. Click Set.
Backup Interface Grouping

The backup device takes control only if all the interfaces of the main device are out of service. This solves the following problem: if an active and a backup device, each connected to a switch, and the switches are cross-connected. When the cable cross-connecting the switches fails, this is communicated to the main device and so the interface grouping is not triggered, but the backup device cannot communicate to the main device and so the backup device takes over. This causes downtime in the service. When Backup Interface Grouping is enabled, the backup device takes over only when all IP interfaces defined in its Redundancy Table fail. Respectively, the backup device releases those interfaces only when all the main devices interfaces are up. When Backup Interface Grouping is not activated, the backup device takes control once one interface of the main device (defined in the Redundancy Table) is out of service. Respectively, the backup device releases the interface once all the interfaces of the main device are available.
To enable interface grouping and backup interface grouping 1. Select Redundancy > Global Configuration. The Global Redundancy Configuration pane is displayed. 2. From the Interface Grouping drop-down list, select enable to allow the device to be backed up by another device.
Note: The backup device is activated only when all the interfaces of the main device fail. The main device resumes control only when all interfaces resume normal functioning. 3. From the Backup Interface Grouping drop-down list, select enable to activate the backup device when all the IP interfaces defined in the Redundancy Table fail. 4. Click Set.
Mirroring the Client Table

LinkProof supports mirroring the Client table across an active device and a redundant, backup device. When LinkProof mirrors the Client Table, the main device sends a snapshot of the table information contained on the main device to the backup device. If the main device fails, the backup device seamlessly continues handling each existing session, ensuring that each request for service is forwarded to the same server in the farm that handled the session before the failover.
Notes: >> Enabling mirroring has a negative impact on LinkProof performance. The degree of the impact depends on the table sizes. >> Radware recommends that you mirror the Client table with very state-sensitive and long-term sessions, such as Telnet or FTP.
271
LinkProof User Guide Redundancy >> You should not mirror the Client table with HTTP applications where sessions are short and a reload mechanism is built-in or transparent. >> You should not mirror the Client table in conjunction with the Dynamic Session ID Tacking feature. >> When enabling mirroring on a backup LinkProof device, the device must be reset. >> When setting up mirroring, Radware recommends that you use the same LinkProof software version for the main and for the backup devices. >> Radware recommends that you not configure mirroring in conjunction with Layer 7 features that require Delayed Bind. This includes Dynamic session ID Persistency, Layer 7 Policies, SSL ID tracking, and so on. For effective and reliable mirroring, do the following: Provide a direct connection between the two devices. An IP interface must be configured on each device for the direct connection port and address used as the Mirroring Device Address for the other device. Exclude physical port used for inter-device communication from Interface grouping. Use a trunk (link aggregation) for direct connection between two devices. Mirroring parameters must be configured on the main device and on the backup device. The devices must be configured using VRRP. For more information, see Global Redundancy Configuration, page 267. The IP address must be defined on dedicated ports (not used for other proposes); and the IP addresses must not be a VRRP-associated IP address. For more information, see VRRP Associated IP Addresses, page 286.
Caution: Mirroring works differently depending on the specified Priority and Preemption Mode of the VRRP redundancy configuration (see Configuring Basic VRRP Redundancy, page 285). The device with the higher priority is the main device. The specified Preemption Mode affects the values you must choose when you configure mirroring. The following tables describe the required values for the main and backup devices according to whether Preemption Mode in the VRRP configuration is true or false.
Table 145: Required Values for Main and Backup Devices with VRRP Preempt Mode = True
Main Device Parameter Path

Redundancy > Mirroring > Active Device Parameters > Client Table Mirroring Redundancy > Mirroring > Backup Device Parameters > Mirroring Status
Backup Device Required Value Parameter Path Required Value
enable (if you Redundancy > Mirroring > Active disable want the table Device Parameters > to be Client Table Mirroring mirrored) disable Redundancy > Mirroring > Backup Device Parameters > Mirroring Status enable
272
Table 146: Required Values for Main and Backup Devices with VRRP Preempt Mode = False
Main Device Parameter Path

Redundancy > Mirroring > Active Device Parameters > Client Table Mirroring Redundancy > Mirroring > Backup Device Parameters > Mirroring Status
Backup Device Required Value Parameter Path Required Value

enable (if you want the table to be mirrored) enable
enable (if you Redundancy > Mirroring > Active want the table Device Parameters > to be Client Table Mirroring mirrored) enable Redundancy > Mirroring > Backup Device Parameters > Mirroring Status
Configuring Mirroring on the Active Device
To configure the active-device mirroring parameters 1. Select Redundancy > Mirroring > Active Device Parameters. The Mirroring: Active Device Parameters pane is displayed. 2. Configure the parameter; and then, click Set.
Table 147: Active-Device Mirroring Parameters
Parameter
Client Table Mirroring
Description
Enables or disables the mirroring of the Client Table. Values: enable, disable Default: disable
Configuring Mirroring on the Backup Device
To configure backup-device mirroring parameters 1. Select Redundancy > Mirroring > Backup Device Parameters. The Mirroring: Backup Device Parameters pane is displayed. 2. From the Mirroring Status drop-down list, specify whether to enable or disable mirroring of the Client Table. Values: enable, disable. Default: disable. 3. Click Set.
Configuring the IP Address of the Mirrored Device
To configure the IP address of the mirrored device 1. Select Redundancy > Mirroring > Mirror Device Parameters. The Mirroring: Device Parameters pane is displayed. 2. Click Create. The Mirror Device Parameters Create pane is displayed.
273
LinkProof User Guide Redundancy 3. In the Mirror Device IP text box, type the IP address of the other device. That is, if you are configuring mirroring on the main device, type the IP address of the backup device here; and if you are configuring mirroring on the backup device, type the IP address of the main device here. Click Set.
4.
Proprietary ARP Redundancy

This section describes how a LinkProof device uses Address Resolution Protocol (ARP) to check the availability of its partner. The ARP method ensures that the LinkProof device is available and that the network connections between the devices are up. The section contains the following topics: Proprietary ARP, page 274 Backup Fake ARP, page 274 Advanced Forwarding, page 276
Proprietary ARP
With the Proprietary method, the LinkProof device uses Address Resolution Protocol (ARP) to check the availability of the partner. The ARP method ensures that the LinkProof device is available and that the network connections between the devices are up. If the main device fails, the backup device takes control and continues seamlessly operating between clients and servers that had been established on the primary device. With Proprietary ARP redundancy, the backup device manages the polling process by continuously polling the main device, using the ARP protocol. When the main device fails, the teaching process is realized when the backup device sends broadcast ARPs informing its network neighbors that the IP addresses of the main device are now associated with its own MAC addresses. This ensures that all traffic destined to the IP addresses of the main device arrives at the backup device. The following table describes the parameters that the backup uses to poll the main device.
Table 148: Polling Parameters
Parameter
Polling Interval Timeout
Description
How often, in seconds, the backup device polls the main device. Default: 3 The number of polling attempts that are made before the backup device takes over. Default: 12
Backup Fake ARP

When two LinkProof devices are working in the redundant mode, the backup device constantly monitors the health of the main device. Once the backup device detects that the main device fails, the backup device takes control, which means that the backup device now owns the IP addresses of the main device. The backup device sends gratuitous ARP to all local stations informing that the main device IP addresses now correspond to the MAC addresses of the backup device. This process ensures smooth redundancy from the main device to the backup. When the main device is operational again, it uses the same technique. The main sends gratuitous ARP to all local stations informing them that the main device IP addresses now correspond to the MAC addresses of the main device. To speed up this process, the backup device also publishes that the IP addresses of the main correspond to the MAC addresses of the main device. This is a fake
274
LinkProof User Guide Redundancy ARP, as one device (the backup) publishes the other device (the main). The fake ARP might confuse some Layer 3 switches, as they update their ARP Tables by the source MAC of the packet, rather than by the MAC in the information part of the packet. The Backup Fake ARP option is enabled by default and can be disabled if needed.
Backup Device in VLAN

To avoid broadcast storms, using redundancy with bridging, the backup device must remain completely silent on the network. This behavior must be set using the Backup Device in VLAN parameter. To enable backup fake ARP and the backup device in a VLAN, enable the Backup Fake ARP and Backup-In-Vlan parameters in the procedure in Global Redundancy Configuration, page 267.
Example Proprietary Redundancy with Routing

The following diagram shows a scheme for a proprietary redundancy configuration with routing.
Figure 30: Proprietary Redundancy with Routing
Router 1 100.1.1.20
Router 2 200.1.1.20
Interface 2 100.1.1.10 200.1.1.10
Interface 2 100.1.1.11 200.1.1.11
Interface 1
10.1.1.10
Interface 1
10.1.1.11
275
Example Proprietary redundancy with bridging

The following diagram illustrates the scheme for proprietary redundancy with bridging. The network side and server side are on the same IP subnet.
Figure 31: Proprietary Redundancy with Bridging
Router 1 100.1.1.20
Router 2 200.1.1.20
Interface 2 200.1.1.10
Interface 2 200.1.1.11
LinkProof 1 Interface 1 100.1.1.10
LinkProof 2 Interface 1 100.1.1.11
Advanced Forwarding
The LinkProof routing mechanism includes a table called IP Fast Forwarding Table (IPFFT). IPFFT includes routing information for the purpose of saving CPU time while calculating routing decisions. A large IPFFT (over 100,000 entries) or IPFFT that overflows due to lots of traffic needs to be routed. IPFFT use may impair the overall performance of the LinkProof device. The Advanced Forwarding feature uses a more efficient algorithm in the IPFFT that can keep it the IPFFT small. The IPFFT is cleared at the following times: When the device restarts When the relevant physical port is disconnected When you enter the following CLI command:
net route fast-forwarding-table clear
276
To configure advanced forwarding using Web Based Management 1. Select Router > IP Router > Operating Parameters. The IP Router Parameters pane is displayed. 2. From the ARP Proxy drop-down list, select enable or disable to specify whether the device responds to ARP requests for nodes located on a different direct sub-net. The device responds with its own MAC address. Values: enableThe device responds to all ARP requests. disableThe device responds only to ARP requests for its own IP addresses.
Default: disable 3. From the Advanced Fast Forwarding Status drop-down list, select Enable or Disable. 4. Click Set.
To configure advanced forwarding using CLI Enter the following command:
net route advanced-forwarding set <disable|enable>
VRRP Redundancy
This section describes redundancy in LinkProof using Virtual Router Redundancy Protocol (VRRP). This section contains the following topics: Introducing VRRP, page 277 VRRP Associated IP Addresses, page 286 Direct Server Connection with VRRP, page 283 Configuring Basic VRRP Redundancy, page 285
Introducing VRRP
VRRP, defined in RFC 2338, is a standard protocol that enables dynamic router redundancy. If the main device fails, VRRP ensures that the backup device takes over, and traffic is forwarded to it. VRRP redundancy uses virtual routers (VRs) that function as a router/gateway for the network; and all traffic is forwarded to the VRs to and from the networkmuch like a physical router. You can configure multiple LinkProof devices can be configured to achieve a full redundancy scheme between any number of devices (NN redundancy). Typically, you configure the same VR on multiple LinkProof devices to achieve redundancy between the devices for the VR. Each device has a priority for a VR; the main device for the VR is the device with the highest priority. Using VRRP, the main device constantly sends advertisements to other VRRP routers, to indicate that it is online. When the advertisements stop, the main device is assumed to be inactive. A new main device is then selected for the VR. The new device is the device with the next highest priority for the VR.
277
LinkProof User Guide Redundancy A VR has a Virtual Router Identifier (VR ID) and one or more IP addresses associated with it (Associated IP addresses). Each VR ID must be unique for the system, even if the IDs relate to different interfaces. If two LinkProof devices belong to the same subnet, and each device is backed up by a VR, the VR IDs for both devices must also be different.
Notes: >> LinkProof uses the term Associated IP to refer to the IP address associated with the interface index and the VR ID. Other vendors may refer to the Associated IP as a virtual IP (VIP) or a floating IP, because it floats between the primary and standby devices being used by whichever device takes ownership of the configuration. >> Each VR has a VRMAC address, which is a MAC address associated with the VR. The VRMAC address eliminates the need for a MAC-address update in case of a fail-over. The VRMAC address is determined by the VR ID. You do not need to configure the VR MAC address manually. >> VRRP is not supported in a Regular VLAN network configurationexcept for configurations using Direct Server Connection. For more information, see Direct Server Connection with VRRP, page 283. >> When working with a VRRP configuration, Radware strongly recommends that you enable Interface Grouping. You associate the interfaces that are used by the redundant configuration to the relevant group.
Caution: Interface grouping (see Interface Grouping, page 269) is disabled by default, but, when interface grouping is enabled: >> By default, all of the device interfaces are included in the Master Interface Grouping, and if any of the interfaces in the group fails, the entire device is declared down and the VR fails over (master switches to backup). >> If the status of a certain VR ID is Disabled, then either all VR IDs on that device are disabled too, or all copies of that VR ID on other devices are disabled as well. >> If, on a certain interface, a LinkProof device has IP addresses that belong to a subnet whose backup device is not on that interface, you must configure the LinkProof device with a primary IP address that belongs to a subnet that the backup device has. >> Upon creating a VR on a port, there must be at least one IP interface configured on the physical port. >> Ensure that the same parameters are configured on both devices for each VR ID.
Example Redundant LinkProof Configuration with VRRPVR IP Address Uses the IP Address of One of the Physical Interfaces of the Primary Device
This example configuration delivers a fully redundant solutionboth for outbound and inbound connections. Assume two LinkProof devices. One device acts as the primary. The other device acts as the secondary. The VR IP address uses the IP address of one of the physical interfaces of the primary device.
Note: The VR priority for the primary device must be 255 in order to use the physical interface IP address.
278
LinkProof User Guide Redundancy Figure 32 - Redundant LinkProof Configuration with VRRPVR IP Address Uses the IP Address of One of the Physical Interfaces of the Primary Device, page 279 shows the example configuration. Figure 33 - Configuration of Redundant LinkProof Devices with VRRPVR IP Address Uses the IP Address of One of the Physical Interfaces of the Primary Device, page 280 describes the flow of the configuration procedure.
Figure 32: Redundant LinkProof Configuration with VRRPVR IP Address Uses the IP Address of One of the Physical Interfaces of the Primary Device
Internet
External Router 01
External Router 02
External Segment
172.16.24.10 LinkProof 01 Primary 192.168.10.10
Virtual Router 172.16.24.10
172.16.24.11 LinkProof 02 Secondary
192.168.10.11
Internal Segment
Users
279
Figure 33: Configuration of Redundant LinkProof Devices with VRRPVR IP Address Uses the IP Address of One of the Physical Interfaces of the Primary Device
Alternatively, you can: 1) Create VRs 2) Create associated IP addresses 3) Up all VRs Configure the following on each device: Interfaces IP Addresses Routing Farm and flows NAT
Enable VRRP
Create a VR with State = Down
Configuring the primary device
Yes
Set VR priority = 255
No Set VR priority less than 255 (for example, 100)
Create Associated IP address for VR
Change VR state = Up
More VRs to configure?
Yes
No
Create Associated IP address for the NAT address
Yes
Using NAT?
No
Require pinging the VR IP or have a VDNS?
Yes
Create a Remote VIP or VDNS IP
No
Create associated IP addresses for the VIP or VDNS
Check failover configuration
280
Example Redundant LinkProof Configuration with VRRPVR IP Address Uses an IP Address Different from the Physical Interfaces of the Primary Device
This example configuration delivers a fully redundant solutionboth for outbound and inbound connections. Assume two LinkProof devices. One device acts as the primary. The other device acts as the secondary. The VR IP address uses an IP address different from the IP addresses of the physical interfaces of the primary device. Figure 34 - Redundant LinkProof Configuration with VRRPVR IP Address Uses an IP Address Different from the Physical Interfaces of the Primary Device, page 281 shows the example configuration. Figure 33 - Configuration of Redundant LinkProof Devices with VRRPVR IP Address Uses the IP Address of One of the Physical Interfaces of the Primary Device, page 280 describes the flow of the configuration procedure.
Figure 34: Redundant LinkProof Configuration with VRRPVR IP Address Uses an IP Address Different from the Physical Interfaces of the Primary Device
Internet
External Router 01
External Router 02
External Segment
172.16.24.10 LinkProof 01 Primary 192.168.10.10
172.16.24.11 LinkProof 02 Secondary
192.168.10.11
Internal Segment
Users
281
Figure 35: Configuration of Redundant LinkProof Devices with VRRPVR IP Address Uses an IP Address Different from the Physical Interfaces of the Primary Device
Alternatively, you can: 1) Create VRs 2) Create associated IP addresses 3) Up all VRs Configure the following on each device: Interfaces IP Addresses Routing Farm and flows NAT
Enable VRRP
Create a VR with State = Down
Configuring the primary device?
Yes
Set VR priority = 200
No Set VR priority less than 200 (for example, 100)
Create Associated IP address for VR
Change VR state = Up
More VRs to configure?
Yes
No
Create Associated IP address for the NAT address
Yes
Using NAT?
No
Require pinging the VR IP or have a VDNS?
Yes
Create a Remote VIP or VDNS IP
No
Create associated IP addresses for the VIP or VDNS
Check failover configuration
282
Direct Server Connection with VRRP

VRRP with Switched IP VLAN allows direct connection of servers to LinkProof in conjunction with routing and bridging. In this configuration, servers with dual network interface controllers (NICs) are directly connected to LinkProof devices. LinkProof uses routing (see Figure 36 - Direct Server Connection with VRRP and Routing, page 284) or bridging (see Figure 37 - Redundant LinkProof Configuration with VRRP and Direct Connection, page 285) between the external network connected to routers or switches, and the internal network connected to servers. Servers are connected directly to the interfaces of LinkProof. A cross cable is required to connect the two LinkProof devices together (using Giga, or Fast Ethernet ports). The interfaces to which the servers are connected and the interface used for connecting the two LinkProof devices, are associated to a Switched IP VLAN. This puts all the servers on a single switch. Using bridging, you need to configure a Regular VLAN including the switch IP VLAN and the LinkProof interface to the external side. This creates a bridge between the Switched VLAN and the interface to the external side. When needed, multiple LinkProof interfaces can be added to this Regular VLAN. Using routing with Layer 2 or Layer 3 switches, either connecting LinkProof and servers or connecting LinkProof to the external subnet, you must avoid configuration that contains a loop. For example, having a cross cable between the switches as well as between LinkProof devices, or connecting each LinkProof to two (2) cross-connected switches where the two (2) connections are on the same Switched IP VLAN on LinkProof, must be avoided. The configuration properties of the examples shown in Figure 36 - Direct Server Connection with VRRP and Routing, page 284 and Figure 37 - Redundant LinkProof Configuration with VRRP and Direct Connection, page 285 are as follows: Direct Server Connection with Routing is supported with VRRP and Switched IP VLAN only. Firewalls are connected directly to the interfaces of LinkProof. Cross cables are required in order to connect the two LinkProof devices together (using Giga, or Fast Ethernet ports). The interfaces to which the firewalls are connected to and the interface used for connecting the two LinkProof devices are associated to a Switched IP VLAN. This puts all the firewalls on a single switch. An IP address (from the blue subnet) should be associated with the Switched IP VLAN in each device. The LinkProof configuration and redundancy configuration does not change from the regular setup. The default gateway of firewalls and routers is the IP address of the respective Switched IP VLAN of the active LinkProof.
Note: When using dual NICs, where the active NIC is determined by pinging the default gateway, set a virtual DNS with IP 10.1.1.20 on the LinkProof device. This IP should be the default gateway of the servers. In the Associated IP Addresses Table pane, configure the following entries: Interface=100002, VRID=10, Associated IP=10.1.1.20. LinkProof is using routing between the blue subnet (of the firewalls) and the orange (routers) subnet. This is essential in order to avoid loops in the network. When adding or removing ports to a Switch IP VLAN that is already associated to a VRID, you must set the VR ID Admin Status to Down, make the change and then set the VR ID Admin Status to Up again.
283
Figure 36: Direct Server Connection with VRRP and Routing

Routers
Switch IP VLAN 1 on LinkProof-L
Switch IP VLAN 1 on LinkProof-R
Switch IP VLAN 2 on LinkProof-L
Switch IP VLAN 2 on LinkProof-R
Interface Grouping Used with Direct Connection

To support redundant configuration with direct server connectivity, the interface grouping operation is modified. Interface grouping is always part of the LinkProof redundancy mechanism. Enabling interface grouping on the main device ensures that if one of the interfaces of the device fails, the device closes all its other interfaces and becomes invisible to the network. Using switched VLAN, the grouping takes place only when all interfaces that were configured in a switched VLAN are down. Interface grouping is released when the all interfaces in a switched VLAN are up. Using Switched VLAN as part of a Regular VLAN, grouping takes place only when all interfaces in a Switched VLAN are down, or when any other port in the Regular VLAN is down. Interface grouping is released when all interfaces in a switched VLAN are up and when all other ports in the Regular VLAN are up.
Example Redundant LinkProof Configuration with VRRP and Direct Connection

The following diagram, Figure 37 - Redundant LinkProof Configuration with VRRP and Direct Connection, page 285, illustrates the scheme for a redundant LinkProof configuration with VRRP and direct connection. VRRP with Switched IP VLAN allows direct connection of servers to LinkProof. Figure 37 - Redundant LinkProof Configuration with VRRP and Direct Connection, page 285 configuration properties: Firewalls are directly connected to LinkProof, possibly with dual NIC. Each router is connected directly to a different LinkProof and they are inter-connected as well (subnet 30.1.1.x). Route towards the other router should be configured on each router. Network side and server side are on different subnets. The virtual IP addresses served by the LinkProof devices are 100.1.1.100 and 200.1.1.100 usually handled by LinkProof 1. Firewalls 10.1.1.1 and 10.1.1.2 are assigned to the farm managed by LinkProof 1. Redundancy is performed using the VRRP protocol.
284
Figure 37: Redundant LinkProof Configuration with VRRP and Direct Connection
Router 1 30.1.1.1 30.1.1.2 Router 2
100.1.1. 20 Port 1 Port 5
Switched IP VLAN Switched IP VLAN 100.1.1.10 100.1.1.11 200.1.1.10 200.1.1.11 Regular 100.1.1.100 Backup 200.1.1.100 Port 5 Port 2 Port 3
200.1.1 .20 Port 1
Port 2 Port 4 Switched IP VLAN 10.1.1.10
Port 4
Dual NIC
Switched IP VLAN 10.1.1.11
Firewall 1 10.1.1.1
Firewall 2 10.1.1.2
Configuring Basic VRRP Redundancy

Caution: For mirroring, Radware strongly recommends that you use a dedicated management port to prevent packet loss while under stress. For more information on mirroring, see Mirroring the Client Table, page 271.
To enable redundancy with VRRP 1. Select Redundancy > Global Configuration. The Global Redundancy Configuration pane is displayed. 2. From the IP Redundancy Admin Status drop-down list, choose VRRP. 3. Click Set.
To configure basic VRRP redundancy 4. Select Redundancy > VRRP > VR Table. The Virtual Router Table pane is displayed. 5. Click Create. The Virtual Router Table Create pane is displayed. 6. Configure the parameters; and then, click Set.
285
Table 149: Virtual Router Parameters
Parameter
If Index
Description
The interface identifier. Values: The traffic ports (not MNG ports) on the device 100001
VR ID Admin Status Priority
The virtual routers identification number. Values: 1255 The status of the port. Values: Up, Down Priority is defined with the values 1255, where the highest priority of 255 should be assigned to the primary VR. Values: 1255
Caution: If the Preemption Mode is False, you must not specify the value 255. Primary IP Authentication Type Authentication Key Advertise Interval Preemption Mode The primary IP address. The device adds a default value unless the you define one. The type of authentication. Values: No Authentication, Text Authentication Password, up to eight (8) characters. The interval, in seconds, at which packets are checked. Default: 1 Specifies the takeover procedure for the VR when a device fails and then resumes functioning. When a device with a certain priority fails, the device with the next highest priority to that of the first device takes control of the VR. Then, when the device with the higher priority for this VR resumes functioning, the Preempt Mode determines whether it retakes control of the VR from the device with the lower priority. Values: TrueThe device with the higher priority takes over the VR. FalseThe device with the lower priority maintains control of the VR. This mode is only applicable when more than two devices share a VR. Default: True Note: The exception to the above description is that the router that owns the IP address(es) associated with the virtual router always preempts, independent of the setting of this flag. Protocol The protocol. For LinkProof, this is IP. Value: IP
VRRP Associated IP Addresses

The Associated IP is the IP address associated with the interface index and the VR ID. An Associated IP is used in NAT configurations. Other vendors may refer to the Associated IP as a virtual IP (VIP)
286
LinkProof User Guide Redundancy or a floating IP, because it floats between the primary and standby devicesbeing used by whichever device takes ownership of the configuration.
To configure the VRRP associated IP addresses 1. Select Redundancy > VRRP > Associated IP Addresses. The Associated IP Addresses pane is displayed. 2. Click Create. The Associated IP Addresses Create pane is displayed. 3. Configure the parameters; and then, click Set.
Table 150: Associated IP Addresses Parameters
Parameter
If Index
Description
The interface identifier. Values: The traffic ports (not MNG ports) on the device 100001
VR ID Associated IP
The identification number of the virtual router. Values: 1255 The IP address associated with the interface index and the VR ID.
Remote Virtual IP Addresses

A remote virtual IP address (remote VIP) is a virtual IP address used by a VRRP redundant configuration to provide additional functionality to the VRRP configuration. Typically, you use a remote VIP when the VRRP configuration (the VIP address) needs to be accessed from the external network. Typical advantages of remote VIP: Being able to ping the VIP Checking the VIP availability by third-party devices Virtual DNS (VDNS), which you can configure also from the VDNS table (LinkProof > DNS Configuration > DNS Virtual IP).
Note: The functionality of Remote VIP and DNS VIP are identical. If you have configured DNS VIP, there is no need to configure a remote VIP. DNS VIP is used mainly when LinkProof provides redundant DNS functionality. In redundant configurations, you need to configure a remote virtual IP address where the regular (main) and backup device provide functionality and access to a service on the same specific IP address. A remote VIP is used as a virtual router IP address on top of the original Associated IP that represents the devices VRRP configuration. The remote virtual IP address needs to be associated with one physical interface on the device. You configure the same remote virtual IP address on both devices.
287
Example Remote Connectivity Checks

In a redundant configuration, configure remote connectivity checks using a remote virtual IP. Connectivity checks are typically performed by a ping sent from the LinkProof device and a network element, such as a firewall. In this setup, the internal LinkProof can use a remote connectivity check to check the connectivity between the firewalls to the external LinkProof. This connectivity check is typically performed by a ping sent from the internal to the external device, or vice versa. In a redundant configuration, when the main device is active, the backup device answers ARPs with the IP address of the main device. However, so as not to create network problems, the backup device does not respond to pings or SNMP requests in the same way. If the main device fails, the backup device does not answer remote connectivity checks. A remote virtual IP can solve this problem. The remote virtual IP is always online. Usually, the main device owns the remote virtual IP. The backup device takes ownership when the main device fails.
To enable redundancy with VRRP 1. 2. 3. Select Redundancy > Global Configuration. The Global Redundancy Configuration pane is displayed. From the IP Redundancy Admin Status drop-down list, choose VRRP. Click Set.
Caution: Make sure to configure the remote virtual IP address on the main device and backup device.
To configure a remote virtual IP address 1. 2. 3. Select LinkProof > Remote Virtual IP Table. The Remote Virtual IP Table pane is displayed. Click Create. The Remote Virtual IP Table Create pane is displayed. Configure the parameters; and then, click Set.
Table 151: Remote Virtual IP Address Parameters
Parameter
Remote Virtual IP Redundancy Mode
Description
Specifies the remote virtual IP address. Specifies the redundancy mode of the current device. Values: regularFor the active device backupFor the backup device Default: regular
288
Chapter 7 Security
This chapter provides a general overview of the Security modules and sub-modules that LinkProof supports. This chapter contains the following sections: Security Introduction, page 289 Update Security Policies, page 290 Configuring Access for Physical Ports, page 290 SNMP, page 291
Security Introduction
This section contains the following topics: SYN Floods TCP-Handshake-Timeout
Note: Some Security features are displayed in the user interface but are currently nonoperational and reserved for future use. Radwares LinkProof Security module performs deep packet inspection at multi-Gigabit speed to provide security from the network layer up to the application layer, protecting against viruses, worms, DoS attacks and intrusions, and anomalies. LinkProof provides secure Internet connectivity with high performance, maintaining legitimate user traffic with advanced mitigation tools that focus on SYN Flood attacks. Some features of the Security module are available only with the Security license.
SYN Floods
A SYN flood is a form of denial-of-service attack in which an attacker sends a succession of SYN requests to a targets system followed by no follow-up packets. LinkProof provides protection against any type of SYN-flood attack, irrespective of the tools that are used to launch the attack. This protection service utilizes a mechanism called SYN Cookies, which performs delayed binding (terminates TCP sessions) and inserts a certain signature into the TCP sequence field. SYN Flood Protection is a service intended to protect the hosts located behind the device and the device itself from SYN flood attacks by performing delayed binding. The SYN Flood attack is performed by sending a SYN packet without completing the TCP three-way handshake. Another type of SYN Flood attack is done by completing the TCP three-way handshake, but no data packets are sent afterwords. Radware provides complete protection against both types of SYN Flood attacks. After the completion of the three-way handshake, LinkProof only processes requests that include the signature that was inserted previously. This mechanism guarantees that only legitimate requests are sent to the servers, while half open TCP connections, aimed to consume servers resources, are terminated by the LinkProof and do not flood the servers, as well as the LinkProof itself. The attacks are detected and blocked by means of SYN Flood Protection Policies. The reports regarding the current attacks appear in the Active Triggers table.
289
LinkProof User Guide Security
TCP-Handshake-Timeout
The Timeout for SYN option enables the protection of the Client Table against SYN attacks that occur during the TCP handshake process. When a client sends SYN to the Layer 4 Policy, LinkProof selects a server, adds a new entry to the Client Table, and forwards SYN to the selected server. If, during a predefined period of time (which can last for 1 to 10 seconds), no additional response arrives from this client, it is regarded as a SYN attack. The entry is then deleted from the Client Table and a reset command is sent to the server, releasing the resources allocated to this session.
Note: The Timeout for SYN parameter is applicable only when the Open Entry When Source Port Different or the Select New Server When Source Port Different parameters are enabled. The Timeout for SYN parameter applies only to TCP sessions. You can enter the value, in seconds, that LinkProof assigns to a new session started by a SYN packet. This value applies when no further traffic is received from the client. Then, the entry is removed from the Client Table and a reset is sent to the server.
Update Security Policies

Use the Activate the latest changes pane to activate the inactive policies.
To activate inactive policies 1. 2. Select Security > Update Policies. The Activate the latest changes pane is displayed. Click Set.
Configuring Access for Physical Ports

Access to any of the devices can be limited to specified physical interfaces. Interfaces connected to insecure segments of a network can be configured to discard some or all kinds of management traffic directed at the device itself. Administrators can allow certain types of management traffic (such as SSH) to be directed to a LinkProof device, while denying others (such as SNMP or Telnet). If an intruder attempts to access the device through a disabled port, the device does not allow access and generates syslog and CLI traps notifications.
To configure the management ports 1. 2. 3. Select Security > Management Ports. The Management Ports Table pane is displayed. Select a port. The Management Ports Table Update pane is displayed. Configure the parameters; and then, click Set.
290
Table 152: Management Port Parameters
Parameter
Port Number SNMP
Description
Displays the ID number of each physical port. Displays access permission for SNMP configuration for each management port. Values: Enable, Disable Default: Enabled
Telnet
Displays access permission for Telnet configuration for each management port. Values: Enable, Disable Default: Enabled
SSH
Displays the access permission for SSH configuration for each management port. Values: Enable, Disable Displays the access permission for SSL configuration for each management port. Values: Enable, Disable Default: Enabled
SSL
Web
Displays access permission for Web Based configuration for each management port. Values: Enable, Disable Default: Enabled
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. LinkProof supports 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 the entities that interface to the actual device being managed allowing changing or retrieving objects in the device. These objects are arranged in a management information base (MIB). SNMP is the protocol that allows managers and agents to communicate for the purpose of accessing these objects. This section contains the following topics: SNMP Global Parameters, page 292 SNMP User Table, page 292 SNMP Community Table, page 293 SNMP Groups Table, page 293 SNMP Access Table, page 294 SNMP View Table, page 294 SNMP Notify Table, page 295 Target Parameters Table, page 295 Target Address Table, page 296 Creating an SNMP User, page 297
291
SNMP Global Parameters
To set the SNMP Global parameters 1. 2. Select Security > SNMP > Global Parameters. The SNMP Global Parameters pane is displayed. Configure the parameters; and then, click Set.
Table 153: SNMP Global Parameters
Parameter
Supported SNMP Versions After Reset SNMP Port SNMP Status
Description
SNMP versions that will be supported by the SNMP agent after resetting the device. Select the check box for the SNMP version you wish to support. Clear the check box for the versions not supported. UDP port on which the agent is listening for SNMP requests. Status of the SNMP agent. Default: Enable
SNMP User Table

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 pane.
To define a new user 1. 2. 3. Select Security > SNMP > User Table. The User Table pane is displayed. Click Create. The User Table Create pane is displayed. Configure the parameters; and then, click Set.
Table 154: SNMP User Parameters
Parameter
User Name Authentication Protocol Authentication Password Privacy Protocol
Description
Type name of the new user, up to 18 characters. Type protocol to be used during authentication process. Default: None, meaning using clear text during the session. Values: MD5, SHA Enter an authentication password. Algorithm to be used for encryption. Values: DES NoneThe data is not encrypted. Default: None
Privacy Password
Enter a user privacy password.
292
SNMP Community Table

You can map community strings into user names and vice versa using the SNMP Community Table pane. This table restricts the range of addresses from which SNMP requests are accepted and to which traps may be sent. The SNMP Community Table is used only for SNMP versions 1 and 2.
To configure the SNMP Community Table 1. Select Security > SNMP > Community Table. The SNMP Community Table pane is displayed. 2. Click Create. The SNMP Community Table Create pane is displayed. 3. Configure the parameters; and then, click Set.
Table 155: SNMP Community Parameters
Parameter
Index Community Name Security Name Transport Tag
Description
A descriptive name for this entry. The community string. User name associated with community string. Specifies a set of target addresses from which the SNMP accepts SNMP requests and to which traps may be sent. Target addresses identified by this tag are defined in the target address table, If this string is empty, addresses are not checked when an SNMP request is received or when a trap is sent. If this string is not empty, the transport tag must be contained in the value of the tag list of at least one entry in the target address table.
SNMP Groups Table

You can associate users with groups in the Groups Table pane. Access rights are defined for groups of users.
To configure the SNMP Groups Table 1. Select Security > SNMP > Groups Table. The Group Table pane is displayed. 2. Click Create. The Group Table Create pane is displayed. 3. Configure the parameters; and then, click Set.
Table 156: SNMP Group Parameters
Parameter
Security Model Security Name Group Name
Description
Select SNMP version for association with this group. Values: SNMPv1, SNMPv2, UserBased (SNMPv3) Select relevant security name, that is the name as defined in the Users Table. Select name from list of all available group names.
293
SNMP Access Table

You can define the access rights for each group and security model in the Access Table pane.
To configure the SNMP Access Table 1. 2. 3. Select Security > SNMP > Access Table. The Access Table pane is displayed. Click Create. The Access Table Create pane is displayed. Configure the parameters; and then, click Set.
Table 157: SNMP Access Parameters
Parameter
Group Name Security Model
Description
The name of your group. 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, SNMPv2, UserBased (SNMPv3) Default: SNMPv1
Security Level
The relevant Security Levels. Values: NoAuthNoPrivNo authentication or privacy are required. AuthNoPrivAuthentication is required, but Privacy is not required. AuthPrivBoth authentication and privacy are required. Default: NoAuthNoPriv
ReadView Name WriteView Name NotifyView Name
Name of one or more entries in View Tree Family Table. Specifies which objects in the MIB tree are readable by this group. Name of one or more entries in View Tree Family Table. Specifies which objects in the MIB tree are writable by this group. Name of one or more entries in View Tree Family Table. Specifies which objects in the MIB tree can be accessed in notifications (traps) by this group.
SNMP View Table

Use the View Table pane 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. 2. 3. Select Security > SNMP > View Table. The View Table pane is displayed. Click Create. The SNMP View Table Create pane is displayed. Configure the parameters; and then, click Set.
294
Table 158: SNMP View Parameters
Parameter
View Name Subtree Subtree Mask Type
Description
Name of this entry. Object ID of a subtree of the MIB. Subtree mask of the MIB. Defines whether an object defined in this entry should be included or excluded in the MIB view. Values: included, excluded Default: included
SNMP Notify Table

Use the Notify Table pane to select management targets that receive notifications including the type of notification to be sent to each selected management target.
To configure the SNMP Notify Table 1. Select Security > SNMP >Notify Table. The Notify Table pane is displayed. 2. Click Create. The Notify Table Create pane is displayed. 3. Configure the parameters; and then, click Set.
Table 159: SNMP Notify Parameters
Parameter
Name Tag
Description
A descriptive name for this entry. This string selects one or more entries in the Target Address table. All entries in the Target Address table whose tag list contains this tag are selected for reception of notifications.
Target Parameters Table

Use the Target Parameters Table pane to configure message generation. Entries in the table are referenced in the Target Address Table pane.
To configure the SNMP Target Parameters Table 1. Select Security > SNMP > Target Parameters Table. The Target Parameters Table pane is displayed. 2. Click Create. The Target Parameters Table Create pane is displayed. 3. Configure the parameters; and then, click Set.
295
Table 160: Target Parameters
Parameter
Name Message Processing
Description
Name of this entry. The Message Processing protocol. Values: SNMPv1 SNMPv2c SNMPv3 Default: SNMPv1
Security Model
The SNMP version that represents the required Security Model. Security models are predefined sets of permissions that can be used by the groups. These sets are defined according to the SNMP versions. By selecting the SNMP version for this parameter, you determine the permissions set to be used. Values: Any, SNMPv1, SNMPv2, UserBased (SNMPv3) Default: SNMPv1
Security Name Security Level
The name of the user. The relevant Security Level. Values: NoAuthNoPrivNo authentication or privacy is required. AuthNoPrivAuthentication is required, but Privacy is not required. AuthPrivBoth authentication and privacy are required. Default: NoAuthNoPriv
Target Address Table

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 pane. Use the Target Address Table pane to set and update the SNMP Target parameters.
To configure the SNMP Target Address Table 1. 2. 3. Select Security > SNMP > Target Address Table. The Target Address Table pane is displayed. Click Create. The Target Address Table Create pane is displayed. Configure the parameters; and then, click Set.
296
Table 161: Target Address Parameters
Parameter
Name
Description
The name for the address entry.
Address-Port The number of Target Port. The TCP port to be used: 161 for SNMP Access and 162 for SNMP Traps. Default: 162 Tag List Parameters Mask A list of tags separated by spaces. The tags contained in the tag list may be either the tags from the notify table or the Transport tags from the Community table. Name of the entry in the Parameters Table to be used when sending the SNMP Traps. The mask address of the subnet. Default: 0.0.0.0
Creating an SNMP User

Use the Create SNMP User pane to create an SNMP user.
Caution: In accordance with the RFC for SNMPv3, the configuration file of a device that contains SNMPv3 users with authentication can be used only by the specific device that a user configured. When exporting the configuration file to another device, the passwords need to be re-entered, since passwords (of SNMPv3 users) cannot be exported from one device to another. If the configuration file is uploaded to another device, there must be at least one user in the user table to be able to change the password.
To create an SNMP user 1. Select Security > SNMP > Create SNMP User. The Create SNMP User pane is displayed. 2. Set the following parameters:
Parameter
SNMP Version User/Community Name Use Authentication Authentication Password Use Privacy Privacy Password Read View Write View Notify View
Description
Values: SNMPv3, SNMPv1, SNMPv2c User name or community string name. Specifies whether SNMPv3 authentication is used. The Authentication password. Specifies whether SNMPv3 privacy is used. The Privacy password. Values: iso, ReadOnly View Default: iso Values: None, iso, ReadOnlyView Default: None Values: None, iso, ReadOnlyView Default: None
3. Click Create User. The new SNMP user is created.
297
Ping Physical Ports

Use the Ping Ports Table pane to define which physical interfaces can be pinged. When a ping is sent to an interface for which ping is not allowed, the packet will be discarded. By default, all interfaces allow ping.
To specify whether physical ports allow ping 1. 2. 3. 4. Select Security > Ping Physical Ports. The Ping Ports Table pane is displayed. Select the link in the relevant row of the table. The Ping Ports Table Update pane is displayed. In the Ping Device field, select Enabled or Disabled. Click Set.
Configuring the Users Table and Authentication Method

You can create a list of users authorized to access and manage the device. Entries in this table allow access to the LinkProof device through any enabled access method (Web, Telnet, SSH, SWBM). When Trace Status is enabled, users can receive e-mail notifications of changes made to the device. Use the User Table and Authentication pane to define additional users that are allowed to access the device through a Telnet device or using Web Based Management. 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.
Configuring the Authentication Method

Before configuring the user table, configure the authentication method.
To configure the method of authenticating user access 1. 2. Select Security > Users. The User Table and Authentication pane is displayed. From the Authentication Method drop-down list, select the method of authenticating a users access to the device. The following methods are supported: Local User TableThe device uses the User Table to authenticate access. RADIUS and Local User TableThe device uses the RADIUS servers to authenticate access. If the request to the RADIUS server is timed out then the device uses the User Table to authenticate access.
Default: Local User Table 3. Click Set.
298
Configuring a User in the User Table
To configure a user in the User Table 1. Select Security > Users. The User Table and Authentication pane is displayed. 2. Click Create. The User Table Create pane is displayed. 3. Configure the parameters; and then, click Set.
Table 162: User Table and Authentication Parameters
Parameter
User Name Password Email Address Severity
Description
The name of the user. The value must be less than 20 characters long. The text password for this user. The value must be less than 20 characters long. The e-mail address for this user. The value must be less than 20 characters long. The level of warning required by the user. Values: FatalLinkProof sends only Fatal messages to the user. ErrorLinkProof sends Fatal and Error messages to the user. WarningLinkProof sends Fatal, Error and Warning messages to the user. InfoLinkProof sends Fatal, Error, Warning, and Info messages to the user. NoneLinkProof sends no messages to the user. Default: None
Web Access Level
The Web access level. Values: Read Write Read Only None
Trace Status
Specifies whether updates in the device configuration should be mailed to this user.
SYN Protection
SYN profiles provide protection against SYN flood attacks. During a SYN flood attack, the attacker sends a volume of TCP SYN packets requesting new TCP connections without completing the TCP handshake, or completing the TCP handshake, but not requesting data. This fills up the server connection queues, denying service to legitimate TCP users.
299
SYN Flood Global Parameters

SYN Flood Protection is intended to protect the hosts located behind the device and the device itself from SYN flood attacks by performing delayed binding. A SYN flood attack is a denial of service attack where the attacker sends a huge number of please-start-a-connection packets and then no follow up packets. The SYN Flood attack is performed by sending a SYN packet without completing the TCP three-way handshake. Another type of SYN Flood attack is done by completing the TCP three-way handshake, but no data packets are sent afterwards. Radware provides complete protection against both types of SYN Flood attacks. The attacks are detected and blocked by means of SYN Flood Protection Policies. The reports regarding the current attacks appear in the Active Triggers table.
To enable SYN Flood protection 1. 2. Select Security > SYN Protection > Global Parameters. The SYN Flood Protection Parameters pane is displayed. Configure the parameters; and then, click Set.
Table 163: SYN Flood Protection Parameters
Parameter
SYN Protection Status
Description
Specifies the status of SYN Flood Protection feature. Values: enableActivates the SYN Flood Protection module. disableDeactivates the SYN Flood Protection module. standbyActivates the SYN Flood Protection module without rebooting the device. Default: disable
TCP Handshake Timeout
Specifies the timeout, in seconds, to complete the TCP three-way handshake. Values: 0Specifies no timeout. 110 Default: 5
SYN Protection Tracking Time
The time, in seconds, during which the number of SYNs directed to the same destination must be below the Deactivation Threshold value. If the number of SYNs exceeds the deactivation threshold within that time, the destination protection is deactivated. Values: 0Specifies no timeout. 110 Default value: 5
300
Table 163: SYN Flood Protection Parameters
Parameter
SYN ACK Reflection Protection Mode
Description
Specifies the mode or status of the SYN-ACK Reflection Attack Prevention mechanism. Values: enableEnables the prevention mode. reportOnlyEnables the report-only mode (no prevention). disableDisables the SYN-ACK Reflection Attack Prevention mechanism. Default: disable
SYN ACK Reflection SrcIP Sampling Per Sec
Specifies the number of SYN packets per second that are sampled and their source IP to be monitored. Values: 010000 Default: 100
SYN ACK Reflection Specifies the threshold representing the maximum number of Maximum SYN Cookies per uncompleted TCP sessions per source IP per second, to be answered. Source Any session exceeding this frequency will be ignored. Values: 1100,000 Default: 1000 Statistics max destinations Specifies the maximum number of destinations that can be reflected in per policy the statistics report. Values: 1100 Default: 5 Note: Destination is a single IP, dest port, or RX port. Statistics time period Specifies the number of seconds used to calculate average values for SYN protection statistics. Values: 1100 Default: 60 Attack Periodic Report Threshold (% incomplete sess) If the percentage of incomplete sessions for a destination protected by a policy exceeds this threshold, the attack is reported periodically. Values: 0Specifies that no report is available. 1100 Default: 50
SYN Flood Protection Policies

Once the SYN Flood Protection is enabled, you can define Protection policies. A policy is defined according to a destination address or address range.
To create a SYN Flood Protection Policy 1. Select Security > SYN Protection > Protection Policies. The SYN Flood Protection Policies pane is displayed. 2. Click Create. The SYN Protection Policies Create pane is displayed.
301
LinkProof User Guide Security 3. Configure the parameters; and then, click Set.
Table 164: SYN Protection Policy Parameters
Parameter
Name Index Protection Mode
Description
The user-defined name of the policy. Location of policy in the protection table that reflects the order in which the classification is performed. Includes a dropdown menu with the following options: EnabledActivates SYN Cookies for all sessions. TriggeredActivates SYN Cookies only when SYN attack is identified. DisabledNever use SYN Cookies.
Operational Status Activation Threshold
Active or Inactive. The maximum number of SYN packets that are allowed to arrive at the same destination per second. If the Activation Threshold goes beyond the predefined number, the traffic is recognized as an attack and the packets are terminated. Default: 2500 Define the process of completing the TCP session. A free text describing the policy. The minimum number of SYN packets per second that can arrive at the same destination. If the number of packets that arrive at the same destination is below Deactivation Threshold, the SYN Flood protection policy is deactivated and the traffic is no longer protected. Default: 1500 Session is completed when the Ack packet arrives (following a SYN/ SYN-ACK packets exchange). Session is completed when the first data request packet arrives (following a SYN/SYN-ACK packets exchange). Destination address of packet matched by policy. A user-defined physical port group or aggregated Link for SYN flood protection. Specifies whether the device counts the statistics for the destinations defined in this policy. Basic filter of protected application destination port.
Verification Type Description Deactivation Threshold
Ack Request Destination Physical Port Group Count Statistics Service
SYN Flood Statistics

To make the process of defining policy thresholds easier for you, you can view SYN Statistics prior to configuring the thresholds. The SYN Protection Statistics pane provides information on the number of SYNs, complete sessions and other data, thus helping you to define reliable thresholds.
302
To define which policies are displayed 1. Select Security > SYN Protection > Statistics. The SYN Protection Statistics pane is displayed. 2. From the Displaying Statistics of Policy drop-down list, select the policy for which to display statistics. To display statistical data for all policies, leave the field empty. 3. Click Set.
To access the SYN statistics Select Security > SYN Protection > Statistics. The SYN Protection Statistics pane is displayed. For each policy, the following data is displayed:
Parameter
Policy Name Dest IP Dest Port SYNs/Sec Peak Attack Status
Description
Name of policy whose traffic data is collected and analyzed. A specific destination IP included in the policy. A specific destination port included in the policy. Highest value of SYNs per second during the statistical analysis period. Current status of attack. Values: Protected (Under Attack) Protected (No Attack) Monitoring (No Attack) Not Protected
To update the statistics 1. Select Security > SYN Protection > Statistics. The SYN Protection Statistics pane is displayed. 2. Under Reset SYN protection Statistics, click Set.
303
Active Triggers
You can view the list of the attacks that are recognized at the current moment in the Active Triggers Table pane.
To view the SYN Flood Active Triggers Table Select Security > SYN Protection > Active Triggers. The Active SYN Protection Triggers pane is displayed. The table contains the following read-only parameters:
Parameter
Type Ip Address Last Sec SYN Last Sec Verified Total SYN Total Dropped sess. Active Time (Secs)
Description
The type of the identified attack. Source IP for SYN ACK Reflection, and dest ip for all other types. Number of SYN Flood attacks recognized in last second. Number of ACKs recognized in the last second. Total number of SYN packets for this trigger. Total number of unverified sessions for this trigger. Number of seconds since the attack began.
Note: When SYN Protection mode is set to Enabled, the SYN count is performed per device and not per destination IP addresses, thus the entry of destination IP in the alert table displays 0.0.0.0, meaning any.
Keys and Certificates

Certificates are an important part of the LinkProof configuration as they contain information about your company, as well as verification from a third party about that identity.
Certificates
Certificates are digitally signed indicators that 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. 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 certificates serial number The certificate holders expiry date A copy of the certificate holders public key The identity of the certificate authority (CA) and its digital signature to affirm the digital certificate was issued by a valid agency
304
Keys
A key is a variable set of numbers that the sender applies to decrypted data in order 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. A key is a secure method of exchanging data between separate locations. 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 as well as preventing forgery. LinkProof supports the following key size lengths512, 1024, or 2048 bytes.
Configuration
Keys and certificates are an important part of LinkProof configuration. A key is a set of numbers or characters used to encode/decode data. A certificate is an electronic identity containing information about your company and verification from a third party about this identity. The following exchange methods are supported: PKCS-12 (Public-Key Cryptology Standards) PEM NET DER
These file formats can encrypt and seal private keys and certificates with a digital signature, if required. Any of these key formats can be imported into the device regardless of whether they are encrypted. LinkProof can be configured using an existing key/certificate, or by creating a new key/ certificate.
Note: Radware recommends that you use a secure connection such as SSH or HTTPS for all Certificate operations where keys are exposed.
Certificates Workflows
This section describes where, when, and how to use various certificates.
To create a Certificate Signing Request (CSR) When a new real Certificate is needed, you should follow this process: 1. Create a certificate and select CSR. 2. Complete the relevant fields (or update the defaults before you start). 3. Click Create. The Key and CSR are created. 4. Go to the Export PKI Components From Device pane (Security > Certificates > Export) and export the CSR to file or text and send to a certificate signing authority such as VeriSign. 5. After receiving the signed certificate back from Certificate Authority (CA), use the Import PKI components pane (Security > Certificates > Import) to import it into the CSR and convert it to a Key and a Certificate.
305
To create a self-signed certificate If the certificate does not needed to be trusted by users (for example, the lab environment or other internal-only cases), LinkProof can create a certificate on its own. 1. 2. 3. Create a Certificate and select Certificate. Complete the relevant fields (or update the defaults before you start). Click Create. The Key and Certificate are created.
To move a Key and Certificate pair from Web server to a LinkProof device or between LinkProof devices (in a redundant configuration) 1. 2. On the first LinkProof machine, go to the Export PKI Components From Device pane (see Export Certificates from a Device) and select an Export Key. On the first LinkProof machine go, to the Export PKI Components From Device pane (see Export Certificates from a Device) and export a Certificate (if you have web servers you can export in one PKCS12 unified file). On the second LinkProof machine, go to the Import PKI Components To Device (see Export Certificates from a Device) and select an Import Key. On the second LinkProof machine, go to the Import PKI Components To Device (see Export Certificates from a Device) and import a Certificate.
3. 4.
To use an intermediate CA for a signed certificate 1. 2. Select Security> Certificates > Import. The Import PKI Components To Device pane is displayed. Set the following parameters:
Parameter
Entry Name Entry Type
Description
Input new entry name to create by import, or existing entry name to overwrite or complete Key or CSR. Values: KeyImport key from backup or exported from another machine. To complete the configuration, you will need to import a certificate into this key. CertificateImport Certificate from backup or exported from another machine. The Certificate must be imported onto a matching key or CSR. Certificate ChainImport a certificate to be used in the SSL policy. Client CA CertificateImport a certificate to be used in the Client Authentication policy Client CA Certificate field. Note: Maximum character length is 50.
306
Parameter
Passphrase
Description
The passphrase (the same that you use to export the key from the Web server). The Key Password encrypts the key in storage and is required to import the key within a Certificate. In this area, you can paste the Certificate in encrypted text format. The filepath of the certificate file to import.
Text Certificate File
3. Click Import. The certificate is imported.
Caution: All Certificate operations where keys are exposed should be allowed only on a secure connection.
Certificates Table
This table holds all imported and created server certificates. Each certificate in the table has a name used for viewing the certificate details.
To manage the Certificates Table 1. Select Security > Certificates > Table. The Certificates Table pane is displayed. 2. Do one of the following: To update, click the certificate name. The Certificate Table Update pane is displayed. To create a new certificate, click Create. The Certificate Table Create pane is displayed.
3. Configure the parameters; and then, click Set.
Table 165: Certificate Parameters
Parameter
Name Entry Type
Description
Name of Key or Certificate. Displays whether the key is linked to a requested certificate, Intermediate certificate, signing request or not. Values: Key Certificate Signing Request Certificate Chain Client CA Certificate
Key Size
The size, in bytes, of the key. Values: 512, 1024, 2048 Note: Larger key sizes generally offer an increased level of security. Radware recommends that certificates have a key size of 1024 bits or more. Using a certificate of this size makes it extremely difficult to forge a digital signature or decode an encrypted message.
307
Table 165: Certificate Parameters
Parameter
Key Passphrase Common Name Locality State Or Province Organization Organization Unit Country Name Email Certificate Validity
Description
Encrypts the key in storage and is required to export the key from LinkProof. The domain name of the organization. For example, www.radware.com Name of the city. State or province. Name of the organization. Department/Unit within the organization. Organization country. Any e-mail address that you want to include within the certificate. The number of days the certificate will remain valid.
Certificate/Certificate Signing Request (CSR) Details
Note: You can set the default values for the Certificate and CSR fields. For more information, see Default Values for Certificates, page 309.
Export Certificates from a Device

Key, Certificate and Certificate Signing Request (CSR) export is used either for backup purposes, moving existing configurations to another machine or for completion of CSR processes. The following gives a brief description of how to export certificates from a device either by copying and pasting a key or downloading a file.
To export Certificates 1. 2. Select Security > Certificates > Export. The Export PKI Components From Device pane is displayed, showing key, certificate, or CSR. To display an existing key, certificate, or CSR with all parameters, click Show. The following certificate details are displayed:
Parameter
Description
The name of the entry to export. According to entry name, you will be able to export Key, and either Certificate or CSR. Note: Keys and certificate are exported in two separate files, and you will need both for backup or to transfer properly to another machine.
Passphrase
Required when exporting Keys. Use the passphrase entered when the key was created/imported. You need to enter the key passphrase to validate that you are authorized to export it. Displays the Key/Certificate/CSR text in text format for you to copy-paste it, when you use the Show option.
Text
308
LinkProof User Guide Security 3. Choose Show or Export. Click Show to display Key/Certificate/CSR in encrypted text format for copy-paste purposes, for example, sending CSR to a certificate signing authority. 4. A dialog message is displayed asking if you want to open or save the certificate file. If you click Open, the file opens in a browser window. If you click Save, you are prompted to save the file.
Import Certificates to a Device

This enables you to either import Keys/Certificates from another machine (Duplicate), to import a Certificate to an existing CSR to complete its process, and to import a Certificate chain or Client CA Certificate to be used in Certificate configuration or in Client Authentication configuration.
To import Certificates 1. Select Security > Certificates > Import. The Import PKI Components To Device pane is displayed. 2. Set the following parameters:
Parameter
Description
Input new entry name to create by import, or existing entry name to overwrite or complete Key or CSR. Values: KeyImport key from backup or exported from another machine. To complete the configuration, you will need to import a certificate into this key. CertificateImport Certificate from backup or exported from another machine. The Certificate must be imported onto a matching key or CSR. Certificate ChainImport a certificate to be used in the SSL policy. Client CA CertificateImport a certificate to be used in the Client Authentication policy Client CA Certificate field. Note: Maximum character length is 50.
Passphrase
The passphrase (the same that you use to export the key from the Web server). The Key Password encrypts the key in storage and is required to import the key within a Certificate. In this area, you can paste the Certificate in encrypted text format. The filepath of the certificate file to import.
Text Certificate File
3. Click Import. The certificate is imported.
Caution: All certificate operations where keys are exposed should be allowed only on a secure connection.
Default Values for Certificates

You need to configure the parameters to be used when creating CSR or self-signed certificates in your organization.
309
To configure default values for certificates 1. 2. Select Security > Certificates > Default values. The Certificate Default Values pane is displayed. Configure the parameters; and then, click Set.
Table 166: Certificate Default Values Parameters
Parameter
Certificate Common Certificate Locality Certificate State or Province Certificate Organization Certificate Organization Unit Certificate Country Name Certificate Email
Description
The domain name of the organization. For example, www.radware.com. The name of the city. The state or province. The name of the organization. The department or unit within the organization. The organization country. Any e-mail address that you want to include within the certificate.
310
Chapter 8 Bandwidth Management

This chapter describes the Bandwidth Management module. This chapter contains the following sections: Bandwidth Management Overview, page 311 Managing Bandwidth Management Global Parameters, page 313 Bandwidth Management Policies, page 315 Services, page 328 Networks, page 338 Port Groups, page 339 Application Port Groups, page 340 VLAN Tag Groups, page 341 Discrete Networks, page 344 Protocol Discovery, page 347 Port Bandwidth, page 350 Cancelling Interface Classification, page 350 Example Time-based BWM Policy, page 351
Bandwidth Management Overview

The Bandwidth Management module includes a feature set that enables you to gain full control over their available bandwidth. Using these features, you can prioritize applications 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 priority over SMTP traffic, which, in turn, may have priority over FTP traffic. At the same time, a Bandwidth Management solution can track the actual bandwidth used by each applicationand either ensure a guaranteed bandwidth for a certain application and/or set limits as to how much each classified traffic pattern can utilize. The Bandwidth Management module enables you to define policies that restrict or maintain the bandwidth that can be sent or received by each application, user, or segment. Therefore, you can control the maximal bandwidth that DoS attacks can consume from corporate resourcesthus ensuring that mission-critical operations are not affected, maintaining the service level required to guarantee smooth business operation. In a similar manner, if you are a carrier, you can ensure that a DoS attack launched on one customer does not compromise another customers Service License Agreement (SLA). Using the Bandwidth Management module, a LinkProof device can classify traffic passing through it according to predefined criteria and can enforce a set of actions on traffic. A comprehensive set of user-configurable policies controls how the device identifies each packet and what it does with each packet. When a packet is matched, LinkProof can do one of three things: Discard the packetAllows the Bandwidth Management module to provide a very robust and granular packet filtering mechanism. Forward the packet in real timeThe packet bypasses the entire bandwidth management system and is immediately forwarded by the device. The result is effectively the same as if bandwidth management was not enabled at all. Prioritize the packetAllows the mechanism to prioritize services.
311
LinkProof User Guide Bandwidth Management If the packet is to be prioritized, it is placed into a queue, which then is assigned a priority from 07, with 0 being the highest priority and 7 the lowest. Each policy gets its own queue. The number of queues is equal to the number of policies in the policy database, but each queue is labeled with one of the eight priorities 07. This means that there could be 100 queues (if there are 100 policies), with each queue having a label from 07.
Scheduler Algorithms
The scheduler takes packets from the many queues and forwards them. The scheduler operates using one of two algorithms: CyclicThe 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, and so on. The scheduler systematically goes through queues of the same priority when it is time to forward a packet with this priority. CBQ (Class Based Queuing)Has the same packet-forwarding pattern as the WFQ algorithm, with one significant difference. The CBQ algorithm is aware of a predefined bandwidth configured per policy. When you configure a policy, you can give it a minimum (guaranteed) allotted bandwidth. For more information, see Guaranteed Bandwidth, page 318.
Note: Unless CBQ is used, policies cannot be configured with an associated bandwidth.
Application Classification
If Application Classification is defined as Per Packet, the device classifies every packet that flows through it. In this mode, every single packet must be individually classified. If Application Classification is defined as Per Session, all packets are classified by session. An intricate algorithm is used to classify all packets in a session until a best fit policy is found, fully classifying the session. Once the session is fully classified, all packets belonging to the same session are classified accordingly. This not only allows for traffic classification according to application, but also saves some overhead for the classifier, as it only needs to classify sessions, and not every single packet.
Classification Mode
The following classification modes are available: PoliciesThe device classifies each packet or session by matching it to policies configured by the user. DiffservThe device classifies packets only by the Differentiated Services Code Point (DSCP) value. ToSThe device classifies packets only by the ToS (Type of Service) bit value.
Random Early Detection

The Random Early Detection (RED) algorithm can be used to protect queues from overflowing that may cause serious session disruption. The algorithm draws from the inherent retransmission and flow control characteristics of TCP. If the RED algorithm is deployed, the status of the queues is monitored. If the queues are approaching full capacity, random TCP packets are intercepted and dropped. Note, that only TCP packets are dropped, and the packet selection is entirely random. This protects the queues from becoming completely full, which will cause less disruption across all TCP sessions and will also protect UDP packets.
312
LinkProof User Guide Bandwidth Management Radwares bandwidth management mechanism can deploy RED in two forms: Global REDMonitors the capacity of all the queues (that is, the global set of queues) and randomly discards TCP packets before the classifier sees them. Weighted RED (WRED)The RED algorithm is deployed per queue (instead of for all the packets in all the queues) and the priority of the queue has an effect on whether a packet gets dropped or not.
Managing Bandwidth Management Global Parameters

Before setting up Bandwidth Manager policies, you need to define the general bandwidth management parameters. Use the BWM Global Parameters pane to configure the global BWM functionality of the device.
Note: Full functionality of the Bandwidth Management module is available only with a BWM license.
To configure the BWM global parameters 1. Select BWM > Global Parameters. The Global Parameters pane is displayed. 2. Configure the parameters; and then, click Set.
Table 167: BWM Global Parameters
Parameter
Classification Mode
Description
The classification to be used. Values: DisableNo classification. The BWM feature is disabled. PoliciesThe device classifies each packet according to various policies configured by the user. The policies can use 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. DiffservThe device classifies packets only by the DSCP (Differentiated Services Code Point) value. This option requires a BWM license. This option is displayed only when a BWM license is installed. ToSThe device classifies packets only by the ToS (Type of Service) bits value. This option requires a BWM license. This option is displayed only when a BWM license is installed. Default: Policies Note: If you change the value for this parameter, you must reset the device.
313
LinkProof User Guide Bandwidth Management
Parameter
Application Classification
Description
The type of application classification. The process of session classification considers either of the following: Each packet of the session is classified until the number of Max Packets for Session Classification is reached. There is a match based on Force Best Fit. There is a match with a policys Content/OMPC definitions. Values: Per-packetThe 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. Default: Per-session
Scheduling Algorithms
The scheduling algorithm for BWM policies. This option requires a BWM license. This option is displayed only when a BWM license is installed. Values: CBQ Cyclic Default: CBQ Note: If you change the value for this parameter, you must reset the device.
Random Early Detection (RED) Specifies the queue management for the BWM mechanism. This option requires a BWM license. This option is displayed only when a BWM license is installed. Values: None Global Weighted Default: None Queue Size The number of packets in each BWM queue. There is one queue per traffic-shaping policy. Default: 128 Dynamic Borrowing Enables or disables borrowing of the bandwidth between policies within the same Policy Group (see all the panes under Classes > Modify). Values: enable, disable Default: disable BW per Traffic Flow Aging The time, in seconds, that the device keeps a non-active traffic flow in the BW flow tracking table.
314
Parameter
Max Packets for Session Classification
Description
When the Application Classification mode is Per-session and one of the policies is configured to search for content, this parameter indicates the maximum number of packets that the device searches for the configured content. If the device fails to find the content after the number of the configured parameter, the device stops searching for the content in the session. Max Packets for Session Classification affects only packets that contain Layer 4 data. For TCP, the device does not count the threeway handshake packets. The device counts packets in each direction of the session. If the configured value is 5 for example, the device counts up to five request packets and up to five reply packets. In some cases, when classifying FTP traffic, the default value should be higher, since the searched content may appear after the first five packets. Values: 0The device searches for the content in all the packets belonging to the session. 1100 Default: 5
Classification on default gateway only
The device classifies traffic for BWM only on the default gateway, not on all the traffic passing through the device. Values: enable disable Default: disable
TCP Classification Mode
Indicates whether to classify TCP sessions according to the BWM policy, only if they start with a SYN packet. This option requires a BWM license. This option is displayed only when a BWM license is installed. Values: SYN-ValidationOnly classifies a session that begins with a SYN packet. PromiscuousClassifies all sessions. Default: Promiscuous
Bandwidth Management Policies

This section describes Bandwidth Management policies and contains the following topics: Bandwidth Management Policy Mechanism, page 316 Bandwidth Management Classification Criteria, page 316 Bandwidth Management Rules, page 318 Managing Bandwidth Management Policies, page 319
315
Bandwidth Management Policy Mechanism

The policy mechanism enables you to classify traffic passing through the LinkProof device and enforce on it bandwidth management. The policy database is made up of two sections. The first is the temporary or inactive portion. These policies 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 basically updates the active policy database, which is what the device uses to sort through the packets that flow through it. A policy consists of a set of conditions (classification criteria) and a set of actions that apply as a consequence of the conditions being satisfied.
Bandwidth Management Classification Criteria

You can use an object (for example, a network object) that you have preconfigured or you can add an IP address manually. Radware recommends that you work with objects that you have preconfigured. A policy includes the following traffic classification criteria: SourceDefines the source of the traffic. This can be specific IP addresses, a range of IP addresses or IP Subnet address. You should first configure Networks. The default value is any, which covers traffic from any source. DestinationDefines the destination of the traffic. This can be specific IP addresses, a range of IP addresses or IP Subnet address. The default value is any, which covers traffic to any destination.
Note: To limit or block access to the devices interface, type the IP address of the interface in the Destination box. DirectionSetting the direction mode to one way enables asymmetric BWM. When a policy is set to One Way, the classifier searches for traffic in one direction only, while with Two Way, the device searches both directions. When a rule is set to One Way, the device classifies only one direction of the traffic and the return traffic is not classified. When a rule is set to Two Way, on the way back, the device replaces the source and destination IP addresses and ports (in case the rule is a L4 or L7 rule). ServiceDefines the traffic type. The Service configured per policy can allow the policy to consider other aspects of the packet, such as the protocol (IP/TCP/UDP), TCP/UDP port numbers, bit patterns at any offset in the packet, and actual content (such as URLs or cookies) deep in the upper layers of the packet. Available Services are very granular. The default value is None, which covers all protocols. Inbound Physical Port GroupClassifies only traffic received on certain interfaces of the device. Enables you to set different policies to identical traffic classes that are received on different interfaces of the device. VLAN Tag GroupDefines VLAN traffic classification according to VLAN ID (VLAN Identifier) tags.
316
LinkProof User Guide Bandwidth Management Traffic Flow IdentificationDefines 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)
Cookie Field IdentifierA string that identifies the cookie field whose value must be used to determine the different traffic flows.
Note: This is required only when Traffic Flow Identification is set to SessionCookie. When Traffic Flow Identification is set to SessionCookie, the BWM classifier searches for the Cookie Field Identifier followed by an equal sign (=) and classifies flows according to the value.
Example
If you have the following rule: Source: IP_A Destination: IP_B Service: HTTP Direction: One Way
only traffic with a source IP, IP_A and a destination IP IP_B with source port X and destination port 80 would be classified. The return packet, with source IP_B and destination IP IP_A, with source port x and destination port 80 would not be classified.
Example
If you have the following rule: Source: NET_A Destination: NET_B Service: HTTP Direction: Two Way
a packet with source IP belongs to NET_A with a destination IP belongs to NET_B requesting a HTTP request will be matched, while a packet with source IP belongs to NET_B with a destination IP belongs to NET_A requesting a HTTP request will not be matched, even if the rule is set to two ways.
317
Bandwidth Management Rules

Once the traffic is classified and matched to a policy, the Bandwidth Management rules can be applied to this policy.
Action
The action determines the access given to traffic. The values for the Action parameter are as follows: Forward (default)The connection is accepted and traffic is forwarded to its destination. This is the default value. BlockAll packets are dropped. Block and ResetAll packets are dropped. In TCP traffic, an RST packet is sent to the client. Block and Bidirectional ResetAll packets are dropped. In TCP traffic, an RST packet is sent to both client and server.
Priority
If the action associated with the policy is Forward, the packet is classified according to the configured priority. There are nine (9) options available: real-time forwarding and priorities 0 through 7.
Guaranteed Bandwidth
If the scheduler is configured to use the CBQ algorithm, the policy can be assigned a minimum (guaranteed) bandwidth. The scheduler will not allow packets that were classified through this policy to exceed this allotted bandwidth, unless borrowing is enabled. Note, that the maximum bandwidth configured for the entire device, as described above, overrides per-policy bandwidth configurations. In other words, the sum of the guaranteed bandwidth for all the policies cannot be higher than the total device bandwidth.
Borrowing Limit
Borrowing can be enabled when the scheduler operates through the CBQ algorithm. If enabled, the scheduler can borrow bandwidth from queues that can spare it, in order to forward packets from queues that have exceeded (or are about to exceed) their allotted amount of bandwidth. The combination of Guaranteed Bandwidth and Borrowing Limit fields value will cause the bandwidth allotted to a policy to behave as follows:
Guaranteed Bandwidth Borrowing Limit Policy Bandwidth

0 X 0 X X 0 0 Y Y (Y>X) X Burstable with no limit, no minimum guaranteed. Burstable with no limit, minimum of X guaranteed. Burstable to Y, no minimum guaranteed. Burstable to Y, minimum of X guaranteed. Nonburstable, X guaranteed.
Policy Group
You can define several bandwidth borrowing domains on a device by organizing policies in groups. Bandwidth that is not utilized by a specific policy in a group is allocated proportionally to the other policies, enabling them to borrow from other policies preventing starvation and utilizing the bandwidth more efficiently. Only policies that participate in a specific group can share bandwidth. The total bandwidth available for a policy group is the sum of Guaranteed Bandwidth values of all policies in the group.
318
LinkProof User Guide Bandwidth Management Configuring a policy group involves the following steps: 1. Setting the global BWM parameter Dynamic Borrowing to Enable. 2. Configuring policy groups. 3. Configuring the device policies. Configure Guaranteed Bandwidth with the required value and Borrowing Limit to 0 (bandwidth limitation is ignored as the policy is able to borrow unused bandwidth from other policies in the group). For each policy, select the relevant policy group to which it belongs. 4. Perform Update policies command.
Notes: >> For more information, see Managing Bandwidth Management Global Parameters, page 313. >> Whenever bandwidth borrowing and/or prioritization is applied, the maximum bandwidth available for allocation per physical port must be configured. For example, for a device, a Fast Ethernet port connected to a router that supports up to 2 Mbit/s, the bandwidth for that port must be set to 2 Mbit/s. The default is the physical capacity of the port. >> The Borrowing Limit parameter must be set to 0 for all the policies in the group and the Dynamic Borrowing global parameter must be enabled.
Traffic Flow Control

The maximum bandwidth allowed per traffic flow.
Max Concurrent Sessions

The maximum concurrent sessions allowed for the BWM policy.
Packet Marking
Packet Marking refers to Differentiated Services Code Point (DSCP) or Diffserv. Enables the device to mark the packet with a range of bits.
Policy Index
The policy order or index is a number that determines the order of the policy in the entire policy database. When the classifier receives a packet, it tries to find a policy that matches the packet. The policy database is searched starting with policy #1, in descending order. Once a policy is matched the process is stopped. Using this logic, the very last policy configured should be the policy that is enforced on all packets that do not match any other policies. In other words, the last configured policy should be the default policy.
Managing Bandwidth Management Policies

You can view the configuration of active BWM policies, as well as configure new ones. The Bandwidth Management solution uses a policy database, which is made up of two sections. The first is the temporary or inactive portion. You can configure and modify these policies without affecting the current operation of the device. As modified policies go into effect only when 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. This section contains the following topics:
319
LinkProof User Guide Bandwidth Management Configuring BWM Policies, page 320 Viewing the Configuration of Active BWM Policies, page 324 Configuring BWM Policy Extensions, page 325 Viewing Active BWM Policy Extensions, page 327 Configuring BWM Policy Groups, page 328 Viewing Active BWM Policy Groups, page 328 Updating BWM Policies, page 328
Configuring BWM Policies
To configure a BWM policy 1. Select BWM > Modify > Policies. The Modify Policies Table pane is displayed with a table comprising the following columns: 2. 3. Name Index Destination Source Action
Click Create. The Modify Policies Table Create pane is displayed. Configure the parameters; and then, click Set.
Table 168: BWM Policy Parameters
Parameter
Index Name Destination
Description
The index number of the policy. The user-defined name of the policy. This value is read-only after creation. 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 Action
The source address of the packet being matched by the policy. The action to be applied to the packet. Values: Forward Block Block and Reset Block and Bidirectional Reset Default: Forward
320
Parameter
Direction
Description
The direction to which the policy relates. Values: One WayA policy only matches packets where the source IP address and port match the source as well as the destination. Two WayIf the source matches the destination and vice versa, this is also a match. Default: Two Way
Priority
The priority attached to the packet by which it is forwarded. Priority is only applicable if the action is Forward. Values: Real Time None 077 is the lowest priority. Default: Real Time
Description Maximum Bandwidth
A description of the policy. The maximum bandwidth, in Kbit/s, for packets matching this policy. This option is used in conjunction with Class Based Queuing (CBQ). Note: If you want this policy to drop all matching packets, enter 0. The type of service (filter). Values: None Basic Filter AND Group OR Group Default: None
Service Type
Service Operational Status
The name of the service required for this policy, based on the Service Type. The operational status of the policy. Values: ActiveWhen policies are updated, this policy is used to be matched against packets. InactiveWhen policies are updated, this policy is not used to be matched against packets. Default: Active
Packet Marking
Refers to Differentiated Services Code Point (DSCP) or Diffserv. Marks the packet with a range of bits. Default: None Specifies whether blocked packets are reported. Values: Disable, Report Blocked Packets Default: Disable
Reporting
321
Parameter
Maximum Bandwidth
Description
The maximum bandwidth, in Kbit/s, for packets matching this policy. This option is used in conjunction with Class Based Queuing (CBQ). Note: If you want this policy to drop all matching packets, enter 0. Sets different policies to 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. To configure this option, you must first configure Port Groups. For more information, see Port Groups, page 339. Note: The group must be configured already. The name of the VLAN tag group. For more information, see VLAN Tag Groups, page 341. Default: None Note: The group must be configured already.
Inbound Physical Port Group
VLAN Tag Group
Policy Group
Specifies the Policy Group. Default: None
Modifying BWM Policies
To modify a BWM policy 1. Select BWM > Modify > Policies. The Modify Policies Table pane is displayed. The pane displays the active policies in a table with the following columns: Name, Index, Destination, Source, Action. To modify the configuration of policy, select the policy. The Modify Policies Table Update pane is displayed. Configure the parameters; and then, click Set.
2. 3.
Parameter
Index Destination
Description
The index number of the policy. 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 Action
The source address of the packet being matched by the policy. The action to be applied to the packet. Values: Forward Block Block and Reset Block and Bidirectional Reset
322
Parameter
Direction
Description
The direction to which the policy relates. Values: One WayA policy only matches packets where the source IP address and port match the source as well as the destination. Two WayIf the source matches the destination and vice versa, this is also a match.
Priority
The priority attached to the packet by which it is forwarded. Priority is only applicable if the action is Forward. Values: Real Time None 077 is the lowest priority. Default: Real Time
Description Guaranteed Bandwidth (kbps) Service Type
A description of the policy. The bandwidth limitation for packets matching this policy. This option is used in conjunction with CBQ. The type of service (filter). Values: None Basic Filter AND Group OR Group
The name of the service required for this policy, based on the Service Type. The operational status of the policy. Values: ActiveWhen policies are updated, this policy is used to be matched against packets. InactiveWhen policies are updated, this policy is not used to be matched against packets.
Packet Marking Reporting Maximum Bandwidth
Refers to Differentiated Services Code Point (DSCP) or Diffserv. Marks the packet with a range of bits. Specifies whether blocked packets are reported. Values: Disable, Report Blocked Packets The maximum bandwidth, in Kbit/s, for packets matching this policy. This option is used in conjunction with Class Based Queuing (CBQ). Note: If you want this policy to drop all matching packets, enter 0. Sets different policies to 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. To configure this option, you must first configure Port Groups (see Port Groups, page 339). Note: The group must be configured already.
323
Parameter
VLAN Tag Group Policy Group
Description
The name of the VLAN tag group (see VLAN Tag Groups, page 341). Note: The group must be configured already. Specifies the Policy Group or none.
Viewing the Configuration of Active BWM Policies
To view the configuration of an active BWM policy 1. Select BWM > View Active > Policies. The Active Policies Table pane is displayed. The pane displays the active policies in a table with the following columns: Name, Index, Destination, Source, Action. To view additional information on a specific policy, select the policy. The following fields are displayed read-only:
2.
Parameter
Name Index Destination
Description
The user-defined name of the policy. The index number of the policy. 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 Action
The source address of the packet being matched by the policy. The action to be applied to the packet. Values: Forward Block Block and Reset Block and Bidirectional Reset
Direction
The direction to which the policy relates. Values: One WayA policy only matches packets where the source IP address and port match the source as well as the destination. Two WayIf the source matches the destination and vice versa, this is also a match.
Priority
The priority attached to the packet by which it is forwarded. Priority is only applicable if the action is Forward. Values: Real Time 077 is the lowest priority
Description Guaranteed Bandwidth (kbps)
A description of the policy. The bandwidth limitation for packets matching this policy. This option is used in conjunction with CBQ.
324
Parameter
Service Type
Description
The type of service (filter). Values: None Basic Filter AND Group OR Group
The name of the service required for this policy, based on the Service Type. The operational status of the policy. Values: ActiveWhen policies are updated, this policy is used to be matched against packets. InactiveWhen policies are updated, this policy is not used to be matched against packets.
Packet Marking Reporting Maximum Bandwidth (kbps) Inbound Physical Port Group
Refers to Differentiated Services Code Point (DSCP) or Diffserv. Marks the packet with a range of bits. Specifies whether blocked packets are reported. Values: Disable, Report Blocked Packets The maximum bandwidth for packets matching this policy. This option is used in conjunction with Class Based Queuing (CBQ). Sets different policies to 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. To configure this option, you must first configure Port Groups (see Port Groups, page 339). Note: The group must be configured already. The name of the VLAN tag group (see VLAN Tag Groups, page 341). Note: The group must be configured already. Specifies the Policy Group.
VLAN Tag Group Policy Group
Configuring BWM Policy Extensions
To create a BWM policy extension 1. Select BWM > Modify > Policy Extensions. The Modify Policies Extensions pane is displayed. The pane displays the active policies in a table with the following columns: Name, From Farm, To Farm, Classification Point, Traffic Flow Identification. 2. Select a policy. The Modify Policies Extensions Update pane is displayed. 3. Configure the parameters; and then, click Set.
325
Table 170: BWM Policy Extension Parameters
Parameter
Name From Farm To Farm Classification Point
Description
The read-only, user-defined name of the policy. The source farm. The destination farm. Indicates whether the classification is done before of after packet modification. Value: After ChangesClassifies the device after the packet changes. Before ChangesClassifies the device before the packet changes.
Traffic Flow Identification
Defines what type of traffic flow we are going to limit via this policy. Values: None ClientSource IP. SessionSource IP and port. ConnectionSource IP and destination IP. FullL4SessionSource and destination IP and port. SessionCookieMust configure cookie identifier.
Traffic Flow Max BW Max Concurrent Sessions Max HTTP Rqts Per Second
The maximum bandwidth, in Kbit/s, allowed per traffic flow. The maximum number of concurrent sessions allowed for a client IP. Note: This option is not available if the Traffic Flow Identifier is set to Session or FullL4Session. 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. A string that identifies the cookie field whose value must be used to determine the different traffic flows. The Cookie Field Identifier is required only when Traffic Flow Identification is set to SessionCookie. When Traffic Flow Identification is set to SessionCookie, the BWM classifier searches for the Cookie Field Identifier followed by = and classifies flows according to the value.
Cookie Field Identifier
Activation Schedule
The Event Schedule for making the BWM policy active. For more information, see Event Scheduler, page 255. Default: None Note: The schedule must be configured already.
Inactivation Schedule
The Event Schedule for making the BWM policy inactive. For more information, see Event Scheduler, page 255. Default: None Note: The schedule must be configured already.
326
Viewing Active BWM Policy Extensions
To view the configuration of active BWM policy extensions 1. Select BWM > View Active > Policy Extensions. The Active Policies Extenstions pane is displayed. The pane displays the active policies in a table with the following columns: Name, From Farm, To Farm, Classification Point, Traffic Flow Identification. 2. To view additional information on a specific policy, select the policy. The following fields described are displayed read-only:
Paremeter
Name Classification Point
Desrciption
The user-defined name of the policy. Indicates whether the classification is done before of after packet modification. Value: After ChangesClassifies the device after the packet changes. Before ChangesClassifies the device before the packet changes.
Traffic Flow Identification
Defines the type of traffic flow that this policy manages. Values: None ClientSource IP. SessionSource IP and port. ConnectionSource IP and destination IP. FullL4SessionSource and destination IP and port. SessionCookieMust configure cookie identifier.
Traffic Flow Max BW (kbps) Max Concurrent Sessions Max HTTP Rqts Per Second
The maximum bandwidth in Kbps allowed per traffic flow. The maximum number of concurrent sessions allowed for a client IP. Note: This option is not available if the Traffic Flow Identifier is set to Session or FullL4Session. 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. String that identifies the cookie field whose value must be used to determine the different traffic flows. The Cookie Field Identifier is required only when Traffic Flow Identification is set to SessionCookie. When Traffic Flow Identification is set to SessionCookie, the BWM classifier searches for the Cookie Field Identifier followed by = and classifies flows according to the value.
Cookie Field Identifier
Activation Schedule
The Event Schedule for making the BWM policy active. For more information, see Event Scheduler, page 255. Default: None The Event Schedule for making the BWM policy inactive. For more information, see Event Scheduler, page 255. Default: None
Inactivation Schedule
327
Configuring BWM Policy Groups

You can organize BWM policies into groups that are defined according to the borrowing limit. Each Policy Group shares the same bandwidth borrowing domain. Only policies that participate in the defined group can share the borrowing domain. For more information, see Policy Group, page 318. The Modify Policies Group table contains all the bandwidth policy groups. You can add new policy groups to this table. You cannot configure a Policy Group when the value of the Borrowing Limit parameter is 0, or Guaranteed.
To configure a BWM Policy Group 1. 2. 3. 4. Select BWM > Modify > Policy Groups. The Modify Policy Group Table pane is displayed. Click Create. The Modify Policy Group Table Create pane is displayed. In the Name box, type the name of the new Policy Group. Click Set. The new policy group is displayed in the Modify Policy Group Table and the Active Policy Group Table.
Viewing Active BWM Policy Groups
To view active BWM Policy Groups Select BWM > View Active > Policy Groups. The Active Policy Group Table pane is displayed.
Updating BWM Policies
To update BWM Policies 1. 2. Select BWM > Update Policies. The Activate Latest Changes pane is displayed. Click Set.
Services
LinkProof uses Services to filter traffic. Services characterize traffic based on layer-37 criteria. A Service is a configuration of a basic filter, which may combine with logical operators to achieve more sophisticated filters (AND Group filters and OR Group filters). LinkProof supports a long list of predefined basic filters. A basic filter includes attributes that specify parameters such as protocol, application port, and content type. When the protocol of a basic filter is TCP or UDP, the filter can include a text string.
Note: The host names in the Hostname List of an L7 Policy are not algorithmically related to a host name configured for a basic filter. You can configure Services separately from policies. When you configure a policy, you can associate it with an existing Service.
328
LinkProof User Guide Bandwidth Management This section contains the following topics: Basic Filters, page 329 AND Group Filters, page 335 OR Group Filters, page 336 Viewing Active Services, page 337
Basic Filters
LinkProof supports an extensive list of predefined basic filters (see Predefined Basic Filters, page 330). You can also create your own basic filters. A basic filter includes the following components: ProtocolThe specific protocol that the packet should carry. The possible choices are IP, TCP, UDP and ICMP. If the specified protocol is IP, all IP packets (including TCP and UDP) will be considered. When configuring TCP or UDP protocol, the following additional parameters are available: Destination Port (From-To)Destination port number for that protocol. For example, for HTTP, the protocol would be 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 should carry in order to match the filter can be configured.
Offset Mask Pattern Condition (OMPC)The OMPC is a means by which any bit pattern can be located for a match at any offset in the packet. This can aid in locating specific bits in the IP header, for example. TOS and Diff-serv bits are perfect examples of where OMPCs can be useful. It is not mandatory to configure an OMPC per filter. However, if an OMPC is configured, there should be an OMPC match in addition to a protocol (and source/destination port) match. In other words, if an OMPC is configured, the packet needs to match the configured protocol (and ports) and the OMPC.
Content Specifications
When the protocol of a basic filter is TCP or UDP, you can search for any text string in the packet. Like OMPCs, 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. You can choose from the following types of configurable content: URL hostname HTTP header field cookie mail domain mail to mail from mail subject file type regular expression text
When the content type is URL, for example, LinkProof assumes the session to be HTTP with a GET, HEAD, or POST method. LinkProof 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, LinkProof searches the entire packet for the content text, starting at the configured offset.
329
LinkProof User Guide Bandwidth Management By allowing a filter to take actual content of a packet/session into account, LinkProof 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), the OMPC (if one exists) and the Content Rule.
Predefined Basic Filters

LinkProof supports an extensive list of predefined basic filters. You cannot modify or delete predefined basic filters. For the list of predefined basic filters, see Appendix B - Predefined Basic Filters, page 563.
Configuring Basic Filters
Caution: If you modify the configuration of a filter that is used in an existing policy, you need to activate the latest changes (Classes > Update Policies > Set).
To configure a basic filter 1. Select Classes > Modify Services > Basic Filters. The Modify Basic Filter Table pane is displayed. The Modify Basic Filter Table pane contains a table with the following columns: 2. 3. Name Description Protocol OMPC Offset OMPC Mask
Select the relevant link. The Modify Basic Filter Table Update pane is displayed. Configure the parameters; and then, click Set.
Table 171: Basic Filter Parameters
Parameter
Name Protocol
Description
The read-only name of the filter. Values: IP TCP UDP ICMP NonIP SCTP Default: IP
330
Parameter
Source App. Port
Description
The Layer-4 source port or source-port range for TCP, UDP, or SCTP traffic. Values: Values in the range 065,535 Value ranges (for example, 30400) dcerpc dns ftp http https imap ms-sql-m ms-sql-s ntp pop3 radius sip smtp snmp ssh sunrpc telnet Note: The value must be greater than the Source Port Range: From value.
331
Parameter
Destination App. Port
Description
The Layer-4 destination port or source-port range for TCP, UDP, or SCTP traffic. Values: Values in the range 065,535 Value ranges (for example, 30400) dcerpc dns ftp http https imap ms-sql-m ms-sql-s ntp pop3 radius sip smtp snmp ssh sunrpc telnet Note: The value must be greater than the Destination Port Range: From value.
OMPC Offset Relative to
Specifies to which OMPC offset the selected offset is relative to. Valid values when IP, UDP, or ICMP protocol is selected: None IP Header IP Data Valid values when TCP protocol is selected: None IP Header IP Data L4 Data ASN1 Ethernet L4 Header
OMPC Offset
The location in the packet where the data starts being checked for specific bits in the IP or TCP header. Values: 01513 Default: 0
332
Parameter
OMPC Mask
Description
Defines the mask for OMPC data. The value must be defined according to the OMPC Length parameter. Values: Must comprise eight hexadecimal symbols Default: 00000000
OMPC Pattern
Defines the fixed-size pattern within the packet that the OMPC rule attempts to find. The value must be defined according to the OMPC Length parameter. The OMPC Pattern must contain eight hexadecimal symbols. If the value for the OMPC Length parameter is smaller than Four Bytes, you need to pad the OMPC Pattern with zeros. For example, if OMPC Length is two bytes, the OMPC Pattern can be abcd0000. Values: Must comprise eight hexadecimal symbols Default: 00000000
OMPC Condition
Values: None Equal Not Equal Greater Than Less Than Default: None
OMPC Length
Values: None One Byte Two Bytes Three Bytes Four Bytes Default: None
Content Offset
Specifies the location in the packet at which the checking of content starts. Values: 01513 Default: 0
Content
Contains the value of the content search. Values: < space > ! " # $ % & ' ( ) * + , -. / 0 1 2 3 4 5 6 7 8 9 : ; < =>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_ àbcdefghijklmnopqrstuvwxyz{|}~.
333
Parameter
Content Type
Description
Specifies the specific content type to search for. Values: None URLA URL in the HTTP request URI. TextText anywhere in the packet. Host NameA hostname in the HTTP header. The host names in the Hostname List of an L7 Policy are not algorithmically related to a host name configured for a basic filter. Header FieldA header field in the HTTP header. ExpressionText anywhere in the packet represented by a regular expression specified in the Content field. Mail DomainThe Mail Domain in the SMTP header. Mail ToThe Mail To SMTP header. Mail FromThe Mail From SMTP header. Mail SubjectThe Mail Subject SMTP header. File TypeThe type of the requested file in the HTTP GET command (for example, JPG, EXE, and so on). CookieThe HTTP cookie field. The Content field includes the cookie name, and the Content Data field includes the cookie value. Normalized URLA normalized URL in the HTTP request URI. POP3 UserThe POP3 User field in the POP3 header. URI lengthFilters according to URI length. FTP CommandParses FTP commands to commands and arguments, while normalizing FTP packets and stripping Telnet opcodes. FTP ContentScans the data transmitted using FTP, normalizes FTP packets and strips Telnet opcodes. Generic UrlThe generic URL in the HTTP Request URI. No normalization procedures are taken. GET/HEAD/POST is not required when this type is selected. This is applicable for protocols like SIP, BitTorrent, and so on. Generic HeaderIn the HTTP Request URI. No normalization procedures are taken. GET/HEAD/POST is not required when this type is selected. This is applicable for protocols like SIP, BitTorrent, and so on. Generic CookieIn the HTTP Request URI. No normalization procedures are taken. GET/HEAD/POST is not required when this type is selected. This is applicable for protocols like SIP, BitTorrent, and so on. Default: None
Content End Offset
Specifies the location in the packet at which the checking of content ends. Values: 01513 Default: None
Content Data
Refers to search for content within the packet.
334
Parameter
Content Coding
Description
The encoding type of the content to search for (as specified in the Content field). Values: None Case Insensitive Case Sensitive HEX International Default: None Note: The value of this field corresponds to the Content Type parameter.
Content Data Coding
The encoding type of the content data to search for (as specified in the Content Data field). Values: None (Default) Case Insensitive Case Sensitive HEX International Default: None Note: The value of this field corresponds to the Content Type parameter.
Description
A description of the filter.
AND Group Filters

An AND Group filter is a combination of basic filters with a logical AND between them. LinkProof supports a set of predefined, static and AND Groups. You can also create your own AND Groups using basic filters.
Note: You cannot modify or delete predefined AND Groups.
Example
The basic filters F1, F2, and F3 have been individually configured. Filter AF1 is user-defined as: AF1= {F1 AND F2 AND F3}. In order for a packet to match AF1, the packet must match all three filters (F1, F2, and F3).
335
To configure an AND Group filter 1. 2. 3. Select Classes > Modify > Services > AND Groups. The Modify AND Groups Table pane is displayed. Click Create. The Modify AND Groups Table Create pane is displayed. Set the following parameters:
Parameter
AND Group Name Basic Filter Name 4. 5. 6. Click Set.
Description
The user-defined AND Group name. A basic filter for this AND Group.
Repeat the previous steps in this procedure (using the same AND Group Name) until you have added all the required basic filters to the AND Group. Click Set.
OR Group Filters
An OR Group Filter is a combination of basic filters and/or AND filters with a logical OR between them. LinkProof supports a set of predefined, static OR Groups. The predefined are based on the predefined basic filters. You can also create your own OR Groups using basic filters or AND Groups.
Example
The basic filters F1, F2, and F3 have been individually configured. Filter AF1 is user-defined as: AF1= {F1 AND F2 AND F3}. In order for a packet to match AF1, the packet must match all three filters (F1, F2, and F3). Filter FG1 is user-defined as: FG1 = {AF1 OR F4 OR F6}. In order for a packet to match FG1, the packet must match either filter AF1, basic filter F4, or basic filter F6. Use the Modify OR Groups Table pane to create, modify, and delete the OR Group filters.
Note: You cannot modify or delete predefined OR Groups.
To configure an OR Group filter 1. 2. Select Classes > Modify > Services > OR Groups. The Modify OR Groups Table pane is displayed. Click Create. The Modify OR Groups Table Create pane is displayed.
336
LinkProof User Guide Bandwidth Management 3. Configure the parameters; and then click Set.
Table 172: OR Groups Parameters
Parameter
OR Group Name Filter Name Filter Type
Description
The user-defined OR Group name. A basic filter or an AND Group, depending on the value in the Filter Type dropdown list, for this OR Group. Specifies the type of the filter options displayed in the Filter Name drop-down list. Values: Basic Filter, And Group
Viewing Active Services

You can view active services and the configuration of each.
To view active Basic Filters Select Classes > View Active > Services > Basic Filter. The Active Basic Filter Table pane is displayed.
Note: To view the configuration of the filter (read-only), select the link of the relevant filter.
To view active AND Groups Select Classes > View Active > Services > AND Groups. The Active AND Groups Table pane is displayed.
To view active OR Groups Select Classes > View Active > Services > OR Groups. The Active OR Groups Table pane is displayed.
337
Networks
A Network is a logical entity, which consists of a group of IP addresses linked together by a network IP and subnet or a range of IP addresses (from-to) and identified by name. A Network can be configured separately and individual elements of the Network list can then be used in the individual policy. An entry in the Network list is known as a configured name and can be either an IP/Mask combination or an IP range. For example, network net1 can be 10.0.0.0/255.0.0.0 and network net2 can be from: 10.1.1.1 to: 10.1.1.7. The Network list allows either configuration. The bandwidth management module allows multiple Networks to have the same configured name. This allows a Network with the name net1 to actually encompass multiple disjointed IP address ranges. Essentially, this makes the Network name a logical pointer to all ranges configured with that name. This will further facilitate the configuration and management of the system. You can view active networks, as well as configure new ones. In addition to active networks, you can configure inactive networks. The inactive networks are kept in a separate database until they are required. You can add, modify, and delete these networks according to your requirements.
Configuring Networks
To configure a network 1. 2. 3. Select Classes > Modify > Networks. The Modify Network Table pane is displayed. Click Create. The Modify Network Table Create pane is displayed. Configure the parameters; and then, click Set.
Table 173: Network Parameters
Parameter
Name Sub Index
Description
The user-defined network name. The unique index number of the subnet. Each network can have several subnets. The Sub Indexes for the subnets within the same network must be unique. The network mode. Values: IPMask, IPRange The IP address of the subnet. The mask address of the subnet. The first IP address in the range of addresses. The last IP address in the range of addresses.
Mode Address Mask From IP To Address
Note: To simplify configuration, a network can consist of a combination of network subnets and rangesfor example: Range = 176.200.100.0: 176.200.100.255 Subnet = 172.0.0.0: 255.0.0.0
338
To edit a network 1. Select Classes > Modify > Networks. The Modify Network Table pane is displayed. 2. Modify the parameters as required. 3. Click Set.
To delete a network 1. Select Classes > Modify > Networks. The Modify Network Table pane is displayed. 2. Select the checkbox in the row of the network to delete. 3. Click Delete. The network is deleted.
Viewing Active Networks
To view active networks 1. Select Classes > View Active > Networks. The Active Network Table pane is displayed. 2. To view the values for all the parameters of a network, click on the relevant network. The Active Network Table pane is displayed with read-only values.
Table 174: Active Network Table Parameters
Parameter
Name Sub Index Address Mask From IP To IP Mode
Description
The user-defined network name. The unique index number of the subnet. The IP address of the subnet. The mask address of the subnet. The first IP address in the range of addresses. The last IP address in the range of addresses. The network mode.
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 HTTP access to the main server only to traffic entering the device via physical interface 3. This provides greater flexibility in configuration. You first configure Port Groups, which are collections of physical interfaces of the device. After you configure the Port Groups, associate a Port Group to the required policies.
339
Configuring Port Groups
To configure a port group 1. 1. 2. Select Classes > Modify > Port Groups. The Modify Physical Port Groups Table pane is displayed. Click Create. The Modify Physical Port Groups Table Create pane is displayed. Configure the parameters; and then, click Set.
Table 175: Physical Port Group Parameters
Parameter
Group Name Inbound Port
Description
The user-configured name of the port group. The inbound port for this group. Values: A port number Any
Viewing Active Port Groups
To view active port groups 1. Select Classes > View Active > Port Groups. The Active Physical Port Groups Table pane is displayed is displayed with the following read-only parameters: Group Name Inbound Port
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 configuration of a group includes the group type; Static or Regular. You cannot change group type. Static groups are predefined by LinkProof, and you cannot delete them. Regular groups are user-defined, and you can delete them.
Configuring Application Port Groups
To configure an application port group 1. 2. Select Classes > Modify > Appl. Port Groups. The Modify Appl. Port Groups Table pane is displayed. Click Create. The Modify Appl. Port Groups Table Create pane is displayed.
340
LinkProof User Guide Bandwidth Management 3. Configure the parameters; and then, click Set.
Table 176: Application Port Groups Parameters
Parameter
Name From Port
Description
The name of the group. The first port in the range. 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
The last port in the range.
Viewing Active Application Port Groups
To view the active application port groups Select Classes > View Active > Appl. Port Groups. The Active Application Port Groups Table pane is displayed with read-only parameters.
Table 177: Active Application Port Groups Parameters
Parameter
Name From Port To Port Group Type
Description
The name of the group. The first port in the range. The last port in the range. The group type. Values: static, regular
VLAN Tag Groups

VLAN tag groups enable you to set different policies to identical traffic classes that are 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 VLAN tag with a specific value. This provides greater flexibility in configuration. The user should first configure VLAN tag groups.
Notes: >> This feature is applicable only when the 802.1q parameter is set to Enabled. Classification is performed according to the tag of the received packet. >> This feature is applicable for in-line, and Static Forwarding operation modes (Device Operation Mode set to Traffic Redirection or Static Forwarding). Use the VLAN Tag Groups panes to create or modify an the existing VLAN tag group or add a new group.
341
Configuring VLAN Tag Groups
To configure a VLAN tag group 1. 2. 3. Select Classes > Modify > VLAN Tag Groups. The Modify Active VLAN Tag Groups pane is displayed. Click Create. The Modify Active VLAN Tag Groups Table Create pane is displayed. Configure the parameters; and then click Set.
Note: You can configure the Group Name, VLAN Tag, and Group Mode values; or you can configure the Group Name, VLAN Tag Range From, and VLAN Tag Range To values.
Table 178: VLAN Tag Groups Parameters
Parameter
Group Name VLAN Tag VLAN Tag Range From VLAN Tag Range To Group Mode
Description
The name of the group of VLAN tags. A VLAN Tag number. Default: 65536 The lowest value in the range of VLAN tags that you want to define. Default: 65536 The highest value in the range of VLAN tags that you want to define. Default: 65536 The mode of the group. Values: DiscreteSelect Discrete if you define a single VLAN tag number. RangeSelect Range if you define the range of the group.
Viewing Active VLAN Tag Groups
To view active VLAN tag groups Select Classes > View Active > VLAN Tag Groups. The Active VLAN Tag Groups pane is displayed with read-only parameters.
Parameter
Group Name VLAN Tag VLAN Tag Range From
Description
The name of the group of VLAN tags. A VLAN Tag number. Default: 65536 The lowest value in the range of VLAN tags that you want to define. Default: 65536
342
Parameter
VLAN Tag Range To Group Mode
Description
The highest value in the range of VLAN tags that you want to define. Default: 65536 The mode of the group. Values: DiscreteSelect Discrete if you define a single VLAN tag number. RangeSelect Range if you define the range of the group.
MAC Groups
A MAC group on a LinkProof device groups a set of MAC addresses into single entity with a given name. You can use the MAC group, for example, in bandwidth management policies.
Configuring MAC Groups
To configure MAC group 1. Select Classes > Modify > MAC Groups. The Modify MAC Address Groups Table is displayed. 2. Click Create. The Modify MAC Address Groups Table Create pane is displayed. 3. Configure the parameters; and then click Set.
Table 180: Modify MAC Address Groups Parameters
Parameter
Group Name MAC Address
Description
The name of the MAC address group. The MAC address.
Viewing Active MAC Groups
To view active MAC groups Select Classes > View Active > MAC Groups. The Active MAC Address Groups Table is displayed with read-only parameters.
Table 181: Active MAC Address Groups Parameters
Parameter
Group Name MAC Address
Description
The name of the MAC address group. The MAC address.
343
Updating PoliciesClasses
If you modify the configuration of a class that is used in an enabled policy, you need to activate the latest changes.
To activate the latest changes 1. 2. Select Classes > Update Policies. The Activate Latest Changes pane is displayed. Click Set.
Discrete Networks
A Discrete Network is a configuration object containing a list of discrete IP addresses and VLAN tags. The Discrete Networks feature is useful in the following situations: The available device resources prohibits using a regular Flow Policy. The required configuration effort prohibits using a regular Flow Policy. The Discrete Networks feature eliminates the need to create (or update) a Flow Policy for each IP addressa task that usually takes several seconds per policy.
You can use a Discrete Network when classifying IP traffic in a Flow Policy or bandwidthmanagement policy. Changes to the elements of a Discrete Network only affect new entries that are classified by it. Changes to the elements of a Discrete Network do not affect the Flow configuration, bandwidth-management configuration. The configuration of an element of a Discrete Network object comprises the parameters Network Name, Network Address, Network VLAN Tag. A Discrete Network object is created when the first IP address is associated with the Discrete Network name. A Discrete Network object is deleted when the last IP address is removed from the Discrete Network name. Depending on your global configuration (uniqeness-status), IP addresses must either be unique across all the Discrete Network objects (represented by the Network Name parameter) or may be associated with multiple Network Name parameter. You can create a Discrete Network with the IP address of a network (for example, 1.1.1.0), since no single IP address has that source address. The following table is an example of a Discrete Network Table on a device whose global configuration allows IP addresses to be associated with multiple Discrete Network objects. Each row in the table is one element of a Discrete Network object (represented by the Network Name parameter).
Table 182: Discrete Network Table Example
Network Name
DiscreteNetwork_1 DiscreteNetwork_1 DiscreteNetwork_1
Network Address
1.2.3.4 1.2.3.5 1.2.3.6
Network VLAN Tag

No Tag No Tag No Tag
344
Table 182: Discrete Network Table Example
Network Name
DiscreteNetwork_1 DiscreteNetwork_1 DiscreteNetwork_2 DiscreteNetwork_2
Network Address
10.200.201.8 10.200.201.9 192.168.10.1 1.2.3.4
Network VLAN Tag

10 10 11 No Tag
You can configure Discrete Networks using CLI or SNMP.
CLI Commands for the Discrete Networks Feature

LinkProof exposes the following CLI commands for the Discrete Networks feature:
lp discrete-net clear <Network Name>

Clears the entire discrete the entire Discrete Network object.
lp discrete-net filtered-table -i
Displays a table of the Discrete Networks configured on the device filtered according to IP address.
lp discrete-net filtered-table -n
Displays a table of the Discrete Networks configured on the device filtered according to Network Name.
lp discrete-net filtered-table -v
Displays a table of the Discrete Networks configured on the device filtered according to VLAN tag.
lp discrete-net global uniqeness-status get

Displays the status of this parameter.
Note: This parameter is exposed in Web Based Management also.
lp discrete-net global uniqeness-status set {enable|disable}

Specifies whether an IP address in a Discrete Network must be unique per network name. Values: enableThe IP addresses in a Discrete Network must be unique per Network Name (that is, cannot be in another Discrete Network on the device) or can be used in multiple Discrete Networks on the device. disableThe IP addresses in a Discrete Network can be used in multiple Discrete Networks on the device.
Default: disable
345
lp discrete-net global write-cdb-status get

Displays the status of this parameter.
lp discrete-net global write-cdb-status set {enable|disable}

Specifies whether the device writes the Discrete Networks table to the configuration file. Default: disable
Caution: Writing the Discrete Networks table to the configuration file consumes significant device resources if the table contains many entries.
lp discrete-net statistics
Displays statistics of the Discrete Networks on the device, which you can use for diagnostic purposes.
lp discrete-net table
Displays the Discrete Networks table, which comprises the columns Network Name, Network Address, and Network VLAN Tag.
lp discrete-net table {create|add} <Network Name> <Network Address> <Network VLAN Tag>
Creates the specified Discrete Network element. The value 0 for Network VLAN Tag parameter specifies no VLAN tag.
lp discrete-net table {destroy|del} <Network Name> <Network Address> <Network VLAN Tag>
Deletes the specified Discrete Network element. The value 0 for Network VLAN Tag parameter specifies no VLAN tag.
lp discrete-net table get <Network Name> <Network Address> <Network VLAN Tag>
Displays the specified Discrete Network element.
Configuring the Discrete Network Parameters Exposed in Web Based Management

You perform most of the configuration tasks of the Discrete Network feature using CLI or SNMP.
To configure the Discrete Network parameters exposed in Web Based Management 1. 2. Select LinkProof > Global Configuration > Discrete Network. The Global Configuration Discrete Network pane is displayed. Configure the parameters; and then, click Set.
346
Table 183: Discrete Network Parameters in Web Based Management
Parameter
Write to CDB Status
Description
Specifies whether the device writes the Discrete Networks table to the configuration file. Values: Enable, Disable Default: Disable
Caution: Writing the Discrete Networks table to the configuration file consumes significant device resources if the table contains many entries. Entries Uniqueness Status Specifies whether an IP address in a Discrete Network must be unique per network name. Values: EnableThe IP addresses in a Discrete Network must be unique per Network Name (that is, cannot be in another Discrete Network on the device) or can be used in multiple Discrete Networks on the device. DisableThe IP addresses in a Discrete Network can be used in multiple Discrete Networks on the device. Default: Disable
Protocol Discovery
The Protocol Discovery feature enables you to recognize the different applications running on your network. This section contains the following topics: Protocol Discovery Overview, page 347 Protocol Statistics Global Parameters, page 348 Protocol Discovery Policies, page 348 Viewing the Protocol Discovery Statistics, page 350
Protocol Discovery Overview

To use the Bandwidth Management module in an optimal way, network administrators must be aware of the different applications running on their network and the amount of bandwidth the applications consume. To enable a full view of the different protocols running on the network, LinkProof supports the t Protocol Discovery feature. You can activate the feature on the entire network or on separate subnetworks by defining Protocol Discovery policies.
Note: You can use the Statistics Tuning pane to view and edit the tuning parameters for Protocol Discovery Policies (the current size of the table for Protocol Discovery Policies entries) and Protocol Discovery Report (the total number of the discovered protocols that can be recorded by the device). To access the Statistics Tuning pane, select Services > Tuning > Statistics.
347
Protocol Statistics Global Parameters

Use the Protocol Statistics Global Parameters pane to configure the global parameters of protocol statistics.
To configure Protocol Statistics global parameters 1. 2. Select Performance > Protocol Statistics > Global Parameters. The Global Parameters pane is displayed. Configure the parameters; and then, click Set.
Table 184: Protocol Statistics Global Parameters
Parameter
Protocol Monitoring Status
Description
Enables or disables the monitoring of protocol statistics by the device. Values: Enabled, Disabled Default: Disabled
Protocol Statistics Reporting Period Protocol Statistics Reporting (SRP)
The time, in seconds, that the device monitors protocol statistics. Default: 60 (seconds) Enables or disables Protocol Statistics Reporting (SRP). The SRP Management Host IP Address must be configured in SRP Management Host IP Address pane (Services > Statistics Monitor > SRP) of the machine on which to create the statistics files. Since the statistics files are cumulative, you must make sure that you disable the Statistics Reporting Mode before you create files larger than you desire. Failure to do so can result in the creation of files that fill all available memory. Values: TrueEnables SRP. FalseDisables SRP. Default: False
Protocol Statistics Aging
The interval, in seconds, at which the device ages (deletes old) statistics. Default: 10 The device classifies traffic on the default gateway only. Values: enable, disable Default: disable
Classification on default gateway only
Protocol Discovery Policies

A Protocol Discovery policy consists of a set of traffic classification criteria.
To configure a Protocol Discovery policy 1. 2. Select Performance > Protocol Statistics > Protocol Discovery Policies. The Protocol Discovery Policies pane is displayed. Click Create. The Protocol Discovery Policies Create pane is displayed.
348
LinkProof User Guide Bandwidth Management 3. Configure the parameters; and then, click Set.
Table 185: Protocol Discovery Policy Parameters
Parameter
Name Index Destination
Description
The user-defined name of the policy. Location of policy in the protection table that reflects the order in which the classification is performed. Specifies the destination of the traffic. Can be specific IP addresses or a range of IP addresses or IP subnet address. Default: anyCovers traffic to any destination. Defines the source of the traffic. Can be specific IP addresses, or a range of IP addresses or IP subnet address. Default: AnyCovers traffic from any source Enables discovery of applications and protocols in the traffic sent to a transparent network device. Default: None Enables discovery of applications and protocols in the traffic sent by a transparent network device (firewall or router). Default: None Classifies only traffic received on certain interfaces of the device. Enables you to set different policies to identical traffic classes that are received on different interfaces of the device. Default: None Defines VLAN traffic classification according to VLAN ID (VLAN Identifier) tags. Default: None Defines the direction of the traffic. Values: One WayFrom source to destination. Two WayFrom source to destination and from destination to source. Default: Two Way
Source
Destination MAC Address Group
Source MAC Address Group
VLAN Tag Group
Direction
Operational Status
Specifies whether the feature is active or inactive. Values: Active Inactive Default: Active
Classification Point
Specifies whether the classification is done before of after packet modification. Values: After ChangesClassifies the device after the packet changes. Before ChangesClassifies the device before the packet changes. Default: After Changes
349
Viewing the Protocol Discovery Statistics

Use the Protocol Statistics Table pane to view the global parameters of protocol statistics. To view the table in the Protocol Statistics Table pane, Protocol Statistics Monitoring must be enabled (see Protocol Statistics Global Parameters, page 348). The following table describes the columns of the Protocol Statistics Table.
Parameter
Policy Name Protocol Port Bandwidth (Kbits) Peak Bandwidth
Description
Name of the policy. IP or Other. TCP/UDP port used by the protocol. Total bandwidth (Kbit/s) used for this protocol-discovery policy during the last second. Peak bandwidth, in Kbit/s, used for this protocol during the last period, per protocol.
To view the protocol statistics table Select Performance > Protocol Statistics > View Protocol Statistics. The Protocol Statistics Table pane is displayed.
Port Bandwidth
To optimize the queuing algorithm, it is essential for the BWM module to be aware of the maximum available bandwidth on the ports. This can configured via the BWM port Bandwidth table. By default, the maximum available throughput is determined by the port type100 Mbit/s for the FE ports and 1 Gbit/s for the Gigabit Ethernet ports. The priority mechanism will only begin to function upon link saturation. Configuring the maximum throughput is the only way of telling if the link is saturated.
To define a maximum available bandwidth for a port 1. 2. 3. 4. Select BWM > Miscellaneous > Port Bandwidth Table. The Port Bandwidth Table pane is displayed. Select the port whose maximum available bandwidth you want to define. The Port Bandwidth Table Update pane is displayed. In the Port Bandwidth [kbps] text box, type the required value. Click Set.
Cancelling Interface Classification

You can cancel classification according to port or according to VLAN. To improve performance, you can configure the Bandwidth Management module to exclude from the classification effort the traffic running through specified physical ports and/or VLANs.
350
To cancel interface classification by port 1. Select BWM > Miscellaneous> Cancel Classification Per Port. The Classification is not performed for the following input ports pane is displayed. 2. Configure the parameters; and then, click Set.
Parameter
Inbound Port Outbound Port Direction
Description
The number of the required port for inbound traffic. The number of the required port for outbound traffic. The direction of the traffic flow through each port. Values: OnewayThe traffic flows in through the inbound port and out through the outbound port. TwowayThe traffic flows both ways through both ports.
To cancel interface classification by VLAN Set the VLAN tag on the interface to 0.
Example Time-based BWM Policy

This section describes an example configuration of a BWM policy for HTTP traffic, which runs for one hour every day.
Note: If you need to run a BWM policy with a schedule, you configure the BWM policy first. Then, you configure the start- and finish-event schedules, and associate the schedules with the BWM policy. The configuration of the example BWM policy involves the following: 1. Configuring the Example BWM Policy, page 352 2. Configuring the Example Start-Event Schedule, page 352 3. Configuring the Example Finish-Event Schedule, page 353 4. Associating the Start- and Finish-Event Schedules with the Example BWM Policy, page 353 5. Activating the Latest Changes for the Example BWM Policy, page 354
351
Configuring the Example BWM Policy
To configure the example BWM policy 1. 2. 3. Select BWM > Modify > Policies. The Modify Policies Table pane is displayed. Click Create. The Modify Policies Table Create pane is displayed. Specify the parameters; and then, click Set.
Table 187: BWM Policy Parameters for Example Time-based BWM Policy
Parameter
Index Name Destination Source Action Direction Priority Description Guaranteed Bandwidth Service Type Service Operational Status Packet Marking Maximum Bandwidth Inbound Physical Port Group VLAN Tag Group Policy Group
Value
1 HTTPPriority any any Forward Two Way 7 Example BWM policy 1024 Basic Filter http Active None 0 None None None
Configuring the Example Start-Event Schedule
To configure the example start-event schedule 1. 2. 3. Select Services > Event Scheduler. The Event Scheduler pane is displayed. Click Create. The Event Scheduler Create pane is displayed. Configure the parameters; and then, click Set.
Table 188: Start-Event Scheduler Parameters for Example Time-based BWM Policy
Parameter
Name Frequency
Values
HTTPPriority_Start Daily
352
Table 188: Start-Event Scheduler Parameters for Example Time-based BWM Policy
Parameter
Time Days Date
Values
2200 All checkboxes must be cleared. 00000000
Configuring the Example Finish-Event Schedule
To configure the example finish-event schedule 1. Select Services > Event Scheduler. The Event Scheduler pane is displayed. 2. Click Create. The Event Scheduler Create pane is displayed. 3. Configure the parameters; and then, click Set.
Table 189: Finish-Event Scheduler Parameters for Example Time-based BWM Policy
Parameter
Name Frequency Time Days Date
Values
HTTPPriority_Finish Daily 2300 All checkboxes must be cleared. 00000000
Associating the Start- and Finish-Event Schedules with the Example BWM Policy
To associate the start- and finish-event schedules with the example BWM policy 1. Select BWM > Modify > Policy Extensions. The Modify Policies Extensions pane is displayed. 2. From the table, select HTTPPriority. The Modify Policies Extensions Update pane is displayed with HTTPPriority displayed in the Name field. 3. Configure the parameters; and then, click Set.
Table 190: BWM Policy Extension Parameters for Example Time-based BWM Policy
Parameter
From Farm To Farm Classification Point Traffic Flow Identification Traffic Flow Max BW Max Concurrent Sessions
Value
Leave empty. Leave empty. After Changes None 0 0
353
Table 190: BWM Policy Extension Parameters for Example Time-based BWM Policy
Parameter
Max HTTP Rqts Per Second Cookie Field Identifier Activation Schedule Inactivation Schedule
Value
0 Leave empty. HTTPPriority_Start HTTPPriority_Finish
Activating the Latest Changes for the Example BWM Policy
To activate the latest changes 1. 2. Select BWM > Update Policies. The Activate Latest Changes pane is displayed. Click Set.
354
Chapter 9 Health Monitoring

This chapter describes Health Monitoring. This chapter contains the following sections: Health MonitoringIntroduction, page 355 Health Check Configuration, page 357 Farm Health Checks, page 381
Health MonitoringIntroduction
This section describes the general function of the Health Monitoring module and the basic healthmonitoring concepts. This section contains the following topics: Health Monitoring Module, page 355 Response Level, page 355 Checked Elements, page 356 Health Checks, page 356 Methods, page 356 Binding and Groups, page 356
Health Monitoring Module

The Health Monitoring module is responsible for checking the health of the network elements such as servers, firewalls, and next-hop routers (NHRs) that are managed by the LinkProof device. The Health Monitoring module determines which network elements are available for service to enable the LinkProof device to load balance traffic among the available resources. Traffic management decisions are based mainly on the availability of the load-balanced elements and on other resources on the data path. The module provides flexible configuration for health monitoring of the load-balanced elements. The module supports various predefined and userdefined checks, and enables you to create dependencies between health checks of different elements.
Response Level
LinkProof can load balance the traffic between servers according to Response Level, which enables the user to always serve clients using the fastest server. 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 actual response time to the configured Timeout. The 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 from 1 through 9 defines the samples value. For example, if the you configure two health checks, c1, which checks ping to server 1, and c2, which checks ping to server 2, and you set the Track Load flag for both checks, two load factors will be generated. LinkProof achieves Response Time Load Balancing by choosing the Response Time Dispatch Method in the farm parameters. The LinkProof device then load-balances the traffic to the fastest element until the Load Factors are equal.
355
LinkProof User Guide Health Monitoring
Checked Elements
A checked element is a network element that is managed and load balanced by the LinkProof device. For example, LinkProof-checked elements are the farm servers, NHRs and LRP, and PRP reports. The health of a checked element may depend on a network element that the device does not load balance.
Health Checks
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. For more information, see Creating a Regular Health Check, page 358. A network element can be tested using one or several health checks.
Methods
Health-check methods are applications or protocols that the LinkProof device uses to check the health of network elements. For example, a health-check method can be Ping, HTTP or other. Although the Health Monitoring module provides a wide array of predefined methods, user-defined methods are also supported. In addition, method-specific arguments can be configured for each health check. For a complete list of supported health-check methods, see Table 194 - Health Check Methods, page 362.
Binding and Groups

The health check defines only how to check elements, however, you need to define which of the checked elements are affected by the results of these checks and how the results are to affect them. You do this by the means of the Health Check Binding function. Health Check Binding describes the relation between the Checked Elements (the load balanced elements) and health checks and defines how the health checks affect the health of the Checked Elements. For example, when a health check is bound to a Checked Element and the check fails, the status of the checked element is changed to Not in Service. A checked element may be bound with more than one health check. For example, a Web server can be bound to an HTTP check, which verifies that the Web server is functioning, and to another health check that makes sure that the database server used by this Web server is also functioning. In addition, a health check can be associated with more than one checked element, meaning that a single resource affects the status of multiple Checked Elements. For example, a single database server may influence the health of multiple Web servers. The shared resource (the database server) is tested only once, and the test results affect multiple checked elements. When a health check fails, the Health Monitoring module reevaluates the status of all checked elements bound to the check. You can group health-check binding for complex conditioning of tests, using logical AND/OR.
356
Health Check Configuration

This section describes how to configure health monitoring according to health check types and contains the following topics: Configuring Health Monitoring Global Parameters, page 357 Managing the Health Checks in the Check Table, page 358 Bindings and Groups, page 374 User-Defined Health Check MethodsPacket Sequence Table, page 375 Configuring a Diameter Health Check, page 1
Configuring Health Monitoring Global Parameters
To configure the global parameters for health monitoring 1. Select Health Monitoring > Global Parameters. The Health Monitoring Global Parameters pane is displayed. 2. Configure the parameters; and then, click Set.
Table 191: Health Monitoring Global Parameters
Parameter
Health Monitoring Status
Description
The Health Monitoring Status mode. Values: DisableThe device does not use Health Monitoring. EnableThe device uses the advanced Health Monitoring capabilities, configured within the module. Default: Enable
Response Level Samples
The number of samples that device uses to calculate the average Response Level, which indicates how fast the round-trip-time of each health check is. The Response Level is the ratio ActualResponseTime:ConfiguredTimeout. LinkProof uses the Response Level for load balancing with the Response Time Dispatch Method. LinkProof routes traffic to the fastest network element until the Load Factors are equal. Values: 0Disables the feature. 1-9 Default: 0
SSL Certificate Entry Name
The SSL Certificate entry name.
357
Managing the Health Checks in the Check Table

Use the Health Monitoring Check Table pane to do the following: View the Health Monitoring Check Table. For more information, see Health Monitoring Check Table, page 358. Create a new health check. For more information, see Creating a Regular Health Check, page 358. View and modify some parameters of the health checks that are currently defined in a database, prior to applying them to a network element. For more information, see the procedure To view or modify the configuration of a health check, page 360.
Health Monitoring Check Table

The Health Monitoring Check Table includes the following columns: Check NameThe name of the configured health check. MethodThe health check method (see Methods, page 356). StatusEither Passed or Failed. Destination HostThe destination host. If you use a hostname as the health check destination, the device performs a DNS query to resolve the IP address of the configured host and perform the health check using the resolved destination IP address. The device caches the DNS reply according to the replied TTL. To use host names, DNS client must be enabled on the device. Response LevelThe Response Level (see Response Level, page 355).
To view the Health Monitoring Check Table Select Health Monitoring > Check Table. The Health Monitoring Check Table pane is displayed.
Creating a Regular Health Check

A regular health check is a check of an individual network element. You can add or edit health check parameters through the Check Table. The Health Monitoring Check Table lists the configured health checks. If a check is not bound to any of the checked elements (see Binding and Groups, page 356), the check is still performed. If it fails, the device sends failure-notification messages, as configured (SNMP traps, syslog messages, or E-mail).
To create a regular health check 1. 2. Select Health Monitoring > Check Table. The Health Monitoring Check Table pane is displayed. Click Create. The Health Monitoring Check Table Create pane is displayed.
358
LinkProof User Guide Health Monitoring 3. Configure the parameters; and then click Set.
Table 192: Health Monitoring Check Table Create Parameters
Parameter
Check Name Method
Description
The user-defined name of the health check. The method for the health check, selected from the drop-down list. For descriptions of the methods, see Table 194 - Health Check Methods, page 362. Default: Ping The hostname or IP address of the checked element. The IP address of the next-hop router. This is needed in order to direct the health check session to a network elements MAC address. Default: 0.0.0.0
Destination Host Next Hop
Dest Port Arguments
The destination port, which is method specific. Default: 0 The additional argument for the relevant health check method. The possible arguments are based on the Method, and may be one or a combination of the following: You enter an argument in the following format: Argument1=value1| Argument2=Value2 For example, the following is an argument for an FTP check: USER=JohnSmith| PASS=ABC
Interval
The time interval, in seconds, between health checks. The value must be greater than the specified Timeout. Values: 1232-1 Default: 10
Retries
The number of times that a health check must fail before the Health Monitoring module reevaluates the elements availability status. Default: 5 The maximum number of seconds that the device waits for a response for the health check. Default: 5 The time, in seconds, that the device waits from initiating a check, until considering the relevant element heavily loaded so as not to send any new sessions to it.
Timeout
No New Session Timeout
359
Table 192: Health Monitoring Check Table Create Parameters
Parameter
Measure Response Time
Description
Specifies whether the response time of the check is used for loadbalancing decisions. This parameter is relevant only when Dispatch Method is Response Time LB. Default: Disabled Specifies whether the check fails when a reply is received according to the check arguments or the check passes when no reply is received. Values: DisableThe check fails when the server does not reply. EnableThe check passes when no reply is received. Default: Disable
Reverse Check Result
To view or modify the configuration of a health check 1. 2. 3. 4. Select Health Monitoring > Check Table. The Health Monitoring Check Table pane is displayed. From the Check Name column, click the required link. The Health Monitoring Check Table Update pane is displayed. View or modify the parameters according to Table 193 - Health Monitoring Check Table Update Parameters, page 360. Click Set.
Table 193: Health Monitoring Check Table Update Parameters
Parameter
Check Name Method
Description
The user-defined name (read-only) of the health check. The method for the health check (read-only). For descriptions of the methods, see Table 194 - Health Check Methods, page 362. The hostname or IP address of the checked element. The IP address of the next-hop router. This is needed in order to direct the health check session to a network elements MAC address.
Destination Host Next Hop
Dest Port Arguments
The destination port, which is method specific. The additional argument for the relevant health check method. The possible arguments are based on the Method, and may be one or a combination of the following: You enter an argument in the following format: Argument1=value1| Argument2=Value2 For example, the following is an argument for an FTP check: USER=JohnSmith| PASS=ABC
360
Table 193: Health Monitoring Check Table Update Parameters
Parameter
Interval
Description
The time interval, in seconds, between health checks. The value must be greater than the specified Timeout. Values: 1232-1 Default: 10
Retries
The number of times the device tries to perform the health check on an unresponsive element. Default: 5 The maximum number of seconds that the device waits for a response for the health check. The time, in seconds, that the device waits from initiating a check, until considering the relevant element heavily loaded so as not to send any new sessions to it. Specifies whether the response time of the check is used for load-balancing decisions. This parameter is relevant only when Dispatch Method is Response Time LB. Default: Disabled The normalized grade (read-only), given to the check, based on the response times of each successful check over the configured Response Level Sample rate and the configured timeout. The ID (read-only) of the health check. The status (read-only) of the health check. Specifies whether the check fails when a reply is received according to the check arguments or the check passes when no reply is received. Values: DisableThe check fails when the server does not reply. EnableThe check passes when no reply is received. Default: Disable
Timeout No New Session Timeout
Measure Response Time
Response Level
Check ID Status Reverse Check Result)
Uptime (%) Success Counter Failure Counter Average Duration
The percentage (read-only) of successful checks out of the total number of checks. The total number (read-only) of the successful checks bound to the checked element since Health Monitoring was enabled. The total number (read-only) of the unsuccessful checks bound to the checked element since Health Monitoring was enabled. The average duration (read-only), in milliseconds, of the checks (SumOfCheckDurations ResponseLevelSamples).
Predefined Health-Monitoring Check Methods

The following table describes the predefined health-monitoring check methods and the supported arguments. The arguments listed in the table are configurable through the Web Based Management (WBM) GUI.
361
Table 194: Health Check Methods
Method
ARP
Description
The module sends an Address Resolution Protocol request to the destination address, and waits for a reply. There are no extra supported arguments for this method. The module sends an initial request to the Citrix server on port 1604. In reply, the Citrix server sends the list of applications running on it. The module compares the applications available on the server, based on the Citrix reply, with a list of up to four applications configured by the user. If all the configured applications are running on the Citrix server, the check passes. If none of the configured applications are running, the module completes the handshake. Supported arguments: Up to four applications running on the server at any given time
Citrix App Browsing
Citrix ICA
The module initiates a connection to the Citrix server, using TCP port 1494 and performs a Citrix handshake. This check passes when the Health Monitoring module identifies the Citrix's reply within the first reply packet. There are no extra supported arguments for this method.
362
Method
DHCP
Description
The Dynamic Host Configuration Protocol allows the automatic configuration of individual hosts in a network. When a new client connects to the network for the first time, the DHCP servers assigns the client its IP address, Subnet Mask, Default Gateway, and other parameters. Using the DHCP health check, the device sends a DHCPDISCOVER message to the DHCP server. The DHCPDISCOVER is sent to the MAC address of the configured server, based on the Destination Host field. After sending the DHCPDISCOVER, the device sends a DHCPREQUEST to the server. Once the server replies, the device sends a DHCPRELEASE command to the DHCP server. When none of the arguments are configured, the device sends a DHCP request to the server and passes the check if the server replies with any IP address. When the physical interface of the device is down, the routing associated with this interface is also unavailable. As a result, checks using Relay Agent IP addresses belonging to the same subnet of that interface will fail. Supported arguments: IP AddressNon-mandatory parameter. When this field is configured, it can either accept an individual IP address or a network address. When the DHCP server replies to the health check, the device compares the servers reply with the configured value. If the server replies with an IP address or address range that is different from the configured value, the check fails. Subnet MaskMandatory only if the IP Address field is set. The Subnet Mask refers to the IP address and it allows configuring either an individual client (using 255.255.255.255) or any other subnet mask. Default GatewayNon-mandatory parameter. When this field is set, the device compares the servers reply with the configured value. If the server replies with an IP address that is different from the configured value, the check fails. DNS ServerNon-mandatory parameter. When this field is set, the device compares the servers reply with the configured value. If the server replies with an IP address that is different from the configured value, the check fails. WINS ServerNon-mandatory parameter. When this field is set, the device compares the servers reply with the configured value. If the server replies with an IP address that is different from the configured value, the check fails. DomainNon-mandatory parameter. When this field is configured, the device compares the servers reply with the configured value. If the server replies with an IP address that is different from the configured value, the check fails. MAC AddressNon-mandatory parameter. When this field is set, the device uses the configured MAC address as the MAC address within the DHCP packet (and not the source MAC address in the packets header.) By default, the device uses its base MAC address. Relay AgentNon-mandatory parameter. When this field is set, the device uses the configured address as the GIADDR field in the DHCP data. This field can accept only IP addresses that are IP interfaces of the device and virtual interfaces.
363
Method
Diameter
Description
To check Diameter application availability, the Diameter health check initiates a connection to the Diameter server. The module performs a Diameter handshake (CER/CEA) and sends an LIR message or another application message. Then, the Diameter connection is disconnected using the DPR or the DPA message. The check passes when the specified result codes are received from the Diameter server. The Diameter server defines various Attribute Value Pairs (AVP) and expected attribute values in the response received from the Diameter server. Traffic flow with the Diameter Health check consists of the following steps: 1. TCP connection handshake. 2. Client sends CER (Capabilities Exchange Request) message and server answers with CEA message (Capabilities Exchange Answer). 3. Client sends LIR (Location Info Request) message and server answers with LIA message or, alternatively another application message or no application message at all, as specified by the administrator. 4. Client sends DPR (Disconnect Peer Request) message and server answers with DPA message (Disconnect Peer Answer). 5. TCP connection close. For information on configuring a Diameter health check, see Managing the Diameter Argument Lists Table, page 378 and Managing Binary File Transfer for Diameter Health Checks, page 380.
DNS
The module submits a DNS query to the configured destination address and host. The module verifies that the reply is received with no errors, and that the reply matches a specific address (if specified). If the IP address parameter is not defined, only the return code of the reply is validated (not the IP address it contains). Supported arguments: Host NameThe name of the to query. Host AddressThe address to match.
FIX
The module creates a Financial Information eXchange (FIX) protocoli packet and sends it to the FIX server (after the TCP handshake). A successful check is a check where in the reply packet, the TestReqID value is the same as the one configured. The SenderCompID is the configured value of the TargetCompID field and vice versa, and the FIX version is the same as the configured value. Supported arguments: TESTREQID(Non-mandatory) Test Request identification. This text is appended to tag TestReqID (112) that is sent as the message. The default value is the number of seconds since 01/01/1970. SENDERCOMPIDUsed as a standard header field by the FIX protocol. This field is a mandatory field. TARGETCOMPIDUsed as a standard header field by the FIX protocol. This field is a mandatory field. FIX VersionThe FIX version which will be used by the check. This field is a mandatory field.
364
Method
FTP
Description
The module executes USER and PASS commands on the FTP server. When the login process is successfully completed, the module executes a SYST command. It can verify the existence of the file on the FTP server, but it does not download the file or check its size. The module verifies that all the commands are executed successfully and then terminates the connection. Supported arguments: Username, Password, Filename Note: The module uses a control session only, not a data session.
HTTP
The module submits an HTTP request to the destination IP address. In addition, it is possible to define a specific URL to test. The request can be a GET, POST, or HEAD request. Requests can be in a proxy format or a Web format, and may include a no-cache directive. The module verifies that the returned status is 200. If the checked server is password protected, the module may send an authorized name and user password. The module sends the HTTP request in HTTP 1.0 format. Supported arguments: PathThe path. HostnameThe hostname. HTTP MethodGET, POST, or HEAD. Proxy HTTPYes or No. Pragma NocacheYes or No UsernameFor basic authentication. PasswordFor basic authentication. Match search stringText for search within the HTTP header and body with the Match mode flag that indicates whether the text must appear or not. Match modeEither String exists or String is absent. HTTP return codeThe module supports up to four valid HTTP return codes in addition to the return code of 200.
HTTPS
The module performs an SSL handshake towards the server and after the session starts, the module performs a GET request from the checked element. Supported arguments: PathThe path. HostnameThe hostname. HTTPS MethodGET, POST, or HEAD. UsernameFor basic authentication. PasswordFor basic authentication. Match search stringText for search within the HTTP header and body with the Match mode flag that indicates whether the text must appear or not. Match modeEither String exists or String is absent. HTTP return codeUp to four valid HTTP return codes in addition to the return code of 200.
IMAP4
The module executes a LOGIN command to the IMAP server, and verifies that the returned code is OK. Supported arguments: Username, Password
365
Method
LDAP
Description
The Health Monitoring module enhances the health checks for LDAP servers by searching in the LDAP server. Before the module performs the search, it first issues a bind command to the LDAP server and after performing the search, it closes the connection with unbind command. A successful search receives an answer from the server that includes a searchResultEntry message. An unsuccessful search receives only an answer of searchResultDone message. Supported arguments: User NameA user with privileges to search the LDAP server. PasswordThe password of the user. Base objectThe location in the directory from which the LDAP search begins. Attribute nameThe attribute to look for (for example, CNCommon Name). Search valueThe value to search. Search ScopeEither baseObject, singleLevel, or wholeSubtree. Search Deref AliasesEither neverDerefAliases, derefInSearching, derefFindingBaseObj, or derefAlways.
LDAPS
The Health Monitoring module performs LDAP health checks over the SSL transport layer. When using LDAP over SSL, the device uses the same SSL private key as the HTTPS health check. When using the LDAPS checks, Radware recommends that you use values greater than 15 seconds for Interval parameter and 10 seconds for the Timeout parameter. Supported arguments: User NameA user with privileges to search the LDAP server. PasswordThe password of the user. Base objectThe location in the directory from which the LDAP search begins. Attribute nameThe attribute to look for (for example, CNCommon Name). Search valueThe value to search Search ScopeEither baseObject, singleLevel, or wholeSubtree. Search Deref AliasesEither neverDerefAliases, derefInSearching, derefFindingBaseObj, or derefAlways.
NNTP
The Health Monitoring module executes a LIST command and verifies that the returned status is valid. There are no extra supported arguments for this method. The Health Monitoring module checks the status of the physical interface. When the link is up, the check passes. Supported argument: Port Number The Health Monitoring module sends an ICMP echo request to the destination address and waits for an echo reply. The module checks that the reply was received from the same destination address that the request was sent to and that the sequence number is correct. Supported arguments: FailThe value No (default) signifies that the check fails when the module receives no reply from the server. The value Yes signifies that the check is considered successful when the module receives no reply from the server. Ping Data SizeThe size, in bytes, of the ICMP echo request (1 byte to 1024 bytes). When not configured, the default is 64 bytes.
Physical Port
Ping
366
Method
POP3
Description
The Health Monitoring module executes USER and PASS commands on the POP3 server, and checks that the returned code is +OK. Supported arguments: Username, Password
RADIUS The Health Monitoring module sends an Access-Request packet with a user name, Authentication password, and a Secret string, and verifies that the request was accepted by the server, which then expects an Access Accept reply. Supported arguments: Username, Password, Secret Note: Ensure the RADIUS server is configured to accept RADIUS requests for the device. RADIUS Accounting The Health Monitoring module sends an RADIUS Accounting-Request packet with a user name, password, and a Secret string, and verifies that the request was accepted by the server, which then expects an Access Accept reply. Ensure the RADIUS server is configured to accept RADIUS requests from the LinkProof device. If the Destination Port Number parameter is not configured, the device uses UDP port 1813. Supported arguments: Username, Password, Secret RTSP The Health Monitoring module executes a DESCRIBE command and expects a return status of 200. Supported arguments: Host Name, Path SIP TCP The Health Monitoring module uses the OPTIONS method to query SIP proxies and end-points as to their capabilities. The capabilities themselves are not relevant to the health check. The check is successful if the module receives a 200 OK response from the server or other specified valid code. Supported arguments: Request URIThe requests destination. FromThe logical name of the device. Max ForwardThe maximum number of hops between proxy servers. The default is 1. Match search stringText for search within the header and body with the Match mode flag that indicates whether the text must appear or not. Match modeEither String exists or String is absent. SIP return codeThe module supports up to four valid return codes in addition to the return code of 200.
367
Method
SIP UDP
Description
The Health Monitoring module uses the OPTIONS method to query SIP proxies and end-points as to their capabilities. The capabilities themselves are not relevant to the health check. The check is successful if the module receives a 200 OK response from the server or other specified valid code. Supported arguments: Request URIThe requests destination. FromThe logical name of the device. Max ForwardThe default is 1. Match search stringText for search within the header and body with the Match mode flag that indicates whether the text must appear or not. Match modeEither String exists or String is absent. SIP return codeThe module supports up to four valid return codes in addition to the return code of 200.
SMTP
The Health Monitoring module executes a HELLO command to the SMTP server and checks that the returned code is 250. Supported argument: Server name for the HELO command (default is Radware). The Health Monitoring module sends an SNMP GET request, and validates the value in the reply. The SNMP check supports INTEGER, Counter, and Gauge data types. Integer can be a negative value. Counter and Gauge must be greater than 0. Supported arguments: OIDThe SNMP Object ID to be checked. CommunityThe SNMP community. Min. valueThe check fails if the returned value is less than the specified Min. value Max valueThe check fails if the returned value is greater than the specified Max value. No New Sessions valueThe bound element is set to No New Sessions when the returned value is greater than the specified No New Sessions value. Use Results For Load BalancingSpecifies whether the results of the can be used for a load-balancing decision, similar to Private Parameters Load Balancing Algorithms. Values: Yes, No. Note: For a device to consider the outcome of the check in the load-balancing decisions, the farms Dispatch Method must be set to Response Time.
SNMP
SSL Hello
The Health Monitoring module sends an SSL Hello packet to the server (using SSL3), and waits for an SSL Hello reply. The session is then closed (using a RESET command). Supported arguments: SSL Versioncan be either SSL V2.3 (the default) or SSL V3.0. SSL V3.0 means that pure SSLv3 is used. SSL V2.3 means that the client sends an SSLv2 request to open an SSLv3 session (this is how Internet Explorer works, for example). Note: Since generating SSL keys on the server is a time-consuming process, Radware recommends that you use a timeout of three to five seconds.
368
Method
TCP Port
Description
The Health Monitoring module checks the availability of the specified TCP port. Supported arguments: Complete TCP handshakeDetermines whether to send an ACK packet before the RST packet or not. Setting this parameter to Yes results in the following TCP handshake flow: SYN, SYN_ACK, ACK, RST. Setting this parameter to No results in the following TCP handshake flow: SYN, SYN_ACK, RST. Complete with FINEither Yes or No.
TCP User Defined UDP Port
The Health Monitoring module uses a user-defined TCP health check. Supported argument: Sequence IDWhich user-defined check to use The Health Monitoring module checks the availability of the specified UDP port. Note that this check does not test the servers availability, but the applications availability within the server. This is due to the nature of UDP. When the UDP application is operational, no reply is received, When the UDP application is not operational, an ICMP message UDP Port Unreachable is sent, so that the absence of a reply indicates the applications availability. This means that when the server is down, the application might still be considered as running. Therefore, you should use UDP Port check always in combination with another server availability check for example, Ping or ARP. There are no extra supported arguments for this method.
i The Financial Information eXchange (FIX) protocol is a technical specification for electronic communication of trade-related messages. More precisely, the FIX protocol is a series of messaging specifications developed through the collaboration of banks, broker-dealers, exchanges, industry utilities and associations, institutional investors, and information technology providers from around the world. These market participants share a vision of a common, global language for automated trading of securities, derivative, and other financial instruments (www.fixprotocol.org).
Configuring Health-Check Arguments

Table 6 - Syntax of Health-Check Method Arguments, page 370 describes predefined healthmonitoring check methods and supported arguments that you can configure in Web Based Management, CLI, Telnet, or SSH. In WBM, you type the argument string in the Arguments text box. Using Web Based Management, CLI, Telnet, or SSH, you can configure some specific arguments by typing a string with the following format in the Arguments text box:
<Arg1>=<Value1>|<Arg2>=<Value2>|<ArgN>=<ValueN>|
where:
<Arg1, <Arg2>, <ArgN> are argument names. <Value1>, <Value2>, <ValueN> are values for the associated arguments. | a pipe ( | ) is the delimiter between arguments. No extra spaces are allowed.
The following table describes the manually configurable arguments for each Check Method. In WBM, depending on the specified Method, you may type the argument string in the Arguments text box.
369
Table 6: Syntax of Health-Check Method Arguments
Method Name (ID) Argument Name

ARP (11) DNS (10) No argument supported HOST ADDR
Argument Description
Mandatory Additional Information
Default
Hostname to query. Yes Address to be received. No Validate only the DNS return code
FTP (6) HTTP (2)
USER PASS PATH
Username. Password. Path of file on Web server to be requested. Hostname. HTTP method to submit.
Yes Yes No Any configured value must begin with a slash (/). /
HOST MTD
No No G=GET P=POST H=HEAD No Y=Use proxy HTTP N=Use Web server HTTP
Server IP address G
PRX
Use proxy HTTP.
NOCACHE
Use pragma: nocache.
No
Y=Use pragma: N no-cache N = Do not use pragma: nocache
MTCH MEXIST
Pattern for content match. Specifies whether the content match pattern must be present or absent.
No No
Wildcards not supported. Y=Fail check if pattern is not found N=Fail check if pattern is found Y
USER PASS C1 C2 C3 C4
Username for basic No authentication. Password for basic authentication. Valid HTTP code. Valid HTTP code. Valid HTTP code. Valid HTTP code. No No No No No
370

IMAP (7) PING (0) USER PASS FAIL
Username. Password. Specifies whether the check fails when reply is received or not received. Packet size. Username. Password. Username. Password. RADIUS secret.

Yes Yes No Y = Fail when server replies N = Fail when server does not reply No Yes Yes Yes Yes Yes 11024 bytes
Default
DSIZE POP(3) RADIUS (12) USER PASS USER PASS SECRET RTSP (13) PATH
64
Path of file on RTSP Yes server to be requested. Hostname to use in No request. IP address of server.
HOST
371

SMNP OID COMM MIN
Object ID to be used by the check.

Yes
Default
The community Yes used by the device. The minimum value Yes for the check to pass. If the minimum is less than the configured, the check fails. The maximum Yes value for the check to pass. If the maximum is greater than the configured value, the check fails. No New Session. Yes The value between the NNS and the max. If the value falls between these two numbers, the checked element will be in No New Session. The measured response time for the check. Yes
MAX
NNS
UR
SSL Hello
SSLV
Can be either v23 Yes or v30. SSL v30 means pure SSLv3 is used. SSLv23 means that the client sends an SSLv2 request to open an SSLv3 session (this is how Internet Explorer works, for example). Argument for SMTP No HELO. SSL version. No
V23 (SSL v2.3) or V30 (SSL v3.0)
SMTP (4) SSL (14)
HELO SSLV
RADWARE V23 (SSL v2.3) V23 or V30 (SSL v3.0)
TCP Port (1)
No argument supported
No
372

TCP User Defined (8) UDP Port SIP UDP SEQID no args UR FROM FRWD
Default
Packet sequence ID Yes to submit. The URI for the check. The senders information. The maximum number of hops between proxy servers. Pattern for content match. Specifies whether the content match pattern must be present or absent. Valid SIP code. Valid SIP code. Valid SIP code. Valid SIP code. Yes Yes No
MTCH MEXIST
No No
Wildcards are not supported. Y=Fail check if pattern not found. N=Fail check if pattern is found.
C1 C2 C3 C4 LDAPS USER
No No No No If you configure a user, the password is mandatory. If you configure a user, the password is mandatory. If you configure BASEO, ATTR is mandatory. If you configure ATTR, BASEO is mandatory.
A user with No privileges to search the LDAP server. The password of the user. No
PASS
BASEO
The location in the directory from which the search starts. The attribute to search for, for example CN: Common Name The value to search.
No
ATTR
No
SEARV
No
373
Bindings and Groups

You can associate a health check with a checked element. You can also define whether the check is mandatory or not, and set the Group Number. Non-mandatory checks in a group are evaluated with a logical OR between them so if there is more than a single non-mandatory check in a group, a failure of one check does not fail the server. When several groups are associated with a single checked element, they are evaluated with a logical AND between them.
Note: When a group consists of a single check that is defined as Non-mandatory, then technically, it is Mandatory. The Group Number is unique per checked element. This means that, for example, group number 2 for Server1 and group number 2 for Server2 are two separate groups. Using groups enables the creation of complex health conditions for the Checked Elements. For example, consider a Web server that communicates with one of two database servers and must use one of two routers in order to provide service. This Web server will be bound using three different binding groups: one group contains health checks for the two routers (each check is Nonmandatory), one group contains health checks to the database servers (each check is Nonmandatory), and the third group contains the health checks on 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 cannot provide the required service. Up to 20 binding groups can be defined per checked element. A health check is still performed even if it is not bound to any of the checked elements. If the check fails, the device sends notification messages (SNMP traps, syslog messages or mail messages, as configured) indicating the failure of the check.
To view the Health Monitoring Binding Table Select Health Monitoring > Binding Table. The Health Monitoring Binding Table pane is displayed.
Table 7: Health Monitoring Binding Table Parameters
Parameter
Check
Description
The identification number of the health check as defined by the user in the Health Monitoring Check Table. Values: All checks as defined in the health-check database The checked element to which the health check is bound. Values: All defined servers configured on the device The group number to which the check belongs. The group number is unique per server. Specifies if the health check is mandatory for the health of the checked element. Values: Mandatory, Non-mandatory
Server Group Mandatory
374
To bind a health check to a network element 1. Select Health Monitoring > Binding Table. The Health Monitoring Binding Table pane is displayed. 2. Click Create. The Health Monitoring Binding Table Create pane is displayed. 3. Configure the parameters that are described in Table 7 - Health Monitoring Binding Table Parameters, page 374. 4. Click Set.
Viewing or Modifying the Configuration of a Health Check Binding
To view or modify the configuration of a health check binding 1. Select Health Monitoring > Binding Table. The Health Monitoring Binding Table pane is displayed. 2. Select the required binding. The Health Monitoring Binding Table Update pane is displayed. 3. View or modify the available parameters, which are described in Table 7 - Health Monitoring Binding Table Parameters, page 374. 4. Click Set.
User-Defined Health Check MethodsPacket Sequence Table

Note: User-defined health checks are available for TCP checks only. If you require a specific health check method that is not provided by the module, you can configure the health check protocol manually. You do this by defining, for every packet sequence, a specific, TCP/UDP, health check. First, you define a sequence of Send and Receive packets, containing a configurable string. The device will transmit the Send packets and verify that the string in the reply matches the string configured for the Receive packets. You can use that user-defined check in the health checks configuration. You configure packet sequences in the Health Monitoring Packet Sequence Table. The Health Monitoring Packet Sequence Table comprises the following columns: Seq IDThe ID number of the entire packet sequence. Each sequence defines a new userdefined check. All packets with the same Sequence ID belong to the same check. Pkt IDThe ID number of the specific packet within the sequence. The first Packet ID of each sequence must always be 0. Packet ID numbers of a sequence must be consecutive TypeThe type of packet, either Send (Transmit), or Receive. StringThe content of the packet for the 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 packets, it can include a regular expression. DescriptionA description of the specific packet in the sequence.
375
To create a packet sequence for a health check 1. 2. 3. Select Health Monitoring > Packet Sequence Table. The Health Monitoring Packet Sequence Table pane is displayed. Click Create. The Health Monitoring Packet Sequence Table Create pane is displayed. Configure the parameters; and then, click Set.
Table 8: Health Monitoring Packet Sequence Parameters
Parameter
Seq ID
Description
The ID number of the entire packet sequence. Each sequence defines a new user-defined check. All packets with the same Sequence ID belong to the same check. The ID number of the specific packet within the sequence. The first Packet ID of each sequence must always be 0. Packet ID numbers of a sequence must be consecutive
Pkt ID
Type String
The type of packet. Values: Send, Receive The content of the packet for the 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 packets, it can include a regular expression. A description of the specific packet in the sequence. Specifies how the Health Monitoring module checks for the required string. Values: Regular ExpressionThe search matches the regular expression to the value of the String parameter. BinaryThe search compares each character found to the ASCII value of the character defined in the String parameter.
Description Compare Method
To view or modify the configuration of a packet sequence for a health check 1. 2. 3. Select Health Monitoring > Packet Sequence Table. The Health Monitoring Packet Sequence Table pane is displayed. Select the required packet sequence. The Health Monitoring Packet Sequence Table Update pane is displayed. Configure the parameters; and then, click Set.
376
Table 9: Health Monitoring Packet Sequence Parameters
Parameter
Seq ID
Description
The ID number (read-only) of the entire packet sequence. Each sequence defines a new user-defined check. All packets with the same Sequence ID belong to the same check. The ID number (read-only) of the specific packet within the sequence. The first Packet ID of each sequence must always be 0. Packet ID numbers of a sequence must be consecutive
Pkt ID
Type String
The type of packet, either Send (Transmit), or Receive. The content of the packet for the 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 packets, it can include a regular expression. A description of the specific packet in the sequence. Specifies how the Health Monitoring module checks for the required string. Values: Regular ExpressionThe search matches the regular expression to the value of the String parameter. BinaryThe search compares each character found to the ASCII value of the character defined in the String parameter.
Description Compare Method
Health Monitoring Server Table

The Health Monitoring Server Table is a read-only table, which comprises the following columns: ServerIndex number of the element attached by the device. DescriptionThe user-defined description for the network server. Availability StatusThe availability status of the element: Available or Unavailable. Response LevelA normalized grade, given to the health check, based on the response times of each successful check over the configured Response Level Sample rate and the configured timeout.
You can select a server from the Server Table to view additional information.
To access the Server Table and view information on a specific server 1. Select Health Monitoring > Server Table. The Health Monitoring Server Table pane is displayed. 2. Select the server whose Health Monitoring information you need to view. The Health Monitoring Server Table pane is displayed.
377
Table 10: Health MonitoringServer Table Parameters
Parameter
Server Description Farm Name Availability Status IP Address Response Level
Description
Index number of the element attached by the device in the Application Server Table. The user-defined description for the network server. The name of the farm in which the server is included. Availability status of the element, Available or Unavailable. IP address of the network server. A normalized grade, given to the health check, based on the response times of each successful check over the configured Response Level Sample rate and the configured timeout. Percentage of health checks that received a successful response. The total number of successful health checks since Health Monitoring was enabled. The total number of unsuccessful health checks since Health Monitoring was enabled.
Uptime (%) Success Counter Failure Counter
Configuring a Diameter Health Check

To configure a Diameter health check, you need to configure a set of parameters to be used as attributes, a Diameter Argument List. You can configure multiple Diameter Argument Lists and use them to check the health of different Diameter servers. If the Diameter Argument List is configured to use a binary file, there is an additional procedure.
Managing the Diameter Argument Lists Table

The Diameter Argument Lists Table includes the following columns: Argument List Name Description Application Message Type: LIR/Binary File/None Binary File Provided: Yes/No/Not Applicable
To create a Diameter Argument List 1. 2. 3. 4. Select Health Monitoring > Diameter > Arguments List. The Diameter Argument List pane is displayed. Click Create. The Diameter Argument List Create pane is displayed. Configure the parameters according to Table 11 - Diameter Argument List Parameters, page 379. Click Set.
378
To view or modify an entry in the Diameter Argument Lists Table 1. Select Health Monitoring > Diameter > Arguments List. The Diameter Argument List Configuration pane is displayed. 2. Select the argument list name. The Diameter Argument List Configuration Update pane is displayed. 3. View or modify the parameters according to Table 11 - Diameter Argument List Parameters, page 379. Argument List Name and Binary File Provided are read-only. 4. Click Set.
Table 11: Diameter Argument List Parameters
Parameter
Argument List Name Description Origin-Host
Description
The name that you define for this Argument List. The user defined description of this argument list. The host name FQDN that identifies the endpoint that created the Diameter message and is present in all Diameter messages. Note: The Origin-Host AVP may resolve to more than one address. The realm of the originator of the Diameter message and is present in all Diameter messages. The value assigned to vendor of Diameter application by IANA. A Vendor-Id value of 0 (zero) in the CER or CEA messages is reserved and indicates that this field is ignored. Default: 0 The vendor assigned name for the product. Specifies the type of application message that will be sent after the Diameter connection is established. Values: LIRLinkProof generates an LIR (Location Info Request) message. Binary FileAssociates a binary file as the Diameter data for the health check packet. The maximum size for the binary file is one kilobyte. When you specify Binary File, you must upload a file to the device and attach it to this argument list (see Managing Binary File Transfer for Diameter Health Checks, page 380). NoneNo application message is sent. Default: LIR
Origin-Realm Vendor ID
Product-Name Application Message Type
Auth-Application-Id
The Auth-Application-Id AVP (AVP Code 258) is used to advertise support of the Authentication and Authorization portion of an application. Default: 0
379
Table 11: Diameter Argument List Parameters
Parameter
Auth-Session-State
Description
Specifies whether the state is maintained for a particular session. Values: State MaintainedUsed to specify that a session state is being maintained, and the access device must issue a session termination message when service to the user is terminated. This is the default value. No State MaintainedUsed to specify that no session termination messages will be sent by the access device upon expiration of the Authorization-Lifetime.
Default: State Maintained Destination-Realm Destination-Host The realm (FQDN) to which message is routed. The 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 address. Public identity of user referred to in LIR request. This AVP contains the public identity of a user in the IMS. The syntax of this AVP corresponds either to a SIP URL or a TEL URL. (TEL URLs describe voice call connections. It has format tel:phone-number. For example: tel:+5550002) A Diameter node must include this AVP in the Disconnect-Peer-Request message to inform the peer of the reason for its intention to shut down the transport connection. Values: RebootingA scheduled reboot is imminent. BusyThe peers internal resources are constrained, and it has determined that the transport connection needs to be closed. Do Not Want To Talk To YouThe peer has determined that it does not see a need for the transport connection to exist, since it does not expect any messages to be exchanged in the near future. Default: Rebooting Accepted Result Codes List of acceptable codes that can be received in a CEA, DPA, and LIA messages. The codes are separated by commas (,) or semicolons (;). You can remove or add values. Values: 2001DIAMETER_FIRST_REGISTRATION 2002DIAMETER_SUBSEQUENT_REGISTRATION 2003DIAMETER_UNREGISTERED_SERVICE 2004DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED 2005DIAMETER_SERVER_SELECTION Default: 2001, 2002, 2003, 2004, 2005
Public Identity
Disconnect Cause
Managing Binary File Transfer for Diameter Health Checks

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.
380
LinkProof User Guide Health Monitoring When you specify Binary File Provided in the Diameter Argument Lists Configuration pane, you must upload a file to the device and attach it to the argument list. If the Application Message Type is set to Binary File but the binary file is not configured, the device cannot use the Diameter Argument List as the parameters for a Diameter health check. Use the Diameter Binary File Transfer pane to upload or download the Diameter file to the device.
To upload the Diameter file 1. Select Health Monitoring > Diameter > Binary File Transfer. The Diameter Binary File Transfer pane is displayed. 2. In the Upload diameter file to device section, do one of the following: Browse to the Diameter file. From the Diameter Argument List Name drop-down list, choose the required Diameter Argument List.
3. Click Set.
To download the Diameter file 1. Select Health Monitoring > Diameter > Binary File Transfer. The Diameter Binary File Transfer pane is displayed. 2. In the Download diameter file to device section, from the Diameter Argument List Name drop-down list, choose the required Diameter Argument List. 3. Click Set.
To delete the Diameter file 1. Select Health Monitoring > Diameter > Binary File Transfer. The Diameter Binary File Transfer pane is displayed. 2. In the Delete diameter file to device section, from the Diameter Argument List Name dropdown list, choose the required Diameter Argument List. 3. Click Set.
Farm Health Checks

Used in large configurations with farms containing multiple servers, the farm-oriented health check automates and simplifies the health monitoring configuration process by replicating a defined check for all servers in a farm.
To configure a health check on a farm 1. In the relevant Farm Table pane (see LinkProof Farms, page 138), from Connectivity Check Status drop-down list, select Health Monitoring. 2. Click Set.
381
382
Appendix A Regular Expressions

This appendix provides an overview of the basic syntax of regular expressions that are supported in LinkProof modules. For example LinkProof supports regular expressions in the DNS Regexp Hostname table, in the Health Monitoring Module. These caret and dollar sign (^ and $) indicate the beginning and end of a string, respectively. For example:
^The matches any string that starts with The. of despair$ matches a string that ends in the substring of despair. âbc$ a string that starts and ends with abc, which can only be abc. notice a string that has the text notice within it.
If neither the caret nor dollar sign is used (as in the last example), this means that the pattern may occur anywhere within the string, and it is not hooked to any of the edges. The star, plus sign, and question mark (*, +, and ?) indicate the number of times a character or a sequence of characters may occur. These symbols mean zero or more, one or more, and zero or one respectively. For example:
ab* matches a string that has an a followed by zero or more bs (a, ab, abbb, and so on). ab+ same as ab*, but there is at least one b (ab, abbb, and so on). ab? there might be one or no b. a?b+$ a possible a followed by one or more bs ending a string.
Bounds can also be used. Bounds are defined inside the brace brackets and indicate ranges in the number of occurrences. For example:
ab{2} matches a string that has an a followed by exactly two bs (abb). ab{2,} matches a string that has at least two bs (abbb, abbbb, and so on). ab{3,5} matches a string that has from three to five bs (abbb, abbbb, or abbbbb).
The first number of a range must always be specifiedfor example, {0,2}, not {,2}. The star, plus sign, and question mark (*, +, and ?) denote the same as bounds {0,}, {1,}, and {0,1}, respectively. To quantify a sequence of characters, they must be defined within parentheses. For example:
a(bc)* matches a string that has an a followed by zero or more copies of the sequence bc. a(bc){1,5} matches a string that has one to five copies of bc.
The vertical bar also called a pipe (|) is an OR operator. For example:
hi|hello matches a string that includes either hi or hello. (b|cd)ef is a string that includes either bef or cdef. (a|b)*c is a string that has a sequence of alternating as and bs ending with c.
A period (.) stands for any single character. For example:
a.[0-9] matches a string that has an a followed by a single character and a digit. ^.{3}$ a string with exactly three (3) characters.
383
LinkProof User Guide Regular Expressions Bracket expressions specify which characters are allowed in a single position of a string. For example:
[ab] matches a string that has either an a or a b (identical to a|b). [a-d] a string that has lowercase letters a through d (identical to a|b|c|d and [abcd]). ^[a-zA-Z] a string that starts with a letter. [0-9]% a string that has a single digit before a percent sign. ,[a-zA-Z0-9]$ a string that ends in a comma, followed by an alphanumeric character.
You can also list the characters which you do not want to appear in the string. Use a caret (^) as the first symbol in a bracket expression. For example, %[â-zA-Z]% matches a string with a character that is not a letter, between two percent signs. To take the characters ^.[$()|*+?{\ literally, they must follow a backslash (\) to denote they have a special meaning. This includes the backslash character itself. Remember that bracket expressions are an exception to the above rule. Within brackets, all special characters, including the backslash, lose their special meanings. For example, [*\+?{}.] matches precisely any of the characters within the brackets.
384
Appendix B Predefined Basic Filters

The following table lists predefined basic filters that LinkProof supports. The list may vary depending on the product version. You can view the entire list of basic filters and their properties in the Modify Basic Filter Table pane (using Web Based Management, Classes > Modify Services > Basic Filters).
385
LinkProof User Guide Predefined Basic Filters
Table 12: Predefined Basic Filters
Name
000 001 010 011 100 101 110 111 aim-aol-any aol-msg ares_ft_udp_0 ares_ft_udp_1 bearshare_download_tcp_0 bearshare_download_tcp_1 bearshare_request_file_udp_0 bearshare_request_file_udp_1 bittorrent_command_1_0 bittorrent_command_1_1 bittorrent_command_1_2 bittorrent_command_1_3 bittorrent_command_1_4 bittorrent_command_2_0 bittorrent_command_2_1 bittorrent_command_2_2 bittorrent_command_2_3
Description
Routine Priority Immediate Flash ToS Flash Override CRITIC/ECP Internetwork Control Network Control AIM/AOL Instant Messenger AOL Instant Ares_FT_udp Ares_FT_udp BearShare_Download_tcp BearShare_Download_tcp BearShare_Request_File_udp BearShare_Request_File_udp BitTorrent BitTorrent BitTorrent BitTorrent BitTorrent BitTorrent BitTorrent BitTorrent BitTorrent
Protocol
IP IP IP IP IP IP IP IP TCP TCP UDP UDP TCP TCP UDP UDP TCP TCP TCP TCP TCP TCP TCP TCP TCP
OMPC Offset
1 1 1 1 1 1 1 1 0 0 36 40 0 4 0 4 0 4 8 12 16 0 4 8 12
OMPC Mask
e0000000 e0000000 e0000000 e0000000 e0000000 e0000000 e0000000 e0000000 ffff0000 0 ffffffff ff000000 ffffffff ffffffff ffffffff 00ffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
386
Name
bittorrent_command_2_4 bittorrent_command_2_5 bittorrent_command_3_0 bittorrent_command_3_1 bittorrent_command_3_2 bittorrent_command_3_3 bittorrent_command_3_4 bittorrent_command_3_5 bittorrent_command_4_0 bittorrent_command_4_1 bittorrent_command_4_2 bittorrent_udp_1_0 bittorrent_udp_1_1 citrix-admin citrix-ica citrix-ima citrix-ma-client citrix-rtmp diameter directconnect_file_transfer_0 directconnect_file_transfer_1 directconnect_file_transfer_2 dns emule_tcp_file_request_0 emule_tcp_file_request_1 emule_tcp_hello_message_0
Description
BitTorrent BitTorrent BitTorrent BitTorrent BitTorrent BitTorrent BitTorrent BitTorrent BitTorrent BitTorrent BitTorrent BitTorrent_UDP_1 BitTorrent_UDP_1 Citrix Admin Citrix ICA Citrix IMA Citrix MA client Citrix RTMP Diameter DirectConnect_File_transfer DirectConnect_File_transfer DirectConnect_File_transfer Session for DNS eMule eMule eMule
Protocol
TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP UDP UDP TCP TCP TCP TCP TCP TCP TCP TCP TCP UDP TCP TCP TCP
OMPC Offset
16 20 0 4 8 12 16 20 8 11 11 8 12 0 0 0 0 0 0 0 21 25 0 0 4 0
OMPC Mask
ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffff0000 ffffff00 ff000000 ff000000 ffffff00 ffff0000 0 0 0 0 0 0 ff000000 ffffffff ffffffff 0 ff000000 ffff0000 ff000000
387
Name
emule_tcp_hello_message_1 emule_tcp_secure_handshake_0 emule_tcp_secure_handshake_1 ftp-session gnutella_tcp_1_0 gnutella_tcp_2_0 gnutella_tcp_2_1 gnutella_tcp_3_0 googletalk_ft_1_0 googletalk_ft_1_1 googletalk_ft_1_2 googletalk_ft_1_3 googletalk_ft_2_0 googletalk_ft_2_1 googletalk_ft_4_0 googletalk_ft_4_1 groove_command_1_0 groove_command_1_1 groove_command_1_2 groove_command_2_0 groove_command_2_1 groove_command_3_0 groove_command_3_1 groove_command_3_2 groove_command_3_3 h.225-session
Description
eMule eMule eMule Session for FTP Gnutella_TCP_1 Gnutella_TCP_2 Gnutella_TCP_2 Gnutella_TCP_3 GoogleTalk_FT_1 GoogleTalk_FT_1 GoogleTalk_FT_1 GoogleTalk_FT_1 GoogleTalk_FT_2 GoogleTalk_FT_2 GoogleTalk_FT_4 GoogleTalk_FT_4 Groove Groove Groove Groove Groove Groove Groove Groove Groove Session Of H225
Protocol
TCP TCP TCP TCP TCP TCP TCP TCP UDP UDP UDP UDP UDP UDP UDP UDP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP
OMPC Offset
4 0 4 0 0 0 4 0 24 28 32 36 24 28 67 71 6 10 14 6 10 7 11 15 19 0
OMPC Mask
ffff0000 ff000000 ffff0000 0 ffffff00 ffffffff ffffffff ffffff00 ffffffff ffffffff ffffffff ffff0000 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffff0000 ffffffff ffffffff ffffffff ffffffff 0
388
Name
hdc1 hdc2 hdc3 hdc4 http http-alt https icecast_1 icecast_2 icecast_3 icmp icq icq_aol_ft_0 icq_aol_ft_1 icq_aol_ft_2 imap imesh_download_tcp_0 imesh_download_tcp_1 imesh_request_file_udp_0 imesh_request_file_udp_1 ip itunesdaap_ft_0 itunesdaap_ft_1 itunesdaap_ft_2 itunesdaap_ft_3 kazaa_request_file_0
Description
High Drop Class 1 High Drop Class 2 High Drop Class 3 High Drop Class 4 World Wide Web HTTP HTTP alternate HTTP over SSL IceCast_Stream IceCast_Stream IceCast_Stream ICMP ICQ ICQ_AOL_FT ICQ_AOL_FT ICQ_AOL_FT Internet Message Access iMesh_Download_tcp iMesh_Download_tcp iMesh_Request_File_udp iMesh_Request_File_udp IP Traffic iTunesDaap_FT iTunesDaap_FT iTunesDaap_FT iTunesDaap_FT Kazaa_Request_File
Protocol
IP IP IP IP TCP TCP TCP TCP TCP TCP ICMP TCP TCP TCP TCP TCP TCP TCP UDP UDP IP TCP TCP TCP TCP TCP
OMPC Offset
1 1 1 1 0 0 0 0 4 8 0 0 0 0 2 0 0 4 0 4 0 0 4 8 2 0
OMPC Mask
fc000000 fc000000 fc000000 fc000000 0 0 0 ffffffff ffffffff ffff0000 0 0 ffffffff ffffffff ffff0000 0 ffffffff ffffffff ffffffff 00ffffff 0 ffffffff ffffffff ffffff00 ffff0000 ffffffff
389
Name
kazaa_request_file_1 kazaa_request_file_2 kazaa_udp_packet_0 kazaa_udp_packet_1 ldap ldaps ldc1 ldc2 ldc3 ldc4 lrp manolito_file_transfer_0_0 manolito_file_transfer_0_1 manolito_file_transfer_0_2 manolito_file_transfer_1_0 manolito_file_transfer_1_1 manolito_file_transfer_2_0 manolito_file_transfer_2_1 mdc1 mdc2 mdc3 mdc4 meebo_get_0 meebo_get_1 meebo_get_2 meebo_get_3
Description
Kazaa_Request_File Kazaa_Request_File Kazaa_UDP_Packet Kazaa_UDP_Packet LDAP LDAPS Low Drop Class 1 Low Drop Class 2 Low Drop Class 3 Low Drop Class 4 Load Report Protocol Manolito Manolito Manolito Manolito Manolito Manolito Manolito Medium Drop Class 1 Medium Drop Class 2 Medium Drop Class 3 Medium Drop Class 4 MEEBO_GET MEEBO_GET MEEBO_GET MEEBO_GET
Protocol
TCP TCP UDP UDP TCP TCP IP IP IP IP UDP TCP TCP TCP TCP TCP TCP TCP IP IP IP IP TCP TCP TCP TCP
OMPC Offset
4 8 6 4 0 0 1 1 1 1 0 0 0 0 4 4 4 4 1 1 1 1 0 4 8 12
OMPC Mask
ffffffff ffff0000 ffffffff ffff0000 0 0 fc000000 fc000000 fc000000 fc000000 0 ffffffff ffffffff ffffffff ff000000 ff000000 ff000000 ff000000 fc000000 fc000000 fc000000 fc000000 ffffffff ffffffff ffffffff ffffffff
390
Name
meebo_get_4 meebo_get_5 meebo_get_6 meebo_get_7 meebo_get_8 meebo_post_0 meebo_post_1 meebo_post_2 meebo_post_3 meebo_post_4 meebo_post_5 meebo_post_6 meebo_post_7 msn-any msn-msg msn_msgr_ft_0 msn_msgr_ft_1 mssql-monitor mssql-server nntp nonip oracle-server1 oracle-server2 oracle-server3 oracle-v1 oracle-v2
Description
MEEBO_GET MEEBO_GET MEEBO_GET MEEBO_GET MEEBO_GET MEEBO_POST MEEBO_POST MEEBO_POST MEEBO_POST MEEBO_POST MEEBO_POST MEEBO_POST MEEBO_POST MSN Messenger Chat MSN Messenger Chat MSN_MSGR_FT MSN_MSGR_FT Microsoft SQL traffic-monitor Microsoft SQL server traffic Network News Non IP Traffic Oracle server Oracle server Oracle server Oracle SQL *Net version 1 Oracle SQL *Net version 2
Protocol
TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP NonIP TCP TCP TCP TCP TCP
OMPC Offset
16 20 24 28 32 0 4 8 12 16 20 24 28 0 0 0 48 0 0 0 0 0 0 0 0 0
OMPC Mask
ffffffff ffffffff ffffffff ffffffff ff000000 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffff00 ffffffff 0 ffffffff ffffffff 0 0 0 0 0 0 0 0 0
391
Name
pop3 prp radius rexec rshell rtp_ft_0 rtp_ft_1 rtp_ft_2 rtsp sap sctp skype-443-handshake skype-443-s-hello skype-80-l-56 skype-80-proxy skype-80-pshack skype-ext-l-54 skype-ext-pshack smtp snmp snmp-trap softethervpn443 softethervpn8888 soulseek_pierce_fw_0 soulseek_pierce_fw_1 soulseek_pierce_fw_2
Description
Post Office Protocol 3 PRP RADIUS protocol Remote Process Execution Remote Shell RTP_FT RTP_FT RTP_FT RTSP SAP SCTP Traffic Skype signature for port 443 Skype signature for port 443 Skype signature for port 80 Skype signature for port 80 Skype signature for port 80 Skype signature Skype signature Simple Mail Transfer SNMP SNMP Trap SoftEther Ethernet System SoftEther Ethernet System SoulSeek_Pierce_FW SoulSeek_Pierce_FW SoulSeek_Pierce_FW
Protocol
TCP UDP TCP TCP TCP UDP UDP UDP TCP TCP SCTP TCP TCP TCP TCP TCP TCP TCP TCP UDP UDP TCP TCP TCP TCP TCP
OMPC Offset
0 0 0 0 0 0 0 16 0 0 0 0 11 2 0 13 2 13 0 0 0 0 0 0 4 2
OMPC Mask
0 0 0 0 0 ffff0000 ffff0000 ffff0000 0 0 0 ff000000 ffffffff ffff0000 ffffffff ff000000 ffff0000 ff000000 0 0 0 ffffff00 ffffff00 ffffffff ff000000 ffff0000
392
Name
ssh tcp telnet tftp udp voip_sign_1 voip_sign_10 voip_sign_11 voip_sign_12 voip_sign_13 voip_sign_2 voip_sign_3 voip_sign_4 voip_sign_5 voip_sign_6 voip_sign_7 voip_sign_8 voip_sign_9 yahoo_ft_0 yahoo_ft_1 yahoo_get_0 yahoo_get_1 yahoo_get_2 yahoo_get_3 yahoo_get_4 yahoo_post_0
Description
Secure Shell TCP Traffic Telnet Trivial File Transfer UDP Traffic VOIP signature VOIP signature VOIP signature VOIP signature VOIP signature VOIP signature VOIP signature VOIP signature VOIP signature VOIP signature VOIP signature VOIP signature VOIP signature YAHOO_FT YAHOO_FT YAHOO_GET YAHOO_GET YAHOO_GET YAHOO_GET YAHOO_GET YAHOO_POST
Protocol
TCP TCP TCP UDP UDP UDP UDP UDP UDP UDP UDP UDP UDP UDP UDP UDP UDP UDP TCP TCP TCP TCP TCP TCP TCP TCP
OMPC Offset
0 0 0 0 0 28 28 28 28 28 28 28 28 28 28 28 28 28 0 10 0 4 8 12 16 0
OMPC Mask
0 0 0 0 0 c03f0000 c03f0000 c03f0000 c03f0000 c03f0000 c03f0000 c03f0000 c03f0000 c03f0000 c03f0000 c03f0000 c03f0000 c03f0000 ffffffff ffff0000 ffffffff ffffffff ffffffff ffffffff ff000000 ffffffff
393
Name
yahoo_post_1 yahoo_post_2 yahoo_post_3 yahoo_post_4
Description
YAHOO_POST YAHOO_POST YAHOO_POST YAHOO_POST
Protocol
TCP TCP TCP TCP
OMPC Offset
4 8 12 16
OMPC Mask
ffffffff ffffffff ffffffff ffff0000
394
Appendix C Glossary
The glossary describes Radware-specific terms frequently used in this guide.
Term
Bandwidth Management (BWM)
Definition
Radwares Bandwidth Management (BWM) is the process of measuring and controlling network traffic, prioritizing applications according to their bandwidth and not exceeding link capacity. Radwares BWM provides attack isolation and protection against unknown flooding attacks, prioritizes bandwidth for critical applications, and delivers traffic shaping, including bandwidth per traffic flow to enable limiting of bandwidth per client or session within a global BWM rule. For example, you can assign HTTP traffic a higher priority than SMTP traffic, which in turn may have higher priority than FTP traffic in your network. Tracking the bandwidth used by each application enables you to: Ensure a guaranteed bandwidth for certain applications. Set limits as to how much bandwidth each classified traffic pattern can utilize.
Class
In Radware, a class is defined as a combination of service definitions and network segment definitions that characterize a certain type of traffic. Services characterize traffic by Layer 3-7 criteria, while network segments characterize traffic by Layer 1-3 criteria. The Classes module allows multiple Networks to have the same configured name. This allows a Network with the name net1 to actually encompass multiple disjointed IP address ranges. Essentially, this makes the Network Group Name a logical pointer to all ranges configured with that name.
Client NAT Address Client NAT Address table - defines the addresses that are available for the Table device to choose from to perform NAT. The NAT addresses are also configured in ranges. The maximum number of configurable NAT addresses depends on the value of the NAT Addresses table parameters. Client Table A Radware Client Table is an internal table used by a Web Server Device to store Client session information, such as Client IP Address, Client IP Port, Farm IP Address, Server IP Address, Last Activity Time, Attach Time. It keeps track of clients connected to the servers for each of the Local Farms in order to maintain client-server persistency. The Layer 3 Client table contains information about the server selected for each client (Source IP address) in each farm, defined as a percent of the Client Table size. If LinkProof finds that a request exists in the Client Table the request is directed to the server recorded in the table. If an entry does not exist, a farm is selected according to the service requested, and a server is selected according to load balancing considerations or according to the Layer 7 Persistency info, The selected server is recorded in the table. Once an entry is created in the Client Table, all subsequent packets that arrive from the client to a farm are forwarded to the server recorded in the entry. Element, Checked A Checked Element is a network element that is managed and load balanced by the Radware device.
395
LinkProof User Guide Glossary
Term
Farm
Definition
An LinkProof Server Farm (aka. Farm) is a collection of one or more networked and load-balanced servers hosting a common service or application that is accessible via a common VIP. A server can be a member of more than one Farm. Using a load balancer, a server farm streamlines internal processes by distributing the workload between the individual components of the farm and expedites computing processes by harnessing the power of multiple servers. Server farms rely on load-balancing software to satisfy tracking demand for processing power from different machines, prioritizing the tasks, and scheduling and rescheduling them depending on user priority and demand. When one server in a farm fails, another takes up the load. Servers contained in a server farm can be placed in different physical locations, belong to different vendors, or have different capacities, all of which is transparent to the user. A server in a farm can also serve in multiple farms.
Group Health Check
Group Health Checks enables the creation of complex health conditions for Checked Elements. For instance, consider a Web server that communicates with one of two database servers and uses one of two routers to provide service. This Web server is bound using three different binding groups: 1. 2. 3. One contains health checks for the two routers (each check is nonmandatory). Another contains health checks for the database servers (each check is non-mandatory). The third contains the health checks for the Web server.
As long as one of the database servers and one of the routers are active, and the Web server health check passes, the Web server is considered active. Otherwise, the Health Monitoring module determines that the Web server is unable to provide the required service. Group, Server A Server Group is subset of configured server hosts used for a particular service. A server may belong to several groups and a group may transverse several farms. Health check A health check defines how to test the health of any network element (not necessarily a Checked Element). A check configuration includes such parameters as the Check Method, the TCP/ UDP port to which the test is sent, the time interval for the test, its timeout, the number of retries, and more. A network element can be tested using one or more health checks. Health Monitoring Health Monitoring is the mechanism by which a load balancer checks to ensure that a load-balanced server is up and functioning. Basic health monitoring includes: ICMP ping TCP port open HTTP HEAD or GET command and looking for an HTTP 200 response.
Radwares health monitoring includes an extensive library of pre-defined health checks to identify any type of failure, whether it is a server hardware failure, an operating system problem, a specific application failure or a back-end database failure.
396
Term
NAT
Definition
Network Address Translation (NAT) is the translation of an IP address used within one network (typically a LAN or internal network) to a different IP address known within another network (a public, external network). The purpose of NAT is to hide the Source IP address. The following NAT options are used in Radware: NAT, Client - hides IP addresses of users sending requests to the Internet via the LinkProof device. NAT, Server - translates the servers IP address in outbound serverinitiated sessions, to a corresponding public address, using Static NAT (only the IP address is changed, no port NAT is done). NAT, Outbound - allows only connections that originate from servers on the internal network to initiate sessions both with the internal network and with the public Internet.
NAT, Client
Client NAT - The device uses this parameter to hide the IP addresses of the clients from the servers. The original Source IP of a request is replaced by the configured NAT IP and port before forwarding the request to the server. The Client NAT feature is used when, for example, the client and the server are on the same subnet, so that the IP address of the client must be hidden. If it is not, servers may send replies directly to clients, rather than sending them through the device.
NAT, Dynamic NAT, Overlapping
Dynamic NAT - maps an unregistered IP address to a registered IP address from a group of registered IP addresses. Overlapping NAT is when IP addresses used on an internal network are registered IP addresses in use on another network. The router must maintain a lookup table of these addresses so that it can intercept them and replace them with registered unique IP addresses. The NAT router must translate the internal addresses to registered unique addresses as well as translate the external registered addresses to unique addresses in the private network. This can be done either through static NAT or by using DNS and implementing Dynamic NAT.
NAT, Pooled
Pooled NAT is similar to Port Address Translation (PAT) except there is a oneto-one mapping of addresses; the number of inside network clients is the same as the number of outside network IP addresses. The NAT router has a pool of available IP addresses, and each client receives its own IP address when it requests a NAT translation. The next available IP address will be selected each time the client requests a translation.
NAT, Server
Server NAT is a parameter in the device configuration that, when enabled, hides a servers IP address for outbound traffic in sessions initiated by the server, using static NAT (only the IP address is changed, no port translation is done). When a session is initiated by a server, the servers request for service is sent using its IP address as the source address. If the servers IP address is a private IP address, the servers address must be translated to a public IP address. The servers IP is translated to the Layer 4 Classifications VIP and a new entry is added to the Client Table. Sessions originating from servers are tracked in the Client Table and tagged with a NAT tag to differentiate this traffic from other inbound client traffic.
397
Term
NAT, Static
Definition
Static NAT is a type of NAT in which client requests with private IP addresses are mapped to a fixed public IP address (for example, the case of an E-mail server). This allows an internal host, such as a Web server, to have an unregistered (private) IP address and still be reachable over the Internet.
OnDemand Switch (ODS) OR Group Outbound NAT Intercept Addresses Table Out-of-band Monitoring
Radware's OnDemand Switch is a data-center switch that scales up as a customer's business expands and demands increased application performance, increased throughput of data traffic and data availability. An OR Group is a logical OR between two Basic Filters, part of the classes database. The Outbound NAT Intercept Addresses table lists networking elements with source addresses that have been NATed. Out-of-band Monitoring is a health check by the Load Balancer for TCP response time generated specifically by the Load Balancer to the server. Using out-of-band monitoring, it is easier to check the validity of the request content. In contrast, in-band monitoring refers to a TCP health check using the natural traffic flow between the client and the server.
PAT
Port Address Translation (PAT) translates TCP or UDP communications between hosts on a private network and hosts on a public network. It allows a single public IP address to be used by many hosts on the LAN. A PAT device transparently modifies IP packets, as they pass from the multiple hosts on the LAN to the public network, so that all the packets appear to originate from a single host - the PAT device.
Port Group
Port Groups is a method of grouping network segments by physical ports. Only packets that arrive from defined physical ports are classified by security policies and bandwidth management policies. For example, you can allow only HTTP traffic to the main server through a certain physical interface #3. On a Load Balancer, if a running application on any one group fails, the Load Balancer will mark the entire group of applications down on a given real server. It will direct requests only to those servers that have all the necessary applications running in order to complete a transaction.
Port Group Application Port Group, Physical Inbound Port, Management
An Application Port Group combines Layer 4 ports for UDP and TCP traffic only. Each group is identified by its unique name. Each group name can be associated with a number of entries in the Application Port Groups table. Inbound Physical Port Groups classify only traffic received/sent on certain interfaces of the device, thus enabling you to set different rules for identical traffic classes that are received on different device interfaces. A management port is a socket in a network device that is used for network management. A management port used for communicating between the interface and a connected device, whether logical or physical.
398
Term
Port Mirroring
Definition
Port Mirroring enables the device to duplicate traffic from one physical port to another physical port on the same device. For example, when an Intrusion Detection System (IDS) device is connected to one of the ports on the device, you can configure port mirroring for received traffic only, for transmitted traffic only, or for both. You can also decide whether to mirror the received broadcast packets.
Port Trunking
Port Trunking (aka Link Aggregation) is a method of increasing bandwidth by combining physical network links into a single logical link. Link aggregation increases the capacity and availability of the communications channel between devices - both switches and end stations - by using the Fast Ethernet and Gigabit Ethernet technology.
Profile, Load Balancing
A Load Balancing Profile configures the load-balancing parameters for a server farm. Each server farm can have only one profile, although a Load Balancing profile can be applied to other farms.
Protocol Discovery
Protocol Discovery provides a view of the protocols running on the network. Network administrators must be aware of the different applications running on their network and the amount of bandwidth they consume. The Protocol Discovery feature can be activated on the entire network or on separate subnetworks by defining Protocol Discovery rules.
Proximity
Global LinkProof devices calculate round-trip latency as well as router hopcount from each remote site to incoming request in order to determine the fastest site. Requests are then dynamically redirected to a site where User Response Time (URT), the time it takes from initiating a request until the user gets a response, is the smallest. Technically, only global LinkProof devices can trigger proximity calculations and store the results, but even local LinkProof devices can participate in the process. There are three consideration that determine the proximity of the server: Traffic load on the available servers Number of hops required to reach the server Latency, the User Response Time (URT)
Proxy Redirection
Proxy Redirection uses the Client NAT mechanism to redirect traffic to another server or site, while ensuring that the return traffic flows through the device that received the original request. A VLAN tag identifies traffic belonging to different VLANs. The IEEE standard 802.1Q standard defines a method called VLAN tagging, where switches insert a four-byte VLAN tag into the header of each frame. The tag contains a 12-bit VLAN ID that identifies the frames VLAN membership. This enables multiple VLANs to use the same switch port. Each VLAN is tagged with a unique identifier to identify different VLAN traffic on the same physical portal, allowing VLANs to communicate with one another using a Layer-3 router. If a packet arrives without a VLAN tag, LinkProof sets a tag according to the destination local subnet. The device can overwrite or retain VLAN Tags on packets passing through it. When the status of VLAN Tag support is changed, the device must be rebooted.
VLAN Tag
399

Radware LLB

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Radware LLB

Hochgeladen von

Copyright:

Verfügbare Formate

LinkProof User Guide

Software Version 6.12

LinkProof User Guide

Document ID: RDWR-LP-V0612_UG1010

LinkProof User Guide

Document ID: RDWR-LP-V0612_UG1010

LinkProof User Guide

Document ID: RDWR-LP-V0612_UG1010

LinkProof User Guide

Notice traitant du copyright

Document ID: RDWR-LP-V0612_UG1010

LinkProof User Guide

Document ID: RDWR-LP-V0612_UG1010

LinkProof User Guide

Document ID: RDWR-LP-V0612_UG1010

LinkProof User Guide

Figure 1: Electrical Shock Hazard Label

Figure 2: Dual-Power-Supply-System Safety Warning in Chinese

Document ID: RDWR-LP-V0612_UG1010

LinkProof User Guide

Figure 3: Statment for Class A VCCI-certified Equipment

Figure 4: Statment for Class B VCCI-certified Equipment

Document ID: RDWR-LP-V0612_UG1010

LinkProof User Guide

Document ID: RDWR-LP-V0612_UG1010

LinkProof User Guide

Figure 5: tiquette d'avertissement de danger de chocs lectriques

Document ID: RDWR-LP-V0612_UG1010

LinkProof User Guide

Document ID: RDWR-LP-V0612_UG1010

LinkProof User Guide

Figure 7: Dclaration pour l'quipement de classe A certifi VCCI

Figure 8: Dclaration pour l'quipement de classe B certifi VCCI

Document ID: RDWR-LP-V0612_UG1010

LinkProof User Guide

Pour brancher l'alimentation lectrique :

Document ID: RDWR-LP-V0612_UG1010

LinkProof User Guide

Figure 9: Warnetikett Stromschlaggefahr

Figure 10: Sicherheitshinweis in chinesischer Sprache fr Systeme mit Doppelspeisung

Document ID: RDWR-LP-V0612_UG1010

LinkProof User Guide

Figure 11: Erklrung zu VCCI-zertifizierten Gerten der Klasse A

Document ID: RDWR-LP-V0612_UG1010

LinkProof User Guide

Figure 12: Erklrung zu VCCI-zertifizierte Gerte der Klasse B

Diese Markierung oder Erklrung enthlt den folgenden Warntext: VORSICHT

Document ID: RDWR-LP-V0612_UG1010

LinkProof User Guide

Anschluss des Stromkabels:

Document ID: RDWR-LP-V0612_UG1010

LinkProof User Guide

Document ID: RDWR-LP-V0612_UG1010

LinkProof User Guide

Document ID: RDWR-LP-V0612_UG1010

LinkProof User Guide Table of Contents

LinkProof Modules ....................................................................................................... 32

Management Tools ...................................................................................................... 34

Chapter 2 Device Management ........................................................................... 35

Document ID: RDWR-LP-V0612_UG1010

LinkProof User Guide Table of Contents

Licensing and Upgrading Licenses ............................................................................. 54 Managing Configuration Files ..................................................................................... 56

Bridging Support ......................................................................................................... 65

LinkProof Global Configuration General ..................................................................... 67 Virtual IP Addresses ................................................................................................... 69