Professional Documents
Culture Documents
BCLE 2010 Nutshell
BCLE 2010 Nutshell
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
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
iv
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:
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.
2.
3.
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
4.
5.
6.
7.
8.
9.
10.
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#
11.
Issue the upgrade all command to upgrade all the BPs and MP boot code.
MP-Appl# upgrade all
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.
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.
When the Brocade ADX reloads, it will boot using the secondary image.
Hardware
2.
3.
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
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
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.
14
15
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
16
17
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.
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
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.
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
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
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
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
27
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
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
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.
32
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
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 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
36
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
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
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
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
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.
42
43
4.
44
45
46
47
3.
4.
5.
48
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.
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.
3.
4.
50
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.
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.
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
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.
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
58
59
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
62