BCLE 2010 Nutshell

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 Director of Education Solutions
Joe Cannata Certification Manager
2010 Brocade Communications
ii
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
iii
Load-balancing Predictor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Least Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Round Robin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Weighted Round Robin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Weighted and Enhanced Weighted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Connection Assignments for Weighted Load-balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Connection Assignments for Enhanced Weighted Load-balancing . . . . . . . . . . . . . . . . . . . . . Dynamic Weighted Predictor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dynamic-weighted Direct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dynamic-weighted Reverse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing the Load-balancing Predictor Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assigning Weights to the Real Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Dynamic Weighted Predictor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configure a Virtual Server with Dynamic Weighted Predictor . . . . . . . . . . . . . . . . . . . . . . . . . . Slow Start of the Backup and the Primary Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining the Maximum Number of Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Layer 4 and Layer 7 Health Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Health Checks Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Layer 4 Health Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring a Port Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . FIN Close for Server Health Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring HTTP Content Matching Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24 24 24 24 25 25 25 26 26 26 26 26 27 28 28 28 29 29 29 29 30 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
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
vi
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
vii
viii
1 - Installation
Functions
The Brocade ADX is an Application Delivery Controller (ADC). ADCs enhance Internet-based application availability, 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 secondary 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 failure. 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 connection to the management port of the Brocade ADX. The boot code can only be upgraded through the Management 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 Reload the Brocade ADX and interrupt the normal boot cycle by pressing b to enter the monitor mode. ADX# reload Configure the Remote address to reach a TFTP Server from the Brocade ADX. Monitor> remote addr 10.45.10.47 255.255.255.0
2.
3.
4.
Configure the remote default gateway Monitor> remote default-gateway 10.45.10.254 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 Copy the Boot image from the TFTP Server using the following command. Monitor> copy tf fl 10.45.10.1 A1B12100.bin A1B12100.bin Check if the image is copied properly to the internal flash using the dir command. Now boot the Brocade ADX in boot loader mode by issuing the following command. boot system flash A1B12100.bin 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 Brocade ADX will then boot in the boot mode as follows. Monitor> boot sys fl A1B12100.bin ...... MP-Appl# Issue the upgrade all command to upgrade all the BPs and MP boot code. MP-Appl# upgrade all
5.
6.
7. 8.
9.
10.
11.
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
12.
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.
2.
3.
Both management modules must be placed at the Monitor> prompt as described in Step 2 of the previous procedure. 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. Reset the management module where the upgrade all command was executed and then place it at the Monitor> prompt again.
4.
Return to the management module that hasnt 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. 2.
3.
Copy the correct Brocade ADX software image to a TFTP server. 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. 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. 2.
3.
4.
Copy the correct Brocade ADX software image to a TFTP server. 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. Configure the Brocade ADX switch to use secondary as its working image. ADX(config)# boot system flash secondary 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 Serial #: Not-Present Part #: Not-Present Version #: 111d8037-00-111d802d-0d-01b720 ==========================================================================
SL slot-sf2: ServerIron Switch Fabric Mod Serial #: Not-Present Part #: Not-Present Version #: 111d8037-00-111d802d-0d-01b720 ========================================================================== SL slot-asm1: ServerIron 8BP App Switch Mod Serial #: Not-Present 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: 4 RU form factor 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)
Brocade ADX 10000 chassis basics: 8 RU form factor 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 Card slots to accommodate modules A fully-loaded Brocade ADX 10000 can accommodate the following components: 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 10000 chassis basics: 10 RU form factor 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 Card slots to accommodate modules A fully-loaded Brocade ADX 10000 can accommodate the following components: 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.
2. 3.
Ethernet interface modules Support is provided for the 4x10G, 12x1G RJ-45, and 12x1G SFP. Switch Fabric Module (SFM) Allows different boards to talk to each other through the switching fabric. Application Switch Module (ASM) The Application Switch Module is the building block for scaling all ADX products. It consists of the following: 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 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.
a.
4.
Hardware-based SSL The hardware-based SSL offering enables application delivery services including SSL offload, SSL termination, 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.
10
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>
11
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
12
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
13
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
14
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 ADXs 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.
15
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
16
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 servers 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.
17
Configure Virtual Servers
Figure 10: Virtual Servers
After you define the actual application servers 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 clients request from port 80 into 8080 before forwarding the request to a real
18
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.
19
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.
20
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.
2.
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. 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 servers 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
21
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)# server virtual-name-or-ip v1 209.157.22.1 ADX(config-vs-v1)# port 80 sticky ADX(config-vs-v1)# port 23 sticky ADX(config-vs-v1)# port 69 sticky ADX(config-vs-v1)# track 80 23 69 ADX(config-vs-v1)# bind 80 r1 80 r2 80 ADX(config-vs-v1)# bind 23 r1 23 r2 23 ADX(config-vs-v1)# bind 69 r1 69 r2 69 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/UDPport> [<TCP/UDP-port>]]] Configuring a Track Port Group A track group is similar to track ports. The Brocade ADX sends a clients request for one of the ports to the same real server the Brocade ADX selected for the same clients 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 clients 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)# server virtual-name-or-ip v1 209.157.22.1 ADX(config-vs-v1)# port 80 sticky ADX(config-vs-v1)# port 69 sticky ADX(config-vs-v1)# port 23 sticky ADX(config-vs-v1)# track-group 80 69 23
22
ADX(config-vs-v1)# ADX(config-vs-v1)# ADX(config-vs-v1)# ADX(config-vs-v1)#
bind 80 r1 80 r2 80 bind 23 r1 23 r2 23 bind 69 r1 69 r2 69 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
23
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
6.
Load-balancing Predictor
The predictor is the parameter that determines how to balance the client load across servers. You can finetune 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
24
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.
3.
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 2. Weight server2 = 8 3. Weight server3 = 2 4. Weight server4 = 2 5. Weight server5 = 5 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, loadbalancing 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 loadbalancing but the order of distribution is different. With enhanced weighted load-balancing, the real server
25
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
26
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
27
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
28
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 servers 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 ports 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.
29
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)# http match-list m2 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"
30
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 match-list m4 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.
31
3 - Additional Server Load Balancing Features

Source-NAT
Figure 11: Brocade ADX in a Multi-netted Network Without Source-NAT 1.
2.
3.
4.
5.
The Brocade ADX sends the packet to the real server with the real servers address as the destination and the clients address as the source. The real server switches the addresses so the real servers address is the source and the clients address is the destination. Since the client is not on the real servers network, the real server must send the packet to its default gateway. 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. Since there is not a return packet to the Brocade ADX, the session in the Brocade ADXs session table remains open.
The solution: use Source-NAT
32
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 servers address and the source address with the server source-ip that is on the same subnet as the real servers IP address. 2. The real server reverses the source and destination IP, since the destination IP is on the same subnet as the real servers 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 clients 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
33
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 ADXs 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 servers 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
34
enabled. However, the SI does still translate the destination IP address in the clients request to the real servers IP address for other ports. ADX(config)# server virtual-name-or-ip v1 209.157.22.1 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 servers 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)# server virtual-name-or-ip v1 209.157.22.1 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
35
- 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
36
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
37
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
38
(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
39
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 requests 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.
40
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
41
4 - ADX Administration GUI

GUI Access Steps
1. 2.
3.
4.
Connect to the Brocade ADX console connector using the serial cable 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 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. 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.
42
Figure 17: GUI Authentication
Figure 18: Brocade ADX Web Interface Home Page
Define Global System Settings

1. 2.
Click the System button. Click the Global Settings link.
43
Figure 19: Brocade ADX GUI Global Settings 3.

4.
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. Click Apply to accept your changes.
Creating a Real Server and Enabling Ports 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.
1.
44
Figure 20: Traffic Management
To configure a real server port, follow these steps:

1. 2. 3. 4. 5.
Click the Port tab In the Applications panel, select HTTP and click Add to enter a new application type. In the Characteristics panel, click on Enable for Admin Status (Enable is the default option). Optionally configure other port level parameters. Click Update. The message the operation was successful is displayed.
Figure 21: Port Tab
45
Creating a Virtual Server/Port and Enabling Binding 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.
1.
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.
46
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
47
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.
3.
4. 5.
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. Under Step 2: Configure Health Check panel, select the real server name from the Select Real Server drop down list. Select the port name from the Select Real Port drop down list. Click the Open Port Health Check configuration page link. A new dialog window will be opened for displaying port configurations under selected real server.
48
Figure 26: Health Check Panel
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.
6.
49
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. 2.
3.
4.
Click Enable for Periodic ARP to enable Layer 2 ARP Check. Enable is the default option. Click Enable for Real Server and Remote Server to enable Layer 3 PING Check. Enable is the default option. Click Enable for Layer 4 Health Check and Fast Port Bring-up to enable Layer 4 TCP/UDP Check. Enable is the default option. Click Apply.
50
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
51
2.
3.
4.
5.
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. 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 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 routerports 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. 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 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
52
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 servers default gateway IP address in VRRPE configuration and the "owner" IP address in VRRP configuration. In Symmetric SLB and Sym-Active configurations with VRRP-E, when the device switches from the Master router to a Backup router, there is a CLI command 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 configure 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 session-sync server subcommand on both devices.
53
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.
54
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
55
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.
56
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-healthcheck 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.
57
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.
58
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.
59
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 sessions util(%) (%) 500000 50 35 128 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 sessions util(%) (%) 1 0 16 128 Virtual IPs: 209.157.22.227(S)
Location N-AM
Location N-AM
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 ADXs 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.
60
CPU load (%) - The percentage of the Brocade ADXs 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 ADXs 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.
61
Taking the Test

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

BCLE 2010 Nutshell

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

BCLE 2010 Nutshell

Hochgeladen von

Copyright:

Verfügbare Formate

BCLE in a Nutshell Study Guide for Exam 150-320

Exam Preparation Materials

Revision May 2010

BCLE in a Nutshell 2010 Edition

BCLE in a Nutshell 2010

Helen Lautenschlager Director of Education Solutions

Joe Cannata Certification Manager

2010 Brocade Communications

BCLE in a Nutshell 2010 Edition

2010 Brocade Communications

BCLE in a Nutshell 2010 Edition

2010 Brocade Communications

BCLE in a Nutshell 2010 Edition

2010 Brocade Communications

BCLE in a Nutshell 2010 Edition

2010 Brocade Communications

BCLE in a Nutshell 2010 Edition

2010 Brocade Communications

BCLE in a Nutshell 2010 Edition

2010 Brocade Communications

BCLE in a Nutshell 2010 Edition

2010 Brocade Communications

BCLE in a Nutshell 2010 Edition

2010 Brocade Communications

BCLE in a Nutshell 2010 Edition

2010 Brocade Communications

BCLE in a Nutshell 2010 Edition

2010 Brocade Communications

BCLE in a Nutshell 2010 Edition

2010 Brocade Communications

BCLE in a Nutshell 2010 Edition

2010 Brocade Communications

BCLE in a Nutshell 2010 Edition

Figure 1: Brocade ADX 1000 Chassis

Figure 2: Brocade ADX 4000 Chassis

2010 Brocade Communications

BCLE in a Nutshell 2010 Edition

Figure 3: Brocade ADX 10000 Chassis

2010 Brocade Communications

BCLE in a Nutshell 2010 Edition

2010 Brocade Communications

BCLE in a Nutshell 2010 Edition

Figure 4: Brocade ADX 10000 Chassis

2010 Brocade Communications

BCLE in a Nutshell 2010 Edition

2010 Brocade Communications

BCLE in a Nutshell 2010 Edition

Figure 5: Brocade ADX Management and SSL Expansion Modules

2010 Brocade Communications

BCLE in a Nutshell 2010 Edition

2010 Brocade Communications

BCLE in a Nutshell 2010 Edition

2010 Brocade Communications

BCLE in a Nutshell 2010 Edition

Figure 6: SLB Example

2010 Brocade Communications

BCLE in a Nutshell 2010 Edition

Figure 7: GSLB Example

2010 Brocade Communications

BCLE in a Nutshell 2010 Edition

Figure 8: URL-based SLB Example

Figure 9: SLB Design

2010 Brocade Communications