Radware LLB

LinkProof User GuideSoftware Version 6.12

Document ID: RDWR-LP-V0612_UG1010September, 2010

LinkProof User Guide

2 Document ID: RDWR-LP-V0612_UG1010


Document ID: RDWR-LP-V0612_UG1010 3

Important NoticesThe following important notices are presented in English, French, and German.

Important NoticesThis guide is delivered subject to the following conditions and restrictions:

Copyright Radware Ltd. 2006–2010. All rights reserved.

The copyright and all other intellectual property rights and trade secrets included in this guide are owned by Radware Ltd.

The guide is provided to Radware customers for the sole purpose of obtaining information with respect to the installation and use of the Radware products described in this document, and may not be used for any other purpose.

The information contained in this guide is proprietary to Radware and must be kept in strict confidence.

It is strictly forbidden to copy, duplicate, reproduce or disclose this guide or any part thereof without the prior written consent of Radware.

Notice importanteCe guide est sujet aux conditions et restrictions suivantes : Copyright Radware Ltd. 2006–2010. Tous droits réservés.

Le copyright ainsi que tout autre droit lié à la propriété intellectuelle et aux secrets industriels contenus dans ce guide sont la propriété de Radware Ltd.

Ce guide d'informations est fourni à nos clients dans le cadre de l'installation et de l'usage des produits de Radware décrits dans ce document et ne pourra être utilisé dans un but autre que celui pour lequel il a été conçu.

Les informations répertoriées dans ce document restent la propriété de Radware et doivent être conservées de manière confidentielle.

Il est strictement interdit de copier, reproduire ou divulguer des informations contenues dans ce manuel sans avoir obtenu le consentement préalable écrit de Radware.

Wichtige AnmerkungDieses Handbuch wird vorbehaltlich folgender Bedingungen und Einschränkungen ausgeliefert: Copyright Radware Ltd. 2006–2010. Alle Rechte vorbehalten.

Das Urheberrecht und alle anderen in diesem Handbuch enthaltenen Eigentumsrechte und Geschäftsgeheimnisse sind Eigentum von Radware Ltd.

Dieses Handbuch wird Kunden von Radware mit dem ausschließlichen Zweck ausgehändigt, Informationen zu Montage und Benutzung der in diesem Dokument beschriebene Produkte von Radware bereitzustellen. Es darf für keinen anderen Zweck verwendet werden.

Die in diesem Handbuch enthaltenen Informationen sind Eigentum von Radware und müssen streng vertraulich behandelt werden.

Es ist streng verboten, dieses Handbuch oder Teile daraus ohne vorherige schriftliche Zustimmung von Radware zu kopieren, vervielfältigen, reproduzieren oder offen zu legen.



Copyright Notices The following copyright notices are presented in English, French, and German.

Copyright NoticesThis 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 <[email protected]>

@author Antoon Bosselaers <[email protected]>

@author Paulo Barreto <[email protected]>

The OnDemand Switch may use software components licensed under the GNU General Public License Agreement Version 2 (GPL v.2) including LinuxBios and Filo open source projects. The source code of the LinuxBios and Filo is available from Radware upon request. A copy of the license can be viewed at: http://www.gnu.org/licenses/old-licenses/gpl-2.0.html

This code is hereby placed in the public domain.

This product contains code developed by the OpenBSD Project

Copyright (c) 1983, 1990, 1992, 1993, 1995

The Regents of the University of California. All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

3. Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

This product includes software developed by Markus Friedl

This product includes software developed by Theo de Raadt

This product includes software developed by Niels Provos

This product includes software developed by Dug Song

This product includes software developed by Aaron Campbell

This product includes software developed by Damien Miller

This product includes software developed by Kevin Steves

This product includes software developed by Daniel Kouril

This product includes software developed by Wesley Griffin

This product includes software developed by Per Allansson

This product includes software developed by Nils Nordman

This product includes software developed by Simon Wilkinson

http://www.gnu.org/licenses/old-licenses/gpl-2.0.html



Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

ALL THE SOFTWARE MENTIONED ABOVE IS PROVIDED BY THE AUTHOR “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.

IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Notice traitant du copyrightCe produit renferme des codes développés dans le cadre du projet OpenSSL.

Ce produit inclut un logiciel développé dans le cadre du projet OpenSSL. Pour un usage dans la boîte à outils OpenSSL (http://www.openssl.org/).

Copyright (c) 1998-2005 Le projet OpenSSL. Tous droits réservés. Ce produit inclut la catégorie de chiffre Rijndael.

L'implémentation de Rijindael par Vincent Rijmen, Antoon Bosselaers et Paulo Barreto est du domaine public et distribuée sous les termes de la licence suivante :

@version 3.0 (Décembre 2000)

Code ANSI C code pour Rijndael (actuellement AES)



@author Paulo Barreto <[email protected]>.

Le commutateur OnDemand peut utiliser les composants logiciels sous licence, en vertu des termes de la licence GNU General Public License Agreement Version 2 (GPL v.2), y compris les projets à source ouverte LinuxBios et Filo. Le code source de LinuxBios et Filo est disponible sur demande auprès de Radware. Une copie de la licence est répertoriée sur:


Ce code est également placé dans le domaine public.

Ce produit renferme des codes développés dans le cadre du projet OpenSSL.

Copyright (c) 1983, 1990, 1992, 1993, 1995

Les membres du conseil de l'Université de Californie. Tous droits réservés.

La distribution et l'usage sous une forme source et binaire, avec ou sans modifications, est autorisée pour autant que les conditions suivantes soient remplies :

1. La distribution d'un code source doit inclure la notice de copyright mentionnée ci-dessus, cette liste de conditions et l'avis de non-responsabilité suivant.

2. La distribution, sous une forme binaire, doit reproduire dans la documentation et/ou dans tout autre matériel fourni la notice de copyright mentionnée ci-dessus, cette liste de conditions et l'avis de non-responsabilité suivant.

3. Le nom de l'université, ainsi que le nom des contributeurs ne seront en aucun cas utilisés pour approuver ou promouvoir un produit dérivé de ce programme sans l'obtention préalable d'une autorisation écrite.

Ce produit inclut un logiciel développé par Markus Friedl




Ce produit inclut un logiciel développé par Theo de Raadt Ce produit inclut un logiciel développé par Niels Provos

Ce produit inclut un logiciel développé par Dug Song

Ce produit inclut un logiciel développé par Aaron Campbell Ce produit inclut un logiciel développé par Damien Miller

Ce produit inclut un logiciel développé par Kevin Steves

Ce produit inclut un logiciel développé par Daniel Kouril

Ce produit inclut un logiciel développé par Wesley Griffin

Ce produit inclut un logiciel développé par Per Allansson

Ce produit inclut un logiciel développé par Nils Nordman

Ce produit inclut un logiciel développé par Simon Wilkinson.

La distribution et l'usage sous une forme source et binaire, avec ou sans modifications, est autorisée pour autant que les conditions suivantes soient remplies :

1. La distribution d'un code source doit inclure la notice de copyright mentionnée ci-dessus, cette liste de conditions et l'avis de non-responsabilité suivant.

2. La distribution, sous une forme binaire, doit reproduire dans la documentation et/ou dans tout autre matériel fourni la notice de copyright mentionnée ci-dessus, cette liste de conditions et l'avis de non-responsabilité suivant.

LE LOGICIEL MENTIONNÉ CI-DESSUS EST FOURNI TEL QUEL PAR LE DÉVELOPPEUR ET TOUTE GARANTIE, EXPLICITE OU IMPLICITE, Y COMPRIS, MAIS SANS S'Y LIMITER, TOUTE GARANTIE IMPLICITE DE QUALITÉ MARCHANDE ET D'ADÉQUATION À UN USAGE PARTICULIER EST EXCLUE.

EN AUCUN CAS L'AUTEUR NE POURRA ÊTRE TENU RESPONSABLE DES DOMMAGES DIRECTS, INDIRECTS, ACCESSOIRES, SPÉCIAUX, EXEMPLAIRES OU CONSÉCUTIFS (Y COMPRIS, MAIS SANS S'Y LIMITER, L'ACQUISITION DE BIENS OU DE SERVICES DE REMPLACEMENT, LA PERTE D'USAGE, DE DONNÉES OU DE PROFITS OU L'INTERRUPTION DES AFFAIRES), QUELLE QU'EN SOIT LA CAUSE ET LA THÉORIE DE RESPONSABILITÉ, QU'IL S'AGISSE D'UN CONTRAT, DE RESPONSABILITÉ STRICTE OU D'UN ACTE DOMMAGEABLE (Y COMPRIS LA NÉGLIGENCE OU AUTRE), DÉCOULANT DE QUELLE QUE FAÇON QUE CE SOIT DE L'USAGE DE CE LOGICIEL, MÊME S'IL A ÉTÉ AVERTI DE LA POSSIBILITÉ D'UN TEL DOMMAGE.

CopyrightvermerkeDieses Produkt enthält einen vom OpenSSL-Projekt entwickelten Code

Dieses Produkt enthält vom OpenSSL-Projekt entwickelte Software. Zur Verwendung im OpenSSL Toolkit. (http://www.openssl.org/).

Copyright (c) 1998-2005 The OpenSSL Project. Alle Rechte vorbehalten. Dieses Produkt enthält die Rijndael cipher

Die Rijndael-Implementierung von Vincent Rijndael, Anton Bosselaers und Paulo Barreto ist öffentlich zugänglich und wird unter folgender Lizenz vertrieben:

@version 3.0 (December 2000)

Optimierter ANSI C Code für den Rijndael cipher (jetzt AES)



@author Paulo Barreto <[email protected]>

Der OnDemand Switch verwendet möglicherweise Software, die im Rahmen der DNU Allgemeine Öffentliche Lizenzvereinbarung Version 2 (GPL v.2) lizensiert sind, einschließlich LinuxBios und Filo Open Source-Projekte. Der Quellcode von LinuxBios und Filo ist bei Radware auf Anfrage erhältlich. Eine Kopie dieser Lizenz kann eingesehen werden unter:


Dieser Code wird hiermit allgemein zugänglich gemacht.

Dieses Produkt enthält 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 binärem Format, mit oder ohne Veränderungen, sind unter folgenden Bedingungen erlaubt:

1. Die Verbreitung von Quellcodes muss den voranstehenden Copyrightvermerk, diese Liste von Bedingungen und den folgenden Haftungsausschluss beibehalten.

2. Die Verbreitung in binärem Format muss den voranstehenden Copyrightvermerk, diese Liste von Bedingungen und den folgenden Haftungsausschluss in der Dokumentation und/oder andere Materialien, die mit verteilt werden, reproduzieren.

3. Weder der Name der Universität noch die Namen der Beitragenden dürfen ohne ausdrückliche vorherige schriftliche Genehmigung verwendet werden, um von dieser Software abgeleitete Produkte zu empfehlen oder zu bewerben.

Dieses Produkt enthält von Markus Friedl entwickelte Software Dieses Produkt enthält von Theo de Raadt entwickelte Software Dieses Produkt enthält von Niels Provos entwickelte Software Dieses Produkt enthält von Dug Song entwickelte Software

Dieses Produkt enthält von Aaron Campbell entwickelte Software Dieses Produkt enthält von Damien Miller entwickelte Software Dieses Produkt enthält von Kevin Steves entwickelte Software Dieses Produkt enthält von Daniel Kouril entwickelte Software Dieses Produkt enthält von Wesley Griffin entwickelte Software Dieses Produkt enthält von Per Allansson entwickelte Software Dieses Produkt enthält von Nils Nordman entwickelte Software

Dieses Produkt enthält von Simon Wilkinson entwickelte Software

Die Verbreitung und Verwendung in Quell- und binärem Format, mit oder ohne Veränderungen, sind unter folgenden Bedingungen erlaubt:

1. Die Verbreitung von Quellcodes muss den voranstehenden Copyrightvermerk, diese Liste von Bedingungen und den folgenden Haftungsausschluss beibehalten.

2. Die Verbreitung in binärem Format muss den voranstehenden Copyrightvermerk, diese Liste von Bedingungen und den folgenden Haftungsausschluss in der Dokumentation und/oder andere Materialien, die mit verteilt werden, reproduzieren.

SÄMTLICHE VORGENANNTE SOFTWARE WIRD VOM AUTOR IM IST-ZUSTAND ("AS IS") BEREITGESTELLT. JEGLICHE AUSDRÜCKLICHEN ODER IMPLIZITEN GARANTIEN, EINSCHLIESSLICH, DOCH NICHT BESCHRÄNKT AUF DIE IMPLIZIERTEN GARANTIEN DER MARKTGÄNGIGKEIT UND DER ANWENDBARKEIT FÜR EINEN BESTIMMTEN ZWECK, SIND AUSGESCHLOSSEN.

UNTER KEINEN UMSTÄNDEN HAFTET DER AUTOR FÜR DIREKTE ODER INDIREKTE SCHÄDEN, FÜR BEI VERTRAGSERFÜLLUNG ENTSTANDENE SCHÄDEN, FÜR BESONDERE SCHÄDEN, FÜR SCHADENSERSATZ MIT STRAFCHARAKTER, ODER FÜR FOLGESCHÄDEN EINSCHLIESSLICH, DOCH NICHT BESCHRÄNKT AUF, ERWERB VON ERSATZGÜTERN ODER ERSATZLEISTUNGEN; VERLUST AN NUTZUNG, DATEN ODER GEWINN; ODER GESCHÄFTSUNTERBRECHUNGEN) GLEICH, WIE SIE ENTSTANDEN SIND, UND FÜR JEGLICHE ART VON HAFTUNG, SEI ES VERTRÄGE, GEFÄHRDUNGSHAFTUNG, ODER DELIKTISCHE HAFTUNG (EINSCHLIESSLICH FAHRLÄSSIGKEIT ODER ANDERE), DIE IN JEGLICHER FORM FOLGE DER BENUTZUNG DIESER SOFTWARE IST, SELBST WENN AUF DIE MÖGLICHKEIT EINES SOLCHEN SCHADENS HINGEWIESEN WURDE.

Safety InstructionsThe following safety instructions are presented in English, French, and German.

Safety InstructionsCAUTION

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-4-11For CE MARK Compliance. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. This equipment generates, uses and can radiate radio frequency energy and, if not installed and used in accordance with the instruction manual, may cause harmful interference to radio communications. Operation of this equipment in a residential area is likely to cause harmful interference in which case the user is required to correct the interference at his own expense.

VCCI ELECTROMAGNETIC-INTERFERENCE STATEMENTS

Figure 3: Statment for Class A VCCI-certified Equipment

Translation of Figure 3 - Statment for Class A VCCI-certified Equipment, page 9:

This is a Class A product based on the standard of the Voluntary Control Council for Interference by Information Technology Equipment (VCCI). If this equipment is used in a domestic environment, radio disturbance may occur, in which case, the user may be required to take corrective action.

Figure 4: Statment for Class B VCCI-certified Equipment



Translation of Figure 4 - Statment for Class B VCCI-certified Equipment, page 9:

This is a Class B product based on the standard of the Voluntary Control Council for Interference by Information Technology Equipment (VCCI). If this is used near a radio or television receiver in a domestic environment, it may cause radio interference. Install and use the equipment according to the instruction manual.

SPECIAL NOTICE FOR NORTH AMERICAN USERS

For North American power connection, select a power supply cord that is UL Listed and CSA Certified 3 - conductor, [18 AWG], terminated in a molded on plug cap rated 125 V, [5 A], with a minimum length of 1.5m [six feet] but no longer than 4.5m...For European connection, select a power supply cord that is internationally harmonized and marked “<HAR>”, 3 - conductor, 0,75 mm2 minimum mm2 wire, rated 300 V, with a PVC insulated jacket. The cord must have a molded on plug cap rated 250 V, 3 A.”.

RESTRICT AREA ACCESS

The DC powered equipment should only be installed in a Restricted Access Area.

INSTALLATION CODES

This device must be installed according to country national electrical codes. For North America, equipment must be installed in accordance with the US National Electrical Code, Articles 110 - 16, 110 -17, and 110 -18 and the Canadian Electrical Code, Section 12.

INTERCONNECTION OF UNITS

Cables for connecting to the unit RS232 and Ethernet Interfaces must be UL certified type DP-1 or DP-2. (Note- when residing in non LPS circuit)

OVERCURRENT PROTECTION

A readily accessible listed branch-circuit over current protective device rated 15 A must be incorporated in the building wiring for each power input.

REPLACEABLE BATTERIES

If equipment is provided with a replaceable battery, and is replaced by an incorrect battery type, then an explosion may occur. This is the case for some Lithium batteries and the following is applicable:

• If the battery is placed in an Operator Access Area, there is a marking close to the battery or a statement in both the operating and service instructions.

• If the battery is placed elsewhere in the equipment, there is a marking close to the battery or a statement in the service instructions.

This marking or statement includes the following text warning:

CAUTION

RISK OF EXPLOSION IF BATTERY IS REPLACED BY AN INCORRECT BATTERY TYPE. DISPOSE OF USED BATTERIES ACCORDING TO THE INSTRUCTIONS.

Caution – To Reduce the Risk of Electrical Shock and Fire

1. This equipment is designed to permit connection between the earthed conductor of the DC supply circuit and the earthing conductor equipment. See Installation Instructions.

2. All servicing must be undertaken only by qualified service personnel. There are not user serviceable parts inside the unit.

3. DO NOT plug in, turn on or attempt to operate an obviously damaged unit.

4. Ensure that the chassis ventilation openings in the unit are NOT BLOCKED.

5. Replace a blown fuse ONLY with the same type and rating as is marked on the safety label adjacent to the power inlet, housing the fuse.

6. Do not operate the device in a location where the maximum ambient temperature exceeds 40°C/104°F.



7. Be sure to unplug the power supply cord from the wall socket BEFORE attempting to remove and/or check the main power fuse. CLASS 1 LASER PRODUCT AND REFERENCE TO THE MOST RECENT LASER STANDARDS IEC 60 825-1:1993 + A1:1997 + A2:2001 AND EN 60825-1:1994+A1:1996+ A2:2001

AC units for Denmark, Finland, Norway, Sweden (marked on product):

• Denmark - “Unit is class I - unit to be used with an AC cord set suitable with Denmark deviations. The cord includes an earthing conductor. The Unit is to be plugged into a wall socket outlet which is connected to a protective earth. Socket outlets which are not connected to earth are not to be used!”

• Finland - (Marking label and in manual) - “Laite on liitettävä suojamaadoituskoskettimilla varustettuun pistorasiaan”

• Norway (Marking label and in manual) - “Apparatet må tilkoples jordet stikkontakt”

• Unit is intended for connection to IT power systems for Norway only.

• Sweden (Marking label and in manual) - “Apparaten skall anslutas till jordat uttag.”

To connect the power connection:

1. Connect the power cable to the main socket, located on the rear panel of the device.

2. Connect the power cable to the grounded AC outlet.

CAUTION

Risk of electric shock and energy hazard. Disconnecting one power supply disconnects only one power supply module. To isolate the unit completely, disconnect all power supplies.

Instructions de sécuritéAVERTISSEMENT

Un dispositif de déconnexion facilement accessible sera incorporé au câblage du bâtiment.

En raison des risques de chocs électriques et des dangers énergétiques, mécaniques et d'incendie, chaque procédure impliquant l'ouverture des panneaux ou le remplacement de composants sera exécutée par du personnel qualifié.

Pour réduire les risques d'incendie et de chocs électriques, déconnectez le dispositif du bloc d'alimentation avant de retirer le couvercle ou les panneaux.

La figure suivante montre l'étiquette d'avertissement apposée sur les plateformes Radware dotées de plus d'une source d'alimentation électrique.

Figure 1 : Étiquette d'avertissement de danger de chocs électriques

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

AVERTISSEMENT DE SÉCURITÉ POUR LES SYSTÈMES DOTÉS DE DEUX SOURCES D'ALIMENTATION ÉLECTRIQUE (EN CHINOIS)

La figure suivante représente l'étiquette d'avertissement pour les plateformes Radware dotées de deux sources d'alimentation électrique.



Figure 6: Avertissement de sécurité pour les systèmes dotes de deux sources d'alimentation électrique (en chinois)

Traduction de la Figure 6 - Avertissement de sécurité pour les systèmes dotes de deux sources d'alimentation électrique (en chinois), page 12:

Cette unité est dotée de plus d'une source d'alimentation électrique. Déconnectez toutes les sources d'alimentation électrique avant d'entretenir l'appareil ceci pour éviter tout choc électrique.

ENTRETIEN

N'effectuez aucun entretien autre que ceux répertoriés dans le manuel d'instructions, à moins d'être qualifié en la matière. Aucune pièce à l'intérieur de l'unité ne peut être remplacée ou réparée.

HAUTE TENSION

Tout réglage, opération d'entretien et réparation de l'instrument ouvert sous tension doit être évité. Si cela s'avère indispensable, confiez cette opération à une personne qualifiée et consciente des dangers impliqués.

Les condensateurs au sein de l'unité risquent d'être chargés même si l'unité a été déconnectée de la source d'alimentation électrique.

MISE A LA TERRE

Avant de connecter ce dispositif à la ligne électrique, les vis de protection de la borne de terre de cette unité doivent être reliées au système de mise à la terre du bâtiment.

LASER

Cet équipement est un produit laser de classe 1, conforme à la norme IEC60825 - 1 : 1993 + A1 :1997 + A2 :2001.

FUSIBLES

Assurez-vous que, seuls les fusibles à courant nominal requis et de type spécifié sont utilisés en remplacement. L'usage de fusibles réparés et le court-circuitage des porte-fusibles doivent être évités. Lorsqu'il est pratiquement certain que la protection offerte par les fusibles a été détériorée, l'instrument doit être désactivé et sécurisé contre toute opération involontaire.

TENSION DE LIGNE

Avant de connecter cet instrument à la ligne électrique, vérifiez que la tension de la source d'alimentation correspond aux exigences de l'instrument. Consultez les spécifications propres à l'alimentation nominale correcte du dispositif.

Les plateformes alimentées en 48 CC ont une tolérance d'entrée comprise entre 36 et 72 V CC. MODIFICATIONS DES SPÉCIFICATIONS

Les spécifications sont sujettes à changement sans notice préalable.

Remarque: Cet équipement a été testé et déclaré conforme aux limites définies pour un appareil numérique de classe A, conformément au paragraphe 15B de la réglementation FCC et EN55022 Classe A, EN 55024, EN 61000-3-2 ; EN 61000-3-3 ; IEC 61000 4-2 to 4-6, IEC 61000 4-8 and IEC 61000-4-11, pour la marque de conformité de la CE. Ces limites sont fixées pour fournir une protection raisonnable contre les interférences nuisibles, lorsque l'équipement est utilisé dans un environnement commercial. Cet équipement génère, utilise et peut émettre des fréquences radio et, s'il n'est pas installé et utilisé conformément au manuel d'instructions, peut entraîner des interférences nuisibles aux communications radio. Le fonctionnement de cet équipement dans une zone résidentielle est susceptible de provoquer des interférences nuisibles, auquel cas l'utilisateur devra corriger le problème à ses propres frais.

DÉCLARATIONS SUR LES INTERFÉRENCES ÉLECTROMAGNÉTIQUES VCCI



Figure 7: Déclaration pour l'équipement de classe A certifié VCCI

Traduction de la Figure 7 - Déclaration pour l'équipement de classe A certifié VCCI, page 13:

Il s'agit d'un produit de classe A, basé sur la norme du Voluntary Control Council for Interference by Information Technology Equipment (VCCI). Si cet équipement est utilisé dans un environnement domestique, des perturbations radioélectriques sont susceptibles d'apparaître. Si tel est le cas, l'utilisateur sera tenu de prendre des mesures correctives.

Figure 8: Déclaration pour l'équipement de classe B certifié VCCI

Traduction de la Figure 8 - Déclaration pour l'équipement de classe B certifié VCCI, page 13:

Il s'agit d'un produit de classe B, basé sur la norme du Voluntary Control Council for Interference by Information Technology Equipment (VCCI). S'il est utilisé à proximité d'un poste de radio ou d'une télévision dans un environnement domestique, il peut entraîner des interférences radio.

Installez et utilisez l'équipement selon le manuel d'instructions.

NOTICE SPÉCIALE POUR LES UTILISATEURS NORD-AMÉRICAINS

Pour un raccordement électrique en Amérique du Nord, sélectionnez un cordon d'alimentation homologué UL et certifié CSA 3 - conducteur, [18 AWG], muni d'une prise moulée à son extrémité, de 125 V, [5 A], d'une longueur minimale de 1,5 m [six pieds] et maximale de 4,5m...Pour la connexion européenne, choisissez un cordon d'alimentation mondialement homologué et marqué "<HAR>", 3 - conducteur, câble de 0,75 mm2 minimum, de 300 V, avec une gaine en PVC isolée. La prise à l'extrémité du cordon, sera dotée d'un sceau moulé indiquant: 250 V, 3 A.".

ZONE A ACCÈS RESTREINT

L'équipement alimenté en CC ne pourra être installé que dans une zone à accès restreint. CODES D'INSTALLATION

Ce dispositif doit être installé en conformité avec les codes électriques nationaux. En Amérique du Nord, l'équipement sera installé en conformité avec le code électrique national américain, articles 110-16, 110 -17, et 110 -18 et le code électrique canadien, Section 12. INTERCONNEXION DES UNÎTES.

Les câbles de connexion à l'unité RS232 et aux interfaces Ethernet seront certifiés UL, type DP-1 ou DP-2. (Remarque- s'ils ne résident pas dans un circuit LPS) PROTECTION CONTRE LES SURCHARGES.

Un circuit de dérivation, facilement accessible, sur le dispositif de protection du courant de 15 A doit être intégré au câblage du bâtiment pour chaque puissance consommée.

BATTERIES REMPLAÇABLES



Si l'équipement est fourni avec une batterie, et qu'elle est remplacée par un type de batterie incorrect, elle est susceptible d'exploser. C'est le cas pour certaines batteries au lithium, les éléments suivants sont donc applicables :

• Si la batterie est placée dans une zone d'accès opérateur, une marque est indiquée sur la batterie ou une remarque est insérée, aussi bien dans les instructions d'exploitation que d'entretien.

• Si la batterie est placée ailleurs dans l'équipement, une marque est indiquée sur la batterie ou une remarque est insérée dans les instructions d'entretien.

Cette marque ou remarque inclut l'avertissement textuel suivant : AVERTISSEMENT

RISQUE D'EXPLOSION SI LA BATTERIE EST REMPLACÉE PAR UN MODÈLE INCORRECT. METTRE AU REBUT LES BATTERIES CONFORMÉMENT AUX INSTRUCTIONS.

Attention - Pour réduire les risques de chocs électriques et d'incendie

1. Cet équipement est conçu pour permettre la connexion entre le conducteur de mise à la terre du circuit électrique CC et l'équipement de mise à la terre. Voir les instructions d'installation.

2. Tout entretien sera entrepris par du personnel qualifié. Aucune pièce à l'intérieur de l'unité ne peut être remplacée ou réparée.

3. NE branchez pas, n'allumez pas ou n'essayez pas d'utiliser une unité manifestement endommagée.

4. Vérifiez que l'orifice de ventilation du châssis dans l'unité n'est PAS OBSTRUE.

5. Remplacez le fusible endommagé par un modèle similaire de même puissance, tel qu'indiqué sur l'étiquette de sécurité adjacente à l'arrivée électrique hébergeant le fusible.

6. Ne faites pas fonctionner l'appareil dans un endroit, où la température ambiante dépasse la valeur maximale autorisée. 40°C/104°F.

7. Débranchez le cordon électrique de la prise murale AVANT d'essayer de retirer et/ou de vérifier le fusible d'alimentation principal.

PRODUIT LASER DE CLASSE 1 ET RÉFÉRENCE AUX NORMES LASER LES PLUS RÉCENTES : IEC 60

825-1:1993 + A1 :1997 + A2 :2001 ET EN 60825-1:1994+A1 :1996+ A2 :2001

Unités à CA pour le Danemark, la Finlande, la Norvège, la Suède (indiqué sur le produit) :

• Danemark - Unité de classe 1 - qui doit être utilisée avec un cordon CA compatible avec les déviations du Danemark. Le cordon inclut un conducteur de mise à la terre. L'unité sera branchée à une prise murale, mise à la terre. Les prises non-mises à la terre ne seront pas utilisées !

• Finlande - (Étiquette et inscription dans le manuel) - Laite on liitettävä suojamaadoituskoskettimilla varustettuun pistorasiaan"

• Norvège (Étiquette et inscription dans le manuel) - "Apparatet må tilkoples jordet stikkontakt"

• L'unité peut être connectée à un système électrique IT (en Norvège uniquement).

• Suède (Étiquette et inscription dans le manuel) - "Apparaten skall anslutas till jordat uttag."

Pour brancher à l'alimentation électrique :

1. Branchez le câble d'alimentation à la prise principale, située sur le panneau arrière de l'unité.

2. Connectez le câble d'alimentation à la prise CA mise à la terre. AVERTISSEMENT

Risque de choc électrique et danger énergétique. La déconnexion d'une source d'alimentation électrique ne débranche qu'un seul module électrique. Pour isoler complètement l'unité, débranchez toutes les sources d'alimentation électrique.

ATTENTION

Risque de choc et de danger électriques. Le débranchement d'une seule alimentation stabilisée ne débranche qu'un module "Alimentation Stabilisée". Pour Isoler complètement le module en cause, il faut débrancher toutes les alimentations stabilisées.



Attention: Pour Réduire Les Risques d'Électrocution et d'Incendie

1. Toutes les opérations d'entretien seront effectuées UNIQUEMENT par du personnel d'entretien qualifié. Aucun composant ne peut être entretenu ou remplacée par l'utilisateur.

2. NE PAS connecter, mettre sous tension ou essayer d'utiliser une unité visiblement défectueuse.

3. Assurez-vous que les ouvertures de ventilation du châssis NE SONT PAS OBSTRUÉES.

4. Remplacez un fusible qui a sauté SEULEMENT par un fusible du même type et de même capacité, comme indiqué sur l'étiquette de sécurité proche de l'entrée de l'alimentation qui contient le fusible.

5. NE PAS UTILISER l'équipement dans des locaux dont la température maximale dépasse 40 degrés Centigrades.

6. Assurez vous que le cordon d'alimentation a été déconnecté AVANT d'essayer de l'enlever et/ou vérifier le fusible de l'alimentation générale.

SicherheitsanweisungenVORSICHT

Die Elektroinstallation des Gebäudes muss ein unverzüglich zugängliches Stromunterbrechungsgerät integrieren.

Aufgrund des Stromschlagrisikos und der Energie-, mechanische und Feuergefahr dürfen Vorgänge, in deren Verlauf Abdeckungen entfernt oder Elemente ausgetauscht werden, ausschließlich von qualifiziertem Servicepersonal durchgeführt werden.

Zur Reduzierung der Feuer- und Stromschlaggefahr muss das Gerät vor der Entfernung der Abdeckung oder der Paneele von der Stromversorgung getrennt werden.

Folgende Abbildung zeigt das VORSICHT-Etikett, das auf die Radware-Plattformen mit Doppelspeisung angebracht ist.

Figure 9: Warnetikett Stromschlaggefahr

SICHERHEITSHINWEIS IN CHINESISCHER SPRACHE FÜR SYSTEME MIT DOPPELSPEISUNG

Die folgende Abbildung ist die Warnung für Radware-Plattformen mit Doppelspeisung.

Figure 10: Sicherheitshinweis in chinesischer Sprache für Systeme mit Doppelspeisung

Übersetzung von Figure 10 - Sicherheitshinweis in chinesischer Sprache für Systeme mit Doppelspeisung, page 15:



Die Einheit verfügt über mehr als eine Stromversorgungsquelle. Ziehen Sie zur Verhinderung von Stromschlag vor Wartungsarbeiten sämtliche Stromversorgungsleitungen ab.

WARTUNG

Führen Sie keinerlei Wartungsarbeiten aus, die nicht in der Betriebsanleitung angeführt sind, es sei denn, Sie sind dafür qualifiziert. Es gibt innerhalb des Gerätes keine wartungsfähigen Teile.

HOCHSPANNUNG

Jegliche Einstellungs-, Instandhaltungs- und Reparaturarbeiten am geöffneten Gerät unter Spannung müssen so weit wie möglich vermieden werden. Sind sie nicht vermeidbar, dürfen sie ausschließlich von qualifizierten Personen ausgeführt werden, die sich der Gefahr bewusst sind.

Innerhalb des Gerätes befindliche Kondensatoren können auch dann noch Ladung enthalten, wenn das Gerät von der Stromversorgung abgeschnitten wurde.

ERDUNG

Bevor das Gerät an die Stromversorgung angeschlossen wird, müssen die Schrauben der Erdungsleitung des Gerätes an die Erdung der Gebäudeverkabelung angeschlossen werden.

LASER

Dieses Gerät ist ein Laser-Produkt der Klasse 1 in Übereinstimmung mit IEC60825 - 1: 1993 + A1:1997 + A2:2001 Standard.

SICHERUNGEN

Vergewissern Sie sich, dass nur Sicherungen mit der erforderlichen Stromstärke und der angeführten Art verwendet werden. Die Verwendung reparierter Sicherungen sowie die Kurzschließung von Sicherungsfassungen muss vermieden werden. In Fällen, in denen wahrscheinlich ist, dass der von den Sicherungen gebotene Schutz beeinträchtigt ist, muss das Gerät abgeschaltet und gegen unbeabsichtigten Betrieb gesichert werden.

LEITUNGSSPANNUNG

Vor Anschluss dieses Gerätes an die Stromversorgung ist zu gewährleisten, dass die Spannung der Stromquelle den Anforderungen des Gerätes entspricht. Beachten Sie die technischen Angaben bezüglich der korrekten elektrischen Werte des Gerätes.

Plattformen mit 48 V DC verfügen über eine Eingangstoleranz von 36-72 V DC. ÄNDERUNGEN DER TECHNISCHEN ANGABEN

Änderungen der technischen Spezifikationen bleiben vorbehalten.

Hinweis: Dieses Gerät wurde geprüft und entspricht den Beschränkungen von digitalen Geräten der Klasse 1 gemäß Teil 15B FCC-Vorschriften und EN55022 Klasse A, EN55024; EN 61000-3-2; EN; IEC 61000 4-2 to 4-6, IEC 61000 4-8 und IEC 61000-4- 11 für Konformität mit der CE-Bezeichnung. Diese Beschränkungen dienen dem angemessenen Schutz vor schädlichen Interferenzen bei Betrieb des Gerätes in kommerziellem Umfeld. Dieses Gerät erzeugt, verwendet und strahlt elektromagnetische Hochfrequenzstrahlung aus. Wird es nicht entsprechend den Anweisungen im Handbuch montiert und benutzt, könnte es mit dem Funkverkehr interferieren und ihn beeinträchtigen. Der Betrieb dieses Gerätes in Wohnbereichen wird höchstwahrscheinlich zu schädlichen Interferenzen führen. In einem solchen Fall wäre der Benutzer verpflichtet, diese Interferenzen auf eigene Kosten zu korrigieren.

ERKLÄRUNG DER VCCI ZU ELEKTROMAGNETISCHER INTERFERENZ

Figure 11: Erklärung zu VCCI-zertifizierten Geräten der Klasse A



Übersetzung von Figure 11 - Erklärung zu VCCI-zertifizierten Geräten der Klasse A, page 16:

Dies ist ein Produkt der Klasse A gemäß den Normen des Voluntary Control Council for Interference by Information Technology Equipment (VCCI). Wird dieses Gerät in einem Wohnbereich benutzt, können elektromagnetische Störungen auftreten. In einem solchen Fall wäre der Benutzer verpflichtet, korrigierend einzugreifen.

Figure 12: Erklärung zu VCCI-zertifizierte Geräte der Klasse B

Übersetzung von Figure 12 - Erklärung zu VCCI-zertifizierte Geräte der Klasse B, page 17:

Dies ist ein Produkt der Klasse B gemäß den Normen des Voluntary Control Council for Interference by Information Technology Equipment (VCCI). Wird dieses Gerät in einem Wohnbereich benutzt, können elektromagnetische Störungen auftreten.

Montieren und benutzen Sie das Gerät laut Anweisungen im Benutzerhandbuch.

BESONDERER HINWEIS FÜR BENUTZER IN NORDAMERIKA

Wählen Sie für den Netzstromanschluss in Nordamerika ein Stromkabel, das in der UL aufgeführt und CSA-zertifiziert ist 3 Leiter, [18 AWG], endend in einem gegossenen Stecker, für 125 V, [5 A], mit einer Mindestlänge von 1,5 m [sechs Fuß], doch nicht länger als 4,5 m. Für europäische Anschlüsse verwenden Sie ein international harmonisiertes, mit "<HAR>" markiertes Stromkabel, mit 3 Leitern von mindestens 0,75 mm2, für 300 V, mit PVC-Umkleidung. Das Kabel muss in einem gegossenen Stecker für 250 V, 3 A enden.

BEREICH MIT EINGESCHRÄNKTEM ZUGANG

Das mit Gleichstrom betriebene Gerät darf nur in einem Bereich mit eingeschränktem Zugang montiert werden.

INSTALLATIONSCODES

Dieses Gerät muss gemäß der landesspezifischen elektrischen Codes montiert werden. In Nordamerika müssen Geräte entsprechend dem US National Electrical Code, Artikel 110 - 16, 110 - 17 und 110 - 18, sowie dem Canadian Electrical Code, Abschnitt 12, montiert werden. VERKOPPLUNG VON GERÄTEN Kabel für die Verbindung des Gerätes mit RS232- und Ethernet-müssen UL-zertifiziert und vom Typ DP-1 oder DP-2 sein. (Anmerkung: bei Aufenthalt in einem nicht-LPS-Stromkreis)

ÜBERSTROMSCHUTZ

Ein gut zugänglicher aufgeführter Überstromschutz mit Abzweigstromkreis und 15 A Stärke muss für jede Stromeingabe in der Gebäudeverkabelung integriert sein.

AUSTAUSCHBARE BATTERIEN

Wird ein Gerät mit einer austauschbaren Batterie geliefert und für diese Batterie durch einen falschen Batterietyp ersetzt, könnte dies zu einer Explosion führen. Dies trifft zu für manche Arten von Lithiumsbatterien zu, und das folgende gilt es zu beachten:

• Wird die Batterie in einem Bereich für Bediener eingesetzt, findet sich in der Nähe der Batterie eine Markierung oder Erklärung sowohl im Betriebshandbuch als auch in der Wartungsanleitung.

• Ist die Batterie an einer anderen Stelle im Gerät eingesetzt, findet sich in der Nähe der Batterie eine Markierung oder einer Erklärung in der Wartungsanleitung.

Diese Markierung oder Erklärung enthält den folgenden Warntext: VORSICHT



EXPLOSIONSGEFAHR, FALLS BATTERIE DURCH EINEN FALSCHEN BATTERIETYP ERSETZT WIRD. GEBRAUCHTE BATTERIEN DEN ANWEISUNGEN ENTSPRECHEND ENTSORGEN.

• Denmark - "Unit is class I - mit Wechselstromkabel benutzen, dass für die Abweichungen in Dänemark eingestellt ist. Das Kabel ist mit einem Erdungsdraht versehen. Das Kabel wird in eine geerdete Wandsteckdose angeschlossen. Keine Steckdosen ohne Erdungsleitung verwenden!"

• Finland - (Markierungsetikett und im Handbuch) - "Laite on liitettävä suojamaadoituskoskettimilla varustettuun pistorasiaan

• Norway - (Markierungsetikett und im Handbuch) - "Apparatet må tilkoples jordet stikkontakt Ausschließlich für Anschluss an IT-Netzstromsysteme in Norwegen vorgesehen

• Sweden - (Markierungsetikett und im Handbuch) - "Apparaten skall anslutas till jordat uttag."

Anschluss des Stromkabels:

1. Schließen Sie das Stromkabel an den Hauptanschluss auf der Rückseite des Gerätes an.

2. Schließen Sie das Stromkabel an den geerdeten Wechselstromanschluss an.

VORSICHT

Stromschlag- und Energiegefahr Die Trennung einer Stromquelle trennt nur ein Stromversorgungsmodul von der Stromversorgung. Um das Gerät komplett zu isolieren, muss es von der gesamten Stromversorgung getrennt werden.

Vorsicht - Zur Reduzierung der Stromschlag- und Feuergefahr

1. Dieses Gerät ist dazu ausgelegt, die Verbindung zwischen der geerdeten Leitung des Gleichstromkreises und dem Erdungsleiter des Gerätes zu ermöglichen. Siehe Montageanleitung.

2. Wartungsarbeiten jeglicher Art dürfen nur von qualifiziertem Servicepersonal ausgeführt werden. Es gibt innerhalb des Gerätes keine vom Benutzer zu wartenden Teile.

3. Versuchen Sie nicht, ein offensichtlich beschädigtes Gerät an den Stromkreis anzuschließen, einzuschalten oder zu betreiben.

4. Vergewissern Sie sich, dass sie Lüftungsöffnungen im Gehäuse des Gerätes NICHT BLOCKIERT SIND.

5. Ersetzen Sie eine durchgebrannte Sicherung ausschließlich mit dem selben Typ und von der selben Stärke, die auf dem Sicherheitsetikett angeführt sind, das sich neben dem Stromkabelanschluss, am Sicherungsgehäuse.

6. Betreiben Sie das Gerät nicht an einem Standort, an dem die Höchsttemperatur der Umgebung 40 °C überschreitet.

7. Vergewissern Sie sich, das Stromkabel aus dem Wandstecker zu ziehen, BEVOR Sie die Hauptsicherung entfernen und/oder prüfen.



Document ConventionsThe following describes the conventions and symbols that this guide uses:

Item Description Description (French) Beschreibung (German)

Example

An example scenario Un scénario d'exemple Ein Beispielszenarium

Caution:

Possible damage to equipment, software, or data

Endommagement possible de l'équipement, des données ou du logiciel

Mögliche Schäden an Gerät, Software oder Daten

Note:

Additional information Informations complémentaires

Zusätzliche Informationen

To

A statement and instructions

Références et instructions

Eine Erklärung und Anweisungen

Tip:

A suggestion or workaround

Une suggestion ou solution

Ein Vorschlag oder eine Umgehung

Warning:

Possible physical harm to the operator

Blessure possible de l'opérateur

Verletzungsgefahr des Bedieners



LinkProof User GuideTable of Contents


Table of ContentsImportant Notices .......................................................................................................... 3Copyright Notices .......................................................................................................... 4Safety Instructions ......................................................................................................... 7Document Conventions ............................................................................................... 19

Chapter 1 – Introduction......................................................................................... 29

LinkProof Overview ..................................................................................................... 29

Supported Radware Platforms .................................................................................... 30

Basic LinkProof Concepts ........................................................................................... 30Multihoming Overview ......................................................................................................... 30Multihomed Network ............................................................................................................ 31Farms ................................................................................................................................... 31Servers ................................................................................................................................ 31Content Rules ...................................................................................................................... 31NAT ...................................................................................................................................... 31Proximity .............................................................................................................................. 32DNS Load Balancing ........................................................................................................... 32Redundancy ......................................................................................................................... 32

LinkProof Modules ....................................................................................................... 32Health Monitoring Module .................................................................................................... 33Traffic Redirection Module ................................................................................................... 33Bandwidth Management Module ......................................................................................... 33Security Module ................................................................................................................... 33

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

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

Device IP Host Parameters and Generic Startup Configuration Menu ........................ 36

CLI Installation Wizard ................................................................................................. 40

Device Interfaces ......................................................................................................... 49Interface Numbering Conventions and Parameters ............................................................. 49Managing Physical Interface Parameters ............................................................................ 49Logical Interface Numbering ................................................................................................ 51Trunk Management .............................................................................................................. 51OnDemand Switch Management Ports Redundancy .......................................................... 51OnDemand Switch Management Ports Isolation ................................................................. 51VLAN Interface Numbering .................................................................................................. 51Managing Interface Status and Properties—L2 Interface Table ......................................... 51

Erasing the Configuration File ..................................................................................... 52

Updating Device Software ........................................................................................... 53

Software Versions List ................................................................................................. 54

LinkProof User Guide Table of Contents


Licensing and Upgrading Licenses ............................................................................. 54

Managing Configuration Files ..................................................................................... 56Sending a Configuration File to the Device ......................................................................... 57Downloading a Configuration File ....................................................................................... 57Configuration Error Log Files .............................................................................................. 58

Updating Policies—Activating the Latest Changes .................................................... 59

Resetting the Device .................................................................................................. 59

Configuring Global Device Parameters ...................................................................... 60

Device Information ...................................................................................................... 60

Device Monitoring ....................................................................................................... 61

Session Table ............................................................................................................. 62Session Table Global Parameters ....................................................................................... 62Session Table Entries ......................................................................................................... 64

Bridging Support ......................................................................................................... 65Bridge Operating Parameters .............................................................................................. 65Bridge Forwarding Table ..................................................................................................... 66Static Forwarding Table ...................................................................................................... 66

LinkProof Global Configuration General ..................................................................... 67

Virtual IP Addresses ................................................................................................... 69Creating Virtual IP Addresses ............................................................................................. 70Virtual IP Translation Ports Exclusion ................................................................................. 70

Mapping NAT Addresses to Virtual IP Addresses ...................................................... 71

Device Tuning ............................................................................................................. 71Tuning Statistics Parameters .............................................................................................. 72Tuning Memory Check ........................................................................................................ 72Tuning BWM Parameters .................................................................................................... 72Tuning Classifier Parameters .............................................................................................. 73Tuning Device Table Parameters ........................................................................................ 75Tuning SYN Protection Parameters .................................................................................... 80Tuning Diagnostics Parameters .......................................................................................... 81Tuning Security Parameters ................................................................................................ 81Tuning Virtual Tunneling Parameters .................................................................................. 83

Device Notifications .................................................................................................... 84CLI Traps ............................................................................................................................ 85Syslog Reporting ................................................................................................................. 85SMTP E-mail Notifications ................................................................................................... 86Configuration Trace ............................................................................................................. 87

DNS-Client Utility ........................................................................................................ 88

Show Tech-Support .................................................................................................... 89

Diagnostics ................................................................................................................. 90Traffic Capture Tool ............................................................................................................ 90Trace-Log ............................................................................................................................ 91



Diagnostic Tools Files Management .................................................................................... 95Diagnostics Policies ............................................................................................................. 95

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

RADIUS Authentication for Management ................................................................. 101

Logging ..................................................................................................................... 103Event Log .......................................................................................................................... 103SMTP Logging .................................................................................................................. 103Power Supply Traps ......................................................................................................... 104

APSolute API ............................................................................................................ 104

Chapter 3 – Basic Switching and Routing.......................................................... 105

Port Settings ............................................................................................................. 105Port Mirroring .................................................................................................................... 105Link Aggregation—Port Trunking ..................................................................................... 106Port Rules ......................................................................................................................... 110Rules Table ....................................................................................................................... 111Port Load Balancing Status .............................................................................................. 111

Virtual LAN ............................................................................................................... 112Virtual LANs ...................................................................................................................... 112Supported VLAN Types .................................................................................................... 112IPv6 Pass-through ............................................................................................................ 113Bridging ............................................................................................................................. 115VLAN Example Configuration ........................................................................................... 115Configuring VLANs ........................................................................................................... 116Redundancy with VLANs .................................................................................................. 118VLAN Tagging .................................................................................................................. 118

IP Addressing and Routing ....................................................................................... 122IP Addressing ................................................................................................................... 122Routing ............................................................................................................................. 122Routing Information Protocol ............................................................................................ 124Configuring ARP Parameters ........................................................................................... 126IP Router Operating Parameters ...................................................................................... 127IP Router Interface Parameters ........................................................................................ 128Open Shortest Path First (OSPF) ..................................................................................... 130

Chapter 4 – Basic Application Switching ........................................................... 135

LinkProof Multihoming Overview .............................................................................. 135

Farm Management ................................................................................................... 138LinkProof Farms ............................................................................................................... 138Farm Load Balancing ........................................................................................................ 144



Default Farm ..................................................................................................................... 153Farm Connectivity Checks ................................................................................................ 154

Server Management ................................................................................................. 155Servers Overview .............................................................................................................. 155Configuring a Logical Router ............................................................................................. 156Configuring a Logical Firewall ........................................................................................... 159Physical Servers ............................................................................................................... 161Cluster Servers ................................................................................................................. 164Full Path Health Monitor .................................................................................................... 166Server Statistics ................................................................................................................ 167

Network Address Translation ................................................................................... 167Network Address Translation (SmartNAT) ........................................................................ 167Dynamic NAT .................................................................................................................... 168Static NAT ......................................................................................................................... 169No NAT ............................................................................................................................. 170Basic NAT ......................................................................................................................... 170One-IP-for-NAT Support .................................................................................................... 171Static Port Address Translation (Static PAT or SPAT) ...................................................... 172NAT Parameters Summary and Miscellaneous Parameters ............................................. 175

Proximity ................................................................................................................... 176Proximity Introduction ........................................................................................................ 176Proximity Configuration ..................................................................................................... 177

DNS .......................................................................................................................... 182DNS Introduction ............................................................................................................... 182Mapping URLs to Local IP Addresses ............................................................................... 182DNS Response Parameters .............................................................................................. 184DNS for Local Users .......................................................................................................... 185DNS Redundancy ............................................................................................................. 187

Basic Load Balancing ............................................................................................... 188Simple Router Load Balancing Configuration ................................................................... 189Simple Router Load Balancing Configuration With VLAN ................................................. 190Simple One-Leg (Lollipop) Configuration .......................................................................... 191Sandwich Configuration .................................................................................................... 192Single Device Installation .................................................................................................. 193

Load Balancing Weights ........................................................................................... 194

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

Client Table .............................................................................................................. 200Client Table Mechanism .................................................................................................... 200Managing Client Tables .................................................................................................... 203Client-Table Logging ......................................................................................................... 208



Viewing Client Table Entries Using CLI ............................................................................ 215Client Table View Filters ................................................................................................... 215Filtered Client Table .......................................................................................................... 217Clearing the Client Table Manually ................................................................................... 217

VPN Load Balancing ................................................................................................ 218Network Topology with LinkProof Devices Through Firewalls .......................................... 218Multicast Dispatch ............................................................................................................. 219Clear Client Table (VPN Load Balancing Feature) ........................................................... 220Client Table Overwrite ...................................................................................................... 222

Chapter 5 – Advanced Features .......................................................................... 225

Content Load Balancing ........................................................................................... 225Content Load Balancing Overview ................................................................................... 225Layer 7 Policies ................................................................................................................ 228Content Rules ................................................................................................................... 230Hostname Lists ................................................................................................................. 233

Tunneling .................................................................................................................. 234Layer 2 Tunneling Protocol (L2TP) ................................................................................... 235Generic Routing Encapsulation (GRE) ............................................................................. 235GPRS Tunneling Protocol (GTP) ...................................................................................... 236Multiprotocol Label Switching (MPLS) .............................................................................. 236

Virtual Tunneling ...................................................................................................... 237Virtual Tunneling Introduction ........................................................................................... 237Virtual Tunneling Configuration ........................................................................................ 239

Cost-based Load Balancing ..................................................................................... 247Configuring Cost Global Parameters ................................................................................ 247Configuring the Cost Parameters for a Link ...................................................................... 247

Event Scheduler ....................................................................................................... 248

Miscellaneous Parameters—Tweaks ....................................................................... 249

Performance Statistics .............................................................................................. 251BWM Policy Statistics ....................................................................................................... 251Element Statistics ............................................................................................................. 254IP Interface Statistics ........................................................................................................ 258NHR Statistics ................................................................................................................... 258

Statistics Monitor SRP Management Host IP Address ............................................. 260

Configuration Auditing .............................................................................................. 261

NTP Service ............................................................................................................. 262

RADIUS Service ....................................................................................................... 263



Chapter 6 – Redundancy...................................................................................... 265

LinkProof Redundancy ............................................................................................. 265Introducing LinkProof Redundancy ................................................................................... 265Active/Backup Setup ........................................................................................................ 266Copying a Device Configuration for a Redundant Environment ........................................ 267Global Redundancy Configuration .................................................................................... 267IP Redundancy Table ........................................................................................................ 268Interface Grouping ............................................................................................................ 269Mirroring the Client Table .................................................................................................. 271

Proprietary ARP Redundancy .................................................................................. 274Proprietary ARP ................................................................................................................ 274Backup Fake ARP ............................................................................................................. 274Backup Device in VLAN .................................................................................................... 275Advanced Forwarding ....................................................................................................... 276

VRRP Redundancy .................................................................................................. 277Introducing VRRP ............................................................................................................. 277Direct Server Connection with VRRP ................................................................................ 283Configuring Basic VRRP Redundancy .............................................................................. 285VRRP Associated IP Addresses ....................................................................................... 286

Remote Virtual IP Addresses ................................................................................... 287

Chapter 7 – Security ............................................................................................. 289

Security Introduction ................................................................................................. 289SYN Floods ....................................................................................................................... 289TCP-Handshake-Timeout .................................................................................................. 290

Update Security Policies ........................................................................................... 290

Configuring Access for Physical Ports ...................................................................... 290

SNMP ....................................................................................................................... 291SNMP Global Parameters ................................................................................................. 292SNMP User Table ............................................................................................................. 292SNMP Community Table ................................................................................................... 293SNMP Groups Table ......................................................................................................... 293SNMP Access Table ......................................................................................................... 294SNMP View Table ............................................................................................................. 294SNMP Notify Table ............................................................................................................ 295Target Parameters Table .................................................................................................. 295Target Address Table ........................................................................................................ 296Creating an SNMP User .................................................................................................... 297

Ping Physical Ports ................................................................................................... 298

Configuring the Users Table and Authentication Method ......................................... 298Configuring the Authentication Method ............................................................................. 298Configuring a User in the User Table ................................................................................ 299



SYN Protection ......................................................................................................... 299SYN Flood Global Parameters ......................................................................................... 300SYN Flood Protection Policies .......................................................................................... 301SYN Flood Statistics ......................................................................................................... 302Active Triggers .................................................................................................................. 304

Keys and Certificates ................................................................................................ 304Certificates ........................................................................................................................ 304Keys .................................................................................................................................. 305Configuration .................................................................................................................... 305Certificates Workflows ...................................................................................................... 305Certificates Table .............................................................................................................. 307Export Certificates from a Device ..................................................................................... 308Import Certificates to a Device .......................................................................................... 309Default Values for Certificates .......................................................................................... 309

Chapter 8 – Bandwidth Management .................................................................. 311

Bandwidth Management Overview ........................................................................... 311Scheduler Algorithms ........................................................................................................ 312Application Classification .................................................................................................. 312Classification Mode ........................................................................................................... 312Random Early Detection ................................................................................................... 312

Managing Bandwidth Management Global Parameters ........................................... 313

Bandwidth Management Policies ............................................................................. 315Bandwidth Management Policy Mechanism ..................................................................... 316Bandwidth Management Classification Criteria ................................................................ 316Bandwidth Management Rules ......................................................................................... 318Managing Bandwidth Management Policies ..................................................................... 319

Services .................................................................................................................... 328Basic Filters ...................................................................................................................... 329AND Group Filters ............................................................................................................ 335OR Group Filters ............................................................................................................... 336Viewing Active Services .................................................................................................... 337

Networks .................................................................................................................. 338Configuring Networks ....................................................................................................... 338Viewing Active Networks .................................................................................................. 339

Port Groups .............................................................................................................. 339Configuring Port Groups ................................................................................................... 340Viewing Active Port Groups .............................................................................................. 340

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

VLAN Tag Groups .................................................................................................... 341Configuring VLAN Tag Groups ......................................................................................... 342Viewing Active VLAN Tag Groups .................................................................................... 342



MAC Groups ............................................................................................................. 343Configuring MAC Groups .................................................................................................. 343Viewing Active MAC Groups ............................................................................................. 343

Updating Policies—Classes ..................................................................................... 344

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

Protocol Discovery .................................................................................................... 347Protocol Discovery Overview ............................................................................................ 347Protocol Statistics Global Parameters ............................................................................... 348Protocol Discovery Policies ............................................................................................... 348Viewing the Protocol Discovery Statistics ......................................................................... 350

Port Bandwidth ......................................................................................................... 350

Cancelling Interface Classification ............................................................................ 350

Example Time-based BWM Policy ........................................................................... 351Configuring the Example BWM Policy ............................................................................... 352Configuring the Example Start-Event Schedule ................................................................ 352Configuring the Example Finish-Event Schedule .............................................................. 353Associating the Start- and Finish-Event Schedules with the Example BWM Policy .......... 353Activating the Latest Changes for the Example BWM Policy ............................................ 354

Chapter 9 – Health Monitoring............................................................................. 355

Health Monitoring—Introduction .............................................................................. 355Health Monitoring Module ................................................................................................. 355Response Level ................................................................................................................ 355Checked Elements ............................................................................................................ 356Health Checks ................................................................................................................... 356Methods ............................................................................................................................ 356Binding and Groups .......................................................................................................... 356

Health Check Configuration ...................................................................................... 357Configuring Health Monitoring Global Parameters ............................................................ 357Managing the Health Checks in the Check Table ............................................................. 358Bindings and Groups ......................................................................................................... 374User-Defined Health Check Methods—Packet Sequence Table ..................................... 375

Health Monitoring Server Table ................................................................................ 377Configuring a Diameter Health Check ............................................................................... 378

Farm Health Checks ................................................................................................. 381

Appendix A – Regular Expressions .................................................................... 383

Appendix B – Predefined Basic Filters ............................................................... 385

Appendix C – Glossary......................................................................................... 395


Chapter 1 – IntroductionThis guide describes Radware LinkProofand how to use it.

Unless specifically stated otherwise, the procedures described in this guide are performed using Web Based Management (WBM).

Note: The term device refers to the physical platform and the LinkProof product.

This chapter provides a general overview of the main features of LinkProof, and includes the following main sections:

• LinkProof Overview, page 29

• Supported Radware Platforms, page 30

• Basic LinkProof Concepts, page 30

• LinkProof Modules, page 32

• Management Tools, page 34

LinkProof OverviewLinkProof 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 fault- tolerant 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)

LinkProof User Guide Introduction


Supported Radware PlatformsLinkProof 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 ConceptsThe following sections briefly describe major LinkProof concepts and features:

• Multihoming Overview, page 30

• Multihomed Network, page 31

• Farms, page 31

• Servers, page 31

• Content Rules, page 31

• NAT, page 31

• Proximity, page 32

• DNS Load Balancing, page 32

• Redundancy, page 32

Multihoming OverviewThe 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 network’s 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.

LinkProof User GuideIntroduction


LinkProof eliminates all complexities of the multihoming design, providing a single, easy-to-manage appliance that intelligently optimizes and utilizes all Internet links.

Multihomed NetworkLinkProof 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 Radware’s 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.

FarmsA 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.

ServersLinkProof 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 RulesA 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 content—MIME type, URLs, cookies, and so on.

NATTo 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.



LinkProof includes the following NAT options:

• Static NAT—Is used to ensure delivery of specific traffic from the WAN to a particular server on the internal network and hide server IP addresses for outgoing traffic. This allows all ISP links to be used for all incoming traffic, and no address from a failed ISP link to ever be advertised to the Internet.

• Dynamic NAT—Is used to hide IP addresses of internal hosts for outbound traffic. LinkProof will choose an IP address that is associated with the router/ISP that was selected for this session. By choosing translated source IP addresses according to the selected router, return delivery issues will not be encountered.

ProximityTo optimize outbound and inbound traffic, LinkProof can also optionally perform proximity calculations. If an internal host wants to access a specific Web site, it is possible that the route through one ISP is more efficient than the route through the other ISP for that specific content. So, LinkProof performs proximity calculations through all available ISPs to the destination. For future traffic to this destination, LinkProof will choose the best ISP connection, according to the results derived from these proximity calculations.

Similarly, if an Internet host needs to access an internal resource then it is likely that this Internet host can get to the multihomed network more efficiently through one ISP versus the other. To accomplish this, LinkProof calculates proximity from its network to all networks with hosts trying to access internal resources.

DNS Load BalancingTo 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 organization’s 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 user’s request. This means that different responses may be provided to different clients requesting the same URL.

RedundancyThe LinkProof redundancy mechanism enables you to define a backup LinkProof in case of failure. Each pair of LinkProof devices can function in an active/backup setup. To achieve redundancy between LinkProof devices, the following methods can be used:

• Proprietary Address Resolution Protocol (ARP)

• VRRP

LinkProof Modules To provide high availability, optimal performance and maximum security levels, LinkProof offers a solution that successfully combines powerful functional modules.

LinkProof’s advanced Health Monitoring guarantees availability of the entire transaction path.

The Traffic Redirection module works closely with the Health Monitoring module and performs Layer 4–7 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,

LinkProof User GuideIntroduction


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 ModuleThe 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 2–Layer 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 ModuleThe Traffic Redirection module provides Layer 4–Layer 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 ModuleThe 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 session—either block traffic or shape traffic. For example, Bandwidth Management allows you to give HTTP traffic a higher priority over SMTP traffic, which, in turn, may have higher priority over FTP traffic. At the same time, the device can track the actual bandwidth used by each application and set limits as to how much each classified traffic pattern can utilize (see Bandwidth Management, page 311).

Security ModuleThe 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 289).

The multi-layer security approach combines a set of security services for attack detection with advanced mitigation tools, such as:

• Application Security

• DoS Shield

• SYN Flood Protection

Management ToolsYou 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.


Chapter 2 – Device ManagementThis chapter describes the LinkProof management and maintenance processes, including the management interfaces and methods by which you access, configure, and operate LinkProof devices. The maintenance procedures presented here include information about upgrading and tuning of LinkProof devices. Also provided in this chapter is a description of system notifications regarding possible system failures. For more information on LinkProof management and maintenance processes, see the Radware Installation and Maintenance Guide.

This chapter contains the following sections:

• Device IP Host Parameters and Generic Startup Configuration Menu, page 36

• CLI Installation Wizard, page 40

• Device Interfaces, page 49

• Erasing the Configuration File, page 52

• Updating Device Software, page 53

• Software Versions List, page 54

• Licensing and Upgrading Licenses, page 54

• Managing Configuration Files, page 56

• Updating Policies—Activating the Latest Changes, page 59

• Resetting the Device, page 59

• Configuring Global Device Parameters, page 60

• Device Information, page 60

• Device Monitoring, page 61

• Session Table, page 62

• Bridging Support, page 65

• LinkProof Global Configuration General, page 67

• Virtual IP Addresses, page 69

• Mapping NAT Addresses to Virtual IP Addresses, page 71

• Device Tuning, page 71

• Device Notifications, page 84

• DNS-Client Utility, page 88

• Show Tech-Support, page 89

• Diagnostics, page 90

• Management Interfaces, page 97

• RADIUS Authentication for Management, page 101

• Logging, page 103

• APSolute API, page 104

LinkProof User Guide Device Management


Device IP Host Parameters and Generic Startup Configuration MenuThe device IP host parameters enable you to establish communication with the device using any of the following interfaces:

• Web Based Management

• SNMP (Simple Network Management Protocol)

• Telnet

• Secure SHell (SSH) client

You can use the generic Startup Configuration menu to configure the device IP host parameters.

Note: LinkProof additionally provides a CLI Installation Wizard for the initial installation. The installation program enables you to install and configure LinkProof without any specific networking knowledge. For more information, see CLI Installation Wizard, page 40.

To manually configure the device IP host parameters for the first time

1. Connect the serial console to the platform.

2. Open a terminal-emulation application with the following parameters:

Parameter ValueBits per second 19200

Data bits 8

Parity None

Stop bits 1

Flow Control None

LinkProof User GuideDevice Management


3. Turn on the power to the platform. After the boot process is complete, the Startup Configuration menu is displayed.

Note: An initial default configuration is provided. When a device boots up for the first time, if the startup is not used for 30 seconds, and a boot-up server is not found within another 30 seconds, default settings are assigned to the device. The initial default configuration consists of the following: • Private IP address (192.168.1.1)• Subnet mask (255.255.255.0)• Port number for management. The port number depends on the platform.

For OnDemand Switch platforms, the default is G-1. • NMS IP address (0.0.0.0, allowing any station to manage the device using SNMP). • Community string public.• Telnet, SSH, SSL and WBM are enabled with a default user of radware with

password radware.

4. Type @ and press Enter. The device displays the following message:

Would you like to use new CLI configuration wizard (y/n) [y]:

5. Enter n. The Startup Configuration menu is displayed.

6. Enter the values for the menu items according to Table 1 - Startup Configuration Menu, page 37 and Table 2 - SNMP Startup Configuration Submenu, page 39.

The device enters a default value for the incomplete parameters, with the exception of the IP address, which is mandatory. A validity check of all the parameters is then performed.

7. When you are finished configuring the menu items, the configuration program prompts you to save the configuration. Continue with the new configuration (y/n)[y]

8. If the configuration is acceptable, type y and press Enter.

Table 1: Startup Configuration Menu

Item Additional CLI Text RemarkEnable management port

(y/n) [n] For OnDemand Switch VL platforms only, this parameter specifies whether the port labeled G6 / MNG1 is configured for management purposes.

IP Address The IP address of the interface is the only mandatory parameter. This address is used to access the device.

IP subnet mask The IP subnet mask address of the device.

Default: The mask of the IP address class

Port number Device port number to which the IP interface is defined.

For a list of available ports per platform, see Table 7 - Interface Numbering Conventions, page 49.

Default: MNG-1

Note: The value is case-sensitive.

Default router IP address

The IP address of the router through which the NMS can be reached.

Default: 0.0.0.0—That is, no default router is configured.



RIP version (0,1,2) [0] The RIP version used by the network router.

Default: 0—Specified disabled

Enable OSPF (y/n) [n] Enables or disables the Open Shortest Path First protocol.

Default: n—Specifies disabled

OSPF aread ID 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

User Name A user name which is added to the Users Table.

Default: radware

User Password The password used to access the device remotely using Web Based Management, Telnet or SSH.

Default: radware

Enable Web Access

(y/n) [n] Enables or disables Web access to the device.

Default: n—No

Enable Secure Web Access

(y/n) [n] Indicates whether Secure Web access to the device is enabled.

Default: n—No

Enable Telnet Access

(y/n) [n] Indicates whether Telnet access to the device is enabled.

Default: n—No

Enable SSH Access

(y/n) [n] Indicates whether Web access to the device is enabled.

Default: n—No

SNMP Configuration

Accesses the SNMP Startup Configuration submenu, which is described in Table 2 - SNMP Startup Configuration Submenu, page 39.

Table 1: Startup Configuration Menu

Item Additional CLI Text Remark



Table 2: SNMP Startup Configuration Submenu

# Item Additional CLI Text Description0 Supported SNMP

versions [1 2 3] Indicates which versions of the SNMP protocol

are supported by the device.

Values: 1, 2, 3

Default: 1 2 3—That is, 1 and 2 and 3

1 Community [public] Device Community name.

Default: public

2 SNMP root user Specifies the use for SNMPv3.

Default: radware

3 Privacy Protocol (NONE/DES) [DES] Specifies whether to enable privacy or disable.

Values: NONE, DESi

Default: DES

i – Data Encryption Standard

4 Privacy Password The password for the SNMPv3 User.

Default: No password

5 Authentication Protocol

(NONE/SHA/MD5 [MD5] Specifies whether to use authentication and the authentication protocol. Must be used in conjunction with privacy.

Values: NONE, SHAii , MD5iii

Default: MD5

ii – Secure Hash Algorithmiii – Message-Digest algorithm 5

6 Authentication Password

The password for the SNMPv3 authentication.


7 NMS IP Address The required NMS IP address. Enter a value if you require to limit the device to a single specified NMS.

Default: 0.0.0.0—Specifies any NMS

8 Configuration file name

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



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

Examples CLI Installation Wizard Configuration ExamplesThe following examples are possible configurations using the CLI Installation Wizard.

Figure 1: Three ISPs connected

A Three (3) ISPs connected

CLI Wizard supported network configuration:

— Three (3) ISPs configured per router

— Different interface per ISP

— Four (4) different subnets (one per interface)



Figure 2: Regular VLAN (bridge)

B Regular VLAN (bridge)

CLI Wizard Supported Network Configuration:

— Two (0) ISP configured per router

— Both ISP 1 (LP Interface 2, 192.168.10.0/24) and internal LAN (Interface 1)—subnet 192.168.10.0/24 are on the same subnet

— ISP on LP Interface 3—subnet 192.168.30.0/24



To install and configure LinkProof using the CLI Installation Wizard

1. Connect the serial console to the platform.

2. Open a terminal-emulation application with the following parameters:

3. Turn on the power to the device. After the boot process is complete, the start-up menu is displayed.

Note: An initial default configuration is provided. When a device boots up for the first time, if the startup is not used for 30 seconds, and a boot-up server is not found within another 30 seconds, default settings are assigned to the device. The initial default configuration consists of the following: • Private IP address (192.168.1.1)• Subnet mask (255.255.255.0)• Port number for management. The port number depends on the platform. For OnDemand Switch platforms, the default is G-1.

• NMS IP address (0.0.0.0, allowing any station to manage the device using SNMP).• Community string, public• Telnet, SSH, SSL and WBM are enabled with a default user of radware with

password radware.

4. Type @ and press Enter. The device displays the following message:

Would you like to use new CLI configuration wizard (y/n) [y]:

5. Enter y. The CLI Wizard Configuration menu is displayed.

Note: If you enter n, the CLI wizard returns to the original configuration wizard where you can configure the device with an IP address for initial access only.

6. Enter the values for the menu items according to Table 3 - CLI Wizard Configuration, page 43.

The device enters a default value for the incomplete parameters, with the exception of the IP address, which is mandatory. A validity check of all the parameters is then performed.

Some menu items may relate to additional information, which you can find in Table 4 - Inbound Traffic Startup Configuration, page 45, Table 6 - ISP Startup Configuration, page 47, and Table 7 - Interface Numbering Conventions, page 49.

Parameter ValueBits per second 19200

Data bits 8

Parity None

Stop bits 1

Flow Control None



7. Press Enter. Static Port Address Translation (Static PAT) is an option, and offers the following inbound services:

Static PAT allows you to configure up to three servers, each with up to five services with the following limitation: starting from one server with all the five services or five servers (with different IP addresses) with one service each, or a combination of the above.

8. Press Enter.

When using inbound services with Static PAT, management ports have to be disabled in order to prevent a conflict with inbound services.

The following ports have been chosen by Radware using RFC 4340. You can alternatively use an optional port recommended by IANA (Internet Assigned Numbers Authority)—http://www.iana.org/assignments/port-numbers.

Notes:>> A message is sent to the use to inform the user that the configuration was successful.

>> An error message is displayed if the ports used were in conflict and the configuration was unsuccessful.

>> If the IP address of the inbound port and the outbound port belong to the same subnet, the following configuration is derived from the topology:• Inbound and outbound ports become members of the 1 VLAN Bridge group.• Radware ensures that all IP addresses belong to the same subnet mask.

Service DefaultWeb (HTTP) TCP port 80

Web SSL (HTTPS) TCP 443

FTP TCP port 21 and 20

Mail (SMTP) TCP port 25

VPN (IPsec) UDP and TCP port 500 plus AH/ESP L3

Service Port Selected by RadwareWeb SSL (HTTPS) TCP 9062

FTP TCP port 9061

Table 3: CLI Wizard Configuration

Item CLI Description RemarkEnable management port

(y/n) [n] For OnDemand Switch VL platforms only, this parameter specifies whether the port labeled G6 / MNG1 is configured for management purposes.

Default: n

IP Address The IP address of the interface is the only mandatory parameter. This address is used to access the device.

Default: 255.255.0.0

IP subnet mask The IP subnet mask address of the device.

Default: The mask of the IP address class

http://www.iana.org/assignments/port-numbers



Port number Device port number to which the IP interface is defined.

For a list of available ports per platform, see Table 7 - Interface Numbering Conventions, page 49.

Default: 1

Note: The value is case-sensitive.

User name A user name which is added to the Users Table.

Default: radware

User password The password used to access the device remotely using Web Based Management, Telnet or SSH.

Default: radware

Enable management port SSH Access

(y/n) [y] Specifies whether Web access to the device is enabled.

Values: y, n

Default: y

Enable management port Secure Web Access

(y/n) [y] Specifies whether to enable SSH access for device management.

Enable management port SNMP Access

(y/n) [y] Specifies whether to enable Web SSL access for device management.

Enable ping response on all NHR ports

(y/n) [n] Specifies whether to enable a ping response on all router ports of the device.

Set Client Table size between 1000 and <MaxClientTableSize>

[<Recommended size>]

Specifies the Client Table Size with values between 1000 and the maximum recommended value for your specific physical platform.

Default: The recommended size, which is the approximate average between 1000 and the maximum size of the client table. The maximum size of the client table depends on the memory of the device.

Caution: It is not recommended to set the Client Table Size to maximum, because it might render the device without operational memory. If you configure higher values, you should check the memory consumption using Web Based Management (Service > Tuning > Memory Check) or CLI (using the command system tune check-memory-capacity).

Remote management IP address

(0 for none) [0] Specifies the IP address for the remote management port.


Item CLI Description Remark



ISP configuration (press <Enter> to configure)

Accesses the ISP Startup Configuration submenu to configure routers NAT by defining the IP address of the routers as well as the IP addresses of the LinkProof interfaces.

For a description of the ISP Startup Configuration submenu items, see Table 6 - ISP Startup Configuration, page 47.

Inbound Traffic configuration

(press <Enter> to configure)

Accesses the Inbound Traffic Startup Configuration submenu. This enables you to configure Static Port Address Translation (Static PAT) options. Static PAT allows you to configure up to three servers, each with up to five services with the following limitation: starting from one server with all the five services or five servers (with different IP addresses) with one service each, or a combination of the above. When using inbound services with Static PAT, management ports have to be disabled in order to prevent a conflict with inbound services.

For a description of the Inbound Traffic Startup Configuration menu items, see Table 4 - Inbound Traffic Startup Configuration, page 45.

SNMP configuration (press <Enter> to configure)

Accesses the SNMP Startup Configuration submenu.

For a description of the SNMP Startup Configuration submenu items, see Table 2 - SNMP Startup Configuration Submenu, page 39.

Table 4: Inbound Traffic Startup Configuration

# Item CLI Description Remark

0 Internal Web server IP address

(0 for none) [0] Optionally specifies an internal Web (HTTP) server with an IP address. TCP port is 80.

Default: 0

1 Internal Web server domain name

(0 for none) [0] When item 0 has a value other than 0, this parameter specifies the relevant domain name.

Default: 0

2 Internal FTP server IP address

(0 for none) [0] Optionally specifies an internal FTP server with an IP address. When specified, the device sets the TCP port 9061 to instead of the well known TCP port 21 and 20.i

Default: 0

3 Internal FTP server domain name


Default: 0

4 Internal SMTP server IP address

(0 for none) [0] Optionally specifies an internal Mail (SMTP) server with an IP address. TCP port 25.

Default: 0


Item CLI Description Remark



5 Internal SMTP server domain name


Default: 0

6 Internal HTTPS server address

(0 for none) [0] Optionally specifies an internal Web SSL (HTTPS) with an IP address. When specified, the device sets the TCP port 9062 to instead of the well known

443.i

Default: 0

7 Internal HTTPS server domain name


Default: 0

8 Internal IPSec server IP address

(0 for none) [0] Optionally specifies an internal VPN (IPsec) server with an IP address. UDP and TCP port 500 plus AH/ESP L3.

Default: 0

9 Internal IPSec server domain name


Default: 0

i – Radware has chosen this port using RFC 4340. You can alternatively use an optional portrecommended by IANA (Internet Assigned Numbers Authority)—http://www.iana.org/assignments/port-numbers.


# Item Additional CLI Text Description0 Supported SNMP

versions [1 2 3] Indicates which versions of the SNMP protocol are

supported by the device.

Values: 1, 2, 3

Default: 1 2 3—that is, 1 and 2 and 3

1 Community [public] Device Community name.

Default: public

2 SNMP root user Specifies the use for SNMPv3.

Default: radware

3 Privacy Protocol (NONE/DES) [DES] Specifies whether to enable privacy or disable.

Values: NONE, DESi

Default: DES

4 Privacy Password The password for the SNMPv3 User.


Table 4: Inbound Traffic Startup Configuration


http://www.iana.org/assignments/port-numbers



5 Authentication Protocol

(NONE/SHA/MD5 [MD5]

Specifies whether to use authentication and the authentication protocol. Must be used in conjunction with privacy.

Values: NONE, SHAii , MD5iii

Default: MD5

6 Authentication Password

The password for the SNMPv3 authentication.


7 NMS IP Address The required NMS IP address. Enter a value if you require to limit the device to a single specified NMS.

Default: 0.0.0.0—That is, any NMS

8 Configuration file name

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

i – Data Encryption Standardii – Secure Hash Algorithmiii – Message-Digest algorithm 5

Table 6: ISP Startup Configuration

# Item CLI Description Remark0 Router IP address of ISP 1

1 Mask address for ISP 1 Default: 255.0.0.0

2 LinkProof IP interface address for ISP 1

3 LinkProof physical port numbers facing ISP 1

4 Set operating mode for the ISP server

(regular or backup) (r/b) [r] Regular is for load balancing.

Backup is for high availability.

5 Do you want to use Dynamic-NAT for the ISP

(y/n) [y] Specifies whether Dynamic NAT is used. If yes, you must specify the IP Interface of that specific Interface, the NAT Address.

Default: y

6 Router IP address of ISP 2 (no to skip this ISP definition) [no]

Default: no

7 Mask address for ISP 2


# Item Additional CLI Text Description






(regular or backup) (r/b) [r] Regular is for load balancing

Backup is for high availability.

Default: r


(y/n) [y]

12 Router IP address of ISP 3 (no to skip this ISP definition) [no]

13 Mask address for ISP 3




(regular or backup) (r/b) [r]


(y/n) [y]

18 Load Balancing Method (use up/down keys) [Least amount of traffic]

Values:

• Least amount of traffic

• Cyclic

• Least number of bytes

• Fewest number of Users

• Hashing

• Response time

Default: Least amount of traffic

For more information, see Dispatch Methods, page 144.

Table 6: ISP Startup Configuration




Device InterfacesThis section describes LinkProof device interfaces and how to configure them.

Interface Numbering Conventions and ParametersThe following table describes the physical ports on the platforms that support LinkProof.

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 Index—The index number of the port.

— Speed—The speed of the port. This option is available only when Auto-negotiation mode is off.

— Duplex—Whether 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 Negotiate—Whether the interface allows the two interfaces on the link to select the best common mode automatically.

Table 7: Interface Numbering Conventions

Physical Interface Type OnDemand Switch VL Port Index Rangei

i – The value is case-sensitive using CLI.

OnDemand Switch 2 Port Index Rangei

OnDemand Switch 3 Port Index Rangei

RJ-45 port for management

G6/MNG1ii

ii – Must be configured manually by means of the Startup Configuration Menu.

MNG 1–2iii

iii – For management only.

MNG 1–2iii

GbE RJ-45 ports G1–G5iv

iv – For traffic. The port that is labeled on the platform G6/MNG1 is configured for management.

G1–G12v

v – For traffic or management.

G1–G8v

SFP GbE ports G7–8v G9–G12v

Dual (SFP or RJ-45) GbE portsvi

vi – Only one side of a dual port can be active at the same time.

G13–16v

10GbE XFP ports XG-1–XG-4v



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. Select Device > Physical Interface. The Physical Interface Table pane is displayed.

2. From the Port Index column, select the required interface. The Physical Interface Table Update pane is displayed.

3. Configure the parameters; and then, click Set.

Table 8: Physical Interface Parameters

Parameter DescriptionSpeed The speed for the interface.

Values:

• Ethernet

• Fast Ethernet

• Giga Ethernet—Gigabit 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 NumberingThere are two types of logical interfaces: trunks (for Link Aggregation) and VLANs.

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 RedundancyOn 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 IsolationNetwork traffic to the management port is fully isolated from the traffic ports, and therefore, no network traffic will be forwarded between the management and traffic ports.

VLAN Interface NumberingLinkProof devices support up to 64 VLANs.

VLAN numbers are from 100000 through 1000063.

Two VLANs are predefined, 100000 and 100001.

Managing Interface Status and Properties—L2 Interface TableYou can view the status and settings for interfaces using all management tools.

The status information comprises the following:

• Interface Index—The index value of the physical interface.

• MAC Address—The MAC address of the interface.

• Interface Admin Status—Either up or down.

• Operational Status—Either Up or Down.

To display the interfaces and their configuration using CLI

Use the command net l2-interface.

OnDemand Switch VL OnDemand Switch 2 OnDemand Switch 3Trunk T-1, T-2, T-3, T-4, T-5 T-1, T-2, T-3, T-4, T-5, T-6,

T-7, T-MNGT-1, T-2, T-3, T-4, T-5, T-6, T-7, T-MNG



To display the interfaces and their configuration using Web Based Management

Select Device > L2 Interface.

Note: Device MAC to Port Correlation specifies whether the device correlates the first 42 bits of the destination MAC address of incoming packets or all 48 bits. The MAC address of each port on the platform is the base MAC address plus the port index.

Values:

—Share—The device correlates only the first 42 bits of the destination MAC address of incoming packets. This value may improve performance.

—Enforce—The device correlates all 48 bits of the destination MAC address of incoming packets to those of the port. This is considered a a more secure MAC-to-port correlation method.

Default: Share

To display current settings for the interfaces using CLI

Use the command net physical-interface.

To display current settings for the interfaces using Web Based Management

Select Device > Physical Interface.

Erasing the Configuration FileYou may need to erase the configuration to restore the factory default configuration.

To erase the configuration file

1. Reboot the device and press any key to stop the auto-boot process.

2. Type q0 and press Enter.

3. Type q1 and press Enter.

4. Press @ to reboot the device. The following line is displayed:Would you like to use new CLI configuration wizard (y/n) [y]:

5. Do one of the following:

— Type n and press Enter. The Startup Configuration menu is displayed.

— Enter y and press Enter. The CLI Wizard Configuration menu is displayed.

6. Set the required parameters.



Updating Device SoftwareYou 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 fromhttp://www.radware.com/content/support/Software_upgrade/default.asp.The upgrade password is based on the Base MAC address (that is, the address of the first interface) of your device and on the version software file size.

You will be asked for that password during the upgrade of your device.

Caution: Before upgrading to a newer software version, save the existing configuration file.

Caution: Before uploading in Regular VLAN mode, disable redundancy.

To update device software

1. Select File > Software Update. The Software Update pane is displayed.

2. In the Password text box, type the password that you received with the new software version.

Note:The password is case-sensitive.

3. In the Software version text box, type the software version number as specified in the new software documentation.

4. In the File text box, type the name of the file, or click Browse and navigate to the required file.


— If you want the device to operate according to the new version after the software download process is complete, select the Enable New Version checkbox (default).

— If you want the device to operate according to the previous version, clear the Enable New Version checkbox.

6. Click Set. The device reboots, which takes a few minutes.

7. Verify that the console message shows the upgraded version.

Caution:

http://www.radware.com/content/support/Software_upgrade/default.asp



Software Versions ListLinkProof 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.

To delete a software version from the Software Versions Table

1. Select File > Software List. The Software Versions Table pane is displayed with the list of versions that the device currently contains.

2. In the row of the version to delete, select the checkbox and click Delete.

To activate a version using the Software Versions Table

1. Select File > Software List. The Software Versions Table pane is displayed with the list of versions that the device currently contains.

2. Click the name of the version to activate. The Software Versions Table Update is displayed.

3. From the Active drop-down list, select TRUE.

4. Click Set.

5. To implement the version activation, from the Device menu, select Reset Device; and then, click Set.

Licensing and Upgrading LicensesYou can upgrade the capabilities of LinkProof devices using the licensing mechanism, for example, to add APSolute OS support.

Table 9: Software Versions Table Columns

Parameter DescriptionName The name of the version

Index The index of the version in the Software List.

Valid The validity of the version.

Values: TRUE, FALSE

Active The current status of the version.

Values: TRUE, FALSE

Version The version number.



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 one-time license, meaning that once this license is changed, the old license code cannot be re-used. For example, if an APSolute OS license was given to you on a trial basis and not purchased, Radware provides you with another license. The old license cannot be reused without APSolute OS support.

The license is based on the MAC address of the device, and on a license ID that is changed every time a new license is inserted. To get a license upgrade, you need to send the MAC address and the current license ID of the device.

To perform a license downgrade, send the MAC address and the current license ID of the device. Once you receive and insert this new license, a screen capture of the License Upgrade pane, or the output of system license get CLI command, must be sent to Radware to prove that you are using the new license.

To upgrade a software license using the CLI

1. Enter the following command:

system license

The current license code is displayed.


system license set <new license code>

A license updated message is displayed in the command line.


reboot

4. Enter yes to confirm the reset.

To view the device-license information using Web Based Management

Select Device > License Upgrade. The License Upgrade pane is displayed.

Table 10: License Upgrade Parameters

Parameter DescriptionBase MAC Address The MAC address of the first port on the device.

License ID Reports the device software license ID and must be provided to the Radware ordering department when a new license is required.

Insert your License Code The device software license allows you to activate advanced software functionality.

The value is case-sensitive.

Throughput License ID Manages the device throughput license ID and must be provided to the Radware ordering department when a new throughput license is required.

Insert your Throughput License Code

Manages the device throughput level license.



To upgrade a license using Web Based Management

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.

Managing Configuration FilesThis section contains the following topics:

• Sending a Configuration File to the Device, page 57

• Downloading a Configuration File, page 57

• Configuration Error Log Files, page 58

Table 11: License Upgrade Parameters

Parameter DescriptionBase MAC Address The MAC address of the first port on the device.

License ID Reports the device software license ID and must be provided to the Radware ordering department when a new license is required.

Insert your License Code The device software license allows you to activate advanced software functionality.

The value is case-sensitive.

Throughput License ID Manages the device throughput license ID and must be provided to the Radware ordering department when a new throughput license is required.

Insert your Throughput License Code

Manages the device throughput level license.



Sending a Configuration File to the Device

To send a configuration file to the device

1. Select File > Configuration > Send To Device. The Upload Configuration File to Device pane is displayed.

2. From the Upload Mode drop-down list, select one of the following:

— Replace configuration file—Replaces 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 file—Adds 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 reboot—Adds 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. All commands that require rebooting the device are implemented.

b. The device reboots.

c. All commands that do not require rebooting the device are implemented.

3. In the Configuration File text box, type the path of the required file or click Browse to navigate to the required file.

4. Click Set. The file is uploaded to the device.

5. If you selected Replace configuration file or Append commands to configuration file, from the Device menu, select Reset Device and then Set in the Reset the Device pane.

Downloading a Configuration File

Note: If you are downloading a configuration file using Web Based Management, you cannot download to a device configured to use only SNMPv3.



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:

— Regular—You receive the device configuration file.

— Backup (Active-Backup)—You receive the device configuration file created for the backup device—to 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 FilesLinkProof automatically generates a log of configuration errors.

Viewing the Configuration Error Log FileYou 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 FileYou can clear the information contained in the configuration log file.

To clear the log file with the configuration errors

1. Select File > Configuration > LogFile > Clear. The Configuration Error Log pane is displayed.

2. Click Set.

Downloading the Configuration Error Log FileYou can download the information contained in the configuration log file.



To download the log file with the configuration errors

1. Select File > Configuration > LogFile > Download. The Configuration Error Log pane is displayed.

2. Click Set.

Updating Policies—Activating the Latest ChangesYou need to explicitly activate changes to the device configuration at the following times:

• When you modify the configuration of a flow-management policy.

• When you modify the configuration of a filter that is used in an existing bandwidth-management (BWM) policy.

• When you modify the configuration of a class that is used in an existing policy.

You activate the latest changes from the Activate Latest Changes pane. The Activate Latest Changes pane is displayed regardless of the configuration path and its functionality is the same.

Open the Activate Latest Changes pane by selecting one of the following:

• LinkProof > Flow Management > Update Policies

• BWM > Update Policies

• Classes > Update Policies

To activate the latest changes

In the Activate Latest Changes pane, click Set.

Resetting the DeviceAfter 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.


Device InformationYou 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 12: Device Global Parameters

Parameter DescriptionDescription General description of the device (read only).

Name User-assigned name of the device, which appears in the panes describing the device.

Location Geographic location of the device.

Contact Person The person or people responsible for the device.

System Up Time Time elapsed since the last reset (read only).

System Time Current user-defined device time.

System Date Current user-defined device date.

Bootp Server Address The IP address of the BootP server. The device forwards BootP requests to the BootP server and acts as a Bootp relay.

Bootp Threshold How many seconds the device will wait before relaying requests to the BootP server. This delay allows local BootP Servers to answer first.

Software Version The software version (read only).

Hardware Version The hardware version (read only).



Device Monitoring

To view the Device Monitoring information

Select Device > Device Monitoring. The Device Monitoring pane is displayed.

Table 13: Device Information Parameters

Parameter DescriptionPlatform The platform type.

Ports The quantity and types of physical ports on the platform.

Hardware Version The hardware version.

Software Version The LinkProof software version.

Build The timestamp and the build number of the software.

Version State The state of this software version.

Values: Open, Closed

ApSolute OS The versions of Bandwidth Management and Application Security modules for this software.

Network Driver The version of network driver.

Active Boot The time, in days, since the active boot commenced.

Secondary Boot The time, in days, since the secondary (redundant) boot commenced.

RAM Size (MB) The amount of RAM, in megabytes.

CM Flash Size (MB) The size, in megabytes, of the CompactFlash.

Flash Size (MB) The size, in megabytes, of the flash (permanent) memory.

Hard Disk(s) The number of hard disks on the device.

Serial Number The serial number of the device.

System Up Time The elapsed time since the last reboot.

Base MAC Address The MAC address of the first physical port on the device.

CPUs Number The number of CPUs on the platform.

Cores Number The total number of cores on the platform.

Power Supply Status Values:

• Single Power Supply OK

• Dual Power Supply OK

• One Power Supply Failed



Session TableThe Session Table enables LinkProof to efficiently process traffic that the LinkProof device only routes or bridges and does not load balance. The Session Table mechanism is similar to the Client Table, but tracks sessions that are not recorded in the Client Table.

Session Table Global Parameters

To configure the Session Table global parameters

1. Select Device > Session Table > Global Parameters. The Session Table Parameters pane is displayed.


Table 14: Device Monitoring Categories

Category DescriptionRedundancy Contains a link to the backup device and the Redundancy Status.

Logical Servers 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:

• Farm—The names of the farms configured on this device. To view or update the configuration of a farm, click the relevant link.

• Type—The type of the farms.

• Servers—The 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:

• Name—The user-defined name of the device.

• System Up Time—The elapsed time since the last reboot.

• Software Version—The LinkProof software version

• Base MAC Address—The 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.



Table 15: Session Table Global Parameters

Parameter DescriptionSession Table Status 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 Layer3—An entry exists in the Session Table for each source IP and destination IP combination of packets passing through the device. This mode is recommended for higher performance, unless traffic classification on layer 4 or 7 is required.

• Full Layer4—An entry exists in the Session Table for each source IP, source port, destination IP and destination port combination of packets passing through the device. This mode is the default mode for Session Table and it is recommended when traffic classification on layer 4 or 7 is required.

Default: Full Layer 4

Remove Session Table Entry at Session End

Enable this feature to remove sessions from the Session Table when the session ends (only valid for Full Layer 4 Lookup Mode). Recommended to free resources when the aging time of the session table is set at a high value, however it can cause slight performance degradation. The size of the Session Table and the Session Passive Protocols Table (used to track sessions for protocols like passive FTP) is tunable using the Device Tuning pane or using the system tune CLI command.


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.


Default: Disabled



Session Table EntriesUse 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.

To set the maximum entries displayed in the Session Table Entries table

1. Select Device > Session Table > View Table Query Results. The View Table Query Results pane is displayed.

2. In the Maximum Displayed Entries text box, type the maximum number of Session Table entries to display. Values: 1–10,000. Default: 100.

3. 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.

Table 16: Session Table Entries Parameters

Parameter DescriptionSource IP The source IP address from which the traffic arrives.

Default: 0.0.0.0

Destination IP The destination IP address.

Default: 0.0.0.0

Source Port The source port of the session.

Default: 0

Destination Port The destination port.

Default: 0

Lifetime The lifetime of the entry.

Aging Type The aging type of the entry.

SYN Protection Status The SYN Flood Protection status of the entry.



To configure the filter for the display of the Session Table entries in the View Table Query Results window

1. Select Device > Session Table > View Table Query Results. The View Table Query Results pane is displayed.

2. Click Create. The Query Filters Table Create pane is displayed.


Bridging SupportA 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 Address—The MAC Address used by the device

— Bridge Type—The types of bridging the device can perform


Table 17: Query Filters Table Parameters

Parameter DescriptionName The unique name of the filter, up to 19 characters.

Physical Port The physical port from which the request arrives.

Default: 65,535

Source IP The source IP address within the defined subnet.

Default: 0.0.0.0

Source IP mask The source IP mask.

Default: 0.0.0.0

Dest IP The destination IP address within the defined subnet.

Default: 0.0.0.0

Dest IP mask The destination IP mask.

Default: 0.0.0.0

Source Port The source port of the session.

Default: 0

Dest Port The destination port.

Default: 0



Bridge Forwarding TableThe 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.

Static Forwarding TableUse 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 18: Query Filters Table Parameters

Parameter DescriptionForwarding Table Aging Time

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: 10–1,000,000

Default: 3600

Delete entries when port goes down

Values: enable, disable

Default: enable

Table 19: Bridge Forwarding Table Parameters

Parameter DescriptionMac Address The MAC address of the node.

Port The port through which the node has been learned—that is, the port through which frames are received from this entry.

Status Describes how the node entry was added to the list, and indicates status.

Values:

• learned—The entry was automatically learned.

• self—The entry is a device port.

• Mgmt—The entry is a static node manually entered using the Edit button.

• Other—The node status cannot be described by one of the above.



To add a new static bridge forwarding node

1. Select Bridge > Static Forwarding Table. The Static Forwarding Table pane is displayed.

2. Click Create. The Static Forwarding Table Create pane is displayed.


LinkProof Global Configuration GeneralUse 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.


Table 20: Static Forwarding Table Parameters

Parameter DescriptionStatic Mac Address The MAC address of the static node.

Static Receive Port The port through which frames are received from this entry.

Status Specifies how the node behaves when the device resets.

Values:

• Permanent—The entry is remains after the device resets.

• Delete on Reset—The entry is deleted when the device resets.

Table 21: Static Forwarding Table Parameters

Parameter DescriptionStatic Mac Address The MAC address of the static node.

Static Receive Port The port through which frames are received from this entry.

Status Specifies how the node behaves when the device resets.

Values:

• Permanent—The entry is remains after the device resets.

• Delete on Reset—The entry is deleted when the device resets.



Table 22: Global Configuration General Parameters

Parameter DescriptionLoad Balancing Admin Status The status of the LinkProof device.

Values:

• Enable—The device is active. All users are balanced between the servers.

• Disable—The device is inactive. Clients connecting to the device will be sent to the default server.

Default: Enable

Note: Typically, the value should remain Enable.

Ignore Flow Policies for Local Routes Specifies whether the device ignores flow policies for local routes and forwards the traffic according to the routing table.

Values:

• Enable—For each new session, the device checks whether the session is destined to be routed locally—that is, the session requires routing but not through the default gateway (0.0.0.0 in the routing table). If this is the case, the flow policies are ignored and the traffic is forwarded according to the routing table.

• Disable—Flow policies take precedence over routing.

Default: Disable

Clients Connect Denials Displays, read-only, the number of connection requests from clients that were denied by the dispatcher.

Translate Outbound Traffic to Virtual Address

When using virtual IP addresses, determines how addresses from the next server will behave.

Values:

• enable—Changes NAT addresses to virtual IP addresses.

• enable—Does not change NAT addresses.

Default: disable

Fragmentation Table Aging Time The time, in seconds, that an entry remains in the Fragmentation Table.

Values: 1–10

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.



Virtual IP Addresses

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.


Default: enable

NHR Tracking Table Aging The time LinkProof keeps an entry in the NHR Tracking Table when no traffic matches it.

Values: 1–3600

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.

Link Quality Evaluation 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.


Default: Enable

Note: Enabling this option has no impact on performance.

Table 22: Global Configuration General Parameters

Parameter Description



This section provides some basic load-balancing configuration examples, which can be implemented without using flow definitions.

This section includes the following:

• Creating Virtual IP Addresses, page 70

• Virtual IP Translation Ports Exclusion, page 70

Creating Virtual IP AddressesYou can create virtual IP addresses so that LinkProof can balance loads between NHRs where one or more use NAT addresses. You do so by creating a virtual IP address and mapping the NAT addresses of the NHRs to it. Clients destined to the virtual IP address are redirected to the appropriate NHR according to the configured Dispatch Method.

You can configure up to 400 virtual IP addresses per LinkProof device.

Use the Virtual IP Table pane to configure virtual IP addresses.

To configure a virtual IP address

1. Select LinkProof > Virtual IP > Virtual IP Table. The Virtual IPs Table pane is displayed.

2. Select Create. The Virtual IPs Table Create pane is displayed.


Virtual IP Translation Ports ExclusionVIP 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.

Table 23: Virtual IPs Table Parameters

Parameter DescriptionVirtual IP Address 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

Mode Defines the mode of the device.

Values:

• Regular—The device is an active device.

• Backup—The device is a backup device.

Default: Regular



To configure port exclusion for VIP translation

1. Select LinkProof > Virtual IP > VIP Exclusion Policy. The Virtual IP Exclusion Policy pane is displayed.

2. Click Create. The Exclusion Policy Table Create pane is displayed.

3. In the Port text box, type the number of the port that you wish to exclude from VIP translation.

4. Click Set.

Mapping NAT Addresses to Virtual IP AddressesAfter you create a virtual IP address, you can map NHR NAT addresses to it. You can assign each virtual IP address one NAT address from each NHR.

To map a new NAT address to a virtual IP

1. Select LinkProof > Mapped IP Table. The Mapped IPs Table pane is displayed.

2. Click Create. The Mapped IPs Table Create pane is displayed.


Device TuningThis section describes the interfaces and methods for device tuning, and contains the following topics:

• Tuning Statistics Parameters, page 72

• Tuning Memory Check, page 72

• Tuning BWM Parameters, page 72

• Tuning Classifier Parameters, page 73

• Tuning Device Table Parameters, page 75

• Tuning SYN Protection Parameters, page 80

• Tuning Diagnostics Parameters, page 81

• Tuning Security Parameters, page 81

• Tuning Virtual Tunneling Parameters, page 83

Table 24: Mapped IPs Table Parameters

Parameter DescriptionVirtual IP Address The virtual IP address to which to map the NAT address.

Next Hop Router The IP address of the NHR to map to the virtual IP address.

Virtual NAT Address The NAT address of the next hop router.



Caution: Radware strongly recommends that you perform any device tuning only after consulting with Radware Technical Support.

Tuning Statistics ParametersThe 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.

Tuning Memory CheckYou 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 ParametersThe changes to the tuning configuration take effect after a device reset.

To configure the BWM tuning parameters

1. Select Services > Tuning > BWM. The BWM Tuning pane is displayed.


Table 25: Statistics Tuning Parameters

Parameter DescriptionProtocol Discovery Policies The size of the table for Protocol Discovery Policies

entries.

Values: 2–256

Default: 8

Protocol Discovery Report Entries The total number of the discovered protocols that the LinkProof device can record.

Values: 2–10000

Default: 128



Tuning Classifier ParametersThe changes to the tuning configuration take effect after a device reset.

The BWM module uses the classifier objects (for example, networks, subnets, discrete IP address, and so on) for all the bandwidth-management policies on the device.

Example Assume the following configuration:

— Network table size = 2

— Subnets per network = 4

— Discretes per network = 4

— Object “LAN1” with index 1: 192.168.10.0/24









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.

Table 26: BWM Tuning Parameters

Parameter DescriptionPolicy Table The number entries in the BWM Policy Table.

Values: 256–150,000

Default: 1024

BW per Traffic Flow sessions tracking

The number of traffic flows for which the device can provide bandwidth or limit the number of sessions.

Values: 16–100,000

Default: 2048

Destination Table The number of destination address entries in the Destination Table.

Values: 64-128,000

Default: 256

Farms Classification Lists Values: 1–10,000

Default: 64



To configure the Classifier tuning parameters

1. Select Services > Tuning > Classifier. The Classifier Tuning pane is displayed.


Table 27: Classifier Tuning Parameters

Parameter DescriptionNetwork Table The number of network entries defined by name and

index. For example, for a network with two indexes, two entries are consumed.

Values: 32–10,000

Default: 1024

Discrete IP Addresses Per Network The number of discrete IP addresses in the network (with a /32 subnet mask).

Values: 1–50,000

Default: 1024

Subnets Per Network The number of non-discrete IP subnets (with a range or mask smaller than a /32).

Values: 16–256

Default: 64

Dynamic Network Table The number of dynamic network entries defined by name and index. For example, for a network with two indexes, two entries are consumed.

Values: 16–256

Default: 64

Discrete IP Addresses Per Dynamic Network

The number of discrete IP addresses in a dynamic network (with a /32 subnet mask).

Values: 1–50,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: 1–50,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: 64–2048

Default: 512

AND Group Table The number of AND Group entries in the table.

Values: 32–2048

Default: 256



Tuning Device Table ParametersThe 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 source-address, source-port, destination address, and destination port requires its own entry in the table.

Note: Layer-4 tables are usually larger than Layer-3 tables. For example, a typical TCP client, using HTTP, opens several TCP sessions to the same destination address.

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).

OR Group Table The number of OR Group entries in the table.

Values: 32–2048

Default: 256

Application port groups The number of application port group entries in the table.

Values: 1–1000

Default: 20

Content Table The number of content entries in the table.

Values: 8–4096

Default: 512

Table 27: Classifier Tuning Parameters




To configure the tuning parameters for the device tables

1. Select Services > Tuning > Device. The Device Tuning pane is displayed.


Table 28: Device Table Tuning Parameters

Table DescriptionFlow Policies Table 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: 16–5000

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: 20–6,500,000

Default: 1,000,000

Session Passive Protocols Table

The maximum number of entries in the Session Passive Protocols Table.

The Session Passive Protocols Table records passive protocols port commands so that all related sessions will be maintained.

Values: 16–32,000

Default: 4096

Session Resets Table The maximum number of entries in the Session Resets Table. Values: 1–100,000

Default: 100

Bridge Forwarding Table The maximum number of entries in the Bridge Forwarding Table.

The Bridge Forwarding Table contains the bridging ports per destination MAC address.

Values: 20–32,767

Default: 1024

IP Forwarding Table The maximum number of entries in the IP Forwarding table. The table contains the destination MAC address and port per destination IP address.

Values: 20–768,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: 20–32,767

Default: 1024



Client Table 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 andOnDemand Switch 2 with 2 GB RAM:

• Values: 20–2,000,000

• Default: 500,000

OnDemand Switch VL with 4 GB RAM, OnDemand Switch 2 with 4 GB RAM, and OnDemand Switch 3 with 8 GB RAM:

• Values: 20–6,500,000

• Default: 1,000,000

Client Table Extension The maximum number of entries in the Client Table Extensions.


• Values: 20–2,000,000

• Default: 500,000

OnDemand Switch VL with 4 GB RAM,OnDemand Switch 2 with 4 GB RAM, andOnDemand Switch 3 with 8 GB RAM:

• Values: 20–6,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: 20–32,767

Default: 512


Table Description



Farm Persistency Table 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 session-identification 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.


• Values: 20–4,000,000

• Default: 500,000


• Values: 20–13,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).


• Values: 1–2,000,000

• Default: 500,000


• Values: 1–6,500,000

• Default: 1,000,000

Proximity Subnets The maximum number of proximity entries in the proximity database.

Values: 1–500,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: 64–20,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: 64–8,192

Default: 512


Table Description



Basic NAT Table 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: 20–8,192

Default: 512

PAT & Dynamic NAT Port Table

The maximum number of entries in the PAT & Dynamic NAT Port Table.

Values: 3072–60,535

Default: 60534

Dynamic NAT Table The maximum number of entries in the Dynamic NAT Table.

Values: 1–1024

Default: 30

URL to IP Table The limit on the number of entries in the URL to IP table.

Values: 100–30,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: 100–30,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.


• Values: 1–131,070

• Default: 30,000


• Values: 1–262,140

• Default: 50,000

Delayed Bind SYN Protection Triggers Table

The maximum number of entries in the Delayed Bind SYN Protection Triggers Table.

Values: 10–100,000

Default: 2048


Table Description



Tuning SYN Protection ParametersThe changes to the tuning configuration take effect after a device reset.

To configure the SYN Protection tuning parameters

1. Select Services > Tuning > SYN Protection. The SYN Protection Tuning pane is displayed.


Table 29: SYN Protection Tuning Parameters

Parameter DescriptionSYN Protection Table 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: 10–1,000,000

Default: 16,384

SYN Protection Requests Table

The number of entries in SYN Protection Requests Table, which stores the ACK or data packet that the client sends, until the handshake with the server is complete and the packet is sent to the server.

Values: 1–32,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 triggers—that is, the destination IPs/ports on which the devices identifies an ongoing attack.

Values: 10–100,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: 16–4096

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: 10–100,000

Default: 16,384

SYN Protection Attack Detection Entries

The maximum number of SYN Protection Attack Detection Entries. Values: 10–1,000,000

Default: 16,384

SYN Statistics Entries The maximum number of SYN Statistics Entries. Values: 1–1000

Default: 10



Tuning Diagnostics ParametersThe changes to the tuning configuration take effect after a device reset.

To configure the Diagnostics tuning parameters

1. Select Services > Tuning > Diagnostics. The Diagnostics Tools Tuning pane is displayed.

2. In the Policies after reset field, configure the parameter; and then, click Set. Values: 1–256. Default: 16.

Tuning Security ParametersSecurity Tuning parameters comprise the following:

• Tuning Application Security parameters

• Tuning Behavioral DoS parameters

Tuning Application Security ParametersThe Application Security Tables store information about sessions passing through the device and their sizes, which are correlated to the actual amount of sessions.


To configure the Application Security Tuning parameters

1. Select Services > Tuning > Security > Application Security. The Application Security Tuning Parameters pane is displayed.


Table 30: Application Security Tuning Parameters

Parameter DescriptionMaximal number of groups to be defined by user

The maximum number of groups defined in the User Groups table. The Groups Table lists the number of

entries of attack groups defined by the user.i

Values: 1–300

Default: 50

Maximal number of attacks to be defined by user

The maximum number of attack entries in the User Attacks Database Table. The Attacks Database Table contains attacks provided by Radware as well as user-defined attacks.i

Values: 1–2000

Default: 100



Maximal number of srcIPs in Suspend Table

This Suspend Table allows the user to define that for certain attacks, in addition to the action defined in the attack, the device should also suspend traffic from the IP address that was the source of the attack, for a period of time.i

The maximum amount of source lP addresses in the Suspend Table. All traffic from the IP address identified as source of this attack will be suspended.

Values: 1000–100,000

Default: 10,000

Counters Source Table The number of sessions to check the source address. i

Values: 100–100,000

Default: 16,384

Counters Target Table Then number of sessions to check the target address.i

Values: 100–64,000

Default: 16,384

Counters Source & Target Table The Source & Target Table contains an attack detection mechanism, which is based on the source and destination addresses of the incoming traffic. Each entry of this table contains source and destination addresses. If the number of packets sent from the same source to the same destination is above the predefined limit, this is identified as an attack. The Source & Target Table tuning parameter defines in how many sessions to check the source.i

Values: 100–64,000

Default: 16,384

Counters DHCP Table The number of entries in the Counters DHCP Table that contains attacks detection mechanism based on counting of IP requests for each MAC address. The requests are made using the Dynamic Host Configuration Protocol. When the number of IP requests for a particular MAC address is above the predefined limit, an attack is identified.i

The DHCP Discover tuning parameter determines for how many MAC addresses to check the number of IP requests.

Values: 100–64,000

Default: 16,384





Tuning Behavioral DoS ParametersThe changes to the tuning configuration take effect after a device reset.

To modify the maximal number of Behavioral DoS policies that the device supports

1. Select Services > Tuning > Security > Behavioral DoS. The Behavioral DoS Tuning Parameters pane is displayed.

2. In the Maximal number of Behavioral DoS policies after reset field, configure the parameter; and then, click Set. Values: 1–1000. Default: 1.

Tuning Virtual Tunneling ParametersVirtual Tunneling tables are used to define the Virtual Tunneling tuning parameters.


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.

Maximal number of entries in NCPF table The maximal number of entries in NCPF table.i

Values: 16–16,000

Default: 2000

Maximal number of Anti-Scanning IP pairs Table

The Anti-Scanning IP pairs table is an internal table which is not configured by the user.i

Values: 10,000–1,000,000

Default: 10,000

i – This parameter is exposed only if the device has an IPS license.





To configure the virtual-tunneling tuning parameters

1. Select Services > Tuning > Virtual Tunneling. The Virtual Tunneling Tuning pane is displayed.


The following table describes the virtual-tunneling tuning settings.

Device NotificationsMost administrators prefer to receive a warning message about a network or server outage. To help minimize the impact of failure in devices such as firewalls, routers, or application servers, LinkProof provides a choice of notification methods: CLI traps, syslog, and e-mail.

This section describes the LinkProof notification features, which distribute warning messages about failures and problems in network elements.

This section contains the following topics:

• CLI Traps, page 85

• Syslog Reporting, page 85

• SMTP E-mail Notifications, page 86

• Configuration Trace, page 87

Table 31: Virtual Tunneling Settings

Table DescriptionLocal Service Table The maximum number of entries in the Local Service Table.

Values: 1–8

Default: 4

Remote Service Table The maximum number of entries in the Remote Service Table.

Values: 1–32

Default: 12

Tunnels per remote service The maximum number of entries in the Tunnels per Remote Service Table.

Values: 1–100

Default: 12

Local Station table The maximum number of entries in the Local Station table.

Values: 1–32

Default: 24

Remote Station table The maximum number of entries in the Remote Station Table.

Values: 1–1024

Default: 250



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 ReportingLinkProof can mirror event traps to a specified syslog server.

You can also define additional notification criteria such as Facility and Severity, which are expressed by numerical values. Facility indicates the type of device of the sender, while Severity indicates the importance or impact of the reported event. The user-defined Facility value is used when the device sends Syslog messages. The default value is 21, meaning Local Use 6, which is the value used by LinkProof versions previous to 3.0. The Severity value is determined dynamically by the device for each message that the device sends.

To configure sending traps to a syslog server

1. Select Services > Syslog Reporting. The Syslog Reporting pane is displayed.


Table 32: Syslog Reporting Parameters

Parameter DescriptionSyslog Operation Enables or disables syslog reporting.


Syslog Station Address The IP address of device running the syslog service (syslogd).

Default: 0.0.0.0



SMTP E-mail NotificationsYou can configure the LinkProof device to send e-mail messages to users configured in the device’s 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.

Syslog Station Facility 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

Table 32: Syslog Reporting Parameters




To configure e-mail notifications

1. Select Services > SMTP. The SMTP pane is displayed.


Configuration TraceLinkProof 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

Table 33: SMTP Parameters

Parameter DescriptionSMTP Primary Server Address The IP address of the SMTP server.

SMTP Alternate Server Address An IP address of an alternative SMTP server. The alternate SMTP server is used when SMTP connection cannot be established successfully with the main SMTP server, or when 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.

Own Email Address The mail address of the device. For example [email protected].

SMTP Status Enables or disables the SMTP client.


Default: disable

Note: The SMTP Status must enable to support features that are related to sending e-mail messages.

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.


Default: disable



DNS-Client UtilityYou 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. Select Services > DNS. The DNS Client Parameters pane is displayed.


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.


4.

Table 34: DNS Client Parameters

Parameter DescriptionPrimary DNS Server The IP address of the primary DNS server.

Alternate DNS Server The IP address of the alternate DNS server.

Table 35: DNS Client Parameters

Parameter DescriptionHost Name The domain name for the specified IP address.

IP Address The IP address for the specified domain name.



Show Tech-SupportA LinkProof device can generate a technical-support file, which you can save to a specified location and send to Radware Technical Support to help diagnose problems.

Using the CLI, the technical-support file includes the following:

• The data that Radware Technical Support typically needs to diagnose a problem with a LinkProof device. The data comprises the collected output from various CLI commands.

• A record of each configuration change to the device (by any management interface). A device begins storing these records when the device receives its first command. The records are sorted by date in ascending order. When the size of the data exceeds the maximum allowed size (2 MB), the oldest record is overwritten. The entire data is never cleared unless you erase the device configuration.

• lp_support.txt—Contains the data that Radware Technical Support typically needs to diagnose a problem with a LinkProof device. The data comprises the collected output from various CLI commands.

• auditLog.log—Contains record of each configuration change to the device (by any management interface). A device begins storing these records when the device receives its first command. The records are sorted by date in ascending order. When the size of the data exceeds the maximum allowed size (2 MB), the oldest record is overwritten. The entire data is never cleared unless you erase the device configuration

The structure of each record in the auditLog.log file is as follows:

<dd>-<MM>-<yyyy> <hh>:<mm>:<ss> <Event description>

Example:

06-12-2009 19:16:11 COMMAND: “logout” by user radware via Console

To generate and display the output of the technical-support file on the terminal using CLI


manage support display

To generate a technical-support file and send it to a TFTP server using CLI


manage support tftp put <file name> <TFTP server IP address> [-v]

where:

-v displays also the output of the command.

To generate and download the technical-support file using Web Based Management

1. Select File > Support. The Download Tech Support Info File pane is displayed.

2. Click Set. A File Download dialog box opens.

3. Click Open or Save and specify the required information.



DiagnosticsLinkProof supports the following diagnostic tools:

• Traffic Capture

• Trace-Log

Diagnostic tools are only available using CLI or Web Based Management.

Diagnostic tools start working only after there is a diagnostic policy configured on the device (see Diagnostics Policies, page 95) and the relevant options are enabled.

Diagnostic tools stop automatically in the following cases:

• You stop the relevant task.

• You reboot the device. That is, when the device reboots, the status of the Capture Tool reverts to Disabled.


• Traffic Capture Tool, page 90

• Trace-Log, page 91

• Diagnostic Tools Files Management, page 95

• Diagnostics Policies, page 95

Traffic Capture ToolThe Traffic Capture tool captures packets that enter the device, leave the device, or both. The captured traffic is in TCPDUMP format. You can download the captured packets, and analyze the traffic using Unix snoop or various tools. For remote administration and debugging, you can also send captured traffic to a terminal (CLI, Telnet, and SSH). You can specify where the device captures packets to get a better understanding of the traffic flow—especially if the device manipulates the packets—due 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.




Trace-LogThe 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.

Table 36: Capture Tool Configuration Parameters

Parameter DescriptionStatus Specifies whether the Capture Tool is enabled.


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 Flash—The device stores the data in RAM and appends the data to the file on the CompactFlash drive. Due to limits on CompactFlash size, LinkProof uses two files. When the first file becomes full, the device automatically switches to the second, until it is full and then it overwrites the first file, and so on.

• RAM Drive—The device stores the data in RAM.

• None—The 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.


Default: Disabled

Capture Point Specifies where the device captures the data.

Values:

• On Packet Arrive—The device captures packets when they enter the device.

• On Packet Send—The device captures packets when they leave the device.

• Both—The 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 sides—the 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 only—Capture the client-side session only.

• Inbound and Outbound—Capture both the client-side and the corresponding server-side sessions.

Default: Inbound only



LinkProof uses the following format for Trace-Log files:

trace_log_<Device Name>_ddMMyyyy_hhmmss_<file number>.txt


• Trace-Log Tool Configuration, page 92

• Diagnostics Trace-Log Message Format, page 92

• Trace-Log Modules, page 93

Trace-Log Tool Configuration

To configure the Trace-Log tool

1. Select Services > Diagnostics > Trace-Log > Parameters. The Diagnostics Trace-Log Tool Configuration pane is displayed.


Diagnostics Trace-Log Message Format Use the Diagnostics Trace-Log Message Format pane to specify which parameters appear in the Trace-Log message.

Table 37: Trace-Log Tool Configuration Parameters

Parameter DescriptionStatus Specifies whether the Trace-Log tool is enabled.


Default: Disabled

Output To File Specifies the location of the stored data.

Values:

• RAM Drive and Flash—The device stores the data in RAM and appends the data to the file on the CompactFlash drive. Due to limits on CompactFlash size, LinkProof uses two files. When the first file becomes full, the device automatically switches to the second, until it is full and then it overwrites the first file, and so on.

• RAM Drive—The device stores the data in RAM.

• None—The 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.


Default: Disabled

Output To Syslog Server Specifies whether the device sends Trace-Log data to a syslog server.


Default: Disabled



To configure the diagnostics Trace-Log message format

1. Select Services > Diagnostics > Trace-Log > Message Format. The Diagnostics Trace-Log Message Format pane is displayed.


Trace-Log ModulesTo 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.

Table 38: Diagnostics Trace-Log Message Format Parameters

Parameter DescriptionDate Specifies whether the date that the message was generated is included in the

Trace-Log message.

Time Specifies whether the time that the message was generated is included in the Trace-Log message.

Platform Name Specifies whether the platform MIB name is included in the Trace-Log message.

File Name Specifies whether the output file name is included in the Trace-Log message.

Line Number Specifies whether the line number in the source code is included in the Trace-Log message.

Packet Id 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.

Module Name Specifies whether the name of the traced module is included in the Trace-Log message is included in the Trace-Log message.

Task Name Specifies whether the name of the specific task of the traced module is included in the Trace-Log message.



To configure the parameters of the Trace-Log modules

1. Select Services > Diagnostics > Trace-Log > Modules. The Trace-Log Modules pane is displayed.

The table in the pane comprises the following columns:

2. Click the relevant link. The Trace-Log Modules Update pane is displayed.


Column DescriptionName Name of the module.

Values:

• BWM

• GENERIC

• HMM

• LCD

Status Current status of the traced module.

Severity The lowest severity of the events that the Trace-Log includes for this module.

Values:

• Emergency

• Alert

• Critical

• Error

• Warning

• Notice

• Info

• Debug

Table 39: Trace-Log Modules Update Parameters

Parameter DescriptionStatus Specifies whether the Trace-Log feature is enabled for the module.

Severity 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

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:

2. From the Action column, select the action, Download or Delete, and follow the instructions.

Diagnostics PoliciesIn most cases, there is no need to capture all the traffic passing through the device. Using diagnostic policies, the device can classify the traffic and store only the required information.

Note: To reuse the policy, edit the policy and set it again.

To configure a diagnostics policy using Web Based Management

1. Select Services > Diagnostics > Policies. The Diagnostics Policies pane is displayed.

2. Click Create. The Diagnostics Policies Create pane is displayed.


Parameter DescriptionFile Name The name of the file.

File Size The file size, in bytes.

Action The action that you can take on the data stored.

Values:

• download—Starts the download process of the selected data. Follow the on-screen instructions.

• delete—Deletes the selected file.



Table 40: Diagnostics Policies Parameters

Parameter DescriptionName The user-defined name of the policy up to 20 characters.

Index The number of the policy in the order in which the diagnostics tools classifies (that is, captures) the packets.

Default: 1

Description The user-defined description of the policy.

VLAN Tag Group The VLAN Tag group whose packets the policy classifies (that is, captures).

Destination The destination IP address or predefined class object whose packets the policy classifies (that is, captures).

Default: any—The diagnostics tool classifies (that is, captures) packets with any destination address.

Source The source IP address or predefined class object whose packets the policy classifies (that is, captures).

Default: any—The 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).

Inbound Port Group The port group whose inbound packets the policy classifies (that is, captures).

Service Type The service type whose packets the policy classifies (that is, captures).

Service The service whose packets the policy classifies (that is, captures).

Values:

• None

• Basic Filter

• AND Group

• OR Group

Default: None

Destination MAC Group The Destination MAC group whose packets the policy classifies (that is, captures).

Source MAC Group 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 The maximal length for a packet the policy captures.

Capture Status Specifies whether the packet-capture feature is enabled in the policy.


Default: Disabled

Trace-Log Status Specifies whether the Trace-Log feature is enabled in the policy.


Default: Disabled



Management InterfacesThis section describes the management interfaces that LinkProof supports and contains the following topics:

• Configuring a Telnet Management Interface, page 97

• Configuring Web Server Management Interfaces, page 98

• Configuring an SSH Interface for Management, page 100

• Configuring an FTP Interface for Management, page 101

Configuring a Telnet Management Interface You can access LinkProof via Telnet. You can configure Telnet access using Web Based Management or CLI.

To configure a Telnet management interface

1. Select Services > Management Interfaces > Telnet. The Telnet Parameters pane is displayed.


Table 41: Telnet Parameters

Parameter DescriptionTelnet Port The TCP port used by the Telnet.

Telnet Status Enables and disables the Telnet interface.

Telnet Session Timeout The time, in minutes, that the device maintains a connection during inactive periods.

Values:

• 0—Specifies no timeout

• 1–120

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: 10–60

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. Select Services > Management Interfaces > Web Server > Web. The Web Server Parameters pane is displayed.


Table 42: Web Server Parameters

Parameter DescriptionWeb Server Port Port to which the Web Based Management is assigned.

Web Server Status Enables or disables the status of the Web server.



Secure WebYou 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.


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

Web Help Location Location (path) of the Web help files.

Web Access Level The access level for Web Based Management or Secure Web Based Management.

Values:

• Read Write

• Read Only—Users 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.

Table 43: Secure Web Parameters

Parameter DescriptionSecure Web Certificate Entry Name Specifies the Certificate file used by secure Web for

encryption.

Secured Web Port Specifies the port through which HTTPS gets requests.

Secured Web Status Specifies the status of the secure Web server.


Default: disable

Table 42: Web Server Parameters




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. Select Services > Management Interfaces > Web Server > Web Services. The Web Services pane is displayed.

2. From the Web Services Status drop-down list, select enable, or disable.

3. 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. Select Services > Management Interfaces > SSH > Server. The Secure Shell Parameters pane is displayed.


Table 44: Secure Shell Parameters

Parameter DescriptionSSH Port The source port for the SSH server connection.

SSH Status Enables or disables the SSH feature. When disabled, an SSH connection is not possible.


Default: Disable

SSH Session Timeout Timeout, in minutes, required for the device to maintain a connection during periods of inactivity.

Values: 1–120

Default: 5

SSH Authentication Timeout

Timeout, in seconds, required to complete the authentication process.

Values: 10–60

Default: 30



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.


RADIUS Authentication for ManagementBefore a management session starts, LinkProof can authenticate the user with a RADIUS server. You can also select whether or not to use the User Table when a RADIUS server is not available.

RADIUS Authentication is available for the following interfaces:

• CLI

• Telnet

• Web Based Management

• SSH

Note: When you enable and configure the RADIUS Authentication feature, the RADIUS server must be available and accessible to the LinkProof device.

Table 45: FTP Server Parameters

Parameter DescriptionFTP Server Port Specifies the application port to access the FTP server on the device.

Default: 21

FTP Server Status Specifies the status of the FTP server on the device.


Default: disable



To configure RADIUS Authentication for device management


a. Select Security > Users. The User Table and Authentication pane is displayed.b. Set the following parameter:

c. Click Set.


a. Select Services > RADIUS. The RADIUS Parameters pane is displayed. b. Set the following parameters:

c. Click Set.

Parameter DescriptionAuthentication Method The method for of authenticating a user’s access to the device.

Values:

• Local User Table—The device uses the User Table to authenticate access.

• RADIUS and Local User Table—The device uses the RADIUS servers to authenticate access. If the request to the RADIUS server times out, the device uses the User Table to authenticate access.

Default: Local User Table

Parameter DescriptionMain RADIUS IP Address IP address of the primary RADIUS server.

Main RADIUS Port Number Access port number of the primary RADIUS server.

Values: 1645, 1812

Main RADIUS Secret Authentication password for primary RADIUS server.

Backup RADIUS IP Address IP address of the backup RADIUS server.

Backup RADIUS Port Number Access port number of the backup RADIUS server.

Values: 1645, 1812

Backup RADIUS Secret Authentication password for backup RADIUS server.

RADIUS Retries Defines number of connection retries to the RADIUS server, when the RADIUS server does not respond to the first connection attempt.

RADIUS Timeout How many seconds device waits for reply from the RADIUS server before a retry, or, if the RADIUS Retries value is exceeded, before the device acknowledges that the server is off line.

RADIUS Client Lifetime Duration, in seconds, for client authentication. After the lifetime expires, the device re-authenticates the user.



LoggingThis section includes details on viewing and enabling various logs for use with LinkProof, and includes these topics:

• Event Log, page 103

• SMTP Logging, page 103

• Power Supply Traps, page 104

Event LogYou 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 LoggingLinkProof can sends SMTP log messages asynchronously to designated locations. You must set a logging output location to view any logs.

LinkProof can send SMTP traps in e-mail messages to specified users. Each user receives e-mail messages according to the specified severity level (Info, Warning, Error or Fatal), which is configured in the User Table.

To configure an SMTP client

1. Select Services > SMTP. The SMTP pane is displayed.


Table 46: SMTP Client Parameters

Parameter DescriptionSMTP Primary Server Address

Specifies the IP address of the SMTP server.

SMTP Alternate Server Address

Specifies the IP address of an alternative SMTP server. The alternate SMTP server is used when an SMTP connection cannot be established successfully with the main SMTP server, or when the main SMTP server closed the connection. The device tries to establish a connection to the main SMTP server, and starts reusing it when it available.

Own Email Address Specifies the e-mail address of the device.



Power Supply TrapsLinkProof 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. Select Services > Logging > SNMP Traps. The Power Supply Trap Status pane is displayed.

2. Configure the parameter; and then, click Set.

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.

SMTP Status Specifies the status of the SMTP client. The value must be enable to support features that are related to sending e-mail messages.


Default: disable

Send Email on Errors Specifies whether the device sends e-mail when an error occurs.


Default: disable

Table 47: Power Supply Trap Status Parameter

Parameter DescriptionPower Supply Trap Status 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.


Default: enable

Table 46: SMTP Client Parameters



Chapter 3 – Basic Switching and RoutingThis chapter describes switching and routing in the context of LinkProof.


• Port Settings, page 105

• Virtual LAN, page 112

• IP Addressing and Routing, page 122

Port SettingsThis section describes LinkProof features that handle traffic and port management and contains the following topics:

• Port Mirroring, page 105

• Link Aggregation—Port Trunking, page 106

• Port Rules, page 110

• Port Load Balancing Status, page 111

Port MirroringOnly 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.

LinkProof User Guide Basic Switching and Routing


To configure port mirroring

1. Select Device > Port Mirroring. The Port Mirroring Table pane is displayed.

2. Click Create. The Port Mirroring Table Create pane is displayed.


Link Aggregation—Port TrunkingLink 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.

Table 48: Port Mirroring Parameters

Parameter DescriptionInput Port The port from which the traffic is mirrored.

Output Port The port to which traffic is mirrored.

Receive/Transmit Select the direction of traffic to be mirrored.

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:

• Enabled—All traffic is copied to the output port.

• Disabled—Only traffic destined to the input port is copied.

Default: Enabled

Backup Port The port for output when the output port is down.

Default: 0—Specifies no backup port

LinkProof User GuideBasic 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 client’s MAC address.

The LinkProof Link Aggregation feature allows defining up to seven trunks. Up to eight physical links can be aggregated into one trunk. All trunk configurations are static.

To provide optimal distribution for different scenarios the load sharing algorithm allows decisions based on source or destination (or both) L2 address (MAC), L3 address (IP), and L4 address (TCP/UDP port numbers). These parameters are used as input for a hashing function.

Notes:>> A port belonging to a trunk should not be copied to another port.

>> A trunk cannot be mirrored.

>> Ports that are part of a trunk cannot be used in port rules. The entire trunk, however, can be used in port rules.

>> Radware recommends that you configure Link Aggregation using CLI.

>> When choosing the Link Aggregation configuration using Web Based Management, it important for the administrator to choose the valid Link Aggregation configuration from Table 49 - Supported Link-Aggregation Configurations for OnDemand Switch 2, page 107.

The following table lists combinations for link aggregation supported on the OnDemand Switch 2 platform.

Note: On OnDemand Switch VL platforms, combinations for link aggregation are not limited.


• Link Aggregation—Global Configuration, page 108

Table 49: Supported Link-Aggregation Configurations for OnDemand Switch 2

Layer 1 2 3 4 5 6 7 8 9 2 Source

MACDestination MAC

Both Ignore Ignore Ignore Ignore Ignore Ignore

3 Ignore Ignore Ignore Source IP

Destination IP

Both Source IP

Destination IP

Both

4 Ignore Ignore Ignore Ignore Ignore Ignore Source Port

Destination Port

Both



• Link Aggregation Trunk Table, page 108

• Link Aggregation Port Table, page 109

Link Aggregation—Global Configuration

To configure link aggregation

1. Select Device > Link Aggregation > Global Configuration. The Global Configuration pane is displayed.


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.

Table 50: Link Aggregation Global Configuration Parameters

Parameter DescriptionLayer 2 Specifies how the MAC address is used in the traffic distribution algorithm.

Values:

• Ignore—Do not use MAC address.

• Source MAC address—Use source MAC address

• Destination MAC address—Use destination MAC address.

• Both MAC addresses—Use both source and destination MAC addresses.

Default: Ignore

Layer 3 Specifies how the IP address is used in the traffic distribution algorithm.

Values:

• Ignore—Do not use IP address.

• Source IP address—Use source IP address.

• Destination IP address—Use destination IP address.

• Both IP addresses—Use 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:

• Ignore—Do not use application port.

• Source application port—Use source application port.

• Destination application port—Use destination application port.

• Both application ports—Use both source and destination application ports.

Default: Both application ports



Link Aggregation Port TableUse 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 DescriptionTrunk Index The trunk index identifier.

Values:

• T-1

• T-2

• T-3

• T-4

• T-5

• T-6

• T-7

• T-MNG

Trunk MAC Address The MAC address assigned to the trunk.

Trunk Status The status of the trunk

Values:

• Individual—No ports are attached to the trunk.

• Aggregate—Ports are attached to the trunk.

Parameter DescriptionPort Index The port index identifier. The list of identifiers depends on the

platform.

Port MAC The MAC address of the port.



2. From the Port Index column, click the relevant port. The Link Aggregation Ports Table Update pane is displayed

3. From the Trunk Index drop-down list, select the trunk to which to attach the port.

4. Click Set.

Port RulesPort 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.

Trunk Index 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:

• Individual—The port is not attached to any trunk.

• Aggregate—The port is attached to a trunk.




Rules TableUse the Rules Table pane to view what rules have been configured on the device. You cannot modify values in the table.

The Rules Table pane displays a table with the following columns:

• Port Number—The LinkProof port number from which the traffic enters.

• Leaving Port Number—The number of the LinkProof port through which traffic entering the LinkProof device can exit.

• Number Of Servers On Port—The 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 StatusFor 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:

— Enable—The device load balances traffic coming in through the port or routes the traffic according to flow policies and a destination address.

— Disable—Traffic always routes the traffic according to flow policies and a destination address.

Default: Enable

4. Click Set.



Virtual LANThis section describes the virtual LANs (VLANs) and how to configure them in the context of LinkProof and contains the following topics:

• Virtual LANs, page 112

• Supported VLAN Types, page 112

• IPv6 Pass-through, page 113

• Bridging, page 115

• VLAN Example Configuration, page 115

• Configuring VLANs, page 116

• Redundancy with VLANs, page 118

• VLAN Tagging, page 118

Virtual LANsA 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 TypesLinkProof 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 VLANA 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 2–Layer 7).

Two protocols can be used when configuring Regular VLANs:

• IP Protocol (ifIndex 100001)—Must be assigned an IP address. IP VLANs are automatically assigned a MAC address. All of the traffic between the ports is intercepted transparently by LinkProof. Packets that need intelligent intervention are checked and modified by LinkProof and then forwarded to the relevant port. Other packets are simply switched by LinkProof as if they were on the same wire.

• Other Protocol (ifIndex 100000)—Includes all protocols for which VLANs have not been defined, but it does not include an IP. A VLAN with the protocol Other cannot be assigned an IP address. This type of VLAN is used to bridge the non-IP traffic through LinkProof. You can define this option also with the Switched type VLAN (Switched VLAN protocol) for wire-speed performance.



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 VLANSwitched 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 Protocol—Frames arriving at a VLAN port are switched according to Layer 2 data. LinkProof does not intercept any traffic.

• IP Protocol—Frames 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-throughIPv6 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 0–4). 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.



The scenario in the following figure shows the following configuration:

• Router 2—For IPv4 device—attached to port G-1 on the LinkProof device.

• Router 1—For IPv6 and IPv4 Traffic—attached to port G-3 on the LinkProof device.

• LAN connection—Attached to port G-4 on the LinkProof device.

IPv6 traffic passing inbound or outbound through Router 1 will be bridges across ports G-3 and G-4. This enables traffic to flow from the IPv6 connectivity WAN to the IPv6 server and vice versa, through the LinkProof device.

Figure 3: LinkProof Device with IPv6 Pass-Through

IPv6 Connectivity

WAN

Router 2

ISP 1ISP 1

RST

APSolute Application DeliveryPWR

USB MNG 2

MNG 1

CONSOLE

PWR

FAN

SYS OK

Link Proof100010/100

G1

G13 G14 G15 G16

G3 G5 G7 G9 G11

G2 G4 G6 G8 G10 G12

100010/100

LAN

Server supports dual stack (IPv4 and IPv6)

Router 1IPv6 capable

LinkProof device

Bi-directional IPv6 traffic

G-4

G-3G-1



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.

BridgingOnce 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 ConfigurationIn 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.



Figure 4: Example VLAN Configuration

Configuring VLANsThis section describes how to configure VLANs and contains the following topics:

• Configuring the Ethernet Type for User-defined VLANs, page 116

• Configuring the Virtual LAN Table and VLAN Port Table, page 117

Configuring the Ethernet Type for User-defined VLANs

To configure the Ethernet type for user-defined VLANs

1. Select Device > VLAN Parameters. The VLan Parameters pane is displayed.


Table 51: VLAN Ethernet Parameters

Parameter DescriptionVLAN Ethernet Type The Ethernet type for user-defined VLANs.

VLAN Ethernet Type Mask The mask on Ethernet type for user-defined VLANs.

Internet

Router192.1.1.100

Client193.1.1.2

Client193.1.1.1

Server192.1.1.11

P2P1

P3 P4User-side VLAN

100005

Network-side VLAN100003

LinkProof



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.


To add a physical port to the VLAN


2. Under VLAN Port Table, click Create. The VLAN Port Table Create pane is displayed.


Table 52: VLAN Interface Parameters

Parameter DescriptionInterface Number Specifies the interface number of the VLAN to be assigned.

Default: 0—Specifies no VLAN.

Protocol 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:

• Regular—The device acts as a bridge.

• Switch—The device acts as a switch. The OnDemand Switch VL platform does not support this option.

Table 53: Physical VLAN Port Parameters

Parameter DescriptionVLAN Interface Index Specifies the index number of the interface from the VLAN Table to

which you need to add a port.

VLAN Port Index Specifies the index number of the relevant port.



To change the protocol or type of an existing user-defined VLAN


2. Click on the relevant interface. The Virtual LAN Table pane is displayed.


Redundancy with VLANsWhen working with VLANs, you can configure two LinkProof devices in an Active/Backup redundancy setup.

For more information on LinkProof Redundancy configuration, see Redundancy, page 273.

VLAN TaggingThis section describes VLAN tagging and contains the following topics:

• VLAN Tagging Support, page 118

• Using VLAN Tagging, page 119

• Setting a VLAN Tag for an IP Interface, page 120

• Configuring VLAN Tagging, page 121

VLAN Tagging SupportVLAN Tagging is IEEE standard 802.1Q for supporting multiple VLANs associated with the same switch port. Each VLAN is tagged with a unique identifier to allow the identification of different VLAN traffic on the same physical port.

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

Table 54: VLAN Parameters

Parameter DescriptionInterface Number The interface number of the VLAN to be automatically assigned.

Type The required VLAN type.

Values:

• Regular—The device acts as a bridge.

• Broadcast—The device broadcasts the VLAN table to all the ports.

• Switched VLAN—The 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



Using VLAN TaggingVLAN 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.



In the following figure, tag 101 is associated to IP interface 10.1.1.10 and tag 102 is associated to IP Interface 20.1.1.10. All traffic to 10.1.1.x servers is tagged with the VLAN tag 101, while all traffic to 20.1.1x servers is tagged with the VLAN tag 102.

Figure 5: Example VLAN Tagging Configuration

Setting a VLAN Tag for an IP Interface

To set a VLAN tag for an IP interface

1. Select Router > IP Router > Interface Parameters. The IP Router Interface Parameters pane is displayed.


— 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.

3. In the VLAN Tag text box, type the required value for the VLAN tag. The value 0 indicates that no VLAN tag is used.

4. Click Set.

Servers

20.1.1.10 Tag 102

10.1.1.10 Tag 101

Servers

10.1.1.x 20.1.1.x

LinkProof



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.


Table 55: VLAN Tagging Parameters

Parameter Description802.1q environment Specifies whether the device handles VLAN tags traffic according to IEEE

802.1Q.

Values:

• Enabled—The device handles VLAN-tagged traffic according to IEEE 802.1Q.

• Disabled—The device drops all VLAN-tagged traffic.

Default: Disabled

VLAN Tag Handling Specifies how the device handles VLAN tags.

Values:

• Retain—The 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.

• Overwrite—The device performs VLAN tagging of outgoing traffic according to the IP interface configuration.

Default: Overwrite



IP Addressing and RoutingThis section describes the configuration of VLAN IP addressing and routing and contains the following topics:

• IP Addressing, page 122

• Routing, page 122

• Routing Information Protocol, page 124

• Configuring ARP Parameters, page 126

• IP Router Operating Parameters, page 127

• Open Shortest Path First (OSPF), page 130

IP AddressingIP addresses are 32-bit binary numbers. Each 32-bit IP address consists of two sub-addresses, one identifying the network and the other identifying the host to the network, with an imaginary boundary separating the two.

The location of the boundary between the network and host portions of an IP address is determined through the use of a subnet mask. A subnet mask is another 32-bit binary number that acts like a filter when it is applied to the 32-bit IP address. By comparing a subnet mask with an IP address, systems determine which portion of the IP address relates to the network, and which portion relates to the host. Anywhere the subnet mask has a bit set to 1, the underlying bit in the IP address is part of the network address. Anywhere the subnet mask is set to 0, the related bit in the IP address is part of the host address.

RoutingRouting 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 RoutingLinkProof 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.


To update a Routing Table entry


2. Select a Destination Address. The Routing Table Update pane is displayed.


Table 56: Routing Table Entry Parameters

Parameter DescriptionDestination Address Specifies the destination IP address of this router.

Network Mask Specifies the destination network mask of this route.

Next Hop Specifies the address of the next system of this route, local to the interface.

Interface Index Specifies the interface index of the local interface through which the next hop of this route is reached.

Type Specifies how remote routing is handled.

Values:

• other—Not used

• reject—Discards packets

• local—Any routing that is associated with local IP interfaces

• remote—Forwards packets

Metric Specifies the number of hops to the destination network.

Table 57: Routing Table Update Parameters

Parameter DescriptionDestination Address Displays (read-only) the destination IP address of this router.

Network Mask Displays (read-only) the destination network mask of this route.

Next Hop Displays (read-only) the address of the next system of this route, local to the interface.

Interface Index Specifies the interface index of the local interface through which the next hop of this route is reached.



Configuring a Default Gateway

Note: You can set up a backup default gateway for LinkProof.

To configure a default gateway


2. Click Create. The Routing Table Create pane is displayed.


Routing Information ProtocolRouting 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.


Values:





Protocol Displays (read-only) the specified Type read-only.

Metric Specifies the number of hops to the destination network.

Table 58: Default Gateway Parameters

Parameter Value/DescriptionDestination Address Use 0.0.0.0 for the destination IP address of the default gateway.

Network Mask Use 0.0.0.0 for the destination network mask of the default gateway.

Next Hop Address of the next system of this route, local to the interface.

Interface Index The IF Index of the local interface through which the next hop of this route is reached.


Values:





Metric Number of hops to the destination network.

Table 57: Routing Table Update Parameters




Using RIP, a gateway host (with a router) sends its entire routing table, which lists all the other hosts that it recognizes, to its closest neighbor host every 30 seconds. The neighbor host then passes the information on to its next available neighbor and so on until all hosts within the network have the same knowledge of routing paths. This is known as network convergence. RIP uses a hop count as a means to determine network distance. Other protocols use more sophisticated algorithms, including timing. Each host with a router in the network uses the routing table information to determine the next host to route a packet to a specified destination.

LinkProof supports RIP versions 1 and 2.

Configuring the RIP Parameters

To configure the RIP parameters

1. Select Router > RIP > Parameters. The RIP Parameters pane is displayed.


Configuring the RIP Parameters of a Specific Interface

To configure the RIP parameters of a specific interface

1. Select Router > RIP > Interface Parameters. The RIP Interface Table pane is displayed.

2. Select the interface to edit. The RIP Interface Table Update pane is displayed.


Table 59: RIP Parameters

Parameter DescriptionAdministrative Status The administrative status of the RIP in the router. Disabled means the

process is not active on any interfaces

Leak Static Routes Controls redistribution of routes from static routes to RIP. When this parameter is enabled, all static routes learned via static are advertised into RIP.

Leak OSPF Routes Controls redistribution of routes from OSPF to RIP. When this parameter is enabled, all routes learned via OSPF are advertised into RIP.

Use Port Rules in Advertisement

Specifies whether the device sends advertisements through the corresponding port in the Port Rules Table or to all ports.

Values:

• Enable—The device sends advertisements through the corresponding port in the Port Rules Table. That is, the device applies port rules also to RIP advertisements.

• Disable—The 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.

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 ARP Parameters

To configure ARP parameters

1. Select Router > IP Router > ARP Table. The ARP Table pane is displayed.

2. Click Create. The ARP Table Create pane is displayed.

Table 60: RIP Interface Parameters

Parameter DescriptionIP Address The IP address of the current interface (read-only).

Outgoing RIP The type of RIP to be sent.

Values:

• rip1—Send RIP updates compliant with RFC 1058.

• ripC—Send RIP C updates.

• rip2—Send multicast RIP-2 updates.

• ripV1—Send RIP updates compliant with RFC 1058.

• ripV2—Send multicast RIP-2 updates.

• doNotSend—Send no RIP updates.

Default: rip1

Incoming RIP The type of RIP to be received.

Values:

• rip1—Accept RIP 1

• rip2—Accept RIP 2

• rip1OrRip2—Accept RIP 1 or RIP 2

• doNotReceive—Accept no RIP updates

Default Metric Metric for the default route entry in RIP updates originated on this interface.

Values:

• 0—Specifies that no default route is originated, and a default route via another router may be propagated.

• 1–15

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

Auto Send 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.





Configuring the ARP Timeout

To configure the ARP timeout

1. Select Router > IP Router > Operating Parameters. The IP Router Parameters pane is displayed.

2. Specify the value for the Inactive ARP Timeout parameter. This is the maximum number of seconds that can pass between ARP requests for an entry in the ARP table. After this period, the entry is deleted from the table.

3. Click Set.

IP Router Operating Parameters

To configure IP router parameters



Table 61: ARP Parameters

Parameter DescriptionInterface Index The interface number on which the station resides.

MAC Address The MAC address of the station.

IP Address The IP address of the station.

Type The entry type.

Values:

• other—Not used.

• invalid—Deletes an existing ARP entry from the table.

• dynamic—The 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.

• static—The entry has been configured by the network management station and is permanent.



IP Router Interface ParametersUse the IP Router Interface Parameters pane to configure IP router interfaces and edit Internet Control Message Protocol (ICMP) parameters of an existing interface.

To configure an IP router interface

1. Select Router > IP Router > Interface Parameters. The IP Router Interface Parameters pane is displayed, which list current IP interfaces.


— 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.


Table 62: IP Router Parameters

Parameter DescriptionInactive 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.

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:

• enable—The device responds to all ARP requests.

• disable—The device responds only to ARP requests for its own IP addresses.

Default: disable

ICMP Error Messages Specifies whether ICMP error messages are generated.


Default: enable

Advanced Fast Forwarding Status

Specifies whether the IP Fast Forward Table is used (enabled). When enabled, the table holds MAC-address information of servers only (pre-defined in the LinkProof farms) and not clients.


Default: Disable

Table 63: IP Router Interface Parameters

Parameter DescriptionIP Address The IP address of the interface.

Default: 0.0.0.0

If Number The interface identifier.

Network Mask The associated subnet mask.Default: 0.0.0.0



To edit the ICMP parameters of an interface


2. From the ICMP Interface Parameters table, click the IP address of the relevant interface. The ICMP Interface Parameters Update pane is displayed.


Fwd Broadcast Specifies whether the device forwards incoming broadcasts to the interface.Values: Enable, Disable

Default: Disable

Broadcast Addr How the device fills the host ID in the broadcast address.• ONE FILL—Fill with ones

• ZERO FILL—Fill with zeros

Default: ONE FILL

VLAN Tag The VLAN tag associated with the interface. When multiple VLANs are associated with the same switch port, the switch needs to identify to which VLAN to direct incoming traffic from that specific port. VLAN tagging provides an indication in the layer 2 header, which enables the switch to make the correct decision.Default: 0

One Ip (Router Interface Only)

Specifies whether the device uses the One-IP-for-NAT feature.For more information, see One-IP-for-NAT Support, page 171.


Default: Disable

Peer Address Specifies the IP address of the interface on the peer device, which is required in a redundant configuration. For more information, see Copying a Device Configuration for a Redundant Environment, page 269.Default: 0.0.0.0


Parameter DescriptionAdvert. Address The IP destination address for multicast Router Advertisements sent

from the interface. Values:

• 224.0.0.1—That is, the all-systems multicast address

• 255.255.255.255—That 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





Open Shortest Path First (OSPF)Open Shortest Path First (OSPF) is an interior gateway routing protocol developed for IP networks and based on the shortest path first or link-state algorithm.

Routers use link-state algorithms to send routing information to all nodes in a network by calculating the shortest path to each node based on a topography of the Internet constructed by each node.

After sending the routing information, each router sends the portion of the routing table (keeping track of routers to particular network destinations) that describes the state of its own links, as well as sending the complete routing structure (topography).

Shortest-path-first algorithms allow you to perform more frequent updates.

With OSPF, you can build a more stable network, since fast convergence prevents such problems as routing loops and Count-to-Infinity (when routers continuously increment the hop count to a particular network).

Caution: Shortest-path-first algorithms require a large amount of CPU power and memory.

OSPF Operating Parameters

To set the OSPF Operating Parameters

1. Select Router > OSPF > Operating Parameters. The OSPF Operating Parameters pane is displayed.


Min Advert. Interval The minimum time, in seconds, between sending unsolicited multicast Router Advertisements from the interface. Values: any value between 3 and the Max Advert. IntervalDefault: 450—This value is 75% of the default Max Advert. Interval.

Advert. Lifetime The maximum time, in seconds, that the advertised addresses are considered valid. Values: any value between the Max Advert. Interval up to 9000

Default: 1800—This value is three times the default Max Advert. Interval

Advertise Specifies whether the device advertises the device IP address using ICMP Router Advertise.

Preference Level The preference level of the address as a default router address, relative to other router addresses on the same subnet.

Reset to Defaults Resets the ICMP interface parameters to the default values.Values: TRUE, FALSE

Default: FALSE





OSPF Interface Parameters

To update the OSPF interface parameters

1. Select Router > OSPF > Interface Parameters. The OSPF Interface Parameters pane is displayed.

2. Select the IP Interface. The OSPF Interface Table Update pane is displayed.

Table 65: OSPF Operating Parameters

Parameter DescriptionAdministrative Status Specifies the OSPF status on the device.

Values:

• enabled—The OSPF process is active on at least one interface.

• disabled—The process is not active on any interfaces.

Default: disabled

Router ID The ID number of device. To ensure uniqueness, the value should equal one of the router IP addresses.

Leak RIP Routes Specifies whether the LinkProof device advertises as external routes all routes inserted into the IP routing table via SNMP into OSPF.

Values:

• enable—all Routes inserted into the IP routing table via SNMP are advertised into OSPF as external routes.

• disable—The process is not active on any interfaces.

Default: disable

Leak Static Routes Controls redistribution of routes from static routes to RIP.

Values:

• enable—All 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:

• enable—All 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).


Default: disable

Conditional OSPF leak on NHR health

Specifies whether or not LinkProof allows NHR health information to leak via OSPF routing updates.


Default: disable




OSPF Area ParametersAn 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.

Table 66: OSPF Interface Parameters

Parameter DescriptionIP Address IP address of this OSPF interface.

Interface Type OSPF interface type. Values:

• broadcast—For broadcast LANs

• nbma—For x.25 and Frame Relay

• pointToPoint—For point-to-point LANs

• pointToMultipoint

Administrative Status Administrative status of the OSPF in the router. Values:

• enabled—The OSPF process is active on at least one interface.

• disabled—The 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.

Hello Interval The time, in seconds, between Hello packets. All routers attached to a common network must have the same Hello Interval.

RtrDeadInterval Number of seconds that the router’s Hello packets have not been seen before the router’s 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.

Interface State The interface state of the OSPF interface.

Values:

• Down—OSPF interface is down.

• Waiting—OSPF interface is currently waiting.

• Point to Point—OSPF interface is in point to point state.

• Designated Router—OSPF interface is the designated router.

• Backup Designated Router—OSPF interface is the backup designated router.

Designated Router Address of designated router, if Interface state is Designated Router.

Backup Designated Router Address of the backup designated router, if the Interface state is Backup Designated Router.

IfAuthKey Authentication key for the interface.

AuthType Type of authentication key for the interface.



To configure OSPF area parameters

1. Select Router > OSPF > Area Parameters. The OSPF Area Parameters Table pane is displayed.


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.

OSPF Link State DatabaseOSPF 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:

Table 67: OSPF Area Parameters

Parameter DescriptionArea ID IP address of the area.

Import AS Extern Ability to import autonomous system external link advertisements.

Number of AS Border Routers Total number of Autonomous System border routers reachable within this area. This is initially 0 and calculated in each SPF pass.

Area LSA Count Number of internal link-state advertisements in the link-state database.

Area LSA Checksum Sum Sum of LS checksums of internal LS advertisements contained in the LS database. Use this sum to determine if there has been a change in a router's LS database, and to compare the LS database of two routers.

Parameter DescriptionArea ID IP address of the area.

Type Each link state advertisement has a specific format. The link can be a Router Link, Network Link, External Link, Summary Link or Stub Link.

Link State ID Identifies a piece of routing domain described by the advertisement. It can be a router ID or an IP address.



3. When updating Link State Database, in the OSPF Link State Database pane, select the Area ID.

4. Click Set.

OSPF Neighbor TableAs 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. Select Router > OSPF > Neighbor Table. The OSPF Neighbor Table pane is displayed.

2. You can view the following parameters:

3. When updating the OSPF Neighbor Table, in the OSPF Neighbor Table pane, select the Neighbor’s 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.

Router ID Identifies the originating router in autonomous system.

Sequence Number for link. Use this to detect old and duplicate link state advertisements. The larger the sequence number the more recent the advertisement.

Parameter DescriptionNeighbor's Address IP address of this neighbor.

Address Less Index If the interface is without an IP address, index appears in this field. If there is an IP address, 0 appears.

Router ID Unique identifier for the neighboring router in the autonomous system.

Options A bit mask corresponding to the neighbor's options.

Priority Priority of this neighbor. Priority of 0 means neighbor cannot become the designated router on the network.



Chapter 4 – Basic Application SwitchingThis chapter describes farm management farm-related features. It also provides you with examples of common configurations of application-switching and load-balancing schemes.


• LinkProof Multihoming Overview, page 135

• Farm Management, page 138

• Server Management, page 155

• Network Address Translation, page 167

• Proximity, page 176

• DNS, page 182

• Basic Load Balancing, page 188

• Load Balancing Weights, page 194

• Flow Management, page 194

• Client Table, page 200

• VPN Load Balancing, page 218

LinkProof Multihoming OverviewThis 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 TrafficOutbound 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.

LinkProof User Guide Basic Application Switching


Figure 6: Example Multihoming Outbound Traffic

Figure 6 - Example Multihoming Outbound Traffic, page 136 shows a scenario where a user on the local network (for example, IP 1.1.1.80) sends an outbound HTTP request to the Internet. The traffic is processed as follows:

1. The new user session reaches LinkProof and activates load balancing mechanism.

2. 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 outbound link for this traffic from the router farm chosen in previous step. The choice is based on the following:

— Link availability measured according to user-defined criteria (health checks)

— Link metrics measured according to user-defined criteria (traffic amount, proximity, cost)

4. Once the load balancing decision is reached, it is recorded in LinkProof tables (see Client Table, page 200) for use on the rest of the session traffic.

5. 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)

6. 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).

7. 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.

8. LinkProof ensures that subsequent packets from the user belonging to the same session will use the same WAN link to ensure persistency (as recorded in the Client Table, page 200).

NAT:100.1.1.21

Local

10.1.1.x

LinkProof

NHR 2200.1.1.20

NHR 1

100.1.1.20

Via NHR1

100.1.1.10

200.1.1.10

NAT: 200.1.1.21

Via NHR2

LinkProof User GuideBasic Application Switching


Inbound TrafficInbound traffic is traffic initiated from an external user to a service provided by the local network, such as a Web server.

LinkProof load balances inbound traffic based on availability and performance of the available links and provides the external user access via the best performing link. This is implemented by configuring the LinkProof as an authoritative name server. When the external client makes a DNS request, the LinkProof responds with the IP address allocated to the internal service by the best available WAN link (ISP).

Figure 7: Example Multihoming Inbound Traffic

Figure 7 - Example Multihoming Inbound Traffic, page 137 shows a scenario where an external user sends a request to www.radware.com that is hosted by internal server 10.1.1.50 represented externally by 100.1.1.21 via ISP1 and 200.1.1.21 via ISP2. The traffic is processed as follows:

1. The external user sends DNS query that is forwarded by DNS servers to LinkProof.

2. If this is a domain name for which LinkProof is authoritative server, LinkProof classifies traffic according to configured routing policies (flow policies) to select the group of WAN links (router farm) that will be used for this traffic.

3. LinkProof selects an inbound link for this traffic from the router farm chosen in the previous step, based on:

— Link availability measured according to user-defined criteria (health checks)

— Link metrics measured according to user-defined criteria (traffic amount, proximity, cost)

4. Once load balancing decision is reached, it is recorded in LinkProof tables for use on the rest of the session traffic.

5. A DNS response is sent back to the external user with the IP that represents the internal server via the selected link (ISP)—for example, 100.1.1.21.

6. The external user sends HTTP request to 100.1.1.21. LinkProof replaces the destination IP address with the internal server address (10.1.1.50 in our case).

7. The reply from the internal server will be forwarded via the same link the request arrived, to ensure persistency, after the source IP (10.1.1.50) is replaced by the NAT IP (100.1.1.21).

NAT:100.1.1.21

NHR 2

200.1.1.20

NHR 1

100.1.1.20

Via NHR1

100.1.1.10

200.1.1.10

NAT: 200.1.1.21

Via NHR2

For 10.1.1.50

www.radware.com

10.1.1.50

For 10.1.1.50



Multihoming Configuration SummaryThe following configuration guidelines details the steps required to configure a basic multihoming solution in LinkProof.

To configure multihoming

1. Configure networking definitions (IP interfaces, VLANs, routing).

2. Configure WAN link load balancing:

— Add a router farm. For the procedure, see Configuring a Farm, page 139.

— Add logical router servers. For the procedures, see Server Management, page 155.

— Define health checks. For more information, see Health Monitoring, page 355.

— Define flows and flow policies—if routing policies are required. For the procedure, see To Configuring Flow Policies, page 197.

3. Configure outbound NAT called Dynamic NAT in LinkProof to define for each router (WAN link) the NAT addresses to be used when forwarding. For more information, see Dynamic NAT, page 168.

4. Do the following to configure inbound traffic load balancing (if required):

a. Configure Static NAT to define for each internal server that must be available for access from the external network the IP address that will represent it via each router (WAN link), Static NAT, page 169.

b. Map the URLs for which LinkProof is authoritative server to the internal server IP addresses, Mapping URLs to Local IP Addresses, page 182.

Farm ManagementThis 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 FarmsLinkProof works with server farms rather than with individual servers. Using multiple servers organized in a farm eliminates downtime, accelerates the service response time, and improves overall performance. A farm is a group of network servers that provide the same service.

In the context of LinkProof, a service can be an application that uses a specified TCP or a UDP port, or a complex service that combines several basic services. Servers in a farm can belong to different vendors and have different capacities. The differences between the servers within a farm are transparent to users. If all the servers within a group provide the same service managed by the device, you can configure the group as a LinkProof server farm.

A LinkProof farm can contain either logical routers (access routers to the WAN) or logical firewalls/VPN gateways, but not combination of the two.



Farm PolicyLinkProof 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 1–Layer 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 1–Layer 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.


Table 68: Farm Parameters

Parameter DescriptionFarm Name 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 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.



Dispatch Method The method that the device uses for farm load balancing. For more information, see Dispatch Methods, page 144.

Values:

• Cyclic

• Least Amount of Traffic

• Fewest Number of Users

• NT-1

• NT-2

• Private-1

• Private-2

• Least Number of Bytes

• Hashing

• Least Amount of Local Traffic

• Fewest Number of Local Users

• Least Number of Local Bytes

• Response Time

• Customized Hash

• Multicast

• Source IP Hashing

• Layer-3 Hashing

Default: Cyclic

Client Aging Time How often, in seconds, the device ages (deletes) entries in the Client Table.

Value: 5–3600

Default: 60

Note: If you set the value to any value larger than the minimum, the device sends traffic for the farm to the platform’s accelerators. If you set the value to the minimum, the device does not send traffic for the farm to the platform’s accelerators, and you may expect reduced performance with large traffic volumes.

Connectivity Check Status

The status of the connectivity check.

Values:

• Disable—Disables Connectivity Checks

• Health Monitoring

• Ping Only

Default: Ping Only

Connectivity Check Interval

The interval, in seconds, that the LinkProof device polls the servers.

Default: 10

Connectivity Check Retries

The number of polling attempts that the LinkProof device makes before a server is considered inactive.

Default: 5





Default Farm Action Specifies the action of the LinkProof device if the farm is unavailable (all the servers in the farm are Not in Service).

Values:

• Drop—The device drops the packet.

• Skip—The 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:

• Disable—LinkProof does none of the actions listed in the drop-down list.

• VIP—Translation to a virtual address is required when working with proxy security servers.

• Transform HTTP Requests—LinkProof 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 Requests—LinkProof translates packets into proxy requests packet and sets the destination address to the POP3 server address. Use this option when antivirus scanners are working in proxy mode, but clients are not configured to send traffic via the proxy.

• Virtual Tunneling—LinkProof uses Radware’s Virtual Tunneling mechanism (see Virtual Tunneling, page 237).

Default: Disable

NAT Mode Species whether LinkProof does network address translation on the packets.


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:

• 0—Specifies that the destination port on the packet sent to the server will remain unchanged.

• 1–65,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: #





Configuring Extended Parameters for a Farm of Logical Routers and/or Logical Firewalls

To configure extended parameters for a farm of logical routers and/or logical firewalls

1. Select LinkProof > Farms > Farm Extended Parameters. The Farm Extended Parameters pane is displayed.

2. From the Farm Name column, click the relevant farm. The Farm Extended Parameters Update pane is displayed.


Table 69: Extended Parameters for a Farm of Logical Routers and/or Logical Firewalls

Parameter DescriptionFarm Name The name of the farm (read-only).

Clear Client Table Condition

The condition for clearing the Client Table.

Values:

• None—Previous functionality is ignored.

• Any Server Up—When 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 Up—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 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

• Discard—Discard packets

• Use Local

http://www.radware.com/content/download.asp?document=8260

http://www.radware.com/content/download.asp?document=8260



Persistency Mode 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 Header—For 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: 0–1440

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.

Table 69: Extended Parameters for a Farm of Logical Routers and/or Logical Firewalls




Farm Load BalancingLoad 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 MethodsLinkProof receives requests for services from clients and decides to which server to direct (that is, dispatch) each request. During this process, LinkProof finds the best server to provide the requested service. The Dispatch Method parameter defines the criteria by which LinkProof selects the best server in the farm. LinkProof uses the specified Dispatch Method only for new sessions; LinkProof handles existing sessions using the Client Table.

You can define the Dispatch Method parameter during the farm configuration, according to farm characteristics and your needs. Criteria may vary for different applications. For example, the number of users is a significant factor for a Web farm, whereas the amount of traffic can be more important for an FTP farm.

The list of available Dispatch Methods depends on the specified farm type.

LinkProof supports the following Dispatch Methods:

• Cyclic, page 144

• Fewest Number of Users, page 144

• Fewest Number of Local Users, page 144

• Hashing, page 145

• Least Local Traffic, page 145

• Least Number of Bytes, page 145

• Least Number of Local Bytes, page 145

• Least Traffic, page 145

• NT-1 and NT-2, page 146

• Private-1 and Private-2, page 147

• Response Time, page 148

• Customized Hash, page 148

• Multicast Dispatch, page 219

• Source IP Hashing, page 149

• Layer 3 Hashing, page 149

CyclicWhen the Cyclic Dispatch Method is specified, LinkProof forwards the traffic dynamically to each sever in a round-robin fashion.

Fewest Number of UsersWhen 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 UsersYou 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.



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 client’s 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.

HashingWhen 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 client’s 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 client’s request to this server.

Least Number of BytesWhen 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 device’s 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 client’s 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 client’s request to this server.

Least TrafficWhen 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 device’s Client Table for all traffic forwarded to that server.



NT-1 and NT-2When the NT-1 or the NT-2 Dispatch Method is specified, LinkProof queries the farm servers for Windows NT SNMP statistics. LinkProof forwards the farm’s 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. Select LinkProof > Load-Balancing Algorithms > Windows NT Parameters. The Windows NT Parameters pane is displayed.

2. Click on a parameter row. The Windows NT Parameters Update pane is displayed.


Table 70: Windows NT Parameters

Parameter DescriptionSerial Number The scheme to be used, either NT-1 or NT-2.

Check Period 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: 1–10

Default: 3

Incoming Traffic Weight The relational weight for considering the amount of traffic coming to the server.

Values: 1–10

Default: 3

Outgoing Traffic Weight The relational weight for considering the amount of traffic going out of the server.

Values: 1–10

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: 1–10

Default: 3



Private-1 and Private-2When the Private-1 or the Private-2 Dispatch Method is specified, LinkProof queries the farm’s 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.


User Limit Weight The relational weight for considering the limit on the number of logged in users on the server.

Values: 1–10

Default: 3

TCP Limit Weight The relational weight for considering the limit of TCP connections to the server.

Values: 1–10

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

Table 71: Load-Balancing Algorithms Private Parameters

Parameter DescriptionSerial number The serial number of the scheme. Scheme number 1 is used for

Dispatch Method Private-1, and so on.

Check Period (Secs) The time interval between queries for the requested parameters.

Retries How many unanswered requests for a variable cause this variable to be ignored in the load balancing decision.

Community The community name for addressing the server.

Var1 Object ID The SNMP ID of the first private variable to check.

Table 70: Windows NT Parameters




Response TimeThe Response Time Dispatch Method enables LinkProof to select the fastest server in the farm. When this method is specified, the load-balancing process is based on choosing the least loaded server as calculated by the Response Level as measured by the Health Monitoring module. The Health Monitoring module enables you to track the round trip time of health checks. The device keeps a Response Level indicator for each check. The Response Level is the average ratio between the actual response time and the configured timeout. This average is calculated over a number of samples as defined in the Response Level Samples parameter. A value of 0 in the Response Level Samples parameter disables the parameter. Any other value, from 1 through 9 defines the samples number. The Response Level Samples parameter can be used in the health checks in which the Measure Response Time parameter is enabled.

Configuration of the Response Time Dispatch Method involves the following steps:

• Setting health checks for servers in the farm. When you configure the health-check parameters, enable the Measure Response Time option for each health check.

• Enabling the Health Monitoring module for this farm (see Health Monitoring, page 367).

• Setting the Dispatch Method parameter in the farm to Response Time.

• Setting the Response Level Samples parameter.

Customized HashThe 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.

Var1 Mode Specifies whether to measure the percentage available or the percentage utilized of the first parameter.

Values:

• Ascending—The value of the variable specified in Var1 Object ID represents the percentage still available.·

• Descending—The value of the variable specified in Var1 Object ID represents the percentage currently utilized.

Var1 Weight The relational weight for considering the value of the first parameter.

Var2 Object ID The SNMP ID of the second private variable to check.

Var2 Mode Specifies whether to measure the percentage available or the percentage utilized of the second parameter.

Values:

• Ascending—The value of the variable specified in Var2 Object ID represents the percentage still available.

• Descending—The 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.

Table 71: Load-Balancing Algorithms Private Parameters




To configure the mask for this method using CLI


lp global customized-hash-mask

The default mask is 0.0.0.255.

To configure the mask for this method using Web Based Management

1. Select LinkProof > Global Configuration > Tweaks > Customized Hash Mask.

2. Type the required value.

3. Click Set.

Multicast When the Multicast Dispatch Method is used, after the return packet reaches the lower LinkProof device, a Multicast is sent with the return packet to both VPN gateways. The gateway that responds first, is the one with an established VPN session. LinkProof forwards the traffic to the VPN gateway and the session is not interrupted. For more information, see VPN Load Balancing, page 218.

Note: The OnDemand Switch VL platform does not support the Multicast Dispatch Method.

Source IP HashingWhen 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 HashingWhen the Layer 3 Hashing Dispatch Method is specified, LinkProof performs the hash function on the source and destination IP. This ensures that when a connection passes through the device, as long as it uses the same source and destination IP address, the connection will remain persistent (that is, it will pass through the same NHR). This method is symmetric, meaning that when replacing the source with the destination IP address and vice versa, the selected NHR will be identical.

Session PersistencySession 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 Mode—for example, source IP or destination IP if the Client Table Mode is Layer 3—or 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 TimeThe 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 HandlingThe 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).

Basic NAT FallbackIf 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.

Table 72: Packet Handling Options

Option DescriptionDisable No address translation required.

VIP 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 Virtual Tunneling requires NAT Mode to be enabled and is configured on packets going to a router farm and received from a farm.

Transform HTTP Requests 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.

Transform POP3 Requests 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.



NHR Tracking TableLinkProof 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.


5. Configure the following parameters:

6. Click Set.

Load Balancing Proxy Firewall Farms A firewall is a filtering application capable of stopping unwanted traffic to and from your network.

The purpose of the firewall is to inspect and control all the traffic between the local network and the Internet. The traffic must be handled in such a way that all potentially dangerous traffic be detected and dropped and if necessary logged. What traffic is dangerous for the local network is determined by the security policy adopted for the site.

A single firewall is a single point of failure and can become capacity bottleneck, causing an interruption in service when the firewall is busy or down.

Organizations encounter numerous problems when installing multiple firewalls. First, different client groups must be configured, which is a time-consuming procedure. Furthermore, multiple points of failure are created with the addition of each firewall. Since the traffic load is not dynamically shared between units, the firewalls are not used optimally. Finally, to achieve fault tolerance and redundancy between firewalls, hot standby, or idle units must be deployed on the network.

Since the firewall’s 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).

Parameter DescriptionNHR Tracking Table Status Specifies whether the LinkProof device uses the NHR Tracking

Table.

NHR Tracking Table Aging The time, in minutes, LinkProof keeps an entry in the NHR Tracking Table when no traffic matches it.



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 firewall’s IP address. On the traffic returning from the proxy firewall to the client, LinkProof replaces the packet’s source IP address (that is the firewall server address) with the VIP address (see the following figure).

Figure 8: Example Proxy Firewall Configuration

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

Client

Client IP (CIP) Virtual IP (VIP)

Server 1 IP (SIP 1)

LinkProof

CIP<-VIP

CIP->SIP1

CIP<-SIP1

CIP->VIP

Server 2 IP (SIP 2)



Figure 9: Example Transparent NAT Firewall

Translating Outbound Traffic to Virtual AddressesLinkProof 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


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 FarmA default farm is automatically created for each server IP address configured on the LinkProof device.

The default farm has the following purposes:

• To allow the device to select an edge (end of flow) farm according to the routing table. When the traffic does not match any configured flow, the device searches the routing table for the default gateway. If the default gateway is a server configured on the device, LinkProof forwards traffic to the default farm that was configured for this server. Otherwise, the traffic is forwarded to the default gateway without any farm being selected.

• When traffic arrives from a logical server that belongs to a farm that is not configured in any flow.

The first time an IP address is configured as belonging to a farm, the device automatically configures this farm as the default farm for the server IP. The farm that is automatically configured as the default farm for a server IP can be changed.

CIP->LIPCIP<-NIP1

CIP->NIP1

Client IP (CIP) Virtual IP (VIP)

Client

Server 1 IP (SIP 1)

Server 2 IP (SIP 2)

Internal Server

CIP->VIP

CIP<-VIP

NAT IP for Internal Server (NIP 2)

NAT IP for Internal Server (NIP 2)

CIP<-LIP



To modify parameters of a default farm

1. Select LinkProof > Farms > Default Farm Table. The Default Farm Table pane is displayed.

2. From the Ip Address column, click the relevant farm. The Default Farm Table Update pane is displayed.


Farm Connectivity ChecksTo 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 server’s 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:

• Basic—Uses pings

• Advanced—Uses the Health Monitoring module

Table 73: Default Farm Parameters

Parameter DescriptionIp Address The IP address of the farm (read-only).

Farm Name 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.



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.

Identify Server by NameThis 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 ManagementThis 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 OverviewIn the context of LinkProof, servers are logical entities that are associated with application services provided by physical servers that run these applications. After configuring the required farms (seeFarm Management, page 138), the process of adding and configuring servers in the LinkProof farm consists of two main stages:

• Adding physical servers

• Setting up farm servers

Table 74: Connectivity Check Methods

Parameter DescriptionConnectivity Interval How often, in seconds, LinkProof polls the servers.

Default: 10

Connectivity Retries The number of polling attempts that LinkProof makes before a server is considered inactive.

Default: 5



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 server’s behavior within a specified farm. The name of the farm server identifies the actual physical server that provides the service. The Server Name parameter is configured when the physical server is added to the Logical Routers table or Logical FW (firewall) table. The IP address of the farm server must also be defined. A physical server can have a few IP addresses, so different farm servers that operate on the same physical server can have different IP addresses. The same server name and server address can be used in different farms (but same type of farms).

Notes:>> LinkProof periodically sends ARP to all logical servers that have an IP address. You can

disable this mechanism using the ARP to Logical Servers parameter, and set the interval between ARPs (in seconds) using the Time between ARPs parameter.

>> LinkProof can select the MAC address and incoming ports of the Next Hop Router to determine the origin of the Next Hop Router traffic. When disabled, only the source MAC is selected. Typically, you enable this option only when using port rules and when Next Hop Routers use the same MAC on different physical ports.

Configuring a Logical Router

To create a logical router

1. Select LinkProof > Servers > Logical Routers Table. The Logical Routers Table pane is displayed.

2. Click Create. The Logical Routers Table Create pane is displayed.




Table 75: Logical Routers Parameters

Parameter DescriptionFarm Name The name of the farm defined in the Router Farm Table pane.

Router Name The user-defined name of the router.

IP Address The IP address of the router.

Weight 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: 1–100

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:

• Regular—The server’s health is checked, as long as it is available the server is eligible for receiving client requests.

• Backup—The server’s health is checked, but the server does not receive any client requests. The server becomes eligible for client requests when all the servers in the Regular mode have failed.

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 farm’s Sessions Mode. When the limit is reached, new requests for service are no longer directed to this server. All open sessions are continued.

Values:

• 0—The mechanism is disabled for this server, and there is no bandwidth limit.

• 1–999,999,999

Default: 0



AdminStatus The user-defined management status of the server, which you can change at any stage of server’s configuration or operation.

Values:

• Enable—The server is active and ready to reply to new requests for service.

• Disable—The server is not active. When setting the Admin Status to Disabled, the device removes all the entries relevant to this server from the Client Table, stops sending new requests for service to this server and disconnects all the connected clients.

• Shutdown—The server cannot get new requests for service. The existing sessions are completed according to the Aging Time.

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:

• 0—Specifies that the mechanism is disabled for this server, and there is no bandwidth limit.

• 1–33,554,431

Default: 0

Inbound Kbps Limit The maximum amount of bandwidth in Kbps allowed for inbound traffic from this logical server.


Values:


• 1–33,554,431

Default: 0

Outbound Kbps Limit The maximum amount of bandwidth in Kbps allowed for inbound traffic from this logical server.


Values:


• 1–33,554,431

Default: 0

Table 75: Logical Routers Parameters




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.


Table 76: Logical Firewall Parameters

Parameter DescriptionFarm Name The name of the farm defined in the FW Farm Table pane.

Firewall Name The user-defined name of the firewall.

IP Address The IP address of the firewall.

Weight 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: 1–100

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:

• Regular—the Server’s health is checked, as long as it is available the server is eligible for receiving client requests.

• Backup—The server’s health is checked, but the server does not receive any client requests. The server becomes eligible for client requests when all the servers in the Regular mode have failed.

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.



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.

Connection Limit The maximum number of Client Table entries that can run simultaneously on the Logical Server. This depends on farm’s Sessions Mode. When the limit is reached, new requests for service are no longer directed to this server. All open sessions are continued.

Default: 0—Specifies that the mechanism is disabled for this server, and there is no user number limit.

AdminStatus The user-defined management status of the server, which you can change at any stage of server’s configuration or operation.

Values:

• Enable—The server is active and ready to reply to new requests for service.

• Disable—The server is not active. When setting the Admin Status to Disabled, the device removes all the entries relevant to this server from the Client Table, stops sending new requests for service to this server and disconnects all the connected clients.


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.


Default: 0—Specifies 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.



Outbound Kbps Limit The maximum amount of bandwidth in Kbps allowed for inbound traffic from this logical server.



Table 76: Logical Firewall Parameters





4. Click Set.

Physical ServersPhysical 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.


4. Click Set.

Table 77: Physical Server Parameters

Parameter DescriptionServer Name 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.

Connected Users The number of users currently connected to the server.


Peak Load The maximum CPU load, in percent, at peak time.


Frames Load Total number of frames at peak time.


Connection Limit The maximum number of Client Table entries that can run simultaneously on the physical server. This depends on farm’s Sessions Mode. When the limit is reached, new requests for service are no longer directed to this server. All open sessions are continued.

When the Connection Limit parameter is configured to 0 (default), this mechanism is disabled for this physical server and there is no user number limit.

When configuring the Connection Limit for the physical server, ensure that the Connection Limit in the farm servers with the same Server name is lower or equal to the Connection Limit in the physical server. The total number of active sessions that run simultaneously on the farm servers must not be higher than the Connection Limit value defined on the physical server.



Peak Kbps Load The maximum Kbit/s reported at peak time.


Recovery Time The time, in seconds, during which no data is sent to the physical server since the server recovers from a failure. When a server’s operational status is changed from inactive to active (dynamically or administratively), the server is not eligible to receive clients for this period of time.

Recovery Time applies to all servers in all farms that share the same Server Name. Once this time is reached, the server becomes eligible for receiving clients requests.

Values: 0–10,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 server’s weight is the specified Weight.

Default: 0—Specifies 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 Reported rate on the server.


Kbits Load Traffic, inbound and outbound, in Kbits to the server, in the last second.


Kbps Limit 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:

• Enabled—The server is active and ready to reply to new requests for service.


Default: Enabled

In Kbps Rate In Kbit/s.






In Kbits Load In load.


In Kbps Limit 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.


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 Kbit/s.


Out Kbps Load Out load.


Bandwidth Limit Exception

Determines the device behavior when outbound or total bandwidth limits are reached for routers.

Values:

• Disable—New sessions will not be allocated to this server, but existing sessions traffic will not be dropped.

• Enable—Traffic will be dropped when bandwidth limit is exceeded.

Discarded Packets Number

The number of discarded packets.


Billing mode LinkProof supports multiple billing models for the Cost feature. You can define the billing model for each router.

Values:

• Inbound—Inbound bandwidth

• Outbound—Outbound bandwidth

• Total—Inbound 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:

• 0–15—For ToS.

• 0–7—For precedence type.

• 255—No ToS is required for the router.

Default: 255





Cluster ServersIn 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 server’s 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 server’s address, thus potentially causing the traffic to be incorrectly redirected.

This following diagram illustrates the problem. Two NHRs are defined on the LinkProof device: NHRA, which is a cluster, and NHRB. LinkProof recognizes MAC A as the MAC address of NHRA (it was discovered via ARP messages to IP A), but when traffic comes from NHRA, its source MAC is either MAC11, MAC 22, or MAC 33, depending on which physical router processed this traffic.

Figure 10: Potential Issues When Not Using Cluster Support

Resolution of Cluster Traffic Issues with Cluster SupportThe Cluster Support feature enables you to configure traffic going through clusters. You do this by associating the MAC address of an NHR cluster server to recognize traffic from a physical server within one of its clusters. You do this by creating an entry in the Cluster Servers Table that includes the NHR cluster IP address, and either an additional IP or MAC address associated with the cluster server.

In the example shown in Figure 10 - Potential Issues When Not Using Cluster Support, page 164, using the Cluster Support feature you can configure MAC 11, MAC 22, and MAC 33 to be associated with server NHRA, enabling the device to recognize traffic with these MAC addresses as traffic from server NHRA. When LinkProof forwards traffic to the cluster server, it uses the destination MAC address that was discovered via an ARP to the logical server IP address (MAC A in the example). However, traffic coming from the cluster will be allocated to the cluster server if the source MAC or its IP is statically configured as belonging to this server.

Router 1–MAC 11Router 2–MAC 22Router 3–MAC 33

LinkProof

NHRB–IP B; MAC B

NHRA–IP A; MAC A



To configure a cluster server using an IP address, the MAC address must be set to 000000000000. To configure a cluster server using a MAC address, the IP address must be set to 0.0.0.0.

Notes:>> In many cases, you may not be required to load balance traffic to the cluster, but rather

to perform NAT on the traffic to and from the cluster. In this case, the cluster needs to be configured as a LinkProof server (NHR or firewall).

>> The LinkProof server IP should be the Virtual IP of the cluster or, in the case of WOC devices, the IP of the router beyond the WOC device.

>> For Hot Standby Router Protocol (HSRP) clusters, where the virtual IP address cannot be the IP address of any of the cluster servers, you can configure the IP addresses of the cluster servers so that their MAC address will be discovered using ARP. This allows you to replace a server in a cluster without changing the LinkProof configuration (if the new server has the same IP address as the old one).

>> For VRRP clusters where the virtual IP address is usually the IP address of one of the cluster servers, you can statically configure the MAC addresses of the cluster servers.

>> For WOC devices, you need to statically configure the MAC address of the WOC device.

Adding an Entry to the Clusters Servers TableUse the Clusters Servers Table pane to configure cluster servers.

The pane displays a table with the following columns:

• Server Address

• Cluster Server Address

• MAC Address

• MAC Status

To add a new cluster servers table entry using CLI

Enter the command lp servers cluster-servers.

To add a new cluster servers table entry using Web Based Management

1. Select LinkProof > Servers > Cluster Servers Table. The Clusters Servers Table pane is displayed.

2. Click Create. The Clusters Servers Table Create pane is displayed.




Full Path Health MonitorThe Health Monitoring module enables extensive health monitoring of all network devices that are load balanced or managed by LinkProof. The module enables the device to load balance the network by making sure which network elements are available and active.

Use the Full Health Monitor Table pane to do the following:

• View the status of farms and associated severs.

• Configure a health check for a server in the servers table. This configuration is identical to the configuration process in the Health Monitoring menu, only simplified to enable the Health Monitoring configuration directly using the Server Table pane.

The Full Health Monitor Table pane displays a table with the following columns:

• Farm Name

• Server Name

• Check Address

• Oprt Status

To configure the parameters of the Full Path Health Monitor

1. 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: Clusters Server Parameters

Parameter DescriptionServer Address The IP address of the physical server.

The physical server must be configured already on the device.

MAC Address 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.

Table 79: Full Health Monitor Parameter

Parameter DescriptionFarm Name The relevant farm.

Server Name The relevant server.

Check Address The IP address of the remote device to check.



Server StatisticsUse the Servers Statistics pane to view the following statistics of each server configured on the device:

• s_name—The server name

• f_name—The farm name

• connections—The current number of connections on the server

• bytes—The number of bytes the server handled at the given moment

• acum_bytes—The 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 TranslationNAT enables translation of an IP address used within one network to a different IP address known within another network.


• Network Address Translation (SmartNAT), page 167

• Dynamic NAT, page 168

• Static NAT, page 169

• No NAT, page 170

• Basic NAT, page 170

• One-IP-for-NAT Support, page 171

• Static Port Address Translation (Static PAT or SPAT), page 172

• NAT Parameters Summary and Miscellaneous Parameters, page 175

Network Address Translation (SmartNAT) The main issue in a multihomed network is managing the IP addressing scheme for the different providers.

There are two common possibilities that can be deployed with regard to the IP scheme that the internal network uses:

• A single IP network number is assigned to the internal network—Requires 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 range—Therefore, 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.

To configure NAT, you first configure the NAT tuning parameters; and then you configure the NAT addresses.

Notes:>> LinkProof performs NAT when forwarding traffic to farms for which NAT has been

enabled (security and firewall farms only). NAT will be performed only for IP addresses that are found in the Smart NAT tables.

>> LinkProof can perform a single NAT per session.

>> For NAT tuning parameters, see Device Tuning, page 71.

Dynamic NATThe Dynamic NAT feature enables LinkProof to hide various network elements located behind LinkProof. Using this feature, LinkProof replaces the original source IP and source port of a packet that is with the configured NAT IP and a dynamically allocated port before forwarding the request to the farm.

The network elements whose addresses are translated can be servers or other local hosts. You can set different NAT addresses for different ranges of intercepted addresses.

For example, traffic from subnet A is translated using IP address 10.1.1.1 and traffic from subnet B is translated using IP address 10.1.1.3.

To configure dynamic NAT

1. Select LinkProof > Smart NAT > Dynamic NAT. The Dynamic NAT Table pane is displayed.

2. Click Create. The Dynamic NAT Table Create pane is displayed.




Static NATUse Static NAT is ensure delivery of specific traffic to a particular server on the internal network. For example, LinkProof uses Static NAT, meaning predefined addresses mapped to a single internal host, to load balance traffic to the host among multiple transparent traffic connections. This ensures that the return traffic uses the same path, and also allows traffic to that single host to use multiple ISPs transparently. You assign multiple Static Smart NAT addresses to the internal server, typically one for each ISP address range.

Note: Static NAT addresses cannot be part of the Dynamic NAT IP pool.

To configure Static NAT

1. Select LinkProof > Smart NAT > Static NAT. The Static NAT Table pane is displayed.

2. Click Create. The Static NAT Table Create pane is displayed.


Table 80: Dynamic NAT Parameters

Parameter DescriptionFrom Local IP The lowest value in the range of IP addresses of the local server.

To Local IP The highest value in the range of IP addresses of the local server.

Server IP The IP address of the farm server. These NAT addresses are used when traffic from local addresses is sent to this farm server.

Dynamic NAT IP 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.

Table 81: Static NAT Parameters

Parameter DescriptionFrom Local IP The lowest value in the range of local IP addresses.

To Local IP The highest value in the range of local IP addresses.

Server IP The IP address of the farm server. The NAT address will be used when traffic from local addresses is sent to this farm server.

From Static NAT IP The lowest value in the range of NAT addresses to be used when forwarding to the server address above.

To Static NAT IP The highest value in the range of NAT addresses to be used when forwarding to the server address above.

Redundancy Mode 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.



Excluding or Enabling Static NAT for the Local NetworkTraffic 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 > 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 NATsA flag allows enabling or disabling simultaneous ping functionality to multiple Static NAT addresses belonging to the same Internet host.

No NATNo NAT enables a simple configuration where internal hosts have IP addresses that belong to a range of one of the farm servers.

Traffic to and from these hosts should not be translated if the traffic is forwarded to this farm server.

If you do not configure any NAT address for a host via a farm server, that farm server will not be used by inbound traffic to that host if the host IP resolution is provided through DNS. To use a farm server for traffic from the host when NAT is not required, use the No NAT configuration.

To configure No NAT

1. Select LinkProof > Smart NAT > No NAT. The No NAT Table pane is displayed.

2. Click Create. The No NAT Table Create pane is displayed.


Basic NATBasic NAT enables a one-to-one NAT mapping for occasional users, based on local IP ranges and destination applications. A pool of NAT addresses for each server is configured per range of local IP addresses and destination port. Whenever a client with an IP address within the range initiates a session to any host with the relevant application port, a NAT address is allocated to this session, and

Table 82: No NAT Parameters

Parameter DescriptionFrom Local IP The start of the range of local IP addresses.

To Local IP The end of the range of local IP addresses.

Port Number 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.

Server IP The IP address of the farm server. These NAT addresses will be used when traffic from local addresses is sent to this farm server.



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 client’s IP address is translated using Dynamic NAT.

Typically, the configured local IP range includes more hosts than the IP addresses allocated for Basic NAT for the same IP range. The latter indicates that any traffic from one of the hosts in the local IP range will be NATed (translated) using one of the Basic NAT addresses configured for this local IP range. This enables the use of a pool of Static NAT addresses, for a (larger) range of local IP addresses.

The destination port can be configured to a specific application port, or to All ports.

You can also configure how the LinkProof should behave if all Basic NAT addresses for the specified IP address range and application are occupied.

To configure Basic NAT

1. Select LinkProof > Smart NAT > Basic NAT. The Basic NAT Table pane is displayed.

2. Click Create. The Basic NAT Table Create pane is displayed.


One-IP-for-NAT Support You can use the One-IP-for-NAT feature to reduce the number of public IP addresses used for LinkProof configurations. When One-IP-for-NAT is enabled, you can define Smart Dynamic NAT and IP addresses that are identical to the devices’ IP addresses. LinkProof registers all incoming and outgoing traffic to distinguish between management traffic, Health Monitoring, or Proximity, and forwarded traffic. It is possible to enable One-IP enabled on several IP interfaces and to disable One-IP 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.

Table 83: Basic NAT Parameters

Parameter DescriptionFrom Local IP The range of local IP addresses.

To Local IP The range of local IP addresses.

Port Number The destination port for which traffic is NATed. For example, if you specify 80, all traffic to destination port 80 is NATed. Destination port 0 refers to all the ports.

Server IP The IP address of the farm server. These NAT addresses will be used when traffic from local addresses is sent to this farm server.

From Basic NAT IP The range of NAT addresses.

To Basic NAT IP The range of NAT addresses.

Redundancy Mode The redundancy mode can be either Backup or Regular. The Active mode is for the active device and the Backup mode is for the backup device.



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 ConfigurationLinkProof uses a set of predefined IP addresses. Each router connected to a LinkProof device needs two IP addresses. One, single IP address is used for the router’s internal interface, and another IP address is used for the LinkProof interfaces themselves. For example, if a LinkProof device uses two IP addresses per router in a regular configuration and there are five routers, then 10 available IP addresses are required. In most LinkProof configurations, the IP addresses used for a configuration like this are public IP addresses. When using LinkProof with SmartNAT configurations, you must assign private IP addresses (according to RFC 1918) for the internal LAN segments behind the LinkProof device, using additional public IP addresses.

To configure Smart NAT with One-IP using Web Based Management


2. Click Create. The Interface Parameters Create pane is displayed.

3. From the One Ip (Router Interface Only) field, select Enable or Disable.

4. Click Set.

To configure Smart NAT with One-IP using CLI


net ip-interface set <IP Address> -oi <enable|disable>

You are required to configure Dynamic NAT (DNAT) using the SmartNAT configuration. For information on how to configure DNAT, see Dynamic NAT, page 168.

Static Port Address Translation (Static PAT or SPAT)Static Port Address Translation (Static PAT or SPAT) allows one-to-one mapping between local and global addresses. With Static PAT, multiple internal hosts can share a single IP address for communication, thus saving public IP address usage.

Static PAT is actually a subset of NAT (RFC 2663), but it is usually referred to as Static PAT when discussing Port Forwarding.

With Static PAT, you can configure static mapping of UDP or TCP ports of LinkProof’s IP interface to the internal hosts’ ports.



The following figure shows an example of Static PAT, where a client initiates a connection from the Internet towards the Web Server.

Figure 11: Example Static PAT

The following two tables describe the example Static PAT configuration.

Table 84: Client to Web Server Configuration Example

Destination IP Destination Port Destination IP Destination Port Action on Web ServerIP B (Public) 80 (HTTP) Forward to IP

(Internal) Private8080 Replay to Client IP

Table 85: Web Server to Client Configuration Example

Destination IP Destination Port Destination IP Destination Port Action on Web ServerClient IP (Public) 8080 IP B (Public) 80 (HTTP) Continue Session



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. Select LinkProof > Smart NAT > Static PAT Table. The Static PAT Table pane is displayed.

2. Click Create. The Static PAT Table Create pane is displayed.


Management IP Considerations with SPAT LinkProof supports management access to the device using the following protocols:

• Telnet—TCP Port 23

• SSH—TCP port 22

• Web—TCP Port 80

• SSL—TCP Port 443

• FTP—TCP Port 21

• SNMP—TCP Port 161

Table 86: Static PAT Table Parameters

Parameter DescriptionStatic PAT Name Name used for identifying the PAT rule.

Internal IP The internal IP of the server.

Internal Port The internal port used by the server.

Protocol The protocol type (TCP, UDP or ICMP).

Server IP The IP of the external route.

External IP The IP of the external LinkProof interface.

External Port The external port that the LinkProof device listens to.

Static PAT Mode Backup and Main is used for mirroring purposes and is defined in accordance with Smart NAT redundancy settings.



When the One-IP-for-NAT feature is enabled (see One-IP-for-NAT Support, page 171), the LinkProof IP address for management (its own IP) will be used for SPAT. This might create a conflict with the above services if they are also used for internal servers. If you try to use any ports in conflict with the above ports, then the following error message is issued:

Can not bind port 80: Port is bound to device WEB service (UDP or TCP). Change service port first

Notes:>> SPAT is supported with TCP, UDP, and ICMP.

>> SPAT with One-IP-for-NAT is supported on TCP and UDP only.

>> By design, SPAT is limited to one (1) server behind the SPAT device using a single port for a single service. Only a single public service with port 80 HTTP (for example) can be exposed per public IP address. In this way, an organization using PAT and a single IP cannot run more than one of the same type of public service behind a PAT (for example, two public web servers using the default port 80).

>> VPN (IPsec) Pass-through with SPAT: In order to configure VPN traffic pass-through together with SPAT, you need to define a SPAT entry with UDP port 500 (IKE). The device will allow AH, ESP protocols to undergo SPAT and pass through the device as well.

>> To resolve conflicting IP addresses, SmartNAT methods have been set according to priority and are set as follows:

1—NoNAT

2—SNAT

3—SPAT

4—DNAT

So, for example, if you have configured an IP to be used in 1IP and SPAT and the same IP is displayed in a SNAT range, where inbound traffic is involved, the SNAT range will take precedence over SPAT. Outbound traffic, for this session, will only use SNAT.

NAT Parameters Summary and Miscellaneous ParametersUse the NAT Parameters Summary pane to view all Smart NAT tables, create new entries and update existing entries, and specify whether Static NAT is used for traffic from the local host to the local network.

By default, traffic from a local host for which Static NAT is configured undergoes NAT when forwarded to a farm for which NAT is enabled; but the traffic to the local network is not translated. That is, by default, the value in the Exclude Static NAT for Local Network drop-down list is Enable. In certain cases, mainly for security purposes, you may also require Static NAT for traffic to the local network from the local host.

To use Static NAT for traffic to the local network from the local host


1. From the Exclude Static NAT for Local Network drop-down list, select Disable.

2. Click Set.



To have the device always translate the Static NAT destination to the local IP address


1. From the Always Translate Static Nat Destination To Local IP drop-down list, select Disable.

2. Click Set.

To configure NAT features using the NAT Parameters Summary pane

Select LinkProof > Smart NAT > NAT Parameters Summary. The NAT Parameters Summary pane is displayed.

For information on the tables in the NAT Parameters Summary pane, see the following:

— Dynamic NAT, page 168

— Static NAT, page 169

— No NAT, page 170

— Basic NAT, page 170

— Static Port Address Translation (Static PAT or SPAT), page 172

ProximityThis section describes LinkProof’s ability to detect network proximity and contains the following:

• Proximity Introduction, page 176

• Proximity Configuration, page 177

Proximity IntroductionIn today’s 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 client’s mouse click all the way to the content located on the provider’s 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, Radware’s redirection mechanisms will reduce the traffic on the Internet backbones. Radware’s 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 ACK’s and ICMP Echo requests) to ensure accurate measurements.

The type of checks used for proximity is configurable to allow users more control of the device and generate maximum performance from the links.

Notes:>> LinkProof can perform proximity checks through up to 10 routers.

>> In the dynamic proximity table, only the best three (3) routers are recorded for each checked subnet.

Proximity ConfigurationYou can configure how the LinkProof uses proximity data.

Proximity ModeLinkProof supports the following proximity modes:

• No Proximity—LinkProof ignores proximity data. The dynamic auto learning mechanism is off.

• Static Proximity—LinkProof 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 Inbound—LinkProof 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 Outbound—LinkProof 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 Both—LinkProof 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 ChecksLinkProof 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:

• Basic—A basic ping test typically used to check inbound traffic.

• Advanced—Simulates 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 Side—Simulates a client of an application (sends TCP SYN packets) hence it is outbound traffic oriented.

• Client Side—Simulates 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 Retries—Defines the number of retries that are performed when the checked destination does not respond to the first attempt.

• Check Interval—Defines the time interval between consecutive retries in seconds.

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

Weights (Hops, Latency, Load)You can define the emphasis that the device should put on the hops parameter and on the latency parameter when making a load balancing decision. In addition you can define the weight the router load should take in the load balancing definition together with the proximity parameters. The router load is calculated according to the Dispatch Method used, for example, the number of clients when using the least amount of users.

Note: The load weight is relevant only when the Farm Dispatch Method is set to Least Amount of Traffic, Least Number of Bytes or Least Number of Users.

Main and Backup DNS AddressesTo 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 company’s 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 MaskBy 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 ProximityIf 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.


Table 87: General Proximity Parameters

Parameter DescriptionProximity Mode Defines the proximity mode.

Values:

• No Proximity—No proximity is operated.

• Static Proximity—The 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 Inbound—The 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 Outbound—The 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 Both—The 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 company’s DNS servers are placed at the Internet provider, the main and backup DNS servers should belong to different ISPs. Only two such DNS servers (main and backup) can be configured.

Backup DNS To prevent inefficient learning of requests that arrive from the local DNS server, configure LinkProof to ignore requests from specific addresses in the dynamic proximity mechanism.

Enter the IP address of the local secondary DNS server.

Note: If the company's DNS server are placed at the Internet provider, the main and backup DNS server should belong to different ISPs. Only 2 such DNS servers (main and backup) can be configured.



Setting Proximity Check Parameters

To configure Proximity Checks

1. Select LinkProof > Proximity > Proximity Parameters > Proximity Checks. The Proximity Checks pane is displayed.


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.

Use Router Mode decisions inside proximity

Set this parameter to Disabled (default is Enabled) to allow the load balancing mechanism to consider NHRs that were defined as backup in the grouping tables. This determines whether there is proximity data for a specific destination via this NHR. This functionality is required when some of your WAN links are restricted (for example domestic access only).

Proximity Subnet Mask 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.

Table 88: Proximity Check Parameters

Parameter DescriptionBasic Proximity Status

This is a basic test typically used to check inbound traffic.

Values:

• None—This check is disabled.

• Inbound Proximity—This check will be used to dynamically measure proximity for inbound requests only.

• Outbound Proximity—This check will be used to dynamically measure proximity for outbound requests only.

• Both—This 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:





Table 87: General Proximity Parameters




Setting Static Proximity

To configure Static Proximity

1. Select LinkProof > Proximity > Static Proximity. The Static Proximity Table pane is displayed.

2. Click Create. The Static Proximity Table Create pane is displayed.


Server Side Proximity Status

This test simulates a client of an application, hence it is outbound traffic oriented.

Values:



• Outbound Proximity—this check will be used to dynamically measure proximity for outbound requests only.


Client Side Proximity Status

This test simulates the server side of an application, hence it is inbound traffic oriented.

Values:





Check Retries Defines the number of check retries with the client or the distributed sites during the proximity mechanism, when the client doesn't respond to the first check.

Check Interval Defines the time interval in seconds between consecutive retries.

Table 89: Static Proximity Parameters

Parameter DescriptionFrom Address The IP address of the first destination in the range.

To Address The IP address of the last destination in the range.

NHR 1 The IP address of the best next hop router.

NHR 2 The IP address of the second best next hop router.

NHR 3 The IP address of the third best next hop router.

Table 88: Proximity Check Parameters




DNSThis section describes the concept of DNS resolution for URLs in multihomed networks and how to incorporate this into your network with LinkProof.

This section contains the following:

• DNS Introduction, page 182

• Mapping URLs to Local IP Addresses, page 182

• DNS Response Parameters, page 184

• DNS for Local Users, page 185

• DNS Redundancy, page 187

DNS IntroductionOne 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 organization’s 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 user’s 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 AddressesFor LinkProof to provide load balancing of inbound traffic to internal servers, you must configure the following:

• Host-to-local-IP mapping—The 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 names—wildcard 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 NAT—For the local IP addresses via all available routers.



Configuring Host-to-Local-IP Mapping

To configure host-to-local-IP mapping

1. Select LinkProof > DNS Configuration > Name to Local IP. The Name To Local IP DNS Table pane is displayed.

1. Click Create. The Name To Local IP DNS Table Create pane is displayed.


Configuring Dynamic-Host-to-Local-IP Mapping

To configure dynamic-host-to-local-IP mapping

1. Select LinkProof > DNS Configuration > Dynamic Host Name to Local IP. The Dynamic Host Name to Local IP DNS Table pane is displayed.

2. Click Create. The Dynamic Host Name to Local IP DNS Table Create pane is displayed.


Table 90: Name to Local IP DNS Parameters

Parameter DescriptionHost Name The URL to be mapped.

Local IP Address The IP address of the local host.

Farm Name 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.


Default: Enable

Table 91: Dynamic-Host-to-Local-IP Mapping Parameters

Parameter DescriptionDynamic Host Name The URL with wildcards to be mapped.

Local IP Address The IP address of the local host.

Index The index number of this dynamic host name entry.



DNS Response ParametersDNS Response parameters include the following:

• Response TTL—Specifies 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 Reply—When 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 Mode—Determines 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.


Farm Name 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.


Default: Enabled

Table 91: Dynamic-Host-to-Local-IP Mapping Parameters




DNS for Local UsersThe 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).

Table 92: DNS Response Parameters

Parameter DescriptionDNS Response TTL The number of seconds that DNS responses are cached. The

default setting is 0, which means the response is not cached.

Two Records in DNS Reply Enables the return of two A records in the DNS response. Disable to return one record.


Default: disable

URL to IP Search Mode Defines how LinkProof handles DNS requests.

Values:

• Both—LinkProof 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 IP—LinkProof searches for the requested URL in the Name to IP Table only.

• Dynamic Host Name To Local IP—LinkProof 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 Mode—Static NAT address if SmartNAT is enabled, local IP address otherwise

• Always NAT IP Address—Static NAT address

• Always Local IP Address

Default: According to SmartNat Mode



The solution implemented in LinkProof depends on whether the DNS server is located internally or externally.

Caution: The DNS for Local Users functionality is resource consuming, since the device has to scan all DNS responses. It should not be enabled if not required.

External DNS Server ConfigurationWhen 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 ConfigurationWhen 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.



Configuring a DNS for Local Clients

To configure the location of the DNS for local clients

1. Select LinkProof > DNS Configuration > DNS for Local Clients. The DNS for Local Clients Parameters pane is displayed.

2. From the DNS Server Location drop-down list, choose the required option.

Values:

— Not Relevant—The feature is disabled.

— Internal—The 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.

— External—The LinkProof device is the authoritative DNS for the internal servers and resolves host name to public IP address (Static NAT). The user, whether external or internal, queries the DNS server for host name resolution. DNS server asks LinkProof for address resolution and receives public IP address. It sends response to users. The response to internal users will pass via LinkProof. LinkProof will intercept the DNS response with internal server resolution and replace public IP with local IP address. Thus, internal users will be able to communicate with internal servers directly, via the local network. External clients will receive the public IP from the DNS server and will be able to access the servers.

Default: Not Relevant

3. Click Set.

To configure an entry DNS Servers Table

1. Select LinkProof > DNS Configuration > DNS for Local Clients. The DNS for Local Clients Parameters pane is displayed.

2. Click Create. The DNS Servers Table Create pane is displayed.

3. In the DNS IP Address text box, type the IP address for the DNS server.

4. Click Set.

DNS RedundancyTo allow DNS requests to be handled smoothly and transparently by the redundant device when the main device is down, virtual DNS (VDNS) IP address must be configured for LinkProof redundant configuration.

A virtual DNS address should be configured for each provider (router). The same address is configured on both devices.

Caution: The order of configuring virtual DNS is critical. First, you must configure the VDNS; and then, you associate an IP address with it.



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.


Basic Load BalancingThis section provides some basic load-balancing configuration examples, which can be implemented without using flow definitions.


• Simple Router Load Balancing Configuration, page 189

• Simple Router Load Balancing Configuration With VLAN, page 190

• Simple One-Leg (Lollipop) Configuration, page 191

• Sandwich Configuration, page 192

• Single Device Installation, page 193

Table 93: DNS Virtual IP Parameters

Parameter DescriptionDNS IP Address The DNS address of the device.

Mode Specifies whether the DNS address represents a main (regular) or backup device.



Simple Router Load Balancing ConfigurationThe following diagram shows a configuration of simple router load balancing.

Figure 12: Simple Router Load Balancing Configuration

100.1.1.10

LinkProof

Interface 1

Interface 2

200.1.1.10

10.1.1.10

Router 1 Router 2NAT:100.1.1.21 NAT:200.1.1.21

for 10.1.1.30

via Router 1

for 10.1.1.30

via Router 2

Internal Server10.1.1.30

Local Network

10.1.1.x



Simple Router Load Balancing Configuration With VLANThe following diagram shows a configuration of simple router load balancing in a VLAN environment.

Figure 13: Simple Router Configuration with VLAN

LinkProof

Interface 2

Router 1 Router 2

NAT: 200.1.1.21

for 10.1.1.30

via Router 1

for 10.1.1.30

via Router 2

Internal Server

10.1.1.30

Local Network

10.1.1.x

Interface 3

200.1.1.10

Interface 1 100.1.1.10

NAT: 100.1.1.21



Simple One-Leg (Lollipop) ConfigurationThe following diagram illustrates a simple configuration that does not require changing the network configuration.

Figure 14: Simple One-Leg (Lollipop) Firewall Configuration

LinkProof

Router 1

Local Network

100.1.1.xInternal Server

100.1.1.30

Router 2

Interface 1

100.1.1.10

Interface 2

200.1.1.10

100.1.1.20

NAT: 200.1.1.21for 100.1.1.30via Router 2

200.1.1.20



Sandwich ConfigurationFirewall Sandwich is a generic description for a common network topology. The example in this section describes how you can easily configure LinkProof to support it.

This configuration is typical when router load balancing as well as firewall load balancing (for both inbound and outbound traffic) is required.

When Static NAT is used on the firewalls, a virtual IP address is created on the external LinkProof to ensure that different NAT addresses, on different firewalls, for a single internal host, are seen as a single public address. This provides load balancing and high availability between the NAT addresses.

The following diagram illustrates a LinkProof sandwich configuration.

Figure 15: Sandwich Configuration

30.1.1.1

Firewall 1 Firewall 2

Local Network10.1.1.30

20.1.1.1 20.1.1.2

10.1.1.x

LinkProof

for 10.1.1.30

NAT: 30.1.1.31NAT: 30.1.1.30

20.1.1.10

10.1.1.10

LinkProof

100.1.1.1

200.1.1.10

30.1.1.10

30.1.1.2

Interface 2

NAT: 100.1.1.21

For 30.1.1.11 VIP For Router 1

NAT: 200.1.1.21 For 30.1.1.11 VIP For Router 2

100.1.1 200.1.1

For 10.1.1.30



Single Device InstallationThis scenario shows a single LinkProof device using the Port Rules functionality.

The same functionality as in the previous example can be achieved with a single LinkProof device using the Port Rules functionality.

In this configuration, two separate farms must be configured, one on the internal interfaces of the firewalls for outbound load balancing and one on the external interfaces of the firewalls for inbound load balancing.

Figure 16: Example Single Device Installation

Local Network10.1.1.x

Firewall 1

Internal External

Firewall 2

LinkProof

Interface 1

20.1.1.2 30.1.1.2

20.1.1.1 30.1.1.1

Interface 3Interface 2

Router 2

Router 1

100.1.1.20200.1.1.20

Interface 4

10.1.1.10

20.1.1.10 30.1.1.10

100.1.1.10200.1.1.20



Load Balancing WeightsYou 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.


Flow ManagementThis section describes the flow management process for LinkProof and describes the flow concept and flow policies and also some LinkProof configuration examples.


• About Flows and Flow Management, page 194

• Default Flow, page 195

• Configuring Flow Management, page 195

• Flow Policies, page 196

• Typical Flow Configurations, page 199

About Flows and Flow ManagementTraffic 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.

Table 94: Load Balancing Weight Parameters

Parameter DescriptionHops Weight The weight applied to the number of hops on the network link.

Latency Weight The weight applied to latency on the network link.

Load Weight The weight applied to load on the network link.

Cost Weight The weight applied to cost parameters on the network link.



Figure 17: General Flow Management Scheme on LinkProof

Default FlowThe LinkProof device automatically creates a default flow that is used for traffic that does not match any flow policy. The default flow does not include any farm. When traffic that must be forwarded according to the default flow is detected, the device looks in the routing table for the default gateway. If the default gateway is a farm server, the default farm of this server is selected as the farm used by the default flow. Traffic is then forwarded to one of the servers in this farm according to the farm load balancing settings.

If the default gateway is not a farm server, then traffic is just forwarded to this default gateway without any load balancing.

Configuring Flow Management

To configure flow management

1. Select LinkProof > Flow Management > Farms Flow Table. The Farms Flow Table pane is displayed.

2. Click Create. The Farms Flow Table Create pane is displayed.


4. To configure flow policies, click Modify Policies, and then, see the procedure in Configuring Flow Policies, page 197.

Table 95: Farms Flow Table Parameters

Parameter DescriptionFlow Name The flow name.

Farm Name The farm name.

Farm Index 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.

InternetRouter

Farm 1 Farm 2

LinkProofClients



Flow PoliciesA 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 Addresses—IP address or a network class (IP subnets, IP ranges, or list of discrete IP addresses can be defined as a network class). For more information, see Bandwidth Management, page 311.

• Application—Using the Service elements it is possible to define a required application according to application port and/or additional data (see Bandwidth Management, page 311).

Note: Although the Service classes that can be configured on the device allow for definition of Layer 7 criteria (for Bandwidth Management purposes), when used for traffic classification for flow management purposes, any criteria that is not found in the first packet of the session will be ignored during the classification process.

Note: In addition to the Service classes, you can use Discrete Networks.For more information, see Discrete Networks, page 344.

• Traffic Direction—Different 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.

• VLAN Tag—Classifies traffic according to VLAN identifier tags.

• Inbound Physical Port—Classifies only traffic received on certain interfaces of the device.

Policy One Way Two WayLayer 3 Policy Requests from policy source to

destination and the related replies from destination.

All traffic between policy source and destination.

Layer 4 Policy Request only from policy source IP and port to destination IP and port.

Requests from policy source IP and port to destination IP and port and related replies from destination.



Configuring Flow Policies

To configure a flow policy

1. Select LinkProof > Flow Management > Modify Policies. The Flow Management Modify Policies pane is displayed.

2. Click Create. The Flow Management Modify Policies Create pane is displayed.


Table 96: Flow Management Policies Parameters

Parameter DescriptionName The user-defined name of the policy.

Index The index number of the policy.

Destination The destination address of the packet being matched by the policy.

Note: The destination can be an IP address or a network class.

Source The source address of the packet being matched by the policy.

Note: The source can be an IP address or a network class.

Direction Values: One Way, Two Way

Description A description of the policy.

Service Type The type of service.

Values: None, Basic Filter, AND Group, OR Group

Service The name of the service required for this policy, based on the Service Type.

Operational Status The operational status of the policy.

Values:

• Active—when policies are updated, the device uses this policy.

• Inactive—when 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.

Inbound Physical Port Group 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.

VLAN Tag Group The VLAN tag group that you want to use.

Packet Marking 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, 1–63

Default: None



Viewing Active Flow PoliciesYou 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:

• Name—The user-defined name of the policy.

• Index—The index number of the policy.

• Farm Flow—The 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 Packets—The 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 97: Flow Management View Active Policies Parameters




Note: The destination can be an IP address or a network class.


Note: The source can be an IP address or a network class.

Direction The direction of the flow, One Way or Two Way.


Service Type The type of service.


Farm Flow The farm flow to which the policy is assigned.

Inbound Physical Port Group 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.

VLAN Tag Group The VLAN tag group.

Packet Marking 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.



Updating Flow Management Policies


1. Select LinkProof > Flow Management > Update Policies. The Activate Latest Changes pane is displayed.

2. Click Set.

Typical Flow ConfigurationsIt is often required to use different WAN links for different applications and/or destinations. In the following example there are two (2) routers. Router 1 is connected to a private network and can only connect to other corporate sites (Intranet). Router 2 is connected to the public network and can be used as a backup for the private link (with VPN) and also for access to the Internet.

HTTP traffic on the Intranet must use the private link as long as it is available and only use the VPN link for backup. The other applications running on the Intranet can use both links (load balanced).

Figure 18: Flow LinkProof Example Application

Local Network

10.1.1.x

Router 2 Router 1 NAT: 100.1.1.21 for 10.1.1.30via Router 1

NAT: 200.1.1.21

via Router 2for 10.1.1.30

Internal Server

10.1.1.30

100.1.1.10

LinkProof

100.1.1.20 200.1.1.20

Interface 2200.1.1.10

Interface 1



Client TableTo 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.


• Client Table Mechanism, page 200

• Managing Client Tables, page 203

• Client-Table Logging, page 208

• Viewing Client Table Entries Using CLI, page 215

• Filtered Client Table, page 217

• Clearing the Client Table Manually, page 217

Client Table MechanismWhen a client first approaches the device, LinkProof checks whether an entry for that client already exists in the Client Table.

LinkProof automatically removes the relevant entries from the Client Table in the following cases:

• When one of the servers within a farm becomes unavailable.

• When the aging time of an entry expires. The Client Aging Time parameter is set per farm.

• If the Remove Entry at Session End option is enabled, when the session ends.

Note: You can clear the client table manually.

If LinkProof finds the relevant entry in the Client Table, LinkProof directs the client session to the farms and servers that appear in the Client Table, In such a case, there is no need to make a load balancing decision.

If LinkProof finds no relevant entry in the Client Table, LinkProof classifies the traffic to identify the flow that matches the traffic. LinkProof creates an entry in the Client Table indicating the sequence of farms the traffic must pass according to the selected flow. LinkProof selects a server for each farm in the flow, as the traffic reaches it, according to the load-balancing considerations that are defined by the Dispatch Method, and records it in the Client Table.



Example The following two tables illustrate Client Table examples of an HTTP outbound session for the network shown in the figure below.

Figure 19: HTTP Outbound Session Example Configuration

Table 98: Client Table Example A

Source Address Destination Address Source Port Destination Port Flow10.1.1.2 202.2.2.2 1062 80 http flow

Table 99: Client Table Example B

Farm Name Server Name Idx Type Action Port # Ext Idxfw_int_farm fw1 1 Regular Send to Farm 16

fw_ext_farm fw1 2 Regular Send to Farm 17

router_farm router2 3 N Send to Farm 18

Local Network10.1.1.x

Firewall 1

Internal External

Firewall 2

LinkProof

Interface 1

20.1.1.2 30.1.1.2

20.1.1.1 30.1.1.1

Interface 3Interface 2

Router 2

Router 1

100.1.1.20200.1.1.20

Interface 4

10.1.1.10

20.1.1.10 30.1.1.10

100.1.1.10200.1.1.20



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. IDX—the 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:

— Type. A Client Entry can have the values listed in the following table:

— Ext Idx—Extension 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.

Parameter ValueSelect Server A server was not yet selected for this farm.

Send to Farm A server was selected for this farm.

Skip Farm This farm was bypassed.

Discard Packets are dropped when they reach this stage.

Passive Farm 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.

Passive Select A passive server was not yet selected.

Select Tunnel A virtual tunnel was selected.

Select Tunnel PBP A virtual tunnel was selected when Virtual Tunneling is operating in Packet-per-packet mode.

Parameter ValueRegular No packet translation.

V Virtual IP translation.

DN Dynamic NAT.

SN Static NAT.

VPN Rglr Session is encrypted, Flow mode = Basic.

VPN Prvt Session is encrypted, Flow mode = Combined Private and VPN.

VPNVT CT Session is encrypted, Flow mode = VT.

RSN Virtual Tunneling NAT using Static NAT.

RNN Virtual Tunneling NAT using No NAT.



If LinkProof determines that an entry does not exist, LinkProof classifies traffic—to 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 TablesThis section describes managing Client Tables and contains the following:

• Configuring Client Table Global Parameters, page 203

• Client Table Modes, page 204

• Remove Entry at Session End, page 206

• Client Table Tuning, page 207

• Aging by Application, page 207

Configuring Client Table Global ParametersThis section describes configuring the global parameters for the Client Table. Client Table global parameters apply to the LinkProof device and affect all the farms defined on the device. There are separate sections for parameters and options that require lengthy descriptions.

To configure the global parameters for the Client Table

1. Select LinkProof > Global Configuration > Client Table > General. The Global Configuration - Client Table pane is displayed.


Table 100: Client Table Global Parameters

Parameter DescriptionClient Table Mode Indicates which layer of address information the device uses to

categorize packets in the Client Table.

Values:

• Layer 3—For more information on this option, see Layer 3 Client Table Mode, page 204

• Half Layer 4—For more information on this option, see Half Layer 4 Client Table Mode, page 205

• Full Layer 4—For more information on this option, see Full Layer 4 Client Table Mode, page 205

Default: Full Layer 4

Remove Entry at Session End When enabled, client entries are immediately removed from the Client Table when the client session ends.


Default: disable



Client Table ModesLinkProof supports the following Client Table modes:

• Layer 3 Client Table Mode, page 204

• Half Layer 4 Client Table Mode, page 205

• Full Layer 4 Client Table Mode, page 205

Note: Since a new table entry is made into the Client Table for every new session, the Client Table has many entries. You can increase the Client Table to accept more entries based on the amount of RAM available on the LinkProof device.

Layer 3 Client Table ModeIn Layer 3 mode, each entry is identified by the following parameters:

• Source IP address

• Destination IP address

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

Remove Alternative Server Clients in Hashing

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.


Default: enable

Server Selection Override Specifies whether a server can be changed after the load-balancing selection. For example, it is possible the load-balancing decision chooses server 1, and the reply comes from server 2.


Default: disable

Table 100: Client Table Global Parameters




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:



• Destination port

In Half Layer 4 mode, all the sessions destined to the same address and port are represented by a single entry in the Client Table, regardless of the source port/s. For example, in a simple Web page retrieval, a client may open several TCP sessions with the server, using each session to transfer different parts of the page, such as text, GIF files, and so on. All of these sessions, identified by Destination port 80 and different Source ports, constitute a single entry in the Client Table.

LinkProof performs the search using source and destination IP addresses, protocol, and destination port only. The source port displayed in the Client Table will be the first source port that initiated the session.

Half Layer 4 mode is the minimum mode required whenever sessions to different destination ports must be tracked separately—for 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 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 entry’s flow and selects the longest period.

Tip: Removing entries from the Client Table immediately when the TCP session is closed frees the memory resources for the active sessions and therefore improves memory utilization.

When the Remove Entry at Session End option is enabled, LinkProof behaves as follows:

• When LinkProof detects a RST or FIN packet between the source and the destination LinkProof marks the entry for deletion from the Client Table, as the RST/FIN packets indicate that the session is closed.

• The entry is aged in five seconds and subsequently removed.

Port HashingThe 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.

Client Table TuningWhen setting the Client table size you must also configure Client Extension Table size. The relationship between the two table sizes is a MIB relationship, which is:

ClientExtensionTableSize = MaxNumberOfFarmsInAFlowAsConfiguredOnTheDevice × ClientTableSize

For example, if LinkProof load balances routers only, the Client Table Extension size should be the same as the Client Table Size.

For information on tuning procedure, see Tuning Device Table Parameters, page 75.

Aging by ApplicationYou can assign different applications different client lifetimes. Since applications are identified by the ports they use, you assign application aging times by configuring aging times for specific ports. For example, you can assign FTP longer aging times and HTTP shorter ones.

You can configure application-aging times for applications over TCP and UDP protocols. For applications not included in the UDP and TCP protocols (for example, ICMP), use port 0. Any applications for which you do not assign an aging time will age according to the farm configuration.

Note: Aging per application is available only if Client Table mode is Half Layer 4 or Full Half Layer 4.

To configure aging by application

1. Select LinkProof > Global Configuration > Client Table > Aging by Application Port. The Aging By Application Port pane is displayed.

2. Click Create. The Aging by Application Port Create pane is displayed.


Table 101: Client Modes and Hashing

Client [Table] Mode Client Table Information that LinkProof Uses Layer on Which LinkProof Does Hashing

Layer 3 Source IP Destination IP L3

Half Layer 4 Source IP Destination IP Destination Port

L3

Full Layer 4 Source IP Destination IP Source Port Destination Port

L3

Full Layer 4 + Port Hashing enabled

Source IP Destination IP Source Port Destination Port

L4



Client-Table LoggingLinkProof can log Client Table data to the following:

• Files on the platform’s hard disk—You can retrieve the files from the hard disk using FTP. The hard-disk Client-Table logging mechanism manages Client-Table data according to user-configurable hard-disk management and log-file management parameters.

• A syslog server—LinkProof can log Client Table data to a syslog server—not a snapshot.

• A snapshot file on the platform’s hard disk—A LinkProof device can write a snapshot (that is, a copy) of the Client Table data in memory directly to the hard disk—even 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 DirectoryLinkProof 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 FormatThe hard-disk Client-Table logging mechanism writes data to text files in CSV ASCII format.

The mechanism names closed files <yyyyMMdd>_<hhmm>_<ss>.txt—for example, 20081207_1713_54.txt.

The mechanism names temporary files <yyyyMMdd>_<hhmm>_<ss>_tmp.txt—for example, 20081207_1713_54_tmp.txt.

Table 102: Aging by Application Port Parameters

Parameter DescriptionApplication Port The application port for which to configure the aging time.

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: 5–65534

Default: 60



The files includes the following fields:

• Start Time—Marks the entry of the start of the client session in dd/MM/yyyy hh:mm format.

• End Time—Marks the entry of the last activity of the entry in dd/MM/yyyy hh:mm format.

• Source IP address—The source where the connection is coming from.

• Destination IP address—The destination where the connection is going to.

• Router/Firewall—Which gateway IP was used by the LinkProof device to access the Internet or WAN.

• Protocol—The protocol used in the packet (according to RFC 5237), for example, FRAG, ICMP, IGMP, UDP, TCP OSPF, and so on.

• Source Port—The port that was requested internally.

• Destination Port—The port that was requested on the destination address.

• NAT Address—The NAT address given by the LinkProof device.

• NAT Type—The NAT type given by the LinkProof device.

• Bytes—The 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)

Hard-Disk Management and Log-File Management The hard-disk Client-Table logging mechanism manages Client-Table data according to user-configurable 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.

Table 103: Example Client TableStart Time End Time Source IP Dest. IP Router Protocol

Type.Source Port

Dest. Port

NAT Address NAT Type Bytes

07/12/2008 23:40 192.168.100.2 6.6.6.200 0.0.0.0 TCP 1024 80 241.226.144.124 OTHER 71



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 Effort—Lower CPU priority. If the CPU has other tasks to perform, logging receives a lower priority.

— FULL—Logging 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: 5–250

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 FIFO—The device overwrites the oldest log file in the log directory.

— Stop Logging—The 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



• services hard-disk total-size

Displays the size, in megabytes, of the hard disk.

Equivalent parameter in Web Based Management: Local Hard Disk Size

• services hard-disk free-size

Displays the size, in megabytes, of the free space on the hard disk.

Equivalent parameter in Web Based Management: Available Free Disk Space

• services hard-disk set free-size-save {<Value>|<Value> MB|<Value> %>

The amount of space that the hard disk will keep free (high-water mark).

Equivalent parameter in Web Based Management: Disk Space to Keep Free

Values:

— Any value, in megabytes, between 0.002 and 99.8 percent the size of the hard disk.

— Any value with a percent sign (%) between 0.002 and 99.8.

Default: 1500 MB

Example:

services hard-disk free-size-saved set “1500.00 MB”

Table 104: CLI Commands for Hard-Disk Management and Log-File Management

Parameter Description CommandLogging Priority The priority of the hard-disk Client-

Table logging to manage CPU load.

Values:

• Best Effort—Lower CPU priority. If the CPU has other tasks to perform, logging receives a lower priority.

• FULL—Logging gets a high priority. The device logs everything ignoring any performance impact.


services hard-disk logging-priority set {full|best effort}Example:services hard-disk logging-priority set best effort

Log File Size (MB)

The maximum size, in megabytes, of the Client-Table log files.

Values: 5–250

Default: 100

services hard-disk log-file-size set <Value>

Example:services hard-disk log-file-size set 100

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 {1|12|24}

Example: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”



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.


Log Files Write Mechanism


Values:

• CYCLIC FIFO—The device overwrites the oldest log file in the log directory.

• Stop Logging—The device stops all logging activity until the hard-disk space issue is resolved.


services hard-disk log-behavior set {“Stop Logging”|”CYCLIC FIFO”}

Example:services hard-disk log-behavior set “CYCLIC FIFO”

Log File Purge Immediately purges the entire Client-Table log-file directory.

services hard-disk log-purge “Purge now”

Local Hard Disk Size (MB)

Displays the size, in megabytes, of the hard disk.

services hard-disk total-size

Available Free Disk Space

Displays the size, in megabytes, of the free space on the hard disk.

services hard-disk free-size

Disk Space to Keep Free

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

services hard-disk set free-size-save {<Value>|<Value> MB|<Value> %>

Example:services hard-disk free-size-saved set “1500.00 MB”

Table 104: CLI Commands for Hard-Disk Management and Log-File Management

Parameter Description Command



Table 105: Hard Disk Logging Management Parameters

Parameter DescriptionLogging Priority The priority of the hard-disk Client-Table logging to manage CPU load.

Values:

• Best Effort—Lower CPU priority. If the CPU has other tasks to perform, logging receives a lower priority.

• Full—Logging gets a high priority. The device logs everything, ignoring any performance impact.


Log File Size (MB) The maximum size, in megabytes, of the Client-Table log files.

Values: 5–250

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


Values:

• CYCLIC FIFO—The device overwrites the oldest log file in the log directory.

• Stop Logging—The device stops all logging activity until the hard-disk space issue is resolved.


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 The size, in megabytes, of the hard disk. This value is read only.

Available Free Disk Space

The size, in megabytes, of the free space on the hard disk. This value is read only.

Disk Space to Keep Free

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



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 disk—even 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.


— 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.



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 FiltersYou can configure up to five different filters to view the types of information that the Client Table of the LinkProof device stores. Use the View Filters pane to configure the filters. The logical condition between the filters is an OR condition. The condition between the different parameters within a filter is an AND condition. It is also possible to activate and deactivate each of the filters. By default, the filters are inactive, which means that the whole Client Table is presented.

To configure a Client Table filter

1. Select LinkProof > Clients > View Filters. The View Filters pane is displayed.

The table comprises the following columns:

— Index

— Source IP From

— Destination IP From

— Destination Port From

— Status

2. Click Create. The View Filters Create pane is displayed.




Table 106: View Filter Parameters

Parameter DescriptionIndex The Filter Index number that is currently selected.

Values: 1–5

Status Specifies whether the filter is active or inactive.

Values: Active, Inactive

Default: Active

Source IP From The start of the range of the clients’ addresses.

Source IP To The end of the range of the clients’ addresses.

Destination IP From The start of the range of the addresses of the servers that provide the requested service.

Destination IP To The end of the range of the addresses of the servers that provide the requested service.

Source Port From 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.

Source Port To 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.

Destination Port From 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.

Destination Port To 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.

Next Hop Router IP The IP address of the next-hop router.

Client Types 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:

• any—Any client type.

• regular—Any client of the type Regular.

• dynamicNat—Any client receiving an dynamic NAT address.

• basicNat—Any client receiving a NAT address from Basic NAT.

• virtualIP—Any client destined for a virtual IP address on the device.

• staticNAT—Any client receiving a NAT address from Basic NAT.

• staticPAT

• no nat—Any client matching the configured NoNAT addresses.

• vpn—Any client matching VPN policy.

• remoteNatStaticNat—Any client matching Virtual Tunneling Policy with Static NAT address policy.

• remoteNatNoNat—Any client matching Virtual Tunneling Policy with No NAT address policy.



Filtered Client TableThe Client Table stores a lot of information, which makes it very difficult to view such tables, since they may become very heavy. To generate reliable and useful reports and to avoid system failures, you can use various filters for presenting information in the Client Table.

To view the filtered Client Table

1. Select LinkProof > Clients > Filtered Client Table. The Filtered Client Table pane is displayed.

The table comprises the following columns:

Clearing the Client Table ManuallyUse the Clear Client Table pane to clear the Client Table.

To clear the Client Table manually

1. Select LinkProof > Clients > Clear Client Table. The Clear Client Table pane is displayed.

2. From the Clear Client Table drop-down list, select Clear.

3. Click Set.

Action The filter action.

Values:

• No Action

• Delete All Matching

• Count All Matching

VIP Type The type of virtual IP the filter uses.

Values:

• any—Any VIP.

• VIP—The specified IP address.

• Disable—The filter does not filter according to VIP.

Parameter DescriptionSource Address The IP address of the source.

Client Address The IP address of the client.

Destination Address The IP address of the destination.

Source Port The source port of the client.

Destination Port The destination port of the client.

Table 106: View Filter Parameters




VPN Load BalancingWhen 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.


• Network Topology with LinkProof Devices Through Firewalls, page 218

• Multicast Dispatch, page 219

• Clear Client Table (VPN Load Balancing Feature), page 220

• Client Table Overwrite, page 222

Network Topology with LinkProof Devices Through FirewallsThe following diagram shows a network topology called a Firewall Sandwich. This topology reflects the inbound and outbound traffic flow as it is routed by the LinkProof devices through firewalls.

Figure 20: Firewall Sandwich Topology

Network Session Starting from Headquarters to BranchIn 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 21: VPN Alternative Traffic Paths

LinkProof is unable to determine which VPN gateway the tunnel uses (the tunnel is maintained via one VPN gateway only). Therefore, if traffic is routed back via the wrong path, the connection is dropped by the other VPN gateway. To avoid this happening, the Multicast Dispatch Method is available to configure a firewall farm.

Multicast DispatchWhen the network session starts from the headquarters to the branch, as shown in Figure 21 - VPN Alternative Traffic Paths, page 219, a VPN session is open along the red path.

H.Q.

Branch

VPN Gateway 1

VPN Gateway 1

VPN Gateway 3

LinkProof

LinkProof

LAN A

LAN B

LAN C

Branch LAN

RouterPath A

Path B

H.Q.

Branch

VPN Gateway 1

VPN Gateway 1

VPN Gateway 3

LinkProof

LinkProof

LAN A

LAN B

LAN C

Branch LAN

Router

H.Q.

Branch

VPN Gateway 1

VPN Gateway 1

VPN Gateway 3

LinkProof

LinkProof

LAN A

LAN B

LAN C

Branch LAN

RouterPath A

Path B



When the Multicast Dispatch Method is used, after the return packet reaches the lower LinkProof device, a Multicast is sent with the return packet to both VPN gateways. The gateway that responds first, is the one with an established VPN session. LinkProof forwards the traffic to the VPN gateway and the session is not interrupted.

Note: The OnDemand Switch VL platform does not support the Multicast Dispatch Method.

For information on configuring a farm with the Multicast Dispatch Method using Web Based Management, see LinkProof Farms, page 138.

To configure multicast dispatch using CLI


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.



Figure 22: Clear Client Table Scenarios

Clear Client Table—Scenario 1In 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.



Clear Client Table—Scenario 2Another 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


lp farms -farms set <Farm Name> -tc <1|2|3> where:

— 1—Specifies None (default); that is, previous functionality is ignored.

— 2—Specifies 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.

— 3—Specifies First Regular Server Up, that is, when a regular server goes up and it is the first regular server for that farm to go up, all the Client Table entries associated with that server selection of that farm are deleted.

Note: You can use the values also when creating the firewall server farm.

For information on configuring a farm with the clear-Client-Table condition using Web Based Management, see LinkProof Farms, page 138.

Client Table OverwriteThis feature assists in dealing with the problems associated with Clear Client Table—Scenario 1, page 221. To solve the problem, a flag indicates when a client entry as part of a farm needs to be deleted when the server of that farm comes up again.

Note: Because two redundant LinkProof devices may not be synchronized and might not recognize that the server is up or down at the same time, there could be persistency issues until server selection status data is overwritten. Persistency issues remain until the Client Table entry is deleted. A server that receives a packet from a different server (firewall) is not overwritten. If the new server is of a farm different from the farm of the original server, the server selection is not overridden. If IP translations (NAT) of any sort are involved for the session, the server selection is not overridden.



To configure Client Table overwrite using CLI


lp global client-table server-selection-override set {disable|enable}

To configure Client Table overwrite once a new farm has been created using Web Based Management

1. Select LinkProof > Global Configuration > Client Table > General > Server Selection Override.

2. From the Server Selection Override drop-down list, select either disable (default) or enable.

3. Click Set.




Chapter 5 – Advanced FeaturesThis chapter describes LinkProof’s advanced capabilities and provides common configuration examples.


• Content Load Balancing, page 225

• Tunneling, page 234

• Virtual Tunneling, page 237

• Cost-based Load Balancing, page 247

• Event Scheduler, page 248

• Miscellaneous Parameters—Tweaks, page 249

• Performance Statistics, page 251

• Statistics Monitor SRP Management Host IP Address, page 260

• Configuration Auditing, page 261

• NTP Service, page 262

• RADIUS Service, page 263

Content Load BalancingThis section describes what content load balancing is and describes the methods for LinkProof load balancing.


• Content Load Balancing Overview, page 225

• Remove Proxy, page 1

• Layer 7 Policies, page 228

• Content Rules, page 230

• Hostname Lists, page 233

Content Load Balancing OverviewDue 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


• Delayed Binding, page 226

• Alias Ports, page 227

LinkProof User Guide Advanced Features


Delayed BindingTo make a load balancing decision based on HTTP content (Layer 7 decision), LinkProof implements a mechanism referred to as Delayed Binding.

When Delayed Binding is used, LinkProof does the following:

1. Performs a TCP handshake with the client in order to receive the HTTP request.

2. Parses the data in the HTTP request, usually HTTP headers.

3. Performs the load balancing decision according to the configured Layer 7 policies.

4. Initiates a TCP handshake with the destination.

5. 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. Select LinkProof > Global Configuration > Delayed Bind. The Global Configuration - Delayed Binding pane is displayed.


Table 107: Delayed Binding Global Parameters

Parameter DescriptionSearch Depth In Bytes 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: 1460–66560

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: 1–100

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.

LinkProof User GuideAdvanced Features


Alias PortsLinkProof devices often are installed on networks that contain proxies. The function of the proxy is to inspect the traffic before sending it out to the internet. These proxies tend to use TCP ports that do not correspond to the well-known TCP ports usually used by a certain protocol (that is, HTTP traffic may appear with port 8080 as the destination port).

LinkProof uses Alias Ports, which enable you to link any destination TCP port to one of these protocols.

Caution: Any type of traffic other than HTTP and POP3 should not use aliases.

To create a new alias port

1. Select LinkProof > Global Configuration > Alias Ports. The Alias Ports pane is displayed.

2. Click Create. The Alias Ports Table Create pane is displayed.


SYN Protection Accumulate Request

Specifies whether the feature is enabled or disabled.


Default: disable

Http Persistency This feature is relevant only when a Layer 7 Policy is enabled (LinkProof > Content LB Parameters > L7 Policies Table).

Values:

• Enable—The 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.

• Disable—Clients 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.

• enableHeadOnly—Same 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.0—Changes 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.

• disableNeutral—Not supported.

Default: Disable

Table 107: Delayed Binding Global Parameters




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.

Caution: Layer 7 PoliciesA single Layer 7 Policy (or L7 Policy) can include several Content Rules (see Content Rules, page 230), all using the same HTTP criteria, such as URL, HTTP header, and so on. For example, a Layer 7 Policy can send HTTP traffic to a certain URL via a specific router always. To select farm according to a Layer 7 Policy, LinkProof matches the packet against the entries within the Policy according to the defined order, and uses the first matching entry.

Caution: The more specific policy must appear first; otherwise; the less specific policy is always matched and used.

Example A packet with a request to URL www.a.com/a arrives at LinkProof, which has a Layer 7 policy with the following entries:

— First entry with classification criteria www.a.com/ab

— Second entry with classification criteria www.a.com/a

Then the second entry is matched and used.

The criteria according to which LinkProof classifies traffic are called Methods.

The following Method Types are available for LinkProof:

— URL—Looks For a specified hostname and/or path in the HTTP request.

— File Type—looks for a specified File Type in the HTTP request.

— Header Field—Looks for a specified Header Field in the HTTP request.

Table 108: Alias Port Parameters

Parameter DescriptionPort Number The value of the destination TCP port. Enter a value that

corresponds to the required protocol.

Well Known Port Number 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)



— Cookie—Looks for a Specified cookie in the HTTP request.

— Regular Expression—Looks for a regular expression anywhere in the HTTP Header of the request. LinkProof supports Posix 1002.3 regular expressions, the string can be up to 80 characters.

Note: All content settings of the methods are case insensitive.

To configure a new Layer 7 policy

1. Select LinkProof > Content LB Parameters > L7 Policies Table. The L7 Policies Table pane is displayed.

2. Click Create. The L7 Policies Table Create pane is displayed.


Table 109: L7 Policy Parameters

Parameter DescriptionL7Policy Name The name of the L7 policy.

L7PolicyIdx The order in the list of policies—in 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.

• Bypass—Bypass all farms of the type defined in this policy.

• Drop—Discard 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 farm’s Dispatch Method.

Values:

• Select-Server—Load balances between the servers in the farm according to the farm’s 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.



Content RulesContent 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

Service Type Values:

• None

• Basic Filter

• AND Group

• OR Group

Default: None

Service The service (traffic type) from the list. The contents of the list depend on the selected Service Type.

Hostname List The Hostname List (see Hostname Lists, page 233) that the device applies when trying to match a packet.

Optional.

Values:

• None—Specifies that the policy does not use a Hostname List.

• The Hostname Lists configured on the device.

Default: None

Table 110: Method Types

Method Type Method-specific Parameters

Description Example

URL Host Name The host name part of the URL in the HTTP header (mandatory)

Host Name = www.a.com

Path The path part of the URI in the HTTP header

Path = cgi-bin

File Type File Type The type of file in the URI Type = html

Header Field Header Field A specific header field in the HTTP request (mandatory)

Header Field + Accept-Language

Token A value inside the specific header field

Token = en-us

Cookie Cookie Key A specific cookie key in the HTTP request (mandatory)

Cookie Key = server

Cookie Value The value of the cookie key

Cookie Value = red

Regular Expression

Regular Expression Regular Expression (string pattern matching)

Regular Expression + .ABC

Table 109: L7 Policy Parameters




Delayed Binding (see Delayed Binding, page 226). When the LinkProof device receives enough information from the HTTP header, a farm and then a server can be selected according to the Layer 7 Policy attached to that Content Rule.

This sections contains the following topics:

• Configuring Content Rules, page 231

• Content Rule Configuration Examples, page 233

Note: Content Rules are activated only for HTTP traffic over standard port 80.

Configuring Content RulesOnce Layer 7 policies have been defined, you can associate the Layer 7 policies to a Content Rule.

Note: The Layer 7 policies selected in the Content Rule must be polices defined for the same type of farms as the Content Rule.

To create a Content Rule

1. Select LinkProof > Content LB Parameters > Content Rules Table. The Content Rules Table pane is displayed.

2. Click Create. The Content Rules Table Create pane is displayed.


Table 111: Content Rule Parameter

Parameter DescriptionContent Rule Name The name of the Content Rule.

Default Action The action that LinkProof takes if the request traffic does not match this policy.

Values:

• Bypass—Bypass all farms of the type defined in this Content Rule.


• 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



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.


Table 112: Content Rule Update Parameters

Parameter DescriptionDefault Action The action that LinkProof takes if the request traffic does not match this

policy.

Values:

• Bypass—Bypass all farms of the type defined in this Content Rule.


• 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



Content Rule Configuration ExamplesDifferent WAN links are often required for different applications provided over HTTP. The following figure shows a configuration with two routers. Router 1 must always be used for the CRM application provided over HTTP and for access to the corporate intranet. For the rest of the traffic, Router 2 should be used, while Router 1 should only be used as backup in case Router 2 fails.

Figure 23: Content Rule Configuration Example

Hostname ListsAn 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.

Interface 1

Local Network

10.1.1.x

LinkProof

Router 2

100.1.1.10

10.1.1.10

Interface 2

200.1.1.10

Router 1



Adding a Hostname to a Hostname ListUse 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.


View Hostname List StatisticsLinkProof exposes Hostname List statistics in the Hostname Lists Statistics pane.

The table in the Hostname Lists Statistics pane comprises the following columns:

• List Name—The name of the Hostname List

• Number of Hostnames—The number of hostnames configured in the relevant Hostname List

• Number of Policy Matches—The 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.

TunnelingCarriers, service providers, and large organizations use various tunneling protocols to transmit data from one location to another. Tunneling is done via the IP network in a way that network elements are unaware of the data encapsulated within the tunnel. This implies that routers route traffic based on source and destination IP addresses. IPS devices and load balancers, however, whose decisions are based on information located inside the IP packet at a known offset, are not able to locate relevant information, since the original IP packet is encapsulated within the tunnel.

LinkProof supports the following tunneling types:

• Layer 2 Tunneling Protocol (L2TP), page 235

• Generic Routing Encapsulation (GRE), page 235

• GPRS Tunneling Protocol (GTP), page 236

• Multiprotocol Label Switching (MPLS), page 236

Table 113: Hostname List Parameters

Parameter DescriptionList Name Combo-box with the Hostname Lists.

Hostname The name or IP address of the host.



If a LinkProof device is positioned between two tunneled purpose border routers (which encapsulate and remove the tunneled header), LinkProof takes all the routing and farms’ load-balancing decisions based on the tunneled header of the packet, since the border routers (and other potential servers) are forwarding the packet based on the tunneled information which the packet carries with it.

Bandwidth management (BWM) and flow-management policies can be applied on tunneled packets. Note that the policy classification is based on the payload of the tunneled packet (and not on the tunneled header), since, generally, with BWM and flow management policies, only the payload is interesting.

To enable tunneling

1. Select Device > Tunneling. The Tunneling Parameters pane is displayed.

2. From the Tunneling Parameters drop-down list, select Enabled.

3. Click Set.

Layer 2 Tunneling Protocol (L2TP)Layer 2 Tunneling Protocol (L2TP) is an extension of Point-to-Point Protocol (PPP) and designed as replacement for two proprietary protocols: Cisco’s L2F and Microsoft’s PPTP.

L2TP, defined in RFC 2661, is an application-layer tunneling protocol, which utilizes UDP port 1701 to transmit multiprotocol packets across layer 2 links.

When a packet is encapsulated using L2TP, a new IP packet is created with a new IP header with the Tunnel ID and Session ID.

Figure 24: Tunnel ID and Session ID in Packet Encapsulated Using L2TP

An example of L2TP packet looks as follows:

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.

Table 114: Example L2TP Packet Structure

Ethernet IP UDP L2TP PPP Original IP header

Original data



Figure 25: IP Header in GRE Packet

GPRS Tunneling Protocol (GTP) GPRS Tunneling Protocol (GTP) defines the protocol between GPRS Support Nodes (GSNs) in the GPRS backbone network. GTP includes both the GTP control plane (GTP-C) and data transfer (GTP-U) procedures. GTP allows multi-protocol packets to be tunneled through the UMTS/GPRS backbone between GSNs and between an SGSN and UTRAN. The GTP protocol tunnels the protocol data units through the IP backbone by adding routing information. GTP operates on top of TCP/UDP over IP.

When a packet is encapsulated using GTP, a new IP packet is created.

Figure 26: IP Header in GTP Packet

Multiprotocol Label Switching (MPLS) Multiprotocol Label Switching (MPLS) is an IETF initiative that integrates Layer 2 information concerning network links (bandwidth, latency, utilization) into Layer 3 (IP) within ISP, service-provider, or carrier networks.

When MPLS is used, a label is added to the original packet. The label contains information about routing, available bandwidth, delays and other parameters. The MPLS header is placed between L2 and L3 headers and contains one or more labels. Each entry is 32-bits long.

Figure 27: Entry Format in MPLS Packet

If the IP packet is already an IP fragment, it cannot be fragmented again, because IP does not support multiple fragmentations.

IP fragments that exceed the network MTU are discarded.



Virtual TunnelingThis section describes virtual tunneling and how it functions in the network in conjuction with LinkProof.


• Virtual Tunneling Introduction, page 237

• Virtual Tunneling Configuration, page 239

Virtual Tunneling IntroductionProviding high availability and load balancing over multiple WAN links for applications such as VPN (Virtual Private networks) or VoIP can be very difficult if not completely impossible with current technology. It should also be noted that Internet load balancing and high availability for IP applications are difficult to NAT.

Applications, such as VoIP signaling and VPN connectivity, have difficulties in multihomed environments that are not BGP-based for reasons such as the following:

• The applications embed source address information in the packet payload in addition to the packet header.

• The destination addresses for the applications are static and not resolved via DNS.

LinkProof handles this issue by providing virtual tunneling. The virtual-tunneling feature utilizes existing SmartNAT technology. LinkProof uses NAT to encapsulate packets between sites by translating both source and destination addresses.

LinkProof creates virtual tunnels between the two application servers located in different sites, allowing them to communicate via multiple and diverse WAN links.

The virtual-tunneling functionality is operational only between pairs of LinkProof devices. No virtual tunnels can be provided to sites not equipped with LinkProof.

The following diagram shows the encapsulation mechanism used by the virtual-tunneling feature; and it also shows how LinkProof can provide the following:

• High availability for traffic between the two gateways

• Load balancing to increase the bandwidth available to the VPN traffic

Figure 28: Virtual Tunneling Scenario

High AvailabilityIf a client in London wants to establish a VPN connection to San Francisco, the London firewall/VPN gateway (IP address L.100) initiates a connection to the internal IP address of San Francisco firewall/VPN gateway (S.100).

Internet

London San Francisco

L.100 S.100

C.0/24A.0/24

B.0/24 D.0/24



LinkProof on the London side receives the packets and selects a virtual tunnel. Since both London and San Francisco have dual Internet connections there are four (4) virtual tunnels available for the London LinkProof to choose from (A-to-C, A-to-D, B-to-C, B-to-D). If tunnel A-D was chosen, the LinkProof will translate source address to its external IP (Static NAT) via router A and destination address to its external IP via router D.

If link D becomes unavailable, LinkProof London chooses a new virtual tunnel—for example A-to-C and translates the source and destination addresses accordingly. LinkProof San Francisco translates the packets back to the original addresses (L.100 - S.100). This allows the connection between the two VPN gateways to be sustained, regardless of the path that the traffic takes.

To achieve this functionality, the LinkProof units must be aware of the Static NAT tables, WAN links health, response time, and load at remote site. This can be achieved by using the inter-LinkProof communication protocol, called TRP (Tunneling Report Protocol) to populate and “teach” each participating LinkProof the relevant information.

Load BalancingLinkProof provides an option to select a virtual tunnel per new Client Table entry or Packet by Packet.

The Packet by Packet option allows to load balance a tunneled connection over multiple WAN links.

• Per Client Table Entry—Once connectivity is established between two VPN gateways, sessions between clients and servers behind the gateways are opened and closed, but the VPN connection is open. Since LinkProof sees communication between the same two IP addresses, the VPN gateways (L.100 and S.100 in our example), and entry in Client Table already exists, all packets are forwarded to the same virtual tunnel, as long as the virtual tunnel is active.

• Packet by Packet—To load balance a VPN connection between all existing virtual tunnels, LinkProof provides the option of selecting a virtual tunnel per packet instead of per new Client Table entry. Each packet is encapsulated within the chosen virtual tunnel.

Local Service and Remote ServiceVirtual tunnels are created for every pair of local service and remote service. There is a tunnel for each combination of a local and a remote link. Tunnels are created automatically according to the changes in the local or remote links.

A virtual tunnel is set between an IP address of the local LinkProof and an IP address of the remote LinkProof.

During the load-balancing decision, LinkProof selects a virtual tunnel according to its health and additional parameters required by the configured Dispatch Method (response time, load).

TRPTRP (Tunneling Report Protocol) is a proprietary inter-LinkProof communication protocol used to establish and maintain the virtual tunnels. The TRP protocol includes two types of messages:

• Regular—Requires the operational and load status of their WAN links from remote LinkProof devices.

• Extended—Requires WAN links status and configuration changes from remote LinkProof devices.

The interval at which these messages are exchanged is configurable.



Virtual Tunneling ConfigurationThis section describes the basic configuration of the virtual-tunneling feature, which is required for each participating LinkProof device.

Before starting to configure virtual tunneling, do the following:

1. Configure each LinkProof for basic load balancing.

For the router farm that will be used for virtual tunneling, set the following parameters

— Packet Translation—NAT and virtual tunneling

— Connectivity Check Status—Health Monitoring

2. Configure Static NAT/No NAT for local stations participating in virtual tunneling.

3. Define static routes to local station subnets.

4. Define static route to external subnets of remote LinkProof devices—destination=0.0.0.0 route covers all possible subnets.

Enabling Virtual Tunneling

To enable virtual tunneling

1. Select LinkProof > Virtual Tunneling > Global Parameters. The Global Parameters pane is displayed.

2. From the Virtual Tunneling Admin Status drop-down list, select Enable.

3. Click Set.

4. Reset the device.

Configuring Virtual Tunneling Global ParametersYou can configure all the virtual-tunneling global parameters only after you enable the virtual-tunneling feature.

To configure the virtual-tunneling global parameters

1. Select LinkProof > Virtual Tunneling > Global Parameters. The Global Parameters pane is displayed.




Configuring a Virtual Tunneling Local ServiceLocal Service is a logical entity, which represents the service (VPN, VoIP) functionality that the LinkProof device provides.

Before configuring a Virtual Tunneling Local Service, ensure the following:

• Smart NAT functionality is enabled.

• Virtual Tunnelling is enabled (LinkProof > Virtual Tunneling > Global Parameters > Virtual Tunneling Admin Status > Enable > Set).

• Health Monitoring is enabled on the device (Health Monitoring > Global Parameters > Health Monitoring Status > Enable > Set).

• For each farm that participates in the Virtual Tunnel, health monitoring is configured (LinkProof > Farms > FW Farm Table or Router Farm Table > Choose the relevant farm > Connectivity Check Status > Health Monitoring > Set).

To configure a new Local Service

1. Select LinkProof > Virtual Tunneling > Local Service Table. The Local Service Table pane is displayed.

2. Click Create. The Local Service Table Create pane is displayed.


Table 115: Virtual Tunneling Global Parameters

Parameter RemarkVirtual Tunneling Admin Status Specifies whether the virtual-tunneling functionality is enabled.

When the feature is enabled, you can view the Virtual Tunneling submenus.

When you change the status, you must reset the device for the change to take effect.

TRP Admin Status Activates the TRP protocol used to establish and maintain the virtual tunnels.

This parameter is displayed only when Virtual Tunnelling Admin Status is Enabled.

Note: Radware recommends that you enable TRP communication. When the TRP Admin Status is disabled, you must configure the Advanced Configuration parameters manually.

Virtual Tunneling HM Admin Status Enables you to perform Health Monitoring of the virtual tunnels.

This parameter is displayed only when Virtual Tunnelling Admin Status is Enabled.

Table 116: Local Service Table Parameters

Parameter DescriptionLocal Service Name The name of the local service available to external users (other

LinkProof devices).

Password Password for the TRP communication.



Configuring a Virtual Tunneling Local StationOnce the local service is defined, you can start attaching application servers that provide the service in the Local Stations Table.






To configure Local Station Table

1. Select LinkProof > Virtual Tunneling > Local Station Table. The Local Station Table pane is displayed.

2. Click Create. The Local Station Table Create pane is displayed.


Configuring a Virtual Tunneling Remote ServiceFor each Local Service, you need to define the Remote Services to which virtual tunneling is available.

Host Name The host name intended for the TRP DNS resolution.

You can define the LinkProof device as the authoritative name server for this domain in the organization’s master DNS servers. If you do this, the DNS queries for the local service domain name arrive at the LinkProof device, which processes the query in accordance with the best NHR connection available for the user’s request.

Distribution Mode How the device distributes the packets.

Values:

• Client-Table—The device performs load balancing using the Client Table entries.

• Per-Packet—The device performs load balancing per packet.

Table 117: Local Station Table Parameters

Parameter DescriptionLocal Service Name Must be the same as the name defined in the Local Service Table.

Internal Station Address Internal IP of station participating in this service—for example, the station for a VPN service is a VPN gateway. A local station can be attached only to one local service.

Table 116: Local Service Table Parameters









To define a new Remote Service

1. Select LinkProof > Virtual Tunneling > Remote Service Table. The Remote Service Table pane is displayed.

2. Click Create. The Remote Service Table Create pane is displayed.


Table 118: Remote Service Table Parameters

Parameter DescriptionRemote Service Name The name of the Remote Service must be the same as Local Service

name defined in the remote device.

Password The password required for the TRP communication.

Host Name The host name of the remote site. A DNS resolution is performed by the local LinkProof to find out the remote LinkProof address. Then, the TRP requests are sent to the resolved address. In case the value is not defined, the customer must set the addresses manually in the Remote Link Table. The value must be the same as defined in remote LinkProof Local Service Table.

Local Service Name The name of the relevant Local Service must be the same as the value defined in the Local Service Table.

TRP Admin Status Specifies whether or not the device initiates any TRP communication.

Values:

• Enable—Enables TRP traffic from device.

• Disable

HM Admin Status Specifies whether or not the Health Monitoring (HM) functionality is available for the selected Remote Service.

This parameter is ignored if the value for Virtual Tunneling HM Admin Status is Disabled in the Virtual Tunneling Global Parameters pane.



Notes: When you edit an existing remote service, the GUI displays the following read-only parameters in addition to the configurable parameters:

>> Load Balance Method—The Load Balance method used by the remote LinkProof device. This data is received via TRP. The algorithm can be either Cyclic (selecting another link for every new flow) or Weighted (using local LB decision, remote Load Balancing decision, and combined tunnel decision by weighing all the parameters).

>> Remote Service Status—Active when the TRP communication is established, NotInService if the Remote Service is not responding to the TRP communication.

Configuring Virtual Tunneling Advanced TablesYou can configure the following advanced virtual-tunneling tables:

• Remote Link Table

• Remote Station Table

• Virtual Tunnels Table

• Service-NHR Bind Table

You need to configure advanced virtual-tunneling tables in the following cases:

• TRP communication is disabled. If TRP communication is disabled, you must configure the Remote Stations Table and Remote Link Table manually.

• TRP communication is enabled, but you want to modify advanced parameters.

Configuring the Virtual-tunneling Remote Link TableSetting up Remote Links involves specifying IP addresses of remote LinkProof devices. You can specify Remote Links for the Remote Services using the Remote Link Table.

To configure the virtual-tunneling Remote Link Table

1. Select LinkProof > Virtual Tunneling > Advance Configuration > Remote Link Table. The Remote Link Table pane is displayed.

2. Click Create. The Remote Link Table Create pane is displayed.


Table 119: Remote Link Parameters

Parameter DescriptionRemote Service Name The name of the Remote Service as defined in the Remote Service

Table.

Remote Link Address An IP address of the remote LinkProof device. The address can be Virtual DNS address (preferable), Virtual IP Address, or external IP interface (that is, the interface to the NHRs) of the remote LinkProof device.

Remote Link Operational Status The status of the remote link.

This parameter is displayed only if there is a virtual tunnel between two devices configured.



Configuring the Virtual-tunneling Remote Station TableYou can configure stations attached to the Remote Service using the Remote Station Table (for example, VPN gateways).

To configure the virtual-tunneling, advanced Remote Station Table

1. Select LinkProof > Virtual Tunneling > Advance Configuration > Remote Station Table. The Remote Station Table pane is displayed.

2. Click Create. The Remote Station Table Create pane is displayed.


Viewing the Virtual-tunneling Virtual Tunnels TableYou can view the existing virtual tunnels and their status in the Virtual Tunnels Table pane. This table is read only.

To view the Virtual Tunnels Table

Select LinkProof > Virtual Tunneling > Advance Configuration > Virtual Tunnels Table. The Virtual Tunnels Table pane is displayed.

Remote Link Name The name of the Remote Link.

This parameter is displayed only if there is a virtual tunnel between two devices configured.

Remote Link Mode Specifies whether the Remote Link functions in Regular mode or Backup mode.

Table 120: Remote Station Parameters


Table.

Remote Link Address An IP address of the remote LinkProof device as defined in the Remote Link Table.

Remote Internal Address Internal IP address of the Remote Station. For example, the Remote Station for a VPN service is a VPN gateway.

Remote External Address (NAT) The Static NAT address associated with the Remote Station via the remote link.

Table 121: Virtual Tunnels Table Parameters


Table.

Remote Link Address An IP address of the remote LinkProof device as defined in the Remote Link Table.

Table 119: Remote Link Parameters




Configuring the Virtual-tunneling Service-NHR Bind TableYou can configure local NHRs available for each Remote Service using the Service-NHR Bind Table. LinkProof populate the table automatically, but you can edit the parameters within the table.

To modify the virtual-tunneling, advanced Service-NHR Bind Table

1. Select LinkProof > Virtual Tunneling > Advance Configuration > Service-NHR Bind Table. The Service-NHR Bind Table pane is displayed.


Local NHR Address The IP address of a local NHR that can be used to reach the Remote Service.

Operational Status The operational status of this tunnel.

Values: Active, NotInService

VT Mode (Local-Remote) The mode of the Virtual Tunnel. The mode depends on the Remote Link Mode and the local NHR Bind Mode.

This parameter is displayed only after there is an entry for Entry mode.

Values:

• Regular-Regular

• Regular-Backup

• Backup-Regular

• Backup-Backup

Note: If there are Regular-Regular virtual tunnels available, only they participate in the load-balancing decision. If no Regular-Regular tunnels are available, Regular-Backup tunnels are the next to consider, then Backup-Regular and finally Backup-Backup.

Table 122: Virtual-tunneling Service-NHR Bind Parameters

Parameter DescriptionRemote Service Name The name of the Remote Service as defined in the Remote Service Table.

Local NHR Address The IP address of a local NHR that can be used to reach the Remote Service.

NHR Bind Mode Specifies whether the NHR is functioning in Regular mode or Backup mode regarding the Remote Service.

Table 121: Virtual Tunnels Table Parameters




Configuring Virtual-Tunneling Tweaks

To configure virtual-tunneling tweaks

1. Select LinkProof > Virtual Tunneling > Tweaks. The Tweaks pane is displayed.


NHR Bind Status Specifies whether the NHR is available for the Remote Service.

Entry Mode The Entry Mode.

Value:

• Dynamic—The device automatically fills up the entry in accordance with other virtual-tunneling settings.

• Static—If you modify the entry, the mode of the entry changes to Static. Once the mode becomes Static, the device does not automatically update the parameters of this entry.

Table 123: Virtual-Tunneling Tweaks

Parameter DescriptionTRP Port The port used by the TRP communication. If there other network

devices on the same network that use the same port, this port number must be changed. The same TRP port must be configured on all the LinkProof devices that communicate via TRP.Default: 2090

TRP Retries The number of times this device tries to initiate the TRP communication with remote LinkProof devices.

TRP Regular Interval The time, in seconds, at which the Regular TRP messages are initiated.

TRP Extended Interval The time, in minutes, at which the Extended TRP messages are initiated.

Tunnel Check Interval The time interval, in seconds, at which the tunnel health is checked.

Tunnel Check Retries The number of times that the tunnel health checks are attempted.

Tunnel Check Timeout The time, in seconds, after which the operational status of a tunnel that does not respond to health checks is set to NotInService.

Tunnel Weight The weight applied to tunnel latency values in the load-balancing decision.Values: 1–100

Local Link Weight The weight applied to a local link load value in the load-balancing decision.Values: 1–100

Table 122: Virtual-tunneling Service-NHR Bind Parameters




Cost-based Load BalancingCompanies 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 Rate—Unlimited usage with a set fee for a specified bandwidth, for example, $1500/month for a 1.5-Mbit/s line.

• Usage-based—Users pay according to received data, for example, $1/MB.

• Tiered—A combination of the flat-rate and usage-based models. Users pay a flat rate for received data up to a threshold and an additional charge for additional received data, for example, $10 for up to 150 MB received data and $2 for every additional MB received.

Configuring Cost Global Parameters

To configure cost global parameters

1. Select LinkProof > Cost > Cost Global Parameters. The Cost Global Parameters pane is displayed.

2. From the Cost Admin Status drop-down list, select Enabled.

3. In the in the Load Calculation Window text box, type the number of seconds for which the average load per link is calculated. Default: 1 sec.

Note: Use the Load Calculation Window parameter to moderate the impact of traffic spikes.

4. Click Set.

Configuring the Cost Parameters for a LinkUse the NHR Cost Table pane to configuring the cost parameters for a link.

When the network implements a “ladder” or “combined” method, repeat the following procedure for each cost-per-bandwidth level.

To configure an entry in the NHR Cost Table

1. Select LinkProof > Cost > NHR Cost Table. The NHR Cost Table pane is displayed.

2. Click Create. The NHR Cost Table Create pane is displayed.




Event SchedulerSometimes, 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:00–10: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.

Table 124: NHR Cost Table Parameters

Parameter DescriptionNHR The IP address of the link’s NHR.

Bandwidth Threshold 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:

• Absolute—For flat-rate cost models

• Per Kbps—For 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.



To configure an event schedule

1. Select Services > Event Scheduler. The Event Scheduler pane is displayed.

2. Click Create. The Event Scheduler Create pane is displayed.


Miscellaneous Parameters—TweaksUse the Global Configuration - Tweaks pane to configure miscellaneous parameters of the device.

To configure miscellaneous parameters

1. Select LinkProof > Global Configuration > Tweaks. The Global Configuration - Tweaks pane is displayed.


Table 125: Event Scheduler Parameters

Parameter DescriptionName A user-defined name for the event.

After creation, this value is read-only.

Frequency The frequency of the event.

Values: Once, Daily, Weekly

Time 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: 0000—12:00 AM

Days 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.

Date 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.



Table 126: Global Configuration Tweaks Parameters

Parameter DescriptionIdentify Next Hop Router by Port

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:

• enable—The device selects the MAC address and incoming ports of the Next Hop Router to determine the origin of the Next Hop Router traffic.

• disable—The device selects only the source MAC.

Default: enable

FTP Data Port Specifies whether the device displays the default settings for this port. You may however change the default settings by entering in a relevant port number.

FTP Control Port Specifies whether the device displays the default settings for this port. You may however change the default settings by entering in a relevant port number.

ToS Type 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.


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.


Default: Enable

Time Between Arps The time, in seconds, between retransmissions of ARP request to Firewalls and remote IDS servers.

Values: 5–3600

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

Identify Server by Name 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.


Default: Disable



Performance StatisticsThis section describes the performance statistics that LinkProof supports.


• BWM Policy Statistics, page 251

• Element Statistics, page 254

• IP Interface Statistics, page 258

• NHR Statistics, page 258

BWM Policy StatisticsThis section includes the following:

• BWM Policy Statistics—Global Parameters, page 251

• BWM Policy Statistics, page 251

BWM Policy Statistics—Global Parameters

To configure Policy Statistics global parameters

1. Select Performance > BWM Policy Statistics > Global Parameters. The Policy Statistics Global Parameters pane is displayed.


BWM Policy StatisticsYou can view statistics for the bandwidth-management policies.


• BWM Policy Statistics—Last-Second Statistics, page 252

• BWM Policy Statistics—Last Period Statistics, page 253

Table 127: BWM Policy Statistics Global Parameters

Parameter DescriptionPolicy Statistics Monitoring Enables or disables the monitoring of policy statistics by the

device.


Default: Disabled

Policy Statistics Reporting Period The time, in seconds, that the device monitors policy statistics.

Policy Statistics Reporting (SRP) 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.


Default: Disabled

Note: If you enable the SRP, you must enter the SRP Management Host IP address.



BWM Policy Statistics—Last-Second StatisticsTo 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 128: Last-Second Statistics

Parameter DescriptionPolicy Name The name of the displayed policy.

Packets The number of packets matching the policy during the last second.

Matched BW (Kbits) The traffic bandwidth, in Kbits, matching the policy during the last second.

Sent BW (Kbits) The volume of sent traffic, in Kbits, in any direction, in the last second.

Full Queue BW (Kbits) The bandwidth, in Kbits, discarded during the last second, due to a full queue.

Aged Packets BW (Kbits)

The amount of discarded bandwidth, in Kbits, during the last second, due to the aging of packets in the queue.

Guar. BW reached Specifies whether the guaranteed bandwidth was reached, during the last second.

Values: true, false

Max. BW reached Specifies whether the maximum bandwidth was reached during the last second.

Values: true, false

Inbound Packets The number of inbound packets in the last second.

Outbound Packets The number of outbound packets in the last second.

Inbound Matched BW (Kbits)

The volume of inbound traffic, in Kbits, in the last second that matched the policy.

Outbound Matched BW (Kbits)

The volume of outbound traffic, in Kbits, in the last second that matched the policy.

Inbound Sent BW (Kbits)

The volume of inbound sent traffic, in Kbits, in the last second.

Outbound Sent BW (Kbits)

The volume of outbound sent traffic, in Kbits, in the last second.

New TCP Sess The number of new TCP sessions the device detected in the last second.

New UDP Sess The number of new UDP sessions the device detected in the last second.



BWM Policy Statistics—Last Period StatisticsTo view the information from the Policy Statistics (Last Period) pane, Policy Statistics Monitoring must be enabled.

The parameter determines the period for the statistics in the Policy Statistics (Last Period) pane.

To view BWM Policy Statistics for the last specified period

1. Select Performance > BWM Policy Statistics > Last Period Statistics. The Policy Statistics (Last Period) pane is displayed with a table comprising the following columns:

— Policy Name

— Packets


— Sent BW (Kbits)

2. To view the statistics for a policy, from the Policy Name column, select the relevant policy.

Table 129: Last-Period Statistics

Parameter DescriptionPolicy Name The name of the displayed policy.

Packets The number of packets matching the policy during the last specified period.

Matched BW (Kbits) The traffic bandwidth, in Kbits, matching the policy during the last specified period.

Sent BW (Kbits) The volume of sent traffic, in Kbits, in the last specified period.

Full Queue BW (Kbits) The discarded bandwidth, in Kbits, during the last specified period, due to a full queue.

Aged Packets BW (Kbits)

The amount of discarded bandwidth, in Kbits, during the last specified period, due to the aging of packets in the queue.

Guar. BW reached Specifies whether the guaranteed bandwidth was reached, during the last specified period.

Max. BW reached Specifies whether the maximum bandwidth was reached during the last specified period.

Inbound Packets The number of inbound packets in the last specified period.

Outbound Packets The number of outbound packets in the last specified period.

Inbound Matched BW (Kbits)

The volume of inbound traffic, in Kbits, in the last specified period that matched the policy.

Outbound Matched BW (Kbits)

The volume of outbound traffic, in Kbits, in the last specified period that matched the policy.

Inbound Sent BW (Kbits)

The volume of inbound sent traffic, in Kbits, in the last specified period.

Outbound Sent BW (Kbits)

The volume of outbound sent traffic, in Kbits, in the last specified period.

New TCP Sess The number of new TCP sessions the device detected in the last specified period.



Element StatisticsThis section includes the following:

• IP Packet Element Statistics, page 254

• SNMP Element Statistics, page 255

• IP Router Element Statistics, page 256

• OSPF Element Statistics, page 257

• Resource Utilization Element Statistics, page 257

• Accelerator Element Statistics, page 257

IP Packet Element Statistics

To view IP packet element statistics

Select Performance > Element Statistics > IP. The IP Packet Statistics pane is displayed.

New UDP Sess 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.

Table 130: IP Packet Statistics

Parameter DescriptionIP Receives The total number of input datagrams received from interfaces, including

those received in error.

IP Header Errors 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.

IP Discarded The total number of input datagrams discarded.

Note: This counter does not include any datagrams discarded while awaiting re-assembly.

IP Successfully Delivered

The total number of input datagrams successfully delivered to IP user- protocols (including ICMP).

IP Out Requests The total number of IP datagrams that local IP user-protocols (including ICMP) supplied to IP in requests for transmission.

IP Out Discards 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).

Table 129: Last-Period Statistics




SNMP Element Statistics

To view SNMP packet element statistics

Select Performance > Element Statistics > SNMP. The SNMP Packet Statistics pane is displayed.

Table 131: SNMP Packet Statistics

Parameter DescriptionSNMP Received Packets The total number of messages delivered to the SNMP entity

from the transport service.

SNMP Sent Packets The total number of SNMP messages that were passed from the SNMP entity to the transport service.

SNMP Successful 'get' Requests 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.

SNMP Successful 'set' Requests 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.

SNMP 'get' Requests The total number of SNMP Get-Request PDUs processed PDUs that were accepted and processed by the SNMP protocol entity.

SNMP 'get-next' Requests The total number of SNMP Get-Request PDUs that were accepted and processed by the SNMP entity.

SNMP 'set' Requests The total number of SNMP Set-Request PDUs that were accepted and processed by the SNMP entity.

SNMP Out 'TooBig' 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'.

SNMP Out 'NoSuchName' The total number of SNMP PDUs that were generated by the SNMP entity and for which the value of the error-status is 'noSuchName'.

SNMP Out '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 'badValue'.

SNMP Out 'GenErrs' 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'.

SNMP Out 'GetResponses' The total number of SNMP Get-Response PDUs that were generated by the SNMP entity.

SNMP Out Traps The total number of SNMP Trap PDUs that were generated by the SNMP entity.



IP Router Element Statistics

To view IP router element statistics

Select Performance > Element Statistics > IP Router. The Ip Router Statistics pane is displayed.

Table 132: IP Router Statistics

Parameter DescriptionIP Forwarded 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.

IP Unknown Protocol The number of locally addressed datagrams received successfully but discarded because of an unknown or unsupported protocol.

IP Out No Routes 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 Fragments Received The number of IP fragments received that needed to be reassembled at this entity.

IP Fragments successfully reassembled

The number of IP datagrams successfully reassembled.

IP Fragments failed reassembly 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

The number of IP datagrams that were successfully fragmented at this entity.

IP datagrams discarded - failed fragmentation

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.

IP datagram fragments generated The number of IP datagram fragments that were generated as a result of fragmentation at this entity.

Valid routing entries discarded The number of valid routing entries that were discarded.

RIP - changes made to IP Route Database

The number of changes made to the IP Route Database by RIP.



OSPF Element Statistics

To view OSPF element statistics

Select Performance > Element Statistics > OSPF. The OSPF Packet Statistics pane is displayed.

Resource Utilization Element Statistics

To view resource utilization statistics

Select Performance > Element Statistics > Resources. The Resource Utilization pane is displayed.

Accelerator Element StatisticsOnly 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.

RIP - global responses sent to RIP queries

The number of responses sent to RIP queries from other systems.

IP Fragments successfully reassembled

The number of IP datagrams successfully reassembled.

Table 133: OSPF Packet Statistics

Parameter DescriptionOSPF - new LSAs originated The number of originating Link-State Advertisements in the

link-state database.

OSPF - LSAs received- new instantiations

The number of received Link-State Advertisements in the link-state database.

Table 134: Resource Utilization Statistics

Parameter DescriptionResource Utilization The percent of the device’s CPU currently utilized.

RS Resource Utilization The percent of the device’s RS resource currently utilized.

RE Resource Utilization The percent of the device's RE resource currently utilized.

Last 5 sec. Average Utilization Average resources utilization in the last 5 seconds.

Last 60 sec. Average Utilization Average resources utilization in the last 10 seconds.

Table 132: IP Router Statistics




Each table in the Accelerator Utilization pane comprises the following columns:

— Accelerator—The accelerator.

— CPU—The CPU core identifier, starting from 0.

— Forwarding—The relative amount of time the accelerator core is forwarding traffic, which is the main task of the accelerator.

— Other—The relative amount of time the accelerator core is handling things other than traffic—Mainly managing the accelerator flow database and communicating with the master.

— Idle—The 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.

NHR StatisticsLinkProof 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.

Table 135: IP Interface Statistics

Parameter DescriptionInterface Address The IP address of the selected interface.

RIP - response packets discarded

The number of RIP response received by the RIP process that were subsequently discarded for any reason (for example, a version 0 packet or an unknown command type).

RIP - routes ignored The number of routes, in valid RIP packets, that were ignored for any reason (for example, an unknown address family or an invalid metric).

RIP - updates sent The number of triggered RIP updates actually sent on this interface. This explicitly excludes full updates sent containing new information.

Status The status of the interface’s IP statistics.

Values: valid, invalid



Daily NHR Statistics Table

To view the Daily NHR Statistics Table

1. Select Performance > NHR Statistics > Daily NHR Statistics Table. The Daily NHR Statistics Table pane is displayed with a table comprising the following columns:

— Policy Name

— Packets


— Sent BW (Kbits)

2. To view additional statistics for a server on a day, from the Month column, select the relevant link.

Daily NHR Cost Statistics TableThe Daily NHR Cost Statistics Table displays statistics related to the Cost-based Load-balancing feature. For information on the feature, see Cost-based Load Balancing, page 247.

To view the Daily NHR Cost Statistics Table

Select Performance > NHR Statistics > Daily NHR Cost Statistics Table. The Daily NHR Cost Statistics Table pane is displayed.

Table 136: Daily Discarded Sessions Table Parameters

Parameter DescriptionMonth The month of the current year.

Day The day of the displayed month.

Discarded Sessions Number The number of discarded sessions on the displayed date.

Table 137: Daily NHR Statistics Table Parameters



Server Name The name of the server.

Discarded Zone Percent The percentage of time during the day that the device’s upper resource-consumption threshold was reached.

Minimum Bandwidth [Kbps] The minimum bandwidth for the server on the day.

Maximum Bandwidth [Kbps] The maximum bandwidth for the server on the day.

Forwarded Packet Number [KB] The number for packets that the server forwarded.

Discarded Packet Number The number for packets that the server discarded.

Forwarded Bytes Number [MB] The number of megabytes that were forwarded.

Forwarded Sessions Number [KB] The number of sessions that were forwarded.



Link Quality TableThe 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.

Statistics Monitor SRP Management Host IP AddressIf 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.

Table 138: Daily NHR Cost Statistics Table Parameters



NHR Name The name of the NHR.

Bandwidth Threshold The upper limit of the line according to the Bandwidth Unit value.

Level Percent The percentage of time during the day that the Bandwidth Threshold was reached.

Table 139: Link Quality Table Parameters

Parameter DescriptionDestination Subnet The address of the destination subnet

Best Link Displays the best link option.

Second Link Option Displays the second-best link option.

Third Link Option Displays the third-best link option.



To specify the IP address of the SRP management host

1. Select Services > Statistics Monitor > SRP. The SRP Management Host IP Address pane is displayed.

2. In the SRP Management Host IP Address text box, type the IP address of the machine on which to create the statistics files. This is normally the machine on which the web-based software is running.

3. Click Set.

Caution: Since the statistics files are cumulative, you must disable the Statistic Reporting Mode before files consume too much disk space. Failure to do so can result in the creation of files that fill all available disk space.

Configuration AuditingConfiguration 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 created—such 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 objects—the device additionally reports what the old and new values of the changed parameter are.

• Deleted configuration objects—reported 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.



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


manage auditing status set

NTP ServiceNetwork 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 validation—such 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 > NTP. The Network Time Protocol pane is displayed.




RADIUS Service

To specify the parameters of a RADIUS Authentication server

1. Select Services > RADIUS. The RADIUS Parameters pane is displayed.


Table 140: Network Time Protocol Parameters

Parameter DescriptionNTP Server Address The IP address of the NTP server.

Default: 0.0.0.0

NTP polling Interval 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 The access port number for the NTP server.

Default: 123

NTP Status Enables or disables the NTP feature.


Default: disable

Table 141: RADIUS Parameters

Parameter DescriptionMain RADIUS IP Address The IP address of the primary RADIUS server.

Default: 0.0.0.0

Main RADIUS Port Number The access port number of the primary RADIUS server.

Values: 1645, 1812

Default: 1645

Main RADIUS Secret The password for primary RADIUS server.

Backup RADIUS IP Address The IP address of the backup RADIUS server.

Default: 0.0.0.0

Backup RADIUS Port Number The access port number of the backup RADIUS server.

Values: 1645, 1812

Default: 1645

Backup RADIUS Secret The password for backup RADIUS server.



RADIUS Timeout 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: 1–10

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: 1–3

Default: 2

RADIUS Client Lifetime Duration, in seconds, for client authentication. After the lifetime expires, the device re-authenticates the user.

Values: 15–3600

Default: 30

Table 141: RADIUS Parameters



Chapter 6 – RedundancyThis chapter describes redundancy features and provides common examples of the different LinkProof redundancy configurations.


• LinkProof Redundancy, page 265

• Proprietary ARP Redundancy, page 274

• VRRP Redundancy, page 277

• Remote Virtual IP Addresses, page 287

LinkProof RedundancyThis section introduces LinkProof redundancy capabilities and describes polling and teaching and how these redundancy schemes are incorporated into the LinkProof configuration.


• Introducing LinkProof Redundancy, page 265

• Active/Backup Setup, page 266

• Global Redundancy Configuration, page 267

• Interface Grouping, page 269

• Mirroring the Client Table, page 271

Introducing LinkProof RedundancyTo provide fault tolerance in the case of device failure, Radware recommends installing LinkProof devices in pairs. LinkProof devices support a polling mechanism that allows the backup device to constantly mirror the main device and to ensure the main device is alive. A teaching mechanism is used by the backup device when the main device is down. This is how the takeover takes place. This way, one LinkProof device can always recognize whether another LinkProof device is up or down. In LinkProof, physical IP addresses are configured to poll other LinkProof physical IP addresses. In Figure 29 - LinkProof Redundancy Scheme, page 266, the interface addresses of LinkProof 2 are configured to poll the addresses of LinkProof 1 and the interface addresses of LinkProof 1 are configured to poll the addresses of LinkProof 2.

The teaching process works as follows: once a LinkProof interface considers the other LinkProof interface to be down, it assumes responsibility for the failed IP address. For example, in Figure 29 - LinkProof Redundancy Scheme, page 266, if LinkProof 1 fails and LinkProof 2 decides to take over operation, LinkProof 2 assumes responsibility for IP addresses of LinkProof 1.

Each pair of LinkProof devices can function in an Active/Backup setup.

To achieve redundancy between pairs of devices, LinkProof supports the following methods:

• Proprietary ARP—The device uses Address Resolution Protocol (ARP) to monitor the other device in the pair and check its availability. With Proprietary ARP redundancy, when failing over, the IP addresses of the main device are managed by the backup device and are associated with the backup device’s MAC address.

• VRRP—The device uses Virtual Router Redundancy Protocol (VRRP), which enables maintaining dynamic redundancy using a virtual router. With VRRP redundancy, IP addresses are associated with the virtual MAC addresses owned by the main device, and when failing over, the backup device takes ownership of the IP addresses.

LinkProof User Guide Redundancy


Caution: If the DNAT address is not equal to the associated IP address of the device, LinkProof creates an appropriate associated IP address for the DNAT entry. In a redundant configuration, when you delete the DNAT address of the backup device, LinkProof does not delete the associated IP address that was created automatically previously for the backup device. You must delete the IP address manually.

Figure 29: LinkProof Redundancy Scheme

Active/Backup SetupIn 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.

Network B&C

Network A

Router 1 Router 2

Port 2MAC B

Port 1MAC A

IP B 1

Port 1MAC C

IP B 2

IP A 2

Users

IP A 1

Port 2MAC D

LinkProof User GuideRedundancy


Copying a Device Configuration for a Redundant EnvironmentRunning LinkProof in a redundant configuration requires configuring the two peer devices almost identically. To facilitate the configuration, a LinkProof device can generate a configuration file for the peer device. And then, you can upload the configuration file to the peer.

Copying a device configuration in a redundant environment involves the following:

• Specifying the Peer Address for each IP interface to enable redundancy on (Router > IP Router > Interface Parameters > Peer Address).

• Specifying the appropriate Configuration Type, Regular or Backup (File > Configuration > Receive from Device > Configuration Type). In the Download Configuration File pane, you can select the Include Private Keys check box to download the Private Key for SSH/SSL configuration, so that both devices will use the same private key. For more information, see Downloading a Configuration File, page 57.

Global Redundancy ConfigurationUse 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.


Table 142: Global Redundancy Configuration Parameters

Parameter DescriptionIP Redundancy Admin Status Allows this device to function as part of a backup configuration.

Values: Proprietary, Disable, VRRP

Default: Disable

Note: You must select VRRP to enable mirroring. For more information, see Mirroring the Client Table, page 271.

Interface Grouping Specifies whether Interface Grouping is enabled. When Interface Grouping is enabled, if one port fails, the device takes down the other ports also, and the backup device becomes the active one only when all the interfaces of the main device are down.


Default: disable

Note: For more information, see Interface Grouping, page 269.

ARP with Interface Grouping Specifies whether the device can send ARP requests with the active interface grouping.

Values: Send, Avoid

Default: Send



IP Redundancy TableIn redundancy configurations, both LinkProof devices, the main and the backup, must be defined to work with virtual and physical addresses. The virtual IP addresses are defined on the backup LinkProof in the same manner as on the main LinkProof and the main device makes sure that the backup LinkProof supports virtual addresses. Different physical IP addresses are used for the main and backup devices, and, typically, an additional configuration is required on the redundant LinkProof to support backup for the physical IP addresses of the main device.

Use the IP Redundancy Table pane to set up IP router redundancy. The IP Redundancy table is only relevant for proprietary redundancy.

The following table describes the columns of the IP Redundancy table.

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.

Backup Fake ARP Enables the backup device to perform a fake ARP.


Default: enable

Note: In networks with Layer 3 switches, the Fake ARP confuses the switch during the redundancy process. In this case, disable this option.

Backup Interface Grouping When enabled, the backup device becomes active only when all the IP interfaces defined in the Redundancy Table fail.


Default: enable

Force Down Ports Status The status of the Force Down Ports mechanism.


Default: Disable

Force Down Ports Time How long, in seconds, the device keeps the ports down after a failover.

Default: 5

Trap VRRP Associate Addresses Sends an SNMP trap with the VRRP Associate failover.

Values: On, Off, Summary

Default: Off

Table 143: IP Redundancy Table

Parameter DescriptionInterface IP Address The IP address of the backup interface.

Main Router Address IP address on the main LinkProof interface, which this LinkProof is backing up.

Table 142: Global Redundancy Configuration Parameters




To configure IP router redundancy

1. Select Redundancy > IP Redundancy Table. The IP Redundancy Table pane is displayed.

2. Click Create. The IP Redundancy Table Create pane is displayed.


Interface GroupingTo 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.

Operating Status The redundancy status.

Values:

• Active—The backup LinkProof is now active on this interface.

• Inactive—The backup LinkProof is not active.

Poll Interval The polling interval, in seconds, for the main LinkProof interfaces.

The value 0 (zero) specifies that the LinkProof device is not polled.

Time Out The interval, in seconds, during which the LinkProof device must respond. If the main LinkProof does not respond within this interval, it is considered inoperative. If Time Out is 0, the backup LinkProof ignores the row.

Table 144: IP Router Redundancy Parameters

Parameter DescriptionInterface IP Address The IP address of the backup interface.

Main Router Address The IP address on the main LinkProof interface, which this LinkProof is backing up.

Poll Interval Polling interval, in seconds, for the main LinkProof interfaces. If the interval is 0, the LinkProof is not polled.

Default: 3

Time Out The time, in seconds, during which the LinkProof device must respond. If the main LinkProof does not respond within this time, it is considered inoperative.

Default: 12

Note: The value 0 (zero) specifies that the backup LinkProof device ignores the row.

Table 143: IP Redundancy Table




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. LinkProof examines the configuration to see if any IP addresses were configured on the port that just went down.

2. If there were IP addresses configured on the port that went down, LinkProof deactivates all other active ports.

3. If there were no IP addresses configured on the port that went down, nothing happens and normal operation continues.

Notes:>> Using Regular VLAN, when any of the ports associated with a VLAN is down, Interface

Grouping is triggered.

>> Using Switched IP VLAN, Interface Grouping is triggered only when all ports on a Switched IP VLAN are down.

>> When using VLAN with interface groupings, a group may go down as a result of a failing interface. In such an event, all traffic to the interfaces belonging to the group will be discarded including management traffic.

Selective Interface GroupingOne of the common installations of LinkProof is the LinkProof redundancy installation. In many installations of this kind, both the main and redundant LinkProof have a separate interface for management, which is used solely for management purposes and not for handling actual traffic. A problem may occur if the management interface goes down, since it causes Interface Grouping on the main device to become activated, resulting in the backup device taking control. This issue occurs since the management interface is an IP interface, which when down, affects Interface Grouping.

Using the Master Interface Grouping table, LinkProof can define which interfaces initiate interface grouping and which do not. In the Master Interface Grouping table, for each interface, you specify whether the interface initiates Interface Grouping if it goes down (interface’s Port Status is set to Included), or not.

Notes:>> If an interface, which is part of a VLAN, goes down and its Port Status is set to Included,

it does not initiate Interface Grouping.

>> When an interface, which has its Port Status set to Included, goes up after it goes down, Interface Grouping is turned off immediately, and the device regains control (becomes the main device). No reboot is required.

To configure the Master Interface Grouping Table

1. Select Redundancy > Master Interface Grouping Table. The Master Interface Grouping Table pane is displayed, which contains the following parameters:

Parameter DescriptionPort Number The port number (read only).

Port Status 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.

4. Click Set.

Backup Interface GroupingThe 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 device’s interfaces are up. When Backup Interface Grouping is not activated, the backup device takes control once one interface of the main device (defined in the Redundancy Table) is out of service. Respectively, the backup device releases the interface once all the interfaces of the main device are available.

To enable interface grouping and backup interface grouping


2. From the Interface Grouping drop-down list, select enable to allow the device to be backed up by another device.

Note: The backup device is activated only when all the interfaces of the main device fail. The main device resumes control only when all interfaces resume normal functioning.

3. From the Backup Interface Grouping drop-down list, select enable to activate the backup device when all the IP interfaces defined in the Redundancy Table fail.

4. Click Set.

Mirroring the Client TableLinkProof supports mirroring the Client table across an active device and a redundant, backup device.

When LinkProof mirrors the Client Table, the main device sends a snapshot of the table information contained on the main device to the backup device. If the main device fails, the backup device seamlessly continues handling each existing session, ensuring that each request for service is forwarded to the same server in the farm that handled the session before the failover.

Notes:>> Enabling mirroring has a negative impact on LinkProof performance. The degree of the

impact depends on the table sizes.

>> Radware recommends that you mirror the Client table with very state-sensitive and long-term sessions, such as Telnet or FTP.



>> You should not mirror the Client table with HTTP applications where sessions are short and a reload mechanism is built-in or transparent.

>> You should not mirror the Client table in conjunction with the Dynamic Session ID Tacking feature.

>> When enabling mirroring on a backup LinkProof device, the device must be reset.

>> When setting up mirroring, Radware recommends that you use the same LinkProof software version for the main and for the backup devices.

>> Radware recommends that you not configure mirroring in conjunction with Layer 7 features that require Delayed Bind. This includes Dynamic session ID Persistency, Layer 7 Policies, SSL ID tracking, and so on.

For effective and reliable mirroring, do the following:

• Provide a direct connection between the two devices. An IP interface must be configured on each device for the direct connection port and address used as the Mirroring Device Address for the other device.

• Exclude physical port used for inter-device communication from Interface grouping.

• Use a trunk (link aggregation) for direct connection between two devices.

• Mirroring parameters must be configured on the main device and on the backup device.

• The devices must be configured using VRRP. For more information, see Global Redundancy Configuration, page 267.

• The IP address must be defined on dedicated ports (not used for other proposes); and the IP addresses must not be a VRRP-associated IP address. For more information, see VRRP Associated IP Addresses, page 286.

Caution: Mirroring works differently depending on the specified Priority and Preemption Mode of the VRRP redundancy configuration (see Configuring Basic VRRP Redundancy, page 285). The device with the higher priority is the main device. The specified Preemption Mode affects the values you must choose when you configure mirroring. The following tables describe the required values for the main and backup devices according to whether Preemption Mode in the VRRP configuration is true or false.

Table 145: Required Values for Main and Backup Devices with VRRP Preempt Mode = True

Main Device Backup DeviceParameter Path Required

ValueParameter Path Required

ValueRedundancy > Mirroring > Active Device Parameters >Client Table Mirroring

enable (if you want the table to be mirrored)

Redundancy > Mirroring > Active Device Parameters >Client Table Mirroring

disable

Redundancy > Mirroring > Backup Device Parameters > Mirroring Status

disable Redundancy > Mirroring > Backup Device Parameters > Mirroring Status

enable



Configuring Mirroring on the Active Device

To configure the active-device mirroring parameters

1. Select Redundancy > Mirroring > Active Device Parameters. The Mirroring: Active Device Parameters pane is displayed.

2. Configure the parameter; and then, click Set.

Configuring Mirroring on the Backup Device

To configure backup-device mirroring parameters

1. Select Redundancy > Mirroring > Backup Device Parameters. The Mirroring: Backup Device Parameters pane is displayed.

2. From the Mirroring Status drop-down list, specify whether to enable or disable mirroring of the Client Table. Values: enable, disable. Default: disable.

3. Click Set.

Configuring the IP Address of the Mirrored Device

To configure the IP address of the mirrored device

1. Select Redundancy > Mirroring > Mirror Device Parameters. The Mirroring: Device Parameters pane is displayed.

2. Click Create. The Mirror Device Parameters Create pane is displayed.

Table 146: Required Values for Main and Backup Devices with VRRP Preempt Mode = False

Main Device Backup DeviceParameter Path Required

ValueParameter Path Required

ValueRedundancy > Mirroring > Active Device Parameters >Client Table Mirroring


Redundancy > Mirroring > Active Device Parameters >Client Table Mirroring


Redundancy > Mirroring > Backup Device Parameters > Mirroring Status

enable Redundancy > Mirroring > Backup Device Parameters > Mirroring Status

enable

Table 147: Active-Device Mirroring Parameters

Parameter DescriptionClient Table Mirroring Enables or disables the mirroring of the Client Table.


Default: disable



3. In the Mirror Device IP text box, type the IP address of the other device. That is, if you are configuring mirroring on the main device, type the IP address of the backup device here; and if you are configuring mirroring on the backup device, type the IP address of the main device here.

4. Click Set.

Proprietary ARP RedundancyThis section describes how a LinkProof device uses Address Resolution Protocol (ARP) to check the availability of its partner. The ARP method ensures that the LinkProof device is available and that the network connections between the devices are up.

The section contains the following topics:

• Proprietary ARP, page 274

• Backup Fake ARP, page 274

• Advanced Forwarding, page 276

Proprietary ARPWith the Proprietary method, the LinkProof device uses Address Resolution Protocol (ARP) to check the availability of the partner. The ARP method ensures that the LinkProof device is available and that the network connections between the devices are up.

If the main device fails, the backup device takes control and continues seamlessly operating between clients and servers that had been established on the primary device.

With Proprietary ARP redundancy, the backup device manages the polling process by continuously polling the main device, using the ARP protocol. When the main device fails, the teaching process is realized when the backup device sends broadcast ARPs informing its network neighbors that the IP addresses of the main device are now associated with its own MAC addresses. This ensures that all traffic destined to the IP addresses of the main device arrives at the backup device.

The following table describes the parameters that the backup uses to poll the main device.

Backup Fake ARPWhen two LinkProof devices are working in the redundant mode, the backup device constantly monitors the health of the main device. Once the backup device detects that the main device fails, the backup device takes control, which means that the backup device now owns the IP addresses of the main device. The backup device sends gratuitous ARP to all local stations informing that the main device IP addresses now correspond to the MAC addresses of the backup device. This process ensures smooth redundancy from the main device to the backup.

When the main device is operational again, it uses the same technique. The main sends gratuitous ARP to all local stations informing them that the main device IP addresses now correspond to the MAC addresses of the main device. To speed up this process, the backup device also publishes that the IP addresses of the main correspond to the MAC addresses of the main device. This is a fake

Table 148: Polling Parameters

Parameter DescriptionPolling Interval How often, in seconds, the backup device polls the main device.

Default: 3

Timeout The number of polling attempts that are made before the backup device takes over.

Default: 12



ARP, as one device (the backup) publishes the other device (the main). The fake ARP might confuse some Layer 3 switches, as they update their ARP Tables by the source MAC of the packet, rather than by the MAC in the information part of the packet.

The Backup Fake ARP option is enabled by default and can be disabled if needed.

Backup Device in VLANTo avoid broadcast storms, using redundancy with bridging, the backup device must remain completely silent on the network. This behavior must be set using the Backup Device in VLAN parameter.

To enable backup fake ARP and the backup device in a VLAN, enable the Backup Fake ARP and Backup-In-Vlan parameters in the procedure in Global Redundancy Configuration, page 267.

Example Proprietary Redundancy with RoutingThe following diagram shows a scheme for a proprietary redundancy configuration with routing.

Figure 30: Proprietary Redundancy with Routing

Interface 2

100.1.1.10

Router 1 Router 2100.1.1.20 200.1.1.20

100.1.1.11

Interface 2

Interface 1 Interface 110.1.1.10 10.1.1.11

10.1.1.xLocal Network

200.1.1.10200.1.1.11



Example Proprietary redundancy with bridgingThe following diagram illustrates the scheme for proprietary redundancy with bridging.

The network side and server side are on the same IP subnet.

Figure 31: Proprietary Redundancy with Bridging

Advanced ForwardingThe LinkProof routing mechanism includes a table called IP Fast Forwarding Table (IPFFT). IPFFT includes routing information for the purpose of saving CPU time while calculating routing decisions.

A large IPFFT (over 100,000 entries) or IPFFT that overflows due to lots of traffic needs to be routed. IPFFT use may impair the overall performance of the LinkProof device.

The Advanced Forwarding feature uses a more efficient algorithm in the IPFFT that can keep it the IPFFT small.

The IPFFT is cleared at the following times:

• When the device restarts

• When the relevant physical port is disconnected

• When you enter the following CLI command:net route fast-forwarding-table clear

LinkProof 2LinkProof 1

100.1.1.11

Interface 2200.1.1.10

Router 1 Router 2100.1.1.20 200.1.1.20

200.1.1.11

Interface 2

Interface 1 Interface 1100.1.1.10

100.1.1.xLocal Network



To configure advanced forwarding using Web Based Management


2. From the ARP Proxy drop-down list, select enable or disable to specify whether the device responds to ARP requests for nodes located on a different direct sub-net. The device responds with its own MAC address.

Values:

— enable—The device responds to all ARP requests.

— disable—The device responds only to ARP requests for its own IP addresses.

Default: disable

3. From the Advanced Fast Forwarding Status drop-down list, select Enable or Disable.

4. Click Set.

To configure advanced forwarding using CLI

Enter the following command:net route advanced-forwarding set <disable|enable>

VRRP RedundancyThis section describes redundancy in LinkProof using Virtual Router Redundancy Protocol (VRRP).


• Introducing VRRP, page 277

• VRRP Associated IP Addresses, page 286

• Direct Server Connection with VRRP, page 283

• Configuring Basic VRRP Redundancy, page 285

Introducing VRRPVRRP, 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 network—much like a physical router.

You can configure multiple LinkProof devices can be configured to achieve a full redundancy scheme between any number of devices (N×N 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 (Associated IP addresses). Each VR ID must be unique for the system, even if the IDs relate to different interfaces. If two LinkProof devices belong to the same subnet, and each device is backed up by a VR, the VR IDs for both devices must also be different.

Notes:>> LinkProof uses the term Associated IP to refer to the IP address associated with the

interface index and the VR ID. Other vendors may refer to the Associated IP as a virtual IP (VIP) or a floating IP, because it floats between the primary and standby devices—being used by whichever device takes ownership of the configuration.

>> Each VR has a VRMAC address, which is a MAC address associated with the VR. The VRMAC address eliminates the need for a MAC-address update in case of a fail-over. The VRMAC address is determined by the VR ID. You do not need to configure the VR MAC address manually.

>> VRRP is not supported in a Regular VLAN network configuration—except for configurations using Direct Server Connection. For more information, see Direct Server Connection with VRRP, page 283.

>> When working with a VRRP configuration, Radware strongly recommends that you enable Interface Grouping. You associate the interfaces that are used by the redundant configuration to the relevant group.

Caution: Interface grouping (see Interface Grouping, page 269) is disabled by default, but, when interface grouping is enabled:

>> By default, all of the device interfaces are included in the Master Interface Grouping, and if any of the interfaces in the group fails, the entire device is declared down and the VR fails over (master switches to backup).

>> If the status of a certain VR ID is Disabled, then either all VR IDs on that device are disabled too, or all copies of that VR ID on other devices are disabled as well.

>> If, on a certain interface, a LinkProof device has IP addresses that belong to a subnet whose backup device is not on that interface, you must configure the LinkProof device with a primary IP address that belongs to a subnet that the backup device has.

>> Upon creating a VR on a port, there must be at least one IP interface configured on the physical port.

>> Ensure that the same parameters are configured on both devices for each VR ID.

Example Redundant LinkProof Configuration with VRRP—VR IP Address Uses the IP Address of One of the Physical Interfaces of the Primary DeviceThis example configuration delivers a fully redundant solution—both 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 32 - Redundant LinkProof Configuration with VRRP—VR IP Address Uses the IP Address of One of the Physical Interfaces of the Primary Device, page 279 shows the example configuration. Figure 33 - Configuration of Redundant LinkProof Devices with VRRP—VR IP Address Uses the IP Address of One of the Physical Interfaces of the Primary Device, page 280 describes the flow of the configuration procedure.

Figure 32: Redundant LinkProof Configuration with VRRP—VR IP Address Uses the IP Address of One of the Physical Interfaces of the Primary Device

LinkProof 01 Primary

Internet

External Segment

Internal Segment

192.168.10.10 192.168.10.11

172.16.24.11172.16.24.10

External Router 01 External Router 02

Users

LinkProof 02 Secondary

Virtual Router192.168.10.10




Figure 33: Configuration of Redundant LinkProof Devices with VRRP—VR IP Address Uses the IP Address of One of the Physical Interfaces of the Primary Device

Enable VRRP

Create a VR withState = Down

Using NAT?

Create Associated IP address for VR

More VRs to configure?

Create Associated IP address for the

NAT address

Requirepinging the VR IP or

have a VDNS?

Create a Remote VIP or VDNS IP

Check failover configuration

Alternatively, you can:1) Create VRs2) Create associated IP addresses3) Up all VRs

Configuring the primary device

Set VR priority = 255

Change VR state = Up

Set VR priority less than 255 (for example, 100)

Create associated IP addresses for the

VIP or VDNS

Yes

No

Yes

No

Yes

No

No

Yes

Configure the following on each device: Interfaces IP Addresses Routing Farm and flows NAT



Example Redundant LinkProof Configuration with VRRP—VR IP Address Uses an IP Address Different from the Physical Interfaces of the Primary DeviceThis example configuration delivers a fully redundant solution—both for outbound and inbound connections. Assume two LinkProof devices. One device acts as the primary. The other device acts as the secondary. The VR IP address uses an IP address different from the IP addresses of the physical interfaces of the primary device.

Figure 34 - Redundant LinkProof Configuration with VRRP—VR IP Address Uses an IP Address Different from the Physical Interfaces of the Primary Device, page 281 shows the example configuration. Figure 33 - Configuration of Redundant LinkProof Devices with VRRP—VR IP Address Uses the IP Address of One of the Physical Interfaces of the Primary Device, page 280 describes the flow of the configuration procedure.

Figure 34: Redundant LinkProof Configuration with VRRP—VR IP Address Uses an IP Address Different from the Physical Interfaces of the Primary Device

LinkProof 01 Primary

Internet

External Segment

Internal Segment

192.168.10.10 192.168.10.11

172.16.24.11172.16.24.10

External Router 01 External Router 02

Users

LinkProof 02 Secondary





Figure 35: Configuration of Redundant LinkProof Devices with VRRP—VR IP Address Uses an IP Address Different from the Physical Interfaces of the Primary Device

Enable VRRP

Create a VR withState = Down

Using NAT?

Create Associated IP address for VR

More VRs to configure?

Create Associated IP address for the

NAT address

Requirepinging the VR IP or

have a VDNS?

Create a Remote VIP or VDNS IP

Check failover configuration

Alternatively, you can:1) Create VRs2) Create associated IP addresses3) Up all VRs

Configuring the primary device?

Set VR priority = 200

Change VR state = Up

Set VR priority less than 200 (for example, 100)

Create associated IP addresses for the

VIP or VDNS

Yes

No

Yes

No

Yes

No

No

Yes

Configure the following on each device:Π InterfacesΠ IP AddressesΠRoutingΠFarm and flowsΠNAT



Direct Server Connection with VRRPVRRP with Switched IP VLAN allows direct connection of servers to LinkProof in conjunction with routing and bridging. In this configuration, servers with dual network interface controllers (NICs) are directly connected to LinkProof devices. LinkProof uses routing (see Figure 36 - Direct Server Connection with VRRP and Routing, page 284) or bridging (see Figure 37 - Redundant LinkProof Configuration with VRRP and Direct Connection, page 285) between the external network connected to routers or switches, and the internal network connected to servers. Servers are connected directly to the interfaces of LinkProof. A cross cable is required to connect the two LinkProof devices together (using Giga, or Fast Ethernet ports).

The interfaces to which the servers are connected and the interface used for connecting the two LinkProof devices, are associated to a Switched IP VLAN. This puts all the servers on a single switch.

Using bridging, you need to configure a Regular VLAN including the switch IP VLAN and the LinkProof interface to the external side. This creates a bridge between the Switched VLAN and the interface to the external side. When needed, multiple LinkProof interfaces can be added to this Regular VLAN.

Using routing with Layer 2 or Layer 3 switches, either connecting LinkProof and servers or connecting LinkProof to the external subnet, you must avoid configuration that contains a loop. For example, having a cross cable between the switches as well as between LinkProof devices, or connecting each LinkProof to two (2) cross-connected switches where the two (2) connections are on the same Switched IP VLAN on LinkProof, must be avoided.

The configuration properties of the examples shown in Figure 36 - Direct Server Connection with VRRP and Routing, page 284 and Figure 37 - Redundant LinkProof Configuration with VRRP and Direct Connection, page 285 are as follows:

• Direct Server Connection with Routing is supported with VRRP and Switched IP VLAN only.

• Firewalls are connected directly to the interfaces of LinkProof. Cross cables are required in order to connect the two LinkProof devices together (using Giga, or Fast Ethernet ports).

• The interfaces to which the firewalls are connected to and the interface used for connecting the two LinkProof devices are associated to a Switched IP VLAN. This puts all the firewalls on a single switch. An IP address (from the blue subnet) should be associated with the Switched IP VLAN in each device.

• The LinkProof configuration and redundancy configuration does not change from the regular setup.

• The default gateway of firewalls and routers is the IP address of the respective Switched IP VLAN of the active LinkProof.

Note: When using dual NICs, where the active NIC is determined by pinging the default gateway, set a virtual DNS with IP 10.1.1.20 on the LinkProof device. This IP should be the default gateway of the servers. In the Associated IP Addresses Table pane, configure the following entries: Interface=100002, VRID=10, Associated IP=10.1.1.20.

• LinkProof is using routing between the blue subnet (of the firewalls) and the orange (routers) subnet. This is essential in order to avoid loops in the network.

• When adding or removing ports to a Switch IP VLAN that is already associated to a VRID, you must set the VR ID Admin Status to Down, make the change and then set the VR ID Admin Status to Up again.



Figure 36: Direct Server Connection with VRRP and Routing

Interface Grouping Used with Direct ConnectionTo support redundant configuration with direct server connectivity, the interface grouping operation is modified. Interface grouping is always part of the LinkProof redundancy mechanism. Enabling interface grouping on the main device ensures that if one of the interfaces of the device fails, the device closes all its other interfaces and becomes invisible to the network.

Using switched VLAN, the grouping takes place only when all interfaces that were configured in a switched VLAN are down. Interface grouping is released when the all interfaces in a switched VLAN are up.

Using Switched VLAN as part of a Regular VLAN, grouping takes place only when all interfaces in a Switched VLAN are down, or when any other port in the Regular VLAN is down. Interface grouping is released when all interfaces in a switched VLAN are up and when all other ports in the Regular VLAN are up.

Example Redundant LinkProof Configuration with VRRP and Direct Connection

The following diagram, Figure 37 - Redundant LinkProof Configuration with VRRP and Direct Connection, page 285, illustrates the scheme for a redundant LinkProof configuration with VRRP and direct connection. VRRP with Switched IP VLAN allows direct connection of servers to LinkProof.

Figure 37 - Redundant LinkProof Configuration with VRRP and Direct Connection, page 285 configuration properties:

• Firewalls are directly connected to LinkProof, possibly with dual NIC.

• Each router is connected directly to a different LinkProof and they are inter-connected as well (subnet 30.1.1.x). Route towards the other router should be configured on each router.

• Network side and server side are on different subnets.

• The virtual IP addresses served by the LinkProof devices are 100.1.1.100 and 200.1.1.100 usually handled by LinkProof 1.

• Firewalls 10.1.1.1 and 10.1.1.2 are assigned to the farm managed by LinkProof 1.

• Redundancy is performed using the VRRP protocol.

Routers

Switch IP VLAN 2 on LinkProof-L

Switch IP VLAN 2 on LinkProof-R

Switch IP VLAN 1 on LinkProof-L

Switch IP VLAN 1 on LinkProof-R



Figure 37: Redundant LinkProof Configuration with VRRP and Direct Connection

Configuring Basic VRRP Redundancy

Caution: For mirroring, Radware strongly recommends that you use a dedicated management port to prevent packet loss while under stress. For more information on mirroring, see Mirroring the Client Table, page 271.

To enable redundancy with VRRP


2. From the IP Redundancy Admin Status drop-down list, choose VRRP.

3. Click Set.

To configure basic VRRP redundancy

4. Select Redundancy > VRRP > VR Table. The Virtual Router Table pane is displayed.

5. Click Create. The Virtual Router Table Create pane is displayed.


Router 1

Firewall 110.1.1.1

Regular 100.1.1.100 Backup200.1.1.100

Firewall 210.1.1.2

Port 2

Port 4Port 3

Port 2

Switched IP VLAN10.1.1.10

Switched IP VLAN10.1.1.11

Port 4

Dual NIC

Router 2

Port 5 Port 5

Port 1 Port 1

Switched IP VLAN100.1.1.10200.1.1.10

Switched IP VLAN100.1.1.11200.1.1.11

30.1.1.1 30.1.1.2

200.1.1.20

100.1.1.20



VRRP Associated IP AddressesThe Associated IP is the IP address associated with the interface index and the VR ID. An Associated IP is used in NAT configurations. Other vendors may refer to the Associated IP as a virtual IP (VIP)

Table 149: Virtual Router Parameters

Parameter DescriptionIf Index The interface identifier.

Values:

• The traffic ports (not MNG ports) on the device

• 100001

VR ID The virtual routers identification number.

Values: 1–255

Admin Status The status of the port.

Values: Up, Down

Priority Priority is defined with the values 1–255, where the highest priority of 255 should be assigned to the primary VR.

Values: 1–255

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.

Authentication Type The type of authentication.

Values: No Authentication, Text Authentication

Authentication Key Password, up to eight (8) characters.

Advertise Interval The interval, in seconds, at which packets are checked.

Default: 1

Preemption Mode 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:

• True—The device with the higher priority takes over the VR.

• False—The device with the lower priority maintains control of the VR. This mode is only applicable when more than two devices share a VR.

Default: True

Note: The exception to the above description is that the router that owns the IP address(es) associated with the virtual router always preempts, independent of the setting of this flag.

Protocol The protocol. For LinkProof, this is IP. Value: IP



or a floating IP, because it floats between the primary and standby devices—being 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.


Remote Virtual IP AddressesA remote virtual IP address (remote VIP) is a virtual IP address used by a VRRP redundant configuration to provide additional functionality to the VRRP configuration. Typically, you use a remote VIP when the VRRP configuration (the VIP address) needs to be accessed from the external network.

Typical advantages of remote VIP:

• Being able to ping the VIP

• Checking the VIP availability by third-party devices

• Virtual DNS (VDNS), which you can configure also from the VDNS table (LinkProof > DNS Configuration > DNS Virtual IP).

Note: The functionality of Remote VIP and DNS VIP are identical. If you have configured DNS VIP, there is no need to configure a remote VIP. DNS VIP is used mainly when LinkProof provides redundant DNS functionality.

In redundant configurations, you need to configure a remote virtual IP address where the regular (main) and backup device provide functionality and access to a service on the same specific IP address.

A remote VIP is used as a virtual router IP address on top of the original Associated IP that represents the devices’ VRRP configuration. The remote virtual IP address needs to be associated with one physical interface on the device. You configure the same remote virtual IP address on both devices.

Table 150: Associated IP Addresses Parameters

Parameter DescriptionIf Index The interface identifier.

Values:

• The traffic ports (not MNG ports) on the device

• 100001

VR ID The identification number of the virtual router.

Values: 1–255

Associated IP The IP address associated with the interface index and the VR ID.



Example Remote Connectivity ChecksIn a redundant configuration, configure remote connectivity checks using a remote virtual IP.

Connectivity checks are typically performed by a ping sent from the LinkProof device and a network element, such as a firewall. In this setup, the internal LinkProof can use a remote connectivity check to check the connectivity between the firewalls to the external LinkProof. This connectivity check is typically performed by a ping sent from the internal to the external device, or vice versa.

In a redundant configuration, when the main device is active, the backup device answers ARPs with the IP address of the main device. However, so as not to create network problems, the backup device does not respond to pings or SNMP requests in the same way. If the main device fails, the backup device does not answer remote connectivity checks. A remote virtual IP can solve this problem.

The remote virtual IP is always online. Usually, the main device owns the remote virtual IP. The backup device takes ownership when the main device fails.

To enable redundancy with VRRP


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.


Table 151: Remote Virtual IP Address Parameters

Parameter DescriptionRemote Virtual IP Specifies the remote virtual IP address.

Redundancy Mode Specifies the redundancy mode of the current device.

Values:

• regular—For the active device

• backup—For the backup device

Default: regular


Chapter 7 – SecurityThis chapter provides a general overview of the Security modules and sub-modules that LinkProof supports.


• Security Introduction, page 289

• Update Security Policies, page 290

• Configuring Access for Physical Ports, page 290

• SNMP, page 291

Security IntroductionThis section contains the following topics:

• SYN Floods

• TCP-Handshake-Timeout

Note: Some Security features are displayed in the user interface but are currently non-operational and reserved for future use.

Radware’s LinkProof Security module performs deep packet inspection at multi-Gigabit speed to provide security from the network layer up to the application layer, protecting against viruses, worms, DoS attacks and intrusions, and anomalies.

LinkProof provides secure Internet connectivity with high performance, maintaining legitimate user traffic with advanced mitigation tools that focus on SYN Flood attacks.

Some features of the Security module are available only with the Security license.

SYN FloodsA SYN flood is a form of denial-of-service attack in which an attacker sends a succession of SYN requests to a target’s system followed by no follow-up packets.

LinkProof provides protection against any type of SYN-flood attack, irrespective of the tools that are used to launch the attack. This protection service utilizes a mechanism called SYN Cookies, which performs delayed binding (terminates TCP sessions) and inserts a certain signature into the TCP sequence field.

SYN Flood Protection is a service intended to protect the hosts located behind the device and the device itself from SYN flood attacks by performing delayed binding.

The SYN Flood attack is performed by sending a SYN packet without completing the TCP three-way handshake. Another type of SYN Flood attack is done by completing the TCP three-way handshake, but no data packets are sent afterwords. Radware provides complete protection against both types of SYN Flood attacks.

After the completion of the three-way handshake, LinkProof only processes requests that include the signature that was inserted previously. This mechanism guarantees that only legitimate requests are sent to the servers, while half open TCP connections, aimed to consume servers’ resources, are terminated by the LinkProof and do not flood the servers, as well as the LinkProof itself.

The attacks are detected and blocked by means of SYN Flood Protection Policies. The reports regarding the current attacks appear in the Active Triggers table.

LinkProof User Guide Security


TCP-Handshake-TimeoutThe Timeout for SYN option enables the protection of the Client Table against SYN attacks that occur during the TCP handshake process.

When a client sends SYN to the Layer 4 Policy, LinkProof selects a server, adds a new entry to the Client Table, and forwards SYN to the selected server. If, during a predefined period of time (which can last for 1 to 10 seconds), no additional response arrives from this client, it is regarded as a SYN attack. The entry is then deleted from the Client Table and a reset command is sent to the server, releasing the resources allocated to this session.

Note: The Timeout for SYN parameter is applicable only when the Open Entry When Source Port Different or the Select New Server When Source Port Different parameters are enabled. The Timeout for SYN parameter applies only to TCP sessions.

You can enter the value, in seconds, that LinkProof assigns to a new session started by a SYN packet. This value applies when no further traffic is received from the client. Then, the entry is removed from the Client Table and a reset is sent to the server.

Update Security PoliciesUse the Activate the latest changes pane to activate the inactive policies.

To activate inactive policies

1. Select Security > Update Policies. The Activate the latest changes pane is displayed.

2. Click Set.

Configuring Access for Physical PortsAccess 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. Select Security > Management Ports. The Management Ports Table pane is displayed.

2. Select a port. The Management Ports Table Update pane is displayed.


LinkProof User GuideSecurity


SNMPThe 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.


• SNMP Global Parameters, page 292

• SNMP User Table, page 292

• SNMP Community Table, page 293

• SNMP Groups Table, page 293

• SNMP Access Table, page 294

• SNMP View Table, page 294

• SNMP Notify Table, page 295

• Target Parameters Table, page 295

• Target Address Table, page 296

• Creating an SNMP User, page 297

Table 152: Management Port Parameters

Parameter DescriptionPort Number Displays the ID number of each physical port.

SNMP Displays access permission for SNMP configuration for each management port.


Default: Enabled

Telnet Displays access permission for Telnet configuration for each management port.


Default: Enabled

SSH Displays the access permission for SSH configuration for each management port.


SSL Displays the access permission for SSL configuration for each management port.


Default: Enabled

Web Displays access permission for Web Based configuration for each management port.


Default: Enabled



SNMP Global Parameters

To set the SNMP Global parameters

1. Select Security > SNMP > Global Parameters. The SNMP Global Parameters pane is displayed.


SNMP User TableYou 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. Select Security > SNMP > User Table. The User Table pane is displayed.

2. Click Create. The User Table Create pane is displayed.


Table 153: SNMP Global Parameters

Parameter DescriptionSupported SNMP Versions After Reset

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.

SNMP Port UDP port on which the agent is listening for SNMP requests.

SNMP Status Status of the SNMP agent.

Default: Enable

Table 154: SNMP User Parameters

Parameter DescriptionUser Name Type name of the new user, up to 18 characters.

Authentication Protocol

Type protocol to be used during authentication process. Default: None, meaning using clear text during the session.

Values: MD5, SHA

Authentication Password

Enter an authentication password.

Privacy Protocol Algorithm to be used for encryption.

Values:

• DES

• None—The data is not encrypted.

Default: None

Privacy Password Enter a user privacy password.



SNMP Community TableYou can map community strings into user names and vice versa using the SNMP Community Table pane. This table restricts the range of addresses from which SNMP requests are accepted and to which traps may be sent. The SNMP Community Table is used only for SNMP versions 1 and 2.

To configure the SNMP Community Table

1. Select Security > SNMP > Community Table. The SNMP Community Table pane is displayed.

2. Click Create. The SNMP Community Table Create pane is displayed.


SNMP Groups TableYou 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.


Table 155: SNMP Community Parameters

Parameter DescriptionIndex A descriptive name for this entry.

Community Name The community string.

Security Name User name associated with community string.

Transport Tag Specifies a set of target addresses from which the SNMP accepts SNMP requests and to which traps 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.”

Table 156: SNMP Group Parameters

Parameter DescriptionSecurity Model Select SNMP version for association with this group.

Values: SNMPv1, SNMPv2, UserBased (SNMPv3)

Security Name Select relevant security name, that is the name as defined in the Users Table.

Group Name Select name from list of all available group names.



SNMP Access TableYou can define the access rights for each group and security model in the Access Table pane.

To configure the SNMP Access Table

1. Select Security > SNMP > Access Table. The Access Table pane is displayed.

2. Click Create. The Access Table Create pane is displayed.


SNMP View TableUse 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. Select Security > SNMP > View Table. The View Table pane is displayed.

2. Click Create. The SNMP View Table Create pane is displayed.


Table 157: SNMP Access Parameters

Parameter DescriptionGroup Name The name of your group.

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: SNMPv1, SNMPv2, UserBased (SNMPv3)

Default: SNMPv1

Security Level The relevant Security Levels.

Values:

• NoAuthNoPriv—No authentication or privacy are required.

• AuthNoPriv—Authentication is required, but Privacy is not required.

• AuthPriv—Both authentication and privacy are required.

Default: NoAuthNoPriv

ReadView Name Name of one or more entries in View Tree Family Table. Specifies which objects in the MIB tree are readable by this group.

WriteView Name Name of one or more entries in View Tree Family Table. Specifies which objects in the MIB tree are writable by this group.

NotifyView Name Name of one or more entries in View Tree Family Table. Specifies which objects in the MIB tree can be accessed in notifications (traps) by this group.



SNMP Notify TableUse 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.


Target Parameters TableUse 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.


Table 158: SNMP View Parameters

Parameter DescriptionView Name Name of this entry.

Subtree Object ID of a subtree of the MIB.

Subtree Mask Subtree mask of the MIB.

Type Defines whether an object defined in this entry should be included or excluded in the MIB view.

Values: included, excluded

Default: included

Table 159: SNMP Notify Parameters

Parameter DescriptionName A descriptive name for this entry.

Tag 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 Address TableIn 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. Select Security > SNMP > Target Address Table. The Target Address Table pane is displayed.

2. Click Create. The Target Address Table Create pane is displayed.


Table 160: Target Parameters

Parameter DescriptionName Name of this entry.

Message Processing 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 The name of the user.

Security Level The relevant Security Level.

Values:

• NoAuthNoPriv—No authentication or privacy is required.

• AuthNoPriv—Authentication is required, but Privacy is not required.

• AuthPriv—Both authentication and privacy are required.

Default: NoAuthNoPriv



Creating an SNMP UserUse 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.


3. Click Create User. The new SNMP user is created.

Table 161: Target Address Parameters

Parameter DescriptionName 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 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.

Parameters Name of the entry in the Parameters Table to be used when sending the SNMP Traps.

Mask The mask address of the subnet.

Default: 0.0.0.0

Parameter DescriptionSNMP Version Values: SNMPv3, SNMPv1, SNMPv2c

User/Community Name User name or community string name.

Use Authentication Specifies whether SNMPv3 authentication is used.

Authentication Password The Authentication password.

Use Privacy Specifies whether SNMPv3 privacy is used.

Privacy Password The Privacy password.

Read View Values: iso, ReadOnly View

Default: iso

Write View Values: None, iso, ReadOnlyView

Default: None

Notify View Values: None, iso, ReadOnlyView

Default: None



Ping Physical PortsUse 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. Select Security > Ping Physical Ports. The Ping Ports Table pane is displayed.

2. Select the link in the relevant row of the table. The Ping Ports Table Update pane is displayed.

3. In the Ping Device field, select Enabled or Disabled.

4. Click Set.

Configuring the Users Table and Authentication MethodYou 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 MethodBefore configuring the user table, configure the authentication method.

To configure the method of authenticating user access

1. Select Security > Users. The User Table and Authentication pane is displayed.

2. From the Authentication Method drop-down list, select the method of authenticating a user’s access to the device. The following methods are supported:

— Local User Table—The device uses the User Table to authenticate access.

— RADIUS and Local User Table—The 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.



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.


SYN ProtectionSYN 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.

Table 162: User Table and Authentication Parameters

Parameter DescriptionUser Name The name of the user. The value must be less than 20 characters long.

Password The text password for this user. The value must be less than 20 characters long.

Email Address The e-mail address for this user. The value must be less than 20 characters long.

Severity The level of warning required by the user.

Values:

• Fatal—LinkProof sends only Fatal messages to the user.

• Error—LinkProof sends Fatal and Error messages to the user.

• Warning—LinkProof sends Fatal, Error and Warning messages to the user.

• Info—LinkProof sends Fatal, Error, Warning, and Info messages to the user.

• None—LinkProof 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 Global ParametersSYN Flood Protection is intended to protect the hosts located behind the device and the device itself from SYN flood attacks by performing delayed binding. A SYN flood attack is a denial of service attack where the attacker sends a huge number of please-start-a-connection packets and then no follow up packets.

The SYN Flood attack is performed by sending a SYN packet without completing the TCP three-way handshake. Another type of SYN Flood attack is done by completing the TCP three-way handshake, but no data packets are sent afterwards. Radware provides complete protection against both types of SYN Flood attacks. The attacks are detected and blocked by means of SYN Flood Protection Policies. The reports regarding the current attacks appear in the Active Triggers table.

To enable SYN Flood protection

1. Select Security > SYN Protection > Global Parameters. The SYN Flood Protection Parameters pane is displayed.


Table 163: SYN Flood Protection Parameters

Parameter DescriptionSYN Protection Status Specifies the status of SYN Flood Protection feature.

Values:

• enable—Activates the SYN Flood Protection module.

• disable—Deactivates the SYN Flood Protection module.

• standby—Activates the SYN Flood Protection module without rebooting the device.

Default: disable

TCP Handshake Timeout Specifies the timeout, in seconds, to complete the TCP three-way handshake.

Values:

• 0—Specifies no timeout.

• 1–10

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:

• 0—Specifies no timeout.

• 1–10

Default value: 5



SYN Flood Protection PoliciesOnce 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.

SYN ACK Reflection Protection Mode

Specifies the mode or status of the SYN-ACK Reflection Attack Prevention mechanism.

Values:

• enable—Enables the prevention mode.

• reportOnly—Enables the report-only mode (no prevention).

• disable—Disables 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: 0–10000

Default: 100

SYN ACK Reflection Maximum SYN Cookies per Source

Specifies the threshold representing the maximum number of uncompleted TCP sessions per source IP per second, to be answered. Any session exceeding this frequency will be ignored.

Values: 1–100,000

Default: 1000

Statistics max destinations per policy

Specifies the maximum number of destinations that can be reflected in the statistics report.

Values: 1–100

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: 1–100

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:

• 0—Specifies that no report is available.

• 1–100

Default: 50

Table 163: SYN Flood Protection Parameters





SYN Flood StatisticsTo 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.

Table 164: SYN Protection Policy Parameters


Index Location of policy in the protection table that reflects the order in which the classification is performed.

Protection Mode Includes a dropdown menu with the following options:

• Enabled—Activates SYN Cookies for all sessions.

• Triggered—Activates SYN Cookies only when SYN attack is identified.

• Disabled—Never use SYN Cookies.

Operational Status Active or Inactive.

Activation Threshold 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

Verification Type Define the process of completing the TCP session.

Description A free text describing the policy.

Deactivation Threshold 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

Ack Session is completed when the Ack packet arrives (following a SYN/SYN-ACK packets exchange).

Request Session is completed when the first data request packet arrives (following a SYN/SYN-ACK packets exchange).

Destination Destination address of packet matched by policy.

Physical Port Group A user-defined physical port group or aggregated Link for SYN flood protection.

Count Statistics Specifies whether the device counts the statistics for the destinations defined in this policy.

Service Basic filter of protected application destination port.



To define which policies are displayed

1. Select Security > SYN Protection > Statistics. The SYN Protection Statistics pane is displayed.

2. From the Displaying Statistics of Policy drop-down list, select the policy for which to display statistics. To display statistical data for all policies, leave the field empty.

3. Click Set.

To access the SYN statistics

Select Security > SYN Protection > Statistics. The SYN Protection Statistics pane is displayed.

For each policy, the following data is displayed:

To update the statistics

1. Select Security > SYN Protection > Statistics. The SYN Protection Statistics pane is displayed.

2. Under Reset SYN protection Statistics, click Set.

Parameter DescriptionPolicy Name Name of policy whose traffic data is collected and analyzed.

Dest IP A specific destination IP included in the policy.

Dest Port A specific destination port included in the policy.

SYNs/Sec Peak Highest value of SYNs per second during the statistical analysis period.

Attack Status Current status of attack.

Values:

• Protected (Under Attack)

• Protected (No Attack)

• Monitoring (No Attack)

• Not Protected



Active TriggersYou 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:

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.

CertificatesCertificates 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 certificate’s serial number

• The certificate holders expiry date

• A copy of the certificate holder’s public key

• The identity of the certificate authority (CA) and its digital signature to affirm the digital certificate was issued by a valid agency

Parameter DescriptionType The type of the identified attack.

Ip Address Source IP for SYN ACK Reflection, and dest ip for all other types.

Last Sec SYN Number of SYN Flood attacks recognized in last second.

Last Sec Verified Number of ACKs recognized in the last second.

Total SYN Total number of SYN packets for this trigger.

Total Dropped sess. Total number of unverified sessions for this trigger.

Active Time (Secs) Number of seconds since the attack began.



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 lengths—512, 1024, or 2048 bytes.

ConfigurationKeys 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 WorkflowsThis 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.



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. Create a Certificate and select Certificate.

2. Complete the relevant fields (or update the defaults before you start).

3. 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. 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.

2. 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).

3. On the second LinkProof machine, go to the Import PKI Components To Device (see Export Certificates from a Device) and select an Import Key.

4. On the second LinkProof machine, go to the Import PKI Components To Device (see Export Certificates from a Device) and import a Certificate.

To use an intermediate CA for a signed certificate

1. Select Security> Certificates > Import. The Import PKI Components To Device pane is displayed.


Parameter DescriptionEntry Name Input new entry name to create by import, or existing entry name

to overwrite or complete Key or CSR.

Entry Type Values:

• Key—Import key from backup or exported from another machine. To complete the configuration, you will need to import a certificate into this key.

• Certificate—Import Certificate from backup or exported from another machine. The Certificate must be imported onto a matching key or CSR.

• Certificate Chain—Import a certificate to be used in the SSL policy.

• Client CA Certificate—Import a certificate to be used in the Client Authentication policy Client CA Certificate field.

Note: Maximum character length is 50.



3. Click Import. The certificate is imported.

Caution: All Certificate operations where keys are exposed should be allowed only on a secure connection.

Certificates TableThis 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.


— To update, click the certificate name. The Certificate Table Update pane is displayed.

— To create a new certificate, click Create. The Certificate Table Create pane is displayed.


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.

Text In this area, you can paste the Certificate in encrypted text format.

Certificate File The filepath of the certificate file to import.

Table 165: Certificate Parameters

Parameter DescriptionName Name of Key or Certificate.

Entry Type 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.




Note: You can set the default values for the Certificate and CSR fields. For more information, see Default Values for Certificates, page 309.

Export Certificates from a DeviceKey, 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. Select Security > Certificates > Export. The Export PKI Components From Device pane is displayed, showing key, certificate, or CSR.

2. To display an existing key, certificate, or CSR with all parameters, click Show. The following certificate details are displayed:

Key Passphrase Encrypts the key in storage and is required to export the key from LinkProof.

Common Name The domain name of the organization. For example, www.radware.com

Certificate/Certificate Signing Request (CSR) Details

Locality Name of the city.

State Or Province State or province.

Organization Name of the organization.

Organization Unit Department/Unit within the organization.

Country Name Organization country.

Email Any e-mail address that you want to include within the certificate.

Certificate Validity The number of days the certificate will remain valid.

Parameter DescriptionEntry Name The name of the entry to export.

Entry Type 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.

Text Displays the Key/Certificate/CSR text in text format for you to copy-paste it, when you use the Show option.

Table 165: Certificate Parameters




3. Choose Show or Export. Click Show to display Key/Certificate/CSR in encrypted text format for copy-paste purposes, for example, sending CSR to a certificate signing authority.

4. A dialog message is displayed asking if you want to open or save the certificate file. If you click Open, the file opens in a browser window. If you click Save, you are prompted to save the file.

Import Certificates to a DeviceThis 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.


3. Click Import. The certificate is imported.

Caution: All certificate operations where keys are exposed should be allowed only on a secure connection.

Default Values for CertificatesYou need to configure the parameters to be used when creating CSR or self-signed certificates in your organization.

Parameter DescriptionEntry Name Input new entry name to create by import, or existing entry name to

overwrite or complete Key or CSR.

Entry Type Values:

• Key—Import key from backup or exported from another machine. To complete the configuration, you will need to import a certificate into this key.

• Certificate—Import Certificate from backup or exported from another machine. The Certificate must be imported onto a matching key or CSR.

• Certificate Chain—Import a certificate to be used in the SSL policy.

• Client CA Certificate—Import 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.

Text In this area, you can paste the Certificate in encrypted text format.

Certificate File The filepath of the certificate file to import.



To configure default values for certificates

1. Select Security > Certificates > Default values. The Certificate Default Values pane is displayed.


Table 166: Certificate Default Values Parameters

Parameter DescriptionCertificate Common The domain name of the organization. For example,

www.radware.com.

Certificate Locality The name of the city.

Certificate State or Province The state or province.

Certificate Organization The name of the organization.

Certificate Organization Unit The department or unit within the organization.

Certificate Country Name The organization country.

Certificate Email Any e-mail address that you want to include within the certificate.


Chapter 8 – Bandwidth ManagementThis chapter describes the Bandwidth Management module.


• Bandwidth Management Overview, page 311

• Managing Bandwidth Management Global Parameters, page 313

• Bandwidth Management Policies, page 315

• Services, page 328

• Networks, page 338

• Port Groups, page 339

• Application Port Groups, page 340

• VLAN Tag Groups, page 341

• Discrete Networks, page 344

• Protocol Discovery, page 347

• Port Bandwidth, page 350

• Cancelling Interface Classification, page 350

• Example Time-based BWM Policy, page 351

Bandwidth Management OverviewThe 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 application—and 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 resources—thus 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 customer’s Service License Agreement (SLA).

Using the Bandwidth Management module, a LinkProof device can classify traffic passing through it according to predefined criteria and can enforce a set of actions on traffic. A comprehensive set of user-configurable policies controls how the device identifies each packet and what it does with each packet.

When a packet is matched, LinkProof can do one of three things:

• Discard the packet—Allows the Bandwidth Management module to provide a very robust and granular packet filtering mechanism.

• Forward the packet in real time—The 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 packet—Allows the mechanism to prioritize services.

LinkProof User Guide Bandwidth Management


If the packet is to be prioritized, it is placed into a queue, which then is assigned a priority from0–7, 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 0–7. This means that there could be 100 queues (if there are 100 policies), with each queue having a label from 0–7.

Scheduler AlgorithmsThe scheduler takes packets from the many queues and forwards them.

The scheduler operates using one of two algorithms:

• Cyclic—The scheduler gives each priority a preference ratio of 2:1 over the immediately adjacent lower priority. In other words, a 0 queue has twice the priority of a 1 queue, which has twice the priority of a 2 queue, and so on. The scheduler systematically goes through queues of the same priority when it is time to forward a packet with this priority.

• CBQ (Class Based Queuing)—Has the same packet-forwarding pattern as the WFQ algorithm, with one significant difference. The CBQ algorithm is aware of a predefined bandwidth configured per policy. When you configure a policy, you can give it a minimum (guaranteed) allotted bandwidth. For more information, see Guaranteed Bandwidth, page 318.

Note: Unless CBQ is used, policies cannot be configured with an associated bandwidth.

Application ClassificationIf Application Classification is defined as Per Packet, the device classifies every packet that flows through it. In this mode, every single packet must be individually classified.

If Application Classification is defined as Per Session, all packets are classified by session. An intricate algorithm is used to classify all packets in a session until a “best fit” policy is found, fully classifying the session. Once the session is fully classified, all packets belonging to the same session are classified accordingly. This not only allows for traffic classification according to application, but also saves some overhead for the classifier, as it only needs to classify sessions, and not every single packet.

Classification ModeThe following classification modes are available:

• Policies—The device classifies each packet or session by matching it to policies configured by the user.

• Diffserv—The device classifies packets only by the Differentiated Services Code Point (DSCP) value.

• ToS—The device classifies packets only by the ToS (Type of Service) bit value.

Random Early DetectionThe Random Early Detection (RED) algorithm can be used to protect queues from overflowing that may cause serious session disruption. The algorithm draws from the inherent retransmission and flow control characteristics of TCP.

If the RED algorithm is deployed, the status of the queues is monitored. If the queues are approaching full capacity, random TCP packets are intercepted and dropped. Note, that only TCP packets are dropped, and the packet selection is entirely random. This protects the queues from becoming completely full, which will cause less disruption across all TCP sessions and will also protect UDP packets.

LinkProof User GuideBandwidth Management


Radware’s bandwidth management mechanism can deploy RED in two forms:

• Global RED—Monitors the capacity of all the queues (that is, the global set of queues) and randomly discards TCP packets before the classifier sees them.

• Weighted RED (WRED)—The RED algorithm is deployed per queue (instead of for all the packets in all the queues) and the priority of the queue has an effect on whether a packet gets dropped or not.

Managing Bandwidth Management Global ParametersBefore setting up Bandwidth Manager policies, you need to define the general bandwidth management parameters.

Use the BWM Global Parameters pane to configure the global BWM functionality of the device.

Note: Full functionality of the Bandwidth Management module is available only with a BWM license.

To configure the BWM global parameters

1. Select BWM > Global Parameters. The Global Parameters pane is displayed.


Table 167: BWM Global Parameters

Parameter DescriptionClassification Mode The classification to be used.

Values:

• Disable—No classification. The BWM feature is disabled.

• Policies—The 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.

• Diffserv—The 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.

• ToS—The device classifies packets only by the ToS (Type of Service) bit’s value. This option requires a BWM license. This option is displayed only when a BWM license is installed.

Default: Policies

Note: If you change the value for this parameter, you must reset the device.



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 policy’s Content/OMPC definitions.

Values:

• Per-packet—The device classifies every packet that flows through it.

• Per-session —Packets are classified by session. All packets in a session are classified until a best fit policy is found, fully classifying the session. Once the session is fully classified, all packets belonging to the same session are classified accordingly.

Default: Per-session

Scheduling Algorithms The scheduling algorithm for BWM policies.

This option requires a BWM license. This option is displayed only when a BWM license is installed.

Values:

• CBQ

• Cyclic

Default: CBQ

Note: If you change the value for this parameter, you must reset the device.

Random Early Detection (RED) Specifies the queue management for the BWM mechanism.


Values:

• None

• Global

• Weighted

Default: None

Queue Size The number of packets in each BWM queue. There is one queue per traffic-shaping policy.

Default: 128

Dynamic Borrowing Enables or disables borrowing of the bandwidth between policies within the same Policy Group (see all the panes under Classes > Modify).


Default: disable

BW per Traffic Flow Aging The time, in seconds, that the device keeps a non-active traffic flow in the BW flow tracking table.





Bandwidth Management PoliciesThis section describes Bandwidth Management policies and contains the following topics:

• Bandwidth Management Policy Mechanism, page 316

• Bandwidth Management Classification Criteria, page 316

• Bandwidth Management Rules, page 318

• Managing Bandwidth Management Policies, page 319

Max Packets for Session Classification

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:

• 0—The device searches for the content in all the packets belonging to the session.

• 1–100

Default: 5

Classification on default gateway only

The device classifies traffic for BWM only on the default gateway, not on all the traffic passing through the device.

Values:

• enable

• disable

Default: disable

TCP Classification Mode Indicates whether to classify TCP sessions according to the BWM policy, only if they start with a SYN packet.


Values:

• SYN-Validation—Only classifies a session that begins with a SYN packet.

• Promiscuous—Classifies all sessions.

Default: Promiscuous





Bandwidth Management Policy MechanismThe policy mechanism enables you to classify traffic passing through the LinkProof device and enforce on it bandwidth management.

The policy database is made up of two sections. The first is the temporary or inactive portion. These policies can be altered and configured without affecting the current operation of the device. As these policies are adjusted, the changes are not in effect unless the inactive database is activated. The activation basically updates the active policy database, which is what the device uses to sort through the packets that flow through it.

A policy consists of a set of conditions (classification criteria) and a set of actions that apply as a consequence of the conditions being satisfied.

Bandwidth Management Classification CriteriaYou 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:

• Source—Defines 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.

• Destination—Defines 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 device’s interface, type the IP address of the interface in the Destination box.

• Direction—Setting 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).

• Service—Defines 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 Group—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.

• VLAN Tag Group—Defines VLAN traffic classification according to VLAN ID (VLAN Identifier) tags.



• Traffic Flow Identification—Defines what type of traffic flow we are going to limit via this policy. The available options are:

— Client (source IP)

— Session (source IP and port)

— Connection (source IP and destination IP)

— FullL4Session (source and destination IP and port)

— SessionCookie (must configure cookie identifier)

• Cookie Field Identifier—A string that identifies the cookie field whose value must be used to determine the different traffic flows.

Note: This is required only when Traffic Flow Identification is set to SessionCookie. When Traffic Flow Identification is set to SessionCookie, the BWM classifier searches for the Cookie Field Identifier followed by an equal sign (=) and classifies flows according to the value.

Example If you have the following rule:

— Source: IP_A

— Destination: IP_B

— Service: HTTP

— Direction: One Way

only traffic with a source IP, IP_A and a destination IP IP_B with source port X and destination port 80 would be classified. The return packet, with source IP_B and destination IP IP_A, with source port x and destination port 80 would not be classified.

Example If you have the following rule:

— Source: NET_A

— Destination: NET_B

— Service: HTTP

— Direction: Two Way

a packet with source IP belongs to NET_A with a destination IP belongs to NET_B requesting a HTTP request will be matched, while a packet with source IP belongs to NET_B with a destination IP belongs to NET_A requesting a HTTP request will not be matched, even if the rule is set to two ways.



Bandwidth Management RulesOnce the traffic is classified and matched to a policy, the Bandwidth Management rules can be applied to this policy.

ActionThe action determines the access given to traffic.

The values for the Action parameter are as follows:

• Forward (default)—The connection is accepted and traffic is forwarded to its destination. This is the default value.

• Block—All packets are dropped.

• Block and Reset—All packets are dropped. In TCP traffic, an RST packet is sent to the client.

• Block and Bidirectional Reset—All packets are dropped. In TCP traffic, an RST packet is sent to both client and server.

PriorityIf 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 BandwidthIf the scheduler is configured to use the CBQ algorithm, the policy can be assigned a minimum (guaranteed) bandwidth. The scheduler will not allow packets that were classified through this policy to exceed this allotted bandwidth, unless borrowing is enabled. Note, that the maximum bandwidth configured for the entire device, as described above, overrides per-policy bandwidth configurations. In other words, the sum of the guaranteed bandwidth for all the policies cannot be higher than the total device bandwidth.

Borrowing LimitBorrowing can be enabled when the scheduler operates through the CBQ algorithm. If enabled, the scheduler can borrow bandwidth from queues that can spare it, in order to forward packets from queues that have exceeded (or are about to exceed) their allotted amount of bandwidth.

The combination of Guaranteed Bandwidth and Borrowing Limit fields value will cause the bandwidth allotted to a policy to behave as follows:

Policy GroupYou can define several bandwidth borrowing domains on a device by organizing policies in groups. Bandwidth that is not utilized by a specific policy in a group is allocated proportionally to the other policies, enabling them to borrow from other policies preventing starvation and utilizing the bandwidth more efficiently. Only policies that participate in a specific group can share bandwidth.

The total bandwidth available for a policy group is the sum of Guaranteed Bandwidth values of all policies in the group.

Guaranteed Bandwidth Borrowing Limit Policy Bandwidth0 0 Burstable with no limit, no minimum guaranteed.

X 0 Burstable with no limit, minimum of X guaranteed.

0 Y Burstable to Y, no minimum guaranteed.

X Y (Y>X) Burstable to Y, minimum of X guaranteed.

X X Nonburstable, X guaranteed.



Configuring a policy group involves the following steps:

1. Setting the global BWM parameter Dynamic Borrowing to Enable.

2. Configuring policy groups.

3. Configuring the device policies. Configure Guaranteed Bandwidth with the required value and Borrowing Limit to 0 (bandwidth limitation is ignored as the policy is able to borrow unused bandwidth from other policies in the group). For each policy, select the relevant policy group to which it belongs.

4. Perform Update policies command.

Notes:>> For more information, see Managing Bandwidth Management Global Parameters,

page 313.

>> Whenever bandwidth borrowing and/or prioritization is applied, the maximum bandwidth available for allocation per physical port must be configured. For example, for a device, a Fast Ethernet port connected to a router that supports up to 2 Mbit/s, the bandwidth for that port must be set to 2 Mbit/s. The default is the physical capacity of the port.

>> The Borrowing Limit parameter must be set to 0 for all the policies in the group and the Dynamic Borrowing global parameter must be enabled.

Traffic Flow ControlThe maximum bandwidth allowed per traffic flow.

Max Concurrent SessionsThe maximum concurrent sessions allowed for the BWM policy.

Packet MarkingPacket Marking refers to Differentiated Services Code Point (DSCP) or Diffserv. Enables the device to mark the packet with a range of bits.

Policy IndexThe policy order or index is a number that determines the order of the policy in the entire policy database. When the classifier receives a packet, it tries to find a policy that matches the packet. The policy database is searched starting with policy #1, in descending order. Once a policy is matched the process is stopped. Using this logic, the very last policy configured should be the policy that is enforced on all packets that do not match any other policies. In other words, the last configured policy should be the default policy.

Managing Bandwidth Management PoliciesYou 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.




• Configuring BWM Policies, page 320

• Viewing the Configuration of Active BWM Policies, page 324

• Configuring BWM Policy Extensions, page 325

• Viewing Active BWM Policy Extensions, page 327

• Configuring BWM Policy Groups, page 328

• Viewing Active BWM Policy Groups, page 328

• Updating BWM Policies, page 328

Configuring BWM Policies

To configure a BWM policy

1. Select BWM > Modify > Policies. The Modify Policies Table pane is displayed with a table comprising the following columns:

— Name

— Index

— Destination

— Source

— Action

2. Click Create. The Modify Policies Table Create pane is displayed.


Table 168: BWM Policy Parameters

Parameter DescriptionIndex The index number of the policy.

Name The user-defined name of the policy.

This value is read-only after creation.


Note: The source or destination can be an IP address or a network address.


Action The action to be applied to the packet.

Values:

• Forward

• Block

• Block and Reset

• Block and Bidirectional Reset

Default: Forward



Direction The direction to which the policy relates.

Values:

• One Way—A policy only matches packets where the source IP address and port match the source as well as the destination.

• Two Way—If the source matches the destination and vice versa, this is also a match.

Default: Two Way

Priority The priority attached to the packet by which it is forwarded. Priority is only applicable if the action is Forward.

Values:

• Real Time

• None

• 0–7—7 is the lowest priority.

Default: Real Time


Maximum Bandwidth The maximum bandwidth, in Kbit/s, for packets matching this policy. This option is used in conjunction with Class Based Queuing (CBQ).

Note: If you want this policy to drop all matching packets, enter 0.

Service Type The type of service (filter).

Values:

• None

• Basic Filter

• AND Group

• OR Group

Default: None



Values:

• Active—When policies are updated, this policy is used to be matched against packets.

• Inactive—When policies are updated, this policy is not used to be matched against packets.

Default: Active

Packet Marking Refers to Differentiated Services Code Point (DSCP) or Diffserv. Marks the packet with a range of bits.

Default: None

Reporting Specifies whether blocked packets are reported.

Values: Disable, Report Blocked Packets

Default: Disable





Modifying BWM Policies

To modify a BWM policy

1. Select BWM > Modify > Policies. The Modify Policies Table pane is displayed. The pane displays the active policies in a table with the following columns: Name, Index, Destination, Source, Action.

2. To modify the configuration of policy, select the policy. The Modify Policies Table Update pane is displayed.




Inbound Physical Port Group

Sets different policies to identical traffic classes that are received on different interfaces of the device. For example, you can allow HTTP access to the main server only to traffic entering the device via physical interface 3. This provides greater flexibility in configuration. To configure this option, you must first configure Port Groups. For more information, see Port Groups, page 339.

Note: The group must be configured already.

VLAN Tag Group The name of the VLAN tag group. For more information, see VLAN Tag Groups, page 341.

Default: None


Policy Group Specifies the Policy Group.

Default: None


Parameter DescriptionIndex The index number of the policy.





Values:

• Forward

• Block

• Block and Reset







Values:




Values:

• Real Time

• None

• 0–7—7 is the lowest priority.

Default: Real Time


Guaranteed Bandwidth (kbps)

The bandwidth limitation for packets matching this policy. This option is used in conjunction with CBQ.


Values:

• None

• Basic Filter

• AND Group

• OR Group



Values:









Sets different policies to identical traffic classes that are received on different interfaces of the device. For example, you can allow HTTP access to the main server only to traffic entering the device via physical interface 3. This provides greater flexibility in configuration. To configure this option, you must first configure Port Groups (see Port Groups, page 339).






Viewing the Configuration of Active BWM Policies

To view the configuration of an active BWM policy

1. Select BWM > View Active > Policies. The Active Policies Table pane is displayed. The pane displays the active policies in a table with the following columns: Name, Index, Destination, Source, Action.

2. To view additional information on a specific policy, select the policy. The following fields are displayed read-only:

VLAN Tag Group The name of the VLAN tag group (see VLAN Tag Groups, page 341).


Policy Group Specifies the Policy Group or none.







Values:

• Forward

• Block

• Block and Reset



Values:




Values:

• Real Time

• 0–7—7 is the lowest priority


Guaranteed Bandwidth (kbps)

The bandwidth limitation for packets matching this policy. This option is used in conjunction with CBQ.





Configuring BWM Policy Extensions

To create a BWM policy extension

1. Select BWM > Modify > Policy Extensions. The Modify Policies Extensions pane is displayed. The pane displays the active policies in a table with the following columns: Name, From Farm, To Farm, Classification Point, Traffic Flow Identification.

2. Select a policy. The Modify Policies Extensions Update pane is displayed.



Values:

• None

• Basic Filter

• AND Group

• OR Group



Values:






Maximum Bandwidth (kbps)

The maximum bandwidth for packets matching this policy. This option is used in conjunction with Class Based Queuing (CBQ).


Sets different policies to identical traffic classes that are received on different interfaces of the device. For example, you can allow HTTP access to the main server only to traffic entering the device via physical interface 3. This provides greater flexibility in configuration. To configure this option, you must first configure Port Groups (see Port Groups, page 339).


VLAN Tag Group The name of the VLAN tag group (see VLAN Tag Groups, page 341).


Policy Group Specifies the Policy Group.




Table 170: BWM Policy Extension Parameters

Parameter DescriptionName The read-only, user-defined name of the policy.

From Farm The source farm.

To Farm The destination farm.

Classification Point Indicates whether the classification is done before of after packet modification.

Value:

• After Changes—Classifies the device after the packet changes.

• Before Changes—Classifies the device before the packet changes.

Traffic Flow Identification

Defines what type of traffic flow we are going to limit via this policy.

Values:

• None

• Client—Source IP.

• Session—Source IP and port.

• Connection—Source IP and destination IP.

• FullL4Session—Source and destination IP and port.

• SessionCookie—Must configure cookie identifier.

Traffic Flow Max BW The maximum bandwidth, in Kbit/s, allowed per traffic flow.

Max Concurrent Sessions

The maximum number of concurrent sessions allowed for a client IP.

Note: This option is not available if the Traffic Flow Identifier is set to Session or FullL4Session.

Max HTTP Rqts Per Second

When the Traffic Flow Max BW parameter is configured and the Traffic Flow Identification parameter is set to Session Cookie, the device can track and limit the number of requests, such as HTTP GET or POST or HEAD per Cookie.

Cookie Field Identifier A string that identifies the cookie field whose value must be used to determine the different traffic flows.

The Cookie Field Identifier is required only when Traffic Flow Identification is set to SessionCookie. When Traffic Flow Identification is set to SessionCookie, the BWM classifier searches for the Cookie Field Identifier followed by “=” and classifies flows according to the value.

Activation Schedule The Event Schedule for making the BWM policy active. For more information, see Event Scheduler, page 255.

Default: None

Note: The schedule must be configured already.

Inactivation Schedule The Event Schedule for making the BWM policy inactive. For more information, see Event Scheduler, page 255.

Default: None

Note: The schedule must be configured already.



Viewing Active BWM Policy Extensions

To view the configuration of active BWM policy extensions

1. Select BWM > View Active > Policy Extensions. The Active Policies Extenstions pane is displayed. The pane displays the active policies in a table with the following columns: Name, From Farm, To Farm, Classification Point, Traffic Flow Identification.

2. To view additional information on a specific policy, select the policy. The following fields described are displayed read-only:

Paremeter DesrciptionName The user-defined name of the policy.

Classification Point Indicates whether the classification is done before of after packet modification.

Value:



Traffic Flow Identification

Defines the type of traffic flow that this policy manages.

Values:

• None

• Client—Source IP.

• Session—Source IP and port.

• Connection—Source IP and destination IP.

• FullL4Session—Source and destination IP and port.

• SessionCookie—Must configure cookie identifier.

Traffic Flow Max BW (kbps)

The maximum bandwidth in Kbps allowed per traffic flow.

Max Concurrent Sessions

The maximum number of concurrent sessions allowed for a client IP.

Note: This option is not available if the Traffic Flow Identifier is set to Session or FullL4Session.

Max HTTP Rqts Per Second

When the Traffic Flow Max BW parameter is configured, and the Traffic Flow Identification parameter is set to Session Cookie, the device can track and limit the number of requests, such as HTTP GET or Post or HEAD per Cookie.

Cookie Field Identifier String that identifies the cookie field whose value must be used to determine the different traffic flows.

The Cookie Field Identifier is required only when Traffic Flow Identification is set to SessionCookie. When Traffic Flow Identification is set to SessionCookie, the BWM classifier searches for the Cookie Field Identifier followed by “=” and classifies flows according to the value.

Activation Schedule The Event Schedule for making the BWM policy active. For more information, see Event Scheduler, page 255.

Default: None

Inactivation Schedule The Event Schedule for making the BWM policy inactive. For more information, see Event Scheduler, page 255.

Default: None



Configuring BWM Policy GroupsYou can organize BWM policies into groups that are defined according to the borrowing limit. Each Policy Group shares the same bandwidth borrowing domain. Only policies that participate in the defined group can share the borrowing domain. For more information, see Policy Group, page 318.

The Modify Policies Group table contains all the bandwidth policy groups. You can add new policy groups to this table.

You cannot configure a Policy Group when the value of the Borrowing Limit parameter is 0, or Guaranteed.

To configure a BWM Policy Group

1. Select BWM > Modify > Policy Groups. The Modify Policy Group Table pane is displayed.

2. Click Create. The Modify Policy Group Table Create pane is displayed.

3. In the Name box, type the name of the new Policy Group.

4. Click Set. The new policy group is displayed in the Modify Policy Group Table and the Active Policy Group Table.

Viewing Active BWM Policy Groups

To view active BWM Policy Groups

Select BWM > View Active > Policy Groups. The Active Policy Group Table pane is displayed.

Updating BWM Policies

To update BWM Policies

1. Select BWM > Update Policies. The Activate Latest Changes pane is displayed.

2. Click Set.

ServicesLinkProof uses Services to filter traffic. Services characterize traffic based on layer-3–7 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.




• Basic Filters, page 329

• AND Group Filters, page 335

• OR Group Filters, page 336

• Viewing Active Services, page 337

Basic FiltersLinkProof supports an extensive list of predefined basic filters (see Predefined Basic Filters, page 330). You can also create your own basic filters.

A basic filter includes the following components:

• Protocol—The specific protocol that the packet should carry. The possible choices are IP, TCP, UDP and ICMP. If the specified protocol is IP, all IP packets (including TCP and UDP) will be considered.

When configuring TCP or UDP protocol, the following additional parameters are available:

— Destination Port (From-To)—Destination port number for that protocol. For example, for HTTP, the protocol would be configured as TCP and the destination port as 80. The port configuration can also allow for a range of ports to be configured.

— Source Port (From-To)—Similar to the destination port, the source port that a packet should carry in order to match the filter can be configured.

• Offset Mask Pattern Condition (OMPC)—The OMPC is a means by which any bit pattern can be located for a match at any offset in the packet. This can aid in locating specific bits in the IP header, for example. TOS and Diff-serv bits are perfect examples of where OMPCs can be useful. It is not mandatory to configure an OMPC per filter. However, if an OMPC is configured, there should be an OMPC match in addition to a protocol (and source/destination port) match. In other words, if an OMPC is configured, the packet needs to match the configured protocol (and ports) and the OMPC.

Content SpecificationsWhen 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 FiltersLinkProof supports an extensive list of predefined basic filters. You cannot modify or delete predefined basic filters. For the list of predefined basic filters, see Appendix B - Predefined Basic Filters, page 563.

Configuring Basic Filters

Caution: If you modify the configuration of a filter that is used in an existing policy, you need to activate the latest changes (Classes > Update Policies > Set).

To configure a basic filter

1. Select Classes > Modify Services > Basic Filters. The Modify Basic Filter Table pane is displayed. The Modify Basic Filter Table pane contains a table with the following columns:

— Name

— Description

— Protocol

— OMPC Offset

— OMPC Mask

2. Select the relevant link. The Modify Basic Filter Table Update pane is displayed.


Table 171: Basic Filter Parameters

Parameter DescriptionName The read-only name of the filter.

Protocol 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 0–65,535

• Value ranges (for example, 30–400)

• 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.





Destination App. Port The Layer-4 destination port or source-port range for TCP, UDP, or SCTP traffic.

Values:

• Values in the range 0–65,535

• Value ranges (for example, 30–400)

• 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: 0–1513

Default: 0





OMPC Mask 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: 0–1513

Default: 0

Content Contains the value of the content search.

Values: < space > ! " # $ % & ' ( ) * + , -. / 0 1 2 3 4 5 6 7 8 9 : ; < = > ? @ A B C D E F G H I J K L M N O P Q R S T U V W X Y Z [ \ ] ^ _ ` a b c d e f g h i j k l m n o p q r s t u v w x y z { | } ~ .





Content Type Specifies the specific content type to search for.

Values:

• None

• URL—A URL in the HTTP request URI.

• Text—Text anywhere in the packet.

• Host Name—A 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 Field—A header field in the HTTP header.

• Expression—Text anywhere in the packet represented by a regular expression specified in the Content field.

• Mail Domain—The Mail Domain in the SMTP header.

• Mail To—The Mail To SMTP header.

• Mail From—The Mail From SMTP header.

• Mail Subject—The Mail Subject SMTP header.

• File Type—The type of the requested file in the HTTP GET command (for example, JPG, EXE, and so on).

• Cookie—The HTTP cookie field. The Content field includes the cookie name, and the Content Data field includes the cookie value.

• Normalized URL—A normalized URL in the HTTP request URI.

• POP3 User—The POP3 User field in the POP3 header.

• URI length—Filters according to URI length.

• FTP Command—Parses FTP commands to commands and arguments, while normalizing FTP packets and stripping Telnet opcodes.

• FTP Content—Scans the data transmitted using FTP, normalizes FTP packets and strips Telnet opcodes.

• Generic Url—The 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 Header—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 Cookie—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.

Default: None

Content End Offset Specifies the location in the packet at which the checking of content ends.

Values: 0–1513

Default: None

Content Data Refers to search for content within the packet.





AND Group FiltersAn 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).


Content Coding 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.





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.


4. Click Set.

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 FiltersAn 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.

Parameter DescriptionAND Group Name The user-defined AND Group name.

Basic Filter Name A basic filter for this AND Group.



3. Configure the parameters; and then click Set.

Viewing Active ServicesYou 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.


Table 172: OR Groups Parameters

Parameter DescriptionOR Group Name The user-defined OR Group name.

Filter Name A basic filter or an AND Group, depending on the value in the Filter Type drop-down list, for this OR Group.

Filter Type Specifies the type of the filter options displayed in the Filter Name drop-down list.

Values: Basic Filter, And Group



NetworksA 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.


Note: To simplify configuration, a network can consist of a combination of network subnets and ranges—for example:Range = 176.200.100.0: 176.200.100.255Subnet = 172.0.0.0: 255.0.0.0

Table 173: Network Parameters

Parameter DescriptionName The user-defined network name.

Sub Index 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.

Mode The network mode.

Values: IPMask, IPRange

Address The IP address of the subnet.


From IP The first IP address in the range of addresses.

To Address The last IP address in the range of addresses.



To edit a network


2. Modify the parameters as required.

3. Click Set.

To delete a network


2. Select the checkbox in the row of the network to delete.

3. Click Delete. The network is deleted.

Viewing Active Networks

To view active networks

1. Select Classes > View Active > Networks. The Active Network Table pane is displayed.

2. To view the values for all the parameters of a network, click on the relevant network. The Active Network Table pane is displayed with read-only values.

Port GroupsYou 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.

Table 174: Active Network Table Parameters

Parameter DescriptionName The user-defined network name.

Sub Index The unique index number of the subnet.

Address The IP address of the subnet.


From IP The first IP address in the range of addresses.

To IP The last IP address in the range of addresses.

Mode The network mode.



Configuring Port Groups

To configure a port group

1. Select Classes > Modify > Port Groups. The Modify Physical Port Groups Table pane is displayed.

1. Click Create. The Modify Physical Port Groups Table Create pane is displayed.


Viewing Active Port Groups

To view active port groups

1. Select Classes > View Active > Port Groups. The Active Physical Port Groups Table pane is displayed is displayed with the following read-only parameters:

— Group Name

— Inbound Port

Application Port GroupsApplication 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.

Table 175: Physical Port Group Parameters

Parameter DescriptionGroup Name The user-configured name of the port group.

Inbound Port The inbound port for this group.

Values:

• A port number

• Any




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.

VLAN Tag GroupsVLAN 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.

Table 176: Application Port Groups Parameters

Parameter DescriptionName The name of the group.

From Port 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.

Table 177: Active Application Port Groups Parameters

Parameter DescriptionName The name of the group.

From Port The first port in the range.

To Port The last port in the range.

Group Type The group type.

Values: static, regular



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.


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.

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.

Table 178: VLAN Tag Groups Parameters

Parameter DescriptionGroup Name The name of the group of VLAN tags.

VLAN Tag A VLAN Tag number.

Default: 65536

VLAN Tag Range From The lowest value in the range of VLAN tags that you want to define.

Default: 65536

VLAN Tag Range To The highest value in the range of VLAN tags that you want to define.

Default: 65536

Group Mode The mode of the group.

Values:

• Discrete—Select Discrete if you define a single VLAN tag number.

• Range—Select Range if you define the range of the group.


Parameter DescriptionGroup Name The name of the group of VLAN tags.

VLAN Tag A VLAN Tag number.

Default: 65536

VLAN Tag Range From The lowest value in the range of VLAN tags that you want to define.

Default: 65536



MAC GroupsA MAC group on a LinkProof device groups a set of MAC addresses into single entity with a given name. You can use the MAC group, for example, in bandwidth management policies.

Configuring MAC Groups

To configure MAC group

1. Select Classes > Modify > MAC Groups. The Modify MAC Address Groups Table is displayed.

2. Click Create. The Modify MAC Address Groups Table Create pane is displayed.


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.

VLAN Tag Range To The highest value in the range of VLAN tags that you want to define.

Default: 65536

Group Mode The mode of the group.

Values:

• Discrete—Select Discrete if you define a single VLAN tag number.

• Range—Select Range if you define the range of the group.

Table 180: Modify MAC Address Groups Parameters

Parameter DescriptionGroup Name The name of the MAC address group.

MAC Address The MAC address.

Table 181: Active MAC Address Groups Parameters

Parameter DescriptionGroup Name The name of the MAC address group.

MAC Address The MAC address.





Updating Policies—ClassesIf you modify the configuration of a class that is used in an enabled policy, you need to activate the latest changes.



1. Select Classes > Update Policies. The Activate Latest Changes pane is displayed.

2. Click Set.

Discrete NetworksA 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 address—a task that usually takes several seconds per policy.

You can use a Discrete Network when classifying IP traffic in a Flow Policy or bandwidth-management policy. Changes to the elements of a Discrete Network only affect new entries that are classified by it. Changes to the elements of a Discrete Network do not affect the Flow configuration, bandwidth-management configuration.

The configuration of an element of a Discrete Network object comprises the parameters Network Name, Network Address, Network VLAN Tag.

A Discrete Network object is created when the first IP address is associated with the Discrete Network name. A Discrete Network object is deleted when the last IP address is removed from the Discrete Network name.

Depending on your global configuration (uniqeness-status), IP addresses must either be unique across all the Discrete Network objects (represented by the Network Name parameter) or may be associated with multiple Network Name parameter.

You can create a Discrete Network with the IP address of a network (for example, 1.1.1.0), since no single IP address has that source address.

The following table is an example of a Discrete Network Table on a device whose global configuration allows IP addresses to be associated with multiple Discrete Network objects. Each row in the table is one element of a Discrete Network object (represented by the Network Name parameter).

Table 182: Discrete Network Table Example

Network Name Network Address Network VLAN TagDiscreteNetwork_1 1.2.3.4 No Tag

DiscreteNetwork_1 1.2.3.5 No Tag




You can configure Discrete Networks using CLI or SNMP.

CLI Commands for the Discrete Networks FeatureLinkProof 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:

— enable—The 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.

— disable—The IP addresses in a Discrete Network can be used in multiple Discrete Networks on the device.

Default: disable


DiscreteNetwork_1 10.200.201.8 10




Table 182: Discrete Network Table Example

Network Name Network Address Network VLAN Tag



• 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 ManagementYou 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.




Protocol DiscoveryThe Protocol Discovery feature enables you to recognize the different applications running on your network.


• Protocol Discovery Overview, page 347

• Protocol Statistics Global Parameters, page 348

• Protocol Discovery Policies, page 348

• Viewing the Protocol Discovery Statistics, page 350

Protocol Discovery OverviewTo 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.

Table 183: Discrete Network Parameters in Web Based Management

Parameter Description Write to CDB Status 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.

Entries Uniqueness Status Specifies whether an IP address in a Discrete Network must be unique per network name.

Values:

• Enable—The 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.

• Disable—The IP addresses in a Discrete Network can be used in multiple Discrete Networks on the device.

Default: Disable



Protocol Statistics Global ParametersUse 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.


Protocol Discovery PoliciesA 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.

Table 184: Protocol Statistics Global Parameters

Parameter DescriptionProtocol Monitoring Status Enables or disables the monitoring of protocol statistics by the device.


Default: Disabled

Protocol Statistics Reporting Period

The time, in seconds, that the device monitors protocol statistics.

Default: 60 (seconds)

Protocol Statistics Reporting (SRP)

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:

• True—Enables SRP.

• False—Disables SRP.

Default: False

Protocol Statistics Aging The interval, in seconds, at which the device ages (deletes old) statistics.

Default: 10

Classification on default gateway only

The device classifies traffic on the default gateway only.


Default: disable




Table 185: Protocol Discovery Policy Parameters


Index Location of policy in the protection table that reflects the order in which the classification is performed.

Destination Specifies the destination of the traffic. Can be specific IP addresses or a range of IP addresses or IP subnet address.

Default: any—Covers traffic to any destination.

Source Defines the source of the traffic. Can be specific IP addresses, or a range of IP addresses or IP subnet address.

Default: Any—Covers traffic from any source

Destination MAC Address Group Enables discovery of applications and protocols in the traffic sent to a transparent network device.

Default: None

Source MAC Address Group Enables discovery of applications and protocols in the traffic sent by a transparent network device (firewall or router).

Default: None

Inbound Physical Port Group 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

VLAN Tag Group Defines VLAN traffic classification according to VLAN ID (VLAN Identifier) tags.

Default: None

Direction Defines the direction of the traffic.

Values:

• One Way—From source to destination.

• Two Way—From source to destination and from destination to source.

Default: Two Way

Operational Status Specifies whether the feature is active or inactive.

Values:

• Active

• Inactive

Default: Active

Classification Point Specifies whether the classification is done before of after packet modification.

Values:



Default: After Changes



Viewing the Protocol Discovery StatisticsUse the Protocol Statistics Table pane to view the global parameters of protocol statistics. To view the table in the Protocol Statistics Table pane, Protocol Statistics Monitoring must be enabled (see Protocol Statistics Global Parameters, page 348).

The following table describes the columns of the Protocol Statistics Table.

To view the protocol statistics table

Select Performance > Protocol Statistics > View Protocol Statistics. The Protocol Statistics Table pane is displayed.

Port BandwidthTo 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 type—100 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 ClassificationYou 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.

Parameter DescriptionPolicy Name Name of the policy.

Protocol IP or Other.

Port TCP/UDP port used by the protocol.

Bandwidth (Kbits) Total bandwidth (Kbit/s) used for this protocol-discovery policy during the last second.

Peak Bandwidth Peak bandwidth, in Kbit/s, used for this protocol during the last period, per protocol.



To cancel interface classification by port

1. Select BWM > Miscellaneous> Cancel Classification Per Port. The Classification is not performed for the following input ports pane is displayed.


To cancel interface classification by VLAN

Set the VLAN tag on the interface to 0.

Example Time-based BWM PolicyThis section describes an example configuration of a BWM policy for HTTP traffic, which runs for one hour every day.

Note: If you need to run a BWM policy with a schedule, you configure the BWM policy first. Then, you configure the start- and finish-event schedules, and associate the schedules with the BWM policy.

The configuration of the example BWM policy involves the following:

1. Configuring the Example BWM Policy, page 352

2. Configuring the Example Start-Event Schedule, page 352

3. Configuring the Example Finish-Event Schedule, page 353

4. Associating the Start- and Finish-Event Schedules with the Example BWM Policy, page 353

5. Activating the Latest Changes for the Example BWM Policy, page 354


Parameter DescriptionInbound Port The number of the required port for inbound traffic.

Outbound Port The number of the required port for outbound traffic.

Direction The direction of the traffic flow through each port.

Values:

• Oneway—The traffic flows in through the inbound port and out through the outbound port.

• Twoway—The traffic flows both ways through both ports.



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.

Configuring the Example Start-Event Schedule

To configure the example start-event schedule




Table 187: BWM Policy Parameters for Example Time-based BWM Policy

Parameter ValueIndex 1

Name HTTPPriority

Destination any

Source any

Action Forward

Direction Two Way

Priority 7

Description Example BWM policy

Guaranteed Bandwidth 1024

Service Type Basic Filter

Service http

Operational Status Active

Packet Marking None

Maximum Bandwidth 0

Inbound Physical Port Group None

VLAN Tag Group None

Policy Group None

Table 188: Start-Event Scheduler Parameters for Example Time-based BWM Policy

Parameter ValuesName HTTPPriority_Start

Frequency Daily



Configuring the Example Finish-Event Schedule

To configure the example finish-event schedule




Associating the Start- and Finish-Event Schedules with the Example BWM Policy

To associate the start- and finish-event schedules with the example BWM policy

1. Select BWM > Modify > Policy Extensions. The Modify Policies Extensions pane is displayed.

2. From the table, select HTTPPriority. The Modify Policies Extensions Update pane is displayed with HTTPPriority displayed in the Name field.


Time 2200

Days All checkboxes must be cleared.

Date 00000000

Table 189: Finish-Event Scheduler Parameters for Example Time-based BWM Policy

Parameter ValuesName HTTPPriority_Finish

Frequency Daily

Time 2300

Days All checkboxes must be cleared.

Date 00000000

Table 190: BWM Policy Extension Parameters for Example Time-based BWM Policy

Parameter ValueFrom Farm Leave empty.

To Farm Leave empty.

Classification Point After Changes

Traffic Flow Identification None

Traffic Flow Max BW 0

Max Concurrent Sessions 0

Table 188: Start-Event Scheduler Parameters for Example Time-based BWM Policy

Parameter Values



Activating the Latest Changes for the Example BWM Policy


1. Select BWM > Update Policies. The Activate Latest Changes pane is displayed.

2. Click Set.

Max HTTP Rqts Per Second 0

Cookie Field Identifier Leave empty.

Activation Schedule HTTPPriority_Start

Inactivation Schedule HTTPPriority_Finish

Table 190: BWM Policy Extension Parameters for Example Time-based BWM Policy

Parameter Value


Chapter 9 – Health MonitoringThis chapter describes Health Monitoring.


• Health Monitoring—Introduction, page 355

• Health Check Configuration, page 357

• Farm Health Checks, page 381

Health Monitoring—IntroductionThis section describes the general function of the Health Monitoring module and the basic health-monitoring concepts.


• Health Monitoring Module, page 355

• Response Level, page 355

• Checked Elements, page 356

• Health Checks, page 356

• Methods, page 356

• Binding and Groups, page 356

Health Monitoring ModuleThe 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 user-defined checks, and enables you to create dependencies between health checks of different elements.

Response LevelLinkProof 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.

LinkProof User Guide Health Monitoring


Checked ElementsA 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 ChecksA health check defines how to test the health of any network element (not necessarily a checked element). A check configuration includes such parameters as the Check Method, the TCP/UDP port to which the test is sent, the time interval for the test, its timeout, the number of retries, and more. For more information, see Creating a Regular Health Check, page 358.

A network element can be tested using one or several health checks.

MethodsHealth-check methods are applications or protocols that the LinkProof device uses to check the health of network elements. For example, a health-check method can be Ping, HTTP or other. Although the Health Monitoring module provides a wide array of predefined methods, user-defined methods are also supported. In addition, method-specific arguments can be configured for each health check.

For a complete list of supported health-check methods, see Table 194 - Health Check Methods, page 362.

Binding and GroupsThe 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.

LinkProof User GuideHealth Monitoring


Health Check ConfigurationThis section describes how to configure health monitoring according to health check types and contains the following topics:

• Configuring Health Monitoring Global Parameters, page 357

• Managing the Health Checks in the Check Table, page 358

• Bindings and Groups, page 374

• User-Defined Health Check Methods—Packet Sequence Table, page 375

• Configuring a Diameter Health Check, page 1

Configuring Health Monitoring Global Parameters

To configure the global parameters for health monitoring

1. Select Health Monitoring > Global Parameters. The Health Monitoring Global Parameters pane is displayed.


Table 191: Health Monitoring Global Parameters

Parameter DescriptionHealth Monitoring Status The Health Monitoring Status mode.

Values:

• Disable—The device does not use Health Monitoring.

• Enable—The 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:

• 0—Disables the feature.

• 1-9

Default: 0

SSL Certificate Entry Name

The SSL Certificate entry name.



Managing the Health Checks in the Check TableUse the Health Monitoring Check Table pane to do the following:

• View the Health Monitoring Check Table. For more information, see Health Monitoring Check Table, page 358.

• Create a new health check. For more information, see Creating a Regular Health Check, page 358.

• View and modify some parameters of the health checks that are currently defined in a database, prior to applying them to a network element. For more information, see the procedure To view or modify the configuration of a health check, page 360.

Health Monitoring Check TableThe Health Monitoring Check Table includes the following columns:

• Check Name—The name of the configured health check.

• Method—The health check method (see Methods, page 356).

• Status—Either Passed or Failed.

• Destination Host—The 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 Level—The Response Level (see Response Level, page 355).

To view the Health Monitoring Check Table

Select Health Monitoring > Check Table. The Health Monitoring Check Table pane is displayed.

Creating a Regular Health CheckA regular health check is a check of an individual network element. You can add or edit health check parameters through the Check Table. The Health Monitoring Check Table lists the configured health checks.

If a check is not bound to any of the checked elements (see Binding and Groups, page 356), the check is still performed. If it fails, the device sends failure-notification messages, as configured (SNMP traps, syslog messages, or E-mail).

To create a regular health check

1. Select Health Monitoring > Check Table. The Health Monitoring Check Table pane is displayed.

2. Click Create. The Health Monitoring Check Table Create pane is displayed.




Table 192: Health Monitoring Check Table Create Parameters

Parameter DescriptionCheck Name The user-defined name of the health check.

Method The method for the health check, selected from the drop-down list. For descriptions of the methods, see Table 194 - Health Check Methods, page 362.

Default: Ping

Destination Host The hostname or IP address of the checked element.

Next Hop The IP address of the next-hop router.

This is needed in order to direct the health check session to a network element’s MAC address.

Default: 0.0.0.0

Dest Port The destination port, which is method specific.

Default: 0

Arguments 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: 1–232-1

Default: 10

Retries The number of times that a health check must fail before the Health Monitoring module reevaluates the element’s availability status.

Default: 5

Timeout The maximum number of seconds that the device waits for a response for the health check.

Default: 5

No New Session Timeout 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.



To view or modify the configuration of a health check

1. Select Health Monitoring > Check Table. The Health Monitoring Check Table pane is displayed.

2. From the Check Name column, click the required link. The Health Monitoring Check Table Update pane is displayed.

3. View or modify the parameters according to Table 193 - Health Monitoring Check Table Update Parameters, page 360.

4. Click Set.

Measure Response Time 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

Reverse Check Result 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:

• Disable—The check fails when the server does not reply.

• Enable—The check passes when no reply is received.

Default: Disable

Table 193: Health Monitoring Check Table Update Parameters

Parameter DescriptionCheck Name The user-defined name (read-only) of the health check.

Method The method for the health check (read-only). For descriptions of the methods, see Table 194 - Health Check Methods, page 362.

Destination Host The hostname or IP address of the checked element.

Next Hop The IP address of the next-hop router.

This is needed in order to direct the health check session to a network element’s MAC address.

Dest Port The destination port, which is method specific.

Arguments 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

Table 192: Health Monitoring Check Table Create Parameters




Predefined Health-Monitoring Check MethodsThe 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.

Interval The time interval, in seconds, between health checks.

The value must be greater than the specified Timeout.

Values: 1–232-1

Default: 10

Retries The number of times the device tries to perform the health check on an unresponsive element.

Default: 5

Timeout The maximum number of seconds that the device waits for a response for the health check.

No New Session Timeout 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.

Measure Response Time 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

Response Level 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.

Check ID The ID (read-only) of the health check.

Status The status (read-only) of the health check.

Reverse Check Result) 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:

• Disable—The check fails when the server does not reply.

• Enable—The check passes when no reply is received.

Default: Disable

Uptime (%) The percentage (read-only) of successful checks out of the total number of checks.

Success Counter The total number (read-only) of the successful checks bound to the checked element since Health Monitoring was enabled.

Failure Counter The total number (read-only) of the unsuccessful checks bound to the checked element since Health Monitoring was enabled.

Average Duration The average duration (read-only), in milliseconds, of the checks (SumOfCheckDurations ÷ ResponseLevelSamples).

Table 193: Health Monitoring Check Table Update Parameters




Table 194: Health Check Methods

Method DescriptionARP 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.

Citrix App Browsing

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 ICA The module initiates a connection to the Citrix server, using TCP port 1494 and performs a Citrix handshake. This check passes when the Health Monitoring module identifies the Citrix's reply within the first reply packet.




DHCP The Dynamic Host Configuration Protocol allows the automatic configuration of individual hosts in a network. When a new client connects to the network for the first time, the DHCP servers 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 Address—Non-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 server’s 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 Mask—Mandatory 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 Gateway—Non-mandatory parameter. When this field is set, the device compares the server’s reply with the configured value. If the server replies with an IP address that is different from the configured value, the check fails.

• DNS Server—Non-mandatory parameter. When this field is set, the device compares the server’s reply with the configured value. If the server replies with an IP address that is different from the configured value, the check fails.

• WINS Server—Non-mandatory parameter. When this field is set, the device compares the server’s reply with the configured value. If the server replies with an IP address that is different from the configured value, the check fails.

• Domain—Non-mandatory parameter. When this field is configured, the device compares the server’s reply with the configured value. If the server replies with an IP address that is different from the configured value, the check fails.

• MAC Address—Non-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 packet’s header.) By default, the device uses its base MAC address.

• Relay Agent—Non-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.


Method Description



Diameter To check Diameter application availability, the Diameter health check initiates a connection to the Diameter server. The module performs a Diameter handshake (CER/CEA) and sends an LIR message or another application message. Then, the Diameter connection is disconnected using the DPR or the DPA message. The check passes when the specified result codes are received from the Diameter server. The Diameter server defines various Attribute Value Pairs (AVP) and expected attribute values in the response received from the Diameter server.

Traffic flow with the Diameter Health check consists of the following steps:

1. TCP connection handshake.

2. Client sends CER (Capabilities Exchange Request) message and server answers with CEA message (Capabilities Exchange Answer).

3. Client sends LIR (Location Info Request) message and server answers with LIA message or, alternatively another application message or no application message at all, as specified by the administrator.

4. Client sends DPR (Disconnect Peer Request) message and server answers with DPA message (Disconnect Peer Answer).

5. TCP connection close.For information on configuring a Diameter health check, see Managing the Diameter Argument Lists Table, page 378 and Managing Binary File Transfer for Diameter Health Checks, page 380.

DNS The module submits a DNS query to the configured destination address and host. The module verifies that the reply is received with no errors, and that the reply matches a specific address (if specified). If the IP address parameter is not defined, only the return code of the reply is validated (not the IP address it contains).


• Host Name—The name of the to query.

• Host Address—The address to match.

FIX The module creates a Financial Information eXchange (FIX) protocoli packet and sends it to the FIX server (after the TCP handshake). A successful check is a check where in the reply packet, the TestReqID value is the same as the one configured. The SenderCompID is the configured value of the TargetCompID field and vice versa, and the FIX version is the same as the configured value.


• 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.

• SENDERCOMPID—Used as a standard header field by the FIX protocol. This field is a mandatory field.

• TARGETCOMPID—Used as a standard header field by the FIX protocol. This field is a mandatory field.

• FIX Version—The FIX version which will be used by the check. This field is a mandatory field.


Method Description



FTP The module executes USER and PASS commands on the FTP server. When the login process is successfully completed, the module executes a SYST command. It can verify the existence of the file on the FTP server, but it does not download the file or check its size. The module verifies that all the commands are executed successfully 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.


• Path—The path.

• Hostname—The hostname.

• HTTP Method—GET, POST, or HEAD.

• Proxy HTTP—Yes or No.

• Pragma Nocache—Yes or No

• Username—For basic authentication.

• Password—For basic authentication.

• Match search string—Text for search within the HTTP header and body with the Match mode flag that indicates whether the text must appear or not.

• Match mode—Either String exists or String is absent.

• HTTP return code—The 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.


• Path—The path.

• Hostname—The hostname.

• HTTPS Method—GET, POST, or HEAD.

• Username—For basic authentication.

• Password—For basic authentication.

• Match search string—Text for search within the HTTP header and body with the Match mode flag that indicates whether the text must appear or not.


• HTTP return code—Up 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


Method Description



LDAP 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.


• User Name—A user with privileges to search the LDAP server.

• Password—The password of the user.

• Base object—The location in the directory from which the LDAP search begins.

• Attribute name—The attribute to look for (for example, CN—Common Name).

• Search value—The value to search.

• Search Scope—Either baseObject, singleLevel, or wholeSubtree.

• Search Deref Aliases—Either 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.


• User Name—A user with privileges to search the LDAP server.

• Password—The password of the user.

• Base object—The location in the directory from which the LDAP search begins.

• Attribute name—The attribute to look for (for example, CN—Common Name).

• Search value—The value to search

• Search Scope—Either baseObject, singleLevel, or wholeSubtree.

• Search Deref Aliases—Either neverDerefAliases, derefInSearching, derefFindingBaseObj, or derefAlways.

NNTP The Health Monitoring module executes a LIST command and verifies that the returned status is valid.


Physical Port The Health Monitoring module checks the status of the physical interface. When the link is up, the check passes.

Supported argument: Port Number

Ping 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.


• Fail—The 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 Size—The size, in bytes, of the ICMP echo request (1 byte to 1024 bytes). When not configured, the default is 64 bytes.


Method Description



POP3 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 Authentication

The Health Monitoring module sends an Access-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.

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.


• Request URI—The request’s destination.

• From—The logical name of the device.

• Max Forward—The maximum number of hops between proxy servers. The default is 1.

• Match search string—Text for search within the header and body with the Match mode flag that indicates whether the text must appear or not.


• SIP return code—The module supports up to four valid return codes in addition to the return code of 200.


Method Description



SIP UDP 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.


• Request URI—The request’s destination.

• From—The logical name of the device.

• Max Forward—The default is 1.

• Match search string—Text for search within the header and body with the Match mode flag that indicates whether the text must appear or not.


• SIP return code—The 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).

SNMP 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.


• OID—The SNMP Object ID to be checked.

• Community—The SNMP community.

• Min. value—The check fails if the returned value is less than the specified Min. value

• Max value—The check fails if the returned value is greater than the specified Max value.

• No New Sessions value—The 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 Balancing—Specifies 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 farm’s Dispatch Method must be set to Response Time.

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 Version—can 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.


Method Description



Configuring Health-Check ArgumentsTable 6 - Syntax of Health-Check Method Arguments, page 370 describes predefined health-monitoring 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.

TCP Port The Health Monitoring module checks the availability of the specified TCP port.


• Complete TCP handshake—Determines 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 FIN—Either Yes or No.

TCP User Defined

The Health Monitoring module uses a user-defined TCP health check.

Supported argument: Sequence ID—Which user-defined check to use

UDP Port The Health Monitoring module checks the availability of the specified UDP port. Note that this check does not test the server’s availability, but the application’s availability within the server. This is due to the nature of UDP. When the UDP application is operational, no reply is received, When the UDP application is not operational, an ICMP message UDP Port Unreachable is sent, so that the absence of a reply indicates the application’s 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.


i – The Financial Information eXchange (FIX) protocol is a technical specification forelectronic communication of trade-related messages. More precisely, the FIX protocol isa 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 participantsshare a vision of a common, global language for automated trading of securities,derivative, and other financial instruments (www.fixprotocol.org).


Method Description



Table 6: Syntax of Health-Check Method Arguments

Method Name (ID) Argument Name

Argument Description

Mandatory Additional Information

Default

ARP (11) No argument supported

DNS (10) HOST Hostname to query. Yes

ADDR Address to be received.

No Validate only the DNS return code

FTP (6) USER Username. Yes

PASS Password. Yes

HTTP (2) PATH Path of file on Web server to be requested.

No Any configured value must begin with a slash (/).

/

HOST Hostname. No Server IP address

MTD HTTP method to submit.

No G=GET

P=POST

H=HEAD

G

PRX Use proxy HTTP. No Y=Use proxy HTTP

N=Use Web server HTTP

N

NOCACHE Use pragma: no-cache.

No Y=Use pragma: no-cache

N = Do not use pragma: no-cache

N

MTCH Pattern for content match.

No Wildcards not supported.

MEXIST Specifies whether the content match pattern must be present or absent.

No Y=Fail check if pattern is not found

N=Fail check if pattern is found

Y

USER Username for basic authentication.

No

PASS Password for basic authentication.

No

C1 Valid HTTP code. No






IMAP (7) USER Username. Yes

PASS Password. Yes

PING (0) FAIL Specifies whether the check fails when reply is received or not received.

No Y = Fail when server replies

N = Fail when server does not reply

N

DSIZE Packet size. No 1–1024 bytes 64

POP(3) USER Username. Yes

PASS Password. Yes

RADIUS (12) USER Username. Yes

PASS Password. Yes

SECRET RADIUS secret. Yes

RTSP (13) PATH Path of file on RTSP server to be requested.

Yes

HOST Hostname to use in request.

No IP address of server.





Default



SMNP OID Object ID to be used by the check.

Yes

COMM The community used by the device.

Yes

MIN The minimum value for the check to pass. If the minimum is less than the configured, the check fails.

Yes

MAX The maximum value for the check to pass. If the maximum is greater than the configured value, the check fails.

Yes

NNS No New Session. 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.

Yes

UR The measured response time for the check.

Yes

SSL Hello SSLV Can be either v23 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).

Yes V23 (SSL v2.3) or V30 (SSL v3.0)

SMTP (4) HELO Argument for SMTP HELO.

No RADWARE

SSL (14) SSLV SSL version. No V23 (SSL v2.3) or V30 (SSL v3.0)

V23

TCP Port (1) No argument supported

No





Default



TCP User Defined (8)

SEQID Packet sequence ID to submit.

Yes

UDP Port no args

SIP UDP UR The URI for the check.

Yes

FROM The sender’s information.

Yes

FRWD The maximum number of hops between proxy servers.

No

MTCH Pattern for content match.

No Wildcards are not supported.

MEXIST Specifies whether the content match pattern must be present or absent.

No Y=Fail check if pattern not found.

N=Fail check if pattern is found.

C1 Valid SIP code. No




LDAPS USER A user with privileges to search the LDAP server.

No If you configure a user, the password is mandatory.

PASS The password of the user.

No If you configure a user, the password is mandatory.

BASEO The location in the directory from which the search starts.

No If you configure BASEO, ATTR is mandatory.

ATTR The attribute to search for, for example CN: Common Name

No If you configure ATTR, BASEO is mandatory.

SEARV The value to search.

No





Default



Bindings and GroupsYou 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 Non-mandatory), one group contains health checks to the database servers (each check is Non-mandatory), 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 DescriptionCheck 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

Server The checked element to which the health check is bound.

Values: All defined servers configured on the device

Group The group number to which the check belongs. The group number is unique per server.

Mandatory Specifies if the health check is mandatory for the health of the checked element.

Values: Mandatory, Non-mandatory



To bind a health check to a network element

1. Select Health Monitoring > Binding Table. The Health Monitoring Binding Table pane is displayed.

2. Click Create. The Health Monitoring Binding Table Create pane is displayed.

3. Configure the parameters that are described in Table 7 - Health Monitoring Binding Table Parameters, page 374.

4. Click Set.

Viewing or Modifying the Configuration of a Health Check Binding

To view or modify the configuration of a health check binding

1. Select Health Monitoring > Binding Table. The Health Monitoring Binding Table pane is displayed.

2. Select the required binding. The Health Monitoring Binding Table Update pane is displayed.

3. View or modify the available parameters, which are described in Table 7 - Health Monitoring Binding Table Parameters, page 374.

4. Click Set.

User-Defined Health Check Methods—Packet 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 ID—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.

• Pkt ID—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

• Type—The type of packet, either Send (Transmit), or Receive.

• String—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.

• Description—A description of the specific packet in the sequence.



To create a packet sequence for a health check

1. Select Health Monitoring > Packet Sequence Table. The Health Monitoring Packet Sequence Table pane is displayed.

2. Click Create. The Health Monitoring Packet Sequence Table Create pane is displayed.


To view or modify the configuration of a packet sequence for a health check

1. Select Health Monitoring > Packet Sequence Table. The Health Monitoring Packet Sequence Table pane is displayed.

2. Select the required packet sequence. The Health Monitoring Packet Sequence Table Update pane is displayed.


Table 8: Health Monitoring Packet Sequence Parameters

Parameter DescriptionSeq ID 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.

Pkt ID 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

Type The type of packet.

Values: Send, Receive

String 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.

Description A description of the specific packet in the sequence.

Compare Method Specifies how the Health Monitoring module checks for the required string.

Values:

• Regular Expression—The search matches the regular expression to the value of the String parameter.

• Binary—The search compares each character found to the ASCII value of the character defined in the String parameter.



Health Monitoring Server TableThe Health Monitoring Server Table is a read-only table, which comprises the following columns:

• Server—Index number of the element attached by the device.

• Description—The user-defined description for the network server.

• Availability Status—The availability status of the element: Available or Unavailable.

• Response Level—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.

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.

Table 9: Health Monitoring Packet Sequence Parameters

Parameter DescriptionSeq ID 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.

Pkt ID 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

Type The type of packet, either Send (Transmit), or Receive.

String 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.

Description A description of the specific packet in the sequence.

Compare Method Specifies how the Health Monitoring module checks for the required string.

Values:

• Regular Expression—The search matches the regular expression to the value of the String parameter.

• Binary—The search compares each character found to the ASCII value of the character defined in the String parameter.



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. Select Health Monitoring > Diameter > Arguments List. The Diameter Argument List pane is displayed.

2. Click Create. The Diameter Argument List Create pane is displayed.

3. Configure the parameters according to Table 11 - Diameter Argument List Parameters, page 379.

4. Click Set.

Table 10: Health Monitoring—Server Table Parameters

Parameter DescriptionServer Index number of the element attached by the device in the Application

Server Table.

Description The user-defined description for the network server.

Farm Name The name of the farm in which the server is included.

Availability Status Availability status of the element, Available or Unavailable.

IP Address IP address of the network server.

Response Level 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.

Uptime (%) Percentage of health checks that received a successful response.

Success Counter The total number of successful health checks since Health Monitoring was enabled.

Failure Counter The total number of unsuccessful health checks since Health Monitoring was enabled.



To view or modify an entry in the Diameter Argument Lists Table

1. Select Health Monitoring > Diameter > Arguments List. The Diameter Argument List Configuration pane is displayed.

2. Select the argument list name. The Diameter Argument List Configuration Update pane is displayed.

3. View or modify the parameters according to Table 11 - Diameter Argument List Parameters, page 379. Argument List Name and Binary File Provided are read-only.

4. Click Set.

Table 11: Diameter Argument List Parameters

Parameter DescriptionArgument List Name The name that you define for this Argument List.

Description The user defined description of this argument list.

Origin-Host 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.

Origin-Realm The realm of the originator of the Diameter message and is present in all Diameter messages.

Vendor ID 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

Product-Name The vendor assigned name for the product.

Application Message Type Specifies the type of application message that will be sent after the Diameter connection is established.

Values:

• LIR—LinkProof generates an LIR (Location Info Request) message.

• Binary File—Associates a binary file as the Diameter data for the health check packet. The maximum size for the binary file is one kilobyte.

When you specify Binary File, you must upload a file to the device and attach it to this argument list (see Managing Binary File Transfer for Diameter Health Checks, page 380).

• None—No application message is sent.

Default: LIR

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



Managing Binary File Transfer for Diameter Health ChecksBinary-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.

Auth-Session-State Specifies whether the state is maintained for a particular session.

Values:

• State Maintained—Used to specify that a session state is being maintained, and the access device must issue a session termination message when service to the user is terminated. This is the default value.

• No State Maintained—Used 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 The realm (FQDN) to which message is routed.

Destination-Host 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 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:+555-0002)

Disconnect Cause A Diameter node must include this AVP in the Disconnect-Peer-Request message to inform the peer of the reason for its intention to shut down the transport connection.

Values:

• Rebooting—A scheduled reboot is imminent.

• Busy—The peers internal resources are constrained, and it has determined that the transport connection needs to be closed.

• Do Not Want To Talk To You—The peer has determined that it does not see a need for the transport connection to exist, since it does not expect any messages to be exchanged in the near future.

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:

• 2001—DIAMETER_FIRST_REGISTRATION

• 2002—DIAMETER_SUBSEQUENT_REGISTRATION

• 2003—DIAMETER_UNREGISTERED_SERVICE

• 2004—DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED

• 2005—DIAMETER_SERVER_SELECTION

Default: 2001, 2002, 2003, 2004, 2005

Table 11: Diameter Argument List Parameters




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


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


2. In the Delete diameter file to device section, from the Diameter Argument List Name drop-down list, choose the required Diameter Argument List.

3. Click Set.

Farm Health ChecksUsed in large configurations with farms containing multiple servers, the farm-oriented health check automates and simplifies the health monitoring configuration process by replicating a defined check for all servers in a farm.

To configure a health check on a farm

1. In the relevant Farm Table pane (see LinkProof Farms, page 138), from Connectivity Check Status drop-down list, select Health Monitoring.

2. Click Set.




Appendix A – Regular ExpressionsThis 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.

• ^abc$—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 b’s (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 b’s ending a string.

Bounds can also be used. Bounds are defined inside the brace brackets and indicate ranges in the number of occurrences. For example:

• ab{2}—matches a string that has an a followed by exactly two b’s (abb).

• ab{2,}—matches a string that has at least two b’s (abbb, abbbb, and so on).

• ab{3,5}—matches a string that has from three to five b’s (abbb, abbbb, or abbbbb).

The first number of a range must always be specified—for example, {0,2}, not {,2}.

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 a’s and b’s 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.

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, %[^a-zA-Z]% matches a string with a character that is not a letter, between two percent signs.

To take the characters ^.[$()|*+?{\ literally, they must follow a backslash (\) to denote they have a special meaning. This includes the backslash character itself.

Remember that bracket expressions are an exception to the above rule. Within brackets, all special characters, including the backslash, lose their special meanings. For example, [*\+?{}.] matches precisely any of the characters within the brackets.


Appendix B – Predefined Basic FiltersThe 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).

LinkProof User Guide Predefined Basic Filters


Table 12: Predefined Basic Filters

Name Description Protocol OMPC Offset OMPC Mask000 Routine IP 1 e0000000

001 Priority IP 1 e0000000

010 Immediate IP 1 e0000000

011 Flash IP 1 e0000000

100 ToS Flash Override IP 1 e0000000

101 CRITIC/ECP IP 1 e0000000

110 Internetwork Control IP 1 e0000000

111 Network Control IP 1 e0000000

aim-aol-any AIM/AOL Instant Messenger TCP 0 ffff0000

aol-msg AOL Instant TCP 0 0

ares_ft_udp_0 Ares_FT_udp UDP 36 ffffffff

ares_ft_udp_1 Ares_FT_udp UDP 40 ff000000

bearshare_download_tcp_0 BearShare_Download_tcp TCP 0 ffffffff

bearshare_download_tcp_1 BearShare_Download_tcp TCP 4 ffffffff

bearshare_request_file_udp_0 BearShare_Request_File_udp UDP 0 ffffffff

bearshare_request_file_udp_1 BearShare_Request_File_udp UDP 4 00ffffff

bittorrent_command_1_0 BitTorrent TCP 0 ffffffff









LinkProof User GuidePredefined Basic Filters









bittorrent_command_3_5 BitTorrent TCP 20 ffff0000

bittorrent_command_4_0 BitTorrent TCP 8 ffffff00

bittorrent_command_4_1 BitTorrent TCP 11 ff000000

bittorrent_command_4_2 BitTorrent TCP 11 ff000000

bittorrent_udp_1_0 BitTorrent_UDP_1 UDP 8 ffffff00

bittorrent_udp_1_1 BitTorrent_UDP_1 UDP 12 ffff0000

citrix-admin Citrix Admin TCP 0 0

citrix-ica Citrix ICA TCP 0 0

citrix-ima Citrix IMA TCP 0 0

citrix-ma-client Citrix MA client TCP 0 0

citrix-rtmp Citrix RTMP TCP 0 0

diameter Diameter TCP 0 0

directconnect_file_transfer_0 DirectConnect_File_transfer TCP 0 ff000000

directconnect_file_transfer_1 DirectConnect_File_transfer TCP 21 ffffffff

directconnect_file_transfer_2 DirectConnect_File_transfer TCP 25 ffffffff

dns Session for DNS UDP 0 0

emule_tcp_file_request_0 eMule TCP 0 ff000000

emule_tcp_file_request_1 eMule TCP 4 ffff0000

emule_tcp_hello_message_0 eMule TCP 0 ff000000


Name Description Protocol OMPC Offset OMPC Mask



emule_tcp_hello_message_1 eMule TCP 4 ffff0000

emule_tcp_secure_handshake_0 eMule TCP 0 ff000000

emule_tcp_secure_handshake_1 eMule TCP 4 ffff0000

ftp-session Session for FTP TCP 0 0

gnutella_tcp_1_0 Gnutella_TCP_1 TCP 0 ffffff00

gnutella_tcp_2_0 Gnutella_TCP_2 TCP 0 ffffffff

gnutella_tcp_2_1 Gnutella_TCP_2 TCP 4 ffffffff

gnutella_tcp_3_0 Gnutella_TCP_3 TCP 0 ffffff00

googletalk_ft_1_0 GoogleTalk_FT_1 UDP 24 ffffffff



googletalk_ft_1_3 GoogleTalk_FT_1 UDP 36 ffff0000





groove_command_1_0 Groove TCP 6 ffffffff




groove_command_2_1 Groove TCP 10 ffff0000





h.225-session Session Of H225 TCP 0 0





hdc1 High Drop Class 1 IP 1 fc000000




http World Wide Web HTTP TCP 0 0

http-alt HTTP alternate TCP 0 0

https HTTP over SSL TCP 0 0

icecast_1 IceCast_Stream TCP 0 ffffffff

icecast_2 IceCast_Stream TCP 4 ffffffff

icecast_3 IceCast_Stream TCP 8 ffff0000

icmp ICMP ICMP 0 0

icq ICQ TCP 0 0

icq_aol_ft_0 ICQ_AOL_FT TCP 0 ffffffff

icq_aol_ft_1 ICQ_AOL_FT TCP 0 ffffffff

icq_aol_ft_2 ICQ_AOL_FT TCP 2 ffff0000

imap Internet Message Access TCP 0 0

imesh_download_tcp_0 iMesh_Download_tcp TCP 0 ffffffff

imesh_download_tcp_1 iMesh_Download_tcp TCP 4 ffffffff

imesh_request_file_udp_0 iMesh_Request_File_udp UDP 0 ffffffff

imesh_request_file_udp_1 iMesh_Request_File_udp UDP 4 00ffffff

ip IP Traffic IP 0 0

itunesdaap_ft_0 iTunesDaap_FT TCP 0 ffffffff

itunesdaap_ft_1 iTunesDaap_FT TCP 4 ffffffff

itunesdaap_ft_2 iTunesDaap_FT TCP 8 ffffff00

itunesdaap_ft_3 iTunesDaap_FT TCP 2 ffff0000

kazaa_request_file_0 Kazaa_Request_File TCP 0 ffffffff





kazaa_request_file_1 Kazaa_Request_File TCP 4 ffffffff

kazaa_request_file_2 Kazaa_Request_File TCP 8 ffff0000

kazaa_udp_packet_0 Kazaa_UDP_Packet UDP 6 ffffffff

kazaa_udp_packet_1 Kazaa_UDP_Packet UDP 4 ffff0000

ldap LDAP TCP 0 0

ldaps LDAPS TCP 0 0

ldc1 Low Drop Class 1 IP 1 fc000000




lrp Load Report Protocol UDP 0 0

manolito_file_transfer_0_0 Manolito TCP 0 ffffffff



manolito_file_transfer_1_0 Manolito TCP 4 ff000000




mdc1 Medium Drop Class 1 IP 1 fc000000




meebo_get_0 MEEBO_GET TCP 0 ffffffff












meebo_get_8 MEEBO_GET TCP 32 ff000000

meebo_post_0 MEEBO_POST TCP 0 ffffffff







meebo_post_7 MEEBO_POST TCP 28 ffffff00

msn-any MSN Messenger Chat TCP 0 ffffffff

msn-msg MSN Messenger Chat TCP 0 0

msn_msgr_ft_0 MSN_MSGR_FT TCP 0 ffffffff

msn_msgr_ft_1 MSN_MSGR_FT TCP 48 ffffffff

mssql-monitor Microsoft SQL traffic-monitor TCP 0 0

mssql-server Microsoft SQL server traffic TCP 0 0

nntp Network News TCP 0 0

nonip Non IP Traffic NonIP 0 0

oracle-server1 Oracle server TCP 0 0



oracle-v1 Oracle SQL *Net version 1 TCP 0 0

oracle-v2 Oracle SQL *Net version 2 TCP 0 0





pop3 Post Office Protocol 3 TCP 0 0

prp PRP UDP 0 0

radius RADIUS protocol TCP 0 0

rexec Remote Process Execution TCP 0 0

rshell Remote Shell TCP 0 0

rtp_ft_0 RTP_FT UDP 0 ffff0000



rtsp RTSP TCP 0 0

sap SAP TCP 0 0

sctp SCTP Traffic SCTP 0 0

skype-443-handshake Skype signature for port 443 TCP 0 ff000000

skype-443-s-hello Skype signature for port 443 TCP 11 ffffffff

skype-80-l-56 Skype signature for port 80 TCP 2 ffff0000

skype-80-proxy Skype signature for port 80 TCP 0 ffffffff

skype-80-pshack Skype signature for port 80 TCP 13 ff000000

skype-ext-l-54 Skype signature TCP 2 ffff0000

skype-ext-pshack Skype signature TCP 13 ff000000

smtp Simple Mail Transfer TCP 0 0

snmp SNMP UDP 0 0

snmp-trap SNMP Trap UDP 0 0

softethervpn443 SoftEther Ethernet System TCP 0 ffffff00

softethervpn8888 SoftEther Ethernet System TCP 0 ffffff00

soulseek_pierce_fw_0 SoulSeek_Pierce_FW TCP 0 ffffffff

soulseek_pierce_fw_1 SoulSeek_Pierce_FW TCP 4 ff000000

soulseek_pierce_fw_2 SoulSeek_Pierce_FW TCP 2 ffff0000





ssh Secure Shell TCP 0 0

tcp TCP Traffic TCP 0 0

telnet Telnet TCP 0 0

tftp Trivial File Transfer UDP 0 0

udp UDP Traffic UDP 0 0

voip_sign_1 VOIP signature UDP 28 c03f0000













yahoo_ft_0 YAHOO_FT TCP 0 ffffffff

yahoo_ft_1 YAHOO_FT TCP 10 ffff0000

yahoo_get_0 YAHOO_GET TCP 0 ffffffff




yahoo_get_4 YAHOO_GET TCP 16 ff000000

yahoo_post_0 YAHOO_POST TCP 0 ffffffff








yahoo_post_4 YAHOO_POST TCP 16 ffff0000




Appendix C – GlossaryThe glossary describes Radware-specific terms frequently used in this guide.

Term DefinitionBandwidth Management (BWM)

Radware’s Bandwidth Management (BWM) is the process of measuring and controlling network traffic, prioritizing applications according to their bandwidth and not exceeding link capacity.

Radware’s 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 Table

Client NAT Address table - defines the addresses that are available for the 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.

LinkProof User Guide Glossary


Farm 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. One contains health checks for the two routers (each check is non-mandatory).

2. Another contains health checks for the database servers (each check is non-mandatory).

3. 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.

Radware’s 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.

Term Definition

LinkProof User GuideGlossary


NAT Network Address Translation (NAT) is the translation of an IP address used within one network (typically a LAN or internal network) to a different IP address known within another network (a public, external network). The purpose of NAT is to hide the Source IP address.

The following NAT options are used in Radware:

• NAT, Client - hides IP addresses of users sending requests to the Internet via the LinkProof device.

• NAT, Server - translates the server’s IP address in outbound server-initiated sessions, to a corresponding public address, using Static NAT (only the IP address is changed, no port NAT is done).

• NAT, Outbound - allows only connections that originate from servers on the internal network to initiate sessions both with the internal network and with the public Internet.

NAT, Client Client NAT - 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 Dynamic NAT - maps an unregistered IP address to a registered IP address from a group of registered IP addresses.

NAT, Overlapping Overlapping NAT is when IP addresses used on an internal network are registered IP addresses in use on another network.

The router must maintain a lookup table of these addresses so that it can intercept them and replace them with registered unique IP addresses. The NAT router must translate the internal addresses to registered unique addresses as well as translate the external registered addresses to unique addresses in the private network. This can be done either through static NAT or by using DNS and implementing Dynamic NAT.

NAT, Pooled Pooled NAT is similar to Port Address Translation (PAT) except there is a one-to-one mapping of addresses; the number of inside network clients is the same as the number of outside network IP addresses.

The NAT router has a pool of available IP addresses, and each client receives its own IP address when it requests a NAT translation. The next available IP address will be selected each time the client requests a translation.

NAT, Server Server NAT is a parameter in the device configuration that, when enabled, hides a server’s 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 server’s request for service is sent using its IP address as the source address. If the server’s IP address is a private IP address, the server’s address must be translated to a public IP address. The server’s IP is translated to the Layer 4 Classification’s VIP and a new entry is added to the Client Table. Sessions originating from servers are tracked in the Client Table and tagged with a “NAT” tag to differentiate this traffic from other inbound client traffic.

Term Definition

LinkProof User Guide Glossary


NAT, Static Static NAT is a type of NAT in which client requests with private IP addresses are mapped to a fixed public IP address (for example, the case of an 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)

Radware's OnDemand Switch is a data-center switch that scales up as a customer's business expands and demands increased application performance, increased throughput of data traffic and data availability.

OR Group An OR Group is a logical OR between two Basic Filters, part of the classes database.

Outbound NAT Intercept Addresses Table

The Outbound NAT Intercept Addresses table lists networking elements with source addresses that have been NATed.

Out-of-band Monitoring

Out-of-band Monitoring is a health check by the Load Balancer for TCP response time generated specifically by the Load Balancer to the server.

Using out-of-band monitoring, it is easier to check the validity of the request content.

In contrast, in-band monitoring refers to a TCP health check using the natural traffic flow between the client and the server.

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

An Application Port Group combines Layer 4 ports for UDP and TCP traffic only.

Each group is identified by its unique name. Each group name can be associated with a number of entries in the Application Port Groups table.

Port Group, Physical Inbound

Inbound Physical Port Groups classify only traffic received/sent on certain interfaces of the device, thus enabling you to set different rules for identical traffic classes that are received on different device interfaces.

Port, Management 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.

Term Definition

LinkProof User GuideGlossary


Port Mirroring 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 sub-networks by defining Protocol Discovery rules.

Proximity Global LinkProof devices calculate round-trip latency as well as router hop-count from each remote site to incoming request in order to determine the fastest site. Requests are then dynamically redirected to a site where User Response Time (URT), the time it takes from initiating a request until the user gets a response, is the smallest.

Technically, only global 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.

VLAN Tag A VLAN tag identifies traffic belonging to different VLANs.

The IEEE standard 802.1Q standard defines a method called VLAN tagging, where switches insert a four-byte VLAN tag into the header of each frame. The tag contains a 12-bit “VLAN ID” that identifies the frame’s 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.

Term Definition

Documents

Radware LLB