LP 6.20 Ug

LinkProof User Guide
Software Version 6.20

Document ID: RDWR-LP-V0620_UG1202
February, 2012
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. 20062011. 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. 20062011. 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. 20062011. 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. This product contains work derived from the RSA Data Security, Inc. MD5 Message-Digest Algorithm. RSA Data Security, Inc. makes no representations concerning either the merchantability of the MD5 Message - Digest Algorithm or the suitability of the MD5 Message - Digest Algorithm for any particular purpose. It is provided "as is" without express or implied warranty of any kind.
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: Statement for Class A VCCI-certified Equipment
Translation of Figure 3 - Statement 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: Statement for Class B VCCI-certified Equipment
Translation of Figure 4 - Statement for Class B VCCI-certified Equipment, page 10: 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. KCC KOREA
Figure 5: KCCKorea Communications Commission Certificate of Broadcasting and Communication Equipment
Figure 6: Statement For Class A KCC-certified Equipment in Korean
Translation of Figure 6 - Statement For Class A KCC-certified Equipment in Korean, page 10: This equipment is Industrial (Class A) electromagnetic wave suitability equipment and seller or user should take notice of it, and this equipment is to be used in the places except for home. 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.
10
INTERCONNECTION OF UNITS Cables for connecting to the unit RS232 and Ethernet Interfaces must be UL certified type DP-1 or DP-2. (Note- when residing in non LPS circuit) OVERCURRENT PROTECTION A readily accessible listed branch-circuit over current protective device rated 15 A must be incorporated in the building wiring for each power input. REPLACEABLE BATTERIES If equipment is provided with a replaceable battery, and is replaced by an incorrect battery type, then an explosion may occur. This is the case for some Lithium batteries and the following is applicable: If the battery is placed in an Operator Access Area, there is a marking close to the battery or a statement in both the operating and service instructions. If the battery is placed elsewhere in the equipment, there is a marking close to the battery or a statement in the service instructions.
This marking or statement includes the following text warning: CAUTION RISK OF EXPLOSION IF BATTERY IS REPLACED BY AN INCORRECT BATTERY TYPE. DISPOSE OF USED BATTERIES ACCORDING TO THE INSTRUCTIONS. Caution To Reduce the Risk of Electrical Shock and Fire 1. This equipment is designed to permit connection between the earthed conductor of the DC supply circuit and the earthing conductor equipment. See Installation Instructions. 2. All servicing must be undertaken only by qualified service personnel. There are not user serviceable parts inside the unit. 3. DO NOT plug in, turn on or attempt to operate an obviously damaged unit. 4. Ensure that the chassis ventilation openings in the unit are NOT BLOCKED. 5. Replace a blown fuse ONLY with the same type and rating as is marked on the safety label adjacent to the power inlet, housing the fuse. 6. Do not operate the device in a location where the maximum ambient temperature exceeds 40C/104F. 7. Be sure to unplug the power supply cord from the wall socket BEFORE attempting to remove and/or check the main power fuse. CLASS 1 LASER PRODUCT AND REFERENCE TO THE MOST RECENT LASER STANDARDS IEC 60 825-1:1993 + A1:1997 + A2:2001 AND EN 60825-1:1994+A1:1996+ A2:2001 AC units for Denmark, Finland, Norway, Sweden (marked on product): Denmark - Unit is class I - unit to be used with an AC cord set suitable with Denmark deviations. The cord includes an earthing conductor. The Unit is to be plugged into a wall socket outlet which is connected to a protective earth. Socket outlets which are not connected to earth are not to be used! Finland - (Marking label and in manual) - Laite on liitettv suojamaadoituskoskettimilla varustettuun pistorasiaan Norway (Marking label and in manual) - Apparatet m tilkoples jordet stikkontakt Unit is intended for connection to IT power systems for Norway only. Sweden (Marking label and in manual) - Apparaten skall anslutas till jordat uttag.
To connect the power connection: 1. Connect the power cable to the main socket, located on the rear panel of the device. 2. Connect the power cable to the grounded AC outlet.
11
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 7: 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.
Figure 8: Avertissement de scurit pour les systmes dotes de deux sources d'alimentation lectrique (en chinois)
Traduction de la Figure 8 - 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.
12
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
Figure 9: Dclaration pour l'quipement de classe A certifi VCCI
Traduction de la Figure 9 - 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.
13
Figure 10: Dclaration pour l'quipement de classe B certifi VCCI
Traduction de la Figure 10 - Dclaration pour l'quipement de classe B certifi VCCI, page 14: 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. KCC Core
Figure 11: KCCCertificat de la commission des communications de Core pour les equipements de radiodiffusion et communication.
Figure 12: Dclaration pour l'quipement de classe A certifi KCC en langue corenne
Translation de la Figure 12 - Dclaration pour l'quipement de classe A certifi KCC en langue corenne, page 14: Cet quipement est un matriel (classe A) en adquation aux ondes lectromagntiques et le vendeur ou l'utilisateur doit prendre cela en compte. Ce matriel est donc fait pour tre utilis ailleurs qu' la maison. 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.
14
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 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. 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. 2. Tout entretien sera entrepris par du personnel qualifi. Aucune pice l'intrieur de l'unit ne peut tre remplace ou rpare. 3. NE branchez pas, n'allumez pas ou n'essayez pas d'utiliser une unit manifestement endommage. 4. Vrifiez que l'orifice de ventilation du chssis dans l'unit n'est PAS OBSTRUE. 5. 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. 6. Ne faites pas fonctionner l'appareil dans un endroit, o la temprature ambiante dpasse la valeur maximale autorise. 40C/104F. 7. 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."
Pour brancher l'alimentation lectrique: 1. Branchez le cble d'alimentation la prise principale, situe sur le panneau arrire de l'unit. 2. Connectez le cble d'alimentation la prise CA mise la terre. AVERTISSEMENT 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.
15
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. Attention: Pour Rduire Les Risques d'lectrocution et d'Incendie 1. 2. 3. 4. 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. NE PAS connecter, mettre sous tension ou essayer d'utiliser une unit visiblement dfectueuse. Assurez-vous que les ouvertures de ventilation du chssis NE SONT PAS OBSTRUES. 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. NE PAS UTILISER l'quipement dans des locaux dont la temprature maximale dpasse 40 degrs Centigrades. 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.
5. 6.
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 13: Warnetikett Stromschlaggefahr
16
SICHERHEITSHINWEIS IN CHINESISCHER SPRACHE FR SYSTEME MIT DOPPELSPEISUNG Die folgende Abbildung ist die Warnung fr Radware-Plattformen mit Doppelspeisung.
Figure 14: Sicherheitshinweis in chinesischer Sprache fr Systeme mit Doppelspeisung
bersetzung von Figure 14 - Sicherheitshinweis in chinesischer Sprache fr Systeme mit Doppelspeisung, page 17: 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.
17
ERKLRUNG DER VCCI ZU ELEKTROMAGNETISCHER INTERFERENZ
Figure 15: Erklrung zu VCCI-zertifizierten Gerten der Klasse A
bersetzung von Figure 15 - Erklrung zu VCCI-zertifizierten Gerten der Klasse A, page 18: 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 16: Erklrung zu VCCI-zertifizierten Gerten der Klasse B
bersetzung von Figure 16 - Erklrung zu VCCI-zertifizierten Gerten der Klasse B, page 18: 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. KCC KOREA
Figure 17: KCCKorea Communications Commission Zertifikat fr Rundfunk-und Nachrichtentechnik
Figure 18: Erklrung zu KCC-zertifizierten Gerten der Klasse A
18
bersetzung von Figure 18 - Erklrung zu KCC-zertifizierten Gerten der Klasse A, page 18: Verkufer oder Nutzer sollten davon Kenntnis nehmen, da dieses Gert der Klasse A fr industriell elektromagnetische Wellen geeignete Gerten angehrt und dass diese Gerte nicht fr den heimischen Gebrauch bestimmt sind. 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 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."
Anschluss des Stromkabels: 1. Schlieen Sie das Stromkabel an den Hauptanschluss auf der Rckseite des Gertes an. 2. Schlieen Sie das Stromkabel an den geerdeten Wechselstromanschluss an. VORSICHT Stromschlag- und Energiegefahr Die Trennung einer Stromquelle trennt nur ein Stromversorgungsmodul von der Stromversorgung. Um das Gert komplett zu isolieren, muss es von der gesamten Stromversorgung getrennt werden.
19
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 40C 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.
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
20
LinkProof User Guide Table of Contents
Table of Contents
Important Notices .......................................................................................................... 3 Copyright Notices .......................................................................................................... 4 Safety Instructions ......................................................................................................... 8 Document Conventions ............................................................................................... 20
Chapter 1 Introduction......................................................................................... 31
LinkProof Overview ..................................................................................................... 31 Supported Radware Platforms .................................................................................... 32 Basic LinkProof Concepts ........................................................................................... 32
Multihoming Overview ......................................................................................................... 32 Multihomed Network ............................................................................................................ 33 Farms ................................................................................................................................... 33 Servers ................................................................................................................................ 33 Content Rules ...................................................................................................................... 33 NAT ...................................................................................................................................... 33 Proximity .............................................................................................................................. 34 DNS Load Balancing ........................................................................................................... 34 Redundancy ......................................................................................................................... 34
LinkProof Modules ....................................................................................................... 34

Health Monitoring Module .................................................................................................... Traffic Redirection Module ................................................................................................... Bandwidth Management Module ......................................................................................... Security Module ................................................................................................................... 35 35 35 36
IPv6 Support ................................................................................................................ 36 Management Tools ...................................................................................................... 37
Chapter 2 Device Management ........................................................................... 39

Device IP Host Parameters and Generic Startup Configuration Menu ........................ 40 Device Interfaces ......................................................................................................... 43
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 ......................................... 43 44 45 45 45 45 46 46
Erasing the Configuration File ..................................................................................... 48 Updating Device Software ........................................................................................... 48 Software Versions List ................................................................................................. 49
21
Licensing and Upgrading Licenses ............................................................................. 50 Managing Configuration Files ..................................................................................... 52

Sending a Configuration File to the Device ......................................................................... 52 Downloading a Configuration File ....................................................................................... 53 Configuration Error Log Files .............................................................................................. 53
Updating PoliciesActivating the Latest Changes .................................................... 54 Resetting the Device .................................................................................................. 55 Configuring Global Device Parameters ...................................................................... 55 Device Information ...................................................................................................... 56 Device Monitoring ....................................................................................................... 57 Session Table ............................................................................................................. 57
Session Table Global Parameters ....................................................................................... 58 Session Table Entries ......................................................................................................... 59
Bridging Support ......................................................................................................... 61

Bridge Operating Parameters .............................................................................................. 61 Bridge Forwarding Table ..................................................................................................... 61 Static Forwarding Table ...................................................................................................... 62
LinkProof Global Configuration General ..................................................................... 63 Virtual IP Addresses ................................................................................................... 65

Creating Virtual IP Addresses ............................................................................................. 65 Virtual IP Translation Ports Exclusion ................................................................................. 66
Device Tuning ............................................................................................................. 67

Tuning Statistics Parameters .............................................................................................. Tuning Memory Check ........................................................................................................ Tuning BWM Parameters .................................................................................................... Tuning Classifier Parameters .............................................................................................. Tuning Device Table Parameters ........................................................................................ Tuning SYN Protection Parameters .................................................................................... Tuning Diagnostics Parameters .......................................................................................... Tuning Virtual Tunneling Parameters .................................................................................. CLI Traps ............................................................................................................................ Syslog Reporting ................................................................................................................. SMTP E-mail Notifications ................................................................................................... Configuration Trace ............................................................................................................. 67 68 68 68 70 75 76 76 77 77 79 80
Device Notifications .................................................................................................... 77
DNS-Client Utility ........................................................................................................ 80 Show Tech-Support .................................................................................................... 81 Diagnostics ................................................................................................................. 82

Traffic Capture Tool ............................................................................................................ Trace-Log ............................................................................................................................ Diagnostic Tools Files Management ................................................................................... Diagnostics Policies ............................................................................................................ 82 84 87 88
22
Management Interfaces ............................................................................................... 89

Configuring a Telnet Management Interface ....................................................................... Configuring Web Server Management Interfaces ................................................................ Configuring an SSH Interface for Management ................................................................... Configuring an FTP Interface for Management ................................................................... 89 90 92 93
RADIUS Authentication for Management .................................................................... 93 Logging ........................................................................................................................ 95

Event Log ............................................................................................................................. 95 SMTP Logging ..................................................................................................................... 95 Power Supply Traps ............................................................................................................ 96
APSolute API ............................................................................................................... 97
Chapter 3 Basic Switching and Routing ............................................................ 99

Port Settings ................................................................................................................ 99
Port Mirroring ....................................................................................................................... 99 Link AggregationPort Trunking ..................................................................................... 100 Port Rules ......................................................................................................................... 104 Rules Table ....................................................................................................................... 105 Port Load Balancing Status .............................................................................................. 105
Virtual LAN ............................................................................................................... 106

Virtual LANs ...................................................................................................................... Supported VLAN Types .................................................................................................... IPv6 Pass-through ............................................................................................................ Bridging ............................................................................................................................. VLAN Example Configuration ........................................................................................... Configuring VLANs ........................................................................................................... Redundancy with VLANs .................................................................................................. VLAN Tagging .................................................................................................................. IP Interfaces ...................................................................................................................... IP Router Operating Parameters ...................................................................................... Viewing and Configuring IP Router IP Interfaces ............................................................. Configuring ICMP Interface Parameters ........................................................................... Routing ............................................................................................................................. Routing Information Protocol ............................................................................................ IPv6 Neighbor Discovery .................................................................................................. Configuring ARP Parameters ........................................................................................... Open Shortest Path First (OSPF) ..................................................................................... 106 106 107 109 109 110 112 112 116 117 117 120 121 123 125 129 130
IP Addressing and Routing ....................................................................................... 116
23
Chapter 4 Basic Application Switching ........................................................... 135

LinkProof Multihoming Overview .............................................................................. 135 Farm Management ................................................................................................... 138
LinkProof Farms ................................................................................................................ Farm Load Balancing ........................................................................................................ Default Farm ..................................................................................................................... Farm Connectivity Checks ................................................................................................ 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 ............................................................................................... IPv6 Prefix-NAT ................................................................................................................ 138 144 153 154 155 156 159 161 164 166 167 168 169 170 171 171 172 174 177 179
Server Management ................................................................................................. 155
Network Address Translation ................................................................................... 167
Proximity ................................................................................................................... 185

Proximity Introduction ........................................................................................................ 185 Proximity Configuration ..................................................................................................... 186
DNS .......................................................................................................................... 191

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 .................................................................................................. 191 191 193 194 196 198 199 200 201 202
Basic Load Balancing ............................................................................................... 197
Load Balancing Weights ........................................................................................... 203
24
Flow Management .................................................................................................... 203

About Flows and Flow Management ................................................................................ Default Flow ...................................................................................................................... Configuring Flow Management ......................................................................................... Flow Policies ..................................................................................................................... Typical Flow Configurations .............................................................................................. Client Table Mechanism ................................................................................................... Managing Client Tables .................................................................................................... Client-Table Logging ......................................................................................................... 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 ...................................................................................................... 203 204 204 205 208 209 212 217 224 224 226 226 227 229 229 231
Client Table .............................................................................................................. 209
VPN Load Balancing ................................................................................................ 227
Chapter 5 Advanced Features .......................................................................... 233

Content Load Balancing ........................................................................................... 233
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) .............................................................................. 233 237 239 242 244 244 245 245
Tunneling .................................................................................................................. 243
Cost-based Load Balancing ..................................................................................... 246

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

LinkProof Redundancy ............................................................................................. 265
Introducing LinkProof Redundancy ................................................................................... Active/Backup Setup ........................................................................................................ Copying a Device Configuration for a Redundant Environment ........................................ Global Redundancy Configuration .................................................................................... Interface Grouping ............................................................................................................ Mirroring the Client Table .................................................................................................. Introducing VRRP ............................................................................................................. Direct Server Connection with VRRP ................................................................................ VRRP with IPv6 Prefix NAT .............................................................................................. Configuring Basic VRRP Redundancy .............................................................................. VRRP Associated IP Addresses ....................................................................................... 265 266 266 267 268 270 273 279 281 291 293
VRRP Redundancy .................................................................................................. 272
Remote Virtual IP Addresses ................................................................................... 294
Chapter 7 Security ............................................................................................. 297

ACL ........................................................................................................................... 297
Configuring ACL Global Parameters ................................................................................. Configuring ACL Policy Rules ........................................................................................... Viewing Active ACL Policy Rules ...................................................................................... Updating ACL Policies ...................................................................................................... Viewing and Managing ACL Reports ................................................................................ 298 300 302 303 303
Ports Access ............................................................................................................. 304 Configuring Access for Physical Ports ...................................................................... 304 SNMP ....................................................................................................................... 305
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 .................................................................................................... 305 306 306 307 308 308 309 309 310 311
Ping Physical Ports ................................................................................................... 312 Configuring the Users Table and Authentication Method ......................................... 312
Configuring the Authentication Method ............................................................................. 312 Configuring a User in the User Table ................................................................................ 313
26
SYN Flood Protection ............................................................................................... 313

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 .......................................................................................... 314 315 316 318 318 319 319 319 321 322 323 323
Keys and Certificates ................................................................................................ 318
Chapter 8 Bandwidth Management .................................................................. 325

Bandwidth Management Overview ........................................................................... 325
Application Classification .................................................................................................. 326 Classification Mode ........................................................................................................... 326
Managing Bandwidth Management Global Parameters ........................................... 326 Bandwidth Management Policies ............................................................................. 328
Bandwidth Management Policy Mechanism ..................................................................... Bandwidth Management Classification Criteria ................................................................ Bandwidth Management Rules ......................................................................................... Default Policy .................................................................................................................... Policy TreesHierarchical Bandwidth-Management Policies ......................................... Managing Bandwidth Management Policies ..................................................................... Basic Filters ...................................................................................................................... AND Group Filters ............................................................................................................ OR Group Filters ............................................................................................................... Viewing Active Services .................................................................................................... 328 329 330 331 331 333 343 350 351 352
Services .................................................................................................................... 342
Networks .................................................................................................................. 353

Configuring Networks ....................................................................................................... 353 Viewing Active Networks .................................................................................................. 354
Port Groups .............................................................................................................. 354

Configuring Port Groups ................................................................................................... 355 Viewing Active Port Groups .............................................................................................. 355
Application Port Groups ............................................................................................ 355

Configuring Application Port Groups ................................................................................ 355 Viewing Active Application Port Groups ........................................................................... 356
VLAN Tag Groups .................................................................................................... 356

Configuring VLAN Tag Groups ......................................................................................... 357 Viewing Active VLAN Tag Groups .................................................................................... 357
27
MAC Groups ............................................................................................................. 358

Configuring MAC Groups .................................................................................................. 358 Viewing Active MAC Groups ............................................................................................. 358
Updating PoliciesClasses ..................................................................................... 359 Discrete Networks .................................................................................................... 359

CLI Commands for the Discrete Networks Feature ........................................................... 360 Configuring the Discrete Network Parameters Exposed in Web Based Management ...... 361
Protocol Discovery .................................................................................................... 362

Protocol Discovery Overview ............................................................................................ Protocol Statistics Global Parameters ............................................................................... Protocol Discovery Policies ............................................................................................... Viewing the Protocol Discovery Statistics ......................................................................... 362 363 363 365
Port Bandwidth ......................................................................................................... 365 Cancelling Interface Classification ............................................................................ 365 Example Time-based BWM Policy ........................................................................... 366
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 ............................................ 367 367 368 368 369
Chapter 9 Health Monitoring............................................................................. 371

Health MonitoringIntroduction .............................................................................. 371
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 ..................................... 371 371 372 372 372 372 373 374 390 391
Health Check Configuration ...................................................................................... 373
Health Monitoring Server Table ................................................................................ 393

Configuring a Diameter Health Check ............................................................................... 394
Farm Health Checks ................................................................................................. 398
28
Appendix A Regular Expressions .................................................................... 399 Appendix B Predefined Basic Filters ............................................................... 401 Appendix C IPv6 Fundamentals ....................................................................... 411
IPv4 Versus IPv6 ...................................................................................................... 411 Name Resolution ...................................................................................................... 412 Internet Protocol Version 6 (IPv6) ............................................................................ 413
Internet Control Message Protocol for IPv6 (ICMPv6) ...................................................... 413
IPv6 Address Autoconfiguration ............................................................................... 415

Autoconfigured Address States ........................................................................................ Types of Autoconfiguration ............................................................................................... Autoconfiguration Process ................................................................................................ IPv6 Routing ..................................................................................................................... IPv6 Configuration Items .................................................................................................. IPv6 Neighbor Discovery .................................................................................................. New Header Format ......................................................................................................... Large Address Space ....................................................................................................... Efficient and Hierarchical Addressing and Routing Infrastructure .................................... Stateless and Stateful Address Configuration .................................................................. Built-in Security ................................................................................................................. Better Support for Quality of Service (QoS) ...................................................................... New Protocol for Neighboring Node Interaction ............................................................... Extensibility ....................................................................................................................... 415 415 415 416 418 419 420 421 421 421 421 421 421 422
Appendix D Glossary......................................................................................... 423
29
30
Chapter 1 Introduction
This guide describes Radware LinkProof and 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 31 Supported Radware Platforms, page 32 Basic LinkProof Concepts, page 32 LinkProof Modules, page 34 Management Tools, page 37
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)
31
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 32 Multihomed Network, page 33 Farms, page 33 Servers, page 33 Content Rules, page 33 NAT, page 33 Proximity, page 34 DNS Load Balancing, page 34 Redundancy, page 34
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.
32
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.
33
LinkProof User Guide Introduction LinkProof includes the following NAT options: Static NATEnsures 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 NATHides 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. IPv6 Prefix-NATPerforms IPv6 WAN load balancing of network traffic across different IPv6 routers. Prefix-NAT replaces the Unique Local IPv6 Address prefix to that of the external router. This enables outside access and persistency of the incoming connection based on the ISP router from which the traffic is coming. You can use LinkProof and Prefix-NAT in various deployment scenarios to provide a modern network solution for complex networks.
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. Proximity works only for router farms, not firewall farms.
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. LinkProof supports VRRP redundancy.
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.
34
LinkProof User Guide Introduction 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, 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 325).
35
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. 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 297). 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
IPv6 Support
LinkProof supports a dual-stack IPv6 and IPv4 environment, including IPv4 and IPv6 link loadbalancing functionality. See the release notes for information on supported features and limitation. For background information on IPv6, see Appendix C - IPv6 Fundamentals, page 411. For more information about load-balancing IPv6 traffic in LinkProof, see IPv6 Prefix-NAT, page 179. LinkProof supports for the following types of traffic: Pure IPv4LinkProof handles traffic from IPv4 clients to IPv4 routers, IPv4 WAN connections, or IPv4 servers. Pure IPv6LinkProof handles traffic from IPv6 clients to IPv4 routers, IPv4 WAN connections, or IPv4 servers. Mixed: LinkProof redirects dual-stacked clients to IPv4 routers if they request an IPv4 request. LinkProof redirects dual-stacked clients to IPv6 routers if they request an IPv6 request
LinkProof supports the following features for all types of traffic (pure IPv4, pure IPv6, mixed): Layer 4 traffic management and load balancing Layer 7 traffic management and load balancing (for IPv4 traffic all) High availability (health monitoring, VRRP redundancy)
The following IPv6 RFCs are supported in this version: 1981: Path MTU Discovery 2375: Multicast address assignment 2428: FTP extensions for IPv6 and NATs 2460: IPv6 Specification 2464: IPv6 over Ethernet 3142: IPv6 to IPv4 transport relay translator (TRT) 3363: Representing IPv6 addresses in DNS 3364: Tradeoffs in DNS for IPv6 3484: Default address selection 3587: Global Unicast address format 3596: DNS extensions for IPv6
36
LinkProof User Guide Introduction 3879: Deprecating site-local addresses 3901: DNS IPv6 transport operational guidelines 4001: Textual conventions for Internet network addresses 4007: IPv6 scoped address architecture 4074: Common misbehavior against DNS queries for IPv6 addresses 4193: Unique Local IPv6 Unicast Addresses 4291: IPv6 Addressing Architecture 4292: MIB for IP forwarding table 4293: MIB for IP 4294: IPv6 node requirements 4443: ICMPv6 4861: Neighbor discovery 4862: Stateless address auto-configuration 5095: Deprecation of type 0 routing headers in IPv6 5156: Special-use IPv6 addresses
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.
37
38
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 40 Device Interfaces, page 43 Erasing the Configuration File, page 48 Updating Device Software, page 48 Software Versions List, page 49 Licensing and Upgrading Licenses, page 50 Managing Configuration Files, page 52 Updating PoliciesActivating the Latest Changes, page 54 Resetting the Device, page 55 Configuring Global Device Parameters, page 55 Device Information, page 56 Device Monitoring, page 57 Session Table, page 57 Bridging Support, page 61 LinkProof Global Configuration General, page 63 Virtual IP Addresses, page 65 Device Tuning, page 67 Device Notifications, page 77 DNS-Client Utility, page 80 Show Tech-Support, page 81 Diagnostics, page 82 Management Interfaces, page 89 RADIUS Authentication for Management, page 93 Logging, page 95 APSolute API, page 97
39
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.
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 3.
Value
19200 8 None 1 None
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. 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. Enter the values for the menu items according to Table 1 - Startup Configuration Menu, page 41 and Table 2 - SNMP Startup Configuration Submenu, page 42. 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. 6. 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]
40
LinkProof User Guide Device Management 7. 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 3 Interface Numbering Conventions, page 43. 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.
RIP version Enable OSPF
(0,1,2) [0] (y/n) [n]
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
(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
(y/n) [n]
41
Table 1: Startup Configuration Menu
Item
Enable SSH Access SNMP Configuration
Additional CLI Text

(y/n) [n]
Remark
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 42.
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, DES1 Default: DES
4 5
Privacy Password Authentication Protocol (NONE/SHA/MD5 [MD5]
The password for the SNMPv3 User. Default: No password Specifies whether to use authentication and the authentication protocol. Must be used in conjunction with privacy. Values: NONE, SHA2 , MD53 Default: MD5
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
42
Table 2: SNMP Startup Configuration Submenu
#
8
Item
Configuration file name
Additional CLI Text
Description
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
1 Data Encryption Standard 2 Secure Hash Algorithm 3 Message-Digest algorithm 5
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 3: Interface Numbering Conventions
Physical Interface Type OnDemand Switch VL OnDemand Switch 2 Port Index Range1 Port Index Range1
RJ-45 port for management GbE RJ-45 ports G6/MNG12 G1G54 G785 G13165 MNG 123 G1G125
OnDemand Switch 3 Port Index Range1

MNG 123 G1G85 G9G125
SFP GbE ports Dual (SFP or RJ-45) GbE ports6 10GbE XFP ports 1 2 3 4 5 6
XG-1XG-45
The value is case-sensitive using CLI. Must be configured manually by means of the Startup Configuration Menu. For management only. For traffic. The port that is labeled on the platform G6/MNG1 is configured for management. For traffic or management. Only one side of a dual port can be active at the same time.
43
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.
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.
44
Table 4: 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
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.
45
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

A Layer 2 Interface is defined as any interface with its own MAC address - physical port, trunk, VLAN. You can configure the administrative status of each interface, monitor and interface statistics. IPv6 interfaces can be defined alongside IPv4 ones for all Layer 2 interfaces, (physical ports, VLANs and trunks). Each Layer 2 interface has IPv6 parameters that apply to all the IPv6 interfaces defined for that interface. Each IPv6 interface is also associated with a prefix. The prefix is the successor of the net mask used in IPv4. There may be no more than one IP address for the same prefix in the same Layer 2 interface. This restriction is for management convenience and applies also for IPv4. 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 mange the L2 interfaces using CLI Use the command net l2-interface.
To manage the L2 interfaces using Web Based Management 1. 2. Select Device> Layer 2 Interface. The Layer 2 Interface Table pane is displayed. From the Device MAC to Port Correlation drop-down list, choose one of the following: 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
Note: The MAC address of each port on the platform is the base MAC address plus the port index. 3. 4. Select the Interface Index to edit. The Layer 2 Interface Table Update pane is displayed. Configure the parameters; and then, click Set.
46
Table 5: L2 Interface Table Parameters
Parameter
Interface Index Interface Description interface Type
Description
(Read-only) The 1nterface index identifier. (Read-only) A textual string containing information about the interface. (Read-only) The type of interface. Additional values are assigned by the Internet Assigned Numbers Authority (IANA), through updating the syntax of the textual convention. The size, in bits, of the largest packet that can be sent or received on the interface. For interfaces that are used for transmitting network datagrams, this is the size of the largest network datagram that can be sent on the interface. Default: 1500 (Read-only) An estimate, in bits per second, of the current bandwidth. (Read-only) The MAC address of the interface. The status of the interface. Values: Up, Down (Read-only) The operational status of the router. Values: Up, Down (Read-only) The sysUpTime at the time the interface entered its current operational state. If the current state was entered prior to the last reinitialization of the local network management subsystem, this object contains a zero value. (Read-only) The number of incoming octets (bytes) through the interface including framing characters. (Read-only) The number of packets delivered by this sub-layer to a higher (sub-) layer, which were not addressed to a multicast or broadcast address at this sub-layer. (Read-only) The number of packets delivered by this sub-layer to a higher (sub-) layer, which were addressed to a multicast or broadcast address at this sub-layer. (Read-only) The number of inbound packets chosen to be discarded even though no errors had been detected to prevent their being deliverable to a higher-layer protocol. One possible reason for discarding such a packet could be to free up buffer space. (Read-only) One of the following: For packet-oriented interfacesThe number of inbound packets that contained errors preventing them from being deliverable to a higher-layer protocol. For character-oriented or fixed-length interfacesThe number of inbound transmission units that contained errors preventing them from being deliverable to a higher-layer protocol.
Interface MTU
Interface Speed MAC Address Interface Admin Status Operational Status Interface Last Change
ifINOctets InUcastPkt
InNUcastPkt
ifInDiscards
ifInErrors
ifOutOctets OutUcastPkt
(Read-only) The total number of octets (bytes) transmitted out of the interface, including framing characters. (Read-only) The total number of packets that higher-level protocols requested be transmitted, and which were not addressed to a multicast or broadcast address at this sub-layer, including those that were discarded or not sent.
47
Table 5: L2 Interface Table Parameters
Parameter
OutNUcastPkt
Description
(Read-only) The total number of packets that higher-level protocols requested be transmitted, and which were addressed to a multicast or broadcast address at this sub-layer, including those discarded or not sent. (Read-only) The number of outbound packets which were chosen to be discarded even though no errors had been detected to prevent their being transmitted. One possible reason for discarding such a packet could be to free up buffer space. (Read-only) One of the following: For packet-oriented interfacesThe number of outbound packets that could not be transmitted because of errors. For character-oriented or fixed-length interfacesThe number of outbound transmission units that could not be transmitted because of errors.
ifOutDiscards
ifOutErrors
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. 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.
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.
48
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.
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 6: Software Versions Table Columns
Parameter
Name Index
Description
The name of the version The index of the version in the Software List.
49
Table 6: Software Versions Table Columns
Parameter
Valid Active Version
Description
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. 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.
50
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 Select Device > License Upgrade. The License Upgrade pane is displayed.
Table 7: 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
To upgrade a license 1. Select Device > License Upgrade. The License Upgrade pane is displayed. The current license string is displayed in the Insert Your License Code field. 2. Do the following: 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.
3. Click Set. The Reset the Device pane is displayed. You must reset the device to validate the license. 4. Click Set. The reset may take a few minutes. A success message is displayed upon completion.
51
Table 8: 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 52 Downloading a Configuration File, page 53 Configuration Error Log Files, page 53
Sending a Configuration File to the Device
To send a configuration file to the device 1. 2. Select File > Configuration > Send To Device. The Upload Configuration File to Device pane is displayed. 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.
52
LinkProof User Guide Device Management 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.
To download a configuration file 1. Select File > Configuration > Receive from Device. The Download Configuration File pane is displayed. 2. 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. If you want the file to include private keys, select the Include Private Keys checkbox. 4. Click Set. The Opening DeviceConfigurationFile<yyyy-MM-dd-hh-mm-ss> dialog box is displayed. 5. Configure the file location and name as required. 6. 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.
53
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.
To download the log file with the configuration errors 1. 2. Select File > Configuration > LogFile > Download. The Configuration Error Log pane is displayed. 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.
54
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.
Configuring Global Device Parameters

To configure the global parameters of the device 1. Select Device > Global Parameters. The Device Global Parameters pane is displayed. 2. Configure the parameters; and then, click Set.
Table 9: 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
(Read-only) General description of the device. 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. (Read-only) Time elapsed since the last reset. 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. (Read-only) The software version. (Read-only) The hardware version.
55
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.
Table 10: 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
56
Device Monitoring
To view the Device Monitoring information Select Device > Device Monitoring. The Device Monitoring pane is displayed.
Table 11: 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.
57
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.
Table 12: 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
58
Table 12: Session Table Global Parameters
Parameter
Remove Session Table Entry at Session End
Description
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
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 13: Session Table Entries Parameters
Parameter
Source IP Destination IP Source Port Destination Port Lifetime
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.
59
Table 13: Session Table Entries Parameters
Parameter
Aging Type SYN Protection Status
Description
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.
To configure the filter for the display of the Session Table entries in the View Table Query Results window 1. 2. 3. Select Device > Session Table > View Table Query Results. The View Table Query Results pane is displayed. Click Create. The Query Filters Table Create pane is displayed. Configure the parameters; and then, click Set.
Table 14: Query Filters Table Parameters
Parameter
Name Physical Port Source IP prefix Dest IP prefix Source Port Dest Port Source IP prefix length Dest IP prefix length
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 prefix. The destination IP prefix. The source port of the session. Default: Any The destination port. Default: Any The length of the source IP prefix. The length of the destination IP prefix.
60
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.
Table 15: 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 16: Bridge Forwarding Table Parameters
Parameter
Mac Address
Description
The MAC address of the node.
61
Table 16: Bridge Forwarding Table Parameters
Parameter
Port Status
Description
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.
Table 17: 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. 2. 3. Select Bridge > Static Forwarding Table. The Static Forwarding Table pane is displayed. Click Create. The Static Forwarding Table Create pane is displayed. Configure the parameters; and then, click Set.
62
Table 18: 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.
Table 19: 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. When two routes on the device are derived from local interfaces, the device has two options. Values: EnableFor each new session, the device checks whether the session is destined to be routed locallythat 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
63
Parameter
Clients Connect Denials Translate Outbound Traffic to Virtual Address
Description
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. disableDoes 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.
NHR Tracking Table Status
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.
64
Parameter
Link Quality Evaluation
Description
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 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
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 65 Virtual IP Translation Ports Exclusion, page 66
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.
65
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 20: 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.
To configure port exclusion for VIP translation 1. 2. 3. 4. Select LinkProof > Virtual IP > VIP Exclusion Policy. The Virtual IP Exclusion Policy pane is displayed. Click Create. The Exclusion Policy Table Create pane is displayed. In the Port text box, type the number of the port that you wish to exclude from VIP translation. Click Set.
66
Device Tuning
This section describes the interfaces and methods for device tuning, and contains the following topics: Tuning Statistics Parameters, page 67 Tuning Memory Check, page 68 Tuning BWM Parameters, page 68 Tuning Classifier Parameters, page 68 Tuning Device Table Parameters, page 70 Tuning SYN Protection Parameters, page 75 Tuning Diagnostics Parameters, page 76 Tuning Virtual Tunneling Parameters, page 76
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. Select Services > Tuning > Statistics. The Statistics Tuning pane is displayed. 2. In the relevant After Reset fields, configure the parameters; and then, click Set.
Table 21: 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
67
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.
Table 22: BWM Tuning Parameters
Parameter
Policy Table
Description
The number entries in the BWM Policy Table. Values: 256150,000 Default: 1024
Policy Leaves Percent
The percentage of hierarchical BWM leaves (that is, hierarchical BWM policies without a child policy) out of the total number of policies that the device supports. Values: 40100 Default: 100
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
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.
68
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.
To configure the Classifier tuning parameters 1. Select Services > Tuning > Classifier. The Classifier Tuning pane is displayed. 2. In the relevant After Reset fields, configure the parameters; and then, click Set.
Table 23: 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
69
Table 23: Classifier Tuning Parameters
Parameter
Dynamic Network Table
Description
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: 1024
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
OR Group Table
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.
70
LinkProof User Guide Device Management 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).
To configure the tuning parameters for the device tables 1. Select Services > Tuning > Device. The Device Tuning pane is displayed. 2. In the relevant After Reset fields, configure the parameters; and then, click Set.
Table 24: 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 Resets Table
The maximum number of entries in the Session Resets Table. Values: 1 100,000 Default: 100 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
Bridge Forwarding Table
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
71
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 and OnDemand Switch 2 with 4 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 and OnDemand Switch 2 with 4 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
72
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 and OnDemand Switch 2 with 4 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 and OnDemand Switch 2 with 4 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
73
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
static PAT Table
The maximum number of static PAT addresses that can be configured on the device. Static PAT enables a one-to-many port-address-translation mapping, which are used mostly for inbound connections for server/ services via a single IP address. Values: 2020,000 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
PAT & Dynamic NAT Port Table
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 and OnDemand Switch 2 with 4 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
74
Tuning SYN Protection Parameters

To configure the SYN Protection tuning parameters 1. Select Services > Tuning > SYN Protection. The SYN Protection Tuning pane is displayed. 2. In the relevant After Reset fields, configure the parameters; and then, click Set.
Table 25: 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
75
Tuning Diagnostics Parameters

To configure the Diagnostics tuning parameters 1. 2. Select Services > Tuning > Diagnostics. The Diagnostics Tools Tuning pane is displayed. In the Policies after reset field, configure the parameter; and then, click Set. Values: 1256. Default: 16.
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.
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 26: 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
76
Table 26: Virtual Tunneling Settings
Table
Local Station table
Description
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 77 Syslog Reporting, page 77 SMTP E-mail Notifications, page 79 Configuration Trace, page 80
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.
77
To configure sending traps to a syslog server 1. 2. Select Services > Syslog Reporting. The Syslog Reporting pane is displayed. Configure the parameters; and then, click Set.
Table 27: Syslog Reporting Parameters
Parameter
Syslog Operation Syslog Station Address Syslog Station Facility
Description
Enables or disables syslog reporting. Values: enable, disable The IP address of device running the syslog service (syslogd). Default: 0.0.0.0 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
78
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.
To configure e-mail notifications 1. Select Services > SMTP. The SMTP pane is displayed. 2. Configure the parameters; and then, click Set.
Table 28: 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
79
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
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 29: DNS Client Parameters
Parameter
DNS Client Primary DNS Server Alternate DNS Server
Description
Specifies whether the DNS client is enabled. The IP address of the primary DNS server. The IP address of the alternate DNS server.
80
To configure an entry in the static DNS table 1. Select Services > DNS. The DNS Client Parameters pane is displayed. 2. Click Create. The Static DNS Table Create pane is displayed. 3. Configure the parameters; and then, click Set.
Table 30: DNS Client Parameters
Parameter
Hostname IPv4 Address IPv6 Address
Description
The domain name for the specified IP addresses. The IPv4 address for the specified domain name. The IPv6 address for the specified domain name.
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 deviceThe 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
81
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. 2. 3. Select File > Support. The Download Tech Support Info File pane is displayed. Click Set. A File Download dialog box opens. Click Open or Save and specify the required information.
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 88) and the relevant options are enabled. Diagnostic tools stop 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 82 Trace-Log, page 84 Diagnostic Tools Files Management, page 87 Diagnostics Policies, page 88
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
82
LinkProof User Guide Device Management 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. Select Services > Diagnostics > Capture > Parameters. The Capture Tool Configuration pane is displayed. 2. Configure the parameters; and then, click Set.
Table 31: 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 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
83
Table 31: Capture Tool Configuration Parameters
Parameter
Capture Point
Description
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. 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 84 Diagnostics Trace-Log Message Format, page 85 Trace-Log Modules, page 86
Trace-Log Tool Configuration
To configure the Trace-Log tool using Web Based Management 1. 2. Select Services > Diagnostics > Trace-Log > Parameters. The Diagnostics Trace-Log Tool Configuration pane is displayed. Configure the parameters; and then, click Set.
84
Table 32: 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 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.
To configure the diagnostics Trace-Log message format using Web Based Management 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 33: Diagnostics Trace-Log Message Format Parameters
Parameter
Date Time Platform Name File Name Line Number
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.
85
Table 33: Diagnostics Trace-Log Message Format Parameters
Parameter
Packet Id Module Name Task Name
Description
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 d 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.
To configure the parameters of the Trace-Log modules using Web Based Management 1. Select Services > Diagnostics > Trace-Log > Modules. The Trace-Log Modules pane is displayed. The table in the pane comprises the following columns: NameThe name of the module. Values: BWM GENERIC HMM LCD StatusThe current status of the traced module. SeverityThe lowest severity of the events that the Trace-Log includes for this module. Values: Emergency Alert Critical Error Warning Notice Info Debug Click the relevant link. The Trace-Log Modules Update pane is displayed. Configure the parameters; and then, click Set.
2. 3.
86
Table 34: 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.
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 using Web Based Management 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.
87
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. 2. 3. Select Services > Diagnostics > Policies. The Diagnostics Policies pane is displayed. Click Create. The Diagnostics Policies Create pane is displayed. Configure the parameters; and then, click Set.
Table 35: 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
The port group whose outbound packets the policy classifies (that is, captures). Note: You cannot set the Outbound Port Group when the value of the Trace-Log Status parameter is Enabled.
Inbound Port Group Service Type Service
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
88
Table 35: Diagnostics Policies Parameters
Parameter
Destination MAC Group Source MAC Group
Description
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 Note: You cannot set the Outbound Port Group when the value of the Trace-Log Status parameter is Enabled.
Management Interfaces
This section describes the management interfaces that LinkProof supports and contains the following topics: Configuring a Telnet Management Interface, page 89 Configuring Web Server Management Interfaces, page 90 Configuring an SSH Interface for Management, page 92 Configuring an FTP Interface for Management, page 93
Configuring a Telnet Management Interface

You can access LinkProof via Telnet. You can configure Telnet access using Web Based Management or CLI.
Note: If three incorrect logins are entered, for the following 10 minutes, the device accepts no further login attempts from the user.
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.
89
Table 36: 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
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.
90
Table 37: Web Server Parameters
Parameter
Web Server Port Web Server Status Web Help Location Web Access Level
Description
Port to which the Web Based Management is assigned. Enables or disables the status of the Web server. 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 38: 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
91
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 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 39: 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
92
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 40: 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

LinkProof provides additional security by authenticating users accessing the device for management purposes. Before a management session starts, LinkProof can authenticate the user with a RADIUS server. These servers determine whether a user can access LinkProof managementusing CLI, Telnet, SSH, or WBM. If a RADIUS server is not available or the user is not defined in the RADIUS server, LinkProof uses the User Table to authenticate access.
Caution: To enable remote management access to the device when no RADIUS server is available, at least one user with read-write access must be configured in the local User Table. If no user with a read-write access is configured in the local User Table, when no RADIUS server is available, only a physical connection to the device is possible. If the RADIUS authentication server successfully authenticates the remote user, the LinkProof device verifies the privileges of the remote user and authorizes the appropriate access level. To determine the access level of the remote user, LinkProof uses the value of the Service-Type attribute (AVP 6) in the Access-Accept response. LinkProof supports the Service-Type values 6 and 255. The value 6 (as specified in the RADIUS RFC) specifies Administrative (read-write) access. The value 255 specifies restricted (read-only) access. The value 255 must be defined in the dictionary of the RADIUS servers as the Vendor-Specific (AVP 26) Radware (Vendor ID 89) Service-Type value.
93
LinkProof User Guide Device Management If the Service-Type attribute is not present in the Access-Accept response or its value is not 6 or 255, LinkProof grants the access level according to the specified Default Authorization value (ReadWrite, Read-Only, or No-Access).
Example RADIUS Dictionary Rows Attribute Service-Type 26 [vid=89 type1=26 len1=+1 data=integer]
Value Service-Type Read-Only 255
To configure RADIUS Authentication for device management 1. 2. 3. 4. Select Security > Users. The User Table and Authentication pane is displayed. From the Authentication Method drop-down list, select RADIUS and Local User Table; and then, click Set. Select Services > Radius. The Radius Parameters pane is displayed. Configure the following parameters; and then, click Set.
Table 41: RADIUS Authentication Parameters
Parameter
Main Radius IP Address Main Radius Port No.
Description
The IP address of the primary RADIUS server. The access port number of the primary RADIUS server. Values: 1645, 1812 Default: 1645
Main Radius Secret Backup Radius IP Address Backup Radius Port No.
The authentication password for the primary RADIUS server. The IP address of the backup RADIUS server. The access port number of the backup RADIUS server. Values: 1645, 1812 Default: 1645
Backup Radius Secret Radius Timeout
The authentication password for the backup RADIUS server. The time, in seconds, that the LinkProof device waits for a reply from the RADIUS server before retrying, or, if the Radius Retries value has been reached, before the device considers the server to be off line. Values: 110 Default: 1
Radius Retries
The number of connection retries to the RADIUS server before the LinkProof device considers the server to be off line. Values: 13 Default: 2
94
Table 41: RADIUS Authentication Parameters
Parameter
Radius Client Life Time
Description
The time, in seconds, for client authentication. After the lifetime expires, the device re-authenticates the user. Values: 23600 Default: 30
Default Authorization
The access level that the LinkProof device grants a user who is authenticated by a RADIUS server but whose user privileges were not provided or unknown user privileges were provided. Values: Read-Write, Read-Only, No-Access Default: Read-Write
Logging
This section includes details on viewing and enabling various logs for use with LinkProof, and includes these topics: Event Log, page 95 SMTP Logging, page 95 Power Supply Traps, page 96
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 send 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.
95
To configure an SMTP client 1. 2. Select Services > SMTP. The SMTP pane is displayed. Configure the parameters; and then, click Set.
Table 42: 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 SMTP Status Specifies the e-mail address of the device. 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 43: 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
96
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.
97
98
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 99 Virtual LAN, page 106 IP Addressing and Routing, page 116
Port Settings
This section describes LinkProof features that handle traffic and port management and contains the following topics: Port Mirroring, page 99 Link AggregationPort Trunking, page 100 Port Rules, page 104 Port Load Balancing Status, page 105
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.
99
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 44: 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

This section contains the following topics: Link AggregationGlobal Configuration, page 102 Link Aggregation Trunk Table, page 102 Link Aggregation Port Table, page 103
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.
100
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 45 - Supported Link-Aggregation Configurations for OnDemand Switch 2, page 101. The following table lists combinations for link aggregation supported on the OnDemand Switch 2 platform.
Table 45: 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.
101
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 46: 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.
102
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.
103
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.
104
Rules Table
Use the Rules Table pane to view what port 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.
105
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 106 Supported VLAN Types, page 106 IPv6 Pass-through, page 107 Bridging, page 109 VLAN Example Configuration, page 109 Configuring VLANs, page 110 Redundancy with VLANs, page 112 VLAN Tagging, page 112
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 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.
106
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.
107
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 19: 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)
108
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.
109
Figure 20: 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 110 Configuring the Virtual LAN Table and VLAN Port Table, page 111
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 47: 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.
110
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 48: 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 49: 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.
111
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 50: 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 265.
VLAN Tagging
This section describes VLAN tagging and contains the following topics: VLAN Tagging Support, page 112 Using VLAN Tagging, page 113 Setting a VLAN Tag for an IP Interface, page 114 Configuring VLAN Tagging, page 115
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.
112
LinkProof User Guide Basic Switching and Routing 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.
Notes >> VLAN tags can also be attached to IPv6 interfaces to apply to IPv6 traffic and behave exactly like IPv4 interfaces. >> If you want 8021.q information, you need to capture what is being sent to the LinkProof on the neighboring switch. Therefore 802.1q header information cannot be displayed in the packet capture.
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.
113
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 21: 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.
114
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 51: 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
115
IP Addressing and Routing

This section describes the configuration of VLAN IP addressing and routing and contains the following topics: IP Interfaces, page 116 IP Router Operating Parameters, page 117 Viewing and Configuring IP Router IP Interfaces, page 117 Configuring ICMP Interface Parameters, page 120 Routing, page 121 Routing Information Protocol, page 123 IPv6 Neighbor Discovery, page 125 Configuring ARP Parameters, page 129 Open Shortest Path First (OSPF), page 130
IP Interfaces
Note: LinkProof supports both IPv4 and IPv6 IP interfaces. An IP interface on LinkProof is an IP address associated with a layer 2 interface (physical port, VLAN or trunk). The IP interface prefix length (for IPv6) netmask (for IPv4) defines the subnet attached to that layer 2 interface. The IP interfaces serve the following purposes: Allows LinkProof to select the layer 2 interface via which traffic sent from the device must be sent. Serves as source address for traffic initiated by LinkProof (for management purposes, proprietary protocols between LinkProof devices, health checks, and so on). Serves as default route for hosts in the attached subnet. However, Radware recommends that in redundant configurations, Virtual IP interfaces are used as default route. Serves as primary IP address for Virtual Routers (VRRP). Radware recommends that Virtual IP interfaces be used as the primary IP address.
LinkProof performs routing between the subnets defined by the IP interfaces. Link-local addresses are network addresses which are intended only for communications within one segment of a local network (a link) or a point-to-point connection. They allow addressing hosts without using a globally-routable address prefix. Routers will not forward packets with link-local addresses. Link-local addresses are often used for network address configuration when no external source of network addressing information is available. This addressing is accomplished by the host operating system using a process known as stateless address autoconfiguration. This is possible in both IPv4 and IPv6. IPv4 addresses in the range 169.254.0.0/16 are assigned automatically by a host operating system when no other IP addressing assignment is available for example, from a DHCP server. In IPv6, linklocal addresses are required and are automatically chosen with the FE80::/10 prefix.
116
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.
Table 52: IP Router Parameters
Parameter
Description
Inactive ARP Timeout 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. Values: 11100,000,000 Note: Changing the value affects only newly created ARP entries. ARP Proxy 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 ICMP Error Messages Specifies whether ICMP error messages are generated. Values: enable, disable Default: enable ICMP Error Burst Limit Advanced Fast Forwarding Status The maximum ICMP error messages, in packets, emitted in a single burst. Default: 64 Specifies whether the IP Fast Forward Table is used. When enabled, the table holds MAC-address information of servers only (pre-defined in the LinkProof farms) and not clients. Values: Enable, Disable Default: Disable
Viewing and Configuring IP Router IP Interfaces

Use the IP Interface Table pane to view and configure the IP interfaces.
To view and configure an IP Interface 1. Select Router > IP Router > IP Interfaces. The IP Interface Table window is displayed. 2. Do one of the following: 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.
117
Table 53: IP Interface Parameters
Parameter
IP Address If Number Address Origin
Description
The IP address of the interface. The interface identifier of the Layer 2 interface. (Read-only) The origin of the address. Values: otherThe address may include a random chosen address or well-known value for example, an IANA assigned anycast address. manualThe address was manually configured. dhcpThe address was assigned to this system by a DHCP server. linklayerThe address was created by IPv6 stateless autoconfiguration.
Status
(Read-only) The current status of the IP interface. Values: PreferredThis is a valid address that can appear as the destination or source address of the packet. DeprecatedThis is a valid but deprecated address that should no longer be used as a source address in new communications, but packets addressed to such an address are processed as expected. InvalidThis is not valid address which should not appear as the destination or source address of a packet. InaccessibleThe address is not accessible because the interface to which this address is assigned is not operational. UnknownThis address is unknown. TentativeThe uniqueness of the address on the link is being verified. DuplicateThe address has been determined to be non-unique on the link and so must not be used. OptimisticThe address is available for use, subject to restrictions, while its uniqueness on a link is being verified. This value is designed to minimize address configuration delays and to reduce disruption.
Prefix Length
The prefix length that defines the subnet attached to this IP interface. For IPv4, the prefix length varies between subnets to subnets, and renumbering subnets can be expensive. With IPv4, the allocation varies by the size of the site, which can be a problem when you migrate from one ISP to another. IPv4 values: 032 For IPv6, the prefix is a decimal value that indicates the number of contiguous, higher-order bits of the address that make up the network portion of the address. For example, 10FA:6604:8136:6502::/64 is a possible IPv6 prefix. The prefix length for an IPv6 subnet will always be less than 64. It allows you to place as many IPv6 devices as the underlying network medium allows. IPv6 values: 3127
Prefix Onlink Flag
Specifies whether the addresses with that prefix can be reached directly without going through a router. The prefix list in the Neighbor Discovery cache table defines a set of IP address ranges that the host can reach. The prefix flags are L for on-link, and A for autonomous. Default: true
118
Table 53: IP Interface Parameters
Parameter
Prefix Autonomous
Description
Specifies whether the prefix came from stateless autoconfiguration. The prefix list in the Neighbor Discovery cache table defines a set of IP address ranges that the host can reach. The prefix flags are L for on-link, and A for autonomous. Default: Disabled The router advertisement preferred life time, in seconds. Values: 1Infinite Default: Infinite
Preferred Lifetime
Valid Lifetime
The router advertisement valid life time, in seconds. Values: 1Infinite Default: Infinite
Fwd Broadcast (This parameter is available only for IPv4 interfaces.) Broadcast Addr (This parameter is available only for IPv4 interfaces.)
Specifies whether the device forwards incoming broadcasts to this interface. Default: Enabled
Specifies whether to fill the host ID in the broadcast address with ones or zeros. Values: One FillFill the host ID in the broadcast address with ones. Zero FileFill the host ID in the broadcast address with zeros. Default: One Fill
VLAN Tag
When multiple VLANs are associated with the same switch port, the switch must identify to which VLAN to direct incoming traffic from that specific port. VLAN tagging provides an indication in the Layer 2 header that enables the switch to make the correct decision. Enter the tag to be associated with this IP interface. (Router Interface Only) Specifies whether the device uses the One-IP-for-NAT feature. This parameter works only for IPv4 interfaces. For more information, see One-IP-for-NAT Support, page 172. Values: Enable, Disable Default: Disable
One IP Mode
Peer IP Address
The IP address of the interface on the peer device, which is required in a redundant configurationthat is, a cluster for high availability. Default: 0.0.0.0
To show or hide link-local address entries in the IP Interface Table 1. Select Router > IP Router > IP Interfaces. The IP Interface Table window is displayed. 2. From the Show link local address entries drop-down list, select one of the following: EnabledShow link-local address entries in the IP Interface Table. DisabledHide link-local address entries in the IP Interface Table.
119
LinkProof User Guide Basic Switching and Routing 3. Configure the parameters; and then, click Set.
Note: The link-local address are generated based on IPv6 RFC compliance.
Configuring ICMP Interface Parameters

Use the ICMP Interface Parameters pane to configure Internet Control Message Protocol (ICMP) parameters of an existing interface.
To edit the ICMP parameters of an interface 1. 2. 3. Select Router > IP Router > Interface Parameters. The ICMP P Router Interface Parameters pane is displayed. From the ICMP Interface Parameters table, click the IP address of the relevant interface. The ICMP Interface Parameters Update pane is displayed. Configure the parameters; and then, click Set.
Table 54: IP Router Interface Parameters
Parameter
IP Address Advert. Address
Description
(Read-only) The IP address of the interface. 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 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
Min Advert. Interval
Advert. Lifetime
Advertise
Specifies whether the device advertises the device IP address using ICMP Router Advertise.
120
Table 54: IP Router Interface Parameters
Parameter
Preference Level Reset to Defaults
Description
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
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. 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.
121
Table 55: 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. 2. 3. Select Router > Routing Table. The Routing Table pane is displayed. Select a Destination Address. The Routing Table Update pane is displayed. Configure the parameters; and then, click Set.
Table 56: Routing Table Update Parameters
Parameter
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. 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.
122
Configuring a Default Gateway
Note: You can set up a backup default gateway for LinkProof.
To configure a default gateway 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 57: Default Gateway Parameters
Parameter
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. 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.
123
Configuring the RIP Parameters
To configure the RIP parameters 1. 2. Select Router > RIP > Parameters. The RIP Parameters pane is displayed. Configure the parameters; and then, click Set.
Table 58: 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. 2. 3. Select Router > RIP > Interface Parameters. The RIP Interface Table pane is displayed. Select the interface to edit. The RIP Interface Table Update pane is displayed. Configure the parameters; and then, click Set.
124
Table 59: 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
IPv6 Neighbor Discovery

IPv6 Neighbor Discovery (NDisc) is a set of messages and processes that determine relationships between neighboring nodes. NDisc replaces Address Resolution Protocol (ARP), Internet Control Message Protocol (ICMP) Router Discovery, and ICMP Redirect, which are used in IPv4, and provides additional functionality. NDisc is described in RFC 2461, Neighbor Discovery for IP Version 6 (IPv6).
125
LinkProof User Guide Basic Switching and Routing Routers use NDisc to do the following: Advertise their presence, host configuration parameters, and on-link prefixes. Inform hosts of a better next-hop address to forward packets for a specific destination.
Nodes use NDisc to do the following: Both resolve the link-layer address of a neighboring node to which an IPv6 packet is being forwarded and determine when the link-layer address of a neighboring node has changed. Determine whether IPv6 packets can be sent to and received from a neighbor.
Configuring the Neighbor Cache

The neighbor cache keeps track of the neighbors on the local links with which AppDirector is in contact. The neighbor cache is the IPv6 parallel of the ARP table. The neighbors are either dynamically discovered using neighbor discovery protocol or statically configured.
To create a Neighbor Cache entry 1. 2. 3. Select Router > IPv6 Neighbor Discovery > Neighbor Cache. The Neighbor Cache window is displayed. Click Create. Configure the parameters; and then, click Set.
Table 60: Neighbor Cache Parameters
Parameter
Interface Index IP Address MAC Address Type
Description
Interface identifier for neighbor cache entry. Neighboring nodes IPv6 address. MAC address corresponding to neighboring nodes IPv6 address. The type of the neighbor-cache entry. Values: Dynamic Invalid Local Other Static Default: Static
The number of times this neighbor relationship has changed state, or (This parameter is exposed an error has occurred. only for existing entries) Values: State Reachable Stale Delay Probe Invalid Unknown Incomplete
126
Configuring Duplicate Address Detection

Duplicate Address Detection (DAD) is the process by which a node determines that an IPv6 address considered for use is not already in use by a neighboring node. (This is equivalent to the use of gratuitous ARP frames in IPv4.) The DAD process consists of sending a neighbor discovery whenever the device is assigned a new IP address, asking for a neighbor with the same address. The device performs the DAD procedure for each newly configured IPv6 address: IP interface, VIP, VIPIm, and client NAT addresses belonging to a subnet configured on the device (matching IP interface). DAD is not performed for VIP, VIPIs, and client NAT addresses that do not have a matching IP interface (that is, orphan addresses). DAD is also performed for each configured IP addresses (IP interfaces, non-orphan VIPs, VIPIs and client NAT addresses) on device startup.
To configure Duplicate Address Detection 1. Select Router > IPv6 Neighbor Discovery > Duplicate Address Detection. The Duplicate Address Detection window is displayed. 2. Configure the parameter; and then, click Set.
Table 61: Neighbor Cache Parameters
Parameter
Retransmits Number
Description
Enables the DAD process and determines the number of times that the DAD Neighbor discovery message is transmitted, where value of zero means DAD is disabled.
IPv6 Router Advertisement

With IPv6, routers can be dynamically discovered and adopted as default gateways by the host nodes on the same local link, rather than having to statically configure the default gateway and change it on every network restructure. This process also allows the node to automatically assign its own global unicast IP address, by having the router publish a prefix for the subnet to be attached to the hosts link local address. This is called stateless auto-configuration and comes as an alternative to DHCP, which is stateful, because it has to keep record of the assigned IP address. Nevertheless, DNS server addresses must still be obtained from DHCP servers, but this does not incur state maintenance. The LinkProof device can periodically send Router Advertisements (RAs) on each IP interface according to a random interval, between specified minimum and maximum times. The managed device also sends these messages in response to Router Solicitation messages.
To configure IPv6 Router Advertisement 1. Select Router > IPv6 Neighbor Discovery > IPv6 Router Advertisement. The IPv6 Router Advertisement window is displayed. 2. Click the link of the required interface. 3. Configure the parameters; and then, click Set.
127
Table 62: IPv6 Router Advertisement Parameters
Parameter
Interface Index Send RA Messages
Description
(Read-only) The identifier of the interface on the physical device. Specifies whether the device sends IPv6 Router Advertisement (RA) messages. Default: true The maximum time, in seconds, between Router Advertisements that the device sends. Values: 41800 Default: 600
Max RA Interval
Min RA Interval
The minimum time, in seconds, between Router Advertisements that the device sends. Values: 31350 Default: 200 Note: The value must be no greater than 75 percent of the specified Max RA Interval.
Managed Address Config
Specifies whether the messages that the device sends include the flag that indicates whether the hosts should use stateful autoconfiguration to obtain addresses. Default: false Note: Router Advertisements contain two flags indicating what type of stateful autoconfiguration (if any) should be performed.
Other Configuration Flag
Specifies whether the messages that the device sends include the flag that indicates whether the hosts should use stateful autoconfiguration to obtain additional information (excluding addresses). Default: false Note: Router Advertisements contain two flags indicating what type of stateful autoconfiguration (if any) should be performed.
MTU
The Maximum Transmission Unit, which is the largest size, in bytes, of physical packets that a network can transmit. The device divides messages larger than the MTU into smaller packets before being sending them. Values: 0Specifies the maximum value 11000000000 Default: 0
Reachable Time
Specifies the time, in seconds, that the router can reach a remote IPv6 node (neighbor) after some reachability confirmation event has occurred. Values: 0Specifies the maximum time 13600000 Default: 0
128
Table 62: IPv6 Router Advertisement Parameters
Parameter
Retransmit Time
Description
The time, in seconds, between sending one neighbor discovery (solicitation) and the next. The time between retransmissions of neighbor solicitations to a neighbor when resolving the address or when probing the reachability of a neighbor. (Read-only.) Values: 0Specifies the maximum time 13600000 Default: 0
Current Hop Limit
The current, advertised, hop limit of the IPv6 router component on the device. Values: 0Specifies the maximum limit 1255Default: 64
Default Router Lifetime How long, in minutes, a host should consider the advertised address to be valid. After the time elapses, and the host has not received a router advertisement from the server, the route marks the advertised addresses as invalid. Values: 0Specifies the maximum time 19000Default: 1800
Configuring ARP Parameters
To configure ARP parameters 1. Select Router > ARP Table. The ARP Table pane is displayed. 2. Click Create. The ARP Table Create pane is displayed. 3. Configure the parameters; and then, click Set.
Table 63: ARP Parameters
Parameter
Interface Index MAC Address
Description
The interface number on which the station resides. The MAC address of the station.
129
Table 63: ARP Parameters
Parameter
IP Address Type
Description
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. 2. Select Router > IP Router > Operating Parameters. The IP Router Parameters pane is displayed. 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. Click Set.
3.
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.
130
OSPF Operating Parameters
To set the OSPF Operating Parameters 1. Select Router > OSPF > Operating Parameters. The OSPF Operating Parameters pane is displayed. 2. Configure the parameters; and then, click Set.
Table 64: 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
131
OSPF Interface Parameters
To update the OSPF interface parameters 1. 2. 3. Select Router > OSPF > Interface Parameters. The OSPF Interface Parameters pane is displayed. Select the IP Interface. The OSPF Interface Table Update pane is displayed. Configure the parameters; and then, click Set.
Table 65: 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.
132
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.
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 66: 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
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.
133
Parameter
Link State ID Router ID Sequence
Description
Identifies a piece of routing domain described by the advertisement. It can be a router ID or an IP address. 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 185 DNS, page 191 Basic Load Balancing, page 197 Load Balancing Weights, page 203 Flow Management, page 203 Client Table, page 209 VPN Load Balancing, page 227
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 22: 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 Network 10.1.1.x NAT: 200.1.1.21 Via NHR2 NHR 2 200.1.1.20
Figure 22 - 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 209) 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 209).
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 23: 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 23 - 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.
Note: For multihoming with IPv6, see IPv6 Prefix-NAT, page 179.
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 371. Define flows and flow policiesif routing policies are required. For the procedure, see Configuring Flow Policies, page 206.
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 169. 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 170. Map the URLs for which LinkProof is authoritative server to the internal server IP addresses, Mapping URLs to Local IP Addresses, page 191.
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.
138
LinkProof User Guide Basic Application Switching A LinkProof farm can contain either logical routers (access routers to the WAN) or logical firewalls/ VPN gateways, but not combination of the two in the same farm.
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 67: 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 Destination IP 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. Default: Disable
NAT Mode
Specifies whether LinkProof does network address translation on the packets for IPv4 addresses or Prefix-NAT for IPv6 addresses. 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
To configure extended parameters for a farm 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 68: Extended Parameters for a Farm of Logical Routers and/or Logical Firewalls
Parameter
Farm Name Clear Client Table Condition
Description
(Read-only) The name of the farm. 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 68: 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. 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 229 Source IP Hashing, page 149 Layer 3 Hashing, page 149 Destination IP 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 69: 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 69: 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 70: 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 70: 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 371). 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 Multicast Dispatch, page 229. This feature is supported only for IPv4 addresses.
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.
Destination IP Hashing
When the Destination IP Hashing Dispatch Method is specified, LinkProof distributes the traffic between the Routers/Firewalls according to the destination IP address. Using this method, you ensure that traffic to the same destination is always sent through the same NHR.
Caution: When the Destination IP Hashing Dispatch Method is specified, the remote LinkProof device must use the same dispatch method.
149
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. 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 71: 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
150
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.
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.
151
LinkProof User Guide Basic Application Switching 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). 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 24: 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
152
LinkProof User Guide Basic Application Switching 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).
Figure 25: 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.
153
LinkProof User Guide Basic Application Switching 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.
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 72: 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 73: 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 (see Farm 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. When the option is 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 74: 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 connection limit. The value range depends on your device. For information, see the LinkProof Tuning Table document.
157
Table 74: 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 75: 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 75: 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. Values: 0The mechanism is disabled for this server, and there is no connection limit. The value range depends on your device. For information, see the LinkProof Tuning Table document.
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.
160
To modify a logical firewall and/or view related statistics 1. Select LinkProof > Servers > Logical Firewalls Table. The Logical Firewall Table pane is displayed. 2. Select the link to the required server. The Logical Firewall Table Update pane is displayed. 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 76: 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.
Connected Users Peak Load Frames Load
161
Parameter
Connection Limit
Description
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 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. Values: 0The mechanism is disabled for this server, and there is no connection limit. The value range depends on your device. For information, see the LinkProof Tuning Table document.
Peak Kbps Load Recovery Time
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
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.
162
Parameter
Kbps Limit
Description
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 Kbits Load In Kbps Limit
In Kbit/s. The value is read-only. 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
The number of discarded packets. The value is read-only.
163
Parameter
Billing mode
Description
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
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.
164
Figure 26: 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 26 - Potential Issues When Not Using Cluster Support, page 165, 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. 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.
165
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. 2. 3. Select LinkProof > Servers > Cluster Servers Table. The Clusters Servers Table pane is displayed. Click Create. The Clusters Servers Table Create pane is displayed. Configure the parameters; and then, click Set.
Table 77: 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.
166
LinkProof User Guide Basic Application Switching 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. Select LinkProof > Servers > Full Path Health Monitor Table. The Full Health Monitor Table pane is displayed. 2. Configure the parameters; and then, click Set. The device IP is added to the table.
Table 78: 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.
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 168 Dynamic NAT, page 169 Static NAT, page 170 No NAT, page 171
167
LinkProof User Guide Basic Application Switching Basic NAT, page 171 One-IP-for-NAT Support, page 172 Static Port Address Translation (Static PAT or SPAT), page 174 NAT Parameters Summary, page 177 IPv6 Prefix-NAT, page 179
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 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.
168
LinkProof User Guide Basic Application Switching 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 67. >> SmartNAT in IPv6 is a challenge, since there is no simple way to perform IPv6-to-IPv6 NATthat is, hiding a network behind a single IP address. The logic behind IPv6 states that all the addresses are routable and accessible on the public Internet. There is no need for one-to-many translations, because there is no expected depletion of IP address in the foreseeable future. For more information, see IPv6 Prefix-NAT, page 179.
Dynamic NAT
The Dynamic NAT feature enables LinkProof to hide various IPv4 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. Select LinkProof > Smart NAT > IPv4 NAT > Dynamic NAT. The Dynamic NAT Table pane is displayed. 2. Click Create. The Dynamic NAT Table Create pane is displayed. 3. Configure the parameters; and then, click Set.
Table 79: Dynamic NAT Parameters
Parameter
From Local IP To Local IP Server 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.
169
Table 79: Dynamic NAT Parameters
Parameter
Dynamic NAT IP
Description
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 IPv4 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. 2. 3. Select LinkProof > Smart NAT > IPv4 NAT > Static NAT. The Static NAT Table pane is displayed. Click Create. The Static NAT Table Create pane is displayed. Configure the parameters; and then, click Set.
Table 80: 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.
170
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. Select LinkProof > Smart NAT > IPv4 NAT > NAT Parameters Summary. The NAT Parameters Summary pane is displayed. 2. From the Exclude Static NAT for Local Network drop-down list, select Disable. 3. 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 IPv4 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. Select LinkProof > Smart NAT > IPv4 NAT > No NAT. The No NAT Table pane is displayed. 2. Click Create. The No NAT Table Create pane is displayed. 3. Configure the parameters; and then, click Set.
Table 81: 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 IPv4 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
171
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. 2. 3. Select LinkProof > Smart NAT > IPv4 NAT > Basic NAT. The Basic NAT Table pane is displayed. Click Create. The Basic NAT Table Create pane is displayed. Configure the parameters; and then, click Set.
One-IP-for-NAT Support
You can use the One-IP-for-NAT feature to reduce the number of public IPv4 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.
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 to maintain connectivity and functionality. For a regular non-VLAN bridge, each router connected to a LinkProof device needs several IP addresses to maintain functionality such as network connectivity, NAT, and so on. To reduce the usage of public IP address in the depleting IPv4 address space, LinkProof provides the One-IP feature. One-IP enables LinkProof to use its external IP address for the following purposes: Dynamic NAT, so the internal users can be dynamically NATed behind the LinkProof interface public address Inbound connections using SPAT (Static Port Address Translation)
172
LinkProof User Guide Basic Application Switching With One-IP not enabled, for a LinkProof device connected to two external routers, each connection will use the following configuration:
Table 82: LinkProof Connected to Two External RoutersOne-IP Not Enabled
Functionality
LinkProof physical interface (connection to router) Router internal IP address (connection to LinkProof)
Requires IP Address Minimal Number of IP Address Required

Yes, public IP Yes, public IP One per router One per router One or more per server
Static NAT IP addresses (that is, Yes, public IP per servers behind LinkProof for server inbound and outbound connectivity) Dynamic NAT (internal users accessing the Internet) Yes, public IP per network
One per network
So, with One-IP not enabled, in the case of a LinkProof device connected to two routers, where the internal network requires to access the Internet, six public IP addresses are required, comprised of the following: Two public addresses on LinkProof interfaces Two public addresses on router interfaces Two public addresses for Dynamic NAT on each LinkProof interface
With One-IP enabled, for a LinkProof device connected to two external routers, each connection will use the following configuration:
Table 83: LinkProof Connected to Two External RoutersOne-IP Enabled
Functionality
LinkProof physical interface (connection to router) Router internal IP address (connection to LinkProof)
Requires IP Address Minimal Number of IP Address Required

Yes, public IP Yes, public IP One per router One per router One or more per server
Static NAT IP addresses (that is, Yes, public IP per server servers behind LinkProof for inbound and outbound connectivity) Dynamic NAT (internal users accessing the Internet) Yes, public IP per network
ZeroLinkProof uses the physical interface IP
So, with One-IP not enabled, in the case of a LinkProof device connected to two routers, where the internal network requires to access the Internet, four public IP addresses are required, comprised of the following: Two public addresses on LinkProof interfaces Two public addresses on router interfaces
Using the One-IP feature, we saved two public addresses using instead the LinkProof external public IP addresses. You can do the same for inbound connections where SPAT will be used for explicitly defined services (for example, SMTP port 25, HTTP port 80) using the same external public address, thus providing services to two servers behind the LinkProof.
173
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 Mode 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 169.
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 IPv4 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.
174
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 27: 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
175
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 > IPv4 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
176
LinkProof User Guide Basic Application Switching When the One-IP-for-NAT feature is enabled (see One-IP-for-NAT Support, page 172), 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

Use the NAT Parameters Summary pane to do the following: View all IPv4 Smart NAT tables. Create new entries and update existing entries. Configure how the LinkProof device implements Static NAT on local-to-local traffic. If you want Static NAT only on one side, keep the defaults, that is, keep the Exclude Static NAT for Local Network and Always Translate Static NAT Destination to Local IP options disabled.
To configure how the device implements Static NAT on local-to-local traffic 1. Select LinkProof > Smart NAT > IPv4 NAT > NAT Parameters Summary. The NAT Parameters Summary pane is displayed. 2. Configure the parameters; and then, click Set.
Caution: You must not enable both Exclude Static NAT for Local Network and Always Translate Static NAT Destination To Local IP options.
177
Table 87: Exclude Static NAT for Local Network, and Always Translate Static NAT Destination To Local IP
Parameter
Description
Exclude Static NAT for Local Network Specifies whether the device does not use Static NAT on traffic from local hosts for which Static NAT is configured. Values: enableTraffic from a local host for which Static NAT is configured does not undergo NAT when forwarded to a network for which NAT is enabled. Use this option when you want LinkProof not to perform Static NAT on local traffictypically, for security purposes. disableTraffic from a local host for which Static NAT is configured undergoes NAT when forwarded to a network for which NAT is enabled; but the traffic to the local network is not translated. For example, suppose LinkProof routes traffic from server x to client y, both of which are in local networks. When there is a Static NAT definition on x, LinkProof changes the packet to be StaticNAT(x) to y. Default: disable Always Translate Static NAT Destination to Local IP Specifies whether LinkProof always translates Static NAT destinations to local IP address. Values: enableLinkProof changes the destination IP address from the Static NAT IP address to the local IP address when the configuration specifies also to perform Static NAT on the source IP address. That is, if the configuration uses Static NAT on both host x and host y, traffic is sent from x to StaticNAT(y), and the traffic should be translated to StaticNAT(x) to y. This means that LinkProof needs remove the Static NAT on the destination and add Static NAT on the source. Enable this option if you want to use Static NAT both on the source and on the destination. disableLinkProof does not change the destination IP address from the Static NAT IP address to the local IP address when the configuration specifies also to perform Static NAT on the source IP address. Default: disable
To configure NAT features using the NAT Parameters Summary pane Select LinkProof > Smart NAT > IPv4 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 169 Static NAT, page 170 No NAT, page 171
178
LinkProof User Guide Basic Application Switching Basic NAT, page 171 Static Port Address Translation (Static PAT or SPAT), page 174
IPv6 Prefix-NAT
Prefix-NAT performs IPv6 WAN load balancingusing address replacement, sending traffic to various ISPs, and load-balancing the load. In IPv6, there is no common practice for IPv6-to-IPv6 NAT. One reason is that due to the massive number of addresses, there is no reason to hide or replace internal addresses with external addresses. In addition, when IPv6 was designed, many of the problems associated with NAT traversal (for example, UDP, IPSec, and so on) were considered irrelevant. For these reasons and others, NAT was not planned or standardized in IPv6 (although there are several pending RFC drafts).
Note: For background information on Internet Protocol version 6 (IPv6), see Appendix C IPv6 Fundamentals, page 411.
IPv6-Address Structure and Network Prerequisites

An IPv6 address is 128 bits long, in the format 2020:1020:1001:1000:0001:0002:0003:0004. As defined by IANA, the following two ranges are reserved: Global Unicast Address (GUA)2000::/3 Unique Local Address (ULA)FC00::/7
Using internal and external IPv6 addresses requires the following: ULAs have already been configured by the network administrator. The administrator must ensure that the internal IPv6 network (the network behind the LinkProof device) uses internal addresses (as described in RFC 4193). ULAs are in the format FC00:AAAA:BBBB:CCCC:0001:0002:0003:0004.
Note: From the perspective of network design, the logic is analogous to RFC 1918 in IPv4, where using internal IP addresses is recommended. Each external router is assigned a public IPv6 addressesthat is, a GUA.
Figure 28 - Global Unicast Address, page 180 shows the structure of a Global Unicast Address. In a Global Unicast Address, the global routing prefix is assigned to an ISP by IANA. The site-level aggregator (SLA), or subnet ID, is assigned to a customer by the service provider. The LAN ID
179
LinkProof User Guide Basic Application Switching represents individual networks within the customer site, and it is administered by the customer. The Host or Interface ID has the same meaning for all unicast addresses. It is 64 bits long and is typically created using the EUI-64 format.
Figure 28: Global Unicast Address
Note: According to IANA regulations, customers are assigned IPv6 addresses with prefixes from /48 to /64. The smallest network prefix is /64 (which is somewhat analogous to class C in IPv4). ISPs dedicate the /48 prefix to customers. Figure 29 - Unique Local Address Structure, page 180 shows the ULA structure.
Figure 29: Unique Local Address Structure
Load-Balancing Traffic Across IPv6 WAN (or Internet) Connections

Due to the nature of the GUA and ULA, the last 64 bits are identical (see Figure 28 - Global Unicast Address, page 180 and Figure 29 - Unique Local Address Structure, page 180). Therefore, the first 48 bits are interchangeable. Utilizing these attributes, it is possible to use the same prefix manipulation for load-balancing traffic across IPv6 WAN (or Internet) connections.
Steps in Configuring Prefix-NAT

Configuring Prefix-NAT using Web Based Management (WBM) comprises the following steps: 1. 2. Configuring the IPv6 interfaces (internal, and router-bound). Configuring the farm, and enabling NAT in the configuration of the farm. In the configuration of the farm, you must ensure that the value of the NAT Mode parameter is Enable. (The default value of the NAT Mode parameter is Disable.) The NAT Mode parameter specifies whether the LinkProof device does network address translation on the packets for IPv4 addresses or PrefixNAT for IPv6 addresses. Configuring the IPv6 routers.
3.
180
Example IPv6 Topology and Prefix-NAT Configuration

Due to the nature of the IPv6 address scheme, the following scenario presents a simplistic approach. According to IANA, the LIR/RIR address assignment should be /48 for subscribers (including private housing). This enables each subscriber to configure about 216 networks. These numbers are immense, so the scenario uses a simple address scheme based on IPv6 subnetting. Consider the following scenario, which is shown in Figure 30 - Example LinkProof IPv6 Topology, page 181: LinkProof is connected to the following two IPv6 service providers: ISP A dedicates the following public addresses: 2030:2020:1000::/48 ISP B dedicates the following public addresses: 2040:1020:2000::/52
The network administrator has followed IANA recommendations and has subnetted the internal network using ULA. In addition, the network administrator has subnetted the external routers accordingly.
Figure 30: Example LinkProof IPv6 Topology
Notes >> The use of the /55 prefix to subnet the /48 network is arbitrary. In real life, subnetting will usually be based on the need for free networks as well as the existing topology. >> The Prefix-NAT feature supports network ranges from /64 to /48.Prefix NAT is allowed as long as the number of internal IPv6 address is smaller than or equal to the number of external IPv6 addresses. So, for example, when the external router is configured with a /64 range, using a ULA /48 for Prefix-NAT is not allowed. When the public IPv6 address range of the external router is /59, using a ULA /59 for Prefix-NAT is allowed. >> The translation is done per address. So, for example, an IPv6 ULA address with the address fc00:1002:fc01:3000:2000::1001/48 will be translated on the external interface using 2030:2020:1000::/48 as 2030:2020:1000:3000:2000::1001. >> The routers are all defined in a single router farm. >> The routers are all set as active, although it is not necessary for the functionality of the Prefix-NAT feature.
181
LinkProof User Guide Basic Application Switching Table 89 - Router Definitions for Example IPv6 Topology, page 182 lists the router definitions based on the example topology shown in Figure 30 - Example LinkProof IPv6 Topology, page 181 and Table 88 - LinkProof Interface Definitions for Example IPv6 Topology, page 182.
Table 88: LinkProof Interface Definitions for Example IPv6 Topology

Role IP Address Prefix Length 59 55 IF VLAN Status Tag 0 0 0 Peer IP Preferred Address Lifetime and Valid Lifetime Infinite Infinite Infinite
ISP B ISP A Internal LAN
2030:1020:2000:a0::1001 2030:2020:1000:200::1001
G-11 G-5 G-2
Preferred :: Preferred :: Preferred ::
fc00:1002:fc01:3000:2000::1001 59
Table 89: Router Definitions for Example IPv6 Topology

Router Name ISP A ISP B IP Address 2030:2020:1000:200::1000 2030:1020:2000:a0::1000 OperStatus Active Active Weight 1 1 Farm Name IPv6Routers IPv6Routers
Figure 31 - Configuration of Example Static Prefix-NAT Entry in WBM, page 182 and Figure 32 Example Static Prefix-NAT Table in WBM, page 182 show the following Static Prefix-NAT configuration in Web Based Management: The entire /59 ULA will be replaced when accessing the IPv6 Internet using ISP A. The range of ULA starting from ::1001 ending with 2001 will be replaced with the prefix of ISP B when accessing the IPv6 Internet.
Figure 31: Configuration of Example Static Prefix-NAT Entry in WBM
Figure 32: Example Static Prefix-NAT Table in WBM
IPv6 Prefix-NAT Calculator

LinkProof provides the IPv6 Prefix-NAT Calculator to predict the outcome of an internal IPv6 address (that is, a ULA), passing through the LinkProof device and being translated to a GUA. The calculator is needed to calculate the external router IPv6 address-especially when the internal prefix is different from the external router prefix. Using the IPv6 Prefix-NAT calculator is extremely important when working with predefined IPv6 addresses (such as external VRRP addresses).
Note: Although Radware recommends adopting the IPv6 ULA concept as detailed in the RFC, the IPv6 Prefix-NAT calculator also supports internal public IPv6 address of the 2000::/3 (Global Unicast range).
182
LinkProof User Guide Basic Application Switching There can be two cases where the prefix of the internal address is translated to the prefix of the external IPv6 address. Case 1The internal prefix is identical to the external-router prefix. It is simple to understand and manually calculate the result IP address (that is, the public IPv6 address) that will be seen by the Internet as the source of the internal packet. The replacement happens on each IPv6 source address passing through the LinkProof device that the IPv6 Prefix-NAT policy identifies. Case 2The internal prefix is different from the external-router prefix. Here, calculating the result IP address (that is, the public IPv6 address) is complex; it involves several mathematical calculations. The IPv6 Prefix-NAT calculator can do the calculation for you.
The IPv6 Prefix-NAT calculator works only in CLI. Syntax: lp smartnat ipv6nat calc <LocalIPv6Addr> <RouterIPv6InternalAddr> <RouterIPv6Prefix> where: <LocalIPv6Addr> is the local IPv6 address. <RouterIPv6InternalAddr> is the router IPv6 internal address. <RouterIPv6Prefix> is the router IPv6 prefix.
Example lp smartnat ipv6nat calc fc00:1002:fc01:3000:2000::1001 2030:2020:1000:200::1000 55

Result:
The nat address is: 2030:2020:1000:200:2000::1001
Configuring the Prefix-NAT Parameters Summary

The Prefix-NAT Parameters Summary pane includes the parameter Block ULA Address on Edge Router. By default, the option is enabled (according to the recommendation in RFC 4193). When the option is enabled, the device blocks ULAs from crossing the border of the LinkProof device.
To configure a Static Prefix-NAT entry 1. Select LinkProof > Smart NAT > IPv6 Prefix-NAT > Prefix-NAT Parameters Summary. 2. From the Block ULA Address on Edge Router drop-down list, choose one of the following: EnableThe device blocks ULAs from crossing the border of the LinkProof device. DisableThe device does not block ULAs from crossing the border of the LinkProof device.
3. Click Set.
183
Configuring Static Prefix-NAT Table Entries

The Static Prefix-NAT Table pane contains the configurations of the Static Prefix-NAT entries. Each entry specifies how one ULA is translated in the IPv6 public Internet.
To configure a Static Prefix-NAT entry 1. 2. Select LinkProof > Smart NAT > IPv6 Prefix-NAT > Static Prefix-NAT Table. Do one of the following: 3. To create a new entry, click Create. To modify an entry, click the relevant link.
Configure the parameters; and then, click Set.
Table 90: Static Prefix-NAT Table Parameters
Parameter
From Local IP
Description
(Mandatory) The first IP address in the internal network that uses Prefix-NAT. When a value for To Local IP is specified, this value must be the first IP address in the internal network that uses Prefix-NAT. When a value for Range Defined by Prefix is specified, this value can be the first IP address in the internal network that uses Prefix-NAT. (Optional. Mutually exclusive with Range Defined by Prefix.) The last IP address in the range. When a value is specified for this parameter, the device translates the addresses in the specified range (From Local IPTo Local IP). When no value is specified for this parameter, the device translates all the addresses starting from the specified value for From Local IP. The IPv6 routers for the Prefix-NAT entry. Values: The IPv6 routers that are defined in the routers definition as having an IPv6 address. This includes all IPv6 routers from all farms. IPv4-only routers are not exposed in the drop-down list.
To Local IP
Server Name
Range Defined by Prefix
(Optional. Mutually exclusive with To Local IP.) When specified, the network is defined according to the value for the From Local IP parameter and the network prefix. This enables LinkProof to translate all the IPv6 addresses on the local interface. The value can be less than or equal to the value of the actual prefix of the router. So, for example, if the router is defined with prefix /55 and the internal network is defined with prefix /55, the administrator can configure any value between /55 and /128 (single address).
Replaced With Prefix
(Read-only) The Global Unicast Prefix associated with the router with which the LinkProof device will replace the ULAs prefix. LinkProof calculates the value according to the router specified in the Server Name field and the IPv6 address of the external LinkProof interface. Specifies whether the prefix represents a main (regular) or backup device. Values: regular, backup Default: regular
Redundancy Mode
184
Proximity
This section describes LinkProofs ability to detect network proximity and contains the following: Proximity Introduction, page 185 Proximity Configuration, page 186
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. 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 >> Proximity works only for router farms, not firewall farms. >> 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.
185
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. 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.
186
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. 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.
187
Table 91: 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 companys 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.
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 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 the servers or routers that were defined as backup in the grouping tables. This determines whether there is proximity data for a specific destination via this the server or router. 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
188
Setting Proximity Check Parameters
To configure Proximity Checks 1. Select LinkProof > Proximity > Proximity Parameters > Proximity Checks. The Proximity Checks pane is displayed. 2. Configure the parameters; and then, click Set.
Table 92: 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.
Server Side Proximity Status
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.
189
Table 92: Proximity Check Parameters
Parameter
Client Side Proximity Status
Description
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 doesnt respond to the first check. Defines the time interval in seconds between consecutive retries.
Check Interval
Setting Static Proximity
To configure Static Proximity 1. 2. 3. Select LinkProof > Proximity > Static Proximity. The Static Proximity Table pane is displayed. Click Create. The Static Proximity Table Create pane is displayed. Configure the parameters; and then, click Set.
Table 93: 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.
190
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 191 Mapping URLs to Local IP Addresses, page 191 DNS Response Parameters, page 193 DNS for Local Users, page 194 DNS Redundancy, page 196
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.
191
Configuring Host-to-Local-IP Mapping
To configure host-to-local-IP mapping 1. 2. 3. Select LinkProof > DNS Configuration > Name to Local IP. The Name To Local IP DNS Table pane is displayed. Click Create. The Name To Local IP DNS Table Create pane is displayed. Configure the parameters; and then, click Set.
Table 94: 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 Local IPv6 Address The IPv6 address of the local host.
Configuring Dynamic-Host-to-Local-IP Mapping
To configure dynamic-host-to-local-IP mapping 1. 2. 3. Select LinkProof > DNS Configuration > Dynamic Host Name to Local IP. The Dynamic Host Name to Local IP DNS Table pane is displayed. Click Create. The Dynamic Host Name to Local IP DNS Table Create pane is displayed. Configure the parameters; and then, click Set.
Table 95: Dynamic-Host-to-Local-IP Mapping Parameters
Parameter
Dynamic Host Name Local IP Address Index Farm Name
Description
The URL with wildcards to be mapped. The IPv4 address of the local host. The index number of this dynamic host name entry. The farm name in which the router with the Static NAT or Static PAT IP address resides. Optional. Default: None
192
Table 95: Dynamic-Host-to-Local-IP Mapping Parameters
Parameter
Backup In DNS Response
Description
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
Local IPv6 Address
The IPv6 address of the local host.
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. Select LinkProof > DNS Configuration > Response. The DNS Response Parameters pane is displayed. 2. Configure the parameters; and then, click Set.
Table 96: 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
193
Table 96: DNS Response Parameters
Parameter
URL to IP Search Mode
Description
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).
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.
194
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.
195
Configuring a DNS for Local Clients
To configure the location of the DNS for local clients 1. 2. Select LinkProof > DNS Configuration > DNS for Local Clients. The DNS for Local Clients Parameters pane is displayed. 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. 2. 3. 4. Select LinkProof > DNS Configuration > DNS for Local Clients. The DNS for Local Clients Parameters pane is displayed. Click Create. The DNS Servers Table Create pane is displayed. In the DNS IP Address text box, type the IP address for the DNS server. 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. You cannot specify the same IP address for the VDNS IP address and a physical interface.
Caution: The order of configuring virtual DNS is critical. First, you must configure the VDNS; and then, you associate an IP address with it.
196
To configure DNS redundancy 1. Select LinkProof > DNS Configuration > DNS Virtual IP. The DNS Virtual IP pane is displayed. 2. Click Create. The DNS Virtual IP Create pane is displayed. 3. Configure the parameters; and then, click Set.
Table 97: 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 198 Simple Router Load Balancing Configuration With VLAN, page 199 Simple One-Leg (Lollipop) Configuration, page 200 Sandwich Configuration, page 201 Single Device Installation, page 202
197
Simple Router Load Balancing Configuration

The following diagram shows a configuration of simple router load balancing.
Figure 33: 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
198
Simple Router Load Balancing Configuration With VLAN

The following diagram shows a configuration of simple router load balancing in a VLAN environment.
Figure 34: 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
199
Simple One-Leg (Lollipop) Configuration

The following diagram illustrates a simple configuration that does not require changing the network configuration.
Figure 35: 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
200
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 36: 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
201
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 37: 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
202
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. Select LinkProof > Load Balancing Weights. The Load Balancing Weights pane is displayed. 2. Configure the parameters; and then, click Set.
Table 98: 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 203 Default Flow, page 204 Configuring Flow Management, page 204 Flow Policies, page 205 Typical Flow Configurations, page 208
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.
203
Figure 38: 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, traffic is just forwarded to this default gateway without any load balancing.
Configuring Flow Management
To configure flow management 1. 2. 3. 4. Select LinkProof > Flow Management > Farms Flow Table. The Farms Flow Table pane is displayed. Click Create. The Farms Flow Table Create pane is displayed. Configure the parameters; and then, click Set. To configure flow policies, click Modify Policies, and then, see the procedure in Configuring Flow Policies, page 206.
Table 99: 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.
204
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 325. ApplicationUsing the Service elements it is possible to define a required application according to application port and/or additional data (see Bandwidth Management, page 325). 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. In addition to the Service classes, you can use Discrete Networks. For more information, see Discrete Networks, page 359. 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.
Table 100: Classification by Layer 3 or Layer 4 Policy per Traffic Direction
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.
205
Configuring Flow Policies
Note: If LinkProof handles FTP traffic, the FTP control and FTP data traffic need to use the same IP address.
To configure a flow policy 1. 2. 3. Select LinkProof > Flow Management > Modify Policies. The Flow Management Modify Policies pane is displayed. Click Create. The Flow Management Modify Policies Create pane is displayed. Configure the parameters; and then, click Set.
Table 101: Flow Management Policies Parameters
Parameter
Name Index Destination Source Direction Description Service Type
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
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, 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
The farm flow to which the policy is assigned.
206
Table 101: Flow Management Policies Parameters
Parameter
Inbound Physical Port Group
Description
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
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. Select LinkProof > Flow Management > View Active Policies. The Flow Management View Active Policies pane is displayed. 2. Select the policy. The Flow Management View Active Policies pane is displayed.
Table 102: Flow Management View Active Policies Parameters
Parameter
Name Index Destination Source Direction Description
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.
207
Table 102: Flow Management View Active Policies Parameters
Parameter
Service Type Service Farm Flow Inbound Physical Port Group
Description
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
Updating Flow Management Policies
To activate the latest changes 1. 2. Select LinkProof > Flow Management > Update Policies. The Activate Latest Changes pane is displayed. 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).
208
Figure 39: 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
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 209 Managing Client Tables, page 212 Client-Table Logging, page 217 Viewing Client Table Entries Using CLI, page 224 Filtered Client Table, page 226 Clearing the Client Table Manually, page 226
Client Table Mechanism

When a client first approaches the device, LinkProof checks whether an entry for that client already exists in the Client Table.
209
LinkProof User Guide Basic Application Switching 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.
Example
The following two tables illustrate Client Table examples of an HTTP outbound session for the network shown in the figure below.
Table 103: 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 104: 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
210
Figure 40: 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
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
211
LinkProof User Guide Basic Application Switching TypeA 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. 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 212 Client Table Modes, page 214 Remove Entry at Session End, page 215 Client Table Tuning, page 216 Aging by Application, page 216
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.
212
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 105: 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 214 Half Layer 4For more information on this option, see Half Layer 4 Client Table Mode, page 214 Full Layer 4For more information on this option, see Full Layer 4 Client Table Mode, page 215 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
Session Limit per Hash Entry
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
213
Table 105: Client Table Global Parameters
Parameter
Remove Alternative Server Clients in Hashing
Description
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
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 214 Half Layer 4 Client Table Mode, page 214 Full Layer 4 Client Table Mode, page 215
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
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.
214
LinkProof User Guide Basic Application Switching 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.
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.
215
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. The following table describes the various Client Table Modes and the hashing.
Table 106: 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 70.
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.
216
LinkProof User Guide Basic Application Switching 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.
Table 107: 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.
217
LinkProof User Guide Basic Application Switching The mechanism names temporary files <yyyyMMdd>_<hhmm>_<ss>_tmp.txt for example, 20081207_1713_54_tmp.txt. 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 108: 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.
218
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
219
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 109: 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
220
Table 109: 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. Select Services > Hard Disk. The Hard Disk Logging Management pane is displayed. 2. Configure the parameters; and then, click Set.
221
Table 110: 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
(Read-only) The size, in megabytes, of the hard disk. (Read-only) The size, in megabytes, of the free space on the hard disk. 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
222
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. Select Reporting > Clients > Parameters. The Reporting Clients Parameters pane is displayed. 2. 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.
223
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: 2. 3. Index Source IP From Destination IP From Destination Port From Status
Click Create. The View Filters Create pane is displayed. Configure the parameters; and then, click Set.
224
Table 111: 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
225
Table 111: 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 Select LinkProof > Clients > Filtered Client Table. The Filtered Client Table pane is displayed. The table comprises the following columns: Source AddressThe IP address of the source. Client AddressThe IP address of the client. Destination AddressThe IP address of the destination. Source PortThe source port of the client. Destination PortThe 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. 2. 3. Select LinkProof > Clients > Clear Client Table. The Clear Client Table pane is displayed. From the Clear Client Table drop-down list, select Clear. Click Set.
226
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 227 Multicast Dispatch, page 229 Clear Client Table (VPN Load Balancing Feature), page 229 Client Table Overwrite, page 231
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 41: Firewall Sandwich Topology
227
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. 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 42: 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.
228
Multicast Dispatch
This feature is supported only for IPv4 addresses.
Note: The OnDemand Switch VL platform does not support the Multicast Dispatch Method. When the network session starts from the headquarters to the branch, as shown in Figure 42 - VPN Alternative Traffic Paths, page 228, a VPN session is open along the red path. 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 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.
229
Figure 43: Clear Client Table Scenarios

Headquarters network
L3 switch/router
LinkProof 1
LinkProof 2
L2 Switch 1
L2 Switch 2
VPN Gateway 1
VPN Gateway 2
L2 Switch 3
L2 Switch 4
LinkProof 3
LinkProof 4 L2 Switch 2 L3 switch/router
Branch A
Branch B
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.
230
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, see LinkProof Farms, page 138.
Client Table Overwrite

This feature assists in dealing with the problems associated with Clear Client TableScenario 1, page 230. 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.
231
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. 2. 3. Select LinkProof > Global Configuration > Client Table > General > Server Selection Override. From the Server Selection Override drop-down list, select either disable (default) or enable. Click Set.
232
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 233 Tunneling, page 243 Cost-based Load Balancing, page 246 Event Scheduler, page 247 Miscellaneous ParametersTweaks, page 248 Performance Statistics, page 250 Statistics Monitor SRP Management Host IP Address, page 259 Configuration Auditing, page 260 NTP Service, page 261 RADIUS Service, page 262
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 233 Layer 7 Policies, page 237 Content Rules, page 239 Hostname Lists, page 242
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 233 Alias Ports, page 236
Delayed Binding
To make a load balancing decision based on HTTP content (Layer 7 decision), LinkProof implements a mechanism referred to as Delayed Binding.
233
LinkProof User Guide Advanced Features 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 112: Delayed Binding Global Parameters
Parameter
Search Depth (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.
234
LinkProof User Guide Advanced Features
Parameter
HTTP Persistency
Description
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
Number of TCP Retransmissions
The number of times the LinkProof device retransmits unanswered TCP requests. Values: 010 Default: 3
POST Classification Input
The part of the POST request where the device does the classification. Values: HeaderThe device accumulates and searches only the header. Header and BodyThe device accumulates both body and header and searches both. Default: Header
Retransmission Interval(sec)
The time, in seconds, between retransmissions of client requests. Values: 010 Default: 1
235
Parameter
Automatic Mode
Description
Specifies whether the device uses the Automatic Mode to conserve resources while under stress. Values: enableIf the LinkProof CPU utilization reaches 95%, the Automatic Mode mechanism doubles the retransmission interval (to the reduce strain on the resources). If CPU utilization reaches 98%, the Automatic Mode mechanism disables the retransmission mechanism until CPU utilization falls below 98% (using the doubled retransmission interval). disableThe device does not use the Automatic Mode. Default: enable
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. 2. 3. Select LinkProof > Global Configuration > Alias Ports. The Alias Ports pane is displayed. Click Create. The Alias Ports Table Create pane is displayed. Configure the parameters; and then, click Set.
Table 113: 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)
236
To update an existing Alias Port 1. Select LinkProof > Global Configuration > Alias Ports. The Alias Ports pane is displayed. 2. Click on the relevant alias port from the table. The Alias Ports Table Update pane is displayed. 3. Edit the value of the Well Known Port Number as required. 4. Click Set.
Layer 7 Policies
A single Content Rule (see Content Rules, page 239) can include one or more Layer 7 Policies (also referred to L7 Policies) 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. In LinkProof, the parameters such as URL, Cookie Type, and so on, are configured within the filters (for example, basic filters, AND filters, and so on) via the classes.
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. 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.
237
To configure a new Layer 7 policy 1. 2. 3. Select LinkProof > Content LB Parameters > L7 Policies Table. The L7 Policies Table pane is displayed. Click Create. The L7 Policies Table Create pane is displayed. Configure the parameters; and then, click Set.
Table 114: 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.
Service Type
Values: None Basic Filter AND Group OR Group Default: None
238
Table 114: L7 Policy Parameters
Parameter
Service Hostname List
Description
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 242) 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 115: 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
239
LinkProof User Guide Advanced Features Delayed Binding (see Delayed Binding, page 233). 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 240 Content Rule Configuration Examples, page 242
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. 2. 3. Select LinkProof > Content LB Parameters > Content Rules Table. The Content Rules Table pane is displayed. Click Create. The Content Rules Table Create pane is displayed. Configure the parameters; and then, click Set.
Table 116: 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
240
To modify a Content Rule 1. Select LinkProof > Content LB Parameters > Content Rules Table. The Content Rules Table pane is displayed. 2. 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. 3. Configure the parameters; and then, click Set.
Table 117: 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
241
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 44: 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.
242
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. Select LinkProof > Content LB Parameters > Hostname > Hostname Lists Table. The Hostname Lists Table pane is displayed. 2. Click Create. The Hostname Lists Table Create pane is displayed. 3. Configure the parameters; and then, click Set.
Table 118: 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 244 Generic Routing Encapsulation (GRE), page 244 GPRS Tunneling Protocol (GTP), page 245 Multiprotocol Label Switching (MPLS), page 245
243
LinkProof User Guide Advanced Features If a LinkProof device is positioned between two tunneled 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. You can apply bandwidth management (BWM) and flow-management policies 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. 2. 3. Select Device > Tunneling. The Tunneling Parameters pane is displayed. From the Tunneling Parameters drop-down list, select Enabled. 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 45: Tunnel ID and Session ID in Packet Encapsulated Using L2TP
An example of L2TP packet looks as follows:
Table 119: 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.
244
Figure 46: 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 47: 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 48: 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.
245
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. 2. 3. Select LinkProof > Cost > Cost Global Parameters. The Cost Global Parameters pane is displayed. From the Cost Admin Status drop-down list, select Enabled. 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. 2. 3. Select LinkProof > Cost > NHR Cost Table. The NHR Cost Table pane is displayed. Click Create. The NHR Cost Table Create pane is displayed. Configure the parameters; and then, click Set.
246
Table 120: 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.
247
To configure an 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 121: 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. 2. Select LinkProof > Global Configuration > Tweaks. The Global Configuration - Tweaks pane is displayed. Configure the parameters; and then, click Set.
248
Table 122: 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 FTP Control Port ToS Type
The FTP data port number. The FTP control port number. The IP header that the ToS marking is applied to. Values: tos, precedence, disable Default: disable
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
249
Performance Statistics
This section describes the performance statistics that LinkProof supports. This section includes the following: BWM Policy Statistics, page 250 Element Statistics, page 253 IP Interface Statistics, page 257 NHR Statistics, page 257
BWM Policy Statistics

This section includes the following: BWM Policy StatisticsGlobal Parameters, page 250 BWM Policy StatisticsLast Second and Last Period, page 250
BWM Policy StatisticsGlobal Parameters
To configure Policy Statistics global parameters 1. 2. Select Performance > BWM Policy Statistics > Global Parameters. The Policy Statistics Global Parameters pane is displayed. Configure the parameters; and then, click Set.
Table 123: 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 StatisticsLast Second and Last Period

You can view statistics for the bandwidth-management policies. This section includes the following: BWM Policy StatisticsLast-Second Statistics, page 251 BWM Policy StatisticsLast Period Statistics, page 252
250
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: 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 124: 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.
251
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: 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 125: 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.
252
Table 125: 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 253 SNMP Element Statistics, page 254 IP Router Element Statistics, page 255 OSPF Element Statistics, page 256 Resource Utilization Element Statistics, page 256 Accelerator Element Statistics, page 256
IP Packet Element Statistics
To view IP packet element statistics Select Performance > Element Statistics > IP. The IP Packet Statistics pane is displayed.
Table 126: 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).
253
SNMP Element Statistics
To view SNMP packet element statistics Select Performance > Element Statistics > SNMP. The SNMP Packet Statistics pane is displayed.
Table 127: 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
254
IP Router Element Statistics
To view IP router element statistics Select Performance > Element Statistics > IP Router. The Ip Router Statistics pane is displayed.
Table 128: 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.
255
Table 128: 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 129: 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 130: 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.
256
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 131: 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.
257
Table 132: 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: 2. Policy Name Packets Matched BW (Kbits) Sent BW (Kbits)
To view additional statistics for a server on a day, from the Month column, select the relevant link.
Table 133: 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 246.
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.
258
Table 134: 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 135: 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.
259
To specify the IP address of the SRP management host 1. 2. Select Services > Statistics Monitor > SRP. The SRP Management Host IP Address pane is displayed. 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. Click Set.
3.
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.
260
To enable configuration auditing using Web Based Management 1. Select Services > Auditing. The Auditing Status pane is displayed. 2. Select enable. 3. Click Set.
To disable configuration auditing using Web Based Management 1. Select Services > Auditing. The Auditing Status pane is displayed. 2. Select disable. 3. 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. Select Services > Time Settings > NTP. The Network Time Protocol pane is displayed. 2. Configure the parameters; and then, click Set.
261
Table 136: Network Time Protocol Parameters
Parameter
NTP Server 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. 2. Select Services > RADIUS. The RADIUS Parameters pane is displayed. Configure the parameters; and then, click Set.
Table 137: 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.
262
Table 137: 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
263
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 VRRP Redundancy, page 272 Remote Virtual IP Addresses, page 294
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 268 Mirroring the Client Table, page 270
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 LinkProof device can always recognize whether the paired LinkProof device is up or down. In LinkProof, physical IP addresses are configured to poll other LinkProof physical IP addresses. In Figure 49 - 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 49 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 Virtual Router Redundancy Protocol (VRRP). VRRP 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.
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.
265
LinkProof User Guide Redundancy
Figure 49: 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.
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.
266
LinkProof User Guide Redundancy Copying a device configuration in a redundant environment involves the following: Specifying the Peer Address for the same interface on the backup device for each IP interface that you configured on the device (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.
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 138: Global Redundancy Configuration Parameters
Parameter
IP Redundancy Admin Status
Description
Allows this device to function as part of a backup configuration. Values: Disable, VRRP Default: Disable Note: You must select VRRP to enable mirroring. For more information, see Mirroring the Client Table, page 270.
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 268.
ARP with Interface Grouping
Specifies whether the device can send ARP requests with the active interface grouping. Values: Send, Avoid Default: Send
Backup-In-Vlan
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.
267
Table 138: Global Redundancy Configuration Parameters
Parameter
Backup Interface Grouping
Description
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
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. 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. >> 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.
Master 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.
268
LinkProof User Guide Redundancy 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. When working with IPv6 interfaces in LinkProof, by default, every interface has an IP address (a link-local address). Thus, all of the interfaces affect the configuration. If you want a failed interface not to affect VRRP fail-over, you must exclude manually it from the Interface grouping.
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
(Read-only) The port number. Specifies whether to include or exclude the port in interface grouping.
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 or Excluded. 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.
269
To enable interface grouping and backup interface grouping 1. 2. Select Redundancy > Global Configuration. The Global Redundancy Configuration pane is displayed. 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. 4. 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. 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 >> 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.
270
LinkProof User Guide Redundancy 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 293.
Caution: Mirroring works differently depending on the specified Priority and Preemption Mode of the VRRP redundancy configuration (see Configuring Basic VRRP Redundancy, page 291). 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 139: 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
Table 140: 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
271
Configuring Mirroring on the Active Device
To configure the active-device mirroring parameters 1. 2. Select Redundancy > Mirroring > Active Device Parameters. The Mirroring: Active Device Parameters pane is displayed. Configure the parameter; and then, click Set.
Table 141: Active-Device Mirroring Parameter
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. 2. 3. Select Redundancy > Mirroring > Backup Device Parameters. The Mirroring: Backup Device Parameters pane is displayed. From the Mirroring Status drop-down list, specify whether to enable or disable mirroring of the Client Table. Values: enable, disable. Default: disable. Click Set.
Configuring the IP Address of the Mirrored Device
To configure the IP address of the mirrored device 1. 2. 3. Select Redundancy > Mirroring > Mirror Device Parameters. The Mirroring: Device Parameters pane is displayed. Click Create. The Mirror Device Parameters Create pane is displayed. 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.
VRRP Redundancy
This section describes redundancy in LinkProof using Virtual Router Redundancy Protocol (VRRP). This section contains the following topics: Introducing VRRP, page 273 Direct Server Connection with VRRP, page 279
272
LinkProof User Guide Redundancy VRRP with IPv6 Prefix NAT, page 281 Configuring Basic VRRP Redundancy, page 291 VRRP Associated IP Addresses, page 293
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. A VR has a Virtual Router Identifier (VR ID) and one or more IP addresses associated with it (that is, 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 address to refer to the IP address associated with the interface index and the VR ID. Other vendors may refer to the associated IP address as a virtual IP (VIP) or a floating IP, because it floats between the primary and standby devicesbeing 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 279. >> 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 268) 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.
273
LinkProof User Guide Redundancy >> 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. Figure 50 - Redundant LinkProof Configuration with VRRPVR IP Address Uses the IP Address of One of the Physical Interfaces of the Primary Device, page 275 shows the example configuration. Figure 51 - Configuration of Redundant LinkProof Devices with VRRPVR IP Address Uses the IP Address of One of the Physical Interfaces of the Primary Device, page 276 describes the flow of the configuration procedure.
274
Figure 50: 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
275
Figure 51: 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 to 255
No Set VR priority less than 255 (for example, 100)
Create Associated IP address for VR
Change VR State to 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
276
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 52 - Redundant LinkProof Configuration with VRRPVR IP Address Uses an IP Address Different from the Physical Interfaces of the Primary Device, page 277 shows the example configuration. Figure 53 - Configuration of Redundant LinkProof Devices with VRRPVR IP Address Uses an IP Address Different from the Physical Interfaces of the Primary Device, page 278 describes the flow of the configuration procedure.
Figure 52: 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
277
Figure 53: 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
Yes
No Set VR priority less than 200 (for example, 100)
Create Associated IP address for VR
Change VR State to Up
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
278
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 54 - Direct Server Connection with VRRP and Routing, page 280) or bridging (see Figure 55 - Redundant LinkProof Configuration with VRRP and Direct Connection, page 281) 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 54 - Direct Server Connection with VRRP and Routing, page 280 and Figure 55 - Redundant LinkProof Configuration with VRRP and Direct Connection, page 281 are as follows: Direct Server Connection with Routing is supported with VRRP and Switched IP VLAN only. sServersCIDCondDel4CIDMM 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.
279
Figure 54: 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 55 - Redundant LinkProof Configuration with VRRP and Direct Connection, page 281, 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 55 - Redundant LinkProof Configuration with VRRP and Direct Connection, page 281 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.
280
Figure 55: 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
VRRP with IPv6 Prefix NAT

This section describes VRRP configuration with IPv6 Prefix-NAT.
Ensuring Proper Connectivity

When creating an IPv6-Prefix-NAT configuration, it is critical that you make sure not to overlap the IPv6 addresses used by the routers for their internal IPv6 interfaces. If there is overlap, the LinkProof device will lose connectivity to the external router.
Figure 56: Example Valid IPv6 Topology

External Router 02
Internal address of router is 2040:2100::2222/48
External Segment 02
External address of LinkProof device is 2040:2100::2001/48

Link Proof
1000 10/100
G1
G3
G5
G7
G9
G1 1
1 000 1 0/100 P WR
MNG 1 P WR FAN SY S O K
G13
G1 4
G1 5
G16
G2
G4
G6
G8
G 10
G1 2
RS T
US B
MNG 2
CON SO L E
Internal address of LinkProof device is FC00:1000::FFF1/64

To configure proper connectivity for IPv6, you must define a proper IPv6 Prefix-NAT range. Defining a full IPv6 Prefix-NAT range of 2040:2100::/48 will cause an IPv6 address overlap thus causing network connectivity failure.
281
LinkProof User Guide Redundancy Defining an IPv6 Prefix-NAT range such as in Improper Configuration 1Full IPv6 Prefix-NAT Range Causes Address Overlap, page 282 and Improper Configuration 2Full IPv6 Prefix-NAT Range Causes Address Overlap, page 282 is improper (LinkProof > Smart NAT > IPv6 Prefix-NAT > Static Prefix-NAT Table). The configurations result in address overlap. That is, LinkProof can translate a packet with address fc00:1000::2222 as 2040:2100::2222, causing the internal router address to be overlapped by the LinkProof device.
Table 142: Improper Configuration 1Full IPv6 Prefix-NAT Range Causes Address Overlap
Parameter
From Local IP To Local IP Server Name Range Defined by Prefix Replaced With Prefix Redundancy Mode
Value
fc00:1000::1 fc00:1000::ffff IPv6Routers/ISP02 Blank 2040:2100::/48 regular
Table 143: Improper Configuration 2Full IPv6 Prefix-NAT Range Causes Address Overlap
Parameter
Value
fc00:1000::1 Blank IPv6Routers/ISP02 /64 2040:2100::/48 regular
To prevent overlapping addresses, you must insert spaces in the IPv6 range for Prefix-NAT to use, excluding the external router IPv6 address and eliminating any overlap.
Table 144: Proper ConfigurationSeparated IPv6 Prefix-NAT Ranges Prevent Address Overlap
Parameter
ValueRow 1
fc00:1000::2000 fc00:1000::2220 IPv6Routers/ISP02 Blank N/A regular
ValueRow 2
fc00:1000::1 Blank IPv6Routers/ISP02 Blank N/A regular
IPv6 Prefix-NAT Address Range

In VRRP with SmartNAT, you explicitly configure each IPv4 address used for (Static NAT, Dynamic NAT, or Basic NAT). In VRRP with IPv6 Prefix-NAT due to the massive number of potential IPv6 address used for Prefix-NAT, you cannot explicitly configure the address. You configure a single IPv6 Prefix-NAT address from the IPv6 Prefix-NAT ranges in the VRRP Associated IP Addresses table. The device looks up the configured IPv6 Prefix-NAT address and creates a special associated VR IPv6 entry that includes the entire IPv6 Prefix-NAT range.
282
VRRP Associated IP Addresses

When a VR ID that supports IPV6 is configured on the device, LinkProof creates an associated IP address for the Primary IP parameter. The entry is created with a link-local address derived from VR MAC. This is part of IPv6 RFC and does not affect regular device functionality.
VRRP Configuration Steps
Caution: In IPv4, the order in which you configure VRRP in LinkProof does not matter. In IPv6, the order in which you configure VRRP in LinkProof is crucial. You can, however, modify the Prefix-NAT configuration. The reason why the order is crucial is that the IPv6 Prefix-NAT ranges define the VR associated IP address that will be used in the IPv6 neighbor solicitation process, which enables the LinkProof device to announce the relevant IPv6 addresses that the VR holds and responds to. VRRP configuration involves the following steps: 1. Configuring all the relevant interfaces, routing, and so on. 2. Configuring e the relevant VR and relevant IP address. 3. Deriving the IPv6 associated IP address from the IPv6 Prefix-NAT calculator. 4. Configuring the IPv6 Prefix-NAT addresses. 5. Configuring VR associated IPv6 ranges (using the calculator).
Note: For more information, see Configuration Flow ChartVRRP with IPv6 and IPv6 PrefixNAT, page 284.
Disabling VRRP
When you disable VRRP with IPv6 Prefix-NAT associated IP addresses (after disabling the VRRP configuration), you will have to clean the ARP table on the adjacent routers (connected directly to the device). This is done because IPv6 neighbor solicitation messages may still point to the VR MAC address.
Interface Grouping Considerations

Interface Grouping is disabled by default. When Interface Grouping is enabled, if any of the interfaces in the group fails, the entire device is declared down and VRRP failover occurs (master switches to backup). When you configure VRRP, make sure to enable Interface Grouping as required. By default, the Master Interface Grouping Table includes all the device interfaces except for management interfaces. When working with IPv6 interfaces in LinkProof, by default, every interface has an IP address (a link-local address). Thus, all of the interfaces affect the configuration. If you want a failed interface not to affect VRRP fail-over, you must exclude manually it from the interface grouping.
283
Configuration Flow ChartVRRP with IPv6 and IPv6 Prefix-NAT

Configure the following on each device: Interfaces IP Addresses Routing Farm and flows NAT
Enable VRRP
Create a VR and set State to Down
Yes
No Set VR priority < 200 (for example, 100)
Use the calculator to derive the VRRP IPv6 Associated IP
Yes
Using IPv6 Prefix-NAT?
No Create IPv6 Prefix-NAT addresses or ranges Create Associated IPv6 address if needed
Use the calculator to create Associated IPv6 address with IPv6 Address for VR Change VR State to Up
Yes
No
Need to ping the VR IP or have a VDNS?
Yes
Create a remote VIP or VDNS IP address to use
No If the VIP is in the IPv6 Prefix-NAT range, create Associated IP Addresses for the VIP or VDNS
Assign interfaces in the Master Interface Grouping table
Yes
Using Interface Grouping?
No
284
Example ConfigurationVRRP with IPv6 Prefix-NAT

Consider the scenario in following figure. For the sake of simplicity, the configuration uses the same segment for both routers, although in real-life scenarios, due to security considerations, the common practice would be to have a LinkProof device connected to each router via a different LinkProof port. In addition, the figure shows the external virtual router as a single entity, whereas in real life, it can be represented by several virtual routers with different VR IDs. This section will focus on a configuration of IPv6 routers and the IPv6 Prefix-NAT associated address. (The topology would be the same in the context of IPv6 Prefix-NAT and VRRP setup.)
Figure 57: VRRP with IPv6 Prefix-NAT Configuration Example
Internet
External Router, ISP01

2030:1000:2000::2222/64
External Router, ISP02

2040:2100::2222/48
2030:1000:2000::2002/64 2040:2100::2002/48 is used to access External Router 02
External Segment 01
External Segment 02
2040:2100::2001/48 2030:1000:2000::2001/64 is used to access External Router 01
Virtual Router 2030:1000:2000::2020/64 2040:2100::2020/48
LinkProof 01 Primary
FC00:1000::FFF2/64 is the IP address of the internal interface of the LinkProof device
Link Proof
1 000 1 0/100
G1
G3
G5
G7
G9
G1 1
1 00 0 1 0/ 100 PW R
MNG 1 P WR F AN SY S O K
Link Proof
1 0 00 1 0 /100
G1
G3
G5
G7
G9
G11
100 0 10/1 00 PWR
M NG 1 PW R FA N S YS O K
G1 3
G14
G1 5
G 16
G2
G4
G6
G8
G1 0
G1 2
RS T
US B
MNG 2
CO N SO LE
G1 3
G 14
G15
G 16
G2
G4
G6
G8
G10
G12
RS T
U SB
M NG 2
C O NS OL E
LinkProof 02 Secondary
FC00:1000::FFF1/64 is the IP address of the internal interface of the LinkProof device
Virtual Router FC00:1000::FFFE/64
Internal Segment FC00:1000::2000/64
Users
The scenario in the figure assumes the following: Both LinkProof devices are in VRRP setup providing failover for one another. LinkProof 01 Primary is the VRRP master. LinkProof 02 Secondary is the VRRP backup. Users on the internal LAN are coming from ULA address (FC00::/64) The administrator has connected the LinkProof to the following two routers: ISP01 with an IPv6 prefix of 2030:1000:2000::/64 ISP02 with an IPv6 prefix of 2040:2100::/48
Each LinkProof is connected to two routers (using an external segment).
285
Table 145: VRRP with IPv6 Prefix-NAT Configuration ExampleAddress Summary Device
Interfaces ISP01 ISP02 LinkProof 01 LinkProof 02 VRRP LinkProof external virtual router (VR ID 01) LinkProof internal virtual router (VR ID 02) LinkProof associated IP address (VR ID 01) LinkProof associated IP address (VR ID 02)
External Interface 01
IPv6 public IP address IPv6 public IP address
External Interface 02
N/A N/A
Internal Interface
2030:1000:2000:2222/64 2040:2100::2222/48 FC00:1000::FFF2/64 FC00:1000::FFF1/64 N/A
2030:1000:2000::2002/64 2040:2100::2002/48 2030:1000:2000::2001/64 2040:2100::2001/48 2030:1000:2000::2020/64 2040:2100::2020/48
N/A
N/A
FC00:1000::FFFF/64
N/A
N/A
FC00:1000::FFFE
2030:1000:2000::2000 through 2030:1000:2000::2220 2030:1000:2000::2223 through 2030:1000:2000::FFFF
2040:2100::2000 through 2040:2100::2220 2040:2100::2223 through 2040:2100::FFFF N/A
N/A
Prefix-NAT
LinkProof IPv6 Prefix-NAT (router 01)
FC00:1000::2000 through FC00:1000::2020 FC00:1000::2023 through FC00:1000::2FFF
N/A
LinkProof IPv6 Prefix-NAT (router 02)
N/A
FC00:1000::2000 through FC00:1000::2020 FC00:1000::2023 through FC00:1000::2FFF
N/A
Users point of entry (that is, the default gateway for the network)
FC00:1000::2000/64
N/A
N/A
As mentioned, the IPv6 associated IP addresses are derived from the IPv6 Prefix-NAT ranges. Therefore, only one IP address from each range needs to be defined in the Redundancy Associated IP Addresses table. This will inform the LinkProof device as to the associated IP address ranges for which it is responsible. In the example, an address from LinkProof external interface 01 can be 2030:1000:2000::2000, and an address from LinkProof external interface 02 can be 2040:2100::2000. Prior to the VRRP configuration, we assume all IPv6 interfaces are configured properly. That is, routing is configured properly (especially, the default route ::/0 to both external routers), and connectivity is working end to end.
To configure the VRRP with the IPv6 Prefix-NAT example configuration 1. Configure the virtual router VR ID 1 (internal interface). On the Master LinkProof Priority = 200 on the backup LinkProof Priority = 100 Redundancy > VRRP > Virtual Routers > Create
286
Table 146: VRRP and IPv6 Prefix-NAT Example ConfigurationVirtual Router Parameters
Parameter
IP Version VR ID If Index Admin Status Priority Primary IP Advertise Interval Preempt Mode
Value
IPv6 1 G-3 disabled 200 Blank 100 True
2. Configure the associated IP address for the internal interface. Redundancy > VRRP > Associated IP Addresses > Create
Table 147: VRRP and IPv6 Prefix-NAT Example ConfigurationAssociated IP Addresses Parameters
Parameter
IP Version VR ID If Index Associated IP
Description
IPv6 1 G-3 fc00:1000::fffe
3. Enable the internal virtual router VR ID 1, which you configured in step 1. 4. Repeat step 1 through step 3 for the backup device.
Note: Once enabled, the VR ID shows a Primary IP from the LLA (link-local address). This is regular IPv6 behavior according to RFC and IPv6 logo specifications. 5. Configure the external virtual router VR ID 2 (on the LinkProof external interface 02).
Table 148: VRRP and IPv6 Prefix-NAT Example ConfigurationVirtual Router Parameters
Parameter
IP Version VR ID If Index Admin Status Priority Primary IP Advertise Interval Preempt Mode
Value
IPv6 2 G-5 disabled 200 Blank 100 True
6. Create Prefix-NAT ranges for internal users accessing the Internet from the router ISP02. LinkProof >Smart NAT > IPv6 Prefix-NAT > Static Prefix-NAT Table > Create
287
Table 149: VRRP and IPv6 Prefix-NAT Example ConfigurationStatic Prefix-NAT Table ParametersFirst Range
Parameter
Value
fc00:1000::2000 fc00:1000::2220 IPv6Routers/ISP02 Blank 2040:2100::/48 regular
Table 150: VRRP and IPv6 Prefix-NAT Example ConfigurationStatic Prefix-NAT Table ParametersSecond Range
Parameter
From Local IP To Local IP Server Name Range Defined by Prefix Replaced With Prefix Redundancy Mode The result is:
Value
fc00:1000::2223 fc00:1000::ffff IPv6Routers/ISP02 Blank 2040:2100::/48 regular
Table 151: VRRP and IPv6 Prefix-NAT Example ConfigurationStatic Prefix-NAT Table Result
Parameter
ValueRow 1
fc00:1000::2000 fc00:1000::2220 IPv6Routers/ISP02 Blank N/A regular
ValueRow 2
fc00:1000::2223 fc00:1000::ffff IPv6Routers/ISP02 Blank N/A regular
From Local IP
fc00:1000::2000 fc00:1000::2223
To Local IP
fc00:1000::2220 fc00:1000::ffff
Range Defined Server Name by Prefix

Blank Blank IPv6Routers/ISP 02 IPv6Routers/ISP02
Redundancy Mode
regular regular
288
LinkProof User Guide Redundancy 7. Using the IPv6 Prefix-NAT calculator, derive the associated IP address of the external interface. From the CLI, run:
lp smartnat ipv6nat calc fc00:1000::2000 2040:1000::2000 48

which generates the following:
result The nat address is: 2040:1000::2000

8. Configure the associated IP address for the internal interface.
Note: Since here, the IPv6 Associated Addresses are derived from the Prefix-NAT, we only need to configure one address from the Prefix-NAT range. One address from the range (using the result of the prefix-NAT calculator from above) is:
Table 153: VRRP and IPv6 Prefix-NAT Example ConfigurationAssociated IP Addresses Parameters for Internal Interface
Parameter
IP Version VR ID If Index Associated IP The result is:
Description
IPv6 2 G-5 2040:2100::2000
Table 154: VRRP and IPv6 Prefix-NAT Example ConfigurationAssociated IP Addresses Update for Internal Interface
Parameter
IP Version VR ID If Index Associated IP From Address To Address
Description
IPv6 2 G-5 2040:2100::2000 2040:2100::2000 2040:2100::2220
The associated IP address range shows the range From AddressTo Address as configured by the IPv6 Prefix-NAT feature. 9. Configure the associated IP address for the second range.
Table 155: VRRP and IPv6 Prefix-NAT Example ConfigurationAssociated IP Addresses Parameters for Second Range
Parameter
IP Version VR ID If Index Associated IP
Description
IPv6 2 G-5 2040:2100::2223
289
LinkProof User Guide Redundancy The result is:
Table 156: VRRP and IPv6 Prefix-NAT Example ConfigurationAssociated IP Addresses Update for Second Range
Parameter
IP Version VR ID If Index Associated IP From Address To Address
Description
IPv6 2 G-5 2040:2100::2223 2040:2100::2223 2040:2100::ffff
10. Enable VR ID 2 as configured in step 5. 11. Repeat step 5 through step 9 for the backup device (with the exclusion of step 7, because as the result would be the same) but with the following exceptions: VRID Priority should be 100 for the backup device. Redundancy mode in the Static Prefix-NAT Table Create pane should be set to backup.
12. For the second router (LinkProof external interface 01), follow the exact same steps using the same VR ID (VR ID 2) or another VR ID number of your choice. 13. In the Static Prefix-NAT pane, for the router ISP01, the configuration (LinkProof > Smart NAT > IPv6 Prefix-NAT > Static Prefix-NAT Table > Create) should be configured as illustrated in the following two tables:
Table 157: VRRP and IPv6 Prefix-NAT Example ConfigurationStatic Prefix-NAT Table ParametersFirst Range
Parameter
Value
fc00:1000::2000 fc00:1000::2220 IPv6Routers/ISP01 Blank 2040:2100:2000:/48 regular
Table 158: VRRP and IPv6 Prefix-NAT Example ConfigurationStatic Prefix-NAT Table ParametersSecond Range
Parameter
Value
fc00:1000::2223 fc00:1000::ffff IPv6Routers/ISP01 Blank 2040:2100:2000:/64 regular
290
LinkProof User Guide Redundancy The result is:
From Local IP
fc00:1000::2000 fc00:1000::2000 fc00:1000::2223 fc00:1000::2223
To Local IP
fc00:1000::2220 fc00:1000::2220 fc00:1000::ffff fc00:1000::ffff
Range Defined Server Name by Prefix

Blank Blank Blank Blank IPv6Routers/ISP01 IPv6Routers/ISP02 IPv6Routers/ISP01 IPv6Routers/ISP02
Redundancy Mode
regular regular regular regular
14. Follow step 7 through step 9 for the external interface VR ID 1 settings using the exact same methodology. 15. Repeat the same steps for secondary (VRRP backup) LinkProof device. 16. Once both VR IDs are enabled, check connectivity and failover. IPv6 end-to-end connectivity should be working with IPv6 router load balancing according to LinkProof functionality.
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 270.
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 1. Select Redundancy > VRRP > Virtual Routers. The Virtual Router Table pane is displayed. 2. Click Create. The Virtual Router Table Create pane is displayed. 3. Configure the parameters; and then, click Set.
291
Table 160: Virtual Router Parameters
Parameter
IP Version
Description
The IP version. Values: IPv4, IPv6 Default: IPv4
VR ID
The identifier of the virtual router. Values: 1255 Default: 1
If Index
The interface identifier. Values: The traffic ports (not MNG ports) on the device 100001 Default: G-1
Admin Status
The status of the port. Values: enabled, disabled Default: disabled
Priority
Priority is defined with the values 1255, where the highest priority of 255 should be assigned to the primary VR. Values: 1255 Default: 100 Caution: If the Preemption Mode is False, you must not specify the value 255.
Primary IP
The primary IP address. The device adds a default value unless the you define one.
292
Table 160: Virtual Router Parameters
Parameter
Advertise Interval Preempt Mode
Description
The interval, in centiseconds, at which the device checks packets. Default: 100 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 Caution: If Preempt Mode is False, with a regular VLAN in the setup, to prevent loops on both devices, you must set the value of the Backup-In-Vlan parameter (see Global Redundancy Configuration, page 267) to Backup, on both devices. 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.
VRRP Associated IP Addresses

The associated IP address is the IP address associated with the interface index and the VR ID. An associated IP address is used in NAT configurations. Other vendors may refer to the associated IP address as a virtual IP (VIP) 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 161: Associated IP Addresses Parameters
Parameter
IP Version
Description
The IP version. Values: IPv4, IPv6 Default: IPv4
VR ID
The identification number of the virtual router. Values: 1255
293
Table 161: Associated IP Addresses Parameters
Parameter
If Index
Description
The interface identifier. Values: The traffic ports (not MNG ports) on the device 100001
Associated IP
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 address 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.
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.
294
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.
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. Select LinkProof > Remote Virtual IP Table. The Remote Virtual IP Table pane is displayed. 2. Click Create. The Remote Virtual IP Table Create pane is displayed. 3. Configure the parameters; and then, click Set.
Table 162: 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
295
296
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: ACL, page 297 Ports Access, page 304 Configuring Access for Physical Ports, page 304 SNMP, page 305 Ping Physical Ports, page 312 Configuring the Users Table and Authentication Method, page 312 SYN Flood Protection, page 313 Keys and Certificates, page 318
ACL
The Access Control List (ACL) module is a stateful firewall that enables you to configure a flexible and focused stateful access-control policy. You can modify and view the active ACL policy. You can also view ACL report summaries and the ACL log analysis. ACL in LinkProof does not work on the physical management ports (MNG 1 and MNG 2). To operate correctly, ACL needs to determine the direction of session packets. ACL determines packet direction as follows: TCP directionAccording to the first SYN packet that creates a session. UDP directionAccording to the first packet in the flow. ICMP directionAccording to the ICMP message type (that is, reply or request type). Non-TCP, Non-UDP and Non-ICMP session directionAccording to the first L3 (IP) packet in the flow. Non-IP directionAccording to the first packet in the flow.
When ACL is enabled and activated, the device learns about the existing sessions for a specified amount of time (by default, 10 minutes). During this learning period, the device accepts all sessions regardless of any unknown direction. However, for the certain cases, ACL treats the session according to the configured policies. ACL treats the session according to the configured policies in the following cases: A new TCP session starts with a SYN packet. A new ICMP session starts with a request packet.
Configuring the ACL feature involves the following steps: 1. 2. Configuring ACL Global Parameters, page 298. Configuring ACL Policy Rules, page 300.
Note: Enabling an ACL policy requires a device reboot.
297
LinkProof User Guide Security
Configuring ACL Global Parameters

You must enable the ACL feature before you can configure an ACL policy.
Note: Enabling ACL requires a device reboot.
To configure ACL global ACL parameters 1. 2. Select Security > ACL > Global Settings. Configure the parameters; and then, click Set.
Table 163: ACL Global Parameters
Parameter
ACL Status
Description
Specifies whether the ACL feature is enabled. When you change this setting, the device requires an immediate reboot. Values: Enabled, Disabled Default: Disabled Caution: The default configuration of the Default ACL policy blocks all traffic.
Learning Period
The time, in seconds, the device takes to learn existing sessions before starting the protection. During the learning period, the device accepts all sessions regardless of any unknown direction. However, for the following cases, ACL will treat the session according to the configured policies: A new TCP session that starts with a SYN packet A new ICMP session that starts with a request packet Values: 0The protection starts immediately 1max integer Default: 600
TCP Handshake Timeout
The time, in seconds, the device waits for the three-way handshake to complete before the device drops the session. Default: 60 The time, in seconds, an idle session remains in the Session table. If the device receives packets for a timed-out, discarded session, the device considers the packets to be out-of-state and drops them. Values: 607200 Default: 3600
TCP Timeout in Established State
298
Table 163: ACL Global Parameters
Parameter
TCP FIN Timeout
Description
The time, in seconds, the session remains in the Session table after the device receives a FIN packet from both sides (from the client and from the server). Values: 1600 Default: 10
TCP RST Timeout
The time, in seconds, the session remains in the Session table after the device receives a TCP RST packet for the session. Values: 1600 Default: 30
TCP Mid Flow Mode
Specifies what the device does with out-of-state packets. Values: Drop, Allow Default: Drop
TCP Reset Validation Mode
Specifies the action that the device takes when RST packet validation fails (that is, the packet sequence number is not within the permitted range). Values: Drop, Allow, ReportOnly Default: Drop
UDP Timeout
The time, in seconds, that the device keeps an idle UDP session open. After the timeout, the session is removed from the Session table. Values: 13600 Default: 180
ICMP Timeout
The time, in seconds, that the device keeps an idle ICMP session open. After the timeout, the session is removed from the Session table. Values: 1300 Default: 60
GRE Timeout
The time, in seconds, that the device keeps an idle GRE session open. After the timeout, the session is removed from the Session table. Values: 17200 Default: 3600
SCTP Timeout
The time, in seconds, that the device keeps an idle SCTP session open. After the timeout, the session is removed from the Session table. Values: 17200 Default: 3600
Allow ICMP Smurf
Specifies whether the ACL module allows ICMP Smurf packets. Values: True, False Default: False
Other IP Protocols Timeout
The time, in seconds, that the device keeps an idle session of other IP protocols (not UDP, not ICMP) open. After the timeout, the session is removed from the Session table. Values: 17200 Default: 600
299
Configuring ACL Policy Rules

Configure ACL policy rules to create a flexible and focused stateful access-control policy. You must enable the ACL feature before you can configure ACL reports.
Tip: You can activate and de-activate rules using predefined event schedules (see Event Scheduler, page 247). Before you configure ACL rules, ensure that you have configured classes for the networks, physical port groups, and VLAN tag groups that you want to use in the rules.
To configure an ACL policy rule 1. 2. Select Security > ACL > Modified Policies. Do one of the following: 3. To update policy, click the relevant link name. To create a new policy, click Create.
Configure the parameters; and then, click Set.
Table 164: ACL Rule Parameters
Parameter
Policy Name Index
Description
The name of the rule up to 50 characters. The index number for the rule. DefensePro examines policy rules according to the ascending order of index numbers. Values: 1max integer The user-defined description of the rule. The predefined event schedule that activates the policy. Default: None The predefined event schedule that de-activates the policy. Default: None Specifies whether the device issues traps for the rule. Values: Enable, Disable Default: Disable
Description Activate Scheduler Inactivate Scheduler Packet Report Status
Protocol
The protocol of the traffic that the policy inspects. Values: Any ICMP Other TCP UDP Other SCTP Default: Any
300
Parameter
Source
Description
The existing source Network class of the packets that the policy inspects. Values: The Network classes displayed in the Classes tab any any_ipv4 any_ipv6 Default: any
Destination
The existing destination Network class of the packets that the policy inspects. Values: The Network classes displayed in the Classes tab any any_ipv4 any_ipv6 Default: any
Physical Port Group
The Physical Port class or physical port that the rule uses. Values: A Physical Port class displayed in the Classes tab The physical ports on the device None
Vlan Tag Group
The existing VLAN Tag class for the rule. Values: The VLAN Tag classes displayed in the Classes tab None Default: None
301
Parameter
Service
Description
The Service for the rule. Services characterize traffic based (Available only when TCP or UDP is on layer-37 criteria. A Service is a configuration of a basic selected for the Protocol parameter) 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. Action The action that the policy takes on packets that match the classification. Values: Accept Drop Drop + Source RST Default: Accept ICMP Flags The ICMP flags in the packets that the policy inspects. The module inspects only the packets with the selected flags. You can specify ICMP flags only when ICMP is the specified protocol. Values: SRC-QUENCHSource Quench TIME-STAMPTIME STAMP INFOInformation ADDR-MASKAddress Mask ALT-HOSTAlternate Host Address DOMAINDomain ROUTE-ADVRouter Advertisement ROUTE-SOLRouter Solicitation DEST-UNREACHDestination Unreachable REDIRECTRedirect TIME-EXTime Exceeded PARAM-PROBParameter Problem ECHOEcho BIG-PCKTPacket Too Big HOME-AGNTHome Agent
Viewing Active ACL Policy Rules

You can view the active rules in the ACL policy configured on the device.
To view the active ACL rule configuration Select Security > ACL > Active Policies. The table displays details of the current ACL rules configured on the device. For information about ACL rule parameters, see ACL Rule Parameters, page 300.
302
Updating ACL Policies
To update the policies on the device Select Security > ACL > Update Policies; and then, click Set.
Viewing and Managing ACL Reports

You can view summary ACL reports and manage ACL report parameters. You must enable the ACL feature before you can configure ACL reports.
To configure ACL report parameters 1. Select Security > ACL > Reports. 2. Configure the parameters; and then, click Set.
Table 165: ACL Report Parameters
Parameter
Summary Reports Period
Description
The frequency, in seconds, that the device produces ACL reports. Values: 1600 Default: 60
Send SRP Reports
Specifies whether the module sends ACL policy reports to the using SRP. Values: True, False Default: False Note: The Statistics Reporting Protocol (SRP) management host IP address must be configured to send ACL policy reports.
Max Detailed Reports Per Second
The maximum number of detailed reports that the device generates per second. Values: 1100 Default: 10
303
Ports Access
You can specify how unbound UDP and TCP ports respond to SYN packets.
To set the port unreachable status 1. 2. Select Security > Ports Status. From the Port Unreachable Status drop-down list, select one of the following: EnabledUnbound TCP ports answer SYN packets with an RST. Unbound UDP ports answer SYN packets with a port-unreachable message. DisabledThe device drops SYN or UDP packets without sending a reply. When the device uses this option, the device does not expose itself to the network.
Default: Enabled 3. 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.
Table 166: 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. Default: Enabled
304
Table 166: Management Port Parameters
Parameter
SSL
Description
Displays the access permission for SSL configuration for each management port. Values: Enable, Disable Default: Enabled
Web
Displays access permission for Web Based configuration for each management port. 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 305 SNMP User Table, page 306 SNMP Community Table, page 306 SNMP Groups Table, page 307 SNMP Access Table, page 308 SNMP View Table, page 308 SNMP Notify Table, page 309 Target Parameters Table, page 309 Target Address Table, page 310 Creating an SNMP User, page 311
SNMP Global Parameters
To set the SNMP Global parameters 1. Select Security > SNMP > Global Parameters. The SNMP Global Parameters pane is displayed. 2. Configure the parameters; and then, click Set.
305
Table 167: 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 168: 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.
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.
306
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 169: 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 170: 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.
307
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 171: 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.
308
Table 172: 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 173: 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.
309
Table 174: 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.
310
Table 175: 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 parameters; and then, click Create User. The new SNMP user is created.
Table 176: SNMP User 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
311
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.
312
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 177: 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 Flood 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.
313
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 configure global SYN flood protection parameters 1. 2. Select Security > SYN Flood Protection > Global Parameters. The SYN Flood Protection Parameters pane is displayed. Configure the parameters; and then, click Set.
Table 178: SYN Flood Protection Parameters
Parameter
SYN Protection Status
Description
Specifies the status of SYN Flood Protection feature. Values: EnabledActivates the SYN Flood Protection module. DisableDeactivates the SYN Flood Protection module. StandbyActivates the SYN Flood Protection module without rebooting the device. Default: Disabled
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: 5
314
Table 178: 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.
315
LinkProof User Guide Security 3. Configure the parameters; and then, click Set.
Table 179: 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.
316
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 [sic] 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 [sic] Statistics, click Set.
317
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
318
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.
319
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 parameters; and then, click Import. The certificate is imported.
Table 180: Import PKI Component 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.
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.
320
Parameter
Text Certificate File
Description
In this area, you can paste the Certificate in encrypted text format. The filepath of the certificate file to import.
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 an entry, 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.
Table 181: 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.
Key Passphrase Common Name
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
321
Table 181: Certificate Parameters
Parameter
Locality State Or Province Organization Organization Unit Country Name Email Certificate Validity
Description
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 323.
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 3. 4.
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. 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.
322
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 parameters; and then, click Import. The certificate is imported.
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
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.
To configure default values for certificates 1. Select Security > Certificates > Default values. The Certificate Default Values pane is displayed. 2. Configure the parameters; and then, click Set.
323
Table 183: 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.
324
Chapter 8 Bandwidth Management

This chapter describes the Bandwidth Management module. This chapter contains the following sections: Bandwidth Management Overview, page 325 Managing Bandwidth Management Global Parameters, page 326 Bandwidth Management Policies, page 328 Services, page 342 Networks, page 353 Port Groups, page 354 Application Port Groups, page 355 VLAN Tag Groups, page 356 Discrete Networks, page 359 Protocol Discovery, page 362 Port Bandwidth, page 365 Cancelling Interface Classification, page 365 Example Time-based BWM Policy, page 366
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 the following: 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 packetEnables you to prioritize services.
325
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.
Application Classification
LinkProof supports the following Application Classification modes: Per PacketThe device classifies every packet that flows through it. In this mode, the device individually classifies every single packet. Per SessionThe device classifies all packets by session. The device classifies each packet in a session until it finds a best-fit policy is found, fully classifying the session. Once the device fully classifies a session fully classified, the device classifies all packets belonging to the same session accordingly. This allows for traffic classification according to application, and also saves some overhead for the classifier.
Classification Mode
LinkProof supports the following classification modes: 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.
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. 2. Select BWM > Global Parameters. The Global Parameters pane is displayed. Configure the parameters; and then, click Set.
326
LinkProof User Guide Bandwidth Management
Table 184: 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: Disable Note: If you change the value for this parameter, you must reset the device.
Application Classification
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 Note: Changing the value takes effect when you update policies (BWM > Update Policies > Set).
BW per Traffic Flow Aging
The time, in seconds, that the device keeps a non-active traffic flow in the BW flow tracking table.
327
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 three-way 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
Bandwidth Management Policies

This section describes Bandwidth Management policies and contains the following topics: Bandwidth Management Policy Mechanism, page 328 Bandwidth Management Classification Criteria, page 329 Bandwidth Management Rules, page 330 Managing Bandwidth Management Policies, page 333
Bandwidth Management Policy Mechanism

The policy mechanism enables you to classify and enforce bandwidth management on the traffic passing through the LinkProof device. 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.
328
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. Traffic Flow IdentificationDefines what type of traffic flow the BWM policy limits. LinkProof supports the following options: Client (source IP) Session (source IP and port) Connection (source IP and destination IP) FullL4Session (source and destination IP and port) SessionCookie (according to a specified cookie identifier) SipCallId (SIP Call ID)
Cookie Field IdentifierA string that identifies the cookie field whose value the device uses determine the different traffic flows. This is required only when Traffic Flow Identification is set to SessionCookie.
329
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.
Bandwidth Management Rules

Once the traffic is classified and matched to a policy, the Bandwidth Management rules can be applied to the policy. When traffic matches a policy, the Bandwidth Management module accepts the connection forwards the traffic to its destination, unless the bandwidth has been exceeded. Bandwidth Management module drops traffic that exceeds the specified bandwidth.
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
You can assign a minimum (guaranteed) bandwidth to a policy. The device will not allow packets that were classified through this policy to exceed this allotted bandwidth. The maximum bandwidth configured for the entire device 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.
Traffic Flow Maximum Bandwidth

Traffic Flow Maximum Bandwidth is the maximum bandwidth allowed per traffic flow.
330
Max Concurrent Sessions

Max Concurrent Sessions is the maximum concurrent sessions allowed for the BWM policy.
Packet Marking
Packet Marking refers to Differentiated Services Code Point (DSCP) or Diffserv. Packet Marking enables the device to mark the packet with a range of bits.
Bandwidth-Management-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 (see Default Policy, page 331).
Default Policy
The Bandwidth Management module automatically creates a Default policy. The packets that match no user-defined policy match the Default policy. You cannot delete a Default policy, and you can modify only some of its configuration parameters. For example, the Index number of the Default policy is always 0, but you can modify the maximum bandwidth for it.
Policy TreesHierarchical Bandwidth-Management Policies

You can organize policies into a hierarchical, tree structure to configure hierarchical bandwidth borrowing domains. For example, you can define sets of policies for groups of users, departments, or customers. You can allocate bandwidth for a group (that is, for a branch), which allows bandwidth borrowing inside a group, but not necessarily among groups. Bandwidth that is not utilized by a specific policy under a tree node is allocated proportionally to the other policies, enabling them to borrow from other policies, preventing starvation and utilizing the bandwidth more efficiently. The following figure shows two policy branches (Company 1 and Company 2) and the Default policy.
Figure 58: Example Hierarchical Bandwidth Management Configuration

Com pany 1 G u a r a n te e d : 7 0 M ax: 80 Com pany 2 G u a ra n te e d : 1 0 M ax: 20 D e fa u lt
R&D G u a r a n te e d : 3 0 M ax: 50
S a le s M ax: 30
FTP M ax: 30
D e fa u lt G u a r a n te e d : 5
SM TP G u a ra n te e d : 5
D e fa u lt
SM TP G u a r a n te e d : 2 0
D e fa u lt M ax: 0
Note: You can use the Policy Trees window to change the hierarchy by means of moving and copying child policies (see Configuring Policy Trees, page 341).
331
Configuration Limitations and Dependencies

The Bandwidth Management module supports up to five levels of hierarchy. Sibling policies share the bandwidth of the parent. The total bandwidth available for a parent policy is the sum of Guaranteed Bandwidth values of all its child policies. The total guaranteed bandwidth among sibling policies cannot exceed the guaranteed bandwidth of the parent. Only a leaf node can be a matching policy. Therefore, each parent must have a Default child policy. The Bandwidth Management module creates the Default policies automatically. A Default policy will match all the traffic that matches the parent policy but does not match any of the sibling policies. You cannot delete a Default policy, and you can modify only some of its configuration parameters. For example, the Index number of the Default policy is always 0, but you can modify the maximum bandwidth for it. Indexes in the branch are preserved. Indexes at lower levels indicate the classification order among sibling policies. Each child node inherits the properties of its parent as follows: Enabling or disabling a parent policy affects all its child nodes. However, the configuration of the child nodes does not change. If you delete a parent policy, you delete all the child policies also. Each child policy inherits the Direction value of its parent. You can change the Direction value of a child policy only if the Direction of the parent is Two Way. You can specify the From Farm and To Farm values of a child node only if the value is unspecified in the parent.
Force Best Fit

Force Best Fit provides information whether the classification is best fit for the session (in terms of packet content classification). Classification is considered best fit if, at each level of the matching branch, one of the following conditions holds: The node is configured with Best Fit enabled. Not left sibling of the classification entry (which is matched by a non-filter match function) is configured with Best Fit enabled.
Hierarchical Policy Notation

The names of the policies are displayed using a dot-delimited string to specify the hierarchy. The name of the first-level parent is first in the string. Using the configuration in Figure 58 - Example Hierarchical Bandwidth Management Configuration, page 331, the names of the policies are as follows: Company 1 Company 1.R&D Company 1.Sales Company 1.Sales.SMTP Company 1.Sales.Default Company 1.FTP Company 1.Default Company 2 Company 2.SMTP Company 2.Default Default
332
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: Configuring BWM Policies, page 333 Viewing the Configuration of Active BWM Policies, page 335 Configuring BWM Policy Extensions, page 337 Viewing Active BWM Policy Extensions, page 340 Configuring Policy Trees, page 341 Updating BWM Policies, page 342
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: Name Index Destination Source Service
2. Click Create. The Modify Policies Table Create pane is displayed. 3. Configure the parameters; and then, click Set.
Table 185: BWM Policy Parameters
Parameter
Name
Description
The user-defined name of the policy. For important information about Policy Trees, that is, hierarchical bandwidth management, see Policy TreesHierarchical BandwidthManagement Policies, page 331. Use the Policy Trees window to change the hierarchy by means of by moving and copying child policies (see Configuring Policy Trees, page 341). Note: This value is read-only after creation.
Index Description
The index number of the policy. A description of the policy.
333
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
Destination
The destination of the packet being matched by the policy. Values: A valid IP address or network address anyAny destination any_ipv4Any IPv4 destination any_ipv6Any IPv6 destination
Source
The source of the packet being matched by the policy. Values: A valid IP address or network address anyAny destination any_ipv4Any IPv4 destination any_ipv6Any IPv6 destination
Service Service Type
The name of the service required for this policy, based on the Service Type. The type of service (filter). Values: None Basic Filter AND Group OR Group Default: None
The guaranteed 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 maximum bandwidth, in Kbit/s, for packets matching this policy. Note: If you want this policy to drop all matching packets, enter 0. The priority attached to the packet by which it is forwarded. Values: Real Time None 077 is the lowest priority. Default: Real Time
Maximum Bandwidth Priority
334
Parameter
Description
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 354. Note: The group must be configured already. The name of the VLAN tag group. For more information, see VLAN Tag Groups, page 356. Default: None Note: The group must be configured already.
VLAN Tag Group
Operational Status
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
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 with a table comprising the following columns: Name Index Destination Source Service
2. To view additional information on a specific policy, select the policy. The following fields are displayed read-only:
Parameter
Name Index Description Direction
Description
The user-defined name of the policy. The index number of the policy. The description of the policy. 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.
335
Parameter
Destination
Description
The destination of the packet being matched by the policy. Values: A valid IP address or network address anyAny destination any_ipv4Any IPv4 destination any_ipv6Any IPv6 destination
Source
The source of the packet being matched by the policy. Values: A valid IP address or network address anyAny destination any_ipv4Any IPv4 destination any_ipv6Any IPv6 destination
Service Service Type
The name of the service required for this policy, based on the Service Type. The type of service (filter). Values: None Basic Filter AND Group OR Group
The reserved bandwidth for packets matching this policy. Note: You cannot configure a child policy with maximum bandwidth and guaranteed bandwidth higher than its parent policy, however, the sum of maximum bandwidth can be higher than the parent policy, and the sum of all guaranteed bandwidth must be less than or equal to the guaranteed bandwidth of the parent policy.
Maximum Bandwidth
The maximum bandwidth that can be forwarded for traffic that matches this policy. The scheduler can borrow bandwidth from other queues, to forward packets from this policy queue that has exceeded, or are about to exceed, their guaranteed bandwidth up to this limit. If this value is set to 0 this policy is burstable up to the maximum available bandwidth with no limit. When hierarchical policies are configured, if one of the children does not consume all of its allocated bandwidth, another child, belonging to the same parent may use the spare bandwidth, which is limited by the Maximum Bandwidth value of the parent. Note: You cannot configure a child policy with maximum bandwidth and guaranteed bandwidth higher than its parent policy, however, the sum of maximum bandwidth can be higher than the parent policy, and the sum of all guaranteed bandwidth must be less than or equal to the guaranteed bandwidth of the parent policy.
336
Parameter
Priority
Description
The priority attached to the packet by which it is forwarded. Values: Real Time None 077 is the lowest priority.
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 354. The name of the VLAN tag group. For more information, see VLAN Tag Groups, page 356.
VLAN Tag Group
Configuring BWM Policy Extensions
To create a BWM policy extension 1. Select BWM > Modify > Policy Extensions. The Modify Policies Extensions pane is displayed with a table comprising the following columns: Name Traffic Flow Identification Traffic Flow Max BW (kbps) Max Concurrent Sessions Max HTTP Rqts Per Second
2. Select a policy. The Modify Policies Extensions Update pane is displayed 3. Configure the parameters; and then, click Set.
337
Table 186: BWM Policy Extension Parameters
Parameter
Name Best Fit
Description
(Read-only) The name of the policy. Specifies whether to classify packets using a best-fit method, which increases performance, but at the potential loss of accuracy. Values: FalseWhen the LinkProof device classifies traffic according to data in the TCP/UDP payload, even when a match is found for the first session packet, the device will continue to look for a match for subsequent packets. True Once the device matches the first packet of a session to a BWM policy, the device stops classification of the packets belonging to the same session and processes the entire session according to the first matched policy. When hierarchical policies are configured, if Best Fit is True on a parent policy, and a packet is matched to that policy, the device searches for the best fit only among the child policies of the parent policy. Default: False Note: The Best Fit parameter is relevant only when the Application Classification mode is Per-session, not Per-packet.
Activation Schedule
The Event Schedule for making the BWM policy active. For more information, see Event Scheduler, page 247. 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 247. Default: None Note: The schedule must be configured already.
Packet Marking Type
Marks the packet with a range of bits displayed in the drop-down list. Values: DSCPThe device marks the Differentiated Services Code Point value. ToSThe device marks the Type of Service value. NoneThe device does no marking. Default: None
Packet Marking Value
The Packet Marking value. Values: None For DCSP, a value in the range 063. For ToS, a value in the range 07. Default: None
338
Table 186: BWM Policy Extension Parameters
Parameter
Traffic Flow Identification
Description
The type of traffic flow that this policy limits. Values: None ClientSource IP. SessionSource IP and port. ConnectionSource IP and destination IP. FullL4SessionSource and destination IP and port. SessionCookieMust configure cookie identifier. SessionCookieSession cookie according to the specified Cookie Identifier. SipCallIdSIP Call ID. Default: None
Traffic Flow Max BW Max Concurrent Sessions
The maximum bandwidth, in Kbit/s, allowed per traffic flow. Default: 0 The maximum number of concurrent sessions allowed for a client IP. Default: 0 Note: This option is not available if the Traffic Flow Identifier is set to Session or FullL4Session.
Max HTTP Rqts Per Second
The maximum number of HTTP requests per second (such as HTTP GET or POST or HEAD) per cookie when Traffic Flow Identification is specified (not None) and Traffic Flow Max BW is not 0. Default: 0 The string that identifies the cookie field. 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. Specifies whether the classification is done before of after packet modification. Value: After ChangesClassifies the packet after the device has modified the packet. Before ChangesClassifies the packet before the device has modified the packet. Default: After Changes
Cookie Field Identifier
Classification Point
From Farm To Farm
The source farm of the traffic that the BWM policy classifies. The destination farm of the traffic that the BWM policy classifies.
339
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 with a table comprising the following columns: 2. Name Traffic Flow Identification Traffic Flow Max BW (kbps) Max Concurrent Sessions Max HTTP Rqts Per Second
To view additional information on a specific policy, select the policy. The following fields described are displayed read-only:
Parameter
Name Best Fit
Description
The name of the policy. Specifies whether to classify packets using a best-fit method, which increases performance, but at the potential loss of accuracy. Values: FalseWhen the LinkProof device classifies traffic according to data in the TCP/UDP payload, even when a match is found for the first session packet, the device will continue to look for a match for subsequent packets. True Once the device matches the first packet of a session to a BWM policy, the device stops classification of the packets belonging to the same session and processes the entire session according to the first matched policy. When hierarchical policies are configured, if Best Fit is True on a parent policy, and a packet is matched to that policy, the device searches for the best fit only among the child policies of the parent policy. Note: The Best Fit parameter is relevant only when the Application Classification mode is Per-session, not Per-packet.
Activation Schedule Inactivation Schedule Packet Marking Type
The Event Schedule for making the BWM policy active. For more information, see Event Scheduler, page 247. The Event Schedule for making the BWM policy inactive. For more information, see Event Scheduler, page 247. Marks the packet with a range of bits displayed in the drop-down list. Values: DSCPThe device marks the Differentiated Services Code Point value. ToSThe device marks the Type of Service value. NoneThe device does no marking.
340
Parameter
Packet Marking Value
Description
The Packet Marking value. Values: None For DCSP, a value in the range 063. For ToS, a value in the range 07.
Traffic Flow Identification
The type of traffic flow that this policy limits. Values: None ClientSource IP. SessionSource IP and port. ConnectionSource IP and destination IP. FullL4SessionSource and destination IP and port. SessionCookieMust configure cookie identifier. SessionCookieSession cookie according to the specified Cookie Identifier. SipCallIdSIP Call ID.
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. The maximum number of HTTP requests per second (such as GET, POST, or HEAD) when Traffic Flow Identification is specified (other than None) and Traffic Flow Max BW is configured (other than 0). Default: 0 The string that identifies the cookie field. 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. Specifies whether the classification is done before of after packet modification. Value: After ChangesClassifies the packet after the device has modified the packet. Before ChangesClassifies the packet before the device has modified the packet.
Cookie Field Identifier
From Farm To Farm
The source farm of the traffic that the BWM policy classifies. The destination farm of the traffic that the BWM policy classifies.
Configuring Policy Trees

Use the Policy Trees pane to configure hierarchical bandwidth management. You can modify the hierarchies by moving and copying parent and child policies. For more information, see Policy TreesHierarchical Bandwidth-Management Policies, page 331.
341
To configure the Policy Tree window parameters 1. 2. Select BWM > Modify > Policy Trees. The Policy Trees window is displayed. Configure the parameters; and then, click Set.
Table 187: Policy Tree Parameters
Parameter
Policy Name Parent Name Action
Description
The name of the policy. The parent policy for this policy. Specifies whether to move or copy this policy to the specified parent policy. You can move a child policy to a higher position in the hierarchy. You can move or copy a parent policy with all its children to a position under another policy (either under a parent or another child). You cannot move or copy a parent policy to a position under a child. Values: copy, move Default: copy
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.
342
LinkProof User Guide Bandwidth Management This section contains the following topics: Basic Filters, page 343 AND Group Filters, page 350 OR Group Filters, page 351 Special ServiceSpecial Filters, page 1 Viewing Active Services, page 352
Basic Filters
LinkProof supports an extensive list of predefined basic filters (see Predefined Basic Filters, page 344). You can also create your own basic filters. A basic filter is a building block for packet or session classification. A filter match can be done according to application protocol, application ports, bit masks and textual classification. There are numerous predefined filters that the user can choose from. In addition to these, the user can create their own filters to meet their specific requirements. These basic filters can be combined into more complex filters by using AND groups and OR groups. 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.
343
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. 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 401.
Example Basic Filter

Although not typically the case, this example configuration of a basic filter combines both OMPC matching and content matching.
Table 188: Example Basic Filter Configuration
Parameter
Name Protocol Source App. Port Destination App. Port OMPC Offset Relative to OMPC Offset OMPC Mask OMPC Pattern
Example Value
MyBasicFilter TCP Not specified Not specified L4 Data 0 ffffff00 41424300
344
Table 188: Example Basic Filter Configuration
Parameter
OMPC Condition OMPC Length Content Offset Content Content Type Content End Offset Content Data Content Coding Content Data Coding Description
Example Value
Equal Three Bytes 67 hello Text 80 Not specified Case Insensitive None My basic filter
This search defined by this basic filter searches for TCP packets from any port to any port. The OMPC fields specify that the three bytes starting 0 bytes after the start of the L4 data must be 414243, which is the hexadecimal ASCII representation of ABC. In addition, the string hello will be searched for in the area between 67 bytes and 80 bytes after the end of the TCP header. The search will be case-insensitive.
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: Name Description Protocol OMPC Offset OMPC Mask
2. Select the relevant link. The Modify Basic Filter Table Update pane is displayed. 3. Configure the parameters; and then, click Set.
345
Table 189: Basic Filter Parameters
Parameter
Name Protocol
Description
(Read-only) The name of the filter. Values: IP TCP UDP ICMP NonIP SCTP Default: IP
Source App. Port
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.
346
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
347
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{|}~.
348
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.
349
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).
350
To configure an AND Group filter 1. Select Classes > Modify > Services > AND Groups. The Modify AND Groups Table pane is displayed. 2. Click Create. The Modify AND Groups Table Create pane is displayed. 3. Set the following parameters:
Parameter
AND Group Name Basic Filter Name 4. Click Set.
Description
The user-defined AND Group name. A basic filter for this AND Group.
5. 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. 6. 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. Select Classes > Modify > Services > OR Groups. The Modify OR Groups Table pane is displayed. 2. Click Create. The Modify OR Groups Table Create pane is displayed.
351
LinkProof User Guide Bandwidth Management 3. Configure the parameters; and then click Set.
Table 190: 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.
352
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. Select Classes > Modify > Networks. The Modify Network Table pane is displayed. 2. Click Create. The Modify Network Table Create pane is displayed. 3. Configure the parameters; and then, click Set.
Table 191: 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
353
To edit a network 1. 2. 3. Select Classes > Modify > Networks. The Modify Network Table pane is displayed. Modify the parameters as required. Click Set.
To delete a network 1. 2. 3. Select Classes > Modify > Networks. The Modify Network Table pane is displayed. Select the checkbox in the row of the network to delete. Click Delete. The network is deleted.
Viewing Active Networks
To view active networks 1. 2. Select Classes > View Active > Networks. The Active Network Table pane is displayed. 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 192: 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.
354
Configuring Port Groups
To configure a port group 1. Select Classes > Modify > Port Groups. The Modify Physical Port Groups Table pane is displayed. 2. Click Create. The Modify Physical Port Groups Table Create pane is displayed. 3. Configure the parameters; and then, click Set.
Table 193: 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 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. Select Classes > Modify > Appl. Port Groups. The Modify Appl. Port Groups Table pane is displayed. 2. Click Create. The Modify Appl. Port Groups Table Create pane is displayed.
355
LinkProof User Guide Bandwidth Management 3. Configure the parameters; and then, click Set.
Table 194: 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 195: 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.
356
Configuring VLAN Tag Groups
To configure a VLAN tag group 1. Select Classes > Modify > VLAN Tag Groups. The Modify Active VLAN Tag Groups pane is displayed. 2. Click Create. The Modify Active VLAN Tag Groups Table Create pane is displayed. 3. 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 196: 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
357
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 a MAC group 1. 2. 3. Select Classes > Modify > MAC Groups. The Modify MAC Address Groups Table is displayed. Click Create. The Modify MAC Address Groups Table Create pane is displayed. Configure the parameters; and then click Set.
Table 198: 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 199: Active MAC Address Groups Parameters
Parameter
Group Name MAC Address
Description
The name of the MAC address group. The MAC address.
358
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. Select Classes > Update Policies. The Activate Latest Changes pane is displayed. 2. 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 200: 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
359
Table 200: 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
360
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. Select LinkProof > Global Configuration > Discrete Network. The Global Configuration Discrete Network pane is displayed. 2. Configure the parameters; and then, click Set.
361
Table 201: 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 362 Protocol Statistics Global Parameters, page 363 Protocol Discovery Policies, page 363 Viewing the Protocol Discovery Statistics, page 365
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.
362
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. Select Performance > Protocol Statistics > Global Parameters. The Global Parameters pane is displayed. 2. Configure the parameters; and then, click Set.
Table 202: 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. Select Performance > Protocol Statistics > Protocol Discovery Policies. The Protocol Discovery Policies pane is displayed. 2. Click Create. The Protocol Discovery Policies Create pane is displayed.
363
LinkProof User Guide Bandwidth Management 3. Configure the parameters; and then, click Set.
Table 203: 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
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
364
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 363). 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. Select BWM > Miscellaneous > Port Bandwidth Table. The Port Bandwidth Table pane is displayed. 2. Select the port whose maximum available bandwidth you want to define. The Port Bandwidth Table Update pane is displayed. 3. In the Port Bandwidth [kbps] text box, type the required value. 4. 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.
365
To cancel interface classification by port 1. 2. Select BWM > Miscellaneous> Cancel Classification Per Port. The Classification is not performed for the following input ports pane is displayed. 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. 2. 3. 4. 5. Configuring the Example BWM Policy, page 367 Configuring the Example Start-Event Schedule, page 367 Configuring the Example Finish-Event Schedule, page 368 Associating the Start- and Finish-Event Schedules with the Example BWM Policy, page 368 Activating the Latest Changes for the Example BWM Policy, page 369
366
Configuring the Example BWM Policy
To configure the example BWM policy 1. Select BWM > Modify > Policies. The Modify Policies Table pane is displayed. 2. Click Create. The Modify Policies Table Create pane is displayed. 3. Specify the parameters; and then, click Set.
Table 205: 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. 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 206: Start-Event Scheduler Parameters for Example Time-based BWM Policy
Parameter
Name Frequency
Values
HTTPPriority_Start Daily
367
Table 206: 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. 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 207: 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. 2. 3. Select BWM > Modify > Policy Extensions. The Modify Policies Extensions pane is displayed. From the table, select HTTPPriority. The Modify Policies Extensions Update pane is displayed with HTTPPriority displayed in the Name field. Configure the parameters; and then, click Set.
Table 208: 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
368
Table 208: 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. Select BWM > Update Policies. The Activate Latest Changes pane is displayed. 2. Click Set.
369
370
Chapter 9 Health Monitoring

This chapter describes Health Monitoring. This chapter contains the following sections: Health MonitoringIntroduction, page 371 Health Check Configuration, page 373 Farm Health Checks, page 398
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 371 Response Level, page 371 Checked Elements, page 372 Health Checks, page 372 Methods, page 372 Binding and Groups, page 372
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.
371
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 374. 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 212 - Health Check Methods, page 378.
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.
372
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 373 Managing the Health Checks in the Check Table, page 374 Bindings and Groups, page 390 User-Defined Health Check MethodsPacket Sequence Table, page 391 Configuring a Diameter Health Check, page 394
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 209: 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.
373
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 374. Create a new health check. For more information, see Creating a Regular Health Check, page 374. 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 376.
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 372). 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 371).
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 372), 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.
374
LinkProof User Guide Health Monitoring 3. Configure the parameters; and then click Set.
Table 210: 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 212 - Health Check Methods, page 378. 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
375
Table 210: 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 211 - Health Monitoring Check Table Update Parameters, page 376. Click Set.
Table 211: Health Monitoring Check Table Update Parameters
Parameter
Check Name Method
Description
(Read-only) The user-defined name of the health check. The method for the health check (read-only). For descriptions of the methods, see Table 212 - Health Check Methods, page 378. 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
376
Table 211: 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).
377
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.
Table 212: 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.
378
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.
379
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 394 and Managing Binary File Transfer for Diameter Health Checks, page 397.
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) protocol1 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.
380
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
381
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
382
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.
383
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.
384
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.
1 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 386 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.
385
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
386

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
387

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
388

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
389
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
390
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 390. 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 390. 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.
391
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.
392
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.
393
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 395. Click Set.
394
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 395. 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 397). 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
395
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
396
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. 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.
397
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. 2. In the relevant Farm Table pane (see LinkProof Farms, page 138), from Connectivity Check Status drop-down list, select Health Monitoring. Click Set.
398
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.
399
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.
400
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).
401
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
402
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
403
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
404
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
405
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
406
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
407
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
408
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
409
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
410
Appendix C IPv6 Fundamentals

This appendix is included as additional background reference for further study of IPv6 and includes the following topics: IPv4 Versus IPv6, page 411 Name Resolution, page 412 Internet Protocol Version 6 (IPv6), page 413 IPv6 Address Autoconfiguration, page 415
IPv4 Versus IPv6

Internet Protocol version 6 (IPv6) is a network layer protocol for packet-switched internetworks. It is designated as the successor of IPv4, the current version of the Internet Protocol, for general use on the Internet. The main improvement brought by IPv6 is the increase in the number of addresses available for networked devices, allowing, for example, each cell phone and mobile electronic device to have its own address. IPv4 supports 232 (about 4.3 billion) addresses, which is inadequate for giving even one address to every living person, let alone supporting embedded and portable devices. IPv6, however, supports 2128 addresses; this is approximately 5 1028 addresses for each of the roughly 6.5 billion people alive today. The following table displays a quick summary of the key differences between IPv4 and IPv6 protocols.
Table 13: IPv4 Versus IPv6
IPv4
Source and destination addresses are 32 bits(4 bytes) in length. IPSec support is optional.
IPv6
Source and destination addresses are 128 bits (16 bytes) in length. IPSec support is required.
No identification of packet flow for QoS handling Packet flow identification for QoS handling by by routers is present within IPv4. routers is present within the IPv6 header using the Flow Label field. Fragmentation is performed by the sending host, Fragmentation is performed only by the sending and at the routers, thus slowing performance. host. No link-layer packet size requirements and has to Link layer must support 1,280 byte packet and reassemble 576-byte packet. rea sse mb el a 1,500 byte packet. Header includes a checksum. Header includes options. ARP uses Broadcast ARP Request frames to resolve an IPv4 address to a link layer address. IGMP is used to manage local subnet group membership. ICMP Router Discovery is used to determine the IPv4 address of the best default gateway and is optional. Header does not include a checksum. All optional data is moved to IPv6 extension headers. ARP Request frames are replaced with multicast Neighbor Solicitation (Discovery) messages. IGMP is replaced with Multicast Listener Discovery (MLD) messages. ICMPv4 Router Discovery is replaced with ICMPv6 Router Solicitation (Discovery) and Router Advertisement messages and is required.
411
LinkProof User Guide IPv6 Fundamentals
Table 13: IPv4 Versus IPv6
IPv4
Broadcast addresses are used to send traffic to all nodes on the subnet. Must be configured either manually or through DHCP for IPv4.
IPv6
There are no IPv6 broadcast addresses. Instead a link-local scope all-nodes multicast address is used. IPV6 does not require manual or DHCP configuration.
Uses host address (A) resource records in DNS to Uses AAAA records in the DNS to map host map host names to IPv4 addresses. names to IPv6 addresses. Uses pointer (PTR) resource records in the INUses pointer (PTR) resource records in the ADDR.ARPA DNS domain to map IPv4 addresses IP6.INT DNS domains to map IPv6 addresses to to host names. host names.
Name Resolution
While IPv6 is designed to work with the 128-bit IPv6 addresses of the source and the destination hosts, computer users are likely to experience difficulty in using and remembering the IPv6 addresses of the computers with which they want to communicate. Unique names, which are easier to remember, can be used instead. If a name is used as an alias for an IPv6 address, you need to ensure that the name is unique and that it resolves to the correct IPv6 address. The IPv6 protocol for the Windows Server 2003 family can use host names to resolve a name to an IPv6 address. Host names are used by programs that use Windows Sockets. Host name resolution is successfully mapping a host name to an IPv6 address. A host name is an alias that is assigned to an IPv6 node, identifying it as an IPv6 host. The host name can be up to 255 characters long and can contain alphabetic and numeric characters, hyphens, and periods. You can assign multiple host names to the same host. Windows Sockets (Winsock) programs can use one of two values for the destination to which you want to connect: the IPv6 address or a host name. When the IPv6 address is specified, name resolution is not required. When a host name is specified, the host name must be resolved to an IPv6 address before IPv6-based communication with a resource can begin. Host names can take various forms. The two most common forms are a nickname and a domain name. A nickname is an alias for an IPv6 address that individuals can assign and use. A domain name is a structured name in a hierarchical namespace named Domain Name System (DNS). An example of a domain name is www.microsoft.com. Nicknames or domain names are resolved through entries in the Hosts file, which is stored in the systemroot\System32\Drivers\Etc folder. For IPv6 name-to-address entries, the IPv6 address is written by using standard colon-hexadecimal format. For more information, see Expressing IPv6 addresses and TCP/IP database files. Domain names are resolved by sending DNS name queries to a configured DNS server, which is a computer that either stores domain name-to-IPv6 address mapping records or has records of other DNS servers. The DNS server resolves the queried domain name to an IPv6 address and returns the results. The DNS client in Windows XP and the Windows Server 2003 family supports the processing of AAAA (quad-A) resource records. All DNS queries and responses are sent by using IPv6 and IPv4. DNS name devolution for fully qualified domain names is also supported. For more information, see DNS defined.
412
Internet Protocol Version 6 (IPv6)

IPv6 is defined in RFC 2460, Internet Protocol, Version 6 (IPv6) Specification. IPv6 is a connectionless, unreliable datagram protocol used primarily for addressing and routing packets between hosts. Connectionless means that a session is not established before exchanging data. Unreliable means that delivery is not guaranteed. IPv6 always makes a best-effort attempt to deliver a packet. An IPv6 packet might be lost, delivered out of sequence, duplicated, or delayed. IPv6 does not attempt to recover from these types of errors. The acknowledgment of packets delivered and the recovery of lost packets are done by a higher-layer protocol, such as TCP. An IPv6 packet, also known as an IPv6 datagram, consists of an IPv6 header and an IPv6 payload, as shown in the following illustration.
IPv6 Packet IPv6 Header IPv6 Payload
The IPv6 header field specifies the following: Source AddressThe IPv6 address of the original source of the IPv6 packet. Destination AddressThe IPv6 address of the intermediate or final destination of the IPv6 packet. Hop LimitThe number of network segments on which the packet is allowed to travel before being discarded by a router. The Hop Limit is set by the sending host and is used to prevent packets from endlessly circulating on an IPv6 internetwork. When forwarding an IPv6 packet, IPv6 routers are required to decrease the Hop Limit by 1 and to discard the IPv6 packet when the Hop Limit is 0. Next Header8-bit selector. This identifies the type of header immediately following the IPv6 header. It uses the same values as the IPv4 Protocol field [RFC-1700 et seq.].
Internet Control Message Protocol for IPv6 (ICMPv6)

Internet Control Message Protocol for IPv6 (ICMPv6) is a required IPv6 standard defined in RFC Message 2463, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. With ICMPv6, hosts and routers that use IPv6 communication can report errors and send simple echo messages. The ICMPv6 protocol also provides a framework for the following: Multicast Listener Discovery (MLD)A series of three ICMPv6 messages that replace version 2 of the Internet Group Management Protocol (IGMP) for IPv4 to manage subnet multicast membership. For more information, see Multicast Listener Discovery (MLD). Neighbor Discovery (NDisc)A series of five ICMPv6 messages that manage node-to-node communication on a link. Neighbor Discovery replaces Address Resolution Protocol (ARP), ICMPv4 Router Discovery, and the ICMPv4 Redirect message and provides additional functions. For more information, see Neighbor Discovery (NDisc).
ICMPv6 messages are usually sent automatically when an IPv6 packet cannot reach its destination.
413
LinkProof User Guide IPv6 Fundamentals ICMPv6 messages are encapsulated and sent as the payload of IPv6 packets, as shown in the following illustration.
IPv6 Packet IPv6 Header IPv6 Payload
ICMPv6 Message ICMPv6 Header Message
Different types of ICMPv6 messages are identified in the ICMPv6 header. Because ICMPv6 messages are carried in IPv6 packets, they are unreliable. ICMPv6 messages not related to MLD or NDisc are listed and described in the following table.
Table 14: ICMPv6 Messages Not Related to MLD or NDisc
ICMPv6 message
Destination Unreachable Packet Too Big Time Exceeded Parameter Problem
Description
An error message that informs the sending host that a packet cannot be delivered. An error message that informs the sending host that the packet is too large to forward. An error message that informs the sending host that the Hop Limit of an IPv6 packet has expired. An error message that informs the sending host that an error was encountered in processing the IPv6 header or an IPv6 extension header. An informational message that is used to determine whether an IPv6 node is available on the network. An informational message that is used to reply to the ICMPv6 Echo Request message.
Echo Request Echo Reply
You can use the ping command to send ICMPv6 Echo Request messages and record the receipt of ICMPv6 Echo Reply messages. With ping, you can detect network or host communication failures and troubleshoot common IPv6 connectivity problems. For more information, see Test IPv6 connectivity by using the ping command. You can use the tracert command to send ICMPv6 Echo Request messages with incrementally increasing values in the Hop Limit field. Tracert will trace and display the path taken by IPv6 packets between a source and destination, allowing you to troubleshoot common IPv6 routing problems.
414
IPv6 Address Autoconfiguration

A highly useful aspect of IPv6 is its ability to automatically configure itself without the use of a stateful configuration protocol, such as Dynamic Host Configuration Protocol for IPv6 (DHCPv6). By default, an IPv6 host can configure a link-local address for each interface. By using router discovery, a host can also determine the addresses of routers, additional addresses, and other configuration parameters. Included in the Router Advertisement message is an indication of whether a stateful address configuration protocol should be used. Address autoconfiguration can only be performed on multicast-capable interfaces. Address autoconfiguration is described in RFC 2462, IPv6 Stateless Address Autoconfiguration.
Autoconfigured Address States

Autoconfigured addresses are in one or more of the following states: TentativeThe address is in the process of being verified as unique. Verification occurs through duplicate address detection. PreferredAn address for which uniqueness has been verified. A node can send and receive unicast traffic to and from a preferred address. The period of time that an address can remain in the tentative and preferred states is included in the Router Advertisement message. DeprecatedAn address that is still valid, but its use is discouraged for new communication. Existing communication sessions can continue to use a deprecated address. A node can send and receive unicast traffic to and from a deprecated address. ValidAn address from which unicast traffic can be sent and received. The valid state covers both the preferred and deprecated states. The amount of time that an address remains in the tentative and valid states is included in the Router Advertisement message. The valid lifetime must be greater than or equal to the preferred lifetime. InvalidAn address for which a node can no longer send or receive unicast traffic. An address enters the invalid state after the valid lifetime expires.
Types of Autoconfiguration
There are three types of autoconfiguration, Stateless, Stateful and Both. StatelessConfiguration of addresses is based on the receipt of Router Advertisement messages. These messages include stateless address prefixes and require that hosts not use a stateful address configuration protocol. StatefulConfiguration is based on the use of a stateful address configuration protocol, such as DHCPv6, to obtain addresses and other configuration options. A host uses stateful address configuration when it receives Router Advertisement messages that do not include address prefixes and require that the host use a stateful address configuration protocol. A host will also use a stateful address configuration protocol when there are no routers present on the local link. BothConfiguration is based on receipt of Router Advertisement messages. These messages include stateless address prefixes and require that hosts use a stateful address configuration protocol.
For all autoconfiguration types, a link-local address is always configured.
Autoconfiguration Process
The address autoconfiguration process for an IPv6 node occurs as follows: 1. A tentative link-local address is derived, based on the link-local prefix of FE80::/64 and the 64bit interface identifier. 2. Duplicate address detection is performed to verify the uniqueness of the tentative link-local address.
415
LinkProof User Guide IPv6 Fundamentals 3. 4. If duplicate address detection fails, manual configuration must be performed on the node. If duplicate address detection succeeds, the tentative link-local address is assumed to be unique and valid. The link-local address is initialized for the interface. The corresponding solicited-node multicast link-layer address is registered with the network adapter. The host sends a Router Solicitation message. If no Router Advertisement messages are received, then the host uses a stateful address configuration protocol to obtain addresses and other configuration parameters. The IPv6 protocol for the Windows Server 2003 family and Windows XP does not support the use of a stateful address configuration protocol. If a Router Advertisement message is received, the configuration information that is included in the message is set on the host. For each stateless autoconfiguration address prefix that is included: a. b. c. d. e. The address prefix and the appropriate 64-bit interface identifier are used to derive a tentative address. Duplicate address detection is used to verify the uniqueness of the tentative address. If the tentative address is in use, the address is not initialized for the interface. If the tentative address is not in use, the address is initialized. This includes setting the valid and preferred lifetimes based on information included in the Router Advertisement message. If it is specified in the Router Advertisement message, the host uses a stateful address configuration protocol to obtain additional addresses or configuration parameters.
For an IPv6 host, address autoconfiguration continues as follows: 1. 2.
3. 4.
IPv6 Routing
Routing is the process of forwarding packets between connected network segments. For IPv6-based networks, routing is the part of IPv6 that provides forwarding capabilities between hosts that are located on separate segments within a larger IPv6-based network. IPv6 is the mailroom in which IPv6 data sorting and delivery occur. Each incoming or outgoing packet is called an IPv6 packet. An IPv6 packet contains both the source address of the sending host and the destination address of the receiving host. Unlike link-layer addresses, IPv6 addresses in the IPv6 header typically remain the same as the packet travels across an IPv6 network. Routing is the primary function of IPv6. IPv6 packets are exchanged and processed on each host by using IPv6 at the Internet layer. Above the IPv6 layer, transport services on the source host pass data in the form of TCP segments or UDP messages down to the IPv6 layer. The IPv6 layer creates IPv6 packets with source and destination address information that is used to route the data through the network. The IPv6 layer then passes packets down to the link layer, where IPv6 packets are converted into frames for transmission over network-specific media on a physical network. This process occurs in reverse order on the destination host. IPv6 layer services on each sending host examine the destination address of each packet, compare this address to a locally maintained routing table, and then determine what additional forwarding is required. IPv6 routers are attached to two or more IPv6 network segments that are enabled to forward packets between them.
IPv6 Routers
IPv6 network segments, also known as links or subnets, are connected by IPv6 routers, which are devices that pass IPv6 packets from one network segment to another. This process is known as IPv6 routing and is shown in the following illustration. IPv6 routers provide the primary means for joining together two or more physically separated IPv6 network segments. All IPv6 routers have the following characteristics: IPv6 routers are physically multihomed hosts.
416
LinkProof User Guide IPv6 Fundamentals A physically multihomed host is a network host that uses two or more network connection interfaces to connect to each physically separated network segment. IPv6 routers provide packet forwarding for other IPv6 hosts. IPv6 routers are distinct from other hosts that use multihoming. An IPv6 router must be able to forward IPv6-based communication between networks for other IPv6 network hosts. You can implement IPv6 routers by using a variety of hardware and software products, including a computer running a member of the Windows Server 2003 family with the IPv6 protocol. Routers that are dedicated hardware devices running specialized software are common. Regardless of the type of IPv6 routers that you use, all IPv6 routing relies on a routing table to communicate between network segments.
Routing Tables
IPv6 hosts use a routing table to maintain information about other IPv6 networks and IPv6 hosts. Network segments are identified by using an IPv6 network prefix and prefix length. In addition, routing tables provide important information for each local host regarding how to communicate with remote networks and hosts. For each computer on an IPv6 network, you can maintain a routing table with an entry for every other computer or network that communicates with that local computer. In general, this is not practical, and a default router is used instead. Before a computer sends an IPv6 packet, it inserts its source IPv6 address and the destination IPv6 address (for the recipient) into the IPv6 header. The computer then examines the destination IPv6 address, compares it to a locally maintained IPv6 routing table, and takes appropriate action. The appropriate action may be one of the following three: The computer passes the packet to a protocol layer above IPv6 on the local host. The computer forwards the packet through one of its attached network interfaces. The computer discards the packet.
IPv6 searches the routing table for the route that is the closest match to the destination IPv6 address. The most specific to the least specific route is determined in the following order: 1. A route that matches the destination IPv6 address (a host route with a 128-bit prefix length). 2. A route that matches the destination with the longest prefix length. 3. The default route (the network prefix::/0). If a matching route is not found, the destination is determined to be an on-link destination.
The IPv6 Routing Table

Every computer that runs IPv6 determines how to forward packets based on the contents of the IPv6 routing table. To display the IPv6 routing table on a computer that is running a member of the Windows Server 2003 family or Windows XP, type netsh interface ipv6 show routes at the command prompt. Entries in the IPv6 routing table consist of: An address prefix The interface over which packets matching the address prefix are sent A forwarding or next-hop address A preference value used to select between multiple routes with the same prefix The lifetime of the route The specification of whether the route is published (advertised in a Routing Advertisement) The specification of how the route is aged The route type
417
LinkProof User Guide IPv6 Fundamentals The IPv6 routing table is built automatically, based on the current IPv6 configuration of your computer. When forwarding IPv6 packets, the routing table is searched by your computer for an entry that is the most specific match to the destination IPv6 address. A route for the link-local prefix (FE80::/64) is not displayed. The default route (a route with a prefix of ::/0) is typically used to forward an IPv6 packet to a default router on the local link. Because the router that corresponds to the default router contains information about the network prefixes of the other IPv6 subnets within the larger IPv6 internetwork, it forwards the packet to other routers until it is eventually delivered to the destination.
IPv6 Configuration Items

You can configure the following for the IPv6 protocol: IPv6 address Default router DNS server
IPv6 Address
By default, link-local addresses are automatically configured for each interface on each IPv6 node (host or router) with a unique link-local IPv6 address. If you want to communicate with IPv6 nodes that are not on attached links, the host must have additional site-local or global unicast addresses. Additional addresses for hosts are either obtained from router advertisements sent by a router or assigned manually. Additional addresses for routers must be assigned manually.
Default Router
To communicate with IPv6 nodes on other network segments, IPv6 must use a default router. A default router is automatically assigned based on the receipt of a router advertisement. Alternately, you can add a default route to the IPv6 routing table. You do not need to configure a default router for a network that consists of a single network segment.
DNS Server
You can use a Domain Name System (DNS) server to resolve host names to IPv6 addresses. When an IPv6 host is configured with the address of a DNS server, the host sends DNS name queries to the server for resolution. AAAA (quad-A) resource records, which are stored on your DNS servers, enable mapping from a host name to its IPv6 address. To enable DNS name resolution, configure an IPv6 router with forwarding enabled and a global prefix that is advertised to clients. You can do this by using the netsh interface ipv6 add route and netsh interface ipv6 set interface commands. For more information, see Add an IPv6 route and Enable IPv6 forwarding. By default, DNS is configured to allow DNS dynamic updates. You can either leave dynamic update enabled when you use IPv6 with DNS, or you can manually add DNS records for IPv6 clients.
Configuring Clients with the DNS Server Address

To provide communication between DNS clients and servers, you can configure the clients with the IPv6 address of the DNS server, or you can configure your DNS server with one of the three default DNS server IPv6 addresses that are automatically configured on all IPv6 clients. You can configure clients with the IPv6 address of the DNS server by using the netsh interface ipv6 add dns command at each client computer or in a logon script that is run each time a client logs on to the network. To configure the DNS server with one of the three IPv6 addresses that are available on IPv6 client computers by default, use the netsh interface ipv6 add address command.
418
LinkProof User Guide IPv6 Fundamentals The three default DNS server addresses are: FEC0:0:0: FFFF::1 FEC0:0:0: FFFF::2 FEC0:0:0:FFFF::3
If your DNS server is on a different subnet than your IPv6 clients, configure a static route to the DNS server on any IPv6 router that is available on the DNS server's subnet.
Configuring the DNS Server to Listen on IPv6

You can configure the DNS server to listen for DNS name registration and resolution requests over IPv6. When your DNS server is configured to listen on both IPv4 and IPv6: Devices that function over IPv6 but not IPv4 will function properly with your DNS server. Computers and other devices that are configured with both IPv4 and IPv6 use IPv6 by default.
IPv6 Neighbor Discovery

IPv6 Neighbor Discovery (NDisc) is a set of messages and processes that determine relationships between neighboring nodes. NDisc replaces Address Resolution Protocol (ARP), Internet Control Message Protocol (ICMP) Router Discovery, and ICMP Redirect, which are used in IPv4, and provides additional functionality. NDisc is described in RFC 2461, Neighbor Discovery for IP Version 6 (IPv6). NDisc is used by routers to: Advertise their presence, host configuration parameters, and on-link prefixes. Inform hosts of a better next-hop address to forward packets for a specific destination.
NDisc is used by nodes to: Both resolve the link-layer address of a neighboring node to which an IPv6 packet is being forwarded and determine when the link-layer address of a neighboring node has changed. Determine whether IPv6 packets can be sent to and received from a neighbor.
The following table lists and describes NDisc processes.
Table 15: NDisc Processes
Parameter
Router Discovery
Description
The process by which a host discovers the local routers on an attached link (equivalent to ICMPv4 Router Discovery) and automatically configures a default router (equivalent to a default gateway in IPv4). Process where a host discovers network prefixes for local destinations. Process by which a host discovers additional operating parameters, including the link maximum transmission unit (MTU) and the default hop limit for outbound packets. Process for configuring IP addresses for interfaces in either the presence or absence of a stateful address configuration server such as Dynamic Host Configuration Protocol version 6 (DHCPv6). For more information, see IPv6 address autoconfiguration.
Prefix Discovery Parameter Discovery
Address Autoconfiguration
419
Table 15: NDisc Processes
Parameter
Address Resolution
Description
Process by which a node resolves a neighboring nodes IPv6 address to its link-layer address (equivalent to ARP in IPv4). The resolved linklayer address becomes an entry in a node's neighbor cache (equivalent to the ARP cache in IPv4). You can use the netsh interface ipv6 show neighbors command to view the contents of the neighbor cache on a computer running the Windows Server 2003 family and Windows XP. The process by which a node determines the IPv6 address of the neighbor to which a packet is being forwarded based on the destination address. The forwarding or next-hop address is either the destination address of the packet being sent or the address of a neighboring router. The resolved next hop address for a destination becomes an entry in a node's destination cache (also known as a route cache). The process by which a node determines that IPv6 packets cannot be sent to and received from a neighboring node. After the link-layer address for a neighbor has been determined, the state of the entry in the neighbor cache is tracked. If the neighbor is no longer receiving and sending back packets, the neighbor cache entry is eventually removed. Neighbor unreachability detection provides a mechanism for IPv6 to determine that neighboring hosts or routers are no longer available on the local network segment.
Next-hop Determination
Neighbor Unreachability Detection
Duplicate Address Detection The process by which a node determines that an address considered for use is not already in use by a neighboring node (equivalent to the use of gratuitous ARP frames in IPv4). Redirect Function The process by which a router informs a host of a better first-hop IPv6 address to reach a destination (equivalent to the function of the IPv4 ICMP Redirect message).
LinkProof learns the MAC addresses of IPv6 servers and routers by intercepting solicited and unsolicited Neighbor Advertisement messages as well as Neighbor discovery messages with source link-layer address (MAC) present. Neighbor discovery messages are validated first to prevent common attack of stealing IP addresses by off-link nodes pretending to be on-link.
Notes >> The hop limit must be 255. If this fails, silently discard the NS message. >> Check that the source IP prefix in the Neighbor discovery message matches any of the prefixes of the IP interfaces on the link through which the message came in. If this fails, LinkProof will still respond to the request with NA, but will not cache the response in the neighbor cache. This prevents attacks where the source IP is spoofed and intended to make LinkProof send traffic to the attacker using the source MAC. If the target address is a native IP address, check that the it is assigned to the Layer 2 link through which the message arrived. If the address is a VIPI associated with a VR, the link has to be the link of the VR. For other cases, no check is required.
New Header Format

The IPv6 header has a new format that is designed to minimize header overhead. This is achieved by moving both nonessential fields and option fields to extension headers that are placed after the IPv6 header. The streamlined IPv6 header provides more efficient processing at intermediate
420
LinkProof User Guide IPv6 Fundamentals routers. IPv4 headers and IPv6 headers are not interoperable and the IPv6 protocol is not backward compatible with the IPv4 protocol. A host or router must use an implementation of both IPv4 and IPv6 in order to recognize and process both header formats. The new IPv6 header is only twice as large as the IPv4 header, even though IPv6 addresses are four times as large as IPv4 addresses.
Large Address Space

IPv6 has 128-bit (16-byte) source and destination addresses. Although 128 bits can provide over 3.41038 possible combinations, the large address space of IPv6 has been designed to allow for multiple levels of subnetting and address allocation from the Internet backbone to the individual subnets within an organization. Although only a small percentage of possible addresses are currently allocated for use by hosts, there are plenty of addresses available for future use. With a much larger number of available addresses, address-conservation techniques, such as the deployment of NATs, are no longer necessary.
Efficient and Hierarchical Addressing and Routing Infrastructure

IPv6 global addresses used on the IPv6 portion of the Internet are designed to create an efficient, hierarchical, and summarized routing infrastructure that addresses the common occurrence of multiple levels of Internet service providers. On the IPv6 Internet, backbone routers have much smaller routing tables.
Stateless and Stateful Address Configuration

To simplify host configuration, IPv6 supports both stateful address configuration, such as address configuration in the presence of a DHCP server, and stateless address configuration (address configuration in the absence of a DHCP server). With stateless address configuration, hosts on a link automatically configure themselves with IPv6 addresses for the link (link-local addresses) and with addresses that are derived from prefixes advertised by local routers. Even in the absence of a router, hosts on the same link can automatically configure themselves with link-local addresses and communicate without manual configuration.
Built-in Security
Support for IPSec is an IPv6 protocol suite requirement. This requirement provides a standardsbased solution for network security needs and promotes interoperability between different IPv6 implementations.
Better Support for Quality of Service (QoS)

New fields in the IPv6 header define how traffic is handled and identified. Traffic identification, by using a Flow Label field in the IPv6 header, allows routers to identify and provide special handling for packets that belong to a flow. A flow is a series of packets between a source and destination. Because the traffic is identified in the IPv6 header, support for QoS can be easily achieved even when the packet payload is encrypted with IPSec.
New Protocol for Neighboring Node Interaction

The Neighbor Discovery protocol for IPv6 is a series of Internet Control Message Protocol for IPv6 (ICMPv6) messages that manage the interaction of neighboring nodes (that is, nodes on the same link). Neighbor Discovery replaces Address Resolution Protocol (ARP), ICMPv4 Router Discovery, and ICMPv4 Redirect messages with efficient multicast and unicast messages and provides additional functionality. For more information, see Neighbor Discovery (ND).
421
Extensibility
IPv6 can be extended for new features by adding extension headers after the IPv6 header. Unlike the IPv4 header, which can only support 40 bytes of options, the size of IPv6 extension headers is only constrained by the size of the IPv6 packet.
422
Appendix D 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.
423
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.
424
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.
425
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.
426
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
427

LP 6.20 Ug

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

LP 6.20 Ug

Uploaded by

Copyright:

Available Formats

LinkProof User Guide

Software Version 6.20

LinkProof User Guide

Document ID: RDWR-LP-V0620_UG1202

LinkProof User Guide

Document ID: RDWR-LP-V0620_UG1202

LinkProof User Guide

Document ID: RDWR-LP-V0620_UG1202

LinkProof User Guide

Notice traitant du copyright

Document ID: RDWR-LP-V0620_UG1202

LinkProof User Guide

Document ID: RDWR-LP-V0620_UG1202

LinkProof User Guide

Document ID: RDWR-LP-V0620_UG1202

LinkProof User Guide

Figure 1: Electrical Shock Hazard Label

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

Document ID: RDWR-LP-V0620_UG1202

LinkProof User Guide

Figure 3: Statement for Class A VCCI-certified Equipment

Document ID: RDWR-LP-V0620_UG1202

LinkProof User Guide

Figure 4: Statement for Class B VCCI-certified Equipment

Figure 5: KCCKorea Communications Commission Certificate of Broadcasting and Communication Equipment

Figure 6: Statement For Class A KCC-certified Equipment in Korean

Document ID: RDWR-LP-V0620_UG1202

LinkProof User Guide

Document ID: RDWR-LP-V0620_UG1202

LinkProof User Guide

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

Document ID: RDWR-LP-V0620_UG1202

LinkProof User Guide

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

Document ID: RDWR-LP-V0620_UG1202

LinkProof User Guide

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

Document ID: RDWR-LP-V0620_UG1202

LinkProof User Guide

Document ID: RDWR-LP-V0620_UG1202

LinkProof User Guide

Figure 13: Warnetikett Stromschlaggefahr

Document ID: RDWR-LP-V0620_UG1202

LinkProof User Guide

Figure 14: Sicherheitshinweis in chinesischer Sprache fr Systeme mit Doppelspeisung

Document ID: RDWR-LP-V0620_UG1202

LinkProof User Guide

ERKLRUNG DER VCCI ZU ELEKTROMAGNETISCHER INTERFERENZ

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

Figure 16: Erklrung zu VCCI-zertifizierten Gerten der Klasse B

Figure 17: KCCKorea Communications Commission Zertifikat fr Rundfunk-und Nachrichtentechnik

Figure 18: Erklrung zu KCC-zertifizierten Gerten der Klasse A

Document ID: RDWR-LP-V0620_UG1202

LinkProof User Guide

Document ID: RDWR-LP-V0620_UG1202

LinkProof User Guide

Document ID: RDWR-LP-V0620_UG1202

LinkProof User Guide Table of Contents

LinkProof Modules ....................................................................................................... 34

IPv6 Support ................................................................................................................ 36 Management Tools ...................................................................................................... 37

Chapter 2 Device Management ........................................................................... 39

Document ID: RDWR-LP-V0620_UG1202

LinkProof User Guide Table of Contents