LP_6.20_UG

LinkProof User GuideSoftware Version 6.20

Document ID: RDWR-LP-V0620_UG1202February, 2012

LinkProof User Guide

2 Document ID: RDWR-LP-V0620_UG1202


Document ID: RDWR-LP-V0620_UG1202 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–2011. 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–2011. 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–2011. 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.

This product contains work derived from the RSA Data Security, Inc. MD5 Message-Digest Algorithm. RSA Data Security, Inc. makes no representations concerning either the merchantability of the MD5 Message - Digest Algorithm or the suitability of the MD5 Message - Digest Algorithm for any particular purpose. It is provided "as is" without express or implied warranty of any kind.

Notice traitant du 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: Statement for Class A VCCI-certified Equipment

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

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



Figure 4: Statement for Class B VCCI-certified Equipment

Translation of Figure 4 - Statement for Class B VCCI-certified Equipment, page 10:

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

KCC KOREA

Figure 5: KCC—Korea Communications Commission Certificate of Broadcasting and Communication Equipment

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

Translation of Figure 6 - Statement For Class A KCC-certified Equipment in Korean, page 10:

This equipment is Industrial (Class A) electromagnetic wave suitability equipment and seller or user should take notice of it, and this equipment is to be used in the places except for home.

SPECIAL NOTICE FOR NORTH AMERICAN USERS

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

RESTRICT AREA ACCESS

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

INSTALLATION CODES

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



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 7: É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 8: Avertissement de sécurité pour les systèmes dotes de deux sources d'alimentation électrique (en chinois)

Traduction de la Figure 8 - 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 9: Déclaration pour l'équipement de classe A certifié VCCI

Traduction de la Figure 9 - 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 10: Déclaration pour l'équipement de classe B certifié VCCI

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

Il s'agit d'un produit de classe B, basé sur la norme du Voluntary Control Council for Interference by Information Technology Equipment (VCCI). S'il est utilisé à proximité d'un poste de radio ou d'une 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.

KCC Corée

Figure 11: KCC—Certificat de la commission des communications de Corée pour les equipements de radiodiffusion et communication.

Figure 12: Déclaration pour l'équipement de classe A certifié KCC en langue coréenne

Translation de la Figure 12 - Déclaration pour l'équipement de classe A certifié KCC en langue coréenne, page 14:

Cet équipement est un matériel (classe A) en adéquation aux ondes électromagnétiques et le vendeur ou l'utilisateur doit prendre cela en compte. Ce matériel est donc fait pour être utilisé ailleurs qu' á la maison.

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 13: Warnetikett Stromschlaggefahr



SICHERHEITSHINWEIS IN CHINESISCHER SPRACHE FÜR SYSTEME MIT DOPPELSPEISUNG

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

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

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

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 15: Erklärung zu VCCI-zertifizierten Geräten der Klasse A

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

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

Figure 16: Erklärung zu VCCI-zertifizierten Geräten der Klasse B

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

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

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

KCC KOREA

Figure 17: KCC—Korea Communications Commission Zertifikat für Rundfunk-und Nachrichtentechnik

Figure 18: Erklärung zu KCC-zertifizierten Geräten der Klasse A



Übersetzung von Figure 18 - Erklärung zu KCC-zertifizierten Geräten der Klasse A, page 18:

Verkäufer oder Nutzer sollten davon Kenntnis nehmen, daß dieses Gerät der Klasse A für industriell elektromagnetische Wellen geeignete Geräten angehört und dass diese Geräte nicht für den heimischen Gebrauch bestimmt sind.

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 ......................................................................................................... 8Document Conventions ............................................................................................... 20

Chapter 1 – Introduction......................................................................................... 31

LinkProof Overview ..................................................................................................... 31

Supported Radware Platforms .................................................................................... 32

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

LinkProof Modules ....................................................................................................... 34Health Monitoring Module .................................................................................................... 35Traffic Redirection Module ................................................................................................... 35Bandwidth Management Module ......................................................................................... 35Security Module ................................................................................................................... 36

IPv6 Support ................................................................................................................ 36

Management Tools ...................................................................................................... 37

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

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

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

Erasing the Configuration File ..................................................................................... 48

Updating Device Software ........................................................................................... 48

Software Versions List ................................................................................................. 49

LinkProof User Guide Table of Contents


Licensing and Upgrading Licenses ............................................................................. 50

Managing Configuration Files ..................................................................................... 52Sending a Configuration File to the Device ......................................................................... 52Downloading a Configuration File ....................................................................................... 53Configuration Error Log Files .............................................................................................. 53

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

Resetting the Device .................................................................................................. 55

Configuring Global Device Parameters ...................................................................... 55

Device Information ...................................................................................................... 56

Device Monitoring ....................................................................................................... 57

Session Table ............................................................................................................. 57Session Table Global Parameters ....................................................................................... 58Session Table Entries ......................................................................................................... 59

Bridging Support ......................................................................................................... 61Bridge Operating Parameters .............................................................................................. 61Bridge Forwarding Table ..................................................................................................... 61Static Forwarding Table ...................................................................................................... 62

LinkProof Global Configuration General ..................................................................... 63

Virtual IP Addresses ................................................................................................... 65Creating Virtual IP Addresses ............................................................................................. 65Virtual IP Translation Ports Exclusion ................................................................................. 66

Device Tuning ............................................................................................................. 67Tuning Statistics Parameters .............................................................................................. 67Tuning Memory Check ........................................................................................................ 68Tuning BWM Parameters .................................................................................................... 68Tuning Classifier Parameters .............................................................................................. 68Tuning Device Table Parameters ........................................................................................ 70Tuning SYN Protection Parameters .................................................................................... 75Tuning Diagnostics Parameters .......................................................................................... 76Tuning Virtual Tunneling Parameters .................................................................................. 76

Device Notifications .................................................................................................... 77CLI Traps ............................................................................................................................ 77Syslog Reporting ................................................................................................................. 77SMTP E-mail Notifications ................................................................................................... 79Configuration Trace ............................................................................................................. 80

DNS-Client Utility ........................................................................................................ 80

Show Tech-Support .................................................................................................... 81

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



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

RADIUS Authentication for Management .................................................................... 93

Logging ........................................................................................................................ 95Event Log ............................................................................................................................. 95SMTP Logging ..................................................................................................................... 95Power Supply Traps ............................................................................................................ 96

APSolute API ............................................................................................................... 97

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

Port Settings ................................................................................................................ 99Port Mirroring ....................................................................................................................... 99Link Aggregation—Port Trunking ..................................................................................... 100Port Rules ......................................................................................................................... 104Rules Table ....................................................................................................................... 105Port Load Balancing Status .............................................................................................. 105

Virtual LAN ............................................................................................................... 106Virtual LANs ...................................................................................................................... 106Supported VLAN Types .................................................................................................... 106IPv6 Pass-through ............................................................................................................ 107Bridging ............................................................................................................................. 109VLAN Example Configuration ........................................................................................... 109Configuring VLANs ........................................................................................................... 110Redundancy with VLANs .................................................................................................. 112VLAN Tagging .................................................................................................................. 112

IP Addressing and Routing ....................................................................................... 116IP Interfaces ...................................................................................................................... 116IP Router Operating Parameters ...................................................................................... 117Viewing and Configuring IP Router IP Interfaces ............................................................. 117Configuring ICMP Interface Parameters ........................................................................... 120Routing ............................................................................................................................. 121Routing Information Protocol ............................................................................................ 123IPv6 Neighbor Discovery .................................................................................................. 125Configuring ARP Parameters ........................................................................................... 129Open Shortest Path First (OSPF) ..................................................................................... 130



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

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

Farm Management ................................................................................................... 138LinkProof Farms ................................................................................................................ 138Farm Load Balancing ........................................................................................................ 144Default 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) ........................................................................ 168Dynamic NAT .................................................................................................................... 169Static NAT ......................................................................................................................... 170No NAT ............................................................................................................................. 171Basic NAT ......................................................................................................................... 171One-IP-for-NAT Support .................................................................................................... 172Static Port Address Translation (Static PAT or SPAT) ...................................................... 174NAT Parameters Summary ............................................................................................... 177IPv6 Prefix-NAT ................................................................................................................ 179

Proximity ................................................................................................................... 185Proximity Introduction ........................................................................................................ 185Proximity Configuration ..................................................................................................... 186

DNS .......................................................................................................................... 191DNS Introduction ............................................................................................................... 191Mapping URLs to Local IP Addresses ............................................................................... 191DNS Response Parameters .............................................................................................. 193DNS for Local Users .......................................................................................................... 194DNS Redundancy ............................................................................................................. 196

Basic Load Balancing ............................................................................................... 197Simple Router Load Balancing Configuration ................................................................... 198Simple Router Load Balancing Configuration With VLAN ................................................. 199Simple One-Leg (Lollipop) Configuration .......................................................................... 200Sandwich Configuration .................................................................................................... 201Single Device Installation .................................................................................................. 202

Load Balancing Weights ........................................................................................... 203



Flow Management .................................................................................................... 203About Flows and Flow Management ................................................................................ 203Default Flow ...................................................................................................................... 204Configuring Flow Management ......................................................................................... 204Flow Policies ..................................................................................................................... 205Typical Flow Configurations .............................................................................................. 208

Client Table .............................................................................................................. 209Client Table Mechanism ................................................................................................... 209Managing Client Tables .................................................................................................... 212Client-Table Logging ......................................................................................................... 217Viewing Client Table Entries Using CLI ............................................................................ 224Client Table View Filters ................................................................................................... 224Filtered Client Table .......................................................................................................... 226Clearing the Client Table Manually ................................................................................... 226

VPN Load Balancing ................................................................................................ 227Network Topology with LinkProof Devices Through Firewalls .......................................... 227Multicast Dispatch ............................................................................................................. 229Clear Client Table (VPN Load Balancing Feature) ........................................................... 229Client Table Overwrite ...................................................................................................... 231

Chapter 5 – Advanced Features .......................................................................... 233

Content Load Balancing ........................................................................................... 233Content Load Balancing Overview ................................................................................... 233Layer 7 Policies ................................................................................................................ 237Content Rules ................................................................................................................... 239Hostname Lists ................................................................................................................. 242

Tunneling .................................................................................................................. 243Layer 2 Tunneling Protocol (L2TP) ................................................................................... 244Generic Routing Encapsulation (GRE) ............................................................................. 244GPRS Tunneling Protocol (GTP) ...................................................................................... 245Multiprotocol Label Switching (MPLS) .............................................................................. 245

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

Event Scheduler ....................................................................................................... 247

Miscellaneous Parameters—Tweaks ....................................................................... 248

Performance Statistics .............................................................................................. 250BWM Policy Statistics ....................................................................................................... 250Element Statistics ............................................................................................................. 253IP Interface Statistics ........................................................................................................ 257NHR Statistics ................................................................................................................... 257

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

Configuration Auditing .............................................................................................. 260



NTP Service ............................................................................................................. 261

RADIUS Service ....................................................................................................... 262

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

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

VRRP Redundancy .................................................................................................. 272Introducing VRRP ............................................................................................................. 273Direct Server Connection with VRRP ................................................................................ 279VRRP with IPv6 Prefix NAT .............................................................................................. 281Configuring Basic VRRP Redundancy .............................................................................. 291VRRP Associated IP Addresses ....................................................................................... 293

Remote Virtual IP Addresses ................................................................................... 294

Chapter 7 – Security ............................................................................................. 297

ACL ........................................................................................................................... 297Configuring ACL Global Parameters ................................................................................. 298Configuring ACL Policy Rules ........................................................................................... 300Viewing Active ACL Policy Rules ...................................................................................... 302Updating ACL Policies ...................................................................................................... 303Viewing and Managing ACL Reports ................................................................................ 303

Ports Access ............................................................................................................. 304

Configuring Access for Physical Ports ...................................................................... 304

SNMP ....................................................................................................................... 305SNMP Global Parameters ................................................................................................. 305SNMP User Table ............................................................................................................. 306SNMP Community Table ................................................................................................... 306SNMP Groups Table ......................................................................................................... 307SNMP Access Table ......................................................................................................... 308SNMP View Table ............................................................................................................. 308SNMP Notify Table ............................................................................................................ 309Target Parameters Table .................................................................................................. 309Target Address Table ........................................................................................................ 310Creating an SNMP User .................................................................................................... 311

Ping Physical Ports ................................................................................................... 312

Configuring the Users Table and Authentication Method ......................................... 312Configuring the Authentication Method ............................................................................. 312Configuring a User in the User Table ................................................................................ 313



SYN Flood Protection ............................................................................................... 313SYN Flood Global Parameters ......................................................................................... 314SYN Flood Protection Policies .......................................................................................... 315SYN Flood Statistics ......................................................................................................... 316Active Triggers .................................................................................................................. 318

Keys and Certificates ................................................................................................ 318Certificates ........................................................................................................................ 318Keys .................................................................................................................................. 319Configuration .................................................................................................................... 319Certificates Workflows ...................................................................................................... 319Certificates Table .............................................................................................................. 321Export Certificates from a Device ..................................................................................... 322Import Certificates to a Device .......................................................................................... 323Default Values for Certificates .......................................................................................... 323

Chapter 8 – Bandwidth Management .................................................................. 325

Bandwidth Management Overview ........................................................................... 325Application Classification .................................................................................................. 326Classification Mode ........................................................................................................... 326

Managing Bandwidth Management Global Parameters ........................................... 326

Bandwidth Management Policies ............................................................................. 328Bandwidth Management Policy Mechanism ..................................................................... 328Bandwidth Management Classification Criteria ................................................................ 329Bandwidth Management Rules ......................................................................................... 330Default Policy .................................................................................................................... 331Policy Trees—Hierarchical Bandwidth-Management Policies ......................................... 331Managing Bandwidth Management Policies ..................................................................... 333

Services .................................................................................................................... 342Basic Filters ...................................................................................................................... 343AND Group Filters ............................................................................................................ 350OR Group Filters ............................................................................................................... 351Viewing Active Services .................................................................................................... 352

Networks .................................................................................................................. 353Configuring Networks ....................................................................................................... 353Viewing Active Networks .................................................................................................. 354

Port Groups .............................................................................................................. 354Configuring Port Groups ................................................................................................... 355Viewing Active Port Groups .............................................................................................. 355

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

VLAN Tag Groups .................................................................................................... 356Configuring VLAN Tag Groups ......................................................................................... 357Viewing Active VLAN Tag Groups .................................................................................... 357



MAC Groups ............................................................................................................. 358Configuring MAC Groups .................................................................................................. 358Viewing Active MAC Groups ............................................................................................. 358

Updating Policies—Classes ..................................................................................... 359

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

Protocol Discovery .................................................................................................... 362Protocol Discovery Overview ............................................................................................ 362Protocol Statistics Global Parameters ............................................................................... 363Protocol Discovery Policies ............................................................................................... 363Viewing the Protocol Discovery Statistics ......................................................................... 365

Port Bandwidth ......................................................................................................... 365

Cancelling Interface Classification ............................................................................ 365

Example Time-based BWM Policy ........................................................................... 366Configuring the Example BWM Policy ............................................................................... 367Configuring the Example Start-Event Schedule ................................................................ 367Configuring the Example Finish-Event Schedule .............................................................. 368Associating the Start- and Finish-Event Schedules with the Example BWM Policy .......... 368Activating the Latest Changes for the Example BWM Policy ............................................ 369

Chapter 9 – Health Monitoring............................................................................. 371

Health Monitoring—Introduction .............................................................................. 371Health Monitoring Module ................................................................................................. 371Response Level ................................................................................................................ 371Checked Elements ............................................................................................................ 372Health Checks ................................................................................................................... 372Methods ............................................................................................................................ 372Binding and Groups .......................................................................................................... 372

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

Health Monitoring Server Table ................................................................................ 393Configuring a Diameter Health Check ............................................................................... 394

Farm Health Checks ................................................................................................. 398



Appendix A – Regular Expressions .................................................................... 399

Appendix B – Predefined Basic Filters ............................................................... 401

Appendix C – IPv6 Fundamentals ....................................................................... 411

IPv4 Versus IPv6 ...................................................................................................... 411

Name Resolution ...................................................................................................... 412

Internet Protocol Version 6 (IPv6) ............................................................................ 413Internet Control Message Protocol for IPv6 (ICMPv6) ...................................................... 413

IPv6 Address Autoconfiguration ............................................................................... 415Autoconfigured Address States ........................................................................................ 415Types of Autoconfiguration ............................................................................................... 415Autoconfiguration Process ................................................................................................ 415IPv6 Routing ..................................................................................................................... 416IPv6 Configuration Items .................................................................................................. 418IPv6 Neighbor Discovery .................................................................................................. 419New Header Format ......................................................................................................... 420Large Address Space ....................................................................................................... 421Efficient and Hierarchical Addressing and Routing Infrastructure .................................... 421Stateless and Stateful Address Configuration .................................................................. 421Built-in Security ................................................................................................................. 421Better Support for Quality of Service (QoS) ...................................................................... 421New Protocol for Neighboring Node Interaction ............................................................... 421Extensibility ....................................................................................................................... 422

Appendix D – Glossary......................................................................................... 423


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

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

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

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

• LinkProof Overview, page 31

• Supported Radware Platforms, page 32

• Basic LinkProof Concepts, page 32

• LinkProof Modules, page 34

• Management Tools, page 37

LinkProof 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 32

• Multihomed Network, page 33

• Farms, page 33

• Servers, page 33

• Content Rules, page 33

• NAT, page 33

• Proximity, page 34

• DNS Load Balancing, page 34

• Redundancy, page 34

Multihoming 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—Ensures 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—Hides IP addresses of internal hosts for outbound traffic. LinkProof will choose an IP address that is associated with the router/ISP that was selected for this session. By choosing translated source IP addresses according to the selected router, return delivery issues will not be encountered.

• IPv6 Prefix-NAT—Performs IPv6 WAN load balancing of network traffic across different IPv6 routers. Prefix-NAT replaces the Unique Local IPv6 Address prefix to that of the external router. This enables outside access and persistency of the incoming connection based on the ISP router from which the traffic is coming. You can use LinkProof and Prefix-NAT in various deployment scenarios to provide a modern network solution for complex networks.

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.

Proximity works only for router farms, not firewall farms.

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. LinkProof supports VRRP redundancy.

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

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



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

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

• Application Security

• DoS Shield

• SYN Flood Protection

IPv6 SupportLinkProof supports a dual-stack IPv6 and IPv4 environment, including IPv4 and IPv6 link load-balancing functionality.

See the release notes for information on supported features and limitation.

For background information on IPv6, see Appendix C - IPv6 Fundamentals, page 411.

For more information about load-balancing IPv6 traffic in LinkProof, see IPv6 Prefix-NAT, page 179.

LinkProof supports for the following types of traffic:

• Pure IPv4—LinkProof handles traffic from IPv4 clients to IPv4 routers, IPv4 WAN connections, or IPv4 servers.

• Pure IPv6—LinkProof handles traffic from IPv6 clients to IPv4 routers, IPv4 WAN connections, or IPv4 servers.

• Mixed:

— LinkProof redirects dual-stacked clients to IPv4 routers if they request an IPv4 request.

— LinkProof redirects dual-stacked clients to IPv6 routers if they request an IPv6 request

LinkProof supports the following features for all types of traffic (pure IPv4, pure IPv6, mixed):

• Layer 4 traffic management and load balancing

• Layer 7 traffic management and load balancing (for IPv4 traffic all)

• High availability (health monitoring, VRRP redundancy)

The following IPv6 RFCs are supported in this version:

• 1981: Path MTU Discovery

• 2375: Multicast address assignment

• 2428: FTP extensions for IPv6 and NATs

• 2460: IPv6 Specification

• 2464: IPv6 over Ethernet

• 3142: IPv6 to IPv4 transport relay translator (TRT)

• 3363: Representing IPv6 addresses in DNS

• 3364: Tradeoffs in DNS for IPv6

• 3484: Default address selection

• 3587: Global Unicast address format

• 3596: DNS extensions for IPv6



• 3879: Deprecating site-local addresses

• 3901: DNS IPv6 transport operational guidelines

• 4001: Textual conventions for Internet network addresses

• 4007: IPv6 scoped address architecture

• 4074: Common misbehavior against DNS queries for IPv6 addresses

• 4193: Unique Local IPv6 Unicast Addresses

• 4291: IPv6 Addressing Architecture

• 4292: MIB for IP forwarding table

• 4293: MIB for IP

• 4294: IPv6 node requirements

• 4443: ICMPv6

• 4861: Neighbor discovery

• 4862: Stateless address auto-configuration

• 5095: Deprecation of type 0 routing headers in IPv6

• 5156: Special-use IPv6 addresses

Management 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 40

• Device Interfaces, page 43

• Erasing the Configuration File, page 48

• Updating Device Software, page 48

• Software Versions List, page 49

• Licensing and Upgrading Licenses, page 50

• Managing Configuration Files, page 52

• Updating Policies—Activating the Latest Changes, page 54

• Resetting the Device, page 55

• Configuring Global Device Parameters, page 55

• Device Information, page 56

• Device Monitoring, page 57

• Session Table, page 57

• Bridging Support, page 61

• LinkProof Global Configuration General, page 63

• Virtual IP Addresses, page 65

• Device Tuning, page 67

• Device Notifications, page 77

• DNS-Client Utility, page 80

• Show Tech-Support, page 81

• Diagnostics, page 82

• Management Interfaces, page 89

• RADIUS Authentication for Management, page 93

• Logging, page 95

• APSolute API, page 97

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.

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:

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

5. Enter the values for the menu items according to Table 1 - Startup Configuration Menu, page 41 and Table 2 - SNMP Startup Configuration Submenu, page 42.

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

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

Parameter ValueBits per second 19200

Data bits 8

Parity None

Stop bits 1

Flow Control None

LinkProof User GuideDevice Management


7. 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 3 - Interface Numbering Conventions, page 43.

Default: MNG-1

Note: The value is case-sensitive.

Default router IP address

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

Default: 0.0.0.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 42.

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, DES1

Default: DES

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, SHA2 , MD53

Default: MD5

6 Authentication Password

The password for the SNMPv3 authentication.

Default: No password

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

Table 1: Startup Configuration Menu

Item Additional CLI Text Remark



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.

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

1 – Data Encryption Standard2 – Secure Hash Algorithm3 – Message-Digest algorithm 5

Table 3: Interface Numbering Conventions

Physical Interface Type OnDemand Switch VL Port Index Range1

1 – The value is case-sensitive using CLI.

OnDemand Switch 2 Port Index Range1

OnDemand Switch 3 Port Index Range1

RJ-45 port for management

G6/MNG12

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

MNG 1–23

3 – For management only.

MNG 1–23

GbE RJ-45 ports G1–G54

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

G1–G125

5 – For traffic or management.

G1–G85

SFP GbE ports G7–85 G9–G125

Dual (SFP or RJ-45) GbE ports6

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

G13–165

10GbE XFP ports XG-1–XG-45

Table 2: SNMP Startup Configuration Submenu

# Item Additional CLI Text Description



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.

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.



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 Redundancy On platforms that support two management ports, you can define the management ports to be a part of the same trunk (T-MNG). If this is the case, one port is active while the other port is in backup. Failure of the active port will seamlessly activate the backup port. The two management ports will share the same IP address.

OnDemand Switch Management Ports 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.

Table 4: 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

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



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 TableA Layer 2 Interface is defined as any interface with its own MAC address - physical port, trunk, VLAN. You can configure the administrative status of each interface, monitor and interface statistics.

IPv6 interfaces can be defined alongside IPv4 ones for all Layer 2 interfaces, (physical ports, VLANs and trunks). Each Layer 2 interface has IPv6 parameters that apply to all the IPv6 interfaces defined for that interface. Each IPv6 interface is also associated with a prefix. The prefix is the successor of the net mask used in IPv4. There may be no more than one IP address for the same prefix in the same Layer 2 interface. This restriction is for management convenience and applies also for IPv4.

You can view the status and settings for interfaces using all management tools.

The status information comprises the following:

• Interface 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 mange the L2 interfaces using CLI

Use the command net l2-interface.

To manage the L2 interfaces using Web Based Management

1. Select Device> Layer 2 Interface. The Layer 2 Interface Table pane is displayed.

2. From the Device MAC to Port Correlation drop-down list, choose one of the following:

— 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

Note: The MAC address of each port on the platform is the base MAC address plus the port index.

3. Select the Interface Index to edit. The Layer 2 Interface Table Update pane is displayed.




Table 5: L2 Interface Table Parameters

Parameter DescriptionInterface Index (Read-only) The 1nterface index identifier.

Interface Description (Read-only) A textual string containing information about the interface.

interface Type (Read-only) The type of interface. Additional values are assigned by the Internet Assigned Numbers Authority (IANA), through updating the syntax of the textual convention.

Interface MTU The size, in bits, of the largest packet that can be sent or received on the interface. For interfaces that are used for transmitting network datagrams, this is the size of the largest network datagram that can be sent on the interface.

Default: 1500

Interface Speed (Read-only) An estimate, in bits per second, of the current bandwidth.

MAC Address (Read-only) The MAC address of the interface.

Interface Admin Status The status of the interface.

Values: Up, Down

Operational Status (Read-only) The operational status of the router.

Values: Up, Down

Interface Last Change (Read-only) The sysUpTime at the time the interface entered its current operational state. If the current state was entered prior to the last re-initialization of the local network management subsystem, this object contains a zero value.

ifINOctets (Read-only) The number of incoming octets (bytes) through the interface including framing characters.

InUcastPkt (Read-only) The number of packets delivered by this sub-layer to a higher (sub-) layer, which were not addressed to a multicast or broadcast address at this sub-layer.

InNUcastPkt (Read-only) The number of packets delivered by this sub-layer to a higher (sub-) layer, which were addressed to a multicast or broadcast address at this sub-layer.

ifInDiscards (Read-only) The number of inbound packets chosen to be discarded even though no errors had been detected to prevent their being deliverable to a higher-layer protocol. One possible reason for discarding such a packet could be to free up buffer space.

ifInErrors (Read-only) One of the following:

• For packet-oriented interfaces—The number of inbound packets that contained errors preventing them from being deliverable to a higher-layer protocol.

• For character-oriented or fixed-length interfaces—The number of inbound transmission units that contained errors preventing them from being deliverable to a higher-layer protocol.

ifOutOctets (Read-only) The total number of octets (bytes) transmitted out of the interface, including framing characters.

OutUcastPkt (Read-only) The total number of packets that higher-level protocols requested be transmitted, and which were not addressed to a multicast or broadcast address at this sub-layer, including those that were discarded or not sent.



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.

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.

OutNUcastPkt (Read-only) The total number of packets that higher-level protocols requested be transmitted, and which were addressed to a multicast or broadcast address at this sub-layer, including those discarded or not sent.

ifOutDiscards (Read-only) The number of outbound packets which were chosen to be discarded even though no errors had been detected to prevent their being transmitted. One possible reason for discarding such a packet could be to free up buffer space.

ifOutErrors (Read-only) One of the following:

• For packet-oriented interfaces—The number of outbound packets that could not be transmitted because of errors.

• For character-oriented or fixed-length interfaces—The number of outbound transmission units that could not be transmitted because of errors.

Table 5: L2 Interface Table Parameters

Parameter Description

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



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

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

To update device software

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

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

Note: The password is case-sensitive.

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

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

5. Do one of the following:

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

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

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

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

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

Table 6: Software Versions Table Columns

Parameter DescriptionName The name of the version

Index The index of the version in the Software List.



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.

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.

Valid The validity of the version.

Values: TRUE, FALSE

Active The current status of the version.

Values: TRUE, FALSE

Version The version number.

Table 6: Software Versions Table Columns




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

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

To upgrade a license

1. Select Device > License Upgrade. The License Upgrade pane is displayed. The current license string is displayed in the Insert Your License Code field.

2. Do the following:

— In the Insert Your License Code text box, type the new license code.

— In the Insert your Throughput License Code text box, type the device throughput level license.

3. Click Set. The Reset the Device pane is displayed. You must reset the device to validate the license.

4. Click Set. The reset may take a few minutes. A success message is displayed upon completion.

Table 7: 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.



Managing Configuration FilesThis section contains the following topics:

• Sending a Configuration File to the Device, page 52

• Downloading a Configuration File, page 53

• Configuration Error Log Files, page 53

Sending a Configuration File to the Device

To send a configuration file to the device

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

Table 8: 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.



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.


Table 9: Device Global Parameters

Parameter DescriptionDescription (Read-only) General description of the device.

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 (Read-only) Time elapsed since the last reset.

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 (Read-only) The software version.

Hardware Version (Read-only) The hardware version.



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 10: 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



Device Monitoring

To view the Device Monitoring information

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

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.

Table 11: 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.



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 12: 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



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.

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

Table 13: 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.

Table 12: Session Table Global Parameters




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.

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.


Aging Type The aging type of the entry.

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

Table 14: 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 prefix The source IP prefix.

Dest IP prefix The destination IP prefix.

Source Port The source port of the session.

Default: Any

Dest Port The destination port.

Default: Any

Source IP prefix length The length of the source IP prefix.

Dest IP prefix length The length of the destination IP prefix.

Table 13: Session Table Entries Parameters




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


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.

Table 15: 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 16: Bridge Forwarding Table Parameters

Parameter DescriptionMac Address The MAC address of the node.



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.

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.


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.

Table 17: 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 16: Bridge Forwarding Table Parameters




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 18: 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 19: 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. When two routes on the device are derived from local interfaces, the device has two options.

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.

• disable—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.

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.





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

This section includes the following:

• Creating Virtual IP Addresses, page 65

• Virtual IP Translation Ports Exclusion, page 66

Creating Virtual IP 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.

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.





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.

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.

Table 20: 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



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

• Tuning Statistics Parameters, page 67

• Tuning Memory Check, page 68

• Tuning BWM Parameters, page 68

• Tuning Classifier Parameters, page 68

• Tuning Device Table Parameters, page 70

• Tuning SYN Protection Parameters, page 75

• Tuning Diagnostics Parameters, page 76

• Tuning Virtual Tunneling Parameters, page 76

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

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

Table 21: 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 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.


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.

Table 22: BWM Tuning Parameters

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

Values: 256–150,000

Default: 1024

Policy Leaves Percent The percentage of hierarchical BWM leaves (that is, hierarchical BWM policies without a child policy) out of the total number of policies that the device supports.

Values: 40–100

Default: 100

BW per Traffic Flow sessions tracking

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

Values: 16–100,000

Default: 2048

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

Values: 64-128,000

Default: 256



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.

To configure the Classifier tuning parameters

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


Table 23: 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



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.

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: 1024

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

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 23: Classifier Tuning Parameters




The changes to the tuning configuration take effect after a device reset.

To view a list of values for LinkProof tuning tables, log onto the Radware Web site; and then, navigate to Support > Documentation > Product (LinkProof) > Document Type (Tuning Table).

To configure the tuning parameters for the device tables

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


Table 24: 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 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 and OnDemand Switch 2 with 4 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


• 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

static PAT Table The maximum number of static PAT addresses that can be configured on the device. Static PAT enables a one-to-many port-address-translation mapping, which are used mostly for inbound connections for server/services via a single IP address.

Values: 20–20,000

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 25: 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 Virtual Tunneling ParametersVirtual Tunneling tables are used to define the Virtual Tunneling tuning parameters.

The changes to the tuning configuration take effect after a device reset.

To view virtual tunneling tuning parameters, you must first enable the Virtual Tunneling Admin Status option.

Caution: It is strongly advised that device tuning only be carried out after consulting with Radware Technical Support.

Note: Before activating Virtual Tunneling, ensure that Smart NAT functionality and Use Connectivity Checks are selected from the Health Monitoring Global Parameters pane.

To configure the virtual-tunneling tuning parameters

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


The following table describes the virtual-tunneling tuning settings.

Table 26: 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



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 77

• Syslog Reporting, page 77

• SMTP E-mail Notifications, page 79

• Configuration Trace, page 80

CLI Traps

To send traps by CLI, Telnet, and SSH

Use the command manage terminal traps-outputs set-on. For console only, use the command manage terminal traps-outputs set normal.

When connected to any Radware product through a serial cable, the device generates traps when events occur.

For example, if a next-hop router fails, LinkProof generates the following error message:10-01-2007 08:35:42 WARNING NextHopRouter 10.10.10.10 Is Not Responding to Ping.

A device can send traps to all CLI users This option enables you to configure whether the device sends traps only to the serial terminal or also to SSH and Telnet clients.

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

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

Table 26: Virtual Tunneling Settings

Table Description



To configure sending traps to a syslog server

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


Table 27: 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

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



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.

To configure e-mail notifications

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


Table 28: 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



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

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.


Table 29: DNS Client Parameters

Parameter DescriptionDNS Client Specifies whether the DNS client is enabled.

Primary DNS Server The IP address of the primary DNS server.

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



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.


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

Table 30: DNS Client Parameters

Parameter DescriptionHostname The domain name for the specified IP addresses.

IPv4 Address The IPv4 address for the specified domain name.

IPv6 Address The IPv6 address for the specified domain name.



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 88) and the relevant options are enabled.

Diagnostic tools stop in the following cases:

• You stop the relevant task.

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


• Traffic Capture Tool, page 82

• Trace-Log, page 84

• Diagnostic Tools Files Management, page 87

• Diagnostics Policies, page 88

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.


Table 31: 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 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



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.

LinkProof uses the following format for Trace-Log files:

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


• Trace-Log Tool Configuration, page 84

• Diagnostics Trace-Log Message Format, page 85

• Trace-Log Modules, page 86

Trace-Log Tool Configuration

To configure the Trace-Log tool using Web Based Management

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


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

Table 31: Capture Tool Configuration Parameters




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

To configure the diagnostics Trace-Log message format using Web Based Management

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


Table 32: 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 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

Table 33: 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.



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.

To configure the parameters of the Trace-Log modules using Web Based Management

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

The table in the pane comprises the following columns:

— Name—The name of the module.

Values:

• BWM • GENERIC• HMM• LCD

— Status—The 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

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


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 d module is included in the Trace-Log message.

Table 33: Diagnostics Trace-Log Message Format Parameters




Diagnostic Tools Files Management LinkProof can store the output of the diagnostic tools in RAM and in the CompactFlash.

If the device is configured to store the output in the CompactFlash, when the data size in RAM reaches its limit, the device appends the data chunk from RAM to the file on the CompactFlash drive. For each enabled diagnostic tool, LinkProof uses two temporary files. When one temporary file reaches the limit (1 MB), LinkProof stores the information in the second temporary file. When the second temporary file reaches the limit (1 MB), LinkProof overwrites the first file, and so on. When you download a CompactFlash file, the file contains both temporary files.

Use the Diagnostic Tools Files Management pane to download or delete files from the RAM or CompactFlash.

To download or delete Trace-Log data using Web Based Management

1. Select Services > Diagnostics > Files. The Diagnostic Tools Files Management pane is displayed.

The pane contains two tables, Files On RAM Drive and Files On Main Flash. Each table comprises the following columns:

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

Table 34: 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.

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.



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.


Table 35: 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).

Note: You cannot set the Outbound Port Group when the value of the Trace-Log Status parameter is Enabled.

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



Management InterfacesThis section describes the management interfaces that LinkProof supports and contains the following topics:

• Configuring a Telnet Management Interface, page 89

• Configuring Web Server Management Interfaces, page 90

• Configuring an SSH Interface for Management, page 92

• Configuring an FTP Interface for Management, page 93

Configuring a Telnet Management Interface You can access LinkProof via Telnet.

You can configure Telnet access using Web Based Management or CLI.

Note: If three incorrect logins are entered, for the following 10 minutes, the device accepts no further login attempts from the user.

To configure a Telnet management interface

1. Select Services > Management Interfaces > Telnet. The Telnet Parameters pane is displayed.


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

Note: You cannot set the Outbound Port Group when the value of the Trace-Log Status parameter is Enabled.

Table 35: Diagnostics Policies Parameters




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 36: 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



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.


Table 37: 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.

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 38: 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



Web Services To provide customers with the capability to develop enhanced application monitoring, customized application delivery network management applications, and advanced automation tools, Radware provides the Web Services interface on APSolute API. APSolute API is an open-standards-based SOAP (XML) API. Integration with APSolute API allows customers a comprehensive view of the LinkProof devices performance including historical data analysis and trending, performance diagnostics, availability reports, and automation of maintenance operations as well as fine-tuning of LinkProof for optimal application delivery based on parameters external to LinkProof.

To configure the Web Services parameter

1. 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 39: 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 ManagementLinkProof provides additional security by authenticating users accessing the device for management purposes. Before a management session starts, LinkProof can authenticate the user with a RADIUS server. These servers determine whether a user can access LinkProof management—using CLI, Telnet, SSH, or WBM.

If a RADIUS server is not available or the user is not defined in the RADIUS server, LinkProof uses the User Table to authenticate access.

Caution: To enable remote management access to the device when no RADIUS server is available, at least one user with read-write access must be configured in the local User Table. If no user with a read-write access is configured in the local User Table, when no RADIUS server is available, only a physical connection to the device is possible.

If the RADIUS authentication server successfully authenticates the remote user, the LinkProof device verifies the privileges of the remote user and authorizes the appropriate access level.

To determine the access level of the remote user, LinkProof uses the value of the Service-Type attribute (AVP 6) in the Access-Accept response. LinkProof supports the Service-Type values 6 and 255. The value 6 (as specified in the RADIUS RFC) specifies Administrative (read-write) access. The value 255 specifies restricted (read-only) access. The value 255 must be defined in the dictionary of the RADIUS servers as the Vendor-Specific (AVP 26) Radware (Vendor ID 89) Service-Type value.

Table 40: 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



If the Service-Type attribute is not present in the Access-Accept response or its value is not 6 or 255, LinkProof grants the access level according to the specified Default Authorization value (Read-Write, Read-Only, or No-Access).

Example RADIUS Dictionary RowsAttribute Service-Type 26 [vid=89 type1=26 len1=+1 data=integer]

Value Service-Type Read-Only 255

To configure RADIUS Authentication for device management

1. Select Security > Users. The User Table and Authentication pane is displayed.

2. From the Authentication Method drop-down list, select RADIUS and Local User Table; and then, click Set.

3. Select Services > Radius. The Radius Parameters pane is displayed.

4. Configure the following parameters; and then, click Set.

Table 41: RADIUS Authentication Parameters

Parameter DescriptionMain Radius IP Address The IP address of the primary RADIUS server.

Main Radius Port No. The access port number of the primary RADIUS server.

Values: 1645, 1812

Default: 1645

Main Radius Secret The authentication password for the primary RADIUS server.

Backup Radius IP Address The IP address of the backup RADIUS server.

Backup Radius Port No. The access port number of the backup RADIUS server.

Values: 1645, 1812

Default: 1645

Backup Radius Secret The authentication password for the backup RADIUS server.

Radius Timeout The time, in seconds, that the LinkProof device waits for a reply from the RADIUS server before retrying, or, if the Radius Retries value has been reached, before the device considers the server to be off line.

Values: 1–10

Default: 1

Radius Retries The number of connection retries to the RADIUS server before the LinkProof device considers the server to be off line.

Values: 1–3

Default: 2



LoggingThis section includes details on viewing and enabling various logs for use with LinkProof, and includes these topics:

• Event Log, page 95

• SMTP Logging, page 95

• Power Supply Traps, page 96

Event 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 send SMTP log messages asynchronously to designated locations. You must set a logging output location to view any logs.

LinkProof can send SMTP traps in e-mail messages to specified users. Each user receives e-mail messages according to the specified severity level (Info, Warning, Error or Fatal), which is configured in the User Table.

Radius Client Life Time The time, in seconds, for client authentication. After the lifetime expires, the device re-authenticates the user.

Values: 2–3600

Default: 30

Default Authorization The access level that the LinkProof device grants a user who is authenticated by a RADIUS server but whose user privileges were not provided or unknown user privileges were provided.

Values: Read-Write, Read-Only, No-Access

Default: Read-Write

Table 41: RADIUS Authentication Parameters




To configure an SMTP client

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


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.

Table 42: 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.

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 43: 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



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.


Chapter 3 – Basic Switching and RoutingThis chapter describes switching and routing in the context of LinkProof.


• Port Settings, page 99

• Virtual LAN, page 106

• IP Addressing and Routing, page 116

Port SettingsThis section describes LinkProof features that handle traffic and port management and contains the following topics:

• Port Mirroring, page 99

• Link Aggregation—Port Trunking, page 100

• Port Rules, page 104

• Port Load Balancing Status, page 105

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 TrunkingThis section contains the following topics:

• Link Aggregation—Global Configuration, page 102

• Link Aggregation Trunk Table, page 102

• Link Aggregation Port Table, page 103

Link aggregation, also known as port trunking, is a method of increasing bandwidth by combining physical network links into a single logical link. Link aggregation increases the capacity and availability of the communications channel between devices (both switches and end stations) by using Fast Ethernet and Gigabit Ethernet technology.

Multiple parallel physical links between two devices can be grouped together to form a single logical link. Link aggregation also provides load balancing where processing and communications activities are distributed across several links in a trunk. This prevents single link overloading.

Treating multiple LAN connections as one aggregated link offers the following advantages:

• Higher link availability.

• Increased link capacity.

• Improvements in existing hardware. Upgrading to higher-capacity link technology is not necessary.

LinkProof supports port trunking according to the IEEE 802.3ad standard for link aggregation.

Table 44: 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 45 - Supported Link-Aggregation Configurations for OnDemand Switch 2, page 101.

The following table lists combinations for link aggregation supported on the OnDemand Switch 2 platform.

Note: On OnDemand Switch VL platforms, combinations for link aggregation are not limited.

Table 45: 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—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 46: 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 port rules have been configured on the device. You cannot modify values in the table.

The Rules Table pane displays a table with the following columns:

• Port 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 106

• Supported VLAN Types, page 106

• IPv6 Pass-through, page 107

• Bridging, page 109

• VLAN Example Configuration, page 109

• Configuring VLANs, page 110

• Redundancy with VLANs, page 112

• VLAN Tagging, page 112

Virtual 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 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 19: 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 20: 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 110

• Configuring the Virtual LAN Table and VLAN Port Table, page 111

Configuring the Ethernet Type for User-defined VLANs

To configure the Ethernet type for user-defined VLANs

1. Select Device > VLAN Parameters. The VLan Parameters pane is displayed.


Table 47: 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 48: 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 49: 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 265.

VLAN TaggingThis section describes VLAN tagging and contains the following topics:

• VLAN Tagging Support, page 112

• Using VLAN Tagging, page 113

• Setting a VLAN Tag for an IP Interface, page 114

• Configuring VLAN Tagging, page 115

VLAN Tagging 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.

Table 50: 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



The ports that interconnect the switches, for example port 10 on each switch, belong to all of the VLANs on that switch. In this case, the switch needs to know to which VLAN to send traffic coming from port 10, as this port belongs to all the VLANs.

Notes>> VLAN tags can also be attached to IPv6 interfaces to apply to IPv6 traffic and behave

exactly like IPv4 interfaces.

>> If you want 8021.q information, you need to capture what is being sent to the LinkProof on the neighboring switch. Therefore 802.1q header information cannot be displayed in the packet capture.

Using VLAN 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 21: 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 51: 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 Interfaces, page 116

• IP Router Operating Parameters, page 117

• Viewing and Configuring IP Router IP Interfaces, page 117

• Configuring ICMP Interface Parameters, page 120

• Routing, page 121

• Routing Information Protocol, page 123

• IPv6 Neighbor Discovery, page 125

• Configuring ARP Parameters, page 129

• Open Shortest Path First (OSPF), page 130

IP Interfaces

Note: LinkProof supports both IPv4 and IPv6 IP interfaces.

An IP interface on LinkProof is an IP address associated with a layer 2 interface (physical port, VLAN or trunk). The IP interface prefix length (for IPv6) netmask (for IPv4) defines the subnet attached to that layer 2 interface.

The IP interfaces serve the following purposes:

• Allows LinkProof to select the layer 2 interface via which traffic sent from the device must be sent.

• Serves as source address for traffic initiated by LinkProof (for management purposes, proprietary protocols between LinkProof devices, health checks, and so on).

• Serves as default route for hosts in the attached subnet. However, Radware recommends that in redundant configurations, Virtual IP interfaces are used as default route.

• Serves as primary IP address for Virtual Routers (VRRP). Radware recommends that Virtual IP interfaces be used as the primary IP address.

LinkProof performs routing between the subnets defined by the IP interfaces.

Link-local addresses are network addresses which are intended only for communications within one segment of a local network (a link) or a point-to-point connection. They allow addressing hosts without using a globally-routable address prefix. Routers will not forward packets with link-local addresses.

Link-local addresses are often used for network address configuration when no external source of network addressing information is available. This addressing is accomplished by the host operating system using a process known as stateless address autoconfiguration. This is possible in both IPv4 and IPv6.

IPv4 addresses in the range 169.254.0.0/16 are assigned automatically by a host operating system when no other IP addressing assignment is available for example, from a DHCP server. In IPv6, link-local addresses are required and are automatically chosen with the FE80::/10 prefix.



IP Router Operating Parameters

To configure IP router parameters

1. Select Router > IP Router > Operating Parameters. The IP Router Parameters pane is displayed.


Viewing and Configuring IP Router IP Interfaces Use the IP Interface Table pane to view and configure the IP interfaces.

To view and configure an IP Interface

1. Select Router > IP Router > IP Interfaces. The IP Interface Table window is displayed.


— 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 52: 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.

Values: 11–100,000,000

Note: Changing the value affects only newly created ARP entries.

ARP Proxy Specifies whether the device responds to ARP requests for nodes located on a different direct sub-net. The device responds with its own MAC address.

Values:

• 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

ICMP Error Burst Limit

The maximum ICMP error messages, in packets, emitted in a single burst.

Default: 64

Advanced Fast Forwarding Status

Specifies whether the IP Fast Forward Table is used. When enabled, the table holds MAC-address information of servers only (pre-defined in the LinkProof farms) and not clients.


Default: Disable



Table 53: IP Interface Parameters

Parameter DescriptionIP Address The IP address of the interface.

If Number The interface identifier of the Layer 2 interface.

Address Origin (Read-only) The origin of the address.

Values:

• other—The address may include a random chosen address or well-known value for example, an IANA assigned anycast address.

• manual—The address was manually configured.

• dhcp—The address was assigned to this system by a DHCP server.

• linklayer—The address was created by IPv6 stateless autoconfiguration.

Status (Read-only) The current status of the IP interface.

Values:

• Preferred—This is a valid address that can appear as the destination or source address of the packet.

• Deprecated—This is a valid but deprecated address that should no longer be used as a source address in new communications, but packets addressed to such an address are processed as expected.

• Invalid—This is not valid address which should not appear as the destination or source address of a packet.

• Inaccessible—The address is not accessible because the interface to which this address is assigned is not operational.

• Unknown—This address is unknown.

• Tentative—The uniqueness of the address on the link is being verified.

• Duplicate—The address has been determined to be non-unique on the link and so must not be used.

• Optimistic—The address is available for use, subject to restrictions, while its uniqueness on a link is being verified. This value is designed to minimize address configuration delays and to reduce disruption.

Prefix Length The prefix length that defines the subnet attached to this IP interface.

For IPv4, the prefix length varies between subnets to subnets, and renumbering subnets can be expensive. With IPv4, the allocation varies by the size of the site, which can be a problem when you migrate from one ISP to another.

IPv4 values: 0–32

For IPv6, the prefix is a decimal value that indicates the number of contiguous, higher-order bits of the address that make up the network portion of the address. For example, 10FA:6604:8136:6502::/64 is a possible IPv6 prefix. The prefix length for an IPv6 subnet will always be less than 64. It allows you to place as many IPv6 devices as the underlying network medium allows.

IPv6 values: 3–127

Prefix Onlink Flag Specifies whether the addresses with that prefix can be reached directly without going through a router. The prefix list in the Neighbor Discovery cache table defines a set of IP address ranges that the host can reach. The prefix flags are L for on-link, and A for autonomous.

Default: true



To show or hide link-local address entries in the IP Interface Table

1. Select Router > IP Router > IP Interfaces. The IP Interface Table window is displayed.

2. From the Show link local address entries drop-down list, select one of the following:

— Enabled—Show link-local address entries in the IP Interface Table.

— Disabled—Hide link-local address entries in the IP Interface Table.

Prefix Autonomous Specifies whether the prefix came from stateless autoconfiguration. The prefix list in the Neighbor Discovery cache table defines a set of IP address ranges that the host can reach. The prefix flags are L for on-link, and A for autonomous.

Default: Disabled

Preferred Lifetime The router advertisement preferred life time, in seconds.

Values: 1–Infinite

Default: Infinite

Valid Lifetime The router advertisement valid life time, in seconds.

Values: 1–Infinite

Default: Infinite

Fwd Broadcast

(This parameter is available only for IPv4 interfaces.)

Specifies whether the device forwards incoming broadcasts to this interface.

Default: Enabled

Broadcast Addr

(This parameter is available only for IPv4 interfaces.)

Specifies whether to fill the host ID in the broadcast address with ones or zeros.

Values:

• One Fill—Fill the host ID in the broadcast address with ones.

• Zero File—Fill the host ID in the broadcast address with zeros.

Default: One Fill

VLAN Tag When multiple VLANs are associated with the same switch port, the switch must identify to which VLAN to direct incoming traffic from that specific port. VLAN tagging provides an indication in the Layer 2 header that enables the switch to make the correct decision. Enter the tag to be associated with this IP interface.

One IP Mode (Router Interface Only) Specifies whether the device uses the One-IP-for-NAT feature.

This parameter works only for IPv4 interfaces.

For more information, see One-IP-for-NAT Support, page 172.


Default: Disable

Peer IP Address The IP address of the interface on the peer device, which is required in a redundant configuration—that is, a cluster for high availability.Default: 0.0.0.0

Table 53: IP Interface Parameters





Note: The link-local address are generated based on IPv6 RFC compliance.

Configuring ICMP Interface ParametersUse the ICMP Interface Parameters pane to configure Internet Control Message Protocol (ICMP) parameters of an existing interface.

To edit the ICMP parameters of an interface

1. Select Router > IP Router > Interface Parameters. The ICMP P Router Interface Parameters pane is displayed.

2. From the ICMP Interface Parameters table, click the IP address of the relevant interface. The ICMP Interface Parameters Update pane is displayed.


Table 54: IP Router Interface Parameters

Parameter DescriptionIP Address (Read-only) The IP address of the interface.

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

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.



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.


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

Table 54: IP Router Interface Parameters




To update a Routing Table entry


2. Select a Destination Address. The Routing Table Update pane is displayed.


Table 55: 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 56: 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.


Values:





Protocol Displays (read-only) the specified Type read-only.

Metric Specifies the number of hops to the destination network.



Configuring a Default Gateway

Note: You can set up a backup default gateway for LinkProof.

To configure a default gateway


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.

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.

Table 57: 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.



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



IPv6 Neighbor DiscoveryIPv6 Neighbor Discovery (NDisc) is a set of messages and processes that determine relationships between neighboring nodes. NDisc replaces Address Resolution Protocol (ARP), Internet Control Message Protocol (ICMP) Router Discovery, and ICMP Redirect, which are used in IPv4, and provides additional functionality. NDisc is described in RFC 2461, Neighbor Discovery for IP Version 6 (IPv6).

Table 59: 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.




Routers use NDisc to do the following:

• Advertise their presence, host configuration parameters, and on-link prefixes.

• Inform hosts of a better next-hop address to forward packets for a specific destination.

Nodes use NDisc to do the following:

• Both resolve the link-layer address of a neighboring node to which an IPv6 packet is being forwarded and determine when the link-layer address of a neighboring node has changed.

• Determine whether IPv6 packets can be sent to and received from a neighbor.

Configuring the Neighbor CacheThe neighbor cache keeps track of the neighbors on the local links with which AppDirector is in contact. The neighbor cache is the IPv6 parallel of the ARP table. The neighbors are either dynamically discovered using neighbor discovery protocol or statically configured.

To create a Neighbor Cache entry

1. Select Router > IPv6 Neighbor Discovery > Neighbor Cache. The Neighbor Cache window is displayed.

2. Click Create.


Table 60: Neighbor Cache Parameters

Parameter DescriptionInterface Index Interface identifier for neighbor cache entry.

IP Address Neighboring node’s IPv6 address.

MAC Address MAC address corresponding to neighboring node’s IPv6 address.

Type The type of the neighbor-cache entry.

Values:

• Dynamic

• Invalid

• Local

• Other

• Static

Default: Static

State

(This parameter is exposed only for existing entries)

The number of times this neighbor relationship has changed state, or an error has occurred.

Values:

• Reachable

• Stale

• Delay

• Probe

• Invalid

• Unknown

• Incomplete



Configuring Duplicate Address DetectionDuplicate Address Detection (DAD) is the process by which a node determines that an IPv6 address considered for use is not already in use by a neighboring node. (This is equivalent to the use of gratuitous ARP frames in IPv4.) The DAD process consists of sending a neighbor discovery whenever the device is assigned a new IP address, asking for a neighbor with the same address.

The device performs the DAD procedure for each newly configured IPv6 address: IP interface, VIP, VIPIm, and client NAT addresses belonging to a subnet configured on the device (matching IP interface). DAD is not performed for VIP, VIPIs, and client NAT addresses that do not have a matching IP interface (that is, orphan addresses).

DAD is also performed for each configured IP addresses (IP interfaces, non-orphan VIPs, VIPIs and client NAT addresses) on device startup.

To configure Duplicate Address Detection

1. Select Router > IPv6 Neighbor Discovery > Duplicate Address Detection. The Duplicate Address Detection window is displayed.


IPv6 Router AdvertisementWith IPv6, routers can be dynamically discovered and adopted as default gateways by the host nodes on the same local link, rather than having to statically configure the default gateway and change it on every network restructure. This process also allows the node to automatically assign its own global unicast IP address, by having the router publish a prefix for the subnet to be attached to the host’s link local address. This is called stateless auto-configuration and comes as an alternative to DHCP, which is stateful, because it has to keep record of the assigned IP address. Nevertheless, DNS server addresses must still be obtained from DHCP servers, but this does not incur state maintenance.

The LinkProof device can periodically send Router Advertisements (RAs) on each IP interface according to a random interval, between specified minimum and maximum times. The managed device also sends these messages in response to Router Solicitation messages.

To configure IPv6 Router Advertisement

1. Select Router > IPv6 Neighbor Discovery > IPv6 Router Advertisement. The IPv6 Router Advertisement window is displayed.

2. Click the link of the required interface.


Table 61: Neighbor Cache Parameters

Parameter DescriptionRetransmits Number Enables the DAD process and determines the number of times that the

DAD Neighbor discovery message is transmitted, where value of zero means DAD is disabled.



Table 62: IPv6 Router Advertisement Parameters

Parameter DescriptionInterface Index (Read-only) The identifier of the interface on the physical device.

Send RA Messages Specifies whether the device sends IPv6 Router Advertisement (RA) messages.

Default: true

Max RA Interval The maximum time, in seconds, between Router Advertisements that the device sends.

Values: 4–1800

Default: 600

Min RA Interval The minimum time, in seconds, between Router Advertisements that the device sends.

Values: 3–1350

Default: 200

Note: The value must be no greater than 75 percent of the specified Max RA Interval.

Managed Address Config

Specifies whether the messages that the device sends include the flag that indicates whether the hosts should use stateful autoconfiguration to obtain addresses.

Default: false

Note: Router Advertisements contain two flags indicating what type of stateful autoconfiguration (if any) should be performed.

Other Configuration Flag

Specifies whether the messages that the device sends include the flag that indicates whether the hosts should use stateful autoconfiguration to obtain additional information (excluding addresses).

Default: false

Note: Router Advertisements contain two flags indicating what type of stateful autoconfiguration (if any) should be performed.

MTU The Maximum Transmission Unit, which is the largest size, in bytes, of physical packets that a network can transmit. The device divides messages larger than the MTU into smaller packets before being sending them.

Values:

• 0—Specifies the maximum value

• 1–1000000000

Default: 0

Reachable Time Specifies the time, in seconds, that the router can reach a remote IPv6 node (neighbor) after some reachability confirmation event has occurred.

Values:

• 0—Specifies the maximum time

• 1–3600000

Default: 0



Configuring ARP Parameters

To configure ARP parameters

1. Select Router > ARP Table. The ARP Table pane is displayed.

2. Click Create. The ARP Table Create pane is displayed.


Retransmit Time The time, in seconds, between sending one neighbor discovery (solicitation) and the next.

The time between retransmissions of neighbor solicitations to a neighbor when resolving the address or when probing the reachability of a neighbor. (Read-only.)

Values:


• 1–3600000

Default: 0

Current Hop Limit The current, advertised, hop limit of the IPv6 router component on the device.

Values:

• 0—Specifies the maximum limit

1–255Default: 64

Default Router Lifetime How long, in minutes, a host should consider the advertised address to be valid. After the time elapses, and the host has not received a router advertisement from the server, the route marks the advertised addresses as invalid.

Values:


1–9000Default: 1800

Table 63: ARP Parameters

Parameter DescriptionInterface Index The interface number on which the station resides.

MAC Address The MAC address of the station.

Table 62: IPv6 Router Advertisement Parameters




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.

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.

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.

Table 63: ARP Parameters




OSPF Operating Parameters

To set the OSPF Operating Parameters

1. Select Router > OSPF > Operating Parameters. The OSPF Operating Parameters pane is displayed.


Table 64: 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 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 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.



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.

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 66: 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.



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.

Link State ID Identifies a piece of routing domain described by the advertisement. It can be a router ID or an IP address.

Router ID Identifies the originating router in autonomous system.

Sequence Number for link. Use this to detect old and duplicate link state advertisements. The larger the sequence number the more recent the advertisement.

Parameter 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 185

• DNS, page 191

• Basic Load Balancing, page 197

• Load Balancing Weights, page 203

• Flow Management, page 203

• Client Table, page 209

• VPN Load Balancing, page 227

LinkProof Multihoming 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 22: Example Multihoming Outbound Traffic

Figure 22 - Example Multihoming Outbound Traffic, page 136 shows a scenario where a user on the local network (for example, IP 1.1.1.80) sends an outbound HTTP request to the Internet. The traffic is processed as follows:

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

NAT:100.1.1.21

Local Network

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 23: Example Multihoming Inbound Traffic

Figure 23 - Example Multihoming Inbound Traffic, page 137 shows a scenario where an external user sends a request to www.radware.com that is hosted by internal server 10.1.1.50 represented externally by 100.1.1.21 via ISP1 and 200.1.1.21 via ISP2. The traffic is processed as follows:

1. The external user sends DNS query that is forwarded by DNS servers to LinkProof.

2. If this is a domain name for which LinkProof is authoritative server, LinkProof classifies traffic according to configured routing policies (flow policies) to select the group of WAN links (router farm) that will be used for this traffic.

3. LinkProof selects an inbound link for this traffic from the router farm chosen in the previous step, based on:

— Link availability measured according to user-defined criteria (health checks)

— Link metrics measured according to user-defined criteria (traffic amount, proximity, cost)

4. Once load balancing decision is reached, it is recorded in LinkProof tables for use on the rest of the session traffic.

5. A DNS response is sent back to the external user with the IP that represents the internal server via the selected link (ISP)—for example, 100.1.1.21.

6. The external user sends HTTP request to 100.1.1.21. LinkProof replaces the destination IP address with the internal server address (10.1.1.50 in our case).

7. The reply from the internal server will be forwarded via the same link the request arrived, to ensure persistency, after the source IP (10.1.1.50) is replaced by the NAT IP (100.1.1.21).

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.

Note: For multihoming with IPv6, see IPv6 Prefix-NAT, page 179.

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

— Define flows and flow policies—if routing policies are required. For the procedure, see Configuring Flow Policies, page 206.

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

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

b. Map the URLs for which LinkProof is authoritative server to the internal server IP addresses, Mapping URLs to Local IP Addresses, page 191.

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 in the same farm.

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 67: 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

• Destination IP 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.

Default: Disable

NAT Mode Specifies whether LinkProof does network address translation on the packets for IPv4 addresses or Prefix-NAT for IPv6 addresses.


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

To configure extended parameters for a farm

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 68: Extended Parameters for a Farm of Logical Routers and/or Logical Firewalls

Parameter DescriptionFarm Name (Read-only) The name of the farm.

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 68: 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.

LinkProof supports the following Dispatch Methods:

• Cyclic, page 144

• Fewest Number of Users, page 144

• Fewest Number of Local Users, page 144

• Hashing, page 145

• Least Local Traffic, page 145

• Least Number of Bytes, page 145

• Least Number of Local Bytes, page 145

• Least Traffic, page 145

• NT-1 and NT-2, page 146

• Private-1 and Private-2, page 147

• Response Time, page 148

• Customized Hash, page 148

• Multicast Dispatch, page 229

• Source IP Hashing, page 149

• Layer 3 Hashing, page 149

• Destination IP Hashing, page 149

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 TrafficYou 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 BytesYou 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 69: 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 70: 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 69: 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 371).

• 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 70: 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.

MulticastWhen the Multicast Dispatch Method is used, after the return packet reaches the lower LinkProof device, a Multicast is sent with the return packet to both VPN gateways. The gateway that responds first, is the one with an established VPN session. LinkProof forwards the traffic to the VPN gateway and the session is not interrupted. For more information, see Multicast Dispatch, page 229.

This feature is supported only for IPv4 addresses.

Note: The OnDemand Switch VL platform does not support the Multicast Dispatch Method.

Source IP 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.

Destination IP HashingWhen the Destination IP Hashing Dispatch Method is specified, LinkProof distributes the traffic between the Routers/Firewalls according to the destination IP address. Using this method, you ensure that traffic to the same destination is always sent through the same NHR.

Caution: When the Destination IP Hashing Dispatch Method is specified, the remote LinkProof device must use the same dispatch method.



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

Table 71: 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.



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.

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.

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.



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

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 24: 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

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)



provided by the firewall server selected for this internal server. The source IP address on reply traffic from the internal servers is changed by the firewall server to the NAT address and by the LinkProof to the VIP address (see the following figure).

Figure 25: Example Transparent NAT Firewall

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.

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



The first time an IP address is configured as belonging to a farm, the device automatically configures this farm as the default farm for the server IP. The farm that is automatically configured as the default farm for a server IP can be changed.

To modify parameters of a default farm

1. 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 72: 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 (see Farm Management, page 138), the process of adding and configuring servers in the LinkProof farm consists of two main stages:

• Adding physical servers

• Setting up farm servers

Table 73: 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. When the option is disabled, only the source MAC is selected. Typically, you enable this option only when using port rules and when Next Hop Routers use the same MAC on different physical ports.

Configuring a Logical Router

To create a logical router

1. 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 74: 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 connection limit.

• The value range depends on your device. For information, see the LinkProof Tuning Table document.



AdminStatus The user-defined management status of the server, which you can change at any stage of 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 74: 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 75: 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.



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.

Values:



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 75: Logical Firewall Parameters




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.


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 76: 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 configuring the Connection Limit for the physical server, ensure that the Connection Limit in the farm servers with the same Server name is lower or equal to the Connection Limit in the physical server. The total number of active sessions that run simultaneously on the farm servers must not be higher than the Connection Limit value defined on the physical server.

Values:



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.






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.

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





Figure 26: 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 26 - Potential Issues When Not Using Cluster Support, page 165, using the Cluster Support feature you can configure MAC 11, MAC 22, and MAC 33 to be associated with server NHRA, enabling the device to recognize traffic with these MAC addresses as traffic from server NHRA. When LinkProof forwards traffic to the cluster server, it uses the destination MAC address that was discovered via an ARP to the logical server IP address (MAC A in the example). However, traffic coming from the cluster will be allocated to the cluster server if the source MAC or its IP is statically configured as belonging to this server.

To configure a cluster server using an IP address, the MAC address must be set to 000000000000. To configure a cluster server using a MAC address, the IP address must be set to 0.0.0.0.

Notes>> In many cases, you may not be required to load balance traffic to the cluster, but rather

to perform NAT on the traffic to and from the cluster. In this case, the cluster needs to be configured as a LinkProof server (NHR or firewall).

>> The LinkProof server IP should be the Virtual IP of the cluster or, in the case of WOC devices, the IP of the router beyond the WOC device.

>> For Hot Standby Router Protocol (HSRP) clusters, where the virtual IP address cannot be the IP address of any of the cluster servers, you can configure the IP addresses of the cluster servers so that their MAC address will be discovered using ARP. This allows you to replace a server in a cluster without changing the LinkProof configuration (if the new server has the same IP address as the old one).

>> For VRRP clusters where the virtual IP address is usually the IP address of one of the cluster servers, you can statically configure the MAC addresses of the cluster servers.

>> For WOC devices, you need to statically configure the MAC address of the WOC device.

Router 1–MAC 11Router 2–MAC 22Router 3–MAC 33

LinkProof

NHRB–IP B; MAC B

NHRA–IP A; MAC A



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.

Table 77: 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.



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.

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 168

• Dynamic NAT, page 169

• Static NAT, page 170

• No NAT, page 171

Table 78: 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.



• Basic NAT, page 171

• One-IP-for-NAT Support, page 172

• Static Port Address Translation (Static PAT or SPAT), page 174

• NAT Parameters Summary, page 177

• IPv6 Prefix-NAT, page 179

Network Address Translation (SmartNAT) The main issue in a multihomed network is managing the IP addressing scheme for the different providers.

There are two common possibilities that can be deployed with regard to the IP scheme that the internal network uses:

• A single IP network number is assigned to the internal 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 67.

>> SmartNAT in IPv6 is a challenge, since there is no simple way to perform IPv6-to-IPv6 NAT—that is, hiding a network behind a single IP address. The logic behind IPv6 states that all the addresses are routable and accessible on the public Internet. There is no need for one-to-many translations, because there is no expected depletion of IP address in the foreseeable future. For more information, see IPv6 Prefix-NAT, page 179.

Dynamic NATThe Dynamic NAT feature enables LinkProof to hide various IPv4 network elements located behind LinkProof. Using this feature, LinkProof replaces the original source IP and source port of a packet that is with the configured NAT IP and a dynamically allocated port before forwarding the request to the farm.

The network elements whose addresses are translated can be servers or other local hosts. You can set different NAT addresses for different ranges of intercepted addresses.

For example, traffic from subnet A is translated using IP address 10.1.1.1 and traffic from subnet B is translated using IP address 10.1.1.3.

To configure dynamic NAT

1. Select LinkProof > Smart NAT > IPv4 NAT > Dynamic NAT. The Dynamic NAT Table pane is displayed.

2. Click Create. The Dynamic NAT Table Create pane is displayed.


Table 79: 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.



Static NATUse Static NAT is ensure delivery of specific IPv4 traffic to a particular server on the internal network. For example, LinkProof uses Static NAT, meaning predefined addresses mapped to a single internal host, to load balance traffic to the host among multiple transparent traffic connections. This ensures that the return traffic uses the same path, and also allows traffic to that single host to use multiple ISPs transparently. You assign multiple Static Smart NAT addresses to the internal server, typically one for each ISP address range.

Note: Static NAT addresses cannot be part of the Dynamic NAT IP pool.

To configure Static NAT

1. Select LinkProof > Smart NAT > IPv4 NAT > Static NAT. The Static NAT Table pane is displayed.

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


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 80: 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.

Table 79: Dynamic NAT Parameters




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 > IPv4 NAT > NAT Parameters Summary. The NAT Parameters Summary pane is displayed.

2. From the Exclude Static NAT for Local Network drop-down list, select Disable.

3. Click Set.

Enable Ping to Multiple Static 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 IPv4 addresses that belong to a range of one of the farm servers.

Traffic to and from these hosts should not be translated if the traffic is forwarded to this farm server.

If you do not configure any NAT address for a host via a farm server, that farm server will not be used by inbound traffic to that host if the host IP resolution is provided through DNS. To use a farm server for traffic from the host when NAT is not required, use the No NAT configuration.

To configure No NAT

1. Select LinkProof > Smart NAT > IPv4 NAT > No NAT. The No NAT Table pane is displayed.

2. Click Create. The No NAT Table Create pane is displayed.


Basic NATBasic NAT enables a one-to-one IPv4 NAT mapping for occasional users, based on local IP ranges and destination applications. A pool of NAT addresses for each server is configured per range of local IP addresses and destination port. Whenever a client with an IP address within the range initiates a session to any host with the relevant application port, a NAT address is allocated to this session, and

Table 81: 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 > IPv4 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 IPv4 addresses used for LinkProof configurations. When One-IP-for-NAT is enabled, you can define Smart Dynamic NAT and IP addresses that are identical to the devices’ IP addresses. LinkProof registers all incoming and outgoing traffic to distinguish between management traffic, Health Monitoring, or Proximity, and forwarded traffic. It is possible to enable One-IP enabled on several IP interfaces and to disable 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.

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 to maintain connectivity and functionality. For a regular non-VLAN bridge, each router connected to a LinkProof device needs several IP addresses to maintain functionality such as network connectivity, NAT, and so on.

To reduce the usage of public IP address in the depleting IPv4 address space, LinkProof provides the One-IP feature.

One-IP enables LinkProof to use its external IP address for the following purposes:

• Dynamic NAT, so the internal users can be dynamically NATed behind the LinkProof interface public address

• Inbound connections using SPAT (Static Port Address Translation)



With One-IP not enabled, for a LinkProof device connected to two external routers, each connection will use the following configuration:

So, with One-IP not enabled, in the case of a LinkProof device connected to two routers, where the internal network requires to access the Internet, six public IP addresses are required, comprised of the following:

• Two public addresses on LinkProof interfaces

• Two public addresses on router interfaces

• Two public addresses for Dynamic NAT on each LinkProof interface

With One-IP enabled, for a LinkProof device connected to two external routers, each connection will use the following configuration:

So, with One-IP not enabled, in the case of a LinkProof device connected to two routers, where the internal network requires to access the Internet, four public IP addresses are required, comprised of the following:

• Two public addresses on LinkProof interfaces

• Two public addresses on router interfaces

Using the One-IP feature, we saved two public addresses using instead the LinkProof external public IP addresses.

You can do the same for inbound connections where SPAT will be used for explicitly defined services (for example, SMTP port 25, HTTP port 80) using the same external public address, thus providing services to two servers behind the LinkProof.

Table 82: LinkProof Connected to Two External Routers—One-IP Not Enabled

Functionality Requires IP Address Minimal Number of IP Address RequiredLinkProof physical interface (connection to router)

Yes, public IP One per router

Router internal IP address (connection to LinkProof)


Static NAT IP addresses (that is, servers behind LinkProof for inbound and outbound connectivity)

Yes, public IP per server

One or more per server

Dynamic NAT (internal users accessing the Internet)

Yes, public IP per network

One per network

Table 83: LinkProof Connected to Two External Routers—One-IP Enabled

Functionality Requires IP Address Minimal Number of IP Address RequiredLinkProof physical interface (connection to router)


Router internal IP address (connection to LinkProof)


Static NAT IP addresses (that is, servers behind LinkProof for inbound and outbound connectivity)

Yes, public IP per server

One or more per server

Dynamic NAT (internal users accessing the Internet)

Yes, public IP per network

Zero—LinkProof uses the physical interface IP



To configure Smart NAT with One-IP using Web Based Management

1. Select Router > IP Router > Interface Parameters. The IP Router Interface Parameters pane is displayed.

2. Click Create. The Interface Parameters Create pane is displayed.

3. From the One IP Mode 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 169.

Static Port Address Translation (Static PAT or SPAT)Static Port Address Translation (Static PAT or SPAT) allows one-to-one mapping between local and global IPv4 addresses. With Static PAT, multiple internal hosts can share a single IP address for communication, thus saving public IP address usage.

Static PAT is actually a subset of NAT (RFC 2663), but it is usually referred to as Static PAT when discussing Port Forwarding.

With Static PAT, you can configure static mapping of UDP or TCP ports of 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 27: 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 > IPv4 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 172), the LinkProof IP address for management (its own IP) will be used for SPAT. This might create a conflict with the above services if they are also used for internal servers. If you try to use any ports in conflict with the above ports, then the following error message is issued:

Can not bind port 80: Port is bound to device WEB service (UDP or TCP). Change service port first

Notes>> SPAT is supported with TCP, UDP, and ICMP.

>> SPAT with One-IP-for-NAT is supported on TCP and UDP only.

>> By design, SPAT is limited to one (1) server behind the SPAT device using a single port for a single service. Only a single public service with port 80 HTTP (for example) can be exposed per public IP address. In this way, an organization using PAT and a single IP cannot run more than one of the same type of public service behind a PAT (for example, two public web servers using the default port 80).

>> VPN (IPsec) Pass-through with SPAT: In order to configure VPN traffic pass-through together with SPAT, you need to define a SPAT entry with UDP port 500 (IKE). The device will allow AH, ESP protocols to undergo SPAT and pass through the device as well.

>> To resolve conflicting IP addresses, SmartNAT methods have been set according to priority and are set as follows:

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 SummaryUse the NAT Parameters Summary pane to do the following:

• View all IPv4 Smart NAT tables.

• Create new entries and update existing entries.

• Configure how the LinkProof device implements Static NAT on local-to-local traffic. If you want Static NAT only on one side, keep the defaults, that is, keep the Exclude Static NAT for Local Network and Always Translate Static NAT Destination to Local IP options disabled.

To configure how the device implements Static NAT on local-to-local traffic

1. Select LinkProof > Smart NAT > IPv4 NAT > NAT Parameters Summary. The NAT Parameters Summary pane is displayed.


Caution: You must not enable both Exclude Static NAT for Local Network and Always Translate Static NAT Destination To Local IP options.



To configure NAT features using the NAT Parameters Summary pane

Select LinkProof > Smart NAT > IPv4 NAT > NAT Parameters Summary. The NAT Parameters Summary pane is displayed.

For information on the tables in the NAT Parameters Summary pane, see the following:

— Dynamic NAT, page 169

— Static NAT, page 170

— No NAT, page 171

Table 87: Exclude Static NAT for Local Network, and Always Translate Static NAT Destination To Local IP

Parameter DescriptionExclude Static NAT for Local Network Specifies whether the device does not use Static NAT on

traffic from local hosts for which Static NAT is configured.

Values:

• enable—Traffic from a local host for which Static NAT is configured does not undergo NAT when forwarded to a network for which NAT is enabled. Use this option when you want LinkProof not to perform Static NAT on local traffic—typically, for security purposes.

• disable—Traffic from a local host for which Static NAT is configured undergoes NAT when forwarded to a network for which NAT is enabled; but the traffic to the local network is not translated. For example, suppose LinkProof routes traffic from server x to client y, both of which are in local networks. When there is a Static NAT definition on x, LinkProof changes the packet to be StaticNAT(x) to y.

Default: disable

Always Translate Static NAT Destination to Local IP

Specifies whether LinkProof always translates Static NAT destinations to local IP address.

Values:

• enable—LinkProof changes the destination IP address from the Static NAT IP address to the local IP address when the configuration specifies also to perform Static NAT on the source IP address. That is, if the configuration uses Static NAT on both host x and host y, traffic is sent from x to StaticNAT(y), and the traffic should be translated to StaticNAT(x) to y. This means that LinkProof needs remove the Static NAT on the destination and add Static NAT on the source. Enable this option if you want to use Static NAT both on the source and on the destination.

• disable—LinkProof does not change the destination IP address from the Static NAT IP address to the local IP address when the configuration specifies also to perform Static NAT on the source IP address.

Default: disable



— Basic NAT, page 171

— Static Port Address Translation (Static PAT or SPAT), page 174

IPv6 Prefix-NATPrefix-NAT performs IPv6 WAN load balancing—using address replacement, sending traffic to various ISPs, and load-balancing the load.

In IPv6, there is no common practice for IPv6-to-IPv6 NAT. One reason is that due to the massive number of addresses, there is no reason to hide or replace internal addresses with external addresses. In addition, when IPv6 was designed, many of the problems associated with NAT traversal (for example, UDP, IPSec, and so on) were considered irrelevant. For these reasons and others, NAT was not planned or standardized in IPv6 (although there are several pending RFC drafts).

Note: For background information on Internet Protocol version 6 (IPv6), see Appendix C - IPv6 Fundamentals, page 411.

IPv6-Address Structure and Network PrerequisitesAn IPv6 address is 128 bits long, in the format 2020:1020:1001:1000:0001:0002:0003:0004.

As defined by IANA, the following two ranges are reserved:

• Global Unicast Address (GUA)—2000::/3

• Unique Local Address (ULA)—FC00::/7

Using internal and external IPv6 addresses requires the following:

• ULAs have already been configured by the network administrator. The administrator must ensure that the internal IPv6 network (the network behind the LinkProof device) uses internal addresses (as described in RFC 4193). ULAs are in the format FC00:AAAA:BBBB:CCCC:0001:0002:0003:0004.

Note: From the perspective of network design, the logic is analogous to RFC 1918 in IPv4, where using internal IP addresses is recommended.

• Each external router is assigned a public IPv6 addresses—that is, a GUA.

Figure 28 - Global Unicast Address, page 180 shows the structure of a Global Unicast Address. In a Global Unicast Address, the global routing prefix is assigned to an ISP by IANA. The site-level aggregator (SLA), or subnet ID, is assigned to a customer by the service provider. The LAN ID



represents individual networks within the customer site, and it is administered by the customer. The Host or Interface ID has the same meaning for all unicast addresses. It is 64 bits long and is typically created using the EUI-64 format.

Figure 28: Global Unicast Address

Note: According to IANA regulations, customers are assigned IPv6 addresses with prefixes from /48 to /64. The smallest network prefix is /64 (which is somewhat analogous to class C in IPv4). ISPs dedicate the /48 prefix to customers.

Figure 29 - Unique Local Address Structure, page 180 shows the ULA structure.

Figure 29: Unique Local Address Structure

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

Steps in Configuring Prefix-NAT Configuring Prefix-NAT using Web Based Management (WBM) comprises the following steps:

1. Configuring the IPv6 interfaces (internal, and router-bound).

2. Configuring the farm, and enabling NAT in the configuration of the farm. In the configuration of the farm, you must ensure that the value of the NAT Mode parameter is Enable. (The default value of the NAT Mode parameter is Disable.) The NAT Mode parameter specifies whether the LinkProof device does network address translation on the packets for IPv4 addresses or Prefix-NAT for IPv6 addresses.

3. Configuring the IPv6 routers.



Example IPv6 Topology and Prefix-NAT ConfigurationDue to the nature of the IPv6 address scheme, the following scenario presents a simplistic approach. According to IANA, the LIR/RIR address assignment should be /48 for subscribers (including private housing). This enables each subscriber to configure about 216 networks. These numbers are immense, so the scenario uses a simple address scheme based on IPv6 subnetting.

Consider the following scenario, which is shown in Figure 30 - Example LinkProof IPv6 Topology, page 181:

• LinkProof is connected to the following two IPv6 service providers:

— ISP A dedicates the following public addresses: 2030:2020:1000::/48

— ISP B dedicates the following public addresses: 2040:1020:2000::/52

• The network administrator has followed IANA recommendations and has subnetted the internal network using ULA.

• In addition, the network administrator has subnetted the external routers accordingly.

Figure 30: Example LinkProof IPv6 Topology

Notes>> The use of the /55 prefix to subnet the /48 network is arbitrary. In real life, subnetting

will usually be based on the need for free networks as well as the existing topology.

>> The Prefix-NAT feature supports network ranges from /64 to /48.Prefix NAT is allowed as long as the number of internal IPv6 address is smaller than or equal to the number of external IPv6 addresses. So, for example, when the external router is configured with a /64 range, using a ULA /48 for Prefix-NAT is not allowed. When the public IPv6 address range of the external router is /59, using a ULA /59 for Prefix-NAT is allowed.

>> The translation is done per address. So, for example, an IPv6 ULA address with the address fc00:1002:fc01:3000:2000::1001/48 will be translated on the external interface using 2030:2020:1000::/48 as 2030:2020:1000:3000:2000::1001.

>> The routers are all defined in a single router farm.

>> The routers are all set as active, although it is not necessary for the functionality of the Prefix-NAT feature.



Table 89 - Router Definitions for Example IPv6 Topology, page 182 lists the router definitions based on the example topology shown in Figure 30 - Example LinkProof IPv6 Topology, page 181 and Table 88 - LinkProof Interface Definitions for Example IPv6 Topology, page 182.

Figure 31 - Configuration of Example Static Prefix-NAT Entry in WBM, page 182 and Figure 32 - Example Static Prefix-NAT Table in WBM, page 182 show the following Static Prefix-NAT configuration in Web Based Management:

• The entire /59 ULA will be replaced when accessing the IPv6 Internet using ISP A.

• The range of ULA starting from ::1001 ending with 2001 will be replaced with the prefix of ISP B when accessing the IPv6 Internet.

Figure 31: Configuration of Example Static Prefix-NAT Entry in WBM

Figure 32: Example Static Prefix-NAT Table in WBM

IPv6 Prefix-NAT CalculatorLinkProof provides the IPv6 Prefix-NAT Calculator to predict the outcome of an internal IPv6 address (that is, a ULA), passing through the LinkProof device and being translated to a GUA. The calculator is needed to calculate the external router IPv6 address-especially when the internal prefix is different from the external router prefix. Using the IPv6 Prefix-NAT calculator is extremely important when working with predefined IPv6 addresses (such as external VRRP addresses).

Note: Although Radware recommends adopting the IPv6 ULA concept as detailed in the RFC, the IPv6 Prefix-NAT calculator also supports internal public IPv6 address of the 2000::/3 (Global Unicast range).

Table 88: LinkProof Interface Definitions for Example IPv6 Topology

Role IP Address Prefix Length

IF VLAN Tag

Status Peer IP Address

Preferred Lifetime and Valid Lifetime

ISP B 2030:1020:2000:a0::1001 59 G-11 0 Preferred :: Infinite

ISP A 2030:2020:1000:200::1001 55 G-5 0 Preferred :: Infinite

Internal LAN fc00:1002:fc01:3000:2000::1001 59 G-2 0 Preferred :: Infinite

Table 89: Router Definitions for Example IPv6 Topology

Router Name IP Address OperStatus Weight Farm Name

ISP A 2030:2020:1000:200::1000 Active 1 IPv6Routers

ISP B 2030:1020:2000:a0::1000 Active 1 IPv6Routers



There can be two cases where the prefix of the internal address is translated to the prefix of the external IPv6 address.

• Case 1—The internal prefix is identical to the external-router prefix. It is simple to understand and manually calculate the result IP address (that is, the public IPv6 address) that will be seen by the Internet as the source of the internal packet. The replacement happens on each IPv6 source address passing through the LinkProof device that the IPv6 Prefix-NAT policy identifies.

• Case 2—The internal prefix is different from the external-router prefix. Here, calculating the result IP address (that is, the public IPv6 address) is complex; it involves several mathematical calculations. The IPv6 Prefix-NAT calculator can do the calculation for you.

The IPv6 Prefix-NAT calculator works only in CLI.

Syntax:

lp smartnat ipv6nat calc <LocalIPv6Addr> <RouterIPv6InternalAddr> <RouterIPv6Prefix>

where:

• <LocalIPv6Addr> is the local IPv6 address.

• <RouterIPv6InternalAddr> is the router IPv6 internal address.

• <RouterIPv6Prefix> is the router IPv6 prefix.

Example lp smartnat ipv6nat calc fc00:1002:fc01:3000:2000::1001 2030:2020:1000:200::1000 55

Result:

The nat address is: 2030:2020:1000:200:2000::1001

Configuring the Prefix-NAT Parameters SummaryThe Prefix-NAT Parameters Summary pane includes the parameter Block ULA Address on Edge Router. By default, the option is enabled (according to the recommendation in RFC 4193). When the option is enabled, the device blocks ULAs from crossing the border of the LinkProof device.

To configure a Static Prefix-NAT entry

1. Select LinkProof > Smart NAT > IPv6 Prefix-NAT > Prefix-NAT Parameters Summary.

2. From the Block ULA Address on Edge Router drop-down list, choose one of the following:

— Enable—The device blocks ULAs from crossing the border of the LinkProof device.

— Disable—The device does not block ULAs from crossing the border of the LinkProof device.

3. Click Set.



Configuring Static Prefix-NAT Table EntriesThe Static Prefix-NAT Table pane contains the configurations of the Static Prefix-NAT entries. Each entry specifies how one ULA is translated in the IPv6 public Internet.

To configure a Static Prefix-NAT entry

1. Select LinkProof > Smart NAT > IPv6 Prefix-NAT > Static Prefix-NAT Table.


— To create a new entry, click Create.

— To modify an entry, click the relevant link.


Table 90: Static Prefix-NAT Table Parameters

Parameter Description From Local IP (Mandatory) The first IP address in the internal network that uses

Prefix-NAT. When a value for To Local IP is specified, this value must be the first IP address in the internal network that uses Prefix-NAT. When a value for Range Defined by Prefix is specified, this value can be the first IP address in the internal network that uses Prefix-NAT.

To Local IP (Optional. Mutually exclusive with Range Defined by Prefix.) The last IP address in the range. When a value is specified for this parameter, the device translates the addresses in the specified range (From Local IP-To Local IP). When no value is specified for this parameter, the device translates all the addresses starting from the specified value for From Local IP.

Server Name The IPv6 routers for the Prefix-NAT entry.

Values: The IPv6 routers that are defined in the routers definition as having an IPv6 address. This includes all IPv6 routers from all farms. IPv4-only routers are not exposed in the drop-down list.

Range Defined by Prefix (Optional. Mutually exclusive with To Local IP.) When specified, the network is defined according to the value for the From Local IP parameter and the network prefix. This enables LinkProof to translate all the IPv6 addresses on the local interface.

The value can be less than or equal to the value of the actual prefix of the router. So, for example, if the router is defined with prefix /55 and the internal network is defined with prefix /55, the administrator can configure any value between /55 and /128 (single address).

Replaced With Prefix (Read-only) The Global Unicast Prefix associated with the router with which the LinkProof device will replace the ULA’s prefix. LinkProof calculates the value according to the router specified in the Server Name field and the IPv6 address of the external LinkProof interface.

Redundancy Mode Specifies whether the prefix represents a main (regular) or backup device.

Values: regular, backup

Default: regular



ProximityThis section describes LinkProof’s ability to detect network proximity and contains the following:

• Proximity Introduction, page 185

• Proximity Configuration, page 186

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 ACKs and ICMP Echo requests) to ensure accurate measurements.

The type of checks used for proximity is configurable to allow users more control of the device and generate maximum performance from the links.

Notes>> Proximity works only for router farms, not firewall farms.

>> LinkProof can perform proximity checks through up to 10 routers.

>> In the dynamic proximity table, only the best three (3) routers are recorded for each checked subnet.



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 91: 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.

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 the servers or routers that were defined as backup in the grouping tables. This determines whether there is proximity data for a specific destination via this the server or router. This functionality is required when some of your WAN links are restricted (for example domestic access only).

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.



Setting Proximity Check Parameters

To configure Proximity Checks

1. Select LinkProof > Proximity > Proximity Parameters > Proximity Checks. The Proximity Checks pane is displayed.


Table 92: 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:





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.




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.


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 93: 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 92: 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 191

• Mapping URLs to Local IP Addresses, page 191

• DNS Response Parameters, page 193

• DNS for Local Users, page 194

• DNS Redundancy, page 196

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

2. 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 94: 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

Local IPv6 Address The IPv6 address of the local host.

Table 95: Dynamic-Host-to-Local-IP Mapping Parameters

Parameter DescriptionDynamic Host Name The URL with wildcards to be mapped.

Local IP Address The IPv4 address of the local host.

Index The index number of this dynamic host name entry.

Farm Name The farm name in which the router with the Static NAT or Static PAT IP address resides. Optional.

Default: None



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.


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

Local IPv6 Address The IPv6 address of the local host.

Table 96: 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

Table 95: 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).

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.

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

Table 96: DNS Response Parameters




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.

You cannot specify the same IP address for the VDNS IP address and a physical interface.

Caution: The order of configuring virtual DNS is critical. First, you must configure the VDNS; and then, you associate an IP address with it.



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 198

• Simple Router Load Balancing Configuration With VLAN, page 199

• Simple One-Leg (Lollipop) Configuration, page 200

• Sandwich Configuration, page 201

• Single Device Installation, page 202

Table 97: 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 33: 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 34: 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 35: 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 36: 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 37: 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 203

• Default Flow, page 204

• Configuring Flow Management, page 204

• Flow Policies, page 205

• Typical Flow Configurations, page 208

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 98: 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 38: 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, 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 206.

Table 99: 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 325.

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

Although the Service classes that can be configured on the device allow for definition of Layer 7 criteria (for Bandwidth Management purposes), when used for traffic classification for flow management purposes, any criteria that is not found in the first packet of the session will be ignored during the classification process.

In addition to the Service classes, you can use Discrete Networks. For more information, see Discrete Networks, page 359.

• Traffic 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.

Table 100: Classification by Layer 3 or Layer 4 Policy per Traffic Direction

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

Note: If LinkProof handles FTP traffic, the FTP control and FTP data traffic need to use the same IP address.

To configure a flow policy

1. 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 101: 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.



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.

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

Table 102: Flow Management View Active Policies Parameters



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 The direction of the flow, One Way or Two Way.


Table 101: Flow Management Policies Parameters




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

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.

Table 102: Flow Management View Active Policies Parameters




Figure 39: Flow LinkProof Example Application

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 209

• Managing Client Tables, page 212

• Client-Table Logging, page 217

• Viewing Client Table Entries Using CLI, page 224

• Filtered Client Table, page 226

• Clearing the Client Table Manually, page 226

Client Table MechanismWhen a client first approaches the device, LinkProof checks whether an entry for that client already exists in the Client Table.

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



LinkProof automatically removes the relevant entries from the Client Table in the following cases:

• When one of the servers within a farm becomes unavailable.

• When the aging time of an entry expires. The Client Aging Time parameter is set per farm.

• If the Remove Entry at Session End option is enabled, when the session ends.

Note: You can clear the client table manually.

If LinkProof finds the relevant entry in the Client Table, LinkProof directs the client session to the farms and servers that appear in the Client Table, In such a case, there is no need to make a load balancing decision.

If LinkProof finds no relevant entry in the Client Table, LinkProof classifies the traffic to identify the flow that matches the traffic. LinkProof creates an entry in the Client Table indicating the sequence of farms the traffic must pass according to the selected flow. LinkProof selects a server for each farm in the flow, as the traffic reaches it, according to the load-balancing considerations that are defined by the Dispatch Method, and records it in the Client Table.

Example The following two tables illustrate Client Table examples of an HTTP outbound session for the network shown in the figure below.

Table 103: Client Table Example A

Source Address Destination Address Source Port Destination Port Flow10.1.1.2 202.2.2.2 1062 80 http flow

Table 104: 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



Figure 40: HTTP Outbound Session Example Configuration

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:

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.

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



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

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 212

• Client Table Modes, page 214

• Remove Entry at Session End, page 215

• Client Table Tuning, page 216

• Aging by Application, page 216

Configuring Client Table Global 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.

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.



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 105: 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 214

• Half Layer 4—For more information on this option, see Half Layer 4 Client Table Mode, page 214

• Full Layer 4—For more information on this option, see Full Layer 4 Client Table Mode, page 215

Default: Full Layer 4

Remove Entry at Session End When enabled, client entries are immediately removed from the Client Table when the client session ends.


Default: disable

Session Limit per Hash Entry Specifies a limit on the number of sessions associated with a hash entry in the Client Table (to maintain optimal performance).

The value 0 (zero) indicates no limit.

For maximum performance, LinkProof uses a hash algorithm to search for a Client Table entry. The hash function is applied on the session identification parameters, as determined by the Client Table Mode.

Multiple Client Table entries can be associated with the same hash entry, especially in Layer 4 modes. As having unlimited sessions associated to the same hash entry causes performance degradation, this parameter enables you to limit this number and maintain optimal performance.

Default: 0

Delayed Bind Timeout The time, in seconds, that the device waits for completion of TCP handshake.

Default: 10



Client Table ModesLinkProof supports the following Client Table modes:

• Layer 3 Client Table Mode, page 214

• Half Layer 4 Client Table Mode, page 214

• Full Layer 4 Client Table Mode, page 215

Note: Since a new table entry is made into the Client Table for every new session, the Client Table has many entries. You can increase the Client Table to accept more entries based on the amount of RAM available on the LinkProof device.

Layer 3 Client Table ModeIn Layer 3 mode, each entry is identified by the following parameters:

• Source IP address

• Destination IP address

In Layer 3 mode, all sessions between the same source and destination addresses are represented by a single Client Table entry and are forwarded to the same farm servers.

LinkProof performs the search using source and destination IP address only. The protocol that is displayed will be the first protocol that initiated the session (for example, ICMP).

Half Layer 4 Client Table Mode In Half Layer 4 mode, each entry is identified by the following parameters:



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

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 105: Client Table Global Parameters




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

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.

Table 106: 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



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.


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.

Table 107: 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 mechanism names temporary files <yyyyMMdd>_<hhmm>_<ss>_tmp.txt—for example, 20081207_1713_54_tmp.txt.

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 108: 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 109: 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 109: CLI Commands for Hard-Disk Management and Log-File Management

Parameter Description Command



Table 110: 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 (Read-only) The size, in megabytes, of the hard disk.

Available Free Disk Space

(Read-only) The size, in megabytes, of the free space on the hard disk.

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.

2. Do the following:

— From the Hard Disk Logging Mechanism drop-down list, select Enable or Disable as required.

— From the Syslog Logging Mechanism drop-down list, select Enable or Disable as required.

— To trigger a Client Table snapshot, from the Client Table Snapshot drop-down list, select Write now. When you click Set, the device writes the Client Table from RAM to disk, and the Client Table Snapshot drop-down list reverts to No write. You can retrieve the snapshot using FTP from the device file system.

3. Click Set.



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 111: 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

Select LinkProof > Clients > Filtered Client Table. The Filtered Client Table pane is displayed.

The table comprises the following columns:

— Source 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.

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.

Table 111: 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 227

• Multicast Dispatch, page 229

• Clear Client Table (VPN Load Balancing Feature), page 229

• Client Table Overwrite, page 231

Network Topology with LinkProof Devices Through 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 41: 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 HeadquartersIn this case, traffic returning from the headquarters will use the same path. If a new traffic session originates from the headquarters to the branch, the traffic should use the same VPN server tunnel as the one used before by the traffic coming from the branch to the headquarters.

The traffic flow is as follows: Branch LAN, VPN gateway 3, First LinkProof, VPN gateway 1, Second LinkProof, Router LAN A.

The following diagram shows two alternative VPN traffic paths.

Figure 42: VPN Alternative Traffic Paths

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.

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



Multicast DispatchThis feature is supported only for IPv4 addresses.

Note: The OnDemand Switch VL platform does not support the Multicast Dispatch Method.

When the network session starts from the headquarters to the branch, as shown in Figure 42 - VPN Alternative Traffic Paths, page 228, a VPN session is open along the red path.

When the Multicast Dispatch Method is used, after the return packet reaches the lower LinkProof device, a Multicast is sent with the return packet to both VPN gateways. The gateway that responds first, is the one with an established VPN session. LinkProof forwards the traffic to the VPN gateway and the session is not interrupted.

For information on configuring a farm with the Multicast Dispatch Method using Web Based Management, see LinkProof Farms, page 138.

To configure multicast dispatch using CLI


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 43: 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.

L3 switch/router

Branch A

LinkProof 1

Headquarters network

Branch B

LinkProof 3 LinkProof 4

LinkProof 2

L3 switch/router

L2 Switch 2

L2 Switch 2

L2 Switch 1

L2 Switch 3 L2 Switch 4

VPN Gateway 1 VPN Gateway 2



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, see LinkProof Farms, page 138.

Client Table OverwriteThis feature assists in dealing with the problems associated with Clear Client Table—Scenario 1, page 230. To solve the problem, a flag indicates when a client entry as part of a farm needs to be deleted when the server of that farm comes up again.

Note: Because two redundant LinkProof devices may not be synchronized and might not recognize that the server is up or down at the same time, there could be persistency issues until server selection status data is overwritten. Persistency issues remain until the Client Table entry is deleted. A server that receives a packet from a different server (firewall) is not overwritten. If the new server is of a farm different from the farm of the original server, the server selection is not overridden. If IP translations (NAT) of any sort are involved for the session, the server selection is not overridden.



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 233

• Tunneling, page 243

• Cost-based Load Balancing, page 246

• Event Scheduler, page 247

• Miscellaneous Parameters—Tweaks, page 248

• Performance Statistics, page 250

• Statistics Monitor SRP Management Host IP Address, page 259

• Configuration Auditing, page 260

• NTP Service, page 261

• RADIUS Service, page 262

Content Load BalancingThis section describes what content load balancing is and describes the methods for LinkProof load balancing.


• Content Load Balancing Overview, page 233

• Layer 7 Policies, page 237

• Content Rules, page 239

• Hostname Lists, page 242

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 233

• Alias Ports, page 236

Delayed BindingTo make a load balancing decision based on HTTP content (Layer 7 decision), LinkProof implements a mechanism referred to as Delayed Binding.

LinkProof User Guide Advanced Features


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 112: Delayed Binding Global Parameters

Parameter DescriptionSearch Depth (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


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

Number of TCP Retransmissions The number of times the LinkProof device retransmits unanswered TCP requests.

Values: 0–10

Default: 3

POST Classification Input The part of the POST request where the device does the classification.

Values:

• Header—The device accumulates and searches only the header.

• Header and Body—The device accumulates both body and header and searches both.

Default: Header

Retransmission Interval(sec) The time, in seconds, between retransmissions of client requests.

Values: 0–10

Default: 1





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.


Automatic Mode Specifies whether the device uses the Automatic Mode to conserve resources while under stress.

Values:

• enable—If the LinkProof CPU utilization reaches 95%, the Automatic Mode mechanism doubles the retransmission interval (to the reduce strain on the resources). If CPU utilization reaches 98%, the Automatic Mode mechanism disables the retransmission mechanism until CPU utilization falls below 98% (using the doubled retransmission interval).

• disable—The device does not use the Automatic Mode.

Default: enable

Table 113: 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)





To update an existing Alias Port

1. Select LinkProof > Global Configuration > Alias Ports. The Alias Ports pane is displayed.

2. Click on the relevant alias port from the table. The Alias Ports Table Update pane is displayed.

3. Edit the value of the Well Known Port Number as required.

4. Click Set.

Layer 7 PoliciesA single Content Rule (see Content Rules, page 239) can include one or more Layer 7 Policies (also referred to L7 Policies) all using the same HTTP criteria, such as URL, HTTP header, and so on. For example, a Layer 7 Policy can send HTTP traffic to a certain URL via a specific router always. To select farm according to a Layer 7 Policy, LinkProof matches the packet against the entries within the Policy according to the defined order, and uses the first matching entry.

In LinkProof, the parameters such as URL, Cookie Type, and so on, are configured within the filters (for example, basic filters, AND filters, and so on) via the classes.

Caution: The more specific policy must appear first; otherwise; the less specific policy is always matched and used.

Example A packet with a request to URL www.a.com/a arrives at LinkProof, which has a Layer 7 policy with the following entries:

— First entry with classification criteria www.a.com/ab

— Second entry with classification criteria www.a.com/a

Then the second entry is matched and used.

The criteria according to which LinkProof classifies traffic are called Methods.

The following Method Types are available for LinkProof:

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

— 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 114: 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.

Service Type Values:

• None

• Basic Filter

• AND Group

• OR Group

Default: None



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 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 242) 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 115: 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 114: L7 Policy Parameters




Delayed Binding (see Delayed Binding, page 233). When the LinkProof device receives enough information from the HTTP header, a farm and then a server can be selected according to the Layer 7 Policy attached to that Content Rule.

This sections contains the following topics:

• Configuring Content Rules, page 240

• Content Rule Configuration Examples, page 242

Note: Content Rules are activated only for HTTP traffic over standard port 80.

Configuring Content 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 116: 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 117: 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 44: 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 244

• Generic Routing Encapsulation (GRE), page 244

• GPRS Tunneling Protocol (GTP), page 245

• Multiprotocol Label Switching (MPLS), page 245

Table 118: 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 border routers (which encapsulate and remove the tunneled header), LinkProof takes all the routing and farms’ load-balancing decisions based on the tunneled header of the packet, since the border routers (and other potential servers) are forwarding the packet based on the tunneled information which the packet carries with it.

You can apply bandwidth management (BWM) and flow-management policies on tunneled packets. Note that the policy classification is based on the payload of the tunneled packet (and not on the tunneled header), since, generally, with BWM and flow management policies, only the payload is interesting.

To enable tunneling

1. 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 45: 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 119: Example L2TP Packet Structure

Ethernet IP UDP L2TP PPP Original IP header

Original data



Figure 46: IP Header in GRE Packet

GPRS Tunneling Protocol (GTP) GPRS Tunneling Protocol (GTP) defines the protocol between GPRS Support Nodes (GSNs) in the GPRS backbone network. GTP includes both the GTP control plane (GTP-C) and data transfer (GTP-U) procedures. GTP allows multi-protocol packets to be tunneled through the UMTS/GPRS backbone between GSNs and between an SGSN and UTRAN. The GTP protocol tunnels the protocol data units through the IP backbone by adding routing information. GTP operates on top of TCP/UDP over IP.

When a packet is encapsulated using GTP, a new IP packet is created.

Figure 47: IP Header in GTP Packet

Multiprotocol Label Switching (MPLS) Multiprotocol Label Switching (MPLS) is an IETF initiative that integrates Layer 2 information concerning network links (bandwidth, latency, utilization) into Layer 3 (IP) within ISP, 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 48: Entry Format in MPLS Packet

If the IP packet is already an IP fragment, it cannot be fragmented again, because IP does not support multiple fragmentations.

IP fragments that exceed the network MTU are discarded.



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 120: 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 121: 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 122: 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 The FTP data port number.

FTP Control Port The FTP control 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 250

• Element Statistics, page 253

• IP Interface Statistics, page 257

• NHR Statistics, page 257

BWM Policy StatisticsThis section includes the following:

• BWM Policy Statistics—Global Parameters, page 250

• BWM Policy Statistics—Last Second and Last Period, page 250

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 Statistics—Last Second and Last PeriodYou can view statistics for the bandwidth-management policies.


• BWM Policy Statistics—Last-Second Statistics, page 251

• BWM Policy Statistics—Last Period Statistics, page 252

Table 123: 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 124: 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 125: 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 253

• SNMP Element Statistics, page 254

• IP Router Element Statistics, page 255

• OSPF Element Statistics, page 256

• Resource Utilization Element Statistics, page 256

• Accelerator Element Statistics, page 256

IP Packet Element Statistics

To view IP packet element statistics

Select Performance > Element Statistics > IP. The IP Packet Statistics pane is displayed.

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 126: 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 125: 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 127: 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 128: 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 129: 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 130: 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 128: 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 131: 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 246.

To view the Daily NHR Cost Statistics Table

Select Performance > NHR Statistics > Daily NHR Cost Statistics Table. The Daily NHR Cost Statistics Table pane is displayed.

Table 132: 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 133: 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 134: 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 135: 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 > Time Settings > 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 136: Network Time Protocol Parameters

Parameter DescriptionNTP Server 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 137: 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 137: RADIUS Parameters



Chapter 6 – RedundancyThis chapter describes redundancy features and provides common examples of the different LinkProof redundancy configurations.


• LinkProof Redundancy, page 265

• VRRP Redundancy, page 272

• Remote Virtual IP Addresses, page 294

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 268

• Mirroring the Client Table, page 270

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 LinkProof device can always recognize whether the paired LinkProof device is up or down. In LinkProof, physical IP addresses are configured to poll other LinkProof physical IP addresses. In Figure 49 - LinkProof Redundancy Scheme, page 266, the interface addresses of LinkProof 2 are configured to poll the addresses of LinkProof 1 and the interface addresses of LinkProof 1 are configured to poll the addresses of LinkProof 2.

The teaching process works as follows: once a LinkProof interface considers the other LinkProof interface to be down, it assumes responsibility for the failed IP address. For example, in Figure 49 - LinkProof Redundancy Scheme, page 266, if LinkProof 1 fails and LinkProof 2 decides to take over operation, LinkProof 2 assumes responsibility for IP addresses of LinkProof 1.

Each pair of LinkProof devices can function in an Active/Backup setup.

To achieve redundancy between pairs of devices, LinkProof supports Virtual Router Redundancy Protocol (VRRP). VRRP enables maintaining dynamic redundancy using a virtual router. With VRRP redundancy, IP addresses are associated with the virtual MAC addresses owned by the main device, and when failing over, the backup device takes ownership of the IP addresses.

Caution: If the DNAT address is not equal to the associated IP address of the device, LinkProof creates an appropriate associated IP address for the DNAT entry. In a redundant configuration, when you delete the DNAT address of the backup device, LinkProof does not delete the associated IP address that was created automatically previously for the backup device. You must delete the IP address manually.

LinkProof User Guide Redundancy


Figure 49: 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.

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.

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 in a redundant environment involves the following:

• Specifying the Peer Address for the same interface on the backup device for each IP interface that you configured on the device (Router > IP Router > Interface Parameters > Peer Address).

• Specifying the appropriate Configuration Type, Regular or Backup (File > Configuration > Receive from Device > Configuration Type). In the Download Configuration File pane, you can select the Include Private Keys check box to download the Private Key for SSH/SSL configuration, so that both devices will use the same private key.

Global Redundancy 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 138: Global Redundancy Configuration Parameters

Parameter DescriptionIP Redundancy Admin Status Allows this device to function as part of a backup configuration.

Values: Disable, VRRP

Default: Disable

Note: You must select VRRP to enable mirroring. For more information, see Mirroring the Client Table, page 270.

Interface Grouping Specifies whether Interface Grouping is enabled. When Interface Grouping is enabled, if one port fails, the device takes down the other ports also, and the backup device becomes the active one only when all the interfaces of the main device are down.


Default: disable

Note: For more information, see Interface Grouping, page 268.

ARP with Interface Grouping Specifies whether the device can send ARP requests with the active interface grouping.

Values: Send, Avoid

Default: Send

Backup-In-Vlan Specifies role of the device in a VLAN. If the main device is active, no traffic is forwarded by this redundant or backup device.

Values: Active, Backup

Note: If your network is set up as a VLAN, configure the backup device before you configure the main device.



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.

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.

>> When using VLAN with interface groupings, a group may go down as a result of a failing interface. In such an event, all traffic to the interfaces belonging to the group will be discarded including management traffic.

Master Interface 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.

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 138: Global Redundancy Configuration Parameters




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.

When working with IPv6 interfaces in LinkProof, by default, every interface has an IP address (a link-local address). Thus, all of the interfaces affect the configuration. If you want a failed interface not to affect VRRP fail-over, you must exclude manually it from the Interface grouping.

Notes>> If an interface, which is part of a VLAN, goes down and its Port Status is set to Included,

it does not initiate Interface Grouping.

>> When an interface, which has its Port Status set to Included, goes up after it goes down, Interface Grouping is turned off immediately, and the device regains control (becomes the main device). No reboot is required.

To configure the Master Interface Grouping Table

1. Select Redundancy > Master Interface Grouping Table. The Master Interface Grouping Table pane is displayed, which contains the following parameters:

2. Select the relevant port number. The Master Interface Grouping Table Update pane is displayed.

3. From the Port Number Status drop-down list, select Included or Excluded.

4. Click Set.

Backup Interface 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.

Parameter DescriptionPort Number (Read-only) The port number.

Port Status Specifies whether to include or exclude the port in interface grouping.



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



For effective and reliable mirroring, do the following:

• Provide a direct connection between the two devices. An IP interface must be configured on each device for the direct connection port and address used as the Mirroring Device Address for the other device.

• Exclude physical port used for inter-device communication from Interface grouping.

• Use a trunk (link aggregation) for direct connection between two devices.

• Mirroring parameters must be configured on the main device and on the backup device.

• The devices must be configured using VRRP. For more information, see Global Redundancy Configuration, page 267.

• The IP address must be defined on dedicated ports (not used for other proposes); and the IP addresses must not be a VRRP-associated IP address. For more information, see VRRP Associated IP Addresses, page 293.

Caution: Mirroring works differently depending on the specified Priority and Preemption Mode of the VRRP redundancy configuration (see Configuring Basic VRRP Redundancy, page 291). The device with the higher priority is the main device. The specified Preemption Mode affects the values you must choose when you configure mirroring. The following tables describe the required values for the main and backup devices according to whether Preemption Mode in the VRRP configuration is true or false.

Table 139: Required Values for Main and Backup Devices with VRRP Preempt Mode = True

Main Device 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

Table 140: 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



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.


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.

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.

VRRP RedundancyThis section describes redundancy in LinkProof using Virtual Router Redundancy Protocol (VRRP).


• Introducing VRRP, page 273

• Direct Server Connection with VRRP, page 279

Table 141: Active-Device Mirroring Parameter

Parameter DescriptionClient Table Mirroring Enables or disables the mirroring of the Client Table.


Default: disable



• VRRP with IPv6 Prefix NAT, page 281

• Configuring Basic VRRP Redundancy, page 291

• VRRP Associated IP Addresses, page 293

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 (that is, associated IP addresses). Each VR ID must be unique for the system, even if the IDs relate to different interfaces. If two LinkProof devices belong to the same subnet, and each device is backed up by a VR, the VR IDs for both devices must also be different.

Notes>> LinkProof uses the term associated IP address to refer to the IP address associated with

the interface index and the VR ID. Other vendors may refer to the associated IP address as a virtual IP (VIP) or a floating IP, because it floats between the primary and standby 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 279.

>> When working with a VRRP configuration, Radware strongly recommends that you enable Interface Grouping. You associate the interfaces that are used by the redundant configuration to the relevant group.

Caution: Interface grouping (see Interface Grouping, page 268) is disabled by default, but, when interface grouping is enabled:

>> By default, all of the device interfaces are included in the Master Interface Grouping, and if any of the interfaces in the group fails, the entire device is declared down and the VR fails over (master switches to backup).

>> If the status of a certain VR ID is Disabled, then either all VR IDs on that device are disabled too, or all copies of that VR ID on other devices are disabled as well.

>> If, on a certain interface, a LinkProof device has IP addresses that belong to a subnet whose backup device is not on that interface, you must configure the LinkProof device with a primary IP address that belongs to a subnet that the backup device has.



>> 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 50 - Redundant LinkProof Configuration with VRRP—VR IP Address Uses the IP Address of One of the Physical Interfaces of the Primary Device, page 275 shows the example configuration. Figure 51 - Configuration of Redundant LinkProof Devices with VRRP—VR IP Address Uses the IP Address of One of the Physical Interfaces of the Primary Device, page 276 describes the flow of the configuration procedure.



Figure 50: 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 51: 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 to 255

Change VR State to 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:InterfacesIP AddressesRoutingFarm and flowsNAT



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 52 - Redundant LinkProof Configuration with VRRP—VR IP Address Uses an IP Address Different from the Physical Interfaces of the Primary Device, page 277 shows the example configuration. Figure 53 - Configuration of Redundant LinkProof Devices with VRRP—VR IP Address Uses an IP Address Different from the Physical Interfaces of the Primary Device, page 278 describes the flow of the configuration procedure.

Figure 52: Redundant LinkProof Configuration with 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






Figure 53: 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


Create Associated IP address for the

NAT address

Requirepinging the VR IP or

have a VDNS?

Create a Remote VIP or VDNS IP


Alternatively, you can:1) Create VRs2) Create associated IP addresses3) Up all VRs

Configuring the primary device?

Set VR priority to 200


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




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 54 - Direct Server Connection with VRRP and Routing, page 280) or bridging (see Figure 55 - Redundant LinkProof Configuration with VRRP and Direct Connection, page 281) between the external network connected to routers or switches, and the internal network connected to servers. Servers are connected directly to the interfaces of LinkProof. A cross cable is required to connect the two LinkProof devices together (using Giga, or Fast Ethernet ports).

The interfaces to which the servers are connected and the interface used for connecting the two LinkProof devices, are associated to a Switched IP VLAN. This puts all the servers on a single switch.

Using bridging, you need to configure a Regular VLAN including the switch IP VLAN and the LinkProof interface to the external side. This creates a bridge between the Switched VLAN and the interface to the external side. When needed, multiple LinkProof interfaces can be added to this Regular VLAN.

Using routing with Layer 2 or Layer 3 switches, either connecting LinkProof and servers or connecting LinkProof to the external subnet, you must avoid configuration that contains a loop. For example, having a cross cable between the switches as well as between LinkProof devices, or connecting each LinkProof to two (2) cross-connected switches where the two (2) connections are on the same Switched IP VLAN on LinkProof, must be avoided.

The configuration properties of the examples shown in Figure 54 - Direct Server Connection with VRRP and Routing, page 280 and Figure 55 - Redundant LinkProof Configuration with VRRP and Direct Connection, page 281 are as follows:

• Direct Server Connection with Routing is supported with VRRP and Switched IP VLAN only.

• sServersCIDCondDel4CIDMM Firewalls are connected directly to the interfaces of LinkProof. Cross cables are required in order to connect the two LinkProof devices together (using Giga, or Fast Ethernet ports).

• The interfaces to which the firewalls are connected to and the interface used for connecting the two LinkProof devices are associated to a Switched IP VLAN. This puts all the firewalls on a single switch. An IP address (from the blue subnet) should be associated with the Switched IP VLAN in each device.

• The LinkProof configuration and redundancy configuration does not change from the regular setup.

• The default gateway of firewalls and routers is the IP address of the respective Switched IP VLAN of the active LinkProof.

Note: When using dual NICs, where the active NIC is determined by pinging the default gateway, set a virtual DNS with IP 10.1.1.20 on the LinkProof device. This IP should be the default gateway of the servers. In the Associated IP Addresses Table pane, configure the following entries: Interface=100002, VRID=10, Associated IP=10.1.1.20.

• LinkProof is using routing between the blue subnet (of the firewalls) and the orange (routers) subnet. This is essential in order to avoid loops in the network.

• When adding or removing ports to a Switch IP VLAN that is already associated to a VRID, you must set the VR ID Admin Status to Down, make the change and then set the VR ID Admin Status to Up again.



Figure 54: 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 55 - Redundant LinkProof Configuration with VRRP and Direct Connection, page 281, illustrates the scheme for a redundant LinkProof configuration with VRRP and direct connection. VRRP with Switched IP VLAN allows direct connection of servers to LinkProof.

Figure 55 - Redundant LinkProof Configuration with VRRP and Direct Connection, page 281 configuration properties:

• Firewalls are directly connected to LinkProof, possibly with dual NIC.

• Each router is connected directly to a different LinkProof and they are inter-connected as well (subnet 30.1.1.x). Route towards the other router should be configured on each router.

• Network side and server side are on different subnets.

• The virtual IP addresses served by the LinkProof devices are 100.1.1.100 and 200.1.1.100 usually handled by LinkProof 1.

• Firewalls 10.1.1.1 and 10.1.1.2 are assigned to the farm managed by LinkProof 1.

• Redundancy is performed using the VRRP protocol.

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 55: Redundant LinkProof Configuration with VRRP and Direct Connection

VRRP with IPv6 Prefix NATThis section describes VRRP configuration with IPv6 Prefix-NAT.

Ensuring Proper ConnectivityWhen creating an IPv6-Prefix-NAT configuration, it is critical that you make sure not to overlap the IPv6 addresses used by the routers for their internal IPv6 interfaces. If there is overlap, the LinkProof device will lose connectivity to the external router.

Figure 56: Example Valid IPv6 Topology

To configure proper connectivity for IPv6, you must define a proper IPv6 Prefix-NAT range.

Defining a full IPv6 Prefix-NAT range of 2040:2100::/48 will cause an IPv6 address overlap thus causing network connectivity failure.

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

Internal address of LinkProof device isFC00:1000::FFF1/64

External address of LinkProof device is 2040:2100::2001/48

Internal address of router is 2040:2100::2222/48

External Segment 02

External Router 02

RST

APSolute Application DeliveryP WR

USB MNG 2

MNG 1

CON SOLE

PWR

FAN

SYS OK

Link Proof1000

10/100

G1

G13 G14 G15 G16

G3 G5 G7 G9 G11

G2 G4 G6 G8 G10 G12

1 000

1 0/100



Defining an IPv6 Prefix-NAT range such as in Improper Configuration 1—Full IPv6 Prefix-NAT Range Causes Address Overlap, page 282 and Improper Configuration 2—Full IPv6 Prefix-NAT Range Causes Address Overlap, page 282 is improper (LinkProof > Smart NAT > IPv6 Prefix-NAT > Static Prefix-NAT Table). The configurations result in address overlap. That is, LinkProof can translate a packet with address fc00:1000::2222 as 2040:2100::2222, causing the internal router address to be overlapped by the LinkProof device.

To prevent overlapping addresses, you must insert spaces in the IPv6 range for Prefix-NAT to use, excluding the external router IPv6 address and eliminating any overlap.

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

Table 142: Improper Configuration 1—Full IPv6 Prefix-NAT Range Causes Address Overlap

Parameter ValueFrom Local IP fc00:1000::1

To Local IP fc00:1000::ffff

Server Name IPv6Routers/ISP02

Range Defined by Prefix Blank

Replaced With Prefix 2040:2100::/48

Redundancy Mode regular

Table 143: Improper Configuration 2—Full IPv6 Prefix-NAT Range Causes Address Overlap


To Local IP Blank


Range Defined by Prefix /64



Table 144: Proper Configuration—Separated IPv6 Prefix-NAT Ranges Prevent Address Overlap

Parameter Value—Row 1 Value—Row 2From Local IP fc00:1000::2000 fc00:1000::1

To Local IP fc00:1000::2220 Blank

Server Name IPv6Routers/ISP02 IPv6Routers/ISP02

Range Defined by Prefix Blank Blank

Replaced With Prefix N/A N/A

Redundancy Mode regular regular



VRRP Associated IP AddressesWhen a VR ID that supports IPV6 is configured on the device, LinkProof creates an associated IP address for the Primary IP parameter. The entry is created with a link-local address derived from VR MAC. This is part of IPv6 RFC and does not affect regular device functionality.

VRRP Configuration Steps

Caution: In IPv4, the order in which you configure VRRP in LinkProof does not matter. In IPv6, the order in which you configure VRRP in LinkProof is crucial. You can, however, modify the Prefix-NAT configuration.

The reason why the order is crucial is that the IPv6 Prefix-NAT ranges define the VR associated IP address that will be used in the IPv6 neighbor solicitation process, which enables the LinkProof device to announce the relevant IPv6 addresses that the VR holds and responds to.

VRRP configuration involves the following steps:

1. Configuring all the relevant interfaces, routing, and so on.

2. Configuring e the relevant VR and relevant IP address.

3. Deriving the IPv6 associated IP address from the IPv6 Prefix-NAT calculator.

4. Configuring the IPv6 Prefix-NAT addresses.

5. Configuring VR associated IPv6 ranges (using the calculator).

Note: For more information, see Configuration Flow Chart—VRRP with IPv6 and IPv6 Prefix-NAT, page 284.

Disabling VRRPWhen you disable VRRP with IPv6 Prefix-NAT associated IP addresses (after disabling the VRRP configuration), you will have to clean the ARP table on the adjacent routers (connected directly to the device). This is done because IPv6 neighbor solicitation messages may still point to the VR MAC address.

Interface Grouping ConsiderationsInterface Grouping is disabled by default. When Interface Grouping is enabled, if any of the interfaces in the group fails, the entire device is declared down and VRRP failover occurs (master switches to backup). When you configure VRRP, make sure to enable Interface Grouping as required.

By default, the Master Interface Grouping Table includes all the device interfaces except for management interfaces. When working with IPv6 interfaces in LinkProof, by default, every interface has an IP address (a link-local address). Thus, all of the interfaces affect the configuration. If you want a failed interface not to affect VRRP fail-over, you must exclude manually it from the interface grouping.



Configuration Flow Chart—VRRP with IPv6 and IPv6 Prefix-NAT

Enable VRRP

Create a VR andset State to Down

Use the calculator to create Associated IPv6 address with

IPv6 Address for VR


Need to pingthe VR IP or have a

VDNS?

Create a remote VIP or VDNS IP address to use

Configuring the primary device? Set VR priority to 200


Set VR priority < 200(for example, 100)


If the VIP is in the IPv6Prefix-NAT range, create

Associated IP Addresses for the VIP or VDNS

Using Interface Grouping?

Assign interfaces in the Master Interface Grouping table

Using IPv6Prefix-NAT?

Use the calculator to derive the VRRP IPv6 Associated IP

Create IPv6 Prefix-NAT addresses or ranges Create Associated IPv6

address if needed


Yes

Yes

Yes

Yes

Yes

No

No

No

No

No



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

Figure 57: VRRP with IPv6 Prefix-NAT Configuration Example

The scenario in the figure assumes the following:

• Both LinkProof devices are in VRRP setup providing failover for one another.

• LinkProof 01 Primary is the VRRP master.

• LinkProof 02 Secondary is the VRRP backup.

• Users on the internal LAN are coming from ULA address (FC00::/64)

• The administrator has connected the LinkProof to the following two routers:

— ISP01 with an IPv6 prefix of 2030:1000:2000::/64

— ISP02 with an IPv6 prefix of 2040:2100::/48

• Each LinkProof is connected to two routers (using an external segment).

LinkProof 01Primary

Internet

Internal Segment


FC00:1000::FFF1/64is the IP address of the internal interface of the

LinkProof device

2030:1000:2000::2222/64 2040:2100::2222/48

FC00:1000::2000/64

FC00:1000::FFF2/64is the IP address of the internal interface of the

LinkProof device

2030:1000:2000::2002/64 2040:2100::2001/48

2040:2100::2002/48is used to access

External Router 02

2030:1000:2000::2001/64is used to access

External Router 01

External Segment 01

External Router, ISP01 External Router, ISP02

Users

Virtual Router2030:1000:2000::2020/642040:2100::2020/48

Virtual RouterFC00:1000::FFFE/64

RS T

APSolute Application DeliveryP W R

US B MNG 2

MNG 1

CON SO LE

P WR

F AN

SY S OK

Link Proof1000

10/100

G1

G1 3 G14 G1 5 G16

G3 G 5 G7 G9 G1 1

G2 G4 G 6 G8 G1 0 G1 2

1000

10/ 100

External Segment 02

RST

APSolute Application DeliveryPWR

U SB M NG 2

M NG 1

C ONSOL E

PW R

FA N

SYS OK

Link Proof1000

10/100

G 1

G1 3 G14 G15 G16

G 3 G5 G7 G9 G11

G 2 G 4 G6 G8 G10 G12

1000

10/1 00



As mentioned, the IPv6 associated IP addresses are derived from the IPv6 Prefix-NAT ranges. Therefore, only one IP address from each range needs to be defined in the Redundancy Associated IP Addresses table. This will inform the LinkProof device as to the associated IP address ranges for which it is responsible. In the example, an address from LinkProof external interface 01 can be 2030:1000:2000::2000, and an address from LinkProof external interface 02 can be 2040:2100::2000.

Prior to the VRRP configuration, we assume all IPv6 interfaces are configured properly. That is, routing is configured properly (especially, the default route ::/0 to both external routers), and connectivity is working end to end.

To configure the VRRP with the IPv6 Prefix-NAT example configuration

1. Configure the virtual router VR ID 1 (internal interface).

On the Master LinkProof Priority = 200

on the backup LinkProof Priority = 100

Redundancy > VRRP > Virtual Routers > Create

Table 145: VRRP with IPv6 Prefix-NAT Configuration Example—Address Summary

Device External Interface 01 External Interface 02 Internal InterfaceInterfaces ISP01 IPv6 public IP address N/A 2030:1000:2000:2222/64

ISP02 IPv6 public IP address N/A 2040:2100::2222/48

LinkProof 01 2030:1000:2000::2002/64 2040:2100::2002/48 FC00:1000::FFF2/64

LinkProof 02 2030:1000:2000::2001/64 2040:2100::2001/48 FC00:1000::FFF1/64

VRRP LinkProof external virtual router (VR ID 01)

2030:1000:2000::2020/64 2040:2100::2020/48 N/A

LinkProof internal virtual router (VR ID 02)

N/A N/A FC00:1000::FFFF/64

LinkProof associated IP address(VR ID 01)

N/A N/A FC00:1000::FFFE

LinkProof associated IP address(VR ID 02)

2030:1000:2000::2000through2030:1000:2000::2220

2030:1000:2000::2223through2030:1000:2000::FFFF

2040:2100::2000through2040:2100::2220

2040:2100::2223 through2040:2100::FFFF

N/A

Prefix-NAT LinkProof IPv6 Prefix-NAT(router 01)

FC00:1000::2000 throughFC00:1000::2020

FC00:1000::2023 throughFC00:1000::2FFF

N/A N/A

LinkProof IPv6 Prefix-NAT(router 02)

N/A FC00:1000::2000throughFC00:1000::2020

FC00:1000::2023throughFC00:1000::2FFF

N/A

Users point of entry (that is, the default gateway for the network)

FC00:1000::2000/64 N/A N/A



2. Configure the associated IP address for the internal interface.

Redundancy > VRRP > Associated IP Addresses > Create

3. Enable the internal virtual router VR ID 1, which you configured in step 1.

4. Repeat step 1 through step 3 for the backup device.

Note: Once enabled, the VR ID shows a Primary IP from the LLA (link-local address). This is regular IPv6 behavior according to RFC and IPv6 logo specifications.

5. Configure the external virtual router VR ID 2 (on the LinkProof external interface 02).

6. Create Prefix-NAT ranges for internal users accessing the Internet from the router ISP02.

LinkProof >Smart NAT > IPv6 Prefix-NAT > Static Prefix-NAT Table > Create

Table 146: VRRP and IPv6 Prefix-NAT Example Configuration—Virtual Router Parameters

Parameter ValueIP Version IPv6

VR ID 1

If Index G-3

Admin Status disabled

Priority 200

Primary IP Blank

Advertise Interval 100

Preempt Mode True

Table 147: VRRP and IPv6 Prefix-NAT Example Configuration—Associated IP Addresses Parameters

Parameter DescriptionIP Version IPv6

VR ID 1

If Index G-3

Associated IP fc00:1000::fffe

Table 148: VRRP and IPv6 Prefix-NAT Example Configuration—Virtual Router Parameters

Parameter ValueIP Version IPv6

VR ID 2

If Index G-5

Admin Status disabled

Priority 200

Primary IP Blank

Advertise Interval 100

Preempt Mode True



The result is:

Table 149: VRRP and IPv6 Prefix-NAT Example Configuration—Static Prefix-NAT Table Parameters—First Range


To Local IP fc00:1000::2220





Table 150: VRRP and IPv6 Prefix-NAT Example Configuration—Static Prefix-NAT Table Parameters—Second Range







Table 151: VRRP and IPv6 Prefix-NAT Example Configuration—Static Prefix-NAT Table Result

Parameter Value—Row 1 Value—Row 2From Local IP fc00:1000::2000 fc00:1000::2223

To Local IP fc00:1000::2220 fc00:1000::ffff

Server Name IPv6Routers/ISP02 IPv6Routers/ISP02

Range Defined by Prefix Blank Blank

Replaced With Prefix N/A N/A

Redundancy Mode regular regular


From Local IP To Local IP Range Defined by Prefix

Server Name Redundancy Mode

fc00:1000::2000 fc00:1000::2220 Blank IPv6Routers/ISP 02 regular

fc00:1000::2223 fc00:1000::ffff Blank IPv6Routers/ISP02 regular



7. Using the IPv6 Prefix-NAT calculator, derive the associated IP address of the external interface.

From the CLI, run:

lp smartnat ipv6nat calc fc00:1000::2000 2040:1000::2000 48

which generates the following:

result

The nat address is: 2040:1000::2000

8. Configure the associated IP address for the internal interface.

Note: Since here, the IPv6 Associated Addresses are derived from the Prefix-NAT, we only need to configure one address from the Prefix-NAT range.

One address from the range (using the result of the prefix-NAT calculator from above) is:

The result is:

The associated IP address range shows the range From Address–To Address as configured by the IPv6 Prefix-NAT feature.

9. Configure the associated IP address for the second range.

Table 153: VRRP and IPv6 Prefix-NAT Example Configuration—Associated IP Addresses Parameters for Internal Interface


VR ID 2

If Index G-5

Associated IP 2040:2100::2000

Table 154: VRRP and IPv6 Prefix-NAT Example Configuration—Associated IP Addresses Update for Internal Interface


VR ID 2

If Index G-5


From Address 2040:2100::2000

To Address 2040:2100::2220

Table 155: VRRP and IPv6 Prefix-NAT Example Configuration—Associated IP Addresses Parameters for Second Range


VR ID 2

If Index G-5




The result is:

10. Enable VR ID 2 as configured in step 5.

11. Repeat step 5 through step 9 for the backup device (with the exclusion of step 7, because as the result would be the same) but with the following exceptions:

— VRID Priority should be 100 for the backup device.

— Redundancy mode in the Static Prefix-NAT Table Create pane should be set to backup.

12. For the second router (LinkProof external interface 01), follow the exact same steps using the same VR ID (VR ID 2) or another VR ID number of your choice.

13. In the Static Prefix-NAT pane, for the router ISP01, the configuration (LinkProof > Smart NAT > IPv6 Prefix-NAT > Static Prefix-NAT Table > Create) should be configured as illustrated in the following two tables:

Table 156: VRRP and IPv6 Prefix-NAT Example Configuration—Associated IP Addresses Update for Second Range


VR ID 2

If Index G-5


From Address 2040:2100::2223

To Address 2040:2100::ffff

Table 157: VRRP and IPv6 Prefix-NAT Example Configuration—Static Prefix-NAT Table Parameters—First Range


To Local IP fc00:1000::2220



Replaced With Prefix 2040:2100:2000:/48


Table 158: VRRP and IPv6 Prefix-NAT Example Configuration—Static Prefix-NAT Table Parameters—Second Range





Replaced With Prefix 2040:2100:2000:/64




The result is:

14. Follow step 7 through step 9 for the external interface VR ID 1 settings using the exact same methodology.

15. Repeat the same steps for secondary (VRRP backup) LinkProof device.

16. Once both VR IDs are enabled, check connectivity and failover. IPv6 end-to-end connectivity should be working with IPv6 router load balancing according to LinkProof functionality.

Configuring Basic VRRP Redundancy

Caution: For mirroring, Radware strongly recommends that you use a dedicated management port to prevent packet loss while under stress. For more information on mirroring, see Mirroring the Client Table, page 270.

To enable redundancy with VRRP


2. From the IP Redundancy Admin Status drop-down list, choose VRRP.

3. Click Set.

To configure basic VRRP redundancy

1. Select Redundancy > VRRP > Virtual Routers. The Virtual Router Table pane is displayed.

2. Click Create. The Virtual Router Table Create pane is displayed.



From Local IP To Local IP Range Defined by Prefix

Server Name Redundancy Mode

fc00:1000::2000 fc00:1000::2220 Blank IPv6Routers/ISP01 regular

fc00:1000::2000 fc00:1000::2220 Blank IPv6Routers/ISP02 regular





Table 160: Virtual Router Parameters

Parameter DescriptionIP Version The IP version.

Values: IPv4, IPv6

Default: IPv4

VR ID The identifier of the virtual router.

Values: 1–255

Default: 1

If Index The interface identifier.

Values:

• The traffic ports (not MNG ports) on the device

• 100001

Default: G-1

Admin Status The status of the port.

Values: enabled, disabled

Default: disabled

Priority Priority is defined with the values 1–255, where the highest priority of 255 should be assigned to the primary VR.

Values: 1–255

Default: 100

Caution: If the Preemption Mode is False, you must not specify the value 255.

Primary IP The primary IP address. The device adds a default value unless the you define one.



VRRP Associated IP AddressesThe associated IP address is the IP address associated with the interface index and the VR ID. An associated IP address is used in NAT configurations. Other vendors may refer to the associated IP address as a virtual IP (VIP) or a floating IP, because it floats between the primary and standby 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.


Advertise Interval The interval, in centiseconds, at which the device checks packets.

Default: 100

Preempt 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

Caution: If Preempt Mode is False, with a regular VLAN in the setup, to prevent loops on both devices, you must set the value of the Backup-In-Vlan parameter (see Global Redundancy Configuration, page 267) to Backup, on both devices.

Note: The exception to the above description is that the router that owns the IP address(es) associated with the virtual router always preempts, independent of the setting of this flag.

Table 161: Associated IP Addresses Parameters

Parameter DescriptionIP Version The IP version.

Values: IPv4, IPv6

Default: IPv4

VR ID The identification number of the virtual router.

Values: 1–255

Table 160: Virtual Router Parameters




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 address that represents the devices’ VRRP configuration. The remote virtual IP address needs to be associated with one physical interface on the device. You configure the same remote virtual IP address on both devices.

Example Remote Connectivity 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.

If Index The interface identifier.

Values:

• The traffic ports (not MNG ports) on the device

• 100001

Associated IP The IP address associated with the interface index and the VR ID.

Table 161: Associated IP Addresses Parameters




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 162: 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.


• ACL, page 297

• Ports Access, page 304

• Configuring Access for Physical Ports, page 304

• SNMP, page 305

• Ping Physical Ports, page 312

• Configuring the Users Table and Authentication Method, page 312

• SYN Flood Protection, page 313

• Keys and Certificates, page 318

ACLThe Access Control List (ACL) module is a stateful firewall that enables you to configure a flexible and focused stateful access-control policy. You can modify and view the active ACL policy. You can also view ACL report summaries and the ACL log analysis.

ACL in LinkProof does not work on the physical management ports (MNG 1 and MNG 2).

To operate correctly, ACL needs to determine the direction of session packets.

ACL determines packet direction as follows:

• TCP direction—According to the first SYN packet that creates a session.

• UDP direction—According to the first packet in the flow.

• ICMP direction—According to the ICMP message type (that is, reply or request type).

• Non-TCP, Non-UDP and Non-ICMP session direction—According to the first L3 (IP) packet in the flow.

• Non-IP direction—According to the first packet in the flow.

When ACL is enabled and activated, the device learns about the existing sessions for a specified amount of time (by default, 10 minutes). During this learning period, the device accepts all sessions regardless of any unknown direction. However, for the certain cases, ACL treats the session according to the configured policies.

ACL treats the session according to the configured policies in the following cases:

• A new TCP session starts with a SYN packet.

• A new ICMP session starts with a request packet.

Configuring the ACL feature involves the following steps:

1. Configuring ACL Global Parameters, page 298.

2. Configuring ACL Policy Rules, page 300.

Note: Enabling an ACL policy requires a device reboot.

LinkProof User Guide Security


Configuring ACL Global ParametersYou must enable the ACL feature before you can configure an ACL policy.

Note: Enabling ACL requires a device reboot.

To configure ACL global ACL parameters

1. Select Security > ACL > Global Settings.


Table 163: ACL Global Parameters

Parameter DescriptionACL Status Specifies whether the ACL feature is enabled.

When you change this setting, the device requires an immediate reboot.


Default: Disabled

Caution: The default configuration of the Default ACL policy blocks all traffic.

Learning Period The time, in seconds, the device takes to learn existing sessions before starting the protection.

During the learning period, the device accepts all sessions regardless of any “unknown” direction.

However, for the following cases, ACL will treat the session according to the configured policies:

• A new TCP session that starts with a SYN packet

• A new ICMP session that starts with a request packet

Values:

• 0—The protection starts immediately

• 1–max integer

Default: 600

TCP Handshake Timeout The time, in seconds, the device waits for the three-way handshake to complete before the device drops the session.

Default: 60

TCP Timeout in Established State

The time, in seconds, an idle session remains in the Session table. If the device receives packets for a timed-out, discarded session, the device considers the packets to be out-of-state and drops them.

Values: 60–7200

Default: 3600

LinkProof User GuideSecurity


TCP FIN Timeout The time, in seconds, the session remains in the Session table after the device receives a FIN packet from both sides (from the client and from the server).

Values: 1–600

Default: 10

TCP RST Timeout The time, in seconds, the session remains in the Session table after the device receives a TCP RST packet for the session.

Values: 1–600

Default: 30

TCP Mid Flow Mode Specifies what the device does with out-of-state packets.

Values: Drop, Allow

Default: Drop

TCP Reset Validation Mode Specifies the action that the device takes when RST packet validation fails (that is, the packet sequence number is not within the permitted range).

Values: Drop, Allow, ReportOnly

Default: Drop

UDP Timeout The time, in seconds, that the device keeps an idle UDP session open. After the timeout, the session is removed from the Session table.

Values: 1–3600

Default: 180

ICMP Timeout The time, in seconds, that the device keeps an idle ICMP session open. After the timeout, the session is removed from the Session table.

Values: 1–300

Default: 60

GRE Timeout The time, in seconds, that the device keeps an idle GRE session open. After the timeout, the session is removed from the Session table.

Values: 1–7200

Default: 3600

SCTP Timeout The time, in seconds, that the device keeps an idle SCTP session open. After the timeout, the session is removed from the Session table.

Values: 1–7200

Default: 3600

Allow ICMP Smurf Specifies whether the ACL module allows ICMP Smurf packets.

Values: True, False

Default: False

Other IP Protocols Timeout The time, in seconds, that the device keeps an idle session of other IP protocols (not UDP, not ICMP) open. After the timeout, the session is removed from the Session table.

Values: 1–7200

Default: 600

Table 163: ACL Global Parameters




Configuring ACL Policy Rules Configure ACL policy rules to create a flexible and focused stateful access-control policy.

You must enable the ACL feature before you can configure ACL reports.

Tip: You can activate and de-activate rules using predefined event schedules (see Event Scheduler, page 247).

Before you configure ACL rules, ensure that you have configured classes for the networks, physical port groups, and VLAN tag groups that you want to use in the rules.

To configure an ACL policy rule

1. Select Security > ACL > Modified Policies.


— To update policy, click the relevant link name.

— To create a new policy, click Create.


Table 164: ACL Rule Parameters

Parameter DescriptionPolicy Name The name of the rule up to 50 characters.

Index The index number for the rule. DefensePro examines policy rules according to the ascending order of index numbers.

Values: 1–max integer

Description The user-defined description of the rule.

Activate Scheduler The predefined event schedule that activates the policy.

Default: None

Inactivate Scheduler The predefined event schedule that de-activates the policy.

Default: None

Packet Report Status Specifies whether the device issues traps for the rule.


Default: Disable

Protocol The protocol of the traffic that the policy inspects.

Values:

• Any

• ICMP

• Other

• TCP

• UDP

• Other

• SCTP

Default: Any



Source The existing source Network class of the packets that the policy inspects.

Values:

• The Network classes displayed in the Classes tab

• any

• any_ipv4

• any_ipv6

Default: any

Destination The existing destination Network class of the packets that the policy inspects.

Values:

• The Network classes displayed in the Classes tab

• any

• any_ipv4

• any_ipv6

Default: any

Physical Port Group The Physical Port class or physical port that the rule uses.

Values:

• A Physical Port class displayed in the Classes tab

• The physical ports on the device

• None

Vlan Tag Group The existing VLAN Tag class for the rule.

Values:

• The VLAN Tag classes displayed in the Classes tab

• None

Default: None





Viewing Active ACL Policy RulesYou can view the active rules in the ACL policy configured on the device.

To view the active ACL rule configuration

Select Security > ACL > Active Policies.

The table displays details of the current ACL rules configured on the device. For information about ACL rule parameters, see ACL Rule Parameters, page 300.

Service

(Available only when TCP or UDP is selected for the Protocol parameter)

The Service for the rule. 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.

Action The action that the policy takes on packets that match the classification.

Values:

• Accept

• Drop

• Drop + Source RST

Default: Accept

ICMP Flags The ICMP flags in the packets that the policy inspects. The module inspects only the packets with the selected flags.

You can specify ICMP flags only when ICMP is the specified protocol.

Values:

• SRC-QUENCH—Source Quench

• TIME-STAMP—TIME STAMP

• INFO—Information

• ADDR-MASK—Address Mask

• ALT-HOST—Alternate Host Address

• DOMAIN—Domain

• ROUTE-ADV—Router Advertisement

• ROUTE-SOL—Router Solicitation

• DEST-UNREACH—Destination Unreachable

• REDIRECT—Redirect

• TIME-EX—Time Exceeded

• PARAM-PROB—Parameter Problem

• ECHO—Echo

• BIG-PCKT—Packet Too Big

• HOME-AGNT—Home Agent





Updating ACL Policies

To update the policies on the device

Select Security > ACL > Update Policies; and then, click Set.

Viewing and Managing ACL ReportsYou can view summary ACL reports and manage ACL report parameters.

You must enable the ACL feature before you can configure ACL reports.

To configure ACL report parameters

1. Select Security > ACL > Reports.


Table 165: ACL Report Parameters

Parameter DescriptionSummary Reports Period The frequency, in seconds, that the device produces ACL reports.

Values: 1–600

Default: 60

Send SRP Reports Specifies whether the module sends ACL policy reports to the using SRP.

Values: True, False

Default: False

Note: The Statistics Reporting Protocol (SRP) management host IP address must be configured to send ACL policy reports.

Max Detailed Reports Per Second

The maximum number of detailed reports that the device generates per second.

Values: 1–100

Default: 10



Ports AccessYou can specify how unbound UDP and TCP ports respond to SYN packets.

To set the port unreachable status

1. Select Security > Ports Status.

2. From the Port Unreachable Status drop-down list, select one of the following:

— Enabled—Unbound TCP ports answer SYN packets with an RST. Unbound UDP ports answer SYN packets with a port-unreachable message.

— Disabled—The device drops SYN or UDP packets without sending a reply. When the device uses this option, the device does not expose itself to the network.

Default: Enabled

3. Click Set.

Configuring Access for Physical 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.


Table 166: 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.

Default: Enabled



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 305

• SNMP User Table, page 306

• SNMP Community Table, page 306

• SNMP Groups Table, page 307

• SNMP Access Table, page 308

• SNMP View Table, page 308

• SNMP Notify Table, page 309

• Target Parameters Table, page 309

• Target Address Table, page 310

• Creating an SNMP User, page 311

SNMP Global Parameters

To set the SNMP Global parameters

1. Select Security > SNMP > Global Parameters. The SNMP Global Parameters pane is displayed.


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

Table 166: Management Port Parameters




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.


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.

Table 167: 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 168: 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.



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 169: 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 170: 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 171: 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 172: 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 173: 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 174: 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.

2. Set the parameters; and then, click Create User. The new SNMP user is created.

Table 175: 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

Table 176: SNMP User Parameters

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


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


2. Click Create. The User Table Create pane is displayed.


SYN Flood 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 177: 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 configure global SYN flood protection parameters

1. Select Security > SYN Flood Protection > Global Parameters. The SYN Flood Protection Parameters pane is displayed.


Table 178: SYN Flood Protection Parameters

Parameter DescriptionSYN Protection Status Specifies the status of SYN Flood Protection feature.

Values:

• Enabled—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: Disabled

TCP Handshake Timeout Specifies the timeout, in seconds, to complete the TCP three-way handshake.

Values:


• 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:


• 1–10

Default: 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 178: 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 179: 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 [sic] drop-down list, select the policy for which to display statistics. To display statistical data for all policies, leave the field empty.

3. Click Set.

To access the SYN statistics

Select Security > SYN Protection > Statistics. The SYN Protection Statistics pane is displayed.

For each policy, the following data is displayed:

To update the statistics

1. Select Security > SYN Protection > Statistics. The SYN Protection Statistics pane is displayed.

2. Under Reset SYN protection [sic] Statistics, click Set.

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

2. Set the parameters; and then, click Import. The certificate is imported.

Table 180: Import PKI Component Parameters

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.



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 an entry, click the certificate name. The Certificate Table Update pane is displayed.

— To create a new certificate, click Create. The Certificate Table Create pane is displayed.


Text In this area, you can paste the Certificate in encrypted text format.

Certificate File The filepath of the certificate file to import.

Table 181: 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.

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





Note: You can set the default values for the Certificate and CSR fields. For more information, see Default Values for Certificates, page 323.

Export Certificates from a 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:

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.

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 181: Certificate Parameters




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.

2. Set the parameters; and then, 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.

To configure default values for certificates

1. Select Security > Certificates > Default values. The Certificate Default Values 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.

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 183: 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 325

• Managing Bandwidth Management Global Parameters, page 326

• Bandwidth Management Policies, page 328

• Services, page 342

• Networks, page 353

• Port Groups, page 354

• Application Port Groups, page 355

• VLAN Tag Groups, page 356

• Discrete Networks, page 359

• Protocol Discovery, page 362

• Port Bandwidth, page 365

• Cancelling Interface Classification, page 365

• Example Time-based BWM Policy, page 366

Bandwidth Management 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 the following:

• 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—Enables you 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.

Application ClassificationLinkProof supports the following Application Classification modes:

• Per Packet—The device classifies every packet that flows through it. In this mode, the device individually classifies every single packet.

• Per Session—The device classifies all packets by session. The device classifies each packet in a session until it finds a best-fit policy is found, fully classifying the session. Once the device fully classifies a session fully classified, the device classifies all packets belonging to the same session accordingly. This allows for traffic classification according to application, and also saves some overhead for the classifier.

Classification ModeLinkProof supports the following classification modes:

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

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.


LinkProof User GuideBandwidth Management


Table 184: 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: Disable

Note: If you change the value for this parameter, you must reset the device.

Application Classification The type of application classification.

The process of session classification considers either of the following:

• Each packet of the session is classified until the number of Max Packets for Session Classification is reached.

• There is a match based on Force Best Fit.

• There is a match with a 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

Note: Changing the value takes effect when you update policies (BWM > Update Policies > Set).

BW per Traffic Flow Aging The time, in seconds, that the device keeps a non-active traffic flow in the BW flow tracking table.



Bandwidth Management PoliciesThis section describes Bandwidth Management policies and contains the following topics:

• Bandwidth Management Policy Mechanism, page 328

• Bandwidth Management Classification Criteria, page 329

• Bandwidth Management Rules, page 330

• Managing Bandwidth Management Policies, page 333

Bandwidth Management Policy MechanismThe policy mechanism enables you to classify and enforce bandwidth management on the traffic passing through the LinkProof device.

The policy database is made up of two sections. The first is the temporary or inactive portion. These policies can be altered and configured without affecting the current operation of the device. As these policies are adjusted, the changes are not in effect unless the inactive database is activated. The activation basically updates the active policy database, which is what the device uses to sort through the packets that flow through it.

A policy consists of a set of conditions (classification criteria) and a set of actions that apply as a consequence of the conditions being satisfied.

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





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 the BWM policy limits. LinkProof supports the following options:

— Client (source IP)

— Session (source IP and port)

— Connection (source IP and destination IP)

— FullL4Session (source and destination IP and port)

— SessionCookie (according to a specified cookie identifier)

— SipCallId (SIP Call ID)

• Cookie Field Identifier—A string that identifies the cookie field whose value the device uses determine the different traffic flows. This is required only when Traffic Flow Identification is set to SessionCookie.



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 the policy.

When traffic matches a policy, the Bandwidth Management module accepts the connection forwards the traffic to its destination, unless the bandwidth has been exceeded. Bandwidth Management module drops traffic that exceeds the specified bandwidth.

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 BandwidthYou can assign a minimum (guaranteed) bandwidth to a policy. The device will not allow packets that were classified through this policy to exceed this allotted bandwidth. The maximum bandwidth configured for the entire device overrides per-policy bandwidth configurations. In other words, the sum of the guaranteed bandwidth for all the policies cannot be higher than the total device bandwidth.

Traffic Flow Maximum BandwidthTraffic Flow Maximum Bandwidth is the maximum bandwidth allowed per traffic flow.



Max Concurrent SessionsMax Concurrent Sessions is the maximum concurrent sessions allowed for the BWM policy.

Packet MarkingPacket Marking refers to Differentiated Services Code Point (DSCP) or Diffserv. Packet Marking enables the device to mark the packet with a range of bits.

Bandwidth-Management-Policy 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 (see Default Policy, page 331).

Default Policy The Bandwidth Management module automatically creates a Default policy. The packets that match no user-defined policy match the Default policy. You cannot delete a Default policy, and you can modify only some of its configuration parameters. For example, the Index number of the Default policy is always 0, but you can modify the maximum bandwidth for it.

Policy Trees—Hierarchical Bandwidth-Management PoliciesYou can organize policies into a hierarchical, tree structure to configure hierarchical bandwidth borrowing domains. For example, you can define sets of policies for groups of users, departments, or customers. You can allocate bandwidth for a group (that is, for a branch), which allows bandwidth borrowing inside a group, but not necessarily among groups. Bandwidth that is not utilized by a specific policy under a tree node is allocated proportionally to the other policies, enabling them to borrow from other policies, preventing starvation and utilizing the bandwidth more efficiently.

The following figure shows two policy branches (Company 1 and Company 2) and the Default policy.

Figure 58: Example Hierarchical Bandwidth Management Configuration

Note: You can use the Policy Trees window to change the hierarchy by means of moving and copying child policies (see Configuring Policy Trees, page 341).

Com pany 2Guaranteed: 10M ax: 20

R&DG uaranteed: 30M ax: 50

Sales

M ax: 30

FTP

M ax: 30

Defau ltGuaranteed: 5

SM TPGuaranteed: 5

Defau lt

Com pany 1Guaranteed: 70M ax: 80

Defau lt

SM TPG uaranteed: 20

Defau lt

M ax: 0



Configuration Limitations and DependenciesThe Bandwidth Management module supports up to five levels of hierarchy.

Sibling policies share the bandwidth of the parent. The total bandwidth available for a parent policy is the sum of Guaranteed Bandwidth values of all its child policies. The total guaranteed bandwidth among sibling policies cannot exceed the guaranteed bandwidth of the parent.

Only a leaf node can be a matching policy. Therefore, each parent must have a Default child policy. The Bandwidth Management module creates the Default policies automatically. A Default policy will match all the traffic that matches the parent policy but does not match any of the sibling policies. You cannot delete a Default policy, and you can modify only some of its configuration parameters. For example, the Index number of the Default policy is always 0, but you can modify the maximum bandwidth for it.

Indexes in the branch are preserved. Indexes at lower levels indicate the classification order among sibling policies.

Each child node inherits the properties of its parent as follows:

• Enabling or disabling a parent policy affects all its child nodes. However, the configuration of the child nodes does not change.

• If you delete a parent policy, you delete all the child policies also.

• Each child policy inherits the Direction value of its parent. You can change the Direction value of a child policy only if the Direction of the parent is Two Way.

• You can specify the From Farm and To Farm values of a child node only if the value is unspecified in the parent.

Force Best Fit Force Best Fit provides information whether the classification is best fit for the session (in terms of packet content classification).

Classification is considered best fit if, at each level of the matching branch, one of the following conditions holds:

• The node is configured with Best Fit enabled.

• Not left sibling of the classification entry (which is matched by a non-filter match function) is configured with Best Fit enabled.

Hierarchical Policy Notation The names of the policies are displayed using a dot-delimited string to specify the hierarchy. The name of the first-level parent is first in the string.

Using the configuration in Figure 58 - Example Hierarchical Bandwidth Management Configuration, page 331, the names of the policies are as follows:

• Company 1

• Company 1.R&D

• Company 1.Sales

• Company 1.Sales.SMTP

• Company 1.Sales.Default

• Company 1.FTP

• Company 1.Default

• Company 2

• Company 2.SMTP

• Company 2.Default

• Default



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 333

• Viewing the Configuration of Active BWM Policies, page 335

• Configuring BWM Policy Extensions, page 337

• Viewing Active BWM Policy Extensions, page 340

• Configuring Policy Trees, page 341

• Updating BWM Policies, page 342

Configuring BWM Policies

To configure a BWM policy

1. Select BWM > Modify > Policies. The Modify Policies Table pane is displayed with a table comprising the following columns:

— Name

— Index

— Destination

— Source

— Service

2. Click Create. The Modify Policies Table Create pane is displayed.


Table 185: BWM Policy Parameters


For important information about Policy Trees, that is, hierarchical bandwidth management, see Policy Trees—Hierarchical Bandwidth-Management Policies, page 331.

Use the Policy Trees window to change the hierarchy by means of by moving and copying child policies (see Configuring Policy Trees, page 341).

Note: This value is read-only after creation.





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

Destination The destination of the packet being matched by the policy.

Values:

• A valid IP address or network address

• any—Any destination

• any_ipv4—Any IPv4 destination


Source The source of the packet being matched by the policy.

Values:






Service Type The type of service (filter).

Values:

• None

• Basic Filter

• AND Group

• OR Group

Default: None

Guaranteed Bandwidth The guaranteed bandwidth, in Kbit/s, for packets matching this policy. This option is used in conjunction with Class Based Queuing (CBQ).

Note: If you want this policy to drop all matching packets, enter 0.

Maximum Bandwidth The maximum bandwidth, in Kbit/s, for packets matching this policy.

Note: If you want this policy to drop all matching packets, enter 0.

Priority The priority attached to the packet by which it is forwarded.

Values:

• Real Time

• None

• 0–7—7 is the lowest priority.

Default: Real Time





Viewing the Configuration of Active BWM Policies

To view the configuration of an active BWM policy

1. Select BWM > View Active > Policies. The Active Policies Table pane is displayed with a table comprising the following columns:

— Name

— Index

— Destination

— Source

— Service

2. To view additional information on a specific policy, select the policy. The following fields are displayed read-only:

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

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

Default: None

Note: The group must be configured already.

Operational Status The operational status of the policy.

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



Description The description of the policy.

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.





Destination The destination of the packet being matched by the policy.

Values:





Source The source of the packet being matched by the policy.

Values:






Service Type The type of service (filter).

Values:

• None

• Basic Filter

• AND Group

• OR Group

Guaranteed Bandwidth The reserved bandwidth for packets matching this policy.

Note: You cannot configure a child policy with maximum bandwidth and guaranteed bandwidth higher than its parent policy, however, the sum of maximum bandwidth can be higher than the parent policy, and the sum of all guaranteed bandwidth must be less than or equal to the guaranteed bandwidth of the parent policy.

Maximum Bandwidth The maximum bandwidth that can be forwarded for traffic that matches this policy. The scheduler can borrow bandwidth from other queues, to forward packets from this policy queue that has exceeded, or are about to exceed, their guaranteed bandwidth up to this limit.

If this value is set to 0 this policy is burstable up to the maximum available bandwidth with no limit.

When hierarchical policies are configured, if one of the children does not consume all of its allocated bandwidth, another child, belonging to the same parent may use the spare bandwidth, which is limited by the Maximum Bandwidth value of the parent.

Note: You cannot configure a child policy with maximum bandwidth and guaranteed bandwidth higher than its parent policy, however, the sum of maximum bandwidth can be higher than the parent policy, and the sum of all guaranteed bandwidth must be less than or equal to the guaranteed bandwidth of the parent policy.




Configuring BWM Policy Extensions

To create a BWM policy extension

1. Select BWM > Modify > Policy Extensions. The Modify Policies Extensions pane is displayed with a table comprising the following columns:

— Name

— Traffic Flow Identification

— Traffic Flow Max BW (kbps)

— Max Concurrent Sessions

— Max HTTP Rqts Per Second

2. Select a policy. The Modify Policies Extensions Update pane is displayed


Priority The priority attached to the packet by which it is forwarded.

Values:

• Real Time

• None

• 0–7—7 is the lowest priority.

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

VLAN Tag Group The name of the VLAN tag group. For more information, see VLAN Tag Groups, page 356.




Table 186: BWM Policy Extension Parameters

Parameter DescriptionName (Read-only) The name of the policy.

Best Fit Specifies whether to classify packets using a best-fit method, which increases performance, but at the potential loss of accuracy.

Values:

• False—When the LinkProof device classifies traffic according to data in the TCP/UDP payload, even when a match is found for the first session packet, the device will continue to look for a match for subsequent packets.

• True— Once the device matches the first packet of a session to a BWM policy, the device stops classification of the packets belonging to the same session and processes the entire session according to the first matched policy. When hierarchical policies are configured, if Best Fit is True on a parent policy, and a packet is matched to that policy, the device searches for the best fit only among the child policies of the parent policy.

Default: False

Note: The Best Fit parameter is relevant only when the Application Classification mode is Per-session, not Per-packet.

Activation Schedule The Event Schedule for making the BWM policy active. For more information, see Event Scheduler, page 247.

Default: None

Note: The schedule must be configured already.

Inactivation Schedule The Event Schedule for making the BWM policy inactive. For more information, see Event Scheduler, page 247.

Default: None

Note: The schedule must be configured already.

Packet Marking Type Marks the packet with a range of bits displayed in the drop-down list.

Values:

• DSCP—The device marks the Differentiated Services Code Point value.

• ToS—The device marks the Type of Service value.

• None—The device does no marking.

Default: None

Packet Marking Value The Packet Marking value.

Values:

• None

• For DCSP, a value in the range 0–63.

• For ToS, a value in the range 0–7.

Default: None



Traffic Flow Identification

The type of traffic flow that this policy limits.

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.

• SessionCookie—Session cookie according to the specified Cookie Identifier.

• SipCallId—SIP Call ID.

Default: None

Traffic Flow Max BW The maximum bandwidth, in Kbit/s, allowed per traffic flow.

Default: 0

Max Concurrent Sessions

The maximum number of concurrent sessions allowed for a client IP.

Default: 0

Note: This option is not available if the Traffic Flow Identifier is set to Session or FullL4Session.

Max HTTP Rqts Per Second

The maximum number of HTTP requests per second (such as HTTP GET or POST or HEAD) per cookie when Traffic Flow Identification is specified (not None) and Traffic Flow Max BW is not 0.

Default: 0

Cookie Field Identifier The string that identifies the cookie field. The Cookie Field Identifier is required only when Traffic Flow Identification is set to SessionCookie. When Traffic Flow Identification is set to SessionCookie, the BWM classifier searches for the Cookie Field Identifier followed by “=” and classifies flows according to the value.

Classification Point Specifies whether the classification is done before of after packet modification.

Value:

• After Changes—Classifies the packet after the device has modified the packet.

• Before Changes—Classifies the packet before the device has modified the packet.

Default: After Changes

From Farm The source farm of the traffic that the BWM policy classifies.

To Farm The destination farm of the traffic that the BWM policy classifies.

Table 186: BWM Policy Extension Parameters




Viewing Active BWM Policy Extensions

To view the configuration of active BWM policy extensions

1. Select BWM > View Active > Policy Extensions. The Active Policies Extenstions pane is displayed with a table comprising the following columns:

— Name

— Traffic Flow Identification

— Traffic Flow Max BW (kbps)

— Max Concurrent Sessions

— Max HTTP Rqts Per Second

2. To view additional information on a specific policy, select the policy. The following fields described are displayed read-only:

Parameter DescriptionName The name of the policy.

Best Fit Specifies whether to classify packets using a best-fit method, which increases performance, but at the potential loss of accuracy.

Values:

• False—When the LinkProof device classifies traffic according to data in the TCP/UDP payload, even when a match is found for the first session packet, the device will continue to look for a match for subsequent packets.

• True— Once the device matches the first packet of a session to a BWM policy, the device stops classification of the packets belonging to the same session and processes the entire session according to the first matched policy. When hierarchical policies are configured, if Best Fit is True on a parent policy, and a packet is matched to that policy, the device searches for the best fit only among the child policies of the parent policy.

Note: The Best Fit parameter is relevant only when the Application Classification mode is Per-session, not Per-packet.

Activation Schedule The Event Schedule for making the BWM policy active. For more information, see Event Scheduler, page 247.

Inactivation Schedule The Event Schedule for making the BWM policy inactive. For more information, see Event Scheduler, page 247.

Packet Marking Type Marks the packet with a range of bits displayed in the drop-down list.

Values:

• DSCP—The device marks the Differentiated Services Code Point value.

• ToS—The device marks the Type of Service value.

• None—The device does no marking.



Configuring Policy TreesUse the Policy Trees pane to configure hierarchical bandwidth management. You can modify the hierarchies by moving and copying parent and child policies.

For more information, see Policy Trees—Hierarchical Bandwidth-Management Policies, page 331.

Packet Marking Value The Packet Marking value.

Values:

• None

• For DCSP, a value in the range 0–63.

• For ToS, a value in the range 0–7.

Traffic Flow Identification

The type of traffic flow that this policy limits.

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.

• SessionCookie—Session cookie according to the specified Cookie Identifier.

• SipCallId—SIP Call ID.

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.

Max HTTP Rqts Per Second

The maximum number of HTTP requests per second (such as GET, POST, or HEAD) when Traffic Flow Identification is specified (other than None) and Traffic Flow Max BW is configured (other than 0).

Default: 0

Cookie Field Identifier The string that identifies the cookie field. The Cookie Field Identifier is required only when Traffic Flow Identification is set to SessionCookie. When Traffic Flow Identification is set to SessionCookie, the BWM classifier searches for the Cookie Field Identifier followed by “=” and classifies flows according to the value.


Value:

• After Changes—Classifies the packet after the device has modified the packet.

• Before Changes—Classifies the packet before the device has modified the packet.

From Farm The source farm of the traffic that the BWM policy classifies.

To Farm The destination farm of the traffic that the BWM policy classifies.




To configure the Policy Tree window parameters

1. Select BWM > Modify > Policy Trees. The Policy Trees window 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.

Table 187: Policy Tree Parameters

Parameter DescriptionPolicy Name The name of the policy.

Parent Name The parent policy for this policy.

Action Specifies whether to move or copy this policy to the specified parent policy. You can move a child policy to a higher position in the hierarchy. You can move or copy a parent policy with all its children to a position under another policy (either under a parent or another child). You cannot move or copy a parent policy to a position under a child.

Values: copy, move

Default: copy




• Basic Filters, page 343

• AND Group Filters, page 350

• OR Group Filters, page 351

• Special Service—Special Filters, page 1

• Viewing Active Services, page 352

Basic FiltersLinkProof supports an extensive list of predefined basic filters (see Predefined Basic Filters, page 344). You can also create your own basic filters.

A basic filter is a building block for packet or session classification. A filter match can be done according to application protocol, application ports, bit masks and textual classification. There are numerous predefined filters that the user can choose from. In addition to these, the user can create their own filters to meet their specific requirements.

These basic filters can be combined into more complex filters by using AND groups and OR groups.

A basic filter includes the following components:

• 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 401.

Example Basic FilterAlthough not typically the case, this example configuration of a basic filter combines both OMPC matching and content matching.

Table 188: Example Basic Filter Configuration

Parameter Example ValueName MyBasicFilter

Protocol TCP

Source App. Port Not specified

Destination App. Port Not specified

OMPC Offset Relative to L4 Data

OMPC Offset 0

OMPC Mask ffffff00

OMPC Pattern 41424300



This search defined by this basic filter searches for TCP packets from any port to any port. The OMPC fields specify that the three bytes starting 0 bytes after the start of the L4 data must be 414243, which is the hexadecimal ASCII representation of ABC. In addition, the string hello will be searched for in the area between 67 bytes and 80 bytes after the end of the TCP header. The search will be case-insensitive.

Configuring Basic Filters

Caution: If you modify the configuration of a filter that is used in an existing policy, you need to activate the latest changes (Classes > Update Policies > Set).

To configure a basic filter

1. Select Classes > Modify Services > Basic Filters. The Modify Basic Filter Table pane is displayed. The Modify Basic Filter Table pane contains a table with the following columns:

— Name

— Description

— Protocol

— OMPC Offset

— OMPC Mask

2. Select the relevant link. The Modify Basic Filter Table Update pane is displayed.


OMPC Condition Equal

OMPC Length Three Bytes

Content Offset 67

Content hello

Content Type Text

Content End Offset 80

Content Data Not specified

Content Coding Case Insensitive

Content Data Coding None

Description My basic filter

Table 188: Example Basic Filter Configuration

Parameter Example Value



Table 189: Basic Filter Parameters

Parameter DescriptionName (Read-only) The 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.

3. Set the following parameters:

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 190: 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 191: 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 192: 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.

2. Click Create. The Modify Physical Port Groups Table Create pane is displayed.


Viewing Active Port Groups

To view active port groups

Select Classes > View Active > Port Groups. The Active Physical Port Groups Table pane is displayed is displayed with the following read-only parameters:

— Group Name

— Inbound Port

Application Port 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 193: 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 194: 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 195: 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 196: 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 a 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 198: Modify MAC Address Groups Parameters

Parameter DescriptionGroup Name The name of the MAC address group.

MAC Address The MAC address.

Table 199: 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 200: 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 200: 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 362

• Protocol Statistics Global Parameters, page 363

• Protocol Discovery Policies, page 363

• Viewing the Protocol Discovery Statistics, page 365

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 201: 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 202: 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 203: 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


Values:

• After Changes—Classifies the device after the packet changes.

• Before Changes—Classifies the device before the packet changes.

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

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 367

2. Configuring the Example Start-Event Schedule, page 367

3. Configuring the Example Finish-Event Schedule, page 368

4. Associating the Start- and Finish-Event Schedules with the Example BWM Policy, page 368

5. Activating the Latest Changes for the Example BWM Policy, page 369


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 205: 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 206: 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 207: 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 208: 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 206: 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 208: BWM Policy Extension Parameters for Example Time-based BWM Policy

Parameter Value


Chapter 9 – Health MonitoringThis chapter describes Health Monitoring.


• Health Monitoring—Introduction, page 371

• Health Check Configuration, page 373

• Farm Health Checks, page 398

Health Monitoring—IntroductionThis section describes the general function of the Health Monitoring module and the basic health-monitoring concepts.


• Health Monitoring Module, page 371

• Response Level, page 371

• Checked Elements, page 372

• Health Checks, page 372

• Methods, page 372

• Binding and Groups, page 372

Health Monitoring 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 374.

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 212 - Health Check Methods, page 378.

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 373

• Managing the Health Checks in the Check Table, page 374

• Bindings and Groups, page 390

• User-Defined Health Check Methods—Packet Sequence Table, page 391

• Configuring a Diameter Health Check, page 394

Configuring Health Monitoring Global Parameters

To configure the global parameters for health monitoring

1. Select Health Monitoring > Global Parameters. The Health Monitoring Global Parameters pane is displayed.


Table 209: 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 374.

• Create a new health check. For more information, see Creating a Regular Health Check, page 374.

• View and modify some parameters of the health checks that are currently defined in a database, prior to applying them to a network element. For more information, see the procedure To view or modify the configuration of a health check, page 376.

Health Monitoring Check 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 372).

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

To view the Health Monitoring Check Table

Select Health Monitoring > Check Table. The Health Monitoring Check Table pane is displayed.

Creating a Regular Health 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 372), the check is still performed. If it fails, the device sends failure-notification messages, as configured (SNMP traps, syslog messages, or E-mail).

To create a regular health check

1. 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 210: 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 212 - Health Check Methods, page 378.

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 211 - Health Monitoring Check Table Update Parameters, page 376.

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 211: Health Monitoring Check Table Update Parameters

Parameter DescriptionCheck Name (Read-only) The user-defined name of the health check.

Method The method for the health check (read-only). For descriptions of the methods, see Table 212 - Health Check Methods, page 378.

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 210: Health Monitoring Check Table Create Parameters




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 211: Health Monitoring Check Table Update 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.

Table 212: 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 394 and Managing Binary File Transfer for Diameter Health Checks, page 397.

DNS The module submits a DNS query to the configured destination address and host. The module verifies that the reply is received with no errors, and that the reply matches a specific address (if specified). If the IP address parameter is not defined, only the return code of the reply is validated (not the IP address it contains).


• Host Name—The name of the to query.

• Host Address—The address to match.

FIX The module creates a Financial Information eXchange (FIX) protocol1 packet and sends it to the FIX server (after the TCP handshake). A successful check is a check where in the reply packet, the TestReqID value is the same as the one configured. The SenderCompID is the configured value of the TargetCompID field and vice versa, and the FIX version is the same as the configured value.


• 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 386 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.


1 – 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 390.

4. Click Set.

Viewing or Modifying the Configuration of a Health Check Binding

To view or modify the configuration of a health check binding

1. Select Health Monitoring > Binding Table. The Health Monitoring Binding Table pane is displayed.

2. Select the required binding. The Health Monitoring Binding Table Update pane is displayed.

3. View or modify the available parameters, which are described in Table 7 - Health Monitoring Binding Table Parameters, page 390.

4. Click Set.

User-Defined Health Check 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 395.

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

• 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



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




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.

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 – IPv6 FundamentalsThis appendix is included as additional background reference for further study of IPv6 and includes the following topics:

• IPv4 Versus IPv6, page 411

• Name Resolution, page 412

• Internet Protocol Version 6 (IPv6), page 413

• IPv6 Address Autoconfiguration, page 415

IPv4 Versus IPv6Internet Protocol version 6 (IPv6) is a network layer protocol for packet-switched internetworks. It is designated as the successor of IPv4, the current version of the Internet Protocol, for general use on the Internet.

The main improvement brought by IPv6 is the increase in the number of addresses available for networked devices, allowing, for example, each cell phone and mobile electronic device to have its own address. IPv4 supports 232 (about 4.3 billion) addresses, which is inadequate for giving even one address to every living person, let alone supporting embedded and portable devices. IPv6, however, supports 2128 addresses; this is approximately 5 × 1028 addresses for each of the roughly 6.5 billion people alive today.

The following table displays a quick summary of the key differences between IPv4 and IPv6 protocols.

Table 13: IPv4 Versus IPv6

IPv4 IPv6Source and destination addresses are 32 bits(4 bytes) in length.

Source and destination addresses are 128 bits (16 bytes) in length.

IPSec support is optional. IPSec support is required.

No identification of packet flow for QoS handling by routers is present within IPv4.

Packet flow identification for QoS handling by routers is present within the IPv6 header using the Flow Label field.

Fragmentation is performed by the sending host, and at the routers, thus slowing performance.

Fragmentation is performed only by the sending host.

No link-layer packet size requirements and has to reassemble 576-byte packet.

Link layer must support 1,280 byte packet and rea sse mb el a 1,500 byte packet.

Header includes a checksum. Header does not include a checksum.

Header includes options. All optional data is moved to IPv6 extension headers.

ARP uses Broadcast ARP Request frames to resolve an IPv4 address to a link layer address.

ARP Request frames are replaced with multicast Neighbor Solicitation (Discovery) messages.

IGMP is used to manage local subnet group membership.

IGMP is replaced with Multicast Listener Discovery (MLD) messages.

ICMP Router Discovery is used to determine the IPv4 address of the best default gateway and is optional.

ICMPv4 Router Discovery is replaced with ICMPv6 Router Solicitation (Discovery) and Router Advertisement messages and is required.

LinkProof User Guide IPv6 Fundamentals


Name ResolutionWhile IPv6 is designed to work with the 128-bit IPv6 addresses of the source and the destination hosts, computer users are likely to experience difficulty in using and remembering the IPv6 addresses of the computers with which they want to communicate. Unique names, which are easier to remember, can be used instead.

If a name is used as an alias for an IPv6 address, you need to ensure that the name is unique and that it resolves to the correct IPv6 address. The IPv6 protocol for the Windows Server 2003 family can use host names to resolve a name to an IPv6 address. Host names are used by programs that use Windows Sockets.

Host name resolution is successfully mapping a host name to an IPv6 address. A host name is an alias that is assigned to an IPv6 node, identifying it as an IPv6 host. The host name can be up to 255 characters long and can contain alphabetic and numeric characters, hyphens, and periods. You can assign multiple host names to the same host.

Windows Sockets (Winsock) programs can use one of two values for the destination to which you want to connect: the IPv6 address or a host name. When the IPv6 address is specified, name resolution is not required. When a host name is specified, the host name must be resolved to an IPv6 address before IPv6-based communication with a resource can begin.

Host names can take various forms. The two most common forms are a nickname and a domain name. A nickname is an alias for an IPv6 address that individuals can assign and use. A domain name is a structured name in a hierarchical namespace named Domain Name System (DNS). An example of a domain name is www.microsoft.com.

Nicknames or domain names are resolved through entries in the Hosts file, which is stored in the systemroot\System32\Drivers\Etc folder. For IPv6 name-to-address entries, the IPv6 address is written by using standard colon-hexadecimal format. For more information, see Expressing IPv6 addresses and TCP/IP database files.

Domain names are resolved by sending DNS name queries to a configured DNS server, which is a computer that either stores domain name-to-IPv6 address mapping records or has records of other DNS servers. The DNS server resolves the queried domain name to an IPv6 address and returns the results. The DNS client in Windows XP and the Windows Server 2003 family supports the processing of AAAA (quad-A) resource records. All DNS queries and responses are sent by using IPv6 and IPv4. DNS name devolution for fully qualified domain names is also supported. For more information, see DNS defined.

Broadcast addresses are used to send traffic to all nodes on the subnet.

There are no IPv6 broadcast addresses. Instead a link-local scope all-nodes multicast address is used.

Must be configured either manually or through DHCP for IPv4.

IPV6 does not require manual or DHCP configuration.

Uses host address (A) resource records in DNS to map host names to IPv4 addresses.

Uses AAAA records in the DNS to map host names to IPv6 addresses.

Uses pointer (PTR) resource records in the IN-ADDR.ARPA DNS domain to map IPv4 addresses to host names.

Uses pointer (PTR) resource records in the IP6.INT DNS domains to map IPv6 addresses to host names.

Table 13: IPv4 Versus IPv6

IPv4 IPv6

LinkProof User GuideIPv6 Fundamentals


Internet Protocol Version 6 (IPv6)IPv6 is defined in RFC 2460, Internet Protocol, Version 6 (IPv6) Specification. IPv6 is a connectionless, unreliable datagram protocol used primarily for addressing and routing packets between hosts.

Connectionless means that a session is not established before exchanging data. Unreliable means that delivery is not guaranteed. IPv6 always makes a best-effort attempt to deliver a packet. An IPv6 packet might be lost, delivered out of sequence, duplicated, or delayed. IPv6 does not attempt to recover from these types of errors. The acknowledgment of packets delivered and the recovery of lost packets are done by a higher-layer protocol, such as TCP.

An IPv6 packet, also known as an IPv6 datagram, consists of an IPv6 header and an IPv6 payload, as shown in the following illustration.

The IPv6 header field specifies the following:

• Source Address—The IPv6 address of the original source of the IPv6 packet.

• Destination Address—The IPv6 address of the intermediate or final destination of the IPv6 packet.

• Hop Limit—The number of network segments on which the packet is allowed to travel before being discarded by a router. The Hop Limit is set by the sending host and is used to prevent packets from endlessly circulating on an IPv6 internetwork. When forwarding an IPv6 packet, IPv6 routers are required to decrease the Hop Limit by 1 and to discard the IPv6 packet when the Hop Limit is 0.

• Next Header—8-bit selector. This identifies the type of header immediately following the IPv6 header. It uses the same values as the IPv4 Protocol field [RFC-1700 et seq.].

Internet Control Message Protocol for IPv6 (ICMPv6)Internet Control Message Protocol for IPv6 (ICMPv6) is a required IPv6 standard defined in RFC 2463, ‘Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification.” With ICMPv6, hosts and routers that use IPv6 communication can report errors and send simple echo messages.

The ICMPv6 protocol also provides a framework for the following:

• Multicast Listener Discovery (MLD)—A series of three ICMPv6 messages that replace version 2 of the Internet Group Management Protocol (IGMP) for IPv4 to manage subnet multicast membership. For more information, see Multicast Listener Discovery (MLD).

• Neighbor Discovery (NDisc)—A series of five ICMPv6 messages that manage node-to-node communication on a link. Neighbor Discovery replaces Address Resolution Protocol (ARP), ICMPv4 Router Discovery, and the ICMPv4 Redirect message and provides additional functions. For more information, see Neighbor Discovery (NDisc).

ICMPv6 messages are usually sent automatically when an IPv6 packet cannot reach its destination.

IPv6 Header IPv6 Payload

IPv6 Packet

Message



ICMPv6 messages are encapsulated and sent as the payload of IPv6 packets, as shown in the following illustration.

Different types of ICMPv6 messages are identified in the ICMPv6 header. Because ICMPv6 messages are carried in IPv6 packets, they are unreliable.

ICMPv6 messages not related to MLD or NDisc are listed and described in the following table.

You can use the ping command to send ICMPv6 Echo Request messages and record the receipt of ICMPv6 Echo Reply messages. With ping, you can detect network or host communication failures and troubleshoot common IPv6 connectivity problems. For more information, see Test IPv6 connectivity by using the ping command.

You can use the tracert command to send ICMPv6 Echo Request messages with incrementally increasing values in the Hop Limit field. Tracert will trace and display the path taken by IPv6 packets between a source and destination, allowing you to troubleshoot common IPv6 routing problems.

Table 14: ICMPv6 Messages Not Related to MLD or NDisc

ICMPv6 message Description Destination Unreachable An error message that informs the sending host that a packet cannot

be delivered.

Packet Too Big An error message that informs the sending host that the packet is too large to forward.

Time Exceeded An error message that informs the sending host that the Hop Limit of an IPv6 packet has expired.

Parameter Problem An error message that informs the sending host that an error was encountered in processing the IPv6 header or an IPv6 extension header.

Echo Request An informational message that is used to determine whether an IPv6 node is available on the network.

Echo Reply An informational message that is used to reply to the ICMPv6 Echo Request message.

IPv6 Header IPv6 Payload

IPv6 Packet

ICMPv6 Message

ICMPv6 Header

Message



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

Address autoconfiguration can only be performed on multicast-capable interfaces. Address autoconfiguration is described in RFC 2462, IPv6 Stateless Address Autoconfiguration.

Autoconfigured Address StatesAutoconfigured addresses are in one or more of the following states:

• Tentative—The address is in the process of being verified as unique. Verification occurs through duplicate address detection.

• Preferred—An address for which uniqueness has been verified. A node can send and receive unicast traffic to and from a preferred address. The period of time that an address can remain in the tentative and preferred states is included in the Router Advertisement message.

• Deprecated—An address that is still valid, but its use is discouraged for new communication. Existing communication sessions can continue to use a deprecated address. A node can send and receive unicast traffic to and from a deprecated address.

• Valid—An address from which unicast traffic can be sent and received. The valid state covers both the preferred and deprecated states. The amount of time that an address remains in the tentative and valid states is included in the Router Advertisement message. The valid lifetime must be greater than or equal to the preferred lifetime.

• Invalid—An address for which a node can no longer send or receive unicast traffic. An address enters the invalid state after the valid lifetime expires.

Types of AutoconfigurationThere are three types of autoconfiguration, Stateless, Stateful and Both.

• Stateless—Configuration of addresses is based on the receipt of Router Advertisement messages. These messages include stateless address prefixes and require that hosts not use a stateful address configuration protocol.

• Stateful—Configuration is based on the use of a stateful address configuration protocol, such as DHCPv6, to obtain addresses and other configuration options. A host uses stateful address configuration when it receives Router Advertisement messages that do not include address prefixes and require that the host use a stateful address configuration protocol. A host will also use a stateful address configuration protocol when there are no routers present on the local link.

• Both—Configuration is based on receipt of Router Advertisement messages. These messages include stateless address prefixes and require that hosts use a stateful address configuration protocol.

For all autoconfiguration types, a link-local address is always configured.

Autoconfiguration ProcessThe address autoconfiguration process for an IPv6 node occurs as follows:

1. A tentative link-local address is derived, based on the link-local prefix of FE80::/64 and the 64-bit interface identifier.

2. Duplicate address detection is performed to verify the uniqueness of the tentative link-local address.



3. If duplicate address detection fails, manual configuration must be performed on the node.

4. If duplicate address detection succeeds, the tentative link-local address is assumed to be unique and valid. The link-local address is initialized for the interface. The corresponding solicited-node multicast link-layer address is registered with the network adapter.

For an IPv6 host, address autoconfiguration continues as follows:

1. The host sends a Router Solicitation message.

2. If no Router Advertisement messages are received, then the host uses a stateful address configuration protocol to obtain addresses and other configuration parameters. The IPv6 protocol for the Windows Server 2003 family and Windows XP does not support the use of a stateful address configuration protocol.

3. If a Router Advertisement message is received, the configuration information that is included in the message is set on the host.

4. For each stateless autoconfiguration address prefix that is included:

a. The address prefix and the appropriate 64-bit interface identifier are used to derive a tentative address.

b. Duplicate address detection is used to verify the uniqueness of the tentative address.

c. If the tentative address is in use, the address is not initialized for the interface.

d. If the tentative address is not in use, the address is initialized. This includes setting the valid and preferred lifetimes based on information included in the Router Advertisement message.

e. If it is specified in the Router Advertisement message, the host uses a stateful address configuration protocol to obtain additional addresses or configuration parameters.

IPv6 RoutingRouting is the process of forwarding packets between connected network segments. For IPv6-based networks, routing is the part of IPv6 that provides forwarding capabilities between hosts that are located on separate segments within a larger IPv6-based network.

IPv6 is the mailroom in which IPv6 data sorting and delivery occur. Each incoming or outgoing packet is called an IPv6 packet. An IPv6 packet contains both the source address of the sending host and the destination address of the receiving host. Unlike link-layer addresses, IPv6 addresses in the IPv6 header typically remain the same as the packet travels across an IPv6 network.

Routing is the primary function of IPv6. IPv6 packets are exchanged and processed on each host by using IPv6 at the Internet layer.

Above the IPv6 layer, transport services on the source host pass data in the form of TCP segments or UDP messages down to the IPv6 layer. The IPv6 layer creates IPv6 packets with source and destination address information that is used to route the data through the network. The IPv6 layer then passes packets down to the link layer, where IPv6 packets are converted into frames for transmission over network-specific media on a physical network. This process occurs in reverse order on the destination host.

IPv6 layer services on each sending host examine the destination address of each packet, compare this address to a locally maintained routing table, and then determine what additional forwarding is required. IPv6 routers are attached to two or more IPv6 network segments that are enabled to forward packets between them.

IPv6 RoutersIPv6 network segments, also known as links or subnets, are connected by IPv6 routers, which are devices that pass IPv6 packets from one network segment to another. This process is known as IPv6 routing and is shown in the following illustration.

IPv6 routers provide the primary means for joining together two or more physically separated IPv6 network segments. All IPv6 routers have the following characteristics:

IPv6 routers are physically multihomed hosts.



A physically multihomed host is a network host that uses two or more network connection interfaces to connect to each physically separated network segment.

IPv6 routers provide packet forwarding for other IPv6 hosts.

IPv6 routers are distinct from other hosts that use multihoming. An IPv6 router must be able to forward IPv6-based communication between networks for other IPv6 network hosts.

You can implement IPv6 routers by using a variety of hardware and software products, including a computer running a member of the Windows Server 2003 family with the IPv6 protocol. Routers that are dedicated hardware devices running specialized software are common. Regardless of the type of IPv6 routers that you use, all IPv6 routing relies on a routing table to communicate between network segments.

Routing TablesIPv6 hosts use a routing table to maintain information about other IPv6 networks and IPv6 hosts. Network segments are identified by using an IPv6 network prefix and prefix length. In addition, routing tables provide important information for each local host regarding how to communicate with remote networks and hosts.

For each computer on an IPv6 network, you can maintain a routing table with an entry for every other computer or network that communicates with that local computer. In general, this is not practical, and a default router is used instead.

Before a computer sends an IPv6 packet, it inserts its source IPv6 address and the destination IPv6 address (for the recipient) into the IPv6 header. The computer then examines the destination IPv6 address, compares it to a locally maintained IPv6 routing table, and takes appropriate action.

The appropriate action may be one of the following three:

• The computer passes the packet to a protocol layer above IPv6 on the local host.

• The computer forwards the packet through one of its attached network interfaces.

• The computer discards the packet.

IPv6 searches the routing table for the route that is the closest match to the destination IPv6 address. The most specific to the least specific route is determined in the following order:

1. A route that matches the destination IPv6 address (a host route with a 128-bit prefix length).

2. A route that matches the destination with the longest prefix length.

3. The default route (the network prefix::/0).

If a matching route is not found, the destination is determined to be an on-link destination.

The IPv6 Routing TableEvery computer that runs IPv6 determines how to forward packets based on the contents of the IPv6 routing table. To display the IPv6 routing table on a computer that is running a member of the Windows Server 2003 family or Windows XP, type netsh interface ipv6 show routes at the command prompt.

Entries in the IPv6 routing table consist of:

• An address prefix

• The interface over which packets matching the address prefix are sent

• A forwarding or next-hop address

• A preference value used to select between multiple routes with the same prefix

• The lifetime of the route

• The specification of whether the route is published (advertised in a Routing Advertisement)

• The specification of how the route is aged

• The route type



The IPv6 routing table is built automatically, based on the current IPv6 configuration of your computer. When forwarding IPv6 packets, the routing table is searched by your computer for an entry that is the most specific match to the destination IPv6 address. A route for the link-local prefix (FE80::/64) is not displayed.

The default route (a route with a prefix of ::/0) is typically used to forward an IPv6 packet to a default router on the local link. Because the router that corresponds to the default router contains information about the network prefixes of the other IPv6 subnets within the larger IPv6 internetwork, it forwards the packet to other routers until it is eventually delivered to the destination.

IPv6 Configuration ItemsYou can configure the following for the IPv6 protocol:

• IPv6 address

• Default router

• DNS server

IPv6 AddressBy default, link-local addresses are automatically configured for each interface on each IPv6 node (host or router) with a unique link-local IPv6 address. If you want to communicate with IPv6 nodes that are not on attached links, the host must have additional site-local or global unicast addresses. Additional addresses for hosts are either obtained from router advertisements sent by a router or assigned manually. Additional addresses for routers must be assigned manually.

Default RouterTo communicate with IPv6 nodes on other network segments, IPv6 must use a default router. A default router is automatically assigned based on the receipt of a router advertisement. Alternately, you can add a default route to the IPv6 routing table. You do not need to configure a default router for a network that consists of a single network segment.

DNS ServerYou can use a Domain Name System (DNS) server to resolve host names to IPv6 addresses. When an IPv6 host is configured with the address of a DNS server, the host sends DNS name queries to the server for resolution. AAAA (quad-A) resource records, which are stored on your DNS servers, enable mapping from a host name to its IPv6 address.

To enable DNS name resolution, configure an IPv6 router with forwarding enabled and a global prefix that is advertised to clients. You can do this by using the netsh interface ipv6 add route and netsh interface ipv6 set interface commands. For more information, see Add an IPv6 route and Enable IPv6 forwarding.

By default, DNS is configured to allow DNS dynamic updates. You can either leave dynamic update enabled when you use IPv6 with DNS, or you can manually add DNS records for IPv6 clients.

Configuring Clients with the DNS Server AddressTo provide communication between DNS clients and servers, you can configure the clients with the IPv6 address of the DNS server, or you can configure your DNS server with one of the three default DNS server IPv6 addresses that are automatically configured on all IPv6 clients.

You can configure clients with the IPv6 address of the DNS server by using the netsh interface ipv6 add dns command at each client computer or in a logon script that is run each time a client logs on to the network.

To configure the DNS server with one of the three IPv6 addresses that are available on IPv6 client computers by default, use the netsh interface ipv6 add address command.



The three default DNS server addresses are:

• FEC0:0:0: FFFF::1

• FEC0:0:0: FFFF::2

• FEC0:0:0:FFFF::3

If your DNS server is on a different subnet than your IPv6 clients, configure a static route to the DNS server on any IPv6 router that is available on the DNS server's subnet.

Configuring the DNS Server to Listen on IPv6You can configure the DNS server to listen for DNS name registration and resolution requests over IPv6. When your DNS server is configured to listen on both IPv4 and IPv6:

Devices that function over IPv6 but not IPv4 will function properly with your DNS server.

Computers and other devices that are configured with both IPv4 and IPv6 use IPv6 by default.

IPv6 Neighbor DiscoveryIPv6 Neighbor Discovery (NDisc) is a set of messages and processes that determine relationships between neighboring nodes. NDisc replaces Address Resolution Protocol (ARP), Internet Control Message Protocol (ICMP) Router Discovery, and ICMP Redirect, which are used in IPv4, and provides additional functionality. NDisc is described in RFC 2461, Neighbor Discovery for IP Version 6 (IPv6).

NDisc is used by routers to:

• Advertise their presence, host configuration parameters, and on-link prefixes.

• Inform hosts of a better next-hop address to forward packets for a specific destination.

NDisc is used by nodes to:

• Both resolve the link-layer address of a neighboring node to which an IPv6 packet is being forwarded and determine when the link-layer address of a neighboring node has changed.

• Determine whether IPv6 packets can be sent to and received from a neighbor.

The following table lists and describes NDisc processes.

Table 15: NDisc Processes

Parameter DescriptionRouter Discovery The process by which a host discovers the local routers on an

attached link (equivalent to ICMPv4 Router Discovery) and automatically configures a default router (equivalent to a default gateway in IPv4).

Prefix Discovery Process where a host discovers network prefixes for local destinations.

Parameter Discovery Process by which a host discovers additional operating parameters, including the link maximum transmission unit (MTU) and the default hop limit for outbound packets.

Address Autoconfiguration Process for configuring IP addresses for interfaces in either the presence or absence of a stateful address configuration server such as Dynamic Host Configuration Protocol version 6 (DHCPv6). For more information, see IPv6 address autoconfiguration.



LinkProof learns the MAC addresses of IPv6 servers and routers by intercepting solicited and unsolicited Neighbor Advertisement messages as well as Neighbor discovery messages with source link-layer address (MAC) present. Neighbor discovery messages are validated first to prevent common attack of stealing IP addresses by off-link nodes pretending to be on-link.

Notes>> The hop limit must be 255. If this fails, silently discard the NS message.

>> Check that the source IP prefix in the Neighbor discovery message matches any of the prefixes of the IP interfaces on the link through which the message came in. If this fails, LinkProof will still respond to the request with NA, but will not cache the response in the neighbor cache. This prevents attacks where the source IP is spoofed and intended to make LinkProof send traffic to the attacker using the source MAC.

If the target address is a native IP address, check that the it is assigned to the Layer 2 link through which the message arrived. If the address is a VIPI associated with a VR, the link has to be the link of the VR. For other cases, no check is required.

New Header FormatThe IPv6 header has a new format that is designed to minimize header overhead. This is achieved by moving both nonessential fields and option fields to extension headers that are placed after the IPv6 header. The streamlined IPv6 header provides more efficient processing at intermediate

Address Resolution Process by which a node resolves a neighboring node’s IPv6 address to its link-layer address (equivalent to ARP in IPv4). The resolved link-layer address becomes an entry in a node's neighbor cache (equivalent to the ARP cache in IPv4). You can use the netsh interface ipv6 show neighbors command to view the contents of the neighbor cache on a computer running the Windows Server 2003 family and Windows XP.

Next-hop Determination The process by which a node determines the IPv6 address of the neighbor to which a packet is being forwarded based on the destination address. The forwarding or next-hop address is either the destination address of the packet being sent or the address of a neighboring router. The resolved next hop address for a destination becomes an entry in a node's destination cache (also known as a route cache).

Neighbor Unreachability Detection

The process by which a node determines that IPv6 packets cannot be sent to and received from a neighboring node. After the link-layer address for a neighbor has been determined, the state of the entry in the neighbor cache is tracked. If the neighbor is no longer receiving and sending back packets, the neighbor cache entry is eventually removed. Neighbor unreachability detection provides a mechanism for IPv6 to determine that neighboring hosts or routers are no longer available on the local network segment.

Duplicate Address Detection The process by which a node determines that an address considered for use is not already in use by a neighboring node (equivalent to the use of gratuitous ARP frames in IPv4).

Redirect Function The process by which a router informs a host of a better first-hop IPv6 address to reach a destination (equivalent to the function of the IPv4 ICMP Redirect message).

Table 15: NDisc Processes




routers. IPv4 headers and IPv6 headers are not interoperable and the IPv6 protocol is not backward compatible with the IPv4 protocol. A host or router must use an implementation of both IPv4 and IPv6 in order to recognize and process both header formats. The new IPv6 header is only twice as large as the IPv4 header, even though IPv6 addresses are four times as large as IPv4 addresses.

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

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

Stateless and Stateful Address ConfigurationTo simplify host configuration, IPv6 supports both stateful address configuration, such as address configuration in the presence of a DHCP server, and stateless address configuration (address configuration in the absence of a DHCP server). With stateless address configuration, hosts on a link automatically configure themselves with IPv6 addresses for the link (link-local addresses) and with addresses that are derived from prefixes advertised by local routers. Even in the absence of a router, hosts on the same link can automatically configure themselves with link-local addresses and communicate without manual configuration.

Built-in SecuritySupport for IPSec is an IPv6 protocol suite requirement. This requirement provides a standards-based solution for network security needs and promotes interoperability between different IPv6 implementations.

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

New Protocol for Neighboring Node InteractionThe Neighbor Discovery protocol for IPv6 is a series of Internet Control Message Protocol for IPv6 (ICMPv6) messages that manage the interaction of neighboring nodes (that is, nodes on the same link). Neighbor Discovery replaces Address Resolution Protocol (ARP), ICMPv4 Router Discovery, and ICMPv4 Redirect messages with efficient multicast and unicast messages and provides additional functionality. For more information, see Neighbor Discovery (ND).



ExtensibilityIPv6 can be extended for new features by adding extension headers after the IPv6 header. Unlike the IPv4 header, which can only support 40 bytes of options, the size of IPv6 extension headers is only constrained by the size of the IPv6 packet.


Appendix D – 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

LP_6.20_UG

Documents

Transcript of LP_6.20_UG