Brocade Bcle Nutshell Certification Study Tools PDF

BCLE in a Nutshell
Study Guide for

Exam 150-320
Exam Preparation Materials
Revision May 2010

Corporate Headquarters - San Jose, CA USA
T: (408) 333-8000
info@brocade.com
European Headquarters - Geneva, Switzerland

T: +41 22 799 56 40
emea-info@brocade.com
Asia Pacific Headquarters - Singapore

T: +65-6538-4700
apac-info@brocade.com
© 2010 Brocade Communications Systems, Inc. All Rights Reserved.
Brocade, the Brocade B-weave logo, Fabric OS, File Lifecycle Manager, MyView, Secure Fabric OS,
SilkWorm, and StorageX are registered trademarks and the Brocade B-wing symbol and Tapestry are
trademarks of Brocade Communications Systems, Inc., in the United States and/or in other countries.
FICON is a registered trademark of IBM Corporation in the U.S. and other countries. All other brands,
products, or service names are or may be trademarks or service marks of, and are used to identify,
products or services of their respective owners.
Notice: This document is for informational purposes only and does not set forth any warranty,
expressed or implied, concerning any equipment, equipment feature, or service offered or to be offered
by Brocade. Brocade reserves the right to make changes to this document at any time, without notice,
and assumes no responsibility for its use. This informational document describes features that may not
be currently available. Contact a Brocade sales office for information on feature and product availability.
Export of technical data contained in this document may require an export license from the United
States government.
Revision: May 2010

BCLE in a Nutshell 2010 Edition
BCLE in a Nutshell 2010
Objective: The BCLE Nutshell guide is designed to help you prepare for the BCLE Certification, exam number
150-320.
Audience: The BCLE Nutshell self-study guide is intended for those who have successfully completed the
ETH 202 Introduction to ServerIron ADX Web Switching and Load Balancing course, and who wish to
undertake self-study or review activities before taking the actual BCLE exam. The BCLE guide is not intended
as a substitute for classroom training or hands-on time with Brocade products.
How to make the most of the BCLE guide: The BCLE guide summarizes the key topics on the BCLE exam for
you in an easy to use format. It is organized closely around the exam objectives. We suggest this guide be
used in conjunction with our free online knowledge assessment test. To benefit from the BCLE guide, we
strongly recommend you have successfully completed the ETH 202 Introduction to ServerIron ADX Web
Switching and Load Balancing course.
We hope you find this useful in your journey towards BCLE Certification, and we welcome your feedback by
sending an email to jcannata@brocade.com.
Helen Lautenschlager Joe Cannata

Director of Education Solutions Certification Manager
©2010 Brocade Communications i

ii ©2010 Brocade Communications

1 - Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Factory Pre-loaded Software: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Upgrading a Boot Image from 12.0.00 to 12.1.00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Upgrade Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Upgrading a Boot Image from 12.0.00 to 12.1.00 on a Dual-Management System . . . . . . . . 2
Downloading a Brocade ADX Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Downloading a Software Image as Primary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
When the Brocade ADX reloads, it will boot using the primary image. . . . . . . . . . . . . . . . . . . . 3
Downloading a Software Image as Secondary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
When the Brocade ADX reloads, it will boot using the secondary image. . . . . . . . . . . . . . . . . . 3
Copying a File Between Flash and a USB Drive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Displaying System Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Brocade ADX 4000 and Brocade ADX 10000 Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Hardware-based SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Setting Up Local User Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Configuring Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Enabling Telnet Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Enabling Telnet Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Configuring Authentication-method Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Using ACLs to Restrict Remote Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2 - Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Main Brocade ADX Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Basic Server Load Balancing (SLB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Global Server Load Balancing (GSLB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
URL-based Server Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Configuring Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
SLB Design Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Configure Real Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Cloning Real Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Configure Virtual Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Disabling Port Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Configurable Application Grouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Hash-based SLB with Server Persistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Configuring Primary and Backup Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Designating a Real Server as a Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Enabling a VIP to use the Primary and Backup Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Enabling HTTP Redirect on a Virtual Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Tracking the Primary Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Configuring a Track Port Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Alias Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Many-to-one TCP or UDP Port Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Binding Same Real Ports to Multiple VIP Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
©2010 Brocade Communications iii

Load-balancing Predictor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Least Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Round Robin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Weighted Round Robin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Weighted and Enhanced Weighted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Connection Assignments for Weighted Load-balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Connection Assignments for Enhanced Weighted Load-balancing . . . . . . . . . . . . . . . . . . . . . 25
Dynamic Weighted Predictor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Dynamic-weighted Direct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Dynamic-weighted Reverse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Changing the Load-balancing Predictor Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Assigning Weights to the Real Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Configuring Dynamic Weighted Predictor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Configure a Virtual Server with Dynamic Weighted Predictor . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Slow Start of the Backup and the Primary Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Defining the Maximum Number of Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Layer 4 and Layer 7 Health Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Health Checks Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Layer 4 Health Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Configuring a Port Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
FIN Close for Server Health Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Configuring HTTP Content Matching Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3 - Additional Server Load Balancing Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Source-NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Direct Server Return (DSR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Health Checks with DSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
GSLB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
DNS Hierarchical Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
GSLB Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Removing All Addresses Except the Best Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Content Switching (CSW). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Source IP, Virutal IP, Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Port Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Cookie Based Persistence (Switching/Hashing) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Cookie Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
SSL ID Based Persistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
URL Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Layer 7 CSW: 3-Step Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Inserting an IP Address in a Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Stateless SLB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Security Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4 - ADX Administration GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
GUI Access Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Define Global System Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Creating a Real Server and Enabling Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Creating a Virtual Server/Port and Enabling Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Configuring a Health Check for a Real Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
iv ©2010 Brocade Communications

5 - Optimization and High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Hot Standby SLB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Symmetric SLB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Displaying VIP Owner in HA Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Sym-Active SLB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Transaction Rate Limiting (TRL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Connection Rate Control (CRC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6 - Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Display Real Server Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Show Server Real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Server States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Application Port States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Display Virtual Server Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Displaying Virtual Servers Configuration Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Displaying Port-Binding Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Displaying GSLB Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Taking the Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
©2010 Brocade Communications v

vi ©2010 Brocade Communications

List of Figures
Brocade ADX 1000 Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Brocade ADX 4000 Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Brocade ADX 10000 Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Brocade ADX 10000 Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Brocade ADX Management and SSL Expansion Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
SLB Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
GSLB Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
URL-based SLB Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
SLB Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Virtual Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Brocade ADX in a Multi-netted Network Without Source-NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Brocade ADX in a Multi-netted Network With Source-NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
DSR Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
SYN-Defense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
SYN-Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Brocade ADX GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
GUI Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Brocade ADX Web Interface Home Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Brocade ADX GUI Global Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Traffic Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Port Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Virtual Server/Port and Enabling Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Configuring a Virtual Server Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Virtual Server Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Configuring a Health Check for a Real Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Health Check Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Generic Helath Check Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Active-Standby Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Symmetric SLB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Sample NDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
©2010 Brocade Communications vii

viii ©2010 Brocade Communications

1 - Installation
Functions
The Brocade ADX is an Application Delivery Controller (ADC). ADCs enhance Internet-based application avail-
ability, performance, and security by providing:
• Layer 4 through Layer 7 redirection, load balancing, and failover
• TCP connection multiplexing
• Server offload such as Secure Socket Layer (SSL) acceleration and TCP connection management
• Data compression
• Network address translation (NAT)
• Network-level security functions, distributed Denial of Service (DDoS) protection, and server cloaking
• Transparent cache switching
Software
Factory Pre-loaded Software:

Brocade ADX Application switches are pre-loaded with a switch image on both primary and secondary flash. If
you place an order for Brocade ADX (PREM) then the unit will still ship with switch code on primary and sec-
ondary flash. However, the unit will be activated for PREM code, so you will be able to download the PREM
code from the Brocade Knowledge Portal and run it on the system.
Upgrading a Boot Image from 12.0.00 to 12.1.00

The Brocade ADX was released with Software version 12.0.00 and boot and monitor code version
“Dob12000”. When upgrading to the latest Application image, the boot code needs to be upgraded to
dob12100. This boot image upgrade is a one-time process and is integrated into the Application image for
future boot code upgrades. When upgrading the boot image, make sure that there will not be any power fail-
ure. A power failure during the upgrade procedure can result in the corruption of the existing boot code and
may require you to RMA the Management module. The boot image can be upgraded only using a console con-
nection to the management port of the Brocade ADX. The boot code can only be upgraded through the Man-
agement port and the image must be downloaded from a TFTP server directly connected to the Management
Port. In Brocade ADX version 12.1.00, the management port will be enabled and you can access the Brocade
ADX using the management port.
Upgrade Procedure
1. Check the version of the boot image in your Brocade ADX by issuing command show version command.
Note that the Boot version and Monitor version are the same and they should be dob12000.
ADX# show version
2. Reload the Brocade ADX and interrupt the normal boot cycle by pressing b to enter the monitor mode.
ADX# reload
3. Configure the Remote address to reach a TFTP Server from the Brocade ADX.
Monitor> remote addr 10.45.10.47 255.255.255.0
©2010 Brocade Communications 1

4. Configure the remote default gateway

Monitor> remote default-gateway 10.45.10.254
5. Check the network settings using the show remote command.
Monitor> show remote
IP address : 10.45.10.47
subnet mask : 255.255.255.0
default gateway : 10.45.10.254
6. Copy the Boot image from the TFTP Server using the following command.
Monitor> copy tf fl 10.45.10.1 A1B12100.bin A1B12100.bin
7. Check if the image is copied properly to the internal flash using the dir command.
8. Now boot the Brocade ADX in boot loader mode by issuing the following command.
boot system flash A1B12100.bin
9. Alternatively, the image can be booted directly from a TFTP server using the following command, but it is
advisable to copy the image to the internal flash and boot from internal flash. Command to boot from tftp
server:
boot system tftp 10.45.10.1 A1B12100.bin
10. Brocade ADX will then boot in the boot mode as follows.
Monitor> boot sys fl A1B12100.bin
......
MP-Appl#
11. Issue the upgrade all command to upgrade all the BPs and MP boot code.
MP-Appl# upgrade all
12. After the upgrade is complete, reboot the Brocade ADX by power cycling the device.
Executing the reset command will reload the device, but it is advisable to power cycle during the boot
image upgrade.
13. After the Brocade ADX comes up, please check the Boot Code version using the show version
command.
ADX# show version
Upgrading a Boot Image from 12.0.00 to 12.1.00 on a Dual-Management System (2 Management Modules)
To prevent the active-standby feature in the application image from interfering with the boot upgrade process,
you must observe the following procedure for a dual-management system.
1. Both management modules must be placed at the Monitor> prompt as described in Step 2 of the previous
procedure.
2. On either of the management modules, follow the procedures described in the previous section up through
Step 10 where you execute the upgrade all command. Do this while keeping the other management
module at the Monitor> prompt.
3. Reset the management module where the upgrade all command was executed and then place it at the
Monitor> prompt again.
2 ©2010 Brocade Communications

4. Return to the management module that hasn’t been upgraded and perform the same procedure that you
performed on the first management module.
After the upgrade procedure is performed on both management modules, you can safely power-cycle the
Brocade ADX. Optionally, instead of power-cycling you can execute the reset command to reload the device,
but it is advisable to power cycle during the boot image upgrade.
Downloading a Brocade ADX Image

By default, a Brocade ADX switch boots from primary. Optionally, it can be configured to boot from secondary.
Downloading a Software Image as Primary

To download a software image to a Brocade ADX switch and reload, follow these steps:
1. Copy the correct Brocade ADX software image to a TFTP server.
2. Use the copy tftp flash command on the Brocade ADX switch to download the software image from the
TFTP server, as shown in the following:
ADX# copy tftp flash <ip_addr> asm12100.bin primary
In this example the image is downloaded to flash as “primary”.
3. Reload the Brocade ADX as shown in the following:
ADX# reload
When the Brocade ADX reloads, it will boot using the primary image.
Downloading a Software Image as Secondary

By default, the Brocade ADX, uses the “primary” image as its working image. You can configure a Brocade ADX
switch to use the “secondary” image as its working image as shown in the following:
1. Copy the correct Brocade ADX software image to a TFTP server.
2. Use the copy tftp flash command on the Brocade ADX switch to download the software image from the
TFTP server, as shown in the following:
ADX# copy tftp flash <ip_addr> asm12100.bin secondary
In this example the image is downloaded to flash as “secondary”.
3. Configure the Brocade ADX switch to use “secondary” as its working image.
ADX(config)# boot system flash secondary
4. Save the running configuration to the startup configuration and reload the switch, as shown in the
following.
ADX# write memory
ADX# reload
When the Brocade ADX reloads, it will boot using the secondary image.

Copying a File Between Flash and a USB Drive

You can copy a file from a USB drive (internal or external) to flash or from flash to a USB drive (internal or
external). The following example copies the file named asm12000.bin on an external USB drive (usb1) to a
file of the same name in flash on the Brocade ADX switch.
ADX# copy usb1 asm12000bin asm12000.bin
Syntax: copy usb0 | usb1 flash <from-filename> <to-filename>
The usb0 parameter directs the Brocade ADX to copy the specified file from its internal USB drive. The usb1
parameter directs the Brocade ADX to copy the specified file from an externally connected USB drive. The
<from-filename> variable specifies the name of the file that you want to copy from the USB drive to the
Brocade ADX flash. The <to-filename> variable specifies the name of the file that you are copying to on
the Brocade ADX flash.
The following example copies the file named asm12000.bin on the Brocade ADX flash to a file of the same
name on a USB drive connected to the USB port on the Brocade ADX switch.
ADX# copy flash usb1 asm12000bin asm12000.bin
Syntax: copy flash usb0 | usb1 <from-filename> <to-filename>
The usb0 parameter directs the Brocade ADX to copy the specified file in flash to its internal USB drive. The
usb1 parameter directs the Brocade ADX to copy the specified file in flash to an externally connected USB
drive. The <from-filename> variable specifies the name of the file that you want to copy from flash to the
USB drive. The <to-filename> variable specifies the name of the file that you are copying to on the USB
drive.
Displaying System Information

To view the software and hardware details for the system, enter the following command.:
ADX# show version
Copyright (c) 1996-2009 Brocade Communications Systems, Inc.
Boot Version 02.00.09 Apr 27 2009 17:13:05 PDT label: dobv2
Monitor Version 02.00.09 Apr 27 2009 17:13:05 PDT label: dobv2
System Version 12.00.00 May 1 2009 13:01:28 PDT label: ASM12000dev
AXP Version: 0.00 Dated: 2009/03/31 11:53:57
PAX Version: 0.0 Dated: 2009/01/23 11:46:57
MBRIDGE Version: 0009, Device ID # bebe
Backplane: ServerIronADX 10000, Serial #: 123451Ìÿÿ
Chassis: ServerIronADX 10000, Serial #: Not-Present
==========================================================================
SL slot-mp1: ServerIron Management Mod, ACTIVE
Serial #: Not-Present
Part #: Not-Present
==========================================================================
SL slot-sf1: ServerIron Switch Fabric Mod
Part #: Not-Present
Version #: 111d8037-00-111d802d-0d-01b720
==========================================================================

SL slot-sf2: ServerIron Switch Fabric Mod

Part #: Not-Present
Version #: 111d8037-00-111d802d-0d-01b720
==========================================================================
SL slot-asm1: ServerIron 8BP App Switch Mod
Part #: Not-Present
Version #: 111d8037-00
Application Processors: 8
1333 MHz Power PC processor (version 00008021/0030) 533 MHz bus
Boot Version 02.00.09 Apr 27 2009 17:12:28 PDT label: dobv2
==========================================================================
Active management module:
1499 MHz Power PC processor (version 00008021/0030) 599 MHz bus
1408 KB Boot flash
65536 KB Code flash
4096 MB DRAM
The system uptime is 3 minutes 6 seconds
The system started at 11:10:36, GMT+00, Tue May 05 2009
The system - boot source: primary, mode: warm start, soft reset, total resets: 0

Hardware
Figure 1: Brocade ADX 1000 Chassis

Brocade ADX 1000 chassis basics (all models):
• 1 RU form factor
• Two hot-pluggable AC or DC power supplies (one+one redundant)
• By default, the system ships with one power supply.
• One hot-pluggable fan tray
• Front-to-back air cooling

Brocade ADX 4000 chassis basics:
• Two hot-pluggable AC or DC power supplies (one+one redundant). One power supply is required, and one is
optional for redundancy. By default, the system ships with one power supply.
• One hot-pluggable fan tray with three fans
• Side-to-side air cooling: left-to-right
• Card slots to accommodate modules

A fully-loaded Brocade ADX 4000 can accommodate the following components:

• Two Ethernet Interface Modules
• Two Application Services Modules (ASM)
• One Management Module (MM)
• One Switch Fabric Module (SFM)
• One fan tray
• Two AC or DC power supplies (one required, one redundant)


• Four hot-pluggable AC or DC power supplies (two+two redundant). Two power supplies are required, and
two are optional for redundancy. By default, the system ships with two power supplies.
• One hot-pluggable fan tray with six fans
• Side-to-side air cooling - left-to-right
• Four Ethernet Interface Modules
• Four Application Services Modules (ASM)
• Two Management Modules (MM)
• Two Switch Fabric Modules (SFM)
• One fan tray
• Four AC or DC power supplies (two required, one or two redundant)


• Four hot-pluggable AC or DC power supplies (two+two redundant). Two power supplies are required, and
two are optional for redundancy. By default, the system ships with two power supplies.
• One hot-pluggable fan tray with six fans
• Front-to-back air cooling
• Four Ethernet Interface Modules
• Four Application Services Modules (ASM)
• Two Management Modules (MM)
• Two Switch Fabric Modules (SFM)
• One fan tray
• Four AC or DC power supplies (two required, one or two redundant)

Brocade ADX 4000 and Brocade ADX 10000 Modules

The Brocade ADX 4000 and Brocade ADX 10000 accommodate the following modules:
1. “Ethernet interface modules”
Support is provided for the 4x10G, 12x1G RJ-45, and 12x1G SFP.
2. “Switch Fabric Module (SFM)” Allows different boards to talk to each other through the switching fabric.
3. “Application Switch Module (ASM)”
The Application Switch Module is the building block for scaling all ADX products. It consists of the
following:
a. Application Core (= Barrel Processor.)
b. ASM switch fabric is local to the ASM module. This is not the same as the SFM which interconnects all
the blades.
c. AXP (Application Switch Processor)
- One AXP per 4 App Cores
- Provides Syn-cookie & DDoSH/W support
- TCP Options Processing
- Checksum Processing
- Outbound packet processing
- Room for future app acceleration functions
d. PAX (Packet Acceleration Processor)
- Counter Sync
- Server Selection H/W Assist
4. “Management Module (MM)”
Contains the main processor and also has the expansion slots for the two SSL daughter cards. The
MM will be shipped with the SSL daughter card populated and the SSL function will have to be turned
on through a licensing process.
Hardware-based SSL
The hardware-based SSL offering enables application delivery services including SSL offload, SSL termina-
tion, and SSL Proxy. Here are some specifics as relates to fixed/chassis systems:
• Fixed configuration Brocade ADX systems: Embedded SSL hardware module is included inside the Brocade
ADX 1000. After Feb 1, 2010, all fixed Brocade ADX 1000 systems ordered will have embedded SSL
hardware by default but usage of SSL capabilities will depend on whether the SSL SKU version was
ordered. Before Feb 1, 2010, only Brocade ADX 1000 systems ordered specifically to be SSL capable will
have this hardware option onboard and enabled at the factory.
• Chassis/Modular Brocade ADX systems: An SSL application expansion module hardware (co-located on a
Management module) provides SSL offload/termination/proxy services for Brocade ADX chassis series. A
Brocade ADX Chassis 4000/10000 can be ordered with an SSL-enabled management module or existing
systems can be upgraded with the addition of an SSL application expansion module onto one or both
management modules.

Figure 5: Brocade ADX Management and SSL Expansion Modules
Administration
Setting Up Local User Accounts

For each user account, you specify the user name. You can also specify:
• A password
• The privilege level, which can be one of the following:
• Full access (super-user). This is the default.
• Port-configuration access
• Read-only access
To configure user accounts, you must add a user account for super-user access before you can add accounts
for other access levels. You will need the super-user account to make further administrative changes.
To set up local user accounts, enter following commands:
ADX(config)# username greg-mcmillan nopassword
ADX(config)# username waldo privilege 5 password whereis
The first command adds a user account for a super-user with the user name "greg-mcmillan" and no
password with privilege level super-user. This user has full access to all configuration and display features.
The second command adds a user account for user name "waldo", password "whereis", with privilege level
read-only. “waldo” can look for information but cannot make configuration changes.
Syntax: [no] username <user-string> privilege <privilege-level> password | nopassword <password-string>

The privilege <privilege-level> parameter specifies one of the following:

• 0 – Full access (super-user)
• 4 – Port-configuration access
• 5 – Read-only access
The default privilege level is 0. To assign full access to the user account, you can enter the command without
privilege 0, as shown in the command example above.
The password | nopassword parameter indicates whether the user must enter a password. If you
specify password, enter the string for the user's password. When the system boots up with the default
configuration, use username admin and password brocade to get access to the console.
Configuring Telnet
The Brocade ADX supports up to five concurrent inbound Telnet and SSH sessions, one outbound
Telnet session, and console access. Write access through Telnet and SSH is limited to one session only.
Telnet or SSH to the assigned management IP address (assuming it is reachable) to access the CLI shell
running Switch (S) code.
Enabling Telnet Authentication

To use local access control or a RADIUS or TACACS/TACACS+ server to authenticate Telnet access to the
Brocade ADX, enter the following command:
ADX(config)# enable telnet authentication
Syntax: [no] enable telnet authentication
Enabling Telnet Password

To assign a password for Telnet session access, enter the following command:
ADX(config)# enable telnet password secretsalso
Syntax: [no] enable telnet password <text>
The <text> parameter specifies the password and is up to 32 alphanumeric characters. To close a Telnet
session, enter logout.
Configuring Authentication-method Lists

To implement one or more authentication methods for securing access to the device, you configure
authentication-method lists that set the order in which the authentication methods are consulted.
In an authentication-method list, you specify the access method (Telnet, Web, SNMP, and so on) and the
order in which the device tries one or more of the following authentication methods:
• Local Telnet login password
• Local password for the Super User privilege level
• Local user accounts configured on the device
• Database on a TACACS or TACACS+ server
• Database on a RADIUS server
• No authentication

Example:
To configure the device to consult a RADIUS server first to authenticate attempts to access the
Privileged EXEC and CONFIG levels of the CLI, then consult the local user accounts if the RADIUS server is
unavailable, enter the following command:
ADX(config)# aaa authentication enable default radius local
Using ACLs to Restrict Remote Access

You can use standard ACLs to control the following access methods to management functions on a
Brocade ADX:
• Telnet access
• SSH access
• Web management access
• SNMP access
To configure access control for these management access methods.
1. Configure an ACL with the IP addresses you want to allow to access the device
2. Configure a Telnet access group, SSH access group, web access group, and SNMP community strings.
Each of these configuration items accepts an ACL as a parameter. The ACL contains entries that identify
the IP addresses that can use the access method.
To configure an ACL that restricts Telnet access to the device, enter commands such as the following:
ADX(config)# access-list 10 deny host 209.157.22.32 log
ADX(config)# access-list 10 deny 209.157.23.0 0.0.0.255 log
ADX(config)# access-list 10 deny 209.157.24.0 0.0.0.255 log
ADX(config)# access-list 10 deny 209.157.25.0/24 log
ADX(config)# access-list 10 permit any
ADX(config)# telnet access-group 10
ADX(config)# write memory

2 - Configuration
Main Brocade ADX Applications
Basic Server Load Balancing (SLB)

Server Load Balancing (SLB) maps one logical (virtual) server connection to multiple physical (real) servers.
Thus, a single IP address (VIP) can serve as the connection point for multiple TCP/UDP services such as HTTP,
FTP or Telnet rather than each of the services requiring a different IP address for each server. These services
can be located on a single server or across multiple servers.
Figure 6: SLB Example

The benefits of Server Load Balancing are:
• Load balance across different servers running same application
• Server and application health checks with seamless failover
• Server maintenance & scaling without impacting service
• Efficiently utilize servers using load balancing algorithms
• Secure servers from DoS, SYN, SYN-ACK attacks

Global Server Load Balancing (GSLB)
GSLB is a feature that extends load balancing capability for the ADX ServerIron to multiple sites. These sites
can be located any where across the globe. When a customer makes a request the GSLB box decides how to
handle the traffic.
The benefits of Global Server Load Balancing are:
• Leverage and enhance existing authoritative DNS Server(s)
• Transparently modify DNS response based on server/app. availability
• Site load condition intelligence gathered using Brocade protocol
Figure 7: GSLB Example
URL-based Server Load Balancing

URL switching is the Brocade ADX’s ability to direct HTTP requests to a server, or group of servers, using
information in the text of a URL string. The Brocade ADX examines the contents of a URL string and makes a
decision about where to send the packet based on selection criteria in user-defined policies.
The benefits of URL-based Server Load Balancing are:
• Optimizes resource access
• Optimizes content distribution by load-balancing on
o Full path and filename of each URL
o URL suffix and/or prefix
The Brocade ADX can examine both the URL string and Host header field when determining where to send the
HTTP request.

Figure 8: URL-based SLB Example
Configuring Servers
SLB Design Example

• We want to configure (2) Virtual servers
- one for FTP users and one for HTTP users (Note: We could do this design with 1 Virtual IP [VIP])
• We will load balance the FTP users across servers 1 and 2
• We will load balance the HTTP users across servers 2 and 3
• We want to ensure no other protocol types (sockets) are sent to any of the three real servers
Figure 9: SLB Design

Configure Real Servers

Real Servers contain the content you wish to load balance. They are application servers which are either
directly attached to the ADX or L2 connected.
ADX> enable
No password has been assigned yet...
ADX# config term
ADX(config)# ip add 169.144.10.11/24
ADX(config)# ip default-gateway 169.144.10.1
ADX(config)# server real RS1 10.10.10.201
ADX(config-rs-RS1)# port ftp
ADX(config-rs-RS1)# server real RS2 10.10.10.202
ADX(config-rs-RS2)# port http
ADX(config-rs-RS2)# port http keep-alive
ADX(config-rs-RS2)# port ftp
ADX(config-rs-RS2)# server real RS3 10.10.10.203
ADX(config-rs-RS3)# port http
ADX(config-rs-RS3)# port http keep-alive
ADX(config-rs-RS3)# exit
ADX# write memory
Cloning Real Servers

To simplify configuration for large server farms, you can
clone real servers. When you clone a real server, you make a copy of the real server’s configuration
information under a new name. The copy includes the port bindings to the virtual server.
To clone a real server, enter commands such as the following:
ADX(config)# server real rs1 1.2.3.4
ADX(config-rs-rs1)# clone-server rs2 5.6.7.8
The first command changes the CLI to the configuration level for the real server you want to copy. The second
command creates a clone of real server rs1. The clone is named "rs2" and has IP address 5.6.7.8.

Configure Virtual Servers
Figure 10: Virtual Servers

After you define the actual application server’s physical addresses (real server), you then need to configure
the:
• External application server address on the ADX. The external application server is the virtual server.
• IP address or server name to which client browsers send requests.
This config represents the Figure 10 diagram above:

ADX(config)# server virtual-name VIP1 169.144.10.100
ADX(config-vs-VIP1)# port ftp
ADX(config-vs-VIP1)# bind ftp RS1 ftp RS2 ftp
ADX(config-vs-VIP1)# server virtual VIP2 169.144.10.200
ADX(config-vs-VIP2)# port http
ADX(config-vs-VIP2)# bind http RS2 http RS3 http
Disabling Port Translation

By default, the Brocade ADX translates the application port number requested by the client into the
application port number you specify on the virtual server when you bind it to the real server.
For example, if you bind port 80 on a virtual server to port 8080 on a real server, the Brocade ADX translates
the application port in the client’s request from port 80 into 8080 before forwarding the request to a real

server. A few Brocade ADX configurations require that you disable translation for an application port. For
example, if you want to bind multiple virtual IP addresses to the same real server, you must disable port
translation for all but one of the virtual IP addresses, then bind the virtual IP addresses to an alias port for the
application. Disabling port translation enables the virtual IP addresses to use the same actual port number on
the real server while the Brocade ADX collects and displays separate statistics for the alias port number
associated with each virtual IP address.
To disable translation for an application port, enter commands such as the following:
ADX(config)# server virtual-name-or-ip v1 209.157.22.1
ADX(config-vs-v1)# no port 80 translate
Syntax: [no] port <tcp/udp-port> translate
Configurable Application Grouping

By default, the Brocade ADX uses the predictor (load-balancing method) you configure for each new request
from a client to a virtual server. This works well for many situations. However, for some Web implementations,
it is desirable or even required to have the client continue to access the same real server for subsequent
requests.
You can configure the Brocade ADX to ensure that a client that accesses certain TCP or UDP ports on a VIP
always goes to the same real server. For example, you might want to configure the TCP or UDP ports related to
an interactive Web site so that when a client begins a session on the site, subsequent requests from the client
go to the same real server. As another example, you might want the real server to be able to arbitrarily assign
open TCP or UDP sessions with the client using ports dynamically allocated by the real server.
Application grouping parameters apply to virtual servers. When you configure a virtual server, you specify the
TCP or UDP ports on that virtual server. When you apply application grouping to a TCP or UDP port on a virtual
server, the application grouping overrides the predictor. The Brocade ADX allows you to configure the following
application grouping methods on an individual virtual-server basis:
• Sticky connections – When you add a TCP or UDP port to a virtual server, if you specify that the port is
“sticky”, a client request for that port always goes to the same real server unless the sticky age timer has
expired. The sticky age timer specifies how long the connection remains “sticky” (always goes to the same
real server) and is reset each time a new client request goes to the sticky port. Once the sticky timer
expires, the Brocade ADX uses the predictor (load-balancing metric) you have configured to select a real
server for requests for a port.
• Configurable TCP or UDP application groups – You can group a “primary” TCP or UDP port with up to four
additional TCP or UDP ports. After the Brocade ADX sends a client request for the primary port to a real
server, subsequent requests from the client for ports grouped with the primary port go to the same real
server.
• Concurrent connections – When you configure a TCP or UDP port in a virtual server to support concurrent
connections, the real server can open additional ("concurrent") TCP or UDP sessions with the client using
arbitrary TCP or UDP port numbers. Although the concurrent connections feature is similar to the
application group feature, application groups apply to specific TCP or UDP ports that you configure on the
virtual server. Concurrent connections enables the real server to arbitrarily determine the TCP or UDP ports
and assign them to the client.

By default, the concurrent property of a virtual TCP or UDP service port is enabled except for FTP, Telnet, TFTP,
HTTP, and SSL ports.
Hash-based SLB with Server Persistence:

This feature provides a persistent hashing mechanism for virtual server ports, which evenly distributes hash
assignments and enables a client to always be redirected to the same real server. The client will be directed
to a new real server only if the assigned real server fails. Using the sticky feature, the current maximum
persistence possible for Stateful SLB is 20 hours. This setting may not be sufficient for systems that always
need the client to be directed to the same real server, unless an event such as real server failure necessitates
reassignment of the client to a different server. When a client makes a request to the VIP, the Brocade ADX
calculates a hash value based on the client IP.
Configuring a Local or Remote Real Server:
When you define a real server, you specify whether the real server is local or remote:
• Local – A local server is one that is connected to the Brocade ADX at Layer 2. The Brocade ADX uses local
servers for regular load balancing.
• Remote – A remote server is one that is connected to the Brocade ADX through one or more router hops.
The Brocade ADX uses remote servers only if all the local servers are unavailable.
Configuring a local real server:
To configure a local real server, enter a command such as the following.

ADX(config)# server real Web1 207.95.55.21
ADX(config-rs-Web1)
Syntax: server real-name-or-ip <name> <ip-addr>
The server name is used to bind the server IP address, so that the real server name can be used to represent
the server. The server name can be any alphanumeric string of up to 32 characters.
Configuring a remote real server:
If the server is attached through one or more router hops, configure the server as remote. When you add a
remote real server, the Brocade ADX does not include the server in the predictor (load-balancing method).
Instead, the Brocade ADX sends traffic to the remote server only if all local real servers are unavailable. The
server name is used to bind the server IP address, so that the real server name can be used to represent the
server.
To configure a remote real server, enter a command such as the following.
Syntax: server remote-name <name> <ip-addr>
The server name can be any alphanumeric string of up to 32 characters.

Configuring Primary and Backup Servers

By default, the virtual server uses the locally attached real servers as the primary load-balancing servers and
uses the remotely attached servers as backups.
You can enable the virtual server to use the servers designated as backups only as backups, and use the
other servers as the primary load-balancing servers.
To configure primary and backup servers:

1. Edit the configuration of each backup real server to designate the server as a backup. You do not need to
designate the primary servers. The Brocade ADX assumes that all servers you do not designate as backup
serves are primary servers.
2. Enable use of the primary and backup servers in individual VIPs on individual application ports. Only the
VIPs and application ports for which you enable the feature use it. The other application ports within the
VIP, and the other VIPs, use the locally-attached servers as their primary servers and the remotely-attached
servers as their backup servers.
Designating a Real Server as a Backup
By default, the virtual server uses the locally attached real servers as the primary load-balancing servers and
the remotely attached servers as backups. To designate a real server to be a backup server, enter the
following command:
ADX(config-rs-R3)# backup
Syntax: [no] backup
In order for the backup functionality to operate, you must also apply the lb-pri-servers command.
Enabling a VIP to use the Primary and Backup Servers

To enable a VIP to use the servers designated as backups only as backups, and use the other servers as the
load-balancing servers, enter the following command at the configuration level for the VIP:
ADX(config-vs-VIP1)# port http lb-pri-servers
This command enables VIP1 to use the backup and primary servers for application port HTTP. The port
http lb-pri-servers command is needed for the backup functionality to operate, regardless of the real
servers you have, local or remote. For example, even if all your real servers are local and you have one
designated as backup, it will not be used as a backup unless you apply this command.
Enabling HTTP Redirect on a Virtual Server

HTTP redirect is disabled by default on a virtual server. When enabled, HTTP redirect configures the Brocade
ADX to send an HTTP redirect message to the client, so the client redirects its HTTP connection to the real
server’s IP address instead of the VIP. Use HTTP redirect when you configure remote real servers and want
replies from the servers to go directly to clients.
To enable HTTP redirect on a virtual server, enter commands such as the following.:
ADX(config)# server virtual-name-or-ip VIP1 209.157.22.88
ADX(config-vs-VIP1) #port http
ADX(config-vs-VIP1)# bind http r1 80 r2 80 r3 80

ADX(config-vs-VIP1)# httpredirect
Syntax: [no] httpredirect
Tracking the Primary Port

You can configure the Brocade ADX to send all client requests for a specific set of TCP or UDP ports to the
same real server as a “primary” TCP or UDP port grouped with the other ports. You can group a primary TCP or
UDP port with up to four additional TCP or UDP ports. After the Brocade ADX sends a client request for the
primary port to a real server, subsequent requests from the client for ports grouped with the primary port go
to the same real server. Note that if any service port is down for a real server, any track ports on that real
server are not considered for load balancing.
To configure a TCP or UDP application group, enter the following commands:
ADX(config-vs-v1)# port 80 sticky
ADX(config-vs-v1)# track 80 23 69
ADX(config-vs-v1)# bind 80 r1 80 r2 80
These commands configure HTTP (port 80), Telnet (port 23), and TFTP (port 69) to be sticky.
Syntax: [no] track <primary-port> <TCP/UDP-port> [<TCP/UDP-port> [<TCP/UDP-
port> [<TCP/UDP-port>]]]
Configuring a Track Port Group

A track group is similar to track ports. The Brocade ADX sends a client’s request for one of the ports to the
same real server the Brocade ADX selected for the same client’s request for another application port. The
features differ in the following way:
• In a track port configuration, the tracking applies only to the primary port, which is the first port in the list
of track ports. If the client requests one of the other applications (one of the applications that is tracking
the primary application) first, the Brocade ADX track feature does not apply.
• In a track port group, the Brocade ADX sends a client’s requests for any of the applications in the group to
the same real server, regardless of which application the client requests first.
Note that if any service port is down for a real server, any track port groups on that real server are not
considered for load balancing.
The following commands illustrate the track group function.
ADX(config-vs-v1)# track-group 80 69 23

ADX(config-vs-v1)# exit
In this example, the track-group command groups the HTTP port (80), TFTP port (69), and Telnet port (23)
together. Whenever a client attempts to connect to a port within the group, the Brocade ADX ensures all ports
in the group are active before granting the connection. The sticky parameter makes the TCP or UDP ports
sticky. The sticky parameter must be set for all ports in the group. After the Brocade ADX sends a client to a
real server for any of these three ports, subsequent requests from that client for the HTTP, TFTP, or Telnet port
go to the same real server. Up to eight ports can be grouped together using the track group function. A port
can be part of only one group. The track-group and track commands for a port are mutually exclusive.
Alias Ports
Many-to-one TCP or UDP Port Binding

When you associate a VIP with a real server, you make the association for a particular TCP or UDP port. The
association of a TCP or UDP port on a VIP with a TCP or UDP port on a real server is called a "port binding".
Typical configurations use one VIP-to-real-server binding for a TCP or UDP port. For example, if you bind VIP
192.29.2.2 to real server 10.0.0.1 for port 80 (the well-known HTTP port), generally you do not then create
another binding between VIP 192.29.2.2 and real server 10.0.0.1 for the same port. However, if you want to
track statistics for individual applications or domain names mapped to the same port, the Brocade ADX allows
you to configure an alias for the port. You configure a separate alias for each additional VIP.
Binding Same Real Ports to Multiple VIP Ports

This feature provides the ability to bind same real ports to multiple VIP ports. This is useful when you want to
bind more than one VIP to the same application service on real servers, and these real servers are listening
on different ports. To bind multiple ports to one real server port, follow these steps:
1. Create a real server with two ports.
ADX(config)# server real rs1
ADX(config-rs-rs1)# port 81
ADX(config-rs-rs1)# port 8081 <- alias port
2. Create a second real server with two ports.
ADX(config)# server real rs2
ADX(config-rs-rs2)# port 82
ADX(config-rs-rs2)# port 8082 <- alias port
3. Create a virtual server.
ADX(config)# server virtual-name-or-ip vs1
4. Configure an HTTP port on the virtual server.
ADX(config-vs-vs1)# port http
5. Bind the the alias ports to the real servers on the virtual servers.
ADX(config-vs-vs1)# bind http rs1 81 rs2 82

6. Create a second virtual server with an HTTP port.

ADX(config)# server virtual-name-or-ip vs2
ADX(config-vs-vs2)#port http
7. Bind the the alias ports to the real servers on the virtual servers.
ADX(config-vs-vs2)# bind http rs1 8081 real-port 81 rs2 8082 real-port 82
Load-balancing Predictor
The predictor is the parameter that determines how to balance the client load across servers. You can fine-
tune how traffic is distributed across multiple real servers by selecting one of the following load balancing
metrics (predictors):
Least Connections
Sends the request to the real server that currently has the fewest active connections with clients.
For sites where a number of servers have similar performance, the least connections option smoothes
distribution if a server gets bogged down. For sites where the capacity of various servers varies greatly, the
least connections option maintains an equal number of connections among all servers. This results in those
servers capable of processing and terminating connections faster receiving more connections than slower
servers over time. The Least Connections predictor does not depend on the number of connections to
individual ports on a real server but instead depends on the total number of active connections to the server.
The Least Connections predictor can be applied globally for the entire Brocade ADX or locally per-virtual
server.
Round Robin
Directs the service request to the next server, and treats all servers equally regardless of the number of
connections. For example, in a configuration of four servers, the first request is sent to server1, the second
request is sent to server2, the third is sent to server3, and so on. After all servers in the list have received one
request, assignment begins with server1 again. If a server fails, SLB avoids sending connections to that
server and selects the next server instead. The Round Robin predictor can be applied globally to apply for the
entire Brocade ADX or locally per-virtual server.
Weighted Round Robin

Like the Round Robin predictor, the Weighted Round Robin predictor treats all servers equally regardless of
the number of connections or response time. It does however use a configured weight value that determines
the number of times within a sequence that the each server is selected in relationship to the weighted values
of other servers. For example, in a simple configuration with two servers where the first server has a value of
4 and the second server has a value of 2 the sequence of selection would occur as described in the following:
1. The first request is sent to Server1
2. The second request is sent to Server2

3. The third request is sent to Server1

4. The fourth request is sent to Server2
5. The fifth request is sent to Server1
6. The sixth request is sent to Server1

Notice that that over this cycle of server connections, Server1 which has a weight of 4 was accessed four
times and Server2 that has a weight of 2 was accessed only twice. This cycle will repeat as long as this
predictor is in use. The Weighted Round Robin predictor can be applied globally to apply for the entire
Brocade ADX or locally per-virtual server.
Weighted and Enhanced Weighted

Assigns a performance weight to each server. Weighted and Enhanced load balancing are similar to Least
Connections, except servers with a higher weight value receive a larger percentage of connections at a time.
You can assign a weight to each real server, and that weight determines the percentage of the current
connections that are given to each server. For example, in a configuration with five servers of various weights,
the percentage of connections is calculated as follows:
1. Weight server1 = 7
6. Total weight of all servers = 24
The result is that server1 gets 7/24 of the current number of connections, server2 gets 8/24, server3 gets 2/
24 and so on. If a new server, server6, is added with a weight of 10, the new server gets 10/34. If you set the
weight so that your fastest server gets 50 percent of the connections, it will get 50 percent of the connections
at a given time. Because the server is faster than others, it can complete more than 50 percent of the total
connections overall because it services the connections at a higher rate. Thus, the weight is not a fixed ratio
but adjusts to server capacity over time. The difference between weighted and enhanced-weighted, load-
balancing is the method of distributing the traffic once it is assigned.
Connection Assignments for Weighted Load-balancing

In weighted load-balancing, the traffic is distributed by allocating all of the required connections sequentially
to the server with the greatest weight first and then to the server with the next greatest weight, and then to
the server with the next greatest weight on-down-the-line, until all servers have gotten their share of
connections. The process then repeats.
Connection Assignments for Enhanced Weighted Load-balancing

In enhanced weighted load-balancing, the traffic is distributed in the same proportions as with weighted load-
balancing but the order of distribution is different. With enhanced weighted load-balancing, the real server

with the greatest weight is allocated a connection first but then the next connection is allocated to the real
server with the next greatest weight, and then to the server with the next greatest weight on-down-the-line,
until all servers have gotten their first connection. The process repeats with each real server getting a
connection in sequence until each real server has gotten connections equal to its assigned weight.
Dynamic Weighted Predictor

Brocade ADX software provides a dynamic weighted predictor that enables Brocade ADX to make load
balancing decisions using real time server resource usage information, such as CPU utilization and memory
consumption. The Brocade ADX retrieves this information through SNMP protocol from MIBs available on the
application servers. To achieve this capability, a software process in Brocade ADX, named SNMP manager is
used. This process is different from the SNMP agent process (a.k.a. SNMP server process) on the Brocade
ADX. A Brocade ADX can be configured as both SNMP agent (that allows management of Brocade ADX
through Network Management System), and SNMP manager (that facilitates the new SNMP based predictor
method). In addition, all the real servers must run the SNMP agent demon and support MIBs that can be
queried by the SNMP manager of the Brocade ADX. You can fine-tune how traffic is distributed across these
real servers by enabling Dynamic Weighted Predictor on the Brocade ADX. The Dynamic Weighted predictors
can be applied globally to apply for the entire Brocade ADX or locally per-virtual server.
Dynamic-weighted Direct
The SNMP response value from real server is considered as direct performance weight of that server. Direct
weighted load balancing is similar to least connections, except that servers with a higher weight value receive
a larger percentage of connections. You can assign a weight to each real server and that weight determines
the percentage of the current connections that are given to each server.
Dynamic-weighted Reverse
The SNMP response from each server is regarded as reverse performance weight. Dynamic-weighted reverse
load balancing is similar to dynamic-weighted direct, except that the servers with a lower weight value receive
a larger percentage of connections. You can assign a weight to each real server, and that weight determines
the percentage of the current connections that are given to each server.
Changing the Load-balancing Predictor Method

The Load-Balancing Predictor Method can be configured either globally or per-Virtual Server as described in
the following.:
To globally change the load-balancing method used by the Brocade ADX, enter the following command:
ADX(config)# server predictor round-robin
To change the load-balancing method used by the Brocade ADX for Virtual Server “v1”, enter the following
commands:
ADX(config)# server virtual-name-or-ip v1
ADX(config-vs-v1)# server enhanced-weighted

Assigning Weights to the Real Servers

To configure weights for three real servers, enter commands such as the following:
ADX(config)# server real rsA
ADX(config-rs-rsA)# weight 1
ADX(config-rs-rsA)# exit
ADX(config)# server real rsB
ADX(config-rs-rsB)# weight 2
ADX(config-rs-rsB)# exit
ADX(config)# server real rsC
ADX(config-rs-rsC)# weight 3
ADX(config-rs-rsC)# exit
The weight command assigns a performance weight to each server. Servers with a larger or higher weight
assigned receive a larger percentage of connections. When no specific weight is configured for a real server,
the default weight is 1.
Configuring Dynamic Weighted Predictor

To configure dynamic weighted predictor you need to perform 2 steps:
1. Configure real server with SNMP query requirements.
2. Configure a Virtual Server with Dynamic Weighted Predictor.
Configure real server with SNMP query requirements

A list of the SNMP Object ID (OID) can be configured under a real server. An OID represents the weight of the
real server, for example server CPU utilization or its memory usage.
To configure SNMP query requirements use the following command:
ADX(config-rs-rs1)# snmp-request oid 1 1.3.6.1.2.1.25.3.3.1.2.1
Syntax: snmp-request oid <ID> <string>
• <ID>—snmp-request entry identification, decimal value 1 - 256
• <string>—ASCII string ASN.1 format - 1.3.6.1.2.1.25.3.3.1.2.1
SNMP versions 1 and 2 use community strings to restrict SNMP access. The administrator must configure an
SNMP community string to match with those configured in all the real servers.
ADX(config-rs-rs1)#snmp-request community public
Syntax: snmp-request community public <port>
• <port>— snmp-request host UDP port (Default: port 161)
You can configure the frequency of the periodic SNMP queries using the following command:
ADX(config)# server snmp-poll 5
Syntax: server snmp-poll <num>
• <num>—Decimal value in seconds (Default: 3 sec)
Configuration example:
ADX(config)#server snmp-poll 5
ADX(config)#server real rs1 10.1.1.1

ADX(config-rs-rsl)#snmp-request community public port 161

ADX(config-rs-rsl)#snmp-request oid 1 1.3.6.1.2.1.25.3.3.1.2.1
ADX(config-r-rsl)#snmp-request oid 2 1.3.6.1.2.1.1.3.0
ADX(config-r-rsl)#port http
ADX(config-r-rsl)#port http keepalive
ADX(config-r-rsl)#port http url "HEAD /"
Configure a Virtual Server with Dynamic Weighted Predictor

Select a dynamic-weighted direct or reverse predictor and an SNMP OID.
Dynamic-weighted direct
To configure a dynamic-weighted reverse predictor, use the following comand:
ADX(config-vs-vs1)# predictor dynamic-weighted direct oid 1
Syntax: predictor dynamic-weighted {direct oid <ID> }
Configuration example:
ADX(config)#server virtual-name-or-ip vs1 10.1.1.151
ADX(config-vs-vs1)#predictor dynamic-weighted direct oid 1
ADX(config-vs-vs1)#port http
ADX(config-vs-vs1)#bind http rs1 http rs2 http rs3 http
Dynamic-weighted reverse
To configure a dynamic-weighted reverse predictor, use the following comand:
ADX(config-vs-vs1)# predictor dynamic-weighted reverse oid 1 max 50
Slow Start of the Backup and the Primary Servers

If the server selection predictor is Least Connections, the backup server may be overwhelmed by the flood of
the new connections when its primary server goes down. The same is true when the primary server goes back
up and starts to take over the connections from the backup server. The slow start mechanism will be used
whenever the switching of the backup or primary server happens, to give the server the chance to ramp up.
The slow start feature is enabled by default.
Defining the Maximum Number of Sessions

You can limit the maximum number of sessions the Brocade ADX will maintain in its session table for each
barrel processor of a real server. By setting a limit for each barrel processor of a real server, you can avoid a
condition where the capacity threshold of the real server is exceeded. When a barrel processor of a real
server reaches the maximum defined connection threshold, an SNMP trap is sent. When all the barrel
processors of a real server pool reach their maximum connection threshold, additional TCP or UDP packets
are dropped, and an ICMP destination unreachable message is sent. Up to one million total sessions are

supported on the Brocade ADX. This is also the default maximum connection value for real servers. To modify
the maximum connections supported for a specific real server, enter commands such as the following:
ADX(config)# server real Web1
ADX(config-rs-Web1)# max-conn 145000
ADX(config-rs-Web4)# end
ADX# write mem
Layer 4 and Layer 7 Health Checks
Health Checks Overview

The Brocade ADX uses Layer 3, Layer 4, and Layer 7 health checks to verify the availability of real servers and
applications on the real servers. When you configure a real server, the Brocade ADX sends an ARP request for
the real server and then sends an IP ping to the server to verify that the Brocade ADX can reach the server
through the network. The ARP request is sometimes referred to as a Layer 2 health check since the request is
for the real server’s hardware layer address. Later, when you bind the real server to a Virtual IP (VIP) server,
the Brocade ADX sends a Layer 4 or Layer 7 health check to bring up the port you used for the binding. For
example, if you bind a real server to a virtual server using port HTTP, the Brocade ADX sends an HTTP Layer 7
health check to bring up the HTTP port on the real server. The Brocade ADX performs the health checks
described by default. In addition, you can enable periodic Layer 4 or Layer 7 keep alive health checks for
individual application ports. Following successful bring up of an application port when you bind a real server
to a virtual server, the Brocade ADX repeats the Layer 4 or Layer 7 keep alive health check to continually
verify the health of the port.
Layer 4 Health Check

When you bind a real server to a virtual server, the Brocade ADX performs either a Layer 4 TCP or UDP health
check or a Layer 7 health check to bring up the application port that binds the real and virtual servers. If the
application port is not one of the applications that is known to the Brocade ADX, the Brocade ADX uses a
Layer 4 health check. Otherwise, the Brocade ADX uses the Layer 7 health check for the known application
type. The Layer 4 health check can be a TCP check or a UDP check:
• TCP health check – The Brocade ADX checks the TCP port’s health based on a TCP three-way handshake:
- The Brocade ADX sends a TCP SYN packet to the port on the real server.
- The Brocade ADX expects the real server to respond with a SYN ACK.
- If the Brocade ADX receives the SYN ACK, the Brocade ADX sends a TCP RESET, satisfied that the
TCP port is alive.
• UDP health check – The Brocade ADX sends a UDP packet with garbage (meaningless) data to the UDP
port:
- If the server responds with an ICMP “Port Unreachable” message, the Brocade ADX concludes that
the port is not alive.
- If the server does not respond at all, the Brocade ADX assumes that the port is alive and received
the garbage data.

Since UDP is a connectionless protocol, the Brocade ADX and other clients do not expect replies to data sent
to a UDP port. Thus, lack of a response indicates a healthy port.
Configuring a Port Profile

Port profiles enable you to globally configure the attributes for individual TCP/UDP ports. A scripted health
check will not work on a TCP port that does not have a profile, since the Brocade ADX assumes any port
without a profile is a UDP port, and will perform UDP health checking on the port.
To use a scripted health check on a TCP port, you must create a port profile and explicitly identify the port as
a TCP port. The following commands configure a port profile for port 12345 and specify that the port is a TCP
port. The no-fast-bringup command is necessary because it prevents the Brocade ADX from marking a
port ACTIVE until it passes both Layer 4 and Layer 7 health checks.
ADX(config)# server port 12345
ADX(config-port-12345)# tcp
ADX(config-port-12345)# no-fast-bringup
FIN Close for Server Health Check

To enable FIN close, use the following command: ADX(config)# server keepalive-fin
Configuring HTTP Content Matching Lists

Brocade ADX supports compound and simple content-matching statements under the match-list
configuration. This enhancement adds support for "start" and "end" statements in the match-list
configuration.
ADX(config)# http match-list m1
ADX(config-real-server-r1) down start "404"
ADX(config-real-server-r1) default up
ADX(config-real-server-r1) up end "found"
ADX(config-real-server-r1) default down
The first match list m1 would cause Brocade ADX to mark the port failed if the text "404" is found at the
beginning of the reply from the server. If the text is not found, the Brocade ADX would mark the port UP, as the
default configuration is UP.
In the second example above, for match-list m2, Brocade ADX would mark the port UP, if the text "found' is
present at the end of the reply from the server.
An HTTP content verification health check is a type of Layer 7 health check in which the Brocade
ADX examines text in an HTML file sent by a real server in response to an HTTP keepalive request.
The Brocade ADX searches the text in the HTML file for user-specified selection criteria and determines
whether the HTTP port on the real server is alive based on what it finds.
The selection criteria used in HTTP content verification is contained in a matching list that is bound to one or
more real servers. To configure a matching list, enter commands such as the following:
ADX(config)#http match-list m1
ADX(config-http-ml-m1)#down simple "404"
ADX(config-http-ml-m1)#down simple "File Not Found"

ADX(config-http-ml-m1)#exit
The first command sets the name of the matching list and enters the HTTP matching list CLI level.
The first down statement looks for the text “404” in the HTML file sent from the real server in response to an
HTTP keepalive request; the second down statement looks for the text “File Not Found.” If either of these text
strings are found in the HTML file, the Brocade ADX marks port 80 (HTTP) on the real server FAILED. If neither
of the text strings are found, the Brocade ADX marks the port ACTIVE.
The down simple and up simple statements specify the selection criteria in the matching list. The following is
an example of a matching list that uses compound selection criteria, in which the beginning and ending parts
of selection criteria are specified:
ADX(config-http-ml-m4)# up compound "monkey see" "monkey do" log
ADX(config-http-ml-m4)# down compound "500" "Internal Server Error" log
ADX(config-http-ml-m4)# down compound "503" "Service Unavailable" log
ADX(config-http-ml-m4)# default down
ADX(config-http-ml-m4)# exit
In this example, the default down command causes port 80 on the real server to be marked FAILED if
none of the selection criteria are found in the HTTP response message.

3 - Additional Server Load Balancing Features
Source-NAT
Figure 11: Brocade ADX in a Multi-netted Network Without Source-NAT

1. The Brocade ADX sends the packet to the real server with the real server’s address as the destination and
the client’s address as the source.
2. The real server switches the addresses so the real server’s address is the source and the client’s address
is the destination.
3. Since the client is not on the real server’s network, the real server must send the packet to its default
gateway.
4. If the client receives the packet, the source is the real servers address, not the VIP and the client will ignore
the packet since it did not send a request to the real server but to the VIP.
5. Since there is not a return packet to the Brocade ADX, the session in the Brocade ADX’s session table
remains open.
The solution: use Source-NAT

Figure 12: Brocade ADX in a Multi-netted Network With Source-NAT

Since the packets from the real servers are returning through the Brocade ADX, the real servers do not need
to be configured with a gateway.
1. Brocade ADX receives the request from the client and replaces the destination address with the real
server’s address and the source address with the server source-ip that is on the same subnet as the real
server’s IP address.
2. The real server reverses the source and destination IP, since the destination IP is on the same subnet as
the real server’s IP, there is no need to ARP for the gateway.
3. The Brocade ADX receives the packet from the real server and replaces the destination with the client’s IP
address and replaces the source with the IP address of the VIP.
This is a portion of the config file associated with the Figure 12 diagram above:
server source-ip 10.10.10.50 255.255.255.0 10.1.1.1
!
server real rs1 10.10.10.201
source-nat
port http
port http url “HEAD /”
!
server real rs2 10.10.10.202
source-nat
port http
port http url “HEAD /”
!
server virtual vip 169.144.10.100
port http
bind http rs1 http rs2 http

bind http rs4 http

You can use it globally or locally under real servers, but do not use both of them together i.e. once you have
defined it globally do not define it locally.
• Implemented globally - affects all real servers
• Implemented locally - affects individual real servers
• Must use server source-ip with source-NAT
You can define a total of 64 source-ip and source-nat-ip addresses on a Brocade ADX running switch code.
The source-ip command is not required on Brocade ADX’s running router code.
Direct Server Return (DSR)

Traffic Flow:
a. Small requests are sent from client to the Server Farm (typically 64-128 byte)
b. The small requests can result in large frames being sent directly back to the client
- Large GIF/JPEG images

- Large File transfers
Maximize the throughput back to the users
Figure 13: DSR Overview

Direct Server Return configures the Brocade ADX to instruct real servers to send client responses directly to
the clients instead of sending the responses back through the Brocade ADX. As a result, the clients receive
faster response time and the Brocade ADX is free to support even more sessions to serve more clients (a
connection is two sessions, one in each direction). You configure DSR on an individual TCP/UDP port basis on
the Brocade ADX by entering or selecting the DSR parameter when you configure your virtual servers. In
addition, the feature requires that you configure a loopback interface on each real server and give the
loopback interface the IP address of the VIP. The Brocade ADX sends the client traffic to the real server
without translating the destination address from the VIP into the real server’s IP address. Thus, the real server
receives the client traffic addressed to its loopback address and responds directly to the client. The DSR
feature applies to individual TCP/UDP ports. To configure the SI for DSR, you enable the feature for individual
TCP/UDP ports when configuring the virtual server. For example, when you enable TCP port 80 (HTTP) on a
virtual server, you can add the dsr parameter to enable DSR for that port. Traffic for other ports still returns
through the SI. The SI does not translate the destination IP address in client requests for the port with DSR

enabled. However, the SI does still translate the destination IP address in the client’s request to the real
server’s IP address for other ports.
ADX(config-vs-v1)# port 80 dsr
Health Checks with DSR

Normally, the Brocade ADX can perform health checks on an application port only when server replies from
that port pass back through the Brocade ADX. If the Brocade ADX does not see the real server’s responses to
client requests, the Brocade ADX concludes that the application or the entire server is down and stops
sending client requests to that server. When you enable an application port for DSR, the Brocade ADX can still
perform heath checks on the application by sending the health checks to the loopback address you configure
on the real server.
ADX(config-vs-v1)# port 80 dsr
You can use Layer 4 and Layer 7 health checks in your DSR configuration.
• The Brocade ADX addresses Layer 3 (IP ping) health checks to the real server IP address, and addresses
Layer 4 health checks to the real server IP address and the TCP or UDP protocol on the server.
• The Brocade ADX addresses Layer 7 health checks to the real server MAC address and to the loopback
address that matches the VIP address.
GSLB
DNS servers perform the translation between fully qualified domain names and IP addresses. DNS supports a
number of record types such as IPv4 Address records (A records), IPv6 Address records (AAAA records), Name
Server records (NS records), Mail Exchange (MX records), and Canonical Name records (CNAME records).
DNS Hierarchical Structure
Just like a file system, the structure of the DNS database is hierarchical. At the top of system is the root. Each
node in this tree must have a label. The label can be 63 characters long and the zero-length label is reserved
for the root. On the next level are the top-level domains (TLDs). This is where the .com, .net, .org, and other Top
Level Domains reside. Nodes within the tree are also known as domains. Domains are simply subtrees of the
domain name space. This is important for domain names are indexes into the DNS database. Therefore,
under the TLDs are individual domains such as brocade.com. The keepers of the TLDs do not administer the
domains under them. This is known as delegation. The name system under the TLDs are administered by the
individuals assigned to them. This can be a private enterprise company or it can be an ISP using their name
servers to as a service to a company.
GSLB Operations
• Modes - [non] transparent, cache
• Proxy DNS (Authoritative address is a VIP[s])
- GSLB ADX does contain a DNS server

- Provides caching and the ability to respond to A records

• Two components in a GSLB configuration:
- GSLB Brocade ADX “Front-ends” an authoritative DNS server(s)
- Remote sites can include a Brocade ADX and a real server
• Geographically separated authoritative DNSs can be front-ended by two GSLBs or by one GSLB with
Source-NAT.
• GSLB protocol is used to communicate between a GSLB ADX and a remote ADX. (TCP port 182)
Site Selection Criteria, default evaluation order:
1. Server Health
2. Brocade ADX session capacity threshold
3. Round Trip Time between the remote Brocade ADX and the DNS client
4. The geographic location of the server

5. Brocade ADX available session capacity
6. FlashBack speed
7. Least Response selection/round-robin
Removing All Addresses Except the Best Address

By default, the GSLB Brocade ADX retains the same number of IP addresses in the DNS replies from the DNS
server. The GSLB policy swaps the IP address on the top of the list with the “best” address, selected by the
GSLB policy. You can configure the Brocade ADX to remove all addresses except the one the GSLB policy
selects as the best address. To configure the GSLB Brocade ADX to remove all addresses except the best
address from the DNS replies, enter the following commands:
ADX(config)# gslb policy
ADX(config-gslb-policy)# dns best-only
Content Switching (CSW)
Session Persistence, the ability to persist all the sessions for a given user to the same server for the duration
of an application transaction.
• Identify the user
• Recognize when an application transaction begins or ends
Types of Session Persistence:
• Source IP, Virtual IP, Port
• Port Tracking
• Concurrent
• Sticky
• Cookie Based Persistence
- Switching
- Hashing

Source IP, Virutal IP, Port

The Brocade ADX sends all the connections for a given combination of source IP, VIP and port number (such
as port 80 for HTTP) to the same server. But, if the same source IP connects to a different VIP or application
port, it will be load balanced to any available server.
Port Tracking
Often, e-commerce applications have SSL traffic following HTTP traffic. The Brocade ADX sends all
connections to the follower port (for example, SSL) to the same real server to which the connections to the
lead port (for example, HTTP) were sent.
Cookie Based Persistence (Switching/Hashing)

There are two ways to do cookie-based persistence: cookie based switching and cookie hashing.
1. Cookie Based Switching - The first time a client accesses a web site, the Brocade ADX load balances the
connection request to one of the web servers. The web server inserts a configurable cookie name and sets
the cookie value to its server ID as defined in the Brocade ADX configuration. The client's browser stores
the cookie on the client's computer and sends the cookie as part of any subsequent HTTP GET request.
The Brocade ADX scans the cookie string in the HTTP get request to find the cookie name "Server",
retrieves its value, and sends the request to the appropriate web server.
2. Cookie Based Hashing - When configured to do cookie based hashing, the Brocade ADX performs a
checksum-like operation on the entire cookie string to create a hash value and assigns a real server to that
hash value. All subsequent HTTP GET requests with cookies that resolve to the same hash value will be
sent to the same real server.
Cookie Insertion
Cookie insertion allows the Brocade ADX to insert a cookie into an HTTP response sent from a server to a
client. When cookie insertion is enabled, the real servers do not need to send or be aware of a cookie related
to cookie switching. In addition to inserting a cookie, the Brocade ADX can also delete the inserted cookie or
“damage” it by rearranging the NAME part of the cookie.
The Brocade ADX will insert a cookie when:
• There is no cookie header
• The cookie header exists but it does not contain the cookie name specified by the port http cookie-name
command
• The cookie name is found, but the cookie value is out of range. The cookie value must be between 1 –
2047
• The cookie name is found, but the real server or server group indicated by the cookie value is not available
SSL ID Based Persistence

To establish an SSL session, a client and a server first exchange certain parameters for encryption and
decryption. The server sends an SSL ID as part of the negotiation. The load balancer stores the SSL session ID

and its association with a real server to ensure that all subsequent traffic with that SSL ID will always be
directed to the same real server.
URL Switching
The Brocade ADX can direct HTTP requests to a server or group of servers, using information in the test of a
URL string. The Brocade ADX examines the contents of a URL string and makes a decision about where to
send the packet based on selection criteria in user-defined policies. If text in the URL string matches the
selection criteria, the HTTP request is sent to a load-balanced server group specified in the policy.
“URL string” is defined as the contents of the Request-URI part of the Request-line in an HTTP request
message. This information usually consists of the absolute pathname (directory and filename) of a resource.
For example: /doc/Brocade ADX /1199/url_switching.html
The network location of the resource is specified in the Host header field in an HTTP request message. For
example: Host: www.brocade.com
The Brocade ADX can examine both the URL string and Host header field when determining where to send the
HTTP request.
Layer 7 CSW: 3-Step Configuration

Content Switching requires a 3 step configuration process in order to define the content switching rules and
policies.
Step 1: Define a CSW Rule
Specifies content to match in HTTP traffic
• Header
Example: (config)# csw-rule rule4 header host exists
(also: header prefix/suffix/pattern/equals/search)
• URL
Example: (config)# csw-rule rule3 url exists
(also: url prefix/suffix/pattern/equals/search)
• Method
Example: (config)# csw-rule rule1 method eq PUT
(also: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS, or CONNECT)
• Version
Example: (config)# csw-rule rule2 version eq 1.1
Step 2: Create a policy

Specifies action to take when rule is matched
• Create a policy
(config)# csw-policy p1
(config-csw-p1)#
• Match rule/take action in one statement
a. Forward

(config-csw-p1)# match rule1 forward 1029

b. Redirect
(config-csw-p1)# match rule1 redirect "*" "*" ssl
c. Rewrite
(config-csw-p1)# match rule1 rewrite request-insert client-ip
Step 3: Bind policy and Enable CSW

Bind policy & turn on csw to a particular VIP
(config)# server virtual cswVIP 192.168.10.100
(config-vs-cswVIP)# port http
(config-vs-cswVIP)# port http csw-policy p1
(config-vs-cswVIP)# port http csw
(config-vs-cswVIP)# bind http rs1 http (*)
(*) must bind at least 1 real server to http and it must be Active
Inserting an IP Address in a Header

HTTP Header insertion can be used to direct the Brocade ADX to insert the Client IP address into the HTTP
requests it receives on a virtual server that match a CSW rule that you define. This can be useful in situations
where Source Network Address Translation (source NAT) is enabled on a Brocade ADX. With Source NAT
enabled, original source IP addresses are translated into one common IP address. As a result, servers are
unable to identify clients by their original source IP addresses. In some cases, the real source IP addresses of
the clients may be necessary; for example, for server applications to report statistics, or for web
administrators who may need to know the real source IP addresses of the clients in order to secure the
system. You can use the HTTP header insertion feature to insert the original source IP address into the HTTP
request. This way, servers are able to identify clients by their original source IP addresses. To cause the
Brocade ADX to insert the IP address of the connecting client into HTTP requests matching rule r1, enter the
following command.
ADX(config-csw-policy1)# match r1 rewrite request-insert client-ip "MyClientIP"
Stateless SLB
Stateless SLB does not use session table entries for the TCP and UDP sessions between the Brocade ADX and
clients or real servers. These configuration options are useful if you want to deploy multiple Brocade ADXs to
provide service for the same VIPs or applications but the network topology cannot ensure that server
responses will pass back through the Brocade ADX. To configure an application port to be stateless, enable
the stateless parameter on the port in the virtual server. Here is an example:
ADX(config)#server real R1 10.10.10.1
ADX(config-rs-R1)#port http
ADX(config-rs-R1)#exit
ADX(config)#server real R2 10.10.11.1

ADX(config-rs-R2)#port http
ADX(config-rs-R2)#exit
ADX(config)#server virtual-name-or-ip StatelessHTTP 192.168.4.69
ADX(config-vs-StatelessHTTP)#port http stateless
ADX(config-vs-StatelessHTTP)#bind http R1 http
ADX(config-vs-StatelessHTTP)#bind http R2 http
The Brocade ADX does not use the standard SLB load-balancing methods when selecting a real server for a
stateless application port. Instead, the Brocade ADX uses hash values to select a real server. The Brocade
ADX calculates the hash value for a given client request based on the request’s source IP address and source
TCP/UDP port.
Security Features
Figure 14: SYN-Defense
The SYN-defense feature allows the Brocade ADX to complete the TCP three-way handshake on behalf of a
connecting client. When a connecting client sends a TCP SYN to a server, the Brocade ADX forwards the SYN
to the real server, then forwards the SYN ACK from the server to the client. Next, the Brocade ADX sends an
ACK to the real server, completing the three-way handshake on behalf of the connecting client. This action
allows the real server to move the connection from its pending connection queue to its established (and much
larger) connection queue.

Figure 15: SYN-Proxy

SYN-Proxy shields the server completely from any TCP connection requests until the connection is
successfully completed with the three-way handshake. The Brocade ADX forwards the connection context to
the server after the connection is fully established. Partially established connections are never seen by the
servers and are timed-out by the Brocade ADX. Configure the ip tcp syn-proxy command as shown in the
following:
1. Configure syn-proxy in the global mode.
ADX(config)# ip tcp syn-proxy
2. Enable syn-proxy on each interface handling inbound SYN requests.
ADX(config)#interface e 3/1
ADX(config-if-3/1)# ip tcp syn-proxy in

4 - ADX Administration GUI

GUI Access Steps
1. Connect to the Brocade ADX console connector using the serial cable
2. Assign an IP address
If you are using a switch code:
ADX 1000>enable
No password has been assigned yet...
ADX 1000#config terminal
ADX 1000(config)#ip address 169.144.10.11/24
ADX 1000(config)#ip default-gateway 169.144.10.1
3. Connect your PC to any regular Ethernet port not the management port on the Brocade ADX using an
Ethernet cable. Use ping to verify IP connectivity.
4. Open a browser (IE or Firefox) and type in the IP address of the Brocade ADX into the address bar. The GUI
login window will open. Click the HTTP button. The Brocade ADX also supports secure socket layer (SSL) for
enabling HTTPS access.
Figure 16: Brocade ADX GUI

5. Enter the User Name/Password (default admin/brocade) and click OK.

Figure 17: GUI Authentication
Figure 18: Brocade ADX Web Interface Home Page
Define Global System Settings

1. Click the System button.
2. Click the Global Settings link.

Figure 19: Brocade ADX GUI Global Settings

3. You can change one or more of the following parameters:
• Load Balancing Predictor: Select the predictor to be used by the Brocade ADX from the drop down list.
• TCP Age: Enter the number of minutes for TCP Age.
• UDP Age: Enter the number of minutes for UDP Age.
• Sticky Age: Enter the number of minutes for Sticky Age.
• Clock Scale: Enter a value from 1 to 24 for Clock Scale.
• Max Sessions Per BP: Enter the maximum number of sessions allowed for each BP. (Note: If you change
this setting, you must reload the Brocade ADX from the CLI.)
• Source NAT: Place a check mark in this box to globally enable source NAT on the system.
4. Click Apply to accept your changes.
Creating a Real Server and Enabling Ports

1. Click the Traffic Management button.
2. Click the Real Server link.
• The content area for configuring the Real Server is displayed on the right side of the window.
• The Summary tab displays a list of the existing real servers in the system.
3. Click the Basic tab at the top of the window. The “Basic Real Server” window is displayed.
4. Click the New button, if New is not already displayed.

5. Enter the following information:
• Real Server Name: For example, RS1 (Real Server #1); Server IP: For example, 10.10.10.201
6. Click Enable for Admin Status. Enable is the default option.
7. Click Apply. The message “The operation was successful” is displayed.

Figure 20: Traffic Management
To configure a real server port, follow these steps:

1. Click the Port tab
2. In the Applications panel, select HTTP and click Add to enter a new application type.
3. In the Characteristics panel, click on Enable for Admin Status (Enable is the default option).
4. Optionally configure other port level parameters.
5. Click Update. The message “the operation was successful” is displayed.
Figure 21: Port Tab

Creating a Virtual Server/Port and Enabling Binding

1. Click the Traffic Management button.
2. Click the Virtual Server link. The content area for configuring the Virtual Server is displayed on the right
side of the window.
3. Click the Basic tab at the top of the window.
4. Click the New button, if New is not already displayed. Enter the following information:
• Virtual Server Name: For example, vip1

• Server IP: For example, 169.144.10.100
5. Click Enable for Admin Status (Enable is the default option).
6. Select a Predictor: Least Connection, Round Robin, Weighted, Enhanced Weighted, Weighted Round Robin,
and Dynamic Weighted (Optionally modify).
7. Click Apply. The message “The operation was successful” is displayed.
Figure 22: Virtual Server/Port and Enabling Binding
To configure a Virtual Server Port, follow these steps:

1. Click the Port tab. The Virtual Server Port window is displayed.
2. In the Applications panel, select port and click “Add” to enter a new application type.
3. In the Characteristics panel, select Enable for Admin Status. (Enabled is the default option.)
4. Optionally specify other port level items.

5. Click Update. The message “The operation was successful” is displayed.

Figure 23: Configuring a Virtual Server Port

To bind a virtual server port to a real port, follow these steps:
1. Click the Bind tab. The Virtual Server Bind window is displayed.
2. Enter the following information:
• Select the virtual server name from the Virtual Server drop down list.
• Select the virtual server port name from the Port drop down list.
• Select the real server name from the Real Server drop down list.
• Select the real server port name from the Port drop down list.
3. Click the Bind button.
Figure 24: Virtual Server Binding

Configuring a Health Check for a Real Server

To configure health check for a individual real server, follow these steps:
1. Click on Traffic Management > Health Checks > Summary. The Summary tab displays links to configure
global health check settings and individual real server health checks.
Figure 25: Configuring a Health Check for a Real Server

2. Follow links available under Step 1 (Optional): Define global health check settings to create or modify
system level health check containers such as port profiles, port policies, element health checks and match
lists, or modify global health checks settings.
3. Under Step 2: Configure Health Check panel, select the real server name from the Select Real Server drop
down list.
4. Select the port name from the Select Real Port drop down list.
5. Click the Open Port Health Check configuration page link. A new dialog window will be opened for
displaying port configurations under selected real server.

Figure 26: Health Check Panel

6. Under the Health Check panel, enter the following information:
• Click the Enable check box to enable periodic Health Check for the real server.
• Click the L4 Check Only check box to enable Layer 4 check.
• Enter the Bringup Health Check Interval range in the L4 and L7 fields, then click Update.
7. Close the dialog box and click Finish on the parent window.

To globally enable Layer 2, Layer 3, and Layer 4 health checks, follow these steps:
Click Traffic Management > Health Checks > Generic. The Generic Health Check window is displayed.
Figure 27: Generic Helath Check Window

1. Click Enable for Periodic ARP to enable Layer 2 ARP Check. Enable is the default option.
2. Click Enable for Real Server and Remote Server to enable Layer 3 PING Check. Enable is the default
option.
3. Click Enable for Layer 4 Health Check and Fast Port Bring-up to enable Layer 4 TCP/UDP Check. Enable is
the default option.
4. Click Apply.

5 - Optimization and High Availability
Hot Standby SLB

One Brocade ADX is always active while the other Brocade ADX is always standby. On chassis systems, hot
standby is supported only in Switch (S) code, not Router (R) code.
Figure 28: Active-Standby Configuration

When Brocade ADX A comes up in a Hot Standby configuration, it comes up in Standby state. When it sends
Hello messages and sees that no other Brocade ADX is responding to those Hello messages, Brocade ADX A
assumes the active state. When Brocade ADX-B comes up, it also goes through Hello-message processing.
When Brocade ADX B sends Hello messages, Brocade ADX A responds to Brocade ADX B with Brocade ADX
A's Active Status. Brocade ADX B assumes Standby status. Brocade ADX A in Active State performs the
following 4 stages of synchronization:
• Port map synchronization
• MAC table synchronization
• Server information synchronization
• Session synchronization
Follow these steps to enable the minimum required configuration shown above. Client connections and
server connections must be on the same interfaces on both Brocade ADXs.
1. On Brocade ADX A, place the untagged hot standby port (sync-link) in its own port-specific VLAN and
disable STP:
ADX-A(config)# vlan 2 by port
ADX-A(config-vlan-2)# untagged ethe 2/1
ADX-A(config-vlan-2)# no spanning-tree

Placing the hot standby port in its own VLAN prevents unnecessary traffic from going over the directly
connected backup link. With Hot Standby, you cannot have spanning-tree configured anywhere on any
link connected between the two Brocade ADXs. By default, spanning tree is usually enabled on
switches but disabled on routers.
2. To avoid system conflicts, globally disable spanning-tree on VLAN 1:
ADX-A(config)# vlan 1 name DEFAULT-VLAN by port
ADX-A(config-vlan-1)# no spanning-tree
3. Configure the server backup port, shared chassis-MAC address between the Brocade ADXs, and any
connected router-ports:
!
server backup ethe 2/1 00e0.5201.0c72 vlan-id 2
server router-ports ethernet 2/3
server router-ports ethernet 2/4
!
The server backup ethernet command must be configured exactly the same on both Brocade ADXs.
The server router-ports command enables the Brocade ADX to count the number of upstream (or
downstream) router ports connected to the switch. Both Brocade ADXs must use the same router-
ports numbers, such as 2/3 in this example. The reason is the standby Brocade ADX is a dummy
device that learns nothing, such as MACs, on its own.
4. Save the configuration and reload the software after configuring or changing the server backup port
number. If you change the port number of the backup while the Brocade ADX is load balancing, clients will
not be able to ping the VIP.
ADX-SLB-A #wr mem
ADX-SLB-A# reload
5. Configure the second Brocade ADX (Brocade ADX-B). On this system, port 2/1 is the hot standby port.
Using the same port numbers and MAC address is a requirement. Notice the chassis-MAC address on each
Brocade ADX matches:
ADX-B# server backup ethe 2/1 00e0.5201.0c72 vlan-id 2
ADX-B# server router-ports ethernet 2/3
ADX-B# server router-ports ethernet 2/4
ADX-B(config)# vlan 1 name DEFAULT-VLAN by port
ADX-B(config-vlan-1)# no spanning-tree
ADX-B(config-vlan-1)# vlan 2 by port
ADX-B(config-vlan-2)# untagged ethe 2/1
ADX-B(config-vlan-2)# no spanning-tree
ADX-B# write memory
ADX-B# reload
Symmetric SLB
Symmetric SLB (SSLB) is active-standby VIP. Each Brocade ADX is the active Brocade ADX for a specific set of
VIPs, while the other Brocade ADX is the backup for the same set of VIPs. Symmetric SLB is supported in both
Switch (S) code and Router (R) code. In SSLB, you determine which Brocade ADXs are active and backup for a

VIP by associating a sym-priority with the VIP. You assign a different priority to the same VIP on each Brocade
ADX. When all Brocade ADXs and associated links are available, the Brocade ADX with the highest priority for
the VIP services the VIP.
Figure 29: Symmetric SLB
If a Brocade ADX is running software with a router image and the Brocade ADXs are in an Active-Active
configuration, you need to enable VRRP or VRRP-E on these Brocade ADXs; otherwise, FTP, RTSP, and MMS
protocols may not work. Also, configure the IP address of the real server’s default gateway IP address in VRRP-
E configuration and the "owner" IP address in VRRP configuration. In Symmetric SLB and Sym-Active configu-
rations with VRRP-E, when the device switches from the Master router to a Backup router, there is a CLI com-
mand that guarantees simultaneous VIP failover in the event VRRP-E fails over to a Backup router. To enable
this feature, first define a VIP group that includes VIP addresses, then bind the VIP group to a Virtual Router ID
(VRID). To configure Symmetric SLB, configure the sym-priority <value> command on each active and standby
VIP. The higher the <value>, the higher the preference (priority). The range is from 0 – 255. You also can con-
figure the priority to dynamically adjust to changes in the health of applications on the VIP. Enabled by default,
any L2 link can be used for automatic session synchronization between the Brocade ADXs. Unlike Hot
Standby, the Brocade ADXs need not be directly connected. To specify a specific port (optional), use the ses-
sion-sync server subcommand on both devices.

Displaying VIP Owner in HA Setup
The show server bind and show server virtual-name-or-ip <virtual-server>

commands display the "owner" for active VIP in HA configuration.
ADX#show server bind
Bind info
Virtual server: xpanvirtual Status: enabled IP: 22.22.22.17
symmetric VIP state: Owner
http -------> xpanserver: 22.22.22.33, http (Active)
ssl -------> xpanserver: 22.22.22.33, ssl (Active)
ServerIron#show server virtual-name-or-ip xpanvirutal-switch
Virtual Servers Info
Name: xpanvirtual-switch State: Enabled IP:22.22.22.17: 1
Pred: least-conn ACL-Id: 0 TotalConn: 0
Sym: group = 1 state = 5 priority = 100 keep = 0
dyn priority/factor = 100/ 0
Activates = 1, Inactive= 0 sym-active = 0 Sym Priority = Enabled
Symmetric VIP state: Owner
Best-standby-mac: 0000.0000.0000
VIP state: healthy
Sym-Active SLB
Sym-Active SLB is true active-active. Both Brocade ADXs handle traffic (active-active), and both Brocade ADXs
are active for the same VIP on both Brocade ADXs. The difference between Sym-Active and Symmetric SLB is
minimal. For Sym-active, the difference being sym-active configured on the VIP to enable the standby box to
process traffic.
Transaction Rate Limiting (TRL)

TRL provides a way to monitor and limit traffic from any one IP address. When this feature is enabled, the
Brocade ADX counts the number of bytes received from any one IP address over a specified interval. During
this interval, if the number of bytes received from an individual IP address exceeds a specified threshold
value, traffic from that IP address is held down and not processed for a specified number of minutes.
TRL can be used to ensure that traffic from a single IP address does not monopolize resources on the
Brocade ADX. Transaction Rate Limiting can be applied to individual interfaces on the Brocade ADX; only
traffic on the specified interfaces is monitored. Transaction Rate Limiting can be applied to TCP, UDP, and
ICMP traffic. For TCP and UDP traffic, you can apply Transaction Rate Limiting to up to four destination ports.
Transaction rate limit provides the flexibility to specify different configurations for different clients, based on
the client IP address/prefix. TRL provides the following benefits:
• Ability to apply a default transaction rate limit value to all clients, while maintaining an exception list.
• Ability to apply a different transaction rate limit rate per client IP or prefix.
• Ability to exclude specific IP addresses or prefixes from transaction rate limit and maintain an exclude list.

• Ability to apply transaction rate limit to traffic coming to a specific VIP only.
• Ability to operate on a per VIP basis, whereby a different rate limit can be applied to traffic coming to a
different VIP.
Connection Rate Control (CRC)

CRC specifies the maximum number of new TCP, UDP, or individual port connections per second allowed on
the real server. It enables you to limit the connection rate to a real server for the following:
• All TCP traffic
• All UDP traffic
• Individual TCP or UDP ports

6 - Troubleshooting
Display Real Server Information
Show Server Real

This command displays the source IPs for ports that have been allocated for this real server:
ADX# show server real rest
Real Servers Info
========================
State(St) - ACT:active, ENB:enabled, FAL:failed, TST:test, DIS:disabled,
UNK:unknown, UNB:unbind, AWU:await-unbind, AWD:await-delete
Name: rest State: Active Cost: 0 IP:1.1.1.15: 1
Mac: 0002.b34c.50f2 Weight: 0 MaxConn: 2000000
SrcNAT: cfg, op DstNAT: not-cfg, not-op Serv-Rsts: 0
tcp conn rate:udp conn rate = 0:0, max tcp conn rate:max udp conn rate = 1:0
BP max local conn configured No: 0 0 0 0 0 0
Max local conn = 0
BP max conn percentage configured No: 0 0 0 0 0 0
Max conn by weight = 0 Effective max conn = 2000000
Use local conn : No
Port St Ms CurConn TotConn Rx-pkts Tx-pkts Rx-octet Tx-octet Reas
---- -- -- ------- ------- ------- ------- -------- -------- ----
default UNB 0 0 0 0 0 0 0 0
http ACT 0 1 2 47 50 2824 3004 0
Server Total 1 2 47 50 2824 3004 0
Src IP mem alloc per real info:
Index = 0 Global index = 0 Src IP = 1.1.1.79
Server States
The server states only concern is up to Layer 3. They do not deal with Layers 4 or 7. Layer 2 reachability refers
to ARPs, a Layer 2 query for Layer 3 information. Layer 3 reachability refers to ICMP echo requests and
replies, or pings.
• Enabled: There is no link to the real server. The real server is configured on the Brocade ADX but is not
physically connected to the Brocade ADX.
• Failed: The real server has failed to respond to repeated Layer 3 health checks (IP pings).
• Testing: A real server will go to "Testing" if it is reachable at Layer 2 but not at Layer 3. When you first add a
real server, the Brocade ADX will first try to ARP it. While it is ARPing, the server state will read "State:
Enabled". After the real server replies to the ARP, the Brocade ADX will normally send one ICMP echo
request. After it gets the ARP reply and before it gets the ICMP echo reply, the Brocade ADX will show the
real server state as Testing.

• Suspect: The Brocade ADX associates a time stamp with each packet sent to and received from the real
servers. If the time gap between the last packet received from the server and the last packet sent to the
server grows to 3 or 4 seconds, the Brocade ADX sends a ping (Layer 3 Health Check) to the server. If the
server does not respond within the ping interval (a configurable parameter), the Brocade ADX changes the
state to SUSPECT and resends the ping, up to the number of retries specified by the ping retries parameter
(also configurable). If the server still does not respond after all the retries, the state changes to FAILED. If
the server does respond, the state changes to ACTIVE.
• Grace-down: The server gracefully shut down.
• Active: A real server will go to active as long as it is reachable at Layer 2 and 3, regardless of whether or not
its ports are bound to anything, regardless of whether or not its ports pass tests. After receiving that first
ping reply, normally the Brocade ADX switches to periodic ARPs. If you enable server l3-health-
check globally, then the Brocade ADX switches to using periodic pings instead. The real server still shows
the state active. If you enter the no server l3-health-check command globally, then the Brocade
ADX will switch back to ARP. After that first ping succeeds, if you do not have L3 Health Checks enabled,
you can add an ICMP blocking ACL on the real server, and the system will still display "Active". If you re-add
server l3-health-check, then the real server state will change from Active to Suspect and then
Failed. This behavior is all done before any ports have been bound to a virtual server. All these states on a
real server have nothing to do with L4/L7.
Application Port States

• ENABLED: There is no link to the server. (This is the same as the ENABLED server state.)
• FAILED: The application has failed to respond to repeated Layer 4 or (if applicable) Layer 7 Health Checks.
When an application enters the FAILED state, the state of the real server itself moves to the TEST state
while the Brocade ADX continually tries to reach the failed application.
• TEST: The server is still reachable at Layer 3, but the application has failed to respond to its Layer 4 (or if
applicable, Layer 7) Health Check.
• SUSPECT: The Brocade ADX associates a time stamp with each packet sent to and received from the real
servers. If the time gap between the last packet received from the server and the last packet sent to the
server grows to 3 or 4 seconds, the Brocade ADX sends a Layer 4 Health Check to the service. (If
applicable, and if the server passes the Layer 4 Health Check, the Brocade ADX then sends a Layer 7
health check to the application.) If the application does not respond within a specified interval, the
Brocade ADX changes the state to SUSPECT and resends the Layer 4 (and if applicable, Layer 7) Health
Check up to a specific number of retries. If the application still does not respond after all the retries, the
state changes to FAILED and the server state changes to TEST. If the application does respond, the
application state changes to ACTIVE.
• GRACE_DN: The forced-shutdown option has been used to gracefully shut the server down.
• ACTIVE: The application has passed its Layer 4 (and if applicable, Layer 7) Health Check.
• UNBND: The application is configured on the real server but is not yet bound to a virtual server.

Display Virtual Server Information
Displaying Virtual Servers Configuration Statistics

To display configuration information and statistics for the virtual servers configured on the Brocade ADX,
enter the following command:
ADX(config)# show server virtual-name-or-ip
Virtual Servers Info
Server Name: v100 IP : 209.157.23.100 : 4
Status: enabled Predictor: least-conn TotConn: 4233
Dynamic: No HTTP redirect: disabled
Sym: group = 1 state = 5 priority = 2 keep = 0
Activates = 4, Inactive= 3
Port State Sticky Concur CurConn TotConn PeakConn
radius enabled NO NO 0 0 0
http enabled NO NO 0 4233 39
ftp enabled NO NO 0 0 0
telnet enabled NO NO 0 0 0
ssl enabled YES NO 0 0 0
smtp enabled NO NO 0 0 0
nntp enabled NO NO 0 0 0
ntp enabled NO NO 0 0 0
dns enabled NO NO 0 0 0
pop2 enabled NO NO 0 0 0
pop3 enabled NO NO 0 0 0
tftp enabled NO NO 0 0 0
imap4 enabled NO NO 0 0 0
snmp enabled NO NO 0 0 0
ldap enabled NO NO 0 0 0
default enabled NO NO 0 0 0
...
<Truncated Output>
Server Name: The name of the virtual server.
IP: The IP address of the virtual server.
Status: The status of the virtual server.
Predictor: The load balancing predictor the Brocade ADX uses to balance traffic among the real servers bound
to this virtual server.
TotConn: The number of client connections on the server since the Brocade ADX was last booted or restarted.
Dynamic; A statistic used by Brocade technical support.
HTTP-redirect: The state of the HTTP redirect feature. This feature enables the Brocade ADX to send an HTTP
redirect message to the client if all the real servers are down and the Brocade ADX is therefore sending client
requests to a remote server.

Sym Information for Symmetric SLB. The following information is displayed:

• group – The Symmetric SLB group number.
• state – State 3 means the VIP is inactive. State 5 means the VIP is active.
• priority – The Symmetric SLB priority configured on the Brocade ADX.
• keep – The number of times an SSLB backup has failed to communicate with the active Brocade ADX.
• Activates – The number of times this Brocade ADX has become the active Brocade ADX.
• Inactive – The number of times this Brocade ADX has changed from being the active Brocade ADX.
Displaying Port-Binding Information

To display port-binding information, enter the following command:
http ---------> s43: 209.157.23.43, http
s60: 209.157.23.60, 8080
ftp ----------> s43: 209.157.23.43, ftp
s60: 209.157.23.60, ftp
70 -----------> s43: 209.157.23.43, 70
s60: 209.157.23.60, 70
Virtual Server Name: v105, IP: 209.157.23.105
telnet -------> s60: 209.157.23.60, 300
ftp ----------> s60: 209.157.23.60, 200
http ---------> s60: 209.157.23.60, 100
dns ----------> s60: 209.157.23.60, 400
tftp ---------> s60: 209.157.23.60, 500
The display lists the port bindings for each virtual server configured on the ServerIron ADX. The first row of
information for each virtual server lists the virtual server name and VIP. The following rows list the TCP/UDP
ports configured on the virtual server and the real servers and port names or numbers to which each port is
bound.

Displaying GSLB Information
show gslb site Command

ADX(config)# show gslb site
ServerIronTE: sunnyvale
ServerIron: slb-1 209.157.22.209:
state: CONNECTION ESTABLISHED
Current num. Session CPU load Preference Location
sessions util(%) (%)
500000 50 35 128 N-AM
Virtual IPs:
209.157.22.227(A) 209.157.22.103(A)
ServerIron: slb-2 209.157.22.210:
state: CONNECTION ESTABLISHED
Current num. Session CPU load Preference Location
sessions util(%) (%)
1 0 16 128 N-AM
Virtual IPs:
209.157.22.227(S)
Brocade ADX name and IP address - For each Brocade ADX, the first item of information listed is the name
and management IP address. This is the information you specified when you added the Brocade ADX to the
site.
ServerIronTE - Indicates the site name of the Brocade ADX. This field appears only when you enter the show
gslb site command without specifying a site name.
ServerIron - Indicates the site Brocade ADX name and management IP address.
State - The state of the GSLB protocol connection between the GSLB Brocade ADX and the site Brocade ADX.
It can be one of the following:
• ATTEMPTING CONNECTION – The GSLB Brocade ADX is still trying to establish a GSLB connection with the
site Brocade ADX.
• CONNECTION ESTABLISHED – The GSLB Brocade ADX has established a GSLB connection with the site
Brocade ADX.
• SELF – The GSLB Brocade ADX is also this site Brocade ADX.
Current num. sessions - The number of sessions in the Brocade ADX’s session table. A session is a one-way
connection to or from a real server. This information is reported by the site Brocade ADX. The number of
sessions in the table does not necessarily match the number of active sessions on the real servers. This can
occur if the session table contains sessions that are no longer active but have not yet timed out.
Session util (%) - The percentage of available sessions that are in use. This is the percentage of the total
number of sessions the Brocade ADX can maintain that are in use. For example, if the Brocade ADX can
maintain 1 million sessions (the default session capacity) and the session table contains 500,000 session
entries, the session utilization is 50%. This information is reported by the site Brocade ADX.

CPU load (%) - The percentage of the Brocade ADX’s CPU that is actively engaged in SLB and other activities.
This information is reported by the site Brocade ADX.
Preference - The numeric preference value for this site Brocade ADX. The preference can be used by the GSLB
policy to select a site. This information is configured on the GSLB Brocade ADX.
Location - The geographic location of the Brocade ADX. The location is based on the Brocade ADX’s
management IP address and can be one of the following: Europe, N-AM – North America, S-AM – South
America If you explicitly identified the geographic location, the value you specified appears instead of a value
based on the IP address..
Virtual IPs - The virtual IP addresses (VIPs) configured on the Brocade ADX. This information is reported by the
site Brocade ADX. The letter in parentheses at the end of each address indicates whether the Brocade ADX is
an active or standby Brocade ADX for that address. The letter can be A (active) or S (standby). Unless the
Brocade ADX is configured along with a partner Brocade ADX for Symmetric Server Load Balancing, the value
is always A. If a number appears following the A or S, a host range (the unlimited VIP feature) is configured on
the VIP. The number indicates the number of hosts in the host range.
The GSLB Brocade ADX does not necessarily provide global SLB for all the VIPs configured on the site Brocade
ADXs. The GSLB provides global SLB only for the VIPs that correspond to the DNS zone names you configure
the GSLB Brocade ADX to load balance
Connection Load - The average load at each connection-load sampling interval in the most recent set of
sample intervals.

Taking the Test

After the Introduction Screen, once you click on Next, you will see the non-disclosure agreement:
Figure 30: Sample NDA

Brocade Bcle Nutshell Certification Study Tools PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Brocade Bcle Nutshell Certification Study Tools PDF

Uploaded by

Copyright:

Available Formats

BCLE in a Nutshell

Study Guide for

Revision May 2010

European Headquarters - Geneva, Switzerland

Asia Pacific Headquarters - Singapore

© 2010 Brocade Communications Systems, Inc. All Rights Reserved.

Revision: May 2010

BCLE in a Nutshell 2010

Helen Lautenschlager Joe Cannata

©2010 Brocade Communications i

ii ©2010 Brocade Communications

©2010 Brocade Communications iii

iv ©2010 Brocade Communications

5 - Optimization and High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

©2010 Brocade Communications v

vi ©2010 Brocade Communications

©2010 Brocade Communications vii

viii ©2010 Brocade Communications

Factory Pre-loaded Software:

Upgrading a Boot Image from 12.0.00 to 12.1.00

©2010 Brocade Communications 1

4. Configure the remote default gateway

2 ©2010 Brocade Communications

Downloading a Brocade ADX Image

Downloading a Software Image as Primary

Downloading a Software Image as Secondary

©2010 Brocade Communications 3

Copying a File Between Flash and a USB Drive

Displaying System Information

4 ©2010 Brocade Communications

SL slot-sf2: ServerIron Switch Fabric Mod

©2010 Brocade Communications 5

Figure 1: Brocade ADX 1000 Chassis

Figure 2: Brocade ADX 4000 Chassis

6 ©2010 Brocade Communications

A fully-loaded Brocade ADX 4000 can accommodate the following components:

Figure 3: Brocade ADX 10000 Chassis

©2010 Brocade Communications 7

Brocade ADX 10000 chassis basics:

8 ©2010 Brocade Communications

Figure 4: Brocade ADX 10000 Chassis

©2010 Brocade Communications 9

Brocade ADX 4000 and Brocade ADX 10000 Modules

10 ©2010 Brocade Communications

Figure 5: Brocade ADX Management and SSL Expansion Modules

Setting Up Local User Accounts

©2010 Brocade Communications 11

The privilege <privilege-level> parameter specifies one of the following:

Enabling Telnet Authentication

Enabling Telnet Password

Configuring Authentication-method Lists

12 ©2010 Brocade Communications

Using ACLs to Restrict Remote Access

©2010 Brocade Communications 13

Main Brocade ADX Applications

Basic Server Load Balancing (SLB)

Figure 6: SLB Example

14 ©2010 Brocade Communications

Global Server Load Balancing (GSLB)

Figure 7: GSLB Example

URL-based Server Load Balancing

©2010 Brocade Communications 15

Figure 8: URL-based SLB Example