Alteon Application Switch Operating System Application Guide
Alteon Application Switch Operating System Application Guide
Application Guide
Software Version 29.0.0.0
Document ID: RDWR-ALOS-V2900_AG1302
February, 2013
Alteon Application Switch Operating System Application Guide
Important Notices
The following important notices are presented in English, French, and German.
Important Notices
This guide is delivered subject to the following conditions and restrictions:
The AppShape++ Script Files provided by Radware Ltd. are subject to the Special License Terms
included in each of the electronic AppShape++ Script Files and are also subject to Radware's End
User License Agreement, a copy of which (as may be amended from time to time) can be found at
the end of this document or at http://www.radware.com/Resources/eula.html.
Please note that if you create your own scripts using any AppShape++ Scripts provided by Radware,
such self-created scripts are not controlled by Radware and therefore Radware will not be liable for
any malfunctions resulting from such self-created scripts.
Copyright Radware Ltd. 2013. All rights reserved.
The copyright and all other intellectual property rights and trade secrets included in this guide are
owned by Radware Ltd.
The guide is provided to Radware customers for the sole purpose of obtaining information with
respect to the installation and use of the Radware products described in this document, and may not
be used for any other purpose.
The information contained in this guide is proprietary to Radware and must be kept in strict
confidence.
It is strictly forbidden to copy, duplicate, reproduce or disclose this guide or any part thereof without
the prior written consent of Radware.
Notice importante
Ce guide est sujet aux conditions et restrictions suivantes:
Les applications AppShape++ Script Files fournies par Radware Ltd. sont soumises aux termes de la
Licence Spéciale (“Special License Terms”) incluse dans chaque fichier électronique “AppShape++
Script Files” mais aussi au Contrat de Licence d'Utilisateur Final de Radware qui peut être modifié de
temps en temps et dont une copie est disponible à la fin du présent document ou à l'adresse
suivante: http://www.radware.com/Resources/eula.html.
Nous attirons votre attention sur le fait que si vous créez vos propres fichiers de commande (fichiers
“script”) en utilisant l'application “AppShape++ Script Files” fournie par Radware, ces fichiers
“script” ne sont pas contrôlés par Radware et Radware ne pourra en aucun cas être tenue
responsable des dysfonctionnements résultant des fichiers “script” ainsi créés.
Copyright Radware Ltd. 2013. Tous droits réservés.
Le copyright ainsi que tout autre droit lié à la propriété intellectuelle et aux secrets industriels
contenus dans ce guide sont la propriété de Radware Ltd.
Ce guide d’informations est fourni à nos clients dans le cadre de l’installation et de l’usage des
produits de Radware décrits dans ce document et ne pourra être utilisé dans un but autre que celui
pour lequel il a été conçu.
Les informations répertoriées dans ce document restent la propriété de Radware et doivent être
conservées de manière confidentielle.
Il est strictement interdit de copier, reproduire ou divulguer des informations contenues dans ce
manuel sans avoir obtenu le consentement préalable écrit de Radware.
Wichtige Anmerkung
Dieses Handbuch wird vorbehaltlich folgender Bedingungen und Einschränkungen ausgeliefert:
Die von Radware Ltd bereitgestellten AppShape++ Scriptdateien unterliegen den in jeder
elektronischen AppShape++ Scriptdatei enthalten besonderen Lizenzbedingungen sowie Radware's
Endbenutzer-Lizenzvertrag (von welchem eine Kopie in der jeweils geltenden Fassung am Ende
dieses Dokuments oder unter http://www.radware.com/Resources/eula.html erhältlich ist). Bitte
beachten Sie, dass wenn Sie Ihre eigenen Skripte mit Hilfe eines von Radware bereitgestellten
AppShape++ Skripts erstellen, diese selbsterstellten Skripte nicht von Radware kontrolliert werden
und Radware daher keine Haftung für Funktionsfehler übernimmt, welche von diesen selbsterstellten
Skripten verursacht werden.
Copyright Radware Ltd. 2013. 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 Notices
The programs included in this product are subject to a restricted use license and can only be used in
conjunction with this application.
This product contains code developed by the OpenSSL Project.
This product includes software developed by the OpenSSL Project. For use in the OpenSSL Toolkit.
(http://www.openssl.org/).
Copyright (c) 1998-2005 The OpenSSL Project. All rights reserved.
This product contains the Rijndael cipher
The Rijndael implementation by Vincent Rijmen, Antoon Bosselaers and Paulo Barreto is in the public
domain and distributed with the following license:
@version 3.0 (December 2000)
Optimized ANSI C code for the Rijndael cipher (now AES)
@author Vincent Rijmen <[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
Ce produit inclut un logiciel développé dans le cadre du projet OpenSSL. Pour un usage dans la boîte
à outils OpenSSL (http://www.openssl.org/).
Copyright (c) 1998-2005 Le projet OpenSSL. Tous droits réservés. Ce produit inclut la catégorie de
chiffre Rijndael.
L’implémentation de Rijindael par Vincent Rijmen, Antoon Bosselaers et Paulo Barreto est du
domaine public et distribuée sous les termes de la licence suivante:
@version 3.0 (Décembre 2000)
Code ANSI C code pour Rijndael (actuellement AES)
@author Vincent Rijmen <[email protected]>
@author Antoon Bosselaers <[email protected]>
@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:
http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
Ce code est également placé dans le domaine public.
Ce produit renferme des codes développés dans le cadre du projet OpenSSL.
Copyright (c) 1983, 1990, 1992, 1993, 1995
Les membres du conseil de l’Université de Californie. Tous droits réservés.
La distribution et l’usage sous une forme source et binaire, avec ou sans modifications, est autorisée
pour autant que les conditions suivantes soient remplies:
1. La distribution d’un code source doit inclure la notice de copyright mentionnée ci-dessus, cette
liste de conditions et l’avis de non-responsabilité suivant.
2. La distribution, sous une forme binaire, doit reproduire dans la documentation et/ou dans tout
autre matériel fourni la notice de copyright mentionnée ci-dessus, cette liste de conditions et
l’avis de non-responsabilité suivant.
3. Le nom de l’université, ainsi que le nom des contributeurs ne seront en aucun cas utilisés pour
approuver ou promouvoir un produit dérivé de ce programme sans l’obtention préalable d’une
autorisation écrite.
Ce produit inclut un logiciel développé par Markus Friedl
Ce produit inclut un logiciel développé par Theo de Raadt Ce produit inclut un logiciel développé par
Niels Provos
Ce produit inclut un logiciel développé par Dug Song
Ce produit inclut un logiciel développé par Aaron Campbell Ce produit inclut un logiciel développé
par Damien Miller
Ce produit inclut un logiciel développé par Kevin Steves
Ce produit inclut un logiciel développé par Daniel Kouril
Ce produit inclut un logiciel développé par Wesley Griffin
Ce produit inclut un logiciel développé par Per Allansson
Ce produit inclut un logiciel développé par Nils Nordman
Ce produit inclut un logiciel développé par Simon Wilkinson.
La distribution et l’usage sous une forme source et binaire, avec ou sans modifications, est autorisée
pour autant que les conditions suivantes soient remplies:
1. La distribution d’un code source doit inclure la notice de copyright mentionnée ci-dessus, cette
liste de conditions et l’avis de non-responsabilité suivant.
2. La distribution, sous une forme binaire, doit reproduire dans la documentation et/ou dans tout
autre matériel fourni la notice de copyright mentionnée ci-dessus, cette liste de conditions et
l’avis de non-responsabilité suivant.
LE LOGICIEL MENTIONNÉ CI-DESSUS EST FOURNI TEL QUEL PAR LE DÉVELOPPEUR ET TOUTE
GARANTIE, EXPLICITE OU IMPLICITE, Y COMPRIS, MAIS SANS S’Y LIMITER, TOUTE GARANTIE
IMPLICITE DE QUALITÉ MARCHANDE ET D’ADÉQUATION À UN USAGE PARTICULIER EST EXCLUE.
EN AUCUN CAS L’AUTEUR NE POURRA ÊTRE TENU RESPONSABLE DES DOMMAGES DIRECTS,
INDIRECTS, ACCESSOIRES, SPÉCIAUX, EXEMPLAIRES OU CONSÉCUTIFS (Y COMPRIS, MAIS SANS
S’Y LIMITER, L’ACQUISITION DE BIENS OU DE SERVICES DE REMPLACEMENT, LA PERTE D’USAGE,
DE DONNÉES OU DE PROFITS OU L’INTERRUPTION DES AFFAIRES), QUELLE QU’EN SOIT LA CAUSE
ET LA THÉORIE DE RESPONSABILITÉ, QU’IL S’AGISSE D’UN CONTRAT, DE RESPONSABILITÉ
STRICTE OU D’UN ACTE DOMMAGEABLE (Y COMPRIS LA NÉGLIGENCE OU AUTRE), DÉCOULANT DE
QUELLE QUE FAÇON QUE CE SOIT DE L’USAGE DE CE LOGICIEL, MÊME S’IL A ÉTÉ AVERTI DE LA
POSSIBILITÉ D’UN TEL DOMMAGE.
Copyrightvermerke
Die in diesem Produkt enthalten Programme unterliegen einer eingeschränkten Nutzungslizenz und
können nur in Verbindung mit dieser Anwendung benutzt werden.
Dieses Produkt enthält einen vom OpenSSL-Projekt entwickelten Code.
Dieses Produkt enthält vom OpenSSL-Projekt entwickelte Software. Zur Verwendung im OpenSSL
Toolkit. (http://www.openssl.org/).
Copyright (c) 1998-2005 The OpenSSL Project. Alle Rechte vorbehalten. Dieses Produkt enthält die
Rijndael cipher
Die Rijndael-Implementierung von Vincent Rijndael, Anton Bosselaers und Paulo Barreto ist
öffentlich zugänglich und wird unter folgender Lizenz vertrieben:
@version 3.0 (December 2000)
Optimierter ANSI C Code für den Rijndael cipher (jetzt AES)
@author Vincent Rijmen <[email protected]>
@author Antoon Bosselaers <[email protected]>
@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:
http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
Dieser Code wird hiermit allgemein zugänglich gemacht.
Dieses Produkt enthält einen vom OpenBSD-Projekt entwickelten Code
Copyright (c) 1983, 1990, 1992, 1993, 1995
The Regents of the University of California. Alle Rechte vorbehalten.
Die Verbreitung und Verwendung in Quell- und binärem Format, mit oder ohne Veränderungen, sind
unter folgenden Bedingungen erlaubt:
1. Die Verbreitung von Quellcodes muss den voranstehenden Copyrightvermerk, diese Liste von
Bedingungen und den folgenden Haftungsausschluss beibehalten.
2. Die Verbreitung in binärem Format muss den voranstehenden Copyrightvermerk, diese Liste von
Bedingungen und den folgenden Haftungsausschluss in der Dokumentation und/oder andere
Materialien, die mit verteilt werden, reproduzieren.
3. Weder der Name der Universität noch die Namen der Beitragenden dürfen ohne ausdrückliche
vorherige schriftliche Genehmigung verwendet werden, um von dieser Software abgeleitete
Produkte zu empfehlen oder zu bewerben.
Dieses Produkt enthält von Markus Friedl entwickelte Software Dieses Produkt enthält von Theo de
Raadt entwickelte Software Dieses Produkt enthält von Niels Provos entwickelte Software Dieses
Produkt enthält von Dug Song entwickelte Software
Dieses Produkt enthält von Aaron Campbell entwickelte Software Dieses Produkt enthält von Damien
Miller entwickelte Software Dieses Produkt enthält von Kevin Steves entwickelte Software Dieses
Produkt enthält von Daniel Kouril entwickelte Software Dieses Produkt enthält von Wesley Griffin
entwickelte Software Dieses Produkt enthält von Per Allansson entwickelte Software Dieses Produkt
enthält von Nils Nordman entwickelte Software
Dieses Produkt enthält von Simon Wilkinson entwickelte Software
Die Verbreitung und Verwendung in Quell- und binärem Format, mit oder ohne Veränderungen, sind
unter folgenden Bedingungen erlaubt:
1. Die Verbreitung von Quellcodes muss den voranstehenden Copyrightvermerk, diese Liste von
Bedingungen und den folgenden Haftungsausschluss beibehalten.
2. Die Verbreitung in binärem Format muss den voranstehenden Copyrightvermerk, diese Liste von
Bedingungen und den folgenden Haftungsausschluss in der Dokumentation und/oder andere
Materialien, die mit verteilt werden, reproduzieren.
SÄMTLICHE VORGENANNTE SOFTWARE WIRD VOM AUTOR IM IST-ZUSTAND (“AS IS”)
BEREITGESTELLT. JEGLICHE AUSDRÜCKLICHEN ODER IMPLIZITEN GARANTIEN, EINSCHLIESSLICH,
DOCH NICHT BESCHRÄNKT AUF DIE IMPLIZIERTEN GARANTIEN DER MARKTGÄNGIGKEIT UND DER
ANWENDBARKEIT FÜR EINEN BESTIMMTEN ZWECK, SIND AUSGESCHLOSSEN.
UNTER KEINEN UMSTÄNDEN HAFTET DER AUTOR FÜR DIREKTE ODER INDIREKTE SCHÄDEN, FÜR
BEI VERTRAGSERFÜLLUNG ENTSTANDENE SCHÄDEN, FÜR BESONDERE SCHÄDEN, FÜR
SCHADENSERSATZ MIT STRAFCHARAKTER, ODER FÜR FOLGESCHÄDEN EINSCHLIESSLICH, DOCH
NICHT BESCHRÄNKT AUF, ERWERB VON ERSATZGÜTERN ODER ERSATZLEISTUNGEN; VERLUST AN
NUTZUNG, DATEN ODER GEWINN; ODER GESCHÄFTSUNTERBRECHUNGEN) GLEICH, WIE SIE
ENTSTANDEN SIND, UND FÜR JEGLICHE ART VON HAFTUNG, SEI ES VERTRÄGE,
GEFÄHRDUNGSHAFTUNG, ODER DELIKTISCHE HAFTUNG (EINSCHLIESSLICH FAHRLÄSSIGKEIT
ODER ANDERE), DIE IN JEGLICHER FORM FOLGE DER BENUTZUNG DIESER SOFTWARE IST, SELBST
WENN AUF DIE MÖGLICHKEIT EINES SOLCHEN SCHADENS HINGEWIESEN WURDE.
Safety Instructions
The following safety instructions are presented in English, French, and German.
Safety Instructions
CAUTION
A readily accessible disconnect device shall be incorporated in the building installation wiring.
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.
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.
KCC KOREA
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 8: Avertissement de sécurité pour les systèmes dotes de deux sources d’alimentation
électrique (en chinois)
Traduction de la Avertissement de sécurité pour les systèmes dotes de deux sources d’alimentation
électrique (en chinois):
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, et 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
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
4. Remplacez un fusible qui a sauté SEULEMENT par un fusible du même type et de même
capacité, comme indiqué sur l’étiquette de sécurité proche de l’entrée de l’alimentation qui
contient le fusible.
5. NE PAS UTILISER l’équipement dans des locaux dont la température maximale dépasse 40
degrés Centigrades.
6. Assurez vous que le cordon d’alimentation a été déconnecté AVANT d’essayer de l’enlever et/ou
vérifier le fusible de l’alimentation générale.
Sicherheitsanweisungen
VORSICHT
Die Elektroinstallation des Gebäudes muss ein unverzüglich zugängliches Stromunterbrechungsgerät
integrieren.
Aufgrund des Stromschlagrisikos und der Energie-, mechanische und Feuergefahr dürfen Vorgänge,
in deren Verlauf Abdeckungen entfernt oder Elemente ausgetauscht werden, ausschließlich von
qualifiziertem Servicepersonal durchgeführt werden.
Zur Reduzierung der Feuer- und Stromschlaggefahr muss das Gerät vor der Entfernung der
Abdeckung oder der Paneele von der Stromversorgung getrennt werden.
Folgende Abbildung zeigt das VORSICHT-Etikett, das auf die Radware-Plattformen mit
Doppelspeisung angebracht ist.
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
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.
关于在非热带气候地区使用的设备,必须在随时可见的位置处粘贴包含如下内容的警告标记:
“ 只可在非热带气候地区使用。”
附件 DD:有关新安全警告标记的说明。
DD.1 海拔警告标记
标记含义:设备的评估仅基于温带气候条件,因此设备只适用于该运行条件。如果在热带气候地区使用设备,可能
会存在某些安全隐患。
Document Conventions
The following describes the conventions and symbols that this guide uses:
Example
Possible damage to Endommagement Mögliche Schäden an
equipment, software, or possible de l’équipement, Gerät, Software oder
data des données ou du Daten
Caution: logiciel
Additional information Informations Zusätzliche
complémentaires Informationen
Note:
A statement and Références et Eine Erklärung und
instructions instructions Anweisungen
To
A suggestion or Une suggestion ou Ein Vorschlag oder eine
workaround solution Umgehung
Tip:
Possible physical harm to Blessure possible de Verletzungsgefahr des
the operator l’opérateur Bedieners
Warning:
Chapter 1 – Preface................................................................................................. 39
Who Should Use This Guide ....................................................................................... 39
What You Will Find in This Guide ................................................................................ 39
Part 1—Basic Features ....................................................................................................... 39
Part 2—IP Routing .............................................................................................................. 39
Part 3—Application Load Balancing Fundamentals ............................................................ 39
Part 4—Advanced Load Balancing ..................................................................................... 40
Appendices .......................................................................................................................... 40
Related Documentation ............................................................................................... 41
Chapter 4 – VLANs.................................................................................................. 81
VLAN ID Numbers ...................................................................................................... 81
VLAN Tagging ............................................................................................................ 81
VLANs and the IP Interfaces ...................................................................................... 82
VLAN Topologies and Design Issues ......................................................................... 82
VLANs and Default Gateways .................................................................................... 85
Defining IP Address Ranges for the Local Route Cache .......................................... 117
Dynamic Host Configuration Protocol ....................................................................... 117
DHCP Relay Agent ........................................................................................................... 117
DHCP Relay Agent Configuration ..................................................................................... 118
Gratuitous ARP (GARP) Command ......................................................................... 119
Static Routes ............................................................................................................ 119
IPv4 Static Routes ............................................................................................................. 119
IPv6 Static Routes ............................................................................................................. 120
• Load Balancing Special Services describes how to extend Server Load Balancing (SLB)
configurations to load balance services including source IP addresses, FTP, RTSP, DNS, WAP,
IDS, and Session Initiation Protocol (SIP).
• WAN Link Load Balancing describes how to balance user session traffic among a pool of available
WAN Links.
• Offloading SSL Encryption and Authentication describes SSL offloading capabilities, which
perform encryption, decryption, and verification of Secure Sockets Layer (SSL) transmissions
between clients and servers, relieving the back-end servers of these tasks.
• Filtering and Traffic Manipulation describes how to configure and optimize network traffic filters
for security and Network Address Translation (NAT).
• ADC-VX Management describes how to use ADC-VX in an Alteon environment. A vADC is a
virtualized instance of the AlteonOS that behaves in the same manner as a traditional
standalone Alteon ADC, with the exception that while it is bound to a specific hardware resource,
the amount of resources allocated to the vADC may vary based on the user’s or application's
resource needs.
• Application Redirection describes how to use filters for redirecting traffic to such network
streamlining devices as caches.
• Health Checking describes how to recognize the availability of the various network resources
used with the various load balancing and application redirection features.
• High Availability describes how to use the Virtual Router Redundancy Protocol (VRRP) to ensure
that network resources remain available if one Alteon is removed for service.
Appendices
• Layer 7 String Handling describes how to perform load balancing and application redirection
based on Layer 7 packet content information (such as URL, HTTP Header, browser type, and
cookies).
• Content-Intelligent Server Load Balancing Not Using Layer 7 Content Switching Rules describes
the sole content-intelligent server load balancing methodology prior to version 28.1.
• IPv6 describes how to configure the IP version 6 features.
Related Documentation
• Alteon Application Switch Operating System Release Notes
• Radware Alteon Maintenance and Installation Guide
• Alteon Application Switch Operating System Command Reference
• Alteon Application Switch Operating System Browser-Based Interface (BBI) Quick Guide
• Alteon Application Switch Operating System Troubleshooting Guide
[Main Menu]
info - Information Menu
stats - Statistics Menu
cfg - Configuration Menu
oper - Operations Command Menu
boot - Boot Options Menu
maint - Maintenance Menu
diff - Show pending config changes [global command]
apply - Apply pending config changes [global command]
save - Save updated config to FLASH [global command]
revert - Revert pending or applied changes [global command]
exit - Exit [global command, always available]
telnet <Alteon_IP_address>
• Using an SSH connection to securely log into another computer over a network—The
SSH (Secure Shell) protocol enables you to securely log into another computer over a network
to execute commands remotely. As a secure alternative to using Telnet to manage the Alteon
configuration, SSH ensures that all data sent over the network is encrypted and secure. For
more information, see Secure Shell and Secure Copy, page 70.
For more information on CLI menus and commands, see the Alteon Application Switch Operating
System Command Reference.
Using SNMP
Alteon provides Simple Network Management Protocol (SNMP) v1.0 and SNMP v3.0 support for
access through any network management software, such as APSolute Vision or HP-OpenView.
SNMP v1.0
To access the SNMP agent, the read and write community strings on the SNMP manager should be
configured to match those on Alteon. The default read community string on Alteon is set to public,
and the default write community string is set to private.
Caution: Leaving the default community strings enabled on Alteon presents a security risk. You can
change the community strings as follows:
SNMP v3.0
SNMPv3 is an enhanced version of SNMP, approved by the Internet Engineering Steering Group in
March, 2002. SNMP v3.0 contains additional security and authentication features that provide data
origin authentication, data integrity checks, timeliness indicators, and encryption to protect against
threats such as masquerade, modification of information, message stream modification, and
disclosure.
SNMPv3 ensures that the client can use SNMP v3 to query the MIBs, mainly for security purposes.
To access the SNMP v3.0 menu, enter the following command in the CLI:
>> # /cfg/sys/ssnmp/snmpv3
For more information on SNMP MIBs and the commands used to configure SNMP on Alteon, see the
Alteon Application Switch Operating System Command Reference.
Default Configuration
Alteon has two default users: adminmd5, which uses MD5 authentication, and adminsha, which
uses SHA authentication.
Both these users have access to all the MIBs supported by Alteon. By default, the passwords for
these users are adminmd5 and adminsha, respectively.
User Configuration
Configure users to use the authentication and privacy options. Alteon supports two authentication
algorithms: MD5 and SHA.
>> # /cfg/sys/ssnmp/snmpv3/usm 5
>> SNMPv3 usmUser 5 # name "test"
>> SNMPv3 usmUser 5 # auth md5
>> SNMPv3 usmUser 5 # authpw test
>> SNMPv3 usmUser 5 # priv des
>> SNMPv3 usmUser 5 # privpw test
2. After configuring a user, specify the access level for this user along with the views to which the
user is allowed access. This is specified in the access table.
>> # /cfg/sys/ssnmp/snmpv3/access 5
>> SNMPv3 vacmAccess 5 # name "testgrp"
>> SNMPv3 vacmAccess 5 # level authPriv
>> SNMPv3 vacmAccess 5 # rview "iso"
>> SNMPv3 vacmAccess 5 # wview "iso"
>> SNMPv3 vacmAccess 5 # nview "iso"
>> # /cfg/sys/ssnmp/snmpv3/group 5
>> SNMPv3 vacmSecurityToGroup 5 # uname test
>> SNMPv3 vacmSecurityToGroup 5 # gname testgrp
If you want to allow the user to access only certain MIBs, see View-Based Configurations,
page 46.
View-Based Configurations
/cfg/sys/ssnmp/snmpv3/usm 4
name "usr"
/cfg/sys/ssnmp/snmpv3/access 3
name "usrgrp"
rview "usr"
wview "usr"
nview "usr"
/cfg/sys/ssnmp/snmpv3/group 4
uname usr
gname usrgrp
/cfg/sys/ssnmp/snmpv3/view 6
name "usr"
tree "1.3.6.1.4.1.1872.2.5.1.2"
/cfg/sys/ssnmp/snmpv3/view 7
name "usr"
tree "1.3.6.1.4.1.1872.2.5.1.3"
/cfg/sys/ssnmp/snmpv3/view 8
name "usr"
tree "1.3.6.1.4.1.1872.2.5.2.2"
/cfg/sys/ssnmp/snmpv3/view 9
name "usr"
tree "1.3.6.1.4.1.1872.2.5.2.3"
/cfg/sys/ssnmp/snmpv3/view 10
name "usr"
tree "1.3.6.1.4.1.1872.2.5.3.2"
/cfg/sys/ssnmp/snmpv3/view 11
name "usr"
tree "1.3.6.1.4.1.1872.2.5.3.3"
/cfg/sys/ssnmp/snmpv3/view 12
name "usr"
tree "1.3.6.1.4.1.1872.2.5.4.2"
/cfg/sys/ssnmp/snmpv3/view 13
name "usr"
tree "1.3.6.1.4.1.1872.2.5.4.3"
/cfg/sys/ssnmp/snmpv3/view 14
name "usr"
tree "1.3.6.1.4.1.1872.2.5.5.2"
/cfg/sys/ssnmp/snmpv3/view 15
name "usr"
tree "1.3.6.1.4.1.1872.2.5.5.3"
/cfg/sys/ssnmp/snmpv3/view 16
name "usr"
tree "1.3.6.1.4.1.1872.2.5.6.2"
/cfg/sys/ssnmp/snmpv3/usm 5
name "slboper"
/cfg/sys/ssnmp/snmpv3/access 4
name "slbopergrp"
rview "slboper"
wview "slboper"
nview "slboper"
/cfg/sys/ssnmp/snmpv3/group 4
uname slboper
gname slbopergrp
/cfg/sys/ssnmp/snmpv3/view 20
name "slboper"
tree "1.3.6.1.4.1.1872.2.5.1.2" /cfg/sys/ssnmp/snmpv3/view 21
name "slboper"
tree "1.3.6.1.4.1.1872.2.5.1.3"
/cfg/sys/ssnmp/snmpv3/view 22
name "slboper"
tree "1.3.6.1.4.1.1872.2.5.2.2"
/cfg/sys/ssnmp/snmpv3/view 23
name "slboper"
tree "1.3.6.1.4.1.1872.2.5.2.3"
/cfg/sys/ssnmp/snmpv3/view 24
name "slboper"
tree "1.3.6.1.4.1.1872.2.5.3.2"
/cfg/sys/ssnmp/snmpv3/view 25
name "slboper"
tree "1.3.6.1.4.1.1872.2.5.3.3"
/cfg/sys/ssnmp/snmpv3/view 26
name "slboper"
tree "1.3.6.1.4.1.1872.2.5.4"
/cfg/sys/ssnmp/snmpv3/view 27
name "slboper"
tree "1.3.6.1.4.1.1872.2.5.4.1"
type excluded
/cfg/sys/ssnmp/snmpv3/view 28
name "slboper"
tree "1.3.6.1.4
.1.1872.2.5.5.2"
/cfg/sys/ssnmp/snmpv3/view 29
name "slboper"
tree "1.3.6.1.4.1.1872.2.5.5.3"
/cfg/sys/ssnmp/snmpv3/view 30
name "slboper"
tree "1.3.6.1.4.1.1872.2.5.6.2"
2. Configure an access group and group table entries for the user. Use the nview command to
specify which traps can be received by the user. In the following example, the user receives the
traps sent by Alteon:
>> # /cfg/sys/ssnmp/snmpv3/access 10
>> SNMPv3 vacmAccess 10 # name "v1trap"
>> SNMPv3 vacmAccess 10 # model snmpv1
>> SNMPv3 vacmAccess 10 # nview "iso"
>> # /cfg/sys/ssnmp/snmpv3/group 10
>> SNMPv3 vacmSecurityToGroup 10 # model snmpv1
>> SNMPv3 vacmSecurityToGroup 10 # uname v1trap
>> SNMPv3 vacmSecurityToGroup 10 # gname v1trap
>> # /cfg/sys/ssnmp/snmpv3/notify 10
>> SNMPv3 vacmSecurityToGroup 10 # name v1trap
>> SNMPv3 vacmSecurityToGroup 10 # tag v1trap
4. Specify the IP address and other trap parameters in the targetAddr and targetParam tables.
Use the uname command to specify the user name used with this targetParam table.
5. Specify the community string used in the traps using the community table.
/cfg/sys/ssnmp/snmpv3/usm 10
name "v2trap"
/cfg/sys/ssnmp/snmpv3/access 10
name "v2trap"
model snmpv2
nview "iso"
/cfg/sys/ssnmp/snmpv3/group 10
model snmpv2
uname v2trap
gname v2trap
/cfg/sys/ssnmp/snmpv3/taddr 10
name v2trap
addr 50.81.25.66
taglist v2trap
pname v2param
/cfg/sys/ssnmp/snmpv3/tparam 10
name v2param
mpmodel snmpv2c
uname v2trap
model snmpv2
/cfg/sys/ssnmp/snmpv3/notify 10
name v2trap
tag v2trap/cfg/sys/ssnmp/snmpv3/comm 10
index v2trap
name public
uname v2trap
2. Configure the user in the user table from the SNMPv3 usmUser 1 menu:
Note: It is not necessary to configure the community table for SNMPv3 traps because the
community string is not used by SNMPv3.
Example
The following example illustrates how to configure an SNMPv3 user v3trap with authentication only:
/cfg/sys/ssnmp/snmpv3/usm 11
name "v3trap"
auth md5
authpw v3trap
/cfg/sys/ssnmp/snmpv3/access 11
name "v3trap"
level authNoPriv
nview "iso"
/cfg/sys/ssnmp/snmpv3/group 11
uname v3trap
gname v3trap
/cfg/sys/ssnmp/snmpv3/taddr 11
name v3trap
addr 50.81.25.66
taglist v3trap
pname v3param
/cfg/sys/ssnmp/snmpv3/tparam 11
name v3param
uname v3trap
level authNoPriv
/cfg/sys/ssnmp/snmpv3/notify 11
name v3trap
tag v3trap
/cfg/sys/access/http ena
To change the HTTP web server port from the default port 80
/cfg/sys/access/wport <x>
/cfg/sys/access/https/https ena
To change the HTTPS Web server port number from the default port 443
/cfg/sys/access/https/port <x>
>>/cfg/sys/access/https/generate
This operation will generate a self-signed server certificate.
Enter key size [512|1024|2048|4096] [1024]:
Enter server certificate hash algorithm [md5|sha1|sha256|sha384|sha512]
[sha1]:
Enter certificate Common Name (e.g. your site's name):
Use certificate default values? [y/n]:
Enter certificate Country Name (2-letter code) []: us
Enter certificate State or Province Name (full name) []: newyork
Enter certificate locality name (e.g. city) []: newyork
Enter certificate Organization Name (e.g. company) []: example
Enter certificate Organizational Unit Name (e.g. accounting) []: exam
Enter certificate Email (e.g. [email protected]) []: [email protected]
Enter certificate validation period in days (1-3650) [365]:
........
Self signed server certificate, certificate signing request and key added.
You can save the certificate to flash for use if you reboot Alteon by using the apply and save
commands.
When a client (for example, a Web browser) connects to Alteon, the client is asked to accept the
certificate and verify that the fields are what are expected. Once you grant BBI access to the client,
the BBI can be used as described in the Alteon Application Switch Browser-Based Interface Quick
Guide.
For more information on using the commands to perform these functions, see the Alteon Application
Switch Operating System Command Reference.
Notes
• To configure MNG 1 as a management port for dedicated out-of-band management on devices
other than the Alteon Application Switch 4408 platform, use the command
/cfg/sys/mmgmt ena to enable the management port. For more information, see the section
on configuring management ports in the Radware Alteon Installation and Maintenance Guide.
• To configure port 6 / MNG 1 as a management port for dedicated out-of-band management on
the Alteon Application Switch 4408 platform, first enable the physical port with the command /
boot/mgmt ena, then use the command /cfg/sys/mmgmt ena to enable the management
port. For more information, see the section on configuring management ports in the Radware
Alteon Installation and Maintenance Guide.
2. Configure a static IP address. Both IPv4 and IPv6 addresses can be configured on the
management port.
3. Enable the management port. When you enable the management port, you can use it to access
Alteon via Telnet, SSH, or BBI, provided you enabled the commands on Alteon. These
commands can occur simultaneously on both the management port and the data ports.
Note: There are a maximum of four concurrent Telnet sessions over the management and data
ports combined.
>> Management Port# ntp mgmt (Select the management port for NTP)
>> Management Port# radius mgmt (Select the management port for
RADIUS)
>> Management Port# syslog mgmt (Select the management port for syslog)
Note: The default for TFTP can be overridden by using the –data or –mgmt option after a
gtimg, ptimg, gtcfg, ptcfg, or ptdmp command.
Command Description
/cfg/sys/access/port/add <port number> Enable port for management access.
/cfg/sys/access/port/rem <port number> Disable port from management
access.
/cfg/sys/access/port/arem Disable all ports from management
access.
/cfg/sys/access/port/cur Current listing of data ports with
management access.
ADC-VX supports virtual ADC (vADC) management access through VLANs. Unlike standalone
appliances, a vADC does not necessarily own the entire physical port and can share it with other
applications or services. To accommodate such a design, the data port management access for
vADCs is supported by VLAN IDs and not by physical ports.
Table 2 lists the commands that can be used to limit management services from VLANs:
Command Description
/cfg/sys/access/vlan/add <vlan number> Enable VLAN for management access.
/cfg/sys/access/vlan/aadd <vlan number> Enable all VLANs for management
access.
/cfg/sys/access/vlan/rem <vlan number> Disable VLAN from management
access.
/cfg/sys/access/vlan/arem Disable all VLANs from management
access.
/cfg/sys/access/vlan/cur Current listing of VLANs with
management access.
File Transfers
Alteon supports the File Transfer Protocol (FTP) as an alternative to the Trivial File Transfer Protocol
(TFTP). FTP is supported over data and management ports for the upload and download of the
following file types:
• Configuration files
• Technical Support (TS) dumps
• Panic dumps
An FTP hostname, filename, username, and password are requested when using FTP.
Time Configuration
This section describes the Alteon time configuration options.
Note: The time zone setting can be disabled in this menu by selecting 11.
4. Select the time zone appropriate to the specific geographic location of Alteon.
2. Set the IP address of the primary NTP server. This is the NTP server that Alteon would regularly
synchronize with to adjust its time.
3. Set the IP address of the secondary NTP server. This is the NTP server that Alteon would
synchronize with in instances where the primary server is not available. You can configure an
IPv4 or IPv6 address for the NTP server.
4. Set the re-synchronization interval. The re-synchronization interval is the amount of time Alteon
waits between queries to the NTP server.
5. Optionally, set the NTP time zone offset. The NTP time zone offset from Greenwich Mean Time
defaults to the setting configured when the Alteon time zone was set. If this has not been done,
or you want to override the current value, do the following:
>> /cfg/sys/access/rlimit
Enter protocol [arp|icmp|tcp|udp]: arp
Current max rate: 0
Enter new max rate: 1000 (Set the rate to 1000 packets per
second)
2. Repeat step 1 to configure rate limits on any other of the supported protocols.
3. Apply and save the configuration.
(continued)
Example
Definition of a range of allowed source IP addresses between 192.192.192.1 to 192.192.192.127:
In this example, the following source IP addresses are granted or not granted access to Alteon:
• A host with a source IP address of 192.192.192.21 falls within the defined range and is granted
access to Alteon.
• A host with a source IP address of 192.192.192.192 falls outside the defined range and is not
granted access.
To ensure that the source IP address is valid, you would need to shift the host to an IP address
within the valid range specified by the address and mask, or modify the address to be
192.192.192.128 and the mask to be 255.255.255.128. This would put the 192.192.192.192 host
within the valid range allowed by the address and mask (192.192.192.128-255).
Caution: If you configure the RADIUS secret using any method other than a direct console
connection, the secret may be transmitted over the network as clear text.3.Optionally, you can
change the default TCP port number used to listen to RADIUS.
The well-known port for RADIUS is 1812.
4. Configure the number of retry attempts for contacting the RADIUS server, and the timeout
period.
User Accounts
The user accounts listed in Table 3 describe the user levels
• that can be defined in the RADIUS server dictionary file. For more information, see RADIUS
Attributes for User Privileges, page 65.
• for defining the class of service for the End User Access Control feature. For more information,
see End User Access Control, page 76.
Backdoor Access
When both the primary and secondary authentication servers are not reachable, the administrator
has the option to allow backdoor access on a per user basis. This access is disabled by default and
must be activated for each individual user the administrator wishes to grant it to.
Note: If a user cannot establish a connection to the RADIUS server, failover to the local backdoor
users are not permitted. This is done to avoid a DoS attack on RADIUS or Alteon allowing access.
Examples
A The following command enables backdoor access for user 9:
TACACS+ Authentication
Alteon supports authentication and authorization with networks using the Cisco Systems® TACACS+
protocol. Alteon functions as the Network Access Server by interacting with the remote client and
initiating authentication and authorization sessions with the TACACS+ access server. The remote
user is defined as someone requiring management access to Alteon either through a data or
management port.
TACACS+ offers the following advantages over RADIUS:
• TACACS+ uses TCP-based, connection-oriented transport, while RADIUS is UDP-based. TCP
offers a connection-oriented transport, while UDP offers best-effort delivery. RADIUS requires
additional programmable variables such as re-transmit attempts and timeouts to compensate
for best-effort transport, but it lacks the level of built-in support that a TCP transport offers.
• TACACS+ offers full packet encryption, while RADIUS offers password-only encryption in
authentication requests.
• TACACS+ separates authentication, authorization, and accounting.
• TACACS+ offers privilege level mapping. By enabling cmap, the privilege level can be increased
from default 0-9 to 0-22.
• Alteon sends command log messages to the TACACS+ server when clog is enabled.
Authorization
Authorization is the action of determining a user's privileges on Alteon, and usually takes place after
authentication.
The mapping between TACACS+ authorization levels and Alteon management access levels is
described in Accounting, page 69.
Table 5 displays TACACS+ levels with disabled privilege level mapping
(/cfg/sys/tacacs/cmap/dis):
Accounting
Accounting is the act of recording a user's activities on Alteon for the purposes of billing and/or
security. It follows the authentication and authorization actions. If the authentication and
authorization actions are not performed through TACACS+, no TACACS+ accounting messages are
sent out.
Whenever a command successfully executes, TACACS+ creates an accounting message and sends it
to the TACACS+ server.
The attributes provided for the TACACS+ accounting are:
• protocol (console, Telnet, SSH, HTTP)
• start time (in seconds)
• stop time (in seconds)
• elapsed time (in seconds)
• disc cause (a string)
Note: Other than these attributes, the cmd and cmd-arg accounting attributes are also supported
for command logging.
Caution: If you configure the TACACS+ secret using any method other than a direct console
connection, the secret may be transmitted over the network as clear text.
3. Optionally, you can change the default TCP port number used to listen to TACACS+.
The well-known port for TACACS+ is 49.
4. Configure the number of retry attempts for contacting the TACACS+ server, and the timeout
period.
Note: There can be a maximum number of four simultaneous Telnet, SSH, SCP connections at one
time. The /cfg/sys/radius/telnet command also applies to SSH/SCP connections.
2. To disable SSH:
Note: The factory default setting for the SCP administrator password is admin.
>> /cfg/sys/access/sshd/scpadm
Changing SCP-only Administrator password; validation required...
Enter current administrator password: <password>
Enter new SCP-only administrator password: <new password>
Re-enter new SCP-only administrator password: <new password>
New SCP-only administrator password accepted.
SCP Services
To perform SCP commands, you need the SCP admin password with administrator privileges (this
password must be different from the admin password).
The following SCP commands are supported in this service. These commands are entered using the
CLI on the client that is running the SCP application:
• getcfg—Used to download the configuration to the remote host via SCP.
• putcfg—Used to upload the configuration from a remote host to Alteon. The diff command is
executed at the end of putcfg to notify the remote client of the difference between the new and
the current configurations.
• putcfg_apply—Runs the apply command after the putcfg is done.
• putcfg_apply_save—Saves the new configuration to the flash after putcfg_apply is done.
Note: The putcfg_apply and putcfg_apply_save commands are provided because additional
apply and save commands are usually required after a putcfg, and an SCP session is not run in an
interactive mode.
The apply and save commands are still needed after the last command (scp appldevice.cfg
192.168.249.13:putcfg). Alternately, you can use the following commands:
Notes
• The diff command is executed at the end of putcfg to notify the remote client of the difference
between the new and the current configurations.
• putcfg_apply runs the apply command after the putcfg command.
• putcfg_apply_save saves the new configuration to the flash after the putcfg_apply
command.
Encryption/Authentication Method
Server host authentication The client RSA authenticates Alteon at the beginning of
every connection.
Key exchange RSA
Encryption 3DES-CBC, DES
User authentication Local password authentication, RADIUS, SecurID via
RADIUS, for SSH only. It does not apply to SCP.
These two commands take effect immediately without the need of an apply command.
When Alteon reboots, it retrieves the host and server keys from the flash memory. If these two keys
are not available in the flash memory and if the SSH server feature is enabled, Alteon generates
them during the system reboot. This process may take several minutes to complete.
Note: This command is available when connected through either the console port, Telnet, or SSH.
The number of hours must be between 0 and 24. 0 indicates that RSA server key auto-generation is
disabled. When greater than 0, Alteon auto-generates the RSA server key every specified interval.
However, RSA server key generation is skipped if Alteon is busy with other key or cipher generation
when the timer expires.
Note: Alteon performs only one key/cipher generation session at a time. As a result, an SSH/SCP
client cannot log in if Alteon is performing key generation at the same time, or if another client has
just logged in. Also, key generation fails if an SSH/SCP client is logging in at the same time.
Note: There is no SNMP or BBI support for SecurID because the SecurID server, ACE, is a one-time
password authentication and requires an interactive session.
An SCP-only administrator's password is typically used when SecurID is used. For example, it
can be used in an automation program (in which the tokens of SecurID are not available) to
back up (download) the configurations each day.
Note: The SCP-only administrator password must be different from the regular administrator
password. If the two passwords are the same, the administrator using that password is not
allowed to log in as an SSH user because Alteon recognizes him as the SCP-only administrator,
and only allows the administrator access to SCP commands.
Alternately, you can configure a regular administrator with a fixed password in the RADIUS
server if it can be supported. A regular administrator with a fixed password in the RADIUS server
can perform both SSH and SCP with no additional authentication required.
>> # /cfg/sys/access/user
To set up a user ID
You can configure up to 10 user IDs. For example:
/cfg/sys/access/user/uid 1
Changing Passwords
To change passwords
The following is an example for changing passwords:
User ID 2 # cur
name jane , dis, cos user , password valid, offline
real servers:
23: 0.0.0.0, disabled, name , weight 1,
timeout 20 mins, max-
con 200000
24: 0.0.0.0, disabled, name , weight 1,
timeout 20 mins, max-
con 200000
# /cfg/sys/access/user/cur
Usernames:
user - Enabled
slbview - Disabled
slboper - Disabled
l4oper - Disabled
oper - Disabled
l3admin - Disabled
slbadmin - Disabled
l4admin - Disabled
admin - Always Enabled
>> # /cfg/sys/access/user/usrpw
Changing USER password; validation required:
Enter current admin password:
Enter new user password:
Re-enter new user password:
Deny Routes
A deny route, or black hole route, can be configured to deny Layer 3 routable packets to destinations
covered by a static route. A deny route is created by setting the gateway address in a static route to
0. If the longest prefix match route (which is obtained via route lookup) is a deny route, the packet
is dropped.
A deny route may be configured when an administrator discovers a specific user or network under
attack. This feature is similar to a deny filter, except that it works only on routable Layer 3 traffic. It
does not deny Layer 2 traffic.
Caution: Do not configure a deny route that covers the destination/mask pair of an existing IP
interface's IP address/mask pair. For example, if you have an IP interface of 50.0.0.1/255.0.0.0, and
a deny route of 50.0.0.0/255.0.0, then traffic to the interface as well as the subnet is denied, which
is not the desired result.
Enter the /info/l3/dump command. A deny route appears in the routing table in bold.
Notes
• Basic VLANs can be configured during initial configuration. For more information, see Using the
Setup Utility in the Alteon Application Switch Operating System Command Reference.
• More comprehensive VLAN configuration can be done from the CLI. For more information, see
VLAN Configuration, as well as Port Configuration, in the Alteon Application Switch Operating
System Command Reference.
VLAN ID Numbers
Alteon supports up to 2048 VLANs per Alteon. Even though the maximum number of VLANs
supported at any given time is 2048, each can be identified with any number between 1 and 4090.
VLANs are defined on a per-port basis. Each port on Alteon can belong to one or more VLANs, and
each VLAN can have any number of ports in its membership. Any port that belongs to multiple
VLANs, however, must have VLAN tagging enabled (see VLAN Tagging, page 81).
Each port has a configurable default VLAN number, known as its PVID. The factory default value for
all PVIDs is 1. This places all ports on the same VLAN initially, although each PVID is configurable to
any VLAN number between 1 and 4090.
Any untagged frames (those with no VLAN specified) are classified with the sending port's PVID.
VLAN Tagging
Alteon supports 802.1Q VLAN tagging, providing standards-based VLAN support for Ethernet
systems.
Tagging places the VLAN identifier in the frame header, allowing multiple VLANs per port. When you
configure multiple VLANs on a port, you must also enable tagging on that port.
Because tagging fundamentally changes the format of frames transmitted on a tagged port, you
must carefully plan the design of a network to prevent transmission of tagged frames to devices that
do not support 802.1Q VLAN tags.
Note: Carefully consider how you create VLANs so that communication with Alteon remains
possible.
For example, if all IP interfaces are left on VLAN 1 (the default), and all ports are configured for
VLANs other than VLAN 1, then management features are effectively cut off. If an IP interface is
added to one of the other VLANs, the stations in that VLAN will all have access to management
features.
Examples
A Multiple VLANS with Tagging Adapters
Component Description
Alteon This Alteon is configured for three VLANs that represent three different IP
subnets. Two servers and five clients are attached to Alteon.
Server #1 This server is part of VLAN 3 and is present in only one IP subnet. The port
that the VLAN is attached to is configured only for VLAN 3, so VLAN
tagging is off.
Server #2 This high-use server needs to be accessed from all VLANs and IP subnets.
The server has a VLAN-tagging adapter installed with VLAN tagging turned
on. The adapter is attached to one of Alteon's Gigabit Ethernet ports that is
configured for VLANs 1, 2, and 3. Tagging is turned on. Because of the
VLAN tagging capabilities of both the adapter and Alteon, the server is able
to communicate on all three IP subnets in this network. Broadcast
separation between all three VLANs and subnets, however, is maintained.
PCs #1 and #2 These PCs are attached to a shared media hub that is then connected to
Alteon. They belong to VLAN 2 and are logically in the same IP subnet as
Server 2 and PC 5. Tagging is not enabled on their ports.
PC #3 A member of VLAN 1, this PC can minimize its broadcast domain to Server
2 and PC 5.
Component Description
PC #4 A member of VLAN 3, this PC can minimize its broadcast domain to Server
1 and Server 2.
PC #5 A member of both VLAN 1 and VLAN 2, this PC has VLAN-tagging Gigabit
Ethernet adapter installed. It can minimize its broadcast domain to Server
#2 via VLAN 1, and to PC #1 and PC #2 via VLAN 2. The port to which it is
connected is configured for both VLAN 1 and VLAN 2 and has tagging
enabled.
Note: VLAN tagging is required only on ports that are connected to other Alteons or on ports
that connect to tag-capable end-stations, such as servers with VLAN- tagging adapters.
Note: In this example, the Gig ports are on different VLANs and the Spanning Tree Protocol (STP) is
disabled. For information on STP, see Spanning Tree Protocol, page 99.
You can configure up to 255 gateways with one gateway per VLAN with values starting from 5
through 259. If the gateways per VLAN fail, then traffic is directed to default gateways 1 through 4.
Default gateways 1 through 4 are used for load balancing session requests and as backup when a
specific gateway that has been assigned to a VLAN is down.
If gateways 5 or 6 fail, then traffic is directed to default gateway 1, which is configured with IP
address 10.10.4.1. If default gateways 1 through 4 are not configured, then packets from VLAN 2
and VLAN 3 are discarded.
The route cache table records each session request by mapping the destination IP address with the
MAC address of the default gateway. The command /info/l3/arp/dump displays the entries in
the route cache similar to Table 9. The destination IP addresses (see the last two rows of the table)
are associated with the MAC addresses of the gateways.
Traffic from VLAN 2 uses Gateway 5 to access destination IP address 192.168.20.200. If traffic from
VLAN 3 requests the same destination address, then traffic is routed via Gateway 5 instead of
Gateway 6, because 192.168.20.200 in the route cache is mapped to Gateway 5. If the requested
route is not in the route cache, then Alteon reads the routing table. If the requested route is not in
the routing table, then Alteon looks at the configured default Gateway.
The real servers reside on VLAN 1. By specifying a VLAN-based gateway, Alteon controls which
external link these real servers will use to respond to client requests. The external link used is not
dependent on whether the client traffic was sourced from VLAN 2 or VLAN 3.
3. Configure the default gateways. Configure gateways 5 and 6 for VLANs 2 and 3, respectively.
Configure default gateway 1 for load-balancing session requests and as backup when gateways
5 and 6 fail.
Note: The IP address for default gateways 1 to 4 must be unique. IP addresses for default
gateways 5 to 259 can be set to the same IP address as the other gateways (including default
gateway 1 to 4). For example, you can configure two default gateways with the same IP address
for two different VLANs.
6. Optionally, configure the local networks using address and mask pairs to ensure that the VLANs
use the configured default gateways.
Overview
When using port trunk groups between two Alteons, as shown in Figure 5 - Example Port Trunk
Group Between Alteons, page 89, you can create a virtual link between Alteons operating up to 4
gigabits per second, depending on how many physical ports are combined. Alteon supports up to 12
static trunk groups per Alteon, each with two to eight ports per group.
Trunk groups are also useful for connecting an Alteon to third-party devices that support link
aggregation, such as Cisco routers and switches with EtherChannel® technology (not ISL trunking
technology) and Sun's Quad Fast Ethernet Adapter. Trunk group technology is compatible with these
devices when they are configured manually.
Note: Layer 4 trunk hashing is currently supported only in Alteon 21.0 and higher.
Prior to configuring each Alteon, you must connect to the appropriate CLI as the administrator.
Note: For details about accessing and using any of the menu commands described in this example,
see the Alteon Application Switch Operating System Command Reference.
In this example, two Alteons are used. If a third-party device supporting link aggregation is used
(such as Cisco routers and switches with EtherChannel technology or Sun's Quad Fast Ethernet
Adapter), trunk groups on the third-party device should be configured manually. Connection
problems could arise when using automatic trunk group negotiation on the third-party device.
Caution: To prevent spanning tree instability, do not change the spanning tree parameters on
individual ports belonging to any trunk group.
4. Examine the resulting information. If any settings are incorrect, make appropriate changes.
5. Save your new configuration changes.
Trunk group 1 (on Alteon 1) is now connected to trunk group 3 (on Alteon 2).
7. Examine the trunking information on each Alteon.
>> /info/l2/trunk
Information about each port in each configured trunk group is displayed. Make sure that trunk
groups consist of the expected ports and that each port is in the expected state.
Notes
• Any physical port can belong to only one trunk group.
• Up to eight ports can belong to the same trunk group.
• Best performance is achieved when all ports in any given trunk group are configured for the
same speed.
• Trunking from non-Alteon devices must comply with Cisco EtherChannel technology.
In this example, actor device ports 1 through 4 can aggregate to form an LACP trunk group with the
partner device ports 1 through 4. Note that the port admin key value has local significance only. The
admin key value for the partner device ports can be any integer value but it should be same for all
ports 1 through 4. In this example, it is 50.
LACP Modes
Each port can have one of the following LACP modes:
• off (default)—The user can configure this port into a regular static trunk group.
• active—The port is capable of forming an LACP trunk. This port sends LACP data unit (LACPDU)
packets to partner system ports.
• passive—The port is capable of forming an LACP trunk. This port only responds to the LACPDU
packets sent from an LACP active port.
Each active LACP port transmits LACPDUs, while each passive LACP port listens for LACPDUs. During
LACP negotiation, the admin key value is exchanged. The LACP trunk group is enabled as long as the
information matches at both ends of the link. If the admin key value changes for a port at either end
of the link, that port's association with the LACP trunk group is lost.
When the system is initialized, all ports by default are in LACP off mode and are assigned unique
admin keys. To make a group of ports eligible for aggregation, you assign all of them the same
admin key. You must set the port's LACP mode to active to activate LACP negotiation. You can set
another port's LACP mode to passive, to reduce the amount of LACPDU traffic, at the initial trunk-
forming stage.
Note: LACP implementation does not support the Churn machine, an option used for detecting the
port is operable within a bounded time period between the actor and the partner. Only the marker
responder is implemented, and there is no marker protocol generator. Refer to 802.3ad-2002 for
details.
Configuring LACP
Use the following procedure to configure LACP for port 1 through port 4 for the actor device to
participate in link aggregation. Perform a similar configuration on the partner device with admin
key 50.
1. Set the LACP mode on port 1.
2. Define the admin key on port 1. Only ports with the same admin key can form a LACP trunk
group.
In both of these examples, the teams are placed in passive mode with either the ports or trunks
operational. The team is in passive mode when all ports or trunks are operational, and the team is
waiting for any one of the ports or trunks to become disabled. When one of the ports or trunks is
disabled, the team goes to active mode and the other ports or trunks in the team are operationally
disabled. The port or trunk that triggered this becomes the master port or trunk.
When the master port or trunk becomes operational once more, the other ports or trunks in the
team are operationally enabled. When all the ports or trunks are operational, the team goes back to
passive mode.
In some cases when the ports and trunks are operationally enabled, some of the other ports or
trunks in the team are not operational either because of a link going down, or because they were
operationally disabled or were set as disabled. If this happens, the team goes into off mode. In this
mode, the team waits until all ports or trunks are operational before going back to passive mode to
repeat the cycle.
Overview
STP detects and eliminates logical loops in a bridged or switched network. STP forces redundant
data paths into a standby (blocked) state. When multiple paths exist, STP configures the network so
that an Alteon uses only the most efficient path. If that path fails, STP sets up another active path
on the network to sustain network operations.
The relationship between port, trunk groups, VLANs, and spanning trees is described in Table 11:
Table 11: Relationship Between Port, Trunk Groups, VLANs, and Spanning Trees
Note: Due to STP’s sequence of listening, learning, and forwarding or blocking, lengthy delays may
occur. For more information on using STP in cross-redundant topologies, see Eliminating Loops with
STP and VLANs, page 568.
The generic action of an Alteon on receiving a BPDU is to compare the received BPDU to its own
BPDU that it transmits. If the received BPDU is better than its own BPDU, it will replace its BPDU
with the received BPDU. Then, Alteon adds its own bridge ID number and increments the path cost
of the BPDU. Alteon uses this information to block any necessary ports.
Bridge Priority
The bridge priority parameter controls which bridge on the network is the STP root bridge. To make
one Alteon the root bridge, configure the bridge priority lower than all other switches and bridges on
your network. The lower the value, the higher the bridge priority. The bridge priority is configured
using the /cfg/l2/stg/brg/prior command.
Port Priority
The port priority helps determine which bridge port becomes the designated port. In a network
topology that has multiple bridge ports connected to a single segment, the port with the lowest port
priority becomes the designated port for the segment. The port priority is configured using the
/cfg/l2/stg/port/prior command.
Creating a VLAN
• When you create a VLAN, that VLAN belongs to STG 1, the default STG. If you want the VLAN in
another STG, you must move the VLAN by assigning it to another STG.
Move a newly created VLAN to an existing STG by following this order:
a. Create the VLAN
b. Add the VLAN to an existing STG
• If ports are tagged, all trunked ports can belong to multiple STGs.
• A port that is not a member of any VLAN cannot be added to any STG. The port must be added
to a VLAN, and that VLAN added to the desired STG.
Adding a Port
When you add a port to a VLAN that belongs to an STG, the port is also added to the STG. However,
if the port you are adding is an untagged port and is already a member of an STG, that port is not
added to an additional STG because an untagged port cannot belong to more that one STG.
Example
VLAN1 belongs to STG1. You add an untagged port, port 1, that does not belong to any STG to
VLAN1, and port 1 becomes part of STG1.
If you add untagged port 5 (which is a member to STG2) to STG1, Alteon prompts you to change the
PVID from 2 to 1:
"Port 5 is an UNTAGGED port and its current PVID is 2. Confirm changing PVID
from 2 to 1 [y/n]:" y
Removing a Port
When you remove a port from a VLAN that belongs to an STG, that port will also be removed from
the STG. However, if that port belongs to another VLAN in the same STG, the port remains in the
STG.
Example
Port 1 belongs to VLAN1, and VLAN1 belongs to STG1. When you remove port 1 from VLAN1, port 1
is also removed from STG1.
However, if port 1 belongs to both VLAN1 and VLAN2 and both VLANs belong to STG1, removing port
1 from VLAN1 does not remove port 1 from STG1 because VLAN2 is still a member of STG1.
Disabling an STG
An STG cannot be deleted, only disabled. If you disable the STG while it still contains VLAN
members, STP will be off on all ports belonging to that VLAN.
Caution: All ports that are within a trunk group should be configured to have the same spanning
tree and VLAN parameters. Spanning tree parameters should not be changed on individual ports
that belong to a trunk group. To change spanning tree parameters on one or more ports belonging
to a trunk group, first remove individual members from the trunk group.
Two spanning tree instances are configured in this example. To identify the STG a VLAN is
participating in for each Alteon, see Multiple Spanning Tree Groups per VLAN Example, page 105.
Table 12 provides a summary of this example:
RSTP is compatible with devices that run 802.1d Spanning Tree Protocol. If Alteon detects 802.1d
BPDUs, it responds with 802.1d-compatible data units. RSTP is not compatible with the Per VLAN
Spanning Tree (PVST+) protocol.
MSTP Region
A group of interconnected bridges that share the same attributes is called a Multiple Spanning Tree
(MST) region. Each bridge within the region must share the following attributes:
• Alphanumeric name
• Version number
• VLAN-to-STG mapping scheme
MSTP provides rapid reconfiguration, scalability and control due to the support of regions, and
multiple spanning tree instances support within each region.
2. Create VLAN and add ports. Once ports have been readied for VLAN membership, VLAN 3 can be
created and the ports added to the VLAN.
Note: If the VLAN was not already created, it would be created with this command.
3. Set the mode to Multiple Spanning Tree, and configure MSTP region parameters.
IP Routing Benefits
Alteon uses a combination of configurable IP interfaces and IP routing options. The IP routing
capabilities provide the following benefits:
• Connects the server IP subnets to the rest of the backbone network.
• Performs Server Load Balancing (using both Layer 3 and Layer 4 in combination) to server
subnets that are separate from backbone subnets.
• Routing IP traffic between multiple Virtual Local Area Networks (VLANs) configured on Alteon.
Figure 10 - Example Topology Migration, page 112 illustrates an example topology migration:
In this example, a corporate campus has migrated from a router-centric topology to a faster, more
powerful, switch-based topology. The legacy of network growth and redesign has left the system
with a mix of illogically distributed subnets.
This is a situation that switching alone cannot normalize. Instead, the router is flooded with cross-
subnet communication. This compromises efficiency in two ways:
• Routers can be slower than switches. The cross-subnet side trip from the switch to the router
and back again adds two hops for the data, slowing throughput considerably.
• Traffic to the router increases, increasing congestion.
Even if every end-station could be moved to better logical subnets, competition for access to
common server pools on different subnets still burdens the routers.
This problem is solved by using Alteon with built-in IP routing capabilities. Cross-subnet LAN traffic
can now be routed within Alteon with wire speed Layer 2 switching performance. This not only eases
the load on the router but saves the network administrators from reconfiguring each and every end-
station with new IP addresses.
Alteon connects the Gigabit Ethernet trunks from various switched subnets throughout one building.
Common servers are placed on another subnet attached to Alteon. A primary and backup router are
attached to Alteon on yet another subnet.
Without Layer 3 IP routing, cross-subnet communication is relayed to the default gateway (in this
case, the router) for the next level of routing intelligence. The router fills in the necessary address
information and sends the data back to Alteon, which then relays the packet to the proper
destination subnet using Layer 2 switching.
With Layer 3 IP routing in place, routing between different IP subnets can be accomplished entirely
within Alteon. This leaves the routers free to handle inbound and outbound traffic for this group of
subnets.
Notes
• Prior to configuration, you must be connected to the CLI as the administrator.
• For details about accessing and using any of the menu commands described in this example, see
the Alteon Application Switch Operating System Command Reference.
1. Assign an IP address (or document the existing one) for each real server, router, and client
workstation.
2. Assign an IP interface for each subnet attached to Alteon. Since there are four IP subnets
connected to Alteon, four IP interfaces are needed:
3. Set each server and workstation's default gateway to the appropriate IP interface (the one in the
same subnet as the server or workstation).
4. Configure the default gateways to the routers' addresses. This allows Alteon to send outbound
traffic to the routers:
>> Default gateway 2# addr 205.21.17.2 (Assign address for secondary router)
>> Default gateway 2# ena (Enable secondary default gateway)
Examine the resulting information. If any settings are incorrect, make the appropriate changes.
6. Save your new configuration changes.
Note: This procedure uses the configuration in Figure 10 - Example Topology Migration, page 112
as its baseline.
1. Determine which ports and IP interfaces belong to which VLANs. Table 16 includes port and
VLAN information used in this example:
2. Add the ports to their respective VLANs. The VLANs are configured as follows:
Each time you add a port to a VLAN, you may get the following prompt:
Enter y to set the default Port VLAN ID (PVID) for the port.
3. Add each IP interface to the appropriate VLAN.
Now that the ports are separated into three VLANs, the IP interface for each subnet must be
placed in the appropriate VLAN. Based on the configuration in step 2, the settings are made as
follows:
Examine the resulting information. If any settings are incorrect, make the appropriate changes.
5. Save your new configuration changes.
Local Host Address Range Local Network Address Local Network Mask
0.0.0.0–127.255.255.255 0.0.0.0 128.0.0.0
128.0.0.0–128.255.255.255 128.0.0.0 128.0.0.0 or 255.0.0.0
205.32.0.0–205.32.255.255 205.32.0.0 255.255.0.0
When Alteon receives a UDP broadcast on port 67 from a DHCP client requesting an IP address,
Alteon acts as a proxy for the client, replacing the client source IP (SIP) and destination IP (DIP)
addresses. The request is then forwarded as a UDP Unicast MAC layer message to two BOOTP
servers with configured IP addresses. The servers respond with a UDP Unicast message back to
Alteon, with the default gateway and IP address for the client. The destination IP address in the
server response represents the interface address that received the client request. This interface
address instructs Alteon on which VLAN to send the server response to the client.
In this Alteon implementation, there is no need for primary or secondary servers. The client request
is forwarded to the BOOTP servers configured. Using two servers provides failover redundancy.
However, no health checking is supported.
>> # /cfg/l3/bootp
>> Bootstrap Protocol Relay# addr (Set IP address of BOOTP server)
>> Bootstrap Protocol Relay# addr2 (Set IP address of second BOOTP
server)
>> Bootstrap Protocol Relay# on (Globally turn BOOTP relay on)
>> Bootstrap Protocol Relay# off (Globally turn BOOTP relay off)
>> Bootstrap Protocol Relay# cur (Display the current configuration)
2. Additionally, DHCP Relay functionality can be assigned on a per-interface basis. Use the
following command to enable the Relay functionality:
Static Routes
Alteon has two basic mechanisms for learning networking routes:
• Dynamic routes—The primary mechanism is through the use of routing protocols like the
Routing Information Protocol (RIP) and Open Shortest Path First (OSPF) protocol. Routes
learned in this manner are often referred to as dynamic routes because they are updated
periodically by the routing protocols to reflect the current conditions in the network. For more
information on these protocols and their use, see Routing Information Protocol, page 121 and
Open Shortest Path First (OSPF), page 137.
• Static routes—Alteon also learns networking routes through static routes. Static routes are
manually entered into Alteon by an administrator. Although whole networks could be built upon
static routes, they do not have the capacity to change without user intervention and therefore
do not adequately represent the ever-changing reality of an enterprise network. It is because of
this that static routes have an important but limited role in the enterprise network. Typically,
static routes are used in situations when a protocol like RIP or OSPF cannot provide the
information necessary to create connectivity between two nodes.
For example, a node in a network that is running OSPF may need to know the route to a node in
a network that is not running OSPF. OSPF would not provide information about either network to
its counterpart. In this situation, a static route should be used to provide connectivity.
Alteon supports both IPv4 and IPv6 static routes through the Layer 3 Configuration menu. Up to
128 IPv4 and 128 IPv6 static routes are supported.
Note: When adding an IPv4 static route, in most cases you do not have to specify an interface
number. However, if you are using Firewall Load Balancing (FWLB) and you define two IP interfaces
on the same subnet, where one IP interface has a subnet of the host which is also included in the
subnet of the second interface, you must specify the interface.
The IPv4 static routes that are currently part of the configuration can be displayed using the /cfg/
l3/route/ip4/cur command.
IPv6 static routes are removed from the switch using the /cfg/l3/route/ip6/rem command,
using the following syntax:
The IPv6 static routes that are currently part of the switch configuration can be displayed using the
/cfg/l3/route/ip6/cur command.
Stability
RIP includes a number of stability features that are common to many routing protocols. For
example, RIP implements the split horizon and hold-down mechanisms to prevent incorrect routing
information.
RIP prevents routing loops from continuing indefinitely by implementing a limit on the number of
hops allowed in a path from the source to a destination. The maximum number of hops in a path is
15. The network destination network is considered unreachable if increasing the metric value by 1
causes the metric to be 16 (that is, infinity). This limits the maximum diameter of a RIP network to
less than 16 hops.
RIP is often used in stub networks and in small autonomous systems that do not have many
redundant paths.
Routing Updates
RIP sends routing update messages at regular intervals and when the network topology changes.
Each router "advertises" routing information by sending a routing information update every 30
seconds. If a router does not receive an update from another router for 180 seconds, the routes
provided by that router are declared invalid. After another 120 seconds without receiving an update
for those routes, the routes are removed from the routing table and respective regular updates.
When a router receives a routing update that includes changes to an entry, it updates its routing
table to reflect the new route. The metric value for the path is increased by 1, and the sender is
indicated as the next hop. RIP routers maintain only the best route (the route with the lowest metric
value) to a destination.
For details on configuring routing updates, see the explanation of the Configuration menu, Routing
Information Protocol Configuration (/cfg/l3/rip command) in the Alteon Application Switch
Operating System Command Reference.
RIP Versions
This section includes the following sub-sections:
• RIP Version 1, page 122
• RIP Version 2, page 122
• RIP Version 2 in RIP Version 1 Compatibility Mode, page 122
RIP Version 1
RIP version 1 (RIPv1) uses broadcast User Datagram Protocol (UDP) data packets for the regular
routing updates. The main disadvantage is that the routing updates do not carry subnet mask
information. Therefore, the router cannot determine whether the route is a subnet route or a host
route. It is of limited use after the introduction of RIPv2.
For more information about RIPv1 and RIPv2, refer to RFC 1058 and RFC 2453.
RIP Version 2
RIP version 2 (RIPv2) is the most popular and preferred configuration for most networks. RIPv2
expands the amount of useful information carried in RIP messages and provides a measure of
security.
RIPv2 improves efficiency by using multicast UDP (address 224.0.0.9) data packets for regular
routing updates. Subnet mask information is provided in the routing updates. A security option is
added for authenticating routing updates by using a shared password. Alteon supports using clear
text passwords for RIPv2.
RIPv2 supports the following enhancements to RIPv1:
• Variable length subnet masks for classless inter-domain routing.
• RIPv2 updates always include the next-hop router address.
• Routing updates can be sent to a multicast address.
• Routing updates can be authenticated using a simple password scheme.
For a detailed explanation of RIPv2, refer to RFC 1723 and RFC 2453.
Note: When using both RIPv1 and RIPv2 within a network, use a single subnet mask throughout
the network.
RIP Features
Alteon provides the following features to support RIPv1 and RIPv2:
• Poison, page 123
• Triggered Updates, page 123
• Multicast, page 123
• Default, page 123
• Metric, page 123
• Authentication, page 123
Poison
Simple split horizon in the RIP scheme omits routes learned from one neighbor in updates sent to
that neighbor. That is the most common configuration used in RIP network topology. Split horizon
with poisoned reverse includes such routes in updates, but sets their metrics to 16. The
disadvantage of using this feature is the increase of size in the routing updates. Therefore, Radware
recommends disabling split horizon with poisoned reverse.
Triggered Updates
Triggered updates are an attempt to speed up convergence. When triggered updates are enabled,
whenever a router changes the metric for a route, it sends update messages almost immediately
without waiting for the regular update interval. Radware recommends enabling triggered updates.
Multicast
RIPv2 messages use the IP multicast address (224.0.0.9) for periodic broadcasts. Multicast RIPv2
announcements are not processed by RIPv1 routers.
To configure RIPv2 in RIPv1 compatibility mode, set multicast to disable.
Default
The RIP router can listen and supply a default route, usually represented as 0.0.0.0 in the routing
table. When a router does not have an explicit route to a destination network in its routing table, it
uses the default route to forward those packets.
Metric
The metric field contains a configurable value between 1 and 15 which specifies the current metric
for the interface. The metric value typically indicates the total number of hops to the destination.
The metric value of 16 represents an unreachable destination.
Authentication
RIPv2 authentication uses clear text passwords for authentication. If configured using an
authentication password, then it is necessary to enter an authentication key value.
The following method is used to authenticate a RIP message:
• If the router is not configured to authenticate RIPv2 messages, then RIPv1 and unauthenticated
RIPv2 messages are accepted. Authenticated RIPv2 messages are discarded.
• If the router is configured to authenticate RIPv2 messages, then RIPv1 messages and RIPv2
messages which pass authentication testing are accepted. Unauthenticated and failed
authentication RIPv2 messages are discarded.
For maximum security, RIPv1 messages are ignored when authentication is enabled. If not, the
routing information from authenticated messages is propagated by RIPv1 routers in an
unauthenticated manner.
Note: A disabled RIP interface uses all the default values of the RIP, no matter how the RIP
parameters are configured for that interface. RIP sends RIP regular updates to include an up
interface, but not a down interface.
4. Use the /maint/route/dump command to check the current valid routes in the routing table.
For those RIP-learned routes within the garbage collection period, routes phasing out of the
routing table with metric 16, use the /info/l3/route/dump command. Locally configured
static routes do not appear in the RIP routing table.
Figure 13: Example Topology using the Border Gateway Protocol (BGP)
Typically, an AS has one or more border routers (that is, peer routers that exchange routes with
other ASs) and an internal routing scheme that enables routers in that AS to reach every other
router and destination within that AS. When Alteon advertises routes to border routers on other
autonomous systems, it is effectively committing to carry data to the IP space represented in the
route being advertised. For example, if Alteon advertises 192.204.4.0/24, it is declaring that if
another router sends it data destined for any address in 192.204.4.0/24, Alteon knows how to carry
that data to its destination.
Route Maps
A route map is used to control and modify routing information. Route maps define conditions for
redistributing routes from one routing protocol to another, or controlling routing information when
injecting it in and out of BGP. Route maps are used by OSPF only for redistributing routes. For
example, a route map is used to set a preference value for a specific route from a peer router and
another preference value for all other routes learned via the same peer router. The following
command is used to define a route map:
A route map lets you match attributes, such as metric, network address, and the AS number. It also
lets you overwrite the local preference metric and to append the AS number in the AS route. For
more information, see BGP Failover Configuration, page 131.
Alteon lets you configure up to 32 route maps. Each route map can have up to eight access lists.
Each access list consists of a network filter. A network filter defines an IP address and subnet mask
of the network that you want to include in the filter. Figure 14 - Relationship Between Route Maps,
Access Lists, and Network Filters, page 127 illustrates the relationship between route maps, access
lists and network filters.
Figure 14: Relationship Between Route Maps, Access Lists, and Network Filters
Precedence
You can set a priority to a route map by specifying a precedence value with the following command:
The lower the value, the higher the precedence. If two route maps have the same precedence value,
the lower number has higher precedence.
Configuration Overview
Enter a filter number from 1 to 256. Specify the IP address and subnet mask of the network that
you want to match. Enable the network filter. You can distribute up to 256 network filters among
32 route maps each containing eight access lists.
2. Optionally, define the criteria for the access list and enable it.
Specify the access list and associate the network filter number configured in step 1.
This step and step 3 are optional, depending on the criteria that you want to match. In this step,
the network filter number is used to match the subnets defined in the network filter. In step 3,
the autonomous system number is used to match the subnets. Alternately, you can use both
step 2 and step 3 criteria (access list [network filter] and access path [AS filter]) to configure
the route maps.
3. Optionally, configure the attributes in the AS filter menu.
6. Assign the route map to a peer router. Select the peer router and then add the route map to one
of the following:
— Incoming route map list:
Aggregating Routes
Aggregation is the process of combining several different routes in such a way that a single route
can be advertised, minimizing the size of the routing table. You can configure aggregate routes in
BGP either by redistributing an aggregate route into BGP or by creating an aggregate entry in the
BGP routing table.
When a subnet is redistributed from an Interior Gateway Protocol (IGP) into BGP, only the network
route is injected into the BGP table. By default, this automatic summarization is disabled.
For an example of creating a BGP aggregate route, see Default Redistribution and Route
Aggregation Example, page 134.
Redistributing Routes
In addition to running multiple routing protocols simultaneously, Alteon can redistribute information
from one routing protocol to another. For example, you can instruct Alteon to use BGP to readvertise
static routes. This applies to all of the IP-based routing protocols.
You can also conditionally control the redistribution of routes between routing domains by defining a
method known as route maps between the two domains. For more information on route maps, see
Route Maps, page 126. Redistributing routes is another way of providing policy control over whether
to export OSPF routes, fixed routes, static routes, and virtual IP address routes. For an example
configuration, see Default Redistribution and Route Aggregation Example, page 134.
Default routes can be configured using the following methods:
• Import
• Originate—The router sends a default route to peers even though it does not have any default
routes in its routing table.
• Redistribute—Default routes are either configured through the default gateway or learned via
other protocols and redistributed to peer routers. If the default routes are from the default
gateway, enable the static routes because default routes from the default gateway are static
routes. Similarly, if the routes are learned from another routing protocol, enable that protocol
for redistribution.
• None
BGP Attributes
The following two BGP attributes are discussed in this section:
• Local Preference Attribute, page 130
• Metric (Multi-Exit Discriminator) Attribute, page 130
Unless otherwise specified, the router compares metric attributes for paths from external neighbors
that are in the same AS.
On Alteon, one peer router (the secondary one) is configured with a longer AS path than the other,
so that the peer with the shorter AS path will be seen by Alteon as the primary default gateway. ISP
2, the secondary peer, is configured with a metric of 3, appearing to Alteon to be three router hops
away.
Example
1. Configure Alteon as you normally would for Server Load Balancing (SLB).
— Assign an IP address to each of the real servers in the server pool.
— Define each real server.
— Define a real server group.
— Define a virtual server.
— Define the port configuration.
For more information about SLB configuration, see Server Load Balancing, page 165.
2. Define the VLANs.
For simplicity, both default gateways are configured on the same VLAN in this example. The
gateways could be in the same VLAN or different VLANs.
Alteon needs an IP interface for each default gateway to which it is connected. Each interface
needs to be placed in the appropriate VLAN. These interfaces are used as the primary and
secondary default gateways for Alteon.
4. IP forwarding is enabled by default and is used for VLAN-to-VLAN (non-BGP) routing. Make sure
IP forwarding is enabled if the default gateways are on different subnets or if Alteon is connected
to different subnets and those subnets need to communicate through Alteon.
>> /cfg/l3/frwd/on
Note: To help eliminate the possibility for a Denial of Service (DoS) attack, the forwarding of
directed broadcasts is disabled by default.
>> # /cfg/l3/bgp/on
6. Configure BGP peer router 1 and 2. Peer 1 is the primary gateway router. Peer 2 is configured
with a metric of 3. The metric option is key to ensuring gateway traffic is directed to peer 1, as
it makes peer 2 appear to be three router hops away from Alteon. Therefore, Alteon should
never use it unless peer 1 goes down.
The metric command in the Peer menu causes Alteon to create an AS path of 3 when advertising
via BGP.
7. Apply and save your configuration changes.
Example
1. Configure the IP interface.
2. Configure the AS number (AS 135) and router ID number (10.1.1.135).
The router ID number must be a unique number and does not have to be an IP address.
However, for convenience, this ID is typically one of IP addresses assigned in IP interfaces.
5. Configure aggregation policy control. Configure the routes that you want aggregated.
>> # apply
>> # save
Note: CLI command paths in this chapter reflect OSPF version 2. For OSPF version 3 paths, it is
sufficient in most cases to replace the ospf parameter with ospfv3. For example:
>> # /cfg/l3/ospf/aindex
>> # /cfg/l3/ospfv3/aindex
OSPF Overview
OSPF is designed for routing traffic within a single IP domain called an Autonomous System (AS).
The AS can be divided into smaller logical units known as areas.
All routing devices maintain link information in their own Link State Database (LSDB). The LSDB for
all routing devices within an area is identical but is not exchanged between different areas. Only
routing updates are exchanged between areas, thereby significantly reducing the overhead for
maintaining routing information on a large, dynamic network.
The following key OSPF concepts are described in this section:
• Equal Cost Multipath Routing Support, page 138
• Types of OSPF Areas, page 138
• Types of OSPF Routing Devices, page 139
• Neighbors and Adjacencies, page 139
• The Link-State Database, page 140
The BDR is adjacent to all other neighbors (including the DR). Each neighbor sends its database
information to the BDR just as with the DR, but the BDR merely stores this data and does not
distribute it. If the DR fails, the BDR takes over the task of distributing database information to the
other neighbors.
Note: The Alteon IPv6 component runs OSPFv3 adjacency per VLAN and not per Layer 3 interface.
This is because OSPFv3 requires a link local address, which is available with a VLAN, but not with a
Layer 3 interface.
OSPF Implementation
Alteon supports a single instance of OSPF and up to 4 K routes on the network. The following
sections describe Alteon OSPF implementation:
• Defining Areas, page 141
• Interface Cost, page 143
• Electing the Designated Router and Backup, page 143
• Summarizing Routes, page 143
• Default Routes, page 143
• Virtual Links, page 145
• Router ID, page 145
• Authentication, page 146
• Host Routes for Load Balancing, page 148
• Redistributing Routes into OSPF, page 148
Defining Areas
If you are configuring multiple areas in your OSPF domain, one of the areas must be designated as
area 0, known as the backbone. The backbone is the central OSPF area and is usually physically
connected to all other areas. The areas inject routing information into the backbone which, in turn,
disseminates the information into other areas.
Since the backbone connects the areas in your network, it must be a contiguous area. If the
backbone is partitioned (possibly as a result of joining separate OSPF networks), parts of the AS will
be unreachable, and you will need to configure virtual links to reconnect the partitioned areas (see
Virtual Links, page 145).
Up to three OSPF areas can be connected to Alteon. To configure an area, the OSPF number must be
defined and then attached to a network interface on Alteon. The full process is explained in this
section.
An OSPF area is defined by assigning two pieces of information—an area index and an area ID. The
command to define an OSPF area is as follows:
Note: The aindex option is an arbitrary index used only by Alteon, and does not represent the
actual OSPF area number. The actual OSPF area number is defined in the areaid portion of the
command.
Note: Although both types of area ID formats are supported, ensure that the area IDs are in the
same format throughout an area.
Example
The following commands could be used to configure IP interface 14 for a presence on the
10.10.10.1/24 network, to define OSPF area 1, and to attach the area to the network:
Interface Cost
The OSPF link-state algorithm (Dijkstra's algorithm) places each routing device at the root of a tree
and determines the cumulative cost required to reach each destination. Usually, the cost is inversely
proportional to the bandwidth of the interface. A low cost indicates high bandwidth. You can
manually enter the cost for the output route with the following command:
A priority value of 255 is the highest, and 1 is the lowest. A priority value of 0 specifies that the
interface cannot be used as a DR or BDR. In case of a tie, the routing device with the highest router
ID wins.
Summarizing Routes
Route summarization condenses routing information. Without summarization, each routing device in
an OSPF network would retain a route to every subnet in the network. With summarization, routing
devices can reduce some sets of routes to a single advertisement, reducing both the load on the
routing device and the perceived complexity of the network. The importance of route summarization
increases with network size.
Summary routes can be defined for up to 16 IP address ranges using the following command:
Default Routes
When an OSPF routing device encounters traffic for a destination address it does not recognize, it
forwards that traffic along the default route. Typically, the default route leads upstream toward the
backbone until it reaches the intended area or an external router.
Each Alteon acting as an ABR inserts a default route into each attached area. In simple OSPF stub
areas or NSSAs with only one ABR leading upstream (see Area 1 in Figure 19 - Default Routes
Example, page 144), any traffic for IP address destinations outside the area is forwarded to Alteon's
IP interface, and then into the connected transit area (usually the backbone). Since this is
automatic, no further configuration is required for such areas.
In more complex OSPF areas with multiple ABRs or ASBRs (such as area 0 and area 2 in Figure 19 -
Default Routes Example, page 144), there are multiple routes leading from the area. In such areas,
traffic for unrecognized destinations cannot determine which route leads upstream without further
configuration.
To resolve the situation and select one default route among multiple choices in an area, you can
manually configure a metric value on each ABR. The metric assigns a priority to the ABR for its
selection as the priority default route in an area.
• metric value sets the priority for choosing this device for the default route.
— The value none sets no default.
— The value 1 sets the highest priority for the default route.
• metric type determines the method for influencing routing decisions for external routes.
Virtual Links
Usually, all areas in an OSPF AS are physically connected to the backbone. In some cases where this
is not possible, you can use a virtual link. Virtual links are created to connect one area to the
backbone through another non-backbone area (see Figure 19 - Default Routes Example, page 144).
The area which contains a virtual link must be a transit area and have full routing information.
Virtual links cannot be configured inside a stub area or NSSA. The area type must be defined as
transit using the following command:
The virtual link must be configured on the routing devices at each endpoint of the virtual link,
though they may traverse multiple routing devices.
>> # /cfg/l3/ospf/virt <link number> /aindex <area index> /nbr <router ID>
Router ID
Routing devices in OSPF areas are identified by a router ID. The router ID is expressed in IP address
format. The IP address of the router ID is not required to be included in any IP interface range or in
any OSPF area.
The router ID can be configured in one of the following two ways:
• Dynamically—By default, OSPF protocol configures the lowest IP interface IP address as the
router ID.
• Statically—Use the following command to manually configure the router ID:
>> # /info/13/ospf/gen
Authentication
OSPF protocol exchanges can be authenticated so that only trusted routing devices can participate.
This ensures less processing on routing devices that are not listening to OSPF packets.
OSPF allows packet authentication and uses IP multicast when sending and receiving packets.
Routers participate in routing domains based on predefined passwords. Alteon supports simple
password (type 1 plain text passwords) and MD5 cryptographic authentication for OSPF version 2.
This type of authentication allows a password to be configured per area.
Figure 20 - Authentication Example, page 146 shows authentication configured for area 0 with the
password test. Simple authentication is also configured for the virtual link between area 2 and area
0. Area 1 is not configured for OSPF authentication.
2. Configure a simple text password up to eight characters for each OSPF IP interface in Area 0 on
Alteons 1, 2, and 3.
>> # /cfg/l3/ospf/if 1
>> OSPF Interface 1 # key test
>> OSPF Interface 1 # /cfg/l3/ospf/if 2
>> OSPF Interface 2 # key test
>> OSPF Interface 1 # /cfg/l3/ospf/if 3
>> OSPF Interface 3 # key test
4. Configure a simple text password up to eight characters for the virtual link between Area 2 and
Area 0 on Alteons 2 and 4.
>> # /cfg/l3/ospf/if 1
>> OSPF Interface 1 # mdkey 1
>> OSPF Interface 1 # /cfg/l3/ospf/if 2
>> OSPF Interface 2 # mdkey 1
>> OSPF Interface 1 # /cfg/l3/ospf/if 3
>> OSPF Interface 3 # mdkey 1
5. Configure MD5 key for the virtual link between Area 2 and Area 0 on Alteons 2 and 4.
• protocol name is static, RIP, iBGP, eBGP, or fixed. By default, these protocol routes are not
redistributed into OSPF.
Use one of the following three methods to redistribute the routes of a particular protocol into OSPF:
• Exporting all the routes of the protocol
• Using route maps
Route maps allow you to control the redistribution of routes between routing domains. For
conceptual information on route maps, see Route Maps, page 126.
• Exporting all routes of the protocol except a few selected routes
Each of these methods is discussed in detail in the following sections.
Note: Alteon does not redistribute Layer 3 interface IPv6 addresses when the address has a prefix
length of 128.
Task Command
Adding a route map for a particular /cfg/l3/ospf/redist <protocol name> /add <route
protocol map numbers>
Adding all 32 route maps /cfg/l3/ospf/redist <protocol name> /add all
Removing a route map for a /cfg/l3/ospf/redist <protocol name> /rem <route
particular protocol map numbers>
Removing all 32 route maps for a /cfg/l3/ospf/redist <protocol name> /rem all
particular protocol
OSPF does not require you to set all the fields in the route map menu. The following procedure
includes the route maps and network filter parameter that must be set:
1. Enable the route map.
If a route map is added to a protocol for redistribution, and if the routes of that protocol match
any of the routes in the access lists, and if action is set to permit, then those routes are
redistributed into OSPF using the metric and metric type assigned for that route map. Metric
sets the priority for choosing this device for the default route.
3. Enable the access list.
>> /cfg/l3/rmap <route map number> /alist <access list number> /ena
>> /cfg/l3/rmap <route map number> /alist <access list number> /action permit
To redistribute routes matched by the route map, the action in the alist must be set to permit.
If the action is set to deny, the routes matched by the route map are not redistributed.
>> /cfg/l3/rmap <route map number> /alist <access list number> /nwf <network
filter number>
The type is the method for influencing routing decisions for external routes.
2. Match the metric of the protocol route.
>> /cfg/l3/rmap <l> /alist <access list number> /metric <metric value>
The metric value sets the priority for choosing this device for the route. The value none sets no
default, and 1 sets the highest priority for the route.
2. Enable OSPF.
3. Define the backbone. Always configure the backbone as a transit area using areaid 0.0.0.0.
>> Open Shortest Path First # aindex 0 (Select menu for area index 0)
>> Open Area (index) 0 # areaid 0.0.0.0 (Set the ID for backbone area 0)
>> Open Area (index) 0 # type transit (Define backbone as transit type)
>> OSPF Area (index) 0 # enable (Enable the area)
>> OSPF Area (index) 0 # /cfg/l3/ospf/aindex 1 (Select menu for area index 1)
>> OSPF Area (index) 1 # areaid 0.0.0.1 (Set the area ID for OSPF area 1)
>> OSPF Area (index) 1 # type stub (Define area as stub type)
>> OSPF Area (index) 1 # enable (Enable the area)
2. Configure the router ID. A router ID is required when configuring virtual links. Later, when
configuring the other end of the virtual link on Alteon 2, the router ID specified here is used as
the target virtual neighbor (nbr) address.
3. Enable OSPF.
>> Open Shortest Path First # aindex 0 (Select menu for area index 0)
>> OSPF Area (index) 0 # areaid 0.0.0.0 (Set the area ID for backbone area 0)
>> OSPF Area (index) 0 # type transit (Define backbone as transit type)
>> OSPF Area (index) 0 # enable (Enable the area)
5. Define the transit area. The area that contains the virtual link must be configured as a transit
area.
>> OSPF Area (index) 0 # /cfg/l3/ospf/aindex 1 (Select menu for area index 1)
>> OSPF Area (index) 1 # areaid 0.0.0.1 (Set the area ID for OSPF area 1)
>> OSPF Area (index) 1 # type transit (Define area as transit type)
>> OSPF Area (index) 1 # enable (Enable the area)
>> OSPF Area (index) 1 # /cfg/l3/ospf/if 1 (Select OSPF menu for IP interface 1)
>> OSPF Interface 1 # aindex 0 (Attach network to backbone index)
>> OSPF Interface 1 # enable (Enable the backbone interface)
8. Configure the virtual link. The nbr router ID configured in this step must be the same as the
router ID that is configured for step 2 in the procedure for Alteon 2.
2. Configure the router ID. A router ID is required when configuring virtual links. This router ID
should be the same one specified as the target virtual neighbor (nbr) in step 8 for Alteon 1.
3. Enable OSPF.
>> IP cfg/13/ospf/on
4. Configure the backbone index on the non-backbone end of the virtual link.
>> Open Shortest Path First # aindex 0 (Select the menu for area index 0)
>> OSPF Area (index) 0 # areaid 0.0.0.0 (Set the area ID for OSPF area 0)
>> OSPF Area (index) 0 # enable (Enable the area)
>> OSPF Area (index) 0 # /cfg/l3/ospf/aindex 1 (Select menu for area index 1)
>> OSPF Area (index) 1 # areaid 0.0.0.1 (Set the area ID for OSPF area 1)
>> OSPF Area (index) 1 # type transit (Define area as transit type)
>> OSPF Area (index) 1 # enable (Enable the area)
>> OSPF Area (index) 1 # /cfg/l3/ospf/aindex 2 (Select menu for area index 2)
>> OSPF Area (index) 2 # areaid 0.0.0.2 (Set the area ID for OSPF area 2)
>> OSPF Area (index) 2 # type stub (Define area as stub type)
>> OSPF Area (index) 2 # enable (Enable the area)
>> OSPF Area (index) 2 # /cfg/l3/ospf/if 1 (Select OSPF menu for IP interface 1)
>> OSPF Interface 1 # aindex 1 (Attach network to transit area index)
>> OSPF Interface 1 # enable (Enable the transit area interface)
9. Configure the virtual link. The nbr router ID configured in this step must be the same as the
router ID that was configured in step 2 for Alteon 1.
Note: You can specify a range of addresses to prevent advertising by using the hide option. In
this example, routes in the range 36.128.200.0 through 36.128.200.255 are kept private.
2. Enable OSPF.
>> Open Shortest Path First # aindex 0 (Select menu for area index 0)
>> OSPF Area (index) 0 # areaid 0.0.0.0 (Set the ID for backbone area 0)
>> OSPF Area (index) 0 # type transit (Define backbone as transit type)
>> OSPF Area (index) 0 # enable (Enable the area)
>> OSPF Area (index) 0 # /cfg/l3/ospf/aindex (Select menu for area index 1)
1
>> OSPF Area (index) 1 # areaid 0.0.0.1 (Set the area ID for OSPF area 1)
>> OSPF Area (index) 1 # type stub (Define area as stub type)
>> OSPF Area (index) 1 # enable (Enable the area)
>> OSPF Area (index) 1 # /cfg/l3/ospf/if 1 (Select OSPF menu for IP interface 1)
>> OSPF Interface 1 # aindex 0 (Attach network to backbone index)
>> OSPF Interface 1 # enable (Enable the backbone interface)
7. Configure route summarization by specifying the starting address and mask of the range of
addresses to be summarized
8. Use the hide command to prevent a range of addresses from advertising to the backbone.
>> OSPF Summary Range 2 # apply (Global command to apply all changes)
>> OSPF Summary Range 2 # save (Global command to save all changes)
All four host routes are injected into the upstream router and advertised externally. Traffic comes in
for both virtual server IP addresses (10.10.10.1 and 10.10.10.2). The upstream router sees that
both addresses exist on both devices and uses the host route with the lowest cost for each. Traffic
for 10.10.10.1 goes to Alteon 1 because its host route has the lowest cost for that address. Traffic
for 10.10.10.2 goes to Alteon 2 because its host route has the lowest cost. This effectively shares
the load among ABRs. Both devices then use standard Server Load Balancing (SLB) to distribute
traffic among available real servers.
In addition, if one of Alteons were to fail, the upstream routing device would forward the traffic to
the ABR whose host route has the next lowest cost. The remaining device assumes the entire load
for both virtual servers.
2. Configure basic SLB parameters. Alteon 1 is connected to two real servers. Each real server is
given an IP address and is placed in the same real server group.
5. Configure the primary virtual server. Alteon 1 is preferred for virtual server 10.10.10.1.
6. Configure the backup virtual server. Alteon 1 acts as a backup for virtual server 10.10.10.2.
Both virtual servers in this example are configured with the same real server group and provide
identical services.
>> Virtual server 2 http service # /cfg/ (Select menu for virtual server 2)
slb/virt 2
>> Virtual server 1 # vip 10.10.10.2 (Set the IP address for virtual server 2)
>> Virtual server 1 # ena (Enable the virtual server)
>> Virtual server 1 # service http (Select menu for service on virtual server)
>> Virtual server 1 http service # group 1 (Use real server group 1 for HTTP service)
>> Open Shortest Path First # aindex 0 (Select menu for area index 0)
>> OSPF Area (index) 0 # areaid 0.0.0.0 (Set the ID for backbone area 0)
>> OSPF Area (index) 0 # type transit (Define backbone as transit type)
>> OSPF Area (index) 0 # enable (Enable the area)
>> OSPF Area (index) 0 # /cfg/l3/ospf/aindex 1 (Select menu for area index 1)
>> OSPF Area (index) 1 # areaid 0.0.0.1 (Set the ID for stub area 1)
>> OSPF Area (index) 1 # type stub (Define area as stub type)
>> OSPF Area (index) 1 # enable (Enable the area)
>> OSPF Area (index) 1 # /cfg/l3/ospf/if 1 (Select OSPF menu for IP interface 1)
>> OSPF Interface 1 # aindex 0 (Attach network to backbone index)
>> OSPF Interface 1 # enable (Enable the backbone interface)
12. Configure host routes. One host route is needed for each virtual server on Alteon 1. Since virtual
server 10.10.10.1 is preferred for Alteon 1, its host route has a low cost. Because virtual server
10.10.10.2 is used as a backup in case Alteon 2 fails, its host route has a high cost.
Note: When a service goes down, the corresponding host route is removed from advertising.
2. Configure the virtual server parameters. The same virtual servers are configured as on Alteon 1.
>> Virtual server 1 # service http (Select menu for service on virtual
server)
>> Virtual server 1 http service # group 1 (Use real server group 1 for http
service)
>> Virtual server 2 http service # /cfg/slb/ (Select menu for virtual server 2)
virt 2
>> Virtual server 1 # vip 10.10.10.2 (Set the IP address for virtual server 2)
>> Virtual server 1 # enable (Enable the virtual server)
>> Virtual server 1 # service http (Select menu for service on virtual
server)
>> Virtual server 1 # group (Use real server group 1 for http
service)
3. Configure IP interfaces for each network that will be attached to OSPF areas.
>> Open Shortest Path# addr 10.10.10.6 (Select menu for area index 0)
>> OSPF Area (index) 0 # areaid 0.0.0.0 (Set the ID for backbone area 0)
>> OSPF Area (index) 0 # type transit (Define backbone as transit type)
>> OSPF Area (index) 0 # enable (Enable the area)
>> OSPF Area (index) 0 # /cfg/l3/ospf/aindex 1 (Select menu for area index 1)
>> OSPF Area (index) 1 # areaid 0.0.0.1 (Set the ID for stub area 1)
>> OSPF Area (index) 1 # type stub (Define area as stub type)
>> OSPF Area (index) 1 # enable (Enable the area)
>> OSPF Area (index) 1 # /cfg/l3/ospf/if 1 (Select OSPF menu for IP interface 1)
>> OSPF Interface 1 # aindex 0 (Attach network to backbone index)
>> OSPF Interface 1 # enable (Enable the backbone interface)
9. Configure host routes. Host routes are configured just like those on Alteon 1, except their costs
are reversed. Since virtual server 10.10.10.2 is preferred for Alteon 2, its host route has been
given a low cost. Because virtual server 10.10.10.1 is used as a backup in case Alteon 1 fails, its
host route has been given a high cost.
>> OSPF Host Entry 2 # apply (Global command to apply all changes)
>> OSPF Host Entry 2 # save (Global command to save all changes)
• You must be able to scale your applications to meet client and LAN request capacity.
• You cannot afford to continue using a less effective load-balancing technique, such as DNS
round-robin or a software-only system.
To provide load balancing for any particular type of service, each server in the pool must have
access to identical content, either directly (duplicated on each server) or through a back-end
network (mounting the same file system or database server).
Alteon with SLB software acts as a front-end to the servers, interpreting user session requests and
distributing them among the available servers. Load balancing in Alteon can be done in the following
ways:
• Virtual server-based load balancing—This is the traditional load balancing method. Alteon is
configured to act as a virtual server and is given a virtual server IP address (or range of
addresses) for each collection of services it distributes. Depending on your Alteon platform,
there can be as many as 1023 virtual servers on Alteon, each distributing up to eight different
services.
Each virtual server is assigned a list of the IP addresses (or range of addresses) of the real
servers in the pool where its services reside. When the user stations request connections to a
service, they communicate with a virtual server on Alteon. When Alteon receives the request, it
binds the session to the IP address of the best available real server and remaps the fields in
each frame from virtual addresses to real addresses.
HTTP, IP, FTP, RTSP, IDS, and static session WAP are examples of some of the services that use
virtual servers for load balancing.
• Filter-based load balancing—A filter allows you to control the types of traffic permitted
through Alteon. Filters are configured to allow, deny, or redirect traffic according to the IP
address, protocol, or Layer 4 port criteria. In filter-based load balancing, a filter is used to
redirect traffic to a real server group. If the group is configured with more than one real server
entry, redirected traffic is load balanced among the available real servers in the group.
Firewalls, WAP with RADIUS snooping, IDS, and WAN links use redirection filters to load balance
traffic.
• Content-based load balancing—Content-based load balancing uses Layer 7 application data
(such as URL, cookies, and Host Headers) to make intelligent load balancing decisions.
URL-based load balancing, browser-smart load balancing, and cookie-based preferential load
balancing are a few examples of content-based load balancing.
All of these issues can be addressed by adding an Alteon with SLB software, as shown in Figure 27 -
Web Hosting with SLB Solutions, page 169:
• Identical content must be available to each server in the same pool. Either of the following
methods can be used:
— Static applications and data are duplicated on each real server in the pool.
— Each real server in the pool has access to the same data through use of a shared file system
or back-end database server.
• Some services require that a series of client requests go to the same real server so that
session-specific state data can be retained between connections. Services of this nature include
Web search results, multi-page forms that the user fills in, or custom Web-based applications
typically created using cgi-bin scripts. Connections for these types of services must be
configured as persistent (see Persistence, page 583), or must use the minmisses, hash, phash
metrics (see Metrics for Real Server Groups, page 180).
• Clients and servers can be connected through the same Alteon port. Each port in use can be
configured to process client requests, server traffic, or both. You can enable or disable
processing on a port independently for each type of Layer 4 traffic:
— Layer 4 client processing—Ports that are configured to process client request traffic
provide address translation from the virtual server IP to the real server IP address.
— Layer 4 server processing—Ports that are configured to process server responses to
client requests provide address translation from the real server IP address to the virtual
server IP address. These ports require real servers to be connected to Alteon directly or
through a hub, router, or another switch.
Note: Ports configured for Layer 4 client/server processing can simultaneously provide Layer 2
switching and IP routing functions.
Alteon load balances traffic to a Web server pool and to a Domain Name System (DNS) server pool.
The port connected to the Web server pool (port 11) is instructed to perform both server and client
processing.
Note: For details about any of the menu commands described in this example, refer to the Alteon
Application Switch Operating System Command Reference.
Note: The IP interface and the real servers must belong to the same VLAN, if they are in the
same subnet. This example assumes that all ports and IP interfaces use default VLAN 1,
requiring no special VLAN configuration for the ports or IP interface.
3. Define each real server. For each real server, you must assign a real server number, specify its
actual IP address, and enable the real server.
4. Define a real server group and add the three real servers to the service group.
5. Define a virtual server. All client requests are addressed to a virtual server IP address on a
virtual server defined on Alteon. Clients acquire the virtual server IP address through normal
DNS resolution. In this example, HTTP is configured as the only service running on this virtual
server, and this service is associated with the real server group.
Note: This configuration is not limited to the HTTP Web service. Other TCP/IP services can be
configured in a similar fashion. For a list of other well-known services and ports, see Table 20. To
configure multiple services, see Multiple Services per Real Server, page 177.
6. Define the port settings. In this example, the following ports are being used on Alteon:
Examine the resulting information. If any settings are incorrect, make the appropriate changes.
8. Save your new configuration changes.
Note: You must apply any changes in order for them to take effect, and you must save
changes if you want them to remain in effect after reboot.
Check that all SLB parameters are working as expected. If necessary, make any appropriate
configuration changes and then check the information again.
• Client NAT behavior—For an IIS server running multiple logical servers, some applications
(such as HTTP) need the client IP addesses to be masked using Proxy-IP/Client-NAT and perform
persistency using other methods (cookies) or allow multiplexing to be used to improve the
server's efficiency, and other applications (such as FTP) require that the client IP addresses not
be masked to allow client-IP persistency. Using a logical server proxy mode, you can define
multiple real servers with desired rports (or in different groups), all with the same IP address,
and set each real server proxy mode to its desired value.
Notes
• DAM must be turned on or a proxy must be used to support multiple real servers with the same
IP address.
• Multiple real servers with the same IP address cannot share the same addports. Multiple real
servers with the same IP address with no addport configured must be associated to different
server groups.
Note: The service number specified on Alteon must match the service specified on the server.
Notes
• Load balancing some applications (such as FTP and RTSP) require special configuration. For
more information, see Load Balancing Special Services, page 279.
• For all applications without a well-known port, you can select Basic-SLB as the application.
When the current session count on your server falls to zero, you can shut down your server.
• If you have configured persistence on the real server, use the following command with the p
(persistent) option to suspend connection assignments (except for persistent http 1.0 sessions)
to the real server:
When the current session count on your server falls to zero and when persistent sessions for the
real server have aged out (refer to the persistence parameters you have set for this real server),
you can shut down your server. For more information, see Persistence, page 583.
• When maintenance is complete, use the following command to enable the real server:
The grace option is enabled only if the real server is in "failed" state and not in "disabled" state
(failed by health check). For example, consider HTTP service when the grace option is enabled. After
handling client requests for some time, the real server is marked failed by the health check, but the
remaining sessions to the real server are still kept to maintain previous connections from client to
the real server.
For details on health monitoring capabilities, see Health Checking, page 481.
2. Enable SLB
>>Main# /cfg/slb/on
Note: It is not mandatory for a buddy server group to be part of any virtual service.
Minimum Misses
The minmisses metric is optimized for cache redirection. It uses IP address information in the client
request to select a server. When selecting a server, Alteon calculates a value for each available real
server based on the relevant IP address information. The server with the highest value is assigned
the connection. This metric attempts to minimize the disruption of persistency when servers are
removed from service. This metric should be used only when persistence is required.
By default, the minmiss algorithm uses the upper 24 bits of the source IP address to calculate the
real server that the traffic should be sent to when the minmisses metric is selected. Alteon allows
the selection of all 32 bits of the source IP address to hash to the real server.
The source or destination IP address information used depends on the application:
• For application redirection, the client destination IP address is used. All requests for a specific IP
destination address are sent to the same server. This metric is particularly useful in caching
applications, helping to maximize successful cache hits. Best statistical load balancing is
achieved when the IP address destinations of load-balanced frames are spread across a broad
range of IP subnets.
• For SLB, the client source IP address and real server IP address are used. All requests from a
specific client are sent to the same server. This metric is useful for applications where client
information must be retained on the server between sessions. With this metric, server load
becomes most evenly balanced as the number of active clients with different source or
destination addresses increases.
To select all 32 bits of the source IP address, use the command, /cfg/slb/group x/mhash
32. This 32-bit hash is most useful in the wireless world.
The minmisses metric cannot be used for Firewall Load Balancing (FWLB), since the real server IP
addresses used in calculating the score for this metric are different on each side of the firewall.
Hash
The hash metric uses IP address information in the client request to select a server. The specific IP
address information used depends on the application:
• For application redirection, the client destination IP address is used. All requests for a specific IP
destination address are sent to the same server. This is particularly useful for maximizing
successful cache hits.
• For SLB, the client source IP address is used. All requests from a specific client are sent to the
same server. This option is useful for applications where client information must be retained
between sessions.
• For FWLB, both the source and destination IP addresses are used to ensure that the two
unidirectional flows of a given session are redirected to the same firewall.
When selecting a server, a mathematical hash of the relevant IP address information is used as an
index into the list of currently available servers. Any given IP address information will always have
the same hash result, providing natural persistence, as long as the server list is stable. However, if a
server is added to or leaves the set, then a different server might be assigned to a subsequent
session with the same IP address information even though the original server is still available. Open
connections are not cleared. The phash metric can be used to maintain stable server assignment.
For more information, see Persistent Hash, page 182.
Note: The hash metric provides more distributed load balancing than minmisses at any given
instant. It should be used if the statistical load balancing achieved using minmisses is not as optimal
as desired. If the load-balancing statistics with minmisses indicate that one server is processing
significantly more requests over time than other servers, consider using the phash metric.
Persistent Hash
The phash metric provides the best features of hash and minmisses metrics together. This metric
provides stable server assignments like the minmiss metric and even load distribution like the hash
metric.
When you select the phash metric for a group, a baseline hash is assumed based on the configured
real servers that are enabled for the group. If the server selected from this baseline hash is
unavailable, then the old hash metric is used to find an available server.
If all the servers are available, then phash operates exactly like hash. When a configured server
becomes unavailable, clients bound to operational servers will continue to be bound to the same
servers for future sessions and clients bound to unavailable servers are rehashed to an operational
server using the old hash metric.
When more servers go down with phash, you will not have an even load distribution as you would
with the standard hash metric.
Tunable Hash
By default, the hash metric uses the client's source IP address as the parameter for directing a client
request to a real server. In environments where multiple users are sharing the same proxy, resulting
in the same source IP address, a load-balancing hash on the source IP address directs all users to
the same real server.
Tunable hash allows the user to select the parameters (source IP, or source IP and source port) that
are used when hashing is chosen as the load-balancing metric.
Weighted Hash
Weighted hash allows real server weighting to be used in conjunction with the hash load balancing
algorithm. If the configured real server weight is greater than 1, the real server weight is taken into
account during the load-balancing calculation. There are no CLI commands to configure or change
the weighted hash state.
Least Connections
The default metric is leastconns. With the leastconns metric, the number of connections currently
open on each real server is measured in real time. The server with the fewest current connections is
considered to be the best choice for the next client connection request.
This option is the most self-regulating, with the fastest servers typically getting the most
connections over time.
Round-Robin
With the roundrobin metric, new connections are issued to each server in turn. This means that the
first real server in the group gets the first connection, the second real server gets the next
connection, followed by the third real server, and so on. When all the real servers in this group have
received at least one connection, the issuing process starts over with the first real server.
Response Time
The response metric uses the real server response time to assign sessions to servers. The response
time between the servers and Alteon is used as the weighting factor. Alteon monitors and records
the amount of time it takes for each real server to reply to a health check to adjust the real server
weights. The weights are adjusted so they are inversely proportional to a moving average of
response time. In such a scenario, a server with half the response time as another server receives a
weight twice as large.
Note: The effects of the response weighting apply directly to the real servers and are not
necessarily confined to the real server group. When response time-metered real servers are also
used in other real server groups that use the leastconns, roundrobin, or (weighted) hash metrics,
the response weights are applied on top of the metric method calculations for the affected real
servers. Since the response weight changes dynamically, this can produce fluctuations in traffic
distribution for the real server groups that use these metrics.
Bandwidth
The bandwidth metric uses real server octet counts to assign sessions to a server. Alteon monitors
the number of octets sent between the server and Alteon. The real server weights are then adjusted
so they are inversely proportional to the number of octets that the real server processes during the
last interval.
Servers that process more octets are considered to have less available bandwidth than servers that
have processed fewer octets. For example, the server that processes half the amount of octets over
the last interval receives twice the weight of the other servers. The higher the bandwidth used, the
smaller the weight assigned to the server. Based on this weighting, the subsequent requests go to
the server with the highest amount of free bandwidth. These weights are assigned.
The bandwidth metric requires identical servers with identical connections.
Note: The effects of the bandwidth weighting apply directly to the real servers and are not
necessarily confined to the real server group. When bandwidth-metered real servers are also used in
other real server groups that use the leastconns, roundrobin, or (weighted) hash metrics, the
bandwidth weights are applied on top of the metric method calculations for the affected real servers.
Since the bandwidth weight changes dynamically, this can produce fluctuations in traffic distribution
for the real server groups that use the above metrics.
Example
A group has 10 real servers, the down threshold is 3, and the restore threshold is 5.
• As long as there are more than three real servers active, the group is up.
• If any of the group’s real servers fail and the number of active servers reaches three, the group’s
status changes to down.
• If the group is down, if the number of active real servers only goes up to four, the status
remains down.
• When the number of active real servers is five or more, the group status changes to up.
These values are set using the /cfg/slb/group/minthrsh and /cfg/slb/group/maxthrsh
commands. For more information, see the Alteon Application Switch Operating System Command
Reference.
To set weights
The effects of the bandwidth weighting apply directly to the real servers and are not necessarily
confined to the real server group. When bandwidth-metered real servers are also used in other real
server groups that use the leastconns or roundrobin metrics, the bandwidth weights are applied on
top of the leastconns or roundrobin calculations for the affected real servers. Since the bandwidth
weight changes dynamically, this can produce fluctuations in traffic distribution for the real server
groups that use the leastconns or roundrobin metrics.
For more information on configuring SNMP health checks, see SNMP Health Check, page 488.
This example changes the time-out period of all connections on the designated real server to 4
minutes.
Values average from approximately 500 HTTP connections for slower servers to 1500 for quicker,
multiprocessor servers. The appropriate value also depends on the duration of each session and how
much CPU capacity is occupied by processing each session. Connections that use many Java or CGI
scripts for forms or searches require more server resources and thus a lower maxcon limit. You may
want to use a performance benchmark tool to determine how many connections your real servers
can handle.
When a server reaches its maxcon limit, Alteon no longer sends new connections to the server.
When the server drops back below the maxcon limit, new sessions are again allowed.
You can also set the max connections mode to physical (default) or logical. Real servers with the
same IP address must be set to the same maxcon connection mode.
• Real servers with the same IP address set to maximum connection mode physical must all have
the same maxcon value. The maxcon value is the maximum number of connections that the real
servers both support.
• Real servers with the same IP address set to maximum connection mode logical can each have
different maxcon values. The maxcon value is the maximum number of connections that each
logical real server supports individually.
>> # apply
>> # save
Backup/Overflow Servers
A real server can back up other real servers and can handle overflow traffic when the maximum
connection limit is reached. Each backup real server must be assigned a real server number and real
server IP address. It must then be enabled. Finally, the backup server must be assigned to each real
server that it will back up.
Example Real server groups using another real server group for
backup/overflow
Example Define Real Server 4 as a backup only server for Real Servers 1 and 2
Example Real server groups using another real server group for backup
Backup Preemption
Alteon supports control preemption of backup when a primary server becomes active.
By default, preempt is enabled. When the primary server becomes active, it displaces the backup
server and takes control. When preempt is disabled, the backup server continues processing
requests sent by Alteon even if the primary server becomes active. During this process, the primary
server is operationally disabled and becomes active only if the backup server goes down.
In the following example, Real Server 4 is configured as backup for Real Server 1, and preemption is
disabled in Real Server 1:
Example Enable slow start for Real Server Group 1 with a setting of 10 seconds
Option Description
VMA with source port: Source IP and source port are used to determine the
processor.
>> /cfg/slb/adv/vmasport
VMA with destination IP: Source IP and destination IP are used to determine the
processor. Both options can be enabled together, where
>> /cfg/slb/adv/vmadip
source IP, source port, and destination IP are used to
determine the processor.
Note: Radware recommends not changing VMA option while Alteon is in operation, as that may
result in temporary disconnection of clients.
The maintenance mode command /maint/debug/vmasp can be used to find the processor for any
combination of source IP, source port (if VMA with source port is enabled), and destination IP (if VMA
with destination IP is enabled).
Miscellaneous Debug
When VMA with destination IP is enabled, the following message displays:
When client NAT is enabled for a virtual service, you can disable NAT or specify a different proxy IP
address for any real server connected to that service. For more information, see Proxy IP Address
for Real Servers, page 194.
Additional NAT capabilities on virtual services include:
• Client IP persistency in selecting a proxy IP address—The same proxy IP address is used to
redirect all connections from a specific client using the same proxy IP address. Available when a
proxy IP subnet or network class is configured per virtual service or real server.
• Host Preservation—Preserves the host bits of an IP address, and translates only the network
prefix bits of the IP address. This is useful when the host number is used to identify users
uniquely. For more information, see Host Preservation, page 192.
Note: Enable proxy processing on the client ports to perform client NAT on a virtual service.
Notes
• WAN Link Load Balancing (see WAN Link Load Balancing, page 631) requires port-based proxy
IP addresses.
• Use an egress port or a VLAN-based proxy IP address for Web Cache Redirection (WCR) filtering.
You can configure up to 1024 port or VLAN-based proxy IP addresses (IPv4 or IPv6) per Alteon, and
up to 32 per single port or VLAN interface.
The default value for the virtual service client NAT capability (Proxy IP Mode) is ingress, so no
special configuration is required on the virtual service in this case. To use egress port-based
proxy IPs:
>> Virtual Server 1 80 http Service # pip/mode (Select egress port or VLAN-based
proxy IP mode)
Current pip mode: ingress
Enter new pip mode
[disable|ingress|egress|address|nwclss]: egress
Host Preservation
You can choose to translate only the network prefix portion of the client IP address, and to preserve
the host portion.
For example, if the proxy IP address is set to 20.12.32.0/255.255.255.0, client IP 133.14.15.29 is
translated to 20.12.32.29, client IP 145.11.23.67 is translated to 20.12.32.67, and so on.
This capability requires configuring a proxy IP subnet for the virtual service.
>> Virtual Server 1 80 http Service # pip/mode (Select PIP Mode Address/Subnet)
Current pip mode: ingress
Enter new pip mode
[disable|ingress|egress|address|nwclss]: address
>> Proxy IP# addr (Define proxy IP address)
Current PIP addresses:
v4 none
v6 none
persist disable
Enter new IPv4 PIP address or none []: 2.2.2.35
Enter new IPv4 PIP mask [255.255.255.255]:
>> Virtual Server 1 80 http Service # pip/mode (Select PIP Mode Address/Subnet)
Current pip mode: ingress
Enter new pip mode
[disable|ingress|egress|address|nwclss]: address
>> Proxy IP# addr (Define proxy IP subnet)
Current PIP addresses:
v4 none
v6 none
persist disable
Enter new IPv4 PIP address or none []: 2.2.2.0
Enter new IPv4 PIP mask [255.255.255.255]: (Available PIP addresses are
255.255.255.252 2.2.2.1-2.2.2.5)
Enter new IPv6 PIP address or none []:
Enter new IPv6 PIP prefix [128]:
Enter PIP persistency (Set PIP persistency for the client
[disable|client|host][disable]: client IP address)
Notes
• Real server proxy IP address configuration is ignored if the client NAT is disabled at the level of
the virtual service.
• Real server-level proxy IP address configuration is ignored for traffic that arrives at the real
server via a redirect filter. Instead, NAT is performed using proxy IP/NAT addresses defined at
filter level.
Mapping Ports
For security, Alteon lets you hide the identity of a port by mapping a virtual server port to a different
real server port. This section includes the following topics:
• Mapping a Virtual Server Port to a Real Server Port, page 195
• Mapping a Virtual Server Port to Multiple Real Server Ports, page 195
• Load-Balancing Metric, page 196
• Configuring Multiple Service Ports, page 197
Note: For each real server, you can only configure one service with multiple real ports.
Figure 31 - Basic Virtual Port-to-Real Port Mapping Configuration, page 195 illustrates an example
virtual port-to-real port mapping configuration:
Table 23 - Basic Virtual Port-to-Real Port Mapping Configuration Example, page 196 further
illustrates this example:
In the example, four real servers are used to support a single service (HTTP). Clients access this
service through a virtual server with IP address 192.168.2.100 on virtual port 80. Since each real
server uses two ports (8001 and 8002) for HTTP services, the logical real servers are:
• 192.168.2.1/8001
• 192.168.2.1/8002
• 192.168.2.2/8001
• 192.168.2.2/8002
• 192.168.2.3/8001
• 192.168.2.3/8002
• 192.168.2.4/8001
• 192.168.2.4/8002
Load-Balancing Metric
For each service, a real server is selected using the configured load-balancing metric (hash,
leastconns, minmisses, or roundrobin). To ensure even distribution, once an available server is
selected, Alteon uses the roundrobin metric to choose a real port to receive the incoming
connection.
If the algorithm is leastconns, Alteon sends the incoming connections to the logical real server (real
server IP address/port combination) with the least number of connections.
The /cfg/slb/virt command defines the real server TCP or UDP port assigned to a service. By
default, this is the same as the virtual port (service virtual port). If rport is configured to be different
from the virtual port defined in /cfg/slb/virt <virtual server number> / service
<virtual port>, Alteon maps the virtual port to the real port.
Note: To use the single virtual port to multiple rports feature, set this real server port option to 0.
However, you cannot configure multiple services with multiple rports in the same server if the
multiple rport feature is enabled.
>> # /cfg/slb/group 1
>> Real server Group 1# add 1
>> Real server Group 1# add 2
>> Real server Group 1# add 3
>> Real server Group 1# add 4
DSR requires that the server be set up to receive frames that have a destination IP address that is
equal to the virtual server IP address.
To set up DSR
Because in this configuration delayed binding (dbind) is enabled, you must force the reply traffic
from the server to go back through Alteon for correct session conversion. This is performed through
routing and not proxy IP (PIP), which forces the traffic to return though Alteon without making
changes on the server.
In this configuration, everything works properly on the server side. The server receives packets with
the client's source MAC address, and because it has a different IP range than the client, the server
correctly returns the traffic to the client. However, the packets fail to reach the client because both
Alteon and the Layer 2 switch are located on the same broadcast domain. This results in Alteon
forwarding packets from the client on a different port on the Layer 2 switch, with the MAC address
acting like a floating address, meaning that first the Layer 2 switch reads the client MAC address on
the client's physical port, and then it reads it on the Alteon physical port.
When enabling source MAC substitution, the packets sent from an Alteon only use Alteon's MAC
address, so the client MAC address "remains" on the client port of the switch.
/cfg/l2/stg 1/off
/cfg/l3/if 1/addr 10.1.1.1/mask 255.255.255.0/en
/cfg/l3/if 2/addr 192.168.1.1/mask 255.255.255.0/en
/cfg/slb/on
/cfg/slb/adv/direct en
/cfg/slb/real 1/rip 192.168.1.101/en/submac en
/cfg/slb/real 2/rip 192.168.1.102/en/submac en
/cfg/slb/group 1/add 1/add 2
/cfg/slb/virt 1/vip 10.1.1.100/en
/cfg/slb/virt 1/service 80/group 1
/cfg/slb/port 1/client en
/cfg/slb/port 1/server en
When DAM (/cfg/slb/adv/direct) is enabled, any client can communicate with any real server's
load-balanced service. Also, any number of virtual services can be configured to load balance a real
service.
With DAM, traffic that is sent directly to real server IP addresses (instead of the virtual server IP
address) is excluded from load-balancing decisions. The same clients may also communicate to the
virtual server IP address for load-balanced requests.
DAM is necessary for applications such as:
• Direct access to real servers for management or administration.
• One real server serving multiple virtual server IP (VIP) addresses.
• Content-intelligent load balancing, which requires traffic to go to specific real servers based on
the inspection of HTTP headers, content identifiers such as URLs and cookies, and the parsing of
content requests.
For more information see Content-Intelligent Server Load Balancing, page 219.
When DAM is enabled, port mapping and default gateway load balancing is supported only when
filtering is enabled, a proxy IP address is configured, or URL parsing is enabled on any port.
Example
You have enabled direct access mode on Alteon so that it can support content-intelligent load
balancing applications such as those described in Content-Intelligent Server Load Balancing,
page 219.
However, you also want to load balance a stateless protocol such as UDP, which by its nature cannot
be recorded in a session entry in the session table.
To block use of DAM for the UDP protocol (service port 9200)
Notes
• The /cfg/slb/virt <x> /service <y> /direct command requires that DAM be enabled
globally on Alteon. If DAM is not enabled globally on Alteon, the direct disable command
has no effect. When DAM is enabled on Alteon and disabled on a virtual server/virtual port pair,
direct access to other real servers (those servers that are not servicing a virtual server/virtual
port pair with direct access mode disabled) is still allowed.
• DAM cannot be disabled for FTP and RTSP services.
Port mapping is supported with DAM when filtering is enabled, a proxy IP address is configured, or
URL parsing is enabled on any port.
For more information on how to map a virtual server port to a real server port, see Mapping Ports,
page 194.
Note: Clients on the management network do not have access to SLB services and cannot access
the virtual services being load balanced.
Delayed Binding
Delayed binding can be used in several scenarios, for example Layer 7 matching, for which you need
to accumulate information about the client connection on which a load-balancing decision is
performed.
Delayed binding consists of the following statuses:
• Enabled— Performs SYN SYN denial-of-service Protection and enables some Alteon Layer 7
capabilities and SYN protection.
• Disabled— No delayed binding is performed.
• Force Proxy—Uses the Application Service Engine and enables TCP Optimization.
Using delayed binding, Alteon intercepts the client SYN request before it reaches the server. Alteon
responds to the client with a SYN ACK that contains embedded client information. Alteon does not
allocate a session until a valid SYN ACK is received from the client or the three-way handshake is
complete.
After Alteon receives a valid ACK or DATA REQ from the client, Alteon sends a SYN request to the
server on behalf of the client, waits for the server to respond with a SYN ACK, and then forwards the
clients DATA REQ to the server. This means that Alteon delays binding the client session to the
server until the proper handshakes are complete.
As a result, two independent TCP connections span a session: one from the client to Alteon, and the
second from Alteon to the selected server. Alteon temporarily terminates each TCP connection until
content has been received, preventing the server from being inundated with SYN requests.
Note: Delayed binding is enabled when content-intelligent load balancing is used. However, if you
are not parsing content, you must explicitly enable delayed binding if desired.
Note: Enable delayed binding without configuring any HTTP SLB processing or persistent binding
types.
To configure delayed binding for cache redirection, see Delayed Binding for Cache Redirection,
page 461.
this mode, the Application Service Engine will perform TCP optimizations without SYN attack
protection (which is performed when the delayed binding mode is set to enabled), function as a full
TCP proxy, reorder TCP packets, and so on.
The Application Service Engine can work in both Alteon delayed binding modes. In enabled delayed
binding mode, the Application Service Engine only provides SYN attack protection. In force proxy
mode, it only provides TCP optimizations.
Note: Persistent timeout must be greater than the virtual service and real server timeout.
This is useful when sessions need to be kept alive after their real server configured timeout expires.
An FTP session could be kept alive after its server defined timeout period, for example.
3. Save configuration.
Note: Since IPv6 does not allow intermediary routers or switches to fragment packets, internal
translation of the maximum IPv4 packet (MTU of 1500) cannot be translated without fragmenting.
Therefore, all IPv4 real servers must use IPv6 SLB to be configured with a maximum MTU less than
or equal to 1480.
For example, in the Windows 2003 environment, run REGEDIT to add a new parameter to the
registry in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
Tcpip\Parameters\Interfaces\xx (where xx is the correct interface for the configured IP
address), with the keyword MTU, using REG_DWORD with a decimal value of 1480.
PIP addresses can be in either IPv4 or IPv6 format. Ports and VLANs can be assigned either one type
or both. The appropriate PIP is used in load-balancing operations based on the IP version of the
incoming packet.
This procedure references Figure 37 - IPv6 to IPv4 Layer 4 SLB Example, page 209.
1. Configure the IPv6 network interface.
7. Enable SLB.
9. Configure client and server processing on the client and server ports.
This procedure references Figure 38 - IPv6 to IPv6 Layer 4 SLB Example, page 212.
1. Configure the IPv6 network interface.
>> # /cfg/slb/nwclss
2. At the prompt, enter the network class ID you want to configure. The Network Class menu
displays.
3. To define the network class name for that ID, enter name. At the prompt, enter the name you
want to define.
4. To set a network element for the network class, enter network. At the prompt, enter the
network element ID you want to set. The Network Element menu displays.
5. Enter net to define the network element. At the prompt, do one of the following:
— Enter range to define a range of IP addresses, and the network match type.
— Enter subnet to define an IP address, a subnet mask, and the network match type.
For a description of all of the /cfg/slb/nwclss commands, refer to the Alteon Application Switch
Operating System Command Reference.
3. Define virtual servers for internal and external customers, and assign the network classes you
defined for each virtual server accordingly. Define an HTTP service for each of the virtual
servers.
Note: For a list of well-known ports identified by Alteon, see Supported Services and Applications,
page 175.
To configure Alteon for HTTP load balancing on its well-known port (80)
Access the virtual server, and set the HTTP virtual service.
To configure Alteon for HTTPS load balancing on its well-known port (443)
Access the virtual server, and set the HTTPS virtual service.
To configure Alteon for HTTPS load balancing on port 444 (non-standard port)
Access the virtual server, and set the HTTP virtual service.
Notes
• Alteon supports Layer 7 content switching using an additional legacy configuration model that is
based on Layer 7 strings. For related examples based on using Layer 7 strings see Appendix B -
Content-Intelligent Server Load Balancing Not Using Layer 7 Content Switching Rules, page 809.
• To support IP fragment traffic when Layer 7 content switching is defined based on strings, use
the forceproxy command under /cfg/slb/virt/service/dbind to force traffic through the
Application Services Engine.
For more information, see /cfg/slb/virt<server number>/service <virtual port or
application name>/dbind/forceproxy option in the Alteon Application Switch Operating
System Command Reference.
Note: Alteon performs HTTP Layer 7 content switching before applying any modifications and is
based on the original requests.
The following sample use cases illustrate the feature range of Layer 7 content switching:
• URL-Based Server Load Balancing, page 220
• Virtual Hosting, page 226
• Cookie-Based Preferential Load Balancing, page 227
• Browser-Smart Load Balancing, page 231
• XML/SOAP-Based Server Load Balancing, page 234
• URL Hashing for Server Load Balancing, page 236
— For an HTTP class to match a path that includes "images", perform the same procedure and
specify "images" in the path parameter.
— For an HTTP class to match a path that includes "secure", perform the same procedure and
specify "secure" in the path parameter.
3. Create two additional server groups containing the real servers that only serve "cgi" (Real
Servers 1 and 2), and the real servers that only serve "images" (Real Servers 3 and 4), and
assign health checks to the groups.
4. Create Layer 7 content switching rules on the HTTP virtual service, including matching and traffic
redirection.
— The following rule defines matching the "cgi" class and redirecting traffic to the group of Real
Servers 1 and 2 for load balancing:
— Define a similar content switching rule to match the "image" class, and redirect traffic to the
group of Real Servers 3 and 4.
Tip: Because the content switching rule ID serves as rule matching priority, Radware recommends
that you leave a gap between rule numbers that you create so you can easily place future rules
within the current hierarchy. For example, create rules 1, 5, and 10 in the event that new rule 3
should be placed between rules 1 and 5, or new rule 7 should be placed between rules 5 and 10. If
you need to move a rule to a different ID, use the copy command. This creates a copy of the rule
from within the command that was used with a new ID, after which you can delete the original rule
ID.
— The following rule defines matching the "secure" class and redirecting traffic to a secure
site:
Note: The redirection location must consist of a full URL (including protocol, hostname, and path).
The optional tokens enable dynamic copying of URL parts from the request to the redirect location,
as a result preserving original client requests.
Virtual Hosting
Alteon enables individuals and companies to have a presence on the Internet in the form of a
dedicated Web site address. For example, you can have a "www.site-a.com" and "www.site-b.com"
instead of "www.hostsite.com/site-a" and "www.hostsite.com/site-b."
Service providers, on the other hand, do not want to deplete the pool of unique IP addresses by
dedicating an individual IP address for each home page they host. By supporting an extension in
HTTP 1.1 to include the host header, Alteon enables service providers to create a single virtual
server IP address to host multiple Web sites per customer, each with their own hostname.
The following list provides more detail on virtual hosting with configuration information:
• An HTTP/1.0 request sent to an origin server (not a proxy server) is a partial URL instead of a
full URL.
The following is an example of the request that the origin server receives:
GET /products/Alteon/ HTTP/1.0
User-agent: Mozilla/3.0
Accept: text/html, image/gif, image/jpeg
The GET request does not include the hostname. From the TCP/IP headers, the origin server
recognizes the hostname, port number, and protocol of the request.
• With the extension to HTTP/1.1 to include the HTTP Host: header, the above request to retrieve
the URL www.radware.com/products/Alteon would look like this:
GET /products/Alteon/ HTTP/1.1
Host: www.radware.com
User-agent: Mozilla/3.0
Accept: text/html, image/gif, image/jpeg
The Host: header carries the hostname used to generate the IP address of the site.
• Based on the Host: header, Alteon forwards the request to servers representing different
customer Web sites.
• The network administrator needs to define a domain name as part of the 128 supported URL
strings.
Note: It is also possible to provide virtual hosting for SSL encrypted sites (HTTPS), using the SSL
protocol Server Name Indication (SNI) extension.
— If the host header is "www.company-a.com," Alteon directs requests to the server group
containing one of the Servers 1 through 4.
— If the host header is "www.company-b.com," Alteon directs requests to the server group
containing one of the Servers 5 through 8.
Cookie-based preferential services enables, among others, the following supported use cases:
• Redirect higher priority users to a larger server or server group.
• Identify a user group and redirect them to a particular server group.
• Serve content based on user identity.
• Prioritize access to scarce resources on a Web site.
• Provide better services to repeat customers, based on access count.
Clients that receive preferential service can be distinguished from other users by one of the
following methods:
• Individual User—A specific individual user can be distinguished by IP address, login
authentication, or permanent HTTP cookie.
• User Communities—A set of users, such as "Premium Users" for service providers who pay
higher membership fees than "Normal Users", can be identified by source address range, login
authentication, or permanent HTTP cookie.
• Applications—Users can be identified by the specific application they are using. For example,
priority can be given to HTTPS traffic that is performing credit card transactions versus HTTP
browsing traffic.
• Content—Users can be identified by the specific content they are accessing.
Based on one or more of these criteria you can load balance requests to different server groups.
For example, to configure the cookie name session-id with the value gold:
3. Repeat step 2 to define HTTP content classes to match the values silver and bronze.
4. Define real server groups to serve each client group according to their cookie value.
For example, Gold clients are served by Real Servers 1 through 4 (Group 1), Silver clients are
served by Real Servers 5 through 8 (Group 2), Bronze clients are served by Real server 9
through 10 (Group 3).
5. Define Layer 7 content switching rules in the HTTP virtual service to match each cookie value
and redirect to the respective server group:
6. Because a session cookie does not exist in the first request of an HTTP session, a default server
group is needed to assign cookies to a None cookie HTTP request. Create a server group
containing designated servers for example servers 1 through 10, and associate it to the HTTP
virtual service as the fallback group.
— Request 5 comes in with a "Titanium" cookie; it is load balanced between servers in Group
15 (Real Servers 1 through 10), and because it does not contain an exact cookie match, it
uses the fallback action.
Regular expressions (regex) can be used to match multiple browser user agents with a single
value. Additional desktop or laptop browser user agents can be added to this class.
3. Configure Class2 to match mobile browsers user-agent header values using the same procedure
as Class1 in step 2.
4. Configure Class3 to match URL my-site.com and class1 (desktop-browsers) by using the logical
expression option in the Class menu:
>> Hostname 1# ..
5. Configure Class4 to match URL my-site.com and Class2 (mobile-browsers) using the procedure
in step 4.
6. Configure Class5 matched with URL mobile.my-site.com using the same procedure in the
URL-based content load balancing example (URL Hashing for Server Load Balancing, page 236).
7. Configure an HTTP Layer7 content switching rule in the HTTP virtual service to match Class3
(with URL my-site.com and desktop-browsers), and perform load balancing using Server
Group 1.
8. Configure an HTTP Layer7 content switching rule in the HTTP virtual service to match Class4
(with URL my-site.com and mobile-browsers), and perform HTTP redirection to
http://mobile.my-site.com.
9. Configure an HTTP Layer7 content switching rule in the HTTP virtual service to match Class5
(with URL mobile.my-site.com), and perform load balancing using Server Group2.
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body xmlns:m="http://www.example.org/stock">
<m:GetStockPrice StockEx=NASDAQ>
<m:StockName>IBM</m:StockName>
</m:GetStockPrice>
</soap:Body>
</soap:Envelope>
In this message, Alteon performs content switching based on a tag attribute such as the tag
GetStockPrice with the attribute StockEx, which has the value NASDAQ. Alternatively, Alteon can
perform content switching based on a tag value like the tag StockName with the value IBM.
2. Configure the Layer 7 content classes to match the XML tags values you need to load balance by.
For example, configuring the XML tag StockName from Example XML/SOAP-Based Message,
page 234:
Note: To reference a tag attribute, use the @ sign in the tag path before the tag attribute
name.
3. Configure additional Layer 7 content classes with different match values (for example Microsoft,
Goggle, and so on). You can also include multiple match values in each class (for example, IBM
or HP).
4. Configure server groups with the real servers that will serve each of the XML tag values, and
assign health checks to them.
5. Configure a Layer 7 content rule in the HTTP virtual service, using the defined XML-based
content classes and groups. For more information on how to configure content switching rules,
see URL-Based Server Load Balancing, page 220.
>> # /cfg/slb/virt 1
>> Virtual Server 1 # service 80
>> Virtual Server 1 http Service # http/httpslb urlhash
Enter new hash length [1-255]: 25
Hashing is based on the URL, including the HTTP Host: header (if present), up to a maximum of
255 bytes.
3. Set the metric for the real server group to minmisses or hash.
HTTP Normalization
Alteon normalizes characters in the HTTP strings that are encoded to real characters and performs
URL path traversal reversals before performing rule matching for HTTP Layer 7 content switching
and HTTP modifications. After matching the content, it is sent back to the real servers in its original
format.
You can enable or disable HTTP normalization via the HTTP Virtual Service menu. For more
information, see the Alteon Application Switch Operating System Command Reference.
Note: To enable X-Forwarded-For, you need to either set delayed binding to full proxy mode and
configure a PIP or enable DAM.
3. On the virtual server attached to the real servers, enable the X-Forwarded-For header:
>> # apply
>> # save
3. Enable or disable HTTP redirection, and then enter a new error code and a new error reason.
Example
To change server responses with error code 333 or 444 to a redirection to
www.alternatesite.com/trythis, use the following configuration:
Note: Using these commands results in path modifications only. The protocol (HTTP or HTTPS) and
the port (when specified) are not modified.
4. Enter the page name and path type to be used for the path change.
Example
To change links in server responses with paths starting with “abcd” to start with “aaabcd”, use the
following configuration:
When editing the existing configuration, the current configuration is displayed in square brackets [ ]
to facilitate the update. To clear the existing configuration of the page name and page type, enter
“None”.
Note: Using these commands results in path modifications only. The protocol (HTTP or HTTPS) and
the port (when specified) are not modified.
Example
In all URLs in the server responses that use www.site.com/test/, "test" should be removed from
the path. For example, when www.site.com/test/a/page.html appears in the response, it is
translated to www.site.com/a/page.html.
Client requests are modified the opposite way. For example, a request from the user to
www.site.com is modified and sent to the server as www.site.com/test. A request to
www.site.com/my.page is modified to www.site.com/test/my.page.
Example
To remove the text "this is a dummy line" from server responses, use the following configuration:
• File type—File type elements within the HTTP requests can be replaced. See Configuring HTTP
Modifications for the HTTP File Type, page 254.
• Status Line—Status line elements within the HTTP responses can be replaced. See Configuring
HTTP Modification for HTTP Status Line, page 255.
• URL—Within requests or responses, headers or entire message body can be replaced. See
Configuring HTTP Modification for URL Elements, page 256.
• Text—Any text elements can be replaced in HTTP headers or the entire message body. See
Configuring HTTP Modification for Text Elements, page 265.
Depending on the element type, these modifications are applied to the header only or both header
and body of the HTTP responses or requests.
About Rules
HTTP Modification rules are based on different types of HTTP elements. A rule can be added,
removed, or copied. The rules are evaluated according to their priority, with the lowest number
getting evaluated first. The maximum number of rules in a rule list is 128.
When defining a rule, you first set the rule ID, and then select the desired element on which the rule
will be based on. You cannot update a rule after setting its rule ID and element. To change the
element, the rule must be deleted and a new rule created.
Once a rule is matched and acted upon, the rest of the rules in the list are not evaluated for that
object. Rules are displayed in numerical order.
Tip: Radware recommends that you leave a gap between rule numbers that you create so you can
easily place future rules within the current hierarchy. For example, create rules 1, 5, and 10 in the
event that new rule 3 should be placed between rules 1 and 5, or new rule 7 should be placed
between rules 5 and 10.
If more than one rule match the same element, only the first modification will take place, that is,
you cannot match and modify an element that has already been modified.
Note: You have to enable the desired rule list and rule, and apply the changes for the modifications
to take effect.
For information on how to associate rules to a virtual service, see Associating HTTP Modification
Rules to a Service, page 267.
The following is a list of all HTTP elements and their supported actions:
Element Action
Header • Configuring the Replace Action for HTTP Headers, page 246
• To configure the remove action for HTTP Headers, page 247
• To configure the remove action for the HTTP text element, page 266
Note: The numbers and names in this procedure are examples only.
1. Access HTTP Modification rule list configuration via the Layer 7 menu, enter a rule list ID, and
enable the rule list.
>>Main# /cfg/slb/layer7/httpmod
>>Enter HTTP Modification rule-list id (alphanumeric): http-mod-list
>>HTTP Modification rule-list http-mod-list# ena
2. Enter rule, the rule ID number, and then enter the desired element type.
3. Enter action to access the Rule Action menu, and then enter replace to set the new rule
replace action.
Note: To replace only the content of the header field (the value) and not the header field
name, enter the same header field name in new header field prompt.
4. Enter directn to set the rule direction, and then enter the rule direction: request or response.
Example
To replace the value of the HTTP Header "My-Header" in all client requests, so that the first match of
the string "ABC" is replaced with "XYZ", use the following configuration:
The header value is only replaced if the original string is an exact match of the complete
replacement value. In this example, if the value is “ABCABC”, it is not replaced since it is not an
exact match.
Note: The numbers and names in this procedure are examples only.
1. Access HTTP Modification rule list configuration via the Layer 7 menu, enter a rule list ID, and
enable the rule list.
>>Main# /cfg/slb/layer7/httpmod
>>Enter HTTP Modification rule-list id (alphanumeric): http-mod-list
>>HTTP Modification rule-list http-mod-list# ena
2. Enter rule, the rule ID number, and then enter the desired element type.
3. Enter action to access the Rule Action menu, and then enter remove to set the new rule
remove action.
4. Enter directn to set the rule direction, and then enter the rule direction: request or response.
Example
To remove HTTP Header "Test-Header" from all server responses, use the following configuration:
If you leave the value empty, the complete header is removed, regardless of the value of the header.
If you set the cookie value, the cookie is only removed when both the key and value match.
Note: The numbers and names in this procedure are examples only.
1. Access HTTP Modification rule list configuration via the Layer 7 menu, enter a rule list ID, and
enable the rule list.
>>Main# /cfg/slb/layer7/httpmod
>>Enter HTTP Modification rule-list id (alphanumeric): http-mod-list
>>HTTP Modification rule-list http-mod-list# ena
2. Enter rule, the rule ID number, and then enter the desired element type.
3. Enter action to access the Rule Action menu, and then enter insert to set the new rule insert
action.
4. For the insert action, you can define a match criteria. If you define a match criteria, the insert is
performed only if the match is met.
Enter the element to be matched for insertion.
5. Based on the selected match element, enter the required parameters. For more information,
refer to the Alteon Application Switch Operating System Command Reference.
6. Enter directn to set the rule direction, and then enter the rule direction: request or response.
Example
To insert the HTTP Header "New-Header" with value of "VALUE" to all client requests for
www.site.com/path/new, use the following configuration:
Note: When both cookie-based pbind is used and HTTP modifications on the same cookie header
are defined, Alteon performs both. This may lead to various application behaviors and should be
done with caution.
Note: The numbers and names in this procedure are examples only.
1. Access HTTP Modification rule list configuration via the Layer 7 menu, enter a rule list ID, and
enable the rule list.
>>Main# /cfg/slb/layer7/httpmod
>>Enter HTTP Modification rule-list id (alphanumeric): http-mod-list
>>HTTP Modification rule-list http-mod-list# ena
2. Enter rule, the rule ID number, and then enter the desired element type.
3. Enter action to access the Rule Action menu, and then enter replace to set the new rule
replace action.
4. Enter directn to set the rule direction, and then enter the rule direction: request or response.
Example
To change the value of the cookie "User-Type" from "Gold" to "Premium" in all client requests, use
the following configuration:
Note: The numbers and names in this procedure are examples only.
1. Access HTTP Modification rule list configuration via the Layer 7 menu, enter a rule list ID, and
enable the rule list.
>>Main# /cfg/slb/layer7/httpmod
>>Enter HTTP Modification rule-list id (alphanumeric): http-mod-list
>>HTTP Modification rule-list http-mod-list# ena
2. Enter rule, the rule ID number, and then enter the desired element type.
3. Enter action to access the Rule Action menu, and then enter remove to set the new rule
remove action.
4. Enter directn to set the rule direction, and then enter the rule direction: request or response.
Example
To remove the Set-Cookie for a cookie named "Old-Cookie" from all server responses, use the
following configuration:
When you leave the cookie value empty, the cookie is removed.
If you set the cookie value, the cookie is removed only when both the key and value match.
Note: The numbers and names in this procedure are examples only.
1. Access HTTP Modification rule list configuration via the Layer 7 menu, enter a rule list ID, and
enable the rule list.
>>Main# /cfg/slb/layer7/httpmod
>>Enter HTTP Modification rule-list id (alphanumeric): http-mod-list
>>HTTP Modification rule-list http-mod-list# ena
2. Enter rule, the rule ID number, and then enter the desired element type.
3. Enter action to access the Rule Action menu, and then enter insert to set the new rule insert
action.
4. For the insert action, you can define a match criteria. If you define a match criteria, the insertion
is performed only if the match is met.
Enter the element to be matched for insertion. For more information, see the Alteon Application
Switch Operating System Command Reference.
Examples
A To insert the Set-Cookie for a cookie named "Device-ID" with the value "Alteon123" to all server
responses, use the following configuration:
B To insert the Set-Cookie for a cookie named "Device-ID" with the value "Alteon123" to server
responses where a cookie named "GSLB" with the value "On" exists, use the following
configuration:
The header is only inserted if the response contains the header Set-Cookie: GSLB=On.
Note: The numbers and names in this procedure are examples only.
1. Access HTTP Modification rule list configuration via the Layer 7 menu, enter a rule list ID, and
enable the rule list.
>>Main# /cfg/slb/layer7/httpmod
>>Enter HTTP Modification rule-list id (alphanumeric): http-mod-list
>>HTTP Modification rule-list http-mod-list# ena
2. Enter rule, the rule ID number, and then enter the desired element type.
3. Enter action to access the Rule Action menu, and then enter replace to set the new rule
replace action.
Example
To replace all requests for ".jpeg" files to use ".jpg", use the following configuration:
Note: The numbers and names in this procedure are examples only.
1. Access HTTP Modification rule list configuration via the Layer 7 menu, enter a rule list ID, and
enable the rule list.
>>Main# /cfg/slb/layer7/httpmod
>>Enter HTTP Modification rule-list id (alphanumeric): http-mod-list
>>HTTP Modification rule-list http-mod-list# ena
2. Enter rule, the rule ID number, and then enter the desired element type.
3. Enter action to access the Rule Action menu, and then enter replace to set the new rule
replace action.
Example
To replace responses with status code of 333 to 444 with text of "status is 444", use the following
configuration:
If you do not set the new status line, the previous text remains.
Note: The numbers and names in this procedure are examples only.
1. Access HTTP Modification rule list configuration via the Layer 7 menu, enter a rule list ID, and
enable the rule list.
2. Enter rule, the rule ID number, and then enter the desired element type.
3. Enter directn to set the rule direction, and then enter the desired rule direction:
— Request—Only client requests are inspected for modification.
— Response—Only server responses are inspected for modification.
— Bidirectional—The modification is done on server response and the reverse modification is
done on the subsequent client request. For example, you can remove the complete path
from the response so that the same path is added to the subsequent request.
By default, only headers are modified (body exclude). To modify both header and body, set to
body include.
5. Enter match to access the Match menu and define the match criteria.
Set the match parameters according to the configured rule direction: request or response. When
the direction is set to bidirectional, set the match parameters to match the server response.
You can set match criteria for the following:
— Protocol—HTTP or HTTPS. The default value is HTTP.
— Port—The port used in the URL. The default value is 0, implying a match for cases when the
port is not explicitly specified in the URL. This means the default port for the specified
protocol (80 for HTTP, 443 for HTTPS) is used. Another example is when the default port
appears explicitly in the URL.
When the port is 0 for both match and action, this implies that the port parameter is not
checked (the rule is matched regardless of the port that is used in the URL) and not
changed.
— Host
• Host Match Type can be set to Suffix, Prefix, Equal, Include or Any. Any implies that any
host will match.
• Host to Match indicates the value to be used for the match. This parameter is not
required when Match Type is set to Any.
For example: Host Match Type prefix and Host to Match www.a will match all hosts that
start with www.a, such as www.a.com, www.abc.com, and so on.
— Path
• Path Match Type can be set to Suffix, Prefix, Equal, Include or Any. This parameter is not
required when Match Type is set to Any. Any implies that any non-empty path will
match.
• Path to Match indicates the value to be used for the match.
This parameter is not required when the Match Type is set to Any.
For example: Path Match Type include, and Path to Match abc match any path that has abc
in it, such as /abc/, /a/abc, and so on.
— Page Name—Used for an exact match.
— Page Type—Used for an exact match.
Note: An AND operation is used between the configured match criteria. Therefore, only when
all the configured match criteria are met in the request (or response), the action is performed.
6. Enter action to access the Rule Action menu, and define the action criteria.
You can set actions for the following parameters:
— Protocol—HTTP or HTTPS. The default value is HTTP.
— Port—The port to be set in the URL. The default value is 0, which means:
• When the match port is not 0, the port is removed from the URL.
• When the port parameter is 0 for both match and action, the port in the URL remains
unchanged. That is, if it was explicitly specified it remains as it is, if it was not specified
it remains so.
— Host—The Host Action Type can be set to Insert, Replace, or Remove.
• Insert— Lets you insert additional text to the hostname, either before or after the
matched text.
• Replace—Lets you replace the matched text in the hostname with another text.
• Remove—Lets you remove the matched text from the hostname.
• None—No action is taken.
Replace and Remove are not allowed when the Host Match Type is set to Any.
When a host match is set, an action must be specified. To leave the same host, use action
replace with the same text string used in the match.
For example: Host Match Type prefix and Host to Match www.a match all hosts that start
with www.a. Using Host Action Insert After with Host to Insert bbb results in the following:
host www.a.com is modified to www.abbb.com. Host www.az.com is modified to
www.abbbz.com.
Note: The numbers and names in this procedure are examples only.
1. Configure the required real servers, group, virtual server and service. The service is HTTP or
HTTPS, according to the site. Associate an HTTP modification policy to achieve the HTTPS link
updates.
4. It is required to modify URLs in the body of the response, so set the body to include.
6. Set the required action. Path match was set, so an action also must be specified. In order not to
change the path, use replace with the same path string.
8. Apply and save. You can use cur to see the complete rule list configuration:
Note: The numbers and names in this procedure are examples only.
1. Configure the required real servers, group, virtual server and service. The service is HTTP or
HTTPS, according to the site. Associate an HTTP Modification Policy to achieve the HTTPS links.
4. It is required to modify URLs in the body of the response, so set the body to include.
6. Set the required action. Since a path match was set, an action also must be specified. To leave
the path unchanged, use replace with the same path string.
8. Apply and save. In addition, you can use cur to see the complete rule list configuration:
4. It is required to modify URLs in the body of the response, so set the body to include
8. Apply and save. In addition, you can use cur to see the complete rule list configuration:
Note: The current rule matches any link that includes any path at www.site2.com. To modify the
URL HTTP://www.site2.com itself (with no path), a different rule is required. The path match is set
to equal empty (leave the value empty), so that the rule list looks as follows:
Note: The numbers and names in this procedure are examples only.
1. Access HTTP Modification rule list configuration via the Layer 7 menu, enter a rule list ID, and
enable the rule list.
>>Main# /cfg/slb/layer7/httpmod
>>Enter HTTP Modification rule-list id (alphanumeric): http-mod-list
>>HTTP Modification rule-list http-mod-list# ena
2. Enter rule, the rule ID number, and then enter the desired element type.
3. Enter action to access the Rule Action menu, and then enter replace to set the new rule
replace action.
4. Enter directn to set the rule direction, and then enter the desired rule direction.
Example
To replace responses that include the text "Copyright 2013" to "All rights reserved", use the
following configuration:
Note: The numbers and names in this procedure are examples only.
1. Access HTTP Modification rule list configuration via the Layer 7 menu, enter a rule list ID, and
enable the rule list.
>>Main# /cfg/slb/layer7/httpmod
>>Enter HTTP Modification rule-list id (alphanumeric): http-mod-list
>>HTTP Modification rule-list http-mod-list# ena
2. Enter rule, the rule ID number, and then enter the desired element type.
3. Enter action to access the Rule Action menu, and then enter remove to set the new rule
remove action.
4. Enter directn to set the rule direction, and then enter the desired rule direction.
Example
To remove the text "test test test" wherever it appears in the response, use the following
configuration:
Content-Intelligent Caching
Web pages are composed of a series of objects. Many of these objects are static objects that are
used repeatedly from page to page. Alteon caching can recognize requests for such objects and
retrieve them directly from Alteon's local cache without fetching them from the Web server. This
relieves the server of dealing with repetitive requests for the same content and at the same time
accelerates objects delivery to the end-user.
Alteon caching support is compliant with RFC 2616 of HTTP 1.1. It respects relevant HTTP headers
(such as Cache-control, Expires, Authorization, Pragma, and so on) which are the Web Application
means of dictating which content is to be cached and when it should be refreshed.
Alteon caching has options to determine its cache behavior, both in terms of which content to cache,
and in terms of which content to serve to clients from cache. Caching support includes the option to
define per-URL caching behavior, cache expiration time, and includes an option to optimize a client
browser's caching to improve response time and Quality of Experience (QoE).
Alteon caching is based on Alteon's RAM to ensure fast retrieval of content and delivery to clients.
You can configure the amount of RAM dedicated for the caching Web object. However, the more
cache space you allocate, the fewer the number of concurrent connections that can be handled by
Alteon.
Caching occurs at the client side of the flow. This means that when a request comes, it is considered
higher priority for serving from cache before all other application services (for example, HTTP
modifications). On the other hand, when a server response arrives at the Application Services
Engine, it goes through all required treatments, such as compression and HTTP modification, before
being cached. Therefore the next serving of that response from cache also includes them.
Caching configuration includes a FastView policy and a cache URL exceptions rule list that is
optionally associated to that policy. FastView policies are, in turn, associated with an HTTP virtual
service.
This section describes the following procedures:
• Configuring the Caching Virtual Service, page 268
• Configuring the FastView Policy, page 269
Note: When indicating the virtual service, you can use either the virtual port number or a
name. In this example, instead of the HTTP, you can enter 80 for the standard HTTP port
number.
The FastView policy name you entered is now associated with virtual service HTTP.
3. Configure the FastView policy, as described in Configuring the FastView Policy, page 269.
Notes
• When the URL ends with an asterisk (*) it is interpreted as a wildcard, and causes the entire
objects “tree” under the specified URL to be invalidated. The wildcard is interpreted in a wide
sense; meaning anything that appears in URL after that point is removed including multiple page
instances differentiated by query parameters.
• If the URL includes a page name and/or page suffix and then an asterisk (for example,
http://mycompany.com/path/page.type*), only various instances of the specific page with
different query parameters (specified after the question mark sign) are removed.
Notes
• When the URL ends with an asterisk (*) it is interpreted as a wildcard, and causes the entire
objects “tree” under the specified URL to be invalidated. The wildcard is interpreted in a wide
sense; meaning anything that appears in URL after that point is removed including multiple page
instances differentiated by query parameters.
• If the URL includes a page name and/or page suffix and then an asterisk (for example,
http://mycompany.com/path/page.type*), only various instances of the specific page with
different query parameters (specified after the question mark sign) are removed.
For more information, see the section on the /oper/slb/cachpurg command in the Alteon
Application Switch Operating System Command Reference.
For details on defining additional caching policy parameters, see the section on the
/cfg/slb/accel/fastview/fastpol/caching menu in the Alteon Application Switch
Operating System Command Reference.
3. Globally enable FastView.
4. Set the HTTP virtual service to be used in the defined virtual server.
5. Enable DAM or configure proxy IP addresses and enable proxy on the client port.
For details on defining additional caching policy parameters, see the section on the
/cfg/slb/accel/fastview/fastpol/caching menu in the Alteon Application Switch
Operating System Command Reference.
3. Define a caching rule list.
5. Set the HTTP virtual service to used in the defined virtual server.
6. Enable DAM or configure proxy IP addresses and enable proxy on the client port.
Content-Intelligent Compression
HTTP compression is built into Web servers and Web clients to make better use of available
bandwidth, and provide faster perceivable transmission speeds between both, as less data is
actually transferred. HTTP data is compressed before it is sent from the server as follows:
• Compliant browsers announce what methods are supported to the server before requesting each
object. Commonly supported methods are the gzip and Deflate compression algorithms.
• Browsers that do not support compliant compression method download uncompressed data.
Alteon compression can ensure optimal application delivery and bandwidth savings through
compression of Web pages such as HTML and JavaScript in real-time before transmission on the
network. This is important especially for small remote offices and home office users where
bandwidth may be limited. This dynamic HTML compression accelerates traffic by reducing the
payload using an open compression standard (gzip and Deflate), providing a powerful performance
boost. The support of the industry-standard gzip algorithm (as well the Deflate algorithm) ensures
compatibility with virtually all popular Web browsers without requiring any special software
installation on the end-user computer.
Alteon HTTP compression includes options to control compression behavior. These include the ability
to define whether objects should be compressed for browser, content-type or URL specific behavior,
as well as a set of predefined exceptions of the default compression behavior based on known
browser limitations.
Compression configuration includes an compression policy and two types of compression rule lists
(URL exceptions and browser exceptions) that are optionally associated to the policy. Compression
policies are, in turn, associated with an HTTP virtual service.
This section describes the following procedures:
• Configuring the Compression Virtual Service, page 272
• Compression Policy, page 273
• Compression Exceptions Rule Lists, page 273
• Common Compression Policy Use Cases, page 274
Note: When indicating the virtual service, you can use either the virtual port number or a
name. In this example, instead of the HTTP, you can enter 80 for the standard HTTP port
number.
The compression policy name you entered is now associated with virtual service HTTP.
3. To configure the compression policy, see the section on the /cfg/slb/accel/compress menu
in the Alteon Application Switch Operating System Command Reference.
Compression Policy
The compression policy defines the compression behavior required for the virtual service. A single
compression policy can be associated to multiple virtual services if they share the same compression
configuration. Compression parameters include:
• Policy name
• Compression algorithm
• Compression level
• Minimum file size to be compressed
• Maximum file size to be compressed
• Compression URL exceptions rule list
• Compression browser exceptions rule list
• Predefined browser exceptions rule list
• Compression by real server
For details on configuring the compression policy parameters, see the section on the
/cfg/slb/accel/compress menu in the Alteon Application Switch Operating System Command
Reference.
Rules are ordered in the rule list according to their index number. Radware recommends putting
rules that are matched often at the top of the list to optimize performance. See the compression URL
rule list statistics per rule to determine which rules are matched more or less often.
The following are the types of compression rule lists you can associate with a compression policy:
• URL Exceptions Rule List—This is a list of compression exceptions rules based on an object’s
URL (file/folder). These rules are the primary filter for evaluating exceptions. Browser exception
and browser limitation rules are only evaluated after the URL exceptions.
For example, the following rules result in all files in images folder being compressed except for
image1.jpg:
rule1: /images/image1.jpg, do not compress
rule2: /images/, compress
• Browser Exceptions Rule List—This is a list of compression exception rules based on
user-agent (browser type) and/or content-type (file type). These rules skip the compression of
certain objects that create issues when uncompressed or that require too many resources with
little benefit (for example, PDFs and PPT files). Browser exception rules are evaluated after the
URL exception rules are evaluated, so they are more general than the URL exceptions.
For example, the following rules result in all files in images folder being compressed except for
image1.jpg:
rule1: /images/image1.jpg, do not compress
rule2: /images/,compress
• Predefined Browser Exceptions Rule List—This is a list of compression browser exception
rules that address known issues in commonly used browsers which cause them to mishandle
specific types of compressed content. The predefined browser limitation rule list cannot be
modified or deleted. In order to customize it, you should first copy the rule list to a new browser
exceptions rule list. This exception list is evaluated last, after the URL exception and browser
exception lists, and therefore can be overridden by both the user-defined browser exception rule
list and the URL rule list.
When there are both URL exception rule lists and browser exception rule lists associated with a
compression policy, compression occurs only if both rule lists result in no exceptions.
For details on defining additional compression policy parameters, see the section on the
/cfg/slb/accel/compress/comppol menu in the Alteon Application Switch Operating
System Command Reference.
3. Globally enable compression.
4. Set the HTTP virtual service to used in the defined virtual server.
5. Enable DAM or configure proxy IP addresses and enable proxy on the client port.
For details on defining additional compression policy parameters, see the section on the
/cfg/slb/accel/compress/comppol menu in the Alteon Application Switch Operating
System Command Reference.
3. Define a compression URL exception rule list.
5. Set the HTTP virtual service to used in the defined virtual server.
6. Enable DAM or configure proxy IP addresses and enable proxy on the client port.
For details on defining additional compression policy parameters, see the section on the
/cfg/slb/accel/compress/comppol menu in the Alteon Application Switch Operating
System Command Reference.
3. Define a compression browser exception rule list.
>> Compression Browser Rule-List mybrwslist# (Add a rule to the rule list)
>> Main# /cfg/slb/accel/compress/brwslist# ena (Enable the browser List)
5. Set the HTTP virtual service to used in the defined virtual server.
FastView Licensing
FastView licenses are not available for Alteon version 29.
Radware's FastView Advanced Web Performance Optimization solution is available as a standalone
solution. For more information, see www.radware.com/Solutions/Enterprise/ApplicationNetworking/
ApplicationAcceleration.aspx.
Note: You must configure the Proxy IP (PIP) addresses to be used as source IP addresses for the
server-side connections. Radware recommends using egress PIP, to ensure PIP is used only to the
required servers and service. When using ingress PIP, all traffic coming via the specified port uses
PIP, including traffic to other services.
Note: The session that is created for the IP service ages based on setting for real server timeout.
Requirements
You must select or enable the following:
• Load-balancing service port 69
• DAM
The following are not supported:
• PIP, because the server port is changed. PIP uses server port for allocating a pport.
• Multiple rports
To enable a session reset for a virtual server that is running the LDAP service
Figure 41 - LDAP Load Balancing, page 283 shows four LDAP servers load balancing LDAP queries:
>> # /cfg/slb/on
2. Configure the four real LDAP servers and their real IP addresses.
>> # /cfg/slb/real 20
>> Real server 20 # ena (Enable Real Server 20)
>> Real server 20 # rip 10.10.10.20 (Specify the IP address)
>> Real server 20 # layer7/ (Select the Layer 7 menu)
>> Real Server 20 Layer 7 Commands# ldapwr e (Enable LDAP read-write)
5. Set up the LDAP service for the virtual server, and add real server Group 1.
Note: You can configure both UDP and TCP DNS queries for the same virtual server IP address.
Pre-configuration Tasks
This procedure references Figure 42 - Layer 4 DNS Load Balancing, page 285.
>> # /cfg/slb/on
>> # /cfg/slb/real 20
>> Real server 20 # ena (Enable Real Server 20)
>> Real server 20 # rip 10.10.10.20 (Specify the IP address)
>> Real server 20 # /cfg/slb/real 21
>> Real server 21 # ena (Enable Real Server 21)
>> Real server 21 # rip 10.10.10.21 (Specify the IP address)
>> Real server 20 # /cfg/slb/real 22
>> Real server 22 # ena (Enable Real Server 22)
>> Real server 22 # rip 10.10.10.22 (Specify the IP address)
>> Real server 20 # /cfg/slb/real 26
>> Real server 26 # ena (Enable Real Server 26)
>> Real server 26 # rip 10.10.10.26 (Specify the IP address)
For more information on configuring health checks, see TCP and UDP-based DNS Health Checks,
page 488.
4. Define and enable the server ports and the client ports.
For more information, see Table 19 - Web Host Example: Port Usage, page 173. Some DNS
servers initiate upstream requests and must be configured both as a server and a client.
2. Set up the DNS service for the virtual server, and add Real Server Group 1.
3. Disable delayed binding. Delayed binding is not required because UDP does not process session
requests with a TCP three-way handshake.
2. Set up the DNS service for virtual server, and select Real Server Group 2.
3. As this is TCP-based load balancing, ensure that you enable TCP DNS queries.
>> Virtual Server 1 DNS Service # dnsslb ena (Enable DNS SLB)
>> Virtual Server 1 DNS Service # dnstype both (Support DNS queries of type DNS
only)
3. In addition to the TCP settings, for the virtual server, if using a TCP-based DNS server, enable
delayed binding (if using a UDP-based DNS server, do not enable delayed binding).
Note: When using the interactive menu the '\' is not inserted as in the regex format. The '\' is
used to cancel the '.' as a wildcard.
# /cfg/slb/layer7/slb/addstr DNSQ=A,AAAA,MX;TP=dns
# /cfg/slb/layer7/slb/addstr DNSQ=A,AAAA,MX,DNSKEY;TP=dnssec
ID SLB String
1 any, cont 1024
2 DNSQ=any;TP=dns;HN=[abcdefg]+\.com, cont 1024
3 DNSQ=any;TP=dns;HN=[hijklm]+\.com, cont 1024
4 DNSQ=any;TP=dns;HN=[nopqrst]+\.com, cont 1024
5 DNSQ=any;TP=dns;HN=[uvwxyz]+\.com, cont 1024
6 DNSQ=A,AAAA,MX;TP=dns, cont 1024
7 DNSQ=A,AAAA,MX,DNSKEY;TP=dnssec, cont 1024
Note: If you do not add a defined string (or add the defined string any) the server handles any
request.
Note: RTSP SLB cannot be set to None for the RTSP service 554.
Note: This feature is not applicable if the streaming media (multimedia) servers use the HTTP
protocol to tunnel RTSP traffic. To ensure that RTSP SLB works, ensure the streaming media server
is configured for the RTSP protocol.
>> # /cfg/slb/on
6. Create a virtual server for the RealNetworks servers. To configure a virtual server for Layer 4
load balancing of RTSP, select rtsp, or port 554, as a service for the virtual server.
7. Create a virtual server for the QuickTime servers. To configure a virtual server for Layer 4 load
balancing of RTSP, select rtsp, or port 554, as a service for the virtual server.
URL Hash
Use the URL hash metric to maximize client requests to hash to the same media server. The original
servers push the content to the cache servers ahead of time. For example, an ISP is hosting audio-
video files for GlobalNews on media servers 1, 2, 3, and 4. The domain name GlobalNews.com
associated with the virtual IP address 120.10.10.10 is configured for URL hash.
The first request for http://Globalnews.com/saleswebcast.rm hashes to media server 1. Subsequent
requests for http://Globalnews.com/saleswebcast.rm from other clients or from client 1 hashes to
the same Server 1. Similarly, another request for http://Globalnews.com/marketingwebcast.rm may
hash to media Server 2, provided saleswebcast and marketingwebcast media files are located in the
origin servers.
Typically, a set of related files (audio, video, and text) of a presentation are usually placed under the
same directory (called a container directory). Alteon URL hashing ensures that the entire container
is cached in a single cache by using the entire URL to compute the hash value and omitting the
extension (for example, .ram, .rm, .smil) occurring at the end of the URL.
String Matching
Use the string matching option to populate the RTSP servers with content-specific information. For
example, you have clients accessing audio-video files on Radware1 and clients accessing audio-
video files on Globalnews2. You can host the Globalnews1 media files on media Servers 5 and 6, and
host Globalnews2 media files on media Servers 7 and 8.
1. Before you start configuring RTSP load balancing, configure Alteon for standard server load
balancing, as described in Server Load Balancing Configuration Basics, page 171:
— Connect each Media server to Alteon.
— Configure the IP addresses on all devices connected to Alteon.
— Configure the IP interfaces on Alteon.
— Enable SLB (/cfg/slb/on)
— Enable client processing at the client port (/cfg/slb/port 1/client ena)
— Enable server processing at the Server Ports 2 and 7 (for example: /cfg/slb/port 2/
server ena)
— Enable Direct Access Mode (DAM)
— Disable proxy IP addressing
5. Create a virtual server for Group 1 media servers. Configure a virtual server and select rtsp, or
port 554, as a service for the virtual server.
6. Configure URL hash-based RTSP load balancing for Group 1 servers. URL hashing maintains
persistency by enabling the client to hash to the same media server.
7. Create another virtual server for Group 2 media servers. Configure a virtual server and select
rtsp, or port 554, as a service for the virtual server.
For easy configuration and identification, each defined string has an ID attached, as shown in
the following table:
ID SLB String
1 any, cont 1024
2 radware1.mov, cont 1024
3 radware2.mov, cont 1024
— Add the defined string IDs to the real servers as shown in Figure 45 - RTSP Load Balancing,
page 296.
The SSL policy name you entered is now associated with virtual service HTTPS.
3. To configure the SSL policy, see the section on the /cfg/slb/ssl/sslpol menu in the Alteon
Application Switch Operating System Command Reference.
The server certificate name you entered is now associated with virtual service 12345.
3. To configure to the server certificate, see the section on the /cfg/slb/ssl/certs/srvrcert
menu in the Alteon Application Switch Operating System Command Reference.
Notes
• You can associate only a single server certificate to a virtual service.
• When the virtual service is enabled and you associate an SSL policy with a virtual service
without a certificate and try to apply the changes with the apply command, you receive an error
message. The SSL offloading capabilities can be set only with both a server certificate and SSL
policy associated with a virtual service.
WAP supports most wireless networks and is supported by all operating systems, with the goal of
inter-operability. A WAP gateway translates Wireless Markup Language (WML) (which is a WAP
version of HTML) into HTML/HTTP so that requests for information can be serviced by traditional Web
servers.
To load balance WAP traffic among available parallel servers, Alteon must provide persistency so
that the clients can always go to the same WAP gateway to perform WAP operation.
Figure 46 - Load Balancing WAP Gateways, page 301 illustrates how the user is first authenticated
by the remote access server. In this example, the RADIUS servers are integrated with the WAP
gateways:
You can configure Alteon to select a WAP gateway for each client request based on one of the
following three methods:
• WAP SLB with RADIUS Static Session Entries, page 301
• WAP SLB with RADIUS Snooping, page 304
• WAP SLB with RADIUS/WAP Persistence, page 306
request from a client, the RADIUS server instructs Alteon to create a static session entry via the
Transparent Proxy Control Protocol (TPCP). TPCP is a proprietary protocol that is used to establish
communication between the RADIUS servers and Alteon. It is UDP-based and uses ports 3121,
1812, and 1645.
The RADIUS servers use TPCP to add or delete static session entries on Alteon. Typically, a regular
session entry is added or removed by Alteon itself. A static session entry, like a regular session
entry, contains information such as the client IP address, the client port number, real port number,
virtual (destination) IP address, and virtual (destination) port number.
A static session entry added via TPCP to Alteon does not age out. The entry is only deleted by
another TPCP Delete Session request. If the user adds session entries using the traditional server
load balancing methods, the entries will continue to age out.
Because TPCP is UDP-based, the Add/Delete Session requests may get lost during transmission. The
WAP gateway issues another Add Session request on detecting that it has lost a request. The WAP
gateway detects this situation when it receives WAP traffic that does not belong to that WAP
gateway. If a Delete Session request is lost, it is overwritten by another Add Session request.
— Enable UDP under the WAP services (ports 9200 to 9203) menu.
Note: If the application is not recognized by the port, set the application to basic-slb.
Note: The RADIUS service number specified on Alteon must match with the service specified
on the server.
>> # /cfg/slb/on
5. Enable the external notification from the WAP gateway to add and delete session requests if you
are using static session via TPCP.
— Enable UDP under the WAP services (ports 9200 to 9203) menu.
Note: The RADIUS service number specified on Alteon must match the service specified on the
server.
>> # /cfg/slb/on
5. Enable the external notification from WAP gateway to add and delete session requests if you are
using static session via TPCP.
7. Configure the following filter on Alteon to examine a RADIUS accounting packet. Set the basic
filter parameters
Note: Alteon supports Virtual Router Redundancy Protocol (VRRP) and stateful failover, using
both static session entries and RADIUS snooping. However, the active-active configuration with
stateful failover is not supported.
Note: The RADIUS accounting packet and the RADIUS accounting service must share the same
rport.
4. The framed IP address attribute is used to rebind the RADIUS session to a new server.
Alteon hashes on the framed IP address to select a real server for the RADIUS accounting
session. If the framed IP address is not found in the RADIUS accounting packet, then
persistence is not maintained for the RADIUS/WAP session. The load-balancing metric of the real
server group has to be hash for RADIUS/WAP Persistence
5. When the client begins to send WAP requests to the WAP gateways on ports 9200 through 9203,
a new session is allocated and a server is bound to the WAP session.
The RADIUS session and the WAP session are now both bound to the same server because both
sessions are using the same source IP address.
>> # /cfg/slb/on
Notes
• The RADIUS service number specified on Alteon must match with the service specified on the
server.
• If the application is not recognized by the port, set the application as basic-slb.
6. Configure the following filter to examine a RADIUS accounting packet. Set the basic filter
parameters.
8. Enable client and server ports and enable filtering on client ports.
The following summarizes the primary steps involved in configuring IDS load balancing:
1. Set up the IDS servers.
Determine if you want to setup the IDS servers in stealth mode (without IP addresses) or with
non-routable IP addresses. For more information about setting up IDS servers, see Setting Up
IDS Servers, page 311.
2. Create the IDS groups.
Create real server groups for the IDS servers. You may create multiple IDS groups to segregate
incoming traffic based on protocols.
— Choose the metric for the group as hash
— Choose the health check for the group: link, icmp, arp, or snmp
— Enable IDS on the group
— Select the type of traffic that is captured by the group by defining the IDS rport value.
Default: any
If multiple groups are configured for the same rport, then only one of the groups is used for
SLB.
3. Enable IDS on the incoming ports (both client and server ports).
Enabling IDS at the port level enables Alteon to make a copy of the frames ingressing the port
and forward the copy to the IDS server group.
4. Configure filter processing on the incoming ports with the IDS hash metric.
This allows a session entry to be created for frames ingressing the port. IDS load balancing
requires a session entry to be created in order to store the information regarding which IDS
server to send the request.
If the allow filter is configured to hash on both the client and server IP address, then this
ensures that both client and server traffic belonging to the same session is sent to the same IDS
server. For more information, see Example 2: Load Balancing to Multiple IDS Groups, page 315.
If the port is configured for client processing only, then Alteon hashes on the source IP address
only.
• Example 3: Load Balancing IDS Servers Across Multiple Alteons, page 318—Two Alteons in a
high availability configuration are connected to each other via a trunked interswitch link that is
associated with all VLANs configured on both Alteons. Each Alteon is connected to IDS servers
that are each on different VLANs but belong to the same IDS group. A feature to disable source
MAC address learning across the interswitch link allows traffic to reach real servers even when
one Alteon goes into the standby state.
Figure 47: Server Load Balancing and IDS Load Balancing to a Single Group
When the client request enters port 25 on Alteon 1, Alteon 1 makes a copy of the packet. Alteon
load balances the copied packet between the two IDS servers based on the configured load
balancing metric (hash). The original data packet however, enters Alteon 2 through the firewall and
Alteon 2 performs standard server load balancing on the client data between the three real servers.
The client request is processed and returned to Alteon 1 via the firewall. An allow filter at ports 26
and port 27 causes Alteon to make a copy of the request and directs the copy to the IDS server
group.
3. Create a group and add the IDS servers. The group must be numbered between 1 and 63.
4. Define the group metric for the IDS server group. IDS SLB supports the hash metric only.
5. Define the health check for the group. Configure link health check which is specifically developed
for IDS servers set up in stealth mode (without IP addresses).
8. Enable IDS on the client and server ports. This enables frames ingressing the port to be copied
to the IDS servers.
>># /cfg/slb/port 25/ids ena (Enable IDS processing for port 25)
>>SLB port 25# /cfg/slb/port 26/ids ena (Enable IDS processing for port 26)
>>SLB port 26# /cfg/slb/port 27/ids ena (Enable IDS processing for port 27)
In addition to enabling IDS at the port level, a filter must be configured to create a session entry
for non-SLB frames ingressing the port. IDS load balancing requires a session entry to be
created to store the information regarding which IDS server to send to.
9. Create an allow filter and configure the filter with the idshash metric.
The IDS hash metric is set to hash on both the source and destination IP addresses. Hashing on
both source and destination IP address ensures that the returning traffic goes to the same IDS
server. If the port is configured for client processing only, then Alteon hashes on the source IP
address. By default, the IDS hash metric hashes on the source IP address only.
10. Apply the allow filter to ports 25, 26, and 27. The allow filter must be applied on all ports that
require Layer 4 traffic to be routed to the IDS servers.
All ingressing traffic at these ports that match any of the filters configured for that port are load
balanced to the IDS groups. The allow filter is used at the end of the filter list to ensure that all
traffic matches a filter. A deny all filter can also be used as the final filter instead of an allow all
filter.
11. Apply and save your changes.
12. Configure Alteon 2 to load balance the real servers as described in Server Load Balancing
Configuration Basics, page 171.
— Configure the IP interfaces on Alteon
— Configure the SLB real servers and add the real servers to the group
— Configure the virtual IP address
— Configure the SLB metric
— Enable SLB
A copy of Layer 4 traffic from clients A, B, and C and from the real servers are directed to the IDS
servers and load balanced between IDS servers 6 and 7.
Figure 48: Server Load Balancing and IDS Load Balancing to Multiple Group
When the same Alteon is configured to load balance real servers and IDS servers, filter processing is
not required on the client processing port (port 25). To maintain session persistency, if you add the
filter to the client port, Alteon can be configured to hash on both the client IP and virtual server IP.
This ensures that both client and server traffic belonging to the same session is sent to the same
IDS server. If you do not add the filter on port 25, then Alteon hashes on the client IP address only.
3. Create two IDS groups and add the IDS servers. Define the two IDS Groups 51 and 52. The IDS
group numbers must be between 1 to 63.
4. Define the group metric for the IDS server groups. IDS SLB supports the hash metric only.
>>Real Server Group 51# metric hash (Set the metric to hash)
>>Real Server Group 51# /cfg/slb/group 52 (Select the other IDS group)
>>Real Server Group 52# metric hash (Set the metric to hash)
The hash metric is implemented in two ways. For more information, see step 4 on page 313.
5. Define the health check for the group. Configure ICMP health check for the group.
>>Real Server Group 51# health icmp (Set the health check to ICMP)
>>Real Server Group 51# /cfg/slb/group 52 (Select the other IDS group)
>>Real Server Group 52# health arp (Set the health check to ARP)
>>Real Server Group 51# idslb ena (Enable IDS for the IDS server group)
>>Real Server Group 51# /cfg/slb/group 52 (Select the other IDS group)
>>Real Server Group 52# idslb ena (Enable IDS for the IDS server group)
8. Enable IDS on the client and server processing ports. This enables frames ingressing the port to
be copied to the IDS servers.
>># /cfg/slb/port 25/idslb ena (Enable IDS SLB for port 25)
>>SLB port 25# /cfg/slb/port 2/idslb ena (Enable IDS SLB for port 2)
>>SLB port 2# /cfg/slb/port 3/idslb ena (Enable IDS SLB for port 3)
>>SLB port 3# /cfg/slb/port 4/idslb ena (Enable IDS SLB for port 4)
In addition to enabling IDS at the port level, a filter must be configured to create a session entry
for non-SLB frames ingressing the port. IDS load balancing requires a session entry to be
created to store the information regarding to which IDS server to send traffic.
9. Create an allow filter and configure the filter with the idshash metric.
The IDS hash metric is set to hash on both the source and destination IP addresses. Hashing on
both source and destination IP address ensures that the returning traffic goes to the same IDS
server. By default, the IDS hash metric hashes on the source IP address only.
10. Apply the filter to ports 2, 3, 4 and 25 only. Enable filter processing on all ports that have IDS
enabled.
If you add the allow filter to the client port 25, Alteon hashes on the client IP and virtual server
IP addresses for both client and server frames. This ensures that both client and server traffic
belonging to the same session is sent to the same IDS server. If you do not add the allow filter
on port 25, Alteon hashes on the client IP only for client frames and hashes on the client IP and
virtual server IP addresses for server frames.
A copy of Layer 4 Web traffic from clients A, B, and C and from the Real Servers 1, 2, and 3 is
load balanced between IDS Servers 6 and 7. A copy of all non-HTTP traffic is directed to IDS
Server 8.
12. Configure Alteon for SLB the real servers as described in Server Load Balancing Configuration
Basics, page 171.
— Configure the IP interfaces on Alteon.
— Configure and create a group for the SLB real servers.
— Configure the virtual IP address.
— Configure the SLB metric.
— Enable SLB.
Figure 49: Server Load Balancing and IDS Load Balancing Across Multiple Alteons
Normally, the standby Alteon learns the source MAC address of clients in the copied packet from the
port that is connected to the interswitch link. The standby Alteon also learns the source MAC address
of the server when the server response packets enter the master Alteon and are flooded to the IDS
VLAN over the interswitch link.
In a high availability configuration, the standby Alteon becomes the master if the current master
Alteon fails. The new master Alteon forwards traffic between clients and servers. Because the MAC
addresses of the real servers are learned via the interswitch link port, the request packets from
clients are forwarded to the interswitch link port on the new master Alteon and are received by the
new standby Alteon. Because the standby Alteon does not forward traffic, the request packets do
not normally reach the real servers.
Alteon remedies this situation by allowing the administrator to disable learning of client and server
source MAC addresses over the interswitch link, thus ensuring that when failover occurs, the client
request packets reach the real servers.
2. On the master Alteon, configure the interswitch link ports/VLANs for the IDS VLAN.
4. Configure an IP interface for the SNMP health check to the other Alteon.
5. Configure VLANs. Disable source MAC address learning only on the IDS VLANs.
The following VLANS are configured on Alteon:
— VLAN 1—For load balancing traffic to the real servers
— VLAN 1000—For performing SNMP health checks on Alteon 2
— VLAN 1001—For IDS Server 1
— VLAN 1002—For IDS Server 2
— VLAN 1003—For IDS Server 3
— VLAN 1004—For IDS Server 4
7. Create an IDS group and add the IDS servers. Define the IDS group. The IDS group numbers
must be between 1 to 63.
8. Define the group metric for the IDS server group. IDS SLB supports the hash metric only.
12. Enable IDS on the client and server ports. This enables frames ingressing the traffic ports to be
copied to the IDS servers.
>>SLB port 7# /cfg/slb/port 27/ids ena (Enable IDS processing for port 27)
>>SLB port 27# /cfg/slb/port 28/ids ena (Enable IDS processing for port 28)
In addition to enabling IDS at the port level, a filter must be configured to create a session entry
for non-SLB frames ingressing the port. IDS load balancing requires a session entry to be
created to store the information regarding to which IDS server to send traffic.
13. Configure an integer value for Alteon to accept the SNMP health check.
If the value returned by the real server for the MIB variable does not match the expected value
configured in the rcvcnt field, then the server is marked down. The server is marked back up
when it returns the expected value.
In this step, the server is marked down if Alteon receives a value of 1. The real server is
considers the health check to have failed.
14. Create an allow filter and configure the filter with the idshash metric.
The IDS hash metric is set to hash on both the source and destination IP addresses. Hashing on
both source and destination IP address ensures that the returning traffic goes to the same IDS
server. If the port is configured for client processing only, then Alteon hashes on the source IP
address. By default, the IDS hash metric hashes on the source IP address only.
15. Apply the allow filter to ports 4, 7, 8, 27, and 28 to enable filter processing on all ports that have
IDS enabled.
If you add the allow filter to the client port 4, Alteon hashes on the client IP and virtual server IP
address for both the client and server frames. This ensures that both client and server traffic
belonging to the same session is sent to the same IDS server. If you do not add the allow filter
on port 5, then Alteon hashes on the client IP only for client frames and hashes on the client IP
and virtual server IP addresses for server frames. The allow filter must be applied on all ports
that require Layer 4 traffic to be routed to the IDS servers.
All ingressing traffic at these ports that match any of the filters configured for that port are load
balanced to the IDS groups. The allow filter is used at the end of the filter list to make sure that
all traffic matches a filter. A deny all filter could also be used as the final filter instead of an
allow all filter.
16. Apply and save your changes.
17. Configure Alteon 2 to load balance the real servers as described in Server Load Balancing
Configuration Basics, page 171.
— Configure the IP interfaces on Alteon.
— Configure the SLB real servers and add the real servers to the group.
— Configure the virtual IP address.
— Configure the SLB metric.
— Enable SLB.
>> # /cfg/slb/on
5. Define the group metric for the server group. TCP-based SIP load balancing supports all metrics.
For example, set the metric to minmisses.
6. Define the health check for the group. The health check is TCP for TCP-based SIP load balancing.
>> # /cfg/slb/virt 1/service 5060 (Add the SIP service for Virtual Server
1)
>> # /cfg/slb/virt 1/service 5060 Group 100 (Add the real server group to the
service)
Note: Distribution of sessions between servers is achieved using the minmisses hash method
and is not always even. Call distribution can be improved by increasing the number of Call ID
bytes that are used as input to the hash function. For example:
Note: SIP sessions are quite long and data may be flowing while the signaling path is idle.
Because Alteon resides in the signaling path, Radware recommends increasing the real server
session timeout value to 30 minutes (Default: 10 minutes).
>> # /cfg/slb/on
5. Define the group metric for the server group. Because SIP load balancing is performed based on
Call-ID, only the minmisses metric is supported to ensure persistency.
6. Define the health check for the group. Configure SIP PING request health check which is
specifically developed for SIP-enabled servers.
>>> # /cfg/slb/virt 1/service 5060 (Add the SIP service for Virtual Server 1)
>> # /cfg/slb/virt 1/service 5060 Group 100 (Add the real server group to the
service)
Note: SIP sessions are quite long and data may be flowing while the signaling path is idle.
Because Alteon resides in the signaling path, Radware recommends increasing the real server
session timeout value to 30 minutes (Default: 10 minutes).
When the call terminates with a BYE command, Alteon releases the session entry immediately.
• Session persistency using the refer method—The refer method of load balancing SIP
servers is required for call transfer services. The refer method indicates that the recipient should
contact a third party using the contact information provided in the request.
To maintain session persistency, the new request from the recipient to the third party should
also hash the same real server. To maintain persistency, whenever Alteon receives a session
configured for the refer method, Alteon creates a persistent session.
When creating a session for a new request, Alteon looks up the session table and selects the
correct real server. If there is a persistent session, then the real server specified in the session
entry is used if that real server is up. Otherwise, the normal minmiss method is used to select
the real server.
• Supports standard health check options—Alteon supports the standard method to health
check SIP servers. The options method (like HTTP and RTSP) is supported by all RFC 3261
compliant proxies.
Alteon sends an options request to the SIP server when configured to use the SIP options
health check. If the response from the server is a “200 OK”, then the server is operational.
Otherwise, the server is marked down.
• Translating the the source port in SIP responses—Alteon supports the translation of the
source port to the application port before forwarding a response to the client in cases where the
server uses a source port different to the application port in its response.
• Support for RTP (SDP) Media Portal NAT—This feature is useful if you have several media
portal servers with private IP addresses. When the proxy servers respond to an INVITE request,
the private IP address of the media portal is embedded in the SDP. Alteon translates this private
IP address to a public IP address.
The private media portal address is sent in the response to an INVITE request. Alteon replaces
the private IP with the public IP address in the SDP.
The SoftGrid platform supports TCP unicast connections using the following protocols:
1. Real Time Streaming Protocol (RTSP)—RTSP is an application-level protocol that is
responsible for controlling the transport of multimedia content, session announcements, and
tear downs.
2. Real Time Transport Protocol (RTP)—RTP is used to transport the application data between
the server and the client.
3. Real Time Control Protocol (RTCP)—RTCP is used to control the streaming of the application
data that is transported by RTP.
The SoftGrid platform uses three channels to complete the application delivery process. Initially,
the SoftGrid Client uses the RTSP channel to create a connection with the SoftGrid Server. The
SoftGrid Server then opens two ports for the RTP and RTCP channels and sends these port
numbers to the client. The client then opens TCP connections to the ports created on the server.
The requested application is then streamed over the RTP channel while the RTCP channel
provides control over the RTP channel.
Make an entry in the network domain controller for the SoftGrid Server. For example,
<sw_name> 10.10.10.10. where <sw_name> was configured on Alteon using the command
cfg/slb/virt 1/vname <sw_name>.
2. Edit the SoftGrid Server OSD files.
When the SoftGrid platform is set up for load balancing, change the .OSD files in the SoftGrid
Servers to point to the Alteon virtual IP address or virtual server name:
If SoftGrid is enabled for an RTSP service, the SoftGrid RTSP mode performs the RTSP SLB for
that service.
Alteon also supports WLM in the redirect filter environment. The SASP protocol enables Alteon to
• receive traffic weight recommendations from the DM
• register Alteon members with the DM
• enable the Generic Window Manager (GWM) to propose new group members to Alteon
If the WLM number is not specified, the group is not registered with the WLM. As a result,
dynamic weights are not used for this group.
3. Specify if the WLM should use data or management port.
Deregisteration Requests: 1
Deregisteration Replies: 1
Deregisteration Reply Errors: 0
To display the current weight for the real servers for a particular service for application
load balancing
To display the current weight for the real server for application redirection
• Client Authentication Policy—Optionally, you can define a client authentication policy that
validates a client’s identity as part of the SSL handshake. In addition to defining the client
authentication policy, you must associate it to the SSL policy for it to take effect. For more
information, see Client Authentication Policies, page 343.
A single client authentication policy can be reused across multiple SSL policies, and by extension
across multiple virtual services.
Note: The order of configuring these components is not important, as long that you eventually
enable and apply them all as a unified configuration at one time. This means that you can configure
one or more of them individually and then configure the remaining items at a later time.
SSL Policies
An SSL policy determines the behavior of the SSL or HTTPS service that it is associated with. The
SSL policy determines the following:
• Which SSL/TLS versions are allowed during handshake
• Which cipher suites are used during handshake and encryption
• Which intermediate Certificate Authority (CA) to use
• Which SSL information to pass to the back-end servers
• When and if to use HTTP protocol-based location redirection conversion from HTTP to HTTPS
• Whether to use back-end encryption
• Whether and how to use client authentication
• Whether to use SSL/TLS on the front-end connection
An single SSL policy can be associated to multiple virtual services if they share the same SSL
configuration.
For details on defining the SSL policy parameters, see the section on the /cfg/slb/ssl/sslpol
menu in the Alteon Application Switch Operating System Command Reference.
Note: Alteon lets you explicitly select or deselect supported SSL and TLS protocol versions for the
front-end and back-end connections.
Certificate Repository
Certificates are digitally signed indicators that identify a server or a user. They are usually provided
in the form of an electronic key or value. The digital certificate represents the certification of an
individual business or organizational public key but can also be used to show the privileges and roles
for which the holder has been certified. It also includes information from a third-party verifying
identity. Authentication is needed to ensure that users in a communication or transaction are who
they claim to be.
A basic certificate includes:
• The certificate holder’s identity
• The certificate serial number
• The certificate 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 authority.
The certificate repository is a secured stronghold of all PKI-related components such as encryption
keys, certificates of different types, and Certificate Signing Requests (CSRs). Certificate components
are required for Alteon to supply SSL offloading services and client authentication. Alteon supports
the X.509 standard for PKIs.
For details on configuring the components of the certificate repository, see the section on the /cfg/
slb/ssl/certs menu in the Alteon Application Switch Operating System Command Reference.
Server Certificates
A server certificate is a type of certificate used to identify servers during SSL handshake. For details
on associating server certificates to SSL-based virtual services, see SSL Offloading Implementation,
page 337. You either import a pre-existing server certificate using the /cfg/slb/ssl/certs/
import command, or you can generate your own in Alteon.
When you generate your own server certificate, if an underlying Certificate Signing Request (CSR)
and/or key pair do not already exist by the same name as the server certificate, they are generated
along with the server certificate. The resulting server certificate is a "self-signed" server certificate,
meaning it was issued by the server for itself. This kind of a certificate is good for testing purposes,
as real users will experience various warning messages if used for the real SSL service. In order to
be used in the real-life SSL environment, the server certificate must be issued (signed) by a
Certificate Authority (CA) which is trusted by the client's browsers.
To achieve this, once the certificate's CSR is generated, you must submit it to a trusted Certificate
Authority (CA) for signing. If the request is successful, the CA sends back a certificate that has been
digitally signed by its own key, which you import using the /cfg/slb/ssl/certs/import
command, ensuring that it is not imported to the same entity name as the CSR.
Intermediate CA Certificates
Intermediate CA certificates are used when the CA providing the virtual service's server certificate is
not directly trusted by the end-user’s Web browsers. This is typical in an organization that has its
own CA server for generating server's certificates. In order to construct the trust chain from the
user’s browser list of trusted CAs to the organization's CA server, an intermediate CA certificate or
chain of certificates can be provided.
You can optionally bind an intermediate Certificate Authority (CA) certificate to the SSL policy (see
SSL Policies, page 338). These certificates are not created in Alteon—you must first import them.
You can also create a group of intermediate certificates (a complete CA chain) and bind it to the SSL
policy.
For details on associating an Intermediate CA certificate to an SSL policy, see the section on the /
cfg/slb/ssl/sslpol menu in the Alteon Application Switch Operating System Command
Reference.
Trusted CA Certificates
Trusted CA certificates are certificates that come from a Certificate Authority that your organization
uses to provide users with certificates (client certificates). Trusted CA certificates are associated with
client authentication policies (see Client Authentication Policies, page 343). If you use this option,
you must specify the trusted client CA certificate or group of trusted client CA certificates to allow
Alteon to know which client certificates to accept.
Trusted CA certificates are not created in Alteon—you must first import them. You select the trusted
CA certificates from those you have imported.
For details on associating a trusted CA certificate to a client authentication policy, see the section on
the /cfg/slb/ssl/authpol menu in the Alteon Application Switch Operating System Command
Reference.
Note: Certificate validation is using the SSL handshake process, which means the TCP handshake
was already completed. This implies that Alteon will open the connection to the back-end server
even if the OCSP validation failed.
For details on configuring client authentication policies, see the section on the /cfg/slb/ssl/
authpol menu in the Alteon Application Switch Operating System Command Reference.
To offload OCSP servers from frequent, repetitive validation requests, Alteon saves OCSP responses
in a cache for a defined period of time. In some cases you may want to purge the OCSP cache of
OCSP responses. For more details, see the section on the /oper/slb/ocsppurg command in the
Alteon Application Switch Operating System Command Reference.
For details on defining additional SSL policy parameters, see the section on the /cfg/slb/ssl/
sslpol menu in the Alteon Application Switch Operating System Command Reference.
3. Define a server certificate for this service:
— Import a third-party signed server certificate. For details on configuring the certificate
repository, see the section on the /cfg/slb/ssl/certs menu in the Alteon Application
Switch Operating System Command Reference.
— Alternatively, generate a self-signed server certificate, as shown in the following example:
Self signed server certificate, certificate signing request and key pair added.
5. Set the HTTPS virtual service to be used in the defined virtual server.
>> SSL Load Balancing# sslpol myPol (Associate the defined SSL Policy)
Note: The back-end server listening port (rport) changes from 443 to 80 because you did not
enable back-end encryption. For a different network setting, rport can be configured manually.
6. Optionally, import an Intermediate CA certificate or group and bind it to the SSL policy. For
details on Intermediate CA certificates and groups, see the section on the /cfg/slb/ssl/
certs menu in the Alteon Application Switch Operating System Command Reference.
To bind the intermediate CA certificate to the SSL policy use the following command:
7. Enable DAM or configure proxy IP addresses and enable proxy on the client port.
For details on defining additional SSL policy parameters, see the section on the /cfg/slb/ssl/
sslpol menu in the Alteon Application Switch Operating System Command Reference.
3. Define a server certificate for this service:
— Import a third-party signed server certificate. For details on configuring the certificate
repository, see the section on the /cfg/slb/ssl/certs menu in the Alteon Application
Switch Operating System Command Reference.
— Alternatively, generate a self-signed server certificate, as shown in the following example:
Self signed server certificate, certificate signing request and key pair added.
5. Set the non-HTTP virtual service to be used in the defined virtual server.
>> Main# /cfg/slb/virt 1/service 12345 (Define the service port and
Application usage: select SSL as the service's
http|https|ssl|dns|rtsp|wts|basic-slb application type)
Enter application: ssl
>> Virtual Server 1 12345 Service# group 1 (Associate the server group to be
used in that service)
>> Virtual Server 1 12345 Service# ssl (Switch to the SSL menu under
the service menu)
>> SSL Load Balancing# srvrcert (Associate the defined server
Current SSL server certificate: none certificate)
Enter new SSL server certificate or group
[cert|group|none] [none]: cert
Enter new SSL server certificate: MyCert
>> SSL Load Balancing# sslpol myPol (Associate the defined SSL Policy)
Note: The back-end server listening port (rport) is set to 12345. For a different setting, rport
can be configured manually.
6. Optionally, import an Intermediate CA certificate or group and bind it to the SSL policy. For
details on Intermediate CA certificates and groups, see the section on the /cfg/slb/ssl/
certs menu in the Alteon Application Switch Operating System Command Reference.
To bind the intermediate CA certificate to the SSL policy use the following command:
7. Enable DAM or configure proxy IP addresses and enable proxy on the client port.
2. Define the SSL policy which will govern the SSL offloading behavior:
For details on defining additional SSL policy parameters, see the section on the /cfg/slb/ssl/
sslpol menu in the Alteon Application Switch Operating System Command Reference.
3. Define a server certificate for this service:
— Import a third-party signed server certificate. For details on configuring the certificate
repository, see the section on the /cfg/slb/ssl/certs menu in the Alteon Application
Switch Operating System Command Reference.
— Alternatively, generate a self-signed server certificate, as shown in the following example:
Self signed server certificate, certificate signing request and key pair added.
5. Set the HTTPS virtual service to be used in the defined virtual server.
>> SSL Load Balancing# sslpol myPol (Associate the defined SSL policy)
Note: The back-end server listening port (rport) is set to 443 because you enabled back-end
encryption. For a different network setting, rport can be configured manually. If the back-end
server listening port was previously configured to a specific port, it will not be modified and must
be configured manually if required.
6. Optionally, import an Intermediate CA certificate or group and bind it to the SSL policy. For
details on Intermediate CA certificates and groups, see the section on the /cfg/slb/ssl/
certs menu in the Alteon Application Switch Operating System Command Reference.
To bind the intermediate CA certificate to the SSL policy use the following command:
7. Enable DAM or configure proxy IP addresses and enable proxy on the client port.
8. When using HTTP SSL offloading with back-end encryption enabled, Radware recommends using
multiplexing to minimize the server load of performing new SSL handshakes. For more details on
multiplexing, see Content-Intelligent Connection Management, page 277.
4. Optionally, define a default certificate that to be used for browsers or clients not supporting SNI:
This certificate can include the various domains for which you do SSL-offloading, using wildcard
domain names or a Subject Alternative Name (SAN).
5. Associate the server certificate group to a virtual service according to Example 1: Configuring a
Basic SSL Offloading Service, page 343 with the following change:
Alteon supports both SSL offloading with and without SNI, and there are various ways to
indicate domain names in certificates (common name, wildcards, subject alternative name
extension). The following is the order in which certificates are used in various scenarios (SSL
offloading certificate matching logic).
— Non-SNI configuration (i.e. a specific server certificate is associated to the virtual service)—
in this scenario, no matter whether or not there is an SNI in the SSL hello from the client,
the associated server certificate is returned to the client.
Note: Alteon is oblivious to the contents of the certificate. Therefore wildcard certificates or
Subject Alternative names (SAN) play no role and are supported.
3. Define the Trusted CA used to authenticate the client’s certificate by importing its certificate to
Alteon.
a. Import a Trusted CA Certificate into the certificate repository. For details on importing a
Trusted CA Certificate, see the section on the /cfg/slb/ssl/certs/import menu in the
Alteon Application Switch Operating System Command Reference.
b. Optionally, you can define a group of Trusted CA certificates. For details on defining a
Trusted CA Certificate group, see the section on the /cfg/slb/ssl/certs/group menu
in the Alteon Application Switch Operating System Command Reference.
4. Define the client authentication policy.
For details on defining additional client authentication policy parameters, see the section on the
/cfg/slb/ssl/authpol menu in the Alteon Application Switch Operating System Command
Reference.
5. Associate the defined client authenticating policy to the SSL policy used in the HTTPS service.
6. Enable DAM or configure proxy IP addresses and enable proxy on the client port.
4. Set the HTTP virtual service to be used in the defined virtual server.
Note: The back-end server listening port (rport) is set to 80 (vport). For a different network
setting, rport can be configured manually. If the back-end server listening port was previously
configured to a specific port, it will not be modified and must be configured manually if required.
5. Enable DAM or configure proxy IP addresses, and enable proxy on the client port.
6. When using back-end encryption, Radware recommends using multiplexing to minimize the
server load of performing new SSL handshakes. For more details on multiplexing, see Content-
Intelligent Connection Management, page 277.
Filtering Benefits
Filtering provides the following benefits:
• Filtering of Layer 2 non-IP frames—In Alteon, a filter can specify only source MAC and
destination MAC addresses, and capture and apply an allow.
• Increased security for server networks—Filtering gives you control over the types of traffic
permitted through Alteon. Filters can be configured to allow or deny traffic from Layer 2 through
Layer 7, including: MAC address, IP address, protocol, Layer 4 port, Layer 7 string or pattern
content.
Layer 2-only filters, as described in MAC-Based Filters for Layer 2 Traffic, page 373, can be
configured to allow or deny non-IP traffic.
• Map the source or destination IP addresses and ports—Generic NAT can be used to map
the source or destination IP addresses and the ports of private network traffic to or from
advertised network IP addresses and ports.
Note: When applied to ports, Alteon filters work exclusively in ingress and not egress.
In addition, Alteon supports advanced filtering options, such as TCP flags (Matching TCP Flags,
page 391) ICMP message types (Matching ICMP Message Types, page 395), and Layer 7 inversion
(Layer 7 Invert Filter, page 363).
Using these filter criteria, you can create a single filter that can potentially perform a very wide
variety of actions. Examples of such filters are:
• Block external Telnet traffic to your main server except from a trusted IP address.
• Warn you if FTP access is attempted from a specific IP address.
• Redirect all incoming e-mail traffic to a server where it can be analyzed for spam.
Filtering Actions
A filtering action (/cfg/slb/filt/action) instructs the filter what to do when the filtering
criteria are matched.
Alteon supports the following filtering actions:
• allow—Allows the frame to pass (by default). This filtering action can be used to redirect the
returning traffic to the service farm if the reverse session is enabled. For more information, see
Reverse Session, page 363.
• deny—Discards frames that fit the filter profile. This can be used for building basic security
profiles.
• redir—Redirects frames that fit the filter profile, such as for Web cache redirection. In addition,
Layer 4 processing must be activated using the /cfg/slb/on command.
• nat—Performs generic Network Address Translation (NAT). This can be used to map the source
or destination IP address and port information of a private network scheme to and from the
advertised network IP address and ports. This is used in conjunction with the nat option and can
also be combined with proxies.
• goto—Allows the user to specify a target filter ID that the filter search should jump to when a
match occurs. The “goto” action causes filter processing to jump to a designated filter,
effectively skipping over a block of filter IDs. Filter searching then continues from the designated
filter ID. To specify the new filter to goto, use the /cfg/slb/filt/adv/goto command.
Stacking Filters
Stacking filters are assigned and enabled on a per-port basis. Each filter can be used by itself or in
combination with any other filter on any given port. The filters are numbered 1 through 2048. When
multiple filters are stacked together on a port, the filter number determines its order of precedence;
the filter with the lowest number is checked first. When traffic is encountered at the port, if the filter
matches, its configured action takes place and the rest of the filters are ignored. If the filter criteria
do not match, Alteon tries to match the criteria of the following filter.
As long as the filters do not overlap, you can improve filter performance by making sure that the
most heavily used filters are applied first. For example, consider a filter system where the Internet is
divided according to destination IP address:
Assuming that traffic is distributed evenly across the Internet, the largest area would be the most
used and is assigned to Filter 1. The smallest area is assigned to Filter 4.
Overlapping Filters
Filters are permitted to overlap, although special care must be taken to ensure the proper order of
precedence. When there are overlapping filters, the more specific filters (those that target fewer
addresses or ports) must be applied before the generalized filters. For example:
In this example, Filter 2 must be processed prior to Filter 3. If Filter 3 is permitted to take
precedence, Filter 2 is never triggered.
Default Filter
Before filtering can be enabled on any given port, a default filter should be configured. This filter
handles any traffic not covered by any other filter. All the criteria in the default filter must be set to
the fullest range possible (any). For example:
In this example, the default filter is defined as Filter 2048 to give it the lowest order of precedence.
All matching criteria in Filter 2048 are set to any. If the traffic does not match the filtering criteria of
any other filter and no action is triggered, Filter 2048 processes it, denying and logging unwanted
traffic.
Default filters are recommended, but not required, when configuring filters for IP traffic control and
redirection. Using default filters can increase session performance but takes some of the session
binding resources. If you experience an unacceptable number of binding failures, as shown in the
Server Load Balancing Maintenance statistics (/stats/slb/maint), you may want to remove
some of the default filters.
Note: Radware recommends numbering filters in small increments (5, 10, 15, 20, and so on) to
make it easier to insert filters into the list at a later time. However, as the number of filters
increases, you can improve performance by minimizing the increment between filters. For example,
filters numbered 2, 4, 6, and 8 are more efficient than filters numbered 20, 40, 60, and 80. Peak
processing efficiency is achieved when filters are numbered sequentially beginning with 1.
>> # /cfg/slb/filter 22
IP Address Ranges
You can specify a range of IP addresses for filtering both the source and/or destination IP address
for traffic. When a range of IP addresses is needed, the source IP (sip) address or destination IP
(dip) address defines the base IP address in the desired range. The source mask (smask) or
destination mask (dmask) is the mask that is applied to produce the range.
For example, to determine if a client request’s destination IP address should be redirected to the
cache servers attached to a particular Alteon, the destination IP address is masked (bit-wise AND)
with the dmask and then compared to the destination IP address.
Filter Logs
To provide enhanced troubleshooting and session inspection capabilities, packet source and
destination IP addresses are included in filter log messages. Filter log messages are generated when
a Layer 3 or Layer 4 filter is triggered and has logging enabled. The messages are output to the
console port, system host log (syslog), and the Web-based interface message window.
Note: Filter logging should only be used for debugging purposes and not run on production
environments, as this may cause excessive CPU utilization if the filter firings are excessive.
When applied to one or more ports, this simple filter rule produces log messages that show when
the filter is triggered, and what the IP source and destination addresses were for the ICMP frames
traversing those ports.
Note: After port filtering is enabled or disabled and you apply the change, session entries are
deleted immediately.
The following is a filter log message output, displaying the filter number, port, source IP address,
and destination IP address:
>> # /cfg/slb/filt <filter number> /adv (Select the Advanced Filter menu)
>> Filter 1 Advanced # cache ena|dis (Enable or disable filter caching)
Note: Do not apply cache-enabled filters to the same ports as cache-disabled filters. Otherwise, the
cache-disabled filters could potentially be bypassed for frames matching the cache-enabled criteria.
Filtering Enhancements
Starting with version 28.1.50, Alteon simplifies session management through filters. While filters
classify user traffic and qualify the proper action, Alteon transparently takes care of session
management and proper handling in cases of proxy deployments.
Alteon supports the following filtering enhancements:
• Reverse Session, page 363
• Return to Proxy, page 363
• Layer 7 Invert Filter, page 363
Reverse Session
Filters only handle and search for a match of incoming traffic sent from the client server. In previous
versions, filters only created one entry in a session table per session. To handle reverse traffic,
either Direct Access Mode (DAM) or a reverse session must be defined.
When using DAM, Alteon changes the source port of the session and identifies the return session by
its changed source port. Alteon then reverts the session parameters to the original parameters of
the client session.
Previously, when using reverse session, Alteon created a reverse session entry in the session table,
handled the packet and reversed its parameters to those of the original client session. However,
reverse session could only handle traffic at layer 4.
Starting with version 28.1.50, reverse session returns traffic to the original session without changing
the source port and handles traffic at all layers. Return traffic is redirected to the original session
table and forwarded to the client with the original parameters.
Reverse session is defined per filter. At Layer 4, if DAM is activated, it takes precedence over reverse
session and overrides it. At Layer 7, reverse session takes precedence over DAM. That is, if reverse
session is enabled, DAM is automatically overridden.
To view an example using reverse session, see Redirecting Traffic with a Transparent Server,
page 364.
Return to Proxy
Alteon supports a wide range of server deployments. In some deployment scenarios, the servers
must have the traffic destined to their own assigned IP address, while the service must maintain
transparent. Starting with version 28.1.50, you can redirect traffic to such servers by changing the
session destination IP to match that of the server. To maintain persistency, that is for the return
traffic to return via the proxy, you must enable the reverse session option when using the
redirecting to proxy option.
To view an example using return to proxy, see Redirecting Traffic with a NAT Filter, page 366.
3. Configure Filter 20 to enable the Return to Source MAC address option. This adds an opposite
entry in the session table so that the return traffic matches its source MAC address.
>> # /cfg/slb/filt 20/adv (Select the Advanced menu for Filter 20)
>> Filter 20 Advanced# rtsrcmac ena (Enable Return to Source MAC Address)
2. Configure Filter 20 as NAT filter to translate source IP addresses before sending client traffic to
browse the Web.
3. Configure Filter 20 to enable the Return to Source MAC address option. This adds an opposite
entry in the session table so that the return traffic matches its source MAC address.
>> # /cfg/slb/filt 20/adv (Select the Advanced menu for Filter 20)
>> Filter 20 Advanced# rtsrcmac ena (Enable Return to Source MAC Address)
Figure 55: Redirecting Traffic with a Semi-Transparent Server and Return to Proxy
>> # /cfg/slb/filt 10/adv (Select the Advanced menu for Filter 10)
>> Filter 10 Advanced# redir (Select the Redirection Advanced menu
for Filter 10)
>> Filter 10 Advanced# rtproxy ena (Enable redirect to proxy server)
3. Configure Filter 20 to allow client traffic from the proxy to browse the Web.
4. Configure Filter 20 to enable the Return to Source MAC address option. This adds an opposite
entry in the session table so that the return traffic matches its source MAC address.
>> # /cfg/slb/filt 20/adv (Select the Advanced menu for Filter 20)
>> Filter 20 Advanced# rtsrcmac ena (Enable Return to Source MAC Address)
3. Configure Filter 20 to enable the Return to Source MAC address option. This adds an opposite
entry in the session table so that the return traffic matches its source MAC address.
>> # /cfg/slb/filt 20/adv (Select the Advanced menu for Filter 20)
>> Filter 20 Advanced# rtsrcmac ena (Enable Return to Source MAC Address)
>> # /cfg/slb/filt 10/adv (Select the Advanced menu for Filter 10)
>> Filter 10 Advanced# redir (Select the Redirection Advanced menu
for Filter 10)
>> Filter 10 Advanced# rtproxy ena (Enable redirect to proxy server)
VLAN-Based Filtering
Filters are applied per Alteon, per port, or per VLAN. VLAN-based filtering allows a single Alteon to
provide differentiated services for multiple customers, groups, or departments. For example, you
can define separate filters for Customers A and B on the same Alteon on two different VLANs. If
VLANs are assigned based on data traffic, for example, ingress traffic on VLAN 1, egress traffic on
VLAN 2, and management traffic on VLAN 3, filters can be applied accordingly to the different
VLANs.
This procedure is based on Figure 58 - Example VLAN-Based Filtering Configuration, page 374.
Note: While this example is based on IP traffic, VLAN-based filtering can also be used for non-IP
traffic by specifying smac and dmac criteria instead of sip and dip.
1. Configure Filter 2 to allow local clients to browse the Web and then assign VLAN 20 to the filter.
The filter must recognize and allow TCP traffic from VLAN 20 to reach the local client destination
IP addresses if originating from any HTTP source port.
3. Configure Filter 2048 to deny traffic and then assign VLAN 70 to the filter. As a result, ingress
traffic from VLAN 70 is denied entry to Alteon.
>> SLB Port 10# add 3 (Add Filter 3 to SLB Port 10)
>> SLB Port 10# add 2048 (Add Filter 2048 to SLB Port 10)
802.1p Priorities
The IEEE 802.1p standard uses eight levels of priority, 0 through 7, with priority 7 being assigned to
highest priority network traffic such as OSPF or RIP routing table updates, priorities 5 though 6
being for delay-sensitive applications such as voice and video, and lower priorities for standard
applications. A value of zero indicates a "best effort" traffic prioritization, and this is the default
when traffic priority has not been configured on your network. Alteon can only filter packets based
on the 802.1p values already present in the packets. It does not assign or overwrite the 802.1p
values in the packet.
2. Go to the Filtering Advanced menu and select the 802.1p priority value.
Apply a Bandwidth Management (BWM) contract to the prioritized filter. You can apply an
802.1p-prioritized filter to a BWM contract to establish the rule for how the traffic that matches
the defined 802.1p priority value. For more information on configuring a BWM contract, see
Contracts, page 761.
Notes
• When either Layer 3/4 or Layer 7 persistence is required, the group metric must be set to hash
or minmiss.
• HTTP Layer 7 persistence, when configured, overwrites the Layer 3/4 persistence setting.
• Persistence binding per filter cannot be enabled with Layer 7 content lookup (/cfg/slb/filt
<filter number>/adv/layer7/l7lkup) because pbind server selection uses Layer 3 and 4
criteria, while the l7lkup command can use Layer 7 SLB strings attached to the server.
• If Firewall Load Balancing (FWLB) is enabled, the FWLB filter which hashes on the source and
destination IP addresses overrides the tunable hash filter. For more information, see Firewall
Load Balancing, page 657.
Hashing on the 24-bit source IP address ensures that client requests access the same cache.
2. Set the metric for the real server group to minmiss or hash.
The source IP address is passed to the real server group for either of the two metrics.
2. Set the metric for the real server group to minmiss or hash.
The source IP address is passed to the real server group for either of the two metrics.
Filter-Based Security
This section includes an example for configuring filters for providing the best security. Radware
recommends that you configure filters to deny all traffic except for those services that you
specifically want to allow. Consider the example network in Figure 59 - Filter-Based Security
Configuration Example, page 379:
In this example, the network is made of local clients on a collector Alteon, a Web server, a mail
server, a domain name server, and a connection to the Internet. All the local devices are on the
same subnet. The administrator wants to install basic security filters to allow only the following
traffic:
• External HTTP access to the local Web server
• External SMTP (mail) access to the local mail server
• Local clients browsing the World Wide Web
• Local clients using Telnet to access sites outside the intranet
• DNS traffic
All other traffic is denied and logged by the default filter.
Note: Since IP address and port information can be manipulated by external sources, filtering does
not replace the necessity for a well-constructed network firewall.
Notes
• In this example, all filters are applied only to the port that connects to the Internet. If intranet
restrictions are required, filters can be placed on ports connecting to local devices.
• Filtering is not limited to the few protocols and TCP or UDP applications shown in this example.
See Well-Known Application Ports, page 175 for a list of well-known applications ports.
1. Before you begin, you must be logged into the CLI as the administrator.
2. Assign an IP address to each of the network devices.
For this example, the network devices have the following IP addresses on the same IP subnet:
Note: Because the proto parameter is not tcp or udp, the source port (sport) and destination
port (dport) values are ignored and may be excluded from the filter configuration.
4. Create a filter that allows external HTTP requests to reach the Web server.
The filter must recognize and allow TCP traffic with the Web server's destination IP address and
HTTP destination port:
>> Filter 1# name allow matching traffic (Provide a descriptive name for the
filter)
>> Filter 1# ena (Enable the filter)
5. Create a pair of filters to allow incoming and outgoing mail to and from the mail server.
Filter 2 allows incoming mail to reach the mail server, and Filter 3 allows outgoing mail to reach
the Internet:
7. Create a filter that allows local clients to telnet anywhere outside the local intranet.
The filter must recognize and allow TCP traffic to reach the local client destination IP addresses if
originating from a Telnet source port:
8. Create a series of filters to allow Domain Name System (DNS) traffic. DNS traffic requires four
filters; one pair is needed for UDP traffic (incoming and outgoing) and another pair for TCP
traffic (incoming and outgoing).
a. For UDP:
>> Filter 8# dmask 255.255.255.255 (Set mask for exact destination address)
>> Filter 8# proto tcp (For TCP protocol traffic)
>> Filter 8# sport any (From any source port)
>> Filter 8# dport domain (To any DNS destination port)
>> Filter 8# action allow (Allow matching traffic to pass)
>> Filter 8# ena (Enable the filter)
>> Filter 8# /cfg/slb/filt 9 (Select the menu for Filter 9)
>> Filter 9# sip 205.177.15.4 (From local DNS Server)
>> Filter 9# smask 255.255.255.255 (Set mask for exact source address)
>> Filter 9# dip any (To any destination IP address)
>> Filter 9# proto tcp (For TCP protocol traffic)
>> Filter 9# sport domain (From a DNS source port)
>> Filter 9# dport any (To any destination port)
>> Filter 9# action allow (Allow matching traffic to pass)
>> Filter 9# ena (Enable the filter)
Alteon lets you add and remove a contiguous block of filters with a single command.
10. Apply and verify the configuration.
Note: After port filtering is enabled or disabled and you apply the change, session entries are
deleted immediately.
Examine the resulting information. If any settings are incorrect, make appropriate changes.
11. Save your new configuration changes.
13. Check that all SLB parameters are working as expected. If necessary, make any appropriate
configuration changes and then check the information again.
Note: Changes to filters on a given port do not take effect until the port's session information is
updated (every two minutes or so). To make filter changes take effect immediately, clear the session
binding table for the port (see the /oper/slb/clear command in the Alteon Application Switch
Operating System Command Reference).
Static NAT
In the following example for static NAT (non-proxy), there are two filters: one for the external client-
side port, and one for the internal, server-side port. The client-side filter translates incoming
requests for the publicly advertised server IP address to the server's internal private network
address. The filter for the server-side port reverses the process, translating the server's private
address information to a valid public address.
In Figure 60 - Static NAT Example, page 385, clients on the Internet require access to servers on
the private network:
Notes
• Within each filter, the smask and dmask values are identical.
• All parameters for both filters are identical except for the NAT direction. For Filter 10, nat
source is used. For Filter 11, nat dest is used.
• Filters for static (non-proxy) NAT should take precedence over dynamic NAT filters (see Dynamic
NAT, page 386). Static filters should be given lower filter numbers.
• After port filtering is enabled or disabled and you apply the change, session entries are deleted
immediately.
Dynamic NAT
Dynamic NAT is a many-to-one solution. Multiple clients on the private subnet take advantage of a
single external IP address, thus conserving valid IP addresses. In the example in Figure 61 -
Dynamic NAT Example, page 386, clients on the internal private network require TCP/UDP access to
the Internet:
You may directly connect the clients to Alteon if the total number of clients is less than or equal to
the ports.
Note: Dynamic NAT can also be used to support ICMP traffic for PING.
This example requires a NAT filter to be configured on the port that is connected to the internal
clients. When the NAT filter is triggered by outbound client traffic, the internal private IP address
information on the outbound packets is translated to a valid, publicly advertised IP address on
Alteon. In addition, the public IP address must be configured as a proxy IP address on the Alteon
port that is connected to the internal clients. The proxy performs the reverse translation, restoring
the private network addresses on inbound packets.
For more information on proxy IP address, see Client Network Address Translation (Proxy IP),
page 190.
Notes
• The invert option in this example filter makes this specific configuration easier, but is not a
requirement for dynamic NAT.
• Filters for dynamic NAT should be given a higher numbers than any static NAT filters (see Static
NAT, page 384).
• After port filtering is enabled or disabled and you apply the change, session entries are deleted
immediately.
You may directly connect the real servers to Alteon if the total number of servers is less than or
equal to the ports.
Note: The passive mode does not need to use this feature.
Note: After port filtering is enabled or disabled and you apply the change, session entries are
deleted immediately.
For more information on proxy IP address, see Client Network Address Translation (Proxy IP),
page 190.
3. Enable active FTP NAT using the following command:
Overlapping NAT
Alteon supports overlapping or duplicate source IP addresses on different VLANs in a source NAT
filter. This is done by extending the session table lookup algorithm to include the session VLAN.
When there is an overlapping source IP address for different VLANs, Alteon creates different
sessions. For the source NAT, Alteon substitutes the source IP address with the configured proxy IP
address. A proxy IP address for the VLAN must be configured for this to function properly.
When there is an overlapping NAT, Alteon does not use the routing table to route the packet back to
the sender in Layer 3 mode, due to the overlapping source address. Instead, Alteon uses the VLAN
gateway to forward the packet back to the sender. While VLAN gateway configuration is necessary to
make this feature function properly, Layer 2 mode is also supported.
2. Configure the source NAT filter. Select the appropriate filter. In this example, Filter 2 is used.
Note: When MCS proxy authentication is enabled, the MCS PC client creates message digests
using the client's private address. These digests are sent back to the MCS server for
authentication during the invite stage. Call setup fails with MCS proxy authentication enabled as
Alteon does not regenerate these message digests with the public address.
Flag Description
URG Urgent
ACK Acknowledgement
PSH Push
RST Reset
SYN Synchronize
FIN Finish
Any filter may be set to match against more than one TCP flag at the same time. If there is more
than one flag enabled, the flags are applied with a logical AND operator. For example, by setting
Alteon to filter SYN and ACK, Alteon filters all SYN-ACK frames.
Notes
• TCP flag filters must be cache-disabled. Exercise caution when applying cache-enabled and
cache-disabled filters to the same port. For more information, see Cached Versus Non-Cached
Filters, page 362.
• With IPv6, TCP health checks end with an RST flag instead of FIN as in IPv4.
In this network, the Web servers inside the LAN must be able to transfer mail to any SMTP-based
mail server out on the Internet. At the same time, you want to prevent access to the LAN from the
Internet, except for HTTP.
SMTP traffic uses well-known TCP port 25. The Web servers originates TCP sessions to the SMTP
server using TCP destination port 25, and the SMTP server acknowledges each TCP session and data
transfer using TCP source port 25.
Creating a filter with the ACK flag closes one potential security hole. Without the filter, Alteon
permits a TCP SYN connection request to reach any listening TCP destination port on the Web
servers inside the LAN, as long as it originated from TCP source port 25. The server would listen to
the TCP SYN, allocate buffer space for the connection, and reply to the connect request. In some
SYN attack scenarios, this could cause the server's buffer space to fill, crashing the server or at least
making it unavailable.
A filter with the ACK flag enabled prevents external devices from beginning a TCP connection (with a
TCP SYN) from TCP source port 25. Alteon drops any frames that have the ACK flag turned off.
2. Configure a filter that allows SMTP traffic from the Internet to pass through Alteon only if the
destination is one of the Web servers, and the frame is an acknowledgment (SYN-ACK) of a TCP
session.
>> Filter 10# /cfg/slb/filt 15 (Select a filter for Internet SMTP ACKs)
>> Filter 15# sip any (From any source IP address)
>> Filter 15# sport smtp (From well-known source SMTP port)
>> Filter 15# proto tcp (For TCP traffic)
>> Filter 15# dip 203.122.186.0 (To the Web servers' IP address)
>> Filter 15# dmask 255.255.255.0 (To the entire subnet range)
>> Filter 15# dport any (To any destination port)
>> Filter 15# action allow (Allow matching traffic to pass)
>> Filter 15# ena (Enable the filter)
>> Filter 15# adv/tcp (Select the advanced TCP menu)
>> Filter 15 Advanced# ack ena (Match acknowledgments only)
>> Filter 15 Advanced# syn ena (Match acknowledgments only)
3. Configure a filter that allows SMTP traffic from the Internet to pass through Alteon only if the
destination is one of the Web servers, and the frame is an acknowledgment (ACK-PSH) of a TCP
session.
>> Filter 15# /cfg/slb/filt 16 (Select a filter for Internet SMTP ACKs)
>> Filter 16# sip any (From any source IP address)
>> Filter 16# sport smtp (From well-known source SMTP port)
>> Filter 16# proto tcp (For TCP traffic)
>> Filter 16# dip 203.122.186.0 (To the Web servers' IP address)
>> Filter 16# dmask 255.255.255.0 (To the entire subnet range)
>> Filter 16# dport any (To any destination port)
>> Filter 16# action allow (Allow matching traffic to pass)
>> Filter 16# ena (Enable the filter)
>> Filter 16# adv/tcp (Select the advanced TCP menu)
>> Filter 16 Advanced# ack ena (Match acknowledgments only)
>> Filter 16 Advanced# psh ena (Match acknowledgments only)
4. Configure a filter that allows trusted HTTP traffic from the Internet to pass through Alteon to the
Web servers.
>> Filter 16 Advanced# /cfg/slb/filt 17 (Select a filter for incoming HTTP traffic)
>> Filter 17# sip any (From any source IP address)
>> Filter 17# sport http (From well-known source HTTP port)
>> Filter 17# proto tcp (For TCP traffic)
>> Filter 17# dip 203.122.186.0 (To the Web servers' IP address)
>> Filter 17# dmask 255.255.255.0 (To the entire subnet range)
>> Filter 17# dport http (To well-known destination HTTP port)
>> Filter 17# action allow (Allow matching traffic to pass)
>> Filter 17# ena (Enable the filter)
5. Configure a filter that allows HTTP responses from the Web servers to pass through Alteon to the
Internet.
>> Filter 17# /cfg/slb/filt 18 (Select a filter for outgoing HTTP traffic)
>> Filter 18# sip 203.122.186.0 (From the Web servers' source IP
address)
>> Filter 18# smask 255.255.255.0 (From the entire subnet range)
>> Filter 18# sport http (From well-known source HTTP port)
>> Filter 18# proto tcp (For TCP traffic)
>> Filter 18# dip any (To any destination IP address)
>> Filter 18# dport http (To well-known destination HTTP port)
>> Filter 18# action allow (Allow matching traffic to pass)
>> Filter 18# ena (Enable the filter)
6. Configure a default filter which denies all other traffic. This filter is required.
Note: After port filtering is enabled or disabled and you apply the change, session entries are
deleted immediately.
For any given filter, only one ICMP message type can be set at any one time. The any option
disables ICMP message type filtering. The list option displays a list of the available ICMP message
types that can be entered.
Note: ICMP message type filters must be cache-disabled. Exercise caution when applying cache-
enabled and cache-disabled filters to the same port. For more information, see Cached Versus Non-
Cached Filters, page 362.
IPv6 Filtering
Alteon IPv6 support includes support for filter classification and action up to Layer 4. Layer 7
classification and actions are not supported on IPv6 filters. IPv6 filtering operates in a similar fashion
to IPv4 filtering.
Notes
• For NAT filters, the advanced PIP address configured within an IPv6 filter must also be IPv6.
• For an IPv6 redirection filter, the server group to which the filter redirects must contain only
IPv6 servers.
Connectivity is maintained in IPv6 through the regular exchange of Neighbors Solicitation (NSol)
packets. These packets are sent to find the link layer address of a neighbor in the link and to find the
reachability of a neighboring node. It is usually necessary to configure an additional ALLOW filter for
these multicast packets so that link neighbors can be learnt. If this is not done, no packets are
allowed because link neighbors cannot be learnt. Filter inversion also must take these NSol packets
into consideration.
Not all Advanced menu commands that are available for configuring IPv4 filters are available for
configuring IPv6 filters. You can use the following Advanced menu commands to configure IPv6
filters:
The following example creates two IPv6 filters for Port 1. Filter 1 allows the exchange Neighbors
Solicitation packets, and Filter 2 allows the movement of bridged HTTP traffic.
Notes
• Alteon supports Layer 7 content switching using an additional legacy configuration model that is
based on Layer 7 strings. For related examples based on using Layer 7 strings see Appendix B -
Content-Intelligent Server Load Balancing Not Using Layer 7 Content Switching Rules, page 809.
• To support IP fragment traffic when Layer 7 content switching is defined based on strings, use
the forceproxy command under /cfg/slb/virt/service/dbind to force traffic through the
Application Services Engine.
For more information, see /cfg/slb/virt<server number>/service <virtual port or
application name>/dbind/forceproxy option in the Alteon Application Switch Operating
System Command Reference.
In earlier versions of Alteon, filters are tied to content rules. The content rules act as a link to virtual
services. Alteon version 29 lets you assign content classes to Layer 7 filtering, freeing content rules
for use in a classification library.
Return-to-Sender
Enabling Return-to-Sender (RTS) allows Alteon to associate the session with the MAC address of the
WAN router. This ensures that the returning traffic takes the same ISP path as the incoming traffic.
RTS is enabled on the incoming WAN ports (port 2 and 7) to maintain persistence for the returning
traffic. Data leaves Alteon from the same WAN link that it used to enter, thus maintaining
persistency.
Note: As of version 29.0, the RTS method has been superseded by Transparent Load Balancing. For
best results, Radware recommends that you use Transparent Load Balancing. For more information,
see Transparent Load Balancing, page 364.
What is ADC-VX?
ADC-VX is a specialized Application Delivery Controller (ADC) hypervisor that runs multiple virtual
ADC instances on dedicated ADC hardware, Radware's OnDemand Switch platforms. ADC-VX is built
on a unique architecture that virtualizes the OnDemand Switch resources—including CPU, memory,
network, and acceleration resources. This specialized hypervisor runs fully functional virtual ADC
instances, each of which delivers ADC functionality just like a dedicated physical ADC. Each virtual
ADC instance contains a complete and separated environment of resources, configurations and
management.
vADCs
A vADC is a virtualized instance of the AlteonOS that behaves in the same manner as a traditional
Alteon hardware ADC, with the exception that while it is bound to a specific hardware resource, the
amount of resources allocated to the vADC may vary based on the user’s or application's resource
needs. This enables you to run multiple independent and private vADCs that vary in their processing
power.
Each vADC comprises a vSP (Virtualized Switch Processor) and a vMP (Virtualized Management
Processor), providing the vADCs with their own set of resources, network infrastructure, and
services that are completely independent of neighboring vADCs. This enables multiple users to run
vADCs and allocate resources to these vADCs without introducing any risk to the other vADCs within
the shared physical environment.
vADC management is divided between two management roles:
• The Global Administrator creates, initially configures, and monitors vADCs. In addition, one of
the main tasks of the Global Administrator is to dynamically allocate CPU and throughput
resources by assigning capacity units and adjusting throughput limits to a vADC. For more
details on capacity units and throughput, see Allocating and Removing Processing Power
(Capacity Units) and Throughput Resources, page 406). For more details on the Global
Administrator’s tasks, see Global Administrator, page 405).
• The vADC Administrator is responsible for the day-to-day configuration and maintenance of
vADCs using the same tasks as with traditional ADCs, except for those vADC tasks that only the
Global Administrator performs. For more details on the vADC Administrator’s tasks, see vADC
Administrator, page 409).
The following is an illustration of a network architecture configured to use ADC-VX:
vADC Management
As opposed to traditional ADC management, vADC management is divided between two
management roles:
• Global Administrator, page 405
• vADC Administrator, page 409
This section also discusses the following topic:
• Resource Management, page 410
Global Administrator
The Global Administrator is a superuser that works at a management level above and separate from
a vADC Administrator. The Global Administrator manages the physical Alteon resources and uses the
physical devices in a data center, is responsible for creating vADC instances, and manages and
monitors both system and vADC resource allocation and utilization. The Global Administrator does
not manage Layer 3 or SLB functionality, but rather they are managed by the vADC Administrator.
The Global Administration environment is only accessible through the out-of-band management
ports.
The basic tasks and responsibilities of the Global Administrator include the following:
• Managing vADCs, page 405
• Monitoring Health and Resource Usage, page 406
• Allocating and Removing Processing Power (Capacity Units) and Throughput Resources,
page 406
The following are additional tasks the Global Administrator performs:
• Assigning Initial User Access, page 406
• Configuring and Maintaining Management Ports, page 406
• Delegating System Services, page 407
• Synchronizing vADCs, page 407
Managing vADCs
The Global Administrator creates and deletes vADCs. The number of vADCs and their overall
capacity and throughput are based on the installed vADC and throughput licenses. Throughput can
be allocated to vADCs in increments of 1 Mbps. The maximum number of vADCs that can be created
is platform-specific from 24–256.
For an example procedure for creating and configuring vADC, see Creating a New vADC, page 419.
For more details on creating vADCs, see the section on the /cfg/vadc menu in the Alteon
Application Switch Operating System Command Reference.
For a discussion of allocating resources, see Allocating and Removing Processing Power (Capacity
Units) and Throughput Resources, page 406.
Allocating and Removing Processing Power (Capacity Units) and Throughput Resources
As a result of monitoring health and resource usage, the Global Administrator may want to readjust
the amount of processing power and throughput resources allocated per application. These
resources are allocated by assigning capacity units to the vADC.
A capacity unit represents the amount of processing power and throughput that is assigned to a
vADC.
Table 35 lists the total number of capacity units that can be assigned to a vADC, and the maximum
throughput per capacity unit.
Platform Maximum number of CUs that can be Maximum throughput (Mbps) per CU
assigned to a vADC
5224 24 666
Capacity units can be assigned to vADCs regardless of throughput requirements and only for the
purpose of increasing processing power. For example, an application that is assigned a policy that
requires a large amount of processing power does not necessarily require more throughput. For such
an application, you can increase the available processing power without having to adjust the
allocated throughput.
You can assign multiple capacity units to a vADC from the available capacity units in the pool of
global capacity units.
After initially assigning a capacity unit, you can add or remove throughput in 100 Mb increments up
until the amount of available throughput, based on the total amount of your installed throughput
license.
To adjust the number of capacity units, you must first shut down (disable) the vADC. After making
the adjustment, for the change to take effect, you then power on (enable) the vADC.
For more details, see the /cfg/vadc/cu command in the Alteon Application Switch Operating
System Command Reference. For an example procedure, see step 5.
Synchronizing vADCs
Environments using ADC-VX usually take advantage of a least one additional Alteon for redundancy
purposes. ADC-VX supports solution designs constructed with up to six peers for redundancy and
risk distribution. A Global Administrator managing the system is required to define a vADC only
once, while the system synchronizes all the settings to one of the peers. The system is aware of the
location of all vADCs and their peers at all times and performs the configuration synchronization
based on the location of the target vADC. Therefore, there is no need to keep track of or make
modifications in multiple locations. The synchronization mechanism creates new vADCs,
synchronizes changes, and adapts to any modification.
Each ADC-VX platform supports synchronization with up to five peers. Each system is aware of the
location of each vADC at any given time. This enables the contextual synchronization of all changed
configuration information to the relevant Alteon without manual intervention or any unnecessary
operations. To use this feature, you perform the following tasks:
• Define the IP information of Alteons in the system. The IP address that is used for
synchronization is the IP address of the Global Administrator management access.
• Assign each vADC with a peer ID using /cfg/vadc #/sys/sync.
For more details, see the section on the /cfg/sys/sync and /oper/sync commands in the
Alteon Application Switch Operating System Command Reference.
Note: ADC-VX also supports bulk vADC peer configuration using the range command available
under /cfg/sys/sync/peer #/range. For more details, see the Alteon Application Switch
Operating System Command Reference.
vADC Administrator
The vADC Administrator manages Layer 3 and SLB functionality controlling the service and/or
application policies and performance. Configuration and management of physical ADCs are handled
only by the Global Administrator.
The basic tasks and responsibilities of the vADC Administrator include the following:
• Configuring vADCs, page 409
• Configuring and Maintaining Management Ports, page 409
• Delegating System Services, page 409
• Locking and Unlocking Delegated Services, page 410
• Monitoring and Maintaining vADCs, page 410
• Synchronizing vADCs, page 410
Configuring vADCs
The vADC is responsible for vADC configuration and management. This is done in the same manner
as a traditional standalone ADC, except for those features and functions which are reserved for the
Global Administrator. For more details on the Global Administrator tasks and responsibilities, see
Global Administrator, page 405).
The vADC Administrator can override many of the Global Administrator settings for individual
vADCs. For example, under the /cfg/sys/mmgmt menu, the vADC Administrator can set different
IP and subnet addresses than were defined by the Global Administrator.
The system services that the vADC Administrator can change, if unlocked, include:
• Syslog server
• AAA Services
— RADIUS server
— TACACS server
• Time Services (NTP)
• Timeout for idle CLI sessions
Synchronizing vADCs
Each vADC individually supports configuration synchronization. Unlike the synchronization
mechanism used by the Global Administrator, which is responsible for synchronizing elements such
as VLANs and throughput limits, this mechanism is controlled by the vADC administrator and
synchronizes elements such as filters, SLB groups, virtual IPs, and all the vADC SLB settings.
If the vADC Administrator needs to synchronize vADC configurations, the synchronization is done in
the same manner as traditional ADCs using the /oper/slb/sync command. For more details, see
the Alteon Application Switch Operating System Command Reference.
Resource Management
ADC-VX manages vADC resources by limiting the resource consumption of vADCs. You can enable or
disable this feature.
• Enabled (default for Alteon 5224)—Limits the resources available to vADCs. See Limiting
Resource Consumption of vADCs, page 411.
• Disabled (default for Alteon 5412)—Enables sharing of any extra available resources between
vADCs. See Sharing Idle Resource Consumption with Other vADCs, page 410.
The Global Administrator can switch between these two modes. When changing modes, all vADCs
remain active and operational. Any connections beyond the allowed maximum resource
consumption are gracefully timed out rather than discarded.
>> /cfg/sys/limitcu/disable
>> /cfg/sys/limitcu/enable
Resource Dashboard
Each vADC has an accompanying dashboard that monitors the processing power and throughput
usage relative to the total allocated resources. The dashboard provides a centralized view of this
data so the Global Administrator can preemptively identify potential application and user issues and
needs by verifying the health, resource usage, and activity of the vADC.
The dashboard displays data on throughput and CPU usage, enabling the Global Administrator to
identify allocation issues and dependencies between the throughput and CPU usage. The charts on
the dashboard provide the Global Administrator with answers to the following questions:
• Are there any vADCs (applications and/or services) that do not have enough resources to fulfill
their tasks successfully or optimally?
• If there are not enough resources, is there a problem with the system or application that needs
to be addressed, or is it just displaying uncharacteristic behavior?
This section includes the following topics:
• Accessing the Dashboard, page 412
• Dashboard Charts, page 413
• Settings Menu, page 417
The following is an example dashboard display of multiple vADCs, as set for viewing through the
Settings menu (see Settings Menu, page 417)
Dashboard Charts
The dashboard displays two charts:
• Resource utilization (CPU and memory)—This chart consists of two metrics: CPU and
memory consumption per vADC.
• Service usage of the set limit (in percents)—This chart displays throughput, SSL, and
compression consumption per vADC.
You can choose one of two chart types to display for each dashboard:
• Bar chart
• Line chart
Chart Filters
You can select one of the following filters based on operating capacity:
• Customize, default view
• vADCs operating at 90% capacity
• vADCs operating at 80% capacity
• vADCs operating at 70% capacity
• Time (real-time, 1 hour, 24 hours)
Tool Tips
All charts include tool tips which provide more detailed information for a given vADC.
For example, the tool tip for the Throughput Utilization chart may state “Throughput utilization is
500Mb/1Gb”, meaning that the vADC is using on average 500 Mb out of the allocated 1 Gb.
Chart Behavior
Table 36 describes the behavior of each chart according to the selected chart type:
Settings Menu
The Settings menu is used to configure the following dashboard settings:
• Sampling interval
• Default chart type
• vADC chart selection
Parameter Description
Time Value This sets the display increments of the real-time chart.
Range: 15—3600 seconds
Default: 15 seconds
Chart View The chart view affects the way information is selected.
Values:
• Thr/Util—Each chart is independent and selects data for display based
on its specific category.
For example, the Top 10 Chart displays the top 10 vADCs in the
resource utilization category, and the top 10 vADCs in the throughput
category.
• Throughput—Services is the selection key. The Top 10 chart displays
the top 10 vADCs that consume the most throughput relative to their
throughput limit.
• Util—Resource utilization is the selection key. The Top 10 chart
displays the top 10 vADCs that consume the most resources relative
to their allocated resource capacity.
Default: RSRC/SRV
Chart Type Options:
• Bars—Displays an aggregate view of all the collected data based on
the selected time period.
• Lines—Displays consumption across time based on all the collected
data.
Default: Lines
For more information on the chart types, see Dashboard Charts,
page 413.
Parameter Description
Time Range Each chart displays a set of sampled data collected across a period of up
to a month. You can change the view based on set time periods in the
context of the chart.
Options:
• Real Time
• 1 Hour
• 1 Day
Default: Real Time
vADC Chart Selection You can create a customized chart that only displays selected vADCs.
Options:
• Add vADCs to the chart
• Remove vADCs from the chart
By default, 10 vADCs are displayed. You can optionally select specific
vADCs to display.
Default Mode: Display the first 10 vADCs created
/cfg/vadc 2/sys
(continued)
>> Global - vADC sys/syslog# ..
------------------------------------------------------------
[vADC system services Menu]
mmgmt - Management Port Menu
peer - Sync Peer Management Port Menu
sync - Assign target appliance for configuration sync
haid - Set HA-ID value
syslog - System Syslog Servers
radius - System RADIUS Servers
tacacs - System TACACS Servers
access - System Access Menu
idle - System timeout for idle CLI sessions
smtp - System SMTP host
cur - Display current vADC system parameters
2. The following cur commands display the status of vADC 1 with syslog and RADIUS servers
enabled:
— Display for the Global Administrator
2. Enter a name for the vADC in order to access it again using the vADC menu.
/cfg/vadc 2/name
3. The initial Management IP is the address assigned to the vADC for initial access. This address
can be changed by the vADC Administrator based on the vADC’s specific requirements:
Note: When assigning a vADC with the required throughput, no capacity units are assigned. You
must do this separately.
5. When assigning capacity units, you need to consider the total allocated throughput. If the
throughput allocated is 1 Gbps, Alteon does not allow you to assign only one capacity unit, but
instead requires you to assign at least two capacity units.
>> vADC 4# cu 2
Current Settings:
vADC 4 Assigned Capacity Units:
New Settings:
vADC 4 Assigned Capacity Units: 2
6. Each vADC requires at least one VLAN assigned to it. A vADC supports any type of interface
represented by a VLAN ID. Alteon uses VLAN IDs to represent any type of link, and such links
can be associated with a vADC (trunk, dedicated link, VLAN tag on a dot1q trunk, team, shared
interface, and so on).
For an example of assigning a VLAN shared interface to a vADC, see Assigning a VLAN Shared
Interface to a vADC, page 428.
Current Settings:
vADC 1 allowed networks:
No allowed IP networks configured.
New Settings:
vADC 1 allowed networks:
Current IPv4 allowed networks:
Id Vlan NetAddress NetMask
---- ---- --------------- ---------------
1 100 192.168.1.0 255.255.255.0
>> vADC 1#
------------------------------------------------------------
Apply complete; don't forget to 'save' updated configuration.
------------------------------------------------------------
Apply complete; don't forget to 'save' updated configuration.
>> vADC 1#
>> /cfg/gtcfg
>> /cfg/gtcfg
Select import option [all/vadc/padc]: vadc
Select vADC recovery type [all/vadmin]: vadmin
Enter vADC number: [1-28]: 1
vADC 1 already exists in the system, do you wish to replace it? [y/n]: y
Example Creating a New vADC from the Settings of the Recovery File
>> /cfg/gtcfg
Select import option [all/vadc/padc]: vadc
Select vADC recovery type [all/vadmin]: vadmin
Enter vADC number: [1-28]: 1
vADC 1 already exists in the system, do you wish to replace it? [y/n]: y
To create a new vADC from the configuration files of a physical, standalone ADC
1. Access the Active Switch Configuration Restoration menu.
>> /cfg/gtcfg
vADC 1 already exists in the system, do you wish to replace it? [y/n]: y
To replace an existing vADC with the configuration files of a physical, standalone ADC
1. Access the Active Switch Configuration Restoration menu.
>> /cfg/gtcfg
>> /cfg/ptcfg
>> /cfg/ptcfg/all
>> /cfg/ptcfg/vadc
Select backup option [all/global/vadc]:all
Choosing this option backs up the entire vADC, including both the Global and vADC
administration settings, such as CUs, VLANs, IP interfaces, licenses, SLB, acceleration features,
and so on.
>> /cfg/ptcfg/vadc
Select backup option [all/global/vadc]:vadc
>> /cfg/ptcfg/vadc
Select backup option [all/global/vadc]:global
Image Management
Alteon can support completely separate and unrelated ADC virtual instances ranging from 10 to 28,
whose images and configurations are managed by the Global Administrator. ADC management also
includes image management, enabling the Global Administrator to manage both standalone and
virtual modes. You can upgrade, patch, migrate, and stage new ADC environments without high
operational costs. With image management, you can
• Load new images
• Selectively upgrade system components
• Switch quickly and easily between standalone and virtual ADC modes
This section includes the following topics:
• Image Management in a Standalone ADC, page 438
• ADC-VX Image Management, page 442
• Switching Between System Modes, page 450
What Is An Image
An image is a file that contains specific pre-installed and pre-configured applications necessary to
implement one or more of the Alteon form factors.
A set of image files are available for download, letting you upgrade only specific elements of the
system. The image is pre-loaded to the system, supporting both ADC-VX and standalone ADC
deployment without the need to change software images. For downloading procedures, see the
Radware Alteon Installation and Maintenance Guide.
The following are the available image types:
Default Image
The default image is the ADC image used in the following scenarios:
• When switching from standalone to ADC-VX
• When creating a new vADC in ADC-VX mode
2. Enter dimage to select the new default image from a list of existing images.
Note: If you delete the default image, the system automatically selects the latest version number
and assigns it as the default image.
Image Bank
The image bank can store up to 10 ADC application images and ADC-VX infrastructure images.
When booting the system or loading an image, the image bank displays all available images and
their statuses. You can only load one image of each AlteonOS version.
Loading Images
In standalone mode, you can
• Upgrade the entire system with an AlteonOS image
• Upgrade an ADC application image
Image Statuses
The image status displays the current ADC-VX setup. The following are the image statuses:
Caution: You should not remove images that are currently being used by vADCs.
Note: ADC-VX is not compatible with image versions earlier than version 28.1. Therefore, images
that are inherited from a standalone ADC from an earlier version are displayed in the image bank as
incompatible.
Loading Images
Only the Global Administrator can load images. Because the system only holds one image for each
ADC-VX at a time, you do not need to load the same image more than once. The same image can be
used by multiple vADCs.
You can only replace an active image after the Global Administrator authorizes the switch.
In the ADC-VX mode, you can load the following images:
• AlteonOS
• ADC application image
• ADC-VX infrastructure image
For more information, see Table 37 - Image Formats, page 436.
3. At the prompt, select the image ID for the new infrastructure image.
Note: If you select no, you must restart the system manually.
Caution: You should not remove images that are currently being used by vADCs.
Note: Images inherited from a standalone ADC that are not compatible with ADC-VX display in the
ADC application repository as incompatible.
Caution: If you remove all infrastructure images, the image switching process cannot be initiated.
Note: Always use the settings available to the vADC, including the management address,
management access mode, syslog service, and so on.
HA ID Management
ADC-VX is a virtual environment in which vADCs can be isolated, share physical links, connect to
shared areas of the network, and connect with other ADC form factors. This virtual environment
handles all network layers, transitions between standalone to virtual environments and application
resiliency.
What is an HA ID?
An HA ID is a unique identifier that you use to assign vADC MAC addresses. You use HA IDs for
vADCs with different IDs, establishing relationships, and for when an overlapping MAC address is
generated over a shared link.
An HA ID is used to generate a unique MAC similar to the way a vADC ID is used to generate virtual
router MACs. Once an HA ID is assigned, a unique virtual router MAC is created for each vADC on the
shared interface. vADCs automatically adjust their virtual router MAC allocation based on the HA ID.
HA ID Settings
The HA ID is set by the Global Administrator and is transparent to the vADC administrator. HA IDs
are automatically assigned to vADCs during creation. By default, they are identical to the vADC ID
and can be modified by the Global Administrator.
Table 40 describes the HA ID settings.
HA ID Description
0 This HA ID is required when creating an HA pair between a vADC and any
other form factor through a shared interface.
1–63 This range of IDs is used to create a unique virtual router MAC together
with the virtual router ID.
Modifying HA IDs
The Global Administrator can modify the HA ID of vADCs.
To modify an HA ID
1. Access the Active Switch Configuration vADC System Services menu.
Note: To access application redirection functionality, the optional Layer 4 software must be enabled.
For more information, see the section on Filtering and Layer 4 in the Alteon Application Switch
Operating System Command Reference.
Overview
Most of the information downloaded from the Internet is not unique, as clients will often access a
Web page many times for additional information or to explore other links. Duplicate information also
gets requested as the components that make up Internet data at a particular Web site (pictures,
buttons, frames, text, and so on) are reloaded from page to page. When you consider this scenario
in the context of many clients, it becomes apparent that redundant requests can consume a
considerable amount of your available bandwidth to the Internet.
Application redirection can help reduce the traffic congestion during peak loads. When application
redirection filters are properly configured, outbound client requests for Internet data are intercepted
and redirected to a group of application or cache servers on your network. The servers duplicate and
store inbound Internet data that has been requested by your clients. If the servers recognize a
client's outbound request as one that can be filled with cached information, the servers supply the
information rather than send the request across the Internet.
In addition to increasing the efficiency of your network, accessing locally cached information can be
much faster than requesting the same information across the Internet.
This network needs a solution that addresses the following key concerns:
• The solution must be readily scalable.
• The administrator should not need to reconfigure all the clients' browsers to use proxy servers.
If you have more clients than ports, then connect the clients to a Layer 2 switch, as shown in Figure
68 - Network with Application Redirection, page 456:
Adding Alteon with optional Layer 4 software addresses the following issues:
• Cache servers can be added or removed dynamically without interrupting services.
• Performance is improved by balancing the cached request load across multiple servers. More
servers can be added at any time to increase processing power.
• The proxy is transparent to the client.
• Frames that are not associated with HTTP requests are normally passed to the router.
Note: For details about these procedures or any of the menu commands described in this example,
see the Alteon Application Switch Operating System Command Reference.
In this example, Alteon is placed between the clients and the border gateway to the Internet. Alteon
is configured to intercept all Internet bound HTTP requests (on default TCP port 80), and redirect
them to the cache servers. Alteon distributes HTTP requests equally to the cache servers based on
the destination IP address of the requests. If the cache servers do not have the requested
information, then the cache servers behave like the client and forward the request out to the
Internet.
Note: Filters are not limited to the few protocols and TCP or UDP applications shown in this
example. See Well-Known Application Ports, page 175 for a list of well-known applications ports.
For this example, the three cache real servers have the following IP addresses on the same IP
subnet:
Note: The IP interface and the real servers must be in the same subnet. This example assumes
that all ports and IP interfaces use default VLAN 1, requiring no special VLAN configuration for
the ports or IP interface.
4. Define each real server. For each cache real server, you must assign a real server number,
specify its actual IP address, and enable the real server. For example:
5. Define a real server group. This places the three cache real servers into one service group.
6. Set the real server group metric to minmisses. This setting helps minimize cache misses in the
event real servers fail or are taken out of service.
7. Verify that server processing is disabled on the ports supporting application redirection.
Note: Do not use the server setting on a port with application redirection enabled. Server
processing is used only with SLB. To disable server processing on the port, use the commands
on the /cfg/slb/port menu, as described in the Alteon Application Switch Operating System
Command Reference.
8. Create a filter that will intercept and redirect all client HTTP requests.
The filter must intercept all TCP traffic for the HTTP destination port and must redirect it to the
proper port on the real server group.
The rport (redirection) parameter must be configured whenever TCP/UDP protocol traffic is
redirected. The rport parameter defines the real server TCP or UDP port to which redirected
traffic is sent. The port defined by the rport parameter is used when performing Layer 4 health
checks of TCP services.
Also, if NAT and proxy addresses are used on Alteon (see step 3), the rport parameter must be
configured for all application redirection filters. Make sure to use the proper port designation
with rport. If the transparent proxy operation resides on the host, the well-known port 80 (or
HTTP) is probably required. If the transparent proxy occurs in Alteon, make sure to use the
service port required by the specific software package.
For more information on IP proxy addresses, see IP Proxy Addresses for NAT, page 464.
9. Create a default filter. In this case, the default filter will allow all non-cached traffic to proceed
normally.
Note: When the proto parameter is not TCP or UDP, sport and dport are ignored.
10. Assign the filters to the client ports. Assuming that the redirected clients are connected to
physical ports 5 and 6, both ports are configured to use the previously created filters.
>> SLB Port 6# /cfg/slb (Select the Server Load Balancing menu)
>> Layer 4# on (Activate Layer 4 software services)
>> Layer 4# apply (Make your changes active)
>> Layer 4# cur (View current settings)
SLB must be turned on in order for the application redirection to work properly.
12. Examine the resulting information from the cur command. If any settings are incorrect, make
appropriate changes.
13. Save your new configuration changes.
Check that all SLB parameters are working as expected. If necessary, make any appropriate
configuration changes and then check the information again.
Note: Changes to filters on a given port only affect new sessions. To make filter changes take
effect immediately, clear the session binding table for the port. See the /oper/slb/clear
command in the Alteon Application Switch Operating System Command Reference).
For more information on delayed binding, see Delayed Binding, page 203.
>> # /cfg/slb/real 1
>> Real server 1# rip 1.1.1.1 (Configure RTSP Cache Server 1)
>> Real server 1# ena (Enable RTSP Cache Server 1)
>> Real server 1# /cfg/slb/real 2
>> Real server 2# rip 1.1.1.2 (Configure RTSP Cache Server 2)
>> Real server 2# ena (Enable RTSP Cache Server 2)
>> Real server 2# /cfg/slb/real 3
>> Real server 3# rip 1.1.1.3 (Configure RTSP Cache Server 3)
>> Real server 3# ena (Enable RTSP Cache Server 3)
>> Real server 3# /cfg/slb/real 4
>> Real server 4# rip 1.1.1.4 (Configure RTSP Cache Server 4)
>> Real server 4# ena (Enable RTSP Cache Server 4)
>> # /cfg/slb/group 1
>> Real Server Group 1# add 1 (Add RTSP Cache Server 1 to Group 1)
>> Real Server Group 1# add 2 (Add RTSP Cache Server 2 to Group 1)
>> Real Server Group 1# add 3 (Add RTSP Cache Server 3 to Group 1)
>> Real Server Group 1# add 4 (Add RTSP Cache Server 4 to Group 1)
4. Define the group metric for the RTSP cache servers. RTSP supports all the standard load-
balancing metrics.
5. Configure an RTSP redirection filter to cache data and balance the load among the cache
servers.
7. Add and enable the redirection filter on the port to support basic cache redirection.
3. Configure the application redirection filters. Once proxy IP addresses are established, configure
each application redirection filter (Filter 2 in this example) with the real server TCP or UDP port
to which redirected traffic will be sent. In this case, the requests are mapped to a different
destination port (8080). You must also enable proxies on the real servers:
Note: This configuration is not limited to the HTTP (Web) service. Other TCP/IP services can be
configured in a similar fashion. For example, if this had been a DNS redirect, rport would be sent
to well-known port 53 (or the service port you want to remap to). For a list of other well-known
services and ports, see the Well-Known Application Ports, page 175.
Note: Origin server refers to the server originally specified in the request.
The HTTP 1.0 Pragma: no-cache header is equivalent to the HTTP 1.1 Cache-Control header. By
enabling the Pragma: no-cache header, requests are forwarded to the origin server.
For cache redirection, at any given time one HTTP header is supported globally on Alteon. This
section discusses the following types of cache redirection:
• URL-Based Cache Redirection, page 466
• HTTP Header-Based Cache Redirection, page 472
• Browser-Based Cache Redirection, page 474
• URL Hashing for Cache Redirection, page 475
• RTSP Streaming Cache Redirection, page 477
Note: Both HTTP 1.0 and HTTP 1.1 requests are supported.
• /product —Any URL that starts with "/product," including any information in the "/product"
directory.
• product —Any URL that has the string "product".
Some of the common noncacheable items that you can configure to add, delete, or modify are:
• Dynamic content files:
— Common gateway interface files (.cgi)
— Cold fusion files (.cfm), ASP files (.asp)
— BIN directory
— CGI-BIN directory
— SHTML (scripted html)
— Microsoft HTML extension files (.htx)
— Executable files (.exe)
• Dynamic URL parameters: +, !, %, =, &
As shown in Figure 70 - URL-Based Cache Redirection, page 467, requests matching the URL are
load balanced among the multiple servers, depending on the metric specified for the real server
group (leastconns is the default).
b. Enable or disable ALLOW for non-GETS (such as HEAD, POST, and PUT) to the origin server:
• ena—Alteon redirects all requests that contain "cookie:" in the HTTP header to the
origin server.
• dis—Alteon compares the URL against the expression table to determine whether the
request should be redirected to a cache server or the origin server.
d. Enable or disable cache redirection of requests that contain the string "Cache-control:no
cache" in the HTTP 1.1 header or the string "Pragma:no cache" in the HTTP 1.0 header to
the origin server.
• ena—Alteon redirects all requests that contain the string “Cache-control: no cache” in
the HTTP 1.1 header or the string “Pragma:no cache” in the HTTP 1.0 header to the
origin server.
• dis—Alteon compares the URL against the expression table to determine whether the
request should be redirected to a cache server or the origin server.
4. Define the strings to be used for cache SLB:
>> # /cfg/slb/layer7/slb/cur
For easy configuration and identification, each defined string has an ID attached, as shown in
Table 42 - SLB Strings, page 470.
ID SLB String
1 any
2 .gif
3 /sales
4 /xitami
5 /manual
6 .jpg
Note: If you do not add a defined string (or add the defined string any), the server will handle
any request.
Add the defined strings to the real servers, where ID is the identification number of the defined
string:
The server can have multiple defined strings. For example: "/images", "/sales", ".gif"
With these defined strings, the server can handle requests that begin with "/images" or "/sales"
and any requests that contain ".gif".
8. Define a real server group and add real servers to the group. The following configuration
combines three real servers into a group.
11. Select the appropriate NAT option. The three NAT options are listed below. For more information
about each option, see Network Address Translation Options, page 468.
— No NAT option:
>> # /cfg/slb/pip
>> Proxy IP Address# add 12.12.12.12 (Configure proxy IP address)
>> # /cfg/slb/filt <filter number>
>> Filter <filter number> # rport 3128 (Specify redirection port)
>> Filter <filter number> # adv/proxyadv (Select the advance menu)
>> Filter <filter number> Advanced# proxy ena (Enable proxy IP address)
For more information on proxy IP addresses, see Client Network Address Translation (Proxy IP),
page 190.
12. Create a default filter for non-cached traffic.
When the proto parameter is not tcp or udp, then sport and dport are ignored.
13. Turn on filtering for the port.
>> # /stats/slb/layer7/redir
Total URL based Web cache redirection stats:
Total cache server hits: 73942
Total origin server hits: 2244
Total straight to origin server hits: 0
Total none-GETs hits: 53467
Total 'Cookie: ' hits: 729
Total no-cache hits: 43
Total RTSP cache server hits: 0
Total RTSP origin server hits: 0
Total HTTP redirection hits: 0
— Define an IP interface.
— Define each real server.
— Assign servers to real server groups.
— Define virtual servers and services.
2. Turn on Layer 7 lookup for the filter.
>> # /cfg/slb/layer7/slb/cur
ID SLB String
1 any
2 .com
3 .org
4 .net
7. Configure the real servers to handle the appropriate load balance strings.
8. Add the defined string IDs to the real servers, where ID is the identification number of the
defined string.
Note: If you do not add a defined string (or add ID=1), the server will handle any request.
>> # /cfg/slb/layer7/slb/cur
ID SLB String
1 any
2 Mozilla
3 Internet Explorer
4 Netscape
7. Add the defined string IDs to configure the real servers to handle the appropriate load balance
strings, where ID is the identification number of the defined string.
If you do not add a defined string (or add the ID 1), the server will handle any request.
— hash disable—Disables hashing based on the URL. Instead, the host header field to
calculate the hash key.
If the host header field does not exist in the HTTP header, then Alteon uses the source IP
address as the hash key.
Examples
A Hashing on the URL
In this example, URL hashing is enabled. If the host field does not exist, the specified length of
the URL is used to hash into the cache server as shown in Figure 71 - URL Hashing for
Application Redirection, page 476. If the host field exists, the specified length of both the host
field and the URL is used to hash into the cache server. The same URL request goes to the same
cache server:
— Client 1 request http://www.radware.com/sales/index.htmis directed to cache server 1.
— Client 2 request http://www.radware.com/sales/index.htmis directed to cache server 1.
— Client 3 request http://www.radware.com/sales/index.htm is directed to cache server 1.
This procedure is based on Figure 72 - RTSP Steaming Cache Redirection, page 477.
1. Before you start configuring this feature, do the following:
— Connect each cache server to the Alteon appliance.
— Configure the IP addresses on all devices connected to Alteon.
— Configure the IP interfaces.
>> # /cfg/slb/real 1
>> Real server 1# rip 1.1.1.1 (Configure RTSP Cache Server 1)
>> Real server 1# ena (Enable RTSP Cache Server 1)
>> Real server 1# /cfg/slb/real 2
>> Real server 2# rip 1.1.1.2 (Configure RTSP Cache Server 2)
>> Real server 2# ena (Enable RTSP Cache Server 2)
>> Real server 2# /cfg/slb/real 3
>> Real server 3# rip 1.1.1.3 (Configure RTSP Cache Server 3)
>> Real server 3# ena (Enable RTSP Cache Server 3)
>> Real server 3# /cfg/slb/real 4
>> Real server 4# rip 1.1.1.4 (Configure RTSP Cache Server 4)
>> Real server 4# ena (Enable RTSP Cache Server 4)
>> # /cfg/slb/group 1
>> Real Server Group 1# add 1 (Add RTSP Cache Server 1 to Group 1)
>> Real Server Group 1# add 2 (Add RTSP Cache Server 2 to Group 1)
>> Real Server Group 1# add 3 (Add RTSP Cache Server 3 to Group 1)
>> Real Server Group 1# add 4 (Add RTSP Cache Server 4 to Group 1)
8. Configure the parameters and file extensions that will bypass RTSP streaming cache redirection.
This is for user-defined, non-cacheable content.
For example, QuickTime files are non-cacheable—RTSP files with the extension *.mov must
bypass the streaming cache redirection. Similarly, you can add other RTSP file extensions (such
as *.smil, *.rm, *.ram, and so forth) to bypass the redirection.
A client request of the form “RTSP://*.mov” bypasses the cache servers and instead is routed
directly to the original servers.
9. Under the filter menu, add the string IDs that need to be excluded.
10. Define the RTSP file extensions to load balance among the cache servers.
>> # /cfg/slb/layer7/slb/cur
ID SLB String
1 any
2 *.mov
3 condor.rm
4 tiger.rm
Note: If no string is assigned to the server, the server will handle all requests.
Client requests “condor.rm” or “tiger.rm” are retrieved from the local Cache servers 1 or 2 and 3
or 4 respectively. However, a client request “cheetah.mov” bypasses the local cache servers and
is forwarded to the original server.
Note: Disabling destination MAC address substitution is only available for filter redirection.
— ARP Health Checks, page 493—Describes how to perform health checks on Intrusion
Detection Servers (IDS) that do not have full TCP/IP stack support.
— RTSP Health Checks, page 494—Describes how to perform RTSP health checks.
— Script-Based Health Checks, page 495—Describes how to configure Alteon to send a series
of health-check requests to real servers or real server groups and monitor the responses.
Health checks are supported for TCP and UDP protocols, using either Binary or ASCII
content.
• Pre-defined Health Check Summary, page 502—Lists all available out-of-the-box health check
objects.
• Failure Types, page 503—Explains the service failed and server failed states.
• DSR Health Checks, page 505—Describes the servers' ability to respond to the client queries
made to the Virtual server IP address when the server is in Direct Server Return (DSR) mode.
• Advanced Group Health Check, page 505—Describes how to configure an expression to
fine-tune the selected health check for a real server group.
• Disabling the Fast Link Health Check, page 506—Describes how to disable fast link health
checks.
Note: The destination port parameter is not relevant for Link, ICMP, and ARP health checks.
• Reverse health check result—When this parameter is enabled, if the health check behaves as
expected, it is considered failed.
• Health check timers
— Interval (1-600 seconds)—Defines the interval at which consecutive health check requests
are sent to the monitored element.
— Timeout (0-600 seconds)—If the health check response from the monitored element does
not arrive within this time frame, the health check fails. This parameter value must be lower
or equal to the interval parameter. When parameter is set to 0, the timeout is equal to the
interval.
— Retries to failure (1-63)—The monitored element is considered unavailable if this number of
consecutive health checks fails.
— Retries to restore (1-63)—The monitored element is considered available after failure if this
number of consecutive health checks is successful.
— Down-time interval (0-600 sec)—This parameter allows defining a different health check
interval (usually longer than regular interval) while the server is down. When the parameter
is set to 0, the server is tested at the same interval whether it is up or down.
Note: Interval, retries to failure, and retries to restore parameters can be overridden at the real
server level.
• Application arguments —Application related arguments that differ based on health check type.
For details on the available health check types and their arguments, see Supported Health Check
Types, page 484.
Note: In most cases, real sever numbering (rindex) and port numbering match up. For
example, real server id 1 is assumed to be connected to port 1. When port/link 1 is up we
declare real server 1 as up.
• Assign the pre-defined Link health check to the IDS server group.
For this health check type only the pre-defined link object is available. It is not possible to configure
a user-defined Link health check.
Note: The pre-defined tcp health check is the default health check for a new group.
Note: The pre-defined icmp health check is the default health check for real servers that are not
attached to any virtual service, and for UDP services when the health check of the attached group is
for a TCP application.
Note: If content is not specified, the health check is performed using the / character.
A Host header using virtual service (hname) and virtual server (dname) parameters
hname= everest
dname= example.com
content= index.html
Health check is performed using:
GET /index.html HTTP/1.1
Host: everest.example.com
hname= (none)
dname= raleighduram.cityguru.com
content= /page/gen/?_template=alteon
Health check is performed using:
GET /page/gen/?_template=alteon HTTP/1.1
Host: raleighduram.cityguru.com
hname= (none)
dname= (none)
content= index.html
Health check is performed using:
GET /index.html HTTP/1.0 (since no HTTP HOST: header is required)
hname= (none)
dname= (none)
content= //everest/index.html
Health check is performed using:
GET /index.html HTTP/1.1
Host: everest
Note: If no filename is specified (directly or via group configuration), the health check performed
for that group is TCP.
A pre-defined tftp health check is available for simple TFTP service monitoring. The health check has
the path or filename parameter set to Inherit, allowing definition using the group content and the
destination port set to standard TFTP port (69).
• Minimum and maximum value—Specifies the minimum and/or maximum value that can be
received as response that is considered a success. This should be used when the OID value is of
numeric type (integer, counter, and so on)
• Response String—Specifies a string expected in the SNMP response value that represents health
check success. This should be used when the OID value is of string type.
Note: If no expected response is configured (minimal or maximal value, or string), the health
check just checks that an SNMP response is received.
• Readjust Weight—Specifies whether the real server weights should be dynamically adjusted
based on SNMP health check response. If the parameter is enabled and the value in the
response packet is greater than 100, then 100 is used as the weight (relevant only for an integer
parameter).
If an OID and community string are assigned per IDS real server (/cfg/slb/real/ids), then they
override the health check configuration.
Note: If the username and password are set to Inherit but group content is empty, the health check
performed for that group is TCP.
A pre-defined pop3 health check is available for simple POP3 service monitoring. The health check
has the username and password parameters set to Inherit, allowing definition using the group
content and the destination port set to standard POP3 port (110).
Note: If the username and password are set to Inherit but the group content is empty, the health
check performed for that group is TCP.
A pre-defined imap health check is available for simple IMAP service monitoring. The health check
has the Username and Password parameters set to Inherit, allowing definition using the group
content and the destination port set to standard IMAP port (143).
Note: If the Newsgroup Name is set to Inherit but the group content is empty, the health check
performed for that group is TCP.
A pre-defined nntp health check is available for simple NNTP service monitoring. The health check
has the newsgroup name parameter set to Inherit, allowing definition using the group content and
the destination port set to standard NNTP port (119).
Note: For a RADIUS Authentication health check if the username, password and secret are
unspecified (directly or using the group configuration), the health check performed for that group is
TCP.
Note: In Alteon, all four WAP services are grouped together. If a health check to one of the services
fail on a specific real server, then all four WAP services (9200, 9201, 9202, or 9203) are disabled on
that real server.
The following WAP-specific arguments are available for WSP and WTP health check types:
• Connect message header (mandatory)—Specifies the content for the Connect message used for
unencrypted WTP health check only.
• Sent content (mandatory)—Specifies the content of the packet that is sent to the gateway as a
hexadecimal string, which should include all applicable WSP headers.
• Received content (mandatory)—Specifies the expected response for WTP health checks as a
hexadecimal byte string. Alteon matches each byte of this string with the received content and if
there is a mismatch of even a single byte on the received content, the health check fails.
• Offset—Specifies the offset from which to start search for the Received Content in the UDP data.
• RADIUS Service Dependency—Specifies whether RADIUS accounting service must also be
monitored on the WAP servers. When this parameter is enabled, if the RADIUS service is
unavailable, the server is unavailable.
Note: For unencrypted WSP and WTP WAP health checks, if the mandatory content arguments are
empty, the health check performed for that group is TCP.
Note: If the Username, Password and Base Distinguish Name are set to Inherit, and the group
content is empty, the health check performed for that group is TCP.
Pre-defined ldap and ldaps health checks are available for simple LDAP and LDAPS service
monitoring. The health checks have all the parameters set to Inherit, allowing definition using the
group content.
The Alteon LDAP health check is supported for LDAP version 2 and 3. The LDAP version used is
defined per Alteon by the global flag cfg/slb/advhc/ldapver.
Notes
• Health check scripts can only be set up via the CLI, but once entered, can be assigned as the
health-check method using SNMP or the BBI.
• There is no need to use double slashes when configuring a script in the BBI that uses special
characters with single slashes. For example, the script entry GET /index.html
HTTP/1.1\r\nHOST:www.hostname.com\r\n\r\n does not require the use of \\r or \\n
to ensure proper functioning of the script.
• Only one protocol can be configured per script.
Script Formats
Health check script formats use different commands based on whether the content to be sent is
ASCII-based or binary-based. The close command is used only to close a TCP connection and is not
required if health checking a UDP-based protocol.
Each script should start with the command open <protocol port number>,
<protocol-name>. The next line can be either a send or expect (for ASCII-based), or bsend or
bexpect (binary-based).
open "80,tcp"
bsend " <binary content for request 1> "
nsend " <continuing binary content for request 1> "
bexpect " <binary content for response 1> "
nexpect " <binary content> "
offset " <byte count from the start of the IP header> "
depth "10"
wait "100"
close #(used in TCP-based health checks only)
• For HTTP-based health checks, the first word is the method. The method is usually the get
command. However, HTTP also supports several other commands, including put and head. The
second word indicates the content desired, or request-URI, and the third word represents the
version of the protocol used by the client.
• If you supplied HTTP/1.1 for the protocol version, you would also have to add in the following
line: Host: www.hostname.com
Example
This is known as a host header. It is important to include because most Web sites now require it for
proper processing. Host headers were optional in HTTP/1.0 but are required when you use
HTTP/1.1+.
• In order to tell the application server you have finished entering header information, a blank line
of input is needed after all headers. At this point, the URL will be processed and the results
returned to you.
Note: If you make an error, enter rem to remove the last typed script line entered. If you need
to remove more than one line, enter rem for each line that needs to be removed.
• Alteon includes the “\” prompt, which is one Enter key stroke. When using the send command,
note what happens when you type the send command with the command string. When you type
send, press the Enter key and allow Alteon to format the command string (that is, \ versus
\\).
Scripting Commands
Listed below are the currently available commands for building a script-based health check:
• OPEN—Specify which destination real server UDP port to be used. For example: OPEN 9201.
You can also use Inherit to allow a script to inherit the destination port from the service server
port. This enables the reuse of a script for multiple services. After entering the destination port,
you will be prompted to specify a protocol. Choose udp.
• CLOSE (for TCP-based health checks only)—Close a TCP connection. It is not necessary to use
this command for UDP services.
• SEND—Specify the send content in raw hexadecimal format.
• BSEND (for binary content only)—Specify binary content (in hexadecimal format) for the
request packet.
• NSEND (for binary content only)—Specify an additional binary send value (in hexadecimal
format) at the end of a UDP based health check script. The NSEND command lets the user
append additional content to the packet generated by the BSEND command. Since the current
CLI limit allows a maximum of 256 bytes to be entered, using one or more NSEND commands
will allow binary content of more than 256 bytes in length to be generated.
• EXPECT—Specify the expected content in raw hexadecimal format.
• BEXPECT (for binary content only)—Specify the binary content (in hexadecimal format) to be
expected from the server response packet.
• NEXPECT (for binary content only)—Similar to NSEND, specify additional binary content to be
appended to the original content specified by the BEXPECT command.
• OFFSET (for binary content only)—Specify the offset from the beginning of the binary data area
to start matching the content specified in the EXPECT command. The OFFSET command is
supported for both UDP and TCP-based health checks. Specify the OFFSET command after an
EXPECT command if an offset is desired. If this command is not present, an offset of zero is
assumed.
• DEPTH (for binary content only)—Specify the number of bytes in the IP packet that should be
examined. If no OFFSET value is specified, DEPTH is specified from the beginning of the packet.
If an OFFSET value is specified, the DEPTH counts the number of bytes starting from the offset
value.
• WAIT—Specify a wait interval before the expected response is returned. The wait window
begins when the SEND string is sent from Alteon. If the expected response is received within the
window, the WAIT step passes. Otherwise, the health check fails. The WAIT command should
come after an EXPECT command in the script, or the OFFSET command if one exists after an
EXPECT command. The wait window is in units of milliseconds.
• Wildcard character (*)—Trigger a match as long as a response is received from the server.
The wildcard character is allowed with the BEXPECT command, as in BEXPECT *. Any NEXPECT,
OFFSET, or DEPTH commands that follow a wildcard character will be ignored.
Scripting Guidelines
• Use generic result codes that are standard and defined by the RFC, as applicable. This helps
ensure that if the server software changes, the servers do not start failing unexpectedly.
• Avoid tasks that may take a long time to perform or the health check will fail. For example, avoid
tasks that exceed the interval for load balancing.
open 80
send “GET /index.html HTTP/1.1\\r\\nHOST:www.hostname.com\\r\\n\\r\\n
expect "HTTP/1.1 200
close
open 80
send "GET /index.html HTTP/1.1\\r\\nHOST:www.hostname.com\\r\\n\\r\\n
expect "HTTP/1.1 200
close
open 443
...
close
Notes
• If you are using the CLI to create a health check script, you must use quotes (") to indicate the
beginning and end of each command string.
• When you are using the CLI to enter the send string as an argument to the send command, you
must type two back slahes (“\”) before an “n” or “r”. If you are instead prompted for the line,
that is, the text string is entered after pressing the Return key, then only one “\” is needed
before the “n” or “r”.
Script-based health checking only sends the appropriate requests to the relevant servers. Using the
script as shown in Figure 73 - Example Health Checking Script, page 500, the first GET statement is
only be sent to Real Server 1 and Real Server 2. Going through the health check statements serially
ensures that all content is available by at least one real server on the remote site.
The remote real server IP address (the virtual server IP address of the remote site) accepts “any”
URL requests. The purpose of the first GET in the script is to check if Real Server 1 or Real Server 2
is up. In other words, it checks if the remote site has at least one server for “images” content. Either
Real Server 1 or Real Server 2 responds to the first GET health check.
If all the real server IP addresses are down, Real Server 7 (the virtual server IP address of the
remote site) responds with an HTTP redirect (respond code 302) to the health check. As a result, the
health check fails, as the expected response code is 200, ensuring that the HTTP redirect messages
will not cause a loop.
open 80
send "GET /images/default.asp HTTP/1.1\\r\\nHOST: 192.192.1.2\\r\\n\\r\\n"
expect "HTTP/1.1 200"
close
open 80
send "GET /install/default.html HTTP/1.1\\r\\nHOST: 192.192.1.2\\r\\n\\r\\n"
expect "HTTP/1.1 200"
close
open 80
send "GET /script.cgi HTTP/1.1\\r\\nHOST: www.myurl.com \\r\\n\\r\\n"
expect "HTTP/1.1 200"
close
Note: A maximum of 255 bytes of input are allowed in the CLI. If you send or expect lengthy
content, you may want to remove spaces in between the numbers to save space on the CLI. For
example, type 000101 instead of 00 01 01. Alternately, continue the content using the nsend and
nexpect commands.
>># /info/slb/real 1
1: 205.178.13.225, 00:00:00:00:00:00, vlan 1, port 0, health 4, FAILED
real ports:
script 2, DOWN, current
send GET / HTTP/1.0\r\n\r\n
expect HTTP/1.0 200
In this case, the server is not responding to the get with the expect string.
When the script succeeds in determining the health of a real server, the following information
displays:
>> # /info/slb/real 1
1: 205.178.13.223, 00:00:5e:00:01:24, vlan 1, port 2, health 4, up
real ports:
script 2, up, current
Name Description
link Verifies the status of the interface using the monitored element to
which it is connected. This type of health check is relevant only for
monitoring IDS servers.
arp Monitors server availability using ARP requests.
icmp Checks connectivity to the monitored element using ICMP.
tcp Monitors a TCP service by sending simple TCP requests to the server
port (rport) of a virtual service.
udp Monitors a UDP service by sending a combination of ICMP requests
and simple UDP requests to the server port (rport) of a virtual
service.
http/https Sends an HTTP or HTTPS request to the Web page defined in the
virtual service (hname and dname) and group (content) and expects
a 200 response code.
dhcp Sends a DHCP request determined by the health check content
configuration in the monitored group.
dns Sends a DNS query for domain name configured in the group health
check content to standard TCP DNS port (53).
udpdns Sends a DNS query for domain name configured in the group health
check content to standard UDP DNS port (53).
ftp Attempts an anonymous login to the FTP server and retrieval of the
filename configured in the group health check content.
imap Attempts to login to the IMAP server on the standard port (143)
using the user and password configured in the group health check
content.
ldap/ldapss Attempts to login into an LDAP or LDAPS server and retrieve data
using the parameters configured in the group health check content.
nntp Attempts to access the NNTP server on the standard port (119) and
retrieve the identification line of the newsgroup configured in the
group health check content.
pop3 Attempts to login to the POP3 server on the standard port (110)
using the user and password configured in the group health check
content.
radius-auth Sends RADIUS authentication request using the parameters values
configured in the group health check content and secret.
radius-aa Sends a RADIUS accounting request.
Name Description
radius-any Sends either a RADIUS authentication or a RADIUS accounting
request, depending on the service port. The service port must be the
standard port for either RADIUS Authentication or Accounting.
rtsp Connects to the RTSP server on the standard 554 port and sends an
RTSP request determined by the group health check content value.
sip Sends an SIP ping (proprietary Nortel) request to the real server.
sipoptions Sends an SIP OPTIONS request to the real server.
smtp Attempts to access the SMTP server on the standard port 25 and
verify the validity of the username configured in the group health
check content.
sslh Sends an SSL Hello version 2 to the real server.
sslh3 Sends an SSL Hello version 3 to the real server.
tftp Attempts to connect to the TFTP server on the standard port 69 and
download the file specified in the group health check content using
TFTP.
wsp Monitors unencrypted connection-less WAP service availability,
optionally in conjunction with the RADIUS service.
Note: This health check is editable.
wtls-wsp Monitors encrypted connection-less WAP service availability,
optionally in conjunction with the RADIUS service.
Note: This health check is editable.
wtls-wtp Monitors encrypted connection-oriented WAP service availability,
optionally in conjunction with the RADIUS service.
Note: This health check is editable.
wtls Monitors encrypted connection-less or connection-oriented WAP
service availability, depending on the server port of the virtual
service. If the service port is not standard secure WSP or WTP port
(9202 or 9203), a TCP health check is performed.
wts Monitors WTS (Window Terminal Server) service availability.
Failure Types
This section describes the following failure types:
• Service Failure, page 503
• Server Failure, page 504
Service Failure
If a certain number of connection requests for a particular service fail, Alteon puts the service into
the service failed state. While in this state, no new connection requests are sent to the server for
this service. However, if graceful real server failure is enabled (using /cfg/slb/adv/grace ena),
state information about existing sessions is maintained and traffic associated with existing sessions
continues to be sent to the server. Connection requests to, and traffic associated with, other
load-balanced services continue to be processed by the server.
Example
A real server is configured to support HTTP and FTP within two real server groups. If a session
device detects an HTTP service failure on the real server, it removes that real server group from the
load-balancing algorithm for HTTP, but keeps the real server in the mix for FTP. Removing only the
failed service from load balancing allows users access to all healthy servers supporting a given
service.
When a service on a server is in the service failed state, the Alteon sends Layer 4 connection
requests for the failed service to the server. When Alteon has successfully established a connection
to the failed service, the service is restored to the load-balancing algorithm.
Server Failure
If all load-balanced services supported on a server fail to respond to connection requests within the
specified number of attempts, then the server is placed in the server failed state. While in this
state, no new connection requests are sent to the server. However, if graceful real server failure is
enabled (using /cfg/slb/adv/grace ena), state information about existing sessions is
maintained and traffic associated with existing sessions continues to be sent to the server.
All load-balanced services on a server must fail before Alteon places the server in the server failed
state.
The server is brought back into service as soon as the first service is proven to be healthy. Additional
services are brought online as they are subsequently proven to be healthy.
Note: The DSR VIP health check (cfg/slb/group/viphlth) is enabled by default. This has no
effect on the health check unless the real server is configured with DSR.
Examples
A (1|2)&(3|4)
Real servers 1, 2, 3, and 4 are configured in group 1 and assigned to virtual service x in Virtual
Server 1. The boolean expression is used to calculate the status of a virtual service using group
1 based on the status of the real servers.
Virtual service x of Virtual Server 1 is marked UP if Real Servers 1 or 2 and Real Servers 3 or 4
are health checked successfully.
B (1&2)|(2&3)|(1&3)
Real servers 1, 2, and 3 are configured in Group 2 and assigned to virtual service x in Virtual
Server 1. The boolean expression is used to calculate the status of the virtual service using
Group 2 based on the status of the real servers.
Virtual service x of Virtual Server 1 is marked UP only if at least two of the real servers are
health checked successfully.
VRRP Overview
VRRP eliminates single points of failure within a network. The protocol supports redundant router
configurations within a LAN, providing alternate router paths for a host.
In a high availability network topology, no device should be a single point of failure for the network
or cause a single point of failure in any other part of the network. This means that a network
remains in service despite the failure of any single device. To achieve this usually requires
redundancy for all vital network components.
Each participating VRRP-capable routing device is configured with the same virtual router IP address
and ID number. One of the virtual routers is elected as the master, based on a number of priority
criteria, and assumes control of the shared virtual router IP address. If the master fails, one of the
backup virtual routers takes control of the virtual router IP address and actively processes traffic
addressed to it.
Because the router associated with a given alternate path supported by VRRP uses the same IP
address and MAC address as the routers for other paths, the host's gateway information does not
change, no matter which path is used. A VRRP-based redundancy schema reduces administrative
overhead because hosts do not need to be configured with multiple default gateways.
Note: The IP address of a VRRP virtual interface router (VIR) and virtual server router (VSR) must
be in the same IP subnet as the interface to which it is assigned.
Component Description
VRRP router A physical router running VRRP.
Virtual router Two or more VRRP routers can be configured to form a virtual router (as
defined in RFC 2338). Each VRRP router may participate in one or more
virtual routers. Each virtual router consists of a user-configured virtual
router identifier (VRID) and an IP address.
Virtual router MAC The VRID is used to build the virtual router MAC address.
address • For legacy-based MAC addresses, the five highest-order octets of the
virtual router MAC address are the standard MAC prefix (00-00-5E-
00-01) defined in RFC 2338. The VRID is used to form the lowest-
order octet.
• If HAID is non-zero, the MAC address is 00:03:B2:78:XX:XX.
• If HAID=0 for IPv4, the MAC address is 00:00:5E:00:01:XX.
• If HAID=0 for IPv6, the MAC address is 00:00:5E:00:02:XX.
Virtual interface IP A VRRP router in a virtual router whose virtual interface router's IP
address owner address matches the real interface address. This router responds to
packets addressed to the virtual interface router's IP address for ICMP
pings, TCP connections, and so on.
Only one of the VRRP routers in a virtual interface router may be
configured as the IP address owner. There is no requirement for any VRRP
router to be the IP address owner. Most VRRP installations choose not to
implement an IP address owner.
If the owner is not available, the backup becomes the master and takes
responsibility for packet forwarding and responding to Address Resolution
Protocol (ARP) requests. However, because this Alteon is not the owner, it
does not have a real interface configured with the virtual interface router's
IP address.
Virtual interface IP A VRRP router in a virtual router that is not the IP address owner.
address renter
Virtual router master Within each virtual router, one VRRP router is selected to be the virtual
router master. If the IP address owner is available, it always becomes the
virtual router master. For an explanation of the selection process, see How
VRRP Priority Decides Which Alteon is the Master, page 509.
The master forwards packets sent to the virtual interface router. It also
responds to Address Resolution Protocol (ARP) requests sent to the virtual
interface router's IP address. The master also sends out periodic
advertisements to let other VRRP routers know it is alive, and its priority.
Virtual router backup A VRRP router within a virtual router not selected to be the master. If the
virtual router master fails, one of the virtual router backups becomes the
master and assumes its responsibilities.
VRRP Priority
This section describes the following topics:
• How VRRP Priority Decides Which Alteon is the Master, page 509
• Transitioning from the INIT State Based on VRRP Priority, page 509
• Determining How to Configure Priority, page 509
• Determining VRRP Priority for Ports Outside the VLAN, page 510
Note: If communication links between the master and the backup are down, but the master is
healthy, Alteon may select a second master within the virtual router. To prevent this, configure
redundant links between the VRRP devices within the virtual router.
Alteon 1 has its real interface configured with the IP address of the virtual interface router, making it
the IP address owner. As the IP address owner, it receives a priority of 255, and is the virtual router
master.
Alteon 2 is a virtual router backup. Its real interface is configured with an IP address that is on the
same subnet as the virtual interface router, but is not the IP address of the virtual interface router.
The virtual interface router is assigned a VRID of 1. Both of the VRRP routers have a virtual router
MAC address of 00-00-5E-00-01-01.
With sharing enabled, an IP interface or a VIP address can be active simultaneously on multiple
Alteons, enabling active-active operation as shown in Figure 74 - Virtual Interface Router
Configuration, page 511 and Table 47 - Active-Active Failover with Shared Interfaces, page 512:
When sharing is used, incoming packets are processed by the Alteon on which they enter the virtual
router. The ingress Alteon is determined by external factors, such as routing and Spanning Tree
configuration.
Sharing cannot be used in configurations where incoming packets have more than one entry point
into the virtual router. For example, where a hub is used to connect Alteons.
When sharing is enabled, the master election process still occurs. Although the process does not
affect which Alteon processes packets that must be routed or that are destined for the virtual server
IP address, it does determine which Alteon sends advertisements and responds to ARP requests sent
to the virtual router's IP address.
Radware strongly recommends that sharing, rather than active-standby configurations, be used
whenever possible. Sharing offers both better performance and fewer service interruptions in the
face of fault conditions than active-standby configurations. See Active-Active Redundancy, page 527
for a configuration example.
Note: For a vrgroup to work correctly, you must first set virtual router tracking for one of the virtual
routers configured for that group using the cfg/l3/vrrp/vrgroup/trackvr command. You can
only set tracking for one virtual router in a vrgroup.
As shown in the example in Figure 76 - Service-Based Virtual Router Groups Configuration, page
513, an administrator wants to provide high availability for Customer A and Customer B's servers
and services across the same two Alteons, without one affecting the other:
• Customer A's traffic load balances across real servers in Real Server Group 1.
• Customer B's traffic load balances across real servers in Real Server Group 2.
Each Alteon is configured with vrgroup 1 for Customer A, and vrgroup 2 for Customer B.
Because each vrgroup is tracked independently of the other, vrgroup 1 can fail over to its equivalent
vrgroup 1 on the other Alteon while not affecting the VRRP state of vrgroup 2.
See Tracking VRRP Router Parameters, page 515 for a configuration example.
Note: A switch-based virtual router group cannot be used for active-active configurations or any
other configuration that requires shared interfaces.
For more information on using switch-based VRRP groups with hot standby, see Hot Standby
Configuration, page 537.
Note: Tracking only affects hot standby and active-standby configurations. It does not have any
effect on active-active sharing configurations.
Each tracked parameter is associated with a user-configurable weight. As the count associated with
each tracked item increases (or decreases), so does the VRRP router's priority, subject to the
weighting associated with each tracked item. If the priority level of a backup is greater than that of
the current master, then the backup can assume the role of the master.
For an example on how to configure Alteon for tracking VRRP priority, see Tracking Virtual Routers,
page 542.
If failover occurs on a customer link, only the group of virtual routers associated with that
customer's vrgroup will fail over to the backup. Other vrgroups configured for other customers do
not fail over. For example, if a vrgroup is configured to track ports, a port failure will decrease the
priority of the vrgroup. The lowered priority causes this vrgroup to fail over to its equivalent vrgroup
on the other Alteon.
For an example on how to configure Alteon for tracking VRRP priority, see Service-Based Virtual
Router Groups, page 543.
In this example, VRRP is configured as active-active. Both Alteons are OSPF-enabled and receive
traffic. The following is a further explanation of Figure 77 - OSPF VRRP Topology Using Cost
Updating, page 517:
1. The cost of the first Alteon is less than the cost of the second Alteon.
2. Mobile clients send traffic from network 20.20.20.x through the first Alteon to GGSN on network
30.30.30.x.
3. Alteon intercepts and redirects the traffic based on the HTTP policy of the 10.10.11.x network.
4. The 10.10.10.x network does not appear in the OSPF routing and is accessed only by Alteon.
5. If the link between the first Alteon and the 10.10.11.x network fails, OSPF is not affected
because the interface of the 10.10.10.X network is not bound to OSPF.
6. The traffic passes from the mobile clients to the first Alteon and the service is interrupted.
7. If the link fails when the traffic returns from the servers in the 10.10.10.x network, traffic
returns through the second Alteon. This causes an asymmetric routing traffic flow.
VRRP cost update support does not require any changes to the OSPF settings. The VRRP
functionality is part of the existing tracking options. This enables OSPF to remain a pure routing
protocol regardless of the services running on top of it.
OSPF maintains a cost value per interface flexibility designed for routers creating deterministic
paths. In the example in Figure 77 - OSPF VRRP Topology Using Cost Updating, page 517, the
traffic flow is handled as a service with path dependencies. That is, the service paths are related and
affect one another.
You can set the OSPF cost increment for the VR (single interface), VR group (multiple interface), and
group (multiple interface). For more information on configuring the OSPF cost, refer to the Alteon
Application Switch Operating System Command Reference.
The link-local unicast address is an address used to communicate with neighbors on the same
link. The source address of an IPv6 VRRP packet is set to the IPv6 link-local address of the
transmission interface.
• Multicast address—The IPv6 multicast address is an identifier for a group interface. IPv6 VRRP
support has an IPv6 link-local scope multicast address assigned by IANA. This multicast address
follows the format FF02:0:0:0:0:0:XXXX:XXXX. The destination address of the IPv6 packet
is set to this link-local scope multicast address. A router must not forward a datagram with this
destination address regardless of its hop limit setting.
Note: Radware recommends setting the default to 100 (1 second) or greater to avoid a high load on
the management CPU.
• The Hop Limit field is used to track how many nodes have forwarded the packet. The field value
is decremented by one for each node that forwards the packet. VRRP routers are instructed to
discard IPv6 VRRP packets that do not have a Hop Limit value of 255.
• The Next Header field is used to identify the type of protocol immediately following the IPv6
header. The IPv6 Next Header assigned by IANA for VRRP is 112.
• The neighbor discovery protocol replaces IPv4 ARP, ICMP router discovery, and ICMP redirection.
Neighbor discovery enables nodes (hosts and routers) to determine the link-layer address of a
neighbor on the same network and to detect any changes in these addresses. It also enables a
router to advertise its presence and address prefix to inform hosts of a better next hop address
to forward packets.
Notes
• You cannot use IPv6 VRRP groups with more than 90 virtual routers.
• The VRRP3 VRID for IPv6 VRRP configuration has a range of 1 to 255.
Note: The current configurations described in this section are valid without session synchronization.
Active-Standby Redundancy
This section describes the following topics:
• Active-Standby Environments, page 521
• Configuring Active-Standby Redundancy, page 522
Active-Standby Environments
In an active-standby configuration, the active switch supports all traffic or services. The backup
switch acts as a standby for services on the active master switch. If the master switch fails, the
backup switch takes over processing for all services. The backup switch may forward Layer 2 and
Layer 3 traffic, as appropriate.
Radware recommends that you do not allow sharing between the Alteon devices. Without sharing,
only the active Alteon performs load balancing. This is a very robust configuration that does not
require dedicated interswitch links (ISL), or hotstandby settings on ports.
Note: The configuration does not require dedicated interswitch links (ISL), or hotstandby
settings on ports.
2. Enable IP forwarding. For more information, see To enable IP forwarding, page 523.
3. Configure two interfaces, one for each VLAN. For more information, see To configure Layer 3
physical interface settings, page 523.
4. Configure virtual routers—one for each interface, and one for each service. For more
information, see To configure Layer 3 virtual router settings for VLANs, page 524.
5. Define each service on a virtual server, and associate each service with a virtual router. For more
information, see To configure Layer 3 virtual router settings for services, page 526.
6. Add all virtual routers to a VRRP group. For more information, see To configure VRRP grouping
for virtual routers, page 527.
Grouping virtual routers enables you to easily give them a common status (active or standby). A
virtual router can belong to one VRRP group only.
2. Repeat for other Spanning Tree groups. Alteon supports up to 16 Spanning Tree groups.
To enable IP forwarding
IP forwarding is enabled by default. Make sure IP forwarding is enabled if the virtual server IP
addresses and real server IP addresses are on different subnets, or if the device is connected to
different subnets and those subnets need to communicate through the device. If you are not sure
whether to enable IP forwarding, enable it as follows:
>> Main # /cfg/l3/if 1/addr 10.10.10.253 (Set the IP address for the interface)
>> Main # /cfg/l3/if 1/mask 255.255.255.0 (Set the subnet mask for the interface)
>> Main # /cfg/l3/if 1/vlan 10 (Set the VLAN number for the
interface)
>> Main # /cfg/l3/if 2/addr 10.10.20.253 (Set the IP address for the interface)
>> Main # /cfg/l3/if 2/mask 255.255.255.0 (Set the subnet mask for the interface)
>> Main # /cfg/l3/if 2/vlan 20 (Set the VLAN number for the
interface)
2. On the standby Alteon, configure two more interfaces and associate a different VLAN with each
interface.
Each interface has a unique IP address.
>> Main # /cfg/l3/if 1/addr 10.10.10.252 (Set the IP address for the interface)
>> Main # /cfg/l3/if 1/mask 255.255.255.0 (Set the subnet mask for the interface)
>> Main # /cfg/l3/if 1/vlan 10 (Set the VLAN number for the
interface)
>> Main # /cfg/l3/if 2/addr 10.10.20.252 (Set the IP address for the interface)
>> Main # /cfg/l3/if 2/mask 255.255.255.0 (Set the subnet mask for the interface)
>> Main # /cfg/l3/if 2/vlan 20 (Set the VLAN number for the
interface)
>> Main # /cfg/l3/vrrp/vr 1/prio 101 (Set the priority bias for the virtual
router)
>> Main # /cfg/l3/vrrp/vr 1/addr 10.10.10.254 (Set the virtual router IP address)
>> Main # /cfg/l3/vrrp/vr 2/prio 101 (Set the priority bias for the virtual
router)
>> Main # /cfg/l3/vrrp/vr 2/addr 10.10.20.254 (Set the virtual router IP address)
2. On the standby Alteon, copy these active Alteon settings, but lower the priority of each virtual
router.
>> Main # /cfg/l3/vrrp/vr 1/prio 100 (Set the priority bias for the virtual
router)
>> Main # /cfg/l3/vrrp/vr 1/addr 10.10.10.254 (Set the virtual router IP address)
>> Main # /cfg/l3/vrrp/vr 2/prio 100 (Set the priority bias for the virtual
router)
>> Main # /cfg/l3/vrrp/vr 2/addr 10.10.20.254 (Set the virtual router IP address)
>> Main # /cfg/slb/virt 1/vip 10.10.10.200 (Set the virtual server virtual IP)
2. On the active Alteon, configure a different virtual router for each service.
>> Main # /cfg/l3/vrrp/vr 4/prio 101 (Set the priority bias for the virtual
router)
>> Main # /cfg/l3/vrrp/vr 4/addr 10.10.10.200 (Set the virtual server IP address)
3. On the standby Alteon, copy these active Alteon settings, but lower the priority of each virtual
router.
>> Main # /cfg/l3/vrrp/vr 4/prio 100 (Set the priority bias for the virtual
router)
>> Main # /cfg/l3/vrrp/vr 4/addr 10.10.10.200 (Set the virtual server IP address)
>> Main # /cfg/l3/vrrp/group/prio 101 (Set the priority base for all virtual
routers in the VRRP group)
>> Main # /cfg/l3/vrrp/group/share dis (Disable sharing for the VRRP group
and all the virtual routers in the group)
2. On the standby Alteon, define the same VRRP group with a lower base priority.
>> Main # /cfg/l3/vrrp/group/prio 100 (Set the priority base for all virtual
routers in the VRRP group)
>> Main # /cfg/l3/vrrp/group/share dis (Disable sharing for the VRRP group
and all the virtual routers in the group)
Active-Active Redundancy
This section describes the following topics:
• Active-Active Environments, page 527
• Configuring Active-Active Redundancy, page 529
Active-Active Environments
This configuration is based on proprietary Alteon extensions to VRRP.
Alteon has extended VRRP features to include virtual servers, allowing full active-active redundancy
between its Layer 4 devices. In an active-active configuration, both switches can process traffic for
the same service at the same time. Both switches share interfaces at Layer 3 and Layer 4, meaning
that both switches can be active simultaneously for a given IP routing interface or load-balancing
virtual server (VIP).
This configuration is often used to allow two different data centers located at different locations to
have different Internet access paths.
Since both sites work independently, these virtual routers are not grouped, and priority is not
dynamically changed by tracking.
In an active-active configuration, the active switch supports all traffic or services. The backup switch
acts as a standby for services on the active master switch. If the master switch fails, the backup
switch takes over processing for all services. The backup switch may forward Layer 2 and Layer 3
traffic, as appropriate.
Alteon supports active-active redundancy in a shared or a non-shared environment.
• In a shared (or service-based) environment, two Alteon devices are used. Both devices support
active traffic but are configured so that they do not simultaneously support the same service.
Each Alteon is active for its own set of services, such as IP routing interfaces or load balancing
virtual server IP addresses, and acts as a standby for other services on the other Alteon. If
either Alteon fails, the remaining Alteon takes over processing for all services. The backup may
forward Layer 2 and Layer 3 traffic, as appropriate.
• In a non-shared (or switch-based) environment, two Alteon devices are used as VRRP routers,
implementing a virtual server router (VSR). The active switch supports all traffic or services. The
backup switch acts as a standby for services on the active master switch. If the master switch
fails, the backup switch takes over processing for all services. The backup switch may forward
Layer 2 and Layer 3 traffic, as appropriate. When both devices are healthy, only the master
responds to packets sent to the virtual server IP address. This is a very robust solution that
allows up to 100% of throughput.
This environment is suitable for configurations that cannot support sharing of interfaces at Layer
3 and Layer 4. This includes configurations where incoming packets are seen by more than one
device, such as instances where a hub is used to connect the devices.
Figure 78 - Active-Standby Configuration, page 522 shows an active-active configuration in a non-
shared environment. In this example, there are two VLANs, each with its own interface. There are
four virtual servers. Each virtual server runs a unique service.
In this configuration, when both devices are healthy, the load-balanced packets are sent to the
virtual server IP address (205.178.13.226 in Figure 78 - Active-Standby Configuration, page 522),
resulting in higher capacity and performance than when the devices are used in an active-standby
configuration.
The Alteon device on which a frame enters the virtual server router is the one that processes that
frame. The ingress device is determined by external factors, such as routing and STP settings.
Note: Each VRRP-capable device is autonomous. There is no requirement that the devices in a
virtual router be identically configured. Different Alteon models with different numbers of ports and
different enabled services may be used in a virtual router.
Note: In this configuration, each server's backup is attached to the other device. This ensures
that operation continues if all of the servers attached to a device fail.
In this configuration, if a link between a device and a server fails, the server fails health checks
and its backup (attached to the other device) goes online. If a link between a device and its
Internet router fails, the protocol used to distribute traffic between the routers (for example,
OSPF) reroutes traffic to the other router. Since all traffic enters the virtual server router on one
device, that device processes all incoming connections.
If an entire master device fails, the backup detects this failure because it no longer receives
advertisements. The backup assumes the master's responsibility of responding to ARP requests
and issuing advertisements.
For more information, see To configure the second Alteon device, page 534.
Note: The maxconn metric is not shared between devices. Therefore, if a server is used for normal
operation by one device and is activated simultaneously as a backup by the other device, the total
number of possible connections to that server is the sum of the maximum connection limits defined
for it on both devices.
Note: In Alteon, you may configure more than one subnet per VLAN.
To configure the IP interfaces for this example, enter the following commands from the CLI:
To configure SLB
In this procedure, you perform the following:
• Define real servers
• Define real server groups
• Define virtual servers
• Define client and server port states
1. Define the real servers.
The real server IP addresses are defined and put into four groups, depending on the service they
are running. Notice that RIPs 7 and 8 are on routable subnets in order to support passive FTP.
For each real server, you must assign a real server number, specify its actual IP address, and
enable the real server:
Repeat this sequence of commands for the following real server groups:
— Group 2—Add RIP 3 and 4
— Group 3—Add RIP 5 and 6
— Group 4—Add RIP 7 and 8
3. Define the virtual servers.
After defining the virtual server IP addresses and associating them with a real server group
number, you must define which IP ports, services, or sockets you want to load balance on each
VIP. You can specify the service by either the port number, service name, or socket number:
Notes
• The ports connected to the upstream devices (the ones connected to the routers) need to be in
the client port state.
• The ports connected to the downstream devices (the ones providing fan out for the servers)
need to be in the server port state.
Apply this sequence of commands to the following virtual routers, assigning each a priority of
101:
— VR 2—Priority 101
— VR 3—Priority 101
— VR 4—Priority 101
4. Configure priority tracking parameters for each virtual router. For this example, the best
parameter to track is Layer 4 ports (l4pts):
This command sets the priority tracking parameter for Virtual Router 1, electing the virtual
router with the most available ports as the master router. Repeat this command for the following
virtual routers:
— VR 2 - Track l4ptsVR 6 - Track l4pts
— VR 3 - Track l4ptsVR 7 - Track l4pts
— VR 4 - Track l4ptsVR 8 - Track l4pts
Configuration for Alteon device 1 is complete.
e. Change the virtual router priorities. Virtual routers 1 through 4 need to have their priority
set to 100 from 101, and virtual routers 5 through 7 need to have their priorities set to 101
from 100. You can find this in the line /cfg/l3/vrrp/vr 1/vrid 1/if 1/prio 101.
f. Scroll to the bottom of the text file and delete anything past Script End.
g. Save the changes to the text file as <Customer Name> Alteon 2.
3. Move your serial cable to the console port on the second device. Any configuration on it needs to
be deleted by resetting it to factory settings, using the following command:
You can tell if the device is at factory default when you log in because it will prompt you if you
want to use the step-by-step configuration process. When it does, respond No.
Note: After completing the setup you cannot proceed further without configuring the ports. To
configure ports enter y, or enter n to ignore.
4. In HyperTerminal, go to transfer/send text file and send the Alteon 2 text file. The configuration
dumps into the device. Type apply, then save. When you can type characters in the terminal
session again, reboot the device (/boot/reset).
Note: Alteon considers a trunk port failed and changes its priority only when all the ports in the
trunk are down.
Note: When a hot standby port is not part of a VLAN assigned to a vADC, Alteon does track the port
for VRRP priority.
Notes
• A port cannot be configured to support both hot standby and interswitch links.
• The interswitch setting for hot standby is not the same as Cisco's ISL protocol.
To set the state for links that attach to the standby Alteon
When the hotstan option is enabled and all hot standby ports have a link, the virtual router group's
priority is incremented by the track other virtual routers value. This lets the Alteons fail over
when a hot standby port loses a link. Other enabled tracking features have an effect only when all
hot standby ports on Alteon have a link. The default virtual routers tracking value is 2 seconds. This
is an automatic process that cannot be turned off.
Note: All ports with hot standby enabled must be connected to another Alteon.
To set the state for links that are used by VRRP to deliver updates
The hot standby Alteon listens to the master's VRRP updates. After an interval has expired without
receiving a update, the backup takes over. The forwarding states of hot standby ports are controlled
much like the forwarding states of the hot standby (hotstan) approach. Enabling hot standby on a
port allows the hot standby algorithm to control the forwarding state of the port. If an Alteon is the
master, the forwarding states of the hot standby ports are enabled. If an Alteon is a backup, the hot
standby ports are blocked from forwarding or receiving traffic.
Note: The VRRP hot standby approach does not support single-link failover. If one hot standby port
loses a link, the entire Alteon must become the master to eliminate loss of connectivity.
The forwarding states of non-hot standby ports are not controlled via the hot standby algorithm,
allowing the additional ports to provide added port density. The client ports on both Alteons should
be able to process or forward traffic to the master.
The interswitch port state is only a place holder. It forces you to configure an interswitch link when
hot standby is globally enabled and prohibits the interswitch link from also being a hot standby link
for VRRP advertisements. These advertisements must be able to reach the backup Alteon.
Note: To use hot standby redundancy, Alteon peers must have an equal number of ports.
The key to hot standby is that the interswitch link does not participate in STP, so there are no loops
in the topology (see Hot Standby Configuration, page 537). You have to disable STP globally to use
the VRRR hot standby scenario.
Note: In a host-standby configuration, Radware recommends that you locate the server and the
interswitch link on the same VLAN. This ensures that services are in the UP state for both the master
as well as the backup.
The following procedures refer to Figure 80 - Hot Standby Configuration, page 537:
• To configure Layer 2 and Layer 3 parameters on Alteon 1, page 538
• To configure virtual router redundancy, page 539
• To prepare a configuration script for Alteon 2, page 540
• To synchronize Layer 4 parameters from Alteon 1 to Alteon 2, page 542
>> Main# cfg/port 3/tag ena (Enable VLAN tagging for Port 3 )
>> Main# /cfg/l2/vlan 172 (VLAN 172 is for th einterswitch link
and for server traffic)
>> VLAN 172# ena (Enable the VLAN)
>> VLAN 172# name ISL_and_servers (Name VLAN 172 for the interswitch
link and for server traffic)
>> VLAN 172# add 3 (Add Port 3 to VLAN 172)
>> VLAN 172# add 4 (Add Port 4 to VLAN 172)
2. From the VRRP menu, enable VRRP group mode and hot standby on all connected ports except
the interswitch link.
Note: When you enable hot standby for a vrgroup, the currently set priority for the vrgroup is
increased by 2.
5. From the SLB menu, enable a hot standby link on the Layer 4 ports, then enable the interswitch
link on the crosslink.
2. Copy and paste the entire contents of the script to a text file. The first and last lines of the file
must be written as shown in the following example:
script start "Alteon Application Switch" 4 /**** DO NOT EDIT THIS LINE!
>> Configuration#
/c/l3/if 1
addr 10.0.1.252
— Change the synchronization peer Alteon to use the IP address of Alteon 1. In this example,
change the last octet from .252 (denoting Alteon 2), to .251 (Alteon 1).
/c/slb/sync/peer 1
ena
addr 172.16.2.251
— Change the virtual router priority from 100 to 101. This indicates that Alteon 2 is the backup
for now.
/c/l3/vrrp/group
:
prio 101
4. Save the changes to the text file as Customer-Name_backup_config and load it onto a TFTP
server.
5. Begin a Telnet session for the second Alteon. Delete any existing configuration on it by resetting
it to factory settings, using the following command:
Note: If you are prompted to use the step-by-step configuration process when you log in,
Alteon is set to the factory defaults. When prompted, enter No.
6. From the CLI, download the configuration script into Alteon from the TFTP server using the
following command:
Note: Alteons that are peers of one another should have an equal number of ports.
4. On both Alteons, enable tracking based on the number of healthy real servers behind the VIP
address. The VIP address is the same as the IP address of the virtual server router on Alteon.
Set the value to 6.
Initially, Alteon 1 has a priority of 100 (base value), plus 5 (initially it is the master), plus 24 (4
active real servers multiplied by 6, per real server), resulting in 129.
Alteon 2 has a priority of 96 (base value), plus 24 (4 active real servers multiplied by 6, per real
server), resulting in 120.
If a server attached to Alteon 1 fails, then the priority for Alteon 1 is reduced by 6, resulting in
123. Since 123 is greater than 120 (the priority for Alteon 2), Alteon 1 remains the master.
If a second server attached to Alteon 1 fails, then the priority for Alteon 1 is reduced by 6 more,
resulting in 117. Since 117 is less than 120 (the priority for Alteon 2), then Alteon 2 becomes
the master. At this point, the priority for Alteon 1 will falls by 5 more, and the priority for Alteon
2 rises by 5, because the Alteons are tracking how many masters they are running. As a result,
the priority for Alteon 1 results in 112, and the priority for Alteon 2 results in 125.
When both servers are restored to Alteon 1, its priority rises by 12 (2 healthy real servers
multiplied by 6, per healthy server), resulting in 124. Because 124 is less than 125, Alteon 2
remains the master.
If, at this point, a server fails on Alteon 2, its priority falls by 6, resulting in 119. Because 119 is
less than 124, Alteon 1 becomes the master. Its priority results in 129, since it is now the
master, while the priority for Alteon 2 drops by 5 more, resulting in 114.
Tip: There is no shortcut to setting tracking parameters. Your goals must first be set and the
outcomes of various configurations and scenarios analyzed to find settings that meet your goals.
4. Configure virtual interface routers 1 and 3, and make sure to disable sharing.
These virtual routers are assigned the same IP address as the IP interfaces configured in step 1,
resulting in Alteon recognizing these as virtual interface routers (VIRs). In this example, Layer 3
bindings are left in their default configuration (disabled). For an active-standby configuration,
sharing is disabled.
9. Synchronize the SLB and VRRP configurations from Alteon 1 with Alteon 2.
Use the /oper/slb/sync command (see Configuring VRRP Peers for Synchronization,
page 569).
/cfg/port 1
pvid 3
/cfg/port 2
pvid 2
/cfg/port 3
tagged ena
pvid 911
/cfg/port 4
tagged ena
pvid 911
/cfg/l2/vlan 2
ena
name "server"
learn ena
def 2,3,4
/cfg/l2/vlan 3
ena
name "client"
learn ena
def 1,3,4
/cfg/l2/vlan 911
ena
name "intersw"
learn ena
def 3,4
cfg/l2/trunk 1
ena
add 3
add 4
/cfg/l2/stg 1/off
/cfg/l2/stg 1/add 1 2 3 911
— Interface configuration:
/cfg/l3/if 2
ena
ipver v6
addr 2000:2:2:0:0:0:0:a
mask 96
vlan 2
/cfg/l3/if 3
ena
ipver v6
addr 3000:3:3:0:0:0:0:a
mask 96
vlan 3
/cfg/l3/if 254
ena
ipver v4
addr 192.168.0.1
mask 255.255.255.0
broad 192.168.0.255
vlan 911
/cfg/l3/gw 1
ena
ipver v6
addr 3000:3:3:0:0:0:0:c
— VRRP configuration:
/cfg/l3/vrrp/on
/cfg/l3/vrrp/vr 2
ena
ipver v6
vrid 2
if 2
addr 2000:2:2:0:0:0:0:fff0
share dis
/cfg/l3/vrrp/vr 3
ena
ipver v6
vrid 3
if 3
addr 3000:3:3:0:0:0:0:ffff
share dis
/cfg/l3/vrrp/group
ena
ipver v6
vrid 254
if 2
share dis
track ports
/cfg/slb
on
/cfg/slb/adv
direct ena
/cfg/slb/real 1 ena
ipver v6
rip 2000:2:2:0:0:0:0:1001
/cfg/slb/real 2
ena
ipver v6
rip 2000:2:2:0:0:0:0:1002
/cfg/slb/group 1
ipver v6
add 1
add 2
/cfg/slb/virt 1
ena
ipver v6
vip 3000:3:3:0:0:0:0:ffff
vname "v6http"
/cfg/slb/virt 1/service http
group 1
/cfg/slb/port 1
client ena
hotstan en
/cfg/slb/port 2
server ena
hotstan en/
cfg/slb/port 3
intersw ena
vlan 400
/cfg/slb/port 4
intersw ena
vlan 400
— Synchronization configuration:
/cfg/slb/sync
prios d
/cfg/slb/sync/peer 1
ena
addr 192.168.0.2
2. Alteon B configuration:
— Layer 2 (port and VLAN) and Layer 3 (interface) configuration:
/cfg/port 1
pvid 3
/cfg/port 2
pvid 2/
cfg/port 3
tagged ena
pvid 911
/cfg/port 4
tagged ena
pvid 911
/cfg/l2/vlan 2
ena
name "server"
learn ena
def 2,3,4
/cfg/l2/vlan 3
ena
name "client"
learn ena
def 1,3,4
/cfg/l2/vlan 911
ena
name "intersw"
learn ena
def 3,4
/cfg/l2/trunk 1
ena
add 3
add 4
/cfg/l2/stg 1/off
/cfg/l2/stg 1/add 1 2 3 911
— Interface configuration:
/cfg/l3/if 2
ena
ipver v6
addr 2000:2:2:0:0:0:0:b
mask 96
vlan 2
/cfg/l3/if 3
ena
ipver v6
addr 3000:3:3:0:0:0:0:b
mask 96
vlan 3
/cfg/l3/if 255
ena
ipver v4
addr 192.168.0.2
mask 255.255.255.0
broad 192.168.0.255
vlan 911
/cfg/l3/gw 1
ena
ipver v6
addr 3000:3:3:0:0:0:0:c
— VRRP configuration:
/cfg/l3/vrrp/on
/cfg/l3/vrrp/vr 2
ena
ipver v6
vrid 2
if 2
addr 2000:2:2:0:0:0:0:fff0
share dis/
cfg/l3/vrrp/vr 3
ena
ipver v6
vrid 3
if 3
addr 3000:3:3:0:0:0:0:ffff
share dis
/cfg/l3/vrrp/group
ena
ipver v6
vrid 254
if 2
share dis
track ports
/cfg/slb
on
/cfg/slb/adv
direct ena
/cfg/slb/real 1
ena
ipver v6
rip 2000:2:2:0:0:0:0:1001
/cfg/slb/real 2
ena
ipver v6
rip 2000:2:2:0:0:0:0:1002
/cfg/slb/group 1
ipver v6
add 1
add 2
/cfg/slb/virt 1
ena
ipver v6
vip 3000:3:3:0:0:0:0:ffff
vname "v6http"
/cfg/slb/virt 1/service http
group 1
/cfg/slb/port 1
client ena
hotstan en/
cfg/slb/port 2
server ena
hotstan en
/cfg/slb/port 3
intersw ena
vlan 400
/cfg/slb/port 4
intersw ena
vlan 400
— Synchronization configuration:
/cfg/slb/sync
prios d
/cfg/slb/sync/peer 1
ena
addr 192.168.0.1
Active-Standby Configuration
Figure 83 - Active-Standby Configuration Example, page 555 illustrates an active-standby
configuration between two Alteon units. The following are considerations for a IPv6 active-standby
configuration:
• Layer 2 (port and VLAN) configuration:
— Each VLAN must be configured per interface.
• Layer 3 interface and VRRP configuration:
— In this example, tracking is performed by Layer 4 ports so that the two virtual routers fail
over when one of the master virtual routers declares itself as the backup.
/cfg/port 1
pvid 3
/cfg/port 2
pvid 2
/cfg/port 3
pvid 911
/cfg/l2/vlan 2
ena
name "server"
learn ena
def 2
/cfg/l2/vlan 3
ena
name "client"
learn ena
def 1
/cfg/l2/vlan 911
ena
name "intersw"
learn ena
def 3
— Interface configuration:
/cfg/l3/if 2
ena
ipver v6
addr 2000:2:2:0:0:0:0:a
mask 96
vlan 2
/cfg/l3/if 3
ena
ipver v6
addr 3000:3:3:0:0:0:0:a
mask 96
vlan 3
/cfg/l3/if 254
ena
ipver v4
addr 192.168.0.1
mask 255.255.255.0
broad 192.168.0.255
vlan 911
/cfg/l3/gw 1
ena
ipver v6
addr 3000:3:3:0:0:0:0:c
— VRRP configuration:
/cfg/l3/vrrp/on
/cfg/l3/vrrp/vr 2
ena
ipver v6
vrid 2
if 2
addr 2000:2:2:0:0:0:0:fff0
share dis
track
l4pts ena
/cfg/l3/vrrp/vr 3
ena
ipver v6
vrid 3
if 3
addr 3000:3:3:0:0:0:0:ffff
share dis
track
l4pts ena
/cfg/slb
on
/cfg/slb/adv
direct ena
/cfg/slb/real 1
ena
ipver v6
rip 2000:2:2:0:0:0:0:1001
/cfg/slb/real 2
ena
ipver v6
rip 2000:2:2:0:0:0:0:1002
/cfg/slb/group 1
ipver v6
add 1
add 2
/cfg/slb/virt 1
ena
ipver v6
vip 3000:3:3:0:0:0:0:ffff
vname "v6http"
/cfg/slb/virt 1/service http
group 1
/cfg/slb/port 1
client ena
/cfg/slb/port 2
server ena
— Synchronization configuration:
/cfg/slb/sync
prios d
/cfg/slb/sync/peer 1
ena
addr 192.168.0.2
2. Alteon-B configuration:
— Layer 2 (port and VLAN) and Layer 3 (interface) configuration:
/cfg/port 1
pvid 3
/cfg/port 2
pvid 2
/cfg/port 3
pvid 911
/cfg/l2/vlan 2
ena
name "server"
learn ena
def 2
/cfg/l2/vlan 3
ena
name "client"
learn ena
def 1
/cfg/l2/vlan 911
ena
name "intersw"
learn ena
def 3
— Interface configuration:
/cfg/l3/if 2
ena
ipver v6
addr 2000:2:2:0:0:0:0:b
mask 96
vlan 2
/cfg/l3/if 3
ena
ipver v6
addr 3000:3:3:0:0:0:0:b
mask 96
vlan 3
/cfg/l3/if 255
ena
ipver v4
addr 192.168.0.2
mask 255.255.255.0
broad 192.168.0.255
vlan 911
/cfg/l3/gw 1
ena
ipver v6
addr 3000:3:3:0:0:0:0:c
— VRRP configuration:
/cfg/l3/vrrp/on
/cfg/l3/vrrp/vr 2
ena
ipver v6
vrid 2
if 2
addr 2000:2:2:0:0:0:0:fff0
share dis
track
l4pts ena
/cfg/l3/vrrp/vr 3
ena
ipver v6
vrid 3
if 3
addr 3000:3:3:0:0:0:0:ffff
share dis
track
l4pts ena
/cfg/slb
on
/cfg/slb/adv
direct ena
/cfg/slb/real 1
ena
ipver v6
rip 2000:2:2:0:0:0:0:1001
/cfg/slb/real 2
ena
ipver v6
rip 2000:2:2:0:0:0:0:1002
/cfg/slb/group 1
ipver v6
add 1
add 2
/cfg/slb/virt 1
ena
ipver v6
vip 3000:3:3:0:0:0:0:ffff
vname "v6http"
/cfg/slb/virt 1/service http
group 1
/cfg/slb/port 1
client ena
/cfg/slb/port 2
server ena
— Synchronization configuration:
/cfg/slb/sync
prios d
/cfg/slb/sync/peer 1
ena
addr 192.168.0.1
Active-Active Configuration
Figure 84 - Active-Active Configuration Example, page 561 illustrates an active-active configuration
between two Alteons. The following are considerations for a IPv6 active-active configuration:
1. Layer 2 (port and VLAN) configuration:
— Each VLAN must be configured per interface.
2. Layer 3 interface and VRRP configuration:
— In this example, tracking is performed by Layer 4 ports so that the two virtual routers fail
over when one of the master virtual routers declare itself as the backup.
/cfg/port 1
pvid 3
/cfg/port 2
pvid 2
/cfg/port 3
pvid 911
/cfg/l2/vlan 2
ena
name "server"
learn ena
def 2
/cfg/l2/vlan 3
ena
name "client"
learn ena
def 1
/cfg/l2/vlan 911
ena
name "intersw"
learn ena
def 3
— Interface configuration:
/cfg/l3/if 2
ena
ipver v6
addr 2000:2:2:0:0:0:0:a
mask 96
vlan 2
/cfg/l3/if 3
ena
ipver v6
addr 3000:3:3:0:0:0:0:a
mask 96
vlan 3
/cfg/l3/if 254
ena
ipver v4
addr 192.168.0.1
mask 255.255.255.0
broad 192.168.0.255
vlan 911
/cfg/l3/gw 1
ena
ipver v6
addr 3000:3:3:0:0:0:0:c
— VRRP configuration:
/cfg/l3/vrrp/on
/cfg/l3/vrrp/vr 2
ena
ipver v6
vrid 2
if 2
addr 2000:2:2:0:0:0:0:fff0
share en
track
l4pts ena
/cfg/l3/vrrp/vr 3
ena
ipver v6
vrid 3
if 3
addr 3000:3:3:0:0:0:0:ffff
share en
track
l4pts ena
/cfg/slb
on
/cfg/slb/real 1
ena
ipver v6
rip 2000:2:2:0:0:0:0:1001
/cfg/slb/real 2
ena
ipver v6
rip 2000:2:2:0:0:0:0:1002
/cfg/slb/group 1
ipver v6
add 1
add 2
/cfg/slb/virt 1
ena
ipver v6
vip 3000:3:3:0:0:0:0:ffff
vname "v6http"
/cfg/slb/virt 1/service http
group 1
/cfg/slb/port 1
client ena
hotstan en
/cfg/slb/port 2
server ena
hotstan en
/cfg/slb/port 3
intersw ena
vlan 400
/cfg/slb/port 4
intersw ena
vlan 400
— Synchronization configuration:
/cfg/slb/sync
prios d
/cfg/slb/sync/peer 1
ena
addr 192.168.0.2
2. Alteon B configuration:
— Layer 2 (port and VLAN) and Layer 3 (interface) configuration:
/cfg/port 1
pvid 3
/cfg/port 2
pvid 2
/cfg/port 3
pvid 911
/cfg/l2/vlan 2
ena
name "server"
learn ena
def 2
/cfg/l2/vlan 3
ena
name "client"
learn ena
def 1
/cfg/l2/vlan 911
ena
name "intersw"
learn ena
def 3
— Interface configuration:
/cfg/l3/if 2
ena
ipver v6
addr 2000:2:2:0:0:0:0:b
mask 96
vlan 2
/cfg/l3/if 3
ena
ipver v6
addr 3000:3:3:0:0:0:0:b
mask 96
vlan 3
/cfg/l3/if 255
ena
ipver v4
addr 192.168.0.2
mask 255.255.255.0
broad 192.168.0.255
vlan 911
/cfg/l3/gw 1
ena
ipver v6
addr 3000:3:3:0:0:0:0:c
— VRRP configuration:
/cfg/l3/vrrp/on
/cfg/l3/vrrp/vr 2
ena
ipver v6
vrid 2
if 2
addr 2000:2:2:0:0:0:0:fff0
share en
track
l4pts en
/cfg/l3/vrrp/vr 3
ena
ipver v6
vrid 3
if 3
addr 3000:3:3:0:0:0:0:ffff
share en
track
sl4pts en
/cfg/slb
on
/cfg/slb/real 1
ena
ipver v6
rip 2000:2:2:0:0:0:0:1001
/cfg/slb/real 2
ena
ipver v6
rip 2000:2:2:0:0:0:0:1002
/cfg/slb/group 1
ipver v6
add 1
add 2
/cfg/slb/virt 1
ena
ipver v6
vip 3000:3:3:0:0:0:0:ffff
vname "v6http"
/cfg/slb/virt 1/service http
group 1
/cfg/slb/port 1
client ena
hotstan en
/cfg/slb/port 2
server ena
hotstan en
/cfg/slb/port 3
intersw ena
vlan 400
/cfg/slb/port 4
intersw ena
vlan 400
— Synchronization configuration:
/cfg/slb/sync
prios d
/cfg/slb/sync/peer 1
ena
addr 192.168.0.1
One drawback to using STP with VRRP is the failover response time. STP could take as long as 45
seconds to re-establish alternate routes after an Alteon or link failure.
This topology allows STP to be disabled. On the Alteons, IP routing allows traffic to cross VLAN
boundaries. The servers use the Alteons as default gateways. For port failure, traffic is rerouted to
the alternate path within one health check interval (configurable between 1 and 60 seconds, with a
default of 2 seconds).
Note: Before you synchronize the configuration between two Alteons, a peer must be configured on
each Alteon. Alteons that are synchronized must use the same administrator password.
Note: Port specific parameters, such as which filters are applied and enabled on which ports, are
part of what is pushed by the /oper/slb/sync command. Therefore, if you use the /oper/slb/
sync command is used, Radware recommends that the hardware configurations and network
connections of all Alteons in the virtual router be identical. This means that each Alteon should be
the same model, have the same line cards in the same slots (if modular), and have the same ports
connected to the same external network devices. Otherwise, unexpected results may occur when
the /oper/slb/sync command attempts to configure a non-existent port or applies an
inappropriate configuration to a port.
You can define whether or not to synchronize certificate repository components by enabling cfg/
slb/sync/certs. By default, this option is disabled. When certificate repository synchronization is
enabled, you are required to set a passphrase to be used during the configuration synchronization
for the encryption of private keys (cfg/slb/sync/passphrs). The same passphrase should be set
manually by the administrator in all VRRP members for private key decryption.
To encrypt or decrypt certificate private keys during configuration synchronization, the same
passphrase must be set at all peer devices.
The sync command copies the following settings to Alteon at the specified IP interface address:
• VRRP settings (including priority)
• SLB settings (including port settings)
• Filter settings (including filter port settings)
• Proxy IP settings
If you use the sync command, you should check the configuration on the target Alteon to ensure
that the settings are correct.
Note: When using both VRRP and GSLB, you must change the /cfg/sys/access/wport
(Browser-Based Interface port) value of the target Alteon (the Alteon to which you are
synchronizing) to a port other than port 80 before VRRP synchronization begins.
Note: Stateful failover is not supported in active-active mode. Also, stateful failover does not
synchronize all sessions, except persistent sessions (SSL session ID persistence and cookie-based
persistence). If a service fails in the middle of a connection, the current session is discarded, but the
new connection binds the session request correctly to the same real server.
To provide stateful failover, the state of the connection and session table must be shared between
Alteon in high availability configurations. If the Virtual Matrix Architecture (VMA) is enabled, all URL
and cookie-parsing information is stored in the session table on the last port number on Alteon.
Sharing this information between Alteons is necessary to ensure the persistent session goes back to
the same server.
Stateful failover only ensures that the client's request returns to the same server based on the
persistent session entries being shared by the master and the slave Alteon. The TCP session
information, however, is not shared.
Figure 88: Stateful Failover Example when the Master Alteon Fails
This procedure is based on Figure 88 - Stateful Failover Example when the Master Alteon Fails, page
572.
1. On the master:
a. Enable stateful failover.
The update does not have to be the same for both Alteons. Stateful failover supports up to
two peers. Repeat the steps mentioned above to enable stateful failover on all the peers.
c. Configure the master as a peer and specify its IP address.
• If Alteon is a backup:
Similar to a standalone Alteon, the vADCs must share a broadcast domain in order to send the
session updates the neighboring vADC.
Figure 89 - Service-Based Session Failover for Hot Standby Configurations, page 575 illustrates a
service-based session failover network topology:
When a new session is created on the master, the session entry is sent to the backup using NAAP.
The backup creates the session and sets the age to a maximum age. This prevents the session from
aging out on the backup and prevents frequent updates between the master and backup. When the
session is updated or deleted on the master, the session on the backup is also updated or deleted.
When the master becomes a backup due to reboot or link failure, it sends a session sync message to
the new master. The new master mirrors all the sessions that need to be mirrored to the backup. To
avoid performance impact, all sessions are not sent at the same time. A timer routine is used to
mirror the sessions. In each round, a maximum of 1024 sessions are sent to the backup.
After the request is sent, the timer routine is disabled with reset flag sfo_sync_req_flg.
• On the receipt of the sync message, the master invokes a response timer routine with one
second time interval.
After the master sends all the sessions to the backup, the total number of synced sessions are
logged with a syslog.
Limitations
• The feature is supported only in group-based active-standby and hot standby VRRP
configurations.
• The following filters and protocols are supported:
— SIP
— FTP (when ftpp is disabled under cfg/slb/virt/service)
— Layer 4 SLB with delayed binding
— NAT filters
• The following filters and protocols are not supported:
— Active-active VRRP
— RTSP
— Layer 7 SLB
— Allow/deny/redir filters
Recommendations
• Ensure a direct interswitch link between the master and backup, as NAAP packets cannot be
routed.
• The same priorities on all Alteons.
• Preemption enabled.
• Layer 4 switch port tracking enabled (/cfg/l3/vrrp/vr/track/l4pts).
• A holdoff interval of at least 3 seconds (/cfg/l3/vrrp/holdoff ).
Note: Due to the difference in the amount of physical memory and session capacity between
different Alteon models, not all sessions can be synchronized. Session synchronization works
correctly if the same model Alteons are used in VRRP HA topologies.
/cfg/l3/vrrp/autosmir
Figure 90 - Session Failover for Active-Standby Configurations, page 579 illustrates a service-based
session failover network topology for active-standby configurations.
Peer Synchronization
Starting with version 28.0, you can define up to five (5) peers for each ADC-VX. This enables you to
plan your system according to considerations such as risk, resource availability and internal
organizational priorities. For more information on vADCs, see ADC-VX Management, page 403.
Figure 91 - Example Peer Synchronization Topology, page 580is an example topology for a set of
Alteons that use peer synchronization:
To configure peers
1. From the Peer Switch menu, define the address settings of the Global Administrator
environment for the peer you want to configure.
You can associate vADCs with the range option. You can enter a combination of single vADCs
and ranges of vADCs. For example: 1, 3-5, 8
Note: For a description of these menu options, see the Alteon Application Switch Operating
System Command Reference.
>> # /cfg/sys/sync/peer
Enter peer switch number (1-5):1
------------------------------------------------------------
[Peer Switch 1 Menu]
addr - Set peer switch IP address
ena - Enable peer switch
dis - Disable peer switch
range - Set synchronization target for a range of vADCs
del - Delete peer switch
cur - Display current peer switch configuration
2. Apply and save. After setting peer switch addresses, vADC configuration is synchronized to the
assigned peers.
>> # /cfg/vadc/sys/sync/
Enter vADC Number [1-28]:1
[Peer Switch Addresses]
Peer switch 1: 10.1.1.1, enabled
Peer switch 2: 20.1.1.1, enabled
Peer switch 3: 30.1.1.1, enabled
Peer switch 4: 40.1.1.1, enabled
Peer switch 5: 0.0.0.0 , disabled
Enter peer switch number (1-5):1
------------------------------------------------------------
2. Enter the peer switch number you want to associate to the selected vADC.
3. Apply and save. After setting peer switch addresses, vADC configuration is synchronized to the
assigned peers.
Overview of Persistence
In a typical SLB environment, traffic comes from various client networks across the Internet to the
virtual server IP address on Alteon. Alteon then load balances this traffic among the available real
servers.
In any authenticated Web-based application, it is necessary to provide a persistent connection
between a client and the content server to which it is connected. Because HTTP does not carry any
state information for these applications, it is important for the browser to be mapped to the same
real server for each HTTP request until the transaction is completed. This ensures that the client
traffic is not load balanced mid-session to a different real server, forcing the user to restart the
entire transaction.
Persistence-based SLB lets you configure the network to redirect requests from a client to the same
real server that initially handled the request. Persistence is an important consideration for
administrators of e-commerce Web sites, where a server may have data associated with a specific
user that is not dynamically shared with other servers at the site.
In Alteon, persistence can be based on:
• Using Source IP Address, page 584
• Using Cookies, page 584
• Using SSL Session ID, page 584
Using Cookies
Cookies are strings passed via HTTP from servers to browsers. Based on the mode of operation,
cookies are inserted by either Alteon or the server. After a client receives a cookie, a server can poll
that cookie with a GET command, which allows the querying server to positively identify the client as
the one that received the cookie earlier.
Cookie-based persistence solves the proxy server problem and gives better load distribution at the
server site. In Alteon, cookies are used to route client traffic back to the same physical server to
maintain session persistence.
Note: If the cookie expiration time is greater than the /cfg/slb/virt x/service x/ptmout
value, timed-out requests will not be persistent.
Note: SSL session ID persistence is not supported when SSL offloading is enabled and other more
advanced persistency features, such as cookie persistency, are available.
HTTPS traffic only) from the same client to map to the same server, as long as the same group is
configured for both services. In Alteon, when the metric configured is hash, phash, or minmisses,
persistence may also be maintained to the real server port (rport), in addition to the real server.
You should disable persistence to the rport on the following conditions:
• When there are two different services, such as TCP and UDP, that must maintain persistence to
the same real server.
• When client IP-based persistence is not dependent on the load balancing metric.
3. Select Client IP-based persistence as the persistent binding option for the virtual port.
If multiple real server ports are configured for this service, you may choose whether to maintain
persistence to the rport on the real server.
Cookie-Based Persistence
Cookies are a mechanism for maintaining the state between clients and servers. When the server
receives a client request, the server issues a cookie, or token, to the client, which the client then
sends to the server on all subsequent requests. Using cookies, the server does not require
authentication, the client IP address, or any other time-consuming mechanism to determine that the
user is the same user that sent the original request.
In the simplest case, the cookie may be just a "customer ID" assigned to the user. It may be a token
of trust, allowing the user to skip authentication while his or her cookie is valid. It may also be a key
that associates the user with additional state data that is kept on the server, such as a shopping cart
and its contents. In a more complex application, the cookie may be encoded so that it actually
contains more data than just a single key or an identification number. The cookie may contain the
user's preferences for a site that allows their pages to be customized.
Note: If the cookie expiration time is greater than the /cfg/slb/virt x/service x/ptmout
value, timed-out requests will not be persistent.
Figure 92 - Cookie-Based Persistence, page 586 illustrates how cookie-based persistence works:
The following topics discussing cookie-based persistence are discussed in this section:
• Permanent and Temporary Cookies, page 586
• Cookie Formats, page 587
• Cookie Properties, page 587
• Client Browsers that Do Not Accept Cookies, page 587
• Cookie Modes of Operation, page 588
• Configuring Cookie-Based Persistence, page 591
Note: When both cookie-based pbind is used and HTTP modifications on the same cookie header
are defined, Alteon performs both. This may lead to various application behaviors and should be
done with caution.
cookie is only valid for the current browser session. Similar to a SSL session-based ID, the
temporary cookie expires when you shut down the browser. Based on RFC 2109, any cookie without
an expiration date is a temporary cookie.
Cookie Formats
A cookie can be defined in the HTTP header (the recommended method) or placed in the URL for
hashing. The cookie is defined as a "Name=Value" pair and can appear along with other parameters
and cookies. For example, the cookie "SessionID=1234" can be represented in one of the following
ways:
• In the HTTP Header:
Cookie: SesssionID=1234
Cookie: ASP_SESSIONID=POIUHKJHLKHD
Cookie: name=john_smith
The second cookie represents an Active Server Page (ASP) session ID. The third cookie
represents an application-specific cookie that records the name of the client.
• Within the URL
http://www.mysite.com/reservations/SessionID=1234
Cookie Properties
Cookies are configured by defining the following properties:
• Cookie names of up to 20 bytes.
• The offset of the cookie value within the cookie string.
For security, the real cookie value can be embedded somewhere within a longer string. The
offset directs Alteon to the starting point of the real cookie value within the longer cookie string.
• Length of the cookie value. This defines the number of bytes to extract for the cookie value
within a longer cookie string.
• Whether to find the cookie value in the HTTP header (the default) or the URL.
• Cookie values of up to 64 bytes for hashing. Hashing on cookie values is used only with the
passive cookie mode (Passive Cookie Mode, page 590), using a temporary cookie. Alteon
mathematically calculates the cookie value using a hash algorithm to determine which real
server should receive the request.
• An asterisk (*) in cookie names for wildcards. For example: Cookie name = ASPsession*
• Domain name—If configured, cookies are sent only to the domain, using the following
commands:
• Cookie path—If the cookie path is configured, the cookie is sent only for URL requests that are
a subset of the path. The path defaults to "/".
• Secure flag—If the secure flag is set, the client is required to use a secure connection to obtain
content associated with the cookie.
• Relative timer—This timer defines the elapsed time from when the cookie was created. The
syntax for the relative timer is days[:hours[:minutes]]. For example:
Alteon adds or subtracts hours according to the time zone settings using the /cfg/sys/ntp/
tzone command. When the relative expiration timer is used, ensure the tzone setting is set
correctly. If NTP is disabled (using /cfg/sys/ntp/off ), the tzone setting still applies to the
cookie mode.
Note: If the cookie expiration timer is not specified, the cookie will expire when the user's
session ends.
Note: Radware recommends passive cookie mode for temporary cookies. However, you can use this
mode for permanent cookies if the server is embedding an IP address. In this case, a cookie has to
be eight characters long, and every two characters represent one byte of IP address encoded in
hexadecimal.
Figure 94 - Passive Cookie Mode, page 590 illustrates passive cookie mode operation:
Subsequent requests from Client 1 with the same cookie value are sent to the same real server (RIP
1 in this example).
When passive cookie persistence mode is enabled, Alteon creates persistent entries for server
returned responses with new cookie values within the same TCP connection.
Note: Rewrite cookie mode only works for cookies defined in the HTTP header, not cookies defined
in the URL.
Figure 95 - Rewrite Cookie Mode, page 591 illustrates the rewrite cookie mode operation:
Note: When Alteon rewrites the value of the cookie, the rewritten value represents the responding
server. This means that the value can be used for hashing into a real server ID or it can be the real
server IP address. The rewritten cookie value is encoded.
3. Server processing is not required if using proxy IP addresses, so optionally you can disable it.
4. Select the appropriate load-balancing metric for the real server group.
After you specify cookie as the persistence mode, you are prompted for the following
parameters:
CLI Capture
When you issue the command /cfg/slb/virt <virtual#>/service <service#>/pbind,
additional inputs taken from the user are listed in the output:
The last parameter in this command answers the "Look for cookie in URI?" prompt. If you
set this parameter to disable, Alteon uses UID=87654321 as the cookie.
The last "Look for cookie in URI?" parameter is set to enable. As a result, Alteon uses
UID=12345678 as the cookie.
This command directs Alteon to use the sid cookie, starting with the first byte in the value, and
using the full 28 bytes.
B Select a specific portion of the sid cookie as a hashing key for selecting the real server
This command directs Alteon to use the sid cookie, starting with the eighth byte in the value,
and using only four bytes. This uses 789a as a hashing key.
C Using wildcards for selecting cookie names
With this configuration, Alteon looks for a cookie name that starts with ASPSESSIONID.
ASPSESSIONID123, ASPSESSIONID456, and ASPSESSIONID789 are seen as the same
cookie name. If more than one cookie matches, only the first one is used.
Notes
• The SSL session ID can only be read after the TCP three-way handshake. In order to make a
forwarding decision, Alteon must terminate the TCP connection to examine the request.
• SSL session ID persistence is not supported when SSL offloading is enabled and other more
advanced persistency features, such as cookie persistency, are available.
Some versions of Web browsers allow the session ID to expire every two minutes, thereby breaking
the SSL ID persistence. To resolve this issue, use persistency with metric hash or pbind
clientip.
Note: The destination port number to monitor for SSL traffic is user-configurable.
Alteon also has set of SSL offloading features for manipulating SSL traffic. For more information, see
Offloading SSL Encryption and Authentication, page 337.
• Session IDs are kept on Alteon until an idle time equal to the configured server timeout (a
default of 10 minutes) for the selected real server has expired.
Figure 96 - SSL Session ID-Based Persistence, page 597 illustrates persistence based on the SSL
session ID, as follows:
1. An SSL Hello handshake occurs between Client 1 and Server 1 via Alteon.
2. An SSL session ID is assigned to Client 1 by Server 1.
3. Alteon records the SSL session ID.
4. Alteon selects a real server based on the existing SLB settings. As a result, subsequent
connections from Client 1 with the same SSL session ID are directed to Server 1.
5. Client 2 appears to have the same source IP address as Client 1 because they share the same
proxy firewall.
However, Alteon does not direct Client 2 traffic to Server 1 based on the source IP address.
Instead, an SSL session ID for the new traffic is assigned. Based on SLB settings, the connection
from Client 2 is spliced to Server 3. As a result, subsequent connections from Client 2 with the
same SSL session ID are directed to Server 3.
For information on how to configure your network for SLB, see Server Load Balancing, page 165.
2. If a proxy IP address is not configured on the client port, enable DAM for real servers.
3. Select session ID-based persistence as the persistent binding option for the virtual port.
>> # /cfg/slb/virt <virtual server number> /service <virtual port> pbind sslid
Note: If the dedicated session director does not exist to relate users to disconnected sessions,
Radware recommends enabling the userhash functionality to perform this task.
Note: If you purchased the Advanced DoS protection option, enable it by typing /oper/swkey and
entering its software key.
• Background, page 601—Describes the rationale for providing Advanced DoS protection and how
it can assist traditional firewalls in preventing malicious network attacks.
• IP Address Access Control Lists, page 602—Describes how to setup blocking of large ranges of
IP addresses.
• Protection Against Common Denial of Service Attacks, page 604—Explains how to prevent
common DoS attacks from entering ports that are connected to unsafe networks.
• Protocol-Based Rate Limiting, page 611—Explains how to monitor and limit incoming UDP, ICMP
or TCP traffic within a configurable time window.
• Protection Against UDP Blast Attacks, page 617—Describes how to monitor and limit traffic on
UDP ports to a maximum number of connections per second.
• TCP or UDP Pattern Matching, page 618—Describes how to match on binary or ASCII patterns
embedded in IP packets, and combine them into pattern groups which can be applied to a filter
to deny traffic containing those patterns.
Background
The Advanced DoS feature set extends the Alteon functionality to act as an application-intelligent
firewall. You can use these features to perform deep inspection and blocking of malicious content.
For example, many newer viruses, worms, malicious code, applications with security bugs, and
cyber attacks have targeted application and protocol weaknesses by tunneling through a firewall
over HTTP port 80, or by encapsulating attacks into SSL tunnels. Such packets can pass undetected
through standard network firewalls, which are configured only to open or close access to HTTP port
80. Many of the attacks (such as nullscan, xmascan, scan SYNFIN) are created with purposely
malformed packets that include illegal fields in the IP headers.
4. When an attack pattern is matched, Alteon drops this packet, and creates a session so that
subsequent packets of the same session (if it is TCP) are also dropped without going through
additional rule inspection.
>> /stats/security/ipacl/dump
IP ACL stats:
Source IP ACL hits: 3
Source IP Addr Mask Type
--------------- --------------- -----
192.168.1.0 255.255.255.0 cfg
Note: To determine which DoS attack types a port is guarding against, view the current
settings by using the command /cfg/security/port <port number>/cur.
4. Repeat step 1 and step 2 to apply DoS protection to any other ports.
5. Apply and save the configuration.
>> /stats/security/dos/dump
---------------------------------------------------------------------------
Protocol anomaly and DoS attack prevention statistics for port 1:
Protocol anomaly and DoS attack prevention statistics for port 8
broadcast : 1
loopback : 8
land : 1
ipptl : 1
ipprot : 1
fragmoredont: 1
fragdata : 2
fragboundary: 2
fraglast : 1
fragdontoff : 1
fragoff : 1
fragoversize: 1
tcplen : 4
tcpportzero : 2
blat : 1
nullscan : 1
fullxmasscan: 1
finscan : 1
vecnascan : 5
xmasscan : 1
synfinscan : 1
synfrag : 1
ftpport : 1
dnsport : 1
seqzero : 1
ackzero : 1
udplen : 2
udpportzero : 2
fraggle : 1
snmpnull : 1
icmplen : 2
smurf : 1
icmpdata : 1
igmplen : 2
igmpfrag : 1
arpnbcast : 21
------
Totals : 77
Specific subtotals are given for only those ports that are seeking attack traffic.
>> /stats/security/dos/help
Once DoS protection is enabled on the appropriate ports, Alteon performs checks on incoming
packets, as described in Table 50.
To display a brief explanation of any of the DoS attacks that Alteon guards against
• UDP and ICMP Rate Limiting—Counts all received packets from a client and compares
against the configured maximum threshold. When the maximum configured threshold has been
reached before the time window expires, Alteon drops until the configured holddown period
expires. For more information, see UDP and ICMP Rate Limiting, page 613.
Holddown Calculation
hold_down = holddur X slowage_time
where
• holddur = the value entered using /cfg/slb/filt <filter number> /adv/security/
ratelim/holddur
• slowage_time = 2 X 2^slowage
Holddown Periods
Alteon monitors the number of new TCP connections (for TCP rate limiting) or UDP/ICMP packets
received (for UDP/ICMP rate limiting). When the number of new connections or packets exceeds the
configured limit, any new TCP connection requests or UDP/ICMP packets from the client are blocked.
When blocking occurs, the client is said to be held down. The client is held down for a specified
number of minutes, after which new TCP connection requests or packets from the client are allowed
once again to pass through.
Note: The time window and hold duration can be configured individually on a per-filter basis.
The holddown period is a multiple of the slowage and holddur values. For more information about
these values, see the Alteon Application Switch Operating System Command Reference. The total
holddown period is the result of the holddur value multiplied by the slowage value.
Note: The rate limit defined in step 3 and step 4 as the maximum number of connections over
a specified time window results in 30 TCP connections for every three seconds (or 10 TCP
connections per second).
If a client exceeds the rate limit, then the client is not allowed to make any new TCP connections
or UDP/ICMP packets for 4 minutes. The following two configuration examples illustrate how to
use protocol-based rate limiting to limit user access based on source IP address and virtual IP
address.
6. Repeat step 1 through step 5 to configure other filters.
7. Apply and save the configuration.
>> /cfg/security/udpblast
>> UDP Blast Protection# add
Enter UDP port number (1 to 65535) or range (first-last): 1001-2000
Enter max packet rate per second (1 to 20000000): 1000
>> UDP Blast Protection# add
Enter UDP port number (1 to 65535) or range (first-last): 2001-4000
Enter max packet rate per second (1 to 20000000): 2000
>> UDP Blast Protection# add
Enter UDP port number (1 to 65535) or range (first-last): 4001-6000
Enter max packet rate per second (1 to 20000000): 5000
Alteon supports up to 5000 UDP port numbers, using any integer from 1 to 65535. For the entire
port range, the difference between the highest port number and the lowest port number must
be less than or equal to 5000.
2. Enable UDP blast protection on the ports that are connected to unsafe networks.
Note: The ability to match and perform filter action on a pattern or group of patterns is available
only when you enable the Security Pack software.
Pattern Criteria
Many TCP or UDP attacks contain common signatures or patterns in the IP packet data. Alteon can
be configured to examine an IP packet from either the beginning, from a specific offset value
(starting point) within the IP packet, and/or from a specified depth (number of characters) into the
IP packet. It then performs a matching operation.
Figure 100 - IP Packet Format, page 619 illustrates an IP packet format. Alteon is able to track from
the beginning of the IP packet (at the IP version number), through an IP packet payload of 1500
bytes. Each row in an IP packet is four bytes.
>> /cfg/slb/layer7/slb/addstr
Value Description
Pattern A pattern can be a regular expression string pattern in ASCII characters, or a binary
pattern in hexadecimal notation. For more information on using regular expressions
to match pattern data, see Regular Expression Matching, page 803.
If the pattern is binary, specify the binary pattern in hexadecimal notation. For
example, to specify the binary pattern 1111 1100 0010 1101, enter FC2D.
Offset An offset value is the byte count from the start of the IP header, from which a
search or compare operation is performed. An offset value is always required when
the creating pattern strings, even if the desired value is zero (0).
For example, if an offset of 12 is specified, Alteon starts examining the hexadecimal
representation of a binary string from the 13th byte. In the IP packet, the 13th byte
starts at the source IP address portion of the IP payload.
Value Description
Depth Depth is the number of bytes in the IP packet that should be examined from either
the beginning of the packet or from the offset value. For example, if an offset of 12
and a depth of 8 is specified, the search begins at the 13th byte in the IP packet,
and matches 8 bytes. An offset of 12 and depth of 8 encompasses the source IP
address and destination IP address fields in the IP payload.
If no depth is specified in ASCII matches, the exact pattern is matched from the
offset value to the end of the pattern. A depth must be specified for binary matches
that are larger than the pattern length in bytes.
Operation An operation tells Alteon how to interpret the pattern, offset, and depth criteria.
• For a string pattern, use the operation eq (equals) to match the content of the
string.
• Use the operations to find values lt (less than), gt (greater than), or eq (equals)
to the specified binary value. If no operation is specified, the pattern is invalid.
The lt and gt operators can be used for certain attack signatures in which one or
more bytes are less than or greater than a certain value.
Note: The pattern group matching feature is available only if you have purchased and enabled the
Advanced Denial of Service Protection software key.
Alteon supports multi-packet inspection. This allows for the inspection of multiple patterns across
multiple packets in a session. Filtering actions will be taken only after matching all the patterns in
the same given sequence.
For example, assume a chain consisting of multiple patterns numbered 1 through 4. The incoming
packets of the session are first searched for pattern 1. Once pattern 1 of the chain is matched,
subsequent packets of the session are searched for pattern 2 and, if matched, pattern 3 is searched
for and so on, until all the patterns in the chain are matched. The filter action is taken after patterns
1 through 4 are matched.
Note: A reset frame is sent to the destination device when a Layer 7 deny filter is matched instead
of waiting for a server side timeout. This releases the TCP connection in the destination device.
Similarly, any time a TCP packet is denied, a reset frame is sent.
>> /cfg/slb/layer7/slb/addstr
Enter type of string [l7lkup|pattern]: pattern (Add the first pattern)
Enter match pattern type [ascii|binary]: binary
(Select binary matching)
Enter HEX string: 014F (For this binary pattern)
Enter offset in bytes from start of IP frame (0- (Starting from third byte)
1500): 2
Enter depth in bytes to search from offset (0- (Search length of the pattern
1500): 0 )
Enter operation (eq|gt|lt): eq (For values equal to this binary
pattern)
>> Server Loadbalance Resource# add (Add the second pattern)
ID SLB String
1 ida
2 %c1%9c
3 %c0%af
4 playdog.com
6 HTTPHDR:Host:www.playdog.com
7 HTTPHDR:SoapAction=*
8 BINMATCH=014F, offset=2, depth=0, op=eq, cont 256
9 STRMATCH=/default.htm offset=44, depth=30, op=eq, cont 256
3. From the Security menu, configure a pattern group and name it something relevant and easy to
remember.
4. Add the new pattern/offset pairs to the pattern group using their ID numbers.
Refer back to step 2, where you typed the cur command, if you need to recall the ID number
associated with the SLB string.
5. Configure a filter and its appropriate protocol in which the patterns are found.
>>/cfg/slb/filt 90
>>Filter 90 # proto tcp
8. Apply the pattern group you configured in step 3 and step 4 to the filter.
9. Enable pattern matching on the filter. This command enables Layer 7 lookup on the filter.
10. Apply the filter to the client port. If the incoming client requests enter Alteon on port 3, then add
this filter to port 3.
Note: The matchall command is configurable only for binary or ASCII patterns added to pattern
groups (pgroup). It does not apply to l7lkup filter strings configured with the /cfg/slb/layer7/
slb/addstr command.
Now, both patterns configured in Matching and Denying a UDP Pattern Group, page 621 must be
matched before a packet is denied and dropped.
ID SLB String
8 BINMATCH=014F, offset=2, depth=0, op=eq, cont 256
9 STRMATCH=/default.htm offset=44, depth=30, op=eq, cont 256
>> /cfg/slb/layer7/slb/addstr
Enter type of string [l7lkup|pattern]: pattern (Add the pattern)
Enter match pattern type [ascii|binary]: binary (Select binary matching)
Enter HEX string: 0000 (non-zero IP offset)
Enter offset in bytes from start of IP frame (0-1500): (Search from seventh byte)
6
Enter depth in bytes to search from offset (0-1500): 0 (Through end of pattern)
Enter operation (eq|gt|lt): gt (For values greater than 0000)
ID SLB String
1 ida
2 %c1%9c
3 %c0%af
4 playdog.com
6 HTTPHDR:Host:www.playdog.com
7 HTTPHDR:SoapAction=*
ID SLB String
8 BINMATCH=014F, offset=2, depth=0, op=eq, cont 256
9 STRMATCH=/default.htm offset=44, depth=30, op=eq, cont 256
10 BINMATCH=0000, offset=6, depth=0, op=gt, cont 256
11 BINMATCH=4000, offset=6, depth=0, op=lt, cont 256
5. In the Security menu, configure a pattern group and name it something relevant and easy to
remember.
7. Configure a filter and its appropriate protocol in which the patterns are found. In this case, the
ICMP protocol should be specified.
9. Set the ICMP message type. Ping of Death uses the ICMP message type echoreq.
10. Apply the pattern group you configured in step 5 and step 6 to the filter.
12. Enable matchall criteria so that the filter matches on all patterns in the pattern group.
13. Apply the filter to the client port. This example assumes a client connection on port 22.
Monitor Mode
In monitor mode, Alteon dumps the SIP header information to the Management Processor (MP) for
analysis. This dump can be used for troubleshooting.
The following is an example set of monitoring messages that are displayed on the console:
Dependent Mode
You can configure two dependent rules for a rule. When rules contain dependent rules, the rule is
matched only when its dependent rules are matched. It checks only the dependent rules for a
match.
Alteon is in the inspection path until it finds a match. When multiple rules are matched, Alteon takes
the action of the highest severity rule. If the highest severity rule contains dependent rules, and if
the dependent rules are not matched, Alteon takes the action of the next highest severity rule that
does not contain dependent rules. Alteon takes the action of the highest severity rule only when all
its dependent rules are matched.
To configure FlexiRules
1. Create the rule.
/cfg/slb/layer7/rule 1/hdrfld
from|to|replyto|via|method|reqline|callid|cseq|contact|expires|contentlen|sdpco
ntent
/cfg/slb/layer7/rule 1/severity 1
5. Assign contract for this rule (1 to 1024). For information about creating contracts, see
Bandwidth Management, page 761.
/cfg/slb/layer7/rule 1/contract 2
6. Define the message. This message appears in the log when the rule is matched.
/cfg/slb/layer7/rule 1/ena
/cfg/slb/filt/adv/layer7/sip/sips ena
/cfg/slb/filt/adv/security/pmatch ena
10. Add the filter on the port. Enable filter on the server port if reverse lookup for SIP UDP rule is
configured.
2. Create Rule 1.
addrule 100
addrule 99
After creating the rules, when Bob calls Sam, Rule 1 and Rule 99 are matched and Alteon takes
the action of Rule 99. Alteon takes the action of Rule 1 only when Rule 100 is also matched. Until
rule 100 is matched in the return traffic, Alteon rate limits the traffic according to Rule 99.
The following is an example of the logs:
Multi-homing
WAN link load balancing enables Alteon to provide gigabit connectivity from corporate resources to
multiple ISP links to the Internet.
To handle the high volume of data on the Internet, corporations may use more than one ISP as a
way to increase reliability of Internet connections. Such enterprises with more than one ISP are
referred to as being multi-homed. In addition to reliability, a multi-homed network architecture
enables enterprises to distribute load among multiple connections and to provide more optimal
routing.
Multi-homing has become essential for reliable networks, providing customers with protection
against connectivity outages and unforeseen ISP failures. Multi-homing also presents other clear
opportunities for enterprises to intelligently manage how WAN links are used. With link load
balancing, organizations have greater flexibility to scale bandwidth and reduce spending for
corporate connectivity.
Alteon provides a solution for enterprises to optimize use of Internet connectivity. This
comprehensive solution helps enterprises to direct traffic over the best connection to maximize
performance, maximize corporate bandwidth investments, and effectively remove existing
deployment and management barriers for multi-homed networks.
Outbound Traffic
Outbound traffic is data from the intranet that accesses content across the Internet. Alteon load
balances outbound traffic using redirection filters to redirect traffic initiated from within the user's
network to a group of devices that exist at the other end of the WAN link. These filters determine
which link is the best at the time the request is generated.
The design of outbound WAN link load balancing is identical to standard redirection, except that
Alteon substitutes the source IP address of each frame with the proxy IP address of the port to
which the WAN link is connected. This substitution ensures that the returning response traverses the
same link.
In Figure 101 - WAN Link Load Balancing for Outbound Traffic, page 634, client 1 at IP address
1.1.1.2 sends an HTTP request to the Internet. Outbound traffic from client 1 reaches port 5 on the
Alteon which is configured with a redirection filter for link load balancing. The traffic is load balanced
between ports 2 and 7 depending on the metric of the WAN group (configured as real servers 1 and
2).
The outbound traffic resolution in Figure 101 - WAN Link Load Balancing for Outbound Traffic, page
634 is described as follows:
1. Client 1 makes a data request for content on the Internet.
2. When the request reaches port 5, the redirection filter is triggered and Alteon selects the
optimal WAN link.
3. Before the packets leave the WAN link ports, the client IP address is substituted with the
configured proxy IP address on port 2 or 7. Proxy IP address maintains persistency for the
returning request.
4. Alteon sends the request to the destination IP address.
5. The returning request from the Internet uses the same WAN link because the destination IP
address responds to the proxy IP address, thereby maintaining persistency. The selected ISP
processes the packet.
6. Alteon converts the proxy IP address to the client IP address and the request is returned to the
client.
Inbound Traffic
Inbound traffic is data from an external client on the Internet that enters Alteon to access an
internal service, such as corporate Web servers or FTP servers.
Alteon lets you load balance the inbound traffic by providing access to the external client with the
best available WAN link.
Note: For load balancing inbound traffic, you must have the Inbound Link Load Balancing license
installed. For more information on installing licenses see the section on the /oper/swkey command
in the Alteon Application Switch Operating System Command Reference, and the Radware Alteon
Installation and Maintenance Guide.
The inbound traffic resolution in Figure 102 - External Client Accessing Data from a Non-SLB Group,
page 635 is described as follows:
1. The client makes a request to www.radware.com.
2. The client query does not exist in the local DNS database. Local DNS queries the Domain Name
Server on Alteon.
3. Alteon monitors WAN links and responds with the virtual IP address of the optimal ISP.
Note: Radware recommends default gateways for each ISP VLAN to avoid asymmetric routing.
The inbound traffic resolution in Figure 103 - External Client Accessing Data from an SLB Group,
page 636 is described as follows:
1. The client makes a request to www.radware.com.
2. The client query does not exist in the local DNS database. Local DNS queries the Domain Name
Server on Alteon.
3. Alteon monitors WAN links and responds with the virtual IP address of the optimal ISP.
4. The client makes the request again to www.radware.com with the provided virtual IP address.
5. The SLB servers respond to the content request, because real server 7 IP address on Alteon is
the virtual server address of www.radware.com.
6. The session request egresses from port 1 and port 11 of Alteon where it is then load balanced
between the SLB servers. The virtual server IP address for the SLB servers on Alteon are
configured as a real server IP address (Real 7 IP: 30.30.30.2). Real 7 is added to a group.
7. The returning data from the SLB server reaches port 1, which is enabled for server processing.
For information on server processing, see Network Topology Requirements, page 169. The
transparent load balancing feature on the WAN ports maintains persistency, so that the traffic
returns via the same ISP.
Note: Do not connect two or more WAN links to the same Alteon port using a Layer 2 switch.
WAN link load balancing uses the proxy IP address of the destination port when translating the
source IP address of the requests.
Configuration Summary
Table 55 summarizes the steps for configuring WAN link load balancing:
Note: For details about any of the menu commands described in the following examples, refer to
the Alteon Application Switch Operating System Command Reference.
Table 56 - Configuring Simple WAN Load Balancing, page 640 provides an overview of configuring
simple WAN load balancing. All definitions for this example refer to Figure 104 - Simple WAN Link
Load Balancing Example, page 639.
2. Configure VLANs. The real server IP addresses (WAN links and real server 3) and the respective
IP interfaces must be on different VLANs. The pvid command sets the default VLAN number
which is used to forward frames which are not VLAN tagged. The default number is 1.
3. Configure the IP interfaces on Alteon. Alteon must have an IP route to all of the real servers that
receive switching services. For load balancing the traffic, Alteon uses this path to determine the
level of TCP/IP reach of the WAN links.
Any of the server load balancing metrics may be used, but response or bandwidth metric is
recommended.
4. Configure health check for the WAN link group.
5. Enable SLB.
>> # /cfg/slb/on
2. Enable transparent load balancing for ports 25 and 26. Enable transparent load balancing to
ensure the returning traffic from all servers to go back to the same ISP router.
4. Enable Direct Access Mode (DAM). Typically, you have two or more virtual server IP addresses
representing the same real service. On the return path, DAM ensures that the real server IP
address is mapped to the correct virtual IP address.
For information about DAM, refer to Direct Access Mode, page 200.
3. Add the link load balancing filter 100 to the outbound client port.
4. If you are configuring link load balancing for outbound traffic only, then go to Step 7—Apply and
Save Your Changes, page 645. The remaining steps in this procedure are used for load
balancing of inbound traffic only.
Step 5—Configure the Virtual Server IP Address and the Services for Each ISP
All client requests are addressed to a virtual server IP address defined on Alteon. Clients acquire the
virtual server IP address through normal DNS resolution. In this example, HTTP and FTP are
configured as the services running on this virtual server, and this service is associated with the real
server group.
Other TCP/IP services can be configured in a similar fashion. For a list of other well-known services
and ports, see Table 20 - Well-Known Application Ports, page 175. To configure multiple services,
see Multiple Services per Real Server, page 177.
Define a virtual server IP address for each ISP.
Step 5a—Configure the Virtual Server IP Address and the Services for ISP 1
Define a virtual server and add the services and real server group for ISP 1.
1. Configure a virtual server for ISP 1.
Step 5b—Configure the Virtual Server IP Address and the Services for ISP 2
Define a virtual server and add the services and real server group for ISP 2.
1. Configure a virtual server for ISP 2.
2. Configure an entry for each ISP and specify the virtual server and real server (ISP router).
You must map the domain record, radware.com, to each ISP. Each ISP has two parameters: a
virtual IP address and a real server IP address. The virtual IP address is used to respond to the
DNS query for the radware.com domain. The real server IP address is used to measure the ISP
load and ISP health. These commands map the two parameters to the ISP link.
Examine the resulting information. If any settings are incorrect, make the appropriate changes.
2. Save your new configuration changes.
4. Check that all load balancing parameters are working as expected. If necessary, make any
appropriate configuration changes and then check the information again.
Figure 105: WAN Link Load Balancing with Server Load Balancing
Table 58 - Configuring WAN Link Load Balancing with SLB, page 647 provides an overview of
configuring simple WAN load balancing with SLB. All definitions for this example refer to Figure 105
- WAN Link Load Balancing with Server Load Balancing, page 646.
2. Configure the IP interfaces on Alteon. Alteon must have an IP route to all of the real servers that
receive switching services. For load balancing the traffic, Alteon uses this path to determine the
level of TCP/IP reach of the WAN links.
3. On Alteon, configure VLANs.
Proxy is disabled on the real servers, because link load balancing and full NAT cache redirection
cannot coexist.
Any of the server load balancing metrics may be used, but response or bandwidth metric is
recommended.
4. Configure health check for the WAN link group.
5. Enable SLB.
>> # /cfg/slb/on
4. Enable Direct Access Mode (DAM). Typically, you have two or more virtual server IP addresses
representing the same real service. On the return path, DAM ensures that the real server IP
address is mapped to the correct virtual IP address.
For information about DAM, refer to Direct Access Mode, page 200.
3. Add the link load balancing filter 100 to the outbound client port.
4. If you are configuring link load balancing for outbound traffic only, then go to Step 7—Apply and
Save Your Changes, page 645. The remaining steps in this procedure are for load balancing
inbound traffic only.
>> # /cfg/slb/filt 50
>> Filter 50# sip 1.1.1.0 (From server subnet)
>> Filter 50# smask 255.255.255.0
>> Filter 50# dip 1.1.1.1 (To IF 1 on Alteon)
>> Filter 50# action allow
>> Filter 50# ena
For more information on health checking, see Health Checks for Real Servers, page 176.
6. Add the allow filter 50 to port 1.
Note: If you are using two Alteons for redundancy, then must add allow filters for VRRP before the
redirection filter. For more information on VRRP, see High Availability, page 507.
Step 5—Configure the Virtual Server IP Address and the Services for Each ISP
All client requests are addressed to a virtual server IP address on a virtual server defined on Alteon.
Clients acquire the virtual server IP address through normal DNS resolution. In this example, HTTP
and FTP are configured as the services running on this virtual server, and this service is associated
with the real server group.
Other TCP/IP services can be configured in a similar fashion. For a list of other well-known services
and ports, see Table 20 - Well-Known Application Ports, page 175. To configure multiple services,
see Configuring Multiple Service Ports, page 197.
Step 5a—Configure the Virtual Server IP Address and the Services for ISP 1
Define a virtual server and add the services and real server group for ISP 1.
1. Configure a virtual server for ISP 1.
Step 5b—Configure the VIrtual Server IP Address and the Services for ISP 2
Define a virtual server and add the services and real server group for ISP 2.
1. Configure a virtual server for ISP 2.
Note: Repeat Step 5a—Configure the Virtual Server IP Address and the Services for ISP 1,
page 652 and Step 5b—Configure the VIrtual Server IP Address and the Services for ISP 2,
page 652 for virtual server 3 and 4, and add group 4 for each of the services. This allows inbound
traffic to access SLB servers hosting the XYZ.com.
drecord 1: abc.com
entry 1 : VIP 1 and Real 1 (for ISP 1)
entry 2 : VIP 2 and Real 2 (for ISP 2)
drecord 2: xyz.com
entry 1 : VIP 3 and Real 1 (for ISP 1)
entry 2 : VIP 4 and Real 2 (for ISP 2)
You must map the domain record, radware.com to each ISP. Each ISP has two parameters: a
virtual IP address and a real server IP address. The virtual IP address is used to respond to the DNS
query for the radware.com domain. The real server IP address is used to measure the ISP load and
ISP health. These commands map the two parameters to the ISP link.
1. Configure the domain record for abc.com.
2. Configure an entry for each ISP and specify the virtual and real server (ISP router).
4. Configure an entry for each ISP and specify the virtual and real server (ISP router).
Examine the resulting information. If any settings are incorrect, make the appropriate changes.
2. Save your new configuration changes.
4. Check that all load balancing parameters are working as expected. If necessary, make any
appropriate configuration changes and then check the information again.
Example
This example applies filter 10 to the link to the first service provider:
>> /c/slb/filt 10
ena
action deny
sip 80.1.1.1
smask 255.255.255.255
dip 50.1.1.2
dmask 255.255.255.255
proto icmp
vlan any
/c/slb/filt 10/adv
icmp echorep
After the filter is applied to the first link, the filter on the second link is applied. The following
commands would apply filter 20 to the link to the second service provider:
/c/slb/filt 20
ena
action deny
sip 50.1.1.1
smask 255.255.255.255
dip 80.1.1.2
dmask 255.255.255.255
proto icmp
vlan any
/c/slb/filt 20/adv
icmp echorep
Note: In addition to the application of the filters, Radware also recommends using a static route.
Firewall Overview
Firewall devices have become indispensable for protecting network resources from unauthorized
access. Without FWLB, firewalls can become critical bottlenecks or single points-of-failure for your
network. As an example, consider the network in Figure 106 - Firewall Configuration with FWLB,
page 657:
One network interface card on the firewall is connected to the public side of the network, often to an
Internet router. This is known as the dirty, or untrusted, side of the firewall. Another network
interface card on the firewall is connected to the side of the network with the resources that must be
protected. This is known as the clean, or trusted, side of the firewall.
In the example in Figure 106 - Firewall Configuration with FWLB, page 657, all traffic passing
between the dirty, clean, and demilitarized zone (DMZ) networks must traverse the firewall, which
examines each individual packet. The firewall is configured with a detailed set of rules that
determine which types of traffic are allowed and which types are denied. Heavy traffic can turn the
firewall into a serious bottleneck. The firewall is also a single point-of-failure device. If it goes out of
service, external clients can no longer reach your services and internal clients can no longer reach
the Internet.
Sometimes a DMZ is attached to the firewall or between the Internet and the firewall. Typically, a
DMZ contains its own servers that provide dirty-side clients with access to services, making it
unnecessary for dirty-side traffic to use clean-side resources.
FWLB provides a variety of options that enhance firewall performance and resolve typical firewall
problems. Alteon supports the following FWLB methods:
• Basic FWLB for simple networks—This method uses a combination of static routes and
redirection filters and is usually employed in smaller networks.
An Alteon filter on the dirty-side splits incoming traffic into streams headed for different
firewalls. To ensure persistence of session traffic through the same firewall, distribution is based
on a mathematical hash of the IP source and destination addresses. For more information, see
Basic FWLB, page 658.
• Four-Subnet FWLB for larger networks—Although similar to basic FWLB, the four-subnet
method is more often deployed in larger networks that require high-availability solutions. This
method adds Virtual Router Redundancy Protocol (VRRP) to the configuration.
Just as with the basic method, four-subnet FWLB uses the hash metric to distribute firewall
traffic and maintain persistence. For more information, see Four-Subnet FWLB, page 668.
Basic FWLB
The basic FWLB method uses a combination of static routes and redirection filters to allow multiple
active firewalls to operate in parallel. Figure 107 - Basic FWLB Topology, page 658 illustrates a basic
FWLB topology:
The firewalls being load balanced are in the middle of the network, separating the dirty side from the
clean side. This configuration requires a minimum of two Alteons: one on the dirty side of the
firewalls and one on the clean side.
A redirection filter on the dirty-side Alteon splits incoming client traffic into multiple streams. Each
stream is routed through a different firewall. The same process is used for outbound server
responses. A redirection filter on the clean-side Alteon splits the traffic, and static routes forward
each stream through a different firewall and then back to the client.
Although other metrics can be used in some configurations (see Free-Metric FWLB, page 683), the
distribution of traffic within each stream is normally based on a mathematical hash of the source IP
address and destination IP addresses. This ensures that each client request and its related
responses will use the same firewall (a feature known as persistence) and that the traffic is equally
distributed. Persistence is required for the firewall as it maintains state and processes traffic in both
directions for a connection.
Although basic FWLB techniques can support more firewalls as well as multiple devices on the clean
and dirty sides for redundancy, the configuration complexity increases dramatically. The four-subnet
FWLB solution is usually preferred in larger scale, high-availability topologies (see Four-Subnet
FWLB, page 668).
On the dirty-side Alteon, one static route is needed for each traffic stream. For instance, the first
static route leads to an IP interface on the clean-side Alteon using the first firewall as the next
hop. A second static route leads to a second clean-side IP interface using the second firewall as
the next hop, and so on. By combining the redirection filter and static routes, traffic is load
balanced among all active firewalls.
All traffic between specific IP source/destination address pairs flows through the same firewall,
ensuring that sessions established by the firewalls persist for their duration.
Note: More than one stream can be routed though a particular firewall. You can weight the
load to favor one firewall by increasing the number of static routes that traverse it.
4. The firewalls determine if they should allow the packets and, if so, forward them to a virtual
server on the clean-side Alteon.
Client requests are forwarded or discarded according to rules configured for each firewall.
Note: If Network Address Translation (NAT) software is used on the firewalls, FWLB session
persistence requires transparent load balancing to be enabled (see Free-Metric FWLB,
page 683).
9. The firewall determines if it should allow the packet and, if so, forwards it to the dirty-side
Alteon.
Each firewall forwards or discards the server responses according to the rules that are
configured for it. Forwarded packets are sent to the dirty-side Alteon and out to the Internet.
10. The client receives the server response.
1. Configure VLANs.
Note: Alternately, if you are using hubs between Alteons and firewalls and you do not want to
configure VLANs, you must enable the Spanning Tree Protocol (STP) to prevent broadcast loops.
3. Configure the clean-side IP interface as if they are real servers on the dirty side.
Later in this procedure, you will configure one clean-side IP interface on a different subnet for
each firewall path being load balanced. On the dirty-side Alteon, create two real servers using
the IP address of each clean-side IP interface used for FWLB.
Note: The real server index number must be the same on both sides of the firewall. For
example, if Real Server 1 is the dirty-side IP interface for Firewall 1, then configure Real Server
1 on the clean side with the dirty-side IP interface. Configuring the same real server number on
both sides of the firewall ensures that the traffic travels through the same firewall.
Real servers in the server groups must be ordered the same on both clean side and dirty side
Alteon. For example, if the Real Server 1 IF connects to Firewall 1 for the clean side server
group, then the Real Server 1 IF on the dirty side should be connected to Firewall 1. Selecting
the same real server ensures that the traffic travels through the same firewall.
Note: Each of the four interfaces used for FWLB (two on each Alteon) in this example must be
configured for a different IP subnet.
5. Set the health check type for the real server group to ICMP.
>> Real server group 1# health icmp (Select ICMP as health check type)
6. Set the load-balancing metric for the real server group to hash.
Using the hash metric, all traffic between specific IP source/destination address pairs flows
through the same firewall. This ensures that sessions established by the firewalls are maintained
for their duration.
Note: Other load-balancing metrics such as leastconns, roundrobin, minmiss, response, and
bandwidth can be used when enabling the transparent load balancing option. For more
information, see Free-Metric FWLB, page 683.
7. Enable SLB.
8. Create a filter to allow local subnet traffic on the dirty side of the firewalls to reach the firewall
interfaces.
Note: When adding an IPv4 static route, if you are using FWLB and you define two IP
interfaces on the same subnet, where one IP interface has a subnet of the host which is also
included in the subnet of the second interface, you must specify the interface.
12. Define static routes to the clean-side IP interfaces, using the firewalls as gateways.
One static route is required for each firewall path being load-balanced. In this case, two paths
are required: one that leads to clean-side IF 2 (10.1.3.1) through the first firewall (10.1.1.10)
as its gateway, and one that leads to clean-side IF 3 (10.1.4.1) through the second firewall
(10.1.2.10) as its gateway.
13. Apply and save the configuration changes
>> # apply
>> # save
Note: An extra IP interface (IF 1) prevents server-to-server traffic from being redirected.
2. Configure the dirty-side IP interfaces as if they were real servers on the clean side.
You should already have configured a dirty-side IP interface on a different subnet for each
firewall path being load balanced. Create two real servers on the clean-side Alteon using the IP
address of each dirty-side IP interface.
Note: The real server index number must be the same on both sides of the firewall. For
example, if Real Server 1 is the dirty-side IP interface for Firewall 1, then configure Real Server
1 on the clean side with the dirty-side IP interface. Configuring the same real server number on
both sides of the firewall ensures that the traffic travels through the same firewall.
Note: Each of the four IP interfaces (two on each Alteon) in this example must be configured
for a different IP subnet.
4. Set the health check type for the real server group to ICMP.
5. Set the load-balancing metric for the real server group to hash.
Note: The clean-side Alteon must use the same metric as defined on the dirty side.
6. Enable SLB.
7. Configure ports 2 and 3, which are connected to the clean-side of the firewalls, for client
processing.
>> Real server group 1# /cfg/slb/port 2/client (Enable client processing on Port 2)
ena
>> SLB port 2# /cfg/slb/port (Enable client processing on Port 3)
>> SLB port 3# apply (Apply the configuration)
>> SLB port 3# save (Save the configuration)
8. Configure the virtual server that will load balance the real servers.
9. Configure the real servers to which traffic will be load balanced. These are the real servers on
the network.
>> Real server group 3# /cfg/slb/group 200 (Select Real Server Group 1)
>> Real server group 200# add 3 (Select Real Server 2 to Group 200)
>> Real server group 200# add 4 (Select Real Server 3 to Group 200)
11. Configure ports 4 and 5, which are connected to the real servers, for server processing.
14. Create the redirection filter. This filter redirects outbound traffic, load balancing it among the
defined real servers in the group. In this case, the real servers represent IP interfaces on the
dirty-side Alteon.
15. Add the filters to the ingress ports for the outbound packets.
Redirection filters are needed on all the ingress ports on the clean-side Alteon. Ingress ports are
any that attach to real servers or internal clients on the clean-side of the network. In this case,
two real servers are attached to the clean-side Alteon on ports 4 and 5.
16. Define static routes to the dirty-side IP interfaces, using the firewalls as gateways.
One static route is required for each firewall path being load balanced. In this case, two paths
are required: one that leads to dirty-side IF 2 (10.1.1.1) through the first firewall (10.1.3.10) as
its gateway and one that leads to dirty-side IF 3 (10.1.2.1) through the second firewall
(10.1.4.10) as its gateway.
Note: Configuring static routes for FWLB does not require IP forwarding to be turned on.
Note: When adding an IPv4 static route, if you are using FWLB and you define two IP
interfaces on the same subnet, where one IP interface has a subnet of the host which is also
included in the subnet of the second interface, you must specify the interface.
Four-Subnet FWLB
The four-subnet FWLB method is often deployed in large networks that require high availability
solutions. This method uses filtering, static routing, and Virtual Router Redundancy Protocol (VRRP)
to provide a parallel firewall operation between redundant Alteons.
Figure 110 - Four-Subnet FWLB Network Topology, page 668 illustrates one possible network
topology using the four-subnet method:
This network is classified as a high availability network because no single component or link failure
can cause network resources to become unavailable. Simple switches and vertical block interswitch
connections are used to provide multiple paths for network failover. However, the interswitch links
may be trunked together with multiple ports for additional protection from failure.
Note: Other topologies that use internal hubs, or diagonal cross-connections between Alteons and
simple switches are also possible. While such topologies may resolve networking issues in special
circumstances, they can make configuration more complex and can cause restrictions when using
advanced features such as active-active VRRP, free-metric FWLB, or content-intelligent switching.
In the example topology in Figure 110 - Four-Subnet FWLB Network Topology, page 668, the
network is divided into four sections:
• Subnet 1 includes all equipment between the exterior routers and dirty-side Alteons.
• Subnet 2 includes the dirty-side Alteons with their interswitch link, and dirty-side firewall
interfaces.
• Subnet 3 includes the clean-side firewall interfaces, and clean-side Alteons with their interswitch
link.
• Subnet 4 includes all equipment between the clean-side Alteons and their servers.
In this network, external traffic arrives through both routers. Since VRRP is enabled, one of the
dirty-side Alteons acts as the primary and receives all traffic. The dirty-side primary Alteon performs
FWLB similar to basic FWLB—a redirection filter splits traffic into multiple streams which are routed
through the available firewalls to the primary clean-side Alteon.
Just as with the basic method, four-subnet FWLB uses the hash metric to distribute firewall traffic
and maintain persistence, though other load-balancing metrics can be used by configuring an
additional transparent load balancing option (see Free-Metric FWLB, page 683).
Note: The port designations of both dirty-side Alteons are identical, as are the port designations of
both clean-side Alteons. This simplifies configuration by allowing you to synchronize the
configuration of each primary Alteon with the secondary.
Route Added: 10.10.4.100 (to clean-side virtual server) via 195.1.1.9 (Subnet 1
VIR)
Firewall IP Addresses
Firewall 1
Dirty-side IP interface 10.10.2.3
Clean-side IP interface 10.10.3.3
Default Gateway 10.10.2.9 (Subnet 2 VIR)
Route added 10.10.4.100 (virtual server) via 10.10.3.9 (Subnet 3
VIR)
Firewall 2
Dirty-side IP interface 10.10.2.4
Clean-side IP interface 10.10.3.4
Default gateway 10.10.2.9 (dirty-side VIR)
Route added 10.10.4.100 (virtual server) via 10.10.3.9 (Subnet 3
VIR)
The firewalls must also be configured with rules that determine which types of traffic will be
forwarded through the firewall and which will be dropped. All firewalls participating in FWLB must be
configured with the same set of rules.
Note: It is important to test the behavior of the firewalls prior to adding FWLB.
>> /cfg/l2/vlan 2
>> add 26
>> add 28
>> ena
Note: Port 25 is part of VLAN 1 by default and does not require manual configuration.
>> /cfg/l3/if 1
>> mask 255.255.255.0
>> addr 195.1.1.10
>> ena
>> /cfg/l3/if 2
>> mask 255.255.255.0
>> addr 10.10.2.1
>> vlan 2
>> ena
>> /cfg/l3/if 3
>> mask 255.255.255.255
>> addr 10.10.2.2
>> vlan 2
>> ena
Note: By configuring the IP interface mask prior to the IP address, the broadcast address is
calculated. Also, only the first IP interface in a given subnet is given the full subnet range mask.
Subsequent IP interfaces (such as IF 3) are given individual masks.
3. Turn Spanning Tree Protocol (STP) off for the primary dirty-side Alteon.
Note: IF 2 is used on all Alteons whenever routing through the top firewall, and IF 3 is used on
all Alteons whenever routing through the lower firewall.
>> /cfg/l3/route/ip4|ip6
>> # add 10.10.3.1 255.255.255.255 10.10.2.3 2
>> # add 10.10.3.2 255.255.255.255 10.10.2.4 3
>> # add 10.10.3.11 255.255.255.255 10.10.2.3 2
>> # add 10.10.3.12 255.255.255.255 10.10.2.4 3
Note: When defining static routes for FWLB, it is important to specify the source IP interface
numbers.
5. When dynamic routing protocols are not used, configure a gateway to the external routers.
>> # apply
>> # save
>> # /boot/reset
>> /cfg/l2/vlan 2
>> add 26
>> add 28
>> ena
>> /cfg/l3/if 1
>> mask 255.255.255.0
>> addr 195.1.1.11
>> ena
>> /cfg/l3/if 2
>> mask 255.255.255.0
>> addr 10.10.2.11
>> vlan 2
>> ena
>> /cfg/l3/if 3
>> mask 255.255.255.255
>> addr 10.10.2.12
>> vlan 2
>> ena
>> /cfg/l3/frwd/route
>> # add 10.10.3.1 255.255.255.255 10.10.2.3 2
>> # add 10.10.3.2 255.255.255.255 10.10.2.4 3
>> # add 10.10.3.11 255.255.255.255 10.10.2.3 2
>> # add 10.10.3.12 255.255.255.255 10.10.2.4 3
5. When dynamic routing protocols are not used, configure a gateway to the external routers on
the secondary dirty-side Alteon.
>> # apply
>> # save
>> # /boot/reset
>> /cfg/l2/vlan 2
>> add 25
>> add 28
>> ena
>> /cfg/l2/vlan 4
>> add 26
>> ena
>> /cfg/l3/if 1
>> mask 255.255.255.0
>> addr 10.10.4.10
>> vlan 4
>> ena
>> /cfg/l3/if 2
>> mask 255.255.255.0
>> addr 10.10.3.1
>> vlan 3
>> ena
>> /cfg/l3/if 3
>> mask 255.255.255.255
>> addr 10.10.3.2
>> vlan 3
>> ena
>> /cfg/l3/frwd/route
>> # add 10.10.2.1 255.255.255.255 10.10.3.3 2
>> # add 10.10.2.2 255.255.255.255 10.10.3.4 3
>> # add 10.10.2.11 255.255.255.255 10.10.3.3 2
>> # add 10.10.2.12 255.255.255.255 10.10.3.4 3
>> # apply
>> # save
>> # /boot/reset
>> /cfg/l2/vlan 3
>> add 25
>> add 28
>> ena
>> /cfg/l2/vlan 4
>> add 26
>> ena
>> /cfg/l3/if 1
>> mask 255.255.255.0
>> addr 10.10.4.11
>> vlan 4
>> ena
>> /cfg/l3/if 2
>> mask 255.255.255.0
>> addr 10.10.3.11
>> vlan 3
>> ena
>> /cfg/l3/if 3
>> mask 255.255.255.255
>> addr 10.10.3.12
>> vlan 3
>> ena
>> /cfg/l3/frwd/route
>> # add 10.10.2.1 255.255.255.255 10.10.3.3 2
>> # add 10.10.2.2 255.255.255.255 10.10.3.4 3
>> # add 10.10.2.11 255.255.255.255 10.10.3.3 2
>> # add 10.10.2.12 255.255.255.255 10.10.3.4 3
>> # apply
>> # save
>> # /boot/reset
>> # /cfg/l3/vrrp/on
>> # /cfg/slb
>> # on
>> # sync/peer 1
>> # addr 195.1.1.10
>> # ena
>> # apply
>> # save
>> # /cfg/l3/vrrp/on
>> # /cfg/slb
>> # on
>> # sync/peer 1
>> # addr 10.10.4.10
>> # ena
>> # apply
>> # save
>> # /cfg/slb
>> # on
>> # real 1
>> # rip 10.10.3.1
>> # ena
>> # /cfg/slb/real 2
>> # rip 10.10.3.2
>> # ena
>> # /cfg/slb/group 1
>> # add 1
>> # add 2
>> # metric hash
Using the hash metric, all traffic between specific IP source/destination address pairs flows
through the same firewall, ensuring that sessions established by the firewalls are maintained for
their duration (persistence).
Note: Other load balancing metrics, such as leastconns, roundrobin, minmiss, response, and
bandwidth, can be used when enabling the transparent load balancing option. For more
information, see Free-Metric FWLB, page 683.
— Filter 20 prevents VRRP traffic (and other multicast traffic on the reserved 224.0.0.0/24
network) from being redirected.
— Filter 2048 redirects the remaining traffic to the firewall group.
>> # /cfg/slb/filt 10
>> # dip 195.1.1.0
>> # dmask 255.255.255.0
>> # ena
>> # /cfg/slb/filt 20
>> # dip 224.0.0.0
>> # dmask 255.255.255.0
>> # ena
>> # /cfg/slb/filt 2048
>> # action redir
>> # group 1
>> # ena
>> # /cfg/slb/port 1
>> # filt ena
>> # add 10
>> # add 20
>> # add 2048
3. Configure VRRP on the primary dirty-side Alteon. VRRP in this example requires two virtual
routers: one for the subnet attached to the routers and one for the subnet attached to the
firewalls.
>> # /cfg/l3/vrrp 2
>> # on
>> # vr 1
>> # vrid 1 (Configure Virtual Router 1)
>> # addr 195.1.1.9 (For the subnet attached to the
routers)
>> # if 1
>> # prio 101
>> # share dis
>> # ena
>> # track
>> # ifs ena
>> # ports ena
>> # /cfg/l3/vrrp/vr 2
>> # vrid 2 (Configure Virtual Router 2)
(For the subnet attached to the
>> # addr 10.10.2.0
firewall)
>> #if 2
>> # prio 101
>> # share dis
>> # ena
>> # track
>> # ifs ena
>> # ports ena
>> # /cfg/slb/sync
>> # prios d
>> # peer 1
>> # ena
>> # addr 195.1.1.11
>> # apply
>> # save
6. Synchronize primary and secondary dirty-side Alteons for the VRRP configuration.
>> # /oper/slb/sync
Note: IF 2 is used on all Alteons whenever routing through the top firewall, and IF 3 is used on
all Alteons whenever routing through the lower firewall.
>> # /cfg/slb
>> # on
>> # real 1
>> # rip 10.10.2.1 (IF2 of the primary dirty-side
Alteon)
>> # ena
>> # /cfg/slb/real 2
>> # rip 10.10.2.2 (IF2 of the primary dirty-side
Alteon)
>> # ena
>> # /cfg/slb/group 1
>> # add 1
>> # add 2
>> # metric hash
Note: The clean-side Alteon must use the same metric as defined on the dirty side. For
information on using metrics other than hash, see Free-Metric FWLB, page 683.
2. Create an SLB real server group on the primary clean-side Alteon to which traffic will be load
balanced.
The external clients are configured to connect to HTTP services at a publicly advertised IP
address. The servers on this network are load balanced by a virtual server on the clean-side
Alteon. SLB options are configured as follows:
Note: The virtual server IP address configured in this step will also be configured as a Virtual
Server Router (VSR) when VRRP is configured in a later step.
>> # /cfg/slb/filt 10
>> # dip 10.10.4.0
>> # dmask 255.255.255.0
>> # ena
>> # /cfg/slb/filt 20
>> # dip 224.0.0.0
>> # dmask 255.255.255.0
>> # ena
>> # /cfg/slb/filt 2048
>> # action redir
>> # group 1
>> # ena
>> # /cfg/slb/port 4
>> # filt ena
>> # add 10
>> # add 20
>> # add 2048
>> # /cfg/l3/vrrp
>> # on
>> # vr 1
>> # vrid 3
>> # addr 10.10.4.9
>> # if 1
>> # prio 100
>> # share dis
>> # ena
>> # track
>> # ifs ena
>> # ports ena
>> # /cfg/l3/vrrp/vr 2
>> # vrid 4
>> # addr 10.10.3.9
>> # if 2
>> # prio 101
>> # share dis
>> # ena
>> # track
>> # ifs ena
>> # ports ena
A third virtual router is required for the virtual server used for optional SLB.
>> # /cfg/l3/vrrp/vr 3
>> # vrid 5
>> # addr 10.10.4.100
>> # prio 102
>> # share dis
>> # ena
>> # track
>> # ifs ena
>> # ports ena
>> # /cfg/slb/sync
>> # prios d
>> # peer 1
>> # ena
>> # addr 10.10.4.11
>> # apply
>> # save
7. Synchronize primary and secondary dirty-side Alteons for the VRRP configuration.
>> # /oper/slb/sync
Free-Metric FWLB
Free-metric FWLB lets you use load-balancing metrics other than hash, such as leastconns,
roundrobin, minmiss, response, and bandwidth, for more versatility. The free-metric method uses
the transparent load balancing option, which can be used with basic FWLB or four-subnet FWLB
networks.
1. On the clean-side Alteon, enable RTS on the ports attached to the firewalls (Ports 2 and 3).
Enable filter and server processing on ports 2 and 3 so that the responses from the real server
are looked-up in the session table.
2. On the clean-side Alteon, remove the redirection filter from the ports attached to the real
servers (Ports 4 and 5), but ensure that filter processing is enabled.
The redirection filter is removed so that the return packet traverses through the same firewall. If
the firewalls synchronize their states, then it is not required to remove the redirection filter.
Filter processing is enabled to make use of the RTS-created sessions.
Use the hash metric if the session is from an FTP or RTSP servers.
3. On the dirty-side Alteon, set the FWLB metric.
>> # /cfg/slb/group 1
>> # metric <metric type>
Any of the following load-balancing metrics can be used: hash, leastconns, roundrobin, minmiss,
response, or bandwidth. See Metrics for Real Server Groups, page 180 for details on using each
metric.
1. On the clean-side Alteons, enable RTS on the ports attached to the firewalls (Port 3) and on the
interswitch port (port 9).
Enable filter and server processing on Ports 3 and 9, so that the responses from the real server
are looked up in the session table on both clean-side Alteons:
2. On the clean-side Alteons, remove the redirection filter from the ports attached to the real
servers (Ports 4), and ensure filter processing is enabled.
To view the original redirection filters that were configured for the four-subnet example, see step
3. Do this on both clean-side Alteons:
3. On the dirty-side Alteons, set the FWLB metric, on both dirty-side Alteons:
>> # /cfg/slb/group 1
>> # metric <metric type>
Any of the following load-balancing metrics can be used: hash, leastconns, roundrobin, minmiss,
response, or bandwidth. See Metrics for Real Server Groups, page 180 for details on using each
metric.
The DMZ servers can be attached to Alteon directly or through an intermediate hub or Alteon. Alteon
is then configured with filters to permit or deny access to the DMZ servers. In this way, two levels of
security are implemented: one that restricts access to the DMZ through the Alteon filters and
another that restricts access to the clean network through the stateful inspection performed by the
firewalls.
To add the filters required for the DMZ (to each Alteon)
1. On the dirty-side Alteon, create the filter to allow HTTP traffic to reach the DMZ Web servers.
In this example, the DMZ Web servers use IP addresses 205.178.29.0/24.
2. Create another filter to deny all other traffic to the DMZ Web servers.
Note: The deny filter has a higher filter number than the allow filter. This is necessary so that
the allow filter has the higher order of precedence.
3. Configure a "dummy" redirect filter as the last filter (after the redirect all filter) to force the
HTTP health checks to activate.
Note: Enure that the number of each real filter is lower than the number of the "dummy"
redirect filter.
In addition to HTTP, Alteon lets you configure up to five (5) different TCP services to listen for health
checks. For example, you can configure FTP and SMTP ports to perform health checks. For a list of
other well-known application ports, see Table 20 - Well-Known Application Ports, page 175.
Overview
A VPN is a connection that has the appearance and advantages of a dedicated link, but it occurs over
a shared network. Using a technique called tunneling, data packets are transmitted across a routed
network, such as the Internet, in a private tunnel that simulates a point-to-point connection. This
approach enables network traffic from many sources to travel via separate tunnels across the
infrastructure. It also enables traffic from many sources to be differentiated, so that it can be
directed to specific destinations and receive specific levels of service.
VPNs provide the security features of a firewall, network address translation, data encryption, and
authentication and authorization. Since most of the data sent between VPN initiators and
terminators is encrypted, network devices cannot use information inside the packet to make
intelligent routing decisions.
Note: VPN load balancing is supported for connecting from remote sites to the network behind the
VPN cluster IP address. A connection initiated from clients internal to the VPN gateways is not
supported.
Basic frame flow, from the dirty side of the network to the clean side, is illustrated in Figure 116 -
Basic Frame Flow, page 692. An external client is accessing an internal server. The VPN devices do
not perform Network Address Translation (NAT).
Note: Radware recommends using the hash load-balancing metric to select the VPN device.
4. VPN Device 1 strips the IP header and decrypts the encrypted IP header.
5. Alteon 2 forwards the packet to the real server.
If an entry is found, the frame is forwarded normally. If an entry is not found, Alteon determines
which VPN device processed the frame by performing a lookup with the source MAC address of the
frame. If the MAC address matches a MAC address of a VPN device, Alteon adds an entry to the
session table so that reverse traffic is redirected to the same VPN device.
session lookup so that it can be load balanced to the same server. If the ISAKMP session is not
found, the IPSec session is bound to a VPN server according to the previously configured load-
balancing metrics.
>> # /cfg/slb/filt 20/adv (Select the Advanced menu for Filter 20)
>> Filter 20 Advanced# rtsrcmac ena (Enable Return to Source MAC Address)
Figure 117 - Example VPN Load-Balancing Configuration, page 693 illustrates VPN load balancing
with two VPN devices and four Alteons in a four-subnet scenario:
>> # /cfg/l2/stg/off
4. Define the clean-side IP interfaces. Create one clean-side IP interface on a different subnet for
each VPN device being load balanced.
5. Configure routes for each of the IP interfaces you configured in step 4 using the VPN devices as
gateways. One static route for redirection is required for each VPN device being load balanced.
>>#/cfg/l3/route
>> IP Static Route# add 10.0.0.10 (Static route destination IP
address)
>> IP Static Route# 255.255.255.255 (Destination subnet mask)
>> IP Static Route# 20.0.0101 (Enter gateway IP address)
>> IP Static Route# 2 (For Interface 2)
>> IP Static Route# add 10.0.0.11 (Enter destination IP address)
>> IP Static Route# 255.255.255.255 (Destination subnet mask)
>> IP Static Route# 20.0.0102 (Enter gateway IP address)
>> IP Static Route# 3 (For Interface 3)
>> # /cfg/slb/on
9. Configure Real Server group 1, and add Real Servers 1, 2, 3, and 4 to the group.
10. Configure a filter to enable the transparent load balancing (Return to Source MAC address)
option. This adds an opposite entry in the session table so that the return traffic matches its
source MAC address.
>> # /cfg/slb/filt 20/adv (Select the Advanced menu for Filter 20)
>> Filter 20 Advanced# rtsrcmac ena (Enable Return to Source MAC Address)
11. Enable filter processing on the server ports so that the responses from the real server are looked
up in the VPN session table.
12. When dynamic routing protocols are not used, configure a gateway to the external router.
>> # apply
>> # save
>> # /boot/reset
4. Define the clean-side IP interfaces. Create one clean-side IP interface on a different subnet for
each VPN device being load balanced.
5. Configure routes for each of the IP interfaces you configured in step 4, using the VPN devices as
gateways. One static route is required for each VPN device being load balanced.
6. Configure Virtual Router Redundancy Protocol (VRRP) for Virtual Routers 1 and 2.
>> # /cfg/l3/vrrp/on
>> Virtual Router Redundancy Protocol# vr
>> VRRP Virtual Router 1# ena
>> VRRP Virtual Router 1# vrid
>> VRRP Virtual Router 1# if
>> VRRP Virtual Router 1# addr 30.0.0.50
>> VRRP Virtual Router 1# share dis
>> VRRP Virtual Router 1 # track/vrs ena
>> VRRP Virtual Router 1 Priority Tracking# /cfg/l3/vrrp/vr 2
>> VRRP Virtual Router 2# ena
>> VRRP Virtual Router 2 # vrid 2
>> VRRP Virtual Router 2 # if 2
>> VRRP Virtual Router 2 # addr 20.0.0.1
>> VRRP Virtual Router 2 # share dis
>> VRRP Virtual Router 2 # track/ports ena
7. Enable SLB.
10. Configure a filter to enable the transparent load balancing (Return to Source MAC address)
option. This adds an opposite entry in the session table so that the return traffic matches its
source MAC address.
>> # /cfg/slb/filt 20/adv (Select the Advanced menu for Filter 20)
>> Filter 20 Advanced# rtsrcmac ena (Enable Return to Source MAC Address)
11. Enable filter processing on the server ports so that the response from the real server will be
looked up in VPN session table.
>> # /cfg/l2/stg/off
5. Define static routes for each of the IP interfaces you configured in step 4 using the VPN devices
as gateways. One static route is required for each VPN device being load balanced.
>> # /cfg/l3/route
>> # add 20.0.0.10 255.255.255.255 10.0.0.101 2
>> # add 20.0.0.11 255.255.255.255 10.0.0.102 3
>> # add 20.0.0.20 255.255.255.255 10.0.0.101 2
>> # add 20.0.0.21 255.255.255.255 10.0.0.102 3
>> # /cfg/l3/vrrp/on
>> Virtual Router Redundancy Protocol# /cfg/l3/vrrp/vr 1
>> VRRP Virtual Router 1# ena
>> VRRP Virtual Router 1# vrid 1
>> VRRP Virtual Router 1# if 1
>> VRRP Virtual Router 1# prio 101
>> VRRP Virtual Router 1# addr 192.168.10.50
>> VRRP Virtual Router 1# share dis
>> VRRP Virtual Router 1# track
>> VRRP Virtual Router 1 Priority Tracking# vrs ena
>> VRRP Virtual Router 1 Priority Tracking# ports ena
>> VRRP Virtual Router 1 Priority Tracking# /cfg/l3/vrrp/vr 2
>> VRRP Virtual Router 2# ena
>> VRRP Virtual Router 2# vrid 2
>> VRRP Virtual Router 2# if 2
>> VRRP Virtual Router 2# prio 101
>> VRRP Virtual Router 2# addr 10.0.0.1
>> VRRP Virtual Router 2# share dis
>> VRRP Virtual Router 2# track
>> VRRP Virtual Router 2 Priority Tracking# vrs ena
>> VRRP Virtual Router 2 Priority Tracking# ports>> # ena
7. Enable SLB.
10. Configure the filters to allow local subnet traffic on the dirty side of the VPN device to reach the
VPN device interfaces.
12. Create a filter to allow the management firewall (policy server) to reach the VPN firewall.
>> # /cfg/slb/port 1
>> # filt ena
>> # add 100/add 110/add 2048
>> # apply
>> # save
>> # /boot/reset
>> # /cfg/l2/stg/off
>> # /cfg/l3/route
>> # add 20.0.0.10 255.255.255.255 10.0.0.101 2
>> # add 20.0.0.11 255.255.255.255 10.0.0.102 3
>> # add 20.0.0.20 255.255.255.255 10.0.0.101 2
>> # add 20.0.0.21 255.255.255.255 10.0.0.102 3
>> # /cfg/l3/vrrp/on
>> # /cfg/l3/vrrp/vr 1
>> # ena
>> # vrid 1
>> # if 1
>> # addr 192.168.10.50
>> # share dis
>> # track
>> # vrs ena
>> # ports ena
>> # /cfg/l3/vrrp/vr 2
>> # ena
>> # vrid 2
>> # if 2
>> # addr 10.0.0.1
>> # share dis
>> # track
>> # vrs ena
>> # ports ena
7. Enable SLB.
>> # /cfg/slb/on
9. Enable the real server group, and place real servers 1 through 4 into the real server group.
>> # /cfg/slb/group 1
>> # metric hash
>> # add 1/add 2/add 3/add 4
10. Configure the filters to allow local subnet traffic on the dirty side of the VPN device to reach the
VPN device interfaces.
>> # /cfg/slb/port 1
>> # filt ena
>> # add 100/add 110/add 2048
>> # apply
>> # save
>> # /boot/reset
Figure 118: Checkpoint Rules for both VPN Devices as seen in the Policy Editor
1. Disconnect the cables (cause failures) to change the available servers that are up
>> # /info/slb/dump
This should change the VRRP preferences. You can view VRRP preferences using the command
/info/l3/vrrp.
2. Watch for accepted and dropped traffic. In the toolbar, go to Window > Log Viewer.
Note: To help simplify the logs, the health checks are not logged.
3. Enter the policy server IP address: 192.168.10.120. You have the option of adding a nickname.
4. Launch a browser (such as Netscape or Internet Explorer) and go to http://30.0.0.100.
5. Enter vpnuser for user name and alteon for the password.
Note: When many clients are coming from behind a VPN gateway (for example, not using the
SecuRemote clients but using a VPN 1 Gateway or other compatible VPN Gateway), you do not see
load balancing across those clients. Each SecuRemote client is treated differently, but each VPN 1
Gateway is treated as one client each (that is, one Client IP address). VPN Device 1 and VPN Device
2 belong to one cluster IP.
Using GSLB
To use GSLB, you must purchase an additional software license and license string. Contact Radware
Technical Support to acquire additional software licenses. GSLB configurations running in earlier
versions of the Alteon are maintained after upgrading. When you upgrade the software image to the
new version, the configuration is migrated.
Once you have obtained the proper password key to enable GSLB, do the following:
1. Connect to the CLI via Telnet or the console port, and log in as the administrator, following the
directions in the “Command Line Interface” chapter of the Alteon Application Switch Operating
System Command Reference.
2. From the CLI, enter the /oper/swkey command.
You are prompted to enter the license string. If it is correct for this MAC address, Alteon accepts
the password, permanently records it in non-volatile RAM (NVRAM), and then enables the
feature.
DSSP Versions
By default, DSSP version 1 is enabled. Alteon supports the following DSSP versions:
• DSSP version 1—The initial release of DSSP.
• DSSP version 2—DSSP version 2 adds support for server response time, CPU use, session
availability, and session utilization in the remote site updates.
• DSSP version 3—DSSP version 3 adds support for the availability persistence selection metric.
• DSSP version 4—DSSP version 4 adds support for the client proximity selection metric in remote
site updates.
• DSSP version 5—DSSP version 5 adds support for IPv6 remote servers updates.
For details on the DSSP site selection metrics, see GSLB Metrics, page 708.
GSLB Overview
GSLB enables balancing server traffic load across multiple physical sites. The Alteon GSLB
implementation takes into account an individual site's health, response time, and geographic
location to smoothly integrate the resources of the dispersed server sites for complete global
performance.
Benefits
GSLB meets the following demands for distributed network services:
• High content availability is achieved through distributed content and distributed decision-
making. If one site becomes disabled, the others become aware of it and take up the load.
• There is no latency during client connection set-up. Instant site hand-off decisions can be made
by any distributed Alteon.
• The best performing sites receive a majority of traffic over a given period of time but are not
overwhelmed.
• Alteons at different sites regularly exchange information through the Distributed Site State
Protocol (DSSP), and can trigger exchanges when any site's health status changes. This ensures
that each active site has valid state knowledge and statistics. All versions of DSSP are
supported.
• GSLB implementation takes geography as well as network topology into account.
• Creative control is given to the network administrator or Webmaster to build and control content
by user, location, target application, and more.
• GSLB is easy to deploy, manage, and scale. Alteon configuration is straightforward. There are no
complex system topologies involving routers, protocols, and so on.
• Flexible design options are provided.
• All IP protocols are supported.
• Supports IPv4, IPv6, and mixed IP version environments.
3. The Example Inc.'s San Jose DNS tells the local DNS to query the Alteon with GSLB software as
the authoritative name server for "www.example.com."
4. The San Jose Alteon responds to the DNS request, listing the IP address with the current best
service.
Each Alteon with GSLB software is capable of responding to the client's name resolution request.
Since each Alteon regularly checks and communicates health and performance information with
its peers, either Alteon can determine which sites are best able to serve the client's Web access
needs. It can respond with a list of IP addresses for the Example Inc.'s distributed sites, which
are prioritized by performance, geography, and other criteria.
In this case, the San Jose Alteon knows that Example Inc. Denver currently provides better
service, and lists Example Inc. Denver's virtual server IP address first when responding to the
DNS request.
5. The client connects to Example Inc. Denver for the best service.
The client's Web browser uses the IP address information obtained from the DNS request to
open a connection to the best available site. The IP addresses represent virtual servers at any
site, which are locally load balanced according to regular SLB configuration.
If the site serving the client HTTP content suddenly experiences a failure (no healthy real
servers) or becomes overloaded with traffic (all real servers reach their maximum connection
limit), Alteon issues an HTTP redirect and transparently causes the client to connect to another
peer site.
The end result is that the client gets quick, reliable service with no latency and no special client-
side configuration.
GSLB Metrics
This section describes all GSLB metrics as governed by DSSP. All metrics can be prioritized for
selection order, and can be weighted on a per site basis. This section includes the following sub-
sections:
• Metric Preferences, page 710
• Rules, page 710
• GSLB Availability Persistence, page 710
• GSLB Client Proximity Metric, page 711
For details on the configuration parameters of GSLB metrics, see the /cfg/slb/gslb/rule menu
and the command descriptions in the Alteon Application Switch Operating System Command
Reference.
The following is a list of all GSLB metrics:
• Session utilization capacity threshold—Causes the GSLB-enabled Alteon to not select the
server when the session utilization of the server goes above the threshold. The session
utilization is the percentage of sessions used over total sessions that results in normalized
sessions between servers. When the server is not available, the session utilization is 100%. This
is a threshold metric and it overwrites all other metrics. This metric requires remote site
updates.
• CPU utilization capacity threshold—Causes the GSLB-enabled Alteon to not select the
server when the CPU utilization of the site with the server goes above the threshold. CPU
utilization is the highest CPU utilization for periods of up to 64 seconds among SPs. This is a
threshold metric and overwrites all other metrics.This metric requires remote site updates.
• Session available capacity threshold—Does not select the server when the number of
available sessions on the server falls below the threshold. When the server is not available, the
session available is 0. This is a threshold metric and it overwrites all other metrics. This metric
requires remote site updates.
• Geographical preference—Causes the GSLB-enabled Alteon to select the server based on the
same IANA region of the source IP address and the server IP address. This metric does not
require remote site updates.
You can use the /info/slb/gslb/geo command to obtain a list of the IP address ranges that
are mapped to each region. The regions are as follows:
— North America
— South America
— Europe
— Caribbean
— Pacific Rim
— Sub-Sahara
— Japan
• Network preference—Selects the server based on the preferred network of the source IP
address. This metric does not require remote site updates.
• Weighted least connections—Selects the server based on which server has the lowest session
utilization. Session utilization is the percentage of sessions used over total sessions, which
results in normalized sessions between servers. A server whose session utilization is 100% is
considered unavailable. This metric requires remote site updates.
• Weighted response time—Selects the server based on the lowest response time in
milliseconds from an SLB health check of the servers. This metric requires SLB health checks
and remote site updates.
• Weighted round-robin—Selects the server based on round-robin of the servers.
• Weighted random—Selects the server based on uniform random distribution of the servers.
• Availability—Selects the same server while the server is still available. If the same server is not
available, this metric selects the next server based on a ranking of the local virtual server and
remote real server in a list from the highest (48) to the lowest (1) ranking. Multiple servers can
have the same priority. This metric allows servers to be grouped based on priorities, or into
primary and secondary groups. This metric requires SLB health checks and remote site updates.
This is discussed in further detail in GSLB Availability Persistence, page 710.
• Quality of service—Selects the server based on combination of the lowest session utilization
and the lowest response time of the SLB health check of the servers. This metric requires SLB
health checks and remote site updates.
• Minmisses—Selects the same server based on the hash of source IP address and domain
name. The hash calculation uses all the servers that are configured for the domain irrespective
of the state of the server. When the server selected is not available, minmisses selects the next
available server.
• Hashing—Selects the same server based on the hash of source IP address and domain name.
The hash calculation uses only the servers that are available for the domain. The server selected
may be affected when a server becomes available or not available, since the hash calculation
uses only the servers that are available.
• DNS local—Selects the local virtual server only when the local virtual server is available. This
metric applies to DNS-based GSLB only.
• DNS always—Selects the local virtual server even though the local virtual server is not
available. This metric applies to DNS-based GSLB only.
• Remote—Selects the remote real servers only.
• Persistence—Selects the server for which the persistency cache contains the client IP address
and subnet mask.
Metric Preferences
Setting metric preferences enables the GSLB selection mechanism to use multiple metrics from a
metric preference list. GSLB selection starts with the first metric in the list. It then goes to the next
metric when no server is selected, or when more than the required servers is selected. The GSLB
selection stops when the metric results in at least one and no more than the required servers, or
after the last metric in the list is reached. For DNS direct-based GSLB, the DNS response can be
configured to return up to 10 required servers. For HTTP redirects based GSLB, the required server
is one.
The following metrics can be selected from the metric preference list:
• Geographical preference
• Network preference
• Least connections
• Response time
• Round-robin
• Random
• Availability
• Quality of service
• Minmisses
• Hashing
• DNS local
• DNS always
• Remote
• Persistence
Rules
A rule lets the GSLB selection mechanism use a different GSLB site selection metric preference list,
and rules can be set based for the time of day. Each domain has one or more rules. Each rule has a
metric preference list. The GSLB selection selects the first rule that matches the domain and starts
with the first metric in the metric preference list of the rule. For more information on rules, see
Configuring GSLB with Rules, page 730.
/cfg/slb/gslb/version 3
2. The availability metric must be the first metric configured in the first GSLB rule. For information
on rule creation, see Rules, page 710.
3. Enable availability persistence on the backup Alteon (the Alteon that will take over from the
primary Alteon) using the following command:
Note: This is an operational command that does not survive an Alteon reboot.
4. After the primary server recovers, you can revert to the configured availabilities on the Alteon
whose virtual server currently has precedence. This is the Alteon with the virtual server that is
advertising an availability of 48:
After both sites are reporting their configured availability, turn the feature back on by enabling
availability persistence on Alteon with the backup server:
You can use the following command to enable or disable availability persistence on the backup
Alteon:
/cfg/slb/gslb/clntprox
/stats/slb/gslb/clntprox
/cfg/slb/gslb/rule/metric/gmetric/persistence
For GSLB sites to synchronize Alteon peers, the passphrase for Alteon synchronization must be
enabled (/cfg/slb/sync/passphrs). Failing to set the passphrase generates an error message.
For more information on configuring GSLB with DNSSEC, see Configuring GSLB with DNSSEC,
page 743.
Notes
• In the procedures described in this example, many of the options are left at their default values.
For more details about these options, see Implementing Server Load Balancing, page 167.
• For details about any of the processes or menu commands described in this example, see the
Alteon Application Switch Operating System Command Reference.
2. If you are using the BBI for managing the San Jose Alteon, change its service port.
By default, GSLB listens on service port 80 for HTTP redirection. By default, the BBI also uses
port 80. Both services cannot use the same port. If the BBI is enabled, configure it to use a
different port.
For example, enter the following command to change the BBI port to 8080:
4. Configure another VLAN for local server traffic, and add server ports to this VLAN.
6. Define an IP interface to the Internet. The IP interface responds when asked to resolve client
DNS requests.
7. Define the default gateway. The router at the edge of the site acts as the default gateway to the
Internet. The default gateway address should be on the same subnet as the IP interface 101,
which points to the Internet. To configure the default gateway for this example, enter the
following commands:
>> # apply
>> # save
9. Configure the master DNS server to recognize the local GSLB Alteon as the authoritative name
server for the hosted services.
Determine the domain name that will be distributed to both sites and the hostname for each
distributed service. In this example, the San Jose DNS server is configured to recognize
200.200.200.1 (the IP interface of the San Jose GSLB Alteon) as the authoritative name server
for "www.gslb.example.com."
>> Real server group 1# health http (Use HTTP for health checks)
>> Real server group 1# content index.html (Set URL content for health
checks)
This configuration is not limited to HTTP services. For a list of other well-known TCP/IP services
and ports, see Well-Known Application Ports, page 175.
5. On the San Jose Alteon, define the type of Layer 4 traffic processing each port must support.
The ports are configured as follows:
Note: Unless you are in the middle of network migration from an Alteon version prior to 22.0,
you should always enable DSSP version 2 or later.
>> # /cfg/slb/gslb/version 2
Each additional remote site should be configured in the same manner. You can enable up to 64
remote sites.
4. On the San Jose Alteon, assign each remote distributed service to a local virtual server.
Configure the local San Jose site to recognize the services offered at the remote Denver site. To
do this, configure one real server entry on the San Jose Alteon for each virtual server located at
each remote site. Since there is only one remote site (Denver) with only one virtual server, only
one more local real server entry is needed at the San Jose site.
The new real server entry is configured with the remote virtual server IP address (that is, Alteon
2's VIP address, rather than the usual IP address of a local physical server). Do not confuse this
value with the IP interface address on the remote Alteon.
The remote parameter is enabled, and the real server entry is added to the real server group
under the local virtual server for the intended service. Finally, since the real server health checks
are performed across the Internet, the health-checking interval should be increased to 30 or 60
seconds to avoid generating excess traffic. The health check interval should also depend on the
number of remote sites. The more remote sites you have, the larger the time interval should be.
For example:
Note: You should note where each configured value originates, or this step can result in
improper configuration.
5. On the San Jose Alteon, define the domain name and hostname for each service hosted on each
virtual server.
In this example, the domain name for Example Inc. is "gslb.example.com," and the hostname
for the only service (HTTP) is "www." These values are configured as follows:
7. Examine the resulting information. If any settings are incorrect, make and apply any appropriate
changes, and then check again.
2. If you are using the BBI for managing the San Jose Alteon, change its service port.
By default, GSLB listens on service port 80 for HTTP redirection. By default, the BBI also uses
port 80. Both services cannot use the same port. If the BBI is enabled, configure it to use a
different port.
For example, enter the following command to change the BBI port to 8080:
4. Configure a VLAN for local server traffic, and add server ports to this VLAN.
>> # apply
>> # save
9. Configure the local DNS server to recognize the local GSLB Alteon as the authoritative name
server for the hosted services.
Determine the domain name that will be distributed to both sites and the hostname for each
distributed service. In this example, the Denver DNS server is configured to recognize
174.14.70.2 (the IP interface of the Denver GSLB Alteon, configured with the domain name
"www.gslb.example.com") as the authoritative name server for "www.example.com."
>> Virtual server 1 http service# group 1 (Associate virtual port to real group)
>> Virtual server 1 http service# /cfg/slb/virt (Enable the virtual server)
1/ena
5. On the Denver Alteon, define the type of Layer 4 processing each port must support, as follows:
>> # /cfg/slb/on
Note: Unless you are in the middle of network migration from an Alteon version prior to 22.0,
you should always enable DSSP version 2.
>> # /cfg/slb/gslb/version 2
Each additional remote site would be configured in the same manner. You can enable up to 64
remote sites.
4. On the Denver Alteon, assign each remote distributed service to a local virtual server.
In this step, the local Denver site is configured to recognize the services offered at the remote
San Jose site. As before, configure one real server entry on the Denver Alteon for each virtual
server located at each remote site. Since there is only one remote site (San Jose) with only one
virtual server, only one more local real server entry is needed at the Denver site.
The new real server entry is configured with the IP address of the remote virtual server, rather
than the usual IP address of a local physical server. Do not confuse this value with the IP
interface address on the remote Alteon.
The remote parameter is enabled, and the real server entry is added to the real server group
under the local virtual server for the intended service. Finally, since the real server health checks
are headed across the Internet, the health-checking interval should be increased to 30 or 60
seconds to avoid generating excess traffic. The more remote sites you have, the larger the time
interval should be.
For example:
Note: You should note where each configured value originates or this step can result in
improper configuration.
5. On the Denver Alteon, define the domain name and hostname for each service hosted on each
virtual server.
These are the same as for the San Jose Alteon: the domain name is "gslb.example.com," and
the hostname for the HTTP service is "www." Configure these values as follows:
7. Examine the resulting information. If any settings are incorrect, make and apply any appropriate
changes, and then check again.
8. Save your new configuration changes. Table 62 shows the resulting port usage:
Following a similar procedure as described in Configuring Basic GSLB, page 713, configure a third
site—Tokyo—in standalone mode.
Remember that in standalone mode, Alteon does not require SLB configuration of local real servers.
1. Optionally, on the Tokyo Alteon, configure management access and management gateway
address.
>> # apply
>> # save
6. Configure the local DNS server to recognize the local GSLB device as the authoritative name
server for the hosted services.
Determine the domain name that will be distributed to both sites and the hostname for each
distributed service. In this example, the Tokyo DNS server is configured to recognize 43.10.10.3
(the IP interface of the Tokyo GSLB device) as the authoritative name server for
"www.gslb.example.com."
2. On the Tokyo Alteon, assign each remote distributed service to a local virtual server.
In this step, the local site, Tokyo, is configured to recognize the services offered at the remote
San Jose and Denver sites. As before, configure one real server entry on the Tokyo Alteon for
each virtual server located at each remote site.
The new real server entry is configured with the IP address of the remote virtual server, rather
than the usual IP address of a local physical server. Do not confuse this value with the IP
interface address on the remote Alteon.
Note: You should note where each configured value originates, or this step can result in
improper configuration.
3. Define a network that will match and accept all incoming traffic for the other sites.
4. Define a new rule that will make the new network active.
6. Examine the resulting information. If any settings are incorrect, make and apply any appropriate
changes, and then check again.
Note: If the DNS server is down, the clients (PCC, Sigma phone that supports DNS and AudioCodes
GW) do not work.
Up to 128 rules can be configured, with up to eight metrics per rule. The site selection metric
sequence in the default Rule 1 is as follows:
1. Network Preference—The first metric in Rule 1 is set to Network Preference, which selects
the server based on the preferred network of the source IP address for a given domain. If
preferred networks are not configured, this metric is not used in the default rule. For more
information on configuring preferred networks, see Configuring GSLB Network Preference,
page 733.
2. None—The second metric in Rule 1 is set to None in order to let you configure the local or
availability metric here. The local server or the server with the highest availability is selected
before any subsequent metric is used to select other servers.
3. Geographical preference—The third metric in Rule 1 is set to Geographical Preference so
that the IANA-defined geographical region based on the client source IP is used to redirect the
request to the client's region.
4. Least connections
5. Round-robin—Round-robin, or random, should be the last metric defined in a rule because it
always returns a value if there is at least one functional site.
6. None
7. None
8. Dnsalways—The last metric in Rule 1 should be configured as dnsalways so that the GSLB
selection mechanism selects at least the local virtual server when all servers are not available.
In this case, metric 6 can be configured with DNS always.
>> # /cfg/slb/gslb/rule 2
5. Specify the GSLB metrics to select a site if a server is not selected at first. Since network metric
is the first metric, make sure to add the configured networks to metric 1.
1. Add the rule to the configured virtual server. Using the basic GSLB example, add the following
command to the virtual server configuration as shown in step 5 in To configure the San Jose Site
for GSLB, page 717:
2. Set the availability values for the real/virt servers. For example:
Note: The Alteon lets you configure up to 128 preferred client networks. Each network can contain
up to 1023 real servers.
Using this configuration, the DNS request for "radware.com" from client IP 205.178.13.0 receives a
DNS response with only the virtual server IP address of Site 1, if Site 1 has less load than Site 3.
In this example, the order of preference for Client X is Site C followed by Site B and Site A. When
Client X loads the browser and enters the URL www.radware.com/products/index.html, the system
sends a DNS getHostByname query to the client's local DNS server for the www,radware.com IP
address.
In the client proximity table, the static client proximity entries are set to Site C as the closest.
Note: When the closest site is down, the client is redirected to the next closest site. In Figure
125 - GSLB Client Proximity Site with HTTPS Service, page 735, if Site A determines that Site C
is down, it sends an HTTP redirect message with Site B VIP address/domain name.
To configure Site A
1. Enable SLB, Direct Access Mode (DAM), and GSLB globally.
>> # /cfg/slb/gslb/version 4
3. Set up local real server. For example, the real server IP address is 10.10.10.12.
10. Create a static entry for each remote site with local VIP as the closest site. This prevents client
proximity calculation for health check packets.
>> # /cfg/slb/gslb/network 1
ena
sip 174.14.70.2
mask 255.255.0.0
addvirt 1 1
>> # /cfg/slb/gslb/network 2
ena
sip 201.2.2.201
mask 255.255.0.0
addvirt 1 1
>> # /cfg/slb/gslb/network 3
ena
sip 20.1.1.10
mask 255.0.0.0
addvirt 1 30 (Least preferred site)
addreal 2 20
addreal 3 10 (Most preferred site)
To configure Site B
1. Enable SLB, DAM, and GSLB globally.
>> # /cfg/slb/gslb/version 4
10. Create a static entry for each remote site with local VIP as the closest site. This prevents client
proximity calculation for health check packets.
>> # /cfg/slb/gslb/network 1
ena
sip 210.10.10.1
mask 255.255.0.0
addvirt 1 1
>> # /cfg/slb/gslb/network 2
ena
sip 201.2.2.201
mask 255.255.0.0
addvirt 1 1
To configure Site C
1. Enable SLB, DAM, and GSLB globally.
>> # /cfg/slb/gslb/version 4
10. Create a static entry for each remote site with local VIP as the closest site. This prevents client
proximity calculation for health check packets.
>> # /cfg/slb/gslb/network 1
ena
sip 174.14.70.1
mask 255.255.0.0
addvirt 1 1
>> # /cfg/slb/gslb/network 2
ena
sip 210.10.10.1
mask 255.255.0.0
addvirt 1 1
>> # /cfg/slb/gslb/network 3
ena
sip 20.1.1.10
mask 255.0.0.0
addvirt 1 10 (Most preferred site)
addreal 2 20
addreal 3 30 (Least preferred site)
Note: When the closest site is down, Client X is redirected to the next best site. In the above
example, if Site A determines that Site C is down, it sends an HTTP redirect message with the
Site B VIP address/domain name.
Note: Ensure that the time and date are configured correctly in the GSLB configuration for all
Alteons. Radware recommends that you manually configure the time date using NTP.
3. Create a Zone Signing Key (ZSK) and define its parameters by repeating the same procedure
with the key type ZSK.
Note: DNS zones are explicitly derived from the dname parameter specified in the GSLB
configuration.
Notes
• The DS export is a manual process that needs administrator validation at both ends (the parent
and child zones).
• You can perform this procedure over a secure connection, such as HTTPS or SSH.
• Timers are defined per key, not globally.
• When working with GSLB and DNSSEC enabled, the configuration of remote sites must be
identical for all Alteons participating in the GSLB configuration (/cfg/slb/gslb/site x). See
Example : Configuring Identical Remote Sites with GSLB and DNSSEC, page 745.
# /cfg/slg/gslb/site 1 (London)
Remote site 1# prima 1.2.3.4 (London IP)
Remote site 1# ena
All IP addresses of all the sites must be configured on all Alteons participating in the GSLB DNSSEC
configuration.
Emergency Rollovers
Emergency rollover is an administrator action.
When an emergency KSK rollover is enabled, Alteon waits for the DS record to be signed by the
parent. The timer waits a pre-defined period (KSK Rollover Phase timer). If the administrator does
not ensure that the DS was signed, a warning is issued that the DNSSEC service might be disturbed.
4. The system administrator is notified through SNMP, console, or e-mail that a new emergency
KSK has been created.
5. The KSK rollover is counted to zero.
6. The RR of the Parent must point to the new DNSKEY.
7. A timeout of 48 hours in addition to the TTL of the original KSK starts.
8. The old DNSKEY is removed.
9. The system administrator is notified through SNMP, console, or e-mail that a new emergency
KSK is in place.
10. All KSKs linked to this KSK are signed with the expiration that was set by the user.
To import a key
ZSKs and KSKs are imported in the same way.
1. Access the DNSSEC import menu.
>> /cfg/slb/gslb/dnssec/import
2. Select the zone from which the ZSK or KSK are imported.
>> /cfg/slb/gslb/dnssec/export
2. Select the zone from which the ZSK or KSK are exported.
3. The following is an example set of parameters to enter at each prompt:
>> /cfg/slb/gslb/dnssec/export
2. Select the zone from which the ZSK or KSK are exported.
Note: The export type DS format is for KSK export only. For more information on DNSSEC
export types, see the Alteon Application Switch Operating System Command Reference.
Deleting Keys
1. Access the DNSSEC Key menu.
>> /cfg/slb/gslb/dnssec/key
Enter key id:
Enter key id: 123
------------------------------------------------------------
[Key 123 Menu]
generate - Create new key
expire - Set key expiration period
rollover - Set key rollover period
sigvalid - Set key signature validity period
sigpub - Set key signature publication period
del - Delete key
ena - Enable entry
dis - Disable entry
cur - Display current key configuration
Example
The DNS server holds the example.com domain and has records for a.example.com and
c.example.com. When someone asks for b.example.com, the DNS server responds with an NSEC for
a.example.com and c.example.com.
Note: When issuing an NSEC RRSIG answer, the DNS server uses only one record (NSEC or
NSEC3).
Note: This feature should be used as the method of last resort for GSLB implementations in
topologies where the remote servers are usually virtual server IP addresses in other Alteons.
Figure 126 - HTTP and Non-HTTP Redirects, page 754 illustrates the packet-flow of HTTP and non-
HTTP redirects in a GSLB environment. The following table explains the HTTP or non-HTTP request
from the client when it reaches Site 2, but Site 2 has no available services.
The following procedure explains the three-way handshake between the two sites and the client for
a non-HTTP application (POP3):
1. A user POP3 TCP SYN request is received by the virtual server at Site 2. Alteon at that site
determines that there are no local resources to handle the request.
2. The Site 2 Alteon rewrites the request such that it now contains a client proxy IP address as the
source IP address, and the virtual server IP address at Site 1 as the destination IP address.
3. Alteon at Site 1 receives the POP3 TCP SYN request to its virtual server. The request looks like a
normal SYN frame, so it performs normal local load balancing.
4. Internally at Site 1, Alteon and the real servers exchange information. The TCP SYN ACK from
Site 1's local real server is sent back to the IP address specified by the proxy IP address.
5. The Site 1 Alteon sends the TCP SYN ACK frame to Site 2, with Site 1's virtual server IP address
as the source IP address, and Site 2's proxy IP address as the destination IP address.
6. Alteon at Site 1 receives the frame and translates it, using Site 1's virtual server IP address as
the source IP address and the client's IP address as the destination IP address.
This cycle continues for the remaining frames to transmit all the client's mail, until a FIN frame is
received.
To configure the proxy address at Site 1 in San Jose for the remote server in Denver
1. Issue the following commands:
For more information on proxy IP addresses, see Client Network Address Translation (Proxy IP),
page 190.
2. If you want to configure proxy IP addresses on Site 2, issue the following commands on the
Denver Alteon:
2. Add the service public IP address (NAT) of the device to the Alteon server.
2. Add the service public IP address (NAT) of the device to the Alteon server.
Some corporations use more than one ISP as a way to increase the reliability and bandwidth of their
Internet connection. Enterprises with more than one ISP are referred to as being multihomed.
Instead of multihoming a network to several other networks, BGP-based GSLB enables you to
multihome a particular piece of content (DNS information) to the Internet by distributing the IP
blocks that contain that content to several sites.
When using DNS to select the site, a single packet is used to make the decision so that the request
is not split to different locations. Through the response to the DNS packet, a client is locked into a
particular site, resulting in efficient, consistent service that cannot be achieved when the content
itself is shared.
For example, in multihoming, you can connect a data center to three different Internet providers
and have one DNS server that has the IP address 1.1.1.1. In this case, all requests can be received
via any given feed but are funneled to the same server on the local network. In BGP-based GSLB,
the DNS server (with the IP address 1.1.1.1) is duplicated and placed local to the peering point
instead of having a local network direct traffic to one server.
When a particular DNS server receives a request for a record (in this case, Alteon), it returns with
the IP address of a virtual server at the same site. This can done using the local option (/cfg/
slb/gslb/rule 1/metric 2/gmetric local) in the GSLB configuration. If one site is
saturated, then Alteon will fail over and deliver the IP address of a more available site.
For more information on configuring Alteon to support BGP routing, see Border Gateway Protocol,
page 125.
Contracts
A contract is created to assign a certain amount of bandwidth for an application. Up to 1024
contracts can be configured on a single Alteon. Alteon uses these contracts to limit individual traffic
flows, and can be enabled or disabled as necessary. Contracts can be assigned to different types of
traffic, based on whether it is Layer 2, Layer 4, or Layer 7 traffic, as well as by port, VLAN, trunk,
filters, virtual IP address, service on the virtual server, URL, and so on. Any item that is configured
with a filter can be used for BWM.
Bandwidth classification is performed using the following menus:
• /cfg/slb/filt — Used to configure classifications based on the IP destination address, IP
source address, TCP port number, UDP, UDP port number, 802.1p priority value, or any filter
rule.
Classification Rules
In a classification rule, certain frames are grouped together. For frames qualifying for multiple
classifications, the contract precedence is also specified per contract. If no precedence is specified,
the default order is used (see Classification Precedence, page 763).
The following classifications limit the traffic outbound from the server farm for bandwidth
measurement and control:
• Physical Port—All frames are from a specified physical port.
• VLAN—All frames are from a specified VLAN. If a VLAN translation occurs, the bandwidth policy
is based on the ingress VLAN.
Classification Precedence
There are two mechanisms for frames that qualify for classifications: a per-contract precedence
value and a default precedence ordering from 1 to 255, where the higher numbers have the higher
precedence. If a contract does not have an assigned precedence value, then the default ordering is
applied as follows:
1. Incoming source port/default assignment
2. VLAN
3. Filter
4. Layer 4 services on the virtual server
5. Layer 7 applications (for example, URL, HTTP, headers, cookies, and so on)
If a frame falls into all of classifications (1 through 5), and if the precedence is same for all the
applicable contracts, then the Layer 7 applications contract classification (precedence level 5) is
assigned because it comes last and has the highest precedence.
Combinations
Combinations of classifications are limited to grouping items together into a contract. For example, if
you want to have three different virtual servers associated with a contract, you specify the same
contract index on each of the three virtual server IP addresses. You can also combine filters in this
manner. Combinations are described further in the following sections:
• Grouped Bandwidth Contracts, page 764—Describes how contracts can be grouped together to
aggregate BMW resources.
• IP User Level Contracts for Individual Sessions, page 765—Describes a user-level contract.
Note: The soft and reserved, or Committed Information Rate (CIR), limits of each contract are not
part of the grouped contract's calculation, and remain set at their individual contract's levels.
For a group contract configuration example, see Configuring Grouped Contracts for Bandwidth
Sharing, page 778.
Mbps). Therefore, even though the individual IP user limits do not exceed their 1 Mbps hard limit,
some or all of the IP users may have some traffic dropped because the contract's hard limit (10
Mbps) is less than the total of the offered traffic rate for all 20 users (20 Mbps).
Example User Limits are Maintained When a Contract has Available Bandwidth
An example contract has a hard limit of 10 Mbps and a user limit of 1 Mbps. There are two IP users
for the contract, with an offered traffic rate of 5 Mbps each (for a total offered traffic rate for the
contract of 10 Mbps). Even though the offered traffic rate for the whole contract does not exceed the
hard limit, Alteon limits the traffic for both the IP users to their user limits (1 Mbps each).
The user limit configured for a contract is the limit for one egress Switch Processor (SP) rather than
the entire Alteon. For example, if a contract is configured for a user limit of 64 kbps, and traffic for a
user (IP address) is egressing port 1 (SP 1) and port 20 (SP 2), that user (IP address) is restricted
to 64 kbps egressing on port 1 and 64 kbps egressing out on port 20.
For an example, see Configuring an IP User-Level Rate Limiting Contract, page 780.
Policies
Bandwidth policies are bandwidth limitations defined for any set of frames, that specify the
maximum, best effort, and minimum guaranteed bandwidth rates. A bandwidth policy is assigned to
one or more contracts. You can define up to 64 bandwidth policies.
A bandwidth policy is often based on a rate structure where a Web host or co-location provider could
charge a customer for bandwidth usage. There are three rates that are configured:
• Committed Information Rate (CIR)/Reserved Limit
• Soft Limit
• Hard Limit
Bandwidth limits are usually entered in Mbps. For better granularity, rates can be entered in kbps by
appending k to the entered number. For example, 1 Mbps can be entered as either 1 or as 1024k.
Time Policy
A BWM contract can be configured to apply different time policies defined by ranges of hours or days
of the week. The time policy is based on the time set in Alteon's system clock (see /info/sys/
general).
Configuring Time and Day Policies, page 791 describes how to configure and apply policies to
different times and days.
Enforcing Policies
For BWM contracts and policies to take effect, the policies must be enforced using the /cfg/bwm/
force ena command.
Even when BWM is not enforced, Alteon can still collect classification information and report it,
allowing an administrator to observe a network before deciding how to configure it. This feature can
be disabled using /cfg/bwm/force dis. When this command is used, no limits will be applied on
any contract.
Rate Limiting
A rate limiting contract is controlled by metering the traffic that egresses from Alteon. If the egress
rate is below the configured rate limit (hard limit) for the port, the traffic is transmitted immediately
without any buffering. If the egress rate is above the configured rate limit the traffic above the rate
limit is dropped. This is illustrated in Figure 130 - Bandwidth Rate Limits, page 767.
For rate limiting contracts, the queue depth is ignored because traffic is not buffered.
Typically, bandwidth management occurs on the Alteon egress port, meaning the port from which
the frame is leaving. However, when there are multiple routes or trunk groups, the egress port can
actually be one of several ports (from the point-of-view of where the queues are located).
A bandwidth policy specifies four limits, listed and described in Table 67 - Bandwidth Rate Limits,
page 768:
Note: Session capping per contract is applied on a per SP basis. Session capping per-user is applied
on a per-Alteon basis.
Application session capping is especially relevant in today's world of peer-to-peer applications that
require a large amount of network bandwidth. It enables the administrator to cap the number of
sessions of an application assigned to each user. In this way, peer-to-peer (and other such non-
business applications) can be limited or completely eliminated on the network.
Note: For the purposes of this feature, a user is defined as a unique source IP address and the
application is identified based on a bandwidth contract
Application session capping functions by creating an entry in the session table that designates the
contract/user combination. Whenever a new session is created, this entry is checked against
existing sessions in the session table and, if a match is made, the maximum sessions value is
queried. If the maximum sessions value has been reached, the new session is dropped. If the value
has not been reached, the session count is incremented and the session is allowed to continue.
Notes
• Application session capping is not supported when a contract is assigned to a port, VLAN, trunk,
or virtual service.
• Application session capping does not support an iplimit contract based on DIP. It does, however,
support an iplimit contract based on SIP.
Traffic Shaping
A traffic shaping contract establishes queues and schedules when frames are sent from each queue.
Traffic is shaped by pacing the packets according to the hard, soft, and reserve limits. Each frame is
put into a managed buffer and placed on a contract queue. The time that the next frame is supposed
to be transmitted for the contract queue is calculated according to the configured rate of the
contract, the current egress rate of the ports, and the buffer size set for the contract queue. The
scheduler then organizes all the frames to be sent according to their time-based ordering and
meters them out to the port.
When packets in a contract queue have not yet been sent and the buffer size set for the queue is
full, any new frames attempting to be placed in the queue are discarded.
For traffic shaping contracts, a queue depth is also associated with a policy. A queue depth is the
size of the queue that holds the data. It can be adjusted to accommodate delay-sensitive traffic
(such as audio) versus drop-sensitive traffic (such as FTP).
If the data is arriving more quickly than it can be transmitted at the soft limit, and sufficient
bandwidth is still available, the rate is adjusted upward based on the depth of the queue, until the
rate is fast enough to reduce the queue depth or the hard limit is reached. If the data cannot be
transmitted at the soft limit, then the rate is adjusted downward until the data can be transmitted or
the CIR is hit. If the CIR is overcommitted among all the contracts configured for Alteon, graceful
degradation reduces each CIR until the total bandwidth allocated fits within the total bandwidth
available.
— To send BWM statistics by socket to a reporting server, issue the following commands:
BWM statistics are sent to TCP port 49152 of the specified reporting server.
2. Configure the selected delivery method.
— To configure e-mail usage, issue these commands:
Note: To obtain graphs with this data, the data must be collected and processed by an external
entity through SNMP.
Note: Mirroring occurs before the application of the limiting contract. Packets that would have been
otherwise discarded by the contract are also copied to the mirroring port.
For more information about SLB configuration, see Server Load Balancing, page 165.
2. Enable BWM.
>># /cfg/bwm/on
Note: If you purchased the Bandwidth Management option, be sure to enable it by typing
/oper/swkey and entering the license string. For more information, see Using Bandwidth
Management, page 761.
3. Select a bandwidth policy. Each policy must have a unique number from 1 to 64.
4. Set the hard, soft, and reserved rate limits for the policy, in Mbps.
Typically, charges are applied for burst rates between the soft and hard limit. Each limit must be
set between 64K and 1000M.
Note: For rates less than 1 Mbps, append a k suffix to the number.
5. Optionally, set the Type-Of-Service (TOS) byte value, between 0 and 255, for the policy
underlimit and overlimit.
There are two parameters for specifying the TOS bits: underlimit (utos) and overlimit (otos).
These TOS values are used to overwrite the TOS values of IP packets if the traffic for a contract
is under or over the soft limit, respectively. These values only have significance to a contract if
TOS overwrite is enabled in the Bandwidth Management Contract menu (/cfg/bwm/cont <x>
/wtos ena).
Note: You should use care when selecting the TOS values because of their greater impact on
the downstream routers.
6. Set the buffer limit for the policy. Set a value between 8192 and 128000 bytes. The buffer depth
for a BWM contract should be set to a multiple of the packet size.
Note: The total buffer limit for the Bandwidth Management policy is 128K.
7. On Alteon, select a BWM contract and, optionally, a name for the contract. Each contract must
have a unique number from 1 to 256.
10. Set the bandwidth policy for this contract. Each bandwidth management contract must be
assigned a bandwidth policy.
11. Optionally, enable traffic shaping. Rate limiting is enabled by default. Enabling traffic shaping
disables rate limiting. For more information, see Traffic Shaping, page 769.
13. Classify the frames for this contract and assign the BWM contract to the filter or virtual IP
address.
Each BWM contract must be assigned a classification rule. The classification can be based on a
filter or services on the virtual server. Filters are used to create classification policies based on
the IP source address, IP destination address, TCP port number, UDP, and UDP port number.
In this case, all frames that match filter 1 or Virtual Server 1 will be assigned Contract 1.
Examine the resulting information. If any settings are incorrect, make any appropriate changes.
Check that all BWM contract parameters are set correctly. If necessary, make any appropriate
configuration changes and then check the information again.
>> # /cfg/bwm/pol 1
2. Set the hard, soft, and reserved rate limits for the bandwidth policy, in Mbps.
3. On Alteon, select a BWM contract and name the contract. Each contract must have a unique
number from 1 to 1024.
4. Set the bandwidth policy for this contract. Each BWM contract must be assigned a bandwidth
policy.
7. Set the hard, soft, and reserved rate limits for this policy, in Mbps.
8. On Alteon, select the second BWM contract and name the contract.
9. Set the bandwidth policy for this contract. Each BWM contract must be assigned a bandwidth
policy.
Examine the resulting information. If any settings are incorrect, make any appropriate changes.
12. On Alteon, save your new configuration changes.
Check that all BWM contract parameters are set correctly. If necessary, make any appropriate
configuration changes and then check the information again.
Note: While traffic shaping contracts may be added to a group level contract, their soft and
reserved limits are not readjusted.
>> /cfg/bwm/on
2. Configure Alteon as you normally would for SLB. Configuration includes the following tasks:
— Assign an IP address to each of the real servers in the server pool.
— Define an IP interface on Alteon.
— Define each real server.
— Define a real server group.
— Define a virtual server.
— Define the port configuration.
3. Select the first bandwidth policy and set the hard, soft, and reserved rate limits for the
bandwidth policy, in Mbps.
4. Configure BWM contract 1. Each contract must have a unique number from 1 to 1024.
6. Enable Contract 1.
8. Set the hard, soft, and reserved rate limits for this policy, in Mbps.
10. Assign Bandwidth Policy 2 to Contract 2. Each BWM contract must be assigned a bandwidth
policy.
12. As described in step 7 through step 11, configure Policy 3 with hard, soft, and reserved limits of
30, 25, and 20 Mbps respectively. Then create Contract 3 and apply Policy 3 to this contract.
13. Configure Policy 4 with hard, soft, and reserved limits of 40, 35, and 30 Mbps respectively. Then
create Contract 4 and apply Policy 4 to this contract.
14. Configure BWM Contract Group 1 and add all four contracts to this group.
Examine the resulting information. If any settings are incorrect, make any appropriate changes.
16. Save your new configuration changes.
Check that all BWM contract parameters are set correctly. If necessary, make any appropriate
configuration changes and then check the information again.
>> # /cfg/bwm/pol 1
2. Configure the BWM policy with a hard limit of 10 Mbps and a "user limit" of 64 kbps. Apply that
policy to Contract 1.
3. Configure a filter to match the source IP address range of the student body, and assign BWM
Contract 1 to that filter.
7. Disable traffic shaping on this contract. Traffic shaping cannot be used in user-level rate limiting
contracts.
/stats/bwm/port 1/cont 1
For more information about SLB configuration, refer to Server Load Balancing, page 165.
>> # /cfg/bwm/pol 1
3. Set the hard, soft, and reserved rate limits for the bandwidth policy in Mbps.
4. Select a BWM contract and name the contract. Each contract must have a unique number from 1
to 1024.
5. Assign the bandwidth policy to this contract. Each BWM contract must be assigned a bandwidth
policy.
8. Set the hard, soft, and reserved rate limits for this policy, in Mbps.
10. Assign the bandwidth policy to this contract. Each BWM contract must be assigned a bandwidth
policy.
12. Create a virtual server that is used to classify the frames for Contract 1 and assign the virtual
server IP address for this server. Assign the BWM contract to the virtual server. Repeat this
procedure for a second virtual server.
Note: This classification applies to the services within the virtual server and not to the virtual
server itself.
The classification rule for these BWM contracts is based on a virtual service. One of the BWM
contracts is applied to any frames that are sent to the virtual server associated with that
contract.
>> BWM Contract 2# /cfg/slb/virt 1/service 80/cont (Assign contract to Virtual Server
1 1)
>> Virtual Server 1# vip 100.2.16.2 (Set virtual server VIP address)
>> Virtual Server 1# ena (Enable this virtual server)
>> Virtual Server 1# /cfg/slb/virt 2/cont 2 (Assign contract to virtual server)
>> Virtual Server 2# vip 100.2.16.3 (Set virtual server IP address)
>> Virtual Server 2# ena (Enable this virtual server)
Examine the resulting information. If any settings are incorrect, make the appropriate changes.
14. Save your new configuration changes.
Check that all BWM contract parameters are set correctly. If necessary, make any appropriate
configuration changes and then check the information again.
• Alteon allocates bandwidth based on certain strings in the incoming URL request. For example, if
a Web site has 10 Mbps of bandwidth, the site manager can allocate 1 Mbps of bandwidth for
static HTML content, 3 Mbps of bandwidth for graphic content and 4 Mbps of bandwidth for
dynamic transactions, such as URLs with cgi-bin requests and .asp requests.
• Ability to prioritize transactions or applications.
• By allocating bandwidth, Alteon can guarantee that certain applications and transactions get
better response time.
• Ability to allocate a certain amount of bandwidth for requests that can be cached.
As shown in Figure 132 - URL-Based SLB with Bandwidth Management, page 784, users are able to
allocate a certain percentage of bandwidth for Web cache requests by using the URL parsing and
bandwidth management feature.
This example assumes you have configured URL-based SLB and the layer 7 strings as described in
Content-Intelligent Server Load Balancing, page 219. For URL-based SLB, a user has to first define
strings to monitor. Each of these strings is attached to real servers, and any URL with the string is
load balanced across the assigned servers. The best way to achieve URL-based bandwidth
management is to assign a contract to each defined string. This allocates a percentage of bandwidth
to the string or URL containing the string.
1. Configure Content-Intelligent Server Load Balancing, page 219.
2. Configure BWM policies with the desired bandwidth limits. In this example, four policies are
configured, as illustrated in Figure 132 - URL-Based SLB with Bandwidth Management, page
784.
3. Configure BWM contracts and apply the appropriate policies to the contracts. In this example,
the policy numbers correspond to the contract numbers.
>> # /cfg/slb/layer7/slb/cur
For easy configuration and identification, each defined string is assigned an ID number, as
shown in the following table. The third column shows the BWM contracts to assign to the strings
in this example.
SLB string ID is the identification number of the defined string as displayed when you enter the
cur command. For example: /cfg/slb/real 2/layer7/addlb 3
8. Either enable Direct Access Mode (DAM) on Alteon or configure a proxy IP address on the client
port. To turn on DAM.
To turn off DAM and configure a proxy IP address on the client port.
For more information on proxy IP addresses, see Client Network Address Translation (Proxy IP),
page 190.
Port mapping for content-intelligent SLB can be performed by enabling DAM on Alteon, or
disabling DAM and configuring a proxy IP address on the client port.
9. Turn on HTTP SLB processing on the virtual server. Configure everything under the virtual server
as in Example Configuring User/Application Fairness, page 776.
If the same string is used by more than one service, and you want to allocate a certain
percentage of bandwidth to this URL string for this service on the virtual server, then define a
rule using the urlcont command.
This contract is tied to service 1. The urlcont command overrides the contract assigned to the
URL string ID.
10. Enable SLB.
>> # /cfg/slb/on
Note: Cookie-based BWM does not apply to cookie-based persistency or cookie passive/active
mode applications.
In this example, you assign bandwidth based on cookies. First, configure cookie-based SLB, which is
very similar to URL-based load balancing. Any cookie containing the specified string is redirected to
the assigned server.
A In this scenario, the Web site has a single virtual server IP address and supports multiple classes
of users. Turn on cookie parsing for the service on the virtual server.
For example:
2. Allocate bandwidth for each string. To do this, assign a BWM contract to each defined string.
3. Configure a real server to handle the cookie. To add a defined string where SLB string ID is the
identification number of the defined string:
For example:
4. Either enable DAM on Alteon or configure a proxy IP address on the client port. To turn on DAM:
To turn off DAM and configure a Proxy IP address on the client port:
For more information on proxy IP addresses, see Client Network Address Translation (Proxy IP),
page 190.
Note: By enabling DAM on Alteon or, alternatively, disabling DAM and configuring a proxy on
the client port, port mapping for URL-based load balancing can be performed.
5. Enable SLB.
>> # /cfg/slb/on
B In this scenario, the Web site has multiple virtual server IP addresses, and the same user
classification or multiple sites use the same string name. There are two virtual IP (VIP)
addresses: 172.17.1.1 and 172.17.1.2. Both the virtual servers and sites have first class and
business class customers, with different bandwidth allocations, as shown in Figure 134 -
Cookie-Based Preferential Services, page 789:
The configuration to support this scenario is similar to Example A, page 787. Note the following:
1. Configure the string and assign contracts for the strings and services.
2. If the same string is used by more than one service, and you want to allocate a certain
percentage of bandwidth to a user class for this service on the virtual server, then define a rule
using the urlcont command.
>> # /cfg/slb/virt 1/service 80/http/urlcont <URL path ID> <BW Contract number>
2. Select a bandwidth policy. Each policy must have a number from 1 to 512.
>> # /cfg/bwm/pol 1
3. Set the hard, soft, and reserved rate limits for this policy in kilobytes.
4. Set a parameter between 8192 and 128000 bytes. The buffer depth for a BWM contract should
be set to a multiple of the packet size.
5. On Alteon, select a BWM contract and name the contract. Each contract must have a unique
number from 1 to 1024.
6. Set the bandwidth policy for the contract. Each BWM contract must be assigned a bandwidth
policy.
8. Create a filter that will be used to classify the frames for this contract and assign the BWM
contract to the filter.
The classification rule for this BWM contract is based on a filter configured to match ICMP traffic.
The contract will be applied to any frames that match this filter.
Examine the resulting information. If any settings are incorrect, make the appropriate changes.
10. On Alteon, save your new configuration changes.
Check that all BWM contract parameters are set correctly. If necessary, make any appropriate
configuration changes and then check the information again.
Note: When configuring time policies, the "To" hour cannot be earlier than the "From" hour, as in a
time policy set from 7PM to 7AM. Alteon does not calculate time policies that cross the 24-hour day
boundary.
1. Configure three BWM policies for high, low, and default bandwidth. These policies will be applied
to different time policies in step 5.
>> /cfg/bwm/cont 1
3. Create the first time policy under Contract 1, for peak working hours.
4. Create the second time policy under Contract 1, for weekday evening hours.
5. Apply the default BWM Policy 3 to this contract. This BWM policy will be in effect at all other
times beyond the specifications of the two time policies.
Software Components
This feature uses two distinct software components that work together to interpret XML files sent to
Alteon. These two software components are:
• Schema document—The schema document is the roadmap that enables Alteon to interpret
the XML documents that are sent to it. This schema document defines the markup tags that
appear in the XML document and what each means. The following is an example schema
document used by the XML Configuration API:
• XML Parser—An XML parser is embedded in the software. This parser is used to interpret an
XML file into usable CLI commands.
Notes
• Certificates used for authentication purposes must be in PEM format. Self-signed certificates are
supported for this purpose.
• A certificate can be either obtained via TFTP/FTP or by simply pasting the certificate directly
through the CLI:
FTC1 - ADC-VX - Main# /cfg/sys/access/xml/gtcert
Import from text or file in PEM format [text|file] [text]:
• Running the “gtcert” is only allowed when you are using SSH to access Alteon, if you are using
telnet you will get the following error:
FTC1 - ADC-VX - Main# /cfg/sys/access/xml/gtcert
“Access Denied: This operation can only be performed over a secure connection such as HTTPS
or SSH. Connect to Alteon using a secure protocol and retry.”
XML Configuration
The following is an example procedure to enable and use the XML Configuration API.
Note: All CLI commands with an enable option also have a corresponding disable option.
1. Globally enable XML configuration. The XML Configuration API is disabled by default. To enable
this feature, enter the following command:
2. Optionally, set the XML transport port number. Since SSL is the transport mechanism for the
XML configuration file, the port used by Alteon to receive these files is the SSL port by default.
You can change the default by using the following command:
Note: Since both HTTPS and XML use SSL as a transport layer, the two are closely tied
together. Both HTTPS and XML must use the same port if both are enabled.
3. Import client certificate. Certificate authentication is required to send an XML configuration file
to Alteon. To import a client certificate, do the following:
After entering the required information, the client certificate is downloaded to Alteon.
Enabling XML debug operations results in all commands in the XML file to be displayed on the
console with one of the following prefaces:
— “running XML cmd:”
— “Invalid XML cmd:”
All responses to these commands are also displayed on the console.
AppShape++ Overview
AppShape++ is a framework for customizing application delivery using user-written scripts.
AppShape++ provides the flexibility to control application flows and fully meet business
requirements in a fast and agile manner.
The AppShape++ framework enables you to:
• Extend Radware’s ADC Fabric services with delivery of new applications
• Quickly deploy new services
• Mitigate application problems without changing the application
• Preserve infrastructure investment by adding new capabilities without additional equipment
investment
AppShape++ provides specific API extension to the Tool Command Language (Tcl) to query and
manipulate data, and take actions such as server selection. For more informaton on Tcl, see
www.tcl.tk/.
The AppShape++ scripts can be attached to virtual service thus allowing to perform protocol
content switching decisions and modification on any TCP/UDP protocol.
Note: When attaching an AppShape++ script to a non-HTTP service, legacy content-based load
balancing for that service must be disabled.
Note: For all content-intelligent load balancing features, enable Direct Access Mode (DAM) or
configure proxy IP addresses. For more information, see Direct Access Mode, page 200
Note: Once exclusionary string matching is enabled, clients cannot access the URL strings that are
added to that real server. This means you cannot configure a dedicated server to receive a certain
string and, at the same time, have it exclude other URL strings. The exclusionary feature is enabled
per server, not per string.
string 1 = cgi
string 2 = NOT cgi/form_A
string 3 = NOT cgi/form_B
As a result, all cgi scripts are matched except form_A and form_B.
ID SLB String
1 any
2 test
3 /images
4 /product
If you configured an "any" string and enabled the exclusion option, the server does not handle any
requests. This has the same effect as disabling the server.
Construction Description
* Matches any string of zero or more characters
. Matches any single character
+ Matches one or more occurrences of the pattern it follows
? Matches zero or one occurrences of its followed pattern
$ Matches the end of a line
\ Escape the following special character
[abc] Matches any of the single character inside the bracket
[^abc] Matches any single character except those inside the bracket
^ Matches the pattern exactly only if it appears at the beginning of a line
Use the following rules when defining patterns for string matching:
• Only one layer of parenthesis is supported.
• Only a single "$" (match at end of line) is supported, which must appear at the end of the string.
For example, "abc$*def" is not supported.
• The size of the user input string must be 40 characters or less.
• The size of the regular expression structure after compilation cannot exceed 43 bytes for load-
balancing strings, and 23 bytes for cache redirection. The size of regular expressions after
compilation varies, based on the regular expression characters used in the user input string.
• Use "/" at the beginning of the regular expression. Otherwise a regular expression will have "*"
prefixed to it. For example, "html/*\.htm" appears as "*html/*\.htm".
• Incorrectly or ambiguously formatted regular expressions are rejected instantly. For example:
— Where a "+" or "?" follows a special character, such as the "*" character.
— A single "+" or "?" sign.
— Unbalanced brackets and parenthesis.
>> # /cfg/slb/layer7/slb/addstr
As a result, both HTTP SLB and application redirection can use regular expression as the resource.
Note: The more complex the structure of the string, the longer it will take for the server to load
balance the incoming packets.
Note: Cookie persistence can also be combined with the Layer 7 content types. For more
information on cookie persistence, see Persistence, page 583
The following are example scenarios for which to use the Content Precedence Lookup feature:
• If the client request is sent without a cookie and if no HTTP SLB is configured, then Alteon binds
the request to the real server using normal SLB.
• If the client request is sent without a cookie, but HTTP SLB is configured on Alteon, then the
request is bound to real server based on HTTP SLB.
• If the client request is sent with a cookie, and a real server associated to the cookie is found in
the local session table, then the request stays bound to that real server.
Requirements
• Enable Direct Access Mode (DAM), or configure proxy IP address if DAM is disabled.
• Enable delayed binding.
If you have configured Content Precedence Lookup with the or and and operators, the request from
the client is as follows:
• HTTP Host or URL SLB—The HTTP Host header takes precedence because it is specified first.
If there is no Host Header information, and because or is the operator, the URL string is
examined next.
— If a request from a client contains no Host Header but has a URL string (such as "/gold"),
the request is load balanced on Server 1 or Server 3.
— If a request from a client contains a Host Header, then the request is load balanced between
Server 2 and Server 3. The URL string is ignored because the HTTP Host was specified and
matched first.
• HTTP Host and URL SLB—The HTTP Host header takes precedence because it is specified first.
Because and is the operator, both a Host Header and URL string are required. If either is not
available, the request is dropped.
— If a request from a client contains a URL string (such as "/gold") but not a Host Header, it is
not served by any real server.
— If a request from a client contains a URL string (such as "/gold") and Host Header, it is
served only by real server 3.
To configure Content Precedence Lookup for this example, the hosting company groups all the real
servers into one real server group even though different servers provide services for different
customers and different types of content. In this case, the servers are set up for the purpose as
illustrated in Table 69.
When a client request is received with www.a.com in the Host Header and .jpg in the URL, the
request is load balanced between Server 1 and Server 2. For this configuration to work properly, you
must assign multiple strings (a Host Header string and a URL string) for each real server.
1. default.asp
2. search.asp
String case sensitivity may be disabled, so that any incoming request containing GET /Default.asp,
GET /DEFAULT.ASP, and other case combinations, all map to string 1.
>> # /cfg/slb/layer7/slb/cur
>> # /cfg/slb/layer7/slb/addmeth 2
The list of supported HTTP methods is updated regularly in Alteon as the HTTP protocol evolves.
Note: When Layer 7 load balancing is configured, Alteon does not support IP fragments. If IP
fragments were supported in this mode, Alteon would have to buffer, re-assemble, and inspect
packets before making a forwarding decision.
Note: Both HTTP 1.0 and HTTP 1.1 requests are supported.
For URL matching you, can configure up to 1024 strings comprised of 40 bytes each. Each URL
request is then examined against the URL strings defined for each real server. URL requests are load
balanced among multiple servers matching the URL, according to the load-balancing metric
configured for the real server group (leastconns is the default).
Consider an example where the following criteria are specified for content load balancing:
• Requests with ".cgi" in the URL are forwarded to Real Servers 3 and 4.
• Requests with the string "images" in the URL are sent to Real Servers 1 and 2.
• Requests with URLs starting with "/product:" are sent to Real Servers 2, 3, and 5.
Requests containing URLs with anything else are sent to Real Servers 1, 2, 3, and 4. These servers
have been defined with the "any" string.
Note: When URL-based SLB is used in an active/active redundant setup, use a proxy IP
address instead of Direct Access Mode (DAM) to enable the URL parsing feature.
• /index.shtm
3. Apply and save your configuration changes.
4. Identify the defined string IDs.
>> # /cfg/slb/layer7/slb/cur
For easy configuration and identification, each defined string is assigned an ID number, as
shown below:
ID SLB String
1 any
2 .gif
3 /sales
4 /xitami
5 /manual
6 .jpg
Note: If you do not add a defined string (or add the defined string any) the server handles any
request.
>> # /cfg/slb/on
7. Enable DAM or configure proxy IP addresses and enable proxy on the client port.
DAM and proxy IPs allow you to perform port mapping for URL load balancing.
— Enable DAM
For more information on proxy IP addresses, see Client Network Address Translation (Proxy IP),
page 190.
8. Enable URL-based SLB on the virtual servers.
>> # /stats/slb/layer7/str
Virtual Hosting
Alteon allows individuals and companies to have a presence on the Internet in the form of a
dedicated Web site address. For example, you can have a "www.site-a.com" and "www.site-b.com",
instead of "www.hostsite.com/site-a" and "www.hostsite.com/site-b."
Service providers, on the other hand, do not want to deplete the pool of unique IP addresses by
dedicating an individual IP address for each home page they host. By supporting an extension in
HTTP 1.1 to include the host header, Alteon enables service providers to create a single virtual
server IP address to host multiple Web sites per customer, each with their own host name.
Note: For SLB, one HTTP header is supported per virtual server.
The following list provides more details on virtual hosting with configuration information:
• An HTTP/1.0 request sent to an origin server (not a proxy server) is a partial URL instead of a
full URL.
An example of the request that the origin server would see as follows:
GET /products/Alteon/ HTTP/1.0User-agent: Mozilla/3.0Accept: text/html,
image/gif, image/jpeg
The GET request does not include the hostname. From the TCP/IP headers, the origin server
knows the requests hostname, port number, and protocol.
• With the extension to HTTP/1.1 to include the HTTP HOST: header, the above request to retrieve
the URL www.radware.com/products/Alteon would look like this:
GET /products/Alteon/ HTTP/1.1
Host: www.radware.com
User-agent: Mozilla/3.0
Accept: text/html, image/gif, image/jpeg
The Host: header carries the hostname used to generate the IP address of the site.
• Based on the Host: header, Alteon forwards the request to servers representing different
customer Web sites.
• The network administrator needs to define a domain name as part of the 128 supported URL
strings.
• Alteon performs string matching. That is, the string "radware.com" or "http://
www.radware.com/” " matches ""http://www.radware.com/".
To support virtual hosting, configure Alteon for Host header-based load balancing
1. Before you can configure host header-based SLB, ensure that Alteon has already been
configured for basic SLB:
— Assign an IP address to each of the real servers in the server pool.
— Define an IP interface.
— Define each real server.
— Assign servers to real server groups.
— Define virtual servers and services.
For information on how to configure your network for SLB, see Server Load Balancing, page 165.
2. Turn on URL parsing for the virtual server for virtual hosting.
4. Configure the real servers to handle the appropriate load balancing strings. To add a defined
string where ID is the identification number of the defined string.
Note: The server handles any request if no string or the string any is defined.
• Applications—Identify users by the specific application they are using. For example, priority
can be given to HTTPS traffic that is performing credit card transactions versus HTTP browsing
traffic.
• Content—Identify users by the specific content they are accessing.
Based on one or more of these criteria, you can load balance requests to different server groups.
>> # /cfg/slb/virt 1
>> Virtual Server 1 # service 80
>> Virtual Server 1 http Service # http
>> HTTP Load Balancing# httpslb
>> Application:
>> urlslb|host|cookie|browser|urlhash|headerhash|version|others|none
>> Select Application:cookie
>> Operation: and|or|none
>> Select Operation: ena
>> Enter Cookie Name: sid
>> Enter the starting point of the Cookie value [1-64]: 1
>> Enter the number of bytes to extract [1-64]: 6
>> Look for Cookie in URI [e:d]: d
In this example
— sid is the cookie name
— 1 is the offset (the starting position of the value to be used for hashing)
— 6 is the length (the number of bytes in the cookie value)
— d looks for the cookie in the cookie header instead of the URI (disables searching for cookie
in the URI)
3. Define the cookie values.
Because a session cookie does not exist in the first request of an HTTP session, a default server
or any server is needed to assign cookies to a None cookie HTTP request.
Example
• Real Server 1—Gold handles gold requests.
• Real Server 2—Silver handles silver request.
• Real Server 3—Bronze handles bronze request.
• Real Server 4—any handles any request that does not have a cookie or matching cookie.
With servers defined to handle the requests listed above, the following occurs:
• Request 1 comes in with no cookie; it is forwarded to Real Server 4 to get cookie assigned.
• Request 2 comes in with a "Gold" cookie; it is forwarded to Real Server 1.
• Request 3 comes in with a "Silver" cookie; it is forwarded to Real Server 2.
• Request 4 comes in with a "Bronze" cookie; it is forwarded to Real Server 3.
• Request 5 comes in with a "Titanium" cookie; it is forwarded to Real Server 4, since it does not
have an exact cookie match (matches with "any" configured at Real Server 4).
4. Configure the real servers to handle the appropriate load balancing strings. Add a defined string,
where ID is the identification number of the string:
Note: If you do not add a defined string (or add the defined string any), the server handles
any request.
5. Enable DAM on Alteon or configure proxy IP addresses and enable proxy on the client port.
To use cookie-based preferential load balancing without DAM, you must configure proxy IP
addresses.
Enable proxy load balancing on the port used for cookie-based preferential load balancing. If
Virtual Matrix Architecture (VMA) is enabled, you can choose to configure the remaining ports
with proxy disabled.
4. Configure the real servers to handle the appropriate load balancing strings.
Note: If you do not add a defined string (or add the defined string any), the server handles
any request.
Use the following command to add a defined string, where ID is the identification number of the
defined string.
ID SLB String
1 any, cont 256
2 HTTPHDR=Host:wap.example.com
3 HTTPHDR=Host:wap.yahoo.com
4 HTTPHDR=Host:wap.google.com
5 HTTPHDR=Host:wap.p-example.com
6 HTTPHDR=Host:10.168.224.227=/top
7 jad, cont 256
8 jar, cont 256
9 HTTPHDR=Accept:text/vnd.foo.j2me.app-descriptor
10 HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST_URL
11 HTTPHDR=Host:any
12 HTTPHDR=Host:any:90
13 HTTPHDR=Host:any:8080
14 HTTPHDR=X-Foo-ipaddress:10.168.100.*
15 HTTPHDR=Host:www.abc.com, cont 256
16 HTTPHDR=Host:any:443, cont 256
17 HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST/nava/toggle.jad, nre,
cont 1024
18 HTTPHDR=Host:mobile.example.com=/4g/w?url=dev.example.com/$URL, nre, cont
1024
1. Configure Alteon with the basic SLB requirements as described in Server Load Balancing
Configuration Basics, page 171.
2. Configure the filter strings.
>> # /cfg/slb/layer7/slb/
>> Server Loadbalance Resource# addstr (Add the first SLB string)
Enter type of string [l7lkup|pattern]: l7lkup
Select Application (http|dns|other) [other]:
http
Configure HTTP header string? (y/n) [n] y
Enter HTTP header name: Host
Enter SLB header value string: wap.example.com
Configure URL string? (y/n) [n] n
>> # /cfg/slb/layer7/slb/ (Select the Server Loadbalance
Resource menu)
>> Server Loadbalance Resource# add (Add the second SLB string)
Configure HTTP header string? [y/n] y
Enter HTTP header name: Host (Define HTTP header name Host)
Enter SLB header value string: wap.yahoo.com
3. Use the same commands as step 2 to configure the rest of the filter strings shown in Server
Load Balancing Configuration Basics, page 171.
4. Identify the ID numbers of the defined strings.
>> # /cfg/slb/layer7/slb/cur
Number of entries: 1
41: any, cont 256
2: HTTPHDR=Host:wap.example.com, cont 256
3: HTTPHDR=Host:wap.yahoo.com, cont 256
4: HTTPHDR=Host:wap.google.com, cont 256
5: HTTPHDR=Host:wap.p-example.com, cont 256
6: HTTPHDR=Host:10.168.224.227=/top, cont 256
7: jad, cont 256
8: jar, cont 256
9: HTTPHDR=Accept:text/vnd.foo.j2me.app-descriptor, cont 256
10: HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST_URL, cont 256
11: HTTPHDR=Host:any, cont 256
12: HTTPHDR=Host:any:90, cont 256
13: HTTPHDR=Host:any:8080, cont 256
14: HTTPHDR=X-Foo-ipaddress:10.168.100.* , cont 256
15: HTTPHDR=Host:www.abc.com, cont 256
16: HTTPHDR=Host:any:443, cont 256
17: HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST/nava/toggle.jad, nre, cont
1024
18: HTTPHDR=Host:mobile.example.com=/4g/w?url=dev.example.com/$URL, nre, cont
1024
5. Configure a port for client traffic. This configuration assumes client traffic enters Alteon on port
1. Enabled filtering on the client port.
The basic HTTP redirection configuration is now complete and can be used for each of the
redirection options described in the following sections.
The following rules filter client requests from different WAP gateways:
• Filter 1—If the client IP address is between 10.168.43.0-255 and the requested URL is http:/
/wap.example.com, then redirect the client request to http://wap.yahoo.com.
• Filter 2—If the Client IP address is between 10.46.6.0.0-255 and the requested URL is http:/
/wap.example.com, then redirect the client request to http://wap.google.com.
• Filter 3—If the client IP address is between 10.23.43.0- 255 and the requested URL is http:/
/wap.p-example.com, then redirect the client request to
http://10.168.224.227/top.
Assuming that each client is in a different subnet, configure Alteon with three filters to redirect client
requests from each subnet, to the URLs specified above. Use the string index numbers in Table 70 -
Example HTTP Redirection Strings, page 819 to configure a redirection map for each filter.
1. Identify the ID numbers of the defined strings. The strings in bold in the filters defined above
are used in this example.
>> # /cfg/slb/layer7/slb/cur
Number of entries: 14
1: any, cont 256
2: HTTPHDR=Host:wap.example.com, cont 256
3: HTTPHDR=Host:wap.yahoo.com, cont 256
4: HTTPHDR=Host:wap.google.com, cont 256
5: HTTPHDR=Host:wap.p-example.com, cont 256
6: HTTPHDR=Host:10.168.224.227=/top, cont 256
7: jad, cont 256
8: jar, cont 256
9: HTTPHDR=Accept:text/vnd.foo.j2me.app-descriptor, cont 256
10: HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST_URL, cont 256
11: HTTPHDR=Host:any, cont 256
12: HTTPHDR=Host:any:90, cont 256
13: HTTPHDR=Host:any:8080, cont 256
14: HTTPHDR=X-Foo-ipaddress:10.168.100.* , cont 256
15: HTTPHDR=Host:www.abc.com, cont 256
16: HTTPHDR=Host:any:443, cont 256
17: HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST/nava/toggle.jad, nre, cont
1024
18: HTTPHDR=Host:mobile.example.com=/4g/w?url=
dev.example.com/$URL, nre, cont 1024
2. Configure Filter 1.
>> /cfg/slb/filt 1
>> Filter 1 # sip 10.168.43.0 (From this source IP address range)
Current source address: any
New pending source address: 10.168.43.0
>> Filter 1 # smask 255.255.255.0
Current source mask: 0.0.0.0
New pending source mask: 255.255.255.0
3. Configure Filter 2.
>> /cfg/slb/filt 2
>> Filter 2 # sip 10.46.6.0.0
Current source address: any
New pending source address: 10.46.6.0.0
>> Filter 2 # smask 255.255.255.0
Current source mask: 0.0.0.0
New pending source mask: 255.255.255.0
>> Filter 2 # proto tcp
Enter protocol or any: udp
Pending new protocol: tcp
>> Filter 2 # dport http
Current destination port or range: any
Pending new destination port or range: http
>> Filter 2 # action redir
Current action: allow
Pending new action: redir
>> Filter 2 # /cfg/slb/filt/adv/layer7
>> Layer 7 Advanced# addrd
Enter filtering string ID (1-1024) to redirect from: 2
Enter filtering string ID (2-1024) to redirect to: 4
4. Configure Filter 3.
>> /cfg/slb/filt 3
>> Filter 3 # sip 10.23.43.0
Current source address: any
New pending source address: 10.23.43.0
>> Filter 3 # smask 255.255.255.0
Current source mask: 0.0.0.0
New pending source mask: 255.255.255.0
>> Filter 3 # proto tcp
Enter protocol or any: udp
Pending new protocol: tcp
>> Filter 3 # dport http
Current destination port or range: any
Pending new destination port or range: http
>> Filter 3 # action redir
Current action: allow
Pending new action: redir
>> Filter 3 # /cfg/slb/filt/adv/layer7
>> Layer 7 Advanced# addrd
Enter filtering string ID (1-1024) to redirect from: 5
Enter filtering string ID (2-1024) to redirect to: 6
1. Identify the ID numbers of the defined strings. The strings in bold in the filters defined above
are used in this example.
>> # /cfg/slb/layer7/slb/cur
Number of entries: 141: any, cont 256
2: HTTPHDR=Host:wap.example.com, cont 256
3: HTTPHDR=Host:wap.yahoo.com, cont 256
4: HTTPHDR=Host:wap.google.com, cont 256
5: HTTPHDR=Host:wap.p-example.com, cont 256
6: HTTPHDR=Host:10.168.224.227=/top, cont 256
7: jad, cont 256
8: jar, cont 256
9: HTTPHDR=Accept:text/vnd.foo.j2me.app-descriptor , cont 256
10: HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST_URL, cont 256
11: HTTPHDR=Host:any, cont 256
12: HTTPHDR=Host:any:90, cont 256
13: HTTPHDR=Host:any:8080, cont 256
14: HTTPHDR=X-Foo-ipaddress:10.168.100.* , cont 256
15: HTTPHDR=Host:www.abc.com, cont 256
16: HTTPHDR=Host:any:443, cont 256
17: HTTPHDR=Host:mobile.example.com=/4g/w?url=
$HOST/nava/toggle.jad, nre, cont 1024
18: HTTPHDR=Host:mobile.example.com=/4g/w?url=dev.example.com/$URL, nre, cont
1024
2. Configure Filter 4.
>> /cfg/slb/filt 4
>> Filter 4 # dip 10.46.6.231
Current destination address: any
New pending destination address: 10.46.6.231
>> Filter 4 # smask 255.255.255.255
Current source mask: 0.0.0.0
New pending source mask: 255.255.255.255
>> Filter 4 # proto tcp
Enter protocol or any: udp
Pending new protocol: tcp
>> Filter 4 # dport http
Current destination port or range: any
Pending new destination port or range: http
>> Filter 4 # action redir
Current action: allow
Pending new action: redir
>> Filter 4 # /cfg/slb/filt/adv/layer7
>> Layer 7 Advanced# addrd
Enter filtering string ID (1-1024) to redirect from: 11
Enter filtering string ID (2-1024) to redirect to: 12
3. Configure Filter 5.
>> /cfg/slb/filt 5
>> Filter 5 # dip 10.46.6.231
Current destination address: any
New pending destination address: 10.46.6.231
>> Filter 5 # smask 255.255.255.255
Current source mask: 0.0.0.0
New pending source mask: 255.255.255.255
>> Filter 5 # proto tcp
Enter protocol or any: udp
Pending new protocol: tcp
>> Filter 5 # dport http
Current destination port or range: any
Pending new destination port or range: http
>> Filter 5 # action redir
Current action: allow
Pending new action: redir
>> Filter 5 # /cfg/slb/filt/adv/layer7
>> Layer 7 Advanced# addrd
Enter filtering string ID (1-1024) to redirect from: 11
Enter filtering string ID (2-1024) to redirect to: 13
1. Identify the ID numbers of the defined strings. The strings in bold are used in this example.
>> # /cfg/slb/layer7/slb/cur
Number of entries: 14
1: any, cont 256
2: HTTPHDR=Host:wap.example.com, cont 256
3: HTTPHDR=Host:wap.yahoo.com, cont 256
4: HTTPHDR=Host:wap.google.com, cont 256
5: HTTPHDR=Host:wap.p-example.com, cont 256
6: HTTPHDR=Host:10.168.224.227=/top, cont 256
7: jad, cont 256
8: jar, cont 256
9: HTTPHDR=Accept:text/vnd.foo.j2me.app-descriptor , cont 256
10: HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST_URL, cont 256
11: HTTPHDR=Host:any, cont 256
12: HTTPHDR=Host:any:90, cont 256
13: HTTPHDR=Host:any:8080, cont 256
14: HTTPHDR=X-Foo-ipaddress:10.168.100.* , cont 256
15: HTTPHDR=Host:www.abc.com, cont 256
16: HTTPHDR=Host:any:443, cont 256
17: HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST/nava/toggle.jad, nre, cont
1024
18: HTTPHDR=Host:mobile.example.com=/4g/w?url=dev.example.com/$URL, nre, cont
1024
2. Configure Filter 6. The filter intercepts string 7, 8, and 9 and then redirects them based on
strings 10, 17, and 18 information. The $HOST_URL is replaced with the incoming request from
the HOST and URL strings. The $HOST is replaced with the incoming request from HOST string.
The $URL is replaced with the incoming request from the URL string.
>> /cfg/slb/filt 6
>> Filter 6 # dip 10.46.6.231
Current destination address: any
New pending destination address: 10.46.6.231
>> Filter 6 # smask 255.255.255.255
Current source mask: 0.0.0.0
New pending source mask: 255.255.255.255
>> Filter 6 # proto tcp
Enter protocol or any: udp
Pending new protocol: tcp
>> Filter 6 # dport http
Current destination port or range: any
Pending new destination port or range: http
>> Filter 6 # action redir
Current action: allow
Pending new action: redir
>> Filter 6 # /cfg/slb/filt/adv/layer7
>> Layer 7 Advanced# addrd
Enter filtering string ID (1-1024) to redirect from: 7
Enter filtering string ID (2-1024) to redirect to: 10
>> Layer 7 Advanced# addrd
Enter filtering string ID (1-1024) to redirect from: 8
Enter filtering string ID (2-1024) to redirect to: 17
>> Layer 7 Advanced# addrd
Enter filtering string ID (1-1024) to redirect from: 9
Enter filtering string ID (2-1024) to redirect to: 18
>> # /cfg/slb/layer7/slb/cur
Number of entries: 14
1: any, cont 256
2: HTTPHDR=Host:wap.example.com, cont 256
3: HTTPHDR=Host:wap.yahoo.com, cont 256
4: HTTPHDR=Host:wap.google.com, cont 256
5: HTTPHDR=Host:wap.p-example.com, cont 256
6: HTTPHDR=Host:10.168.224.227=/top, cont 256
7: jad, cont 256
8: jar, cont 256
9: HTTPHDR=Accept:text/vnd.foo.j2me.app-descriptor, cont 256
10: HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST_URL, cont 256
11: HTTPHDR=Host:any, cont 256
12: HTTPHDR=Host:any:90, cont 256
13: HTTPHDR=Host:any:8080, cont 256
14: HTTPHDR=X-Foo-ipaddress:10.168.100.* , cont 256
15: HTTPHDR=Host:www.abc.com, cont 256
16: HTTPHDR=Host:any:443, cont 256
17: HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST/nava/toggle.jad, nre, cont
1024
18: HTTPHDR=Host:mobile.example.com=/4g/w?url=dev.example.com/$URL, nre, cont
1024
2. Configure Filter 7 to redirect the URL as described above. By default, filter protocol is any.
Change it to udp.
>> /cfg/slb/filt 7
>> Filter 7 # dip 10.46.6.231
Current destination address: any
New pending destination address: 10.46.6.231
>> Filter 7 # smask 255.255.255.255
Current source mask: 0.0.0.0
New pending source mask: 255.255.255.255
>> Filter 7 # proto tcp
Enter protocol or any: udp
Pending new protocol: tcp
>> Filter 7 # dport httpCurrent destination port or range: any
Pending new destination port or range: http
>> Filter 7 # action redirCurrent action: allow
Pending new action: redir
>> Filter 7 # /cfg/slb/filt/adv/layer7
>> Layer 7 Advanced# addrd
Enter filtering string ID (1-1024) to redirect from: 2
Enter filtering string ID (2-1024) to redirect to: 6
>> # /cfg/slb/layer7/slb/cur
Number of entries: 14
1: any, cont 256
2: HTTPHDR=Host:wap.example.com, cont 256
3: HTTPHDR=Host:wap.yahoo.com, cont 256
4: HTTPHDR=Host:wap.google.com, cont 256
5: HTTPHDR=Host:wap.p-example.com, cont 256
6: HTTPHDR=Host:10.168.224.227=/top, cont 256
7: jad, cont 256
8: jar, cont 256
9: HTTPHDR=Accept:text/vnd.foo.j2me.app-descriptor , cont 256
10: HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST_URL, cont 256
11: HTTPHDR=Host:any, cont 256
12: HTTPHDR=Host:any:90, cont 256
13: HTTPHDR=Host:any:8080, cont 256
14: HTTPHDR=X-Foo-ipaddress:10.168.100.* , cont 256
15: HTTPHDR=Host:www.abc.com, cont 256
16: HTTPHDR=Host:any:443, cont 256
17: HTTPHDR=Host:mobile.example.com=/4g/w?url=$HOST/nava/toggle.jad, nre, cont
1024
18: HTTPHDR=Host:mobile.example.com=/4g/w?url=dev.example.com/$URL, nre, cont
1024
2. Configure Filter 8 redirect URL as described above. By default, filter protocol is any. Change it to
udp.
>> /cfg/slb/filt 8
>> Filter 8 # sip 10.46.6.231
Current source address: any
New pending source address: 10.46.6.231
>> Filter 8 # smask 255.255.255.255
Current source mask: 0.0.0.0
New pending source mask: 255.255.255.255
>> Filter 8 # proto tcp
Enter protocol or any: udp
Pending new protocol: tcp
>> Filter 8 # dport http
Current destination port or range: any
Pending new destination port or range: http
>> Filter 8 # action redir
Current action: allow
Pending new action: redir
>> Filter 8 # /cfg/slb/filt/adv/layer7
>> Layer 7 Advanced# addrd
Enter filtering string ID (1-1024) to redirect from: 2
Enter filtering string ID (2-1024) to redirect to: 14
/c/slb/layer7/slb/cur
ren 2 "HTTPHDR=Host:any"
ren 3 "HTTPHDR=Host:www.abc.com,"
ren 4 "HTTPHDR=Host:any:443"
/c/slb/filt 9
ena
action redir
ipver v4
proto tcp
dport http
/c/slb/filt 9/adv/layer7
l7lkup ena
addrd 3>4
/c/slb/filt 10
ena
action redir
ipver v4
dip 205.10.10.10
proto tcp
dport http
/c/slb/filt 10/adv/layer7
l7lkup ena
addrd 2>4
7. Enable SLB.
11. Configure the IPv6 redirection filter to redirect all HTTP traffic to the cache servers.
13. Enable filter processing on client ports and add the two filters to the client ports.
IPv4 IPv6
Source and destination addresses are 32 bits Source and destination addresses are 128 bits (16
(4 bytes) in length. bytes) in length.
IPSec support is optional. IPSec support is required.
No identification of packet flow for QoS Packet flow identification for QoS handling by
handling by routers is present within IPv4. routers is present within the IPv6 header using the
Flow Label field.
Fragmentation is performed by the sending Fragmentation is performed only by the sending
host, and at the routers, thus slowing host.
performance.
No link-layer packet size requirements and Link layer must support 1,280 byte packet and rea
has to reassemble 576-byte packet. 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 ARP Request frames are replaced with multicast
resolve an IPv4 address to a link layer Neighbor Solicitation (Discovery) messages.
address.
IGMP is used to manage local subnet group IGMP is replaced with Multicast Listener Discovery
membership. (MLD) messages.
IPv4 IPv6
ICMP Router Discovery is used to determine ICMPv4 Router Discovery is replaced with ICMPv6
the IPv4 address of the best default gateway Router Solicitation (Discovery) and Router
and is optional. Advertisement messages and is required.
Broadcast addresses are used to send traffic There are no IPv6 broadcast addresses. Instead a
to all nodes on the subnet. link-local scope all-nodes multicast address is used.
Must be configured either manually or IPV6 does not require manual or DHCP
through DHCP for IPv4. configuration.
Uses host address (A) resource records in Uses AAAA records in the DNS to map host names
DNS to map host names to IPv4 addresses. to IPv6 addresses.
Uses pointer (PTR) resource records in the Uses pointer (PTR) resource records in the IP6.INT
IN-ADDR.ARPA DNS domain to map IPv4 DNS domains to map IPv6 addresses to host
addresses to host names. names.
Example
FEDC:BA98:7654:BA98:FEDC:1234:ABCD:5412
Example
The address FE80:0:0:0:2AA:FF:FA:4CA2 can be compressed to FE80::2AA:FF:FA:4CA2.
Unlike IPv4, a subnet mask is not used for IPv6 addresses.
Example
In this example, 64 is the network prefix:
21DA:D300:0000:2F3C::/64
Unicast
There are two types of unicast addresses:
• Global unicast address—This is an address that can be reached and identified globally. Global
unicast addresses use the high-order bit range from 2000 to 3FFF. If the last 64 bits of the
address are not configured, Alteon defaults to the EUI-64 (Extended Unique Identifier 64-bit)
address format. RFC 3513 defines the expanding of the Ethernet MAC address based on a 48-bit
format into a 64-bit EUI-64 format.
The interface ID must be unique within the same subnet.
• Link-local unicast address—This is an address used to communicate with a neighbor on the
same link. Link-local addresses use the high-order bit range from FE80 to FEBF. Link-local
unicast addresses are configured on the interface by using the link-local prefix FE80::/10 and
the interface identifier in EUI-64 format for its low-order 64-bit. Link-local packets are not
routed between subnets.
Multicast
A multicast address (FF00 to FFFF) is an identifier for a group interface. The multicast address most
often encountered is a solicited-mode multicast address using prefix FF02::1:FF00:0000/104 with
the low-order 24 bits of the unicast or anycast address.
Anycast
Anycast addresses can be global unicast, site-local or link-local addresses used for a one-to-nearest
node member of the anycast group communication. Alteon does not support anycast addresses.
To specify the interface number when pinging to a IPv6 link-local unicast address
nonexclusive, nontransferable license to copy and modify the Code Samples and create
derivative works based thereon solely for the SDK Purpose and solely on computers within your
organization. The SDK shall be considered part of the term “Software” for all purposes of this
License Agreement. You agree that you will not assign, sublicense, transfer, pledge, lease, rent
or share your rights under this License Agreement nor will you distribute copies of the Software
or any parts thereof. Rights not specifically granted herein, are specifically prohibited.
2. Evaluation Use. Notwithstanding anything to the contrary in this License Agreement, if the
Software is provided to you for evaluation purposes, as indicated in your purchase order or sales
receipt, on the website from which you download the Software, as inferred from any time-
limited evaluation license keys that you are provided with to activate the Software, or otherwise,
then You may use the Software only for internal evaluation purposes (“Evaluation Use”) for a
maximum of 30 days or such other duration as may specified by Radware in writing at its sole
discretion (the “Evaluation Period”). The evaluation copy of the Software contains a feature that
will automatically disable it after expiration of the Evaluation Period. You agree not to disable,
destroy, or remove this feature of the Software, and any attempt to do so will be a material
breach of this License Agreement. During or at the end of the evaluation period, you may
contact Radware sales team to purchase a Commercial License to continue using the Software
pursuant to the terms of this License Agreement. If you elect not to purchase a Commercial
License, you agree to stop using the Software and to delete the evaluation copy received
hereunder from all computers under your possession or control at the end of the Evaluation
Period. In any event, your continued use of the Software beyond the Evaluation Period (if
possible) shall be deemed your acceptance of a Commercial License to the Software pursuant to
the terms of this License Agreement, and you agree to pay Radware any amounts due for any
applicable license fees at Radware's then-current list prices.
3. Subscription Software. If you licensed the Software on a subscription basis, your rights to use
the Software are limited to the subscription period. You have the option to extend your
subscription. If you extend your subscription, you may continue using the Software until the end
of your extended subscription period. If you do not extend your subscription, after the expiration
of your subscription, you are legally obligated to discontinue your use of the Software and
completely remove the Software from your system.
4. Feedback. Any feedback concerning the Software including, without limitation, identifying
potential errors and improvements, recommended changes or suggestions (“Feedback”),
provided by you to Radware will be owned exclusively by Radware and considered Radware's
confidential information. By providing Feedback to Radware, you hereby assign to Radware all of
your right, title and interest in any such Feedback, including all intellectual property rights
therein. With regard to any rights in such Feedback that cannot, under applicable law, be
assigned to Radware, you hereby irrevocably waives such rights in favor of Radware and grants
Radware under such rights in the Feedback, a worldwide, perpetual royalty-free, irrevocable,
sublicensable and non-exclusive license, to use, reproduce, disclose, sublicense, modify, make,
have made, distribute, sell, offer for sale, display, perform, create derivative works of and
otherwise exploit the Feedback without restriction. The provisions of this Section 4 will survive
the termination or expiration of this Agreement.
5. Limitations on Use. You agree that you will not: (a) copy, modify, translate, adapt or create
any derivative works based on the Software; or (b) sublicense or transfer the Software, or
include the Software or any portion thereof in any product; or (b) reverse assemble, decompile,
reverse engineer or otherwise attempt to derive source code (or the underlying ideas,
algorithms, structure or organization) from the Software; or (c) remove any copyright notices,
identification or any other proprietary notices from the Software (including any notices of Third
Party Software (as defined below); or (d) copy the Software onto any public or distributed
network or use the Software to operate in or as a time-sharing, outsourcing, service bureau,
application service provider, or managed service provider environment. Notwithstanding Section
5(d), if you provide hosting or cloud computing services to your customers, you are entitled to
use and include the Software in your IT infrastructure on which you provide your services. It is
hereby clarified that the prohibitions on modifying, or creating derivative works based on, any
Software provided by Radware, apply whether the Software is provided in a machine or in a
human readable form. Human readable Software to which this prohibition applies includes
(without limitation) “Radware AppShape++ Script Files” that contain “Special License Terms”. It
is acknowledged that examples provided in a human readable form may be modified by a user.
6. Intellectual Property Rights. You acknowledge and agree that this License Agreement does
not convey to you any interest in the Software except for the limited right to use the Software,
and that all right, title, and interest in and to the Software, including any and all associated
intellectual property rights, are and shall remain with Radware or its third party licensors. You
further acknowledge and agree that the Software is a proprietary product of Radware and/or its
licensors and is protected under applicable copyright law.
7. No Warranty. The Software, and any and all accompanying software, files, libraries, data and
materials, are distributed and provided “AS IS” by Radware or by its third party licensors (as
applicable) and with no warranty of any kind, whether express or implied, including, without
limitation, any non-infringement warranty or warranty of merchantability or fitness for a
particular purpose. Neither Radware nor any of its affiliates or licensors warrants, guarantees, or
makes any representation regarding the title in the Software, the use of, or the results of the
use of the Software. Neither Radware nor any of its affiliates or licensors warrants that the
operation of the Software will be uninterrupted or error-free, or that the use of any passwords,
license keys and/or encryption features will be effective in preventing the unintentional
disclosure of information contained in any file. You acknowledge that good data processing
procedure dictates that any program, including the Software, must be thoroughly tested with
non-critical data before there is any reliance on it, and you hereby assume the entire risk of all
use of the copies of the Software covered by this License. Radware does not make any
representation or warranty, nor does Radware assume any responsibility or liability or provide
any license or technical maintenance and support for any operating systems, databases,
migration tools or any other software component provided by a third party supplier and with
which the Software is meant to interoperate.
This disclaimer of warranty constitutes an essential and material part of this License.
In the event that, notwithstanding the disclaimer of warranty above, Radware is held liable
under any warranty provision, Radware shall be released from all such obligations in the event
that the Software shall have been subject to misuse, neglect, accident or improper installation,
or if repairs or modifications were made by persons other than by Radware's authorized service
personnel.
8. Limitation of Liability. Except to the extent expressly prohibited by applicable statutes, in no
event shall Radware, or its principals, shareholders, officers, employees, affiliates, licensors,
contractors, subsidiaries, or parent organizations (together, the “Radware Parties”), be liable for
any direct, indirect, incidental, consequential, special, or punitive damages whatsoever relating
to the use of, or the inability to use, the Software, or to your relationship with, Radware or any
of the Radware Parties (including, without limitation, loss or disclosure of data or information,
and/or loss of profit, revenue, business opportunity or business advantage, and/or business
interruption), whether based upon a claim or action of contract, warranty, negligence, strict
liability, contribution, indemnity, or any other legal theory or cause of action, even if advised of
the possibility of such damages. If any Radware Party is found to be liable to You or to any third-
party under any applicable law despite the explicit disclaimers and limitations under these
terms, then any liability of such Radware Party, will be limited exclusively to refund of any
license or registration or subscription fees paid by you to Radware.
9. Third Party Software. The Software includes software portions developed and owned by third
parties (the “Third Party Software”). Third Party Software shall be deemed part of the Software
for all intents and purposes of this License Agreement; provided, however, that in the event that
a Third Party Software is a software for which the source code is made available under an open
source software license agreement, then, to the extent there is any discrepancy or inconsistency
between the terms of this License Agreement and the terms of any such open source license
agreement (including, for example, license rights in the open source license agreement that are
broader than the license rights set forth in Section 1 above and/or no limitation in the open
source license agreement on the actions set forth in Section 5 above), the terms of any such
open source license agreement will govern and prevail. The terms of open source license
agreements and copyright notices under which Third Party Software is being licensed to
Radware or a link thereto, are included with the Software documentation or in the header or
readme files of the Software. Third Party licensors and suppliers retain all right, title and interest
in and to the Third Party Software and all copies thereof, including all copyright and other
intellectual property associated therewith. In addition to the use limitations applicable to Third
Party Software pursuant to Section 5 above, you agree and undertake not to use the Third Party
Software as a general SQL server, as a stand-alone application or with applications other than
the Software under this License Agreement.
10. Term and Termination. This License Agreement is effective upon the first to occur of your
opening the package of the Product, purchasing, downloading, installing, copying or using the
Software or any portion thereof, and shall continue until terminated. However, sections 4-13
shall survive any termination of this License Agreement. The License under this License
Agreement is not transferable and will terminate upon transfer of the Software. If the Software
is licensed on subscription basis, this Agreement will automatically terminate upon the
termination of your subscription period if it is not extended.
11. Export. The Software or any part thereof may be subject to export or import controls under the
laws and regulations of the United States and/or Israel. You agree to comply with such laws and
regulations, and, agree not to knowingly export, re-export, import or re-import, or transfer
products without first obtaining all required Government authorizations or licenses therefor.
12. Governing Law. This License Agreement shall be construed and governed in accordance with
the laws of the State of Israel.
13. Miscellaneous. If a judicial determination is made that any of the provisions contained in this
License Agreement is unreasonable, illegal or otherwise unenforceable, such provision or
provisions shall be rendered void or invalid only to the extent that such judicial determination
finds such provisions to be unreasonable, illegal or otherwise unenforceable, and the remainder
of this License Agreement shall remain operative and in full force and effect. In any event a
party breaches or threatens to commit a breach of this License Agreement, the other party will,
in addition to any other remedies available to, be entitled to injunction relief. This License
Agreement constitutes the entire agreement between the parties hereto and supersedes all prior
agreements between the parties hereto with respect to the subject matter hereof. The failure of
any party hereto to require the performance of any provisions of this License Agreement shall in
no manner affect the right to enforce the same. No waiver by any party hereto of any provisions
or of any breach of any provisions of this License Agreement shall be deemed or construed
either as a further or continuing waiver of any such provisions or breach waiver or as a waiver of
any other provision or breach of any other provision of this License Agreement.
IF YOU DO NOT AGREE WITH THE TERMS OF THIS LICENSE YOU MUST REMOVE THE
SOFTWARE FROM ANY DEVICE OWNED BY YOU AND IMMIDIATELY CEASE USING THE
SOFTWARE.
COPYRIGHT © 2013, Radware Ltd. All Rights Reserved.