WEB UI Application Guide
WEB UI 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 Radwares 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. 2016. 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 :
Les applications AppShape++ Script Files fournies par Radware Ltd. sont soumises aux termes de la
Licence Spciale (Special License Terms) incluse dans chaque fichier lectronique AppShape++
Script Files mais aussi au Contrat de Licence dUtilisateur Final de Radware qui peut tre modifi de
temps en temps et dont une copie est disponible la fin du prsent document ou ladresse
suivante: http://www.radware.com/Resources/eula.html.
Nous attirons votre attention sur le fait que si vous crez vos propres fichiers de commande (fichiers
script) en utilisant lapplication AppShape++ Script Files fournie par Radware, ces fichiers
script ne sont pas contrls par Radware et Radware ne pourra en aucun cas tre tenue
responsable des dysfonctionnements rsultant des fichiers script ainsi crs.
Copyright Radware Ltd. 2016. Tous droits rservs.
Le copyright ainsi que tout autre droit li la proprit intellectuelle et aux secrets industriels
contenus dans ce guide sont la proprit de Radware Ltd.
Ce guide dinformations est fourni nos clients dans le cadre de linstallation et de lusage des
produits de Radware dcrits dans ce document et ne pourra tre utilis dans un but autre que celui
pour lequel il a t conu.
Les informations rpertories dans ce document restent la proprit de Radware et doivent tre
conserves de manire confidentielle.
Il est strictement interdit de copier, reproduire ou divulguer des informations contenues dans ce
manuel sans avoir obtenu le consentement pralable crit de Radware.
Wichtige Anmerkung
Dieses Handbuch wird vorbehaltlich folgender Bedingungen und Einschrnkungen ausgeliefert:
Die von Radware Ltd bereitgestellten AppShape++ Scriptdateien unterliegen den in jeder
elektronischen AppShape++ Scriptdatei enthalten besonderen Lizenzbedingungen sowie Radwares
Endbenutzer-Lizenzvertrag (von welchem eine Kopie in der jeweils geltenden Fassung am Ende
dieses Dokuments oder unter http://www.radware.com/Resources/eula.html erhltlich 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 fr Funktionsfehler bernimmt, welche von diesen selbsterstellten
Skripten verursacht werden.
Copyright Radware Ltd. 2016. Alle Rechte vorbehalten.
Das Urheberrecht und alle anderen in diesem Handbuch enthaltenen Eigentumsrechte und
Geschftsgeheimnisse sind Eigentum von Radware Ltd.
Dieses Handbuch wird Kunden von Radware mit dem ausschlielichen Zweck ausgehndigt,
Informationen zu Montage und Benutzung der in diesem Dokument beschriebene Produkte von
Radware bereitzustellen. Es darf fr keinen anderen Zweck verwendet werden.
Die in diesem Handbuch enthaltenen Informationen sind Eigentum von Radware und mssen streng
vertraulich behandelt werden.
Es ist streng verboten, dieses Handbuch oder Teile daraus ohne vorherige schriftliche Zustimmung
von Radware zu kopieren, vervielfltigen, reproduzieren oder offen zu legen.
Copyright Notices
The following copyright notices are presented in English, French, and German.
Copyright Notices
The programs included in this product are subject to a restricted use license and can only be used in
conjunction with this application.
The OpenSSL toolkit stays under a dual license, i.e. both the conditions of the OpenSSL License and
the original SSLeay license apply to the toolkit. See below for the actual license texts. Actually both
licenses are BSD-style Open Source licenses. In case of any license issues related to OpenSSL,
please contact [email protected].
OpenSSL License
Copyright (c) 1998-2011 The OpenSSL Project. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted
provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and
the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions
and the following disclaimer in the documentation and/or other materials provided with the
distribution.
3. All advertising materials mentioning features or use of this software must display the following
acknowledgement:
This product includes software developed by the OpenSSL Project for use in the OpenSSL
Toolkit. (http://www.openssl.org/)
4. The names OpenSSL Toolkit and OpenSSL Project must not be used to endorse or promote
products derived from this software without prior written permission. For written permission,
please contact [email protected].
5. Products derived from this software may not be called OpenSSL nor may OpenSSL appear in
their names without prior written permission of the OpenSSL Project.
6. Redistributions of any form whatsoever must retain the following acknowledgment:
This product includes software developed by the OpenSSL Project for use in the OpenSSL
Toolkit (http://www.openssl.org/)
THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT AS IS'' AND ANY EXPRESSED OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT
SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
This product includes cryptographic software written by Eric Young ([email protected]). This
product includes software written by Tim Hudson ([email protected]).
Original SSLeay License
Copyright (C) 1995-1998 Eric Young ([email protected])
All rights reserved.
This package is an SSL implementation written by Eric Young ([email protected]).
The implementation was written so as to conform with Netscapes SSL.
This library is free for commercial and non-commercial use as long as the following conditions are
aheared to. The following conditions apply to all code found in this distribution, be it the RC4, RSA,
lhash, DES, etc., code; not just the SSL code. The SSL documentation included with this distribution
is covered by the same copyright terms except that the holder is Tim Hudson ([email protected]).
Copyright remains Eric Young's, and as such any Copyright notices in the code are not to be
removed.
If this package is used in a product, Eric Young should be given attribution as the author of the parts
of the library used.
This can be in the form of a textual message at program startup or in documentation (online or
textual) provided with the package.
Redistribution and use in source and binary forms, with or without modification, are permitted
provided that the following conditions are met:
1. Redistributions of source code must retain the copyright notice, this list of conditions and the
following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions
and the following disclaimer in the documentation and/or other materials provided with the
distribution.
3. All advertising materials mentioning features or use of this software must display the following
acknowledgement:
"This product includes cryptographic software written by Eric Young ([email protected])"
The word 'cryptographic' can be left out if the rouines from the library being used are not
cryptographic related :-).
4. If you include any Windows specific code (or a derivative thereof) from the apps directory
(application code) you must include an acknowledgment:
"This product includes software written by Tim Hudson ([email protected])"
THIS SOFTWARE IS PROVIDED BY ERIC YOUNG AS IS' AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT
SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
Redistribution and use in source and binary forms, with or without modification, are permitted
provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and
the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions
and the following disclaimer in the documentation and/or other materials provided with the
distribution.
This product contains work derived from the RSA Data Security, Inc. MD5 Message-Digest
Algorithm. RSA Data Security, Inc. makes no representations concerning either the merchantability
of the MD5 Message - Digest Algorithm or the suitability of the MD5 Message - Digest Algorithm for
any particular purpose. It is provided as is without express or implied warranty of any kind.
Copyrightvermerke
Die in diesem Produkt enthalten Programme unterliegen einer eingeschrnkten Nutzungslizenz und
knnen nur in Verbindung mit dieser Anwendung benutzt werden.
Dieses Produkt enthlt einen vom OpenSSL-Projekt entwickelten Code
Dieses Produkt enthlt vom OpenSSL-Projekt entwickelte Software. Zur Verwendung im OpenSSL
Toolkit (http://www.openssl.org/).
Copyright 1998-2005 The OpenSSL Project. Alle Rechte vorbehalten. Dieses Produkt enthlt die
Rijndael cipher.
Die Rijndael-Implementierung von Vincent Rijndael, Anton Bosselaers und Paulo Barreto ist
ffentlich zugnglich und wird unter folgender Lizenz vertrieben:
@version 3.0 (December 2000)
Optimierter ANSI C Code fr den Rijndael cipher (jetzt AES)
@author Vincent Rijmen <[email protected]>
@author Antoon Bosselaers <[email protected]>
@author Paulo Barreto <[email protected]>
Der OnDemand Switch verwendet mglicherweise Software, die im Rahmen der DNU Allgemeine
ffentliche Lizenzvereinbarung Version 2 (GPL v.2) lizensiert sind, einschlielich LinuxBios und Filo
Open Source-Projekte. Der Quellcode von LinuxBios und Filo ist bei Radware auf Anfrage erhltlich.
Eine Kopie dieser Lizenz kann eingesehen werden unter http://www.gnu.org/licenses/old-licenses/
gpl-2.0.html.
Dieser Code wird hiermit allgemein zugnglich gemacht.
Standard Warranty
The following standard warranty is presented in English, French, and German.
Standard Warranty
Radware offers a limited warranty for all its products (Products). Radware hardware products are
warranted against defects in material and workmanship for a period of one year from date of
shipment. Radware software carries a standard warranty that provides bug fixes for up to 90 days
after date of purchase. Should a Product unit fail anytime during the said period(s), Radware will, at
its discretion, repair or replace the Product.
For hardware warranty service or repair, the product must be returned to a service facility
designated by Radware. Customer shall pay the shipping charges to Radware and Radware shall pay
the shipping charges in returning the product to the customer. Please see specific details outlined in
the Standard Warranty section of the customers purchase order.
Radware shall be released from all obligations under its Standard Warranty in the event that the
Product and/or the defective component has been subjected to misuse, neglect, accident or
improper installation, or if repairs or modifications were made by persons other than Radware
authorized service personnel, unless such repairs by others were made with the written consent of
Radware.
EXCEPT AS SET FORTH ABOVE, ALL RADWARE PRODUCTS (HARDWARE AND SOFTWARE) ARE
PROVIDED BY AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED.
Garantie standard
Radware octroie une garantie limite pour lensemble de ses produits (Produits). Le matriel
informatique (hardware) Radware est garanti contre tout dfaut matriel et de fabrication pendant
une dure dun an compter de la date dexpdition. Les logiciels (software) Radware sont fournis
avec une garantie standard consistant en la fourniture de correctifs des dysfonctionnements du
logiciels (bugs) pendant une dure maximum de 90 jours compter de la date dachat. Dans
lhypothse o un Produit prsenterait un dfaut pendant ladite (lesdites) priode(s), Radware
procdera, sa discrtion, la rparation ou lchange du Produit.
Sagissant de la garantie dchange ou de rparation du matriel informatique, le Produit doit tre
retourn chez un rparateur dsign par Radware. Le Client aura sa charge les frais denvoi du
Produit Radware et Radware supportera les frais de retour du Produit au client. Veuillez consulter
les conditions spcifiques dcrites dans la partie Garantie Standard du bon de commande client.
Radware est libre de toutes obligations lies la Garantie Standard dans lhypothse o le Produit
et/ou le composant dfectueux a fait lobjet dun mauvais usage, dune ngligence, dun accident ou
dune installation non conforme, ou si les rparations ou les modifications quil a subi ont t
effectues par dautres personnes que le personnel de maintenance autoris par Radware, sauf si
Radware a donn son consentement crit ce que de telles rparations soient effectues par ces
personnes.
SAUF DANS LES CAS PREVUS CI-DESSUS, LENSEMBLE DES PRODUITS RADWARE (MATERIELS ET
LOGICIELS) SONT FOURNIS TELS QUELS ET TOUTES GARANTIES EXPRESSES OU IMPLICITES
SONT EXCLUES, EN CE COMPRIS, MAIS SANS SY RESTREINDRE, LES GARANTIES IMPLICITES DE
QUALITE MARCHANDE ET DADQUATION UNE UTILISATION PARTICULIRE.
Standard Garantie
Radware bietet eine begrenzte Garantie fr alle seine Produkte (Produkte) an. Hardware Produkte
von Radware haben eine Garantie gegen Material- und Verarbeitungsfehler fr einen Zeitraum von
einem Jahr ab Lieferdatum. Radware Software verfgt ber eine Standard Garantie zur
Fehlerbereinigung fr einen Zeitraum von bis zu 90 Tagen nach Erwerbsdatum. Sollte ein Produkt
innerhalb des angegebenen Garantiezeitraumes einen Defekt aufweisen, wird Radware das Produkt
nach eigenem Ermessen entweder reparieren oder ersetzen.
Fr den Hardware Garantieservice oder die Reparatur ist das Produkt an eine von Radware
bezeichnete Serviceeinrichtung zurckzugeben. Der Kunde hat die Versandkosten fr den Transport
des Produktes zu Radware zu tragen, Radware bernimmt die Kosten der Rckversendung des
Produktes an den Kunden. Genauere Angaben entnehmen Sie bitte dem Abschnitt zur Standard
Garantie im Bestellformular fr Kunden.
Radware ist von smtlichen Verpflichtungen unter seiner Standard Garantie befreit, sofern das
Produkt oder der fehlerhafte Teil zweckentfremdet genutzt, in der Pflege vernachlssigt, einem
Unfall ausgesetzt oder unsachgem installiert wurde oder sofern Reparaturen oder Modifikationen
von anderen Personen als durch Radware autorisierten Kundendienstmitarbeitern vorgenommen
wurden, es sei denn, diese Reparatur durch besagte andere Personen wurden mit schriftlicher
Genehmigung seitens Radware durchgefhrt.
MIT AUSNAHME DES OBEN DARGESTELLTEN, SIND ALLE RADWARE PRODUKTE (HARDWARE UND
SOFTWARE) GELIEFERT WIE GESEHEN UND JEGLICHE AUSDRCKLICHEN ODER
STILLSCHWEIGENDEN GARANTIEN, EINSCHLIESSLICH ABER NICHT BEGRENZT AUF
STILLSCHWEIGENDE GEWHRLEISTUNG DER MARKTFHIGKEIT UND EIGNUNG FR EINEN
BESTIMMTEN ZWECK AUSGESCHLOSSEN.
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.
SERVICING
Do not perform any servicing other than that contained in the operating instructions unless you are
qualified to do so. There are no serviceable parts inside the unit.
HIGH VOLTAGE
Any adjustment, maintenance, and repair of the opened instrument under voltage must be avoided
as much as possible and, when inevitable, must be carried out only by a skilled person who is aware
of the hazard involved.
Capacitors inside the instrument may still be charged even if the instrument has been disconnected
from its source of supply.
GROUNDING
Before connecting this device to the power line, the protective earth terminal screws of this device
must be connected to the protective earth in the building installation.
LASER
This equipment is a Class 1 Laser Product in accordance with IEC60825 - 1: 1993 + A1:1997 +
A2:2001 Standard.
FUSES
Make sure that only fuses with the required rated current and of the specified type are used for
replacement. The use of repaired fuses and the short-circuiting of fuse holders must be avoided.
Whenever it is likely that the protection offered by fuses has been impaired, the instrument must be
made inoperative and be secured against any unintended operation.
LINE VOLTAGE
Before connecting this instrument to the power line, make sure the voltage of the power source
matches the requirements of the instrument. Refer to the Specifications for information about the
correct power rating for the device.
48V DC-powered platforms have an input tolerance of 36-72V DC.
SPECIFICATION CHANGES
Specifications are subject to change without notice.
Note: This equipment has been tested and found to comply with the limits for a Class A digital
device pursuant to Part 15B of the FCC Rules and EN55022 Class A, EN 55024; EN 61000-3-2; EN
61000-3-3; IEC 61000 4-2 to 4-6, IEC 61000 4-8 and IEC 61000-4-11For CE MARK Compliance.
These limits are designed to provide reasonable protection against harmful interference when the
equipment is operated in a commercial environment. This equipment generates, uses and can
radiate radio frequency energy and, if not installed and used in accordance with the instruction
manual, may cause harmful interference to radio communications. Operation of this equipment in a
residential area is likely to cause harmful interference in which case the user is required to correct
the interference at his own expense.
SPECIAL NOTICE FOR NORTH AMERICAN USERS
For North American power connection, select a power supply cord that is UL Listed and CSA Certified
3 - conductor, [18 AWG], terminated in a molded on plug cap rated 125 V, [10 A], with a minimum
length of 1.5m [six feet] but no longer than 4.5m...For European connection, select a power supply
cord that is internationally harmonized and marked <HAR>, 3 - conductor, 0,75 mm2 minimum
mm2 wire, rated 300 V, with a PVC insulated jacket. The cord must have a molded on plug cap rated
250 V, 3 A.
RESTRICT AREA ACCESS
The DC powered equipment should only be installed in a Restricted Access Area.
INSTALLATION CODES
This device must be installed according to country national electrical codes. For North America,
equipment must be installed in accordance with the US National Electrical Code, Articles 110 - 16,
110 -17, and 110 -18 and the Canadian Electrical Code, Section 12.
INTERCONNECTION OF UNITS
Cables for connecting to the unit RS232 and Ethernet Interfaces must be UL certified type DP-1 or
DP-2. (Note- when residing in non LPS circuit)
OVERCURRENT PROTECTION
A readily accessible listed branch-circuit over current protective device rated 15 A must be
incorporated in the building wiring for each power input.
REPLACEABLE BATTERIES
If equipment is provided with a replaceable battery, and is replaced by an incorrect battery type,
then an explosion may occur. This is the case for some Lithium batteries and the following is
applicable:
If the battery is placed in an Operator Access Area, there is a marking close to the battery or
a statement in both the operating and service instructions.
If the battery is placed elsewhere in the equipment, there is a marking close to the battery or a
statement in the service instructions.
CAUTION
Risk of electric shock and energy hazard. Disconnecting one power supply disconnects only one
power supply module. To isolate the unit completely, disconnect all power supplies.
Instructions de scurit
AVERTISSEMENT
Un dispositif de dconnexion facilement accessible sera incorpor au cblage du btiment.
En raison des risques de chocs lectriques et des dangers nergtiques, mcaniques et dincendie,
chaque procdure impliquant louverture des panneaux ou le remplacement de composants sera
excute par du personnel qualifi.
Pour rduire les risques dincendie et de chocs lectriques, dconnectez le dispositif du bloc
dalimentation avant de retirer le couvercle ou les panneaux.
La figure suivante montre ltiquette davertissement appose sur les plateformes Radware dotes
de plus dune source dalimentation lectrique.
Figure 4: Avertissement de scurit pour les systmes dotes de deux sources dalimentation
lectrique (en chinois)
Traduction de la Avertissement de scurit pour les systmes dotes de deux sources dalimentation
lectrique (en chinois):
Cette unit est dote de plus dune source dalimentation lectrique. Dconnectez toutes les sources
dalimentation lectrique avant dentretenir lappareil ceci pour viter tout choc lectrique.
ENTRETIEN
Neffectuez aucun entretien autre que ceux rpertoris dans le manuel dinstructions, moins dtre
qualifi en la matire. Aucune pice lintrieur de lunit ne peut tre remplace ou rpare.
HAUTE TENSION
Tout rglage, opration dentretien et rparation de linstrument ouvert sous tension doit tre vit.
Si cela savre indispensable, confiez cette opration une personne qualifie et consciente des
dangers impliqus.
Les condensateurs au sein de lunit risquent dtre chargs mme si lunit a t dconnecte de la
source dalimentation lectrique.
MISE A LA TERRE
Avant de connecter ce dispositif la ligne lectrique, les vis de protection de la borne de terre de
cette unit doivent tre relies au systme de mise la terre du btiment.
LASER
Cet quipement est un produit laser de classe 1, conforme la norme IEC60825 - 1: 1993 + A1:
1997 + A2: 2001.
FUSIBLES
Assurez-vous que, seuls les fusibles courant nominal requis et de type spcifi sont utiliss en
remplacement. Lusage de fusibles rpars et le court-circuitage des porte-fusibles doivent tre
vits. Lorsquil est pratiquement certain que la protection offerte par les fusibles a t dtriore,
linstrument doit tre dsactiv et scuris contre toute opration involontaire.
TENSION DE LIGNE
Avant de connecter cet instrument la ligne lectrique, vrifiez que la tension de la source
dalimentation correspond aux exigences de linstrument. Consultez les spcifications propres
lalimentation nominale correcte du dispositif.
Les plateformes alimentes en 48 CC ont une tolrance dentre comprise entre 36 et 72 V CC.
MODIFICATIONS DES SPCIFICATIONS
Les spcifications sont sujettes changement sans notice pralable.
Remarque: Cet quipement a t test et dclar conforme aux limites dfinies pour un appareil
numrique de classe A, conformment au paragraphe 15B de la rglementation FCC et EN55022
Classe A, EN 55024, EN 61000-3-2; EN 61000-3-3; IEC 61000 4-2 to 4-6, IEC 61000 4-8, et IEC
61000-4-11, pour la marque de conformit de la CE. Ces limites sont fixes pour fournir une
protection raisonnable contre les interfrences nuisibles, lorsque lquipement est utilis dans un
environnement commercial. Cet quipement gnre, utilise et peut mettre des frquences radio et,
sil nest pas install et utilis conformment au manuel dinstructions, peut entraner des
interfrences nuisibles aux communications radio. Le fonctionnement de cet quipement dans une
zone rsidentielle est susceptible de provoquer des interfrences nuisibles, auquel cas lutilisateur
devra corriger le problme ses propres frais.
NOTICE SPCIALE POUR LES UTILISATEURS NORD-AMRICAINS
Pour un raccordement lectrique en Amrique du Nord, slectionnez un cordon dalimentation
homologu UL et certifi CSA 3 - conducteur, [18 AWG], muni dune prise moule son extrmit,
de 125 V, [10 A], dune longueur minimale de 1,5 m [six pieds] et maximale de 4,5m...Pour la
connexion europenne, choisissez un cordon dalimentation mondialement homologu et marqu
<HAR>, 3 - conducteur, cble de 0,75 mm2 minimum, de 300 V, avec une gaine en PVC isole. La
prise lextrmit du cordon, sera dote dun sceau moul indiquant: 250 V, 3 A.
ZONE A ACCS RESTREINT
Lquipement aliment en CC ne pourra tre install que dans une zone accs restreint.
CODES DINSTALLATION
Ce dispositif doit tre install en conformit avec les codes lectriques nationaux. En Amrique du
Nord, lquipement sera install en conformit avec le code lectrique national amricain, articles
110-16, 110 -17, et 110 -18 et le code lectrique canadien, Section 12.
INTERCONNEXION DES UNTES
Les cbles de connexion lunit RS232 et aux interfaces Ethernet seront certifis UL, type DP-1 ou
DP-2. (Remarque- sils ne rsident pas dans un circuit LPS).
PROTECTION CONTRE LES SURCHARGES
Un circuit de drivation, facilement accessible, sur le dispositif de protection du courant de 15 A doit
tre intgr au cblage du btiment pour chaque puissance consomme.
BATTERIES REMPLAABLES
Si lquipement est fourni avec une batterie, et quelle est remplace par un type de batterie
incorrect, elle est susceptible dexploser. Cest le cas pour certaines batteries au lithium, les
lments suivants sont donc applicables:
Si la batterie est place dans une zone daccs oprateur, une marque est indique sur la
batterie ou une remarque est insre, aussi bien dans les instructions dexploitation que
dentretien.
Si la batterie est place ailleurs dans lquipement, une marque est indique sur la batterie ou
une remarque est insre dans les instructions dentretien.
ATTENTION
Risque de choc et de danger lectriques. Le dbranchement dune seule alimentation stabilise ne
dbranche quun module Alimentation Stabilise. Pour Isoler compltement le module en cause, il
faut dbrancher toutes les alimentations stabilises.
Attention: Pour Rduire Les Risques dlectrocution et dIncendie
1. Toutes les oprations dentretien seront effectues UNIQUEMENT par du personnel dentretien
qualifi. Aucun composant ne peut tre entretenu ou remplace par lutilisateur.
2. NE PAS connecter, mettre sous tension ou essayer dutiliser une unit visiblement dfectueuse.
3. Assurez-vous que les ouvertures de ventilation du chssis NE SONT PAS OBSTRUES.
4. Remplacez un fusible qui a saut SEULEMENT par un fusible du mme type et de mme
capacit, comme indiqu sur ltiquette de scurit proche de lentre de lalimentation qui
contient le fusible.
5. NE PAS UTILISER lquipement dans des locaux dont la temprature maximale dpasse 40
degrs Centigrades.
6. Assurez vous que le cordon dalimentation a t dconnect AVANT dessayer de lenlever et/ou
vrifier le fusible de lalimentation gnrale.
Sicherheitsanweisungen
VORSICHT
Die Elektroinstallation des Gebudes muss ein unverzglich zugngliches Stromunterbrechungsgert
integrieren.
Aufgrund des Stromschlagrisikos und der Energie-, mechanische und Feuergefahr drfen Vorgnge,
in deren Verlauf Abdeckungen entfernt oder Elemente ausgetauscht werden, ausschlielich von
qualifiziertem Servicepersonal durchgefhrt werden.
Zur Reduzierung der Feuer- und Stromschlaggefahr muss das Gert vor der Entfernung der
Abdeckung oder der Paneele von der Stromversorgung getrennt werden.
Folgende Abbildung zeigt das VORSICHT-Etikett, das auf die Radware-Plattformen mit
Doppelspeisung angebracht ist.
Electromagnetic-Interference Statements
The following statements are presented in English, French, and German.
Electromagnetic-Interference Statements
SPECIFICATION CHANGES
Specifications are subject to change without notice.
Note: This equipment has been tested and found to comply with the limits for a Class A digital
device pursuant to Part 15B of the FCC Rules and EN55022 Class A, EN 55024; EN 61000-3-2; EN
61000-3-3; IEC 61000 4-2 to 4-6, IEC 61000 4-8 and IEC 61000-4-11For CE MARK Compliance.
These limits are designed to provide reasonable protection against harmful interference when the
equipment is operated in a commercial environment. This equipment generates, uses and can
radiate radio frequency energy and, if not installed and used in accordance with the instruction
manual, may cause harmful interference to radio communications. Operation of this equipment in a
residential area is likely to cause harmful interference in which case the user is required to correct
the interference at his own expense.
VCCI ELECTROMAGNETIC-INTERFERENCE STATEMENTS
KCC KOREA
Figure 12: KCCCertificat de la commission des communications de Core pour les equipements de
radiodiffusion et communication.
Figure 13: Dclaration pour lquipement de classe A certifi KCC en langue corenne
Hinweis: Dieses Gert wurde geprft und entspricht den Beschrnkungen von digitalen Gerten der
Klasse 1 gem Teil 15B FCC-Vorschriften und EN55022 Klasse A, EN55024; EN 61000-3-2; EN; IEC
61000 4-2 to 4-6, IEC 61000 4-8 und IEC 61000-4- 11 fr Konformitt mit der CE-Bezeichnung.
Diese Beschrnkungen dienen dem angemessenen Schutz vor schdlichen Interferenzen bei Betrieb
des Gertes in kommerziellem Umfeld. Dieses Gert erzeugt, verwendet und strahlt
elektromagnetische Hochfrequenzstrahlung aus. Wird es nicht entsprechend den Anweisungen im
Handbuch montiert und benutzt, knnte es mit dem Funkverkehr interferieren und ihn
beeintrchtigen. Der Betrieb dieses Gertes in Wohnbereichen wird hchstwahrscheinlich zu
schdlichen Interferenzen fhren. In einem solchen Fall wre der Benutzer verpflichtet, diese
Interferenzen auf eigene Kosten zu korrigieren.
ERKLRUNG DER VCCI ZU ELEKTROMAGNETISCHER INTERFERENZ
BSMI
2000m
DD
2000m
DD
DD.1
2000m 2000m
DD.2
Document Conventions
The following describes the conventions and symbols that this guide uses:
Example
Possible damage to Endommagement Mgliche Schden an
equipment, software, or possible de lquipement, Gert, Software oder
Caution: data des donnes ou du Daten
logiciel
Additional information Informations Zustzliche
complmentaires Informationen
Note:
A statement and Rfrences et Eine Erklrung 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 loprateur Bedieners
Warning:
Chapter 1 Preface................................................................................................. 41
Who Should Use This Guide ....................................................................................... 41
What You Will Find in This Guide ................................................................................ 41
Related Documentation ............................................................................................... 42
WAN Link Load Balancing describes how to balance user session traffic among a pool of available
WAN Links.
Firewall Load Balancing describes how to combine features to provide a scalable solution for load
balancing multiple firewalls.
Security describes the protection features that can be used to prevent a wide range of network
attacks.
Bandwidth Management describes how to allocate specific portions of the available bandwidth
for specific users or applications.
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.
Glossary defines the terminology used throughout the book.
Related Documentation
The Alteon documentation set includes the following publications in PDF format:
Alteon Release Notes
Alteon Maintenance and Installation Guide
Alteon VA Maintenance and Installation Guide
Alteon Web Based Management Application Guide
Alteon Command Line Interface Application Guide
Alteon Command Line Interface Reference Guide
Alteon Web Based Management Quick Start
Alteon Troubleshooting Guide
Alteon AppShape++ Reference Guide
Alteon NG Deployment Guide
FastView for Alteon NG User Guide
AppWall for Alteon NG User Guide
LinkProof for Alteon NG User Guide
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 SNMPv3 to query the MIBs, mainly for security purposes.
Default Configuration
Alteon has the following default users which have access to all the MIBs supported by Alteon:
User Configuration
Configure users to use the authentication and privacy options. Alteon supports two authentication
algorithms: MD5 and SHA.
e. In the Privacy Protocol field, select a protocol from the drop-down list, and type a
password.
f. Click Submit.
In this example, we use the following values:
2. 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.
a. Select Configuration > System > SNMP > SNMPv3 > Access.
Group Name Security Level Read View Name Write View Name Notify View Name
testgrp Authentication iso iso iso
and Privacy
To allow the user to access only certain MIBs, see View-Based Configurations, page 46.
View-Based Configurations
The following are example view-based configurations, including:
To configure an SNMP user equivalent to the user CLI access level, page 46
To configure an SNMP user equivalent to the oper CLI access level, page 47
Group Name Security Level Read View Name Write View Name Notify View Name
usrgrp No Authentication usr usr usr
4. Configure MIB views for displaying locally held information about families of subtrees.
a. Select Configuration > System > SNMP > SNMPv3 > View Trees.
d. In the Security Level field, select the minimum level of security required to gain the access
rights allowed by this row.
e. In the Read View Name field, select the MIB view of the SNMP context to which this row
authorizes read access.
f. In the Write View Name field, select the MIB view of the SNMP context to which this row
authorizes write access.
g. In the Notify View Name field, select the MIB view of the SNMP context to which this row
authorizes access for notifications.
h. Click Submit.
In this example, we use the following values:
Group Name Security Level Read View Name Write View Name Notify View Name
slbopergrp No Authentication slboper slboper slboper
4. Configure MIB views for displaying locally held information about families of subtrees.
a. Select Configuration > System > SNMP > SNMPv3 > View Trees.
c. From the Security Model drop-down list, select the security model to be used when
generating SNMP messages using this entry.
d. In the USM User Name field, type the name of the user that you want to link to an access
group.
e. In the Group Name field, type the name of the access group to which you want to link the
user.
f. Click Submit.
In this example, we use the following values:
Name Tag
v1trap v1trap
c. In the User Name field, type the User-based Security Model (USM) name for the user.
Maximum 32 characters.
In this example, we use v2trap.
d. Click Submit.
2. Configure an access group for the user.
a. Select Configuration > System > SNMP > SNMPv3 > Access.
Name Tag
v2trap v2trap
d. In the Community Name field, type the community string for which a row in this table
represents a configuration.
Maximum 32 characters.
e. In the Security Name field, type the string representing the corresponding value of the
Community Name field in a security model independent format.
Maximum 32 characters.
f. Click Submit.
In this example, we use the following values:
Note: It is not necessary to configure the community table for SNMPv3 traps because the
community string is not used by SNMPv3.
The following example illustrates how to configure an SNMPv3 user v3trap with authentication only:
d. In the Authentication Protocol field, select a protocol from the drop-down list, and type a
password.
e. In the Privacy Protocol field, select a protocol from the drop-down list, and type a
password.
f. Click Submit.
In this example, we use the following values:
f. From the Target Parameters Name drop-down list, select the entry that contains the
SNMP parameters to be used when generating messages sent to the specified transport
address.
g. Click Submit.
In this example, we use the following values:
Name Tag
v3trap v3trap
/cfg/sys/access/https/https ena
To change the HTTPS Web server port number from the default port 443
> In the Alteon CLI, type /cfg/sys/access/https/port.
/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 WBM access to the client,
the WBM can be used.
REST API
Representational state transfer (REST) is a way to create, read, update, or delete information on a
server using simple HTTP calls.
The Alteon REST API provides complete access to all of the functionality of Alteon using HTTP
requests and responses that can be implemented using almost any programming language and
runtime environment. The API acts as an interface for managing an Alteon platform using GET, POST
(add), PUT (edit), or DELETE operations on any part of the Alteon system configuration.
Alteon scalar and table entities are identified in the REST API using a shortened name based on the
Alteon MIB name. For details on the Alteon REST API, including the exact names to be used in the
requests, see the Alteon REST API Reference Guide.
Note: If Alteon maintains multiple management sessions via Telnet, SSH, and/or HTTP, do not
perform any configuration or update operations when an Apply operation is in progress on one of the
management sessions.
The management port does not participate in the switching and routing protocols that run on the
data ports, but it can be used to perform management functions such as:
Accessing the NTP server
Sending out SNMP traps
Sending out syslog messages
Accessing the RADIUS server
Accessing the TACACS+ server
Accessing the DNS server
Performing TFTP or FTP functions (ptimg, gtimg, ptcfg, gtcfg, ptdmp)
Accessing the SMTP server
Running the ping, telnet, and traceroute commands
Notes
To configure MNG 1 as a management port for dedicated out-of-band management on devices
other than the Alteon Application Switch 4408 and 5208 platforms, select the Enable
Management Port option in the Port Settings tab at Configuration > System >
Management Access > Management Ports to enable the management port. For more
information, see the section on configuring management ports in the Alteon Maintenance and
Installation Guide.
To configure port 6/MNG 1 as a management port for dedicated out-of-band management on the
Alteon Application Switch 4408 and 5208 platforms, first enable the physical port with the
Global State of Management Port on Next Reset option at Configuration > System >
Management Access > Management Ports (which requires a system reset), then select the
Enable Management Port option in the Port Settings tab at Configuration > System >
Management Access > Management Ports to enable the management port. For more
information, see the section on configuring management ports in the Alteon Maintenance and
Installation Guide.
Note: There are a maximum of four concurrent Telnet sessions over the management and data
ports combined.
In this example, we use the following values:
IPv4 IP IPv4 Mask/ IPv4 Default IPv6 IP IPv6 Mask/ IPv6 Default
Address Prefix Gateway Address Prefix Gateway
10.10.10.5 255.255.255.0 10.10.10.1 2001::2213 64 2001::1111
4. Click Allow to enable a VLAN for mangement access, or Deny to disable a VLAN for
management access.
5. Click Submit.
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.
Language Configuration
This section describes how to configure and modify the display language for the Alteon Web Based
Management interface, including the following topics:
Modifying the Default Alteon Global Language, page 62
Setting the Default Language for New Local Users, page 63
Configuring Language Settings in the RADIUS Server, page 64
Configuring Language Settings in the TACACS Server, page 64
To modify the global default language for the Alteon Web Based Management interface
(standalone, VA, and vADC mode)
1. Select Configuration > System > Management Access.
2. From the Language Display drop-down list, select a new default language.
3. Click Submit.
To modify the global default language for the Alteon Web Based Management interface
(ADC-VX mode)
1. Select Configuration > vADC > vADC.
2. In the vADC table, click to add an entry. The relevant Add tab displays.
3. From the Language Display drop-down list, select a new default language.
4. Click Submit.
Note: Local users can change their own default Alteon Web Based Management interface language
by clicking in the global toolbar and selecting a language from the drop-down list.
To modify the Alteon Web Based Management interface language for a local user
(standalone, VA, and vADC mode)
1. Select Configuration > System > Users > Local Users.
2. In the Local Users table, select an entry and click , or double-click the entry you want to edit.
The relevant Edit tab displays.
3. From the Language Display drop-down list, select a new default language.
4. Click Submit.
To modify the Alteon Web Based Management interface language for a local user (ADC-
VX mode)
1. Select Configuration > vADC > vADC.
2. In the vADC table, select an entry and click , or double-click the entry you want to edit. The
relevant Edit tab displays.
3. Select the Users tab.
4. From the Language Display drop-down list, select a new default language.
5. Click Submit.
test User-Password=test
Alteon-Language = Alteon-Chinese,
Alteon-Service-Type = Alteon-User
<Authorizations>
<Authorization>
<!--This entry will only be processed in the times given below-->
<!--<Time>MTWRFSN,04:00-21:00</Time>-->
<!--This authorization section applies to the following user groups. In case
of conflicting authorization entries for the same group, the entry which
appears first in the file is used.-->
<UserGroups>
<UserGroup>AAS ADMIN 6</UserGroup>
</UserGroups>
<!--This authorization section applies to the following client groups. In
case of conflicting authorization entries for the same client group, the
entry which appears first in the file is used.-->
<!--If no client groups are specified then the settings are applied to the
specified usergroups irrespective of the clients they come from-->
<!--ClientGroups>
<ClientGroup>LOCALHOST</ClientGroup>
<ClientGroup>INTERNAL</ClientGroup>
</ClientGroups-->
<AutoExec>
<!--<Set>acl=7</Set>-->
<!-- When an exec is started, its connection access list will be 7. It will
also automatically execute this autocmd. If the cmd element is not provided
then the shell entry is used when the shell is first invoked.-->
<!--<Set>autocmd=telnet 10.1.1.1</Set>-->
<Set>priv-lvl=6</Set>
<Set>Alteon-Language=0</Set>
</AutoExec>
<UserGroup>
<Name>AAS ADMIN 6</Name>
<AuthenticationType>File</AuthenticationType>
<Users>
<User>
<Name>user1</Name>
<LoginPassword ClearText="h6" DES=""> </LoginPassword>
<EnablePassword ClearText="" DES=""></EnablePassword>
<CHAPPassword ClearText="" DES=""> </CHAPPassword>
<OutboundPassword ClearText="" DES=""> </OutboundPassword>
</User>
<User>
<Name>user2</Name>
<LoginPassword ClearText="somepassword" DES=""> </LoginPassword>
<EnablePassword ClearText="" DES=""></EnablePassword>
<CHAPPassword ClearText="" DES=""> </CHAPPassword>
<OutboundPassword ClearText="" DES=""> </OutboundPassword>
</User>
</Users>
</UserGroup>
Note: By default, until a protocol is defined there are no restrictions for a specific protocol.
When an IP packet reaches Alteon, Alteon checks the source IP address against the range of
addresses defined by the management network and mask. If the source IP address of the host or
hosts are within this range, Alteon allows the packets to attempt to log in. Any packet addressed to
an Alteon IP interface with a source IP address outside this range is discarded.
You can configure both IPv4 and IPv6 IP ranges with up to 128 management IP addresses and
mask/prefix pairs.
3. In the IPV4 Management Networks table, click to add an entry. The relevant Add tab
displays.
4. Configure an IPv4 address and subnet mask.
5. (Optional) Select the protocols that are allowed.
6. Click Submit
In this example, we use the following values:
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).
User Accounts
The user accounts listed in Table 1 - Alteon User Accounts and Access Levels, page 71 describe the
user levels
that can be defined in the RADIUS server dictionary file. For more information, see RADIUS
Attributes for User Privileges, page 72.
for defining the class of service for the End User Access Control feature. For more information,
see End User Access Control, page 78.
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.
2. In the Local Users table, select an entry and click , or double-click the entry you want to edit.
The relevant Edit tab displays.
3. Set RADIUS/TACACS Fallback to Enable.
4. Click Submit.
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.
Authorization
Authorization is the action of determining a users 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 76.
You enable and disable mapping at Configuration > System > Users > Remote Authentication
> New Privilege Level Mapping.
Table 3 - Alteon-Proprietary with Disabled Privilege Level Mapping for TACACS+, page 75 displays
TACACS+ levels with privilege level mapping disabled.
Table 4 - Alteon-Proprietary with Enabled Privilege Level Mapping for TACACS+, page 75 displays
TACACS+ levels with privilege level mapping enabled.
Accounting
Accounting is the act of recording a users 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, HTTPS)
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.
Note: Alteon does not support export/import of configuration containing keys using external SCP
client.
The Alteon implementation of SSH supports both versions 1.5 and 2.0, and supports SSH clients
version 1.5 to 2.x. The following SSH clients have been tested:
PuTTY 0.64
SecureCRT 7.3
MobaXterm tool (Personal Edition v6.6)
Linux OS - centOS 5.5 (openSSH_4.3p2), centos 7 (openSSH_6.6.1p1), fedora 21
(openSSH_6.7p1)
Note: There can be a maximum number of four simultaneous Telnet, SSH, SCP connections at one
time.
Note: SSH access can be enabled using the console port or Telnet. SSH access can be disabled only
using the serial console and not using Telnet. For vADC, SSH access can be disabled via Telnet.
To enable SSH
1. Select Configuration > System > Management Access > Management Protocols.
2. In the SSH tab, select Enable SSH.
3. Set the Version option to V2.
4. Click Submit.
SCP Services
To perform SCP commands, you need the SCP administrator password with administrator privileges
(this password must be different from the administrator password).
The following SCP commands are supported in this service:
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.
1. Select Configuration > System > Management Access > Management Protocols.
2. In the SSH tab, enable SCP Apply and Save.
3. Click Submit.
Note: There is no SNMP or WBM support for SecurID because the SecurID server, ACE, is a one-
time password authentication and requires an interactive session.
Adding a User
You can configure up to 10 users.
2. In the Local Users table, click to add an entry. The relevant Add tab displays.
3. Select Enable User.
4. In the User ID field, type an identifier for the user.
Valid values are in the range 111.
5. In the User Name field, type a name for the user of up to 8 characters.
6. From the User Role drop-down list, select a role for the user.
7. In the Current Admin Password field, type your administrator password.
8. In the New Password field, type a password for the user of up to 128 characters.
9. In the Confirm New Password field, type the user password again.
10. Click Submit.
2. In the Local Users table, select an entry and click , or double-click the entry you want to edit.
The relevant Edit tab displays.
3. From the User Role drop-down list, select a role for the user.
4. Click Submit.
2. In the Local Users table, select an entry and click , or double-click the entry you want to edit.
The relevant Edit tab displays.
3. In the Real Server table, select real servers and use the arrows to move them between the
Available and Selected lists.
4. Click Submit.
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.
2. In the Static Routes table, click to add an entry. The relevant Add tab displays.
3. Define a destination IP address, destination subnet mask, and a gateway IP address.
Caution: Do not configure a deny route that covers the destination/mask pair of an existing IP
interfaces 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.
What is ADC-VX?
ADC-VX is a specialized Application Delivery Controller (ADC) hypervisor that runs multiple virtual
ADC instances on dedicated ADC hardware, the OnDemand Switch platforms. ADC-VX is built on a
unique architecture that virtualizes the OnDemand Switch resourcesincluding 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.
You can save and back up configurations from and to different form factors. For more information,
see Backing Up the Active vADC Configuration, page 100.
vADCs
A vADC is a virtualized instance of the AlteonOS that behaves in the same manner as a traditional
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 users or applications 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, throughput, and other
resources by assigning capacity units and adjusting capacity limits to a vADC. For more details
on capacity units, see Allocating Processing Power (Capacity Units), page 85. For more details
on the Global Administrators tasks, see Global Administrator, page 85).
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 Administrators tasks, see vADC
Administrator, page 88).
vADC Management
As opposed to traditional ADC management, ADC-VX management is divided between two
management roles:
Global Administrator, page 85
vADC Administrator, page 88
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 server load balancing 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 85
Monitoring Health and Resource Usage, page 85
Allocating Processing Power (Capacity Units), page 85
Managing vADCs
The Global Administrator creates and deletes vADCs. The Global Administrator can also apply
changes for all running vADCs with pending configurations and save active configurations of all
running 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.
Note: The maximum number of vADCs depends on the Alteon Operating System version and
platform. For more information, refer to the Alteon Maintenance and Installation Guide.
For an example procedure for creating and configuring vADC, see Creating a New vADC, page 93
For a discussion of allocating resources, see Allocating Processing Power (Capacity Units), page 85.
Note: Configuring (applying) changes involving a large number of filters with the audit feature
enabled takes much time (up to four minutes) in particular for virtualization with few capacity units
for a given vADC. The apply time can be reduced with proper (more) CU allocation.
Traffic processing 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.
In addition, the minimal number of CUs that must be allocated for traffic processing is affected by
the following optional capacity limits:
The maximum number of SSL CPS.
The maximum compression throughput.
The maximum number of pages per minute processed by APM.
The maximum number of pages per second processed by FastView.
Notes
FastView and Web Application Security (AppWall and Authentication) can be activated (capacity
limit definition and CU allocation) only if a license for these capabilities is installed on the Alteon
platform.
FastView and Web Application Security (AppWall and Authentication) cannot both be activated
on the same vADC.
You can assign multiple capacity units to a vADC from the available capacity units in the pool of
global capacity units. For information on capacity unit limits per vADC, and throughput limits for
capacity units, see the Alteon Maintenance and Installation Guide.
Disable the vADC before adjusting the number of capacity units. Enable the vADC for the change to
take effect.
The system services that the Global Administrator can delegate include:
Syslog server
AAA Services
RADIUS server
TACACS server
Timeout for idle CLI sessions
vADC Management IP settings
Management access protocols
SMTP services
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.
vADC Administrator
The vADC Administrator manages Layer 3 and server load balancing 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 88
Configuring and Maintaining Management Ports, page 89
Delegating System Services, page 89
Locking and Unlocking Delegated Services, page 89
Monitoring and Maintaining vADCs, page 89
Synchronizing vADCs, page 89
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 85).
The vADC Administrator can override many of the Global Administrator settings for individual
vADCs. For example, using Configuration > System > Management Access > Management
Ports, 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
vADC Management IP settings
Management access protocols
SMTP services
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, server load balancing groups, virtual IPs, and all the vADC
server load balancing settings.
To synchronize the configuration between two Alteons, a peer must be configured and enabled on
each Alteon.
Use the button to send SLB, FILT, and VRRP configuration updates to peers.
Resource Management
ADC-VX manages vADC resource consumption by limiting or sharing extra resources.
The Global Administrator can enable or disable this feature:
EnableLimits the resources available to vADCs.
DisableEnables sharing of any extra available resources between vADCs.
Note: When changing modes between limit (enabled) and shared (disabled), all vADCs remain
active and operational. Any connections beyond the allowed maximum resource consumption are
gracefully timed out rather than discarded.
The CUs of each process must use the same physical core. The CUs are distributed between the two
processes as follows:
FastView Offline CUs (in vADC) Offline Learning CUs Offline Resources CUs
(core affinity required) (core affinity required)
2 (minimum) 1 1
3 2 1
4 2 2
5 3 2
3 3
7 4 3
8 (maximum) 4 4
Understanding CU Allocation
As an example, let's consider an Alteon 5224 ADC-VX, which has 7 physical cores available for CU
allocation. It was originally configured (without FastView/Web security functionality) to have five
vADCs with the following CU allocation:
vADC 1 - 10 CUs
vADC 2 - 2 CUs
vADC 3 - 2 CUs
vADC 4 - 2 CUs
vADC 5 - 2 CUs
If we now need to provision vADC6 with a total size of 10 CUs (2 CUs for ADC and 8 CUs for
FastView) two full cores (4 CUs each) are required for the FastView offline processes and additional
two CUs are required for the ADC functionality.
Although there are 10 CUs available in the system, the vADC creation will fail as the core affinity
requirements cannot be satisfied. The action will fail upon Apply
This indicates that the user should reorganize the vADCs to use different cores.
Note: The reorganization process temporarily disables some of the vADCs for a short period of
time.
b. In the vADC table, select an entry and click , or double-click the entry you want to edit.
The relevant Edit tab displays.
c. Select Enable vADC, such that the option no longer has a check mark.
d. Click Submit.
2. Enable the new vADC6.
a. Go to Configuration > vADC > vADC.
b. In the vADC table, select an entry and click , or double-click the entry you want to edit.
The relevant Edit tab displays.
c. Select Enable vADC, such that the option has a check mark.
d. Click Submit.
3. Re-enable vADC1.
a. Go to Configuration > vADC > vADC.
b. In the vADC table, select an entry and click , or double-click the entry you want to edit.
The relevant Edit tab displays.
c. Select Enable vADC, such that the option has a check mark.
d. Click Submit.
4. If vADC1 cannot operationally be disabled, disable several vADCs (for example, vADC 2 and
vADC 4) in order to free two cores.
a. Go to Configuration > vADC > vADC.
b. In the vADC table, select an entry and click , or double-click the entry you want to edit.
The relevant Edit tab displays.
c. Select Enable vADC, such that the option no longer has a check mark.
d. Repeat until two or more cores are disabled.
e. Click Submit.
5. Enable the new vADC6.
a. Go to Configuration > vADC > vADC.
b. In the vADC table, select an entry and click , or double-click the entry you want to edit.
The relevant Edit tab displays.
c. Select Enable vADC, such that the option has a check mark.
d. Click Submit.
6. Re-enable vADC2 and vADC4.
a. Go to Configuration > vADC > vADC.
b. In the vADC table, select an entry and click , or double-click the entry you want to edit.
The relevant Edit tab displays.
c. Select Enable vADC, such that the option has a check mark.
d. Click Submit.
This section also includes Enabling a Newly Created vADC, page 96.
For the purposes of illustration, the example procedures in this section illustrate a vADC created for
a new Marketing Portal, which includes the following configuration:
The new vADC is set with four VLANs.
Only one VLAN is limited for a specific subnet (in the example, 100), while VLANs 101, 102, and
200 can use any IP subnet as required by the vADC Administrator.
Note: In a virtualization environment, do not configure different network masks for the
management networks and for the vADCs. Otherwise, the system uses the least mask value
configured to decide the local network and will not work properly.
When working with ADC-VX in a hot-standby configuration, disable the Spanning Tree Protocol (STP)
for a VLAN assigned to a vADC.
2. In the vADC table, click to add an entry. The relevant Add tab displays.
3. In the vADC ID field, type a numeric ID for the vADC.
4. In the vADC System Name field, type a common name to use for the vADC.
5. Select the Capacities tab.
a. In the Throughput Limit field, type the numeric Mbps limit.
b. In the SSL Limit field, type the numeric CPS limit.
c. In the Compression Limit field, type the numeric Mbps limit.
d. Click Submit.
6. Select the Network tab.
a. In the VLAN Assignment table, select the VLAN ID and use the arrows to move the VLAN ID
between the Available and Selected lists until all VLANs are selected.
b. In the Allowed Networks table, click to add an entry. The relevant Add tab displays.
c. In the Network ID field, type the ID to use for the allowed network.
d. In the VLAN field, type the VLAN number.
e. Select an IP version in the IP Version field.
f. In the IP Address field, type the IP address.
g. In the Mask field, type the subnet mask.
h. Click Submit.
7. Select the vADC Peers tab.
a. In the Peer ID field, type the peer ID to associate with this vADC.
b. In the Peer Name field, type the common name for the peer ID for this vADC.
c. In the appropriate IP version column field:
In the IP Address field, type the IP address.
In the Mask/Prefix field, type the subnet mask.
In the Default Gateway field, type the gateway.
d. Click Submit.
8. Select Enable vADC.
In this example, the Global Administrator may want to set a global usage policy that results in all
vADCs being required to use the organizations AAA server. To do so, the Global Administrator can
impose and lock certain delegated services so that the vADC Administrator is not able to reconfigure
them.
1. In the following steps, the syslog and RADIUS servers are enabled:
a. Select Configuration > vADC > vADC.
b. In the vADC table, select an entry and click , or double-click the entry you want to edit.
The relevant Edit tab displays.
c. Select the Services tab.
d. Select the check box in front of the Syslog Servers and Radius Servers fields.
2. Click Submit.
To create a vADC
1. Select Configuration > vADC > vADC.
2. In the vADC table, click to add an entry. The relevant Add tab displays.
3. In the vADC ID field, type a numeric ID for the vADC.
4. In the vADC System Name field, type a common name by which to refer to the vADC.
5. Select the Management tab.
a. In the appropriate IP version column field:
In the IP Address field, type the management IP address.
In the Mask/Prefix field, type the management subnet mask.
In the Default Gateway field, type the management gateway.
b. Click Submit.
6. Select the Capacities tab.
a. In the MP CPU Size field, select Basic from the drop-down list.
b. In the Throughput Limit field, type the throughput limit number in Mbps.
c. In the SSL Limit field, type the SSL limit number in CPS.
d. In the Compression Limit field, type the compression limit in Mbps.
e. In the CUs for Traffic Processing field, type the number of Capacity Units for the vADC.
Remember to consider the total throughput when assigning CUs.
f. Click Submit.
7. Select the Network tab.
a. In the VLAN Assignment table, select a VLAN ID and use the arrows to move the VLAN ID
between the Available and Selected list. Repeat until all VLAN IDs are selected for the
vADC.
b. In the Allowed Networks table, click to add an entry. The relevant Add tab displays.
c. In the Network ID field, type the ID number for the network.
d. In the VLAN field, type the VLAN number.
e. Select the IP version in the IP Version field.
f. In the IP Address field, type the IP address.
2. In the vADC table, select an entry and click , or double-click the entry you want to edit. The
relevant Edit tab displays.
3. Select Enable vADC.
4. Click Submit.
2. In the vADC table, select an entry and click , or double-click the entry you want to edit. The
relevant Edit tab displays.
3. Select the Capacities tab.
4. In the CUs for Traffic Processing field, type a new number of capacity units to use.
5. Click Submit.
b. In the VLAN table, click to add an entry. The relevant Add tab displays.
c. In the VLAN ID field, type the ID for the new VLAN.
d. In the VLAN Name field, type a common name for the VLAN.
e. On the VLAN Settings tab, select a port and use the arrows to move the port between the
Available and Selected lists. Repeat until all ports for the VLAN are selected.
f. Select Enable VLAN.
g. Click Submit.
2. Configure the vADC with the VLANs.
a. Select Configuration > vADC > vADC.
b. In the vADC table, select an entry and click , or double-click the entry you want to edit.
The relevant Edit tab displays.
c. Select the Network tab.
d. In the VLAN Assignment table, select the VLAN ID you want to add to the vADC and use the
arrows to move the VLAN ID between the Available and Selected lists. Repeat until all
VLAN IDs are selected.
e. Click Submit.
Note: In order not to create a conflict in IP addresses, you must first change the IP address in the
cfg file with a new IP address for the new VADC. When you then run the cfg/gtcfg command with the
padc argument, enter the new VADC IP address.
To create a new vADC from the configuration files of a physical, standalone ADC
1. Select Configuration > System > Configuration Management.
2. Select Import the Configuration.
3. Select Include Private Keys.
4. In the Passphrase field, type the passphrase to use.
5. In the Configuration Type field, select Standalone from the drop-down list.
6. In the vADC ID field, type the ID of the standalone device to use to create the configuration file.
7. Click Browse, and navigate to the file to use.
8. Click Import.
To replace an existing vADC with the configuration files of a physical, standalone ADC
1. Select Configuration > System > Configuration Management.
2. Select Import the Configuration.
3. Select Include Private Keys.
4. In the Passphrase field, type the passphrase to use.
5. In the Configuration Type field, select Standalone from the drop-down list.
6. In the vADC ID field, type the ID of the standalone device to use to create the configuration file.
7. Click Browse, and navigate to the file to use.
8. Click Import.
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
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
Alteon Maintenance and Installation 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
3. In the ADC Images table, select an entry and click , The relevant Edit tab displays.
4. Select Set as Default Image.
5. Click Submit.
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
3. In the ADC Images table, select an entry and click , The relevant Edit tab displays.
4. In the vADC ID table, select the vADC ID and use the arrows to move the ID between the
Available and Selected lists. Repeat until all IDs are selected.
5. Click Submit.
3. In the ADC Images table, select an entry and click , The relevant Edit tab displays.
4. In the vADC ID table, select the vADC ID and use the arrows to move the ID between the
Available and Selected lists. Repeat until all IDs are selected.
5. Click Submit.
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.
Regardless of the mode which is booted, the system does not delete old configuration files.
Caution: If you remove all infrastructure images, the image switching process cannot be initiated.
When booting with the last known configuration, the image IDs stored in the configuration file are
used. If the image bank is empty, the assigned default image is used. The last known ADC-VX
configuration includes both AC settings and vADCs.
5. Click Transform.
The system now boots up with the following settings:
The ADC-VX infrastructure boots with the pre-installed version (for example version
28.1.0.0) and the vADCs are loaded based on the image IDs originally set for them.
The standalone configuration file is still available to the system but is not visible to the
system administrator.
This procedure prevents combining the configuration import and operational mode
transformation.
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.
ADC-VX supports
Establishing a high availability relationship between vADCs with different IDs
Establishing a high availability relationship between vADCs and standalone or virtual appliances
Sharing a single link between up to 64 vADCs
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 9 - HA ID Settings, page 111 describes the HA ID settings.
Table 9: 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.
163 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. Select Configuration > vADC > vADC.
2. In the vADC table, select an entry and click , or double-click the entry you want to edit. The
relevant Edit tab displays.
3. Select the vADC Peering tab.
4. In the HA ID field, type the HA ID for the vADC.
5. Click Submit.
Notes
Basic VLANs can be configured during initial configuration. For more information, see Using the
Setup Utility in the Alteon Command Line Interface Reference Guide.
More comprehensive VLAN configuration can be done from the CLI. For more information, see
VLAN Configuration, as well as Port Configuration, in the Alteon Command Line Interface
Reference Guide.
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.
Each port has a configurable default VLAN ID. The factory default value for all VLAN IDs is 1. This
places all ports on the same VLAN initially, although each VLAN ID is configurable to any VLAN
number between 1 and 4090.
Any untagged frames (those with no VLAN specified) are classified with the VLAN ID of the sending
port.
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
The components of this example VLAN configuration are described in Table 10 - Explanation of
Example of Multiple VLANs with Tagging Adapters, page 116:
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 Alteons 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.
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.
B Parallel Links with VLANs
This example shows how it is possible through the use of VLANs to create configurations where
there are multiple links between two Alteons, without creating broadcast loops.
In Figure 4 - Parallel Links with VLANs Example, page 117, two Alteons are connected with two
different Gigabit Ethernet links. Without VLANs, this configuration would create a broadcast
loop. To prevent broadcast loops, port 25 is on VLAN 10 and port 26 is on VLAN 109. Both
Alteon-to-Alteon links are on different VLANs and therefore are separated into their own
broadcast domains.
Note: In this example, the Gig ports are on different VLANs and the Spanning Tree Protocol (STP) is
disabled.
Note: : All MP-originating traffic selects its default gateway from gateway numbers 1 through 4
only. If they are not configured and there is no more specific route configured to the destination, the
MP drops the packets.
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. View the route cache table at Monitoring > Network >
Layer 3 > Learned MACs > ARP. Table 11 - Sample Route Cache Table, page 118 displays the
entries in the route cache. The destination IP addresses 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.
a. Select Configuration > Network > Layer 3 > Gateways.
g. In the VLAN field, type the number of the VLAN that you are adding to the gateway.
Valid values are in the range 14090.
In this example, we use VLAN 2 for default gateway 5.
h. Click Submit.
i. Repeat the procedure for gateways 1 and 6, as follows:
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.
4. Configure the local networks using address and mask pairs to ensure that the VLANs use the
configured default gateways, as follows:
a. Select Configuration > Network > Layer 3 > Local Networks.
Basic IP Routing
This section provides configuration background and examples for performing IP routing functions,
and includes the following topics:
IP Routing Benefits, page 123
Routing Between IP Subnets, page 123
Subnet Routing Example, page 125
Using VLANs to Segregate Broadcast Domains, page 127
Defining IP Address Ranges for the Local Route Cache, page 128
Dynamic Host Configuration Protocol, page 129
Gratuitous ARP (GARP) Command, page 131
Static Routes, page 131
IP Routing Benefits
Alteon uses a combination of configurable IP interfaces and IP routing options. Alteon 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.
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 Command Line Interface Reference Guide.
1. Assign an IP address (or document the existing one) for each real server, router, and client
workstation.
In the example configuration in Example Configuration IP Subnet Routing with Alteon, page 125,
the following IP addresses are used:
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:
b. In the IP Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type an ID for the interface.
d. In the IP Address field, type an IP address for the interface.
e. In the Mask field, type the subnet mask to use with this interface.
f. In the VLAN field, select an option from the drop-down list.
g. Select Enable IP Interface.
h. Click Submit.
i. Repeat step 2 until all interface IDs are configured.
In this example, we use the following values:
Interface ID IP Address
1 205.21.17.3
2 100.20.10.1
3 131.15.15.1
4 206.30.15.1
3. Set each server and workstations 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:
a. Select Configuration > Network > Layer 3 > Gateways.
b. In the Gateways table, click to add an entry. The relevant Add tab displays.
c. In the Gateway ID field, type the numeric ID for the gateway.
d. In the IP Address field, type the IP address to use for the gateway.
e. In the VLAN field, type the VLAN to use for the gateway.
f. Select Enable Gateway.
g. Click Submit.
h. Repeat until all gateways are configured.
In this example, we use the following values:
Gateway ID IP Address
1 205.21.17.1
2 205.21.17.2
Note: This procedure uses the configuration in Example Topology Migration, page 124 as its
baseline.
1. Determine which ports and IP interfaces belong to which VLANs. Port and VLAN information used
in this example:
2. Add the ports to their respective VLANs. The VLANs are configured as follows:
a. Select Configuration > Network > Layer 2 > VLAN.
b. In the VLAN table, select an entry and click , or double-click the entry you want to edit.
The relevant Edit tab displays.
c. In the VLAN Settings tab, select ports and use the arrows to move them between the
Available and Selected lists.
d. Click Submit.
e. Repeat until all VLAN ports are configured.
In this example, we use the following values:
Enter y to set the default Port VLAN ID (PVID) for the port.
b. In the IP Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type an ID for the interface.
d. In the IP Address field, type an IP address for the interface.
e. In the Mask field, type the subnet mask to use with this interface.
f. In the VLAN field, select an option from the drop-down list.
g. Select Enable IP Interface.
h. Click Submit.
i. Repeat step 2 until all interface IDs are configured.
In this example, we use the following values:
Interface ID VLAN
1 2
2 1
3 1
4 3
Note: All addresses that fall outside the defined range are forwarded to the default gateway. The
default gateways must be within range.
Note: Static routes must be configured within the configured range. All other addresses that fall
outside the defined range are forwarded to the default gateway.
To limit the route cache to your local hosts, you could configure the parameters as shown in Example
Local Routing Cache Address Ranges, page 129:
Local Host Address Range Local Network Address Local Network Mask
0.0.0.0127.255.255.255 0.0.0.0 128.0.0.0
128.0.0.0128.255.255.255 128.0.0.0 128.0.0.0 or 255.0.0.0
205.32.0.0205.32.255.255 205.32.0.0 255.255.0.0
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.
b. In the IP Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the ID to use for the interface.
d. In the IP Address field, type the IP address to use for the interface.
e. In the Mask field, type the subnet mask to use for the interface.
f. In the VLAN field, select an option from the drop-down list.
g. In the BOOTP Relay field, select Enable from the drop-down list.
h. Click Submit.
2. In the Static ARP table, click to add an entry. The relevant Add tab displays.
3. In the IP Address field, type the IP address to use for ARP.
4. In the MAC Address field, type the MAC address of the device using ARP.
5. In the Port field, type the port of the device.
6. In the VLAN field, type the VLAN to use.
7. Click Submit.
Static Routes
Alteon has two basic mechanisms for learning networking routes:
Dynamic routesThe 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 133 and Open Shortest Path First (OSPF), page 149.
Static routesAlteon 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. You can define up to 1024 static routes.
2. In the Static Routes table, click to add an entry. The relevant Add tab displays.
3. In the Destination IP field, type the destination IP address.
4. In the Mask field, type the subnet mask IP address.
5. In the Gateway field, type the gateway IP address.
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.
2. In the Static Routes table, select the route to delete, then click .
2. In the IPv6 Static Routes table, click to add an entry. The relevant Add tab displays.
3. In the Destination IP field, type the destination IP address.
4. In the Prefix field, type the prefix length.
5. In the Gateway field, type the gateway IP address.
6. In the Interface field, type an interface number to use.
7. Click Submit.
2. In the IPv6 Static Routes table, select the route to delete, then click .
In a routed environment, routers communicate with one another to keep track of available routes.
Routers can learn about available routes dynamically using the Routing Information Protocol (RIP).
Alteon supports RIP version 1 (RIPv1) and RIP version 2 (RIPv2) for exchanging TCP/IP route
information with other routers.
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 Command Line
Interface Reference Guide.
RIP Versions
This section includes the following sub-sections:
RIP Version 1, page 134
RIP Version 2, page 134
RIP Version 2 in RIP Version 1 Compatibility Mode, page 134
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 135
Triggered Updates, page 135
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. Radware
recommends therefore that you disable 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 that you enable 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.
To configure RIP
1. Add VLANs for routing interfaces.
a. Select Configuration > Network > Layer 2 > VLAN.
b. In the VLAN table, select the VLAN to add to the port and click , or double-click the entry
you want to edit. The relevant Edit tab displays.
c. In the VLAN tab, select the port and use the arrows to move the port between the Available
and Selected lists.
d. Click Submit.
e. Repeat until all VLANs are configured with the required ports.
In this example, we use the following values:
VLAN Port
2 2
3 3
b. In the IP Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the numeric ID for the IP interface.
d. In the IP Address field, type the IP address to use for the interface.
e. In the Mask field, type the subnet mask to use for the interface.
f. In the VLAN field, select the VLAN to use from the drop-down list.
g. Select Enable IP Interface.
h. Click Submit.
i. Repeat until all of the IP interfaces are configured with VLANs.
In this example, we use the following values:
BGP-based Global Server Load Balancing (GSLB) uses the Internets routing protocols to localize
content delivery to the most efficient and consistent site. For more information on BGP-based GSLB,
see Using Anycast for GSLB, page 567.
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.
Note: Restart the BGP peer after updating an access list or route map.
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.
2. In the Route Maps table, click to add an entry. The relevant Add tab displays.
3. In the Route Map ID field, type an ID for the route map.
4. Select Enable Route Map.
5. Click Submit.
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 145.
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 10 - Relationship Between Route Maps,
Access Lists, and Network Filters, page 139 illustrates the relationship between route maps, access
lists and network filters.
Figure 10: Relationship Between Route Maps, Access Lists, and Network Filters
Route maps in an outgoing route map list behave similar to route maps in an incoming route map
list. If a route map is not configured in the outgoing route map list, all routes are advertised or
permitted. If a route map is configured in the outgoing route map list, matched routes are
advertised and unmatched routes are ignored.
Precedence
You can set a priority to a route map by specifying a precedence value with the following option:
2. In the Route Maps table, click to add an entry. The relevant Add tab displays.
3. In the Route Map ID field, type an ID for the route map.
4. In the Precedence field, type the numeric value to use.
5. Select Enable Route Map.
6. Click Submit.
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
You can configure route maps.
b. In the Network Filters table, click to add an entry. The relevant Add tab displays.
c. In the Network Filter ID field, type the ID for the filter.
d. In the IP Address field, type the IP address to use.
e. In the Mask field, type the subnet mask to use.
f. Select Enable Network Filter.
g. Click Submit.
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.
a. Select Configuration > Network > Layer 3 > Dynamic Routing > Route Maps.
b. In the Route Maps table, click to add an entry. The relevant Add tab displays.
c. In the Route Map ID field, type the numeric ID to use for the route map.
d. In the Access List tab, click to add an entry. The relevant Add tab displays.
e. In the Access List ID field, type the numeric ID for the access list.
f. In the Network Filter field, type the numeric ID for the network filter.
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.
a. Select Configuration > Network > Layer 3 > Dynamic Routing > Route Maps.
b. In the Route Maps table, click to add an entry. The relevant Add tab displays.
c. In the Route Map ID field, type the numeric ID to use for the route map.
d. In the Access Path tab, click to add an entry. The relevant Add tab displays.
e. In the Access Path ID field, type the numeric ID for the access path.
f. In the AS Number field, type the numeric ID.
g. In th Action field, select either Permit or Deny for the action.
h. Select Enable Access List.
i. Click Submit.
In this example, we use the following values:
b. In the Route Maps table, click to add an entry. The relevant Add tab displays.
c. In the Route Map ID field, type the ID for the route map.
d. In the Local Preference field, type the local preference value.
e. In the AS-Path Prepend of Matched Route field, type the AS number to prepend.
f. In the Metric field, type the metric.
g. Select Enable Route Map.
h. Click Submit.
In this example, we use the following values:
5. 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:
a. Select Configuration > Network > Layer 3 > Dynamic Routing > BGP > Peers.
b. In the Peers table, click to add an entry. The relevant Add tab displays.
c. In the Peer ID field, type a numeric ID.
d. In the Remote IP Address field, type a remote IP address.
e. In the In Route Map tab, select the route map and use the arrows to move it between
the Available and Selected lists.
f. Select Enable BGP Peer.
g. Click Submit.
Outgoing route map list:
a. Select Configuration > Network > Layer 3 > Dynamic Routing > BGP > Peers.
b. In the Peers table, click to add an entry. The relevant Add tab displays.
c. In the Peer ID field, type a numeric ID.
d. In the Remote IP Address field, type a remote IP address.
e. In the Out Route Map tab, select the route map and use the arrows to move it between
the Available and Selected lists.
f. Select Enable BGP Peer.
g. Click Submit.
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.
Example
2. In the Aggregations table, click to add an entry. The relevant Add tab displays.
3. In the Aggregation ID field, type the numeric ID.
4. In the IP Address field, type the IP address.
5. In the Mask field, type the subnet mask.
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 re-
advertise 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 138. 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 148.
Default routes can be configured using the following methods:
Import
OriginateThe router sends a default route to peers even though it does not have any default
routes in its routing table.
RedistributeDefault 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 143
Metric (Multi-Exit Discriminator) Attribute, page 144
To configure the BGP default local preference, affecting outbound direction only
1. Select Configuration > Network > Layer 3 > Dynamic Routing > BGP.
2. In the Local Preference field, type the local preference value.
3. Select Enable BGP.
4. Click Submit.
To configure the route map local preference, affecting both inbound and outbound
directions
1. Select Configuration > Network > Layer 3 > Dynamic Routing > Route Maps.
2. In the Route Maps table, click to add an entry. The relevant Add tab displays.
3. In the Route Map ID field, type the numeric ID for the route map.
4. In the Local Preference field, type the local preference value.
5. Select Enable Route Map.
6. Click Submit.
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 205.
b. In the VLAN table, click to add an entry. The relevant Add tab displays.
c. In the VLAN ID field, type the numeric ID for the VLAN.
d. In the VLAN Settings tab, select a port and use the arrows to move it between the Available
and Selected lists.
e. Click Submit.
3. Define the IP interfaces.
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.
Alteon can be configured with up to 255 gateways. Gateways 1 to 4 are reserved for default
gateway load balancing. Gateways 5 to 259 are used for load-balancing of VLAN-based
gateways.
4. Configure the Re-ARP period.
a. Select Configuration > Network > Layer 3.
b. In the Settings tab, in the Re-Arp Period field, type the re-ARP period for the interface.
c. Click Submit.
In this example, we use the following values:
Re-Arp Period
10
b. In the IP Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the numeric ID for the interface.
d. In the IP Address field, type the IP address.
e. In the Mask field, type the subnet mask value.
f. In the Peer IP field, type the peer IP address.
g. Select Enable IP Interface.
h. Click Submit.
i. Repeat these steps until all IP interfaces are configured.
In this example, we use the following values:
7. Enable IP forwarding.
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.
a. Select Configuration > Network > Layer 3.
b. In the Settings tab, ensure that Enable Forwarding is selected. If it is not, click Enable
Forwarding and then click Submit.
To help eliminate the possibility for a Denial of Service (DoS) attack, the forwarding of directed
broadcasts is disabled by default.
8. Globally turn on BGP.
a. Select Configuration > Network > Layer 3 > Dynamic Routing > BGP.
b. Select Enable BGP.
c. Click Submit.
9. 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.
a. Select Configuration > Network > Layer 3 > Dynamic Routing > BGP > Peers.
b. In the Peers table, click to add an entry. The relevant Add tab displays.
c. In the Peer ID field, type the numeric ID for the peer.
d. In the Remote IP Address field, type the IP address.
e. In the Remote AS Number field, type the remote AS value.
f. In the Redistribution tab, additional fields display.
g. In the Advertised Route Metric field, type the metric.
h. In the Default Route Action field, select an option from the drop-down list.
i. Select Enable BGP Peer.
j. Click Submit.
k. Repeat these steps until all peers are configured.
In this example, we use the following values:
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.
3. Configure the AS number.
a. Select Configuration > Network > Layer 3 > Dynamic Routing > BGP.
b. In the AS Number field, type the AS number.
c. Select Enable BGP.
d. Click Submit.
4. Configure the Router ID.
a. Select Configuration > Network > Layer 3 > Dynamic Routing.
b. In the Router ID field, type the router ID.
c. Click Submit.
In this example, we use the following values:
AS Number Router ID
135 10.1.1.135
b. In the Peers table, click to add an entry. The relevant Add tab displays.
c. In the Peer ID field, type the ID number.
d. In the Remote IP Address field, type the IP address.
e. In the Remote AS Number field, type the remote AS number.
f. In the Redistribution tab, in the Default Route Action field, select an option from the drop-
down list.
g. Repeat until all peers are configured.
In this example, we use the following values:
6. Configure aggregation policy control. Configure the routes that you want aggregated.
a. Select Configuration > Network > Layer 3 > Dynamic Routing > BGP >
Aggregations.
b. In the Aggregations table, click to add an entry. The relevant Add tab displays.
c. In the Aggregation ID field, type the ID number.
d. In the IP Address field, type the IP address.
e. In the Mask field, type the subnet mask value.
f. Select Enable Aggregation.
g. Click Submit.
In this example, we use the following values:
Note: Options in this section reflect OSPF version 2. For OSPF version 3 options, it is sufficient in
most cases to replace the OSPF in the path with OSPFv3. For example:
OSPF version 2:
Configuration > Network > Layer 3 > Dynamic Routing > OSPF
OSPF version 3:
Configuration > Network > Layer 3 > Dynamic Routing > OSPFv3
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 150
Types of OSPF Areas, page 150
Types of OSPF Routing Devices, page 151
Neighbors and Adjacencies, page 152
The Link-State Database, page 152
The Shortest Path First Tree, page 152
Internal versus External Routing, page 152
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.
It is also useful to expose the routes you can access outside your network (upstream providers or
peers) about the routes you have access to in your network. Sharing of routing information between
autonomous systems is known as external routing.
Typically, an AS has one or more border routers (peer routers that exchange routes with other OSPF
networks) as well as an internal routing system enabling every router in that AS to reach every
other router and destination within that AS.
When a routing device advertises routes to boundary 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 the routing device advertises 192.204.4.0/24, it is declaring that if another router sends
data destined for any address in the 192.204.4.0/24 range, it will carry that data to its destination.
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 153
Interface Cost, page 156
Electing the Designated Router and Backup, page 156
Summarizing Routes, page 157
Default Routes, page 157
Virtual Links, page 158
Router ID, page 159
Authentication, page 160
Host Routes for Load Balancing, page 164
Redistributing Routes into OSPF, page 164
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 158).
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 informationan area index and an area ID. The
option to define an OSPF area is as follows:
2. In the Areas table, click to add an entry. The relevant Add tab displays.
3. In the Area Number field, type the numeric area index value.
4. In the Area ID field, type the area ID IP address.
5. Click Submit.
Note: The Area Number value 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 Area ID value.
2. In the Areas table, click to add an entry. The relevant Add tab displays.
3. In the Area Number field, type the area index value.
4. In the Area ID field, type an area IP address.
5. Repeat these steps until all areas are configured.
In this example, we use the following values:
2. In the Areas table, click to add an entry. The relevant Add tab displays.
3. In the Area Number field, type the area index value.
4. In the Area ID field, type an area IP address.
5. Repeat these steps until all areas are configured.
In this example, we use the following values:
Note: Although both types of area ID formats are supported, ensure that the area IDs are in the
same format throughout an area.
2. In the Interfaces table, click to add an entry. The relevant Add tab displays.
3. In the Interface ID field, type the ID for the interface.
4. In the Area Number field, select an option from the drop-down list.
5. Click Submit.
Example
The following options 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:
1. Configure the IP Interface.
a. Select Configuration > Network > Layer 3 > IP Interfaces.
b. In the Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the ID for the interface.
d. In the IP Address field, type the IP address.
e. In the Mask field, type the subnet mask.
f. In the VLAN field, select an option from the drop-down list.
g. Click Submit.
In this example, we use the following values:
b. In the Areas table, click to add an entry. The relevant Add tab displays.
c. In the Area Number field, type the area index number.
d. In the Area ID field, type the area IP address.
e. Click Submit.
In this example, we use the following values:
b. In the Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the interface ID.
d. In the Area Number field, select an option from the drop-down list.
e. Click Submit.
In this example, we use the following values:
Interface Cost
The OSPF link-state algorithm (Dijkstras 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 as follows:
2. In the Interfaces table, click to add an entry. The relevant Add tab displays.
3. In the Interface ID field, type the interface ID.
4. In the Router Priority field, type a router priority value.
The default value is 1. Valid values are in the range 0255.
5. Click Submit.
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 options:
2. In the Summary Ranges table, click to add an entry. The relevant Add tab displays.
3. In the Range ID field, type an ID for the range.
4. In the IP Address field, type an IP address.
5. In the Mask field, type a subnet mask.
range number is a number 1 to 16
IP address is the base IP address for the range
mask is the IP address mask for the range
6. Click Submit.
For a detailed configuration example, see 3: Summarizing Routes, page 174.
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 Default Routes Example,
page 158), any traffic for IP address destinations outside the area is forwarded to Alteons 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 Default
Routes Example, page 158), 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.
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 Default Routes Example, page 158).
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 options:
2. In the Areas table, click to add an entry. The relevant Add tab displays.
3. In the Area Number field, type an area index number.
4. In the Area ID field, type the IP address for the area.
5. In the Area Type field, select Transit.
6. Click Submit.
The virtual link must be configured on the routing devices at each endpoint of the virtual link,
though they may traverse multiple routing devices.
2. In the Virtual Links table, click to add an entry. The relevant Add tab displays.
3. In the Router ID field, type the ID for the router.
4. In the IP Address field, type the IP address for the router.
5. In the Interfaces field, select an option from the drop-down list.
6. Click Submit.
Another router ID is needed when configuring a virtual link in the other direction. To provide Alteon
with a router ID, see Router ID, page 159.
For a detailed configuration example on Virtual Links, see 2: Virtual Links, page 169.
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:
DynamicallyBy default, OSPF protocol configures the lowest IP interface IP address as the
router ID.
StaticallyUse the following option to manually configure the router ID:
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.
Authentication Example, page 160 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.
b. In the Areas table, click to add an entry. The relevant Add tab displays.
c. In the Area Number field, type an area index number for the interface.
2. Configure a simple text password up to eight characters for each OSPF IP interface in Area 0 on
Alteons 1, 2, and 3.
a. Select Configuration > Network > Layer 3 > Dynamic Routing > Interfaces.
b. In the Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type an ID for the interface.
d. In the Keys tab, type a password in the Authentication Key field.
e. Click Submit.
f. Repeat step 2 until all passwords are configured.
In this example, we use the following values:
b. In the Areas table, click to add an entry. The relevant Add tab displays.
c. In the Area Number field, type an area index number for the interface.
d. In the Area ID field, type an IP address for the area.
e. In the Authentication Type field, select Password from the drop-down list.
f. Click Submit.
In this example, we use the following values:
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.
a. Select Configuration > Network > Layer 3 > Dynamic Routing > Interfaces.
b. In the Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type an ID for the interface.
d. In the Keys tab, type a password in the Authentication Key field.
e. Click Submit.
f. Repeat step 2 until all passwords are configured.
In this example, we use the following values:
b. In the Areas table, click to add an entry. The relevant Add tab displays.
c. In the Area Number field, type the numeric ID for the interface.
d. In the Area ID field, type the IP address for the area.
e. Click Submit.
In this example, we use the following values:
b. In the Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the MD5 Key ID field, type the numeric ID.
d. In the Key field, type an identifier by which the MD5 key will be known.
e. Click Submit.
In this example, we use the following values:
b. In the Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the numeric ID for the interface.
d. In the Area Number field, select area 0 from the drop-down list.
e. In the Keys tab, enter the MD5 key to associate with this interface in the MD5 Key ID field.
f. Click Submit.
In this example, we use the following values:
b. In the Areas table, click to add an entry. The relevant Add tab displays.
c. In the Area Number field, type the numeric ID for the interface.
d. In the Area ID field, type the IP address for the area.
e. Click Submit.
In this example, we use the following values:
5. Configure MD5 key for the virtual link between Area 2 and Area 0 on Alteons 2 and 4.
a. Select Configuration > Network > Layer 3 > Dynamic Routing > OSPF > MD5 Key.
b. In the Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the MD5 Key ID field, type the numeric ID.
d. In the Key field, type an identifier by which the MD5 key will be known.
e. Click Submit.
In this example, we use the following values:
b. In the Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the numeric ID for the interface.
d. In the Area Number field, select area 0 from the drop-down list.
e. In the Keys tab, enter the MD5 key to associate with this interface in the MD5 Key ID field.
f. Click Submit.
In this example, we use the following values:
If redundant routes via multiple routing processes (such as OSPF, RIP, BGP, or static routes) exist on
your network, Alteon defaults to the OSPF-derived route. For a configuration example, see 4: Host
Routes, page 177.
Note: Alteon does not redistribute Layer 3 interface IPv6 addresses when the address has a prefix
length of 128.
Note: If you want to remove a previous configuration, type 0 in the Metric field for the route
protocol in question and click Submit.
4. In the AS External Metric Type field, select either Type 1 or Type 2 from the drop-down list.
The default is Type 1.
5. Click Submit.
b. In the Route Maps table, click to add an entry. The relevant Add tab displays.
c. In the Route Map ID field, type a numeric ID for the route map.
d. Select Enable Route Map.
e. Click Submit.
2. Configure a network filter to use with the route map.
a. Select Configuration > Network > Layer 3 > Dynamic Routing > Network Filters.
b. In the Network Filters table, click to add an entry. The relevant Add tab displays.
c. In the Network Filter ID field, type the numeric ID for the filter.
d. In the IP Address field, type the IP address for the filter.
e. In the Mask field, type the subnet mask.
b. In the Route Maps table, click to add an entry. The relevant Add tab displays.
c. In the Route Map ID field, type a numeric ID for the route map.
d. Select the Access List tab.
e. In the Access List table, click to add an entry. The relevant Add tab displays.
f. In the Access List ID field, type a numeric access list ID.
g. In the Network Filter field, type a numeric filter value.
h. In the Metric field, type the metric value in the AS-External (ASE) LSA.
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.
i. In the Action field, select Permit.
To redistribute routes matched by the route map, the Action field must be set to Permit. If
the Action field is set to Deny, the routes matched by the route map are not redistributed.
j. Select Enable Access List.
k. Click Submit.
b. In the Route Maps table, click to add an entry. The relevant Add tab displays.
c. In the Route Map ID field, type a numeric ID for the route map.
d. In the OSPF Metric field, select the method for influencing decision for external routes from
the drop-down list.
e. Click Submit.
2. Match the metric of the protocol route.
a. Select Configuration > Network > Layer 3 > Dynamic Routing > Route Maps.
b. In the Route Maps table, click to add an entry. The relevant Add tab displays.
c. In the Route Map ID field, type a numeric ID for the route map.
d. In the Metric field, type the numeric value to set the priority for choosing this device for the
route. A value of 0 sets no default. A value of 1 sets the highest priority for the route.
e. Click Submit.
The configuration of the route map is similar to that described in the second method except that the
action is set to deny.
b. In the IP Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the numeric ID for the interface.
2. Enable OSPF.
a. Select Configuration > Network > Layer 3 > Dynamic Routing > OSPF.
b. Select Enable OSPF.
c. Click Submit.
3. Define the backbone. Always configure the backbone as a transit area using area ID 0.0.0.0.
a. Select Configuration > Network > Layer 3 > Dynamic Routing > OSPF > Areas.
b. In the Areas table, click to add an entry. The relevant Add tab displays.
c. In the Area Number field, type the numeric area index.
d. In the Area ID field, type the IP address.
e. In the Area Type field, select Transit.
f. Select Enable Area.
g. Click Submit.
In this example, we use the following values:
b. In the Areas table, click to add an entry. The relevant Add tab displays.
c. In the Area Number field, type the numeric area index.
d. In the Area ID field, type the IP address.
e. In the Area Type field, select Stub.
f. Select Enable Area.
g. Click Submit.
In this example, we use the following values:
b. In the Interfaces table, click to add an entry. The relevant Add tab displays.
b. In the Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the numeric ID.
d. In the Area Number field, select the area from the drop-down menu.
e. Select Enable Interface.
f. Click Submit.
In this example, we use the following values:
b. In the IP Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the numeric ID for the interface.
d. In the IP Address field, type the IP address.
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 address.
a. Select Configuration > Network > Layer 3 > Dynamic Routing > OSPF > Virtual
Links.
b. In the Virtual Links table, click to add an entry. The relevant Add tab displays.
c. In the Router ID field, type the numeric area index.
d. In the IP Address field, type the IP address.
e. In the Interface field, select an option from the drop-down list.
f. Select Enable Area.
g. Click Submit.
In this example, we use the following values:
3. Enable OSPF.
a. Select Configuration > Network > Layer 3 > Dynamic Routing > OSPF.
b. Select Enable OSPF.
c. Click Submit.
4. Define the backbone.
a. Select Configuration > Network > Layer 3 > Dynamic Routing > OSPF > Areas.
b. In the Areas table, click to add an entry. The relevant Add tab displays.
c. In the Area Number field, type the numeric area index.
d. In the Area ID field, type the IP address.
e. In the Area Type field, select Transit.
f. Select Enable Area.
g. Click Submit.
In this example, we use the following values:
5. Define the transit area. The area that contains the virtual link must be configured as a transit
area.
a. Select Configuration > Network > Layer 3 > Dynamic Routing > OSPF > Areas.
b. In the Areas table, click to add an entry. The relevant Add tab displays.
c. In the Area Number field, type the numeric area index.
d. In the Area ID field, type the IP address.
e. In the Area Type field, select Transit.
f. Select Enable Area.
g. Click Submit.
In this example, we use the following values:
b. In the Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the numeric ID.
d. In the Area Number field, select the area from the drop-down menu.
e. Select Enable Interface.
f. Click Submit.
In this example, we use the following values:
b. In the Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the numeric ID.
d. In the Area Number field, select the area from the drop-down menu.
e. Select Enable Interface.
f. Click Submit.
In this example, we use the following values:
8. Configure the virtual link. The virtual neighbor 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.
a. Select Configuration > Network > Layer 3 > Dynamic Routing > OSPF > Virtual
Links.
b. In the Virtual Links table, click to add an entry. The relevant Add tab displays.
c. In the Router ID field, type the numeric ID.
d. In the IP Address field, select the area from the drop-down menu.
e. In the Interface field, select the interface from the drop-down menu.
f. Select Enable Virtual Routers.
g. Click Submit.
In this example, we use the following values:
b. In the IP Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the numeric ID for the interface.
d. In the IP Address field, type the IP address.
e. In the Mask field, type the subnet mask.
f. In the VLAN field, select an option from the drop-down list.
g. Select Enable IP Interface.
h. Click Submit.
In this example, we use the following values:
10. 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 in step 8 for Alteon 1.
a. Select Configuration > Network > Layer 3 > Dynamic Routing > OSPF > Virtual
Links.
b. In the Virtual Links table, click to add an entry. The relevant Add tab displays.
c. In the Router ID field, type the numeric area index.
d. In the IP Address field, type the IP address.
e. In the Interface field, select an option from the drop-down list.
f. Select Enable Area.
g. Click Submit.
In this example, we use the following values:
12. Configure the backbone index on the non-backbone end of the virtual link.
a. Select Configuration > Network > Layer 3 > Dynamic Routing > OSPF > Areas.
b. In the Areas table, click to add an entry. The relevant Add tab displays.
c. In the Area Number field, type the numeric area index.
d. In the Area ID field, type the IP address.
e. In the Area Type field, select Transit.
f. Select Enable Area.
g. Click Submit.
In this example, we use the following values:
b. In the Areas table, click to add an entry. The relevant Add tab displays.
c. In the Area Number field, type the numeric area index.
d. In the Area ID field, type the IP address.
e. In the Area Type field, select Transit.
f. Select Enable Area.
g. Click Submit.
In this example, we use the following values:
b. In the Areas table, click to add an entry. The relevant Add tab displays.
c. In the Area Number field, type the numeric area index.
d. In the Area ID field, type the IP address.
e. In the Area Type field, select Stub.
f. Select Enable Area.
g. Click Submit.
In this example, we use the following values:
b. In the Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the numeric ID.
d. In the Area Number field, select the area from the drop-down menu.
b. In the Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the numeric ID.
d. In the Area Number field, select the area from the drop-down menu.
e. Select Enable Interface.
f. Click Submit.
In this example, we use the following values:
17. Configure the virtual link. The virtual neighbor router ID configured in this step must be the
same as the router ID that was configured in step 10 for Alteon 1.
a. Select Configuration > Network > Layer 3 > Dynamic Routing > OSPF > Virtual
Links.
b. In the Virtual Links table, click to add an entry. The relevant Add tab displays.
c. In the Router ID field, type the numeric ID.
d. In the IP Address field, select the area from the drop-down menu.
e. In the Interface field, select the interface from the drop-down menu.
f. Select Enable Virtual Routers.
g. Click Submit.
In this example, we use the following values:
Notes
You can use redundant paths by configuring multiple virtual links.
Only the endpoints of the virtual link are configured. The virtual link path may traverse multiple
routers in an area as long as there is a routable path between the endpoints.
If the network IP addresses in an area are assigned to a contiguous subnet range, you can configure
the ABR to advertise a single summary route that includes all the individual IP addresses within the
area.
Summarizing Routes Example, page 175 illustrates one summary route from area 1 (stub area)
injected into area 0 (the backbone). The summary route consists of all IP addresses from
36.128.192.0 through 36.128.254.255, except for the routes in the range 36.128.200.0 through
36.128.200.255.
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.
1. Configure IP interfaces for each network which is attached to OSPF areas.
a. Select Configuration > Network > Layer 3 > IP Interfaces.
b. In the IP Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the numeric ID for the interface.
d. In the IP Address field, type the IP address.
e. In the Mask field, type the subnet mask.
f. In the VLAN field, select an option from the drop-down list.
g. Select Enable IP Interface.
h. Click Submit.
In this example, we use the following values:
2. Enable OSPF.
a. Select Configuration > Network > Layer 3 > Dynamic Routing > OSPF.
b. Select Enable OSPF.
c. Click Submit.
b. In the Areas table, click to add an entry. The relevant Add tab displays.
c. In the Area Number field, type the numeric area index.
d. In the Area ID field, type the IP address.
e. In the Area Type field, select Transit.
f. Select Enable Area.
g. Click Submit.
In this example, we use the following values:
b. In the Areas table, click to add an entry. The relevant Add tab displays.
c. In the Area Number field, type the numeric area index.
d. In the Area ID field, type the IP address.
e. In the Area Type field, select Stub.
f. Select Enable Area.
g. Click Submit.
In this example, we use the following values:
b. In the Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the numeric ID.
d. In the Area Number field, select the area from the drop-down menu.
e. Select Enable Interface.
f. Click Submit.
In this example, we use the following values:
b. In the Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the numeric ID.
d. In the Area Number field, select the area from the drop-down menu.
7. Configure route summarization by specifying the starting address and mask of the range of
addresses to be summarized.
a. Select Configuration > Network > Layer 3 > Dynamic Routing > OSPF > Summary
Ranges.
b. In the Summary Ranges table, click to add an entry. The relevant Add tab displays.
c. In the Range ID field, enter a numeric ID for the summary range.
d. In the Area Number field, select an area index number from the drop-down list.
e. In the IP Address field, type an IP address.
f. In the Mask field, type a subnet mask.
g. In the Range field, select Hide.
h. Select Enable Summary Range.
i. Click Submit.
In this example, we use the following values:
b. In the IP Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the numeric ID for the interface.
d. In the IP Address field, type the IP address.
e. In the Mask field, type the subnet mask.
f. In the VLAN field, select an option from the drop-down list.
g. Select Enable IP Interface.
h. Click Submit.
i. Repeat step 1 until all interfaces are configured.
In this example, we use the following values:
Interface ID IP Address
1 10.10.10.5
2 100.100.100.40
2. Configure basic server load balancing 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.
a. Select Configuration > Application Delivery > Server Resources > Real Servers.
b. In the Real Services table, click to add an entry. The relevant Add tab displays.
c. In the Real Server ID field, type a numeric ID for the server.
d. In the Server IP Address, type the IP address for the server.
e. Select Enable Real Server.
f. Click Submit.
g. Repeat step 2 until all servers are configured.
In this example, we use the following values:
b. In the Server Groups table, click to add an entry. The relevant Add tab displays.
c. In the Server Group ID field, type an ID for the server group.
d. In the Real Servers tab, select the real servers and use the arrows to move them between
the Available and Selected lists.
e. Click Submit.
In this example, we use the following values:
b. In the Port Processing table, click to add an entry. The relevant Add tab displays.
c. In the Port field, type the port number.
d. Select Server.
e. Click Submit.
f. Repeat step 4 until all ports are configured.
In this example, we use the following values:
Port
4
5
b. In the Virtual Services table, click to add an entry. The relevant Add tab displays.
c. In the Virtual Server ID field, type the numeric ID for the virtual server.
d. In the IP Address field, type the IP address.
e. In the Virtual Services tab, click to add an entry. The relevant Add tab displays.
f. In the Service Port field, type the virtual port number.
g. In the Group ID field, select an option from the drop-down list.
h. In the Advanced tab, select Enable in the Direct Access Mode field.
i. Repeat step 5 until direct access mode is enable for each port.
In this example, we use the following values:
6. Configure the primary virtual server. Alteon 1 is preferred for virtual server 10.10.10.1.
a. Select Configuration > Application Delivery > Virtual Services.
b. Int he Virtual Services table, click to add an entry. The relevant Add tab displays.
c. In the Virtual Server ID field, type the numeric ID for the virtual server.
d. In the IP Address field, type the IP address.
e. In the Virtual Services tab, click to add an entry. The relevant Add tab displays.
f. In the Application field, select HTTP from the drop-down list.
g. In the Group ID field, select an option from the drop-down list.
h. Click Submit.
In this example, we use the following values:
7. 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.
a. Select Configuration > Application Delivery > Virtual Services.
b. Int he Virtual Services table, click to add an entry. The relevant Add tab displays.
c. In the Virtual Server ID field, type the numeric ID for the virtual server.
d. In the IP Address field, type the IP address.
e. In the Virtual Services tab, click to add an entry. The relevant Add tab displays.
f. In the Application field, select HTTP from the drop-down list.
g. In the Group ID field, select an option from the drop-down list.
h. Click Submit.
In this example, we use the following values:
b. In the Areas table, click to add an entry. The relevant Add tab displays.
c. In the Area Number field, type the numeric area index.
d. In the Area ID field, type the IP address.
e. In the Area Type field, select Transit.
f. Select Enable Area.
g. Click Submit.
In this example, we use the following values:
b. In the Areas table, click to add an entry. The relevant Add tab displays.
c. In the Area Number field, type the numeric area index.
d. In the Area ID field, type the IP address.
e. In the Area Type field, select Transit.
f. Select Enable Area.
g. Click Submit.
In this example, we use the following values:
b. In the Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the numeric ID.
d. In the Area Number field, select the area from the drop-down menu.
e. Select Enable Interface.
f. Click Submit.
In this example, we use the following values:
b. In the Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the numeric ID.
d. In the Area Number field, select the area from the drop-down menu.
e. Select Enable Interface.
f. Click Submit.
In this example, we use the following values:
13. 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: You do not need to enable redistribution if you configure virtual server routes as host
routes.
a. Select Configuration > Network > Layer 3 > Dynamic Routing > OSPF > Hosts.
b. In the Hosts table, click to add an entry. The relevant Add tab displays.
c. In the Host ID field, type the ID for the host.
d. In the IP Address field, type the IP address.
e. In the Area Number field, select the area index number from the drop-down list.
f. In the Output Cost field, type the cost value.
g. Select Enable Host.
h. Click Submit.
i. Repeat step 13 until all hosts are configured.
In this example, we use the following values:
Note: When a service goes down, the corresponding host route is removed from advertising.
14. Configure basic server load balancing parameters. Alteon 2 is connected to two real servers.
Each real server is given an IP address and is placed in the same real server group.
a. Select Configuration > Application Delivery > Server Resources > Real Servers.
b. In the Real Services table, click to add an entry. The relevant Add tab displays.
c. In the Real Server ID field, type a numeric ID for the server.
d. In the Server IP Address, type the IP address for the server.
e. Select Enable Real Server.
f. Click Submit.
g. Repeat step 14 until all servers are configured.
In this example, we use the following values:
b. In the Server Groups table, click to add an entry. The relevant Add tab displays.
c. In the Server Group ID field, type an ID for the server group.
d. In the Real Servers tab, select the real servers and use the arrows to move them between
the Available and Selected lists.
e. Click Submit.
In this example, we use the following values:
16. Configure the virtual server parameters. The same virtual servers are configured as on Alteon 1.
a. Select Configuration > Application Delivery > Virtual Services.
b. Int he Virtual Services table, click to add an entry. The relevant Add tab displays.
c. In the Virtual Server ID field, type the numeric ID for the virtual server.
d. In the IP Address field, type the IP address.
e. In the Virtual Services tab, click to add an entry. The relevant Add tab displays.
f. In the Application field, select HTTP from the drop-down list.
g. In the Group ID field, select an option from the drop-down list.
h. Click Submit.
i. Repeat step 16 until all virtual servers are configured.
In this example, we use the following values:
17. Configure IP interfaces for each network that will be attached to OSPF areas.
a. Select Configuration > Network > Layer 3 > IP Interfaces.
b. In the IP Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the ID for the interface.
d. In the IP Address field, type the IP address.
e. In the Mask field, type the subnet mask.
f. In the VLAN field, select an option from the drop-down list.
g. Select Enable IP Interface.
h. Click Submit.
i. Repeat step 17 until all IP interfaces are configured.
In this example, we use the following values:
Interface ID IP Address
1 10.10.10.6
2 100.100.100.41
b. In the Areas table, click to add an entry. The relevant Add tab displays.
c. In the Area Number field, type the numeric area index.
d. In the Area ID field, type the IP address.
e. In the Area Type field, select Transit.
f. Select Enable Area.
g. Click Submit.
In this example, we use the following values:
b. In the Areas table, click to add an entry. The relevant Add tab displays.
c. In the Area Number field, type the numeric area index.
d. In the Area ID field, type the IP address.
e. In the Area Type field, select Transit.
f. Select Enable Area.
g. Click Submit.
In this example, we use the following values:
b. In the Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the numeric ID.
d. In the Area Number field, select the area from the drop-down menu.
e. Select Enable Interface.
f. Click Submit.
In this example, we use the following values:
b. In the Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the numeric ID.
d. In the Area Number field, select the area from the drop-down menu.
23. 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.
a. Select Configuration > Network > Layer 3 > Dynamic Routing > OSPF > Hosts.
b. In the Hosts table, click to add an entry. The relevant Add tab displays.
c. In the Host ID field, type the ID for the host.
d. In the IP Address field, type the IP address.
e. In the Area Number field, select the area index number from the drop-down list.
f. In the Output Cost field, type the cost value.
g. Select Enable Host.
h. Click Submit.
i. Repeat step 23 until all hosts are configured.
In this example, we use the following values:
Switch HA Mode
In Switch HA mode, a switch-based group aggregates all virtual IPs (VIP, PIP, and floating IP
addresses) on an Alteon as a single entity. PIPs for real servers, services, and VLAN ports associated
with a VIP are automatically added when you add that VIP to a group. The active Alteon supports all
traffic or services. The backup Alteon acts as a standby for services on the active master Alteon. If
the master Alteon fails, the backup Alteon takes over processing for all services. The backup Alteon
may forward Layer 2 and Layer 3 traffic, as appropriate. When both Alteons are healthy, only the
master responds to packets sent to the virtual server IP address. All virtual IPs fail over as a group,
and cannot fail over individually. All virtual IPs in a switch-based group are either in a master or
backup state.
In Switch HA mode, only one Alteon is active at any given time, and the other is in standby mode.
When failover occurs, the Alteon that becomes active sends Gratuitous ARP messages to the virtual
IP addresses (VIP, PIP, and floating IP addresses) associated with the Alteon that becomes inactive.
Service HA Mode
In Service HA mode, several VIPs and floating IP addresses can be grouped together and behave as
a single entity for failover purposes. PIP addresses for real servers and services associated with a
VIP are automatically added when you add that VIP to a group. PIP addresses for VLAN ports are not
added. A service group is comprised of several VIPs and their associated floating IP addresses. You
can define up to 64 service groups on a single Alteon platform.
Service HA mode provides an efficient tracking and failover method based on a groups tracking
parameters while leaving other groups unaffected.
In Service HA mode, both Alteon platforms can be active. Some VIPs are active on one Alteon, while
others are active on the second Alteon. A single service group (VIP or group of VIP and floating IP
addresses) can fail to the other device. When failover occurs, the Alteon that becomes active sends
Gratuitous ARP messages to the virtual IP addresses (VIP, PIP, and floating IP addresses) associated
with the Alteon that becomes inactive.
Notes
PIP addresses configured per port/VLAN are not synchronized and do not fail over.
The same PIP address cannot be configured on two virtual servers in different service groups.
Failback Mode
Alteon supports two failback modes, as follows:
AlwaysFailback to the Alteon with the preferred state set to active occurs when that Alteon
becomes available.
On FailureFailback does not occur if all tracked resources are available on the active Alteon.
The failback mode of both Alteons in the HA pair should be the same.
Select a failback mode at the following locations:
In Switch HA modeConfiguration > Network > High Availability > Failback Mode
(default On Failure).
In Service HA mode Configuration > Network > High Availability > Service Groups >
Failback Mode (default On Failure).
Preferred State
The preferred state for an Alteon platform (Switch HA mode) or a service group (Service HA mode)
can be Active or Standby.
The preferred state is relevant and configurable only when the failback mode is Always.
The preferred state should be Active for one of the Alteons (or service groups) in an HA pair, and
Standby for the other.
If both Alteon platforms (or service groups) have the same preferred state, the system arbitrarily
selects the active Alteon (or group).
Select a preferred state at the following locations:
In Switch HA modeConfiguration > Network > High Availability > Preferred State
(default Standby).
In Service HA mode Configuration > Network > High Availability > Service Groups >
Preferred State (default Active).
Advertisement Interfaces
Select the IP interface through which Alteon sends high availability advertisements. Define IP
interfaces at Configuration > Network > Layer 3 > IP Interfaces, making sure that you set a
peer IP address for each interface. Radware recommends that you define at least two advertisement
interfaces.
Select interfaces at the following locations:
In Switch HA modeConfiguration > Network > High Availability > Advertisement
Interfaces.
In Service HA modeConfiguration > Network > High Availability > Service Groups >
Advertisement Interfaces.
Holdoff Timer
When an Alteon platform becomes the master at power up or after a failover operation, it may begin
to forward data traffic before the connected gateways or real servers are operational. Alteon may
create empty session entries for the incoming data packets and the traffic cannot be forwarded to
any gateway or real server.
Alteon supports a holdoff timer, which pauses the start as, or changes to, the master state during
the initialization. The holdoff timer can be set from 0 to 255 seconds. The master waits the specified
number of seconds before forwarding traffic to the default gateway and real servers.
This can also be used, for example, with LACP to postpone initialization after LACP LAG negotiation,
and after health checks are confirmed.
Floating IP Addresses
A floating IP address is a virtual IP address that is identical for both devices in a high availability pair.
The floating IP address is intended for routing purposes from clients and real servers when they are
not located in the same Layer 2 domain.
The floating IP address must reside on the same subnet as the interface, and it must be different
than any other defined IP addresses (virtual IP, proxy IP, interface IP, and peer IP addresses).
3. In the Service Groups table, click to add an entry. The relevant Add tab displays.
4. In the Service Group ID field, type an ID of up to 32 characters.
Allowed characters: alphanumeric, hyphen (-), and underscore (_).
For each service group, you must assign a service group ID.
5. Select a preferred initial state for the service group. For more information, see Preferred State,
page 188.
6. Select a failback mode for the service group. For more information, see Failback Mode,
page 188.
7. Select Enable Service Group to activate this service group.
8. Click Submit.
3. In the Service Groups table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
4. In the VIPs table of the Group Members tab, select the virtual servers that you want to add to
the service group and use the arrows to move the VIPs between the Available and Selected
lists.
5. Click Submit.
3. In the Service Groups table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
4. In the Advertisement Interfaces tab, select the interfaces that you want to add to the service
group and use the arrows to move the interfaces between the Available and Selected lists.
5. Click Submit.
3. In the Service Groups table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
4. In the Floating IPs table of the Group Members tab, select the floating IP addresses that you
want to assign to the service group and use the arrows to move the IPs between the Available
and Selected lists.
5. Click Submit.
4. In the Service Groups table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
5. (Optional) In the Failover Trigger tab, select Real Servers Tracking to remove a real server
from the calculation of available resources when that server does not respond to Alteon.
6. (Optional) Select Gateway Tracking to enable tracking of configured gateways. Gateway
failure causes failover.
7. In the Interfaces section, select the interfaces and gateways to include and exclude when
tracking and use the arrows to move the interfaces between the Available and Selected lists.
8. Click Submit.
4. In the Static Trunks table, click to add an entry. The relevant Add tab displays.
5. Select the number for the trunk, and the minimum number of ports that must be active. Failover
occurs when the number of available ports on the trunk falls below this value
6. Click Submit.
7. In the LACP table, click to add an entry. The relevant Add tab displays.
8. Select the administration key for the trunk, and the minimum number of ports that must be
active. Failover occurs when the number of available ports on the trunk falls below this value.
9. Click Submit.
Stateful Failover
Alteon supports high availability by allowing a standby Alteon to take over when the primary Alteon
fails. This ensures that an Alteon platform is always available to process traffic. However, when an
Alteon platform becomes active, existing connections are dropped and new connections are load-
balanced to newly selected servers.
Stateful failover ensures that traffic can continue without interruption. This is achieved by mirroring
session state and persistence data to the standby Alteon, allowing the standby Alteon to continue
forwarding traffic on existing connections, and ensuring persistence for new connections.
Stateful failover is available in Switch HA mode and in switch-based Legacy VRRP modes only.
This section describes the following topics:
Session Mirroring, page 194
Operations During Stateful Data Mirroring on Reboot, page 195
Configuring Session Mirroring, page 196
Persistent Session State Mirroring, page 197
Configuring Persistent Session State Mirroring, page 197
What Happens When Alteon Fails, page 198
Configuring Stateful Failover, page 199
Forcing Failover, page 200
Session Mirroring
Session mirroring synchronizes the state of active connections with the standby Alteon to prevent
service interruptions in case of failover.
Session mirroring can be activated per virtual service or filter.
Session mirroring is recommended for long-lived TCP connections, such as FTP, SSH, and Telnet
connections. Session mirroring for protocols characterized by short-lived connections such as UDP
and in many cases HTTP, is not necessary. Radware recommends that you use service-based session
mirroring only when you need to maintain the state of a long connection.
Session mirroring support can differ according to the type of processing and protocol, as follows:
Support for Sessions Processed at Layer 4 Support for Sessions Processed at Layer 7
Session mirroring is performed for regular Session mirroring is supported in non-proxy
Layer 4 protocols. mode (delayed binding enabled) when the
For protocols that require ALG support: back-end server does not change during the
session. When the back-end server changes
Session mirroring is performed for SIP during the session (per transaction), session
and FTP. mirroring is not supported. For more
Session mirroring is not performed for information, see Immediate and Delayed
RTSP. Binding, page 248.
In full proxy mode (delayed binding force
Proxy), new sessions, server changes, and
session deletions are mirrored to the backup
device, but the TCP sequence is not updated
during the session life. Upon failover, the
newly active Alteon sends a reset to the
clients, inducing them to initiate new
connections as soon as possible.
SSL termination sessions are not mirrored
(only their underlying TCP sessions, as per
full proxy mode), as this requires
synchronizing to the peer Alteon confidential
SSL session parameters (such as the shared
SSL key negotiated between the client and
the Alteon server during the SSL
handshake).
Prerequisites
To work with session mirroring, you must perform the following prerequisites:
Configure the master and backup with the same port layout and trunk IDs.
Define a configuration synchronization peer. Radware recommends that you synchronize
configuration between Alteons after each Apply operation using the Alteon automated
mechanism. If you do not want to synchronize configuration via Alteon, to ensure session
mirroring works properly, you must at least enable mapping synchronization, which
synchronizes the mapping of alphanumeric IDs to internal IDs for servers, groups, and virtual
servers across Alteons.
2. In the Virtual Servers table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
3. In the Virtual Services table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
4. Select the Session Management tab.
5. Set the Session Mirroring option to Enable.
The default value is Disable.
6. Click Submit.
2. In the Filters table, select an entry and click , or double-click the entry you want to edit. The
relevant Edit tab displays.
3. Select the Session Management tab.
4. Set the Session Mirroring option to Enable.
5. Click Submit.
Note: Insert and rewrite cookie modes do not require a persistent session state because
cookie insertion is based on a hashing algorithm, which results in both Alteons of the cluster
binding to the same servers without the need for a session table.
SSL ID
FTP state
Persistent session state data is synchronized over the same interface used for configuration
synchronization, thus configuration synchronization peer must be defined for the persistent session
state mirroring to occur.
New persistent entries are aggregated and synchronized to the peer device over unicast UDP
communication every user-defined interval (default 30 seconds) or when more than 32 entries are
aggregated, whichever occurs first.
Figure 21: Stateful Failover Example when the Master Alteon Fails
Recommendations
Radware recommends that you use the following configuration options for optimal stateful failover:
Enable preemption at Configuration > Application Delivery > Virtual Services > Real
Servers > Edit (or Add New) Real Server > Backup > Backup Preemption.
The master and backup Alteons should run the same software version, to ensure that stateful
failover works correctly (data structures can change between versions).
The master and backup Alteons should be the same model with the same amount of memory, to
ensure all stateful data can be mirrored (different models have different amounts of physical
memory and therefore different stateful data capacity).
3. In the Stateful Failover section, select Unicast Session Mirroring to enable unicast mirroring
mode.
4. Reverse the primary and secondary interfaces configured for the master Alteon.
Available interfaces are defined at Configuration > Network > Layer 3 > IP Interfaces.
Unicast mirroring interfaces must include a peer IP address.
5. At Configuration > Network > High Availability > Failback Mode, select a failback mode.
The failback mode of both Alteons in the HA pair should be the same.
6. At Configuration > Network > High Availability > Preferred State, select a preferred
state.
The preferred state is relevant and configurable only when the failback mode is Always.
The preferred state should be Active for one of the Alteons (or service groups) in an HA pair,
and Standby for the other.
7. Enable session mirroring for all virtual services and filters for which session state mirroring is
required.
For virtual services, see To enable session mirroring for a virtual service, page 196.
For filters, see To enable session mirroring for a filter, page 196.
8. Select Sync Persistent Sessions.
9. In the Sync Interval field, set the time, in seconds, between stateful failover updates.
The default is 30. Reduce the default value if the loss of a persistent session is problematic for
you. For example, when filling in long online forms.
10. Click Submit.
Forcing Failover
You can force a specified master Alteon, or a specified master service group, into backup mode. This
is generally used for passing master control back to a preferred Alteon (or service group) once the
preferred Alteon (or service group) has been returned to service after a failure.
If failback mode is Always when you force failover, the Alteon with preferred state Active (the
preferred master) briefly becomes the backup and then reverts to the master.
4. Select the master service group that you want to force into backup mode. Use the Ctrl key on
your keyboard to select multiple service groups.
5. Click Backup to force failover of the selected service groups.
Note: Configuration synchronization is supported only between Alteon platforms running the exact
same software version.
Alteon supports synchronization of the following:
Manual ADC/vADC Configuration Synchronization, page 201
Manual ADC-VX Configuration Synchronization, page 202
Automatically Synchronizing Alteon Peers, page 204
In addition, Alteon can synchronize updates of OSPF dynamic routes to the backup Alteon platform
to make sure that the backup can start processing traffic quickly when it becomes the master. The
synchronization of routing updates is done periodically, at user-defined intervals, and not by clicking
the button.
Radware recommends that you synchronize configuration after initial Alteon configuration to keep
peers synchronized, and after any further changes to parameters that are synchronized.
Use the the button in the local toolbar to initiate synchronization after Apply or at any other
time.
Radware recommends that when port specific parameters, such as Layer 4 port processing (for
client, server, proxy, or filter) are synchronized, 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 and have the same ports connected to the same external network devices.
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. To encrypt
or decrypt certificate private keys during configuration synchronization, the same passphrase
must be set on all peer platforms.
To support stateful failover, one of the following synchronization options is required:
Trigger configuration synchronization after each server load balancing configuration changes
session (recommended).
Perform the same configuration changes manually on the peer Alteon and enable only
synchronization of index mapping table (this maps the alphanumeric IDs of server load
balancing objects to internal indexes). When enabled, index mapping table synchronization
automatically occurs after each Apply.
2. In the Peer Synchronization table, select an entry and click , or double-click the entry you
want to edit. The relevant Edit tab displays.
3. In the vADC ID table, select the vADC peers to synchronize withthe vADC configuration and use
the arrows to move the vADC peers between the Available and Selected lists.
4. Click Submit.
2. In the vADC table, select an entry and click , or double-click the entry you want to edit. The
relevant Edit tab displays.
3. From the Sync Peer ADC VX drop-down list, select the peer switch number you want to
associate with the selected vADC.
4. Click Submit.
For additional information on SLB commands, refer to the Alteon Command Line Interface Reference
Guide.
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 balancingThis 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 balancingA 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.
All of these issues can be addressed by adding an Alteon with SLB software, as shown in Figure 25 -
Web Hosting with SLB Solutions, page 209:
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, or must use the Min Misses, Hash, or Persistent Hash metrics (see
Metrics for Real Server Groups, page 223).
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 processingPorts 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 processingPorts 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.
The following is an example network topology:
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.
b. In the IP Interfaces table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
c. In the IP Address field, type the IP address.
d. Select Enable IP Interface.
e. Click Submit.
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.
In this example, we use the following values:
IP Address
200.200.200.100
3. Define each real server. For each real server, you must assign a real server ID, specify its actual
IP address, and enable the real server.
a. Select Configuration > Application Delivery > Server Resources > Real Servers.
b. In the Real Servers table, click to add an entry. The relevant Add tab displays.
c. In the Real Server ID field, type the server ID number.
d. In the Server IP Address field, type the actual IP address for the server.
e. Select Enable Real Server.
f. Click Submit.
g. Repeat until all real servers are configured.
In this example, we use the following values:
4. Define a real server group and add the three real servers to the service group.
a. Select Configuration > Application Delivery > Server Resources > Server Groups.
b. In the Server Groups table, click to add an entry. The relevant Add tab displays.
c. In the Server Group ID field, type the server group ID number.
d. In the Real Servers tab, select the server and use the arrows to move the server between
the Available and Selected lists. Repeat until all servers are selected.
e. Click Submit.
In this example, we use the following values:
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.
a. Select Configuration > Application Delivery > Virtual Services.
b. In the Virtual Servers table, click to add an entry. The relevant Add tab displays.
c. In the Virtual Server ID field, type the virtual server ID number.
d. In the IP Address field, type the IP address for the virtual server.
e. In the Virtual Services tab, click to add an entry in the Virtual Services table. The
relevant Add tab displays.
f. In the Application field, select HTTP from the drop-down list.
g. In the Group ID field, select the group from the drop-down list.
h. Click Submit.
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 13 -
Well-known Application Ports , page 215. To configure multiple services, see Configuring Multiple
Services per Real Server, page 219.
In this example, we use the following values:
b. In the Port Processing table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. Select the required port processing settings for the port.
d. Click Submit.
e. Repeat these steps until all ports are configured.
In this example, we use the following values:
Layer7 content switching to specific application portIf you have multiple HTTP
applications running on the same real server differentiated by the listening port on the server,
the applications are identified by HTTP (Layer 7) content switching rules that review requesting
URL content to determine destination application port.
Alteon lets you define different real servers with the same IP address and different ports where
every HTTP application is configured on a separate real server with its own ports, all with the
same IP address. The real servers are associated with groups, each dedicated to a Layer 7
content switching rule on the virtual service.
Health checkLets you configure scripted health checks for a server with multiple ports.
Maximum connections
Physical serverIf you need to limit the maximum number of connections per physical
server (maximum TCP capacity), you can define multiple real servers with the same IP
address and set each real server mode to physical and its maximum connectionsto the
required value.
Logical serverIf you need to limit the maximum number of connections per logical server
running on the same physical server, you can define multiple real servers with the same IP
address and set each real mode to logical and its maximum connections to the required
value.
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 maximum connection mode.
Real servers with the same IP address set to maximum connection mode physical must all have
the same maximum connections value. The maximum connections 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 maximum connections values. The maximum connections value is the maximum
number of connections that each logical real server supports individually.
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 added ports. Multiple real
servers with the same IP address with no added port 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 335.
For all applications without a well-known port, you can select Basic-SLB as the application.
Select a table row and click to edit an entry. The relevant Edit tab displays.
Alternatively, you can double-click the table row you want to edit.
or
2. Select Configuration > Application Delivery > Virtual Services and click the Quick
Service Creation link.
To run a single service over both the UDP and TCP protocols
1. Define two virtual servers with the same VIP address.
a. Select Configuration > Application Delivery > Virtual Services.
b. In the Virtual Servers table, click to add an entry. The relevant Add tab displays.
c. In the Virtual Server ID field, type the server ID number.
d. In the Description field, type a common name for the virtual server.
e. In the IP Version field, select IPv4 from the drop-down list.
f. In the IP Address field, type the IP address the server will use.
g. Select Enable Virtual Server.
h. Click Submit.
i. Repeat this step until all virtual servers are configured.
In this example, we use the following values:
b. In the Virtual Servers table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. Select the Virtual Services tab
d. In the Virtual Services table, click to add an entry. The relevant Add tab displays.
e. In the Application field, select Basic-SLB from the drop-down list.
f. In the Service Port field, type the port number.
g. In the Protocol field, select TCP from the drop-down list.
h. In the Group ID field, select the group number from the drop-down list.
i. Click Submit.
In this example, we use the following values:
b. In the Virtual Servers table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. Select the Virtual Services tab
d. In the Virtual Services table, click to add an entry. The relevant Add tab displays.
e. In the Application field, select Basic-SLB from the drop-down list.
f. In the Service Port field, type the port number.
g. In the Protocol field, select UDP from the drop-down list.
h. In the Group ID field, select the group number from the drop-down list.
i. Click Submit.
In this example, we use the following values:
In the Real Servers table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
Select Enable Real Server. In order to disable the server, there should not be a check
mark in the box.
Click Submit.
When the current session count on your server falls to zero, you can shut down your server.
When maintenance is complete, use the following option to re-enable the real server.
Select Configuration > Application Delivery > Server Resources > Real Servers.
In the Real Servers table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
Select Enable Real Server. In order to enable the server, there should be a check mark in
the box.
Click Submit.
Alteon resumes assignment of connections to this real server immediately.
Table 14 - Disabling Commands Behavior, page 218 compares the behavior of the /oper/slb/dis
and /cfg/slb/real <real id>/dis commands:
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.
Note: To disable a real server (for example, to perform maintenance) and make sure that the
backup real server takes over, use the /oper/slb/dis command. If you use the /cfg/slb/real
<real id>/dis command, the backup real server remains in a blocked state. A backup real server
takes over only in the following cases:
When a health check request to the primary real server fails.
When traffic overflow occurs on the primary real server.
When a real server is disabled using the /oper/slb/dis command.
2. In the Real Servers table, select an entry and click , or double-click the entry you want to edit.
The relevant Edit tab displays.
3. Select the Health Check tab.
4. In the Interval field, type the number of seconds at which the server should be checked.
5. In the Retries to Failure field, type the number of checks to attempt before declaring the
server down.
6. Click Submit.
In this example, we use the following values:
For more complex health-checking strategies, see Health Checking, page 399.
2. In the Real Servers table, select an entry and click , or double-click the entry you want to edit.
The relevant Edit tab displays.
3. Select the Health Check tab.
4. In the Buddy Servers table, click to add an entry. The relevant Add tab displays.
5. In the Buddy Server ID field, select the server ID from the drop-down list.
6. Int he Buddy Server Group ID field, select the server group ID from the drop-down list.
7. In the Buddy Server Service Port field, type the service port number.
8. Click Submit.
2. In the Real Servers table, select an entry and click , or double-click the entry you want to edit.
The relevant Edit tab displays.
3. Select the Health Check tab.
4. In the Buddy Servers table, select an entry and click to delete it.
5. Click Submit.
2. In the Real Servers table, select an entry and click , or double-click the entry you want to edit.
The relevant Edit tab displays.
3. Select the Health Check tab.
4. In the Buddy Servers table, find the entry you want to review.
b. In the IP Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the ID number.
d. In the IP Address field, type the IP address.
e. In the Mask field, type the subnet mask.
f. Select Enable IP Interface.
g. Click Submit.
In this example, we use the following values:
b. In the Port Processing table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. Select Server.
d. Click Submit.
e. Repeat these steps until all ports are configured.
b. In the Real Servers table, click to add an entry. The relevant Add tab displays.
c. In the Real Server ID field, type an ID for the real server.
d. In the Server IP Address field, type the IP address for the real server.
e. Select Enable Real Server.
f. Click Submit.
g. Repeat these steps until all ports are configured.
In this example, we use the following values:
b. In the Server Groups table, click to add an entry. The relevant Add tab displays.
c. In the Server Group ID field, type the server group ID number.
d. In the Real Servers tab, select each real server to associate with the group and use the
arrows to move the real server between the Available and Selected lists. Repeat until all
real servers are required are listed in the Selected list.
e. In the Group Settings tab, select TCP from the drop-down list in the Health Check field.
f. Click Submit.
In this example, we use the following values:
b. In the Virtual Servers table, click to add an entry. The relevant Add tab displays.
c. In the Virtual Server ID field, type the ID number.
d. In the IP Address field, type the IP address for the virtual server.
e. In the Virtual Services tab, click to add an entry in the Virtual Services table. The
relevant Add tab displays.
f. In the Application field, select HTTP from the drop-down list.
g. Click Submit.
In this example, we use the following values:
b. In the Real Servers table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
c. In the Health Check tab, click to add an entry in the Buddy Servers table. The relevant
Add tab displays.
d. In the Buddy Server ID field, select the server ID to use as a buddy from the drop-down
list.
e. In the Buddy Server Group ID field, select the server group ID to use as a buddy server
group from the drop-down list.
f. In the Buddy Server Service Port, type the service port the buddy server uses.
g. Click Submit.
h. Repeat these steps until all buddy servers are configured.
In this example, we use the following values:
2. In the Server Groups table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
3. Select the Group Settings tab.
4. In the Group Settings tab, set the SLB Metric drop-down list to Min Misses.
5. Click Submit.
Minimum Misses
The Min Misses 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 persistence when servers are
removed from service. This metric should be used only when persistence is required.
By default, the Min Misses 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 Min Misses 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, select the Min Misses metric and set the Minmiss
Hash option to 32 Bits. This 32-bit hash is most useful in the wireless world.
The Min Misses 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 Persistent Hash metric can be used to maintain stable server
assignment. For more information, see Persistent Hash, page 225.
Note: The Hash metric provides more distributed load balancing than Min Misses at any given
instant. It should be used if the statistical load balancing achieved using Min Misses is not as optimal
as desired. If the load balancing statistics with Min Misses indicate that one server is processing
significantly more requests over time than other servers, consider using the Persistent Hash metric.
Persistent Hash
The Persistent Hash metric provides the best features of Hash and Min Misses metrics together. This
metric provides stable server assignments like the Min Misses metric and even load distribution like
the Hash metric.
When you select the Persistent Hash 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 Persistent Hash 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 Persistent Hash, you will not have an even load distribution as you
would with the standard hash metric.
The default Persistent Hash mask is 255.255.255.255. To change the default, configure the required
mask next to metric parameter.
Tunable Hash
By default, the Hash metric uses the clients 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 Least Connections. With the Least Connections 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 Round Robin 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 Least Connections, Round Robin, 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 Least Connections, Round Robin, 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.
To set weights
1. Enable dynamic readjustment of weights.
a. Select Configuration > Application Delivery > Server Resources > Health Check.
b. In the Health Check table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
c. In the Expect tab, select Enabled from the drop-down list in the Readjust Weight field.
d. Click Submit.
2. Set the required weight for a real server.
a. Select Configuration > Application Delivery > Server Resources > Real Servers.
b. In the Real Servers table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
c. In the Properties tab, type the weight in the Weight field.
d. Click Submit.
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 Least Connections or Round Robin metrics, the bandwidth weights are
applied on top of the Least Connections or Round Robin 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 Least Connections or Round Robin metrics.
2. In the Health Check table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
3. In the Expect tab, select Enabled from the drop-down list in the Readjust Weight field.
4. Click Submit.
For more information on configuring SNMP health checks, see SNMP Health Check, page 408.
Note: By default, Alteon creates a session with a time-out value of 4 minutes. Alteon updates this
value for subsequent traffic on the same session for virtual servers and filters after the initial packet.
2. In the Real Server table, select an entry and click , or double-click the entry you want to edit.
The relevant Edit tab displays.
3. In the Properties tab, type the time-out period to use for the server in the Inactivity Timeout
field.
4. Click Submit.
2. In the Real Servers table, select an entry and click , or double-click the entry you want to edit.
The relevant Edit tab displays.
3. In the Properties tab, type a new value in the Maximum Connections field.
4. Click Submit.
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 maximum number of
connections 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 maximum number of connections limit, Alteon no longer sends new
connections to the server. When the server drops back below the maximum connections 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 maximum connection mode.
Real servers with the same IP address set to maximum connection mode physical must all have
the same maximum connection value. The 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 maximum connection values. The value is the maximum number of connections that
each logical real server supports individually.
2. In the Real Servers table, select an entry and click , or double-click the entry you want to edit.
The relevant Edit tab displays.
3. In the Properties tab, select Physical in the Server Mode field.
4. In the Maximum Connections field, type 0 (zero).
5. Click Submit.
Server Redundancy
This section describes how Alteon supports server redundancy. When one server in a group of
servers fails and no backup server is defined, Alteon continues to send traffic to all servers in the
group, except the failed server.
This section describes the following topics:
Backup/Overflow Servers, page 230
Backup Only Server, page 232
Buddy Server, page 232
Backup Preemption, page 233
Secondary Backup Real Server Group, page 234
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 ID and real
server IP address. It must then be enabled and associated with each real server that it will back up.
b. In the Real Server table, click to add an entry. The relevant Add tab displays.
c. In the Real Server ID field, type the server ID number.
d. In the Server IP Address field, type the IP address for the real server.
e. Select Enable Real Server.
f. Click Submit.
In this example, we use the following values:
b. In the Real Server table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
c. In the Backup tab, select the server to use as a backup server using the drop-down list in
the Backup Server field.
d. In the Backup Activation on Overflow field, select Enable.
e. Click Submit.
In this example, we use the following values:
2. In the Server Groups table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
3. In the Backup tab, select Group in the Backup field.
4. In the Backup Group ID field, select the server group from the drop-down list.
5. Click Submit.
In this example, we use the following values:
Example Real server groups using another real server group for backup/
overflow
1. Select Configuration > Application Delivery > Server Resources > Server Groups.
2. In the Server Groups table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
3. In the Backup tab, select Group in the Backup field.
4. In the Backup Group ID field, select the server group from the drop-down list.
5. Click Submit.
In this example, we use the following values:
Example Define Real Server 4 as a backup only server for Real Servers 1 and 2
1. Configure the backup server.
a. Select Configuration > Application Delivery > Server Resources > Real Servers.
b. In the Real Server table, click to add an entry. The relevant Add tab displays.
c. In the Real Server ID field, type the server ID number.
d. In the Server IP Address field, type the IP address for the real server.
e. Select Enable Real Server.
f. Click Submit.
In this example, we use the following values:
b. In the Real Server table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
c. In the Backup tab, select the server to use as a backup server using the drop-down list in
the Backup Server field.
d. In the Backup Activation on Overflow field, select Enable.
e. Click Submit.
f. Repeat these steps until all real servers are configured with a backup server.
In this example, we use the following values:
Buddy Server
Alteon administrators can tie the health of a real server to another real server, known as a buddy
server. The real server and its buddy can be in the same real server group, or in separate groups.
In this configuration, a real server is only considered healthy if its buddy is also healthy. If the buddy
server fails, the real server also fails.
For more information on configuring a real server as a buddy server for another real server, see
Buddy Server Health Checks, page 220.
Backup Preemption
Alteon supports control preemption of backup when a primary server becomes active.
By default, preemption is enabled. When the primary server becomes active, it displaces the backup
server and takes control. When preemption 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.
2. In the Real Server table, select an entry and click , or double-click the entry you want to edit.
The relevant Edit tab displays.
3. In the Backup tab, select Enable or Disable using the drop-down list in the Backup
Preemption field.
4. In the Backup Activation on Overflow field, select Enable.
5. Click Submit.
6. Repeat these steps until all real servers are configured with a backup server.
Note: When a group of backup servers is assigned to a real server group, preemption must be
enabled for all servers in the group. If preemption is disabled for one server in the group, you
cannot configure a backup group or a backup real server for this group since this will cause a mixed
group to be created.
In the following example, Real Server 4 is configured as backup for Real Server 1, and preemption is
disabled in Real Server 1:
To configure real server 4 as backup for real server 1 and disable preemption on real
server 1
1. Configure the backup server.
a. Select Configuration > Application Delivery > Server Resources > Real Servers.
b. In the Real Server table, click to add an entry. The relevant Add tab displays.
c. In the Real Server ID field, type the server ID number.
d. In the Server IP Address field, type the IP address for the real server.
e. Select Enable Real Server.
f. Click Submit.
In this example, we use the following values:
b. In the Real Server table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
c. In the Backup tab, select the server to use as a backup server using the drop-down list in
the Backup Server field.
d. In the Backup Preemption field, select Disable.
e. Click Submit.
In this example, we use the following values:
2. In the Server Groups table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
3. In the Backup tab, select Group in the Backup field.
4. In the Secondary Group ID field, select the secondary server to serve as a backup from the
drop-down list.
5. Click Submit.
Note: Radware recommends that you do not change VMA option while Alteon is in operation, as
that may result in temporary disconnection of clients.
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 239.
Additional NAT capabilities on virtual services include:
Client IP persistence in selecting a proxy IP addressThe 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 PreservationPreserves the host bits of an IP address, and translates only the network
prefix bits of the IP address. Useful when the host number is used to identify users uniquely. For
more information, see Host Preservation, page 237.
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 1) requires port-based proxy IP
addresses.
Use an egress port or a VLAN-based proxy IP address for Web Cache Redirection (WCR) filtering.
c. In the Proxy IPv4 tab, click to add an entry. The relevant Add tab displays.
b. In the Virtual Servers table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In the Virtual Services tab, click to add an entry. The relevant Add tab displays.
d. In the Proxy IP tab, select Egress in the Client NAT Mode field.
e. Click Submit.
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.
b. In the Virtual Servers table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In the Virtual Services tab, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
d. In the Proxy IP tab, select Address/Subnet from the drop-down list in the Client NAT
Mode field.
e. In the Client NAT IPv4 Address field, type a new IP address.
f. In the Mask field, type a subnet mask.
Enter a subnet only when configuring multiple proxy IP addresses.
g. In the Client NAT Persistency field, select Client IP from the drop-down list.
h. Click Submit.
In this example, we use the following values:
b. In the Virtual Servers table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In the Virtual Services tab, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
d. In the Proxy IP tab, select Network Class from the drop-down list in the Client NAT Mode
field.
e. In the Client NAT IPv4 Network field, select the network class from the drop-down list. If
the required network class is not listed, click to add a new class. The relevant Add tab
displays.
f. In the Client NAT Persistency field, select Client IP from the drop-down list.
g. In the Network Class ID field, type the class ID number.
h. In the Network Class Elements table, click to add an entry. The relevant Add tab
displays.
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 240
Mapping a Virtual Server Port to Multiple Real Server Ports, page 240
Load Balancing Metric for Real Servers, page 242
Load Balancing Metric for Real Ports, page 242
Configuring Multiple Service Ports, page 242
2. In the Virtual Servers table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
3. In the Properties tab, enter the port number in the Real Server Port field.
4. Click Submit.
Note: For each real server, you can only configure one service with multiple real ports.
Figure 29 - Basic Virtual Port-to-Real Port Mapping Configuration, page 241 illustrates an example
virtual port-to-real port mapping configuration:
Table 15 - Basic Virtual Port-to-Real Port Mapping Configuration Example, page 241 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
Note: To use the single virtual port to multiple real ports 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 real port feature is enabled.
b. In the Real Servers table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
c. In the Service Port table, click to add an entry. The relevant Add tab displays.
d. In the Service Port field, type the number for the port to add to the real server.
e. Click Submit.
2. To delete a port.
a. In the Service Port table, select the entry you want to remove and click . The port is
removed from the real server configuration.
b. Select Configuration > Application Delivery > Server Resources > Real Servers.
c. In the Real Servers table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
To set up DSR
1. To configure a real server:
a. Select Configuration > Application Delivery > Server Resources > Real Servers.
b. In the Real Servers table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
c. Select the Advanced tab.
d. In the Source MAC Substitution field, select Enable from the drop-down list.
e. Click Submit.
2. To configure a virtual server:
a. Select Configuration > Application Delivery > Virtual Services.
b. In the Virtual Servers table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In the Virtual Services tab, select an entry and click , or double-click an entry you want to
edit. The relevant Edit tab displays.
d. Select the Advanced tab.
e. In the Direct Server Return field, select Enable.
f. Click Submit.
Because in this configuration delayed binding 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 clients 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 clients 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 Alteons MAC
address, so the client MAC address remains on the client port of the switch.
To block use of DAM for the UDP protocol (service port 9200)
1. Select Configuration > Application Delivery > Virtual Services.
2. In the Virtual Servers table, select an entry and click , or double-click an entry you want to
edit. The relevant Edit tab displays.
3. In the Virtual Services tab, select an entry and click , or double-click an entry you want to
edit. The relevant Edit tab displays.
4. In the Advanced tab, select Disable in the Direct Access Mode field.
5. Click Submit.
Notes
The virtual services Direct Access Mode option 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.
First, two port processes must be executed on the real server. One real server port handles the
direct traffic, and the other handles SLB traffic. Then, the virtual server port on Alteon must be
mapped to the proper real server port.
Figure 32 - Mapped and Non-Mapped Server Access, page 247 illustrates a topology where clients
can access SLB services through well-known TCP port 80 at the virtual servers IP address. Alteon
behaves like a virtual server that is mapped to TCP port 8000 on the real server. For direct access
that bypasses the virtual server and SLB, clients can specify well-known TCP port 80 as the real
servers IP address.
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 239.
Note: Clients on the management network do not have access to SLB services and cannot access
the virtual services being load balanced.
The Source Network Address and Source Network Mask parameters are located at
Configuration > Application Delivery > Virtual Services > Settings > Real Server Direct
Management Access. They are described below:
Source Network AddressDefines the source IP addresses allowed direct (non-Layer 4)
access to the real servers for administration and monitoring purposes. When this option is not
defined, anyone can directly access the servers.
Source Network MaskThe IP address mask used with the Source Network Address to
select management traffic which is allowed direct access to real servers.
Immediate Binding
The immediate binding process occurs as follows:
1. Alteon receives a TCP SYN request from the client.
2. Alteon selects to which server to forward the request.
3. Alteon immediately forwards the TCP SYN request to the selected server.
4. The TCP three-way handshake is completed.
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 supports the following load balancing options:
Layer 7 server load balancing
Layer 7 redirection filtering
SSL session ID-based binding for session persistence
Cookie-based binding for session persistence
Table 16 - Services Supporting Force Proxy, page 249 lists the services that support the delayed
binding Force Proxy option.
Note: Using Acceleration Engine services, Alteon does not initiate TCP keep-alive packets on front-
end and back-end connections. However, Alteon responds to client initiated keep-alive packets.
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.
2. In the Virtual Servers table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
3. Select the Virtual Services tab.
4. In the Virtual Services table, click to add an entry. The relevant Add tab displays.
Note: Enable delayed binding without configuring any HTTP SLB processing or persistent binding
types.
The probability of a SYN attack is higher if excessive half-open sessions are generated on Alteon.
Half-open sessions show an incomplete three-way handshake between the server and the client.
To detect SYN attacks, Alteon keeps track of the number of new half-open sessions for a set period.
If the value exceeds the threshold, then a syslog message and an SNMP trap are generated.
You can change the default parameters for detecting SYN attacks at Configuration > Security
SYN Protection. You can specify how frequently you want to check for SYN attacks, from two
seconds to one minute, and modify the default threshold representing the number of new half-open
sessions per second.
Note: When sending SYN to a server on a back-end connection, Alteon does not use the TCP
Maximum Segment Size (MSS) option and the segment size for TCP packets that Alteon sends to the
client depends on the server's default MSS size.
Note: 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.
2. In the Virtual Servers table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
3. In the Virtual Services tab, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
4. In the Properties tab, select Force Proxy in the Delayed Binding field.
5. Click Submit.
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.
2. In the Virtual Servers table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
3. In the Virtual Services tab, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
4. In the Session Management tab, type the timeout amount in minutes to use in the Session
Timeout field.
5. Click Submit.
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.
b. In the IP Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the ID to use to identify this interface.
d. In the IP Version field, select IPv6 from the drop-down list.
e. In the IP Address field, type the IP address.
f. In the Prefix field, type the prefix.
g. In the VLAN field, select the VLAN to associate with this interface.
h. Select Enable IP Interface.
i. Click Submit.
In this example, we use the following values:
b. In the IP Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the ID to use to identify this interface.
d. In the IP Version field, select IPv4 from the drop-down list.
e. In the IP Address field, type the IP address.
f. In the Mask field, type the subnet mask.
g. In the VLAN field, select the VLAN to associate with this interface.
h. In the Peer IP field, type the peer IP address.
i. Select Enable IP Interface.
j. Click Submit.
In this example, we use the following values:
b. In the Gateways table, click to add an entry. The relevant Add tab displays.
c. In the Gateway ID field, type the ID for the gateway.
d. In the IP Version field, select IPv6 from the drop-down list.
e. In the IP Address field, type the IP address to use for the gateway.
f. In the VLAN field, select the VLAN from the drop-down list.
4. Configure a PIP.
a. Select Configuration > Network > Proxy IP.
b. In the Proxy IP Associated to field, select either Ports or VLANs, depending on your
requirements.
The PIP address is used to converge the IPv4 and IPv6 traffic. Optionally, the PIP address
can be assigned to a VLAN instead of the port.
c. In either the Proxy IPv4 or Proxy IPv6 tab, and click to add an entry. The relevant Add
tab displays.
d. In the IP Address field, type the IP address for the PIP.
e. In the Port Range field, select a port and use the arrow keys to move the port between the
Available and Selected lists.
f. Click Submit.
In this example, we use the following values:
b. In the Real Servers table, click to add an entry. The relevant Add tab displays.
c. In the Real Server ID field, type an identifier for the server.
d. In the Server IP field, type the IP address for the real server.
e. Select Enable Real Server.
f. Click Submit.
g. Repeat these steps until all real servers are configured.
In this example, we use the following values:
b. In the Server Group table, click to add an entry. The relevant Add tab displays.
c. In the Server Group ID, type an identifier for the server group.
d. In the Real Servers tab, select a real server and use the arrows to move the server between
the Available and Selected lists. Repeat until all real servers are configured.
e. In the Group Settings tab, select the health check to use in the drop-down list in the Health
Check field.
f. Click Submit.
In this example, we use the following values:
b. In the Virtual Servers table, click to add an entry. The relevant Add tab displays.
c. In the Virtual Server ID field, type an identifier for the virtual server.
d. In the IP Version field, select IPv6 from the drop-down list.
e. In the IP Address field, type the IP address for the virtual server.
f. In the Virtual Services tab, click to add an entry. The relevant Add tab displays.
g. In the Service Port field, type the port for the service.
h. In the Group ID field, select the server group to use with this virtual service from the drop-
down list.
i. Click Submit.
In this example, we use the following values:
8. Configure ports.
a. Select Configuration > Application Delivery > Port Processing.
b. In the Port Processing table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In the Port Processing Settings field, select either Client or Server, as applicable, for the
selected port.
d. Click Submit.
e. Repeat these steps until all ports are properly configured.
In this example, we use the following values:
b. In the IP Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the ID to use to identify this interface.
d. In the IP Version field, select IPv6 from the drop-down list.
e. In the IP Address field, type the IP address.
f. In the Prefix field, type the prefix.
g. In the VLAN field, select the VLAN to associate with this interface.
h. Select Enable IP Interface.
i. Click Submit.
In this example, we use the following values:
b. In the Real Servers table, click to add an entry. The relevant Add tab displays.
c. In the Real Server ID field, type an identifier for the server.
d. In the IP Version field, select IPv6 from the drop-down list.
e. In the Server IP field, type the IP address for the real server.
f. Select Enable Real Server.
g. Click Submit.
h. Repeat these steps until all real servers are configured.
In this example, we use the following values:
b. In the Server Group table, click to add an entry. The relevant Add tab displays.
c. In the Server Group ID, type an identifier for the server group.
d. In the IP Version field, select IPv6 in the drop-down list.
e. In the Real Servers tab, select a real server and use the arrows to move the server between
the Available and Selected lists. Repeat until all real servers are configured.
f. In the Group Settings tab, select the health check to use in the drop-down list in the Health
Check field.
g. Click Submit.
In this example, we use the following values:
b. In the Virtual Servers table, click to add an entry. The relevant Add tab displays.
c. In the Virtual Server ID field, type an identifier for the virtual server.
d. In the IP Version field, select IPv6 from the drop-down list.
e. In the IP Address field, type the IP address for the virtual server.
f. In the Virtual Services tab, click to add an entry. The relevant Add tab displays.
g. In the Service Port field, type the port for the service.
h. In the Group ID field, select the server group to use with this virtual service from the drop-
down list.
i. Click Submit.
In this example, we use the following values:
6. Configure ports.
a. Select Configuration > Application Delivery > Port Processing.
b. In the Port Processing table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In the Port Processing Settings field, select either Client or Server, as applicable, for the
selected port.
d. Click Submit.
e. Repeat these steps until all ports are properly configured.
In this example, we use the following values:
FQDN Servers
In a virtualized environment, and in cloud networks in particular, server IP addresses can change. In
such environments it is necessary to define a server by domain name to automatically update its IP
address. This also allows for smooth scalability as a domain name can be served by multiple servers.
FQDN servers allow real servers to be defined by domain name instead of by static IP address.
Traffic can then be forwarded to a server when its IP address changes, or even when additional
servers are added, without any change in the Alteon configuration.
Once an FQDN server is created, Alteon contacts DNS servers to resolve the FQDN. According to the
response, Alteon creates one or more ephemeral real servers. The ephemeral servers take their
parameters (except ID and IP address) from a real server object designated as a template (a
different template can be used for each FQDN server). When a parameter changes in one of the real
server templates, all new ephemeral servers subsequently created with that template inherit that
change.
The ephemeral servers are not included in the configuration; they are only run-time instances.
You can view the ephemeral servers and their status at Monitoring > Application Delivery >
Real Servers.
Ephemeral servers are deleted:
Upon Alteon reset. The DNS resolution process is initiated and new ephemeral servers are
created.
When the FQDN server is disabled or deleted.
When the FQDN or IP version is changed. The DNS resolution process is initiated and new
ephemeral servers are created.
When a No such name DNS response is received.
The IP addresses received as a result are available for the duration of their TTL. Once the TTL
expires, DNS resolution is attempted again. Based on the response, the following can occur:
The same IP addresses are received. No change is performed to the ephemeral real servers, and
the TTL is reset.
Some of the IP addresses are changed. New ephemeral servers are created for the new IPs
addresses. Existing ephemeral servers whose IP addresses are not included in the DNS response
are moved to graceful shutdown mode after 15 seconds (graceful shutdown mode is delayed by
15 seconds). No new sessions are allocated but existing sessions are allowed to continue on the
server.
DNS timeout. No change is performed to the ephemeral real servers, and DNS resolution
continues to be attempted.
A No such name DNS response is received. Ephemeral servers are deleted.
Notes
The following real server capabilities are not supported for ephemeral real servers:
Buddy server
Legacy Layer 7 (Layer 7 strings)
User management role (ephemeral servers cannot be attached to a specific user)
The backup server can be configured via template only.
Switch failover is supported for high availability.
The Alteon DNS client must be configured with the DNS servers available for resolution.
A network class is a configuration object that can include multiple IP ranges and/or IP subnets and
can be used for traffic classification.
Configuring Network Classes, page 263
Configuring Source Network-Based Server Load Balancing, page 263
2. In the Network Classes table, click to add an entry. The relevant Add tab displays.
3. In the Network Class ID field, type an identifier for the network class.
4. In the Network Class Elements field, click to add an element. The relevant Add tab
displays.
5. In the ID field, type an identifier for the network element.
6. In the Network Type field, select either Subnet or Range from the drop-down list.
If Subnet is selected:
In the IP Address field, type the IP address.
In the Mask field, type the subnet mask.
If Range is selected:
In the From IP Address field, type the first IP address of the a range.
In the To IP Address field, type the last IP address of the range.
7. In the Match Type field, select either Include or Exclude.
8. Click Submit.
9. Repeat step 4 through step 8 until all elements are configured.
10. Click Submit.
b. In the Network Classes table, click to add an entry. The relevant Add tab displays.
c. In the Network Class ID field, type an identifier for the network class.
d. In the Network Class Elements field, click to add an element. The relevant Add tab
displays.
e. In the ID field, type an identifier for the network element.
f. In the Network Type field, select Range from the drop-down list.
g. In the From IP Address field, type the first IP address of the a range.
h. In the To IP Address field, type the last IP address of the range.
i. In the Match Type field, select either Include.
j. Click Submit.
k. Repeat until all network classes and elements are configured.
In this example, we use the following values:
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.
a. Select Configuration > Application Delivery >Virtual Services.
b. In the Virtual Servers table, click to add an entry. The relevant Add tab displays.
c. In the Virtual Server ID field, type the identifier for the virtual server.
d. In the IP Address field, type the IP address for the virtual server.
e. In the Virtual Services tab, click to add an entry. The relevant Add tab displays.
f. In the Application field, select HTTP from the drop-down list.
g. In the Server Port field, type the port number to use for the virtual service.
h. In the Group ID field, select the server group from the drop-down list.
i. In the Proxy IP tab, select Network Class from the drop-down list in the Client NAT Mode
field.
j. In the Client NAT IPv4 Network field, select the network class to use for this virtual
service.
k. Click Submit.
l. Repeat these steps until all virtual servers are configured.
In this example, we use the following values:
Virtual IP Address Application Server Port Group ID Client NAT Client NAT
Server ID Mode IPv4
Network
1 128.100.10 HTTP 80 1 Network Internal
0.100 Class
2 128.100.10 HTTP 80 1 Network External
0.100 Class
Note: For a list of well-known ports identified by Alteon, see Supported Services and Applications,
page 215.
This section describes the following topics:
Implementing HTTP/HTTPS Server Load Balancing, page 267
Content-Intelligent Server Load Balancing, page 269
Content-Intelligent Application Services, page 282
Advanced Content Modifications, page 290
Content-Intelligent Caching and Compression Overview, page 314
Content-Intelligent Caching, page 315
Cache Content Management, page 316
Content-Intelligent Compression, page 320
Content-Intelligent Connection Management, page 327
FastView for Alteon, page 328
HTTP/2 Gateway, page 329
Application Performance Monitoring (APM), page 331
To configure Alteon for HTTP load balancing on its well-known port (80)
1. Select Configuration > Application Delivery > Virtual Services.
2. In the Virtual Servers table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
3. Select the Virtual Services tab.
4. In the Virtual Services table, do one of the following:
Select a table row and click to edit an entry. The relevant Edit tab displays.
Alternatively, you can double-click the table row you want to edit.
To configure Alteon for HTTPS load balancing on its well-known port (443)
1. Select Configuration > Application Delivery > Virtual Services.
2. In the Virtual Servers table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
3. Select the Virtual Services tab.
4. In the Virtual Services table, do one of the following:
Select a table row and click to edit an entry. The relevant Edit tab displays.
Alternatively, you can double-click the table row you want to edit.
5. In the Application field, select HTTPS from the drop-down list.
6. In the Service Port field, type 443.
7. Set the Action option to Discard.
8. Click Submit.
2. In the Virtual Servers table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
3. Select the Virtual Services tab.
4. In the Virtual Services table, do one of the following:
Select a table row and click to edit an entry. The relevant Edit tab displays.
Alternatively, you can double-click the table row you want to edit.
5. In the Application field, select HTTP from the drop-down list.
6. In the Service Port field, type 88.
7. Set the Action option to Discard.
8. Click Submit.
2. In the Virtual Servers table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
3. Select the Virtual Services tab.
4. In the Virtual Services table, do one of the following:
Select a table row and click to edit an entry. The relevant Edit tab displays.
Alternatively, you can double-click the table row you want to edit.
5. In the Application field, select HTTPS from the drop-down list.
6. In the Service Port field, type 444.
7. Set the Action option to Discard.
8. Click Submit.
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 A -
Content-Intelligent Server Load Balancing Not Using Layer 7 Content Switching Rules, page 699.
To support IP fragment traffic when Layer 7 content switching is defined based on strings, use
the forceproxy option at Configuration > Application Delivery > Virtual Services to force
traffic through the Application Services Engine.
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 270
Virtual Hosting, page 273
Cookie-Based Preferential Load Balancing, page 274
Browser-Smart Load Balancing, page 277
XML/SOAP-Based Server Load Balancing, page 280
URL Hashing for Server Load Balancing, page 281
HTTP Normalization, page 282
Requests containing URLs with anything else are load balanced between Real Servers 1 through 4.
b. In the Content Classes table, click to add an entry. The relevant Add tab displays.
c. In the Content Class ID field, type cgi.
Maximum characters: 32
Allowed characters: alphanumeric, hyphen (-), and underscore (_).
d. In the URL Path tab, click to add an entry. The relevant Add tab displays.
e. In the ID field, type an ID for the content class URL path.
Maximum characters: 32
Allowed characters: alphanumeric, hyphen (-), and underscore (_).
f. Select Include from the Match Type drop-down list.
g. Disable the Case-Sensitive Matching option.
3. Repeat step 2 to define an HTTP class for URL load balancing to match a path that includes
images.
In this example, we use the following values:
4. Repeat step 2 to define an HTTP class for URL load balancing to match a path that includes
secure.
In this example, we use the following values:
5. 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.
6. Create Layer 7 Content Switching rules on the HTTP virtual service, including matching and
traffic redirection.
a. Select Configuration > Application Delivery > Virtual Services.
b. In the Virtual Servers table, select a virtual server.
c. In the Virtual Services of Selected Virtual Server table, select an HTTP service and click ,
or double-click the HTTP service. The relevant Edit tab displays
d. Select the Content Based Rules tab.
e. In the Content Based Rules table, click to add an entry. The relevant Add tab displays.
f. Select Enable Content based Rule.
g. In the Rule ID field, type a number for the content-based rule.
Valid values are in the range 112800.
h. In the Rule Name field, type a name for the content-based rule of up to 32 characters.
i. From the Content Class drop-down list, select the content class for the content-based rule.
j. From the Action drop-down list, select the action for the content-based rule.
k. From the Group ID drop-down list, select the server group containing the real servers that
serve the content-based rule.
l. Click Submit.
In this example, we use the following values:
7. Repeat step 6 to define a similar content switching rule to match the image class, and redirect
traffic to the group of Real Servers 3 and 4 (group 1).
In this example, we use the following values:
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 because the content switching rule ID serves as
rule matching priority. 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 option. This creates a copy of the rule from within the
option that was used with a new ID, after which you can delete the original rule ID.
8. Repeat step 6 to define a similar content switching rule to match the secure class, and redirect
traffic to a secure site.
In this example, we use the following values:
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.company.com/products/Alteon would look like this:
GET /products/Alteon/ HTTP/1.1
Host: www.company.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.
Clients that receive preferential service can be distinguished from other users by one of the
following methods:
Individual UserA specific individual user can be distinguished by IP address, login
authentication, or permanent HTTP cookie.
User CommunitiesA 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.
ApplicationsUsers 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.
ContentUsers 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.
b. In the Content Classes table, click to add an entry. The relevant Add tab displays.
c. In the Content Class ID field, type the content class identifier for the content-based rule.
Maximum characters: 32
Allowed characters: alphanumeric, hyphen (-), and underscore (_).
d. In the Cookie tab, click to add an entry. The relevant Add tab displays.
e. In the ID field, type an ID for the cookie.
Maximum characters: 32
Allowed characters: alphanumeric, hyphen (-), and underscore (_).
f. From the Cookie Key Match Type drop-down list, define the path match criteria of the
cookie key string.
g. In the Cookie Key field, type the cookie key.
The cookie ID and the cookie key set the cookie string to be matched for the rule to take
effect.
Maximum characters: 128
h. From the Cookie Value Match Type drop-down list, define the path match criteria of the
cookie match string.
Content Class ID Cookie Key Cookie Key Cookie Value Cookie Value
ID Match Type Match Type
cookie-gold 1 Equal session-id Equal gold
3. Repeat step 2 to define HTTP classes to match the values silver and bronze.
In this example, we use the following values:
Content Class ID Cookie Key Cookie Key Cookie Value Cookie Value
ID Match Type Match Type
cookie-gold 1 Equal session-id Equal silver
cookie-gold 1 Equal session-id Equal 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:
a. Select Configuration > Application Delivery > Virtual Services.
b. In the Virtual Servers table, select a virtual server.
c. In the Virtual Services of Selected Virtual Server table, select an HTTP service and click ,
or double-click the HTTP service. The relevant Edit tab displays
d. Select the Content Based Rules tab.
e. In the Content Based Rules table, click to add an entry. The relevant Add tab displays.
f. Select Enable Content based Rule.
g. In the Rule ID field, type a number for the content-based rule.
Valid values are in the range 112800.
h. In the Rule Name field, type a name for the content-based rule of up to 32 characters.
i. From the Content Class drop-down list, select the content class for the content-based rule.
j. From the Action drop-down list, select the action for the content-based rule.
k. From the Group ID drop-down list, select the server group containing the real servers that
serve the content-based rule.
l. Click Submit.
In this example, we use the following values:
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.
a. Select Configuration > Application Delivery > Virtual Services.
b. In the Virtual Servers table, select a virtual server.
c. In the Virtual Services of Selected Virtual Server table, select an HTTP service and click ,
or double-click the HTTP service. The relevant Edit tab displays
d. Set the Action option to Group.
e. From the Group ID drop-down list, select the server group containing the real servers that
serve the content-based rule.
f. Click Submit.
In this example, we use the following values:
Action Group ID
Group 15
HTTP Class4Matched with URL my-site.com and Class2 and redirects request to the mobile-
phone specific version of the Web site located at mobile.my-site.com.
HTTP Class5Matched with URL mobile.my-site.com and performs SLB using Server Group 2
which contains the optimized mobile version of the web site.
b. In the Content Classes table, click to add an entry. The relevant Add tab displays.
c. In the Content Class ID field, type desktop-browsers.
Maximum characters: 32
Allowed characters: alphanumeric, hyphen (-), and underscore (_).
d. Select the Header tab.
e. In the Header table, click to add an entry. The relevant Add tab displays.
f. In the ID field, type an ID for the header.
Maximum characters: 32
Allowed characters: alphanumeric, hyphen (-), and underscore (_).
g. From the Header Name Match Type drop-down list, define the path match criteria of the
header string.
h. In the Header Name field, type the header name.
The header ID and the header name set the cookie string to be matched for the rule to take
effect.
Maximum characters: 128
i. From the Header Value Match Type drop-down list, define the path match criteria of the
header match string.
j. In the Header Value field, type the match value.
Maximum characters: 128
k. Click Submit.
In this example, we use the following values:
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.
4. Configure content class Class2 to match mobile browsers user-agent header values using the
same procedure as Class1 in step 2.
5. Configure content class Class3 to match URL my-site.com and Class1 (desktop-browsers) by
using the Regex option:
a. Select Configuration > Application Delivery > Traffic Match Criteria > Content
Classes.
b. In the Content Classes table, click to add an entry. The relevant Add tab displays.
c. In the Content Class ID field, type Class3.
Maximum characters: 32
Allowed characters: alphanumeric, hyphen (-), and underscore (_).
d. Select the URL Hostname tab.
e. In the URL Hostname table, click to add an entry. The relevant Add tab displays.
f. In the ID field, type an ID for the hostname.
Maximum characters: 32
Allowed characters: alphanumeric, hyphen (-), and underscore (_).
g. From the Match Type drop-down list, define the path match criteria of the hostname string.
h. In the Hostname field, type the hostname.
Maximum characters: 128
i. Click Submit.
In this example, we use the following values:
6. Configure Class4 to match URL my-site.com and Class2 (mobile-browsers) using the procedure
in step 5.
7. 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 281).
8. Configure an HTTP Layer 7 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.
9. Configure an HTTP Layer 7 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.
10. Configure an HTTP Layer 7 Content Switching rule in the HTTP virtual service to match Class5
(with URL mobile.my-site.com), and perform load balancing using Server Group 2.
<?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 XML/SOAP-Based Message, page 280:
a. Select Configuration > Application Delivery > Traffic Match Criteria > Content
Classes.
b. In the Content Classes table, click to add an entry. The relevant Add tab displays.
c. In the Content Class ID field, type StockName-IBM.
d. Select the XML Tag tab.
e. In the XML Tag table, click to add an entry. The relevant Add tab displays.
f. In the ID field, type ibm.
g. Set XML Name Match Type to Equal.
h. In the Path and Tag Name field, type \GetStockPrice\StockName.
i. Set XML Value Match Type to Equal.
j. In the Path and Tag Name field, type IBM.
k. Click Submit.
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 270.
>> # /cfg/slb/virt 1
>> Virtual Server 1 # service 80
>> Virtual Server 1 http Service # http/httpslb urlhash
Enter new hash length [1-255]: 25
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.
Note: To enable X-Forwarded-For, either set delayed binding to full proxy mode and configure a
proxy IP address, or enable Direct Access Mode.
c. In the Virtual Services tab, click to add an entry. The relevant Add tab displays.
d. In the Service Port field, type a port to use.
e. In the Group ID field, select an option from the drop-down list.
f. In the HTTP Content Modification tab, click Insert X-Forward-For.
g. Click Submit.
c. In the Virtual Services tab, click to add an entry. The relevant Add tab displays.
d. In the Service Port field, type a port to use.
e. In the Group ID field, select an option from the drop-down list.
f. In the HTTP Content Modification tab, click Error Code Update. Additional fields display.
g. In the Match Error Code(s) field, type the error codes required.
h. In the HTTP Redirection field, enable or disable HTTP redirection.
i. In the URL field, type the URL for redirection.
j. In the Response Code field, type the response code.
k. Click Submit.
In this example, we use the following values:
c. In the Virtual Services tab, click to add an entry. The relevant Add tab displays.
d. In the Service Port field, type a port to use.
e. In the Group ID field, select an option from the drop-down list.
f. In the HTTP Content Modification tab, click Error Code Update. Additional fields display.
2. In the Match Error Code(s) field, type the error codes required.
3. In the HTTP Redirection field, enable or disable HTTP redirection.
4. In the URL field, type the URL for redirection.
Note: Using these options results in path modifications only. The protocol (HTTP or HTTPS) and the
port (when specified) are not modified.
c. In the Virtual Services tab, click to add an entry. The relevant Add tab displays.
d. In the Service Port field, type a port to use.
e. In the Group ID field, select an option from the drop-down list.
f. In the HTTP Content Modification tab, click URL Changes. Additional fields display in the
URL Match and URL Action section.
3. Define the URL Match options.
a. In the Hostname Match Type field, select an option from the drop-down list.
b. In the Hostname to Match field, type the hostname to match.
c. In the Path Match Type field, select an option from the drop-down list.
d. In the Path to Match field, type the path to match.
e. In the Page Name field, type the page name to match.
f. In the Path Name field, type the path name to match.
In this example, we use the following values:
Hostname Hostname to Path Match Path to Match Page Name Path Name
Match Type Match Type
Equal www.a.com Prefix www.path.com test html
5. Click Submit.
To change links in server responses with paths starting with abcd to start with
aaabcd
1. Define server response code control.
a. Select Configuration > Application Delivery > Virtual Services.
b. In the Virtual Servers table, select a virtual server.
c. In the Virtual Services tab, click to add an entry. The relevant Add tab displays.
d. In the Service Port field, type a port to use.
e. In the Group ID field, select an option from the drop-down list.
f. In the HTTP Content Modification tab, click URL Changes. Additional fields display in the
URL Match and URL Action section.
2. Define the URL Match options.
a. In the Hostname Match Type field, select an option from the drop-down list.
b. In the Path Match Type field, select an option from the drop-down list.
c. In the Path to Match field, type the path to match.
In this example, we use the following values:
4. Click Submit.
c. In the Virtual Services tab, click to add an entry. The relevant Add tab displays.
d. In the Service Port field, type a port to use.
e. In the Group ID field, select an option from the drop-down list.
f. In the HTTP Content Modification tab, click Server Cloaking.
g. Click Submit.
Note: Using these options results in path modifications only. The protocol (HTTP or HTTPS) and the
port (when specified) are not modified.
c. In the Virtual Services tab, click to add an entry. The relevant Add tab displays.
d. In the Service Port field, type a port to use.
e. In the Group ID field, select an option from the drop-down list.
f. In the HTTP Content Modification tab, click URL Path Obfuscation. Additional fields display.
g. In the Hostname Match Type field, select an option from the drop-down list.
h. In the Path Match Type field, select an option from the drop-down list.
i. In the Path to Remove field, type the path to remove.
j. Click Submit.
c. In the Virtual Services tab, click to add an entry. The relevant Add tab displays.
d. In the Service Port field, type a port to use.
e. In the Group ID field, select an option from the drop-down list.
f. In the HTTP Content Modification tab, click URL Obfuscation.
2. Define the URL Obfuscation options.
a. In the Hostname Match Type field, select an option from the drop-down list.
b. In the Path Match Type field, select an option from the drop-down list.
c. In the Path to Remove field, type the path to remove.
d. Click Submit.
c. In the Virtual Services tab, click to add an entry. The relevant Add tab displays.
d. In the Service Port field, type a port to use.
e. In the Group ID field, select an option from the drop-down list.
f. In the HTTP Content Modification tab, click Free Text Replacement. Additional fields
display.
g. In the Action Type field, select an option from the drop-down list.
h. In the Replace/Remove Text field, type the text to replace or remove.
i. Click Submit.
c. In the Virtual Services tab, click to add an entry. The relevant Add tab displays.
d. In the Service Port field, type a port to use.
e. In the Group ID field, select an option from the drop-down list.
f. In the HTTP Content Modification tab, click Free Text Replacement. Additional fields
display.
g. In the Action Type field, select an option from the drop-down list.
h. In the Replace/Remove Text field, type the text to replace or remove.
i. Click Submit.
In this example, we use the following values:
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 matches 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 314.
Table 18 - HTTP Elements and Their Supported Actions, page 291 lists all HTTP elements and their
supported actions:
Element Action
Header To configure the replace action for header elements, page 292
To configure the remove action for HTTP Headers, page 293
To configure the insert action for HTTP headers, page 294
Cookie To configure the replace action for cookies, page 296
To configure the remove action for cookies, page 298
To configure the insert action for cookies, page 299
File type To configure HTTP modification for the HTTP file type, page 303
Status line To configure the replace action for the HTTP status line, page 304
URL To use HTTP content modifications for URL elements, page 306
Text To configure the replace action for an HTTP text element, page 311
To configure the remove action for the HTTP text element, page 312
Note: The numbers and names in this procedure are examples only.
1. Select Configuration > Application Delivery > Application Services > HTTP > Content
Modification Rule-List.
2. In the Content Modification Rule-List table, select a rule.
3. In the HTTP Rules tab, click to add an entry. The relevant Add tab displays.
4. Click Enable Modification Rule-List.
5. In the Rule ID field, type an ID for the content modification rule.
6. In the Element field, select an option from the drop-down list.
7. In the Direction field, select an option from the drop-down list.
8. In the Action field, select an option from the drop-down list.
9. Click Submit.
In this example, we use the following values:
c. In the HTTP Rules tab, click to add an entry. The relevant Add tab displays.
d. Click Enable Modification Rule-List.
e. In the Rule ID field, type an ID for the content modification rule.
f. In the Element field, select an option from the drop-down list.
g. In the Direction field, select an option from the drop-down list.
h. In the Action field, select an option from the drop-down list.
i. Click Submit.
In this example, we use the following values:
2. In the Action tab, configure the required information to define the string to replace.
a. In the Header Field to Replace field, type the cookie key to remove.
b. In the Header Value to Replace field, type the new cookie value to remove.
c. In the New Header Field field, type the new cookie key to use.
d. In the New Header Value field, type the new cookie value to use.
e. Click Submit.
In this example, we use the following values:
Header Field to Header Value to New Header Field New Header Value
Replace Replace
My-Header ABC My-Header XYZ
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. Configure the remove action for HTTP Headers.
a. Select Configuration > Application Delivery > Application Services > HTTP >
Content Modification Rule-List.
b. In the Content Modification Rule-List table, select a rule.
c. In the HTTP Rules tab, click to add an entry. The relevant Add tab displays.
d. Click Enable Modification Rule-List.
e. In the Rule ID field, type an ID for the content modification rule.
f. In the Element field, select an option from the drop-down list.
g. In the Direction field, select an option from the drop-down list.
h. In the Action field, select an option from the drop-down list.
i. Click Submit.
In this example, we use the following values:
2. In the Action tab, configure the required information to define the string to replace.
a. In the Header Field to Remove field, type the cookie key to remove.
b. In the Header Value to Remove field, type the new cookie value to remove.
c. Click Submit.
c. In the HTTP Rules tab, click to add an entry. The relevant Add tab displays.
d. Click Enable Modification Rule-List.
e. In the Rule ID field, type an ID for the content modification rule.
f. In the Element field, select an option from the drop-down list.
g. In the Direction field, select an option from the drop-down list.
h. In the Action field, select an option from the drop-down list.
i. Click Submit.
In this example, we use the following values:
2. In the Action tab, configure the required information to define the string to replace.
a. In the Header Field to Remove field, type the cookie key to remove.
b. In the Header Value to Remove field, type the new cookie value to remove.
c. Click Submit.
In this example, we use the following values:
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. Configure the insert action for HTTP Headers.
a. Select Configuration > Application Delivery > Application Services > HTTP >
Content Modification Rule-List.
b. In the Content Modification Rule-List table, select a rule.
c. In the HTTP Rules tab, click to add an entry. The relevant Add tab displays.
d. Click Enable Modification Rule-List.
e. In the Rule ID field, type an ID for the content modification rule.
f. In the Element field, select an option from the drop-down list.
g. In the Direction field, select an option from the drop-down list.
h. In the Action field, select an option from the drop-down list.
In this example, we use the following values:
2. In the Action tab, configure the required information to define the string to replace.
a. In the Header Field to Remove field, type the cookie key to remove.
b. In the Header Value to Remove field, type the new cookie value to remove.
c. Click Submit.
3. In the Conditional Header Insert tab, select an option from the drop-down list. Additional fields
display depending on the selection.
4. Click Submit.
c. In the HTTP Rules tab, click to add an entry. The relevant Add tab displays.
d. Click Enable Modification Rule-List.
e. In the Rule ID field, type an ID for the content modification rule.
f. In the Element field, select an option from the drop-down list.
g. In the Direction field, select an option from the drop-down list.
h. In the Action field, select an option from the drop-down list.
i. Click Submit.
In this example, we use the following values:
2. In the Conditional Header Insert tab, configure the required information to define the string to
replace.
a. In the Element to Match field, select an option from the drop-down list.
b. In the Host to Match field, type the host to match.
c. In the Path to Match field, type the path to match.
d. Click Submit.
In this example, we use the following values:
3. In the Action tab, configure the required information to define the string to replace.
a. In the Header Field to Remove field, type the cookie key to remove.
b. In the Header Value to Remove field, type the new cookie value to remove.
c. Click Submit.
In this example, we use the following values:
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. Define the replace action for cookies.
a. Select Configuration > Application Delivery > Application Services > HTTP >
Content Modification Rule-List.
b. In the Content Modification Rule-List table, select a rule.
c. In the HTTP Rules tab, click to add an entry. The relevant Add tab displays.
d. Click Enable Modification Rule-List.
e. In the Rule ID field, type an ID for the content modification rule.
f. In the Element field, select an option from the drop-down list.
g. In the Direction field, select an option from the drop-down list.
h. In the Action field, select an option from the drop-down list.
i. Click Submit.
In this example, we use the following values:
2. In the Action tab, configure the required information to define the string to replace.
a. In the Cookie Key to Replace field, type the cookie key to remove.
b. In the Cookie Value to Replace field, type the new cookie value to remove.
c. In the New Cookie Key field, type the new cookie key to use.
d. In the New Cookie Value field, type the new cookie value to use.
e. Click Submit.
c. In the HTTP Rules tab, click to add an entry. The relevant Add tab displays.
d. Click Enable Modification Rule-List.
e. In the Rule ID field, type an ID for the content modification rule.
f. In the Element field, select an option from the drop-down list.
g. In the Direction field, select an option from the drop-down list.
h. In the Action field, select an option from the drop-down list.
i. Click Submit.
In this example, we use the following values:
2. In the Action tab, configure the required information to define the string to replace.
a. In the Cookie Key to Replace field, type the cookie key to remove.
b. In the Cookie Value to Replace field, type the new cookie value to remove.
c. In the New Cookie Key field, type the new cookie key to use.
d. In the New Cookie Value field, type the new cookie value to use.
e. Click Submit.
In this example, we use the following values:
Note: The numbers and names in this procedure are examples only.
1. Define a content modification rule list.
a. Select Configuration > Application Delivery > Application Services > HTTP >
Content Modification Rule-List.
b. In the Content Modification Rule-List table, select a rule.
c. In the HTTP Rules tab, click to add an entry. The relevant Add tab displays.
d. Click Enable Modification Rule-List.
e. In the Rule ID field, type an ID for the content modification rule.
f. In the Element field, select an option from the drop-down list.
g. In the Direction field, select an option from the drop-down list.
h. In the Action field, select an option from the drop-down list.
i. Click Submit.
In this example, we use the following values:
2. In the Action tab, configure the required information to define the string to replace.
a. In the Cookie Key to Replace field, type the cookie key to remove.
b. In the Cookie Value to Replace field, type the new cookie value to remove.
c. In the New Cookie Key field, type the new cookie key to use.
d. In the New Cookie Value field, type the new cookie value to use.
e. Click Submit.
c. In the HTTP Rules tab, click to add an entry. The relevant Add tab displays.
d. Click Enable Modification Rule-List.
e. In the Rule ID field, type an ID for the content modification rule.
f. In the Element field, select an option from the drop-down list.
g. In the Direction field, select an option from the drop-down list.
h. In the Action field, select an option from the drop-down list.
i. Click Submit.
In this example, we use the following values:
2. In the Action tab, configure the required information to define the string to replace.
a. In the Cookie Key to Replace field, type the cookie key to remove.
b. In the New Cookie Key field, type the new cookie key to use.
c. Click Submit.
In this example, we use the following values:
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. Configure a content modification rule list.
a. Select Configuration > Application Delivery > Application Services > HTTP >
Content Modification Rule-List.
b. In the Content Modification Rule-List table, select a rule.
c. In the HTTP Rules tab, click to add an entry. The relevant Add tab displays.
d. Click Enable Modification Rule-List.
e. In the Rule ID field, type an ID for the content modification rule.
f. In the Element field, select an option from the drop-down list.
g. In the Direction field, select an option from the drop-down list.
h. In the Action field, select an option from the drop-down list.
i. Click Submit.
In this example, we use the following values:
2. In the Conditional Header Insert tab, configure the required information to define the string to
replace.
a. In the Element to Match field, select an option from the drop-down list.
b. In the Host to Match field, type the host to match.
c. In the Path to Match field, type the path to match.
d. Click Submit.
3. In the Action tab, configure the required information to define the string to replace.
a. In the Cookie Key to Insert field, type the cookie key to insert.
b. In the Cookie Value to Insert field, type the cookie value to insert.
c. In the Cookie Path to Insert field, type the path for the cookie to insert.
d. In the Cookie Domain Name to Insert field, type the domain name for the cookie to insert.
e. In the Cookie Expiration Time to Insert field, type the new expiration time to insert.
f. Click Submit.
Examples
A To insert the Set-Cookie for a cookie named Device-ID with the value Alteon123 in all server
responses, use the following configuration:
To insert the Set-Cookie for a cookie named Device-ID with the value Alteon123 in
all server responses
1. Configure a content modification rule list.
a. Select Configuration > Application Delivery > Application Services > HTTP >
Content Modification Rule-List.
b. In the Content Modification Rule-List table, select a rule.
c. In the HTTP Rules tab, click to add an entry. The relevant Add tab displays.
d. Click Enable Modification Rule-List.
e. In the Rule ID field, type an ID for the content modification rule.
f. In the Element field, select an option from the drop-down list.
g. In the Direction field, select an option from the drop-down list.
h. In the Action field, select an option from the drop-down list.
i. Click Submit.
In this example, we use the following values:
2. In the Action tab, configure the required information to define the string to replace.
a. In the Cookie Key to Insert field, type the cookie key to insert.
b. In the Cookie Value to Insert field, type the cookie value to insert.
c. In the Cookie Path to Insert field, type the path for the cookie to insert.
d. In the Cookie Domain Name to Insert field, type the domain name for the cookie to insert.
e. In the Cookie Expiration Time to Insert field, type the new expiration time to insert.
f. Click Submit.
In this example, we use the following values:
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:
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
1. Configure a content modification rule list.
a. Select Configuration > Application Delivery > Application Services > HTTP >
Content Modification Rule-List.
b. In the Content Modification Rule-List table, select a rule.
c. In the HTTP Rules tab, click to add an entry. The relevant Add tab displays.
d. Click Enable Modification Rule-List.
e. In the Rule ID field, type an ID for the content modification rule.
f. In the Element field, select an option from the drop-down list.
g. In the Direction field, select an option from the drop-down list.
h. In the Action field, select an option from the drop-down list.
i. Click Submit.
In this example, we use the following values:
2. In the Conditional Cookie Insert tab, configure the required information to define the string to
replace.
a. In the Element to Match field, select an option from the drop-down list.
b. In the Host to Match field, type the host to match.
c. In the Path to Match field, type the path to match.
d. Click Submit.
In this example, we use the following values:
3. In the Action tab, configure the required information to define the string to replace.
a. In the Cookie Key to Insert field, type the cookie key to insert.
b. In the Cookie Value to Insert field, type the cookie value to insert.
c. Click Submit.
In this example, we use the following values:
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. Select Configuration > Application Delivery > Application Services > HTTP > Content
Modification Rule-List.
2. In the Content Modification Rule-List table, select a rule.
3. In the HTTP Rules tab, click to add an entry. The relevant Add tab displays.
4. Click Enable Modification Rule-List.
5. In the Rule ID field, type an ID for the content modification rule.
6. In the Element field, select an option from the drop-down list.
7. In the Direction field, select an option from the drop-down list.
8. In the Action field, select an option from the drop-down list.
9. Click Submit.
c. In the HTTP Rules tab, click to add an entry. The relevant Add tab displays.
d. Click Enable Modification Rule-List.
e. In the Rule ID field, type an ID for the content modification rule.
f. In the Element field, select an option from the drop-down list.
g. In the Direction field, select an option from the drop-down list.
h. In the Action field, select an option from the drop-down list.
i. Click Submit.
In this example, we use the following values:
2. In the Action tab, configure the required information to define the string to replace.
a. In the File Type to Replace field, type the file type to remove.
b. In the New File Type field, type the new file type to use.
c. Click Submit.
In this example, we use the following values:
Note: The numbers and names in this procedure are examples only.
1. Configure a content modification rule list.
a. Select Configuration > Application Delivery > Application Services > HTTP >
Content Modification Rule-List.
b. In the Content Modification Rule-List table, select a rule.
c. In the HTTP Rules tab, click to add an entry. The relevant Add tab displays.
d. Click Enable Modification Rule-List.
e. In the Rule ID field, type an ID for the content modification rule.
f. In the Element field, select an option from the drop-down list.
g. In the Direction field, select an option from the drop-down list.
h. In the Action field, select an option from the drop-down list.
i. Click Submit.
In this example, we use the following values:
2. In the Action tab, configure the required information to define the string to replace.
a. In the Status to Replace field, type the status to remove.
b. In the New Status Code field, type the new status to use.
c. In the New Status Text field, type a message to display.
d. Click Submit.
In this example, we use the following values:
c. In the HTTP Rules tab, click to add an entry. The relevant Add tab displays.
d. Click Enable Modification Rule-List.
e. In the Rule ID field, type an ID for the content modification rule.
f. In the Element field, select an option from the drop-down list.
g. In the Direction field, select an option from the drop-down list.
h. In the Action field, select an option from the drop-down list.
i. Click Submit.
In this example, we use the following values:
2. In the Action tab, configure the required information to define the string to replace.
a. In the Status to Replace field, type the status to remove.
b. In the New Status Code field, type the new status to use.
c. In the New Status Text field, type a message to display.
If you do not set the new status line, the previous text remains.
d. Click Submit.
In this example, we use the following values:
All the components within this URL can be modified using a single HTTP Modification URL rule.
The following topics are discussed in this section:
Update the Path, page 308
Force links to sensitive information to use HTTPS, page 309
Update Host and Path, page 310
Note: The numbers and names in this procedure are examples only.
1. Define a content modification rule list.
a. Select Configuration > Application Delivery > Application Services > HTTP >
Content Modification Rule-List.
b. In the Content Modification Rule-List table, select a rule.
c. In the HTTP Rules tab, click to add an entry. The relevant Add tab displays.
d. Click Enable Modification Rule-List.
e. In the Rule ID field, type an ID for the content modification rule.
f. In the Element field, select an option from the drop-down list.
g. In the HTTP Body field, select an option from the drop-down list.
By default, only headers are modified (body exclude). To modify both header and body, set
to body include.
h. In the Direction field, select an option from the drop-down list.
RequestOnly client requests are inspected for modification.
ResponseOnly server responses are inspected for modification.
BidirectionalThe 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.
i. In the Action field, select an option from the drop-down list.
j. Click Submit.
2. In the URL Match tab, define the URL Match options using the displayed fields.
a. In the Protocol field, select an option from the drop-down list.
HTTP or HTTPS. The default value is HTTP.
b. In the Port field, type the port to use 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.
c. In the Host Match Type field, select an option from the drop-down list.
Host Match Type can be set to Suffix, Prefix, Equal, Include or Any. Any implies that any host
will match.
d. In the Host to Match field, type the value to use for the match.
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.
e. In the Path Match Type field, select an option from the drop-down list.
Path Match Type can be set to Suffix, Prefix, Equal, Include or Any. Any implies that any
non-empty path will match.
f. In the Path to Match field, type the value to use for the match.
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.
g. In the Page Name field, type the value for an exact match.
h. In the Page Type field, type the value for an exact match.
i. Click Submit.
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.
3. In the URL Action tab, define the URL Action options depending on the path action type using the
displayed fields.
a. In the Protocol field, select an option from the drop-down list.
HTTP or HTTPS. The default value is HTTP.
b. In the Port field, type 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.
c. In the Host Action Type field, select an option from the drop-down list.
Insert Lets you insert additional text to the hostname, either before or after the
matched text.
ReplaceLets you replace the matched text in the hostname with another text.
RemoveLets you remove the matched text from the hostname.
NoneNo 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.
d. In the Path Action Type field, select an option from the drop-down list.
InsertLets you insert additional text to the path, either before or after the matched
text.
ReplaceLets you replace the matched text in the path with another text.
RemoveLets you remove the matched text from the path.
NoneNo action is taken.
Replace and Remove are not allowed when the Path Match Type is set to Any.
When using a path match, an action must be specified. To use path match as match
criteria only and leave the same path, use the replace action with the same text string
used in the match.
For example: Path Match Type include, and Path to Match abc match any path that
contains abc, such as /abc/, /a/abc, and so on. Using Path Action Remove results in
the following: path abc is removed, path de/abc/xyz is modified to de/xyz.
e. In the Page Name field, type a new page name. Leave this action empty to remove the
matched page name. When both match and action are empty, no operation is performed.
f. In the Page Type field, type a new page type. Leave this action empty to remove the
matched page type. When both match and action are empty, no operation is performed.
g. Click Enable HTTP Modification Rule.
h. Click Submit.
Note: The numbers and names in this procedure are examples only.
To update a path
1. Define a content modification rule list.
a. Select Configuration > Application Delivery > Application Services > HTTP >
Content Modification Rule-List.
b. In the Content Modification Rule-List table, select a rule.
c. In the HTTP Rules tab, click to add an entry. The relevant Add tab displays.
d. Click Enable Modification Rule-List.
e. In the Rule ID field, type an ID for the content modification rule.
f. In the Element field, select an option from the drop-down list.
g. In the HTTP Body field, select an option from the drop-down list.
h. In the Direction field, select an option from the drop-down list.
i. Click Submit.
In this example, we use the following values:
2. In the URL Match tab, define the URL Match options using the displayed fields depending on the
element and action selected.
a. In the Protocol field, select an option from the drop-down list.
b. In the Path Match Type field, select an option from the drop-down list.
c. In the Path to Match field, type the value to use for the match.
d. Click Submit.
In this example, we use the following values:
3. In the URL Action tab, define the URL Action options using the displayed fields depending on the
element and action selected.
a. In the Protocol field, select an option from the drop-down list.
b. In the Path Action Type field, select an option from the drop-down list.
c. In the New Path to Replace field, type the new path to insert.
d. Click Submit.
In this example, we use the following values:
Note: The numbers and names in this procedure are examples only.
c. In the HTTP Rules tab, click to add an entry. The relevant Add tab displays.
d. Click Enable Modification Rule-List.
e. In the Rule ID field, type an ID for the content modification rule.
f. In the Element field, select an option from the drop-down list.
g. In the HTTP Body field, select an option from the drop-down list.
h. In the Direction field, select an option from the drop-down list.
i. Click Submit.
In this example, we use the following values:
2. In the URL Match tab, define the URL Match options using the displayed fields depending on the
element and action selected.
a. In the Protocol field, select an option from the drop-down list.
b. In the Path Match Type field, select an option from the drop-down list.
c. In the Path to Match field, type the value to use for the match.
d. Click Submit.
In this example, we use the following values:
3. In the URL Action tab, define the URL Action options using the displayed fields depending on the
element and action selected.
a. In the Protocol field, select an option from the drop-down list.
b. In the Path Action Type field, select an option from the drop-down list.
c. In the New Path to Replace field, type the new path to insert.
d. Click Submit.
In this example, we use the following values:
c. In the HTTP Rules tab, click to add an entry. The relevant Add tab displays.
d. Click Enable Modification Rule-List.
e. In the Rule ID field, type an ID for the content modification rule.
f. In the Element field, select an option from the drop-down list.
g. In the HTTP Body field, select an option from the drop-down list.
h. In the Direction field, select an option from the drop-down list.
i. Click Submit.
In this example, we use the following values:
2. In the URL Match tab, define the URL Match options using the displayed fields depending on the
element and action selected.
a. In the Protocol field, select an option from the drop-down list.
b. In the Host Match Type field, select an option from the drop-down list.
c. In the Host to Match field, type the value to use for the match.
d. Click Submit.
In this example, we use the following values:
3. In the URL Action tab, define the URL Action options using the displayed fields depending on the
element and action selected.
a. In the Host Action Type field, select an option from the drop-down list.
b. In the New Host to Replace field, type the new host name to use.
c. In the Path Action Type field, select an option from the drop-down list.
d. In the Path to Insert field, type the new path to insert.
e. In the Insert Matched Section field, select where the new path should be inserted.
f. Click Submit.
In this example, we use the following values:
Host Action Type New Host to Path Action Type Path to Insert Insert Matched
Replace Section
Replace www.site1.com Insert site2/ Before
Note: The numbers and names in this procedure are examples only.
1. Configure a content modification rule list.
a. Select Configuration > Application Delivery > Application Services > HTTP >
Content Modification Rule-List.
b. In the Content Modification Rule-List table, select a rule.
c. In the HTTP Rules tab, click to add an entry. The relevant Add tab displays.
d. Click Enable Modification Rule-List.
e. In the Rule ID field, type an ID for the content modification rule.
2. In the Action tab, define the Action options using the displayed fields depending on the element
and action selected.
a. In the Text to Replace field, type the text to remove.
b. In the New Text field, type the new text to use in place of the replaced text.
c. Click Submit.
In this example, we use the following values:
Note: The numbers and names in this procedure are examples only.
Note: The numbers and names in this procedure are examples only.
1. Define a content modification rule list.
a. Select Configuration > Application Delivery > Application Services > HTTP >
Content Modification Rule-List.
b. In the Content Modification Rule-List table, select a rule.
c. In the HTTP Rules tab, click to add an entry. The relevant Add tab displays.
d. Click Enable Modification Rule-List.
e. In the Rule ID field, type an ID for the content modification rule.
f. In the Element field, select an option from the drop-down list.
g. In the HTTP Body field, select an option from the drop-down list.
h. In the Direction field, select an option from the drop-down list.
i. Click Submit.
In this example, we use the following values:
2. In the Action tab, define the Action options using the displayed fields depending on the element
and action selected.
a. In the Text to Remove field, type the text to remove.
b. Click Submit.
In this example, we use the following values:
Text to Remove
test test test
c. In the HTTP Rules tab, click to add an entry. The relevant Add tab displays.
d. Click Enable Modification Rule-List.
e. In the Rule ID field, type an ID for the content modification rule.
f. In the Element field, select an option from the drop-down list.
g. In the HTTP Body field, select an option from the drop-down list.
h. In the Direction field, select an option from the drop-down list.
i. Click Submit.
In this example, we use the following values:
2. In the Action tab, define the Action options using the displayed fields depending on the element
and action selected.
a. In the Text to Remove field, type the text to remove.
b. Click Submit.
In this example, we use the following values:
Text to Remove
test test test
c. In the Virtual Services tab, click to add an entry. The relevant Add tab displays.
d. In the Application field, select an option from the drop-down list.
e. In the Service Port field, type a port to use.
f. In the Group ID field, select an option from the drop-down list.
g. Click Submit.
2. In the HTTP Content Modification tab, define the rule list required for the service.
a. In the HTTP Modification Rule List field, select the rule using the drop-down list. If the
rule does not display, click to add an entry. The relevant Add tab displays.
b. Click Submit.
In this example, we use the following values:
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 Alteons 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, and Pragma) 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
browsers caching to improve response time and Quality of Experience (QoE).
Alteon caching is based on available 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 caching policy and a cache URL exceptions rule list that is optionally
associated to that policy. Caching policies are, in turn, associated with an HTTP virtual service.
The following caching procedures are covered in this section:
Configuring the Caching Virtual Service, page 315
Configuring the Caching Policy, page 316
c. In the Virtual Services tab, click to add an entry. The relevant Add tab displays.
d. In the Application field, select an option from the drop-down list.
e. In the Service Port field, type a port to use.
f. In the Group ID field, select an option from the drop-down list.
g. Click Submit.
In this example, we use the following values:
Caching Policy
Caching1
For details on configuring the caching policy parameters, view Configuration > Application
Delivery > Application Services > HTPP > Caching.
A rule list is an ordered list of rules that specifies which URLs to cache or not cache. You can create
multiple rule lists and change the lists associated with a caching policy as needed.
Rule list logic is first-match, meaning once a rule within the list is matched, the remaining rules in
the list are not evaluated. You can duplicate an entire rule list using the Copy Rule-List option.
Rules are ordered in the rule list according to their index number. Radware recommends that you
put rules that are matched often at the top of the list to optimize performance. See the cache URL
rule list statistics per rule to determine how often rules are matched.
b. In the Policy table, click to add an entry. The relevant Add tab displays.
c. In the Policy ID field, type an identifier for the policy.
d. In the URL Rule List field, select the URL rule to use with this policy. If the URL rule is not
listed, click to add an entry. The relevant Add tab displays.
e. Click Enable Caching Policy.
f. Click Submit.
In this example, we use the following values:
b. In the URL Rule-List table, click to add an entry. The relevant Add tab displays.
c. In the Rule-List ID field, type an ID for the rule.
d. In the table, select the rule list to use with this policy. If the URL rule does is not listed, click
to add an entry. The relevant Add tab displays.
e. In the Rule ID field, type an ID for the rule.
f. In the Expiration Time field, enter the amount of time for which the rule is valid.
g. Click Enable URL Rule.
h. Click Submit.
In this example, we use the following values:
Rule-List ID Rule ID
myurllist 1
b. Select the virtual service from the displayed list. If the virtual service is not listed, click
to add an entry. The relevant Add tab displays.
c. In the Virtual Services tab, select the virtual service from the list. If the virtual service is
not listed, click to add an entry. The relevant Add tab displays
d. In the Application field, select an option from the drop-down list.
e. In the HTTP tab, define the compression policy to use with this service.
f. In the Compression Policy field, select an option from the drop-down list. If the policy is
not listed, click to add an entry. The relevant Add tab displays.
g. Click Submit.
In this example, we use the following values:
The compression policy name you entered is now associated with virtual service HTTP.
6. Enable DAM or configure proxy IP addresses and enable proxy on the client port.
b. In the Policy table, click to add an entry. The relevant Add tab displays.
c. In the Policy ID field, type an identifier for the policy.
d. In the URL Rule List field, select the URL rule to use with this policy. If the URL rule is not
listed, click to add an entry. The relevant Add tab displays.
e. Click Enable Caching Policy.
f. Click Submit.
In this example, we use the following values:
b. In the URL Rule-List table, click to add an entry. The relevant Add tab displays.
c. In the Rule-List ID field, type an ID for the rule.
d. In the table, select the rule list to use with this policy. If the URL rule does is not listed, click
to add an entry. The relevant Add tab displays.
e. In the Rule ID field, type an ID for the rule.
f. In the Expiration Time field, enter the amount of time for which the rule is valid.
g. Click Enable URL Rule.
h. Click Submit.
In this example, we use the following values:
Rule-List ID Rule ID
myurllist 1
b. Select the virtual service from the displayed list. If the virtual service is not listed, click
to add an entry. The relevant Add tab displays.
c. In the Virtual Services tab, select the virtual service from the list. If the virtual service is
not listed, click to add an entry. The relevant Add tab displays
d. In the Application field, select an option from the drop-down list.
e. In the HTTP tab, define the compression policy to use with this service.
f. In the Compression Policy field, select an option from the drop-down list. If the policy is
not listed, click to add an entry. The relevant Add tab displays.
g. Click Submit.
In this example, we use the following values:
The compression policy name you entered is now associated with virtual service HTTP.
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.
The following procedures are covered in this section:
Configuring the Compression Virtual Service, page 321
Compression Policy, page 322
Compression Exceptions Rule Lists, page 322
Common Compression Policy Use Cases, page 323
2. Select the virtual service from the displayed list. If the virtual service is not listed, click to
add an entry. The relevant Add tab displays.
3. In the Virtual Services tab, select the virtual service from the list. If the virtual service is not
listed, click to add an entry. The relevant Add tab displays
4. In the Application field, select an option from the drop-down list.
5. In the HTTP tab, define the compression policy to use with this service.
6. In the Compression Policy field, select an option from the drop-down list. If the policy is not
listed, click to add an entry. The relevant Add tab displays.
7. Click Submit.
In this example, we use the following values:
The compression policy name you entered is now associated with virtual service HTTP.
Compression Policy
A compression policy defines the compression behavior required for the virtual service to which it is
associated. A single compression policy can be associated to multiple virtual services if they share
the same compression configuration.
The maximum number of policies is 1024. The compression policy is identified by an alphanumeric
ID.
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, view more information at
Configuration > Application Delivery > Application Services > HTTP > Compression.
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.
Note: If you must set up a new policy, remember to click Enable Compression Policy to
ensure the new policy is functioning when you turn on global compression.
In this example, we use the following values:
Policy ID
myPol
b. Select the virtual service from the displayed list. If the virtual service is not listed, click
to add an entry. The relevant Add tab displays.
c. In the Virtual Services tab, select the virtual service from the list. If the virtual service is
not listed, click to add an entry. The relevant Add tab displays
d. In the Application field, select an option from the drop-down list.
e. In the HTTP tab, define the compression policy to use with this service.
f. In the Compression Policy field, select an option from the drop-down list. If the policy is
not listed, click to add an entry. The relevant Add tab displays.
g. Click Submit.
In this example, we use the following values:
6. Enable DAM or configure proxy IP addresses and enable proxy on the client port.
b. In the Policy table, click to add an entry. The relevant Add tab displays.
c. Click the Enable Compression Policy to enable the policy, once defined.
d. In the Policy ID field, type an ID for the new policy.
e. Click Submit.
In this example, we use the following values:
b. In the URL Exceptions Rule-List table, click to add an entry. The relevant Add tab
displays.
c. Click Enable URL Rule-List to enable the list, once defined.
d. In the URL Rule-List ID field, type an ID for the rule list.
e. In the Compression URL Exception Rules table, click to add an entry. The relevant Add
tab displays.
f. Click Enable Compression URL Rule to enable the list, once defined.
g. In the Rule ID field, enter a numeric ID for the new rule.
h. Click Submit.
4. Globally enable compression.
a. Select Configuration > Application Delivery > HTTP > Compression.
b. Click Enable Compression.
5. Set the HTTP virtual service to used in the defined virtual server.
a. Select Configuration > Application Delivery > Virtual Services.
b. Select the virtual service from the displayed list. If the virtual service is not listed, click
to add an entry. The relevant Add tab displays.
c. In the Virtual Services tab, select the virtual service from the list. If the virtual service is
not listed, click to add an entry. The relevant Add tab displays
d. In the Application field, select an option from the drop-down list.
e. In the HTTP tab, define the compression policy to use with this service.
f. In the Compression Policy field, select an option from the drop-down list. If the policy is
not listed, click to add an entry. The relevant Add tab displays.
g. Click Submit.
In this example, we use the following values:
6. Enable DAM or configure proxy IP addresses and enable proxy on the client port.
Enable SLB.
Define server port and client port.
Define virtual server
2. Define the caching policy which will govern the caching behavior, as follows:
a. Select Configuration > Application Delivery > Compression > URL Exceptions Rule-
List.
b. In the Policy table, click to add an entry. The relevant Add tab displays.
c. Click the Enable Compression Policy to enable the policy, once defined.
d. In the Policy ID field, type an ID for the new policy.
e. In the Items to Compress tab, define the compression browser rule list to use with this
policy.
f. In the Compression Browser Rule List, select an existing rule list to use or click to
add a new rule list. The relevant Add tab displays.
g. Click Submit.
In this example, we use the following values:
b. In the Browser Exceptions Rule-List table, click to add an entry. The relevant Add tab
displays.
c. Click Enable Browser Rule-List to enable the rule, once it is defined.
d. In the Browser Rule-List ID field, type an alphanumeric ID for the rule.
e. In the Compression Browser Exceptions Rules tab, define the additional rules to use for this
rule list.
f. In the Compression Browser Exceptions Rules table, select the rule to use with this rule. If
the rule is not listed, click to add an entry. The relevant Add tab displays.
g. In the Rule ID field, type an identifier for the rule.
h. Click Submit.
b. Select the virtual service from the displayed list. If the virtual service is not listed, click
to add an entry. The relevant Add tab displays.
c. In the Virtual Services tab, select the virtual service from the list. If the virtual service is
not listed, click to add an entry. The relevant Add tab displays
To enable connection management for the HTTP and HTTPS protocol on a virtual server
1. Select Configuration > Application Delivery > Virtual Services.
2. In the Virtual Services table, select a virtual service. If the virtual service is not listed, click
to add an entry. The relevant Add tab displays.
3. In the Virtual Server ID field, type an alphanumeric ID for the virtual server.
4. In the Virtual Services tab, click to add an entry. The relevant Add tab displays.
5. In the Application field, select an option from the drop-down list.
6. In the Service Port field, type the port to use for this service.
7. In the Group ID field, select the group from the drop-down list.
8. In the HTTP tab, define the connection management to use with this virtual service.
9. In the Server Connection Management field, select an option from the drop-down list.
Note: You must configure the Proxy IP (PIP) addresses to be used as source IP addresses for the
server-side connections. Radware recommends that you use 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: A FastView license must be installed and resources allocated before Web acceleration can be
enabled.
FastView Provisioning
FastView capabilities are supported on Alteon operating in virtualized mode (ADC-VX), and on
Alteon VA for VMWare.
To provision FastView
1. Install a FastView license on Alteon.
2. For ADC-VX users, the following must be set at vADC creation:
Capacity limit for FastView Pages per Second must be defined on the vADC.
Capacity Units (CUs) must be allocated on the vADC for FastView Offline Processing
(minimum 2 CUs, maximum is 8). The FastView Offline Processing CUs are used by the
smart optimization engine.
Note: For more information regarding FastView for Alteon configuration and operation, refer to the
FastView for Alteon NG User Guide.
Server PUSH
Server PUSH is an HTTP/2 protocol capability that lets the server push a resource to a client without
the client asking for the resource. This is a unique behavior that lets the server initiate data transfer
to the client to improve page load time. Using FastView, HTTP/2 PUSH is used to send resources to
newcomers to the site for best landing page experience. This behavior is fully automated, and no
manual PUSH lists are required.
This is a FastView treatment that is available only for HTTP/2 treatment sets.
HTTP/2 Gateway
The Internet world has changed dramatically since HTTP 1.1 was first introduced. There has been a
meteoric increase in the number of clients over the Web, and Web pages have become significantly
more complex, introducing new performance and security challenges. These challenges have
multiplied as Web sites need to support a growing range of devices (such as mobile devices) which
have limited compute and memory resources compared to desktops.
HTTP/2 is the next major version of the HTTP network protocol. Its main goal is to improve Web
page load time and latency, without compromising security.
The latest versions of most Web browsers support HTTP/2, which is enabled by default. To gain the
performance improvement value of HTTP/2 without changing your back-end systems, Alteon
provides a high speed gateway from HTTP/2 to HTTP/1. Your back-end system can remain intact
while any browsers that are HTTP/2-ready can benefit from HTTP/2 right away.
The following diagram describes the topology for the HTTP/2 Gateway:
HTTP/2 gateway configuration is very easy: you associate an HTTP/2 policy to your HTTPS service.
You can monitor and view various statistics about HTTP/2 usage and behavior.
For information on how to configure FastView HTTP/2 treatment sets, see the FastView for Alteon NG
User Guide.
Notes
The HTTP/2 Gateway is for Alteon virtual services (not for filters).
To benefit the most from the single optimized TCP connection between client and server with
HTTP/2:
Alteon should be the HTTP/2 terminating device. It is best if the long haul is between the
client side of the connection and Alteon.
It is best that a service use a single front-end IP address. A service that uses multiple
front-end IP addresses (for example for www.site.com and for anotherdomain.site.com, for
different resources or a different part of the page) would require multiple connection
establishments.
Radware recommends that you use HTTP/2 in conjunction with multiplexing to back-end servers,
compression, and caching. To add acceleration value, work with FastView to best leverage HTTP/
2 FastView PUSH. FastView PUSH support is included both with FastView and with FastView+ for
Alteon NG. For more information on PUSH support, see Server PUSH, page 329.
HTTP/2 can be used only for HTTPS services:
The HTTP/2 Gateway must be used in conjunction with TLS 1.2.
To use GCM, the SSL Policy configuration must have http/2 as the selected Cipher Suite.
Radware recommends for HTTP/2 services that you set Configuration > Virtual Services
> Edit Virtual Service > HTTP > Server Connections Management either to
Multiplexing, or if client IP visibility is required on the servers, to Transparent for HTTP/
2 Gateway.
HTTP/2 implies that the site is available and used over SSL. If your site is currently using clear
text HTTP, you may benefit from the following Alteon capabilities for the transition to HTTPS:
Make sure that the SSL Policy Convert parameter is set to Enabled.
Add header modification for front-end-SSL to indicate to the back-end system to use links to
HTTPS.
The HTTP/2 Gateway currently uses software-based SSL offload only.
The HTTP/2 Gateway is currently not supported in conjunction with AppShape++ or APM.
The HTTP/2 Gateway is currently not supported in conjunction with Pass SSL Info to back-end
servers and with Pass Client Authentication Information to back-end servers.
The Alteon APM module provides visibility into the application performance and the actual quality of
experience (QoE) end-users are experiencing.
Alteon APM provides the following key values:
Complete visibility of Web application performance and real-user experience, managing and
tracking user-defined SLAs
Fast Root Cause Analysis using highly granular measurement, in real time
Monitoring of actual user traffic, with no dedicated scripts per Web application, lowering costs
For more details on the Application Performance Monitoring capabilities, see the APSolute Vision
User Guide.
Note: When you have an APM license for 1000 PgPm, for example, it means that only 1000 HTML
pages per minutes are monitored out of the total traffic. It does not have an impact on the amount
of transactions or even PgPm load balanced.
Prerequisites
To activate and support APM functionality on HTTP/HTTPS services, the following are required:
An APM server must be installed. For more information, see the APSolute Vision Installation
Guide.
Configure and apply an APM server on your Alteon platform. You must apply the APM server
configuration to activate APM on services.
Enable APM on desired HTTP or HTTPS services.
An APM license must be installed on the Alteon platform. The APM license defines the maximum
number of pages per minute that can be used for APM data gathering. By default, 10 pages per
minute are always available. For higher capacity, an early APM subscription should be
purchased. For more information, see the Alteon Maintenance and Installation Guide.
The traffic that Alteon receives must be HTTP or HTTPS.
The traffic that Alteon receives must be clear text. APM cannot work with traffic that another
network element has compressed or encrypted. To support APM functionality for compressed
traffic, Alteon must compress the traffic using a compression policy on the virtual service.
AppShape++ Priority number 16 must be reserved for the APM AppShape++ script. The
AppShape++ Priority parameter determines the order in which the AppShape++ script runs
relative to the other AppShape++ scripts that are associated with the virtual service.
The virtual server on which the virtual service runs must be configured with IPv4.
In the configuration of the virtual service, set the real server port to 0 or the same value as the
APM server port.
On an HTTPS virtual service with back-end SSL traffic:
You must configure the SSL parameters (server certificate type, server certificate, and SSL
policy) on the virtual service.
The server certificate must be of type certificate.
In the configuration of the SSL policy, enable back-end SSL encryption.
You cannot edit or delete these objects. You can delete the APM server to remove these objects.
Note: When Alteon platforms are managed via APSolute Vision, the connection details of the APM
server should also be configured in the APSolute Vision Asset Management perspective.
Note: If the virtual server ID includes a hyphen (-), a service activation error displays when you
try to enable APM server on Alteon.
If the same virtual server ID is used in multiple devices, the APM data for all these services is
aggregated by the APM server as a single application domain.
If service activation is successful, after Apply a predefined AppShape++ script, called APM_Script,
is attached to the virtual service, with priority 16. This script redirects the HTTP requests that
contain report beacons to the APM server. This script cannot be edited or deleted. If APM is disabled
on the service, after Apply the AppShape++ APM_Script is removed from the virtual service.
AppShape++ script priority 16 must be empty on the service before enabling APM, otherwise APM
activation fails.
For additional information on SLB commands, refer to the Alteon Command Line Interface Reference
Guide.
2. In the Virtual Servers table, click to add an entry. The relevant Add tab displays.
3. In the Virtual Server ID field, type the ID for the virtual server.
4. In the IP Address field, type the IP address.
5. Select Virtual Services.
6. In the Virtual Services table, click to add an entry. The relevant Add tab displays.
7. In the Application field, select IP from the drop-down list.
8. In the Group ID field, select the group in the drop-down list.
9. Select Advanced.
10. In the Session Mode field, select Client IP.
11. Click Submit.
Note: The session that is created for the IP service ages based on setting for real server timeout.
Select a table row and click to edit an entry. The relevant Edit tab displays.
Alternatively, you can double-click the table row you want to edit.
3. Select Enable TCP Optimization Policy.
4. In the Description field, type a description of up to 32 characters for this policy.
5. From the Congestion Control Mechanism drop-down list, select one of the following
algorithms to prevent network congestion:
Reno
Hybla
Hybla+Pacing
The default value is Hybla+Pacing.
6. In the Receive Buffer Size and Send Buffer Size options, set the Application Services Engine
TCP buffer size in bytes. You can increase the buffer to allow more data to accumulate in the
Application Services Engine before forwarding. The buffer size is advertised to Alteon clients and
servers, and controls their ability to send and receive data.
The default value is 256K.
7. From the Maximum Segment Size drop-down list, select the maximum segment size, in bytes,
to be used over the TCP connection.
The TCP protocol includes a mechanism for both ends of a connection to advertise the maximum
segment size to be used over the connection when the connection is created.
Each end uses the OPTIONS field in the TCP header to advertise a proposed maximum segment
size. Alteon uses the smaller of the values provided by the two ends. The other party does not
necessarily have to use this value.
Note: It is more efficient to send the largest possible packet size to ensure maximum
bandwidth on the network. However, to avoid fragmentation, a host must specify the maximum
segment size as equal to the largest datagram available for all other networks between the end
points.
The default value is DefaultThe advertised maximum segment size is calculated using the
Path MTU Discovery mechanism. Initial maximum segment size is 1460 bytes, but because the
mechanism can detect smaller MTU values on the path, the maximum segment size can be
smaller than 1460. In most cases, the maximum segment size will effectively be 1460.
8. (Optional) Set Selective Acknowledgement to Enable to improve system performance by
processing data using selective ACK messages.
The default value is Enable.
9. (Optional) Set Adaptive Tuning to Enable to limit the use of the proxy server memory to
prevent overloading by resizing the TCP buffers according to RAM usage.
The default value is Enable.
10. Click Submit.
Note: You can add a TCP optimization policy only to a TCP service that supports delayed binding in
force proxy mode.
3. In the Virtual Services of Selected Virtual Server table, select an entry and click , or double-
click the entry you want to edit. The relevant Edit tab displays.
4. Select the TCP Optimization tab.
5. From the Frontend TCP Optimization Policy drop-down list, select the TCP optimization
policy for the client side of the flow.
6. From the Backend TCP Optimization Policy drop-down list, select the TCP optimization policy
for the server side of the flow.
7. Click Submit.
Note: You can add a TCP optimization policy only to a redirection filter that supports delayed
binding in force proxy mode.
2. In the Filters table, select an entry and click , or double-click the entry you want to edit. The
relevant Edit tab displays.
3. Select the TCP Optimization tab.
4. From the Frontend TCP Optimization Policy drop-down list, select the TCP optimization
policy for the client side of the flow.
5. From the Backend TCP Optimization Policy drop-down list, select the TCP optimization policy
for the server side of the flow.
6. Click Submit.
Note: In a DSR environment, with Passive FTP you must enable FTP parsing (FTPP) to ensure
that responses pass through the Alteon platform.
Alteon supports both active and passive FTP operation modes. You can switch from active to passive,
or vice versa, in the same FTP session.
FTP Configuration
To create an active FTP configuration, enable both the FTP and FTP data services on the virtual
server. If there is no proxy defined on the client port or VLAN, you do not have to enable the FTP
data service.
To create a passive FTP configuration, enable both the FTP and FTP data services on the virtual
server.
2. In the Virtual Services table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
3. Select the Virtual Services tab.
4. In the Virtual Services table, click to add an entry. The relevant Add tab displays.
5. In the Application field, select FTP from the drop-down list.
6. In the Service Port field, type the port number.
7. In the Group ID field, select the group ID from the drop-down list.
8. Click Submit.
9. Repeat step 4 to step 8 to configure the FTP data services on the virtual server.
Application
FTP, FTP-Data
2. In the Virtual Services table, select an entry and click , or double-click the entry to edit. The
relevant Edit tab displays.
3. Select the Virtual Services tab.
4. In the Virtual Services table, select an entry and click PIX, or double-click the entry to edit. The
relevant Edit tab displays.
5. Select the FTP tab.
Requirements
You must select or enable the following:
load balancing service port 69
DAM
b. In the Virtual Services table, select an entry and click , or double-click an entry to edit it.
The relevant Edit tab displays.
c. Select the Virtual Service tab.
d. In the Virtual Services table, click to add an entry. The relevant Add tab displays.
To enable a session reset for a virtual server that is running the LDAP service
1. Select Configuration > Application Delivery > Virtual Settings.
2. In the Virtual Services table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
3. Select the Virtual Services tab.
4. In the Virtual Services table, select an LDAP entry and click , or double-click the entry you
want to edit. The relevant Edit tab displays.
5. Select the LDAP tab.
6. In the Send REST on Aging field, select Enable from the drop-down list.
7. Click Submit.
Figure 40 - LDAP Load Balancing, page 342 shows four LDAP servers load balancing LDAP queries:
b. In the Real Servers table, click to add an entry. The relevant Add tab displays.
c. In the Real Server ID field, type the server ID number.
d. In the Server IP Address field, type the servers IP address.
e. Select the Layer 7 String Based Server Selection tab.
f. In the LDAP Server Type field, select Read-Write.
g. Repeat step 1 until all servers are configured.
In this example, we use the following values:
b. In the Server Groups table, click to add an entry. The relevant Add tab displays.
c. In the Server Group ID field, type the server group ID number.
d. Select the Real Servers tab.
e. In the Real Servers tab, select the real server and click the arrows to move the server
between the Available and Selected lists. Repeat until all real servers are added to the
server group.
f. Select the Group Settings tab.
g. In the SLB Metric field, select Round Robin from the drop-down list.
h. Click Submit.
In this example, we use the following values:
b. In the Virtual Servers table, click to add an entry. The relevant Add tab displays.
c. In the Virtual Server ID field, type the server ID number.
d. In the IP Address field, type the IP address for the virtual server.
e. Select the Virtual Services tab.
f. In the Virtual Services table, click to add an entry. The relevant Add tab displays.
g. In the Application field, select LDAP from the drop-down list.
h. In the Group ID field, select the group from the drop-down list.
i. Click Submit.
In this example, we use the following values:
b. In the Virtual Servers table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. Select the Virtual Services tab.
d. In the Virtual Services table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
e. In the Application field, select LDAP from the drop-down list.
f. In the Group ID field, select the group from the drop-down list.
g. Select the LDAP tab.
h. In the Send RST on Aging field, select Enable from the drop-down list.
i. Click Submit.
Note: You can configure both UDP and TCP DNS queries for the same virtual server IP address.
Preconfiguration Tasks
This procedure references Figure 41 - Layer 4 DNS Load Balancing, page 344.
b. In the Real Servers table, click to add an entry. The relevant Add tab displays.
c. In the Real Server ID field, type the server ID number.
d. In the Server IP Address field, type the servers IP address.
e. Repeat step 1 until all servers are configured.
In this example, we use the following values:
b. In the Server Groups table, click to add an entry. The relevant Add tab displays.
c. In the Server Group ID field, type the server group ID number.
d. Select the Real Servers tab.
e. In the Real Servers tab, select the real server and click the arrows to move the server
between the Available and Selected lists. Repeat until all real servers are added to the
server group.
f. Select the Group Settings tab.
g. In the SLB Metric field, select Round Robin from the drop-down list.
h. In the Health Check field, select the health setting from the drop-down list.
i. Click Submit.
j. Repeat step 2 until all groups are configured.
In this example, we use the following values:
2. In the Virtual Servers table, click to add an entry. The relevant Add tab displays.
3. In the Virtual Server ID field, type the server ID number.
4. In the IP Address field, type the IP address.
5. Select the Virtual Services tab.
6. In the Virtual Services table, click to add an entry. The relevant Add tab displays.
7. In the Application field, select DNS from the drop-down list.
8. In the Protocol field, select UDP from the drop-down list.
9. In the Group ID field, select the group from the drop-down list.
10. Select the Properties tab.
11. In the Delayed Binding field, select Disable.
2. In the Virtual Servers table, click to add an entry. The relevant Add tab displays.
3. In the Virtual Server ID field, type the server ID number.
4. In the IP Address field, type the IP address.
5. Select the Virtual Services tab.
6. In the Virtual Services table, click to add an entry. The relevant Add tab displays.
7. In the Application field, select DNS from the drop-down list.
8. In the Protocol field, select UDP from the drop-down list.
9. In the Group ID field, select the group from the drop-down list.
10. Click Submit.
In this example, we use the following values:
Server 3 is an old DNS server not supporting DNSSEC queries and answers DNS queries of types
MX, AAAA and A for all hostnames.
Server 4 supports only DNSSEC queries and answers DNS types A, AAAA, MX and DNSKEY for all
hostnames.
b. In the Virtual Servers table, click to add an entry. The relevant Add tab displays.
c. In the Virtual Server ID field, type the server ID number.
e. In the Virtual Services table, click to add an entry. The relevant Add tab displays.
f. In the Application field, select DNS from the drop-down list.
g. In the Protocol field, select UDP from the drop-down list.
h. Select the Properties tab.
i. In the Delayed Binding field, select Disable.
j. Select the DNS tab.
k. In the DNS Type field, select DNS Only from the drop-down list.
l. Click Submit.
In this example, we use the following values:
b. In the Layer 7 Strings table, click to add an entry. The relevant Add tab displays.
c. In the Application field, select DNS.
d. In the DNS Type field, select ANY.
e. In the Hostname field, type the text string.
f. Click Submit.
In this example, we use the following values:
b. In the Layer 7 Strings table, click to add an entry. The relevant Add tab displays.
c. In the Application field, select DNS.
d. In the DNS Type field, select ANY.
e. In the Hostname field, type the text string.
f. Click Submit.
In this example, we use the following values:
b. In the Real Servers table, select an entry and click , or double-click the enter you want to
edit. The relevant Edit tab displays.
c. Select the Layer 7 Match Conditions tab.
d. In the Layer 7 String Based Server Selection tab, select a string and use the arrows to move
the string between the Available and Selected lists. Repeat until all required strings are
selected.
e. Click Submit.
In this example, we use the following values:
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: Alteon does not respond to DNS queries on a service with action set to redirect. To enable
Alteon to respond to DNS queries, set the first metric in the DNS rule attached to the virtual server
to Network, and add the virtual server and relevant remote servers, as follows:
h. In the Virtual Servers table, click to add a virtual server to the network.
From the Virtual Server ID drop-down list, select the server to add to the network.
In the Preference field, type a preference value for the virtual server.
Valid values are in the range 165535.
The default value is 65535.
Click Submit.
i. In the Real Servers table, click to add a real server to the network.
From the Real Server ID drop-down list, select the server to add to the network.
In the Preference field, type a preference value for the real server.
Valid values are in the range 165535.
The default value is 65535.
Click Submit.
In this example, we use the following values:
2. Define a new rule that will make the new network active.
a. Select Configuration > Application Delivery > Global Traffic Redirection > DNS
Redirection Rules.
j. In the DNS Redirection Metrics table, select Metric Index 1 and click , or double-click the
entry. The relevant Edit tab displays
k. Set the Metric Type drop-down list to Network.
l. In the Client Network Rule table, select the rules that you want to add to the metric and use
the arrows to move the contracts between the Available and Selected lists.
m. Click Submit.
In this example, we use the following values:
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.
The RTSP stream setup sequence is different for these two servers, and Alteon handles each
differently:
Real ServerReal Server from RealNetworks Corporation supports both UDP and TCP transport
protocols for the RTSP streams. The actual transport is negotiated during the initialization of the
connection. If TCP transport is selected, then all streams of data flow in the TCP control
connection itself. If UDP transport is chosen, the client and server negotiate a client UDP port,
which is manually configurable.
The real media files that the Real Server plays have the extension .rm, .ram or .smil.
QuickTime Streaming ServerQuickTime Streaming Server from Apple Incorporated
supports a QuickTime presentation that typically has two streams and therefore uses four UDP
connections exclusively for transport and one TCP control connection. QuickTime clients use a
UDP port, which is manually configurable. The QuickTime files have the extension .mov.
Alteon can also support other RTSP-compliant applications such as Microsoft Windows Media Server
9.
2. In the Virtual Services table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
3. Select the Virtual Services tab.
4. In the Virtual Services tab, click to add an entry. The relevant Add tab displays.
5. In the Application field, select RTSP from the drop-down list.
6. In the Service Port field, type the non-standard port number.
7. Select the RTSP tab.
8. In the URL Load Balancing Mode field, select URL Hash from the drop-down list.
9. Click Submit.
In this example, we use the following values:
b. In the Real Servers table, click to add an entry. The relevant Add tab displays.
c. In the Real Server ID field, type the server ID number.
d. In the Server IP Address field, type the servers IP address.
e. Repeat this step until all servers are configured.
In this example, we use the following values:
b. In the Server Groups table, click to add an entry. The relevant Add tab displays.
c. In the Server Group ID field, type the group ID number.
d. Select the Real Servers tab.
e. In the Real Servers tab, select the real server and use the arrows to move the server
between the Available and Selected lists. Repeat this step until all real servers are
selected.
In this example, we use the following values:
b. In the Server Groups table, click to add an entry. The relevant Add tab displays.
c. In the Server Group ID field, type the group ID number.
d. Select the Real Servers tab.
e. In the Real Servers tab, select the real server and use the arrows to move the server
between the Available and Selected lists. Repeat this step until all real servers are
selected.
In this example, we use the following values:
b. In the Virtual Servers table, click to add an entry. The relevant Add tab displays.
f. In the Virtual Services table, click to add an entry. The relevant Add tab displays.
g. In the Application field, select RTSP from the drop-down list.
h. In the Service Port field, type the port number.
i. In the Group ID field, select the group from the drop-down list.
j. Click Submit.
In this example, we use the following values:
b. In the Virtual Servers table, click to add an entry. The relevant Add tab displays.
c. In the Virtual Server ID field, type the server ID number.
d. In the IP Address field, type the virtual server IP address.
e. Select the Virtual Services tab.
f. In the Virtual Services table, click to add an entry. The relevant Add tab displays.
g. In the Application field, select RTSP from the drop-down list.
h. In the Service Port field, type the port number.
i. In the Group ID field, select the group from the drop-down list.
j. Click Submit.
In this example, we use the following values:
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 Server1 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.
b. In the Real Servers table, click to add an entry. The relevant Add tab displays.
c. In the Real Server ID field, type the server ID number.
d. In the Server IP Address field, type the servers IP address.
e. Repeat this step until all servers are configured.
In this example, we use the following values:
b. In the Server Groups table, click to add an entry. The relevant Add tab displays.
c. In the Server Group ID field, type the group ID number.
d. Select the Real Servers tab.
e. In the Real Servers tab, select the real server and use the arrows to move the server
between the Available and Selected lists. Repeat this step until all real servers are
selected.
In this example, we use the following values:
b. In the Server Groups table, click to add an entry. The relevant Add tab displays.
c. In the Server Group ID field, type the group ID number.
d. Select the Real Servers tab.
e. In the Real Servers tab, select the real server and use the arrows to move the server
between the Available and Selected lists. Repeat this step until all real servers are
selected.
In this example, we use the following values:
b. In the Virtual Servers table, click to add an entry. The relevant Add tab displays.
c. In the Virtual Server ID field, type the server ID number.
d. In the IP Address field, type the virtual server IP address.
e. Select the Virtual Services tab.
f. In the Virtual Services table, click to add an entry. The relevant Add tab displays.
g. In the Application field, select RTSP from the drop-down list.
b. In the Virtual Servers table, click to add an entry. The relevant Add tab displays.
c. In the Virtual Server ID field, type the server ID number.
d. In the IP Address field, type the virtual server IP address.
e. Select the Virtual Services tab.
f. In the Virtual Services table, click to add an entry. The relevant Add tab displays.
g. In the Application field, select RTSP from the drop-down list.
h. In the Service Port field, type the port number.
i. In the Group ID field, select the group from the drop-down list.
j. Select the RTSP tab.
k. In the URL Load Balancing Mode field, select URL Pattern Match from the drop-down
list.
l. Click Submit.
In this example, we use the following values:
b. In the Layer 7 Strings table, click to add an entry. The relevant Add tab displays.
c. In the String field, type the search string to use.
d. Click Submit.
e. Repeat until all strings are configured.
In this example, we use the following values:
String ID String
1 any
2 server1.mov
3 server2.mov
b. In the Real Servers table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
c. Select the Layer 7 String Based Server Selection tab.
d. Select the string ID and use the arrows to move the string ID between the Available and
Selected lists. Repeat until all strings are selected.
In this example, we use the following values:
2. In the Virtual Services table, select the service and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
3. In the Application field, select SSL from the drop-down list.
4. Select the SSL tab.
5. In the SSL Policy field, do one of the following:
2. In the Virtual Services table, select the service and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
3. In the Application field, select SSL from the drop-down list.
4. Select the SSL tab.
5. In the Server Certificate field, select the certificate from the drop-down list.
6. Click Submit.
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.
You can configure Alteon to select a WAP gateway for each client request based on one of the
following three methods:
WAP Server Load Balancing with RADIUS Static Session Entries, page 363
WAP Server Load Balancing with RADIUS Snooping, page 364
WAP Server Load Balancing with RADIUS/WAP Persistence, page 367
How WAP Server Load Balancing Works with Static Session Entries
The WAP SLB workflow is as follows:
1. On dialing, the user is first authenticated by the Remote Access Server (RAS).
2. The RAS sends a RADIUS authentication request to one of the RADIUS servers, which can be
integrated with a WAP gateway.
3. If the user is accepted, the RADIUS server determines which WAP gateway is right for this user
and informs Alteon of the decision via TPCP.
4. Alteon receives a request from the RADIUS server, and adds a session entry to its session table
to bind a WAP gateway with that user.
5. A response packet is sent back to the RAS by the RADIUS server.
6. The RAS receives the packet and allows the WAP traffic for that user.
7. If the user disconnects, the RAS detects it and sends this information to the RADIUS server.
8. The RADIUS server removes the session entry for that user.
b. In the Real Servers table, click to add an entry. The relevant Add tab displays.
c. In the Real Server ID field, type the server ID number.
d. In the Server IP Address field, type the servers IP address.
e. Repeat this step until all servers are configured.
In this example, we use the following values:
b. In the Server Groups table, click to add an entry. The relevant Add tab displays.
c. In the Server Group ID field, type the group ID number.
d. Select the Real Servers tab.
e. In the Real Servers tab, select the real server and use the arrows to move the server
between the Available and Selected lists. Repeat this step until all real servers are
selected.
In this example, we use the following values:
3. Configure TPCP for external notification from the WAP gateway to add and delete session
requests if you are using static session.
a. Select Configuration > Application Delivery > Virtual Services > Settings.
b. Select the WAP tab.
c. In the Transparent Proxy Cache Protocol field, select Enable from the drop-down list.
d. Click Submit.
4. Configure TPCP for adding and deleting WAP sessions.
a. Select Configuration > Application Delivery > Virtual Services > Settings.
b. Select the Server Initiated Connections tab.
c. In the Transparent Proxy Cache Protocol field, select Enable from the drop-down list.
d. Click Submit.
When the client ends the WAP connection, the RAS sends an RADIUS Accounting Stop packet. If
Alteon finds the needed information in a RADIUS Accounting Stop packet, it removes the
corresponding session entry from its table.
The following steps occur when using RADIUS snooping:
1. The user is authenticated on dialing.
2. The RAS establishes a session with the client and sends a RADIUS Accounting Start message
with the client IP address to the RADIUS server.
3. Alteon snoops on the RADIUS accounting packet and adds a session entry if it finds enough
information in the packet.
4. Alteon load balances the WAP traffic to a specific WAP gateway.
5. When the client terminates the session, the RAS sends an Accounting Stop message to the
RADIUS server, and the session entry is deleted from Alteon.
Review the following guidelines before configuring RADIUS snooping:
The same virtual server IP address must be used when load balancing both the RADIUS
accounting traffic and WAP traffic.
All the RADIUS servers must use the same UDP port for RADIUS accounting services.
Before a session entry is recorded on Alteon, WAP packets for a user can go to any of the real
WAP gateways.
If a session entry for a client cannot be added because of resource constraints, the subsequent
WAP packets for that client will not be load balanced correctly. The client will need to drop the
connection and then reconnect to the wireless service.
The persistence of a session cannot be maintained if the number of healthy real WAP gateways
changes during the session. For example, if a new WAP server comes into service or some of the
existing WAP servers are down, the number of healthy WAP gateway changes and, in this case,
the persistence for a user cannot be maintained.
Persistence cannot be maintained if the user moves from one ISP to another, or if the base of
the users session changes (that is, from CALLING_STATION_ID to USER_NAME, or vice versa).
For example, if a user moves out of a roaming area, it is possible that the users
CALLING_STATION_ID is not available in the RADIUS accounting packets. In such a case, Alteon
uses USER_NAME to choose a WAP server instead of CALLING_STATION_ID. As a result,
persistence cannot be maintained.
b. In the Real Servers table, click to add an entry. The relevant Add tab displays.
c. In the Real Server ID field, type the server ID number.
d. In the Server IP Address field, type the servers IP address.
e. Repeat this step until all servers are configured.
In this example, we use the following values:
b. In the Server Groups table, click to add an entry. The relevant Add tab displays.
c. In the Server Group ID field, type the group ID number.
d. Select the Real Servers tab.
e. In the Real Servers tab, select the real server and use the arrows to move the server
between the Available and Selected lists. Repeat this step until all real servers are
selected.
In this example, we use the following values:
3. Configure TPCP for external notification from the WAP gateway to add and delete session
requests if you are using static session.
a. Select Configuration > Application Delivery > Virtual Services > Settings.
b. Select the WAP tab.
c. In the Transparent Proxy Cache Protocol field, select Enable from the drop-down list.
d. Click Submit.
4. Configure TPCP for adding and deleting WAP sessions.
a. Select Configuration > Application Delivery > Virtual Services > Settings.
b. Select the Server Initiated Connections tab.
c. In the Transparent Proxy Cache Protocol field, select Enable from the drop-down list.
d. Click Submit.
5. Configure filters.
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the filter ID number.
d. In the Action field, select Redirect from the drop-down list.
e. In the Group ID field, select the group from the drop-down list.
f. Select the Match Settings tab.
g. In the Protocol field, select UDP from the drop-down list.
h. In the IP Address/Network field, type the destination IP address.
i. In the Mask/Prefix field, type the destination subnet mask.
j. In the Application Port/Range Start field, type the destination port number.
k. Select the Action Settings tab.
l. In the Real Server Port field, type the real server port number.
m. In the Load Balancing Capabilities section, select RADIUS Snooping.
n. Click Submit.
In this example, we use the following values:
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.
b. In the Real Servers table, click to add an entry. The relevant Add tab displays.
c. In the Real Server ID field, type the server ID number.
d. In the Server IP Address field, type the servers IP address.
e. Repeat this step until all servers are configured.
In this example, we use the following values:
b. In the Server Groups table, click to add an entry. The relevant Add tab displays.
c. In the Server Group ID field, type the group ID number.
d. Select the Real Servers tab.
e. In the Real Servers tab, select the real server and use the arrows to move the server
between the Available and Selected lists. Repeat this step until all real servers are
selected.
f. Select the Group Settings tab.
g. In the SLB Metric field, select Hash from the drop-down list.
h. Click Submit.
In this example, we use the following values:
b. In the Virtual Servers table, click to add an entry. The relevant Add tab displays.
c. In the Virtual Server ID field, type the server ID number.
d. In the IP Address field, type the IP address.
e. Select the Virtual Services tab.
f. In the Virtual Services table, click to add an entry. The relevant Add tab displays.
g. In the Service Port field, type a RADIUS/WAP port number.
The RADIUS service number specified on Alteon must match the service specified on the
server.
If the application is not recognized by the port, set the application as basic-slb.
h. In the Protocol field, select UDP from the drop-down list.
i. Click Submit.
b. In the Filters table, select an entry and click , or double-click the entry you want to edit.
The relevant Edit tab displays.
c. Select the Action Settings tab.
d. In the Load Balancing Capabilities section, select RADIUS/WAP Persistency.
e. Click Submit.
5. Configure filters.
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the filter ID number.
d. In the Action field, select Redirect from the drop-down list.
e. In the Group ID field, select the group from the drop-down list.
f. Select the Match Settings tab.
g. In the Protocol field, select UDP from the drop-down list.
h. In the IP Address/Network field, type the destination IP address.
i. In the Mask/Prefix field, type the destination subnet mask.
j. In the Application Port/Range Start field, type the destination port number.
k. Select the Action Settings tab.
l. In the Real Server Port field, type the real server port number.
m. In the Load Balancing Capabilities section, select RADIUS Snooping.
n. Click Submit.
In this example, we use the following values:
6. Configure TPCP for external notification from the WAP gateway to add and delete session
requests if you are using static session.
a. Select Configuration > Application Delivery > Virtual Services > Settings.
b. Select the WAP tab.
c. In the Transparent Proxy Cache Protocol field, select Enable from the drop-down list.
d. Click Submit.
Intrusion detection devices inspect every packet before it enters a network, looking for any signs of
an attack. The attacks are recorded and logged in an attempt to guard against future attacks and to
record the information about the intruders.
IDS SLB helps scale intrusion detection systems since it is not possible for an individual server to
scale information being processed at Gigabit speeds.
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 376.
If the port is configured for client processing only, then Alteon hashes on the source IP address
only.
Figure 46: 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.
b. In the Real Servers table, click to add an entry. The relevant Add tab displays.
c. In the Real Server ID field, type the server ID number.
d. In the Server IP Address field, type the IP address for the server.
e. Select Enable Real Server.
f. Click Submit.
In this example, we use the following values:
3. Configure a group and add the IDS servers. The group must be numbered between 1 and 63.
a. Select Configuration > Application Delivery > Server Resources > Server Groups.
b. In the Server Groups table, click to add an entry. The relevant Add tab displays.
c. In the Server Group ID field, type the group ID number.
d. In the Real Servers tab, select the real server and use the arrows to move the server
between the Available and Selected lists. Repeat until all servers are selected.
e. Select the Group Settings tab.
f. In the SLB Metric field, select Hash from the drop-down list.
g. In the Health Check field, select link from the drop-down list.
h. Select the IDS tab.
i. In the IDS Group field, select Enable.
j. In the Mirror Traffic of Service Port field, type the port ID number IDS group.
k. Click Submit.
In this example, we use the following values:
Server Group Selected SLB Metric Health Check IDS Group Mirror Traffic
ID of Service
Port
50 6, 7 Hash link Enable 0 (any)
4. Configure IDSLB on each port. This enables frames ingressing the port to be copied to the IDS
servers.
a. Select Configuration > Application Delivery > Port Processing.
b. In the Port Processing table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. Select IDSLB.
d. Click Submit.
e. Repeat this step until all ports are configured.
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.
5. Configure an allow filter using the IDSHash metric.
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the filter ID number.
d. In the Action field, select Action from the drop-down list.
e. Select the IDS Load Balancing tab.
f. In the Hash Based Group Metrics field, select Source and Destination IP from the
drop-down list.
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.
g. Click Submit.
In this example, we use the following values:
b. In the Port Processing table, select an entry and click , or double-click the entry you want
edit. The relevant Edit tab displays.
c. Select Filter/Outbound LLB.
d. Select the filter and use the arrows to move the filter between the Available and Selected
lists.
e. Click Submit.
In this example, we use the following values:
Port Selected
25 2048
26 2048
27 2048
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.
7. Configure Alteon 2 to load balance the real servers as described in Server Load Balancing
Configuration Basics, page 211.
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 47: 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 persistence, 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.
b. In the Real Servers table, click to add an entry. The relevant Add tab displays.
c. In the Real Server ID field, type the server ID number.
d. In the Server IP Address field, type the IP address for the server.
e. Select Enable Real Server.
f. Click Submit.
In this example, we use the following values:
3. Configure a group and add the IDS servers. The group must be numbered between 1 and 63.
a. Select Configuration > Application Delivery > Server Resources > Server Groups.
b. In the Server Groups table, click to add an entry. The relevant Add tab displays.
c. In the Server Group ID field, type the group ID number.
d. In the Real Servers tab, select the real server and use the arrows to move the server
between the Available and Selected lists. Repeat until all servers are selected.
e. Select the Group Settings tab.
f. In the SLB Metric field, select Hash from the drop-down list.
g. In the Health Check field, select link from the drop-down list.
h. Select the IDS tab.
i. In the IDS Group field, select Enable.
j. In the Mirror Traffic of Service Port field, type the port ID number IDS group.
k. Click Submit.
In this example, we use the following values:
Server Group Selected SLB Metric Health Check IDS Group Mirror Traffic
ID of Service
Port
51 6, 7 Hash icmp Enable (HTTP port)
52 8 Hash arp Enable 0 (any)
4. Configure IDSLB on each port. This enables frames ingressing the port to be copied to the IDS
servers.
a. Select Configuration > Application Delivery > Port Processing.
b. In the Port Processing table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. Select IDSLB.
d. Click Submit.
e. Repeat this step until all ports are configured.
In this example, we use the following values:
Port Selected
25, 2, 3, 4 IDSLB
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.
5. Configure an allow filter using the IDSHash metric.
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, click to add an entry. The relevant Add tab displays.
b. In the Port Processing table, select an entry and click , or double-click the entry you want
edit. The relevant Edit tab displays.
c. Select Filter/Outbound LLB.
d. Select the filter and use the arrows to move the filter between the Available and Selected
lists.
e. Click Submit.
In this example, we use the following values:
Port Selected
2 2048
3 2048
4 2048
25 2048
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.
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.
7. Configure Alteon to load balance the real servers as described in Server Load Balancing
Configuration Basics, page 211.
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 48: Server Load Balancing and IDS Load Balancing Across Multiple Alteon Platforms
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.
3. Configure VLANs. Disable source MAC address learning only on the IDS VLANs.
The following VLANS are configured on Alteon:
VLAN 1For load balancing traffic to the real servers
VLAN 1000For performing SNMP health checks on Alteon 2
VLAN 1001For IDS Server 1
VLAN 1002For IDS Server 2
VLAN 1003For IDS Server 3
VLAN 1004For IDS Server 4
a. Select Configuration > Network > Layer 2 > VLAN.
b. In the VLAN table, click to add an entry. The relevant Add tab displays.
c. In the VLAN ID field, enter the ID number.
d. Select Enable VLAN.
e. Select the VLAN Settings tab.
f. In the VLAN Settings tab, select a port and use the arrows to move the port between the
Available and Selected lists. Repeat until all ports are selected for the VLAN.
g. In the Source MAC Learning field, select Disabled.
h. Click Submit.
i. Repeat until all VLANs are configured.
In this example, we use the following the values:
VLAN ID Ports
1
1000
1001 25, 26
1002 25, 26
1003 25, 26
1004 25, 26
4. Configure an IP interface for the SNMP health check to the other Alteon.
a. Select Configuration > Network > Layer 3 > IP Interfaces.
b. In the IP Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the interface ID number.
d. In the IP Address field, type the IP address.
e. In the Mask field, type the subnet mask.
f. In the VLAN field, select the VLAN from the drop-down list.
g. Select Enable IP Interface.
h. Click Submit.
In this example, we use the following the values:
b. In the Real Servers table, click to add an entry. The relevant Add tab displays.
c. In the Real Server ID field, type the server ID number.
d. In the Server IP Address field, type the IP address for the server.
e. Select Enable Real Server.
f. Select the IDS tab.
g. In the VLAN field, type the IDS VLAN to set for this server.
h. In the Port field, type the port number.
i. Select the Advanced tab.
j. In the SNMP Health Check OID field, type the OID port number.
k. Click Submit.
l. Repeat until all real servers are configured.
In this example, we use the following values:
6. Configure a group and add the IDS servers. IDS group numbers must be between 1 to 8191.
a. Select Configuration > Application Delivery > Server Resources > Server Groups.
b. In the Server Groups table, click to add an entry. The relevant Add tab displays.
c. In the Server Group ID field, type the group ID number.
d. In the Real Servers tab, select the real server and use the arrows to move the server
between the Available and Selected lists. Repeat until all servers are selected.
e. Select the Group Settings tab.
f. In the SLB Metric field, select Hash from the drop-down list.
g. In the Health Check field, select snmp1 from the drop-down list.
h. Select the IDS tab.
i. In the IDS Group field, select Enable.
j. In the Mirror Traffic of Service Port field, type the port ID number IDS group.
k. Click Submit.
In this example, we use the following values:
Server Group Selected SLB Metric Health Check IDS Group Mirror Traffic
ID of Service
Port
23 1, 2, 3, 4 Hash snmp1 Enable 80
7. Configure IDSLB on each port. This enables frames ingressing the port to be copied to the IDS
servers.
a. Select Configuration > Application Delivery > Port Processing.
b. In the Port Processing table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. Select IDSLB.
d. Click Submit.
e. Repeat this step until all ports are configured.
In this example, we use the following values:
Port Selected
7, 8, 27, 28 IDSLB
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.
8. Configure an allow filter using the IDSHash metric.
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, click to add an entry. The relevant Add tab displays.
b. In the Port Processing table, select an entry and click , or double-click the entry you want
edit. The relevant Edit tab displays.
c. Select Filter/Outbound LLB.
d. Select the filter and use the arrows to move the filter between the Available and Selected
lists.
e. Click Submit.
In this example, we use the following values:
Port Selected
4 2048
7 2048
8 2048
27 2048
28 2048
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.
10. Configure Alteon 2 to load balance the real servers as described in Server Load Balancing
Configuration Basics, page 211.
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.
This feature load balances SIP proxy servers such as Nortel MCS (Multimedia Communications
Server) and TCP-based implementations like Microsoft OCS.
b. In the Real Servers table, click to add an entry. The relevant Add tab displays.
c. In the Real Server ID field, type the server ID number.
d. In the Server IP Address field, type the IP address for the server.
e. Select Enable Real Server.
f. Click Submit.
In this example, we use the following values:
3. Configure a group to load balance the SIP proxy servers. TCP-based SIP load balancing supports
all metrics. For example, set the metric to min misses.
a. Select Configuration > Application Delivery > Server Resources > Server Groups.
b. In the Server Groups table, click to add an entry. The relevant Add tab displays.
c. In the Server Group ID field, type the group ID number.
d. In the Real Servers tab, select the real server and use the arrows to move the server
between the Available and Selected lists. Repeat until all servers are selected.
b. In the Virtual Services table, click to add an entry. The relevant Add tab displays.
c. In the Virtual Server ID field, type the server ID number.
d. In the IP Address field, type the IP address.
e. Select Enable Virtual Server.
f. Click Submit.
g. Repeat until all services are configured for the virtual server.
In this example, we use the following values:
5. Configure SIP service 5060 and the SIP TLS service 5061 for Virtual Server 1.
a. Select Configuration > Application Delivery > Virtual Services.
b. In the Virtual Services table, select an entry and click , or double-click on the entry you
want to edit. The relevant Edit tab displays.
c. In the Virtual Services tab, click to add an entry. The relevant Add tab displays.
d. In the Service Port field, type the port number.
e. In the Group ID field, select the group from the drop-down list.
f. Click Submit.
g. Repeat until all services are configured for the virtual server.
In this example, we use the following values:
b. In the Real Server table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
c. Select the Properties tab.
d. In the Inactivity Timeout field, type the time in minutes.
e. Click Submit.
f. Repeat this step until all servers are configured.
Note: SIP sessions are quite long and data may be flowing while the signaling path is idle.
Radware recommends that you increase the real server session timeout value to 30 minutes
(default: 10 minutes) because Alteon resides in the signaling path.
In this example, we use the following values:
Inactivity Timeout
30
b. In the Virtual Services table, select an entry and click , or double-click on the entry you
want to edit. The relevant Edit tab displays.
c. In the Virtual Services tab, click to add an entry. The relevant Add tab displays.
d. In the Service Port field, type the port number.
e. In the Group ID field, select the group from the drop-down list.
f. Click Submit.
g. Repeat until all services are configured for the virtual server.
In this example, we use the following values:
b. In the Port Processing table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. Select Client and Server.
d. Click Submit.
e. Repeat until all ports are configured.
SIP is a text-based protocol with header lines preceding the content. Like HTTP, the first header line
has the method specification followed by the other header lines that specify other parameters like
Call-ID, and so on.
b. In the Real Servers table, click to add an entry. The relevant Add tab displays.
c. In the Real Server ID field, type the server ID number.
d. In the Server IP Address field, type the IP address for the server.
e. Select Enable Real Server.
f. Click Submit.
In this example, we use the following values:
3. Configure a group to load balance the SIP proxy servers. TCP-based SIP load balancing supports
all metrics. For example, set the metric to min misses.
a. Select Configuration > Application Delivery > Server Resources > Server Groups.
b. In the Server Groups table, click to add an entry. The relevant Add tab displays.
c. In the Server Group ID field, type the group ID number.
d. In the Real Servers tab, select the real server and use the arrows to move the server
between the Available and Selected lists. Repeat until all servers are selected.
e. Select the Group Settings tab.
f. In the SLB Metric field, select Min Misses from the drop-down list.
g. In the Health Check field, select sip from the drop-down list.
h. Click Submit.
In this example, we use the following values:
b. In the Virtual Services table, click to add an entry. The relevant Add tab displays.
c. In the Virtual Server ID field, type the server ID number.
d. In the IP Address field, type the IP address.
e. Select Enable Virtual Server.
f. Click Submit.
g. Repeat until all services are configured for the virtual server.
In this example, we use the following values:
b. In the Virtual Services table, select an entry and click , or double-click on the entry you
want to edit. The relevant Edit tab displays.
c. In the Virtual Services tab, click to add an entry. The relevant Add tab displays.
d. In the Service Port field, type the port number.
e. In the Protocol field, select UDP from the drop-down list.
f. In the Group ID field, select the group from the drop-down list.
g. Select the SIP tab.
h. In the SIP Load Balancing field, select Enable.
i. Select the Advanced tab.
j. In the Direct Access Mode field, select Enable.
k. Click Submit.
l. Repeat until all services are configured for the virtual server.
In this example, we use the following values:
b. In the Real Server table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
c. Select the Properties tab.
d. In the Inactivity Timeout field, type the time in minutes.
e. Click Submit.
f. Repeat this step until all servers are configured.
Note: SIP sessions are quite long and data may be flowing while the signaling path is idle.
Radware recommends that you increase the real server session timeout value to 30 minutes
(default: 10 minutes) because Alteon resides in the signaling path.
In this example, we use the following values:
Inactivity Timeout
30
b. In the Port Processing table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. Select Client and Server.
d. Click Submit.
e. Repeat until all ports are configured.
b. In the Virtual Servers table, select an entry and click , or double-click the entry you
want to edit. The relevant Edit tab displays.
c. In the Virtual Services table, select an entry and click , or double-click the entry you
want to edit. The relevant Edit tab displays.
b. In the Virtual Servers table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In the Virtual Services tab, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
d. Select the Properties tab.
e. In the Real Server Port, type the port number.
f. Click Submit.
2. Configure the health option for the group.
a. Select Configuration > Application Delivery > Server Resources > Server Groups.
b. In the Server Groups table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. Select the Group Settings tab.
d. In the Health Check field, select the health check from the drop-down list.
e. Click Submit.
b. In the Media Portal NAT tab, click to add an entry. The relevant Add tab displays.
c. In the Private IP Address field, type the private IP address.
d. In the Public IP Address field, type the public IP address.
e. Click Submit.
2. Configure SDP Media Portal NAT on a virtual server.
a. Select Configuration > Application Delivery > Virtual Services.
b. In the Virtual Servers table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In the Virtual Services tab, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
d. Select the SIP tab.
e. In the Media Portal NAT field, select Enable from the drop-down list.
f. Click Submit.
3. Create static NAT filters.
This allows RTP traffic destined for the public media portal address to be translated to the actual
private media portal address. Create static NAT filters to operate in both directions: one to
translate the public address to the private address, and one to translate the private address to
the public address.
For more information on static NAT filters, see Network Address Translation, page 461.
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.
Note: SoftGrid load balancing does not work with proxy IP addresses.
b. In the Virtual Servers table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In the Virtual Services tab, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays. The virtual service must use the RTSP application
option.
d. Select the RTSP tab.
e. In the SoftGrid Load Balancing field, select Enable from the drop-down list.
f. Click Submit.
If SoftGrid is enabled for an RTSP service, the SoftGrid RTSP mode performs the RTSP SLB for
that service.
b. In the Server Groups table, click to add an entry. The relevant Add tab displays.
c. In the Server Group ID field, type the server group ID number.
d. Select the Advanced tab.
e. In the Workload Manager ID field, type the WLM ID number.
f. Click Submit.
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.
ARP Health Checks, page 412Describes how to perform health checks on Intrusion
Detection Servers (IDS) that do not have full TCP/IP stack support.
RTSP Health Checks, page 413Describes how to perform RTSP health checks.
SIP Health Checks, page 413Describes how to perform SIP health checks for end-points
within an IP domain.
Script-Based Health Checks, page 414Describes 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 421Lists all available out-of-the-box health check
objects.
Failure Types, page 422Explains the service failed and server failed states.
Direct Server Return (DSR) Health Checks, page 424Describes 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 424Describes how to configure an expression to fine-
tune the selected health check for a real server group.
Disabling the Fast Link Health Check, page 425Describes how to disable fast link health
checks.
Notes
Before configuring a health check for a real server, assign the real server to a group that is
associated with a virtual server
When a group is not associated with any virtual server, Alteon performs an ICMP health check
for the real servers in that group, regardless of the health check configured for the real servers.
Alteon restarts health checks for all the real servers that are not associated to any virtual service
or filters, even when you perform an SLB configuration change that is not related to the real
server setting.
Destination portDefines the application port where the health check must be sent.
When the destination port is unspecified (default), the health check destination port is
determined by the server port used for each monitored service. When the destination
address is specified, the destination port must also be specified.
Note: The destination port parameter is not relevant for Link, ICMP, and ARP health checks.
Reverse health check resultWhen this parameter is enabled, if the health check behaves as
expected, it is considered failed.
Transparent health check
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 argumentsApplication 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 403.
Note: In most cases, real server 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.
Note: HTTPS health check initiates an SSL handshake using TLS 1.2.
The following HTTP/S specific arguments facilitate the configuration of accurate health checks:
HTTPSSpecifies whether to perform an HTTP (disabled) or HTTPS (enabled) health check.
HostSpecifies the host header to be used in the health check request (up to 128 characters).
If this parameter is not specified an HTTP 1.0 request is sent. Otherwise an HTTP 1.1 request is
sent. An Inherit value can be configured to allow the host definition per virtual service using the
virtual service Hostname parameter and the virtual server Domain Name parameter. See
Example HTTP Health Checks, page 406.
PathSpecifies the request path (up to 256 characters). If empty, the request is sent to the
Web service root (/). An Inherit value can be configured to allow the path configuration using
the group content. See Example HTTP Health Checks, page 406.
MethodSpecifies the HTTP method used in the request. The options are GET (default), POST,
and HEAD.
Additional headersSpecifies additional headers to be included in the health check HTTP
request.
BodySpecifies the HTTP body to be included in the health check HTTP request (up to 512
characters).
AuthenticationSpecifies whether the monitored server requires authentication. The options
are None, Basic (user and password), and NTLM (v2).
User name and passwordSpecifies the login user name and password if authentication is
required.
Proxy requestSpecifies whether to perform HTTP proxy health check. This means that the full
path URI is included in the GET/POST command (even in HTTP 1.1 where the host appears in
Host header).
Response codesSpecifies a list of up to 10 response codes that represent health check success
(or failure if a reverse check is performed). Default: 200
Return String and TypeSpecifies a string (up to 256 characters) expected in the response that
represents health check success (or failure if a reverse check is performed) and its match type
(included or regex).
Pre-defined http and https health checks are available for simple HTTP and HTTPS service
monitoring. The health checks have the host and path parameters set to Inherit (their definition is
taken from the virtual service and group configuration) and expect 200 OK response codes.
d. In the Virtual Services table, click to add an entry. The relevant Add tab displays.
e. Select the Properties tab.
f. In the Hostname field, define the virtual server hostname (maximum 34 characters).
2. Configure the domain name as follows:
a. Select Configuration > Application Delivery > Virtual Services.
Note: If content is not specified, the health check is performed using the / character.
Examples
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
Pre-defined udpdns (DNS over UDP) and dns (UDP over TCP) health checks are available for simple
DNS service monitoring. The domain parameter of the pre-defined health checks is set to Inherit,
allowing definition using the group content and the destination port set to standard DNS port (53).
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).
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 WeightSpecifies 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).
OID and community strings assigned to an IDS real server override the health check configuration.
Note: The Alteon FTP health check request allows you to configure both a user name name and
password to log in in the FTP server, but Alteon sends a FIN message instead of the password.
The FTP health check monitors an FTP service by attempting to log in to the server and retrieve the
specified file size.
The following FTP-specific arguments are available:
UsernameSpecifies the login user name to the FTP server (up to 32 characters). Default:
anonymous
PasswordSpecifies the login password for the configured username (up to 32 characters).
Path/FilenameSpecifies the name of the file to be downloaded (up to 256 characters). An
Inherit value can be configured to allow path/filename definition using the group content
parameter. If no filename is specified, the FTP health check only checks successful login to the
FTP server.
A pre-defined ftp health check is available for simple FTP service monitoring. The health check has
the username set to Anonymous and the path/filename parameter set to Inherit, allowing definition
using the group content and the destination port set to standard FTP control port (21).
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.
The following pre-defined RADIUS health checks are available:
radius-authRADIUS Authentication health check with username, password and shared secret
set to Inherit.
radius-accRADIUS Accounting health check with username, password empty and shared
secret set to Inherit.
radius-aaPerforms either a RADIUS Accounting or a RADIUS Authentication health check
based on the server port (rport) configured on the service. If the server port is not a standard
RADIUS port (1812 or 1813), a TCP health check is performed. For this health check, the
username, password and shared secret are set to Inherit.
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.
OffsetSpecifies the offset from which to start search for the Received Content in the UDP data.
RADIUS Service DependencySpecifies 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.
You can configure an Inherit value for Username, Password, and Base Distinguish Name arguments
to allow configuration using the group content. The group content includes all required parameters
in the LDAP message format: cn=<username>,dc=<base-part1>,dc=<base-part2>,dc=<base-
part3>:<password>.
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 at Configuration > Application Delivery > Server Resources > Health
Check > LDAP Version.
In any IP communication, the ARP cache is consulted to see if the IP address of the computer or the
router is present in the ARP cache. The corresponding physical address is used to send a packet.
A pre-defined arp health check is available.
An Inherit value can be configured for both parameters to allow configuration using the group
content.
The group content supports the following options:
requestDHCP REQUEST with a random source port
srequestDHCP REQUEST with source port 68 for an IPv4 target or 546 for an IPv6 target
strictDHCP INFORM with source port 68 for an IPv4 target or 546 for an IPv6 target
noneDHCP INFORM with a random source port
A pre-defined dhcp health check is available for simple DHCP service monitoring. The health check
has the parameters set to Inherit, allowing definition using the group content.
A pre-defined rtsp health check is available for simple RTSP service monitoring. The health check
has the parameters set to Inherit, allowing definition using the group content and destination port
set to standard RTSP port (554).
Pre-defined SIP (SIP Ping) and SIPOPTIONS (SIP OPTIONS) health checks are available for simple
SIP service monitoring. For these health checks, the Request URI is set to Inherit and the expected
response code is 200.
Note: Script-based health check requests in Alteon cannot match data that is split across two
packets.
The benefits of using script-based health checks include:
Ability to send multiple commands
Check for any return ASCII string or binary pattern
Test availability of different applications
Test availability of multiple domains or Web sites
A simple CLI controls the addition and deletion of commands to each script. New commands are
added and removed from the end of the script. Commands exist to open a connection to a specific
TCP or UDP port, send a request to the server, expect an ASCII string or binary pattern, and, for
TCP-based health checks only, to close a connection. The string or pattern configured with an
expect (or in the case of binary, bexpect) command is searched for in each response packet. If it is
not seen anywhere in any response packet before the real server health check interval expires, the
server does not pass the expect (or bexpect) step and fails the health check. A script can contain
any number of these commands, up to the allowable number of characters that a script supports.
Notes
There is no need to use double slashes when configuring a script in WBM 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 TCP/UDP payload> "
depth "10"
wait "100"
close #(used in TCP-based health checks only)
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:
OPENSpecify 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.
SENDSpecify 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.
EXPECTSpecify 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 TCP/UDP
payload 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 TCP/UDP payload that
should be examined. If no OFFSET value is specified, DEPTH is specified from the beginning of
the TCP/UDP payload. If an OFFSET value is specified, the DEPTH counts the number of bytes
starting from the offset value.
WAITSpecify 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
When using scripts:
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.
2. In the Health Check table, select an entry to edit and click , or double-click the entry you want
to edit. The relevant Edit field displays.
Notes
If you are using the CLI to create a health check script, you must use quotation marks () 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.
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 to the real server.
sslh3 Sends an SSL Hello 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 422
Server Failure, page 423
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, 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, 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.
To define the duration of the server slow start period for a real server in a group
1. Select Configuration > Application Delivery > Server Resources > Server Groups.
2. In the Server Groups table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit table displays.
3. In the Group Settings tab, type a value in seconds in the Server Slow-Start field.
4. Click Submit.
Note: The DSR VIP health check is enabled by default. This has no effect on the health check unless
the real server is configured with DSR.
Using parenthesis with the boolean operators, you can create a boolean expression to state the
health of the server group. The following two boolean expressions show two examples with real
servers 1, 2, 3, and 4 in two different groups:
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.
Select Configuration > Application Delivery > Server Resources > Server Groups.
In the Server Groups table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
Select the Advanced tab.
In the Health Check Formula field, configure an expression for the health check.
Click Submit.
In this example, we use the following values:
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.
Select Configuration > Application Delivery > Server Resources > Server Groups.
In the Server Groups table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
Select the Advanced tab.
In the Health Check Formula field, configure an expression for the health check.
Click Submit.
In this example, we use the following values:
2. In the Real Servers table, select an entry and click , or double-click the entry you want to edit.
The relevant Edit tab displays.
3. Select the Health Check tab.
4. In the Status Update on Port Failure field, select either Immediate or Standard to enable
or disable the fast health check option.
Filtering Benefits
Filtering provides the following benefits:
Filtering of Layer 2 non-IP framesIn Alteon, a filter can specify only source MAC and
destination MAC addresses, and capture and apply an allow.
Increased security for server networksFiltering 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 2Only filters, as described in MAC-Based Filters for Layer 2 Traffic, page 448, can be
configured to allow or deny non-IP traffic.
You can also secure Alteon from further virus attacks by configuring Alteon with a list of
potential offending string patterns.
Any filter can be optionally configured to generate system log messages for increased security
visibility.
Map the source or destination IP addresses and portsGeneric 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.
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 (Configuration > Application Delivery > Filters) instructs the filter what to do
when the filtering criteria are matched.
Alteon supports the following filtering actions:
AllowAllows 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 435.
DenyDiscards frames that fit the filter profile. This can be used for building basic security
profiles.
RedirectRedirects frames that fit the filter profile, such as for Web cache redirection.
NATPerforms 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.
Outbound LLBPerforms outbound WAN Link Load Balancing. Transparently forwards traffic
from the local network to the wide-area network via a WAN Link selected from the group of WAN
links specified. The public addresses used to NAT this outgoing traffic should be configured per
each WAN link (in WAN link server configuration).
GoToAllows the user to specify a target filter ID that the filter search should jump to when a
match occurs. This 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.
This filter does not support Layer 7 classification.
Note: If the filter destination matches or includes the virtual IP address on a device, only the Allow
and Deny actions are supported. No Redirect action is possible from a filter.
Stacking Filters
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.
2. In the Filters table, click to add an entry. The relevant Add tab displays.
3. In the Filter ID field, enter the numeric ID for the new filter.
4. In the Description field, enter a common description for the filter.
5. In the Action field, select Deny from the drop-down list.
6. In the Match Settings tab, in the Protocol field, select Any from the drop-down list.
7. Int he Match Settings tab, in both the Source and Destination columns, type 0.0.0.0 in the IP
Address/Network field.
8. Select Enable Filter.
9. Click Submit.
In this example, we use the following values:
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, you may want to remove some of the default filters.
You use a network class to define a filter source IP address or filter destination IP address.
For more information on network classes, see Server Load Balancing, page 205.
3. In the Filters table, select the correct filter and click to edit it. The relevant Edit tab displays.
4. Click Submit.
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 address or destination IP address
defines the base IP address in the desired range. The source mask or destination mask is the mask
that is applied to produce the range.
For example, to determine if a client request 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 destination mask 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.
2. In the Filters table, click to add an entry. The relevant Add tab displays.
3. In the Filters ID field, type the numeric ID for the new filter.
4. In the Description field, type the common name for the filter.
5. In the Action field, select Allow from the drop-down list.
6. In the Match Settings tab, select ICMP from the drop-down list in the Protocol field.
7. In the Session Management tab, select Enable in the Session Log field.
8. Select Enable Filter.
9. Click Submit.
In this example, we use the following values:
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.
2. In the Filters table, select the correct filter and click to edit the entry. The relevant Edit tab
displays.
3. In the Session Management tab, select an option in the drop-down list in the Session Caching
field.
4. Click Submit.
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.
Alteon does not create a session, or track fragments, for a filter which has caching disabled. Alteon
drops fragments when a filter does not allow caching.
2. In the Filters table, select the correct filter and click to edit the entry. The relevant Edit tab
displays.
3. In the Session Management tab, select an option in the drop-down list in the Logging field.
4. Click Submit.
Filtering Enhancements
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 435
Return to Proxy, page 436
Layer 7 Invert Filter, page 436
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.
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.
Note: Reverse entries are created only for TCP/UDP/ICMP traffic. For any other kind of traffic (such
as ESP), create an additional filter to match the return traffic.
To view an example using reverse session, see Redirecting Traffic with a Transparent Server,
page 437.
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. You can redirect traffic to such servers by changing the session destination IP to match
that of the server. To maintain persistence, 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.
Traffic that matches the Layer 7 invert filtering criteria can be redirected to VAS servers when
enabling the Configuration > Application Delivery > Filters > Add/Edit > Layer 7 Match
Conditions > Invert Action option.
Alteon sends the client request for picture.jpg directly to the specified hostname www.a.com.
Alteon sends the request for page.html transparently to proxy server group 1, as defined in step 6
of To configure a filter to redirect traffic, page 438.
b. In the Virtual Services table, click to add an entry. The relevant Add tab displays.
c. Select Enable Virtual Server.
d. In the Virtual Server ID field, type the ID for the server.
e. In the IP Version field, select IPv4 from the drop-down list.
f. In the IP Address field, type the IP address for the server.
g. Click Submit.
In this example, we use the following values:
b. In the Server Groups table, click to add an entry. The relevant Add tab displays.
c. In the Server Group ID field, type the ID for the server group.
d. In the IP Version field, select IPv4 from the drop-down list.
e. Select the Group Settings tab.
f. In the Health Check field, select ICMP from the drop-down list.
g. Click Submit.
In this example, we use the following values:
b. In the Filters table, select the correct filter and click . The relevant Edit tab displays.
c. In the Action Settings tab, type the port number to associate with this filter in the Real
Server Port field.
d. Click Submit.
5. Configure the content class properties on which the filters operate.
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, select an entry and click , or double-click the entry you want to edit.
The relevant Edit tab displays.
c. Select Layer 7 Match Conditions.
d. In the Content Class field, select an option from the drop-down list. If the correct option is
not listed, click to add an entry. The relevant Add tab displays.
e. Click Submit.
6. Configure filter 1.
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. Select Enable Filter.
d. In the Filter ID field, type the ID for the new filter.
e. In the Action field, select Redirect from the drop-down list.
f. In the Group ID field, select the group from the drop-down list.
In this example, we use the following values:
Content Class
0
9. Configure filter 2.
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. Select Enable Filter.
d. In the Filter ID field, type the ID for the new filter.
e. In the Action field, select Allow from the drop-down list.
f. In the Group ID field, select the group from the drop-down list.
In this example, we use the following values:
b. In the Port Processing table, click to add an entry. The relevant Add tab displays.
c. In the Port field, type the number for the port.
d. Select Filter/Outbound LLB.
e. Select the filter and use the arrows to move the filter between the Available and Selected
lists.
f. Click Submit.
Port Selected
1 10
2 20
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. Select Enable Filter.
d. In the Filter ID field, type the ID for the new filter.
e. In the Action field, select Redirect from the drop-down list.
In this example, we use the following values:
Filter ID Action
1 Redirect
4. Configure filter 2.
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. Select Enable Filter.
d. In the Filter ID field, type the ID for the new filter.
e. In the Action field, select Allow from the drop-down list.
In this example, we use the following values:
Filter ID Action
2 Allow
b. In the Port Processing table, click to add an entry. The relevant Add tab displays.
Port Selected
1 1
2 2
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. Select Enable Filter.
d. In the Filter ID field, type the ID for the new filter.
e. In the Action field, select Redirect from the drop-down list.
In this example, we use the following values:
Filter ID Action
1 Redirect
4. Configure filter 2.
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. Select Enable Filter.
d. In the Filter ID field, type the ID for the new filter.
e. In the Action field, select Allow from the drop-down list.
In this example, we use the following values:
Filter ID Action
2 Allow
b. In the Port Processing table, click to add an entry. The relevant Add tab displays.
c. In the Port field, type the number for the port.
d. Select Filter/Outbound LLB.
e. Select the filter and use the arrows to move the filter between the Available and Selected
lists.
f. Click Submit.
In this example, we use the following values:
Port Selected
1 1
2 2
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. Select Enable Filter.
d. In the Filter ID field, type the ID for the new filter.
e. In the Action field, select Redirect from the drop-down list.
In this example, we use the following values:
Filter ID Action
1 Redirect
b. In the Port Processing table, click to add an entry. The relevant Add tab displays.
c. In the Port field, type the number for the port.
d. Select Filter/Outbound LLB.
e. Select the filter and use the arrows to move the filter between the Available and Selected
lists.
f. Click Submit.
In this example, we use the following values:
Port Selected
1 1
2 2
MAC-based filters are supported for VLAN-based filters (see VLAN-Based Filtering, page 449), and
802.1p bit filtering (see Filtering on 802.1p Priority Bit in a VLAN Header, page 453).
2. In the Filters table, click to add an entry. The relevant Add tab displays.
3. In the Filter ID field, type the ID for the filter.
4. In the Action field, select Deny from the drop-down list.
5. Select the Advanced Matching tab.
6. In the Source MAC field, ensure the default (00:00:00:00:00:00) displays.
7. In the Destination MAC field, type the destination MAC code.
In this example, we use the following values:
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.
Note: While this example is based on IP traffic, VLAN-based filtering can also be used for non-IP
traffic by specifying source and destination MAC addresses instead of source and destination IP
addresses.
1. Configure filter 2 to allow local clients to browse the Web and then assign VLAN 20 to the filter.
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the ID for the filter.
d. In the Action field, select Allow from the drop-down list.
In this example, we use the following values:
Filter ID Action
2 Allow
d. In the Source column, in the IP Address/Network field, select HTTP from the drop-down
list. If the correct selection is not listed, click to add an entry. The relevant Add tab
displays.
e. In the Destination column, in the IP Address/Network field, type the destination IP
address.
f. In the Destination column, in the Mask/Prefix field, type the destination subnet mask.
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.
In this example, we use the following values:
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the ID for the filter.
d. In the Description field, type a common-name description for the filter.
e. In the Action field, select Allow from the drop-down list.
In this example, we use the following values:
5. 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.
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the ID for the filter.
d. In the Description field, type a common-name description for the filter.
e. In the Action field, select Deny from the drop-down list.
In this example, we use the following values:
Filter ID Action
2048 Deny
b. In the Port Processing table, click to add an entry. The relevant Add tab displays.
c. In the Port field, type the number for the port.
d. Select Filter/Outbound LLB.
e. Select the filter and use the arrows to move the filter between the Available and Selected
lists.
f. Click Submit.
Port Selected
10 2, 3, 2048
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.
b. In the Filters table, click to add a new entry. The relevant Add tab displays.
c. In the Filter ID field, type the number for the new filter.
d. In the Action field, select an option from the drop-down list.
2. Select the Advanced Matching tab.
a. In the 802.1p Match field, select Enable.
b. In the 802.1p Matching Value field, type the match value number.
3. Select the Bandwidth Management tab.
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 665.
a. In the Traffic Contract table, select the contract. If the correct contract is not listed, click
to add an entry. The relevant Add tab displays.
b. Click Submit.
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 (Configuration >
Application Delivery > Filters > Add/Edit > Layer 7 Match Conditions > Content
Lookup) because persistency server selection uses Layer 3 and 4 criteria, while the Layer 7
Content Lookup option 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 571.
b. In the Filters table, click to add a new entry. The relevant Add tab displays.
c. In the Filter ID field, type the filter ID number.
d. In the Action field, select Redirect from the drop-down list.
e. In the Group ID field, select the group from the drop-down list.
f. Select the Match Settings tab.
g. In the Protocol field, select the protocol from the drop-down list.
h. Select the Action Settings tab.
i. In the Real Server Port field, type the port number.
j. In the Hash Based Group Metrics field, select an option from the drop-down list.
2. Set the metric for the real server group to Min Misses or Hash.
The source IP address is passed to the real server group for either of the two metrics.
a. Select Configuration > Application Delivery > Server Resources > Server Groups.
b. In the Server Groups table, select a server group and click , or double-click the server
group. The relevant Edit tab displays.
c. Select Group Settings.
d. In the SLB Metric field, select the metric from the drop-down list.
e. Click Submit.
In this example, we use the following values:
SLB Metric
Min Misses or Hash
b. In the Filters table, click to add a new entry. The relevant Add tab displays.
c. In the Filter ID field, type the filter ID number.
d. In the Action field, select Redirect from the drop-down list.
e. In the Group ID field, select the group from the drop-down list.
f. Select the Match Settings tab.
g. In the Protocol field, select the protocol from the drop-down list.
h. Select the Action Settings tab.
i. In the HTTP Header Hash field, select Enable.
j. In the Header Name field, type the name.
k. In the Header Value field, type the header value number.
In this example, we use the following values:
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.
a. Select Configuration > Application Delivery > Server Resources > Server Groups.
b. In the Server Groups table, select a server group and click , or double-click the server
group. The relevant Edit tab displays.
c. Select Group Settings.
d. In the SLB Metric field, select the metric from the drop-down list.
e. Click Submit.
In this example, we use the following values:
SLB Metric
Min Misses or Hash
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 456:
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
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.
Note: 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
Table 13 - Well-known Application Ports , page 215 for a list of well-known applications ports.
1. 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:
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the ID for the filter.
d. In the Description field, type a description for the filter.
e. In the Action field, select Deny from the drop-down list.
f. Select Session Management.
g. In the Logging field, select Enable.
h. Click Submit.
In this example, we use the following values:
3. Create a filter that allows external HTTP requests to reach the Web server.
The filter must recognize and allow TCP traffic with the Web servers destination IP address and
HTTP destination port:
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the ID for the filter.
d. In the Action field, select Deny from the drop-down list.
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:
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the filter ID.
d. In the Action field, select Allow from the drop-down list.
In this example, we use the following values:
Filter ID Action
2 Allow
3 Allow
b. In the Filters table, click to add an entry. The relevant Add tab displays.
9. 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:
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the filter ID number.
d. In the Action field, select Allow from the drop-down list.
In this example, we use the following values:
Filter ID Action
5 Allow
11. 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. Select Configuration > Application Delivery > Filters.
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the filter ID number.
d. In the Action field, select Allow from the drop-down list.
In this example, we use the following values:
Filter ID Action
6 Allow
7 Allow
8 Allow
9 Allow
13. Assign the filters to the port that connects to the Internet.
a. Select Configuration > Application Delivery > Port Processing.
b. In the Port Processing table, click to add an entry. The relevant Add tab displays.
c. In the Port field, type the number for the port.
d. Select Filter/Outbound LLB.
e. Select the filter and use the arrows to move the filter between the Available and Selected
lists.
f. Click Submit.
In this example, we use the following values:
Port Selected
5 1, 2, 3, 4, 5, 6, 7, 8, 9, 2048
14. 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 ports session information
is updated (every two minutes or so). To make filter changes take effect immediately, clear the
session binding table for the port.
In the NAT examples in this section, a company has configured its internal network with private IP
addresses. A private network is one that is isolated from the global Internet and is, therefore, free
from the usual restrictions requiring the use of registered, globally unique IP addresses.
With NAT, private networks are not required to remain isolated. Alteon NAT capabilities allow
internal, private network IP addresses to be translated to valid, publicly advertised IP addresses and
back again. NAT can be configured in one of the following two ways:
Static NAT provides a method for direct mapping of one predefined IP address (such as a
publicly available IP address) to another (such as a private IP address).
Dynamic NAT provides a method for mapping multiple IP addresses (such as a group of internal
clients) to a single IP address (to conserve publicly advertised IP addresses).
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 servers internal private network
address. The filter for the server-side port reverses the process, translating the servers private
address information to a valid public address.
Alteon ignores Layer 4 parameters when you do not configure a proxy IP address for a filter.
In Figure 60 - Static NAT Example, page 462, clients on the Internet require access to servers on the
private network:
a. In the Filters table, click to add an entry. The relevant Add tab displays.
b. In the Filter ID field, type the filter ID number.
c. In the Action field, select NAT from the drop-down list.
In this example, we use the following values:
Filter ID Action
10 NAT
20 NAT
a. In the Port Processing table, click to add an entry. The relevant Add tab displays.
b. In the Port field, type the number for the port.
c. Select Filter/Outbound LLB.
d. Select the filter and use the arrows to move the filter between the Available and Selected
lists.
e. Click Submit.
In this example, we use the following values:
Port Selected
1 10
2 20
Notes
Within each filter, the source and destination IP address values are identical.
All parameters for both filters are identical except for the NAT direction. For filter 10, the source
NAT is used. For filter 11, the destination NAT is used.
Filters for static (non-proxy) NAT should take precedence over dynamic NAT filters (see Dynamic
NAT, page 463). 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 464, 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.
a. In the Filters table, click to add an entry. The relevant Add tab displays.
b. In the Filter ID field, type the filter ID number.
c. In the Action field, select NAT from the drop-down list.
In this example, we use the following values:
Filter ID Action
14 NAT
NAT Type
Dynamic
a. In the Port Processing table, click to add an entry. The relevant Add tab displays.
b. In the Port field, type the number for the port.
c. Select Proxy (Client NAT).
d. Select Filter/Outbound LLB.
e. Select the filter and use the arrows to move the filter between the Available and Selected
lists.
f. Click Submit.
In this example, we use the following values:
Port Selected
1 14
For more information on proxy IP address, see Client Network Address Translation (Proxy IP),
page 235.
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 461).
After port filtering is enabled or disabled and you apply the change, session entries are deleted
immediately.
Because of the way FTP works in active mode, a client sends information on the control channel
(information that reveals their private IP address) out to the Internet. However, the filter only
performs NAT translation on the TCP/IP header portion of the frame, preventing a client with a
private IP address from performing active FTP.
Alteon can monitor the control channel and replace the clients private IP address with a proxy IP
address defined on Alteon. When a client in active FTP mode sends a port command to a remote FTP
server, Alteon analyzes the data part of the frame and modifies the port command as follows:
The real server (client) IP address is replaced by a public proxy IP address.
The real server (client) port is replaced with a proxy port.
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.
1. Select Configuration > Application Delivery > Filters.
a. In the Filters table, click to add an entry. The relevant Add tab displays.
b. In the Filter ID field, type the filter ID number.
c. In the Action field, select NAT from the drop-down list.
In this example, we use the following values:
Filter ID Action
14 NAT
a. In the Port Processing table, click to add an entry. The relevant Add tab displays.
b. In the Port field, type the number for the port.
c. Select Proxy (Client NAT).
d. Select Filter/Outbound LLB.
e. Select the filter and use the arrows to move the filter between the Available and Selected
lists.
f. Click Submit.
In this example, we use the following values:
Port Selected
1 14
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.
b. In the Gateways table, click to add an entry. The relevant Add tab displays.
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the filter ID number.
d. In the Action field, select NAT from the drop-down list.
3. Enable overlapping NAT at Configuration > Application Delivery > Filters > Overlapping
IPs in NAT Filters.
Default: Source IP
d. Set Include Destination Port in VMA to Enable to include the processor destination IP
address in VMA.
Default: Enable
e. Click Submit.
3. Configure a NAT filter and enable SIP parsing.
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the filter ID number.
d. In the Action field, select NAT from the drop-down list.
e. Select Action Settings.
f. In the NAT Type field, select Static from the drop-down list.
g. In the Direction field, select Source.
h. In the SIP NAT field, select Enable in the drop-down list.
In this example, we use the following values:
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the filter ID number.
d. In the Action field, select NAT from the drop-down list.
e. Select Bandwidth Management.
f. In the BW Contract field, type a bandwidth contract.
g. In the SIP RTP Contract field, type a SIP RTP contract.
h. Click Submit.
In this example, we use the following values:
Flag Description
URG Urgent
ACK Acknowledgment
PSH Push
RST Reset
Flag Description
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 434.
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 servers 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.
b. In the Filters table, select to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the filter ID number.
d. In the Action field, select Allow from the drop-down list.
In this example, we use the following values:
Filter ID Action
10 Allow
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 (SYN-ACK) of a TCP
session.
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, select to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the filter ID number.
d. In the Action field, select Allow from the drop-down list.
In this example, we use the following values:
Filter ID Action
15 Allow
TCP Flags
SYN, ACK
6. 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.
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, select to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the filter ID number.
d. In the Action field, select Allow from the drop-down list.
In this example, we use the following values:
Filter ID Action
16 Allow
TCP Flags
SYN, PSH
9. Configure a filter that allows trusted HTTP traffic from the Internet to pass through Alteon to the
Web servers.
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, select to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the filter ID number.
d. In the Action field, select Allow from the drop-down list.
In this example, we use the following values:
Filter ID Action
17 Allow
11. Configure a filter that allows HTTP responses from the Web servers to pass through Alteon to the
Internet.
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, select to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the filter ID number.
d. In the Action field, select Allow from the drop-down list.
In this example, we use the following values:
Filter ID Action
18 Allow
13. Configure a default filter which denies all other traffic. This filter is required.
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, select to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the filter ID number.
d. In the Definition field, type a common name for the filter.
e. In the Action field, select Deny from the drop-down list.
In this example, we use the following values:
a. In the Port Processing table, click to add an entry. The relevant Add tab displays.
b. In the Port field, type the number for the port.
c. Select Proxy (Client NAT).
d. Select Filter/Outbound LLB.
e. Select a filter and use the arrows to move the filter between the Available and Selected
lists.
f. Click Submit.
In this example, we use the following values:
Port Selected
1 15, 16, 17, 2048
2 10, 18,2048
3 10, 18, 2048
Note: After port filtering is enabled or disabled and you apply the change, session entries are
deleted immediately.
2. In the Filters table, click to add an entry. The relevant Add tab displays.
3. In the Filter ID field, type the filter ID number.
4. In the Action field, select an action from the drop-down list.
5. Select Advanced Matching.
6. In the ICMP Message Type field, select an option from the drop-down list.
7. Click Submit.
For any given filter, only one ICMP message type can be set at any one time.
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 434.
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 learned. If this is not done, no packets are
allowed because link neighbors cannot be learned. Filter inversion also must take these NSol packets
into consideration.
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.
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the filter ID number.
d. In the Action field, select Allow from the drop-down list.
In this example, we use the following values:
Filter ID Action
1 Allow
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the filter ID number.
d. In the Action field, select Allow from the drop-down list.
In this example, we use the following values:
Filter ID Action
2 Allow
a. In the Port Processing table, click to add an entry. The relevant Add tab displays.
b. In the Port field, type the number for the port.
c. Select Proxy (Client NAT).
d. Select Filter/Outbound LLB.
e. Select the filter and use the arrows to move the filter between the Available and Selected
lists.
f. Click Submit.
In this example, we use the following values:
Port Selected
1 1, 2
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 A -
Content-Intelligent Server Load Balancing Not Using Layer 7 Content Switching Rules, page 699.
To support IP fragment traffic when Layer 7 content switching is defined based on strings, set
the Configuration > Application Delivery > Virtual Services > Virtual Servers > Add/
Edit > Delayed Binding option to Force Proxy to force traffic through the Application Services
Engine.
2. In the Filters table, select the filter and click , or double-click the filter. The relevant Edit tab
displays.
3. Select Layer 7 Match Conditions.
4. In the Content Class field, click to add an entry. The relevant Add tab displays.
5. In the Content Class ID field, type the content class ID value.
6. Select one of the following tabs to configure content classes:
URL Hostname
URL Path
URL Filename
Header
Cookie
Text
XML Tag
7. On each tab, click to add an entry. The relevant Add tab displays.
8. Click Submit when finished configuring each content class.
2. In the Filters table, select the filter and click , or double-click the filter. The relevant Edit tab
displays.
3. Select Layer 7 Match Conditions.
4. In the Content Class field, select the content class from the drop-down list.
5. Click Submit.
Data Classes
A data class is a unique key-value pair that can be referred to from within AppShape++ scripts and
Layer 7 content classes. A data class may also contain only a key. Data classes are useful when you
perform a search within a list of values. For example, when:
Blocking or allowing traffic to certain URLs, as defined in a black or white list.
Performing content-switching for a large number of URLs. In such cases, the data class contains
pairs of URLs, and a group to be selected for each URL.
Checking domain aliases for GSLB resolution.
You configure data classes for use with AppShape++ scripts and Layer 7 content classes as follows:
You access data classes from AppShape++ scripts using the class command.
You can assign data classes of type string to HTTP or RTSP content classes to compare
processed traffic values. The different field types in the content class allow you to select a data
class instead of manual configuration. You define the match type (for example, suffix or prefix)
and case-sensitivity in the content class element to which the data class is assigned.
Alteon supports up to 1024 configured data classes, which can occupy up to 40 MB of memory.
This section describes the following topics:
Defining a Data Class, page 480
Assigning a Data Class to a Content Class, page 481
2. In the Data Classes table, click to add an entry. The relevant Add tab displays.
3. In the Data Classes ID field, type the data class ID value.
4. In the Description field, type a descriptive name for the data class.
5. In the Data Type field, select either IP or String from the drop-down list.
6. In the Data Class Entries table, click to add an entry. The relevant Add tab displays.
7. In the Key field, type the key to use. If you selected IP in the Data Type field, the key is an IP
address.
8. In the Value field, type the value. Valid values are:
IPv4 hostx.y.z.w
IPv4 subnetx.y.z.w/prefix
IPv6 hosta:b:c:d:e:f:g:h or a:b:c::e
IPv6 subneta:b:c:d:e:f:g:h/prefix or a:b:c::e/prefix
When data type is set to string, the key is a string.
The maximum key length is 256 characters. The maximum value length is 512 characters.
9. Click Submit.
2. In the Filters table, select the filter and click , or double-click the filter. The relevant Edit tab
displays.
3. Select Layer 7 Match Conditions.
4. In the Content Class field, click to add an entry. The relevant Add tab displays.
5. In the Content Class ID field, type the content class ID.
6. Select URL Hostname.
7. In the URL Hostname table, click to add an entry. The relevant Add tab displays.
8. In the ID field, type the ID.
9. In the Hostname field, type the hostname.
10. In the Data Class field, select or create a data class of type String.
11. Click Submit.
12. Select URL Path.
13. In the URL Path table, click to add an entry. The relevant Add tab displays.
14. In the ID field, type the ID.
15. In the Path field, type the path.
16. Click Submit.
Filtering uses the Global filter and forward commands. Filter matching fires the
HTTP_FILTER_MATCH event. For more information, see the Alteon AppShape++ Reference
Guide.
Note: The order of the filters is significant. For example, Alteon classifies traffic sent to a basic
tunnel as non-HTTP, even if a later filter is set to use an HTTP tunnel.
Example
Assume the following user data table:
In this example, you can set the filter to seek a match based on CoS string values Silver, Gold, or
Default_Cos.
To perform the following operations:
Redirect Gold users.
Filter all other known users by NAT.
Block all other traffic.
Return to Sender
The Return to Sender (RTS) option enables Alteon to look up responses from the real server in the
session table.
When you enable RTS, Alteon associates 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 persistence.
You can also use a VLAN for RTS information on the real server, and include the IP address in the
session table look-up.
Note: The RTS method has been superseded by Transparent Load Balancing. Radware recommends
that you use Transparent Load Balancing for best results. For more information, see Transparent
Load Balancing, page 437.
GSLB Overview
GSLB enables balancing server traffic load across multiple physical sites. The Alteon GSLB
implementation takes into account an individual sites 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 sites 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.
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 clients 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 clients 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. Denvers virtual server IP address first when responding to the
DNS request.
5. The client connects to Example Inc. Denver for the best service.
The clients 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 Licensing
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. Select Configuration > System > Licenses,
2. Enter your license in the License String field.
3. Click Set License.
If the license is correct for this MAC address, Alteon accepts the password, permanently records
it in non-volatile RAM (NVRAM), and then enables the feature.
Preserves a single IP address in high availability configurations, thus simplifying master DNS
server configuration.
DNS resolution statistics are available (virtual service statistics for a DNS Responder service).
The DNS Responder provides both UDP and TCP services. When you define a DNS responder VIP,
Alteon creates two virtual server IDs for the same VIP; one for the UDP service and one for the TCP
service.
When a client queries Alteon for DNS records using an IPv6 DNS responder VIP address, Alteon
supports retrieval of both A and AAAA (quad-A) records.
When a client queries Alteon using the IPv4 address of an Alteon interface, Alteon supports retrieval
of A records only.
For authentication purposes, Alteon uses two different keys in DNSKEY records, with different
DNSKEY records for each. Key Signing Keys (KSKs) are used to sign the Zone Signing Key (ZSKs)
and are exported (publicly) to the parent DNS. ZSKs are used to sign the DNS resource records
(RRs). Because the ZSKs are controlled and used by one specific DNS zone, they can be switched
more easily and more frequently. RFC 4614 recommends changing ZSKs on a monthly basis,
enabling them to be shorter in bit length (for example, 1024). The KSK validity period is usually one
year, and needs a higher bit length (for example, 2048), making it harder to forge. When a new KSK
is created, the delegation signer (DS) record must be transferred to the parent zone, and must be
signed and published there.
When working with GSLB and DNSSEC enabled, the configuration of remote sites must be identical
for all Alteons participating in the GSLB configuration (Configuration > Application Delivery >
Global Traffic Redirection > Remote Sites).
For GSLB sites to synchronize Alteon peers, the passphrase for Alteon synchronization must be
enabled (Network > High Availability > Configuration Sync > Modules to Sync > Use
Passphrase for authentication). Failing to set the passphrase generates an error message.
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.
This section includes the following topics:
Basic DNSSEC Configuration, page 489
DNSSEC Key Rollover, page 491
Importing and Exporting Keys, page 494
Deleting Keys, page 496
NSEC and NSEC3 Records, page 496
6. Create a key signing key and define its parameters. For example:
7. Click Submit.
8. From the Type drop-down list, select Zone Signing Key.
9. Create a zone signing key and define its parameters as for the key signing key.
10. Click Submit.
11. Select Configuration > Application Delivery > DNS Authority > DNSSEC > Zone to Key
Association.
Notes
The DS export is a manual process that needs administrator validation at both the parent and
child zones.
You can perform this procedure over a secure connection, such as HTTPS or SSH.
In the site DSSP configuration (Configuration > Application Delivery > Global Traffic
Redirection > Distributed Site State Protocol (DSSP)), each site contains the configuration of
the other sites (remote IP address).
All IP addresses of all the sites must be configured on all Alteons participating in the GSLB DNSSEC
configuration.
The automatic rollover of the DNSSEC keys is performed according to the parameters specified in
Table 24 - Automated ZSK Rollover as Defined in RFC 4641, page 492:
e. A timeout of 12 hours, in addition to the TTL of the original ZSK, starts before enabling the
DNSKEY publication.
f. All zone records are signed with the new ZSK, including all RRSIGs still existing in cache.
g. The old RRSIGs are removed from storage. The old ZSK remains in storage and is publicly
available using DNSKEY.
h. A timeout of 12 hours, in addition to the TTL of the highest signed RRSIG, starts.
i. The old ZSK is revoked and is removed from storage.
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 predefined 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.
When exporting a public key, only the DNSKEY with all the relevant DNSSEC key properties and
features (DS, TTLS, zone assignment, timer values and so on) is exported. When exporting a
KSK in DS format, the key must be signed by the parent of the domain. Make sure to manually
send the DS export to be signed by the parent of the domain.
When importing keys, you import DNSSEC key properties, such as timers, which require user
input. After importing, a DNSKEY is not functional unless it is assigned to a zone.
Note: Importing and exporting DNSSEC keys requires a secure connection such as HTTPS or SSH.
To import a key
ZSKs and KSKs are imported in the same way.
1. Select Configuration > Application Delivery > DNS Authority > DNSSEC > Key
Repository.
2. Click .
3. In the Import screen, select Enable Key, and define the key parameters. For example:
4. Click Choose File and browse to the containing the key you want to import.
5. Select File from the drop-down list, and perform these steps:
6. Click Open.
7. Click Import.
2. In the Key Repository table, select an entry and click , or double-click the entry you want to
export. The relevant Edit tab displays.
3. Select Export.
4. Type and confirm the key passphrase.
5. From the Export To drop-down list, select File.
6. Click Export.
Alteon downloads the key to your computer as a text file with a .txt extension.
2. In the Key Repository table, select an entry and click , or double-click the entry you want to
export. The relevant Edit tab displays.
3. Select Export.
4. Type and confirm the key passphrase.
5. From the Export To drop-down list, select Text.
6. Click Export.
Alteon displays the key in the Text area.
Deleting Keys
This section describes how to delete a DNSSEC key.
To delete a key
1. Select Configuration > Application Delivery > DNS Authority > DNSSEC > Key
Repository.
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.
If the domain name and a matching record exists, the regular GSLB DNSSEC procedure is
followed.
If the domain name exists but no matching record exists, Alteon returns the NSEC or NSEC3
record of the requested name.
If neither the domain name nor a matching record exists, Alteon drops the DNS request.
Note: When issuing an NSEC RRSIG answer, the DNS server uses only one record (NSEC or
NSEC3).
To configure Site A
1. Assign an IP interface for each subnet attached to Alteon, as follows:
a. Select Configuration > Network > Layer 3 > IP Interfaces.
i. In the Secondary IP Address field, type the IP address for the secondary server.
j. Click Submit.
In this example, we use the following values:
b. In the DNS Redirection Rules table, select the default rule 1 and click , or double-click the
entry. The relevant Edit tab displays.
c. Select Enable DNS Redirection Rule.
d. In the DNS Redirection Metrics table, select Metric Index 1 and click , or double-click the
entry. The relevant Edit tab displays
e. Set the Metric Type drop-down list to Persistence.
f. Click Submit.
To configure Site B
1. Assign an IP interface for each subnet attached to Alteon, as follows:
a. Select Configuration > Network > Layer 3 > IP Interfaces.
b. In the DNS Redirection Rules table, select the default rule 1 and click , or double-click the
entry. The relevant Edit tab displays.
c. Select Enable DNS Redirection Rule.
d. In the DNS Redirection Metrics table, select Metric Index 1 and click , or double-click the
entry. The relevant Edit tab displays
e. Set the Metric Type drop-down list to Persistence.
f. Click Submit.
DSSP Versions
By default, DSSP version 1 is enabled. Alteon supports the following DSSP versions:
DSSP version 1The initial release of DSSP. Uses fixed TCP port 80.
DSSP version 2DSSP version 2 adds support for server response time, CPU use, session
availability, and session utilization in the remote site updates. Lets you modify TCP port 80, and
encrypts the DSSP payload by default.
DSSP version 3DSSP version 3 adds support for the availability persistence selection metric.
DSSP version 4DSSP version 4 adds support for the client proximity selection metric in remote
site updates.
DSSP version 5DSSP version 5 adds support for IPv6 remote server updates. Does not
support client proximity for IPv6.
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 208.
For details about any of the processes or menu commands described in this example, see the
Alteon Command Line Interface Reference Guide.
This section describes the following procedures:
To configure the San Jose site, page 503
To configure the Denver site, page 510
Parameter Value
IP Address 10.10.242.40
Mask/Prefix 255.255.248.0
Default Gateway 10.10.240.1
2. Select Configuration > System > Management Access, and set the Idle Timeout field to
123 minutes.
3. Enable Telnet access to Alteon.
a. Select Configuration > System > Management Access > Management Protocols.
b. In the Telnet tab, select Enable Telnet.
c. Click Submit.
4. Enable SSH access to Alteon.
a. Select Configuration > System > Management Access > Management Protocols.
b. In the SSH tab, select Enable SSH.
c. Set the Version option to V2.
d. Click Submit.
5. Assign an IP interface for each subnet attached to Alteon, as follows:
a. Select Configuration > Network > Layer 3 > IP Interfaces.
b. In the Virtual Routers table, click to add an entry. The relevant Add tab displays.
c. Select Enable Virtual Routers.
d. In the Router ID field, type the router ID.
The default value is 1. Valid values are in the range 11024.
b. In the Virtual Routers table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. Select the Tracking tab.
d. Disable Tracking Sharing.
e. Click Submit.
f. Repeat the procedure for additional virtual routers.
10. Configure a virtual router group.
a. Select Configuration > Network > High Availability > Legacy VRRP > Virtual Router
Groups.
b. Set Working Mode to Switch Based.
c. Select Enable Virtual Router Group.
d. Set the IP Version option to IPv4 (default) or IPv6.
IPv6 increases the number of addresses available for networked devices. In this example,
we use IPv4.
e. In the Router ID field, type the virtual router ID for this group.
Valid values are in the range 1255.
f. In the Interface field, type an interface to assign the virtual router to.
Valid values are in the range 1256.
g. In the Priority field, type the election priority bias for this virtual router group.
The default value is 100. Valid values values are in the range 1254.
During the master router election process, the routing Alteon with the highest virtual router
priority number wins. If there is a tie, the Alteon with the highest IP interface address wins.
If this virtual routers IP address is the same as the one used by the IP interface, the priority
for this virtual router is automatically be set to 255 (highest).
h. Disable the Tracking Sharing option to prevent the sharing of interfaces between Alteon
platforms in an active-standby configuration.
When this option is enabled, this Alteon processes any traffic addressed to this virtual
router, even when in backup mode.
i. Click Submit.
In this example, we use the following values:
The real server ID is used to determine to which port the server is connected.
Note: The real server ID must exist before you can configure the service ports for the real
server.
e. (Optional) In the Description field, type a description of up to 31 characters for the real
server.
f. Set the Server Type option to one of the following:
Local (default)The real server does not participate in GSLB.
RemoteThe real server participates in GSLB.
WAN LinkThe real server connects the internal network to an ISP link.
g. Set the IP Version option to IPv4 (default) or IPv6.
IPv6 increases the number of addresses available for networked devices.
h. In the Server IP Address field, type the IP address for the real server.
i. Click Submit.
The new real server displays in the Real Servers table.
In this example, we use the following values:
15. Configure a remote real server entry on each Alteon for each remote service to enable each
Alteon to recognize remote peers.
a. Select Configuration > Application Delivery > Server Resources > Real Servers.
b. In the Server Groups table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In the Real Servers tab, select a real server ID and use the arrows to move the server
between the Available and Selected lists.
d. Click Submit.
In this example, we use the following values:
17. Configure server load processing for each type of Level 4 traffic per port.
a. Select Configuration > Application Delivery > Port Processing.
b. In the Port Processing table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays
c. Select Client, Server, or Proxy (Client NAT).
d. Click Submit.
In this example, we use the following values:
19. Define the domain name and hostname for each service hosted on each virtual server.
a. Select Configuration > Application Delivery > Virtual Services.
b. In the Virtual Servers table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. Select the Global Server Load Balancing tab.
d. In the Domain Name field, type the domain name for the service.
The domain name typically includes the name of the company or organization, and the
Internet group code (.com, .edu, .gov, .org, and so on). For example, foocorp.com.
It does not include the hostname portion (www, www2, ftp, and so on).
Values: 164 alphanumeric characters.
e. Click Submit.
f. In the Virtual Servers table, select the server you are configuring click , or double-click
the entry you want to edit. The relevant Edit tab displays.
g. In the Virtual Services table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
h. From the Group ID drop-down list, select the real server group identifier for the service.
i. Select the Properties tab.
j. In the Real Server Port field, type the Layer 4 real port for the service.
k. In the Hostname field, type the hostname for the service.
l. Click Submit.
In this example, we use the following values:
Parameter Value
IP Address 10.10.242.11
Mask/Prefix 255.255.248.0
Default Gateway 10.10.240.1
2. Select Configuration > System > Management Access, and set the Idle Timeout field to
9999 minutes.
3. Enable Telnet access to Alteon.
a. Select Configuration > System > Management Access > Management Protocols.
b. In the Telnet tab, select Enable Telnet.
c. Click Submit.
4. Enable SSH access to Alteon.
a. Select Configuration > System > Management Access > Management Protocols.
b. In the SSH tab, select Enable SSH.
c. Set the Version option to V2.
d. Click Submit.
5. Assign an IP interface for each subnet attached to Alteon, as follows:
a. Select Configuration > Network > Layer 3 > IP Interfaces.
b. In the Virtual Routers table, click to add an entry. The relevant Add tab displays.
c. Select Enable Virtual Routers.
d. In the Router ID field, type the router ID.
The default value is 1. Valid values are in the range 11024.
e. In the VR ID field, type the virtual router ID.
Valid values are in the range 11024.
f. Set the IP Version option to IPv4 (default) or IPv6.
IPv6 increases the number of addresses available for networked devices. In this example,
we use IPv4.
g. In the IP Address field, type the IP address for the interface.
h. From the Interface drop-down list, select an interface to assign the virtual router to.
i. Click Submit.
j. Repeat the procedure for additional virtual routers.
In this example, we use the following values:
b. In the Virtual Routers table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In the Priority field, type the election priority bias for this virtual router group.
The default value is 100. Valid values values are in the range 1254.
d. Click Submit.
e. Repeat the procedure for additional virtual routers.
In this example, we use the following values:
Router ID Priority
11 101
14 101
41
100 101
10. Prevent the sharing of interfaces between Alteon platforms in an active-standby configuration.
a. Select Configuration > Network > High Availability > Legacy VRRP > Virtual
Routers.
b. In the Virtual Routers table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. Select the Tracking tab.
d. Disable Tracking Sharing.
e. Click Submit.
f. Repeat the procedure for additional virtual routers.
11. Configure a virtual router group.
a. Select Configuration > Network > High Availability > Legacy VRRP > Virtual Router
Groups.
b. Set Working Mode to Switch Based.
c. Select Enable Virtual Router Group.
d. Set the IP Version option to IPv4 (default) or IPv6.
IPv6 increases the number of addresses available for networked devices. In this example,
we use IPv4.
e. In the Router ID field, type the virtual router ID for this group.
Valid values are in the range 1255.
f. In the Interface field, type an interface to assign the virtual router to.
Valid values are in the range 1256.
g. In the Priority field, type the election priority bias for this virtual router group.
The default value is 100. Valid values values are in the range 1254.
During the master router election process, the routing Alteon with the highest virtual router
priority number wins. If there is a tie, the Alteon with the highest IP interface address wins.
If this virtual routers IP address is the same as the one used by the IP interface, the priority
for this virtual router is automatically be set to 255 (highest).
h. Disable the Tracking Sharing option to prevent the sharing of interfaces between Alteon
platforms in an active-standby configuration.
When this option is enabled, this Alteon processes any traffic addressed to this virtual
router, even when in backup mode.
i. Click Submit.
In this example, we use the following values:
Note: The real server ID must exist before you can configure the service ports for the real
server.
e. (Optional) In the Description field, type a description of up to 31 characters for the real
server.
f. Set the Server Type option to one of the following:
Local (default)The real server does not participate in GSLB.
RemoteThe real server participates in GSLB.
WAN LinkThe real server connects the internal network to an ISP link.
g. Set the IP Version option to IPv4 (default) or IPv6.
IPv6 increases the number of addresses available for networked devices.
h. In the Server IP Address field, type the IP address for the real server.
i. Click Submit.
The new real server displays in the Real Servers table.
In this example, we use the following values:
16. Configure a remote real server entry on each Alteon for each remote service to enable each
Alteon to recognize remote peers.
a. Select Configuration > Application Delivery > Server Resources > Real Servers.
b. In the Server Groups table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In the Real Servers tab, select a real server ID and use the arrows to move the server
between the Available and Selected lists.
d. Click Submit.
In this example, we use the following values:
18. Configure server load processing for each type of Level 4 traffic per port.
a. Select Configuration > Application Delivery > Port Processing.
b. In the Port Processing table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays
c. Select Client, Server, or Proxy (Client NAT).
d. Click Submit.
In this example, we use the following values:
20. Define the domain name and hostname for each service hosted on each virtual server.
a. Select Configuration > Application Delivery > Virtual Services.
b. In the Virtual Servers table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. Select the Global Server Load Balancing tab.
d. In the Domain Name field, type the domain name for the service.
The domain name typically includes the name of the company or organization, and the
Internet group code (.com, .edu, .gov, .org, and so on). For example, foocorp.com.
It does not include the hostname portion (www, www2, ftp, and so on).
Values: 164 alphanumeric characters.
e. Click Submit.
f. In the Virtual Servers table, select the server you are configuring click , or double-click
the entry you want to edit. The relevant Edit tab displays.
g. In the Virtual Services table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
h. From the Group ID drop-down list, select the real server group identifier for the service.
i. Select the Properties tab.
j. In the Real Server Port field, type the Layer 4 real port for the service.
k. In the Hostname field, type the hostname for the service.
l. Click Submit.
In this example, we use the following values:
Note: In this configuration each Alteons has its own GSLB license, but only the standalone Tokyo
Alteon must have a GSLB license.
Parameter Value
IP Address 43.100.80.20
Mask/Prefix 255.255.255.0
Default Gateway 43.100.80.1
2. Configure a VLAN.
a. Select Configuration > Network > Layer 2 > VLAN.
b. In the VLAN table, select an entry and click , or double-click the entry you want to edit.
The relevant Edit tab displays.
c. In the VLAN ID field, type an ID.
Valid values are in the range 14090.
d. In the VLAN Name field, type a name of up to 32 characters.
e. Click Submit.
In this example, we use the following values:
b. In the VLAN table, select an entry and click , or double-click the entry you want to edit.
The relevant Edit tab displays.
c. In the Ports table, select the ports that you want to add to the VLAN and use the arrows to
move the ports between the Available and Selected lists.
d. Click Submit.
In this example, we use the following values:
VLAN ID Port
103 3
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.
7. 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.
a. Select Configuration > Application Delivery > Server Resources > Real Servers.
Note: The real server ID must exist before you can configure the service ports for the real
server.
e. (Optional) In the Description field, type a description of up to 31 characters for the real
server.
f. Set the Server Type option to one of the following:
Local (default)The real server does not participate in GSLB.
RemoteThe real server participates in GSLB.
WAN LinkThe real server connects the internal network to an ISP link.
g. Set the IP Version option to IPv4 (default) or IPv6.
IPv6 increases the number of addresses available for networked devices.
h. In the Server IP Address field, type the IP address for the real server.
i. Click Submit.
The new real server displays in the Real Servers table.
j. Repeat the procedure for additional real servers.
In this example, we use the following values:
Note: Note where each configured value originates, or this step can result in improper
configuration.
8. Define a network that will match and accept all incoming traffic for the other sites.
a. Select Configuration > Application Delivery > Global Traffic Redirection > DNS
Redirection Rules > Client Network Rules.
h. In the Virtual Servers table, click to add a virtual server to the network.
From the Virtual Server ID drop-down list, select the server to add to the network.
In the Preference field, type a preference value for the virtual server.
Valid values are in the range 165535.
The default value is 65535.
Click Submit.
i. In the Real Servers table, click to add a real server to the network.
From the Real Server ID drop-down list, select the server to add to the network.
In the Preference field, type a preference value for the real server.
Valid values are in the range 165535.
The default value is 65535.
Click Submit.
b. In the DNS Redirection Rules table, select the default rule 1 and click , or double-click the
entry. The relevant Edit tab displays.
c. Select Enable DNS Redirection Rule.
d. In the DNS Redirection Metrics table, select Metric Index 1 and click , or double-click the
entry. The relevant Edit tab displays
e. Set the Metric Type drop-down list to Network.
f. In the Client Network Rule table, select the rules that you want to add to the metric and use
the arrows to move the contracts between the Available and Selected lists.
g. Click Submit.
In this example, we use the following values:
10. Define a new rule that will make the new network active.
a. Select Configuration > Application Delivery > Global Traffic Redirection > DNS
Redirection Rules.
j. In the DNS Redirection Metrics table, select Metric Index 1 and click , or double-click the
entry. The relevant Edit tab displays
k. Set the Metric Type drop-down list to Network.
l. In the Client Network Rule table, select the rules that you want to add to the metric and use
the arrows to move the contracts between the Available and Selected lists.
m. Click Submit.
In this example, we use the following values:
Default Rule
Alteon comes with a predefined rule (rule 1). By default, Alteon assigns rule 1 to all virtual servers.
Radware recommends that you create an entirely new rule if you want to assign a different metric
sequence to a rule. Do not modify the default rule. The site selection metric sequence in rule 1 is as
follows:
Table 25 - Default Rule 1 Gmetrics, page 525 describes the gmetrics for the default rule.
For a complete description of all available gmetrics, see Table 26 - Available GSLB Metrics, page
528.
b. In the Virtual Servers table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. Select the Global Server Load Balancing tab.
d. In the Domain Name field, type the domain name for the service.
The domain name typically includes the name of the company or organization, and the
Internet group code (.com, .edu, .gov, .org, and so on). For example, foocorp.com.
It does not include the hostname portion (www, www2, ftp, and so on).
Values: 164 alphanumeric characters.
e. Click Submit.
f. In the Virtual Servers table, select the server you are configuring click , or double-click
the entry you want to edit. The relevant Edit tab displays.
g. In the Virtual Services table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
h. From the Group ID drop-down list, select the real server group identifier for the service.
i. Select the Properties tab.
j. In the Real Server Port field, type the Layer 4 real port for the service.
k. In the Hostname field, type the hostname for the service.
l. Click Submit.
In this example, we use the following values:
b. In the Virtual Servers table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. Select the Global Server Load Balancing tab.
d. In the Site Selection Rules table, select the rules that you want to add to the domain and
use the arrows to move the contracts between the Available and Selected lists.
e. Click Submit.
In this example, we use the following values:
Note: When a rule contains both a Network metric and a Remote metric, and the domain name is
configured for both the rule and a virtual server, preference goes to the Network metric and the
servers associated with it.
For example, assume the domain name www.a.com is configured for a virtual server and for a
rule.
If there are five configured remote real servers, but only three of them are added to the Network
metric, Remote metric selection applies only to the three remote real servers included in the
network.
2. In the DNS Redirection Rules table, select an entry and click , or double-click the entry you
want to modify. The relevant Edit tab displays.
3. In the DNS Redirection Metrics table, select the Network metric you want to modify and click
, or double-click the entry. The relevant Edit tab displays.
4. In the Client Network Rule table, select the rules that you want to add to the metric and use the
arrows to move the contracts between the Available and Selected lists.
5. Click Submit.
Metric Description
Network Selects the server based on the preferred network defined for a given domain. If
preferred networks are not configured, this metric is not used in the default rule.
Uses the IP address of the clients DNS caching server, not the actual client IP
address.
Note: The network metric ignores the preference settings of virtual servers
and remote real servers in the network preference table. Alteon uses these
preference settings only when creating the client proximity table.
For more information on configuring preferred networks, see Configuring GSLB
Network Preference, page 558.
Geographical Selects the server based on the IANA-defined geographical region of the client
source IP address.
The available regions are as follows:
Africa
Caribbean
Pacific Rim
Europe
North America
Least Selects the server based on which server has the lowest session utilization.
Connections 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.
If the number of possible matches is greater than the number of DNS resource
records (virtual IP addresses) returned in the DNS response (as defined in the
Records in Response parameter of the rule), Alteon returns nothing and moves
on to the next metric.
Requires remote site updates.
The value of this gmetric represents a percentage of the maximum connections
for the relevant service, and not an absolute number.
Session utilization on one site must reach at least 1% of the maximum
connections for this gmetric to operate correctly. If session utilization on both
sites is equal to or less than 1%, there is no difference between the sites.
Round Robin Selects the server based on a round robin of servers.
Set the last metric in a rule to Round Robin or Random so that the GSLB
mechanism returns a value if there is at least one functional site.
Response Selects the server based on the lowest response time in milliseconds from an SLB
health check of the servers.
Requires SLB health checks and remote site updates.
Random Selects the server based on uniform random distribution of the servers.
Set the last metric in a rule to Round Robin or Random so that the GSLB
mechanism returns a value if there is at least one functional site.
Metric Description
Availability Selects a server exclusively when that server is available. If that server becomes
unavailable, Alteon selects the next available server. Availability is determined by
a rank assigned to each server ranging from the lowest score of 1 to the highest
score of 48. Multiple servers can be scored the same.
Rules that use Availability as the primary metric handle failures by selecting the
server with the next highest score compared to that of the server that failed, and
begin forwarding requests to that server. If the server that failed becomes
operational again, that server regains precedence and requests are routed to it
once more.
GSLB availability persistence lets the administrator use the Availability metric to
reassign requests to a server that had previously failed thanks to its higher initial
score. Enabling Availability Persistence ensures that after the server that failed
becomes operational again, it cannot regain precedence from the recovery server.
If this new primary server fails, its original availability value is restored and the
next server in the list gains the higher precedence.
Lets you group servers based on priority, or into primary and secondary groups.
Requires SLB health checks and remote site updates.
For examples using this gmetric, see Using the Availability Gmetric in a Rule,
page 535 and Using the Availability Gmetric with GSLB Availability Persistence,
page 536.
QoS Selects the server based on combination of the lowest session utilization and the
lowest response time of the SLB health check of the servers.
Requires SLB health checks and remote site updates.
Minmisses Selects the same server based on the hash of source IP address (the IP address of
the clients DNS caching server, not the actual client 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.
Hash Selects the same server based on the hash of source IP address (the IP address of
the clients DNS caching server, not the actual client 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 become available or
not available since the hash calculation uses only the servers that are available.
Persistence Selects the server for which the persistence cache contains the client IP address
and subnet mask.
For an example using this gmetric, see Using the Persistence Gmetric in a Rule,
page 537.
Local Selects the local virtual server only when the local virtual server is available.
Applies to DNS-based GSLB only.
Always Selects the local virtual server even though the local virtual server is not
available. Applies to DNS-based GSLB only
Set the last metric in rule 1 to Always so that the GSLB selection mechanism
selects at least the local virtual server when all servers are unavailable.
Remote Selects the remote real servers only.
Phash Selects the server for which the persistence cache contains the client IP address
and subnet mask. If the client IP address and subnet mask are not contained in
the persistence cache, select the server by performing hashing on the source IP
address and domain name.
None Removes a gmetric value. Alteon rule iteration passes to the next metric.
Weighting Gmetrics
All metrics can be weighted on a per-site basis.
For example, if you associate a rule that includes the Round Robin gmetric to weighted virtual
servers, Alteon uses a virtual server with weight 2 twice in DNS replies, while a virtual server with
weight 1 is used only once. Alteon uses virtual servers with higher weighting more often when
replying to DNS queries.
2. In the Virtual Servers table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
3. Select the Global Server Load Balancing tab.
4. In the Weight field, type the global server weight for this virtual server.
The higher the weight value, the more connections that are directed to the local site.
The response time of this site is divided by this weight before the best site is assigned to a
client. Remote site response times are divided by the real server weight before selection
occurs.
The default value is 1. Valid values are in the range 148.
5. Click Submit.
Thresholds
Gmetrics are completed by thresholds. Thresholds are not metrics; they are utilization thresholds
which when exceeded cause Alteon to ignore a site during the selection process. Table 27 - GSLB
Thresholds, page 531 lists and describes the GSLB thresholds available at Configuration >
Application Delivery > Global Traffic Redirection > Global Redirection Thresholds.
Threshold Description
Sessions The threshold percentage for session utilization capacity.
Utilization Ignores a server when the server session utilization exceeds the threshold.
Session utilization is the percentage of sessions used of total sessions that result in
normalized sessions between servers.
When the server is not available, session utilization is 100%.
Overwrites all other metrics and requires remote site updates.
Values 1100
Default: 90
CPU The threshold percentage for the CPU utilization capacity.
Utilization Ignores a server when CPU utilization of the site with the server exceeds the
threshold.
CPU utilization is the highest CPU utilization for periods of up to 64 seconds among
SPs.
Overwrites all other metrics and requires remote site updates.
Values 1100
Default: 90
Available The capacity threshold for the sessions available on the real server for GSLB.
Sessions Ignores a server when the number of available sessions on the server falls below the
threshold.
When the server is not available, the session available capacity is 0.
Overwrites all other metrics and requires remote site updates.
Values 165535
Default: 1024
Rule Iteration
You can configure one or more rules on each domain. Setting metric preferences enables the GSLB
selection mechanism to use multiple metrics from a metric preference list. The GSLB selection
mechanism selects the first rule that matches the domain and starts with the first metric in the
metric preference list of the rule. It then goes to the next metric when no server is selected, or when
more than the required servers are selected.
The GSLB selection stops when the metric results in at least one server, and no more than the
required number of servers, or when Alteon reaches the last metric in the list. For DNS direct-based
GSLB, the DNS response can be configured to return up to 10 required servers. For HTTP redirect-
based GSLB, the only one server is required server.
Alteon checks metrics until the number of possible matches is less than or equal to the number of
DNS resource records (virtual IP addresses) found. Then Alteon submits the possible matches in the
DNS response.
If the number of possible matches for is greater than the number of VIP addresses in the response,
or no match is found, Alteon moves to the next metric until a match is found or the rule list ends.
a. In the DNS Redirection Metrics table, select the metric you want to modify and click , or
double-click the metric. The relevant Edit tab displays.
b. Set the Metric Type drop-down list to one of the options described in Table 26 - Available
GSLB Metrics, page 528.
c. Click Submit.
d. Repeat for additional gmetrics.
In this example, we use the following values:
h. In the Virtual Servers table, click to add a virtual server to the network.
From the Virtual Server ID drop-down list, select the server to add to the network.
In the Preference field, type a preference value for the virtual server.
Valid values are in the range 165535.
The default value is 65535.
Click Submit.
i. In the Real Servers table, click to add a real server to the network.
From the Real Server ID drop-down list, select the server to add to the network.
In the Preference field, type a preference value for the real server.
Valid values are in the range 165535.
The default value is 65535.
Click Submit.
In this example, we use the following values:
2. Disable the default rule 1 to ensure that the time-based rule is processed first.
a. Select Configuration > Application Delivery > Global Traffic Redirection > DNS
Redirection Rules.
b. Select the default rule 1 and click , or double-click rule 1. The relevant Edit tab displays.
c. Deselect Enable DNS Redirection Rule.
d. Click Submit.
Rule ID
2
4. Specify the GSLB metrics to select a site if a server is not selected at first. Since the Network
gmetric is the first metric, make sure that you add the configured networks to metric 1.
a. Select Configuration > Application Delivery > Global Traffic Redirection > DNS
Redirection Rules.
b. In the DNS Redirection Rules table, select the rule and click , or double-click the entry.
The relevant Edit tab displays.
c. In the DNS Redirection Metrics table, select the metric you want to modify and click , or
double-click the metric. The relevant Edit tab displays.
d. Set the Metric Type drop-down list to one of the options described in Table 26 - Available
GSLB Metrics, page 528.
e. Click Submit.
f. Repeat for additional gmetrics.
In this example, we use the following values:
b. In the Virtual Servers table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. Select the Global Server Load Balancing tab.
d. In the Site Selection Rules table, select the rules that you want to add to the domain and
use the arrows to move the contracts between the Available and Selected lists.
e. Click Submit.
In this example, we use the following values:
b. In the DNS Redirection Rules table, select rule 1 and click , or double-click rule 1. The
relevant Edit tab displays.
c. In the DNS Redirection Metrics table, select metric 2 and click , or double-click metric 2.
The relevant Edit tab displays.
d. From the Metric Type drop-down list, select Availability.
e. Click Submit.
b. In the Virtual Servers table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. Select the Global Server Load Balancing tab.
d. In the Weight field, type the global server weight for this virtual server.
The higher the weight value, the more connections that are directed to the local site.
The response time of this site is divided by this weight before the best site is assigned to a
client. Remote site response times are divided by the real server weight before selection
occurs.
The default value is 1. Valid values are in the range 148.
e. Click Submit.
3. Set the availability values for the real servers.
a. Select Configuration > Application Delivery > Server Resources > Real Servers.
b. In the Real Servers table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
c. Select the Properties tab.
d. In the Weight field, set a weighting for this real server in the range 148 for use in load
balancing algorithms.
Higher weighting values force the server to receive more connections than the other servers
configured in the same real server group. A setting of 10 assigns the server roughly 10
times the number of connections as a server with a weight of 1.
The default value is 1.
e. Click Submit.
b. In the DNS Redirection Rules table, select rule 1 and click , or double-click rule 1. The
relevant Edit tab displays.
c. In the DNS Redirection Metrics table, select metric 1 and click , or double-click metric 2.
The relevant Edit tab displays.
2. In the DNS Redirection Rules table, select an entry and click , or double-click the entry you
want to modify. The relevant Edit tab displays.
3. In the DNS Redirection Metrics table, select an entry and click , or double-click the entry you
want to modify. The relevant Edit tab displays.
4. From the Metric Type drop-down list, select Persistence.
5. Click Submit.
Note: The persistence cache is not enabled unless you define a rule that includes the Persistence
gmetric. Without such a rule, no caching takes place.
Best Practices
The following are best practices:
If you want a rule with a different metric sequence to default rule 1, create an entirely new rule.
Do not modify the default rule.
When setting the order of metrics for a rule, place more specific metrics, such as the Network
metric, before more general gmetrics such as Geographical.
Set the last metric in a rule to Always so that the GSLB selection mechanism selects at least the
local virtual server when all servers are unavailable.
Note: Client proximity does not work for HTTPS services or HTTP services with the Delayed
Binding option set to Force Proxy, for example, HTTP services with content rules, FastView, and
compression (see Configuring Virtual Service Binding Properties, page 182). Set the Delayed
Binding option to Enable. If the Delayed Binding option is set to Disable, traffic goes to the
Alteon management processor, and not to the switch processor, impacting performance.
This section describes the following topics:
GSLB Client Proximity Metric, page 538
Static Client Proximity Dataflow, page 539
Configuring Static Client Proximity, page 540
Configuring Dynamic Client Proximity, page 557
Configuring GSLB Network Preference, page 558
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.company.com/products/index.html, the system
sends a DNS getHostByname query to the clients local DNS server for the www.company.com IP
address.
The dataflow for the example as shown Figure 67 - GSLB Client Proximity Site with HTTP Service,
page 539 is as follows:
1. The Client X DNS requests the local DNS server to send the www.company.com IP address.
2. The local DNS server queries the upstream DNS server on Alteon.
3. The Site A Alteon receives a DNS request and acts as the authoritative DNS. Site A responds to
the DNS request with a Site A VIP address according to the DNS GSLB configured metric.
4. Client X opens an HTTP application session with an Alteon at Site A.
5. On receiving the request, Site A checks its client proximity table and finds a static entry. It
identifies Site C to be the closest site and sends an HTTP 302 redirection with Site C IP address/
domain name.
6. On receiving the request, Site C checks its client proximity table and serves the HTTP request.
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
67 - GSLB Client Proximity Site with HTTP Service, page 539, if Site A determines that Site C is
down, it sends an HTTP redirect message with Site B VIP address/domain name.
Example Topology for GSLB Client Proximity Site with HTTP Service
This example begins with a sample configuration for Site C, followed by sample configurations for
Sites A and B. In Figure 67 - GSLB Client Proximity Site with HTTP Service, page 539, the order of
preference for Client X is Site C followed by Site B and Site A.
The configurations are located as follows:
To configure Site C, page 540
To configure Site A, page 546
To configure Site B, page 551
To configure Site C
1. Enable Direct Access mode.
a. Select Configuration > Application Delivery > Virtual Services > Settings.
b. Select Enable SLB to enable server load balancing on the Alteon platform.
c. Set the Direct Access Mode option to Enable.
d. Click Submit.
2. Set DSSP to version 4 for client proximity updates.
a. Select Configuration > Application Delivery > Global Traffic Redirection.
b. In the Distributed Site State Protocol (DSSP) tab, set the Version field to DSSP Version 4.
3. Configure and enable the local real server.
a. Select Configuration > Application Delivery > Server Resources > Real Servers.
Note: The real server ID must exist before you can configure the service ports for the real
server.
e. (Optional) In the Description field, type a description of up to 31 characters for the real
server.
f. Set the Server Type option to one of the following:
Local (default)The real server does not participate in GSLB.
RemoteThe real server participates in GSLB.
WAN LinkThe real server connects the internal network to an ISP link.
g. Set the IP Version option to IPv4 (default) or IPv6.
IPv6 increases the number of addresses available for networked devices.
h. In the Server IP Address field, type the IP address for the real server.
i. Click Submit.
The new real server displays in the Real Servers table.
In this example, we use the following values:
b. In the Server Groups table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In the Group Settings tab, set the Health Check option to the match the type of content
you want to examine during health checks.
The default value is tcp.
d. Click Submit.
b. In the Server Groups table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In the Real Servers tab, select a real server ID and use the arrows to move the server
between the Available and Selected lists.
d. Click Submit.
In this example, we use the following values:
7. Configure server load processing for each type of Level 4 traffic per port.
a. Select Configuration > Application Delivery > Port Processing.
b. In the Port Processing table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays
c. Select Client, Server, or Proxy (Client NAT).
d. Click Submit.
In this example, we use the following values:
h. (Optional) In the Source Network field, select the source network for the virtual server
from the drop-down list.
i. Click Submit.
The new virtual server displays in the Virtual Servers table.
In this example, we use the following values:
b. In the Virtual Servers table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. Select the Virtual Services tab.
d. In the Virtual Services table, do one of the following:
Select a table row and click to edit an entry. The relevant Edit tab displays.
Alternatively, you can double-click the table row you want to edit.
e. In the Application field, select the application type for the virtual service from the drop-
down list.
f. In the Action field, select Group as the action type of this virtual service when no match is
found in the HTTP content rule.
g. In the Group ID field, select a real server group from the drop-down list.
h. Click Submit.
In this example, we use the following values:
b. In the Virtual Servers table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. Select the Global Server Load Balancing tab.
d. In the Domain Name field, type the domain name for the service.
The domain name typically includes the name of the company or organization, and the
Internet group code (.com, .edu, .gov, .org, and so on). For example, foocorp.com.
It does not include the hostname portion (www, www2, ftp, and so on).
Values: 164 alphanumeric characters.
e. Click Submit.
In this example, we use the following values:
i. In the Secondary IP Address field, type the IP address for the secondary server.
j. Click Submit.
In this example, we use the following values:
14. Create a static entry for each remote site with local VIP as the closest site. This prevents client
proximity calculation for health check packets.
a. Select Configuration > Application Delivery > Global Traffic Redirection > DNS
Redirection Rules > Client Network Rules.
h. In the Virtual Servers table, click to add a virtual server to the network.
From the Virtual Server ID drop-down list, select the server to add to the network.
In the Preference field, type a preference value for the virtual server.
Valid values are in the range 165535.
The default value is 65535.
Click Submit.
i. In the Real Servers table, click to add a real server to the network.
From the Real Server ID drop-down list, select the server to add to the network.
In the Preference field, type a preference value for the real server.
Valid values are in the range 165535.
The default value is 65535.
Click Submit.
j. Configure a static entry for client network 20.0.0.0.
In this example, we use the following values:
To configure Site A
1. Enable Direct Access mode.
a. Select Configuration > Application Delivery > Virtual Services > Settings.
b. Select Enable SLB to enable server load balancing on the Alteon platform.
c. Set the Direct Access Mode option to Enable.
d. Click Submit.
2. Set DSSP to version 4 for client proximity updates.
a. Select Configuration > Application Delivery > Global Traffic Redirection.
b. In the Distributed Site State Protocol (DSSP) tab, set the Version field to DSSP Version 4.
3. Configure and enable the local real server.
a. Select Configuration > Application Delivery > Server Resources > Real Servers.
Note: The real server ID must exist before you can configure the service ports for the real
server.
e. (Optional) In the Description field, type a description of up to 31 characters for the real
server.
f. Set the Server Type option to one of the following:
Local (default)The real server does not participate in GSLB.
RemoteThe real server participates in GSLB.
WAN LinkThe real server connects the internal network to an ISP link.
g. Set the IP Version option to IPv4 (default) or IPv6.
IPv6 increases the number of addresses available for networked devices.
h. In the Server IP Address field, type the IP address for the real server.
i. Click Submit.
The new real server displays in the Real Servers table.
In this example, we use the following values:
b. In the Server Groups table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In the Group Settings tab, set the Health Check option to the match the type of content
you want to examine during health checks.
The default value is tcp.
d. Click Submit.
In this example, we use the following values:
b. In the Server Groups table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In the Real Servers tab, select a real server ID and use the arrows to move the server
between the Available and Selected lists.
d. Click Submit.
In this example, we use the following values:
7. Configure server load processing for each type of Level 4 traffic per port.
a. Select Configuration > Application Delivery > Port Processing.
b. In the Port Processing table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays
c. Select Client, Server, or Proxy (Client NAT).
d. Click Submit.
In this example, we use the following values:
b. In the Virtual Servers table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. Select the Virtual Services tab.
d. In the Virtual Services table, do one of the following:
Select a table row and click to edit an entry. The relevant Edit tab displays.
Alternatively, you can double-click the table row you want to edit.
e. In the Application field, select the application type for the virtual service from the drop-
down list.
f. In the Action field, select Group as the action type of this virtual service when no match is
found in the HTTP content rule.
g. In the Group ID field, select a real server group from the drop-down list.
h. Click Submit.
In this example, we use the following values:
b. In the Virtual Servers table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. Select the Global Server Load Balancing tab.
d. In the Domain Name field, type the domain name for the service.
The domain name typically includes the name of the company or organization, and the
Internet group code (.com, .edu, .gov, .org, and so on). For example, foocorp.com.
It does not include the hostname portion (www, www2, ftp, and so on).
Values: 164 alphanumeric characters.
e. Click Submit.
In this example, we use the following values:
14. Create a static entry for each remote site with local VIP as the closest site. This prevents client
proximity calculation for health check packets.
a. Select Configuration > Application Delivery > Global Traffic Redirection > DNS
Redirection Rules > Client Network Rules.
h. In the Virtual Servers table, click to add a virtual server to the network.
From the Virtual Server ID drop-down list, select the server to add to the network.
In the Preference field, type a preference value for the virtual server.
Valid values are in the range 165535.
The default value is 65535.
Click Submit.
i. In the Real Servers table, click to add a real server to the network.
From the Real Server ID drop-down list, select the server to add to the network.
In the Preference field, type a preference value for the real server.
Valid values are in the range 165535.
The default value is 65535.
Click Submit.
j. Configure a static entry for client network 20.0.0.0.
In this example, we use the following values:
To configure Site B
1. Enable Direct Access mode.
a. Select Configuration > Application Delivery > Virtual Services > Settings.
b. Select Enable SLB to enable server load balancing on the Alteon platform.
c. Set the Direct Access Mode option to Enable.
d. Click Submit.
2. Set DSSP to version 4 for client proximity updates.
a. Select Configuration > Application Delivery > Global Traffic Redirection.
b. In the Distributed Site State Protocol (DSSP) tab, set the Version field to DSSP Version 4.
3. Configure and enable the local real server.
a. Select Configuration > Application Delivery > Server Resources > Real Servers.
The real server ID is used to determine to which port the server is connected.
Note: The real server ID must exist before you can configure the service ports for the real
server.
e. (Optional) In the Description field, type a description of up to 31 characters for the real
server.
f. Set the Server Type option to one of the following:
Local (default)The real server does not participate in GSLB.
RemoteThe real server participates in GSLB.
WAN LinkThe real server connects the internal network to an ISP link.
g. Set the IP Version option to IPv4 (default) or IPv6.
IPv6 increases the number of addresses available for networked devices.
h. In the Server IP Address field, type the IP address for the real server.
i. Click Submit.
The new real server displays in the Real Servers table.
In this example, we use the following values:
b. In the Server Groups table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In the Group Settings tab, set the Health Check option to the match the type of content
you want to examine during health checks.
The default value is tcp.
d. Click Submit.
In this example, we use the following values:
b. In the Server Groups table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In the Real Servers tab, select a real server ID and use the arrows to move the server
between the Available and Selected lists.
d. Click Submit.
In this example, we use the following values:
7. Configure server load processing for each type of Level 4 traffic per port.
a. Select Configuration > Application Delivery > Port Processing.
b. In the Port Processing table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays
c. Select Client, Server, or Proxy (Client NAT).
d. Click Submit.
In this example, we use the following values:
b. In the Virtual Servers table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. Select the Virtual Services tab.
d. In the Virtual Services table, do one of the following:
Select a table row and click to edit an entry. The relevant Edit tab displays.
Alternatively, you can double-click the table row you want to edit.
e. In the Application field, select the application type for the virtual service from the drop-
down list.
f. In the Action field, select Group as the action type of this virtual service when no match is
found in the HTTP content rule.
g. In the Group ID field, select a real server group from the drop-down list.
h. Click Submit.
In this example, we use the following values:
b. In the Virtual Servers table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. Select the Global Server Load Balancing tab.
d. In the Domain Name field, type the domain name for the service.
The domain name typically includes the name of the company or organization, and the
Internet group code (.com, .edu, .gov, .org, and so on). For example, foocorp.com.
It does not include the hostname portion (www, www2, ftp, and so on).
Values: 164 alphanumeric characters.
e. Click Submit.
In this example, we use the following values:
14. Create a static entry for each remote site with local VIP as the closest site. This prevents client
proximity calculation for health check packets.
a. Select Configuration > Application Delivery > Global Traffic Redirection > DNS
Redirection Rules > Client Network Rules.
h. In the Virtual Servers table, click to add a virtual server to the network.
From the Virtual Server ID drop-down list, select the server to add to the network.
In the Preference field, type a preference value for the virtual server.
Valid values are in the range 165535.
The default value is 65535.
Click Submit.
i. In the Real Servers table, click to add a real server to the network.
From the Real Server ID drop-down list, select the server to add to the network.
In the Preference field, type a preference value for the real server.
Valid values are in the range 165535.
The default value is 65535.
Click Submit.
j. Configure a static entry for client network 20.0.0.0.
In this example, we use the following values:
For the example, when Client X loads the browser and enters the URL www.company.com/products/
index.html, the system sends a DNS getHostByname query to the clients local DNS server for the
www.company.com IP address.
The following is the workflow for the example as shown Figure 67 - GSLB Client Proximity Site with
HTTP Service, page 539 using HTTP-based dynamic client proximity:
1. The Client X DNS requests the local DNS server to send the www.company.com IP address.
2. The local DNS server queries the upstream DNS server on Alteon.
3. The Site A Alteon receives a DNS request and acts as the authoritative DNS. Site A responds to
the DNS request with a Site A VIP address according to the DNS GSLB configured metric.
4. The client opens an HTTP application session with Alteon at Site A.
5. Site A receives the HTTP request and checks the client proximity entry. If a client proximity entry
does not exist, computation begins for this client network.
6. Alteon at Site A responds with three URL links. The Site A Alteon computes multi-trip time (RTT)
with the client from current connection and obtains remote sites RTT through DSSP updates.
The following are the URL links at Site A:
http://<Site A IP address>/products/index.html
http://<Site B IP address>/company_client_proximity_url
http://<Site C IP address>/company_client_proximity_url
7. Client X sends an HTTP request to Site A, Site B, and Site C. Client X establishes a TCP
connection with Site B and Site C, and sends a cntpurl request. Site B and C respond with a
dummy response and in the process compute the RTT of their TCP connections with the Client X.
Site B and Site C update the computed RTTs to Site A. On receiving RTT from Sites B and C, Site
A sends the consolidated RTT list to all sites.
8. At this time, Site A serves the request from the client.
9. During the next request from the Client X, Site A redirects the HTTP request to the closest RTT
site (Site C in this example).
10. Client X opens a new connection with Site C.
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: The Alteon lets you configure up to 128 preferred client networks. Each network can contain
up to 1023 real servers.
Note: The maximum number of preferred client networks that you can configure depends on the
type of platform and the number of CUs configured, as follows:
Standalone: 2048
Alteon VA: 2048
vADC with less than 11 CUs: 1024
vADC with 11 or more CUs: 2048
h. In the Virtual Servers table, click to add a virtual server to the network.
From the Virtual Server ID drop-down list, select the server to add to the network.
In the Preference field, type a preference value for the virtual server.
Valid values are in the range 165535.
The default value is 65535.
Click Submit.
i. In the Real Servers table, click to add a real server to the network.
From the Real Server ID drop-down list, select the server to add to the network.
In the Preference field, type a preference value for the real server.
Valid values are in the range 165535.
The default value is 65535.
Click Submit.
In this example, we use the following values:
b. In the DNS Redirection Rules table, select the default rule 1 and click , or double-click the
entry. The relevant Edit tab displays.
c. Select Enable DNS Redirection Rule.
d. In the DNS Redirection Metrics table, select Metric Index 1 and click , or double-click the
entry. The relevant Edit tab displays
e. Set the Metric Type drop-down list to Network.
f. In the Client Network Rule table, select the rules that you want to add to the metric and use
the arrows to move the contracts between the Available and Selected lists.
g. Click Submit.
In this example, we use the following values:
Using this configuration, the DNS request for company.com from client IP address
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.
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 69 - HTTP and Non-HTTP Redirects, page 561 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 1s 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 1s virtual server IP address
as the source IP address, and Site 2s proxy IP address as the destination IP address.
6. Alteon at Site 1 receives the frame and translates it, using Site 1s virtual server IP address as
the source IP address and the clients IP address as the destination IP address.
This cycle continues for the remaining frames to transmit all the clients 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. Configure a proxy IP address and associate it with a port.
a. Select Configuration > Network > Proxy IP.
b. Set the Proxy IP Associated to option to Ports or VLANs, as required.
c. In the Proxy IPv4 tab, click to add an entry. The relevant Add tab displays.
d. In the IP Address field, type the proxy IP address to which you want to add the port or
VLAN.
e. In the VLAN Range (or Port Range) table, select the VLANs or ports that you want to add to
the proxy IP address and use the arrows to move the VLANs or ports between the Available
and Selected lists.
f. Click Submit.
In this example, we use the following values:
b. In the Port Processing table, select port 6 and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
c. Select Proxy (Client NAT).
d. Click Submit.
b. In the Real Servers table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
c. In the Client NAT tab, set the Client NAT Mode option to No NAT.
d. Click Submit.
In this example, we use the following values:
b. In the Real Servers table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
c. In the Client NAT tab, set the Client NAT Mode option to Inherit.
d. Click Submit.
In this example, we use the following values:
For more information on proxy IP addresses, see Client Network Address Translation (Proxy IP),
page 235.
5. To configure proxy IP addresses on Site 2, use the following values on the Denver Alteon:
Figure 71 - Network with GSLB Configuration Behind NAT Devices, page 565 illustrates a
configuration where Alteons at Sites A and B are located behind NAT devices, and Alteon at Site C is
not.
Table 29 - GSLB Configuration Behind NAT Devices, page 565 summarizes the network
configuration.
b. In the Virtual Servers table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. From the IP Version drop-down list, select IPv4.
d. Click Submit.
In this example, we use the following values:
2. Add the service public IP address (NAT) of the device to the Alteon server.
a. Select the Global Server Load Balancing tab.
b. In the NAT Address field, type the public IP address (NAT) of the device.
c. Click Submit.
In this example, we use the following values:
b. In the Virtual Servers table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. From the IP Version drop-down list, select IPv6.
d. Click Submit.
In this example, we use the following values:
2. Add the service public IP address (NAT) of the device to the Alteon server.
In this example, we use the following values:
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 72 - Firewall Configuration with FWLB, page
571:
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 72 - Firewall Configuration with FWLB, page 571, 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 networksThis 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 572.
Four-Subnet FWLB for larger networksAlthough 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 585.
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 73 - Basic FWLB Topology, page 572 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 605), 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 585).
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.
7. Redirection filters on the clean-side Alteon balance responses among different IP addresses.
Redirection filters are needed on all ports on the clean-side Alteon that attach to real servers or
internal clients on the clean-side of the network. Filters on these ports redirect the Internet-
bound traffic to a real server group that consists of a number of different IP addresses. Each IP
address represents an IP interface on a different subnet on the dirty-side Alteon.
8. Outbound traffic is routed to the firewalls.
Static routes are configured on the clean-side Alteon. One static route is needed for each stream
that was configured on the dirty-side Alteon. For instance, the first static route is configured to
lead to the first dirty-side IP interface using the first firewall as the next hop. The second static
route leads to the second dirty-side IP interface using the second firewall as the next hop, and
so on.
Since Alteon intelligently maintains state information, all traffic between specific IP source or
destination addresses flows through the same firewall, maintaining session persistence.
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 605).
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.
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.
2. Define the dirty-side IP interface.
In addition to one IP interface for general Alteon management, there must be one dirty-side IP
interface for each firewall path being load balanced. Each must be on a different subnet.
a. Select Configuration > Network > Layer 3 > IP Interfaces.
b. In the IP Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the ID number for the interface.
d. In the IP Address field, type the IP address.
e. In the Mask field, type the subnet mask.
f. Select Enable IP Interface.
g. Click Submit.
h. Repeat until all IP Interfaces are configured and enabled.
In this example, we use the following values:
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 ID on both
sides of the firewall ensures that the traffic travels through the same firewall.
a. Select Configuration > Application Delivery > Server Resources > Real Servers.
b. In the Real Servers table, click to add an entry. The relevant Add tab displays.
c. In the Real Server ID field, type the ID for the real server.
d. In the Server IP Address field, type the IP address.
e. Select Enable Real Server.
f. Click Submit.
g. Repeat until all real servers are configured.
In this example, we use the following values:
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.
4. Place the IP interface real servers into a real server group.
a. Select Configuration > Application Delivery > Server Resources > Server Groups.
b. In the Server Groups table, click to add an entry. The relevant Add tab displays.
c. In the Server Group ID field, type an ID for the server group.
d. In the Real Servers tab, select the real server ID and use the arrows to move the ID
between the Available and Selected lists. Repeat until all real server IDs are selected.
e. Click Submit.
In this example, we use the following values:
5. Set the health check type and load balancing metric for the real server group.
a. Select Configuration > Application Delivery > Server Resources > Server Groups.
b. In the Server Groups table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
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 Least Connections, Round Robin, Min Misses,
Response Time, and Server Bandwidth can be used when enabling the transparent load
balancing option. For more information, see Free-Metric FWLB, page 605.
6. Create a filter to allow local subnet traffic on the dirty side of the firewalls to reach the firewall
interfaces.
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the filter ID.
d. In the Action field, select the action from the drop-down list.
e. Select Enable Filter.
f. Select the Match Settings tab.
g. In the Destination column of the IP Address/Network field, type the IP address.
h. In the Destination column of the Mask/Prefix field, type the subnet mask.
i. Click Submit.
In this example, we use the following values:
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the filter ID.
d. In the Action field, select the action from the drop-down list.
e. In the Group ID field, select the group from the drop-down list.
f. Select Enable Filter.
g. Select the Match Settings tab.
h. In the Protocol field, select the protocol from the drop-down list.
i. Click Submit.
In this example, we use the following values:
8. Enable FWLB.
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, select an entry and click , or double-click the entry you want to edit.
The relevant Edit tab displays.
c. Select the Action Settings tab.
d. In the Load Balancing Capabilities section, select Firewall LB.
e. Click Submit.
9. Firewall load balancing requires the by number mode of operation to be enabled.
10. Add filters to the ingress port.
a. Select Configuration > Network > Layer 3 > Static Routes.
b. In the Static Routes table, click to add an entry. The relevant Add tab displays.
c. In the Destination IP field, type the IP address.
d. In the Mask field, type the subnet mask.
e. In the Gateway field, type the IP address for the gateway.
f. Click Submit.
g. Repeat until all static routes are configured.
In this example, we use the following values:
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.
11. 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.
Note: An extra IP interface (IF 1) prevents server-to-server traffic from being redirected.
a. Select Configuration > Network > Layer 3 > IP Interfaces.
b. In the IP Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the ID number for the interface.
d. In the IP Address field, type the IP address.
e. In the Mask field, type the subnet mask.
f. Select Enable IP Interface.
g. Click Submit.
h. Repeat until all IP Interfaces are configured and enabled.
In this example, we use the following values:
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 ID on both
sides of the firewall ensures that the traffic travels through the same firewall.
a. Select Configuration > Application Delivery > Server Resources > Real Servers.
b. In the Real Servers table, click to add an entry. The relevant Add tab displays.
c. In the Real Server ID field, type the ID for the real server.
d. In the Server IP Address field, type the IP address.
e. Select Enable Real Server.
f. Click Submit.
g. Repeat until all real servers are configured.
In this example, we use the following values:
Note: Each of the four IP interfaces (two on each Alteon) in this example must be configured
for a different IP subnet.
3. Place the real servers into a real server group.
a. Select Configuration > Application Delivery > Server Resources > Server Groups.
b. In the Server Groups table, click to add an entry. The relevant Add tab displays.
c. In the Server Group ID field, type an ID for the server group.
d. In the Real Servers tab, select the real server ID and use the arrows to move the ID
between the Available and Selected lists. Repeat until all real server IDs are selected.
e. Click Submit.
In this example, we use the following values:
4. Set the health check type and load balancing metric for the real server group.
a. Select Configuration > Application Delivery > Server Resources > Server Groups.
b. In the Server Groups table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. Select the Group Settings tab.
d. In the SLB Metric field, select the load balancing metric to use for the server group from
the drop-down list.
e. In the Health Check field, select the health check to use for the server group from the
drop-down list.
f. Click Submit.
In this example, we use the following values:
Note: The clean-side Alteon must use the same metric as defined on the dirty side.
5. Configure ports 2 and 3, which are connected to the clean-side of the firewalls, for client
processing.
a. Select Configuration > Application Delivery > Port Processing.
b. In the Port Processing table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In Port Processing Settings, select Client.
d. Click Submit.
6. Configure the virtual server that will load balance the real servers.
a. Select Configuration > Application Delivery > Virtual Services.
b. In the Virtual Servers table, click to add an entry. The relevant Add tab displays.
c. In the Virtual Server ID field, type the ID for the virtual server.
d. In the IP Address field, type the IP address.
e. Select Enable Virtual Server.
f. Click Submit.
g. Repeat until all virtual servers are configured.
In this example, we use the following values:
7. Configure the real servers to which traffic will be load balanced. These are the real servers on
the network.
a. Select Configuration > Application Delivery > Server Resources > Real Servers.
b. In the Real Server table, click to add an entry. The relevant Add tab displays.
c. In the Real Server ID field, type the ID for the real server.
d. In the Server IP Address field, type the IP address.
e. Select Enable Real Server.
f. Click Submit.
g. Repeat until all real servers are configured.
In this example, we use the following values:
b. In the Server Groups table, click to add an entry. The relevant Add tab displays.
c. In the Server Group ID field, type the ID for the server group.
d. In the Real Servers tab, select a real server ID and use the arrows to move the ID between
the Available and Selected lists. Repeat until all real server IDs are selected.
e. Click Submit.
In this example, we use the following values:
9. Configure ports 4 and 5, which are connected to the real servers, for server processing.
a. Select Configuration > Application Delivery > Port Processing.
b. In the Port Processing table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In Port Processing Settings, select Server.
d. Click Submit.
e. Repeat until all ports are configured with the correct processing type.
In this example, we use the following values:
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the filter ID.
d. In the Action field, select the action from the drop-down list.
e. Select Enable Filter.
f. Select the Match Settings tab.
g. In the Protocol field, select the protocol from the drop-down list.
h. In the Destination column of the IP Address/Network field, type the IP address.
i. In the Destination column of the Mask/Prefix field, type the subnet mask.
j. Click Submit.
In this example, we use the following values:
11. 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.
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the filter ID.
d. In the Action field, select the action from the drop-down list.
e. In the Group ID field, select the group from the drop-down list.
f. Select Enable Filter.
g. Select the Match Settings tab.
h. In the Protocol field, select the protocol from the drop-down list.
i. Click Submit.
In this example, we use the following values:
12. 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.
a. Select Configuration > Application Delivery > Port Processing.
b. In the Port Processing table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In Port Processing Settings, select Filter/Outbound LLB.
d. Select the rule ID and use the arrows to move the rule between the Available and
Selected lists. Repeat until all rules are selected.
e. Click Submit.
In this example, we use the following values:
13. 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.
a. Select Configuration > Network > Layer 3 > Static Routes.
b. In the Static Routes table, click to add an entry. The relevant Add tab displays.
c. In the Destination IP field, type the destination IP address.
d. In the Mask field, type the subnet mask.
e. In the Gateway field, type the gateway IP address.
f. Click Submit.
In this example, we use the following values:
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 76 - Four-Subnet FWLB Network Topology, page 585 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 76 - Four-Subnet FWLB Network Topology, page 585, 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 FWLBa 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 605).
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.
Four-subnet FWLB configuration includes the following procedures:
Configure routers and firewalls and test them for proper operation, as explained in Configure the
Routers, page 588 and Configure the Firewalls, page 588.
Configure VLANs, IP interfaces, and static routes on all Alteons and test them, as explained in:
Configure the Primary Dirty-Side Alteon, page 588Configure FWLB groups and redirection
filters on the primary dirty-side Alteon.
Configure the Secondary Dirty-Side Alteon, page 591Configure and synchronize VRRP on
the primary dirty-side Alteon.
Configure the Primary Clean-Side Alteon, page 593Configure FWLB and SLB groups, and
add FWLB redirection filters on the primary clean-side Alteon.
Configure the Secondary Clean-Side Alteon, page 594Configure VRRP on the primary
clean-side Alteon and synchronize the secondary.
Verify Proper Connectivity, page 596
Configure secondary Alteons with VRRP support settings, as explained in:
Configure VRRP on the Secondary Dirty-Side Alteon, page 596
Configure VRRP on the Secondary Clean-Side Alteon, page 597
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.
b. In the VLAN table, click to add an entry. The relevant Add tab displays.
c. In the VLAN ID field, type an ID for the VLAN.
d. In the VLAN Settings tab, select a port ID and use the arrows to move the port ID between
the Available and Selected lists. Repeat until all ports are configured.
e. Select Enable VLAN.
f. Click Submit.
In this example, we use the following values:
Note: Port 25 is part of VLAN 1 by default and does not require manual configuration.
2. Configure IP interfaces on the primary dirty-side Alteon.
Three IP interfaces (IFs) are used. IF 1 is on placed on Subnet 1. IF 2 is used for routing traffic
through the top firewall. IF 3 is used for routing traffic through the lower firewall. To avoid
confusion, IF 2 and IF 3 are used in the same way on all Alteons.
a. Select Configuration > Network > Layer 3 > IP Interfaces.
b. In the IP Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the ID for the interface.
d. In the IP Address field, type the IP address.
e. Int he Mask field, type the subnet mask.
f. In the VLAN field, select the VLAN from the drop-down list, if needed.
g. Select Enable IP Interface.
h. Click Submit.
i. Repeat until all IP interfaces are configured.
In this example, we use the following values:
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.
a. Select Configuration > Network > Layer 2 > Spanning Tree > Spanning Tree Group.
b. In the Spanning Tree Group table, select an entry and click , or double-click the entry you
want to edit. The relevant Edit tab displays.
c. Select Enable Spanning Tree Group so that the option does not have a check mark.
d. Click Submit.
4. Configure static routes on the primary dirty-side Alteon.
Four static routes are required:
To primary clean-side IF 2 via Firewall 1 using dirty-side IF 2
To primary clean-side IF 3 via Firewall 2 using dirty-side IF 3
To secondary clean-side IF 2 via Firewall 1 using dirty-side IF 2
To secondary clean-side IF 3 via Firewall 2 using dirty-side IF 3
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.
This example requires the following static route configuration:
a. Select Configuration > Network > Layer 3 > Static Routes.
For IPv4:
In the Static Routes table, click to add an entry. The relevant Add tab displays.
In the Destination IP field, type the IP Address.
In the Mask field, type the subnet mask.
In the Gateway field, type the gateway IP address.
In Interface field, type the interface number.
For IPv6:
In the IPv6 Static Routes table, click to add an entry. The relevant Add tab displays.
In the Destination IP field, type the IP Address.
In the Mask field, type the subnet mask.
In the Gateway field, type the gateway IP address.
In VLAN field, type the interface number.
b. Click Submit.
c. Repeat until all routes are configured.
In this example, we use the following values:
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.
a. Select Configuration > Network > Layer 3 > Gateways.
b. In the Gateways table, click to add an entry. The relevant Add tab displays.
c. In the Gateway ID field, type an ID for the gateway.
d. In the IP Address field, type an IP address.
e. Select Enable Gateway.
f. Click Submit.
g. Repeat until all gateways are configured.
In this example, we use the following values:
Gateway ID IP Address
1 195.1.1.1
2 195.1.1.2
b. In the VLAN table, click to add an entry. The relevant Add tab displays.
c. In the VLAN ID field, type the ID for the VLAN.
d. In the VLAN Settings tab, select a port ID and use the arrows to move the port ID between
the Available and Selected lists. Repeat until all port IDs are configured for the VLAN.
e. Select Enable VLAN.
f. Click Submit.
In this example, we use the following values:
b. In the IP Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the ID for the interface.
d. In the IP Address field, type the IP address.
e. In the Mask field, type the subnet mask.
f. In the VLAN field, select the VLAN ID from the drop-down list, if required.
g. Select Enable IP Interface.
h. Click Submit.
b. In the Spanning Tree Group table, select an entry and click , or double-click the entry you
want to edit. The relevant Edit tab displays.
c. Select Enable Spanning Group Tree, so that the option is no longer check marked.
d. Click Submit.
4. Configure static routes on the secondary dirty-side Alteon.
a. Select Configuration > Network > Layer 3 > Static Routes.
For IPv4:
In the Static Routes table, click to add an entry. The relevant Add tab displays.
In the Destination IP field, type the IP Address.
In the Mask field, type the subnet mask.
In the Gateway field, type the gateway IP address.
In Interface field, type the interface number.
For IPv6:
In the IPv6 Static Routes table, click to add an entry. The relevant Add tab displays.
In the Destination IP field, type the IP Address.
In the Mask field, type the subnet mask.
In the Gateway field, type the gateway IP address.
In VLAN field, type the interface number.
b. Click Submit.
c. Repeat until all routes are configured.
In this example, we use the following values:
5. When dynamic routing protocols are not used, configure a gateway to the external routers on
the secondary dirty-side Alteon.
a. Select Configuration > Network > Layer 3 > Gateways.
b. In the Gateways table, click to add an entry. The relevant Add tab displays.
c. In the Gateway ID field, type an ID for the gateway.
d. In the IP Address field, type an IP address.
e. Select Enable Gateway.
f. Click Submit.
g. Repeat until all gateways are configured.
In this example, we use the following values:
Gateway ID IP Address
1 195.1.1.1
2 195.1.1.2
b. In the VLAN table, click to add an entry. The relevant Add tab displays.
c. In the VLAN ID field, type the ID for the VLAN.
d. In the VLAN Settings tab, select a port ID and use the arrows to move the port ID between
the Available and Selected lists. Repeat until all port IDs are configured for the VLAN.
e. Select Enable VLAN.
f. Click Submit.
In this example, we use the following values:
b. In the IP Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the ID for the interface.
d. In the IP Address field, type the IP address.
e. In the Mask field, type the subnet mask.
f. In the VLAN field, select the VLAN ID from the drop-down list, if required.
g. Select Enable IP Interface.
h. Click Submit.
i. Repeat until all IP Interfaces are configured.
In this example, we use the following values:
b. In the Spanning Tree Group table, select an entry and click , or double-click the entry you
want to edit. The relevant Edit tab displays.
c. Select Enable Spanning Group Tree, so that the option is no longer check marked.
d. Click Submit.
Spanning Tree Protocol is disabled because VLANs prevent broadcast loops.
4. Configure static routes on the primary clean-side Alteon.
Four static routes are needed:
To primary dirty-side IF 2 via Firewall 1 using clean-side IF 2
To primary dirty-side IF 3 via Firewall 2 using clean-side IF 3
To secondary dirty-side IF 2 via Firewall 1 using clean-side IF 2
To secondary dirty-side IF 3 via Firewall 2 using clean-side IF 3
This example requires the following static route configuration:
a. Select Configuration > Network > Layer 3 > Static Routes.
For IPv4:
In the Static Routes table, click to add an entry. The relevant Add tab displays.
In the Destination IP field, type the IP Address.
In the Mask field, type the subnet mask.
In the Gateway field, type the gateway IP address.
In Interface field, type the interface number.
For IPv6:
In the IPv6 Static Routes table, click to add an entry. The relevant Add tab displays.
In the Destination IP field, type the IP Address.
In the Mask field, type the subnet mask.
In the Gateway field, type the gateway IP address.
In VLAN field, type the interface number.
b. Click Submit.
c. Repeat until all routes are configured.
In this example, we use the following values:
b. In the VLAN table, click to add an entry. The relevant Add tab displays.
c. In the VLAN ID field, type the ID for the VLAN.
d. In the VLAN Settings tab, select a port ID and use the arrows to move the port ID between
the Available and Selected lists. Repeat until all port IDs are configured for the VLAN.
e. Select Enable VLAN.
f. Click Submit.
In this example, we use the following values:
b. In the IP Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the ID for the interface.
d. In the IP Address field, type the IP address.
e. In the Mask field, type the subnet mask.
f. In the VLAN field, select the VLAN ID from the drop-down list, if required.
g. Select Enable IP Interface.
h. Click Submit.
i. Repeat until all IP Interfaces are configured.
In this example, we use the following values:
b. In the Spanning Tree Group table, select an entry and click , or double-click the entry you
want to edit. The relevant Edit tab displays.
c. Select Enable Spanning Group Tree, so that the option is no longer check marked.
d. Click Submit.
Spanning Tree Protocol is disabled because VLANs prevent broadcast loops.
In the Static Routes table, click to add an entry. The relevant Add tab displays.
In the Destination IP field, type the IP Address.
In the Mask field, type the subnet mask.
In the Gateway field, type the gateway IP address.
In Interface field, type the interface number.
For IPv6:
In the IPv6 Static Routes table, click to add an entry. The relevant Add tab displays.
In the Destination IP field, type the IP Address.
In the Mask field, type the subnet mask.
In the Gateway field, type the gateway IP address.
In VLAN field, type the interface number.
b. Click Submit.
c. Repeat until all routes are configured.
In this example, we use the following values:
2. In the Peers tab, click to add an entry. The relevant Add tab displays.
3. In the Peer ID field, type the ID for the peer.
4. In the IP Address field, type the IP address.
5. Select Enable Peer.
6. Click Submit.
In this example, we use the following values:
Peer ID IP Address
1 195.1.1.10
2. In the Peers tab, click to add an entry. The relevant Add tab displays.
3. In the Peer ID field, type the ID for the peer.
4. In the IP Address field, type the IP address.
5. Select Enable Peer.
6. Click Submit.
In this example, we use the following values:
Peer ID IP Address
1 10.10.4.10
b. In the Real Server table, click to add an entry. The relevant Add tab displays.
c. In the Real Server ID field, type the ID for the real server.
d. In the Server IP Address field, type the IP address.
e. Select Enable Real Server.
f. Click Submit.
g. Repeat until all real servers are configured.
In this example, we use the following values:
b. In the Server Groups table, click to add an entry. The relevant Add tab displays.
c. In the Server Group ID field, type the ID for the server group.
d. In the Real Servers tab, select a real server ID and use the arrows to move the real server
ID between the Available and Selected lists. Repeat until all real servers are configured for
the group.
e. In the Group Settings tab, select the metric to use from the drop-down list in the SLB
Metric field.
f. Click Submit.
In this example, we use the following values:
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 Least Connections, Round Robin, Min Misses,
Response Time, and Server Bandwidth can be used when enabling the transparent load
balancing option. For more information, see Free-Metric FWLB, page 605.
4. Create the FWLB filters.
Three filters are required on the port attaching to the routers:
Filter 10 prevents local traffic from being redirected.
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.
5. Configure filters.
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the ID for the filter.
d. In the Action field, select the action from the drop-down list, if required.
e. In the Group field, select the group from the drop-down list. This field displays if Redirect
is selected in the Action field.
f. Select the Match Settings tab.
g. In the Destination column of the IP Address/Network field, type the IP address.
h. In the Destination column of the Mask/Prefix field, type the subnet mask.
i. Select Enable Filter.
j. Click Submit.
b. In the Port Processing table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In Port Processing Settings, select Filter/Outbound LLB.
d. Select the filter IDs and use the arrows the arrows to move the filters between the
Available and Selected lists. Repeat until all filters are configured for the port.
e. Click Submit.
In this example, we use the following values:
7. 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.
a. Select Configuration > Network > High Availability > Legacy VRRP > Virtual
Routers.
b. In the Virtual Routers table, click to add an entry. The relevant Add tab displays.
c. In the Router ID field, type the ID for the virtual router.
d. In the VR ID field, type the ID to use for the virtual router table index.
e. In the IP Address field, type an IP address.
f. In the Interface field, select an interface the virtual router is representing from the drop-
down list.
g. In the Priority field, type the priority value for the virtual router.
h. In the Tracking tab, select the individual tracking parameters required.
i. In the Tracking Sharing field, select whether to enable load sharing of non-master virtual
routers.
j. Select Enable Virtual Routers.
k. Click Submit.
l. Repeat until all virtual routers are configured.
In this example, we use the following values:
d. In the Peers table, click to add an entry. The relevant Add tab displays.
e. In the Peer ID field, type the ID for the peer.
f. In the IP Address field, type the IP address for the peer.
g. Select Enable Peer.
h. Click Submit.
In this example, we use the following values:
Peer ID IP Address
1 195.1.1.11
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.
2. Configure real servers.
a. Select Configuration > Application Delivery > Server Resources > Real Servers.
b. In the Real Servers table, click to add an entry. The relevant Add tab displays.
c. In the Real Server ID field, type the ID for the real server.
d. In the Server IP Address field, type the IP address for the real server.
e. Select Enable Real Server.
f. Click Submit.
g. Repeat until all real servers are configured.
In this example, we use the following values:
a. In the Server Groups table, click to add an entry. The relevant Add tab displays.
b. In the Server Group ID field, type the ID for the server group.
c. In the Real Servers tab, select the real server ID and use the arrows to move the real server
ID between the Available and Selected lists. Repeat until all real servers are configured for
the server group.
d. In the Group Settings tab, select the required metric from the drop-down list in the SLB
Metric field.
e. Click Submit.
In this example, we use the following values:
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 605.
4. 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:
5. Configure real servers.
a. Select Configuration > Application Delivery > Server Resources > Real Servers.
b. In the Real Servers table, click to add an entry. The relevant Add tab displays.
c. In the Real Server ID field, type the ID for the real server.
d. In the Server IP Address field, type the IP address for the real server.
e. Select Enable Real Server.
f. Click Submit.
g. Repeat until all real servers are configured.
In this example, we use the following values:
a. In the Server Groups table, click to add an entry. The relevant Add tab displays.
b. In the Server Group ID field, type the ID for the server group.
c. In the Real Servers tab, select the real server ID and use the arrows to move the real server
ID between the Available and Selected lists. Repeat until all real servers are configured for
the server group.
d. In the Group Settings tab, select the required metric from the drop-down list in the SLB
Metric field.
e. Click Submit.
In this example, we use the following values:
b. In the Virtual Servers table, click to add an entry. The relevant Add tab displays.
c. In the Virtual Server ID field, type the ID for the virtual server.
d. In the IP Address field, type the IP address for the virtual server.
e. Select the Virtual Services tab.
f. In the Virtual Services table, click to add an entry. The relevant Add tab displays.
g. In the Application field, select the required application from the drop-down list.
h. In the Service Port field, type the port to use.
i. In the Group ID field, select the group from the drop-down list.
j. Select Enable Virtual Server.
k. Click Submit.
In this example, we use the following values:
b. In the Port Processing table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In Port Processing Settings, select the required parameter.
d. Click Submit.
e. Repeat until all ports are configured.
In this example, we use the following values:
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.
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the ID for the filter.
d. In the Action field, select the action from the drop-down list, if required.
e. In the Group field, select the group from the drop-down list. This field displays if Redirect
is selected in the Action field.
f. Select the Match Settings tab.
g. In the Destination column of the IP Address/Network field, type the IP address.
h. In the Destination column of the Mask/Prefix field, type the subnet mask.
i. Select Enable Filter.
j. Click Submit.
k. Repeat until all filters are configured.
In this example, we use the following values:
b. In the Port Processing table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In Port Processing Settings, select Filter/Outbound LLB.
d. Select the filter IDs and use the arrows the arrows to move the filters between the
Available and Selected lists. Repeat until all filters are configured for the port.
e. Click Submit.
In this example, we use the following values:
b. In the Virtual Routers table, click to add an entry. The relevant Add tab displays.
13. A third virtual router is required for the virtual server used for optional SLB.
a. Select Configuration > Network > High Availability > Legacy VRRP > Virtual
Routers.
b. In the Virtual Routers table, click to add an entry. The relevant Add tab displays.
c. In the Router ID field, type the ID for the virtual router.
d. In the VR ID field, type the ID to use for the virtual router table index.
e. In the IP Address field, type an IP address.
f. In the Interface field, select an interface the virtual router is representing from the drop-
down list.
g. In the Priority field, type the priority value for the virtual router.
h. In the Tracking tab, select the individual tracking parameters required.
i. In the Tracking Sharing field, select whether to enable load sharing of non-master virtual
routers.
j. Select Enable Virtual Routers.
k. Click Submit.
In this example, we use the following values:
d. In the Peers table, click to add an entry. The relevant Add tab displays.
e. In the Peer ID field, type the ID for the peer.
f. In the IP Address field, type the IP address for the peer.
g. Select Enable Peer.
h. Click Submit.
In this example, we use the following values:
Peer ID IP Address
1 10.10.4.11
Free-Metric FWLB
Free-metric FWLB lets you use load balancing metrics other than hash, such as Least Connections,
Round Robin, Min Misses, Response Time, and Server 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.
Speed Duplex
Any Any
Idle Timeout
10080
b. In the Port Settings table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
c. In the Port Settings tab, type the port VLAN ID in the PVID field.
d. Click Submit.
e. Repeat until all VLANs per port are configured.
In this example, we use the following values:
Port PVID
1 2
2 3
b. In the VLAN table, click to add an entry. The relevant Add tab displays.
c. In the VLAN ID field, type the ID for the VLAN.
d. In the VLAN Settings tab, select the ports and use the arrows to move the ports between the
Available and Selected lists. Repeat until all ports are configured for the VLAN.
e. In the Source MAC Learning field, select whether MAC address learning is enabled.
f. Select Enable VLAN.
g. Click Submit.
In this example, we use the following values:
b. In the VLAN table, click to add an entry. The relevant Add tab displays.
c. In the VLAN ID field, type the ID for the VLAN.
d. In the VLAN Name field, type a common name to use for the VLAN.
e. In the VLAN Settings tab, select the ports and use the arrows to move the ports between the
Available and Selected lists. Repeat until all ports are configured for the VLAN.
f. In the Source MAC Learning field, select whether MAC address learning is enabled.
g. Select Enable VLAN.
h. Click Submit.
In this example, we use the following values:
b. In the VLAN table, click to add an entry. The relevant Add tab displays.
c. In the VLAN ID field, type the ID for the VLAN.
d. In the VLAN Name field, type a common name to use for the VLAN.
e. In the VLAN Settings tab, select the ports and use the arrows to move the ports between the
Available and Selected lists. Repeat until all ports are configured for the VLAN.
f. In the Source MAC Learning field, select whether MAC address learning is enabled.
g. Select Enable VLAN.
h. Click Submit.
In this example, we use the following values:
b. In the Spanning Tree Group table, select an entry and click , or double-click the entry you
want to edit. The relevant Edit tab displays.
c. In the Advanced tab, select the VLAN and use the arrows to move the VLAN between the
Available and Selected lists. Repeat until all VLANs are configured.
d. Click Submit.
In this example, we use the following values:
Selected VLANs
1, 2, 3
b. In the IP Interfaces table, click to add an entry. The relevant Add tab displays.
b. In the Static Routes table, click to add an entry. The relevant Add tab displays.
c. In the Destination IP field, type the destination IP address.
d. In the Mask field, type the subnet mask.
e. In the Gateway field, type the gateway IP address.
f. In the Interface field, type the IP interface ID.
g. Click Submit.
h. Repeat until all routes are configured.
In this example, we use the following values:
b. In the Real Servers table, click to add an entry. The relevant Add tab displays.
c. In the Real Server ID field, type the identifier for the real server.
d. In the IP Version field, select the IP version from the drop-down list.
e. In the Server IP Address field, type the IP address for the real server.
f. Select Enable Real Server.
g. Click Submit.
h. Repeat until all real servers are configured.
In this example, we use the following values:
b. In the Server Groups table, click to add an entry. The relevant Add tab displays.
c. In the Server Group ID field, type the identifier for the server group.
d. In the IP Version field, select the IP version from the drop-down list.
e. In the Group Settings tab, select the metric for the server group from the drop-down list in
the SLB Metric field.
f. In the Health Check field, select the check method from the drop-down list.
g. In the Real Servers tab, select a real server and use the arrows to move the ID between the
Available and Selected lists. Repeat until all real servers are configured for the real server
group.
h. Click Submit.
In this example, we use the following values:
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the identifier for the filter.
d. In the Action field, select the filter action from the drop-down list.
e. In the Group ID field, select the group from the drop-down list, if required.
In this example, we use the following values:
Filter ID Real Server Port Return to Last Reverse Session Load Balancing
Hop Capabilities
10 0 (default) (default) (default)
15 0 Enable Disable Firewall LB
b. In the Port Processing table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In Port Processing Settings, select Filter/Outbound LLB.
d. Select a filter ID and use the arrows to move the ID between the Available and Selected
lists. Repeat until all filters are selected.
e. Click Submit.
In this example, we use the following values:
Speed Duplex
Any Any
Idle Timeout
10080
b. In the Port Settings table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
c. In the Port Settings tab, type the port VLAN ID in the PVID field.
d. Click Submit.
e. Repeat until all VLANs per port are configured.
In this example, we use the following values:
Port PVID
1 4
2 5
6 6
5. Enable RTS on the ports attached to the firewalls (ports 1 and 2), and enable filter and server
processing so that responses from the real server are looked up in the session table.
a. Select Configuration > Application Delivery > Port Processing.
b. In the Port Processing table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In Port Processing Settings, select the required settings.
d. Click Submit.
b. In the VLAN table, click to add an entry. The relevant Add tab displays.
c. In the VLAN ID field, type the ID for the VLAN.
d. In the VLAN Settings tab, select the ports and use the arrows to move the ports between the
Available and Selected lists. Repeat until all ports are configured for the VLAN.
e. In the Source MAC Learning field, select whether MAC address learning is enabled.
f. Select Enable VLAN.
g. Click Submit.
In this example, we use the following values:
b. In the VLAN table, click to add an entry. The relevant Add tab displays.
c. In the VLAN ID field, type the ID for the VLAN.
d. In the VLAN Name field, type a common name to use for the VLAN.
e. In the VLAN Settings tab, select the ports and use the arrows to move the ports between the
Available and Selected lists. Repeat until all ports are configured for the VLAN.
f. In the Source MAC Learning field, select whether MAC address learning is enabled.
g. Select Enable VLAN.
h. Click Submit.
In this example, we use the following values:
b. In the VLAN table, click to add an entry. The relevant Add tab displays.
c. In the VLAN ID field, type the ID for the VLAN.
d. In the VLAN Name field, type a common name to use for the VLAN.
e. In the VLAN Settings tab, select the ports and use the arrows to move the ports between the
Available and Selected lists. Repeat until all ports are configured for the VLAN.
f. In the Source MAC Learning field, select whether MAC address learning is enabled.
b. In the VLAN table, click to add an entry. The relevant Add tab displays.
c. In the VLAN ID field, type the ID for the VLAN.
d. In the VLAN Name field, type a common name to use for the VLAN.
e. In the VLAN Settings tab, select the ports and use the arrows to move the ports between the
Available and Selected lists. Repeat until all ports are configured for the VLAN.
f. In the Source MAC Learning field, select whether MAC address learning is enabled.
g. Select Enable VLAN.
h. Click Submit.
In this example, we use the following values:
b. In the Spanning Tree Group table, select an entry and click , or double-click the entry you
want to edit. The relevant Edit tab displays.
c. In the Advanced tab, select the VLAN and use the arrows to move the VLAN between the
Available and Selected lists. Repeat until all VLANs are configured.
d. Click Submit.
In this example, we use the following values:
Selected VLANs
1, 4, 5, 6
b. In the IP Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the ID for the interface.
d. In the IP Version field, select the IP version from the drop-down list.
e. In the IP Address field, type the IP address for the interface.
f. In the Mask field, type the subnet mask, if required.
g. In the VLAN field, select the VLAN from the drop-down list, if required.
h. Select Enable IP Interface.
i. Click Submit.
b. In the Static Routes table, click to add an entry. The relevant Add tab displays.
c. In the Destination IP field, type the destination IP address.
d. In the Mask field, type the subnet mask.
e. In the Gateway field, type the gateway IP address.
f. In the Interface field, type the IP interface ID.
g. Click Submit.
h. Repeat until all routes are configured.
In this example, we use the following values:
b. In the Real Servers table, click to add an entry. The relevant Add tab displays.
c. In the Real Server ID field, type the identifier for the real server.
d. In the IP Version field, select the IP version from the drop-down list.
e. In the Server IP Address field, type the IP address for the real server.
f. Select Enable Real Server.
g. Click Submit.
h. Repeat until all real servers are configured.
In this example, we use the following values:
b. In the Server Groups table, click to add an entry. The relevant Add tab displays.
c. In the Server Group ID field, type the identifier for the server group.
d. In the IP Version field, select the IP version from the drop-down list.
e. In the Group Settings tab, select the metric for the server group from the drop-down list in
the SLB Metric field.
f. In the Real Servers tab, select a real server and use the arrows to move the ID between the
Available and Selected lists. Repeat until all real servers are configured for the real server
group.
g. Click Submit.
In this example, we use the following values:
b. In the Port Processing table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In Port Processing Settings, select the required setting.
d. Click Submit.
e. Repeat until all ports are configured.
In this example, we use the following values:
16. Add filters to Alteon network ports. To ensure that return packets traverse the same firewall
through which they were sent, do not add the redirection filter (filter 15see step 18) to
network ports.
a. Select Configuration > Application Delivery > Port Processing.
b. In the Port Processing table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In Port Processing Settings, select the required settings.
d. Select a filter ID and use the arrows to move the filter between the Available and Selected
lists. Repeat until all filters are configured.
e. Click Submit.
f. Repeat until all ports are configured.
In this example, we use the following values:
b. In the Virtual Servers table, click to add an entry. The relevant Add tab displays.
c. In the Virtual Server ID field, type the identifier for the virtual server.
d. In the IP Address field, type the IP address for the virtual server.
e. In the Virtual Services tab, click to add an entry. The relevant Add tab displays.
f. In the Service Port field, type the port number to use.
g. In the Group ID field, select the group number from the drop-down list.
h. In the Properties tab, type a port number in the Real Server Port field.
i. Click Submit.
j. Select Enable Virtual Server.
k. Click Submit.
In this example, we use the following values:
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the identifier for the filter.
d. In the Action field, select the filter action from the drop-down list.
e. In the Group ID field, select the group from the drop-down list, if required.
In this example, we use the following values:
Filter ID Real Server Port Return to Last Reverse Session Load Balancing
Hop Capabilities
10 0 (default) (default) (default)
15 0 Enable Disable Firewall LB
Speed Duplex
Any Any
f. Click Submit.
In this example, we use the following values:
Idle Timeout
10080
b. In the Port Settings table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
c. In the Port Settings tab, type the port VLAN ID in the PVID field.
d. Click Submit.
e. Repeat until all VLANs per port are configured.
In this example, we use the following values:
Port PVID
1 4
2 3
b. In the VLAN table, click to add an entry. The relevant Add tab displays.
c. In the VLAN ID field, type the ID for the VLAN.
d. In the VLAN Settings tab, select the ports and use the arrows to move the ports between the
Available and Selected lists. Repeat until all ports are configured for the VLAN.
e. In the Source MAC Learning field, select whether MAC address learning is enabled.
f. Select Enable VLAN.
g. Click Submit.
In this example, we use the following values:
b. In the VLAN table, click to add an entry. The relevant Add tab displays.
c. In the VLAN ID field, type the ID for the VLAN.
d. In the VLAN Name field, type a common name to use for the VLAN.
e. In the VLAN Settings tab, select the ports and use the arrows to move the ports between the
Available and Selected lists. Repeat until all ports are configured for the VLAN.
f. In the Source MAC Learning field, select whether MAC address learning is enabled.
g. Select Enable VLAN.
h. Click Submit.
In this example, we use the following values:
b. In the VLAN table, click to add an entry. The relevant Add tab displays.
c. In the VLAN ID field, type the ID for the VLAN.
d. In the VLAN Name field, type a common name to use for the VLAN.
e. In the VLAN Settings tab, select the ports and use the arrows to move the ports between the
Available and Selected lists. Repeat until all ports are configured for the VLAN.
f. In the Source MAC Learning field, select whether MAC address learning is enabled.
g. Select Enable VLAN.
h. Click Submit.
In this example, we use the following values:
b. In the Spanning Tree Group table, select an entry and click , or double-click the entry you
want to edit. The relevant Edit tab displays.
c. In the Advanced tab, select the VLAN and use the arrows to move the VLAN between the
Available and Selected lists. Repeat until all VLANs are configured.
d. Click Submit.
e. Repeat until all spanning trees are configured.
In this example, we use the following values:
b. In the IP Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the ID for the interface.
d. In the IP Version field, select the IP version from the drop-down list.
e. In the IP Address field, type the IP address for the interface.
f. In the Mask field, type the subnet mask, if required.
g. In the VLAN field, select the VLAN from the drop-down list, if required.
h. Select Enable IP Interface.
i. Click Submit.
j. Repeat until all IP interfaces are configured.
In this example, we use the following values:
b. In the Static Routes table, click to add an entry. The relevant Add tab displays.
c. In the Destination IP field, type the destination IP address.
d. In the Mask field, type the subnet mask.
e. In the Gateway field, type the gateway IP address.
f. In the Interface field, type the IP interface ID.
g. Click Submit.
h. Repeat until all routes are configured.
In this example, we use the following values:
Speed Duplex
Any Any
Idle Timeout
10080
b. In the Port Settings table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
c. In the Port Settings tab, type the port VLAN ID in the PVID field.
d. Click Submit.
e. Repeat until all VLANs per port are configured.
In this example, we use the following values:
Port PVID
1 2
2 5
b. In the VLAN table, click to add an entry. The relevant Add tab displays.
c. In the VLAN ID field, type the ID for the VLAN.
d. In the VLAN Settings tab, select the ports and use the arrows to move the ports between the
Available and Selected lists. Repeat until all ports are configured for the VLAN.
e. In the Source MAC Learning field, select whether MAC address learning is enabled.
f. Select Enable VLAN.
g. Click Submit.
In this example, we use the following values:
b. In the VLAN table, click to add an entry. The relevant Add tab displays.
c. In the VLAN ID field, type the ID for the VLAN.
d. In the VLAN Name field, type a common name to use for the VLAN.
e. In the VLAN Settings tab, select the ports and use the arrows to move the ports between the
Available and Selected lists. Repeat until all ports are configured for the VLAN.
f. In the Source MAC Learning field, select whether MAC address learning is enabled.
g. Select Enable VLAN.
h. Click Submit.
In this example, we use the following values:
b. In the VLAN table, click to add an entry. The relevant Add tab displays.
c. In the VLAN ID field, type the ID for the VLAN.
d. In the VLAN Name field, type a common name to use for the VLAN.
e. In the VLAN Settings tab, select the ports and use the arrows to move the ports between the
Available and Selected lists. Repeat until all ports are configured for the VLAN.
f. In the Source MAC Learning field, select whether MAC address learning is enabled.
g. Select Enable VLAN.
h. Click Submit.
In this example, we use the following values:
b. In the Spanning Tree Group table, select an entry and click , or double-click the entry you
want to edit. The relevant Edit tab displays.
c. In the Advanced tab, select the VLAN and use the arrows to move the VLAN between the
Available and Selected lists. Repeat until all VLANs are configured.
d. Click Submit.
e. Repeat until all spanning trees are configured.
In this example, we use the following values:
b. In the IP Interfaces table, click to add an entry. The relevant Add tab displays.
c. In the Interface ID field, type the ID for the interface.
d. In the IP Version field, select the IP version from the drop-down list.
e. In the IP Address field, type the IP address for the interface.
f. In the Mask field, type the subnet mask, if required.
g. In the VLAN field, select the VLAN from the drop-down list, if required.
h. Select Enable IP Interface.
i. Click Submit.
j. Repeat until all IP interfaces are configured.
In this example, we use the following values:
b. In the Static Routes table, click to add an entry. The relevant Add tab displays.
c. In the Destination IP field, type the destination IP address.
d. In the Mask field, type the subnet mask.
e. In the Gateway field, type the gateway IP address.
f. In the Interface field, type the IP interface ID.
g. Click Submit.
h. Repeat until all routes are configured.
In this example, we use the following values:
b. In the Port Processing table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In Port Processing Settings, select Return to Sender (RTS).
d. Click Submit.
e. Repeat until all ports are configured.
In this example, we use the following values:
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. Do this on both clean-side Alteons:
a. Select Configuration > Application Delivery > Port Processing.
b. In the Port Processing table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In Port Processing Settings, select Return to Sender (RTS).
d. Click Submit.
e. Repeat until all ports are configured.
In this example, we use the following values:
3. On the dirty-side Alteons, set the FWLB metric on both dirty-side Alteons:
a. Select Configuration > Application Delivery > Server Resources > Server Groups.
b. In the Server Groups table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In the Group Settings tab, select the required metric using the drop-down list in the SLB
Metric field.
d. Click Submit.
Any of the following load balancing metrics can be used: Least Connections, Round Robin, Min
Misses, Response Time, and Server Bandwidth. See Metrics for Real Server Groups, page 223
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.
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the identifier for the filter.
d. In the Action field, select the action from the drop-down list.
e. Select the Match Settings tab.
f. In the Protocol field, select the filter protocol from the drop-down list.
g. In the Destination column of the IP Address/Network field, type the destination IP
address.
h. In the Destination column of the Mask/Prefix field, type the subnet mask.
i. Select Enable Filter.
j. Click Submit.
k. In this example, we use the following values:
2. Create another filter to deny all other traffic to the DMZ Web servers.
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the identifier for the filter.
d. In the Action field, select the action from the drop-down list.
e. Select the Match Settings tab.
f. In the Destination column of the IP Address/Network field, type the destination IP
address.
g. In the Destination column of the Mask/Prefix field, type the subnet mask.
h. Select Enable Filter.
i. Click Submit.
j. In this example, we use the following values:
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. Add the filters to the traffic ingress ports.
a. Select Configuration > Application Delivery > Port Processing.
b. In the Port Processing table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In Port Processing Settings, select the required settings.
d. Select a filter ID and use the arrows to move the filter between the Available and Selected
lists. Repeat until all filters are configured on the port.
e. Click Submit.
In this example, we use the following values:
For example, to configure Alteon to allow one-second intervals between health checks or pings, two
failed health checks to remove the firewall, and four successful health checks to restore the firewall
to the real server group, use the following command:
2. In the Real Servers table, select an entry and click , or double-click the entry you want to edit.
The relevant Edit tab displays.
3. Select the Health Check tab.
4. In the Interval field, type the number of seconds between health checks or pings.
5. In the Retries to Failure field, type the number of failed check before removing the firewall.
6. In the Retries to Restore field, type the number of successful health checks to restore the
firewall.
7. Click Submit.
In this example, we use the following values:
b. In the Server Groups table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In the Group Settings tab, select http from the drop-down list in the Health Check field.
d. Click Submit.
2. Configure a dummy redirect filter as the last filter (after the redirect all filter) to force the HTTP
health checks to activate.
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the identifier for the filter.
d. In the Action field, select an action from the drop-down list.
e. In the Group ID field, select the group from the drop-down list.
f. In the Match Settings tab, select TCP from the drop-down list in the Protocol field.
g. In the Action Settings tab, type the port in the Real Server Port field.
h. Select Enable Filter.
i. Click Submit.
j. In this example, we use the following values:
Note: Ensure that the number of each real filter is lower than the number of the dummy
redirect filter.
3. Apply filter to the port directed to the firewall.
a. Select Configuration > Application Delivery > Port Processing.
b. In the Port Processing table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In Port Processing Settings, select Filter/Outbound LLB.
d. Select the filter ID and use the arrows to move the filter between the Available and
Selected lists.
e. Click Submit.
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 13 - Well-known Application Ports , page 215.
Note: If you purchased the Advanced DoS protection option, enable it by typing /oper/swkey and
entering its software key.
Background, page 631Describes the rationale for providing Advanced DoS protection and how
it can assist traditional firewalls in preventing malicious network attacks.
IP Address Access Control Lists (ACLs), page 632Describes how to setup blocking of large
ranges of IP addresses.
Protection Against Common Denial of Service Attacks, page 633Explains how to prevent
common DoS attacks from entering ports that are connected to unsafe networks.
Protocol-Based Rate Limiting, page 640Explains how to monitor and limit incoming UDP, ICMP
or TCP traffic within a configurable time window.
Protection Against UDP Blast Attacks, page 645Describes how to monitor and limit traffic on
UDP ports to a maximum number of connections per second.
TCP or UDP Pattern Matching, page 645Describes 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.
b. In the Blocked Source Address table, click to add an entry. The relevant Add tab displays.
c. In the IP Address field, type the IP address to block.
d. In the Mask field, type the subnet mask, if required.
e. Click Submit.
2. Repeat step 1 to configure any other IP addresses that should be dropped.
3. Enable IP ACL processing on the ingress port.
a. Select Configuration > Security > Port Protection.
b. In the Port Protection table, click select an entry and click , or double-click the entry you
want to edit. The relevant Edit tab displays.
c. Select IP ACL.
d. Click Submit.
b. In the Port Protection table, click select an entry and click , or double-click the entry you
want to edit. The relevant Edit tab displays.
c. Select DoS Attack Protection.
d. Click Submit.
2. Add a DoS attack type to guard against.
a. Select Configuration > Security > Port Protection.
b. In the Port Protection table, click select an entry and click , or double-click the entry you
want to edit. The relevant Edit tab displays.
c. In Protocol Anomaly, select a DoS attack type to protect against and use the arrows to move
the attack type between the Available and Selected lists. Repeat until all attack types are
configured.
d. Click Submit.
3. Optionally, remove a DoS attack type from a port:
a. Select Configuration > Security > Port Protection.
b. In the Port Protection table, click select an entry and click , or double-click the entry you
want to edit. The relevant Edit tab displays.
c. In Protocol Anomaly, select a DoS attack type to protect against and use the arrows to move
the attack type between the Selected and Available lists. Repeat until all attack types are
removed.
d. Click Submit.
4. Repeat step 1and step 2 to apply DoS protection to any other ports.
To display a brief explanation of any of the DoS attacks that Alteon guards against
> Select Configuration > Security > Port Protection and click the Help button. A list of
protocol anomalies is available for review.
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 Command Line Interface Reference Guide. The total holddown
period is the result of the holddur value multiplied by the slowage value.
2. In the Filters table, select an entry and click , or double-click the entry you want to edit. The
relevant Edit tab displays.
3. In the Match Settings tab, select the appropriate rate limiting filter from the drop-down list in
the Protocol field. Only UDP, ICMP, and TCP protocols are supported for rate limiting.
4. In the Security tab, select Enable from the drop-down list in the Rate Limiting field.
5. In the Maximum Connections field, type the maximum number of connections to allow. The
value of 1 indicates a total of 10 TCP connections (or sessions).
6. In the Time Window field, type the number of seconds for the time window.
Note: The rate limit defined in step 5 and step 6 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).
7. In the Hold Down Duration field, type the hold down duration in number of minutes.
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.
8. Click Submit.
9. Repeat these steps until all Filters are configured.
In this example, we use the following values:
2. In the Filters table, click to add an entry. The relevant Add tab displays.
3. In the Filter ID field, type the identifier for the filter.
4. In the Match Settings tab, select the appropriate rate limiting filter from the drop-down list in
the Protocol field. Only UDP, ICMP, and TCP protocols are supported for rate limiting.
5. In the IP Address/Network field, type the IP address in the Source column.
6. In the Mask/Prefix, type the subnet mask in the Source column.
7. Select the Security tab.
8. In the Rate Limiting field, select Enable from the drop-down list.
9. In the Maximum Connections field, type the maximum number of connections to allow. The
value of 1 indicates a total of 10 TCP connections (or sessions).
10. In the Time Window field, type the length in seconds of the session time window.
11. In the Hold Down Duration field, type the length in minutes of the session hold duration.
12. Click Submit.
In this example, we use the following values:
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the identifier for the filter.
d. In the Action field, select Allow from the drop-down list.
e. In the Match Settings tab, select ICMP from the drop-down list in the Protocol field.
f. Select the Security tab.
g. In the Rate Limiting field, select Enable from the drop-down list.
h. In the Maximum Connections field, type the maximum number of connections to allow.
i. In the Time Window field, type the length in seconds of the session time window.
j. In the Hold Down Duration field, type the length in minutes of the session hold duration.
k. Select Enable Filter.
l. Click Submit.
In this example, we use the following values:
This configuration limits all clients to 100 new TCP (or UDP/ICMP packets) per second to the
server. If a client exceeds this rate, then the client is not allowed to transmit sessions or
connections to the virtual server for 40 minutes.
2. Add the filter to the ingress port.
a. Select Configuration > Application Delivery > Port Processing.
b. In the Port Processing table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. Select Filter/Outbound LLB.
d. Select the filter and use the arrow keys to move the filter between the Available and
Selected lists. Repeat until all filters are configured.
e. Click Submit.
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the identifier for the filter.
d. In the Action field, select Allow from the drop-down list.
e. In the Match Settings tab, select ICMP from the drop-down list in the Protocol field.
f. Select the Security tab.
g. In the Rate Limiting field, select Enable from the drop-down list.
h. In the Maximum Connections field, type the maximum number of connections to allow.
i. Select Enable Filter.
j. Click Submit.
In this example, we use the following values:
b. In the Port Processing table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. Select Filter/Outbound LLB.
d. Select the filter and use the arrow keys to move the filter between the Available and
Selected lists. Repeat until all filters are configured.
e. Click Submit.
b. In the UDP Blast table, click to add an entry. The relevant Add tab displays.
c. In the Lowest Application Port Number field, type the lowest UDP port number.
d. In the Highest Application Port Number field, type the highest UDP port number.
e. In the Maximum Packet Rate field, type the maximum packet rate per second.
f. Click Submit.
g. Repeat until all UDP port ranges are configured.
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.
a. Select Configuration > Security > Port Protection.
b. In the Port Protection table, select the port and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. Select UDP Blast.
d. Click Submit.
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 84 - IP Packet Format, page 646 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.
2. In the Layer 7 Strings table, click to add an entry. The relevant Add tab displays.
3. Configure the string as required.
4. Click Submit.
Table 34 - Pattern Criteria Values, page 646 includes an explanation of values you are prompted to
provide:
Value Description
Pattern A pattern can be a regular expression string pattern in ASCII characters, or a binary
pattern in hexadecimal notation.
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.
b. In the Layer 7 Strings table, click to add an entry. The relevant Add tab displays.
c. In the String Type field, select Binary Pattern.
d. In the Operation field, select Equals from the drop-down list.
e. In the Hex String field, type the string to identify.
f. In the Offset field, type the offset amount in bytes.
g. In the Depth field, type the offset required.
h. Click Submit.
In this example, we use the following values:
b. In the Layer 7 Strings table, click to add an entry. The relevant Add tab displays.
c. In the String Type field, select Text Pattern.
d. In the String field, type the string to identify.
e. In the Offset field, type the offset amount in bytes.
f. In the Depth field, type the offset required.
g. Click Submit.
In this example, we use the following values:
ID SLB String
1 any
2 ida
3 %c1%9c
4 %c0%af
6 playdog.com
7 HTTPHDR:Host:www.playdog.com
8 HTTPHDR:SoapAction=*
9 BINMATCH=014F, offset=2, depth=0, op=eq, cont 256
10 STRMATCH=/default.htm offset=44, depth=30, op=eq, cont 256
3. Configure a pattern group, give it an easy to remember common name, and add the new
pattern/offset pairs.
a. Select Configuration > Application Delivery > Filters > Pattern Matching Group.
b. In the Pattern Matching Group table, click to add an entry. The relevant Add tab displays.
c. In the Pattern Matching Group ID field, type a numeric identifier for the group. Valid
entries are 1 to 1024.
d. In the Description field, type a common name for the group.
e. Select a string and use the arrows to move the string between the Available and Selected
lists. Repeat until all strings are configured for the pattern group.
f. Click Submit.
4. Configure a filter to use the pattern group.
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the identifier for the filter.
d. In the Action field, select Deny from the drop-down list.
e. Select the Match Settings tab.
f. In the Protocol field, select TCP from the drop-down list.
g. In the IP Address/Network field, type the IP address in the Destination column.
h. Select the Security tab.
i. In the Pattern Matching field, select Enable from the drop-down list.
j. In Pattern Matching Group, select a group ID and use the arrows to move the group ID
between the Available and Selected lists.
k. Click Submit.
In this example, we use the following values:
5. Apply the filter to the client port. If the incoming client requests enter the Alteon on port 3, then
add this filter to port 3.
a. Select Configuration > Application Delivery > Port Processing.
b. In the Port Processing table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. Select Filter/Outbound LLB.
d. Select a rule and use the arrow keys to move the rule between the Available and Selected
lists.
e. Click Submit.
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.
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
The flags field begins at the seventh byte of the IP packet, and the fragment offset is right after this
field. The two fields taken together occupy a total of two (2) bytes. By searching for values greater
than 0000 and less than 4000, Alteon searches for either of these conditions, or both.
b. In the Layer 7 Strings table, click to add an entry. The relevant Add tab displays.
c. In the String Type field, select Text Pattern.
d. In the Operation field, select Greater Than from the drop-down list.
e. In the Hex String field, type the string to identify.
f. In the Offset field, type the offset amount in bytes.
g. In the Depth field, type the offset required.
h. Click Submit.
In this example, we use the following values:
b. In the Layer 7 Strings table, click to add an entry. The relevant Add tab displays.
c. In the String Type field, select Text Pattern.
d. In the Operation field, select Less Than from the drop-down list.
e. In the Hex String field, type the string to identify.
f. In the Offset field, type the offset amount in bytes.
g. In the Depth field, type the offset required.
h. Click Submit.
In this example, we use the following values:
ID SLB String
1 any
2 ida
3 %c1%9c
4 %c0%af
6 playdog.com
7 HTTPHDR:Host:www.playdog.com
8 HTTPHDR:SoapAction=*
9 BINMATCH=014F, offset=2, depth=0, op=eq, cont 256
10 STRMATCH=/default.htm offset=44, depth=30, op=eq, cont 256
11 BINMATCH=0000, offset=6, depth=0, op=gt, cont 256
12 BINMATCH=4000, offset=6, depth=0, op=lt, cont 256
b. In the Pattern Matching Group table, click to add an entry. The relevant Add tab displays.
c. In the Pattern Matching Group ID field, type an identifier for the pattern matching group.
The valid range is 1 to 1024.
d. In the Description field, type a common name by which the pattern matching group will be
known.
e. In the Strings section, select a string ID and use the arrow keys to move the ID between the
Available and Selected lists. Repeat until all string IDs are configured for this group.
f. Click Submit.
In this example, we use the following values:
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the identifier for the filter.
d. In the Action field, select Deny from the drop-down list.
e. Select the Match Settings tab.
f. In the Protocol field, select TCP from the drop-down list.
g. Select the Advanced Matching tab.
h. In the ICMP Message Type field, select Echo Request from the drop-down list.
i. Select the Security tab.
j. In the Pattern Matching field, select Enable from the drop-down list.
k. In Pattern Matching Group, select a group ID and use the arrows to move the group ID
between the Available and Selected lists.
l. Click Submit.
In this example, we use the following values:
6. Apply the filter to the client port. This example assumes a client connection on port 22.
a. Select Configuration > Application Delivery > Port Processing.
b. In the Port Processing table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. Select Filter/Outbound LLB.
d. Select a rule and use the arrow keys to move the rule between the Available and Selected
lists.
e. Click Submit.
In this example, we use the following values:
FlexiRules for SIP over UDP are advanced pattern match filters. Multiple rules can be configured. The
severity level can be set from 1 to 5, where 1 is the highest severity. Selection is based on severity
when multiple rules are hit.
The following inputs define FlexiRules for SIP over UDP:
Header field name and content
Bandwidth Management (BWM) contract for the rule
Alert message display
Severity
Dependent rules
There are two modes set by the SIP rules in a session entry:
Monitor Mode, page 653
Dependent Mode, page 654
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.
2. In the Traffic Contracts table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
3. In the Operation Mode field, select Monitor.
4. Click Submit.
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. Configure the FlexiRule.
a. Select Configuration > Application Delivery > Application Services > SIP >
FlexiRules.
b. In the FlexiRules table, click to add an entry. The relevant Add tab displays.
c. In the Rule ID field, type an identifier for the rule. Valid entries are 1 to 100.
d. Select the Rule Classification tab.
e. In the Header Name Field, select header type from the drop-down list.
f. Select the Rule Action tab.
g. In the Alert Message field, type the message that will appear in the log file when the rule is
matched.
h. In the Severity field, select the severity from 0 to 5 from the drop-down list.
i. In the BWM Contract field, type the bandwidth management contract number to associate
with this rule.
j. Select Enable SIP FlexiRule.
k. Click Submit.
2. Configure SIP and Pattern Matching in the filter.
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, select an entry and click , or double-click the entry you want to edit.
The relevant Edit tab displays.
c. Select the Security tab.
d. In the SIP UDP Filtering field, select Enable from the drop-down list.
e. In the Pattern Matching field, select Enable from the drop-down list.
f. Click Submit.
3. Configure the port.
a. Select Configuration > Application Delivery > Port Processing.
b. In the Port Processing table, select an entry and click , or double-click on the entry you
want to edit. The relevant Edit tab displays.
c. Select Filter/Outbound LLS.
d. Select a rule and use the arrows to move the rule between the Available and Selected
lists.
e. Click Submit.
b. In the Traffic Policies table, click to add an entry. The relevant Add tab displays.
c. In the Traffic Policy ID field, type the identifier for the policy. The valid range is 1 to 512.
d. In the Hard Limit field, type the hard limit amount. The valid range is 0k to 1000m.
e. In the Soft Limit field, type the soft limit amount. The valid range is 0k to 1000m.
f. In the Reservation Limit field, type the reservation limit amount. The valid range is 0k to
1000m.
g. In the User Limit field, type the user limit amount. The valid range is 0k to 1000m.
h. Click Submit.
In this example, we use the following value:
b. In the Traffic Contracts table, click to add an entry. The relevant Add tab displays.
c. Select Enable Traffic Contract.
d. In the Traffic Contract ID field, type the identifier for the contract. The valid range is 1 to
1024.
e. In the Policy field, type the contract policy number to associate with this contract. All
contracts must be associated with a policy.
f. Click Submit.
In this example, we use the following values:
3. Create Rule 1.
a. Select Configuration > Application Delivery > Application Services > SIP >
FlexiRules.
b. In the FlexiRules table, click to add an entry. The relevant Add tab displays.
c. In the Rule ID field, type an identifier for the rule. Valid entries are 1 to 100.
d. Select the Rule Classification tab.
e. In the Header Field Name Field, select the header type from the drop-down list.
f. Int he Header Field Content field, type the content. The maximum character limit is 49.
g. Select the Rule Action tab.
h. In the Alert Message field, type the message that will appear in the log file when the rule is
matched.
i. In the Severity field, select the severity from 0 to 5 from the drop-down list.
j. In the BWM Contract field, type the bandwidth management contract number to associate
with this rule.
k. Select Enable SIP FlexiRule.
l. Click Submit.
In this example, we use the following values:
Rule ID Header Field Header Field Alert Message Severity BWM Contract
Name Content
1 From bob from_has_bo 3 1
b
b. In the FlexiRules table, click to add an entry. The relevant Add tab displays.
c. In the Rule ID field, type an identifier for the rule. Valid entries are 1 to 100.
d. Select the Rule Classification tab.
e. In the Header Field Name Field, select the header type from the drop-down list.
f. Int he Header Field Content field, type the content. The maximum character limit is 49.
g. Select the Rule Action tab.
h. In the Alert Message field, type the message that will appear in the log file when the rule is
matched.
i. In the Severity field, select the severity from 0 to 5 from the drop-down list.
j. Select Enable SIP FlexiRule.
k. Click Submit.
In this example, we use the following values:
b. In the FlexiRules table, click to add an entry. The relevant Add tab displays.
c. In the Rule ID field, type an identifier for the rule. Valid entries are 1 to 100.
d. Select the Rule Classification tab.
e. In the Header Field Name Field, select the header type from the drop-down list.
f. Int he Header Field Content field, type the content. The maximum character limit is 49.
g. Select the Rule Action tab.
h. In the Alert Message field, type the message that will appear in the log file when the rule is
matched.
i. In the Severity field, select the severity from 0 to 5 from the drop-down list.
j. Select Enable SIP FlexiRule.
k. Click Submit.
In this example, we use the following values:
b. In the FlexiRules table, select rule 1 and click , or double-click rule 1. The relevant Edit
tab displays.
c. Select the Rule Classification tab.
d. Select a rule ID and use the arrows to move the rule ID between the Available and
Selected lists. Repeat until all IDs are configured.
e. Click Submit.
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:
For more information regarding configuration and operation of AppWall and Authentication, see the
AppWall for Alteon NG User Guide.
SSL Inspection
Most web applications used for private, commercial, or business purposes encrypt the transactions
based on the SSL/HTTPS protocol to ensure the privacy of data transfer between the user and
server.
SSL solves the privacy problem and secures the communication of sensitive information in and out
of the enterprise, but it created a new blind spot in the visibility of traffic that goes in and out of the
enterprise. SSL has also become a vehicle to carry malicious programs into the enterprise IT
infrastructure and allows sensitive information to leak out of the enterprise unnoticed. Even private
emails or innocent collaboration tools have become a security hazard as malicious programs can
cross through the enterprise's anti-virus solution unchecked, hidden in the SSL connection
established between the two ends.
Organizations subjected to industry and government regulations have strict rules on accessing
sensitive information and require all traffic in the datacenter to be visible. This requirement
contradicts the inherent need to keep data transmission encrypted to ensure privacy.
Alteon offers one unified solution that uniquely addresses all challenges and requirements.
Alteon can be implemented as a bump in the wire, overseeing all traffic to and from the Internet.
Based on its advanced Layer 4 to Layer 7 classification capabilities, Alteon seamlessly intercepts and
terminates SSL sessions as if it was a server, and opens a new SSL session on its other side, on
behalf of the end-user, towards the original destination server. In between, Alteon's advanced
transparent traffic steering capabilities forwards the decrypted traffic to deep packet inspection
(DPI) security solutions, such as firewalls, anti-malware, and data leakage protection, providing full
visibility into the content of both SSL encrypted and clear text sessions.
As illustrated, the traffic flow for the SSL Inspection solution is as follows:
1. A client initiates an HTTPS request (SSL Hello) to a secured Web site.
2. Alteon intercepts the request and initiates an SSL connection to the destination server. During
the SSL handshake, the server passes its certificate to Alteon.
3. Alteon quickly generates a server certificate identical to the remote server's certificate, signs it
with the configured CA certificate and passes it to the client This solves the problem of
performing registry changes on the client's PC and also presents the exact server certificate's
details to the client. The new certificate includes all the relevant information from the original
certificate including the common fields:
Serial number
Valid from
Valid to
Subject
Subject alternative name extension (if exists)
Issuer alternative name extension (if exists)
The original Issuer field is passed in a Netscape comment extension in the new certificate, as it
is not part of the new certificate when validated by the browser. The new certificate is created
with a new Issuer field, which is changed to the common name of the CA certificate imported/
created on Alteon for this purpose.
4. After completing the SSL handshake with the client, Alteon decrypts the client's request and
sends the HTTP request to the security device (antivirus, DLP, etc.) to be inspected.
5. The security device scans the HTTP traffic and if the result is OK, sends the traffic to the
Internet.
Note: The same traffic can be inspected by multiple security devices, in a serial manner.
6. Alteon intercepts the request sent by the security device (the last in line in case of multiple
devices) and initiates an encrypted request to the remote site as per the destination address
requested by the client in the original request. The source IP address of the request is either the
client's or its own, depending on the configuration.
7. The returning traffic follows the same flow but in the opposite direction.
During the SSL handshake with the remote server, Alteon authenticates the server and verifies that
the server's public certificate is signed by a known and recognized CA authority. For this, a list of
trusted CA certificates must be imported into Alteon. Alteon also verifies the certificate's expiration
date and validity.
During the SSL handshake, Alteon presents a newly created certificate to the client in place of the
original server. This means that, in effect, the client receives a certificate that has been issued by
Alteon, as opposed to the original issuer. Because of this, a security warning pop-up message
displays to the client. The message usually states the following:
An authentication problem occurred while trying to connect to the remote Web site. The problem is
one of the following:
The security certificate was issued by a company you have not chosen to trust.
The security certificate date is not valid
The common name on the security certificate is invalid or does not match the name of the site.
Note: In VX mode SSL Limit must be defined on the vADC on which you want to activate SSL
Inspection.
Notes
Currently, a single pair of front-end and back-end SSL policies can be configured for SSL
Inspection.
To perform Layer 7 decisions on the decrypted traffic you must use AppShape++.
b. In the Filters table, click to add an entry. The relevant Add tab opens.
c. Select Enable Filter.
d. In the Filter ID field, type an identifier for the filter. The valid range is 1 to 2048.
e. In the Action field, select Redirect from the drop-down list.
f. In the Group ID field, select the appropriate group ID from the drop-down list, or click
to add a new group.
In this example, we use the following values:
Filter ID Action
10 Redirect
In the Application Port/Range Start field, type 443 in the Destination column.
In this example, we use the following values:
Delayed Bind Real Server Port Return to Last Hop Reverse Session
Forceproxy 80 Enable Enable
b. In the Filters table, click to add an entry. The relevant Add tab opens.
c. Select Enable Filter.
d. In the Filter ID field, type an identifier for the filter. The valid range is 1 to 2048.
e. In the Action field, select Redirect from the drop-down list.
f. In the Group ID field, select the appropriate group ID from the drop-down list, or click
to add a new group.
In this example, we use the following values:
Filter ID Action
20 Redirect
Delayed Bind Real Server Port Return to Last Hop Reverse Session
Forceproxy 80 Enable Enable
j. Click Submit.
3. Configure port processing to use the configured filters.
a. Select Configuration > Application Delivery > Port Processing.
b. In the Port Processing table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. Select Filter/Outbound LLB.
d. Select the rule ID and use the arrows to move the rule ID between the Available and
Selected lists.
e. Click Submit.
f. Repeat until all filters are configured for each port.
In this example, we use the following values:
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 bandwidth management.
Bandwidth classification is performed using the following option locations:
Configuration > Network > Bandwidth Management Used to configure traffic contracts
for bandwidth management.
Configuration > Network > Physical Ports > Port SettingsUsed to configure specific
traffic contracts for specific ports.
Configuration > Network > Layer 2 > VLANUsed to configure classifications based on
VLANs.
Note: Configuration > Network > Layer 2 > Port Trunking > Static Trunk Groups
Used to configure trunking.
Configuration > Application Delivery > Virtual ServicesUsed to configure classifications
based on virtual servers.
Configuration > Application Delivery > FiltersUsed 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.
To associate a particular classification with a contract, enter the contract index into the cont menu
option under the applicable configuration menus.
As illustrated in Figure 87 - How Bandwidth Management Works, page 666, when the Virtual Matrix
Architecture (VMA) is enabled, traffic classification is performed on the ingress port (the port on
which the frame is received), and not the client port or the server port. If the traffic classification
is performed on Layer 4 through Layer 7 traffic (filter-based or SLB traffic), then the classification
occurs on the designated port.
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 667).
The following classifications limit the traffic outbound from the server farm for bandwidth
measurement and control:
Physical PortAll frames are from a specified physical port.
VLANAll frames are from a specified VLAN. If a VLAN translation occurs, the bandwidth policy
is based on the ingress VLAN.
IP Source AddressAll frames have a specified IP source address or range of addresses
defined with a subnet mask.
IP Destination AddressAll frames have a specified IP destination address or range of
addresses defined with a subnet mask.
Switch services on the virtual servers.
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 668Describes how contracts can be grouped together to
aggregate BMW resources.
IP User Level Contracts for Individual Sessions, page 669Describes a user-level contract.
Note: The soft and reserved, or Committed Information Rate (CIR), limits of each contract are not
part of the grouped contracts calculation, and remain set at their individual contracts levels.
For a group contract configuration example, see Configuring Grouped Contracts for Bandwidth
Sharing, page 681.
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 683.
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.
2. In the Traffic Contracts table, click to add an entry. The relevant Add tab displays.
3. In the Traffic Contract ID field, type an identifier for the contract.
4. In the Description, optionally type a common name by which the contract will be known.
5. In the Policy field, type a policy identifier.
6. Click Submit.
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 the Alteons system clock.
Configuring Time and Day Policies, page 692 describes how to configure and apply policies to
different times and days.
2. In the Traffic Contracts table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
3. In the Time Based Policies tab, click to add an entry. The relevant Add tab displays.
Note: The time-based policy is based on the time set in the Alteon system clock.
Enforcing Policies
For BWM contracts and policies to take effect, the policies must be enforced.
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. When thisoption is used, no limits will be applied on any contract.
To enforce policies
1. Select Configuration > Network > Bandwidth Management.
2. In the Operation Mode field, select Enforce.
3. Click Submit.
Rate Limiting
A rate limiting contract is controlled by metering the traffic that egresses from the 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 88 - Bandwidth Rate Limits, page 671.
For rate limiting contracts, the queue depth is ignored because traffic is not buffered.
Typically, bandwidth management occurs on the egress port of the Alteon, 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 36 - Bandwidth Rate Limits,
page 672:
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 applied in the following ways:
Contract CappingSession capping per contract is applied per SP.
User CappingSession capping per user is applied.
Application session capping is especially relevant in todays 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 the Alteon,
graceful degradation reduces each CIR until the total bandwidth allocated fits within the total
bandwidth available.
2. In the Traffic Contracts table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
3. Select the Advanced tab.
4. In the Statistics History field, select Enable to maintain history for the selected contract.
5. Click Submit.
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.
Note: If you purchased the Bandwidth Management option, be sure to enable it by entering
the license string. For more information, see Using Bandwidth Management, page 665.
3. Configure the policy.
a. Select Configuration > Network > Bandwidth Management > Traffic Policies.
b. In the Traffic Policies table, click to add an entry. The relevant Add tab displays.
c. In the Traffic Policy ID field, type an identifier for the policy. Valid numbers are 1 to 512.
d. In the Hard Limit field, type the rate that the policy should never exceed.
e. In the Soft Limit field, type the desired bandwidth rate.
f. In the Reservation Limit field, type the committed information rate.
g. In the Buffer Limit field, type 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.
h. In the Under Limit TOS field, optionally type a value that overwrites the original TOS value
if the traffic for this contract is under the soft limit.
i. In the Over Limit TOS field, optionally type a value that overwrites the original TOS value if
the traffic is over the soft limit.
There are two parameters for specifying the TOS bits underlimit (Under Limit TOS) and
overlimit (Over Limit TOS). 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 at Configuration >
Network > Bandwidth Management > Traffic Contracts > Advanced > Overwrite IP
TOS.
j. Click Submit.
In this example, we use the following values:
Traffic Hard Limit Soft Limit Reservation Buffer Limit Under Limit Over Limit
Policy ID Limit TOS TOS
1 6 5 4 16320 204 192
b. In the Traffic Contracts table, click to add an entry. The relevant Add tab displays.
c. In the Traffic Contract ID field, type an identifier for the contract. Valid range is 1 to 1024.
d. In the Description field, optionally type a common name for the contract.
e. In the Operation Mode field, optionally select Shaping. Rate limiting is enabled by default.
Enabling traffic shaping disables rate limiting. For more information, see Traffic Shaping,
page 673.
f. In the Precedence field, optionally type a precedence value from 1 to 255. The higher the
number, the higher the precedence. If a frame is applicable to different classifications, then
the contract with the higher precedence is assigned to the frame. If the precedence is the
same for the applicable contracts, then the following order will be used to assign the
contract to the frame:
Incoming port
VLAN
Filter
Service on the virtual server
URL/cookie
g. In the Policy field, type the bandwidth policy number to associate with this contract. Each
contract must have an associated policy.
h. Select the Advanced tab.
i. In the Overwrite IP TOS, optionally select Enable to allow TOS overwriting for this
contract.
b. In the Virtual Server table, select an entry and click , or double-click the entry you
want to edit. The relevant Edit tab displays.
c. In the Advanced tab, type the contract identifier in the Traffic Contract field.
d. Click Submit.
In this example, we use the following values:
Traffic Contract
1
b. In the Filters table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
c. In the Bandwidth Management tab, type the traffic contract identifier in the BW
Contract field.
d. Click Submit.
In this example, we use the following values:
BW Contract
1
In this example, BWM is configured to prevent broadband customers from affecting dial-up
customer access. This is accomplished by setting higher bandwidth policy rate limits for the port that
processes broadband traffic.
Policy 1 is for dial-up customers with lower bandwidth allocation needs.
Policy 2 is for broadband customers with higher bandwidth allocation needs.
b. In the Traffic Policies table, click to add an entry. The relevant Add tab displays.
c. In the Traffic Policy ID field, type an identifier for the traffic policy.
d. In the Hard Limit field, type the never exceed rate for the policy.
e. In the Soft Limit field, type the desired bandwidth rate.
f. In the Reservation Limit field, type the committed information rate.
g. Click Submit.
In this example, we use the following values:
b. In the Traffic Contracts table, click to add an entry. The relevant Add tab displays.
c. In the Traffic Contract ID field, type an identifier for the contract.
d. In the Description field, optionally type a common name by which this contract is known.
e. In the Policy field, type the bandwidth policy for this contract. Each BWM contract must be
assigned a bandwidth policy.
f. Select Enable Traffic Contract.
g. Click Submit.
In this example, we use the following values:
b. In the Traffic Policies table, click to add an entry. The relevant Add tab displays.
c. In the Traffic Policy ID field, type an identifier for the traffic policy.
d. In the Hard Limit field, type the never exceed rate for the policy.
e. In the Soft Limit field, type the desired bandwidth rate.
f. In the Reservation Limit field, type the committed information rate.
g. Click Submit.
In this example, we use the following values:
b. In the Traffic Contracts table, click to add an entry. The relevant Add tab displays.
c. In the Traffic Contract ID field, type an identifier for the contract.
d. In the Description field, optionally type a common name by which this contract is known.
e. In the Policy field, type the bandwidth policy for this contract. Each BWM contract must be
assigned a bandwidth policy.
f. Select Enable Traffic Contract.
g. Click Submit.
In this example, we use the following values:
Note: While traffic shaping contracts may be added to a group level contract, their soft and
reserved limits are not readjusted.
1. Ensure BWM is enabled on the Alteon.
a. Select Configuration > Network > Bandwidth Management.
b. Select Enable Bandwidth Management.
c. Click Submit.
2. Configure the 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 the 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.
a. Select Configuration > Network > Bandwidth Management > Traffic Policies.
b. In the Traffic Policies table, click to add an entry. The relevant Add tab displays.
c. In the Traffic Policy ID field, type an identifier for the policy.
d. In the Hard Limit field, type a never exceed rate for the policy.
e. In the Soft Limit field, type the desired bandwidth rate.
f. In the Reservation Limit field, type the committed information rate.
g. Click Submit.
In this example, we use the following values:
4. Configure and enable BWM contract 1. Each contract must have a unique number from 1 to
1024.
a. Select Configuration > Network > Bandwidth Management > Traffic Contracts.
b. In the Traffic Contracts table, click to add an entry. The relevant Add tab displays.
c. In the Traffic Contract ID field, type an identifier for the contract.
d. In the Policy field, type the BWM policy to associate with this contract. Each BWM contract
must be assigned a bandwidth policy.
e. Select Enable Traffic Contract.
f. Click Submit.
In this example, we use the following values:
5. Select the second bandwidth policy and set the hard, soft, and reserved rate limits for the
bandwidth policy, in Mbps.
a. Select Configuration > Network > Bandwidth Management > Traffic Policies.
b. In the Traffic Policies table, click to add an entry. The relevant Add tab displays.
c. In the Traffic Policy ID field, type an identifier for the policy.
d. In the Hard Limit field, type a never exceed rate for the policy.
e. In the Soft Limit field, type the desired bandwidth rate.
f. In the Reservation Limit field, type the committed information rate.
g. Click Submit.
In this example, we use the following values:
6. Configure and enable BWM contract 1. Each contract must have a unique number from 1 to
1024.
a. Select Configuration > Network > Bandwidth Management > Traffic Contracts.
b. In the Traffic Contracts table, click to add an entry. The relevant Add tab displays.
c. In the Traffic Contract ID field, type an identifier for the contract.
d. In the Policy field, type the BWM policy to associate with this contract. Each BWM contract
must be assigned a bandwidth policy.
e. Select Enable Traffic Contract.
f. Click Submit.
In this example, we use the following values:
7. Using the same procedures, 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.
8. 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.
9. Configure BWM Contract Group 1 and add all four contracts to this group.
a. Select Configuration > Network > Bandwidth Management > Contract Groups.
b. In the Contract Groups table, click to add an entry. The relevant Add tab displays.
c. In the Traffic Contract Group ID field, type an identifier for the contract group.
d. Select a contract ID and use the arrows to move the contract between the Available and
Selected lists. Repeat until all contracts are configured.
e. Click Submit.
If the number of octets sent out exceeds the value of the entire contract (10 Mbps), excess
octets are dropped.
If the number of octets is below the value of the contract (10 Mbps), a session is created on the
Alteon that records the students IP address, the egress port number, and the contract number,
as well as the number of octets transferred for that second. The session updates the number of
octets being transferred every second, thus maintaining traffic within the configured user limit of
64 kbps.
1. Select the first bandwidth policy and set the hard, soft, and reserved rate limits for the
bandwidth policy, in Mbps.
a. Select Configuration > Network > Bandwidth Management > Traffic Policies.
b. In the Traffic Policies table, click to add an entry. The relevant Add tab displays.
c. In the Traffic Policy ID field, type an identifier for the policy.
d. In the Hard Limit field, type a never exceed rate for the policy.
e. In the User Limit field, type the desired bandwidth rate.
f. Click Submit.
In this example, we use the following values:
2. Configure and enable BWM contract 1. Each contract must have a unique number from 1 to
1024.
a. Select Configuration > Network > Bandwidth Management > Traffic Contracts.
b. In the Traffic Contracts table, click to add an entry. The relevant Add tab displays.
c. In the Traffic Contract ID field, type an identifier for the contract.
d. In the Policy field, type the BWM policy to associate with this contract. Each BWM contract
must be assigned a bandwidth policy.
e. Select Enable Traffic Contract.
f. Click Submit.
In this example, we use the following values:
3. Configure a filter to match the source IP address range of the student body, and assign BWM
contract to that filter.
b. In the Traffic Policies table, click to add an entry. The relevant Add tab displays.
c. In the Traffic Policy ID field, type an identifier for the bandwidth policy. The valid range is
1 to 512.
d. In the Hard Limit field, type the never exceed rate.
e. In the Soft Limit field, type the desired bandwidth rate.
f. In the Reservation Limit field, type the committed information rate.
g. Click Submit.
In this example, we use the following values:
b. In the Traffic Contracts table, click to add an entry. The relevant Add tab displays.
c. In the Traffic Contract ID field, type an identifier for the contract. Each ID must be unique.
The valid range is 1 to 1024.
d. In the Description field, type a common name by which this contract will be known.
e. In the Policy field, type the bandwidth policy you want to assign to this contract. Each BWM
contract must be assigned a bandwidth policy.
f. Select Enable Traffic Contract.
g. Click Submit.
In this example, we use the following values:
b. In the Traffic Policies table, click to add an entry. The relevant Add tab displays.
c. In the Traffic Policy ID field, type an identifier for the bandwidth policy. The valid range is
1 to 512.
d. In the Hard Limit field, type the never exceed rate.
e. In the Soft Limit field, type the desired bandwidth rate.
f. In the Reservation Limit field, type the committed information rate.
g. Click Submit.
In this example, we use the following values:
b. In the Traffic Contracts table, click to add an entry. The relevant Add tab displays.
c. In the Traffic Contract ID field, type an identifier for the contract. Each ID must be unique.
The valid range is 1 to 1024.
d. In the Description field, type a common name by which this contract will be known.
e. In the Policy field, type the bandwidth policy you want to assign to this contract. Each BWM
contract must be assigned a bandwidth policy.
f. Select Enable Traffic Contract.
g. Click Submit.
In this example, we use the following values:
6. 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.
a. Select Configuration > Application Delivery > Virtual Services.
b. In the Virtual Servers table, click to add an entry. The relevant Add tab displays.
c. In the Virtual Server ID field, type an identifier for the service.
d. In the IP Address field, type the IP address for the server.
e. Select Enable Virtual Server.
f. In the Virtual Services tab, click to add an entry. The relevant Add tab displays.
g. In the Server Index field, type an identifier for the service.
h. In the Service Port field, type the port number for the service.
i. In the Group ID field, select the group from the drop-down list.
j. In the Bandwidth Management tab, type the traffic contract ID in the Bandwidth Traffic
Control field.
k. Click Submit.
l. Repeat until all virtual services are configured.
In this example, we use the following values:
This example assumes you have configured URL-based SLB and the Layer 7 strings as described in
Content-Intelligent Server Load Balancing, page 269. 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 269.
2. Configure BWM policies with the desired bandwidth limits. In this example, four policies are
configured, as illustrated in Figure 90 - URL-Based SLB with Bandwidth Management, page 688.
a. Select Configuration > Network > Bandwidth Management > Traffic Policies.
b. In the Traffic Policies table, click to add an entry. The relevant Add tab displays.
c. In the Traffic Policy ID field, type an identifier for the bandwidth policy. The valid range is
1 to 512.
d. In the Hard Limit field, type the never exceed rate.
e. In the Soft Limit field, type the desired bandwidth rate.
f. In the Reservation Limit field, type the committed information rate.
g. Click Submit.
In this example, we use the following values:
3. Configure BWM contracts and apply the appropriate policies to the contracts. In this example,
the policy numbers correspond to the contract numbers.
a. Select Configuration > Network > Bandwidth Management > Traffic Contracts.
b. In the Traffic Contracts table, click to add an entry. The relevant Add tab displays.
c. In the Traffic Contract ID field, type an identifier for the contract. Each ID must be unique.
The valid range is 1 to 1024.
d. In the Policy field, type the bandwidth policy you want to assign to this contract. Each BWM
contract must be assigned a bandwidth policy.
e. Select Enable Traffic Contract.
f. Click Submit.
In this example, we use the following values:
b. In the Layer 7 Strings table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In the Traffic Contract field, type the identifier for the traffic contract to associate with the
string.
d. Click Submit.
e. Repeat until all strings are configured with BWM contracts.
b. In the Real Servers table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
c. In the Layer 7 String Based Server Selection tab, select the string ID and use the arrows to
move it between the Available and Selected lists.
d. Click Submit.
e. Repeat until all real servers are configured with the correct string IDs.
7. Either enable Direct Access Mode (DAM) on the Alteon or configure a proxy IP address on the
client port. To turn on DAM.
a. Select Configuration > Application Delivery > Virtual Services > Settings.
b. In the Direct Access Mode field, select Enable.
c. Click Submit.
To turn off DAM and configure a proxy IP address on the client port.
Turning off DAM:
a. Select Configuration > Application Delivery > Virtual Services > Settings.
b. In the Direct Access Mode field, select Disable.
c. Click Submit.
Configuring a Proxy IP:
a. Select Configuration > Network > Proxy IP.
b. In the Proxy IP Associated to field, select Ports.
c. In the Proxy IPv4 tab, click to add an entry. The relevant Add tab displays.
d. In the IP Address field, type the IP address.
e. In Port Range, select a port and use the arrows to move the port between the Available
and Selected lists.
f. Click Submit.
In this example, we use the following values:
For more information on proxy IP addresses, see Client Network Address Translation (Proxy IP),
page 235.
Port mapping for content-intelligent SLB can be performed by enabling DAM on the Alteon, or
disabling DAM and configuring a proxy IP address on the client port.
8. Turn on HTTP SLB processing on the virtual server. Configure everything under the virtual server
as in Configuring User/Application Fairness, page 680.
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
ruleas follows.
a. Select Configuration > Application Delivery > Virtual Services.
b. In the Virtual Servers table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In the Virtual Services tab, click to add an entry. The relevant Add tab displays.
d. In the Bandwidth Management tab, click to add an entry. The relevant Add tab displays.
b. In the Traffic Policies table, click to add an entry. The relevant Add tab displays.
c. In the Traffic Policy ID field, type an identifier for the bandwidth policy. The valid range is
1 to 512.
d. In the Hard Limit field, type the never exceed rate.
e. In the Soft Limit field, type the desired bandwidth rate.
f. In the Reservation Limit field, type the committed information rate.
g. In the Buffer Limit field, type the buffer depth. The buffer limit should be between 8192
and 128000 bytes. The buffer depth for a BWM contract should be set to a multiple of the
packet size.
h. Click Submit.
In this example, we use the following values:
b. In the Traffic Contracts field, click to add an entry. The relevant Add tab displays.
c. In the Traffic Contract ID field, type the identifier for the contract. The valid range is 1 to
1024.
d. In the Description field, type the common name by which to identify the contract.
e. In the Policy field, type the traffic policy identifier to associate with this contract. All
contracts must have an associated bandwidth policy.
f. Select Enable Traffic Contract.
g. Click Submit.
4. 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.
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, click to add an entry. The relevant Add tab displays.
c. In the Filter ID field, type the identifier for the filter.
d. In the Match Settings tab, select ICMP from the drop-down list in the Protocol field.
e. In the Bandwidth Management tab, type the traffic contract ID in the BW Contract field.
f. Select Enable Filter.
g. Click Submit.
If both Time Policy 1 and Time Policy 2 are enabled on a contract, and both policies match the
current time set in the Alteon system clock, Time Policy 1 will take effect.
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.
a. Select Configuration > Network > Bandwidth Management > Traffic Policies.
b. In the Traffic Policies table, click to add an entry. The relevant Add tab displays.
c. In the Traffic Policy ID field, type an identifier for the bandwidth policy. The valid range is
1 to 512.
d. In the Hard Limit field, type the never exceed rate.
e. In the Soft Limit field, type the desired bandwidth rate.
f. Click Submit.
In this example, we use the following values:
b. In the Traffic Contracts field, click to add an entry. The relevant Add tab displays.
c. In the Traffic Contract ID field, type the identifier for the contract. The valid range is 1 to
1024.
d. In the Policy field, type the traffic policy identifier to associate with this contract. All
contracts must have an associated bandwidth policy. This BWM policy will be in effect at all
other times beyond the specifications of the two time policies.
e. Select Enable Traffic Contract.
f. Click Submit.
3. Create the first time policy under Contract 1, for peak working hours.
a. Select Configuration > Network > Bandwidth Management > Traffic Contracts.
b. In the Traffic Contracts field, click to add an entry. The relevant Add tab displays.
c. In the Traffic Contract ID field, type the identifier for the contract. The valid range is 1 to
1024.
d. In the Time Based Policies tab, click to add an entry. The relevant Add tab displays.
e. In the Time Policy ID field, type the identifier for the time policy.
f. In the Day field, select the day or days of the week for the policy from the drop-down list.
g. In the Start Hour field, type the time of day the policy should begin. The valid range is 0 to
23.
h. In the End Hour field, type the time of day the policy should end. The valid range is 0 to 23.
i. In the Policy field, type the identifier for the traffic policy to associate with this time policy.
j. Select Enable Time Based Policy.
k. Click Submit.
In this example, we use the following values:
4. Create the second time policy under Contract 1, for weekday evening hours.
a. Select Configuration > Network > Bandwidth Management > Traffic Contracts.
b. In the Traffic Contracts field, click to add an entry. The relevant Add tab displays.
c. In the Traffic Contract ID field, type the identifier for the contract. The valid range is 1 to
1024.
d. In the Time Based Policies tab, click to add an entry. The relevant Add tab displays.
e. In the Time Policy ID field, type the identifier for the time policy.
f. In the Day field, select the day or days of the week for the policy from the drop-down list.
g. In the Start Hour field, type the time of day the policy should begin. The valid range is 0 to
23.
h. In the End Hour field, type the time of day the policy should end. The valid range is 0 to 23.
i. In the Policy field, type the identifier for the traffic policy to associate with this time policy.
j. Select Enable Time Based Policy.
k. Click Submit.
In this example, we use the following values:
b. In the Port Settings table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
c. In the Bandwidth Management tab, type the bandwidth contract identifier in the Traffic
Contract field.
d. Click Submit.
2. In the Port Settings table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
3. In the Bandwidth Management tab, type the egress bandwidth in the Egress Limit field.
4. Click Submit.
2. In the Traffic Contracts table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
3. In the Advanced tab, select Enable in the Overwrite TCP Window field.
4. Click Submit.
Note: Cookie-based BWM does not apply to cookie-based persistence or cookie passive/active
mode applications.
In thse examples, 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.
String
Business
First
Coach
2. 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:
a. Select Configuration > Application Delivery > Server Resources > Real Servers.
b. In the Real Servers table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
c. In the Layer 7 String Based Server Selection tab, select the string ID and use the arrows to
move the ID between the Available and Selected lists. Repeat until all string IDs are
configured.
d. Click Submit.
3. Either enable DAM on the Alteon or configure a proxy IP address on the client port. To turn on
DAM:
a. Select Configuration > Application Delivery > Virtual Services > Settings.
b. In the Direct Access Mode field, select Enable.
c. Click Submit.
To turn off DAM and configure a Proxy IP address on the client port:
Turning off DAM:
a. Select Configuration > Application Delivery > Virtual Services > Settings.
b. In the Direct Access Mode field, select Disable.
c. Click Submit.
Configuring a Proxy IP:
a. Select Configuration > Network > Proxy IP.
b. In the Proxy IP Associated to field, select Ports.
c. In the Proxy IPv4 tab, click to add an entry. The relevant Add tab displays.
d. In the IP Address field, type the IP address.
e. In Port Range, select a port and use the arrows to move the port between the Available
and Selected lists.
f. Click Submit.
In this example, we use the following values:
For more information on proxy IP addresses, see Client Network Address Translation (Proxy IP),
page 235.
Note: By enabling DAM on the Alteon or, alternatively, disabling DAM and configuring a proxy
on the client port, port mapping for URL-based load balancing can be performed.
The configuration to support this scenario is similar to Example Example, page 695. 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.
a. Select Configuration > Application Delivery > Virtual Services.
b. In the Virtual Servers table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In the Virtual Services tab, click to add an entry. The relevant Add tab displays.
d. In the Service Port field, type the port to use.
e. Select the Bandwidth Management tab.
f. In the BWM Contract per String table, click to add an entry. The relevant Add tab
displays.
g. In the String ID field, type the string identifier.
h. In the Bandwidth Contract field, type the contract identifier.
i. Click Submit.
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.
URL-Based Server Load Balancing, page 699
Statistics for URL-Based Server Load Balancing, page 703
Virtual Hosting, page 703
Cookie-Based Preferential Load Balancing, page 706
Browser-Smart Load Balancing, page 709
Configure SLB Strings for HTTP Redirection, page 710
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.
Assign an IP address to each of the real servers in the server pool.
Define an IP interface.
Define each real server.
Define a real server group and set up health checks for the group.
Define a virtual server on virtual port 80 (HTTP), and assign the real server group to service
it.
Enable SLB.
Enable client processing on the port connected to the clients.
For information on how to configure your network for SLB, see Server Load Balancing, page 205.
2. Define the strings to be used for URL load balancing.
a. Select Configuration > Application Delivery > Traffic Match Criteria > Layer 7
Strings.
b. In the Layer 7 Strings table:
This string would not allow the server to process these requests, however:
/company/images/b.gif
/product/images/c.gif
/testing/images/a.gif
/default.asp
/index.shtm
ID SLB String
1 any
2 .gif
3 /sales
4 /xitami
5 /manual
6 .jpg
b. In the Real Servers table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
c. Select the Layer 7 String Based Server Selection tab.
d. Select the string ID and use the arrows to move the ID between the Available and
Selected lists.
e. Click Submit.
Note: If you do not add a defined string (or add the defined string any) the server handles any
request.
A server can have multiple defined strings such as:
/images
/sales
.gif
With these defined strings, this particular server can handle requests that start with /images or
/sales and any requests that contain .gif.
4. 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.
a. Enable DAM
Select Configuration > Application Delivery > Virtual Services > Settings.
In the Direct Access Mode field, select Enable from the drop-down list.
Click Submit.
b. Configure a proxy IP address and enable proxy on the client port.
Select Configuration > Network > Proxy IP.
In the Proxy IP Associated to field, select Ports.
In the Proxy IPv4 or Proxy IPv6 tab, click to add an entry. The relevant Add tab
displays.
In the IP Address field, type the IP address to use.
Select the port and use the arrows to move the port between the Available and
Selected lists. Repeat until all ports are configured.
Click Submit.
For more information on proxy IP addresses, see Client Network Address Translation (Proxy IP),
page 235.
5. Enable URL-based SLB on the virtual servers.
a. Select Configuration > Application Delivery > Virtual Services.
b. In the Virtual Servers table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In the Virtual Services tab, click to add an entry. The relevant Add tab displays.
d. In the Application field, select HTTP from the drop-down list.
e. In the Service Port field, type a port number associated with HTTP.
f. In the HTTP Server Selection tab, in the Server Selection Parameter field, select URL
from the drop-down list.
g. Click Submit.
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:
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.company.com/products/Alteon would look like this:
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 company.com or http://
www.company.com/ matches http://www.company.com/.
To support virtual hosting, configure the Alteon for Host header-based load balancing
1. Before you can configure host header-based SLB, ensure that the 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 205.
2. Turn on URL parsing for the virtual server for virtual hosting.
a. Select Configuration > Application Delivery > Virtual Services.
b. In the Virtual Servers table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In the Virtual Services tab, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
d. Select the HTTP Server Selection tab.
e. In the Server Selection Parameter field, select Host from the drop-down list.
f. Click Submit.
3. Define the host names.
a. Select Configuration > Application Delivery > Traffic Match Criteria > Layer 7
Strings.
b. In the Layer 7 Strings table, click to add an entry. The relevant Add tab displays.
c. In the String field, type the new string.
d. Click Submit.
e. Repeat until all strings are configured.
In this example, we use the following values:
String
www.customer1.com
www.customer2.com
www.customer3.com
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.
a. Select Configuration > Application Delivery > Server Resources > Real Servers.
b. In the Real Servers table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
c. In the Layer 7 String Based Server Selection tab, select the string ID and use the arrows to
move the ID between the Available and Selected lists. Repeat until all strings are
configured.
d. Click Submit.
Note: The server handles any request if no string or the string any is defined.
Clients that receive preferential service can be distinguished from other users by one of the
following methods:
Individual UserDistinguish a specific user by IP address, login authentication, or permanent
HTTP cookie.
User CommunitiesIdentify some set of users, such as Premium Users for service providers
who pay higher membership fees than Normal Users by source address range, login
authentication, or permanent HTTP cookie.
ApplicationsIdentify 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.
ContentIdentify 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.
b. In the Virtual Servers table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In the Virtual Services tab, click to add an entry. The relevant Add tab displays.
d. In the Application field, select HTTP from the drop-down list.
e. In the Service Port field, type an HTTP service port number.
f. In the Group ID field, select a group from the drop-down list.
g. In the Properties tab, select Enable in the Delayed Binding field.
h. In the HTTP Server Selection tab, select Cookie from the drop-down list in the Server
Selection Parameter field.
i. In the Cookie Name field, type the name of the cookie. The maximum name length is 20
characters.
j. In the Value Length field, type the number of bytes to extract from the cookie value. Valid
values are 1 to 64.
k. In the Value Offset field, type the starting point for the cookie value. Valid values are 1 to
64.
l. Click Submit.
In this example, we use the following values:
Application Service Port Server Cookie Name Value Length Value Offset
Selection
Parameter
HTTP 80 Cookie sid 1 6
b. In the Layer 7 Strings table, click to add an entry. The relevant Add tab displays.
c. In the String field, type the new string.
d. Click Submit.
e. Repeat until all strings are configured.
In this example, we use the following values:
String
Gold
Silver
Bronze
any
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.
Real Server 1Gold handles gold requests.
Real Server 2Silver handles silver request.
Real Server 3Bronze handles bronze request.
Real Server 4any 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:
a. Select Configuration > Application Delivery > Server Resources > Real Servers.
b. In the Real Servers table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
c. In the Layer 7 String Based Server Selection tab, select the string ID and use the arrows to
move the ID between the Available and Selected lists. Repeat until all strings are
configured.
d. Click Submit.
In this example, we use the following values:
Note: If you do not add a defined string (or add the defined string any), the server handles
any request.
5. Enable DAM on the 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.
b. In the Virtual Servers table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. In the Virtual Services tab, click to add an entry. The relevant Add tab displays.
d. In the Application field, select HTTP from the drop-down list.
e. In the Service Port field, type an HTTP service port number.
f. In the Group ID field, select a group from the drop-down list.
g. In the Properties tab, select Enable in the Delayed Binding field.
h. In the HTTP Server Selection tab, select Browser from the drop-down list in the Server
Selection Parameter field.
i. Click Submit.
In this example, we use the following values:
b. In the Layer 7 Strings table, click to add an entry. The relevant Add tab displays.
c. In the String field, type the new string.
d. Click Submit.
e. Repeat until all strings are configured.
In this example, we use the following values:
String
Mozilla
Internet Explorer
Netscape
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.
a. Select Configuration > Application Delivery > Server Resources > Real Servers.
b. In the Real Servers table, select an entry and click , or double-click the entry you want to
edit. The relevant Edit tab displays.
c. In the Layer 7 String Based Server Selection tab, select the string ID and use the arrows to
move the ID between the Available and Selected lists. Repeat until all strings are
configured.
d. Click Submit.
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 211.
2. Configure the filter strings.
a. Select Configuration > Application Delivery > Traffic Match Criteria > Layer 7
Strings.
b. In the Layer 7 Strings table, click to add an entry. The relevant Add tab displays.
c. In the String Type field, select L7 Lookup.
d. In the Application field, select HTTP.
e. In the Header Name field, type Host. The maximum character length for this field is 32.
f. In the Header Value field, type the value of the header. The maximum character length for
this field is 38.
g. Click Submit.
h. Repeat until all strings are configured.
In this example, we use the following values:
Header Value
wap.example.com
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 211.
4. Configure a port for client traffic. This configuration assumes client traffic enters Alteon on
port 1. Enabled filtering on the client port.
a. Select Configuration > Application Delivery > Port Processing.
b. In the Port Processing table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. Select Filter/Outbound LLB.
d. Select the filter ID and use the arrow keys to move the ID between the Available and
Selected lists. Repeat until all filter IDs are configured for the port.
e. Click Submit.
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 1If 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 2If 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 3If 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 37 -
Example HTTP Redirection Strings, page 711 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.
2. Configure Filter 1.
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, click to add a new entry. The relevant Add tab displays.
c. Select Enable Filter.
d. In the Filter ID field, type the identifier for the filter. The valid range for this field is 1 to
2048.
e. In the Action field, select Redirect from the drop-down list.
In this part of the example, we use the following values:
Filter ID Action
1 Redirect
l. In the HTTP Redirection table, click to add a string. The relevant Add tab displays.
m. In the From String field, select the from string from the drop-down list.
n. In the To String field, select the to string from the drop-down list.
o. Click Submit to return to the Add Filter tab.
p. Click Submit.
In this part of the example, we use the following values:
3. Configure Filter 2.
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, click to add a new entry. The relevant Add tab displays.
c. Select Enable Filter.
d. In the Filter ID field, type the identifier for the filter. The valid range for this field is 1 to
2048.
e. In the Action field, select Redirect from the drop-down list.
In this part of the example, we use the following values:
Filter ID Action
2 Redirect
l. In the HTTP Redirection table, click to add a string. The relevant Add tab displays.
m. In the From String field, select the from string from the drop-down list.
n. In the To String field, select the to string from the drop-down list.
o. Click Submit to return to the Add Filter tab.
p. Click Submit.
In this part of the example, we use the following values:
4. Configure Filter 3.
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, click to add a new entry. The relevant Add tab displays.
c. Select Enable Filter.
d. In the Filter ID field, type the identifier for the filter. The valid range for this field is 1 to
2048.
e. In the Action field, select Redirect from the drop-down list.
In this part of the example, we use the following values:
Filter ID Action
3 Redirect
l. In the HTTP Redirection table, click to add a string. The relevant Add tab displays.
m. In the From String field, select the from string from the drop-down list.
n. In the To String field, select the to string from the drop-down list.
o. Click Submit to return to the Add Filter tab.
p. Click Submit.
In this part of the example, we use the following values:
1. Identify the ID numbers of the defined strings. The strings in bold in the filters defined above
are used in this example.
2. Configure Filter 4.
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, click to add a new entry. The relevant Add tab displays.
c. Select Enable Filter.
d. In the Filter ID field, type the identifier for the filter. The valid range for this field is 1 to
2048.
e. In the Action field, select Redirect from the drop-down list.
In this part of the example, we use the following values:
Filter ID Action
4 Redirect
l. In the HTTP Redirection table, click to add a string. The relevant Add tab displays.
m. In the From String field, select the from string from the drop-down list.
n. In the To String field, select the to string from the drop-down list.
o. Click Submit to return to the Add Filter tab.
p. Click Submit.
In this part of the example, we use the following values:
3. Configure Filter 5.
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, click to add a new entry. The relevant Add tab displays.
c. Select Enable Filter.
d. In the Filter ID field, type the identifier for the filter. The valid range for this field is 1 to
2048.
e. In the Action field, select Redirect from the drop-down list.
In this part of the example, we use the following values:
Filter ID Action
5 Redirect
l. In the HTTP Redirection table, click to add a string. The relevant Add tab displays.
m. In the From String field, select the from string from the drop-down list.
n. In the To String field, select the to string from the drop-down list.
o. Click Submit to return to the Add Filter tab.
p. Click Submit.
In this part of the example, we use the following values:
b. In the Filters table, click to add a new entry. The relevant Add tab displays.
c. Select Enable Filter.
d. In the Filter ID field, type the identifier for the filter. The valid range for this field is 1 to
2048.
e. In the Action field, select Redirect from the drop-down list.
In this part of the example, we use the following values:
Filter ID Action
6 Redirect
l. In the HTTP Redirection table, click to add a string. The relevant Add tab displays.
m. In the From String field, select the from string from the drop-down list.
n. In the To String field, select the to string from the drop-down list.
o. Click Submit to return to the Add Filter tab.
p. Click Submit.
In this part of the example, we use the following values:
b. In the Filters table, click to add a new entry. The relevant Add tab displays.
c. Select Enable Filter.
d. In the Filter ID field, type the identifier for the filter. The valid range for this field is 1 to
2048.
e. In the Action field, select Redirect from the drop-down list.
In this part of the example, we use the following values:
Filter ID Action
7 Redirect
l. In the HTTP Redirection table, click to add a string. The relevant Add tab displays.
m. In the From String field, select the from string from the drop-down list.
n. In the To String field, select the to string from the drop-down list.
o. Click Submit to return to the Add Filter tab.
p. Click Submit.
In this part of the example, we use the following values:
b. In the Filters table, click to add a new entry. The relevant Add tab displays.
c. Select Enable Filter.
d. In the Filter ID field, type the identifier for the filter. The valid range for this field is 1 to
2048.
e. In the Action field, select Redirect from the drop-down list.
In this part of the example, we use the following values:
Filter ID Action
8 Redirect
l. In the HTTP Redirection table, click to add a string. The relevant Add tab displays.
m. In the From String field, select the from string from the drop-down list.
n. In the To String field, select the to string from the drop-down list.
o. Click Submit to return to the Add Filter tab.
p. Click Submit.
In this part of the example, we use the following values:
1. Define Layer 7 strings and identify their ID numbers. The strings in bold in the filters defined
above are used in this example.
a. Select Configuration > Application Delivery > Traffic Match Criteria > Layer 7
Strings.
b. In the Layer 7 Strings table, click to add an entry. The relevant Add tab displays.
c. In the Application field, select HTTP.
d. In the Header Name field, type Host. This field allows a maximum of 31 characters.
e. In the Header Value field, type the value for which to search. This field allows a maximum
of 48 characters.
f. Click Submit.
g. Repeat until all strings are configured.
In this example, we use the following values:
2. Configure Filter 9.
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, click to add a new entry. The relevant Add tab displays.
c. Select Enable Filter.
d. In the Filter ID field, type the identifier for the filter. The valid range for this field is 1 to
2048.
e. In the Action field, select Redirect from the drop-down list.
In this part of the example, we use the following values:
Filter ID Action
9 Redirect
h. In the Application Port/Range Start field, type the port number in the Destination
column.
In this part of the example, we use the following values:
j. In the HTTP Redirection table, click to add a string. The relevant Add tab displays.
k. In the From String field, select the from string from the drop-down list.
l. In the To String field, select the to string from the drop-down list.
m. Click Submit to return to the Add Filter tab.
n. Click Submit.
In this part of the example, we use the following values:
b. In the Filters table, click to add a new entry. The relevant Add tab displays.
c. Select Enable Filter.
d. In the Filter ID field, type the identifier for the filter. The valid range for this field is 1 to
2048.
e. In the Action field, select Redirect from the drop-down list.
In this part of the example, we use the following values:
Filter ID Action
10 Redirect
k. In the HTTP Redirection table, click to add a string. The relevant Add tab displays.
l. In the From String field, select the from string from the drop-down list.
m. In the To String field, select the to string from the drop-down list.
n. Click Submit to return to the Add Filter tab.
o. Click Submit.
In this part of the example, we use the following values:
b. In the VLAN table, click to add an entry. The relevant Add tab displays.
c. Select Enable VLAN.
d. In the VLAN ID field, type the identifier for the VLAN. The valid range for this field is 1 to
4090.
e. In the VLAN Name field, type a common name by which the VLAN will be known. The
maximum number of characters for this field is 32.
f. Click Submit.
In this example, we use the following values:
b. In the IP Interfaced table, click to add an entry. The relevant Add tab displays.
c. Select Enable IP Interface.
d. In the Interface ID field, type the identifier. The valid range for this field is 1 to 256.
e. In the IP Version field, select IPv6 from the drop-down list.
f. In the IP Address field, type the IP address.
g. In the Prefix field, type the prefix.
h. In the VLAN field, select the VLAN to associate with this interface from the drop-down list.
i. Click Submit.
In this example, we use the following values:
b. In the VLAN table, click to add an entry. The relevant Add tab displays.
c. Select Enable VLAN.
d. In the VLAN ID field, type the identifier for the VLAN. The valid range for this field is 1 to
4090.
e. In the VLAN Name field, type a common name by which the VLAN will be known. The
maximum number of characters for this field is 32.
f. In the VLAN Settings tab, select a port and use the arrows to move it between the Available
and Selected list. Repeat until all ports are configured for this VLAN.
g. Click Submit.
In this example, we use the following values:
b. In the IP Interfaced table, click to add an entry. The relevant Add tab displays.
c. Select Enable IP Interface.
d. In the Interface ID field, type the identifier. The valid range for this field is 1 to 256.
e. In the IP Version field, select IPv6 from the drop-down list.
f. In the IP Address field, type the IP address.
g. In the Prefix field, type the prefix.
h. In the VLAN field, select the VLAN to associate with this interface from the drop-down list.
i. Click Submit.
In this example, we use the following values:
b. In the VLAN table, click to add an entry. The relevant Add tab displays.
c. Select Enable VLAN.
d. In the VLAN ID field, type the identifier for the VLAN. The valid range for this field is 1 to
4090.
e. In the VLAN Name field, type a common name by which the VLAN will be known. The
maximum number of characters for this field is 32.
f. In the VLAN Settings tab, select a port and use the arrows to move it between the Available
and Selected list.
g. Click Submit.
In this example, we use the following values:
b. In the IP Interfaced table, click to add an entry. The relevant Add tab displays.
c. Select Enable IP Interface.
d. In the Interface ID field, type the identifier. The valid range for this field is 1 to 256.
e. In the IP Version field, select IPv6 from the drop-down list.
f. In the IP Address field, type the IP address.
g. In the Prefix field, type the prefix.
h. In the VLAN field, select the VLAN to associate with this interface from the drop-down list.
i. Click Submit.
In this example, we use the following values:
b. In the Real Servers table, click to add an entry. The relevant Add tab displays.
c. Select Enable Real Server.
d. In the Real Server ID field, type the identifier for the real server. This field accepts a
maximum of 32 characters, including letters, numbers, hyphens, and underscores.
e. In the IP Version field, select IPv6 from the drop-down list.
f. In the Server IP Address field, type the server IP address.
g. Click Submit.
In this example, we use the following values:
b. In the Real Servers table, click to add an entry. The relevant Add tab displays.
c. Select Enable Real Server.
d. In the Real Server ID field, type the identifier for the real server. This field accepts a
maximum of 32 characters, including letters, numbers, hyphens, and underscores.
e. In the IP Version field, select IPv6 from the drop-down list.
f. In the Server IP Address field, type the server IP address.
g. Click Submit.
In this example, we use the following values:
b. In the Server Groups table, click to add an entry. The relevant Add tab displays.
c. In the Server Group ID field, type an identifier for the group. This field allows a maximum
of 32 characters, including letters, numbers, hyphens, and underscores.
d. In the IP Version field, select IPv6 from the drop-down list.
e. In the Real Servers tab, select a server and use the arrows to move it between the
Available and Selected lists. Repeat until all servers are configured.
f. Click Submit.
In this example, we use the following values:
10. Configure the IPv6 redirection filter to redirect all HTTP traffic to the cache servers.
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, click to add a new entry. The relevant Add tab displays.
c. Select Enable Filter.
d. In the Filter ID field, type the identifier for the filter. The valid range for this field is 1 to
2048.
e. In the Description field, type a common name by which this filter will be known. This field
accept up to 31 characters.
f. In the Action field, select Redirect from the drop-down list.
g. In the Group ID field, select a group ID from the drop-down list.
In this part of the example, we use the following values:
l. Click Submit.
11. Configure IPv6 default filter to allow other traffic.
a. Select Configuration > Application Delivery > Filters.
b. In the Filters table, click to add a new entry. The relevant Add tab displays.
c. Select Enable Filter.
d. In the Filter ID field, type the identifier for the filter. The valid range for this field is 1 to
2048.
e. In the Description field, type a common name by which this filter will be known. This field
accept up to 31 characters.
f. In the Action field, select Allow from the drop-down list.
g. In the Match Settings tab, select IPv6 in the IP Version field.
h. Click Submit.
In this part of the example, we use the following values:
12. Enable filter processing on client ports and add the two filters to the client ports.
a. Select Configuration > Application Delivery > Port Processing.
b. In the Port Processing table, select an entry and click , or double-click the entry you want
to edit. The relevant Edit tab displays.
c. Select Filter/Outbound LLB.
d. Select a filter ID and use the arrows to move the ID between the Available and Selected
lists. Repeat until all filters are configured for this port.
e. Click Submit.
In this example, we use the following values:
Selected Filters
1, 2048
Term Description
active-active A configuration in which two Alteons can process traffic for the same
configuration service at the same time. Both Alteons share interfaces at Layer 3 and
Layer 4, meaning that both Alteons can be active simultaneously for a
given IP routing interface or load balancing virtual server (VIP).
active-standby A configuration in which two Alteons are used. The active Alteon supports
configuration all traffic or services. The backup Alteon acts as a standby for services on
the active master Alteon. If the master Alteon fails, the remaining Alteon
takes over processing for all services. The backup Alteon may forward
Layer 2 and Layer 3 traffic, as appropriate.
DIP (destination IP The destination IP address of a frame.
address)
dport (destination port) The destination port (application socket: for example, HTTP-80, HTTPS-
443, DNS-53).
hot-standby A configuration in which two Alteons provide redundancy for each other.
configuration One Alteon is elected master and actively processes Layer 4 traffic. The
other Alteon (the backup) assumes the master role if the master fails.
In a hot-standby configuration, the Spanning Tree Protocol (STP) is not
needed to eliminate bridge loops. This speeds up failover when an Alteon
fails. The standby Alteon disables all data ports configured as hot-standby
ports, whereas the master Alteon sets these same ports to forwarding.
Consequently, on a given Alteon, all virtual routers are either master or
backup; they cannot change state individually.
LAG (link aggregation A logical port containing physical ports, as provided for by the Link
group) Aggregation Control Protocol (LACP). A LAG can contain up to a total of
eight physical and standby ports.
NAT (Network Address Any time an IP address is changed from one source IP or destination IP
Translation) address to another address, network address translation (NAT) can be
said to have taken place. In general, half NAT is when the destination IP or
source IP address is changed from one address to another. Full NAT is
when both addresses are changed from one address to another. No NAT is
when neither source nor destination IP addresses are translated. Virtual
server-based load balancing uses half NAT by design, because it translates
the destination IP address from the virtual server IP address to that of one
of the real servers.
preemption In VRRP, preemption causes a virtual router that has a lower priority to
become the backup, should a peer virtual router start advertising with a
higher priority.
preferred master An Alteon platform that is always active for a service, and forces its peer
to be the backup.
Preferred master is set according to VRRP priority. If a primary device is
set with VRRP priority 101, and a secondary device is set with priority
100, then primary device is preferred master.
Term Description
priority In VRRP, the value given to a virtual router to determine its ranking with
its peers. A higher number wins out for master designation.
Values: 1254 for an IP renter, 255 for an IP owner
Default: 100
proto (protocol) The protocol of a frame. Can be any value represented by a 8-bit value in
the IP header adherent to the IP specification, such as TCP, UDP, OSPF,
ICMP, and so on.
real server group A group of real servers that are associated with a virtual server IP
address, or a filter.
RIP (real server IP An IP address to which Alteon load balances when requests are made to a
address) virtual server IP address (VIP).
redirection or filter- A type of load balancing that operates differently from virtual server-
based load balancing based load balancing. With this type of load balancing, requests are
transparently intercepted and redirected to a server group.
Transparently means that requests are not specifically destined for a
virtual server IP address that Alteon owns. Instead, a filter is configured
on Alteon. This filter intercepts traffic based on certain IP header criteria
and load balances it.
Filters can be configured to filter on the SIP/range (via netmask), DIP/
range (via netmask), protocol, sport/range or dport/range. The action on
a filter can be Allow, Deny, Redirect to a Server Group, or NAT (translation
of either the source IP or destination IP address). In redirection-based
load balancing, the destination IP address is not translated to that of one
of the real servers. Therefore, redirection-based load balancing is
designed to load balance Alteons that normally operate transparently in
your networksuch as a firewall, spam filter, or transparent Web cache.
SIP (source IP address) The source IP address of a frame.
split brain A failure condition in which there is no communication or synchronization
between two Alteon platforms which both behave as the master.
sport (source port) The source port (application socket: for example: HTTP-80, HTTPS-443,
DNS-53).
tracking A method to increase the priority of a virtual router and, as a result, the
master designation (with preemption enabled).
Term Description
virtual server load Classic load balancing. Requests destined for a virtual server IP address
balancing (VIP), which is owned by Alteon, are load balanced to a real server
contained in the group associated with the VIP. Network address
translation is done back and forth, by Alteon, as requests come and go.
Frames come to Alteon destined for the VIP. Alteon then replaces the VIP
and with one of the real server IP addresses (RIPs), updates the relevant
checksums, and forwards the frame to the server for which it is now
destined. This process of replacing the destination IP (VIP) with one of the
real server addresses is called half NAT. If the frames were not sent to the
address of one of the RIPs using half NAT, a server would receive the
frame that was destined for its MAC address, forcing the packet up to
Layer 3. The server would then drop the frame, because the packet would
have the DIP of the VIP, and not that of the server (RIP).
VRRP (Virtual Router A protocol that acts similarly to Ciscos proprietary HSRP address sharing
Redundancy Protocol) protocol. The reason having for both of these protocols is so Alteons have
a next hop or default gateway that is always available. Two or more
Alteons sharing an IP interface are either advertising or listening for
advertisements. These advertisements are sent via a broadcast message
to an address such as 224.0.0.18.
With VRRP, one Alteon is considered the master and the other the backup.
The master is always advertising via broadcasts. The backup Alteon is
always listening for the broadcasts. Should the master stop advertising,
the backup takes over ownership of the VRRP IP and MAC addresses as
defined by the specification. Alteon announces this change in ownership to
Alteons around it by way of a Gratuitous ARP, and advertisements. If the
backup Alteon did not perform Gratuitous ARP, the Layer 2 devices
attached to Alteon would not know that the MAC address had moved in
the network. For a more detailed description, refer RFC 2338.
VRRP router A physical router running the Virtual Router Redundancy Protocol.
virtual router (VR) An address shared by two Alteon platforms using VRRP, as defined in
RFC 2338. A virtual router is the master on one Alteon, and the backup on
the other. Alteon determines which virtual router to use for interfaces,
virtual IP addresses, and proxy IP addresses.
For each virtual router, the virtual router identifier (VRID) and the IP
address are the same on both Alteons in the high availability solution.
VRID (virtual router In VRRP, a value used by each virtual router to create its MAC address and
identifier) identify its peer for which it is sharing this VRRP address. The VRRP MAC
address as defined in the RFC is 00-00-5E-00-01-{VRID}. If you have a
VRRP address that two Alteons are sharing, then the VRID number must
be identical on both Alteons so each virtual router on each Alteon can
determine with which Alteon to share.
Assign the same VRID to the Alteon platforms in a high availability
solution. Radware recommends that you do not use this VRID for other
devices in the same VLAN.
Values: 1255
Term Description
virtual router MAC A MAC address associated with a virtual router. For legacy-based MAC
address addresses, the five highest-order octets of the virtual router MAC address
are the standard MAC prefix defined in RFC 2338. The VRID is used to
form the lowest-order octet.
The MAC address format is as follows:
If HA ID is non-zero00:03:B2:78:XX:XX where XX:XX is the
combination of HAID and VRID.
If HA ID=0 for IPv400:00:5E:00:01:XX.
If HA ID=0 for IPv600:00:5E:00:02:XX.
where XX is the VRID.
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.
The master forwards packets sent to the virtual interface router. It also
responds to Address Resolution Protocol (ARP) requests sent to the virtual
interface routers 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, the virtual router backup becomes the master
and assumes its responsibilities.
VRRP advertisement The master periodically sends advertisements to an IP multicast address.
messages As long as the backups receive these advertisements, they remain in the
backup state. If a backup does not receive an advertisement for three
advertisement intervals, it initiates a bidding process to determine which
VRRP router has the highest priority and takes over as master. The
advertisement interval must be identical for all virtual routers, or virtual
router groups.
virtual interface router An IP interface that is bound to a virtual router.
(VIR)
Virtual interface IP A VRRP router where the associated Layer 3 interface IP address matches
address owner the VRRP real interface IP address.
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, but use only a renter.
A VIR owner is always dynamically assigned a priority of 255. If active, the
VIR owner always assumes the master role, regardless of preemption
settings.
Tracking is not possible with a priority of 255.
virtual server router A virtual router supporting Layer 4 (VIP) interfaces.
(VSR)
virtual proxy router A proxy IP address that is bound to a virtual router.
(VPR)
Term Description
VRRP sharing When enabled, both Alteons are able to load balance an ingress request,
even if an Alteon is not in the master. A get request is directed by the
routing protocol.
When disabled, only a master Alteon can load balance an ingress request.
A get a request directed by the routing protocol is not processed.
Sharing is enabled in active-active configurations, and disabled in all other
configurations, such as active-standby and hot-standby
VIP (virtual server IP An IP address that Alteon owns and uses to terminate a load balancing
address) request for a particular service request.
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 sell, assign, license, 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 Radwares then-current list prices.
3. Lab License. Notwithstanding anything to the contrary in this License Agreement, if the
Software is provided to you for use in your lab, as indicated in your purchase order, sales
receipt, the part number description for the Software, or otherwise, then You may use the
Software only for internal testing and development purposes in your lab but not for any
production use purposes.
4. 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.
5. 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 Radwares
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,
sub-licensable 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 5 will survive
the termination or expiration of this Agreement.
6. 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,
disassemble, decompile, reverse engineer or otherwise attempt to derive source code (or the
underlying ideas, algorithms, structure or organization) from the Software, in whole or in part,
except and only to the extent: (i) applicable law expressly permits any such action, despite this
limitation, in which case you agree to provide Radware at least ninety (90) days advance written
notice of your belief that such action is warranted and permitted and to provide Radware with an
opportunity to evaluate if the laws requirements necessitate such action, or (ii) required to
debug changes to any third party LGPL-libraries linked to by the Software; or (c) create,
develop, license, install, use, or deploy any software or services to circumvent, enable, modify
or provide access, permissions or rights which violate the technical restrictions of the Software;
(d) in the event the Software is provided as an embedded or bundled component of another
Radware Product, you shall not use the Software other than as part of the combined Product and
for the purposes for which the combined Product is intended; (e) remove any copyright notices,
identification or any other proprietary notices from the Software (including any notices of Third
Party Software (as defined below); or (f) 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) to 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.
7. 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.
8. 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 Radwares authorized service
personnel.
9. 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.
10. 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 6 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 6 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.
11. 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 5-15
shall survive any termination of this License Agreement. The Licenses granted under this License
Agreement are not transferable and will terminate upon: (i) termination of this License
Agreement, or (ii) transfer of the Software, or (iii) in the event the Software is provided as an
embedded or bundled component of another Radware Product, when the Software is un-bundled
from such Product or otherwise used other than as part of such Product. 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.
12. Export. The Software or any part thereof may be subject to export or import controls under
applicable export/import control laws and regulations including such 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. Furthermore, You hereby covenant
and agree to ensure that your use of the Software is in compliance with all other foreign,
federal, state, and local laws and regulations, including without limitation all laws and
regulations relating to privacy rights, and data protection. You shall have in place a privacy
policy and obtain all of the permissions, authorizations and consents required by applicable law
for use of cookies and processing of users data (including without limitation pursuant to
Directives 95/46/EC, 2002/58/EC and 2009/136/EC of the EU if applicable) for the purpose of
provision of any services.
13. US Government. To the extent you are the U.S. government or any agency or instrumentality
thereof, you acknowledge and agree that the Software is a commercial computer software and
commercial computer software documentation pursuant to applicable regulations and your use
of the is subject to the terms of this License Agreement.
14. Governing Law. This License Agreement shall be construed and governed in accordance with
the laws of the State of Israel.
15. 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 2016, Radware Ltd. All Rights Reserved.