Uploaded by rhoering

brocade virtual ADX

advertisement
53-1003247-01
July 2014
Brocade Virtual ADX
Server Load Balancing Guide
Supporting Brocade Virtual ADX version 03.1.00
®
Copyright © 2014 Brocade Communications Systems, Inc. All Rights Reserved.
ADX, AnyIO, Brocade, Brocade Assurance, the B-wing symbol, DCX, Fabric OS, ICX, MLX, MyBrocade, OpenScript, VCS, VDX, and
Vyatta are registered trademarks, and HyperEdge, The Effortless Network, and The On-Demand Data Center are trademarks of
Brocade Communications Systems, Inc., in the United States and/or in other countries. Other brands, products, or service names
mentioned may be trademarks 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.
The authors and Brocade Communications Systems, Inc. shall have no liability or responsibility to any person or entity with
respect to any loss, cost, liability, or damages arising from the information contained in this book or the computer programs that
accompany it.
The product described by this document may contain “open source” software covered by the GNU General Public License or other
open source license agreements. To find out which open source software is included in Brocade products, view the licensing
terms applicable to the open source software, and obtain a copy of the programming source code, please visit
http://www.brocade.com/support/oscd.
Brocade Communications Systems, Incorporated
Corporate and Latin American Headquarters
Brocade Communications Systems, Inc.
130 Holger Way
San Jose, CA 95134
Tel: 1-408-333-8000
Fax: 1-408-333-8101
E-mail: [email protected]
Asia-Pacific Headquarters
Brocade Communications Systems China HK, Ltd.
No. 1 Guanghua Road
Chao Yang District
Units 2718 and 2818
Beijing 100020, China
Tel: +8610 6588 8888
Fax: +8610 6588 9999
E-mail: [email protected]
European Headquarters
Brocade Communications Switzerland Sàrl
Centre Swissair
Tour B - 4ème étage
29, Route de l'Aéroport
Case Postale 105
CH-1215 Genève 15
Switzerland
Tel: +41 22 799 5640
Fax: +41 22 799 5641
E-mail: [email protected]
Asia-Pacific Headquarters
Brocade Communications Systems Co., Ltd. (Shenzhen WFOE)
Citic Plaza
No. 233 Tian He Road North
Unit 1308 – 13th Floor
Guangzhou, China
Tel: +8620 3891 2000
Fax: +8620 3891 2111
E-mail: [email protected]
Document History
Title
Publication number
Summary of changes
Date
Brocade Virtual ADX Server Load
Balancing Guide
53-1003247-01
New document
July 2014
Contents
Preface
Document conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Text formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Command syntax conventions . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
Notes, cautions, and warnings . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
Brocade resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Contacting Brocade Technical Support . . . . . . . . . . . . . . . . . . . . . . . xv
Document feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi
Chapter 1
Features
Brocade Virtual ADX Supported Features . . . . . . . . . . . . . . . . . . . . . . 1
Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Content Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
OpenScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
SSL offload for optimization of encrypted traffic. . . . . . . . . . . . . 1
Advanced networking with support for static and dynamic routing2
High availability for active and standby deployments . . . . . . . . . 2
Rate Limiting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Support for Brocade Virtual ADX as a GSLB site for increased
availability across datacenters . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Extended hypervisor support for heterogeneous environments. 2
Feature summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Chapter 2
Server Load Balancing
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
How SLB works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Load-balancing predictor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Sticky connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Application port groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Concurrent connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Remote Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Direct Server Return . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Configuring basic SLB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Configuration guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Defining the real servers and real application ports. . . . . . . . . 19
Defining a virtual server (VIP) . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Binding virtual and real servers . . . . . . . . . . . . . . . . . . . . . . . . . 21
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
iii
Changing the Load-Balancing Predictor Method . . . . . . . . . . . . . . . 21
Configuring a weighted predictor . . . . . . . . . . . . . . . . . . . . . . . . 22
Configuring dynamic weighted predictor . . . . . . . . . . . . . . . . . . 24
Configuring the smooth factor . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Real server ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Disabling or re-enabling application ports . . . . . . . . . . . . . . . . . 27
Globally disabling application ports . . . . . . . . . . . . . . . . . . . . . . 28
Disabling SLB to a server when an application goes down . . . 28
Slow-start mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Enabling or disabling the keepalive health check . . . . . . . . . . . 29
Configuring a real port as TCP-only or UDP-only . . . . . . . . . . . . 30
Configuring a stateless port . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Source NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Enabling source NAT globally . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Enabling source NAT on a real server. . . . . . . . . . . . . . . . . . . . . 33
Configuring a shared source IP address for NAT . . . . . . . . . . . . 34
Client subnet based source NAT . . . . . . . . . . . . . . . . . . . . . . . . . 34
Enabling port allocation per real server for source NAT IP . . . . 35
Remote server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Sticky and concurrent connections . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Configuring sticky ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Configuring stickiness based on client’s subnet . . . . . . . . . . . . 37
Setting the sticky age . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Increasing the sticky-age per VIP longer than 60 minutes . . . . 38
Sticky connection return from backup server to primary . . . . . 39
Group sticky: Layer 4 SLB to server group . . . . . . . . . . . . . . . . . 39
Enabling a concurrent port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Application port grouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Tracking primary ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Track port group function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
TCP/UDP application groups configuration example. . . . . . . . . 47
Primary and backup servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Designating a real server as a backup . . . . . . . . . . . . . . . . . . . . 51
Enabling a VIP to use the primary and backup servers. . . . . . . 51
Configuration example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Designating a real server port as a backup . . . . . . . . . . . . . . . . 53
Per server based real server backup . . . . . . . . . . . . . . . . . . . . . 54
Configuring Direct Server Return . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Configuring L2 Direct Server Return. . . . . . . . . . . . . . . . . . . . . . 58
Configuring L3 Direct Server Return. . . . . . . . . . . . . . . . . . . . . . 63
Displaying server information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Port ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Defining a port range. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Using a port range under a real server definition . . . . . . . . . . . 67
Using a port range under a virtual server definition . . . . . . . . . 67
Binding a port range for virtual ports to a real server. . . . . . . . 67
Defining port profile for port range. . . . . . . . . . . . . . . . . . . . . . . 68
Displaying a list of port ranges . . . . . . . . . . . . . . . . . . . . . . . . . . 68
iv
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Multiple port binding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Direct binding of multiple ports . . . . . . . . . . . . . . . . . . . . . . . . . 70
Port aliases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Real server groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Defining a real server group . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Associating a real server with a real server group. . . . . . . . . . . 78
Binding a real server group to a virtual server. . . . . . . . . . . . . . 79
Showing real server groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Disabling or deleting VIPs and real ports . . . . . . . . . . . . . . . . . . . . . 79
Disabling VIPs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Disabling a real server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Disabling or re-enabling an application port . . . . . . . . . . . . . . . 80
Globally disabling real and virtual ports. . . . . . . . . . . . . . . . . . . 80
Deleting a VIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Enabling force-delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Real server shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Port holddown timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Hash-based SLB with server persistence . . . . . . . . . . . . . . . . . . . . . 86
Persistent hash table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Clear vs reassign mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Enabling persistent hashing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Enabling the clear-on-change mechanism . . . . . . . . . . . . . . . . . 87
Enabling the reassign-on-change mechanism. . . . . . . . . . . . . . 88
Configuring the reassign threshold and duration . . . . . . . . . . . 89
Reassignment sequence and example . . . . . . . . . . . . . . . . . . . 89
Keeping the persistent hash table unchanged . . . . . . . . . . . . . 91
Real server failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Displaying persistent hash table entry and statistics . . . . . . . . 93
Clearing the hit count for the persistent hash table . . . . . . . . . 94
Clearing the persistent hash table . . . . . . . . . . . . . . . . . . . . . . . 94
Reassigning a persistent hash table entry. . . . . . . . . . . . . . . . . 94
Displaying hash bucket changes . . . . . . . . . . . . . . . . . . . . . . . . 95
SLB spoofing configuration and support. . . . . . . . . . . . . . . . . . . . . . 95
Policy-based SLB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
v
Miscellaneous options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106
Changing a real server’s IP address . . . . . . . . . . . . . . . . . . . . .106
Adding a description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Configuring a local or remote real server . . . . . . . . . . . . . . . . . 107
Configuring a TCP MSS value at the global level . . . . . . . . . . . 107
Configuring a TCP MSS value for a virtual server . . . . . . . . . . 107
Configuring a TCP MSS value at the virtual server port level .108
Configuring a TCP MSS value at the TCP profile level . . . . . . .108
Support for TCP Window Scale option in TCP header . . . . . . .108
Binding a TCP profile to a virtual port and
response rewrite policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109
Limiting the maximum number of TCP SYN requests . . . . . . .110
Configuring the maximum connection rate for a real server .110
Configuring the maximum connection rate for a virtual server111
Disabling port translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112
Traffic distribution among BPs . . . . . . . . . . . . . . . . . . . . . . . . .112
Including the server client port in hash calculations . . . . . . .113
Sending ICMP Port Unreachable or Destination Unreachable
messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113
Sending a TCP RST to a client that requests unavailable
applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114
Sending a TCP RST when TCP session entry ages out . . . . . .114
Disabling TCP RST message when a real server goes down
during an open session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115
No TCP RST response to non-SYN first packet of a TCP flow .115
Decrement counters in deletion queue . . . . . . . . . . . . . . . . . .115
Optimized fast-path SLB processing. . . . . . . . . . . . . . . . . . . . .116
Configuring TCP fast aging . . . . . . . . . . . . . . . . . . . . . . . . . . . .116
Server opt-enable-route recalculation . . . . . . . . . . . . . . . . . . . 117
Enabling use of the client MAC address. . . . . . . . . . . . . . . . . . 117
Enabling transparent VIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Enabling SYN ACK threshold . . . . . . . . . . . . . . . . . . . . . . . . . . .118
Replacing the source MAC address of the packet. . . . . . . . . .118
Cloning real servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118
Configuring a host range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119
Unbinding all application ports from virtual servers . . . . . . . .119
Identifying VIP port as TCP only or UDP only . . . . . . . . . . . . . .119
Enabling fast aging for UDP sessions . . . . . . . . . . . . . . . . . . . .120
Enabling normal UDP aging for DNS and RADIUS . . . . . . . . . .121
Setting TCP and UDP ages for VIPs. . . . . . . . . . . . . . . . . . . . . .121
Configuring session aging behavior . . . . . . . . . . . . . . . . . . . . .122
Configuring DNS CPU-based throttling . . . . . . . . . . . . . . . . . . .122
Configuring UDP DNS count connection . . . . . . . . . . . . . . . . .123
Dedicated next hop per VIP for reverse SLB traffic . . . . . . . . .123
VIP route health injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124
VIP RHI with dangling subnets . . . . . . . . . . . . . . . . . . . . . . . . .130
VIP RHI and high availability topologies . . . . . . . . . . . . . . . . . .132
Application-specific SLB considerations . . . . . . . . . . . . . . . . . . . . .150
RTSP server load balancing . . . . . . . . . . . . . . . . . . . . . . . . . . .150
Deletion of UDP data session along with TCP control session
for RTSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .150
TFTP load balancing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .150
vi
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Show and debug commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .151
Displaying the BP distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . .151
Chapter 3
Stateless Server Load Balancing
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .153
Stateless TCP and UDP ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .153
How the Brocade Virtual ADX selects a real server
for a stateless port. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .154
Configuring the stateless hash table size . . . . . . . . . . . . . . . .155
Configuring a stateless application port . . . . . . . . . . . . . . . . .155
Fragmentation support in the stateless mode. . . . . . . . . . . . .157
Chapter 4
Health Checks
Health checks overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .159
Layer 3 health checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .159
Disabling Layer 3 health checks . . . . . . . . . . . . . . . . . . . . . . . .160
Modifying the ping interval and ping retries. . . . . . . . . . . . . . .161
Setting the Periodic ARP Interval . . . . . . . . . . . . . . . . . . . . . . .161
Layer 4 health checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161
Performing Layer 4 UDP keepalive health checks
for the DNS port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163
Layer 7 health checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .166
Application ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .167
DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .168
FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .169
HTTP (status code). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .169
HTTP (content verification) . . . . . . . . . . . . . . . . . . . . . . . . . . . .170
Scripted (content verification for unknown ports) . . . . . . . . . .170
IMAP4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
MMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .172
NNTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .173
PNM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .173
POP3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .173
RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
RTSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
SMTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .175
SSL (complete) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .175
SSL (simple) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Port-specific settings for Layer 7 health checks . . . . . . . . . . . 176
Layer 7 health check for an unknown port . . . . . . . . . . . . . . .183
Server and application port states . . . . . . . . . . . . . . . . . . . . . . . . .184
Server states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .184
Application port states. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .185
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
vii
Port profiles and attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .187
Configuring a port profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .188
Configuring port profile attributes . . . . . . . . . . . . . . . . . . . . . .189
Port policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .193
Port policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .193
Configuring a port policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .193
Binding the policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .195
Configuring a keepalive interval under a port policy . . . . . . . .196
Health check policy for VIP port . . . . . . . . . . . . . . . . . . . . . . . .197
Element health checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .198
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .198
Configuring element-action expressions . . . . . . . . . . . . . . . . .198
Attaching a health-check policy to an application port
on a server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .205
Displaying health-check policies and their status . . . . . . . . . .206
Displaying health-check policy statistics . . . . . . . . . . . . . . . . .207
Clearing health-check policy statistics . . . . . . . . . . . . . . . . . . .207
Health check with content match . . . . . . . . . . . . . . . . . . . . . . . . . .208
Content match for HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .208
Content match for non-HTTP ports . . . . . . . . . . . . . . . . . . . . . .211
Binary scripted health check. . . . . . . . . . . . . . . . . . . . . . . . . . .214
Boolean health checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .216
Boolean health-check policies . . . . . . . . . . . . . . . . . . . . . . . . .216
Health-check policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .216
Configuring boolean health check . . . . . . . . . . . . . . . . . . . . . . 217
Miscellaneous health check settings . . . . . . . . . . . . . . . . . . . . . . .219
Basing an alias port’s health on the health of its
master port. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .219
Basing a port’s health on the health of another port . . . . . . .220
Reassign threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .220
Globally disabling all health-check policies . . . . . . . . . . . . . . .222
Health checking for real servers in other subnets. . . . . . . . . .222
Best path to a remote server . . . . . . . . . . . . . . . . . . . . . . . . . .222
Handling traffic initiated from remote server. . . . . . . . . . . . . .223
Health check of multiple websites on the same real server. .224
Minimum healthy real servers under VIP port . . . . . . . . . . . . .225
Server port bring-up enhancement . . . . . . . . . . . . . . . . . . . . .225
Slow-start mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .225
FIN close for server health check . . . . . . . . . . . . . . . . . . . . . . .233
Health-check state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233
Enhanced server bringup . . . . . . . . . . . . . . . . . . . . . . . . . . . . .234
Track-Port support under real server for health checks . . . . .234
Sample show commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .235
Syslog for health status change . . . . . . . . . . . . . . . . . . . . . . . .235
Session table parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . .236
Configuring TCP age. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .239
Configuring UDP age . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .239
Setting the clock scale. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .240
Syslog for session table entries . . . . . . . . . . . . . . . . . . . . . . . .240
viii
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Chapter 5
Layer 7 Content Switching
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243
Layer 7 content switching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243
Enabling CSW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .244
Specifying scan depth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .244
Enabling CSW load balance . . . . . . . . . . . . . . . . . . . . . . . . . . .244
CSW rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .245
CSW policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .250
Explanation of offsets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .265
Sample configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .266
CSW topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .267
Request delete configuration . . . . . . . . . . . . . . . . . . . . . . . . . .267
Layer 7 content switching on HTTP response . . . . . . . . . . . . . . . . . 271
Response header rewrite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Configuring HTTP header response rewrite . . . . . . . . . . . . . . . 271
Using multiple cookies under virtual server port . . . . . . . . . . . . . .273
Configuring multiple unique cookie insertion with
cookie path. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .273
Specifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Server passive cookie persistence . . . . . . . . . . . . . . . . . . . . . . . . .275
Configuring server passive cookie persistence . . . . . . . . . . . . 276
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .278
Server and server port persistence with CSW nested rules. . . . . .279
Configuring server and server port persistence with
CSW nested rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .279
Configuring persist on the nested rule . . . . . . . . . . . . . . . . . . .280
Configuring persist on the real port . . . . . . . . . . . . . . . . . . . . .280
Displaying CSW information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .282
Displaying the statistics for all HTTP content rewrites . . . . . .287
Displaying Layer 7 switching statistics . . . . . . . . . . . . . . . . . . .288
Usage guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .289
Support for large GET requests. . . . . . . . . . . . . . . . . . . . . . . . .290
Miscellaneous Layer 7 switching configurations . . . . . . . . . . . . . .290
Cleaning up all hash buckets . . . . . . . . . . . . . . . . . . . . . . . . . .290
Layer 7 content buffering options. . . . . . . . . . . . . . . . . . . . . . .290
HTTP 1.1 support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .291
Layer 7 CSW pseudo stack client-side retransmission
handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .295
Layer 7 CSW pseudo stack server-side TCP packet
out-of-sequence handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . .297
Setting up SSL session ID switching . . . . . . . . . . . . . . . . . . . . . . . .298
Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .301
Command reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .302
rewrite request-delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .302
rewrite request-insert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .303
rewrite request-replace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .303
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
ix
Chapter 6
Hot Standby High Availability
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .305
Hot Standby HA protocol operations. . . . . . . . . . . . . . . . . . . . .306
Hot Standby HA configuration modes . . . . . . . . . . . . . . . . . . . . . . .307
Non-Promiscuous mode with default non-shared MAC option307
Promiscuous mode with shared MAC option . . . . . . . . . . . . . .308
Hot Standby HA Configuration Considerations . . . . . . . . . . . . . . . .308
Configuring standard Hot Standby HA . . . . . . . . . . . . . . . . . . . . . . .308
Additional configuration variations . . . . . . . . . . . . . . . . . . . . . . . . .312
VIP and servers in different subnets . . . . . . . . . . . . . . . . . . . .312
Source-NAT in Hot Standby . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
Configuring additional HA parameters . . . . . . . . . . . . . . . . . . . . . . 314
Configuring a backup group ID . . . . . . . . . . . . . . . . . . . . . . . . .315
Setting the backup timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .315
Enabling backup preference . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Configuring failover based on active VIP count . . . . . . . . . . . . 316
Configuring failover based on the number of active virtual ports317
Delayed failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .318
Configuring a Brocade Virtual ADX to remain in standby state318
Configuring the forwarding of synchronizing messages . . . . . . . . .319
Configuring synchronization with HA . . . . . . . . . . . . . . . . . . . . . . . .319
Hot-standby HA with routing protocols. . . . . . . . . . . . . . . . . . . . . . .319
Tie state of virtual link and HA physical link using health checks321
Chapter 7
SIP Server Load Balancing
SIP overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .323
SIP packet flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .324
SIP client registration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .326
SIP terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .326
SIP message headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .327
SIP SLB and call persistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .328
SIP and call persistence specifications . . . . . . . . . . . . . . . . . .329
Sample deployment topologies. . . . . . . . . . . . . . . . . . . . . . . . .330
SIP server health monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . .333
Configuring SIP SLB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .333
SIP SLB over UDP (Stateless SLB mode) . . . . . . . . . . . . . . . . .333
SIP SLB over UDP (stateful SLB mode). . . . . . . . . . . . . . . . . . .338
Debug commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .340
SIP SLB command reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .343
Real server configuration mode . . . . . . . . . . . . . . . . . . . . . . . .343
Virtual server configuration mode . . . . . . . . . . . . . . . . . . . . . .343
Sample configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .343
Chapter 8
IPv6 Support for Server Load Balancing
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .345
x
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Defining IPv6 real servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .346
Defining IPv6 virtual servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .346
Defining port characteristics using port profile . . . . . . . . . . . . . . .346
Defining IP routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .346
VLAN and tagging definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .347
Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .347
Saving the configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .347
IPv6 configuration example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .347
Appendix A
Server-specific Loopback Configurations
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .349
Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .349
Linux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .349
Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .350
Manual installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .350
Unattended installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .350
Deleting the unwanted routes. . . . . . . . . . . . . . . . . . . . . . . . . .351
Appendix B
SLB Show and Debug Commands
Using show source-ipsource ip [real-server ip | all] . . . . . . . . . . . .355
Using the show session all command . . . . . . . . . . . . . . . . . . . . . . .356
Using the source-ip-debug command . . . . . . . . . . . . . . . . . . . . . . .357
Using the debug filter command . . . . . . . . . . . . . . . . . . . . . . . . . . .357
Using the packet capture utility . . . . . . . . . . . . . . . . . . . . . . . .357
"debug filter" example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .363
Saving captured packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .367
Helpful tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .368
Displaying global Layer 4 Brocade Virtual ADX configuration . . . .368
Displaying real server information and statistics . . . . . . . . . . . . . . 371
Using the show server real command . . . . . . . . . . . . . . . . . . . 371
Using the show server real detail command . . . . . . . . . . . . . .373
Displaying real server keepalive statistics . . . . . . . . . . . . . . . . 376
Displaying real server connections per second statistics . . . . 376
Displaying virtual server information and statistics . . . . . . . . . . . .377
Displaying a list of failed servers . . . . . . . . . . . . . . . . . . . . . . . . . . .380
Displaying a list of failed ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . .380
Displaying port-binding information. . . . . . . . . . . . . . . . . . . . . . . . .381
Using the “show server bind” command . . . . . . . . . . . . . . . . .381
Using the “show server session” command. . . . . . . . . . . . . . .381
Displaying packet traffic statistics . . . . . . . . . . . . . . . . . . . . . . . . . .384
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
xi
Displaying configuration information . . . . . . . . . . . . . . . . . . . . . . . .386
Showing aggregate health of tracked ports . . . . . . . . . . . . . . .386
Auto repeat of show command output . . . . . . . . . . . . . . . . . . .387
Clearing all session table entries . . . . . . . . . . . . . . . . . . . . . . .387
Clearing the connections counter. . . . . . . . . . . . . . . . . . . . . . .388
Appendix C
Acknowledgements
OpenSSL license . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .389
Cryptographic software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .390
Original SSLeay License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .390
xii
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Preface
Document conventions
This section describes text formatting conventions and important notice formats that may be used
in this document.
Text formatting
The following text formatting conventions may be used in the flow of the text to highlight specific
words or phrases.
Format
Description
bold text
Identifies command names
Identifies keywords
Identifies the names of user-manipulated GUI elements
Identifies text to enter at the GUI or CLI
italic text
Provides emphasis
Identifies variables and modifiers
Identifies paths and Internet addresses
Identifies document titles
code
Identifies CLI output
Identifies command syntax examples
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
xiii
Command syntax conventions
Convention
Description
bold text
Identifies command names, keywords, and command options.
italic text
Identifies variables.
[]
Syntax components displayed within square brackets are optional.
{ x | y |z }
A choice of required parameters is enclosed in curly braces separated
byvertical bars. You must select one.
x|y
A vertical bar separates mutually exclusive elements.
<>
Nonprinting characters, for example, passwords, are enclosed in angle
brackets.
...
Repeat the previous element. For example, member [member...].
\
Indicates a “soft” line break in command examples. If a backslash
separates two lines of a command input, enter the entire command at the
prompt without the backslash.
Notes, cautions, and warnings
The following notices and statements may be used in this document. They are listed below in order
of increasing severity of potential hazards.
NOTE
A note provides a tip, guidance or advice, emphasizes important information, or provides a reference
to related information.
ATTENTION
An Attention statement indicates a stronger note, for example, to alert you when traffic might be
interrupted or the device might reboot.
CAUTION
A Caution statement alerts you to situations that can be potentially hazardous to you or cause
damage to hardware, firmware, software, or data.
DANGER
A Danger statement indicates conditions or situations that can be potentially lethal or extremely
hazardous to you. Safety labels are also attached directly to products to warn of these conditions
or situations.
xiv
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Brocade resources
To get up-to-the-minute information, go to http://my.brocade.com to register at no cost for a user ID
and password.
Release notes are available at http://my.brocade.com.
White papers, online demonstrations, and data sheets are available through the Brocade website
at:
http://www.brocade.com/products-solutions/products/index.page
Select Application Delivery Switches on this page to navigate to the relevant product information.
Contacting Brocade Technical Support
As a Brocade customer, you can contact Brocade Technical Support 24x7 online, by telephone, or
by e-mail. Brocade OEM customers contact their OEM/Solutions provider.
For product support information and the latest information on contacting the Technical Assistance
Center, go to http://www.brocade.com/services-support/index.html
If you have purchased Brocade product support directly from Brocade, use one of the following
methods to contact the Brocade Technical Assistance Center 24x7.
Online
Telephone
Email
Preferred method of contact
for non-urgent issues:
Required for Sev 1-Critical and
Sev 2-High issues:
[email protected]
• My Cases through
• Continental US:
MyBrocade
• Software downloads &
licensing tools
• Knowledge Base
Please include:
•
• Europe, Middle East, Africa, •
•
and Asia Pacific: +800-AT
FIBREE (+800 28 34 27
•
1-800-752-8061
33)
Problem summary
Serial number
Installation details
Environment description
• For areas unable to access
toll free number:
+1-408-333-6061
• Toll-free numbers are
available in many countries.
If you have purchased Brocade product support from a Brocade OEM/Solution Provider, contact
your OEM/Solution Provider for all of your product support needs.
• OEM/Solution Providers are trained and certified by Brocade to support Brocade® products.
• Brocade provides backline support for issues that cannot be resolved by the OEM/Solution
Provider.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
xv
Document feedback
• Brocade Supplemental Support augments your existing OEM support contract, providing direct
access to Brocade expertise. For more information, contact Brocade or your OEM.
• For questions regarding service levels and response times, contact your OEM/Solution
Provider.
Document feedback
Quality is our first concern at Brocade and we have made every effort to ensure the accuracy and
completeness of this document. However, if you find an error or an omission, or you think that a
topic needs further development, we want to hear from you. You can provide feedback in two ways:
• Through the online feedback form in the HTML documents posted on
http://www.brocade.com.
• By sending your feedback to [email protected]
Provide the publication title, part number, and as much detail as possible, including the topic
heading and page number if applicable, as well as your suggestions for improvement.
xvi
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Chapter
1
Features
Brocade Virtual ADX Supported Features
The Brocade Virtual ADX supports all of the essential features for ensuring the optimized delivery of
application traffic.
Load Balancing
The Brocade Virtual ADX enables the efficient distribution of traffic among application and
infrastructure servers. In this capacity, the system can load balance traffic based on a number of
different characteristics including server connection load, server resources such as CPU and
memory, application response time, and pre-assigned server weights while ensuring session
stickiness on selected servers when required. Together, these capabilities combined with a rich set
of server monitoring capabilities serve to ensure an optimal application experience.
Content Switching
To manage traffic based on deeper application intelligence, the Brocade Virtual ADX can determine
the server that is best suited to respond to different traffic types and direct traffic accordingly.
Traffic policies can be configured based on both URL and HTTP header information allowing traffic
to be distributed based on user information and device characteristics as well as the content
they're requesting.
OpenScript
The Brocade Virtual ADX includes a powerful application scripting engine for developing real-time
application services - allowing for the manipulation of transaction responses based on information
in the request and vice versa enabling more advanced traffic-handling. The small footprint of the
OpenScript engine increases the number of scripts that can run simultaneously on the system. And
to ensure optimal performance, the system can estimate the performance of custom scripts
without requiring the need for live traffic.
SSL offload for optimization of encrypted traffic
The Brocade Virtual ADX supports the offloading of CPU-intensive SSL negotiation and connection
management from application servers, to improve response times. This is achieved by decrypting
incoming client requests, processing the traffic and load balancing each request before
re-encrypting the response on the return path.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
1
1
Brocade Virtual ADX Supported Features
Advanced networking with support for static and dynamic routing
The system supports both static and dynamic routing (for OSPF, BGP and RIP protocols) as well as
route health injection (RHI). This combination of features allows administrators to configure the
system so that an upstream router can pick the optimal route for reaching a virtual server.
High availability for active and standby deployments
To ensure undisrupted transaction processing the Brocade Virtual ADX can be deployed as an
active-standby pair. In this configuration two ADX devices can be configured so that one device is
set up to actively manage traffic while the other acts as a standby device and is positioned to take
over in the event of a failure. When a failover occurs the active device will transition control to the
standby device effectively switching the roles of the two devices. The result is a more robust load
balancing topology.
Rate Limiting
For added control the Brocade Virtual ADX now supports rate limiting at the port level allowing
administrators to define the maximum throughput for a given port. The system then monitors the
rate of traffic passing through that port and takes preventive action, in real time, based on the
predefined traffic rate.
Support for Brocade Virtual ADX as a GSLB site for increased
availability across datacenters
Global Server Load Balancing (GSLB) is a common deployment topology used to manage traffic
across one or more datacenters or sites. These sites are often distributed geographically. In this
release of the Brocade Virtual ADX, a Brocade GSLB controller can now recognize a Brocade Virtual
ADX instance as participating in a GSLB site, further increasing availability of the entire application.
Extended hypervisor support for heterogeneous environments
The Brocade Virtual ADX can now be deployed on a variety of third party hypervisors including
VMware ESX, Citrix XenServer and KVM. Supported releases are listed below:
• VMware Hypervisor ESX version 4.0 or later and VMware vSphere Client version 4.0 or later
• KVM host 0.9.0 or higher
• Citrix XenServer hypervisor version 6.2.0 or later and Citrix XenCenter client version 6.2 or later
2
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Feature summary
1
Feature summary
The following tables lists the supported features and related documentation for the Brocade Virtual
ADX releases.
TABLE 1
Supported features for Brocade Virtual ADX version 03.1.00
Category
Feature
Document
Networking
Rate Limiting and Counters at VE or VIP
Brocade Virtual ADX Switching and
Routing Guide
Global Server Load Balancing
GSLB controller
Brocade Virtual ADX Global Server
Load Balancing Guide
Licensing
License SKUs
Brocade Virtual ADX Licensing
Guide
Management
Linux Shell access
Single IP address for management port
TCP checksum offload for Xen or KVM
Upgrade process
Additional interfaces
Brocade Virtual ADX Installation
Guide
System-max based on memory
Brocade Virtual ADX Licensing
Guide and
Brocade Virtual ADX Switching and
Routing Guide
Security
ACL
DDoS
SYN-Proxy
TRL
VIP Max-Conn rate
VIP prioritization
Brocade Virtual ADX Security Guide
Server Load Balancing
SIP
Brocade Virtual ADX Server Load
Balancing Guide
TABLE 2
Supported features for Brocade Virtual ADX version 03.0.00
Category
Feature
Document
Networking
IPv6
Brocade Virtual ADX Switching and
Routing Guide
Dynamic routing (for OSPF, BGP and RIP
protocols)
Brocade Virtual ADX Switching and
Routing Guide
Rate limiting at the port level
Brocade Virtual ADX Switching and
Routing Guide
Route health injection (RHI)
Brocade Virtual ADX Server Load
Balancing Guide
Content Switching
SSL session ID switching
Brocade Virtual ADX Server Load
Balancing Guide
Health Monitoring
Health Check for non-HTTP protocols
(RTSP and MMS)
Brocade Virtual ADX Server Load
Balancing Guide
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
3
1
Feature summary
TABLE 2
Supported features for Brocade Virtual ADX version 03.0.00 (Continued)
Category
Feature
Document
High Availability
Hot Standby configuration
Brocade Virtual ADX Server Load
Balancing Guide
Hypervisor
ESX, KVM, XenServer
Brocade Virtual ADX Installation
Guide
Security
SSL Offload, SSL Termination on
Brocade Virtual ADX
Brocade Virtual ADX Security Guide
and Brocade Virtual ADX Server
Load Balancing Guide
DNS DPI
Brocade Virtual ADX Security Guide
IP NAT
Brocade Virtual ADX Security Guide
GSLB
GSLB site
Brocade Virtual ADX Global Server
Load Balancing Guide
XML
Config templates (XML, CLI, and GUI)
Brocade Virtual ADX Graphic User
Interface Guide
TABLE 3
Supported features for Brocade Virtual ADX version 02.0.00
Category
Feature
Document
Networking
Static Routing
Brocade Virtual ADX Switching and
Routing Guide
VLANs and VLAN tagging
Brocade Virtual ADX Switching and
Routing Guide
IPv4
Brocade Virtual ADX Switching and
Routing Guide
Server Load Balancing for TCP and UDP
protocols
Brocade Virtual ADX Server Load
Balancing Guide
Policy-based Server Load Balancing
(PBSLB)
Brocade Virtual ADX Server Load
Balancing Guide
Source NAT
Brocade Virtual ADX Server Load
Balancing Guide
Direct Server Return (DSR)
Brocade Virtual ADX Server Load
Balancing Guide
Content Switching
Content Switching for HTTP protocol
Brocade Virtual ADX Server Load
Balancing Guide
OpenScript
Content Scripting for HTTP protocol
Brocade Virtual ADX OpenScript
Programmer’s Guide and
Brocade Virtual ADX OpenScript
Programmer’s Guide
Health Monitoring
Health Check for TCP, UDP, and HTTP
protocols
Brocade Virtual ADX Server Load
Balancing Guide
Load Balancing
4
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Feature summary
TABLE 3
1
Supported features for Brocade Virtual ADX version 02.0.00 (Continued)
Category
Feature
Document
High Availability
Additional variations, IPv4 to IPv6
gateway high availability support
Brocade Virtual ADX Server Load
Balancing Guide
System Management
All system management including
SOAP/XML API for supported features,
CLI, GUI, syslog, Telnet, SCP, SNTP,
SNMP, AAA, packet filter etc.)
Brocade ADX Administration Guide
and Brocade ADX Graphical User
Interface Guide
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
5
1
6
Feature summary
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Chapter
Server Load Balancing
2
Overview
The Brocade Virtual ADX Application Delivery Switch (Brocade Virtual ADX) helps ease the
administration of TCP-based or UDP-based applications. They provide server load balancing (SLB)
for the application servers, help offload CPU-intensive tasks from the application servers, and
provide added security to the server farm.
In Figure 1, the system administrator has greater flexibility in managing application server
resources. By using a Brocade Virtual ADX, the system administrator can seamlessly add or remove
the application servers (real servers) and handle the changing traffic requirements without
disrupting service to the end-users. The application clients access the virtual IP address or VIP
(virtual server) that is hosted by the Brocade Virtual ADX.
In addition to offering increased control over server resources, the Brocade Virtual ADX offers
numerous other functions, such as application health checks, server offload, and greater security.
FIGURE 1
Single virtual IP address mapped to multiple real servers
The server load balancing (SLB) requires associations between the application servers (real
servers) and the virtual server (VIP). The associations are done by binding TCP or UDP ports on the
real servers with TCP or UDP ports on the virtual server. When a client sends a TCP or UDP request
to an application port defined under the virtual server, the Brocade Virtual ADX identifies one of the
back-end application servers based on the configured load balancing method and forwards the
client request to it. The client is completely unaware of this traffic distribution, but observes
increased availability, faster response time and better throughput. The Brocade Virtual ADX can be
configured to host multiple application services such as web (HTTP), FTP, or DNS under a single
virtual server.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
7
2
Overview
In Figure 1, an application administrator has established a web site www.example7.com. This web
site is mapped to the virtual server (VIP 10.95.55.1) that is hosted on the Brocade Virtual ADX. All
queries made to this web site arrive at the virtual server. The Brocade Virtual ADX then distributes
these queries among the four back-end application servers. The actual addresses of these four real
web servers remain unknown and unseen to the end users. They observe only one IP address,
which is the VIP address for the web service.
How SLB works
A Brocade Virtual ADX running SLB software establishes a virtual server that acts as a front end to
physical servers, distributing user service requests among active real servers. SLB packet
processing is based on the Network Address Translation (NAT) method. Packets received by the
virtual server IP address are translated into the real physical IP address based on the configured
distribution metric (for example, “round robin”) and sent to a real server. Packets returned by the
real server for the end user are translated by SLB so that the source address is that of the virtual
server instead of the real server.
Port translation is not performed for any virtual port that is bound to a default virtual port.
Load-balancing predictor
The load-balancing predictor is an algorithm that determines how traffic is distributed among the
application servers (real servers).
It is possible to fine-tune traffic distribution among servers by selecting one of the following
predictors:
Least connections predictor
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
smooths 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. Servers that are capable of processing and terminating connections faster then receive
more connections than slower servers over time.
NOTE
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 to the entire Brocade Virtual ADX or locally
per virtual server as described in “Changing the Load-Balancing Predictor Method” on page 21.
Round Robin predictor
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 Virtual ADX or locally
per-virtual server as described in “Changing the Load-Balancing Predictor Method” on page 21.
8
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Overview
2
Weighted Round Robin predictor
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 weight of 4 and the second server has a
weight of 2, the sequence of selection would occur as described in the following:
1. The first request is sent to Server1.
2. The second request is sent to Server2.
3. The third request is sent to Server1.
4. The fourth request is sent to Server2.
5. The fifth request is sent to Server1.
6. The sixth request is sent to Server1.
Notice that over this cycle of server connections, Server1, which had a weight of 4, was accessed
four times and Server2, which had 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 the entire Brocade Virtual ADX or
locally per virtual server as described in “Changing the Load-Balancing Predictor Method” on
page 21.
Static Weighted Round Robin predictor
The Static Weighted Round Robin predictor makes its server selections exactly like the Weighted
Round Robin predictor, however, it does not distribute the load to available barrel processors (BPs)
within the Brocade Virtual ADX. Consequently, server selection can be concurrent to better utilize
your system capacity. The following description provides a simple example:
The Brocade Virtual ADX has the following configuration:
• Two BPs are enabled and in an operating state
• Three servers are connected: Server1 with a weight of 3, Server2 with a weight of 2, Server3
with a weight of 1
Distribution will occur as described in the following.
For BP1
1. The first request is sent to Server1.
2. The second request is sent to Server2.
3. The third request is sent to Server3.
4. The fourth request is sent to Server1.
5. The fifth request is sent to Server2.
6. The sixth request is sent to Server1.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
9
2
Overview
For BP2
1. The first request is sent to Server1.
2. The second request is sent to Server2.
3. The third request is sent to Server3.
4. The fourth request is sent to Server1.
5. The fifth request is sent to Server2.
6. The sixth request is sent to Server1.
Notice that this sequence for each pair of servers is exactly the same as described in the example
for the Weighted Round Robin predictor. The only difference is that these selections are being
performed concurrently on each of the BPs which allows each server to be selected more
frequently. This method scales to accommodate the number of processors present in the system.
The Static Weighted Round Robin predictor can be applied globally to the entire Brocade Virtual
ADX or locally per virtual server as described in “Changing the Load-Balancing Predictor Method”
on page 21.
NOTE
To use the static weighted round robin predictor for Layer 7, a server group must be defined for
bound real servers. When all of the server’s fail to meet the Layer-7 selection criteria, load balancing
will not fall back to Layer-4 server load balancing.
Weighted and Enhanced Weighted load balancing
Assigns a performance weight to each server. Weighted and Enhanced load balancing are similar to
least connections, except that 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.
NOTE
it is required that you configure a weight for any real server that is bound to a VIP that is expected to
load balance based on a weighted or enhanced weighted predictor
For example, in a configuration with five servers of various weights, the percentage of connections
is calculated as follows:
•
•
•
•
•
•
Weight server1 = 7
Weight server2 = 8
Weight server3 = 2
Weight server4 = 2
Weight server5 = 5
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.
10
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
2
Overview
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. Therefore, the weight is not a fixed ratio but adjusts to server capacity
over time.
The difference between weighted and enhanced-weighted load-balancing is the method of
distributing the traffic after it is assigned.
Connection assignments with weighted predictor 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, followed by the server with the next greatest weight and so on, until all servers have
received their share of connections. The process then repeats.
Table 4 shows the distribution pattern for Weighted Load-Balancing in an example configuration
with three real servers, A, B, and C. Real Server A has a weight of 1, Real Server B has a weight of
2, and Real Server C has a weight of 3. The numbers in bold indicate which server receives the new
connection. When the weighted predictor is configured, connections are assigned as shown in
Table 4.
TABLE 4
SLB with the weighted predictor
Real Server A
weight = 1
Connections
Server loada
Real Server B
Real Server C
weight = 2
weight = 3
Connections
Server load
Connections
Server load
0
0/1=0
0
0/2=0
0
0/3=0
0
0/1=0
0
0/2=0
1
1/3=0
0
0/1=0
0
0/2=0
2
2/3=0
0
0/1=0
0
0/2=0
3
3/3=1
0
0/1=0
1
1/2=0
3
3/3=1
0
0/1=0
2
2/2=1
3
3/3=1
1
1/1=1
2
2/2=1
3
3/3=1
1
1/1=1
2
2/2=1
4
4/3=1
1
1/1=1
2
2/2=1
5
5/3=1
1
1/1=1
2
2/2=1
6
6/3=2
1
1/1=1
3
3/2=1
6
6/3=2
1
1/1=1
4
4/2=2
6
6/3=2
2
2/1=2
4
4/2=2
6
6/3=2
2
2/1=2
4
4/2=2
7
7/3=2
2
2/1=2
4
4/2=2
8
8/3=2
a. For the weighted predictor, the server load is calculated as connections divided by server weight = server load.
Fractional remainders are rounded down. If there is a tie, the server with the highest weight receives the connection
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
11
2
Overview
Connection assignments with enhanced weighted predictor for enhanced weighted load-balancing
In enhanced weighted load-balancing, the traffic is distributed in the same proportions as in
weighted load-balancing, but the order of distribution is different. With enhanced weighted
load-balancing, the real server with the greatest weight is allocated a connection first, but then the
next connection is allocated to the real server with the next greatest weight, and then to the server
with the next greatest weight on-down-the-line, until all servers have received their first connection.
The process repeats with each real server getting a connection in sequence until each real server
has connections equal to its assigned weight.
Table 5 shows the distribution pattern for Enhanced Weighted Load-Balancing in an example
configuration with three real servers, A, B, and C. Real Server A has a weight of 1, Real Server B has
a weight of 2, and Real Server C has a weight of 3. The numbers in bold indicate which server
receives the new connection. When the weighted predictor is configured, connections are assigned
as shown in Table 5.
TABLE 5
SLB with the enhanced weighted predictor
Real Server A
Real Server B
Real Server C
weight = 1
weight = 2
weight = 3
Connections
Server loada
Connections
Server load
Connections
Server load
0
0x6/1=0
0
0x6/2=0
0
0x6/3=0
0
0x6/1=0
0
0x6/2=0
1
1x6/3=2
0
0x6/1=0
1
1x6/2=3
1
1x6/3=2
1
1x6/1=6
1
1x6/2=3
1
1x6/3=2
1
1x6/1=6
1
1x6/2=3
2
2x6/3=4
1
1x6/1=6
2
2x6/2=6
2
2x6/3=4
1
1x6/1=6
2
2x6/2=6
3
3x6/3=6
1
1x6/1=6
2
2x6/2=6
4
4x6/3=8
1
1x6/1=6
3
3x6/2=9
4
4x6/3=8
2
2 x 6 / 1 = 12
3
3x6/2=9
4
4x6/3=8
2
2 x 6 / 1 = 12
3
3x6/2=9
5
5 x 6 / 3 = 10
2
2 x 6 / 1 = 12
4
4 x 6 / 2 = 12
5
5 x 6 / 3 = 10
2
2 x 6 / 1 = 12
4
4 x 6 / 2 = 12
6
6 x 6 / 3 = 12
2
2 x 6 / 1 = 12
4
4 x 6 / 2 = 12
7
7 x 6 / 3 = 14
2
2 x 6 / 1 = 12
5
5 x 6 / 2 = 15
7
7 x 6 / 3 = 14
a. For the enhanced weighted predictor, the server load is calculated as connections x [combined weights /
server weight] = server load. Fractional remainders are rounded down. If there is a tie, the server with the highest
weight receives the connection.
Weighted and Enhanced Weighted predictors can be enabled as described in: “Changing the
Load-Balancing Predictor Method” on page 21.
12
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Overview
2
Dynamic weighted predictor
The Brocade Virtual ADX provides a dynamic weighted predictor that enables it to make load
balancing decisions using real time server resource usage information, such as CPU utilization and
memory consumption. The Brocade Virtual ADX retrieves this information (through the SNMP
protocol) from MIBs available on the application servers.
To achieve this capability, a software process in the Brocade Virtual ADX, named SNMP manager
(also called SNMP client) is used. This process is different from the SNMP agent process (a.k.a.
SNMP server process) on the Brocade Virtual ADX. A Brocade Virtual ADX can be configured as
both SNMP agent (that allows management of the Brocade Virtual 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 daemon and support MIBs that
can be queried by the SNMP manager of the Brocade Virtual ADX.
You can fine-tune how traffic is distributed across these real servers by enabling Dynamic Weighted
Predictor on the Brocade Virtual ADX.
The Dynamic Weighted predictors can be applied globally to apply for the entire Brocade Virtual
ADX or locally per virtual server as described in “Changing the Load-Balancing Predictor Method”
on page 21 and “Configuring dynamic weighted predictor” on page 24.
NOTE
The global command snmp-server is enabled by default and this command must not be removed if
the dynamic weighted predictor is configured. If this command is removed, then the Brocade Virtual
ADX will stop listening on the UDP port 161 and drop SNMP responses from the real servers that are
used for this predictor.
Dynamic-weighted Direct
The SNMP response from each server is regarded as a performance weight. The displayed SNMP
Weight under “show server real” is the direct weight from the SNMP response. Weighted load
balancing is similar to least connections, except that servers with a higher weight value receive a
larger percentage of connections at a time. The dynamic weight is polled for the specified real
server, and that weight determines the percentage of the current connections that are given to the
server. The default weight is 0 if it does not receive any SNMP response.
For example, in a configuration with five servers of various weights, the percentage of connections
is calculated as follows:
•
•
•
•
•
•
Weight server1 = 7
Weight server2 = 8
Weight server3 = 2
Weight server4 = 2
Weight server5 = 5
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.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
13
2
Overview
If the SNMP-weight indicates that your fastest server gets 50 percent of the connections, the server
will get 50 percent of the connections at a given time. However, because the server is faster than
others, it can complete more than 50 percent of the total connections overall by servicing the
connections at a higher rate. As a result, the weight is not a fixed ratio but instead adjusts to server
capacity over time.
Dynamic-weighted Reverse
The SNMP response from each server is regarded as a performance weight. Reverse-Weighted load
balancing is similar to Direct-Weighted, except that the SNMP-weight will be calculated by the
difference of the maximum based value and the dynamic SNMP response value (max. based value
– SNMP response). The server load balance will balance the same way as the direct-weighted
predictor with the dynamically calculated SNMP-weight value.
For an example of CPU usage, if you configure the maximum based value to 100% and the SNMP
response is 90% of CPU usage, the SNMP weight becomes 10% (100 - 90 = 10). The server load
balance does direct-weight load balancing with the 10% unused CPU time. In other words, servers
with a higher SNMP response (a higher CPU usage and lower SNMP-weight) receive a lower
percentage of connections at a time.
Server response time
Distributes traffic among real servers based on a dynamic weight value that is derived from the
response time of health check packets. If Layer 7 health check is enabled, application response
time is used. If Layer 4 health check in enabled, response time based on TCP SYN and TCP SYN
ACK packets is used. The response time weight is derived from the actual time response
measurement where the shorter the response time, the larger the response time weight value
computed. The response time wait is calculated according to the following rules:
• If the response time is 0, the weight is 1000
• If the response time is greater than 100 ms, the weight is 1
• If the response time is between 0.1 and 100 ms, the weight is 100 divided by the response
time (in 0.1 ms intervals)
The response time predictor is only applicable to TCP traffic.
The server response time predictors can be applied globally to apply for the entire Brocade Virtual
ADX or locally per virtual server as described in “Changing the Load-Balancing Predictor Method”
on page 21.
Sticky connections
When a service request by a client mandates a series of sequential TCP or UDP port connections to
be served by the same real server, you can enable a sticky connection on that TCP or UDP virtual
server port. For example, if a user is accessing dynamically generated pages, the client must
consistently attach to the same server; otherwise, the state information is lost. By default, the
sticky parameter is disabled for virtual service ports.
14
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Overview
2
Application port groups
Application groups enhance the sticky connections method by allowing you to group up to four TCP
or UDP ports with another, “primary” TCP or UDP port. When the Brocade Virtual ADX sends a client
request for the primary port to a real server, requests from the same client for a port that is
grouped with the primary port also go to the same real server. The application group method, like
the sticky method, is governed by the sticky age.
The Brocade Virtual ADX automatically sends requests for the grouped ports to the same real
server as the “primary” port, as long as the sticky timer has not expired. You must define all the
ports in an application group individually in the VIP, and you must configure all of them to be sticky.
Concurrent connections
The concurrent connection option is similar to the sticky option. However, instead of supporting
sequential connections to the same server, the concurrent connection option supports both a
primary connection and secondary connections. The connections are supported at the same time.
The primary connection is the controlling connection and dictates the resource, such as a server, to
which subsequent or secondary connections are made.
When the controlling connection is established, the server dynamically assigns a TCP or UDP port
to which the client should open subsequent or secondary connections. Subsequent connections
from that client are accepted on the server as long as the controlling connection is still active.
Figure 2 shows an example of a concurrent connection. A client initiates a session request to an
application supported on servers S1, S2, and S3. When the SLB switch receives the request, the
switch forwards the request to server S2. This forms the primary connection. Then S2 dynamically
assigns a port, 10000, to the application and forwards it to the client.
FIGURE 2
Concurrent connections in operation on an SLB network
NOTE
The method the server uses to communicate the dynamic port to the client is application-specific.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
15
2
Overview
The Brocade Virtual ADX switches all subsequent connections to S2 to ensure that the application
session completes successfully.
By default, the concurrent property of a virtual TCP or UDP service port is enabled except for FTP,
Telnet, TFTP, HTTP, and SSL ports.
Remote Servers
The application servers that are a Layer 3 hop away (in other words, in a different subnet that is
separated by router) are identified as remote servers in the Brocade Virtual ADX.
Direct Server Return
DSR (Direct Server Return) configures the Brocade Virtual ADX to instruct real servers to send
client responses directly to the clients instead of sending the responses back through the Brocade
Virtual ADX. As a result, the clients experience faster response times and the Brocade Virtual ADX
is free to support more sessions to serve more clients.
The Brocade Virtual ADX supports both Layer 2 Direct Server Return (L2 DSR) and Layer 3 Direct
Server Return (L3 DSR).
• In an L2 DSR configuration, the Brocade Virtual ADX and the real servers are on the same
subnet.
• In an L3 DSR configuration, the Brocade Virtual ADX and the real servers need not be on the
same subnet; they can be connected through a router.
Understanding L2 DSR
As in standard SLB configurations, an L2 DSR-configured Brocade Virtual ADX sends client
requests addressed to a VIP to a load balanced real server. However, the Brocade Virtual ADX does
not translate the destination IP address in the client’s request from the VIP into the real server’s IP
address as in other SLB configurations. Instead, the Brocade Virtual ADX leaves the destination IP
address unchanged. And the Brocade Virtual ADX also formats the client request packets in such a
way that the real servers respond directly to the clients, instead of sending the responses back
through the Brocade Virtual ADX.
For L2 DSR to work you must configure a loopback interface on each real server and give the
loopback interface the same IP address as the VIP. Because the Brocade Virtual ADX sends the
client traffic to the real server without translating the destination address from the VIP into the real
server's IP address, the real server receives the client traffic addressed to its loopback address
and responds directly to the client.
16
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Overview
2
Figure 3 shows an example of a Brocade Virtual ADX deployed in an L2 DSR configuration.
FIGURE 3
Brocade Virtual ADX in an L2 DSR configuration
The example above shows the flow of packets in which the Brocade Virtual ADX and the real
servers are Layer 2 connected.
1. The client sends a packet to an VIP on the Brocade Virtual ADX.
2. The Brocade Virtual ADX forwards the packets to the loopback address on the real server.
3. The real server then sends the packet directly to the client.
L2 DSR can be configured on an individual TCP or UDP port basis when you configure your virtual
servers. For a complete discussion of L2 DSR and a configuration example, refer to “Configuring L2
Direct Server Return” on page 58.
Understanding L3 DSR
As with L2 DSR, a Brocade Virtual ADX configured for L3 DSR enables application servers to
respond directly to the clients resulting in faster server-to-client response times and increased
connection capacity for the Brocade Virtual ADX.
But unlike L2 DSR, which requires that the Brocade Virtual ADX servers and clients be directly
(Layer 2) connected, in an L3 DSR configuration the servers and clients can be connected using a
router.
For L3 DSR to work, the Brocade Virtual ADX must be able to inspect the DSCP field of incoming
packets and modify it to a configured value. Also, the real server must be configured to use the VIP
address as the source IP address in the response if the received packet has a matching DSCP field
value.
A typical configuration includes servers that are one hop away where the Brocade Virtual ADX has
additional intelligence to handle health checks response packets. Figure 4 shows an example of a
Brocade Virtual ADX deployed in an L3 DSR configuration.
FIGURE 4
Brocade Virtual ADX in an L3 DSR configuration
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
17
2
Configuring basic SLB
In the example, the Brocade Virtual ADX inspects and modifies packets sent to a VIP. The real
server uses the L3 DSR VIP as the source address in response packets if the DSCP bit value of the
received packet matches the configured value.
1. The client sends a packet to an L3 DSR VIP on the Brocade Virtual ADX.
2. The Brocade Virtual ADX modifies the DSCP field in the packet to a configured value and sends
the packet to a real server.
3. The real server examines the DSCP field and (if the field matches the configured value) uses
the DSR VIP as a source IP address instead of its own interface IP address. The real server
then sends the packet directly to the client.
For a complete discussion of L3 DSR and a configuration example, refer to “Configuring L3 Direct
Server Return” on page 63.
Configuring basic SLB
To configure basic SLB, perform the following tasks:
• Define the application servers as real servers on the Brocade Virtual ADX. Refer to “Defining
the real servers and real application ports” on page 19.
• Define a virtual server. Refer to “Defining a virtual server (VIP)” on page 20.
• Bind the real servers to the VIP. Refer to “Binding virtual and real servers” on page 21.
Figure 5 shows an example of a basic SLB configuration. This example uses multiple Web servers
to handle remote Web requests received on the Web site. The Web site URL is assigned to the
switch as the focal point for all inquiries as a virtual server address. The virtual server will then
forward requests to each of the four Web servers as specified by the predictor (load balancing
metric).
The sections following this example show how to configure the Brocade Virtual ADX in the example
using the CLI.
FIGURE 5
18
Basic SLB configuration
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Configuring basic SLB
TABLE 6
2
Real and virtual server assignments
Domain name
Virtual IP
Port
Real IP
Port
www.example7.com
10.95.55.1
80
10.95.55.21 (Web1)
80
10.95.55.22 (Web2)
80
10.95.55.23 (Web3)
80
10.95.55.24 (Web4)
80
Configuration guidelines
The following configuration guidelines should be observed when configuring SLB on a switch:
•
•
•
•
•
Each virtual server name and IP address must be unique.
Each virtual server can have multiple TCP or UDP ports assigned.
Each real server name and IP address must be unique.
Each real server can have multiple TCP or UDP ports assigned.
Each real server TCP or UDP port can be bound to one or more virtual TCP or UDP ports.
NOTE
If you need to map a real server port to multiple VIP ports, you can use the multiple port
binding feature. Refer to “Multiple port binding” on page 69.
• One virtual TCP or UDP port can be bound to one or more real TCP or UDP ports.
NOTE
If you need to map virtual port to multiple real server ports, you can use the many-to-one TCP
or UDP port binding feature. Refer to “Multiple port binding” on page 69.
• The default load-balancing predictor is Round Robin.
• Binding must be done to establish a relationship between virtual and real servers.
Defining the real servers and real application ports
Identify your application servers as real servers. Define a real server using its name and IP
address. Add your application ports under these real servers.
NOTE
When you add a port other than port 80 to a real server, the port number l4-check-only command is
automatically applied to the configuration. You cannot remove this command from the non-HTTP
ports.
Virtual
Virtual
Virtual
Virtual
ADX(config)#server real Web1 10.95.55.21
ADX(config-rs-Web1)#port http
ADX(config-rs-Web1)#port dns
ADX(config-rs-Web1)#exit
Virtual ADX(config)#server real Web2 10.95.55.22
Virtual ADX(config-rs-Web2)#port http
Virtual ADX(config-rs-Web2)#port dns
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
19
2
Configuring basic SLB
Virtual ADX(config-rs-Web2)#exit
Virtual
Virtual
Virtual
Virtual
ADX(config)#server real Web3 10.95.55.23
ADX(config-rs-Web3)#port http
ADX(config-rs-Web3)#port dns
ADX(config-rs-Web3)#exit
Virtual
Virtual
Virtual
Virtual
ADX(config)#server real Web4 10.95.55.24
ADX(config-rs-Web4)#port http
ADX(config-rs-Web4)#port dns
ADX(config-rs-Web4)#exit
Syntax: [no] server real [name] ip-address
Syntax: [no] port tcp/udp-port
The server name can be any alphanumeric string of up to 42 characters.
After you have defined the real server, you can refer to it using its name or IP address, and modify
its configuration.
Virtual ADX(config)#server real Web1
Virtual ADX(config-rs-Web1)#port ftp
Virtual ADX(config-rs-Web1)#exit
Virtual ADX(config)#server real 10.95.55.21
Virtual ADX(config-rs-Web1)#port ftp
Virtual ADX(config-rs-Web1)#exit
Virtual ADX(config)#no server real Web1
NOTE
If a real server is not reachable from the Brocade Virtual ADX at Layer 2 (does not respond to ARP
requests from the Brocade Virtual ADX), then define it as a remote server.
NOTE
Optionally, if you have a one-armed topology, you may need to enable source NAT along with
source-ip to ensure that return traffic flows through the Brocade Virtual ADX.
Defining a virtual server (VIP)
After you define the actual Web server’s physical addresses (real server), you then need to
configure the external Web server address on the switch. The external Web server is the virtual
server.
It is the IP address or server name to which client browsers send requests. Add the TCP or UDP
application ports the Brocade Virtual ADX will load balance. These should be the same application
ports you specified for the real servers.
To define the virtual name and address that is the access point for the company's Web site and the
supported service, enter commands such as the following.
Virtual ADX(config-rs-Web4)#server virtual-name-or-ip www.altergo.com 10.95.55.1
Virtual ADX(config-vs-www.altergo.com)#port http
Syntax: [no] server virtual-name-or-ip [name] ip-address
Syntax: [no] port tcp/udp-port
20
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Changing the Load-Balancing Predictor Method
2
After you have defined the virtual server, you can add configuration statements or delete the server
by referring to the server’s IP address or name, by entering commands such as the following.
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server virtual-name-or-ip www.altergo.com 10.95.55.1
ADX(config-vs-www.altergo.com)#port http
ADX(config-vs-www.altergo.com)#exit
ADX(config)#server virtual-name-or-ip 10.95.55.1
ADX(config-vs-www.altergo.com)#exit
ADX(config)#server virtual-name-or-ip www.altergo.com
ADX(config-vs-www.altergo.com)#exit
ADX(config)#no server virtual-name-or-ip 10.95.55.1
Binding virtual and real servers
After you define the real servers, virtual servers, and TCP or UDP ports, you need to bind the real
and virtual servers together. The bindings are based on the TCP and UDP application ports you are
load balancing.
To bind the four Web servers shown in Figure 5 to the virtual server address, enter the following
commands.
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config-rs-Web4)#server virtual-name-or-ip
ADX(config-vs-www.altergo.com)#bind http Web1
ADX(config-vs-www.altergo.com)#bind http Web2
ADX(config-vs-www.altergo.com)#bind http Web3
ADX(config-vs-www.altergo.com)#bind http Web4
www.altergo.com
http
http
http
http
Syntax: [no] bind tcp/udp-port-number real-server-name tcp/udp-port-number
NOTE
For clarity, the bindings in the example are shown as four separate entries. You can enter all the
binding information as one command: bind http Web1 http Web2 http Web3 http Web4 http
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 Virtual ADX, enter the following
command.
Virtual ADX(config)#server predictor round-robin
To change the load-balancing method used by the Brocade Virtual ADX for virtual server “v1”, enter
the following commands.
Virtual ADX(config)#server virtual-name-or-ip v1
Virtual ADX(config-vs-v1)#predictor enhanced-weighted
Syntax: [no] server predictor { least-conn | round-robin | weighted-round-robin |
weighted-round-robin-static |weighted | enhanced-weighted | dynamic-weighted { direct |
reverse } | response-time }
Selecting the least-conn parameter configures the Least Connections load-balancing method. This
method is described in “Least connections predictor” on page 8.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
21
2
Changing the Load-Balancing Predictor Method
Selecting the round-robin parameter configures the Round Robin load-balancing method. This
method is described in “Round Robin predictor” on page 8.
Selecting the weighted-round-robin parameter configures the Weighted Round Robin
load-balancing method. This method is described in “Weighted Round Robin predictor” on page 9.
Selecting the weighted-round-robin-static parameter configures the Static Weighted Round Robin
load-balancing method. This method is described in “Static Weighted Round Robin predictor” on
page 9.
Selecting the weighted parameter configures the Weighted load-balancing method. This method is
described in “Weighted and Enhanced Weighted load balancing” on page 10.
Selecting the enhanced-weighted parameter configures the Weighted load-balancing method. This
method is described in “Weighted and Enhanced Weighted load balancing” on page 10.
Selecting the response-time parameter configures the response time load-balancing method. This
method is described in “Server response time” on page 14. Configuring the response time load
balancing method requires that you configure a smooth factor as described in “Configuring the
smooth factor” on page 25.
Selecting the dynamic-weighted parameter configures the Dynamic Weighted load-balancing
method. This method can be configured as either direct or reverse as described in “Dynamic
weighted predictor” on page 13. Details about configuring the Dynamic Weighted load-balancing
method as direct or reverse are described in “Configuring dynamic weighted predictor” on page 24.
If you enable any of the weighted methods, you must configure the weights for all real servers
involved. The weights can range from 0 through 65000. This configuration is described in
“Configuring a weighted predictor” on page 22.
NOTE
If a given VIP port is bound to multiple ports on the same real server, then the least-connection
predictor may not produce even traffic distribution. Use the round-robin predictor instead.
For overview information, refer to “Load-balancing predictor” on page 8.
Configuring a weighted predictor
Several of the Load-Balancing Predictor Methods used on the Brocade Virtual ADX require that
weights be assigned to the real servers. The Brocade Virtual ADX uses a formula based on each
real server’s assigned weight to calculate the server load for the real servers, then selects the real
server as determined by the predictor that is configured on the Brocade Virtual ADX.
To configure a Load-Balancing Predictor Method, perform the following tasks.
1. Assign weights to the real servers.
2. Configure the weighted predictor either globally or for a virtual server.
NOTE
If a real server port is bound under a VIP but a weight is not configured under the real server, the
Brocade Virtual ADX will assume the weight for that real server is 1.
22
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Changing the Load-Balancing Predictor Method
2
Assigning weights to the real servers
When configuring Weights on a real server, consider the following:
• Real Server Weight assignments apply to all ports configured under the real server.
• For the Weighted Round Robin predictor, server weights are assigned at the server level and
not at the server port level. The load balancing, however, is based on per-server port.
• The Weighted Round Robin predictor has VIP port-level granularity. This granularity is reflected
in the output from the show server session and show server conn commands, because they
display output for the Weighted Round Robin predictor at a per vip-port level.
To configure weights for three real servers, enter commands such as the following.
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
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
Syntax: [no] weight weight-value
The weight command assigns a performance weight to each server or firewall. Servers or firewalls
with a larger or higher weight assigned receive a larger percentage of connections.
The weight-value variable specifies the real server’s weight relative to other real servers in terms of
the number of connections on the server. More precisely, this weight is based on the number of
session table entries the Brocade Virtual ADX has for TCP or UDP sessions with the real server. You
can specify a value from 0 through 65000. The default is 1.
Configuring the weight for real servers
This weight command specifies the weight assigned to the real server. It is used for the weighted
and least connection with server response-time-weights for load balancing methods.
Suppose you want to assign a higher weight to real server Web1 to bias traffic toward that server.
No other changes are made to the weights of Web servers 2, 3, and 4, and they remain configured
with the default weight of zero (Figure 5). Enter commands such as the following.
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server virtual-name-or-ip www.example7.com
ADX(config-vs-www.example7.com)#predictor weighted
ADX(config-vs-www.example7.com)#server real Web1 10.95.55.21
ADX(config-vs-www.example7.com)#exit
ADX(config)#server real Web1
ADX(config-rs-Web1)#weight 10
Syntax: weight least-connections-weight
The least-connections-weight variable specifies the real server’s weight relative to other real
servers in terms of the number of connections on the server. More precisely, this weight is based
on the number of session table entries the Brocade Virtual ADX has for TCP or UDP sessions with
the real server. You can specify a value from 0 to 65000. The default is 1. However, if you want to
use a weight value only for the Server Response Time but not for the number of connections,
specify 0 for this variable.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
23
2
Changing the Load-Balancing Predictor Method
If you enter a value for response-time-weight, the Brocade Virtual ADX adds the two weight values
together when selecting a real server. If you specify equal values for each parameter, the Brocade
Virtual ADX treats the weights equally. The number of connections on the server is just as relevant
as the server’s response time. However, if you set one parameter to a higher value than the other,
the Brocade Virtual ADX places more emphasis (weight) on the parameter with the higher value.
For example, if you specify a higher server response time weight than the weight for the number of
connections, the Brocade Virtual ADX pays more attention to the server’s response time than to the
number of connections it currently has when considering the real server for a new connection.
Configuring dynamic weighted predictor
This section contains the following sections:
• “Configuring a real server with SNMP query requirements” on page 24
• “Configuring a virtual server with a dynamic weighted predictor” on page 24
Configuring a 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.
Virtual 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
The ID variable specifies the snmp-request entry identification, decimal value 1 - 256
The string variable specifies the 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.
Virtual ADX(config-rs-rs1)#snmp-request community public
Syntax: snmp-request community string [ port number ]
The string variable is the SNMP community string. Enter a string with a maximum of 32 characters.
The port port option specifies the snmp-request host UDP port (Default: port 161).
You can configure the frequency of the periodic SNMP queries using the following command.
Virtual ADX(config)#server snmp-poll 5
Syntax: server snmp-poll num
The num variable specifies the decimal value in seconds (Default: 3 sec.)
Configuring a virtual server with a dynamic weighted predictor
Select a dynamic-weighted direct or reverse predictor and an SNMP OID.
24
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Changing the Load-Balancing Predictor Method
2
Dynamic-weighted direct
To configure a dynamic-weighted reverse predictor, use the following command.
Virtual ADX(config-vs-vs1)#predictor dynamic-weighted direct oid 1
Syntax: predictor dynamic-weighted direct oid ID
Configuration example
server virtual-name-or-ip vs1 10.1.1.151
predictor dynamic-weighted direct oid 1
port http
bind http rs1 http rs2 http rs3 http
Dynamic-weighted reverse
To configure a dynamic-weighted reverse predictor, use the following command.
Virtual ADX(config-vs-vs1)#predictor dynamic-weighted reverse oid 1 max 50
Syntax: predictor dynamic-weighted reverse oid ID [max value]
NOTE
The max value option subtracted from the reverse weight is equal to the direct weight.
Configuration example
Virtual ADX(config)#server snmp-poll 5
Virtual ADX(config)#server real rs1 10.1.1.1
snmp-request community public port 161
snmp-request oid 1 1.3.6.1.2.1.25.3.3.1.2.1
snmp-request oid 2 1.3.6.1.2.1.1.3.0
port http
port http keepalive
Virtual ADX(config)#server virtual vs1 10.200.1.1
predictor dynamic-weighted direct oid 1
Configuring the smooth factor
This section applies to the server response time load balancing method.
The Brocade Virtual ADX calculates the server response time value for a real server by regularly
collecting response time samples, then using a calculation to smooth the values of the samples
and derive a single response time value for the real server. The Brocade Virtual ADX relies on the
health-check traffic to sample the response time. As the default interval of health checks to real
servers is five seconds, the Brocade Virtual ADX collects the response time samples for every five
seconds. The sampling rate can vary slightly depending on the processing the Brocade Virtual ADX
is performing.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
25
2
Changing the Load-Balancing Predictor Method
To smooth the samples out, the Brocade Virtual ADX uses the following calculation:
R = ((S * previous_R) + ((100 - S) * new_R)) / 100
where:
R = Response time
S = smooth factor, which is configurable and can be from 1to 99. The default is 60. A large
value gives the previous response time more weight than the new response time. A small value
gives the new response time more weight than the previous response time.
For example, if a given real server’s previous response time value was two milliseconds, and a new
measurement also results in two milliseconds, the calculated server response time using the
smooth factor of 90 is as follows:
R = ((90 * 2) + ((100 - 90) * 2) / 100
R = 180 + 20 / 100
R = 200 / 100
R=2
If the real server’s response time slows due to processing for additional connections, the slower
response time affects the Server Response Time calculation for the server. For example, if the next
server response time sample is five milliseconds instead of two, the Server Response Time
calculation is as follows:
R = ((90 * 2) + ((100 - 90) * 5) / 100
R = 180 + 50 / 100
R = 230 / 100
R = 2.3
Since the real server’s response time has slowed by two and a half times, the server’s response
time calculation biases the Brocade Virtual ADX away from selecting that server for new
connections.
You can affect the degree of difference in subsequent response time weights by changing the
smooth factor (S). For example, if you change the smooth factor from 90 to 50, the calculations
shown above have the following results:
Here is the calculation when the previous and new response times are 2 milliseconds:
R = ((50 * 2) + ((100 - 50) * 2) / 100
R = 100 + 100 / 100
R = 200 / 100
R=2
Here is the calculation if the server’s next response time is 5 milliseconds.
R = ((50 * 2) + ((100 - 50) * 5) / 100
R = 100 + 250 / 100
R = 350 / 100
R = 3.5
26
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Real server ports
2
Notice that the differences between the first and second samples are much greater when the
smooth factor is 50 than when the smooth factor is 90. A large value gives the previous response
time more weight than the new response time. A small value gives the new response time more
weight than the previous response time.
You can change the smooth factor on an individual virtual server’s application port basis.
If you change the smooth factor for a virtual server, the change affects all Server Response Time
calculations for the real servers bound to the virtual server.
If you change the smooth factor for an application port, the change affects Server Response Time
calculations only for port bindings that use that application port.
To change the smooth factor for a virtual server’s application port, enter a command such as the
following at the configuration level for the virtual server:
Virtual ADX(config-vs-Joes_Garage)#port 80 smooth-factor 50
Syntax: [no] smooth-factor num
The num variable specifies the smooth factor value the server response time calculation uses. You
can specify a number from 1 to 99. The default is 60.
Real server ports
You can globally configure an application port by configuring its port profile. When you configure a
port profile, the parameters in the profile apply to all servers that include the application port. To
configure a port profile, refer to “Port profiles and attributes” on page 187.
You also can locally define some SLB port parameters on an individual real-server basis:
• State (enabled or disabled) – Ports are enabled by default.
• Keepalive health check state – Keepalive health checks are enabled if you have configured a
port profile for the port and did not globally disable the health check. You can disable the
keepalive health check locally for the port on a specific real server while leaving the health
check globally enabled.
• Layer 7 health check parameters – For some application ports that are known to the Brocade
Virtual ADX, you can customize the Layer 7 health checks for individual real servers.
Disabling or re-enabling application ports
Application ports are enabled by default. To disable an application port on a real server, use either
of the following methods.
To disable an application port, enter commands such as the following.
Virtual ADX(config)#server real Sy_Borg 192.168.4.69
Virtual ADX(config-rs-Sy_Borg)#port http disable
Syntax: [no] port tcp/udp-port disable | enable
To re-enable a port, enter commands such as the following.
Virtual ADX(config)#server real Sy_Borg 192.168.4.69
Virtual ADX(config-rs-Sy_Borg)#no port http disable
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
27
2
Real server ports
To disable all the application ports on a real server, enter the following command at the
configuration level for the server.
Virtual ADX(config-rs-R1)#port disable-all
To re-enable all the application ports, enter the following command.
Virtual ADX(config-rs-R1)#no port disable-all
Syntax: [no] port disable-all
Globally disabling application ports
You can globally disable a Layer 4 port on the Brocade Virtual ADX. The port can be disabled for all
real servers, all virtual servers, or all real and virtual servers. After you disable a port globally, you
can enable the port on individual real or virtual servers as necessary. By default, all real and virtual
ports are enabled.
When the Brocade Virtual ADX is booted, if the command to globally disable a real or virtual port
exists in the startup-config file, the specified port is disabled at startup. When a real or virtual port
is created, and the port has been disabled globally, the real or virtual port is disabled as well. You
must enable the port explicitly.
To disable all real HTTP ports, enter the following commands.
Virtual ADX(config)#server port 80
Virtual ADX(config-port-http)#disable real
Virtual ADX(config-port-http)#
To disable all virtual HTTP ports, enter the following commands.
Virtual ADX(config)#server port 80
Virtual ADX(config-port-http)#disable virtual
Virtual ADX(config-port-http)#
To disable all real and virtual HTTP ports, enter the following commands.
Virtual ADX(config)#server port 80
Virtual ADX(config-port-http)#disable
Virtual ADX(config-port-http)#
Syntax: disable [real | virtual]
Disabling SLB to a server when an application goes down
By default, if an application on a real server becomes unavailable, but the real server itself is still
up, the Brocade Virtual ADX continues to include the real server in its load balancing decisions for
the application. For example, if the HTTP application on a real server stops responding to Layer 4
health checks, but the real server continues to respond to Layer 3 health checks (IP pings) from the
Brocade Virtual ADX, the Brocade Virtual ADX continues to forward HTTP requests to the real
server.
NOTE
New connections are only sent to servers that have passed an application health check.
In some configurations, such as those that use a cluster of servers for an application, you may want
to configure the Brocade Virtual ADX to stop sending requests to a server when the requested
application is down on the server. For example, this feature is useful in an NFS configuration.
28
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Real server ports
2
When you enable this feature, the Brocade Virtual ADX resets the connection for an unavailable
TCP or UDP application on a real server in addition to redirecting future requests away from this
real server.
To enable the feature, enter commands such as the following:
Virtual
Virtual
Virtual
Virtual
ADX(config)#server virtual vip-test 10.50.1.250
ADX(config-vs-vip-test)#port http
ADX(config-vs-vip-test)#port http reset-on-port-fail
ADX(config-vs-vip-test)#
The above example enables the feature for the http application defined under the virtual server.
Similarly, this feature can be enabled for the other application ports as well.
Syntax: [no] port application-port reset-on-port-fail
Slow-start mechanism
When the Brocade Virtual ADX begins sending client requests to a real server that has recently
gone online, it allows the server to ramp up by using the slow-start mechanism. The slow-start
mechanism allows a server (or a port on the server) to handle a limited number of connections at
first and then gradually handle an increasing number of connections until the maximum is
reached.
The Brocade Virtual ADX uses two kinds of slow-start mechanisms:
• The non-configurable server slow-start mechanism applies to a real server that has just gone
online.
• The configurable port slow-start mechanism applies to individual TCP application ports that
have just been activated on a real server.
Refer to “Slow-start mechanism” on page 225 for more information.
Enabling or disabling the keepalive health check
When you configure a port profile for an application port, the L4/L7 keepalive health check for that
port is enabled automatically. You also can enable or disable the keepalive health check for an
application port on a specific real server, without affecting the global setting for the health check.
NOTE
If you configured a port profile for the port, the keepalive health check is enabled.
To enable the keepalive health check, enter commands such as the following.
Virtual ADX(config)#server real Auto_Plooker 192.168.2.69
Virtual ADX(config-rs-Auto_Plooker)#port http keepalive
To disable the keepalive health check, enter commands such as the following.
Virtual ADX(config)#server real Auto_Plooker 192.168.2.69
Virtual ADX(config-rs-Auto_Plooker)#no port http keepalive
Syntax: [no] port tcp/udp-port keepalive
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
29
2
Real server ports
Configuring a real port as TCP-only or UDP-only
This feature allows you to configure a Brocade Virtual ADX to allow traffic to a virtual port being
load-balanced to a different set of real ports based on its protocol (TCP or UDP). No configuration
change is required for the virtual server. A virtual port can be bound to tcp-only, udp-only and a
regular real port at the same time.
By default, a real port accepts both TCP and UDP traffic. If a real port is configured as tcp-only,
when a given traffic is UDP traffic, the real port will not participate in the server selection, even if it
is bound to the virtual port. Similarly, a udp-only port will not be considered for TCP traffic.
The behaviors of all predictors remain unchanged among eligible real ports (i.e., tcp-only and
regular real ports for TCP traffic, and udp-only and regular real ports for UDP traffic).
The tcp-only, and udp-only commands for a real port are configured under the real port
configuration mode as shown in the following.
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server real R1 10.10.10.1
ADX(config-rs-R1)#port 80 tcp-only
ADX(config-rs-R1)#exit
ADX(config)#server real R2 10.10.11.1
ADX(config-rs-R2)#port 80 udp-only
Syntax: [no] port portnum {tcp-only | udp-only}
The portnum variable specifies the application port you want to make tcp-only or udp-only.
TCP only and UDP only are mutually exclusive. This means that when tcp-only is configured,
udp-only cannot be configured for a port at the same time. udp-only will be automatically disabled if
tcp-only is configured, and vice versa.
Configuring a stateless port
By default, the Brocade Virtual ADX creates session table entries for sessions between clients and
applications on real servers. The Brocade Virtual ADX uses the session table entries to maintain
state information for the sessions. The Brocade Virtual ADX uses the state information for features
such as health checking and session failover in Hot Standby HA configurations.
You can configure individual application ports to be stateless. The Brocade Virtual ADX does not
maintain state information for a stateless port. Making a port stateless is useful when you want to
conserve session table resources or when you have configured the VIP to be transparent.
For examples and configuration information, refer to Chapter 3, “Stateless Server Load Balancing”.
To configure an application port to be stateless, enable the stateless parameter on the port in the
virtual server, such as the following.
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server real R1 10.10.10.1
ADX(config-rs-R1)#port http
ADX(config-rs-R1)#exit
ADX(config)#server real R2 10.10.11.1
ADX(config-rs-R2)#port http
ADX(config-rs-R2)#exit
ADX(config)#server virtual-name-or-ip StatelessHTTP 192.168.4.69
ADX(config-vs-StatelessHTTP)#port http stateless
ADX(config-vs-StatelessHTTP)#bind http R1 http
ADX(config-vs-StatelessHTTP)#bind http R2 http
Syntax: [no] port tcp/udp-portnum stateless
30
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Source NAT
2
The tcp/udp-portnum variable specifies the application port you want to make stateless.
NOTE
The Brocade Virtual ADX supports port translation for stateless SLB. Port translation is useful when
clients connect to real servers directly. Without port translation, if a client connects to a real server
directly, the Brocade Virtual ADX automatically replaces the source IP address to a VIP. When you
configure port translation, the Brocade Virtual ADX overcomes the limitation of performing NAT on
all packets initiated from the real server. NAT does not occur because the Brocade Virtual ADX does
not match the port number.
NOTE
The Brocade Virtual ADX supports stateless SLB for any TCP and UDP application protocols. For a
TCP application, hashing must be enabled on the Brocade Virtual ADX. For a UDP application, you
can enable or disable hashing on the Brocade Virtual ADX.
Source NAT
Source NAT configuration is useful where a Brocade Virtual ADX is connected in one-armed mode;
for example where it is connected to the network infrastructure through an uplink as shown in
Figure 6.
In this situation the Brocade Virtual ADX passes the source IP address of the client to a back-end
application server. If these servers have a direct path to the client, (as would be the case in
one-armed design) the response will bypass the Brocade Virtual ADX in the return path. This bypass
breaks the traffic flow because the client sees the response coming from the IP address of the real
server, instead of the IP address of the virtual server.
With Source NAT configured, a Brocade Virtual ADX replaces the IP address of a client IP with the IP
address of the Brocade Virtual ADX in request packets forwarded to the real server. This action
forces the real server to forward replies to the Brocade Virtual ADX instead of bypassing it.
Figure 6 provides an example of what can occur when a real server has a path back to a client that
bypasses a Brocade Virtual ADX without Source NAT enabled as described in the following.
1. A request from the Client arrives at the Brocade Virtual ADX through a Layer 2 switch.
2. The Brocade Virtual ADX translates the VIP IP address to the IP address of the real server and
forwards the request to the real server through the Layer 2 switch.
3. The real server sees the request coming from the IP address of the client and replies back
directly through the Layer-2 switch bypassing the Brocade Virtual ADX.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
31
2
Source NAT
4. The Client sees the response coming from an unknown IP address (other than the one that it
sent the request to) and drops the packet.
FIGURE 6
Scenario without source NAT configured
In Figure 7 the traffic flow of the configuration is changed by enabling Source NAT as described in
the following:
1. A request from the Client arrives at the Brocade Virtual ADX through a Layer 2 switch.
2. The Brocade Virtual ADX translates the VIP IP address to the IP address of the real server,
replaces the IP address of the client with it’s own IP address and forwards the request to the
real server.
3. The real server sees the request coming from the IP address of the Brocade Virtual ADX and
replies back through the Layer 2 switch to the Brocade Virtual ADX.
4. The Brocade Virtual ADX translates the IP address of the real server to the VIP IP address and
replies to the client.
FIGURE 7
Scenario with source NAT configured
Source NAT can be configured either globally or per real server as described in the following
sections: “Enabling source NAT globally” and “Enabling source NAT on a real server”.
32
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Source NAT
2
Enabling source NAT globally
Source NAT allows the Brocade Virtual ADX to use a specific source IP address as the source for
sending packets to real servers, which is useful for operating in a multinetted environment. You can
enable source NAT globally or locally on individual real servers. If you enable source NAT globally,
the feature applies to all real servers. If you enable the feature locally, the Brocade Virtual ADX
performs source NAT only for those real servers. Other locally-attached real servers, on which
source NAT is not enabled, must be in the same subnet as the Brocade Virtual ADX.
To enable source NAT globally, enter the following command.
Virtual ADX(config)#server source-nat
Syntax: [no] server source-nat
NOTE
In a system with a large number of barrel processors (BP), the usable source NAT ports are limited.
The larger the number of BPs that a system has, the lesser number of Source ports available for the
BP. It is suggested that you use the “Enabling Port Allocation” feature when all 64 Source IPs are
used up. Refer to “Enabling port allocation per real server for source NAT IP” on page 35 and
“Enabling port allocation per real server for source NAT IP” on page 35 for details.
If you are configuring a pair of Brocade Virtual ADX devices for hot-standby (active-standby) HA and
you want to use the same source IP address on each Brocade Virtual ADX, use the server
source-nat-ip command instead.
NOTE
If there are sessions that are currently using the source-nat-ip address and you delete that IP
address, then you should wait till all the sessions are deleted before using the server source-nat-ip
command with the deleted address or before a reload of the Brocade Virtual ADX.
Enabling source NAT on a real server
Source NAT allows the Brocade Virtual ADX to use a source IP address as the source for packets
sent to the real server. Source NAT allows the Brocade Virtual ADX to be in more than one subnet. If
the real server and the Brocade Virtual ADX are in different subnets and not connected by a router
that is multinetted, enable source NAT on the real server.
If you enable source NAT on a real server, the feature applies only to the server. You also can
enable source NAT globally. Refer to “Enabling source NAT globally” on page 33.
To enable source NAT on a real server, enter commands such as the following.
Virtual ADX(config)#server real-name berto
Virtual ADX(config-rs-berto)#source-nat
Syntax: [no] source-nat
Source NAT is disabled by default.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
33
2
Source NAT
Configuring a shared source IP address for NAT
Use the server source-nat-ip command to divide the ports used for source NAT for a source IP
address.
In a hot-standby (active-standby) HA configuration, this command configures a shared source IP
address for NAT. Enter the same command with the same source IP address on each of the
Brocade Virtual ADX devices. The address is active only on one Brocade Virtual ADX (the Brocade
Virtual ADX that is currently active) at a time.
NOTE
This command applies only to hot-standby (active-standby) HA configurations. If you are configuring
a shared IP address for use by the real servers as their default gateway, use the standby-ip address
under the ve interface or ethernet interface, if the IP assignment is done under ethernet interface.
The gateway parameter is required.
To configure a shared source IP address, enter the command such as the following.
Virtual ADX(config)#server source-nat-ip 10.10.10.5/24 0.0.0.0 port-range 2
Syntax: [no] server source-nat-ip ip-addr ip-mask|prefix default-gateway port-range 1 | 2
The ip-addr ip-mask variable is the source address and subnet mask or prefix. For an IPv6 source
address, the prefix length must be equal to or greater than 32.
The default-gateway variable is required. If you do not want to specify a gateway, enter "0.0.0.0".
The port-range parameter specifies which port range this peer uses for source NAT for this source
IP address.Specify 1 for the lower port range or 2 for the upper port range.
Displaying Information about the Shared Source IP Address
To display information about the source IP address, enter the command such as the following.
Syntax: show server source-nat-ip ip-addr
Client subnet based source NAT
The selection of source NAT IP addresses is based on configured client subnets. You can associate
a client subnet with a particular source NAT, which is defined on the Brocade Virtual ADX. You can
also associate multiple client subnets with the same source NAT IP address, and the same client
subnet to multiple source NAT IP addresses. (These association type allow the clients to be
load-balanced to real servers belonging to different subnets, and the source NAT IP address
selected should belong to the same subnet as the real server).
When a client belonging to a configured subnet makes a new connection request, the source NAT
IP address list corresponding to that client’s subnet is retrieved. Out of this list, a source NAT IP
address is selected that is in the same subnet as the selected real server. If the selected source
NAT IP address runs out of source ports, the Brocade Virtual ADX tries to use the next available
source NAT IP address for that client’s subnet. The source-nat-ips that have been defined only for
that client subnet will be used
To configure this feature, enter the following command.
Virtual ADX(config)#server source-nat 192.168.2.10 10.10.6.1
Syntax: server source-nat client-subnet source-ip
The client-subnet variable is the IP address to which the client belongs.
34
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Source NAT
2
The source-ip variable is the source NAT IP address of the subnet with which you want to associate
the client subnet. The source NAT IP address you enter must be configured on the Brocade Virtual
ADX.
Enabling port allocation per real server for source NAT IP
For the Brocade Virtual ADX products, the port pools are not shared globally but are allocated to
each real server and each real server is able to use the entire pool by itself. To enable port
allocation per real server for the source NAPT IP address, use the following command.
Virtual ADX(config)#server source-nat-ip 10.10.10.5 255.255.255.0 0.0.0.0
port-range 2 port-alloc-per-real
Syntax: [no] server source-nat-ip ip-addr ip-mask default-gateway port-range 1|2
[port-alloc-per-real]
This feature is recommended for deployments with large numbers of real servers, which can lead
to a shortage of ports and necessitate configuration of additional source NAT IPs.
NOTE
This enhancement only applies to the server source-nat-ip.
NOTE
You need to write memory and reload after you configure this feature.
Consider the following when enabling port allocation per real server:
• When you enable port allocation per real server, you must reload the Brocade Virtual ADX.
Otherwise, the SLB traffic fails.
• The Brocade Virtual ADX does not use the source-nat-ip default-gateway parameter for remote
server health checks as well as for forwarding SLB traffic to the remote server.
• You should not enable or disable this functionality while the IP addresses are in use by the
traffic flow. You must bring the number of traffic flows utilizing this IP address to zero or
remove the command and redefine it.
As an example, for changing from statement #1 to statement #2 below, either bring the traffic
level to nil or negate the command first using "no server...." and then re-define it.
statement #1: server ... port-range 1
statement #2: server ... port-range 1 port-alloc-per-real
• The maximum number of configured source-nat-ip addresses that can be supported by the
“port allocation per real server” feature is 16.
You can configure the Brocade Virtual ADX to log a message when source NAT IP runs out of ports.
Syntax: [no] source-ip-log
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
35
2
Remote server
Remote 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 Virtual ADX does not include the server in the predictor
(load-balancing method). Instead, the Brocade Virtual 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 42 characters.
This command is used in conjunction with the server load balancing feature on the Brocade Virtual
ADX.
Refer to “Unbinding all application ports from virtual servers” on page 119.
Sticky and concurrent connections
Configuring sticky ports
By default, the Brocade Virtual ADX sends a client’s request to the next available real server based
on the load balancing method. This is true regardless of whether the client has already sent a
request for the same application. If you want the Brocade Virtual ADX to send all of a client’s
requests for a given application to the same real server during a client’s session with the server,
configure the application port to be sticky.
Both the track port and track port group methods of application port grouping require you configure
the application ports involved as sticky ports. For more information, see “Application port grouping”
on page 43.
NOTE
For servers that use passive FTP in a DSR configuration, configure the FTP ports to be both sticky
and concurrent.
NOTE
When a default port is configured as “sticky”, Brocade Virtual ADX creates the sticky session in each
destination port and not in the whole destination port.
To configure a TCP or UDP port as sticky, use the port sticky command when you add that port to a
virtual server:
Virtual ADX(config)#server virtual-name-or-ip v1 10.157.22.1
Virtual ADX(config-vs-v1)#port 80 sticky
In this example, the commands configure HTTP (port 80) as sticky.
Syntax: [no] port tcp/udp-port sticky
36
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Sticky and concurrent connections
2
Configuring stickiness based on client’s subnet
The sticky function causes the Brocade Virtual ADX to send all of a client’s requests for a given
application to the same real server during the client’s session with the server. By default, the
stickiness is based on the client's IP address. You can configure the Brocade Virtual ADX to base
the stickiness on the client’s subnet, rather than IP address. All requests originating from a specific
subnet for a given application are sent to the same real server.
For example, to send all HTTP requests originating from a given subnet to the same real server,
enter commands such as the following.
Virtual ADX(config)#server virtual-name-or-ip vs1 10.10.10.10
Virtual ADX(config-vs-vs1)#port http
Virtual ADX(config-vs-vs1)#port http client-subnet-sticky prefix-length 24
Syntax: [no] port portnum client-subnet-sticky prefix-length prefix-length
or
Syntax: [no] port portnum client-subnet-sticky subnet-mask client-subnet-mask
In this example, client requests from subnet 192.168.9.x would go to the same real server. Sub-net
sticky connections are aged out according to the sticky age setting, in the same way regular sticky
connections are aged out.
The features port sticky and port client-subnet-sticky cannot be configured together on the same
port on the same virtual server.
Setting the sticky age
You can age out inactive sticky server connections. A connection is sticky if you configure the
Brocade Virtual ADX to send successive requests from the same client for the same application
port to the same real server, instead of load balancing the requests to different real servers.
Sticky connections are defined on a virtual server port of an SLB switch when a service request by
a client mandates a series of sequential TCP or UDP port connections to be served by the same
real server. For example, if a client is accessing dynamically generated pages, the client must
consistently attach to the same server, otherwise the state information will be lost.
The sticky age is a global setting applying to all virtual servers; you can also set the sticky age for an
individual virtual server. The sticky age for the individual virtual server overrides the global setting.
To set the sticky age globally, enter a command such as the following.
Virtual ADX(config)#server sticky-age 20
To set the sticky age for an individual virtual server, enter commands such as the following.
Virtual ADX(config)#server virtual-name-or-ip v1
Virtual ADX(config-vs-v1)#sticky-age 20
Syntax: [no] server sticky-age minutes
The minutes variable is the sticky age in minutes. Enter an integer from 2 to 60. The default is 5
minutes.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
37
2
Sticky and concurrent connections
Allowing sticky ports
You can configure the Brocade Virtual ADX to continue using a sticky port (a persistent connection)
even if you have entered a command to unbind the port or the port is disabled.
When you unbind an application port from a server, the Brocade Virtual ADX temporarily places the
port in the aw_unbnd (awaiting unbind) state. If you delete an application port, the Brocade Virtual
ADX temporarily places the port in the aw_del (awaiting delete) state. These temporary states allow
open sessions on the port to be completed before the port is unbound or removed.
By default, when the Brocade Virtual ADX receives a new request associated with a sticky port in
the aw_unbnd state, the Brocade Virtual ADX establishes the session on another real server, not
the real server from which you are unbinding the port.
You can configure the Brocade Virtual ADX to accept new sessions for the same real server for a
sticky port, even under the following conditions:
• The real server port is in the aw_unbnd state.
• The real server port is in the aw_del state.
• The real server port is disabled.
To do so, enter the following command.
Virtual ADX(config)#server allow-sticky
Syntax: [no] server allow-sticky [refresh-age]
The refresh-age option resets the age of a sticky session on the port whenever a new connection
associated with the sticky port is established. This parameter ensures that the session stays up
indefinitely until it is no longer needed.
By default, the Brocade Virtual ADX does not reset the age of the session when new connections
are established. Instead, the session times out after the sticky age expires.
If you use refresh-age, the Brocade Virtual ADX resets the age of the session to the value of the
sticky age. For example, if the sticky age is five minutes (the default), when the Brocade Virtual ADX
establishes a new session on the sticky port, the Brocade Virtual ADX resets the age time for the
session to five minutes. Each time the Brocade Virtual ADX receives another connection request
associated with the sticky session, the Brocade Virtual ADX resets the session age again.
Increasing the sticky-age per VIP longer than 60 minutes
Several applications require sticky age to be longer than the 60 minute global maximum that is
configured using the server sticky-age command as described in “Setting the sticky age” on
page 37. This might occur where a client connects in the morning and requires connectivity
throughput the day.
There are also situations where you may want to configure a different value per virtual server. The
following command allows you to apply a multiplier value to the global sticky-age value for a
specific virtual server.
Virtual ADX(config)#server virtual-name-or-ip vs1 10.10.10.10
Virtual ADX(config-vs-vs1)#sticky-age-multiplier 5
Syntax: sticky-age-multiplier multiplier-value
38
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Sticky and concurrent connections
2
The multiplier-value variable is a numerical value in the following range: 2 to 120. This value is
used to produce a sticky-age value for the virtual server it is configured under that is a multiple of
the value configured globally for the Brocade Virtual ADX as described in “Setting the sticky age” on
page 37. For example, if the sticky age is configured to be 20 minutes, and the sticky-age-multiplier
to be 40, then the actual sticky age of the sticky sessions for the server will be 20x40= 800
minutes.
Note that even though the sticky-ages are multiplied, the show session command will still only
show ordinary age of the sticky sessions. The difference is that the age is incremented in a slower
pace when multiplier is applied. For example if the sticky-age-multiplier is configured to be 40, the
age counter in the session table is incremented once in 40 minutes instead of 1 minute.
NOTE
You can remove the multiplier by using the sticky-age-multiplier 1 or no sticky-age-multiplier number
command.
Sticky connection return from backup server to primary
You can designate real servers as primary servers or backup servers. A primary server is used by
the Brocade Virtual ADX when load balancing client requests for an application. A backup server is
used by the Brocade Virtual ADX only if all the primary servers are unavailable for the requested
application.
In a configuration where one real server is configured as a primary server and another is
configured as a backup, the virtual server can have the sticky option enabled, which ensures that
new connections are sent to the primary server, and a sticky session to a given port is created that
points to that primary server.
If the primary server goes down, new connections are sent to the backup server, and a sticky
session to the port is created that points to the backup server. The sticky session to the
(inoperative) primary server is deleted. When the primary server becomes operative again, since
the sticky session to the backup server is still valid (that is, it has not aged out), new connections to
the port are still sent to the backup server. This is the default behavior.
You can optionally configure the Brocade Virtual ADX to send new connections for the port to the
primary server when it comes back up, even though there is a sticky session to the backup server.
To do this for the DNS port on virtual server v1, enter the following commands.
Virtual
Virtual
Virtual
Virtual
ADX(config)#server virtual-name-or-ip v1 192.168.9.210
ADX(config-vs-v1)#port dns lb-pri-servers
ADX(config-vs-v1)#port dns sticky
ADX(config-vs-v1)#port dns active-primary-overide-sticky
Syntax: port port active-primary-overide-sticky
When the active-primary-overide-sticky command is configured, if the primary server goes down
and then comes back up, any new connection to the DNS port is sent to the primary server. The old
sticky session to the backup server is deleted, and a new sticky session to the primary server is
created.
Group sticky: Layer 4 SLB to server group
Layer 4 load balancing to server groups is performed through a Group Sticky function. This sticky
behavior supports Group Sticky and Group Failover functionality.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
39
2
Sticky and concurrent connections
Enabling group sticky
The group sticky feature enables sticky connections to be load balanced among servers in the
same group. Without this feature, normal sticky behavior always sends a specific client IP to a
specific server. Group Sticky is useful when the server farm is grouped into clusters, and each
cluster has servers with replicated (mirrored) content.
To enable Group Sticky, use the port type group-sticky command.
Configuration example
Figure 8 shows two server groups: group-id 1 1 and group-id 2 2. The configured VIP is serving the
clients and load balancing traffic across the servers in their respective groups.
FIGURE 8
Group sticky sample topology
When a client first enters the system, the Brocade Virtual ADX inspects the defined groups,
predictors, and chooses a server within a group to create a sticky session. When a new connection
comes in from the same client and group sticky is configured, the Brocade Virtual ADX will find all
the servers belonging to the group and will load balance among the servers.
Perform the following steps.
1. Set up the real servers and group IDs. The rs1 and rs2 are in group 1. The devices Web1,
Web2, and Web3 are in group 2.
server real rs1 10.20.1.40
port http
port http url "HEAD /"
port http group-id 1 1
server real rs2 10.20.1.41
port http
port http url "HEAD /"
port http group-id 1 1
server real Web1 10.20.1.42
40
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Sticky and concurrent connections
2
port http
port http url "HEAD /"
port http group-id 2 2
server real Web2 10.20.1.43
port http
port http url "HEAD /"
port http group-id 2 2
server real Web3 10.20.1.44
port http
port http url "HEAD /"
port http group-id 2 2
2. On the VIP, ensure the minimum required commands for Group Sticky are present: port type
group-sticky and port type sticky. If stickiness is not configured, load balancing among the
group will not work.
Virtual ADX(config-vs-v1)#server virtual-name-or-ip vip1 10.40.1.10
Virtual ADX(config-vs-vip1)#predictor round-robin
Virtual ADX(config-vs-vip1)#port http sticky !(or port http
client-subnet-sticky)
Virtual ADX(config-vs-vip1)#port http group-sticky
Virtual ADX(config-vs-vip1)#bind http rs1 http rs2 http Web1 http Web2 http
Virtual ADX(config-vs-vip1)#bind http Web3 http
Once a group sticky session is created, all subsequent traffic will be load balanced across the
group. The first incoming sticky session will go to a real server in group 1. All subsequent
connections will also go to group 1.
If multiple clients are in the same subnet, then use the port http client-subnet-sticky command
instead of port http sticky. The group sticky behavior will apply itself to the client-subnet-sticky.
NOTE
When a real server’s port is part of two groups, the group-sticky feature takes the first listed
group ID only, if the first connection is load balanced to this server.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
41
2
Sticky and concurrent connections
3. Identify what server the sticky session is pointed to. In the example below, the sticky session
was originated from the client 10.30.1.1 to the VIP 10.40.1.10 using real server rs1. All the
traffic to/from the client is being load balanced across the group (group-id 1 1) to which the
real server rs1 belongs. Enter the show session all 0 command (at the BP console) such as the
following.
.
Virtual ADX#rconsole 1 1
Virtual ADX 1/1#show session all 0
Session Info:
Flags - 0:UDP, 1:TCP, 2:IP, 3:INT, 4:INVD, H: sessInHash, N: sessInNextEntry
Index Src-IP
===== ======
0
10.30.1.1
Dst-IP
======
10.40.1.10
S-port D-port Age Next Serv
Flags
====== ====== === ==== ==== =========
0
80
59 000000 rs1
SLB3 H
NOTE
In most cases, an "S-port" of value "0" indicates a sticky session. Regardless of the source port
(S-port) of the connection, the sticky session will stick to Src-IP 10.30.1.1, Dst-IP 10.40.1.10, and
D-port 80 in the example.
To clear a sticky session, use the clear server session command.
Enabling group sticky failover
Normal Group Sticky behavior sends connections to a group of servers. When an entire server
group is unreachable, Group Sticky Failover sends connections to a different reachable group. The
sticky session is removed from the unreachable group; a connection request is forwarded to a new
group, and a new sticky session is then formed with that group.
To enable group sticky failover, enter commands such as the following.
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server virtual-name-or-ip vip1 10.40.1.10
ADX(config-vs-vip1)#predictor round-robin
ADX(config-vs-vip1)#port http sticky
ADX(config-vs-vip1)#port http group-sticky
ADX(config-vs-vip1)#port http group-sticky-failover
ADX(config-vs-vip1)#bind http rs1 http rs2 http rs3 http rs4 http
ADX(config-vs-vip1)#bind http rs5 http
Use the required port http group-sticky-failover command in addition to port http sticky and port
http group-sticky commands. The group-sticky-failover option alone will not work.
Syntax: port type group-sticky-failover
NOTE
You can also apply the server sticky-age command to a sticky group.
42
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Application port grouping
2
Enabling a concurrent port
The concurrent feature allows a client to have sessions on different application ports on the same
real server at the same time. When you enable an application port to be concurrent, 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 attribute is similar to application groups, application groups
apply to specific TCP or UDP ports that you configure on the virtual server.
NOTE
For servers that use passive FTP in a DSR configuration, configure the FTP ports to be both sticky
and concurrent.
To enable an application port to be concurrent, enter commands such as the following.
Virtual ADX(config)#server virtual-name-or-ip v1 10.157.22.1
Virtual ADX(config-vs-v1)#port 80 concurrent
Syntax: [no] port tcp/udp-port concurrent
Application port grouping
The track port and track port group methods of TCP/UDP application grouping are similar. In both
configurations, the Brocade Virtual ADX sends all client requests for ports within a specific set of
application ports to the same real server. The two methods 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, Brocade Virtual ADX tracking does
not apply.
• In a track port group configuration, the Brocade Virtual ADX sends client requests for
applications within a group to the same real server regardless of which application the client
requests first.
The track and track-group commands for a port are mutually exclusive.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
43
2
Application port grouping
Tracking primary ports
You can configure the Brocade Virtual 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.
The primary TCP or UDP port can be grouped with up to four additional TCP or UDP ports. Once the
Brocade Virtual ADX sends a client request for the primary port to a real server, all subsequent
requests from the client for ports grouped with the primary port go to the same real server. For a
configuration example and more information, refer to “TCP/UDP application groups configuration
example” on page 47.
Note that if any primary port is down for a real server, any track ports on that real server are not
considered for load balancing.
NOTE
You must configure all the grouped ports to be “sticky” and bind them to all real servers involved.
NOTE
If a client requests one of the ports that follows the primary port before requesting the primary port
itself, the Brocade Virtual ADX does not make the connection sticky. Only after the client requests
the primary port does the Brocade Virtual ADX make subsequent requests from the client for that
port or ports that track the primary port sticky.
NOTE
For servers that use passive FTP in a DSR configuration, configure the FTP ports to be both sticky
and concurrent.
To configure a TCP or UDP application group, enter the following commands.
Virtual ADX(config)#server virtual-name-or-ip v1 10.157.22.1
Virtual ADX(config-vs-v1)#port 80 sticky
Virtual ADX(config-vs-v1)#port 23 sticky
Virtual ADX(config-vs-v1)#port 69 sticky
Virtual ADX(config-vs-v1)#track 80 23 69
Virtual ADX(config-vs-v1)#bind 80 r1 80 r2 80
Virtual ADX(config-vs-v1)#bind 23 r1 23 r2 23
Virtual 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/UDP-port [TCP/UDP-port]]]
Track port group function
In a track port group, the Brocade Virtual ADX sends client requests for applications within a group
of ports to the same real server, regardless of which application the client requests first.
Up to eight ports can be grouped together using the track port group function. However, a port can
be part of only one track port group. For a configuration example and more information, refer to
“TCP/UDP application groups configuration example” on page 47.
Note that if any service port is down for a real server, the track port groups on that real server are
not considered for load balancing.
44
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Application port grouping
2
NOTE
Every port in a track port group must be configured to be “sticky” and be bound to the real servers
involved.
NOTE
If no track port group configured, the sticky session age is not refreshed if any data session exists.
Only the data session's age will be refreshed if the connection is still alive.
NOTE
If a track port group is configured into the VIP (i.e. for two ports), the sticky session refreshes and
will not expire as long as one of the ports has an alive session.
Configuring a track port group
To configure a track port group, enter commands such as the following:
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server virtual-name-or-ip v1 10.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
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
ADX(config-vs-v1)#exit
In this example, the track-group command groups the HTTP port (80), TFTP port (69), and Telnet
port (23) together. Whenever a client attempts to connect to a port within the port group, the
Brocade Virtual ADX ensures that all ports in the group are active before granting the connection.
Syntax: [no] track-group TCP/UDP-port...
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 Virtual ADX sends a client to a real server for any of these three ports,
subsequent requests from that client for port HTTP, TFTP, or Telnet will go to the same real server.
Track port group health checks for real servers
The Brocade Virtual ADX enables you to configure track port groups for both virtual servers and real
servers; thereby reducing the need to create large numbers of Boolean health checks.
You can track the health of multiple application ports under a real server definition. If the health of
one of the application ports fails, the aggregated health will be marked as fail.
Track port group health checks co-exists with existing health checks and other features of the
Brocade Virtual ADX. If even one of the application ports under real server is not up, the track port
group state will be down and the traffic will not be forwarded to any of the ports in the track port
group.
A sample configuration is shown below.
Virtual ADX(config)#server real r1 10.1.1.1
Virtual ADX(config-real-server-r1) port 80
Virtual ADX(config-real-server-r1) port 8081
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
45
2
Application port grouping
Virtual ADX(config-real-server-r1) port 8082
Virtual ADX(config-rsr1) hc-track-group 80 8081 8082
In this example, the Brocade Virtual ADX now tracks health status for ports 80, 8081, and 8082. If
any of these ports is down. the combined health would be marked as failed and the Brocade Virtual
ADX will not use these ports for load balancing traffic.
Sample configuration
server real rs1 10.1.1.1
port http
port 8081
port 8082
hc-track-group http 8081 8082
Here is the output of the show hc-track-group-state command for this feature.
Virtual ADX#show hc-track-group-state
Real Server
track-group
state
rs1
80 8081 8082
ACTIVE
Syntax: show hc-track-group-state
NOTE
The output of the above command may be truncated. For a complete output display, use the show
hc-track-group-state detail command.
Here is an example output for the show hc-track-group-state detail command.
Virtual ADX#show hc-track-group-state detail
Status of health check track groups
Real Server: rs1
Track-group: 80 8080 8081 8082
State
: DOWN
Real Server: rs2
Track-group: 80 8080 8081 8082
State
: ACTIVE
Enabling track ports in a track port group to unbind
By default, when a lead port of track group is unbound, it goes to the unbind (UNB) state if there is
no connection on this port, although some connections on other ports of the track group exist.
When you configure the server track-group-unbind-wait-all command, it keeps the port lead port in
the await-unbind (AWU) state until no connection on any port of the track group exists.
To configure the Brocade Virtual ADX to allow track ports in a track port group to unbind gracefully
after the unbinding of the track group’s lead port, enter the following command:
Virtual ADX(config)#server track-group-unbind-wait-all
Syntax: [no] server track-group-unbind-wait-all
NOTE
If a port is the primary port of a track group, the port (primary port itself) cannot be unbound
immediately if there is any outstanding sessions for any ports in that track group.
46
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Application port grouping
2
TCP/UDP application groups configuration example
Normally, when the Brocade Virtual ADX selects a real server for a client’s request for a TCP/UDP
port, there is no guarantee that the Brocade Virtual ADX will select the same real server for
subsequent requests from the same client. In many situations, this does not present a problem.
Even when the client is requesting the same Web page or application, if the content or service is
replicated on all the real servers, the client does not know or care which real server provides the
content or service for each request.
However, some applications may require that the client continue to use the same real server. For
example, an interactive Web site might require successive client requests to come to the same
server. Other applications might require that additional TCP/UDP applications also be on the same
real server. Some applications may even require the ability to open concurrent connections on the
client with different TCP/UDP ports dynamically assigned by the real server.
In all of these cases, the predictor (load-balancing metric) does not ensure that the client returns to
the same real server. To accommodate these types of applications, you can configure ports on a
virtual server to have the following attributes:
• Sticky connections – When you add a TCP/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 ages out inactive sticky server connections.
Possible values are from 2 through 60 minutes. The default is 5 minutes. For more
information, see “Setting the sticky age” on page 37.
• TCP/UDP application groups (using the track port function) – A “primary” TCP/UDP port is
grouped with up to four additional TCP/UDP ports. After the Brocade Virtual 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. For more information, see “Tracking
primary ports” on page 44.
• TCP/UDP application groups (using the track group function) – Up to eight TCP/UDP ports are
grouped together. After the Brocade Virtual ADX sends a client request for any of the grouped
ports to a real server, subsequent requests from the client for ports in the group go to the
same real server. For more information, see “Track port group function” on page 44.
NOTE
You must configure all the ports in a TCP/UDP application group to be “sticky”.
• Concurrent connections – The real server can open additional ("concurrent") TCP/UDP
sessions with the client using arbitrary TCP/UDP port numbers.
NOTE
Although the concurrent connections attribute is similar to application groups, application
groups apply to specific TCP/UDP ports that you configure on the virtual server. Concurrent
connections enable the real server to arbitrarily determine the TCP/UDP ports and assign them
to the client.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
47
2
Application port grouping
Figure 9 shows an example of servers configured with sticky ports and an application group. In this
example, the content on each real server is identical. However, some applications on the server
require that clients use the same server for subsequent requests to the application. The virtual
server is configured to make the ports sticky and to group the TFTP and Telnet ports under the
HTTP port.
FIGURE 9
Sticky ports and application group (using the track-port function) used to group TCP/UDP
applications
To implement an application group for this example, enter the following commands.
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server real-name r1 10.0.1.5
ADX(config-rs-r1)#port http
ADX(config-rs-r1)#port tftp
ADX(config-rs-r1)#port telnet
ADX(config-rs-r1)#exit
ADX(config)#server real-name r2 10.0.2.200
ADX(config-rs-r2)#port http
ADX(config-rs-r1)#port telnet
ADX(config-rs-r2)#exit
After you enter information for the real servers, you are ready to create the virtual server. To create
the virtual server, enter the following commands.
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server virtual-name-or-ip v1 10.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 80 69 23
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
ADX(config-vs-v1)#exit
The commands above illustrate the track port function. The sticky parameter makes the TCP/UDP
ports sticky. The track command groups the Telnet port (23) and the TFTP port (69) under the HTTP
port (80); the HTTP port is established as the “primary” port. After the Brocade Virtual ADX sends a
client to a real server for the HTTP port, subsequent requests from that client for the HTTP, TFTP, or
Telnet port go to the same real server. Up to four ports can be grouped with the primary port.
48
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Primary and backup servers
2
NOTE
Because ports 23 and 69 track port 80, state information for the tracking ports (23 and 69 in this
example) are based on the tracked port’s state (port 80 in this example). The state is shown in the
Ms (Master port state) field of the display produced by the show server real command. Refer to
“Displaying real server information and statistics” on page 371.
The track group function works similarly to the track port function. With the track port function, the
client uses the same server for applications associated with the grouped ports, as long as the
primary port is active. In contrast, with the track group function, the client uses the same server for
applications associated with the grouped ports, as long as all the ports in the group are active.
After the Brocade Virtual ADX sends a client to a real server for any of the grouped ports,
subsequent requests from that client for any of the grouped ports go to the same real server.
The following commands illustrate the track group function.
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server virtual-name-or-ip v1 10.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
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
ADX(config-vs-v1)#exit
In this example, the track-group command groups the HTTP port (80), Telnet port (23), and TFTP
port (69) together. Whenever a client attempts to connect to a port within the group, the Brocade
Virtual ADX ensures all ports in the group are active before granting the connection.
The sticky parameter makes the TCP/UDP ports sticky. The sticky parameter must be set for all
ports in the group.
After the Brocade Virtual 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.
Primary and backup servers
The Brocade Virtual ADX has the feature where the real server is either a primary server or a
backup server based on how you added it:
• A primary server is used by the Brocade Virtual ADX when load balancing client requests for an
application. It is a locally attached server added using the server real-name-or-ip command or
using the Web GUI equivalent.
• A backup server is used by the Brocade Virtual ADX only if all the primary servers are
unavailable for the requested application. It is remotely attached and added using the server
remote-name command or using the Web GUI equivalent.
You can explicitly designate a server to be a primary server or a backup server, regardless of the
command you used to add it. Therefore, a primary server or backup server can be locally attached
or attached through a router.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
49
2
Primary and backup servers
In addition, this feature implements the primary and backup configuration on an individual VIP
basis. You designate each backup server by changing the real server configurations. You do not
need to designate the primary servers. You enable the feature in individual VIPs for individual
application ports.
NOTE
The Brocade Virtual ADX does not differentiate between real and remote servers when the
primary-backup feature is enabled. Traffic will be load balanced among primary servers (real or
remote). When all primary servers are down, traffic will be load balanced among backup servers.
NOTE
Without the primary-backup feature enabled, traffic will be load balanced among real servers and
when all real servers are down, traffic will be sent to remote servers.
Figure 10 shows an SLB configuration that uses locally attached and remotely attached servers.
The configuration also uses some of the servers as the primary load-balancing servers while using
the other servers only as backups. Notice that one of the locally attached servers is a backup
server while one of the remotely attached servers is a primary load-balancing server.
FIGURE 10
Servers configured as primaries and backups
By default, when this feature is enabled on a VIP and all the primary servers are unavailable, a VIP
begins using the backup servers until a primary server becomes available again. When a primary
server is available, the VIP uses the primary server instead. Optionally, you can configure a VIP to
continue to use the backup servers even after the primary servers become available again.
To configure primary and backup servers, perform the following tasks.
1. Edit the configuration of each backup real server to designate the server as a backup.
NOTE
You do not need to designate the primary servers. The Brocade Virtual ADX assumes that all
servers you do not designate as backup servers are primary servers.
2. Enable use of the primary and backup servers in individual VIPs on individual application
ports. Only the VIPs and application ports for which you enable the feature use it. The other
application ports within the VIP, and the other VIPs, use the locally-attached servers
(configured using the server real-name-or-ip command) as their primary servers and the
50
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Primary and backup servers
2
remotely-attached servers (configured using the server remote-name command) as their
backup servers.
Optionally, configure the individual applications on the VIPs to continue using the backup
servers following a failover, instead of returning to the primary 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 uses the remotely attached servers as backups.
To designate a real server to be a backup server, enter the following command.
Virtual 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.
Virtual 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.
To configure the VIP and application port to continue using the backup servers even after the
primary servers become available again, use the backup-stay-active parameter, as in the following
example.
Virtual ADX(config-vs-VIP1)#port http lb-pri-servers backup-stay-active
Syntax: [no] port tcp/udp-port lb-pri-servers [backup-stay-active]
When configuring the backup-stay-active option you might expect that all traffic will go to the
backup server even when the primary comes back up however this may not be the case in some
situations as described in the following.
The client traffic is handled by either primary servers only or by the backup servers only at all times.
You can use the show server backup-associated state to see which server is currently active as
shown in the following example.
Virtual ADX(config-vs-VIP1)# show server backup-associated state
Backup state info:
*indicates the current selection
Virtual server: vip1
Status: enabled
IP: 10.1.1.100
http:
Primary: rs1: http(Active)*
Backup: rs2: http(Active)
Syntax: show server backup-associated-state [vip-name [application-port]]
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
51
2
Primary and backup servers
Configuration example
The example configures load-balancing shown in Figure 10 on page 50.
To configure the real servers, enter commands such as the following.
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server real R1 10.10.10.10
ADX(config-rs-R1)#port http
ADX(config-rs-R1)#exit
ADX(config)#server real R2 10.10.10.20
ADX(config-rs-R2)#port http
ADX(config-rs-R2)#exit
ADX(config)#server real R3 10.10.10.30
ADX(config-rs-R3)#backup
ADX(config-rs-R3)#port http
ADX(config-rs-R3)#exit
ADX(config)#server remote-name R4 10.10.10.40
ADX(config-rs-R4)#port http
ADX(config-rs-R4)#exit
ADX(config)#server remote-name R5 10.10.10.50
ADX(config-rs-R5)#backup
ADX(config-rs-R5)#port http
Notice that the backup command is used with servers R3 and R5.
To configure the VIP, enter commands such as the following.
Virtual ADX(config-rs-R5)#server virtual-name-or-ip VIP1 10.10.10.100
Virtual ADX(config-vs-VIP1)#port http lb-pri-servers
Virtual ADX(config-vs-VIP1)#bind http R1 http R2 http R3 http R4 http R5 http
52
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Primary and backup servers
2
Designating a real server port as a backup
Backup functionality can be configured at the application port level, meaning that for a given real
server, you can specify one port to be a backup and another port as a primary. Figure 11 illustrates
this feature.
FIGURE 11
Real server application ports configured as primaries and backups
In this example, real servers RS1 and RS2 are bound to a VIP. Each real server has three ports
defined: HTTP, FTP, and DNS. RS1 is the primary server for HTTP and FTP, and the backup for DNS.
RS2 is the primary server for DNS and the backup for HTTP and FTP. An HTTP or FTP request will
not be sent to RS2 unless the HTTP or FTP service on RS1 is down, and a DNS request will not be
sent to RS1 unless the DNS service on RS2 is down.
To configure the VIP and the real servers in Figure 11, enter commands such as the following.
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server virtual-name-or-ip vs1 10.10.10.10
ADX(config-vs-vs1)#port http
ADX(config-vs-vs1)#bind http rs1 http rs2 http
ADX(config-vs-vs1)#port http lb-primary-servers
ADX(config-vs-vs1)#port ftp
ADX(config-vs-vs1)#bind ftp rs1 ftp rs2 ftp
ADX(config-vs-vs1)#port ftp lb-primary-servers
ADX(config-vs-vs1)#port dns
ADX(config-vs-vs1)#bind dns rs1 dns rs2 dns
ADX(config-vs-vs1)#port dns lb-primary-servers
ADX(config)#server real rs1 10.10.10.1
ADX(config-rs-rs1)#port http
ADX(config-rs-rs1)#port ftp
ADX(config-rs-rs1)#port dns backup
ADX(config-rs-rs1)#exit
ADX(config)#server real rs2 10.10.10.2
ADX(config-rs-rs2)#port http backup
ADX(config-rs-rs2)#port ftp backup
ADX(config-rs-rs2)#port dns
ADX(config-rs-rs2)#exit
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
53
2
Primary and backup servers
Syntax: [no] port port-name backup
Per server based real server backup
The current implementation of the backup server requires that all non-backup servers fail before
SLB directs requests to backup servers. This method might not allow for maintaining the same level
of performance in the server farm. The ability to maintain the same performance level for a given
service is critical for many customers.
Per server based real server backup allows the backup servers to be associated with the specified
primary servers. When a primary server fails, its backup server starts processing the traffic no
matter what state the other primary servers are in. This feature works with the current real server
backup mechanism by providing additional control of the backup server selection.
Current backup scheme
Currently, when a primary server goes down another server is selected among the active primary
servers. Until all the primary servers are down, the server is selected from the backup servers.
Additionally, the users can configure backup-stay-active to keep the server selection in the backup
groups active, even when some primary servers come back up.
Per server based backup scheme
With this feature, the associated primary and backup servers back up each other, regardless of the
state of the other service ports. If a backup server is associated with a primary server, they work as
a pair so that each can substitute for the other when it becomes unavailable.
If the backup-stay-active is configured, the backup server continues to process the traffic even
after the primary server comes up again.
Example
Primary servers: A and B
Backup servers: C and D
Backup association: C is backup of A, D is backup of B.
Condition 1: When A goes down and B is alive, the server is selected from C and B.
Condition 2: When both A and B go down, the server is selected from C and D.
Condition 3: if backup-stay-alive is not configured. When B comes up and A stays down, the server
is selected from C and B.
Condition 4: if backup-stay-alive is configured, when B comes up and A stays down, the server is
selected from C and D.
54
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Primary and backup servers
2
Slow start of the backup and the primary servers
If the server selection predictor is least connection, the backup server can 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 mechanism of the backup or the primary server will be the same as the one currently
being used for the new servers. The slow start parameters are configured on the real server port.
NOTE
The slow start is enabled by default.
One backup per primary port or server
There will be the following restrictions:
• At the real port mode, the primary and backup ports have a one-to-one relationship. That is,
the primary port can only be backed up by one backup port, and the backup port can only back
up one primary port.
• At the real server mode, the primary and backup servers have a one-to-one relationship. That
is, the primary server can only be backed up by one backup server, and the backup server can
only back up one primary server.
The back port has the precedence over the back server
When both the port and the server backup are configured, the port configuration takes precedence
over the server configuration.
For instance, the following is configured:
• The server C is the backup of the server A.
• The port 8080 of the server C is the backup of the port 8080 of the server B.
Then, the port 8080 of the server C becomes the backup of the port 8080 of the server B, but not
the backup of the port 8080 of the server A.
Real server backup commands
• “Server backup association” on page 55
• “Server port backup association” on page 56
• “Display the backup bindings” on page 57
Server backup association
This command is to configure the backup server for a particular primary server, in the real server
mode.
Syntax: [no] backup [server-name]
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
55
2
Primary and backup servers
Example
To configure the real server R2 as the backup of the real server R1.
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server real-name R1 10.10.10.10
ADX(config-rs-R1)#port http
ADX(config-rs-R1)#exit
ADX(config)#server real-name R2 10.10.10.20
ADX(config-rs-R2)#backup R1
ADX(config-rs-R2)#port http
ADX(config-rs-R2)#exit
Server port backup association
This command is to configure the backup server port for a particular primary server port, in the real
server port mode.
Syntax: [no] port port-name backup server-name port-name
Example
To configure the http port of the real server R2 as the backup of the http port of the real server R1.
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server real-name R1 10.10.10.10
ADX(config-rs-R1)#port http
ADX(config-rs-R1)#exit
ADX(config)#server real-name R2 10.10.10.20
ADX(config-rs-R2)#port http
ADX(config-rs-R2)#port http backup R1 http
ADX(config-rs-R2)#exit
NOTE
When both server backup and server port backup are configured, the server port backup has the
precedence over the server backup.
Example
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server real-name R1 10.10.10.10
ADX(config-rs-R1)#port http
ADX(config-rs-R1)#exit
ADX(config)#server real-name R2 10.10.10.20
ADX(config-rs-R2)#port http
ADX(config-rs-R2)#exit
ADX(config)#server real-name R3 10.10.10.30
ADX(config-rs-R2)#backup R2
ADX(config-rs-R2)#port http
ADX(config-rs-R2)#port http backup R1 http
ADX(config-rs-R2)#exit
The server R3 will be the backup of R2, while the HTTP port on R3 will be the backup of the HTTP
port on R1.
56
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Configuring Direct Server Return
2
Display the backup bindings
This command is used to display the binding relationship between the servers and the ports.
Syntax: show server backup-server-port-binding
Example
Virtual ADX(config)#server real-name R1 10.10.10.10
Virtual ADX(config-rs-R1)#port http
Virtual ADX(config-rs-R1)#exit
Virtual ADX(config)#server real-name R2 10.10.10.20
Virtual ADX(config-rs-R2)#backup R1
Virtual ADX(config-rs-R2)#port http
Virtual ADX(config-rs-R2)#port http backup R1 http
Virtual ADX(config-rs-R2)#exit
Virtual ADX(config)#show server backup-server-port-binding
Server/Port State - 0: disabled, 1:enabled, 2:failed, 3:test, 4:suspect,
5:grace_dn, 6:active
Real Server rs3:(state 6)
Backup Server : rs2(state 6)
Port 80(state 6) <---------- Port rs2:80(state 6)
Configuring Direct Server Return
In some Brocade Virtual ADX implementations both client-to-server and server-to-client traffic flow
through Brocade Virtual ADX. In such configurations, the Brocade Virtual ADX uses two sessions for
each connection: one session for the client-to-server traffic and a second session is for the
server-to-client traffic.
Direct Server Return (DSR) configurations enhance server response times and increase capacity
on the Brocade Virtual ADX by allowing server responses (server-to-client traffic) to bypass the
Brocade Virtual ADX.
Direct Server Return may be used in many different Brocade Virtual ADX implementations. For
example, it can be used on a single Brocade Virtual ADX supporting a single server farm or applied
to multiple Brocade Virtual ADX devices in the Hot Standby high availability (HA) scenario.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
57
2
Configuring Direct Server Return
FIGURE 12
Two Brocade Virtual ADX devices in an DSR configuration
Brocade Virtual ADX supports both Layer 2 Direct Server Return (L2 DSR) and Layer 3 Direct Server
Return (L3 DSR). The steps required to configure support L2 DSR and L3 DSR differ significantly.
• In an L2 DSR configuration, the Brocade Virtual ADX and the real servers must be on the same
subnet.
• In an L3 DSR configuration, the Brocade Virtual ADX and the real servers can be connected by
a router.
Configuring L2 Direct Server Return
A Brocade Virtual ADX configured for L2 DSR acts as a dispatcher, sending client requests for a VIP
directly to the real server, which responds directly to the client. The Brocade Virtual ADX does not
translate the destination IP address in the client’s request from the VIP into the real server’s IP
address as in other SLB configurations. Instead, the Brocade Virtual ADX leaves the destination IP
address unchanged.
NOTE
In an L2 DSR configuration, you cannot router hop between the Brocade Virtual ADX devices. They
must have Layer 2 connectivity.
Two changes must be implemented to support L2 DSR:
• Support for L2 DSR must be enabled on individual TCP/UDP ports when you configure the
virtual server (DSR VIP).
• A loopback address must be configured on each real server and the appropriate VIP address
must be assigned to that loopback interface.
58
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Configuring Direct Server Return
2
Enabling L2 DSR on TCP/UDP ports
To configure the Brocade Virtual ADX for L2 DSR, you must 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 L2 DSR for that port.
Virtual ADX(config)#server virtual-name-or-ip v1 10.157.22.1
Virtual ADX(config-vs-v1)#port 80 dsr
Traffic for other ports still returns through the Brocade Virtual ADX. The Brocade Virtual ADX does
not translate the destination IP address in client requests for the port with L2 DSR enabled.
However, the Brocade Virtual ADX still translates the destination IP address in the client’s request
to the real server’s IP address for other ports.
Syntax: [no] port tcp/udp-port dsr
Configuring the loopback address on a real server
To configure the real servers for L2 DSR, configure a loopback interface on each real server and
assign the VIP addresses to the loopback interface.
The loopback interface enables the real server to respond to client requests directed at the VIPs,
while at the same time keeping the real server “hidden”. The loopback interface responds to
unicast traffic directed to it, but does not respond to ARP requests. The Brocade Virtual ADX
responds to pings and ARPs for the VIPs. Thus, any attempt to obtain the real server’s MAC address
using ARP protocol does not succeed.
You can configure loopback addresses on some common types of real servers. Refer to the
“Server-specific Loopback Configurations” on page 349 for details.
Health checks with L2 DSR
Normally, the Brocade Virtual ADX can perform health checks on an application port only when a
server replies from that port pass back through the Brocade Virtual ADX. If the Brocade Virtual ADX
does not see the real server’s responses to client requests, the Brocade Virtual 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 Virtual ADX can still perform heath
checks on the application by sending the health checks to the loopback address you configure on
the real server.
You can use Layer 4 and Layer 7 health checks in your DSR configuration.
• The Brocade Virtual ADX addresses Layer 3 (IP ping) health checks to the real server IP
address.
• The Brocade Virtual ADX addresses Layer 4 and Layer 7 health checks to the real server MAC
address and to the loopback address that matches the VIP address.
The configuration procedures for the health checks are the same as for other types of SLB. Refer to
Chapter 4, “Health Checks”.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
59
2
Configuring Direct Server Return
Placing a session in delete queue
DSR fast delete places a session in a delete queue upon seeing the first FIN in Direct Server Return
(as opposed to the standard two FINs). The session is deleted in eight seconds instead of the
standard two minute FIN session age.
The DSR fast-delete option is enabled by default. To disable the option, enter commands as follows:
Virtual ADX(config)#server virtual-name-or-ip vs
Virtual ADX(config-vs-vs)#port 80 dsr no-fast-delete
Syntax: [no] port port dsr no-fast-delete
NOTE
The default setting is recommended in most cases. In the DSR setup, the Brocade Virtual ADX will
not be able to see a FIN message from a server, resulting into session piling up and connection drops
when the same TCP connection is reused within two minutes by a client.
L2 DSR configuration example
Direct Server Return may be used in many different Brocade Virtual ADX implementations including
the Hot Standby high availability (HA) scenario. Figure 13 shows an example of an L2 DSR
configuration for an HA scenario.
FIGURE 13
60
Brocade Virtual ADX devices deployed in Direct Server Return configuration
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Configuring Direct Server Return
2
To implement the configuration shown in Figure 13, configure Brocade Virtual ADX devices A and B.
Because multiple VIPs are mapped to the same ports on the same real servers, TCP/UDP port
binding is used. Thus, port 180 on VIP2 on Brocade Virtual ADX A and on VIP1 on Brocade Virtual
ADX B is a logical port that is bound to port 80 on the real servers. For more information, refer to
“Multiple port binding” on page 69.
TABLE 7
DSR configuration example
Brocade
Virtual ADX
Domain name
Virtual IP (VIP)
address
VIP’s TCP
port
Real IP address
Real Server TCP
port
A
www.abc.com
VIP1:
10.157.22.100
80
Real Server 1:
10.0.0.1
80
Real Server 2:
10.0.0.2
80
Real Server 1:
10.0.1.1
180
Real Server 2:
10.0.1.2
180
Real Server 3:
10.0.0.1
180
Real Server 4:
10.0.0.2
180
Real Server 3:
10.0.1.1
80
Real Server 4:
10.0.1.2
80
A
B
B
www.def.com
www.abc.com
www.def.com
VIP2:
10.157.22.101
VIP1:
10.157.22.100
VIP2:
10.157.22.101
80
80
80
Note the dsr parameter on the port commands that add the HTTP port (TCP port 80) to the VIPs. To
enable L2 DSR for additional TCP/UDP ports, use the dsr parameter for each port when you add
the port to a VIP.
NOTE
Be sure you configure all the real servers on both Brocade Virtual ADX devices, and bind the VIPs on
each Brocade Virtual ADX to all the real servers.
Configuring Brocade Virtual ADX A
Notice that all four real servers must be configured, and bound to the VIPs, on both Brocade Virtual
ADX devices. Notice also that two HTTP ports are added to each real server. This type of
configuration requires that you use the TCP/UDP port binding feature to bind the ports on the two
real servers to the same port on the virtual server. For information, refer to “Multiple port binding”
on page 69.
To configure the real servers, enter the following commands.
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADXA(config)#server real-name Real_Server_1 10.0.0.1
ADXA(config-rs-Real_Server_1)#port http
ADXA(config-rs-Real_Server_1)#port 180
ADXA(config-rs-Real_Server_1)#exit
ADXA(config)#server real-name Real_Server_2 10.0.0.2
ADXA(config-rs-Real_Server_2)#port http
ADXA(config-rs-Real_Server_2)#port 180
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
61
2
Configuring Direct Server Return
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADXA(config-rs-Real_Server_2)#exit
ADXA(config)#server real-name Real_Server_3 10.0.1.1
ADXA(config-rs-Real_Server_3)#port http
ADXA(config-rs-Real_Server_3)#port 180
ADXA(config-rs-Real_Server_3)#exit
ADXA(config)#server real-name Real_Server_4 10.0.1.2
ADXA(config-rs-Real_Server_4)#port http
ADXA(config-rs-Real_Server_4)#port 180
ADXA(config-rs-Real_Server_4)#exit
To configure the VIPs, enter the following commands.
Virtual ADXA(config)#server virtual-name-or-ip VIP1 10.157.22.100
Virtual ADXA(config-vs-VIP1)#port http dsr
Virtual ADXA(config-vs-VIP1)#bind http Real_Server_1 http Real_Server_2 http
Real_Server_3 http Real_Server_4 http
Virtual ADXA(config-vs-VIP1)#exit
Virtual ADXA(config)#server virtual-name-or-ip VIP2 10.157.22.101
Virtual ADXA(config-vs-VIP2)#port http dsr
Virtual ADXA(config-vs-VIP2)#bind http Real_Server_1 180 Real_Server_2 180
Real_Server_3 180 Real_Server_4 180
Virtual ADXA(config-vs-VIP2)#no http port translate
Virtual ADXA(config-vs-VIP2)#exit
Virtual ADXA(config)#write memory
Configuring Brocade Virtual ADX B
To configure the real servers, enter the following commands.
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADXB(config)#server real-name Real_Server_1
ADXB(config-rs-Real_Server_1)#port http
ADXB(config-rs-Real_Server_1)#port 180
ADXB(config-rs-Real_Server_1)#exit
ADXB(config)#server real-name Real_Server_2
ADXB(config-rs-Real_Server_2)#port http
ADXB(config-rs-Real_Server_2)#port 180
ADXB(config-rs-Real_Server_2)#exit
ADXB(config)#server real-name Real_Server_3
ADXB(config-rs-Real_Server_3)#port http
ADXB(config-rs-Real_Server_3)#port 180
ADXB(config-rs-Real_Server_3)#exit
ADXB(config)#server real-name Real_Server_4
ADXB(config-rs-Real_Server_4)#port http
ADXB(config-rs-Real_Server_4)#port 180
ADXB(config-rs-Real_Server_4)#exit
10.0.0.1
10.0.0.2
10.0.1.1
10.0.1.2
To configure the VIPs, enter the following commands.
Virtual ADXB(config)#server virtual-name-or-ip VIP1 10.157.22.100
Virtual ADXB(config-vs-VIP1)#port http dsr
Virtual ADXB(config-vs-VIP1)#bind http Real_Server_1 180 Real_Server_2 180
Real_Server_3 180 Real_Server_4 180
Virtual ADXB(config-vs-VIP1)#no http port translate
Virtual ADXB(config-vs-VIP1)#exit
Virtual ADXB(config)#server virtual-name-or-ip VIP2 10.157.22.101
Virtual ADXB(config-vs-VIP2)#port http dsr
Virtual ADXB(config-vs-VIP2)#bind http Real_Server_1 http Real_Server_2 http
Real_Server_3 http Real_Server_4 http
Virtual ADXB(config-vs-VIP2)#exit
Virtual ADXB(config)#write memory
62
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Configuring Direct Server Return
2
Configuring L3 Direct Server Return
In an L3 DSR configuration, the Brocade Virtual ADX marks all packets sent to servers bound to a
specified VIP (the L3 DSR VIP) by setting the DSCP field to a configured value.
The real server must be programmed to check the DSCP field of incoming packets and change the
source IP address of appropriate reply packets from its own IP address (real IP address) to the
virtual IP address (VIP).
Three changes must be implemented to support L3 DSR:
• TOS marking of SLB and health check packets: All SLB and health check traffic sent to servers
bound to a specified VIP must be marked by a specific DSCP field value. Use the tos-marking
command to specify the DSCP field value.
• Special intelligence on real servers: The real server must be programmed to check the DSCP
field of incoming packets and change the source IP address of appropriate reply packets from
its own IP address (real IP address) to the virtual IP address (VIP).
• Special intelligence for handling health check responses: To enable the Brocade Virtual ADX to
correctly handle health check replies you must configure hc-l3-dsr under the VIP using the
tos-marking command with the hc-l3-dsr option.
TOS marking of SLB and health check packets
To configure the Brocade Virtual ADX for L3 DSR, the Brocade Virtual ADX must set the DSCP field
value in all packets sent to servers bound to a specified VIP.
Use the tos-marking command within a VIP configuration to specify the DSCP field value of traffic
packets send to real servers bound to a specific VIP.
Virtual ADX(config)#server virtual-name-or-ip vip1 10.10.1.151
Virtual ADX(config-vs-vip1)#tos-marking 18
Virtual ADX(config-vs-vip1)#bind http rs1 http
The Brocade Virtual ADX sets the DSCP field value to 18 in all packets sent to real server rs1.
Use the hc-l3-dsr option to ensure that Brocade Virtual ADX will process the health check reply
packets correctly:
Virtual ADX(config)#server virtual-name-or-ip vip1 10.10.1.151
Virtual ADX(config-vs-vip1)#tos-marking 18 hc-l3-dsr
Virtual ADX(config-vs-vip1)#bind http rs1 http
Although the Brocade Virtual ADX will have sent health check probes to the real server IP, it will
receive replies from the VIP. The hc-l3-dsr option ensures that responses from a different IP
address are handled correctly.
Syntax: tos-marking DSCP-value hc-l3-dsr
The DSCP-value variable specifies the value of the DSCP field that you want to send to all packets
sent to servers bound to the VIP.
With the hc-l3-dsr option configured the health check reply packets will be sent back to the VIP on
the Brocade Virtual ADX.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
63
2
Configuring Direct Server Return
Special handling by real servers
L3 DSR requires special intelligence on the real server. Real servers must be programmed to check
for DSCP field values in incoming packets and, if the received DSCP value matched a preconfigured
value, change the source IP address of reply packets from its own IP address (real-ip) to a virtual IP
address (virtual-ip).
Health checks with L3 DSR
When TOS marking is configured, all health check packets to servers bound under a VIP will have
DSCP field set with a configured value. If special handling is enabled on the real servers, reply
packets will come from VIP instead of the real server IP. For the Brocade Virtual ADX to process
these reply packets correctly, you must configure tos marking using the hc-l3-dsr option.
With the hc-l3-dsr option configured the health check reply packets will be sent back to the VIP on
the Brocade Virtual ADX. If you have the tos-marking command configured without this option, if a
reply packet has the VIP as its source IP address, health checks will fail and the packet will be
dropped.
The tos-marking hc-l3-dsr command implicitly enables DSR fast-delete. Hence, the option
expedites deleting DSR SLB sessions when the Brocade Virtual ADX receives a first TCP FIN
message from a client; this behavior is similar to dsr fast-delete for L2 DSR. For information, refer
to “Placing a session in delete queue” on page 60.
NOTE
Only TCP is supported with L3 DSR health checks. For UDP and ICMP health checks, the Brocade
Virtual ADX does not mark the DSCP field.
L3 DSR configuration example
To enable Layer 3 DSR, you must configure a Brocade Virtual ADX to set the DSCP field to a
configured value in all packets sent to servers bound to a specified VIP (L3 DSR VIP).
Use the tos-marking command with the hc-l3-dsr option under the VIP to set the DSCP field to a
configured value. The hc-l3-dsr option makes the Brocade Virtual ADX to accept health check
packets coming from the L3 DSR VIP rather than the real server IP address.
To enable Layer 3 DSR, perform the following steps.
1. Configure a real server as a remote server because it is not connected to any VLANs on the
Brocade Virtual ADX.
Virtual ADX(config)#server remote-server rs1 10.20.1.31
Virtual ADX(config-rs-rs1)#port http
Virtual ADX(config-rs-rs1)#exit
2. Define an SLB VIP and make it to an L3 DSR VIP by configuring the tos-marking command and
hc-l3-dsr option.
Virtual ADX(config)#server virtual-name-or-ip vip1 10.1.1.151
Virtual ADX(config-vs-vip1)#tos-marking 20 hc-l3-dsr
In this example, Brocade Virtual ADX sets the DSCP value to 20 in all packets, either for health
check or server load balancing, sent to real server rs1. Note that ADX is not configured with
source-nat even though you have a remote server.
64
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Displaying server information
2
NOTE
To make the above configuration work, the real server must have a special intelligence. When the
server receives a packet with DSCP value 20, it should use "10.1.1.151" as a source IP address in
response packets.
NOTE
When DSR is configured, the server directly responds to the client, therefore, if the user binds
different real server ports and virtual server ports, e.g. port 8080 of real server to port 80 of virtual
server, the DSR traffic will not work.
Displaying server information
The show server command, as a standalone command, gives the output of the following
commands together:
• show server global - Refer to “Displaying global Layer 4 Brocade Virtual ADX configuration” on
page 368.
• show server bind - Refer to “Displaying port-binding information” on page 381.
• show server sessions - Refer to “Displaying port-binding information” on page 381.
• show server traffic - Refer to “Displaying packet traffic statistics” on page 384.
The show server global command gives the output of the show server backup command.
Port ranges
Port ranges can be defined under real servers or virtual servers. Port ranges can be used with bind
statement under VIP. Additionally, you can define port profiles for a port range and specify
characteristics such as TCP or UDP, keepalive timers, retires for all ports inside port range.
NOTE
Port-policy definition is not supported with port range. This is because all ports inside a port range
must have the same characteristics, and these characteristics can be defined using port profile.
The Brocade Virtual ADX processes client requests destined to ports inside a port range in the
same way it processes connections to individual ports.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
65
2
Port ranges
Defining a port range
Port ranges are identified by their names. A port range can be created as follows.
1. Define the port range
Virtual ADX(config)#port-range pr1
Syntax: [no] port-range port-range-name
2. Identify the ports in the range.
Virtual ADX(config-pr-pr1)#port 8051 to 8100
Syntax: [no] port port-number to port-number
Enter the port’s numerical value for port-number.
When defining a port range:
•
•
•
•
•
•
Ports in a port range must be consecutive.
You must define a starting port and an ending port for the range.
The starting port must be greater than zero (0).
The ending port must be larger than the starting port.
There can be up to 50 ports in a port range.
You can change the starting port and ending port using a single command. When changing the
ports in a port range, if the port range is not used with a bind statement or other configuration,
then the change is applied immediately; otherwise, the change remains pending until the apply
port-range command is issued.
• You cannot include the default port (65535) and well-known ports in a port range.
• Furthermore, if role-based management is used, only the super user or global manager can
create port ranges at the global configuration level. Role-based users can use port ranges and
bind them under the real server and virtual server configuration levels. Also, role-based users
can view the list of port ranges by issuing the show port-range command.
• If you define many port ranges to cover many application ports (several hundreds or thousands
of ports) then you need to keep an eye on MP CPU resources, because a system might not be
able to handle health checks for all these ports. Disabling of health checks for several ports or
port-ranges might be needed in such cases to prevent health check issues.
• Port ranges cannot be used with alias port ("real-port") definitions.
• Some of the other features not supported with port range are: Multiple port binding, PBSLB,
boolean health check, scripted health check, track-groups, track-ports, tcp offload, and
keepalive.
66
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Port ranges
2
Using a port range under a real server definition
You can define port ranges under a real server definition.
Virtual ADX(config)#server real real1 10.0.0.1
Virtual ADX(config-rs-real1)#port-range pr1
Syntax: [no] port-range port-range-name
Enter the ID of the port range for port-range-name. Refer to the rules in “Defining a port range” on
page 66 for additional rules.
You can add more than one port range to a real server; however, the ports in the port ranges
cannot overlap. For example, if you define PR1 to include ports 8051 to 8100 and define PR2 to
include ports 8061 to 8110, then you cannot use these two port ranges under the same real server
because ports are overlapping. Also, if a port is included inside a port range and that port range is
specified under real server, then the port cannot be specified separately under same real server.
All commands available to a single application port are available to the ports in a port range. For
example, you can configure keepalive for a port range as you would for a single port.
Virtual ADX(config)#server real rs1 10.0.0.1
Virtual ADX(config-rs-rs1)#port-range pr1 keepalive
Using a port range under a virtual server definition
You can define a port range under a virtual server.
Virtual ADX(config)#server virtual-name-or-ip virtual1 10.0.0.1
Virtual ADX(config-vs-virtual1)#port-range pr1
Syntax: [no] port-range port-range-name
Enter the ID of the port range for port-range-name.
The rules for including port ranges to a real server also apply to a virtual server. (Refer to “Using a
port range under a real server definition”.)
Binding a port range for virtual ports to a real server
You can bind a port range from under a virtual server to real servers. Binding a port range is
equivalent to binding all ports contained in the port range to the specified real server. All rules that
apply to single port bindings also apply to binding port ranges. In addition, you can bind different
port ranges to a virtual server if the port ranges each have the same number of ports.
The binding is a one-to-one mapping, where the starting port in the virtual server port range is
bound to the starting port in the real server port range. The second port in a virtual server port
range is bound to the second port of a real server port range.
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#port-range pr1
ADX(config-pr-pr1)#port 8051 to 8100
ADX(config-pr-pr1)#exit
ADX(config)#port-range pr2
ADX(config-pr-pr2)#port 7051 to 7100
ADX(config-pr-pr2)#exit
ADX(config)#server virtual-name-or-ip virtual1 10.0.0.1
ADX(config-vs-virtual1)#bind-range pr1 realserver1 pr1 realserver2 pr2
Syntax: [no] bind-range port-range-name real-server-name port-range-name
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
67
2
Port ranges
Defining port profile for port range
You can define a profile for a port range. Policies and other features defined for a port profile are
applied to all the ports included in the port range.
Virtual ADX(config)#server port-profile port-range pr1
Virtual ADX(config-port-profile-range-pr1))#tcp keepalive use-master-state
Syntax: [no] server port-profile port-range port-range-name
The following commands are available under the port-profile-range configuration level:
•
•
•
•
•
•
•
bringup-retries
disable
l4-bringup-interval
l7-bringup-interval
no-fast-bringup
tcp
udp
When defining a port profile for a port range, note the following:
• A separate port profile for an individual port inside a port-range definition is not permitted. All
ports inside a port-range must have the same properties.
• In the case of overlapping port ranges that are used under different real servers, a port profile
for only one of the port ranges is allowed. You cannot have conflicting properties for the same
port under different port ranges.
Displaying a list of port ranges
You can display a list of port ranges that have been created in the Brocade Virtual ADX by issuing
the following command.
Virtual ADX(config)#show port-range
Syntax: show port-range [start-index]
Issuing the show port-range command displays information for all the port ranges configured on
the Brocade Virtual ADX. To limit the number of port ranges included in the output, issue the show
port-range start-index command. Information only for the port ranges starting from the specified
start-index is displayed.
Virtual ADX#show port-range
Name
Start
pr2
8090
pr3
8140
pr98
9800
range4
7001
End
8139
8149
9803
7050
Pending Start
Pending End RefCnt
500
100
4
.
68
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Multiple port binding
2
Using a start-index variable begins display at the record specified where the first record has a value
of 0. In the following example, the start-index value of 2 is used on the same port-range displayed
in the previous example.
Virtual ADX(config)#show port-range 2
Name
Start
End
pr98
9800
9803
range4
7001
7050
Pending Start
Pending End RefCnt
4
To display a list of port ranges with a name that starts with a specified prefix, issue the following
command.
Virtual ADX(config)#show port-range starts-with pr
Syntax: show port-range starts-with prefix
Virtual ADX#show port-range starts with pr
Name
Start
End
pr2
8090
8139
pr3
8140
8149
pr98
9800
9803
Pending Start
Pending End RefCnt
500
100
4
The Table 8 describes the information in the output.
TABLE 8
Field descriptions of show port-range command
Field
Description
Name
Name of the port range
Start
First port in the port range
End
Last port in the port range
Pending Start
The port range has been changed but the apply port-range command has
not been issued. This column shows the start of the new port range.
Pending End
The port range has been changed but the apply port-range command has
not been issued. This column shows the end of the new port range.
RefCnt
This field is used by developers for debugging purposes.
Multiple port binding
Multiple port binding allows you to bind one real server port to multiple virtual server ports.
The Brocade Virtual ADX supports two methods of associating a real server TCP or UDP port to
multiple virtual TCP or UDP ports (VIPs): direct binding of multiple ports and port aliases.
• Direct binding of multiple ports enables to you to associate a real server TCP or UDP port
directly to multiple virtual TCP or UDP ports. Using this method you do not need to configure
additional alias ports for real ports or virtual ports in order to bind a single real server to
multiple virtual servers; nor are alias ports needed to bind a real server to multiple virtual ports
on a single virtual server.
• Port aliases bind a real server TCP or UDP port to multiple port aliases, which are bound to the
virtual ports.
Although the Brocade Virtual ADX supports both direct binding of multiple ports and port aliases,
the two methods cannot co-exist for the same real port or virtual port.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
69
2
Multiple port binding
To simplify an existing configuration that uses port aliases, you can manually convert that
configuration to the direct binding method to reduce the size of SLB configurations. If you choose to
use the direct method, you must first remove all alias port bindings and reload your configuration.
Direct binding of multiple ports
Direct binding of multiple ports enables you to associate a real server TCP or UDP port with multiple
virtual TCP or UDP ports.
Binding a real server port to multiple VIPs
To bind one real server port (rs1) to multiple VIPs (vs1 and vs2), complete the following steps:
1. Create a real server with one port.
Virtual ADX(config)#server real rs1 10.0.0.1
Virtual ADX(config-rs-rs1)#port http
2. Create a virtual server.
Virtual ADX(config)#server virtual vs1 10.0.0.101
3. Create an HTTP port on the virtual server.
Virtual ADX(config-vs-vs1)#port http
4. Bind the real port on the real server to the HTTP port on the virtual server.
Virtual ADX(config-vs-vs1)#bind http rs1 http
5. Repeat the steps 2 through 4 for each additional virtual server.
Virtual ADX(config)#server virtual vs2 10.0.0.102
Virtual ADX(config-vs-vs2)#port http
Virtual ADX(config-vs-vs2)#bind http rs1 http
.
Configuration rules
Although both direct binding of multiple ports and port binding of multiple ports via port aliases are
supported by the Brocade Virtual ADX, the two configurations cannot co-exist for the same real port
or virtual port.
A real server port cannot be bound to a virtual port if any of the following conditions are met:
• The real port is already bound to another virtual port as an alias port.
• The virtual port has been bound to an alias port.
• The virtual port is configured for stateless or stateless fragmentation support. For more
information, see “Fragmentation support in the stateless mode” on page 157.
• The virtual port is configured for persistent hashing. For more information, see “Enabling
persistent hashing” on page 87.
When a real port is bound to multiple virtual ports, the following configurations are not allowed:
•
•
•
•
70
A virtual port with a multiple port binding cannot be bound as an alias port.
The real port cannot be bound as an alias port or use another port as an alias port.
The virtual port cannot be configured for stateless or stateless fragmentation support.
The virtual port cannot be configured for persistent hashing.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Multiple port binding
2
NOTE
The default port (a port the Brocade Virtual ADX automatically configures on all real and virtual
servers) and the source IP application port do not support multiple port binding.
Specifying the number of multiple port bindings available
Direct binding of multiple ports is enabled by default with the default value for the number of
bindings allowed as determined by the license that is active on your system. Use the system-max
l4-multi-binding command to change the number of multiple port bindings available or disable
multiple port binding.
Syntax: system-max l4-multi-binding new_max
The new_max variable identifies the number of multiple port bindings that can be created. The
minimum, maximum and default values are determined by the license that is active on your
system. For actual values associated with your license, refer to the Brocade Virtual ADX Licensing
Guide. If the new_max value is set to 0, support for multiple port binding is disabled.
Whenever you specify the number of multiple port bindings, you must restart the system if you
change the new_max value to a different non-zero value. If reloading the system is not an option,
you must remove all additional multiple port bindings before changing the new_max value.
The show server resource command displays the number of multiple port bindings, as shown in the
following example.
Virtual ADX#show server resource
Server resource usage:
Current
Maximum
l4-real-server
2
256
l4-virtual-server
2
32
l4-server-port
8
2048
l4-multi-binding
1
8192
The number of configured server ports and configured multiple port bindings can be captured by
an SNMP trap when a certain threshold is reached.
In the output of the show server bind command, each additional binding is displayed with a + sign
appended to it.
Virtual ADX#show server bind
Bind info
Virtual server: vs1
Status: enabled
http -------> rs1: 10.1.2.1, http (Active)
rs2: 10.1.2.2, http (Active)
Virtual server: vs2
Status: enabled
http -------> + rs1: 10.1.2.1, http (Active)
+ rs2: 10.1.2.2, http (Active)
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
IP: 10.1.2.100
IP: 10.1.2.101
71
2
Multiple port binding
Port aliases
When you associate a virtual port (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".
In most configurations, only one VIP-to-real-server binding is made for a TCP or UDP port. For
example, if you bind VIP 10.29.2.2 to real server 10.0.0.1 for port 80 (the well-known HTTP port),
you do not generally create any other bindings between VIP 10.29.2.2 and real server 10.0.0.1 for
the same port. However, should you wish to track statistics for multiple applications or domain
names mapped to the same real server port, you can do so by creating multiple port bindings.
One method of binding a single real server port to multiple VIPs is to configure a port alias for each
additional VIP. For example, if you want to associate three VIPs with the same real server, you can
define two TCP or UDP port aliases, one for each of the additional VIPs.
In such a configuration, the Brocade Virtual ADX collects and displays statistics and configuration
information individually for each VIP, but sends all traffic to the same TCP or UDP port number on
the real server.
Binding same real ports to multiple VIP ports
Multiple port binding enables a real server port to be bound to multiple VIP ports, which is useful
when you want to bind multiple VIPs to a single application service on real servers, and the real
servers are listening on different ports.
NOTE
This command is backward-compatible with the real-port command.
To bind multiple ports to one real server port, follow these steps.
1. Create a real server with two ports.
Virtual ADX(config)#server real rs1
Virtual ADX(config-rs-rs1)#port 81
Virtual ADX(config-rs-rs1)#port 8081 <- alias port
2. Create a second real server with two ports.
Virtual ADX(config)#server real rs2
Virtual ADX(config-rs-rs2)#port 82
Virtual ADX(config-rs-rs2)#port 8082 <- alias port
3. Create a virtual server.
Virtual ADX(config)#server virtual-name-or-ip vs1
4. Configure an HTTP port on the virtual server.
Virtual ADX(config-vs-vs1)#port http
5. Bind the alias ports to the real servers on the virtual servers.
Virtual ADX(config-vs-vs1)#bind http rs1 81 rs2 82
6. Create a second virtual server with an HTTP port.
Virtual ADX(config)#server virtual-name-or-ip vs2
Virtual ADX(config-vs-vs2)#port http
72
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Multiple port binding
7.
2
Bind the alias ports to the real servers on the virtual servers.
Virtual ADX(config-vs-vs2)#bind http rs1 8081 real-port 81 rs2 8082 real-port
82
Syntax: bind virtual-port real-server-name alias-port [real-port real-port-num]
NOTE
Alias ports should be treated like regular ports and should have the same server ID and group ID.
Binding a real server port to multiple VIPs for port translation
You can bind a real server port to multiple VIP ports with or without port translation. Port
translation is useful in cases where different client groups require different VIPs.
The real-port option has been added to the existing port virtual subcommand.
Syntax: [no] port tcp/udp-port real-port real-server-port-to-use
NOTE
This feature takes precedence over the no port port translate virtual subcommand.
In the following examples, notice that alias port 8081 is defined for binding between the real server
and virtual server. The alias port and the real-port work together.
To bind one real server port to multiple VIPs (vs1 and vs2), enter commands such as the following.
server real rs
port 8080
port 8080 l4-check-only
port 8081 <---- alias port
port 8081 l4-check-only
server virtual-name-or-ip vs1
port http
bind http rs 8080
server virtual-name-or-ip vs2
port http
port http real-port 8080
<---- use real port 8080 to do port translation
bind http rs 8081
<--- bind to alias port
To bind one real server port to multiple virtual ports of one VIP, enter commands such as the
following.
.
.
server real rs
port 8080
port 8080 l4-check-only
port 8081 <---- alias port
port 8081 l4-check-only
server virtual-name-or-ip vs
port http
bind http rs 8080
port 81
port 81 real-port 8080
<---- use real port 8080 to do port translation
bind 81 rs 8081
<---- bind to alias port
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
73
2
Multiple port binding
Configuration rules
Use the following rules when configuring the Brocade Virtual ADX to bind more than one virtual
server to the same real server using the same application port:
• You must configure both the real port and the alias port on the real servers. For example, if you
need to create alias port 180 so that you can bind two virtual servers to the same real server
and application port (80) on a real server, you must configure port 80 and port 180 on the real
server. Otherwise, you will not be able to completely bind all the virtual servers to the real
server. In the example below, the following real server configurations are incomplete because
neither of the real servers has both the untranslated and alias ports configured.
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server real-name r1 10.0.1.5
ADX(config-rs-r1)#port http
ADX(config-rs-r1)#exit
ADX(config)#server real-name r2 10.0.2.200
ADX(config-rs-r2)#port 180
ADX(config-rs-r2)#exit
• You cannot bind to both the untranslated port and the alias port in the same bind statement. In
the example below, the following bind statement is invalid.
Virtual ADX(config-vs-VIP1)#port http
Virtual ADX(config-vs-VIP1)#bind http r1 http r2 180
Here is a more detailed explanation.
When you configure SLB, one of the tasks you perform is to bind the TCP or UDP application ports
on the virtual server to their counterparts on the real server. For example, if clients will be sending
requests to port 80 (HTTP) on virtual server www.example8.com, but your real servers expect the
HTTP connections to arrive on port 8080 of real server R1, you must bind port 80 on the virtual
server to port 8080 on the real server.
One of the requirements is that a real server can be bound to only one virtual server using the
same TCP or UDP application port. As a result, when you bind a real server port to a virtual server
port, you cannot then bind the same real server port to a different virtual server port.
Normally, the Brocade Virtual ADX translates the IP address and application port of the virtual
server requested by the client into the real server IP address and application port that you bind to
the virtual server. However, when you disable port translation, the Brocade Virtual ADX does not
perform the translation for the application port. Instead, the Brocade Virtual ADX translates the
destination IP address in the client’s request to the IP address of a real server, but leaves the
application port in the client’s request untranslated.
74
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Multiple port binding
2
Configuration example
To implement the configuration described above, enter commands such as the following.
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server real-name r1 10.0.1.5
ADX(config-rs-r1)#port http
ADX(config-rs-r1)#port 180
ADX(config-rs-r1)#exit
ADX(config)#server real-name r2 10.0.2.200
ADX(config-rs-r2)#port http
ADX(config-rs-r2)#port 180
ADX(config-rs-r2)#exit
ADX(config)#server virtual-name-or-ip VIP1 10.157.22.88
ADX(config-vs-VIP1)#port http
ADX(config-vs-VIP1)#bind http r1 http r2 http
ADX(config-vs-VIP1)#exit
ADX(config)#server virtual-name-or-ip VIP2 10.157.22.99
ADX(config-vs-VIP2)#port http
ADX(config-vs-VIP2)#no port http translate
ADX(config-vs-VIP2)#bind http r1 180 r2 180
The well-known port (80) is used for VIP1, but an alias (180) is used for VIP2. The real servers
actually use port 80 for traffic to both virtual IP addresses. However, the alias port enables the ISP
to distinguish among the two IP addresses and their traffic when they display SLB information on
the Brocade Virtual ADX. The no port http translate command is required. This command enables
the Brocade Virtual ADX to send traffic from multiple VIPs to the same real TCP/UDP port on the
real server (in this example, “http” (port 80)). If you leave this command out, the Brocade Virtual
ADX does not use port 180 as an alias but instead sends the VIP traffic to TCP/UDP port 180 on
the real server rather than 80.
NOTE
Because the untranslated port is logically bound to the translated port and both ports are bound to
the same port on the real server, state information for the untranslated port is based on the
translated port’s state. In this example, state information for port 180 is based on the state for port
80. The state is shown in the Ms (Master port state) field of the display produced by the show server
real command. Refer to “Displaying real server information and statistics” on page 371.
NOTE
You can configure the Brocade Virtual ADX to perform health checks on each VIP independently.
Refer to “Health check of multiple websites on the same real server” on page 224.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
75
2
Multiple port binding
To display statistics for the separate real IP addresses, enter the following command at any
command prompt.
Virtual ADX(config)#show server real
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
HLD:held-down
Name: r1
State: Active
Cost: 0 IP:10.95.7.1:1
Mac: 0000.855d.e2cd
Weight: 1/1
MaxConn: n/a
Src-nat (cfg:op) = 0: 0 Dest-nat-(cfg:op) = 0: 0
Port St
Ms CurConn TotConns
Rx-pkts
Tx-pkts
Rx-octet Tx-octet Reas
180
ENB
2
0
0
0
0
0
0 0
http ENB
0
0
0
0
0
0
0 0
Keepalive: Disabled, status code(s) default (200-299, 401)
HTTP URL: "HEAD /"
defaulunbnd
0
0
0
0
0
0
0 0
Server
Total
Name: r2
Src-nat (cfg:op) =
0
0
0
IP: 10.0.2.200
:
0: 0 Dest-nat-(cfg:op) =
0
1 State: 3
0: 0
0
Wt: 1
0
0
Max-conn: n/a
Port St
Ms CurConn TotConns
Rx-pkts
Tx-pkts
Rx-octet Tx-octet Reas
http ENB
2
0
0
0
0
0
0 0
Keepalive: Disabled, status code(s) default (200-299, 401)
HTTP URL: "HEAD /"
defaul UNB 0
0
0
0
0
0
0 0
Server Total
0
0
0
0
0
0 0
The lines highlighted in bold indicate the separate HTTP port numbers. The two HTTP lines for real
server 1 (r1) indicate that an alias is in use. The first line lists the alias port number, and the
second line lists the actual port number used by the real server. Even though the same port
number is used on the real server, the Brocade Virtual ADX display distinguishes the traffic for the
two virtual IP addresses.
NOTE
The state of the alias HTTP port is always the same as the state of the actual HTTP port used in the
packets the Brocade Virtual ADX sends to the real server. The state is shown in the Ms (Master port
state) column in the show server real display. Refer to“Displaying real server information and
statistics” on page 371.
Performing SLB based on alias port state
To perform SLB based on an alias port state, enter commands such as the following.
Virtual
Virtual
Virtual
Virtual
ADX(config)#server virtual-name-or-ip v1 10.10.1.151
ADX(config-vs-v1)#port 8080
ADX(config-vs-v1)#no port 8080 translate
ADX(config-vs-v1)#port 8080 use-alias-port-state
Syntax: [no] port number use-alias-port-state
76
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Real server groups
2
Assume a configuration having two VIPs on the same real server with different health checks for
each VIP using no port translate. If the real server health check fails for the first VIP (bound to
master port), traffic is not sent to the second VIP (bound to alias port). The client will receive a RST.
When port use-alias-port-state is enabled, traffic to a VIP on the alias port will be forwarded if the
health of the alias port passes. This feature is useful in scenarios where master port health and
alias port health are using different URLs for health check.
Enabling the Brocade Virtual ADX to use the alias port’s state
In a configuration with two VIPs bound to the same server port, where the VIPs are hosting multiple
Web sites on the same server (different VIPs point to different sites), an alias port is required. In
this scenario, if the master port goes down, the Brocade Virtual ADX stops forwarding traffic to the
other sites as well, even though these sites are up. This behavior occurs because the Brocade
Virtual ADX uses the master port’s state for traffic forwarding decisions. To resolve this issue, you
must enable the Brocade Virtual ADX to use the alias port’s state for traffic forwarding decisions.
So, if the alias port’s state is up, the Brocade Virtual ADX continues to forward traffic. Likewise, if
the alias port’s state is down, the Brocade Virtual ADX stops forwarding traffic to the server.
To enable the Brocade Virtual ADX to use the alias port’s state for traffic forwarding decisions,
enter the following command.
Virtual ADX(config-vs-v2))#port http use-alias-port-state
Syntax: port tcp/udp port use-alias-port-state
In the next example, if site test1 goes down, the Brocade Virtual ADX would stop forwarding traffic
to VIP2 as well. In this scenario, you would enable the port http use-alias-port-state command so
that traffic to VIP2 does not stop when site test1 goes down.
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server real r1 10.10.1.31
ADX(config-rs-r1)#port http
ADX(config-rs-r1)#port http url "test1.html"
ADX(config-rs-r1)#port 8080
ADX(config-rs-r1)#port 8080 url "test2.html"
ADX(config-rs-r1)#server virt VIP1 10.10.1.121
ADX(config-vs-v1)#port http
ADX(config-vs-v1)#bind http r1 http
ADX(config-vs-v1)#server virt VIP2 10.10.1.122
ADX(config-vs-v2)#port http
ADX(config-vs-v2)#bind http r1 8080
ADX(config-vs-v2)#no port http translate
Real server groups
A real server group is a container of multiple real servers that you can use to simplify and reduce
the size of your load balancing configurations.
For large scale configurations you'll want to use real server groups to avoid reaching the 1.4MB
configuration file size limit set by the Brocade Virtual ADX.
Using real server groups you can reduce the size and complexity of load balancing configurations
by associating multiple real servers with a single real server group and then binding that group to a
virtual server. Brocade Virtual ADX automatically binds all of the real servers associated with the
real server group to the bound virtual server.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
77
2
Real server groups
Real server group configuration is a three-step process:
• First, you must define the real server group.
• Once defined, you can associate one or more real servers with that real server group. Up to
four real servers can be associated with a real server group in a single command.
• You can then bind the real server group to a virtual server.
Although a real server can be associated with one-and-only-one real server group, each real server
group can be bound to multiple virtual servers.
Defining a real server group
To define a real server group use the server group-real command.
Virtual ADX(config)#server group-real sg1
Syntax: [no] server group-real real-server-group-name
The real-server-group-name variable identifies the name of the real server group.
The no option enables you to delete a real server group. If you delete a real server group that has
been bound to a virtual server, the Brocade Virtual ADX automatically unbinds all of the real
servers associated with that real server group. The real servers themselves are not deleted and
remain intact in the configuration.
Associating a real server with a real server group
Use the real-server command to associate one or more real servers with a real server group.
Each real server can be associated with one-and-only-one real server group. If you associate a real
server with a real server group that is already bound to a virtual server, the Brocade Virtual ADX
automatically binds the newly associated real server to the virtual server.
To associate up to four real servers with a real server group, enter a command such as the
following:
Virtual ADX(config-rsg-sg1)#real-server rs1 rs2 rs3 rs4
Syntax: [no] real-server real-server-names
The real-server-names variable specifies the real servers associated with a real server group.
The no option enables you to disassociate a real server from a real server group. If you disassociate
a real server from a real server group bound to a virtual server, the Brocade Virtual ADX
automatically unbinds the real server. Only those real server bindings that were particular to the
real server group are removed.
78
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Disabling or deleting VIPs and real ports
2
Binding a real server group to a virtual server
Use the bind group-real command to bind a real server group to a virtual server.
Virtual ADX(config)#server virtual name-or-ip v1
Virtual ADX(config-vs-v1)#bind http group-real sg1 http
A real server group can be bound to multiple virtual servers.
Syntax: [no] bind virtual-server-port group-real real-server-group-name real-server-port
The virtual-server-port variable identifies the virtual server port to be bound to the real server
group. The real-server-group-name variable specifies the name of the real server group to which
the virtual server is bound. The real-server-port variable specifies the real server port.
NOTE
Do not bind an empty real server group to a virtual server. You must associate at least one real server
with a real server group before you bind that real server group with a virtual server otherwise the
Brocade Virtual ADX issues an error.
Showing real server groups
Use the show server group-real command to view real server groups.
To view the real servers or virtual servers bound to a real server group, enter commands such as
the following:
Virtual ADX(config)#show server group-real sg1
Real server group: sg1
rs2 rs3 rs4 rs5
Syntax: show server group-real real-server-group-name
The real-server-group-name variable identifies the name of the real server group.
Disabling or deleting VIPs and real ports
Disabling VIPs
You can globally or individually disable VIPs.
To globally disable all virtual servers, enter the following command.
Virtual ADX(config)#server disable-vip
Use the no server disable-vip command to globally re-enable virtual servers after disabling them.
Syntax: [no] server disable-vip
To disable an individual virtual server, enter commands such as the following.
Virtual ADX(config)#server virtual-name-or-ip www.foo.com
Virtual ADX(config-vs-www.foo.com)#disable
Use the no disable command to re-enable a virtual server.
Syntax: [no] disable
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
79
2
Disabling or deleting VIPs and real ports
Disabling a real server
Under the real server config level, you can disable a real server. Disabling a real server also
disables all the existing real server ports. The real server state will become “disabled”, and no new
connections will be assigned to a disabled real server. However, all the existing connections will
remain. No health check will be done for a disabled real server.
To disable a real server, enter commands such as the following.
Virtual ADX(config)#server real rs1 10.1.1.1
Virtual ADX(config-rs-rs1)#disable
Syntax: [no] disable
Disabling or re-enabling an application port
Application ports are enabled by default. To disable an application port on a virtual server, enter
commands such as the following.
Virtual ADX(config)#server virtual-name-or-ip Zoot_Allures 10.2.3.4
Virtual ADX(config-vs-Zoot_Allures)#port http disable
Syntax: [no] port tcp/udp-port disable
To re-enable a port, enter commands such as the following.
Virtual ADX(config)#server virtual-name-or-ip Zoot_Allures 10.2.3.4
Virtual ADX(config-vs-Zoot_Allures)#no port http disable
Globally disabling real and virtual ports
You can globally disable a Layer 4 port on the Brocade Virtual ADX. The port can be disabled for all
real servers, all virtual servers or all real and virtual servers. After you disable a port globally, you
can enable the port on individual real or virtual servers as necessary. By default, all real and virtual
ports are enabled.
When the Brocade Virtual ADX is booted, if the command to globally disable a real or virtual port
exists in the startup-config file, the specified port is disabled at startup. When a real or virtual port
is created, and the port has been disabled globally, the real or virtual port is disabled as well. You
must enable the port explicitly.
To disable all real HTTP ports, enter commands such as the following.
Virtual ADX(config)#server port 80
Virtual ADX(config-port-http)#disable real
Virtual ADX(config-port-http)#
To disable all virtual HTTP ports, enter commands such as the following.
Virtual ADX(config)#server port 80
Virtual ADX(config-port-http)#disable virtual
Virtual ADX(config-port-http)#
To disable all real and virtual HTTP ports, enter commands such as the following.
Virtual ADX(config)#server port 80
Virtual ADX(config-port-http)#disable
Virtual ADX(config-port-http)#
Syntax: disable [real | virtual]
80
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Disabling or deleting VIPs and real ports
2
Deleting a VIP
It is critical that you follow the steps below before deleting a VIP that is in production or is handling
live traffic.
1.
Disable the real server ports that are associated with this virtual server port.
Syntax: [no] server real real-server-name
Syntax: [no] port port disable
2. Keep checking the current connection count against the real server until the connection count
falls to zero.
Syntax: show server real real-server-name
3. If the current connection value does not drop to zero after some time has passed, then unbind
the real server port from under the VIP.
Syntax: no bind virtual-port real-server-name real-server-port
4. Double check to make sure that real server is unbound from the virtual server.
Syntax: show server bind
If the real server is not unbound properly, then check the connection count under the BP
console and try clearing the server sessions.
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX#rconsole 1 1
ADX1/1#show server real rs1
ADX1/1#rconsole-exit
ADX#rconsole 1 2
ADX1/2#show server real rs1
ADX1/1#rconsole-exit
ADX#rconsole 1 3
ADX1/3#show server real rs1
ADX1/1#rconsole-exit
Syntax: rconsole slot# BP#
Syntax: show server real real-server-name
Syntax: rconsole-exit
If there are existing connections or the port is still in AWU or AWM state, then clear the server
sessions using following command.
Syntax: clear server all-session real-server-name real-port
5. After the connection count drops to zero or the unbinding is successful, delete the VIP.
Syntax: no server virtual virtual-server-name
6. If real servers are not required, then delete those also.
Syntax: no server real real-server-name
If any current connection or current session cannot be disabled and the port is in "AWU" or "AWM",
then issue a clear server all-session command.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
81
2
Disabling or deleting VIPs and real ports
Enabling force-delete
SLB allows the graceful shutdown of servers and services. By default, when a service is disabled or
deleted, the Brocade Virtual ADX does not send new connections to the real servers for that
service. However, the Brocade Virtual ADX does allow existing connections to complete normally,
however long that takes.
You can force the existing SLB connections to be terminated within two minutes, by using the server
force-delete command.
If you disable or delete a service, do not enter an additional command to reverse the command you
used to disable or delete the service, while the server is in graceful shutdown.
NOTE
Refer to “Real server shutdown” on page 83 for important information about shutting down services
or servers.
Suppose you have unbound the Telnet service on real server 15, but you do not want to wait until
the service comes down naturally. You can force server load-balancing connections to be
terminated by entering the following command.
Virtual ADX(config)#server force-delete
Syntax: server force-delete
To display active sessions for a specific server, enter show server real server number and a display
as seen below will appear. Notice that the display below shows the Telnet connection on server 15
as awaiting unbinding. Without server force-delete, this feature will stay in this state until the
session ends naturally.
Because the binding is awaiting deletion, it will also still be seen as an active binding, if you enter
the show server bind command, such as the following.
Virtual ADX(config-vs-building)#show server bind
Virtual Server Name: building,
IP: 10.95.5.130
http -------> s21: 10.95.18.21, http
s15: 10.95.18.15, http
s50: 10.95.18.50, http
ftp -------> s50: 10.95.18.50, ftp
s21: 10.95.18.21, ftp
s15: 10.95.18.15, ftp
telnet -------> s15: 10.95.18.15, telnet
s21: 10.95.18.21, telnet
s50: 10.95.18.50, telnet
After force delete is enabled, the unbinding will occur within two minutes.
NOTE
The binding for the real server will also be eliminated from the show server bind display.
82
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Disabling or deleting VIPs and real ports
2
Real server shutdown
The force shutdown feature (sometimes called the force delete feature) allows you to force
termination of existing SLB connections. This feature assumes that you already have shut down a
TCP/UDP service on the real server, or you have shut down the real server itself.
There are several methods for shutting down a service or server. Each method has consequences,
so choose the method that works best in your situation. The methods are as follows:
• Edit the real server configuration on the Brocade Virtual ADX to disable the TCP/UDP ports on
the server. For example, to disable port 80 (HTTP), you can use the port http disable command
at the real server level of the CLI. If you use this method, you do not need to re-define the real
server to add the server back to SLB. However, you do need to re-enable the disabled TCP/UDP
ports.
• Delete the real server from the Brocade Virtual ADX. This option immediately prevents new
connections. To safely delete the real server from the Brocade Virtual ADX, we recommend the
following procedure.
1. Under the real server, disable the application ports.
2. Check to ensure the current connections and session comes down to zero (in show server
real output).
3. Under VIP, unbind the real server.
4. Delete the real server.
The Brocade Virtual ADX allows existing connections to end normally or, if you have enabled
the force shutdown option, the Brocade Virtual ADX ends all connections within two minutes. If
you use this method and later want to re-add the real server to the Brocade Virtual ADX, you
must redefine the real server, then rebind the real server to the appropriate VIP.
• Shut down the real server itself, rather than change definitions on the Brocade Virtual ADX.
When the real server stops responding to health checks, the Brocade Virtual ADX removes the
server from the SLB. This option is simple because it does not require any configuration
changes on the Brocade Virtual ADX. However, this option immediately disconnects all users,
whereas the above options allow the server or service to gracefully shut down (unless you use
the force shutdown option).
Port holddown timer
When a real server port fails, a Brocade Virtual ADX stops sending any new connections to the port.
Configuring the server force-delete command ensures that existing sessions are terminated within
two minutes. If a real server port fails and recovers before the force-delete operation has
completed, stale sessions can potentially cause problems for clients seeking access to the real
servers.
Enabling the port holddown timer disallows a failed port from being marked active until all idle
sessions have timed out. Thus, when a real port fails and recovers before a configurable timeout
(default 2 minutes) has elapsed the port is not allowed to move to the active state and is held in a
special helddown state. This is a pseudo-state while the port transitions from active to failed and
then to testing. If the subsequent health check is successful, the port is marked as active.
If all the ports bound to a VIP are in the helddown state, the VIP would still be in the inactive state.
The behavior of VIP health does not change. Where VIP health is concerned, a real port in the
helddown state is equivalent to a real port in the failed state.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
83
2
Disabling or deleting VIPs and real ports
Table 9 describes the behavior of the Brocade Virtual ADX for a specified action when it is
configured with the server force-delete command, with a port hold-down timer configured and in a
normal scenario without either configured.
TABLE 9
Behavior with server force-delete command
Action
Normal Scenario
With Force-Delete
With Port Hold-down
Delete Real Server
Sessions deleted within 2
minutes.
Sessions deleted
within 2 minutes.
If real server is re-added, it is
treated as a new server addition
and port isn’t held down.
Unbind Port
Sessions deleted within 2
minutes.
Sessions deleted
within 2 minutes.
If re-bound, the port is not held
down.
Disable Real Server
Port
Existing sessions continue to
exist through their lifetime.
Sessions deleted
within 2 minutes.
If enabled quickly (within the
timeout) the port is held down.
Real Port Fails
Existing sessions continue to
exist through their lifetime.
Sessions deleted
within 2 minutes.
If the port comes up quickly, the
port is held down.
Behavior with flapping ports
If a port keeps flapping within the configured port holddown timeout period, the port is held down
until the port stops flapping for the configured timeout. In practice this means that the port must
be available for a time interval greater than the configured timeout period for it to come back up.
NOTE
If a port that was disabled when the holddown timer is started is enabled within the timeout period,
the port is held down until the timeout period has passed.
The port hold down timer can be configured globally, per real server port and per port-profile.
Changing the default port holddown timer value
The default holddown timeout is 2 minutes. The following command allows you to configure this
global timeout value or reset the timeout to the default.
Virtual ADX(config)#server port-holddown-timeout 240
Syntax: [no] server port-holddown-timeout timeout-value
The timeout-value variable specifies the length of the port holddown timer in seconds. Acceptable
values are 1 second to 86400 seconds (1 day). The default value is 120 seconds (2 minutes).
The value set by this command applies to all port holddown configurations.
Enabling the port holddown timer globally
You can configure the port holddown timer globally to enable port hold down for all ports on all real
servers. This setting overrides any configurations for individual ports.
Virtual ADX(config)#server port-holddown
Syntax: [no] server port-holddown
84
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
2
Disabling or deleting VIPs and real ports
Enabling the port hold down timer for an individual real server port
You can configure the port hold down timer to enable port holddown for an individual port within a
real server configuration.
Virtual ADX(config)#server real rs1
Virtual ADX(config-real-rs1)#port http holddown
Syntax: [no] port port-type holddown
The port-type variable specifies the port that you want to apply the holddown timer to.
Enabling the port holddown timer for a port profile
You can configure the port hold down timer to enable port holddown for all ports within a server
port profile.
Virtual ADX(config)#server port http
Virtual ADX(config-port-http)#holddown
Syntax: [no] holddown
Displaying port holddown
The show server real and show server real detail commands provide information about the current
state and duration of port holddown.
In the following example, the show server real command displays the state of the “http” port as
“HLD”.
Virtual ADX(config)#show server real rs1
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,
HLD:held-down
Name: rs1
State: Active
Cost: 0 IP:192.168.3.1:
1
Mac: 000c.29b6.64de
Weight: 1/1
MaxConn: n/a
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 = 0:0
BP max local conn configured No: 0 0 0 0 0 0
BP max conn percentage configured No: 0 0 0 0 0 0
Use local conn : No
Port
---default
http
St
-UNB
HLD
Ms
-0
0
CurConn
------0
0
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
TotConn
------0
0
Rx-pkts
------0
0
Tx-pkts
------0
0
Rx-octet
-------0
0
Tx-octet
-------0
0
Reas
---0
0
85
2
Hash-based SLB with server persistence
The time remaining for the holddown state is displayed by the show server real detail command as
shown in the following.
Virtual ADX(config)#show server real rs1 det
http
HLD 0 0
0
0
0
0
0
0
max_conn =
10
fail time =
0, Vir IP 192.168.1.2
tcp conn rate:udp conn rate = 0:0, max tcp conn rate:max udp conn rate =
0:0
BP max local conn configured No: 0 0 0 0 0 0
BP max conn percentage configured No: 0 0 0 0 0 0
Use local conn : No
resp_time =
7
Keepalive(G/L:Off/On):On
Status Code(s): default (200-299, 401)
HTTP URL: "HEAD /"
tcp-age: 30
Hold-down time remaining: 25 second(s)
dns
ACT 0 0
39
39
45
10151
3972
0
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.
Command support is also provided to help you manage the introduction of a new server.
This feature 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.
By default, SLB uses stateful load balancing for Virtual IP addresses (VIPs). In stateful load
balancing, the Brocade Virtual ADX creates session table entries for the connections between the
client and the destination (the real server). If multiple real servers are bound to a VIP, then
requests from the same client can be serviced by different real servers over a period of time.
However, for transaction-oriented systems, a client might need to be serviced by the same real
server each time the client makes a request, regardless of the length of time between each request
made.
Using the sticky feature, the current maximum persistence possible for Stateful SLB is 20 hours.
This setting might 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.
Persistent hash table
Each virtual server port maintains a persistent hash table consisting of 256 entries. When the
Brocade Virtual ADX boots up, all the hash entries in the table are empty (no real server
assignments to any of the entries). When a client makes a request to the VIP, the Brocade Virtual
ADX calculates a hash value based on the client IP. The hash will be a value between 0 and 255
and will map to one of the entries in the persistent hash table. The Brocade Virtual ADX then
retrieves the persistent hash table entry for the calculated hash value. If there is no real server
allocated for the table entry, the Brocade Virtual ADX selects a real server for that table entry using
the configured SLB predictor. The system will then assign the real server to the table entry, and the
client request will be serviced by the real server.
86
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Hash-based SLB with server persistence
2
If the client makes another request to the VIP, for example after two days, then the Brocade Virtual
ADX will again calculate the hash based on the client IP and retrieve the persistent hash table
entry. Because a real server has already been allocated to the persistent hash table entry, the
Brocade Virtual ADX will use this real server to service the client request. As an effect, the client will
always be directed to the same real server.
Clear vs reassign mechanisms
There are two configurable mechanisms to handle the introduction of a new server:
• clear-on-change — Whenever a new server comes up, the entire persistent hash table is
cleared and assignments are started afresh. For more information, refer to “Enabling the
clear-on-change mechanism” on page 87.
• reassign-on-change — The default. Whenever a new server comes up, the Brocade Virtual ADX
calculates the number of hash entries allocated to each existing server. The Brocade Virtual
ADX then reassigns some of these entries to the new server. For more information, refer to
“Enabling the reassign-on-change mechanism” on page 88.
Enabling persistent hashing
To enable the persistent hashing (phash) mechanism for a virtual server port, enter commands
such as the following.
Virtual ADX(config)#server virtual-name-or-ip vs1
Virtual ADX(config-vs-vs1)#port http persist-hash
The reassign-on-change function is selected by default.
Syntax: [no] port port persist-hash [clear-on-change | reassign-on-change]
When persistent hashing is configured for a VIP, the round robin predictor for the VIP is
automatically enabled. This default is used to evenly distribute hash assignments. After you enter
the port port persist-hash command, the predictor round-robin command automatically appears
under the virtual server in the configuration file.
NOTE
SSL is a special case where sticky automatically gets turned on. If persistent hashing must be
configured for port SSL, you need to explicitly turn off sticky on the SSL port using the no port ssl
sticky command and then enable persistent hashing for this port.
Enabling the clear-on-change mechanism
To enable the clear-on-change mechanism, enter commands such as the following.
Virtual ADX(config)#server virtual-name-or-ip vs1
Virtual ADX(config-vs-vs1)#port http persist-hash clear-on-change
Virtual ADX(config-vs-vs1)#end
When the clear-on-change command is set for persistent hashing, the entire persistent hash table
is cleared whenever a new server comes up. For example, is shown in the following figure.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
87
2
Hash-based SLB with server persistence
Figure 14 shows the persistent hash table for a virtual server port before the rs3 comes up.
FIGURE 14
Hash table before rs3 comes up
Persistent Hash table
virtual server vs1
port http
Hash 0
none
Hash 1
rs2
Hash 2
rs2
Hash 3
rs1
Hash 4
rs1
Hash 5
rs2
Hash 6
..............
rs1
Hash 255
none
Assume the administrator now binds port HTTP of a new real server rs3 to port HTTP of virtual
server vs1. When real server rs3 comes up, the entire persistent hash table is cleared.
Figure 15 shows the persistent hash table for a virtual server port after the rs3 comes up.
FIGURE 15
Hash table after rs3 comes up
Persistent Hash table
virtual server vs1
port http
Hash 0
none
Hash 1
none
Hash 2
none
Hash 3
none
Hash 4
none
none
Hash 5
Hash 6
..............
none
Hash 255
none
Enabling the reassign-on-change mechanism
To enable the reassign-on-change mechanism, enter commands such as the following.
Virtual ADX(config)#server virtual-name-or-ip vs1
Virtual ADX(config-vs-vs1#port http persist-hash reassign-on-change
When reassign-on-change is enabled (the default), the Brocade Virtual ADX reassigns some of the
existing hash table entries on the introduction of a new server.
88
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Hash-based SLB with server persistence
2
Configuring the reassign threshold and duration
There are two configurable global parameters related to the reassign mechanism:
• Reassign threshold — When the number of empty hash entries (buckets) in the persistent hash
table falls to or below this threshold (less than or equal to), the Brocade Virtual ADX reassigns
some of the persistent hash entries on introduction of a new real server. By default, the
Brocade Virtual ADX reassigns persistent hash entries to the new real server only if there are
no empty persistent hash entries (for example, the default persist hash reassign threshold is 0
percent).
To specify the threshold, enter a command such as the following.
Virtual ADX(config)#server persist-hash-threshold 5
Syntax: [no] server persist-hash-threshold percent-value
The percent-value variable can be any value from 0 through 99.
With the reassign mechanism, if multiple servers come up simultaneously and need
reassignment because the number of empty hash table entries is below the reassign
threshold, then the Brocade Virtual ADX will clear the persistent hashing table.
• Reassign duration — If the number of empty persistent hash entries is below the reassign
threshold, the Brocade Virtual ADX reassigns some of the persistent hash entries over a period
of time to the new real server. This duration of time is known as the persist hash reassign
duration.
To specify the reassign duration, enter a command such as the following.
Virtual ADX(config)#server persist-hash-reassign-duration 5
This global command is applied to all configured VIP ports that are persist-hash enabled. The
Brocade Virtual ADX will complete the reassignment within 2 minutes by default.
Syntax: [no] server persist-hash-reassign-duration value
The value variable can be a time duration from 2 to 30 minutes.
Reassignment sequence and example
The sequence is performed as follows.
1. When a new server is introduced, the Brocade Virtual ADX calculates how many of the hash
table entries in the persistent hash table are empty. If the number is greater than the
persist-hash-reassign-threshold, the Brocade Virtual ADX does no reassignment.
If the number of empty hash table entries is less than or equal to the persist hash reassign
threshold, the Brocade Virtual ADX proceeds with the reassignment. The system first
calculates the total number of active real servers, which includes the new real server.
2. The system calculates the entries per server as follows.
X = entries per server = total assigned hash table entries/number of active real servers
3. The Brocade Virtual ADX attempts to reassign X persistent hash entries to the new real server
over the duration specified by the persist-hash-reassign-duration.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
89
2
Hash-based SLB with server persistence
The Brocade Virtual ADX will stop reassigning persistent hash entries to the new real server when
either of the following occurs:
• The system has finished reassigning X persistent hash entries to the new real server (occurs in
the amount of time specified by the persist-hash-reassign-duration).
• The number of persistent hash entries assigned to the new real server is equal to the lowest
number of persistent hash entries assigned to any of the existing real servers, whichever
happens earlier.
Consider the following reassignment example. Figure 16 shows the hash table before
reassignment.
FIGURE 16
Hash table before reassignment
Persistent Hash table
virtual server vs1
port http
Hash 0
none
Hash 1
..............
none
Hash 47
rs1
Hash 48
rs1
Hash 49
rs1
Hash 50
rs1
Hash 51
rs1
Hash 52
rs1
Hash 53
rs1
Hash 54
rs1
Hash 55
rs2
Hash 56
rs2
..............
Hash 255
none
Persistent hash entries have been assigned as follows. Entries 47 to 54 have been assigned to real
server rs1. Entries 55 and 56 have been assigned to rs2. All other entries are empty (no real server
has been assigned to them).
In this example, the administrator configures a reassign-threshold of 99 percent. That is, whenever
the number of empty hash entries falls below 99 percent, the Brocade Virtual ADX will reassign the
persistent hash table entries whenever a new real server comes up. The reassign-duration is the
default value (2 minutes).
Next, the administrator binds port HTTP of a new real server rs3 to port HTTP of virtual server vs1.
When real server rs3 comes up, the Brocade Virtual ADX calculates the number of active real
server ports. In this example, the number is 3 (rs1, rs2 and rs3). The system then calculates the
number of empty hash table entries. In this example, the number is 246. Because less than 99
percent of the hash table entries are empty, the Brocade Virtual ADX now attempts to reassign
some of the persistent hash entries to the new real server rs3.
The Brocade Virtual ADX then calculates entries per server X as follows.
X = total assigned hash table entries/number of active real servers = 10/3 = 3
90
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
2
Hash-based SLB with server persistence
The Brocade Virtual ADX now attempts to reassign 3 persistent hash entries to the new real server
over 2 minutes. The system will stop after it has reassigned 2 entries of real server rs1 to new real
server rs3. The reason is that when rs3 is assigned 2 persistent hash entries, the value is equal to
the number of entries assigned to existing real server rs2.
Figure 17 shows the persistent hash table after the reassignment.
FIGURE 17
Hash table after reassignment
Persistent Hash table
virtual server vs1
port http
Hash 0
none
Hash 1
..............
none
Hash 47
rs3
Hash 48
rs3
Hash 49
rs1
Hash 50
rs1
Hash 51
rs1
Hash 52
rs1
Hash 53
rs1
Hash 54
rs1
Hash 55
rs2
Hash 56
rs2
..............
Hash 255
none
Keeping the persistent hash table unchanged
To configure the Brocade Virtual ADX not to clear the persistent hashing table when multiple
servers come up simultaneously and need reassignment, enter commands such as the following.
SLB-Virtual ADX(config)#server virtual-name-or-ip vs1
SLB-Virtual ADX(config-vs-vs1)#port http no-auto-clear-persist-hash-buckets
If this command is configured and multiple servers need reassignment simultaneously, then the
Brocade Virtual ADX will leave the persistent hash table unchanged.
Syntax: port port no-auto-clear-persist-hash-buckets
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
91
2
Hash-based SLB with server persistence
Real server failure
If a real server fails, the Brocade Virtual ADX will remove all assignments of the real server from all
persistent hash table entries in the persistent hash table.
For example, consider a virtual server vs1 whose port HTTP is bound to port HTTP of real server rs1
and rs2. Figure 18 shows the persistent hash table for vs1 for port HTTP before server failure.
FIGURE 18
Hash table before server failure
Persistent Hash table
virtual server vs1
port http
Hash 0
rs1
Hash 1
rs2
Hash 2
..............
rs1
Hash 255
none
Real server rs1 has been assigned to persistent hash table entries corresponding to hash value 0
and hash value 2. Real server rs2 has been assigned to the entry corresponding to hash value 1.
Now assume all other hash table entries have not been assigned to any real servers.
If port HTTP of real server rs1 fails, then the Brocade Virtual ADX will clear assignment of rs1 to the
persistent hash entries in the above table. Figure 19 shows the persistent hash table for vs1 for
port HTTP after server failure.
FIGURE 19
Hash table after server failure
Persistent Hash table
virtual server vs1
port http
Hash 0
Hash 1
none
rs2
Hash 2
..............
none
Hash 255
none
The Brocade Virtual ADX does not immediately assign a new server to the cleared hash table
entries. Instead, the Brocade Virtual ADX will select and assign a real server for these entries using
the SLB predictor the next time a client hashes to these hash table entries.
92
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
2
Hash-based SLB with server persistence
In the previous example, assume a client now makes an HTTP request for virtual server vs1.
Assume also the client’s IP address hashes to a value of 2. The Brocade Virtual ADX checks the
hash table entry corresponding to hash value 2 in the above persistent hash table. Because no real
server is associated with the hash entry, the Brocade Virtual ADX selects a new real server, such as
rs2, using the SLB predictor and then assigns the server to the hash table entry. This and
subsequent requests from the client will then be serviced by rs2. Figure 20 shows the new real
server rs2 to service request to the client.
FIGURE 20
Using rs2 to service requests
Persistent Hash table
virtual server vs1
port http
Hash 0
none
Hash 1
rs2
Hash 2
..............
rs2
Hash 255
none
Displaying persistent hash table entry and statistics
To display the persistent hash table entry and statistics for a virtual server, use rconsole to get into
the BP and enter the show server persist-hash-buckets command.
Virtual ADX#rconsole 1 1
Virtual ADX1/1#show server persist-hash-buckets http-vs
Virtual port Persist Hash Buckets:
Virtual Server <http-vs> Port <80>:
Bucket: Server
Hit
Bucket: Server
45: http-rs1
1
Virtual Server <http-vs> Port <53>:
Bucket: Server
Hit
Bucket: Server
45: dns-ns
2
Hit
Hit
Syntax: show server persist-hash-buckets virtual-server-name
If you do not specify a virtual server name, all the persistent hash tables for all virtual server ports
for all virtual servers will be displayed. Table 10 displays the output field description of show server
persist-hash-buckets command.
TABLE 10
Output field descriptions of show server persist-hash-buckets command
Field
Description
Virtual server
Name of the virtual server.
Port
Virtual server port.
Bucket
Hash value for hash table entry.
Server
Real server assigned to the hash table entry.
Hit
Number of times the client IP has hashed to this entry and been serviced
by the associated real server. It is possible for multiple clients to hash to
the same hash entry (bucket).
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
93
2
Hash-based SLB with server persistence
Clearing the hit count for the persistent hash table
To clear the hit count for the persistent hash table for a virtual server port, enter commands such
as the following.
Virtual ADX(config)#server virtual-name-or-ip http-vs
Virtual ADX(config-vs-http-vs)#port http clear-persist-hash-statistics
Virtual ADX(config-vs-http-vs)#end
Syntax: port port clear-persist-hash-statistics
Clearing the persistent hash table
To clear the persistent hash table (all assignments and hit counts) for a virtual server port, enter
commands such as the following.
Virtual ADX(config)#server virtual-name-or-ip http-vs
Virtual ADX(config-vs-http-vs)#port http clear-persist-hash-buckets
Virtual ADX(config-vs-http-vs)#end
Syntax: port port clear-persist-hash-buckets
Reassigning a persistent hash table entry
To manually reassign a persistent hash table entry to a real server for a specified client IP, enter a
command such as the following.
Virtual ADX#show server manual-persist-assign-hash 10.1.1.33 http-vs 80 http-rs1
80
Hash bucket for Client IP 10.1.1.33 = 36
Server http-rs1 allocation to bucket 36 of specified virtual server for port 80
completed!
Syntax: show server manual-persist-assign-hash client-ip virtual-server-name virtual-port
real-server-name real-port
If you manually assign a real server for a hash table entry for which another real server is currently
assigned, the new real server will replace the old real server for the hash entry as follows.
Virtual ADX#show server manual-persist-assign-hash 10.1.1.33 http-vs 80 http-rs2
80
Hash bucket for Client IP 10.1.1.33 = 36
Replacing current server http-rs1 allocated for hash 36 with server http-rs2
Server http-rs2 allocation to bucket 36 of specified virtual server for port 80
completed!
94
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
2
SLB spoofing configuration and support
Displaying hash bucket changes
You can display information about hash bucket changes on the Brocade Virtual ADX, through use of
the show server proxy keep-alive command. A truncated display is shown with the hash bucket
information.
Virtual ADX#show server proxy keep-alive
Keep-alive connection statistics:
...
Hash Bucket Change:
Current serv is down =
Lower BP wins
=
...
Virtual ADX#
1
0
Serv exceed max-con =
0
Syntax: show server proxy keep-alive
Table 11 displays the output field description of show server proxy keep-alive command.
TABLE 11
Output field descriptions for hash buckets of show server proxy keep-alive command
Field
Description
Current serv is down
The current server is down.
Serv exceed max-conn
Not applicable
Lower BP wins
The hash table is synchronized to all BPs. Where another BP assigns the
bucket to a different server, the lower BP wins.
SLB spoofing configuration and support
Spoofing is the Brocade Virtual ADX application switch's ability to redirect reverse SLB traffic to the
interface from where the actual connection came through, regardless of any other route
configured.
When spoofing is enabled for a port on a virtual server, the Brocade Virtual ADX marks the input
interface of the connection. Later any response traffic for the session will be forwarded using this
information regardless of any other route (like next-hop route, policy based route, default route)
configured.
Configuration example:
Virtual ADX(config)#server virtual-name-or-ip vip1 10.10.1.100
Virtual ADX(config-vs-vip1)#port http
Virtual ADX(config-vs-vip1)#port http spoofing
Syntax: [no] port port spoofing
SLB spoofing is supported for all TCP traffic except for complex protocol ports (for example FTP,
MMS, RTSP and TFTP).
SLB spoofing is supported for UDP with the following limitations.
• UDP spoofing will not work if dns-udp-count-connection is configured.
• It is not supported for IMCP response traffic originated from the VIP.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
95
2
Policy-based SLB
Policy-based SLB
Policy-based server load balancing (PBSLB) is the Brocade Virtual ADX ability to direct requests to a
server group based on the source IP address of the request.
When policy-based SLB is enabled for a port on a virtual server, the Brocade Virtual ADX examines
the source IP address of each new connection sent to the VIP on the port. The Brocade Virtual ADX
looks up the source IP address of the request in an internal policy list. The policy list is a table that
associates IP addresses with real server groups. If an entry for the IP address is found in the policy
list, then the Brocade Virtual ADX forwards the request to the associated real server group. If no
entry for the IP address is found, the Brocade Virtual ADX directs the request to a server group
specified as the "default" server group.
Figure 21 shows a sample policy-based SLB configuration.
FIGURE 21
Policy-based SLB configuration
The policy list contains three entries: one associating IP address 10.10.10.10 with Real Server
Group 1, another associating network address 20.20.0.0/16 with Real Server Group 2. In addition,
Real Server Group 3 is specified as the default server group.
In this example, policy-based SLB works as follows:
• When a request from address 10.10.10.10 is received on the VIP, the Brocade Virtual ADX
forwards the request to one of the load-balanced servers in Real Server Group 1.
• When a request from network 20.20.0.0/16 is received, it is forwarded to the real server in
group 2.
96
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Policy-based SLB
2
• When a request from a different address is received, because it does not have an entry in the
policy list, it is forwarded to one of the load-balanced real servers in the default server group,
which is specified as group 3.
NOTES:
• Policy-based SLB is enabled for individual ports on virtual servers.
• Because policy-based SLB is enabled on a per-VIP basis, some VIPs configured on the
Brocade Virtual ADX can have policy-based SLB enabled, while others do not.
• Policy-based SLB can exist on a standalone device or in a Hot Standby high-availability
configuration.
• Policy-based SLB cannot coexist on the same VIP with Layer 7 switching features,
including URL switching and cookie switching.
Configuring a policy list
A policy list can be created in two ways depending on the number of policies being defined:
• If the number of policies is small, you can create the policy list file using the CLI. Refer to
“Creating the policy list using the CLI.”
• If the number of policies is large, you can download the policy list file from a TFTP server. Refer
to “Creating the policy list file to dynamically download from a TFTP server.”
Creating the policy list using the CLI
The following command can be used to add policies.
Virtual ADX(config)#server pbslb add 10.10.10.10 1
Syntax: server pbslb add ipv4-addr {prefix | netmask [server-group-id]
The ipv4-addr variable can be a complete host address, or a network address followed by IPv4
mask bits. You must specify either a prefix or a netmask.
The server-group-id variable is alphanumeric and refers to one of the real server groups configured
on the Brocade Virtual ADX.
For the example shown in “Policy-based SLB configuration” on page 96, the policies can be added
as shown in the following.
Virtual ADX(config)#server pbslb add 10.10.10.10 1
Virtual ADX(config)#server pbslb add 20.20.0.0/16 2
Creating the policy list file to dynamically download from a TFTP server
To dynamically download a policy list file from a TFTP server, it must be a flat ASCII text file that
consists of one or more policy-based SLB entries configured in the following format.
ip-addr [network-mask] [server-group-id]
The ip-addr variable can be a complete host address, or a network address followed by IP mask
bits.
The server-group-id variable is alphanumeric and refers to one of the real server groups configured
on the Brocade Virtual ADX.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
97
2
Policy-based SLB
For the example shown in “Policy-based SLB configuration” on page 96, the policies would be
defined as shown in the following.
10.10.10.10 1
20.20.0.0/16 2
The policy list file created in the format defined above can be transferred to the Brocade Virtual
ADX from a TFTP server. A single download file should contain all IPv4 entries. These entries can be
in any order.
NOTE
Downloading a new file overwrites the existing policy list file on a Brocade Virtual ADX. Consequently
any entries that are not in the most recent download will be lost.
Dynamically downloading a policy list using TFTP
When a policy list is created, as described in “Creating the policy list file to dynamically download
from a TFTP server”, the following command can be used to download the file from a TFTP server.
Virtual ADX(config)#server pbslb tftp 192.168.9.210 policy-list.txt 5
When you enter this command, the downloaded policy list file immediately replaces the entries in
the Brocade Virtual ADX’s policy-based SLB configuration.
Syntax: server pbslb tftp tftp-server-ip-addr filename retry-count
The tftp-server-ip-addr variable specifies the IP address of the TFTP server.
The filename variable specifies the name of the policy list file.
The retry-count variable specifies the number of times that the Brocade Virtual ADX retries the
download if the first attempt is not successful.
Redirecting traffic to the default group during download
The Brocade Virtual ADX supports seamless download (or no blocking of VIP traffic while a policy
list is being downloaded) only when the number of PBSLB entries do not exceed 1,000,000 IPv4
entries. A Brocade Virtual ADX maintains two separate tables in memory: one for the existing list
and one for the new list that is being downloaded. After the new list is completely downloaded, it is
swapped with the existing list. This method allows for the new policy list to take effect immediately
without affecting the VIP traffic during the download.
NOTE
This redirect method only applies when the maximum number of PBSLB entries has not been
increased to 5,000,000 for IPv4 through the use of the server pbslb max-entries command.
For policy list files that contain more than 1,000,000 entries, all VIP traffic will be blocked during
the download and will resume only after the policy list file is completely downloaded. To be able to
send VIP traffic to the default server group instead of blocking it during download, enable the
server pbslb send-to-default-group-during-download feature.
There are three steps to turn on this feature.
1. Create a PBSLB default group-ID.
2. Assign real server ports to the default group.
3. Enable send-to-default-group-during-download.
98
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Policy-based SLB
2
Creating a PBSLB default group
To create a PBSLB default group, enter a command such as the following.
Virtual ADX(config)#server pbslb default-group-id ipv4 4
Syntax: [no] server pbslb default-group-id ipv4 group-id
Assigning real server ports to default group
A default group can contain one or more real servers. If there is more than one real server in a
default group, requests are load balanced across all the servers in the group. To assign real servers
to the default group, enter commands such as the following.
Virtual ADX(config)#server real-name rs1 10.95.7.14
Virtual ADX(config-rs-rs1)#port http group-id 4 4
Virtual ADX(config-rs-rs1)#exit
Enabling pbslb send-to-default-group-during-download
To enable send-to-default-group-during-download, enter a command such as the following.
Virtual ADX(config)#server pbslb send-to-default-group-during-download
Syntax: [no] server pbslb send-to-default-group-during-download
NOTE
You configure this command only if you have increased the maximum number of PBSLB entries over
the default number.
Specifying the maximum number of entries
You can optionally specify the maximum number of entries allowed for a policy-based SLB
configuration. The minimum, maximum and default values are determined by the license that is
active on your system. For actual values associated with your license, refer to the Brocade Virtual
ADX Licensing Guide.
For example, to specify 40,000 as the maximum number of IPv4 entries for policy-based SLB, enter
the following command.
Virtual ADX(config)#server pbslb max-entries ipv4 40000
Syntax: server pbslb max-entries ipv4 max-number
The max-number variable specifies the maximum number of PBSLB entries you want to configure.
The maximum number of IPv4 entries that the Brocade Virtual ADX supports is determined by the
license that is active on your system. For actual values associated with your license, refer to the
Brocade Virtual ADX Licensing Guide.
After you enter this command and save the configuration, you must reload the software for the new
maximum limit to take effect.
Deleting an entry from the policy list
To delete an entry from the policy list, enter the following command.
Virtual ADX(config)#server pbslb delete 10.10.10.1/24 4
Syntax: server pbslb delete ipv4-addr { netmask | prefix [server-group-id]}
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
99
2
Policy-based SLB
The ipv4-addr variable specifies the IPv4 entry that you want to delete from the policy list. You must
specify either a prefix or a netmask.
The server-group-id variable is alphanumeric and refers to one of the real server groups configured
on the Brocade Virtual ADX.
Deleting an entire PBSLB list
To delete the entire PBSLB list, enter a command such as the following.
NOTE
This command will delete all the entries in the PBSLB list. You can enter the show pbslb all 0
command to first display the contents of the list before deleting the entire list.
Virtual ADX(config)#server pbslb delete all ipv4
The whole IPv4 table of PBSLB has been deleted.
Syntax: server pbslb delete all ipv4
Copying a policy list to a file on TFTP server
To copy the currently loaded policy list from the Brocade Virtual ADX to a file on a TFTP server, enter
a command such as the following.
Virtual ADX#copy pbslb-running-config tftp 192.168.9.210 policy-list.txt
Syntax: copy pbslb-running-config tftp tftp-server-ip-addr filename
The tftp-server-ip-addr variable is the IP address of the TFTP server.
The filename is the name the policy list file will be saved as.
Specifying a default server group
When a new connection is sent to a VIP where policy-based SLB is enabled, if no entry for the
source IP address is found in the policy list, the Brocade Virtual ADX directs the request to a server
group specified as the "default" server group.
To specify a server group as the default server group, enter a command such as the following.
Virtual ADX(config)#server pbslb default-group-id ipv4 3
Syntax: server pbslb default-group-id ipv4 group-id
The group-id variable is alphanumeric and refers to one of the real server groups configured on the
Brocade Virtual ADX.
Assigning real servers to server groups
The policy list associates source IP addresses with real server group IDs. To configure policy-based
SLB, you assign real servers to real server groups.
A real server group can contain one or more real servers. If there is more than one real server in a
server group, requests are load balanced across all the servers in the group. To assign real servers
to server groups, establish the IP address of each real server and specify the server groups to
which it belongs.
100
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Policy-based SLB
2
For example, to configure real server rs1 in Figure 21 on page 96, enter commands such as the
following.
Virtual ADX(config)#server real rs1 10.95.7.1
Virtual ADX(config-rs-rs1)#port http group-id 1 1
Virtual ADX(config-rs-rs1)#exit
Syntax: [no] server real real-server-name ip-addr
Syntax: [no] port port group-id server-group-id-pairs
In this example, the server real command defines a real server called rs1 with an IP address of
10.95.7.1.
The port http group-id command indicates the server groups to which the real server belongs. The
server group is expressed as a pair of numbers, indicating a range of real server group IDs. The first
number is the lowest-numbered server group ID, and the second is the highest-numbered server
group ID. For example, if a real server belongs only to the server group with ID = 1, the last two
numbers in the port http group-id command would be 1 1. (Note the space between the two
numbers.) If a real server belongs to server groups 1 through 10, the last two numbers in the
command would be 1 10. Valid numbers for server group IDs are from 0 through 1023.
To include a real server in groups that are not consecutively numbered, enter up to four server
group ID pairs. For example, to include a real server in groups 1–5 and 11–15, enter the following
command.
Virtual ADX(config-rs-rs1)#port http group-id 1 5 11 15
You can also specify the server group ID pairs on separate lines; for example.
Virtual ADX(config-rs-rs1)#port http group-id 1 5
Virtual ADX(config-rs-rs1)#port http group-id 11 15
The configuration for the remaining real servers in Figure 21 on page 96 is shown below. These
commands place real server rs2 in server group ID = 1 (along with real server rs1), real server rs3
in server group ID = 2, and real server rs4 in server group ID = 3.
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server real
ADX(config-rs-rs2)#port
ADX(config-rs-rs2)#exit
ADX(config)#server real
ADX(config-rs-rs3)#port
ADX(config-rs-rs3)#exit
ADX(config)#server real
ADX(config-rs-rs4)#port
ADX(config-rs-rs4)#exit
rs2 10.95.7.2
http group-id 1 1
rs3 10.95.7.3
http group-id 2 2
rs4 10.95.7.4
http group-id 3 3
Enabling PBSLB for a port on a virtual server
To enable policy-based SLB on a VIP for Figure 21 on page 96, enter commands such as the
following.
Virtual
Virtual
Virtual
Virtual
ADX(config)#server virtual-name-or-ip mysite 10.157.22.63
ADX(config-vs-mysite)#port http
ADX(config-vs-mysite)#port http sw-l4-pbslb
ADX(config-vs-mysite)#bind http rs1 http rs2 http rs3 http rs4 http
Syntax: [no] port port sw-l4-pbslb
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
101
2
Policy-based SLB
Deleting existing PBSLB sessions
By default, when a PBSLB server group configuration changes, the client sessions with that group
remain open. For example, if a client has sessions associated with Group A, but Group A’s
configuration changes and moves the client sessions to Group B, the sessions with Group A are still
open. You can change this behavior by enabling the scan-session-table-after-config-change feature.
With this feature enabled, old connections are deleted and a new connection is set up with a new
group whenever a PBSLB server's configuration changes.
To enable this feature, enter the following command.
Virtual ADX(config)#server pbslb scan-session-table-after-config-change
Syntax: [no] server pbslb scan-session-table-after-config-change
Use the no form of the command to disable this feature. The feature is disabled by default.
PBSLB pool failsafe group
The PBSLB pool failsafe group feature allows a Brocade Virtual ADX to direct traffic away from a
given server pool to a "default pool" in situations where the servers in the server pool become
unavailable.
Overview of PBSLB pool failsafe group
When PBSLB is used to filter traffic based on source IP address, a Brocade Virtual ADX looks up a
group id for the client to forward the incoming request to. If all the servers in the group fail, the
Brocade Virtual ADX sends a TCP reset to the client, causing the request to fail. This feature allows
you to configure a failsafe group, which will be used to forward traffic, in case the group designated
for a client source-ip address fails. The following section outlines the behavior of this feature in two
scenarios.
For IP addresses present in the PBSLB list:
• If the group-id is 0 (deny group), the traffic is denied (RST in case of TCP and drop in case of
udp).
• If the group-id is not 0, if the servers are healthy, traffic is load balanced among servers as per
predictor.
• If all servers of the group are in a failed state, traffic is load balanced among "failsafe" group
servers.
• If all of the servers of the "failsafe" group are in a failed state, traffic is denied (RST in case of
TCP and drop in case of UDP).
For IP addresses not present in the PBSLB list:
• If the default-group-id is not configured or is configured as 0 (deny group), traffic is denied.
• If the default-group-id is configured, traffic is load balanced among default-group servers as
per predictor.
• If all of the servers of the default-group are in a failed state, the traffic is load balanced among
"failsafe" group servers.
• If all of the servers of the failsafe group are in a failed state, the traffic is denied.
102
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Policy-based SLB
2
Command line interface
There are three steps to enable this feature.
1. Create a PBSLB failsafe group ID.
2. Assign real server ports to a failsafe group.
3. Enable PBSLB on a VIP port.
Creating a PBSLB failsafe group
To create a PBSLB failsafe group, enter a command such as the following.
Virtual ADX(config)#server pbslb failsafe-group-id ipv4 2
Syntax: [no] server pbslb failsafe-group-id ipv4 group-id
The group-id variable is alphanumeric and refers to one of the real server groups configured on the
Brocade Virtual ADX.
Assigning real server ports to a failsafe group
A failsafe group can contain one or more real servers. If there is more than one real server in a
failsafe group, requests are load balanced across all the servers in the group. To assign real
servers to the failsafe group, enter commands such as the following.
Virtual ADX(config)#server real-name rs1 10.95.7.1
Virtual ADX(config-rs-rs1)#port http group-id 2 2
Virtual ADX(config-rs-rs1)#exit
Enabling PBSLB on a VIP port
To enable PBSLB on a VIP port, enter commands such as the following.
Virtual
Virtual
Virtual
Virtual
ADX(config)#server virtual-name-or-ip mysite 10.157.22.63
ADX(config-vs-mysite)#port http
ADX(config-vs-mysite)#port http sw-l4-pbslb
ADX(config-vs-mysite)#bind http rs1 http
Using show commands
To view the number of requests forwarded to the failsafe server group, enter the following
command.
Virtual ADX#show pblsb failsafe ipv4
Syntax: show pbslb failsafe ipv4
To clear the PBSLB failsafe counter, enter the following command.
Virtual ADX#clear pbslb failsafe
Syntax: clear pbslb failsafe
Auto Download of PBSLB list
Policy Based Load Balancing (PBSLB) Auto Download allows you to automatically download a list of
policies to the Brocade Virtual ADX at a scheduled interval or a specific time of day. This
automation precludes the need to write scripts and cron jobs. Using PSLB Auto Download, you can
regularly upload an updated PBSLB list to the Brocade Virtual ADX on a pre-determined schedule.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
103
2
Policy-based SLB
NOTE
The server pbslb tftp command must be configured before the server pbslb time-of-day or server
pbslb download-interval command, so the Brocade Virtual ADX knows which server and file name to
use in the download.
NOTE
The PBSLB time-of-day granularity is in minutes, so seconds are ignored in the configuration. For
example, if you enter time as 16:35:30, it is taken as 16:35:00.
Configuring PBSLB download interval
To configure the Brocade Virtual ADX to download a PBSLB list at a periodic interval, use
commands similar to the following.
Virtual ADX(config)#server pbslb tftp 10.10.1.101 iplist.txt 2
Virtual ADX(config)#server pbslb download-interval 20
Syntax: server pbslb download-interval interval-in-minutes
In this example, the Brocade Virtual ADX downloads the list in iplist.txt from server 10.10.1.101
once every 20 minutes. If it encounters an error, it retries two times.
PBSLB syslog messages
Messages similar to the following appear whenever autodownload PBSLB is executed.
Aug 15 21:23:59:I:PBSLB config file 5mil-2.txt downloaded from TFTP server
172.20.1.6 -->
The preceding line indicates success.
Aug 16 13:30:03:A:FAILED to download PBSLB config file 5mil-2.txt from TFTP server
172.20.1.6 -->
The preceding line indicates failure.
Aug 16 14:20:59:W:RETRY download of PBSLB config file 5mil-2.txt from TFTP server
172.20.1.6 -->
The preceding line indicates a retry.
Displaying PBSLB entries
You can display one or more entries in the currently loaded policy list. To display an individual policy
list entry, enter a command such as the following.
Virtual ADX#show
IP address
10.10.1.101
pbslb 10.10.1.101
Mask
Server Group ID
128
11
Syntax: show pbslb ip-address
The ip-address variable specifies the IPv4 address of the entry in the currently loaded policy list
that you want to display.
The show pbslb command displays the entry in the policy list that corresponds to the specified IP
address. If no entry is found for the specified IP address, no output is displayed.
104
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Policy-based SLB
2
To display multiple entries in the policy list, enter a command such as the following.
Virtual ADX#show pbslb all ipv4 10
Max Count: 1000000
Total Count: 2
IP address
Mask
Server Group ID
10.10.1.101
128
11
Syntax: show pbslb all ipv4 index
The show pbslb all command displays 20 entries in the policy list, starting from the point specified
with the index variable. In the example, 20 entries in the policy list are displayed, starting from the
100th entry.
Packet trace
When a policy list file is downloaded to the Brocade Virtual ADX, messages to indicate download
progress are printed on the console. By default, when a policy list file is downloaded through a
Telnet or SSH session to the Brocade Virtual ADX, these messages do not appear on the Telnet or
SSH session. To monitor the download progress, you need to enable packet trace using the
following command.
Virtual ADX#ptrace term
debug output is now sent to this terminal
Syntax: ptrace term
Virtual ADX(config)#server pbslb tftp 10.1.1.1
pbslb/pbslb2M.txt 1 Download of pbslb config from TFTP server is initiated.
[email protected] ADX(config)#.............................................
...............................Download of pbslb config from TFTP server is
done.
TFTP file size = 27718556, Entry count = 1000000, Parse error = 0, Table
full error 1000000 Resetting pbslb trie Processing PBSLB entries
.......................................PBSLB processing done
BP sync msg = 200, BP Sync fail = 0
Duplicates = 0, Alloc err = 0, Full err = 0, Unknown err = 0
TABLE 12
Error messages
Message
Description
BP sync msg
The number of messages that it took for the MP to synch the downloaded PBSLB
table to the BP (The download itself is staggered, so it is done in multiple passes).
BP Sync fail
The number of messages (mentioned above) that failed successful transmission. In
the event of a failure, the message is sent again.
If BP sync fails, the MP will try to push down the PBSLB table to the BPs again after
100 ms. This process continues until the BP synch is completely successful. On the
BP, the PBSLB tree is not populated until the download is totally successful.
Alloc err
The number of times the Brocade Virtual ADX was unsuccessful in allocating
memory for the PBSLB table. The device tries to allocate the entire table at once, so
if there is an error, this counter can only show a value of 1.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
105
2
Miscellaneous options
TABLE 12
Error messages (Continued)
Message
Description
Full err
The number of times the Brocade Virtual ADX could not add a new PBSLB entry to
the table because the PBSLB is already full. This value should indicate the number by
which the downloaded pbslb table size exceeds the value that the Brocade Virtual
ADX supports.
When the PBSLB list is downloaded, it is first populated into a flat table that does not
have any hierarchy. After populating this table, the MP will construct the DP table to
actually store the PBSLB entries for later lookups. Even when the MP synchs the
PBSLB info to the BPs, it is the flat table that is pushed down and not the DP table.
Full error refers to those error cases where new entries cannot be added to the DP
table because the tree is already full. Table full error refers to those error cases
where no more entries can be added to the flat table because the flat table is filled
up.
Unknown err
Is used to catch miscellaneous unexpected errors. For example, if the download
buffer of the PBSLB table from MP to BP is corrupted. Another example is when we
try to add an entry to the tree and the entry cannot be added due to an unexpected
error.
Miscellaneous options
Changing a real server’s IP address
The Brocade Virtual ADX enables you to easily change a real server’s IP address, even when the
real server is active. This capability is useful when you want to perform some maintenance on the
real server (either the server itself or the server’s configuration on the Brocade Virtual ADX) or
when the network topology has changed.
By default, when you change a server’s IP address, the Brocade Virtual ADX performs the change
gracefully, as follows:
• Existing connections are allowed to continue on the old IP address until they terminate
normally.
• New client requests are sent to the new IP address.
Optionally, you can force all existing connections to be reset instead of waiting for them to
terminate normally. When you force the connections to be reset, the Brocade Virtual ADX
immediately resets a connection when it receives client data for the connection.
To change a real server’s IP address, enter commands such as the following.
Virtual ADX(config)#server real rs1
Virtual ADX(config-rs-rs1)#ip-address 10.6.7.8
Syntax: [no] ip-address ip-addr [force-shutdown]
The ip-addr variable specifies the new IP address for the real server.
The force-shutdown parameter immediately resets a client’s connection to the IP address when the
Brocade Virtual ADX receives TCP data from the client. By default, the Brocade Virtual ADX allows
existing connections to terminate normally following the address change.
106
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Miscellaneous options
2
Adding a description
You can add a description to a real server or virtual server. The description appears in the output of
show commands and in the running-config and startup-config files.
To add a description, enter commands such as the following.
Virtual ADX(config)#server real RS20 10.2.3.4
Virtual ADX(config-rs-RS20)#description "Real Server #20"
Syntax: [no] description “text"
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 Virtual ADX at Layer 2. The
Brocade Virtual ADX uses local servers for regular load balancing.
• Remote – A remote server is one that is connected to the Brocade Virtual ADX through one or
more router hops. The Brocade Virtual ADX uses remote servers only if all the local servers are
unavailable.
NOTE
To use a remote server for regular load balancing, refer to “Primary and backup servers” on page 49.
Configuring a TCP MSS value at the global level
The default TCP MSS value configured on a Brocade Virtual ADX is 1460 Bytes. This value can be
changed globally as shown in the following.
Virtual ADX(config)#tcp-mss 4000
Syntax: [no] tcp-mss mss-value
The mss-value variable specifies the global MSS value. This value can be from 576 to 9176.
Configuring a TCP MSS value for a virtual server
The default TCP MSS value configured on a Brocade Virtual ADX is 1460 Bytes. This value can be
changed per virtual server as shown in the following.
Virtual ADX(config)#server virtual-name-or-ip v1
Virtual ADX(config-vs-v1)#tcp-mss 4000
Syntax: [no] tcp-mss mss-value
The mss-value variable specifies MSS value for all the real servers bound to the specified virtual
server. This value can be from 576 to 9176.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
107
2
Miscellaneous options
Configuring a TCP MSS value at the virtual server port level
The default TCP MSS value configured on a Brocade Virtual ADX is 1460 Bytes. This value can be
changed per virtual server port as shown in the following.
Virtual ADX(config)#server virtual-name-or-ip v1
Virtual ADX(config-vs-v1)#port http tcp-mss 4000
Syntax: [no] port virtual-server-port tcp-mss mss-value
The virtual-server-port variable specifies the TCP port that the MSS value will be applied to.
The mss-value variable specifies the MSS value for all the real server ports bound to the specified
virtual server port. This value can be from 576 to 9176.
Configuring a TCP MSS value at the TCP profile level
The default TCP MSS value configured on a Brocade Virtual ADX is 1460 Bytes. This value can be
changed per TCP profile as shown in the following.
Virtual ADX(config)#tcp profile tcp1
Virtual ADX(config-tcp-profile-tcp1)#tcp-mss 4000
Syntax: [no] tcp-mss mss-value
The mss-value variable specifies the MSS value for all the real servers bound to the specified
virtual server configured with the specific TCP profile. This value can be from 576 to 9176.
Support for TCP Window Scale option in TCP header
The TCP window scale option in TCP header feature optionally increases the definition of the
maximum TCP window from 16 bits (65535) bytes by a window scale factor, to a theoretical
maximum of (8388480 bytes). However, this theoretical value is limited by the maximum RX TCP
buffer size of 3145278 bytes.
If this feature is not enabled, the maximum TCP window remains at 65535 bytes.
The window scale factor is expressed as a shift count - a power of 2. When enabled, the range of
this count is from 1 to 7, i.e., from 2 to the power of 1 to 2 to the power of 7. Zero is the value of the
default shift count, when TCP window scale is not specified
NOTE
The TCP window scale option appears in the SYN segment. Both ends of a TCP connection must send
this option in their SYN segment. Otherwise window scaling is not enabled.
108
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Miscellaneous options
2
Configuring TCP window scale option
To configure the TCP window scale option in the TCP header and change the receive and transmit
buffer sizes, enter the following commands at the tcp profile name configuration level as shown in
the example:
Virtual
Virtual
Virtual
Virtual
ADX(config)# tcp profile sample
ADX(config-tcp-sample)# tcp-wnd-scale 1
ADX(config-tcp-sample)# rxbuf-size 3145278
ADX(config-tcp-sample)# txbuf-size 3145278
Syntax: [no] tcp-wnd-scale window_scale_factor
The window_scale_factor variable specifies the TCP window scale factor from 1 to 7. The default
is 0.
Syntax: [no] rxbuf-size buffer-size
The buffer-size variable specifies maximum TCP receive buffer size. Enter an integer from 0 to
3145278. The default is 0.
Syntax: [no] txbuf-size buffer-size
The buffer-size variable specifies maximum TCP transmit buffer size. Enter an integer from 0 to
3145278. The default is 0.
To display the TCP profile sample, enter the following show tcp profile command:
Virtual ADX# show tcp profile sample
TCP profile: sample
TCP Rx Buffer Size: 314278
TCP Tx Buffer Size: 314278
TCP Window scale factor: 1
Syntax: show tcp profile name
Binding a TCP profile to a virtual port and
response rewrite policy
You can bind a TCP profile to a virtual port and response rewrite policy as shown in the following.
Virtual ADX(config)#server virtual-name-or-ip v1
Virtual ADX(config-vs-v1)#port http response-rewrite-policy resp-1 tcp1
Syntax: [no] port virtual-port response-rewrite-policy response-rewrite-policy-name
tcp-profile-name
The virtual-port variable specifies the TCP port that the specified TCP policy will be bound to.
The response-rewrite-policy-name variable specifies the response rewrite policy that the specified
TCP policy will be bound to.
The tcp-profile-name variable specifies the TCP policy that the specified response rewrite policy
and virtual port will be bound to.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
109
2
Miscellaneous options
Limiting the maximum number of TCP SYN requests
You can limit the maximum number of TCP SYN requests per second per server. A TCP SYN request
is a packet a client sends requesting a TCP connection to the server.
To limit the maximum number of TCP SYN requests to 3500, enter the following command.
Virtual ADX(config)#server syn-limit 3500
Syntax: [no] server syn-limit max_requests
The max_requests variable is maximum number of TCP SYN requests per second per server. Enter
an integer from 1 to 65535. The default value is 65535.
Configuring the maximum connection rate for a real server
Connection Rate Control (CRC) specifies the maximum number of new TCP, UDP, or individual port
connections per second allowed on a 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
The Brocade Virtual ADX increments the connection counter for real server connections only after
the Brocade Virtual ADX selects a server for the connection. If the Brocade Virtual ADX cannot
serve a client request because a real server, cache, or firewall already has the maximum number of
connections for the current second for the requested port, the Brocade Virtual ADX tries another
server. If there are no servers available, the Brocade Virtual ADX sends a TCP RST to the client.
If you configure a limit for TCP or UDP and also for an individual application port, the Brocade
Virtual ADX uses the lower limit. For example, if you limit new TCP connections to a real server to
1000 per second and also limit new HTTP connections to 600 per second, the Brocade Virtual ADX
limits connections to TCP port HTTP to 600 per second.
NOTE
The Brocade Virtual ADX counts only the new connections that remain in effect at the end of the
one-second interval. If a connection is opened and terminated within the interval, the Brocade
Virtual ADX does not include the connection in the total for the server.
NOTE
Connection rates might not be strictly limited to the configured values. A slight drift can be
introduced due to latency. For example, with traffic running at 1000 connections per second, and
the max-tcp-conn-rate command is configured at 100, the connection rate could go up to 140.
To limit the number of new TCP and UDP connections a real server can receive each second, enter
commands such as the following.
Virtual ADX(config)#server real RS1 10.2.3.4
Virtual ADX(config-rs-RS1)#max-tcp-conn-rate 1000
Virtual ADX(config-rs-RS1)#max-udp-conn-rate 800
110
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Miscellaneous options
2
The first command limits new TCP connections to the real server to 1000 per second. The second
command limits the rate of new UDP connections to the real server to 800 per second.
Syntax: max-tcp-conn-rate num
Syntax: max-udp-conn-rate num
The num variable specifies the maximum number of connections per second. There is no default.
The maximum connection rate that can be configured is 4294967295.
To limit the rate of new connections for a specific application port, enter commands such as the
following.
Virtual ADX(config-rs-RS1)#port http
Virtual ADX(config-rs-RS1)#port http max-tcp-conn-rate 600
These commands add port HTTP (80) to the real server and limit the rate of new connections to the
port to 600.
Syntax: port TCP/UDP-portnum max-tcp-conn-rate num
Syntax: port TCP/UDP-portnum max-udp-conn-rate num
The TCP/UDP-portnum variable specifies the application port.
The num variable specifies the maximum number of connections per second. The maximum
connection rate that can be configured is 4294967295.
Configuring the maximum connection rate for a virtual server
You can specify the maximum allowed TCP or UDP connection rate for virtual servers. The Brocade
Virtual ADX monitors the traffic conditions and rejects new connections when the connection rate
exceeds the limit.
To limit the number of new TCP or UDP connections that a virtual server can receive each second,
use the max-tcp-conn-rate or max-udp-conn-rate command, respectively.
Virtual ADX(config)# server virtual-name-or-ip vs2 200.1.1.2
Virtual ADX(config-vs-vs2)# max-tcp-conn-rate 2000
Virtual ADX(config-rs-vs2)# max-udp-conn-rate 800
The first command limits new TCP connections to the server to 2000 per second. The second
command limits the rate of new UDP connections to the server to 800 per second.
Syntax: max-tcp-conn-rate num
Syntax: max-udp-conn-rate num
The num variable specifies the maximum number of connections per second. There is no default.
Enter a number from 1 to 4294967295.
You can display the VIP TCP connection rate (tcp-conn-rate) and UDP connection rate
(udp-conn-rate) by using the show server virtual command.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
111
2
Miscellaneous options
Disabling port translation
By default, the Brocade Virtual 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 Virtual ADX translates the application port in the client’s request from port 80 into 8080
before forwarding the request to a real server.
A few Brocade Virtual 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 Virtual 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.
Virtual ADX(config)#server virtual-name-or-ip v1 10.157.22.1
Virtual ADX(config-vs-v1)#no port 80 translate
Syntax: [no] port tcp/udp-port translate
Traffic distribution among BPs
The Brocade Virtual ADX uses a hash algorithm to distribute traffic among barrel processors (BP). A
default algorithm and 3 optional algorithms operate on the Source or Destination IP addresses to
balance traffic among the BPs.
The default hash algorithm is “hash-crc32l”. In most situations, this setting will provide the most
effective distribution of traffic across BPs. If you find however that traffic is not being efficiently
distributed across the BPs on your Brocade Virtual ADX, you can try one of the other options.
To change the server hash algorithm from the default “hash-crc32l” to “hash-crc32u” use the
following command.
Virtual ADX(config)#server hash-crc32u
Syntax: server hash-crc32l | hash-crc32u | hash-xorl | hash-xoru
hash-crc32l: This algorithm performs CRC on the 32-bits of source IP in the forward direction and
the 32-bits of Destination IP in the reverse direction. The lower five bits of the computed result are
used to distribute traffic among BPs. This is the default setting.
hash-crc32u: This algorithm performs CRC on the 32-bits of source IP in the forward direction and
the 32-bits of Destination IP in the reverse direction. The upper five bits of the computed result are
used to distribute traffic among BPs.
hash-xorl: This algorithm performs XOR on the 32-bits of source IP in the forward direction and the
32-bits of Destination IP in the reverse direction. The lower five bits of the computed result are
used to distribute traffic among BPs.
hash-xoru: This algorithm performs XOR on the 32-bits of source IP in the forward direction and the
32-bits of Destination IP in the reverse direction. The upper five bits of the computed result are
used to distribute traffic among BPs.
112
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Miscellaneous options
2
Including the server client port in hash calculations
When there are a small number of client IP addresses that connect to a Brocade Virtual ADX, the
traffic distribution of IP addresses to the BPs might not be optimal. Where this is the case, it can be
useful to include the client source port in the hash calculations. This configuration is achieved by
running the following command.
Virtual ADX(config)#server source-port-hash
Syntax: [no] server source-port-hash
NOTE
This command can be configured with any of the hash algorithms configured using the server
hash-xxx command described previously. This command cannot be used for protocols that involve
dynamic ports such as FTP and RTSP, and with sticky features.
Sending ICMP Port Unreachable or Destination Unreachable messages
NOTE
ICMP messages are disabled by default.
By default, if the Brocade Virtual ADX receives a client request for a specific VIP and UDP port, but
the requested port is not bound to the requested VIP, the Brocade Virtual ADX drops the packet. For
example, if a client sends a request to VIP 10.10.5.1 and UDP port 99, but configuration for VIP
10.10.5.1 on the Brocade Virtual ADX does not include a binding for port 99, the Brocade Virtual
ADX drops the request without sending a message to the client.
You can configure the Brocade Virtual ADX to send an “ICMP Port Unreachable message” instead
of dropping the packet without notice.
Also by default, if a client requests an unavailable TCP or UDP port, the Brocade Virtual ADX does
not send an “ICMP Destination Unreachable message” to the client.
For HTTP traffic, you can configure the Brocade Virtual ADX to send such a message to the client, if
the requested port either is not configured on any of the real servers or is unavailable because all
the servers configured with the requested port are busy or down.
To configure the Brocade Virtual ADX to send “ICMP Destination Unreachable messages” to clients,
or to send an “ICMP Port Unreachable message” when the device receives a request for a UDP port
that is not bound to the requested VIP, enter the following command.
Virtual ADX(config)#server icmp-message
Syntax: [no] server icmp-message
NOTE
If server disable-ping-vip-down is configured, the Brocade Virtual ADX will stop responding to ICMP
echo request when the VIP is down.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
113
2
Miscellaneous options
Sending a TCP RST to a client that requests unavailable
applications
If a client requests an unavailable application, the Brocade Virtual ADX does one of the following:
• Quietly drops the request.
• Sends an ICMP Destination Unreachable message (for UDP or TCP).
• Sends a TCP RST (for TCP only) – the default action.
Generally, an application is unavailable if all the real servers that have the application are
unavailable or if the application is not configured on the VIP requested by the client.
To configure the Brocade Virtual ADX to send a TCP RST to a client, enter the following command.
Virtual ADX(config)#server reset-message
Syntax: [no] server reset-message
NOTE
The server reset message overrides the ICMP Destination Unreachable message. If the
configuration contains both, the Brocade Virtual ADX sends a TCP RST instead of an ICMP message
for TCP requests. For UDP requests, the device still sends ICMP messages. TCP RST does not apply
to UDP.
For information on how to globally configure the Brocade Virtual ADX to send an ICMP Destination
Unreachable message to a client, refer to “Sending ICMP Port Unreachable or Destination
Unreachable messages” on page 113.
Sending a TCP RST when TCP session entry ages out
By default, the Brocade Virtual ADX does not send a TCP RST to a client or server when its TCP
session in the session table ages out.
You can enable the Brocade Virtual ADX to send a TCP RST to a client or server when a TCP session
entry in use by the client or server ages out. To do this, enter the following command.
Virtual ADX(config)#server tcp-age reset
Syntax: [no] server tcp-age reset [both | client | server]
This command only works if you are running Layer 7 SLB.
The both option (default) enables the device to send messages to clients and servers.
The client option enables the device to send messages only to clients.
The server option enables the device to send messages only to servers.
114
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Miscellaneous options
2
Disabling TCP RST message when a real server goes down
during an open session
By default, if a real server goes down during an open TCP session with a client, the Brocade Virtual
ADX sends a TCP RST message to the client to terminate the session normally. When the real server
comes back up, clients can establish a new session with the server.
You can globally disable the TCP RST message from being sent under these circumstances. When
you disable the TCP RST message, the client can resume the interrupted session when the real
server comes back up.
NOTE
Disabling the TCP RST messages affects only the message sent to a client when a real server goes
down during a client’s session with the server. TCP RST messages sent under other circumstances
are not affected.
To globally disable the TCP RST message from being sent, enter the following command.
Virtual ADX(config)#server no-reset-for-established-session
Syntax: [no] server no-reset-for-established-session
By default, sending TCP RST messages is enabled.
No TCP RST response to non-SYN first packet of a TCP flow
The Brocade Virtual ADX can remain passive for non-SYN packet in the beginning of the flow. The
default behavior is to send a TCP RST packet to client when a non-SYN packet is received at the
beginning.
By default, the Brocade Virtual ADX responds with a TCP RST packet whenever it receives a
non-SYN TCP packet from a client destined for a VIP if there is no matching session.
If you want the Brocade Virtual ADX to remain passive, use the following command to ensure that
no RST packet is sent to the client.
Virtual ADX(config)#server reset-on-syn-only
Syntax: [no] server reset-on-syn-only
Decrement counters in deletion queue
On a Brocade Virtual ADX, when a connection is closed, the corresponding sessions are not
immediately deleted. The sessions are put in a deletion queue and deleted later at MSL time
(default is 8 seconds). Statistics on the closed connections are not adjusted until the sessions are
actually deleted from the deletion queue.
To adjust statistics when sessions are put in the deletion queue, use the following command.
Virtual ADX(config)#server decrement-counter-when-put-in-delQ
Syntax: [no] server decrement-counter-when-put-in-delQ
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
115
2
Miscellaneous options
Optimized fast-path SLB processing
You can enable the Brocade Virtual ADX to use fast-path processing for stateful SLB. Stateful SLB is
the standard form of SLB that uses session table entries to track session information. All traffic for
stateful SLB takes an optimized processing path.
When you enable fast-path processing, the Brocade Virtual ADX does not process every TCP or UDP
packet in a given session in detail. Instead, the Brocade Virtual ADX uses information gathered
during setup of the session to forward packets in the session.
NOTE
SLB optimization is useful if simple stateful SLB is the primary or sole application on the device.
NOTE
Stateful SLB traffic is optimized by default.
Configuration considerations
Consider the following:
• Optimization applies only to SLB TCP or UDP traffic that is initiated by clients. Other types of
traffic are not optimized.
• Optimization does not apply to fragmented IP packets.
• In the current release, the port name or number on the VIP must be same as the one on the
real server bound to the VIP. Port translation is not supported.
•
•
•
•
FTP traffic is not supported.
Source NAT (source-nat command) is not supported.
Host ranges (host-range command) are not supported.
Many-to-one TCP or UDP port binding (no port tcp/udp-port translate command) is not
supported.
NOTE
Traffic for an SLB configuration that does not meet these criteria is still forwarded using normal
processing, but fast-path processing is not used.
Configuring TCP fast aging
Following a RST from the server, the Brocade Virtual ADX ages out session table entries in the
amount of time specified in the server msl seconds command, by default 8 seconds. You can
optionally configure the Brocade Virtual ADX to use the 1- to 2- minute aging time used in previous
releases.
To set the amount of time a session table entry stays in the delete queue following a RST from the
server, enter a command such as the following.
Virtual ADX(config)#server msl 2
Syntax: server msl seconds
The seconds variable can be from 1 through 180 seconds. The default is 8 seconds. Note that
attempting to set the value to 0 resets the value to the default (8 sec.).
116
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Miscellaneous options
2
To disable TCP fast aging and use the 1- to 2- minute aging time from previous releases, enter the
following command.
Virtual ADX(config)#server no-tcp-fast-age-on-server-reset
Syntax: [no] server no-tcp-fast-age-on-server-reset
Server opt-enable-route recalculation
For optimized SLB, the Brocade Virtual ADX does not calculate a reverse route for every packet in a
flow. In this scenario, the Brocade Virtual ADX uses the route that it learns in the first reverse
packet, such as SYN-ACK packet. However, this calculation might not be desirable in a environment
where a route can be dynamically changed, such as a case with upstream firewall failover, where
the new firewall has the same IP address but a different MAC address. To cover these cases, the
server opt-enable-route-recalculation command is used to force the Brocade Virtual ADX to
dynamically calculate the reverse route.
In the case where the Server ADX only has Layer 4 SLB functionality, it will select an optimized way
to accelerate the session handling by creating data sessions and remaining with the same ports for
forwarding and reverse data traffic when the Brocade Virtual ADX receives the SYN packet. If later
on, traffic needs to go through different ports, the traffic will fail. The server
opt-enable-route-recalculation command is used to solve this problem by routing data out of the
ports after recalculating the route. By enabling this command, however, the network performance
will be affected.
NOTE
This command should be used only when there is a need to recalculate reverse route. Most
situations do not require this.
Enabling use of the client MAC address
By default, the Brocade Virtual ADX uses the MAC address of its default gateway as the destination
MAC address for server replies (TCP SYN and TCP SYN ACK) to a client. You can enable use of the
client MAC address instead of the default gateway address, by entering the following command.
Virtual ADX(config)#server l7-dont-use-gateway-mac
Syntax: [no] server l7-dont-use-gateway-mac
Enabling transparent VIP
Transparent VIP allows you to configure a Brocade Virtual ADX to transparently load balance a VIP,
without owning the VIP address. Multiple Brocade Virtual ADX devices on which this virtual server is
configured to be transparent can load balance requests for the server.
To configure an individual virtual server for the transparent VIP feature, enter a command such as
the following.
Virtual ADX(config-vs-TransVIP)#transparent-vip
Syntax: [no] transparent-vip
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
117
2
Miscellaneous options
Enabling SYN ACK threshold
The SYN ACK threshold specifies the number of contiguous unacknowledged TCP SYN ACKs the
Brocade Virtual ADX allows to accumulate for a real server, before determining that the server is
down and marking it FAILED. For examples and configuration information, refer to “Reassign
threshold” on page 220.
Syntax: server reassign-threshold number
The number variable specifies the number of contiguous unacknowledged TCP SYN ACKs for the
threshold. Enter an integer from 6 to 4000. By default, the Brocade Virtual ADX assigns a threshold
value of 20.
Replacing the source MAC address of the packet
When you configure the server source-mac-replacement command, if the incoming and outgoing
SLB traffic belongs to different VLANs, the source MAC address of the packet will be replaced using
the Brocade Virtual ADX’s MAC address.
Virtual ADX(config)#server source-mac-replacement
Syntax: [no] server source-mac-replacement
Cloning real servers
To simplify configuration for large server farms, you can clone real servers. When you clone a real
server, you make a copy of the real server 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.
Virtual ADX(config)#server real rs1 10.2.3.4
Virtual ADX(config-rs-rs1)#clone-server rs2 10.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 10.6.7.8.
Syntax: [no] clone-server name ip-addr
• The name variable specifies the name of the clone.
• The ip-addr variable specifies the IP address of the clone.
NOTE
To delete a server clone, you must manually edit the startup-config file to remove the command. The
no option is not supported for this command.
118
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Miscellaneous options
2
Configuring a host range
If you want to use the Unlimited VIP feature to load balance a large set of contiguous IP addresses
on the real server, configure a host range to create a range of contiguous virtual IP addresses
(VIPs) based on the VIP address of the virtual server. The Brocade Virtual ADX creates the range by
creating the number of VIPs that you specify with this command. You do not specify a range; you
specify the number of hosts in the range. The beginning address in the range is always the VIP. The
IP addresses must be contiguous on the real server.
To define a range of 256 contiguous VIPs, enter commands such as the following.
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server real-name r1 10.4.4.4
ADX(config-rs-r1)#host-range 256
ADX(config-rs-r1)#exit
ADX(config)#server real-name r2 10.4.4.5
ADX(config-rs-r2)#host-range 256
ADX(config-rs-r2)#exit
ADX(config)#server virtual-name-or-ip lotsofhosts 10.157.22.99
ADX(config-vs-lotsofhosts)#host-range 256
ADX(config-vs-lotsofhosts)#exit
Defining a host range simplifies configuration by allowing you to enter a single command or Web
option for the whole range of addresses instead of entering information for each address
individually.
You must also configure a corresponding range of addresses on the virtual server.
To configure a host range on a real server.
Virtual ADX(config)#server real-name r1 10.0.0.1
Virtual ADX(config-rs-r1)#host-range 20
This command configures a range of 20 IP addresses, from 10.0.0.1 through 10.0.0.20.
Syntax: [no] host-range num
Unbinding all application ports from virtual servers
By default, a real server application ports remain bound to the virtual servers to which you bind
them. You can unbind all of a real server’s application ports from the virtual servers.
To unbind a real server application ports, enter the following command at the configuration level for
the server.
Virtual ADX(config-rs-R1)#port unbind-all
Syntax: port unbind-all
NOTE
Once you unbind the ports, you can rebind them only on an individual virtual server and port basis.
Identifying VIP port as TCP only or UDP only
You can explicitly identify an application port to be "TCP only" or "UDP only." The "TCP only" port
accepts connections that arrive on TCP transport and drops connections that arrive on UDP
transport. The ports that are identified as "UDP only" ports accept connections only on UDP
transport:
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
119
2
Miscellaneous options
• Allow "TCP only" or "UDP only" port definitions under virtual server
• Allow similar definitions under real server also
On a Brocade Virtual ADX, when a port is defined under VIP, both UDP and TCP traffic with the port
number are enabled and passed through to the real server. This scenario is not desirable in some
cases.
As an enhancement, the user is allowed to define a TCP-only or UDP-only port so that only TCP or
UDP traffic with the specified port number can pass through. TCP-only or UDP-only traffic control
has been supported internally on a Brocade Virtual ADX, but no CLI is available for the user to
enable it.
As the enhancement, the following commands allow the user to enable or disable TCP-only or
UDP-only traffic control for a port defined under VIP.
Syntax: [no] port port tcp-only | udp-only
The command is available under VIP configuration mode.
When either TCP-only or UDP-only is configured, only TCP traffic or UDP traffic can pass through as
configured; otherwise both TCP traffic and UDP traffic can pass through. TCP-only and UDP-only are
exclusive, which means when TCP-only is configured, TCP-only and UDP-only cannot be configured
for a particular port at the same time. UDP-only will be automatically disabled if TCP-only is
configured, and vice versa.
Enabling fast aging for UDP sessions
When fast aging for UDP sessions is configured, a client request causes the Brocade Virtual ADX to
add an entry to its session table; when a response is detected, the Brocade Virtual ADX
immediately deletes the session table entry.
NOTE
Fast aging is the default behavior for the well-known DNS and RADIUS ports. To change DNS or
RADIUS to use the UDP age timer instead, refer to “Setting TCP and UDP ages for VIPs” on page 121.
When this feature is configured, if the Brocade Virtual ADX detects a server response to a client
request, and the response is not fragmented, the session table entry is deleted immediately. If the
response is fragmented, the Brocade Virtual ADX waits for the last fragment to arrive, forwards it to
the client, and then sends the session to the delete queue. By default, the session stays in the
delete queue for 8 seconds before being deleted. You can change the amount of time the session
stays in the delete queue to between 1 and 40 seconds.
To activate fast aging for UDP sessions for port 1234, enter commands such as the following.
Virtual ADX(config)#server virtual-name-or-ip vs1 192.168.1.2
Virtual ADX(config-vs-vs1)#port 1234 udp-fast-age
Syntax: port UDP-portnum udp-fast-age
To set the amount of time sessions for ports configured with the udp-fast-age command stay in the
delete queue before being deleted, enter the following command.
Virtual ADX(config)#server msl 2
Syntax: server msl secs
The secs variable can be from 1 to 40 seconds.
120
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Miscellaneous options
2
Enabling normal UDP aging for DNS and RADIUS
By default, the Brocade Virtual ADX immediately deletes a UDP DNS or RADIUS session table entry
when the Brocade Virtual ADX receives a reply for the application from a real server. You can
configure the Brocade Virtual ADX to instead age out DNS or RADIUS sessions normally using the
UDP age timer.
To age DNS or RADIUS sessions using the UDP age timer, enter the following command at the
global CONFIG level of the CLI.
Virtual ADX(config-vs-VIP1)#port dns udp-normal-age
Syntax: [no] port dns | radius udp-normal-age
For DNS and RADIUS UDP load balancing, unless the port is configured with this command, the
DNS or RADIUS sessions are always aged out after two minutes.
NOTE
By default, a Brocade Virtual ADX will exercise normal-age for DNS and RADIUS if the response is
fragmented traffic from a real server. If you would like to enable the fast-age feature for fragmented
traffic as well as non-fragmented traffic, you need to explicitly configure the udp-fast-age command
on the port level.
Setting TCP and UDP ages for VIPs
The TCP and UDP ages specify how many minutes a TCP or UDP session can remain inactive before
the Brocade Virtual ADX closes the session and clears the session from its session table. You can
set the TCP or UDP ages for a specific virtual server, and you can set the TCP or UDP ages for an
individual port on a virtual server.
NOTE
The session age is per minute and has a one minute range. For example, if you configured a TCP or
UDP age of three minutes for a virtual server, the age timeout is from two to three minutes.
For example, to set the TCP age for virtual server v1 to 20 minutes, enter the following commands.
Virtual ADX(config)#server virtual-name-or-ip v1
Virtual ADX(config-vs-v1)#tcp-age 20
Syntax: [no] tcp-age minutes
To set the UDP age for virtual server v1 to 26 minutes, enter the following commands.
Virtual ADX(config)#server virtual-name-or-ip v1
Virtual ADX(config-vs-v1)#udp-age 26
Syntax: [no] udp-age minutes
To set the TCP age for the HTTP port on virtual server v1 to 10 minutes, enter the following
commands.
Virtual ADX(config)#server virtual-name-or-ip v1
Virtual ADX(config-vs-v1)#port http tcp-age 10
Syntax: [no] port port tcp-age minutes
To set the UDP age for the SNMP port on virtual server v1 to 26 minutes, enter the following
commands.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
121
2
Miscellaneous options
Virtual ADX(config)#server virtual-name-or-ip v1
Virtual ADX(config-vs-v1)#port snmp udp-age 26
Syntax: [no] port port udp-age minutes
You can set the TCP or UDP age from 2 through 60 minutes. The default TCP age is 30 minutes. The
default UDP age is five minutes.
More specific settings override more general settings; that is, a TCP or UDP age setting for the HTTP
port will override a TCP or UDP age setting for the virtual server, which will override the global TCP
or UDP age (set with the server tcp-age or server udp-age commands).
Configuring session aging behavior
In stateful (default) mode, sessions are created when traffic flows through the Brocade Virtual ADX.
Two sessions are created for each flow: “forward” session (In Layer4 SLB, Client to VIP), and
“reverse” session (In Layer4 SLB, Real-Server to Client). These two sessions are tied together. Each
session has an associated time after which the session is marked for removal. The session age is
refreshed each time there is a new packet on the flow. The default mechanism to delete sessions is
when both forward and reverse sessions reach their age limit.
You can use the following commands to change the default session aging behavior.
To age out forward and reverse sessions independently use the following command,
Virtual ADX(config)#server one-way-session-age
Syntax: server one-way-session-age
If one session ages out, delete that session but do not delete the other session.
To delete both sessions when any of the sessions ages out use the following command.
Virtual ADX(config)#two-way-session-age-on-one-age
Syntax: server two-way-session-age-on-one-age
Configuring DNS CPU-based throttling
DNS request processing time can become very slow when CPU utilization is at a high level (90 95%). With this feature you can direct a Brocade Virtual ADX to reject new DNS requests when CPU
utilization goes beyond a configured threshold.
You can set DNS CPU-based throttling as shown.
Virtual ADX(config)#server throttle-on-overload 40
Syntax: [no] server throttle-on-overload cpu-percentage
The cpu-percentage variable specifies the threshold of CPU utilization when the Brocade Virtual
ADX will reject new DNS requests.
Limitation
This feature is applicable for UDP DNS only.
122
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Miscellaneous options
2
NOTE
CPU utilization is not collected for every packet but every second. Consequently, the throttling
decision might not always be accurate. Because of this, CPU utilization might go higher than the set
threshold in some situations.
Configuring UDP DNS count connection
When a client’s UDP DNS traffic follows a pattern such that the 4 tuples (Source IP, Destination IP,
Source Port, Dest Port) are exactly the same across multiple DNS requests, the Brocade Virtual
ADX will have an issue. This is because the 5 tuples (SIP, DIP, SP, DP and protocol) based on which
a new session is created by the Brocade Virtual ADX is no longer unique for the subsequent
connections but will match the existing connection created by the first DNS request. When the first
response is received from the real server, the session which was used by the multiple DNS
connections will be deleted as expected. This leads to the subsequent response from the real
server to not find a session and therefore will get the Layer 2 information forwarded instead of the
translation from real server to the virtual IP (VIP). This will result in DNS responses reaching the
client un-translated.
To resolve this, configure the Brocade Virtual ADX to keep a count of the number of UDP DNS
connections used by the session and to delete the session only when all the responses to this
session is received. Use the command at the global config level as shown.
Virtual ADX(config)#server dns-udp-count-connection
Syntax: [no] server dns-udp-count-connection
Dedicated next hop per VIP for reverse SLB traffic
This feature allows you to configure a default gateway for reverse SLB traffic at the Virtual server
level.
To configure a virtual server with a next hop gateway use the command shown in the following.
Virtual ADX(config)#server virtual-name-or-ip v1 10.1.1.1
Virtual ADX(config-vs-v1)#next-hop 10.1.1.100
Syntax: [no] next-hop next-hop-IPaddress
The next-hop-IPaddress variable specifies the IP address of the nest hop gateway for the virtual
server.
NOTE
The IP address specified for the next-hop-IPaddress must be directly connected to the Brocade
Virtual ADX.
You can also configure the virtual server to allow it to fall back to its default gateway as shown in
the following.
Virtual ADX(config)#server virtual-name-or-ip v1 10.1.1.1
Virtual ADX(config-vs-v1)#next-hop-allow-fallback-to-default-gateway
Syntax: [no] next-hop-allow-fallback-to-default-gateway
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
123
2
Miscellaneous options
VIP route health injection
VIP route health injection (RHI) allows the Brocade Virtual ADX to advertise the availability of an
IPv4 or IPv6 VIP address (instead of a real host) throughout the network. Multiple Brocade Virtual
ADX devices with identical VIP addresses and services can exist throughout the network. This
feature allows the Brocade Virtual ADX VIP to be used in lieu of the same VIP on other Brocade
Virtual ADX devices if the VIP is no longer healthy on those devices. A VIP can also provide the
services because it is logically closer to the client systems than the other Brocade Virtual ADX
devices.
Specifically, you can configure a Brocade Virtual ADX to check the health of a VIP configured on it
and inject a VIP route into the network to force a preferred route to the VIP. VIP RHI checks the VIP
health and reports one of the following:
• VIP is healthy. If the VIP is healthy, the Brocade Virtual ADX injects a VIP route into its route
table for the VIP. The Brocade Virtual ADX then advertises the route to other routers using an
IGP routing protocol, such as OSPF or OSFPv3.
• VIP is not healthy. The Brocade Virtual ADX removes the IP route to the VIP from its route table.
As a result, the route is withdrawn by the routing protocols and is no longer used by upstream
routers. The upstream routers instead use another route to the same VIP.
NOTE
IPv4 uses the OSPF routing protocol. For IPV6, the OSPFv3 routing protocol is used.
Routers receiving client traffic for the VIP select the best route to the VIP. As a result, clients enjoy
fast response time regardless of their location, because their gateway routers use the best path to
the VIP. RHI also prevents client traffic from being routed to a VIP that is unavailable.
VIP route health injection advertises the host route to the VIP instead of a network route to the VIP's
subnet. This approach ensures that the clients' gateway routers receive a route to the IP address
only if that VIP is available.
Configuration of VIP RHI is the same in most cases for IPv4 and IPv6 addresses. It is clearly shown
in the following sections where there are differences in configuration commands or procedures.
NOTE
Disabling the real ports of all real servers using the server disable-all-real command causes the
respective virtual port's RHI state to become "Not Healthy", and the VIP host route will not be
advertised. In contrast, when you disable the virtual port of virtual server, the RHI state of a virtual
port will not become "Not Healthy", and the Brocade Virtual ADX will keep advertising the VIP host
route.
Injecting and deleting VIP route based on VIP health
The route for a VIP is injected when the VIP was previously unhealthy and is now deemed to be
healthy. Similarly, the route for the VIP is withdrawn if it was previously healthy and is now down.
The health of a VIP is based on the health of its VIP ports. The health of a VIP port is based on the
health of the real server ports bound to that VIP port.
You can configure any of the traditional health checks supported for the real servers. When a real
server port fails the health check, the Brocade Virtual ADX will check if the real server port is bound
to a VIP port whose VIP has the RHI feature enabled. If so, the Brocade Virtual ADX will determine
how many real server ports bound to the VIP port are healthy. If the amount is below the threshold
(if percentage threshold is configured) or if none of the other real server ports are healthy (if
124
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Miscellaneous options
2
percentage threshold is not configured), then the VIP port will be declared unhealthy. If you have
configured the option where a VIP should be considered healthy if at least one VIP port is healthy,
then the Brocade Virtual ADX will check if there are any other healthy VIP ports. If there are none, it
will delete the VIP route. If you have not configured this option (a VIP should be considered healthy
only if all VIP ports are healthy), then the Brocade Virtual ADX will delete the VIP route.
Similarly, when a real server port transitions from the failed to the active state, the Brocade Virtual
ADX will check if the real server port is bound to a VIP port whose VIP has the RHI feature enabled.
If this is the case, the Brocade Virtual ADX will determine how many real server ports bound to the
VIP port are healthy. If you have configured a percentage threshold, and if this number is above the
threshold, then Brocade Virtual ADX will declare this VIP port healthy. If you have not configured a
threshold, then the Brocade Virtual ADX will declare this VIP healthy. If you have configured the
option where a VIP should be considered healthy if at least one VIP port is healthy and the VIP was
previously unhealthy, then it will inject the VIP route. If you have not configured this option (a VIP
should be considered healthy only if all VIP ports are healthy), then the Brocade Virtual ADX will
check if all other VIP ports are healthy. If they are, the Brocade Virtual ADX will inject the VIP route.
Configuration considerations
Before you enable RHI, consider the following three issues:
• Static route redistribution — It is required to redistribute the host route for the VIP into OSPF or
OSPFv3. To enable redistribution of static routes for IPv4, enter commands such as the
following:
Virtual ADX(config)#router ospf
Virtual ADX(config-ospf-router)#area 0
Virtual ADX(config-ospf-router)#redistribution static
Syntax: [no] redistribution static
To enable redistribution of static routes for IPv6, enter commands such as the following:
Virtual ADX(config)#ipv6 router ospf
Virtual ADX(config-ospf6-router)#redistribute static
Syntax: [no] redistribute static
• Disabling network route advertisement for an interface associated with VIP RHI — The ip
dont-advertise or ipv6 dont-advertise commands configure the Brocade Virtual ADX to block
advertisement of the network on the interface. If you do not block advertisement of the
network, the Brocade Virtual ADX will advertise a route to the network containing the VIP, even
if the VIP itself is unavailable. After you enter the ip dont-advertise command, the Brocade
Virtual ADX advertises only a host route to the VIP address. Therefore, if the VIP is not healthy,
the Brocade Virtual ADX will remove the static host route for the VIP address and also not
advertise a network route for the network containing the VIP address.
NOTE
When using the dont-advertise commands, the IP or IPv6 and subnet mask length should be
the same as the interface IP or IPv6 and subnet mask length.
For IPv4, enter commands similar to the following.
Virtual ADX(config)# interface ethernet 1
Virtual ADX(config-if-e1000-1)# ip address 10.1.1.99 255.255.255.0
Virtual ADX(config-if-e1000-1)# ip dont-advertise 10.1.1.99 255.255.255.0
Syntax: ip dont-advertise ip-addr mask I ip-addr/mask-bits
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
125
2
Miscellaneous options
For IPv6, enter commands similar to the following.
Virtual ADX(config)#interface loopback 1
Virtual ADX(config-lbif-1)#ipv6 address 2001:db8::1/64
Virtual ADX(config-lbif-1)#ipv6 dont-advertise 2001:db8::1/64
Syntax: ipv6 dont-advertise ipv6-prefix/prefix length
The following example of the display from the show ipv6 route command shows how
dont-advertise routes are represented for IPv6 routes. As shown, the route type for these
routes is “C (N)”.
Virtual ADX(config-lbif-3)#show ipv6 route
IPv6 Routing Table - 5 entries:
Type Codes: C - Connected, C(N) Connected(Dont-Advertise), S - Static, R RIP, O - OSPF, B - BGP, D - RA
Type IPv6 Prefix
Next Hop Router
Interface Dis/Metric
C
2001:DB8:3000::/64::
e 1
0/0
C
2001:DB8:4000::/64::
ve 40
0/0
C(N) 2001:DB8:4444::/64::
loopback 1
0/0
S
2001:DB8:4444::/96 2001:DB8:4444::110 loopback 1
1/1
C(N) 2001:DB8:6020::/78::
loopback 3
0/0
• Loopback interface, non-dangling VIPs, or dangling VIPs - For VIP RHI to work, you must
configure a loopback interface or VE interface in the same subnet as the VIP subnet
(non-dangling VIP) or configure the VIP without any associated interface (dangling VIP
described in “VIP RHI with dangling subnets” on page 130).
The loopback interface or VE interface must have the ip dont-advertise command configured.
The following example configures a loopback interface to support two VIPs.
Virtual server 1 IP: 10.1.152.65
Virtual server 2 IP: 10.1.152.66
If the subnet of the VIPs is /30 then you need to configure either a VE interface or a loopback
interface as follows:
Virtual ADX(config)#interface loopback 2
Virtual ADX(config-lbif-2)#ip address 10.1.152.67/28
Virtual ADX(config-lbif-2)#ip dont-advertise 10.1.152.67/28
Enabling or disabling VIP RHI
The Brocade Virtual ADX can enable VIP RHI globally or at the VIP sublevel for IPv4 hosts, IPv6
hosts or both. To enable VIP RHI feature globally for all IPv4 VIPs, enter commands such as the
following.
Virtual ADX(config)#server global-advertise-vip-route v4-only
To enable VIP RHI feature globally for all IPv6 VIPs, enter commands such as the following.
Virtual ADX(config)#server global-advertise-vip-route v6-only
Syntax: [no] server global-advertise-vip-route [v4-only | v6-only | both]
The v4-only parameter enables VIP RHI globally or at the VIP sublevel for IPv4 hosts.
The v6-only parameter enables VIP RHI globally or at the VIP sublevel for IPv6 hosts.
The both parameter enables VIP RHI globally or at the VIP sublevel for IPv4 and IPv6 hosts.
If none of these parameters are specified, VIP RHI is enabled globally for IPv4 hosts only.
126
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Miscellaneous options
2
NOTE
Where VIP hosts are classified as healthy, the Brocade Virtual ADX injects static host/subnet routes.
If a VIP is found to be unhealthy, RHI withdraws the static host/subnet route but the feature remains
enabled. Using the no server global-advertise-vip-route command (IPv4 and IPv6) disables RHI and
causes all routes that were injected by RHI because of the global-advertise command to be
withdrawn. Routes injected by local advertise will still be in effect and will override the global
advertise setting.
To enable VIP RHI for an individual virtual server, enter commands such as the following.
Virtual ADX(config)#server virtual-name-or-ip vs1
Virtual ADX(config-vs-vs1#advertise-vip-route
Syntax: [no] advertise-vip-route
NOTE
Where VIP hosts are classified as healthy, the Brocade Virtual ADX injects a static host/subnet
routes only for the VIP specified by the advertise-vip-route command. If a VIP is found to be
unhealthy, RHI withdraws the static host/subnet route for the host of the configured VIP but the
feature remains enabled. Using the no advertise-vip-route command causes any routes for this VIP
host injected by RHI to be withdrawn.
To disable VIP RHI for an individual virtual server, enter commands such as the following.
Virtual ADX(config)#server virtual-name-or-ip vs1
Virtual ADX(config-vs-vs1#disable-advertise-vip-route
Virtual ADX(config-vs-vs1)#end
Syntax: [no] disable-advertise-vip-route
This command is useful if you need to enable VIP RHI globally and disable it for a few virtual
servers.
NOTE
Due to certain design restrictions, we advise that users turn off the RHI feature before modifying an
interface configuration (on the interface to which the VIP is attached). After changes have been
made to the interface configuration, you can turn the RHI feature on again. Following this method
allows new VIP static routes to be recomputed and advertised while the old VIP routes are
withdrawn. Use the Global and Local VIP advertise commands to turn the RHI on and off.
Defining the health of a VIP port
There are two options for defining VIP port health:
• By default, a VIP port will be considered healthy as long as there is at least one healthy real
server port bound to it.
• You can define the percentage of bound real server ports that must be healthy in order to
consider the VIP port healthy.
When you define the percentage of bound real server ports that must be healthy in order to
consider the VIP port healthy, you can define this setting globally or per-VIP.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
127
2
Miscellaneous options
Defining the health of a VIP port globally
To globally define the percentage of bound real server ports that must be healthy to consider a VIP
port healthy, enter commands such as the following.
Virtual ADX(config)#server rhi-active-bindings-threshold 20
Syntax: [no] server rhi-active-bindings-threshold percent
Defining the health of a VIP port per VIP
To define the percentage of bound real server ports that must be healthy to consider a VIP port
healthy for a specific VIP, enter commands such as the following.
Virtual ADX(config)#server virtual-name-or-ip dns-p1
Virtual ADX(config-vs-dns-p1)#rhi-active-bindings-threshold 30
NOTE
The VIP level configuration applies to all Virtual ports on the configured virtual server.
Syntax: [no] rhi-active-bindings-threshold percent
A valid range for percent is 1 through 100.
If the percent variable is not set, the percentage is 0. In this case, the default method will be used
to determine the health of the VIP port. For example, a VIP port will be considered healthy as long
as there is at least one healthy real server port bound to it.
As another example, consider a virtual server 10.1.1.101 with the port http command configured.
This port http of the virtual server is bound to port http of real server 10.1.1.15 and port http of real
server 10.1.1.44. If you have not configured any active bindings threshold percentage, then port
http of VIP 10.1.1.101 will be considered healthy as long as at least one of the two bound real
server ports is healthy.
If you configure an active bindings threshold percentage of 100, then this setting requires all
bound real server ports for the VIP port to be healthy in order to consider the VIP port healthy. If real
server port http for real server 10.1.1.15 goes down, then VIP port http is no longer considered
healthy because only 50 percent of the bound real server ports are healthy. The configuration in
this example requires 100 percent of the bound real server ports to be up in order to consider the
VIP port as healthy.
Defining the health of a VIP
Multiple VIP ports can be configured for a VIP. There are two options provided for determining the
health of a VIP:
• By default, a VIP will be considered healthy if all VIP ports for the VIP are healthy.
• You can specify a VIP to be considered healthy as long as there is at least one healthy VIP port.
To specify that a VIP should be considered healthy if at least one VIP port is healthy, enter
commands such as the following.
Virtual ADX(config)#server rhi-one-vip-port-up
Syntax: [no] server rhi-one-vip-port-up
If this command is not configured, a VIP will be considered healthy only if all VIP ports are healthy.
128
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Miscellaneous options
2
NOTE
If a VIP port is not bound to any real server ports, it will not be used for deciding the health of the VIP.
If a VIP port is bound but you do not want to use it to determine the health of the VIP as described
above, then configure the following for the VIP port.
Virtual ADX(config)#server virtual-name-or-ip dns-p1
Virtual ADX(config-vs-dns-p1)#port ftp rhi-dont-use-port
Syntax: [no] port port rhi-dont-use-port
As another example, assume the port http and port ftp commands have been configured for virtual
server vs1. You then bind port ftp of real server rs1 and port ftp of real server rs2 to port ftp of
virtual server vs1. Similarly, you bind port http of real server rs1 and port http of real server rs2 to
port http of virtual server vs1. If you need to base the health of the VIP vs1 only on the health of the
VIP port http, then you can configure the following for the port ftp.
Virtual ADX(config)#server virtual-name-or-ip vs1
Virtual ADX(config-vs-dns-p1)#port ftp rhi-dont-use-port
As a result, only the health of port http of virtual server vs1 will be used to determine the health of
virtual server vs1 and consequently to determine if the VIP route for vs1 should be injected or
withdrawn.
Configuring the VIP RHI Route Mask Length
You can configure the subnet mask length that VIP RHI injects into the routing table for a specific
virtual server by entering a command such as the following.
Virtual ADX(config)#server virt virt-2
Virtual ADX(config-vs-virt-2)#vip-route-subnet-mask-length 28
Syntax: [no] vip-route-subnet-mask-length length
The ipv4-subnet-mask-length variable specifies the IPv4 subnet mask length of VIP RHI injected
route for this virtual server. This parameter must have a value between interface subnet mask
length and 32.
The ipv6-subnet-mask-length variable specifies the IPv6 subnet mask length of VIP RHI injected
route for this virtual server. This parameter must have a value between interface subnet mask
length and 128.
The server global-vip-route-mask-length command that configured the VIP RHI route mask length at
a global level has been deprecated. This configuration will be translated to VIP level mask length
under each individual VIP during image upgrade.
NOTE
The VIP-RHI mask length should not be less than the interface subnet mask length.
Depending on the interface mask length and the vip-route-mask length there can be either a host
route or single/dual subnet routes to this VIP host.
Virtual ADX(config-vs-virt-2)#vip-route-subnet-mask-length 28
For example, If you have a VIP host with the IPv6 address “2001:DB8::10” configured over a
loopback interface with the IPv6 address “2001:DB8::1/64” will, by default, RHI inject a static host
route as shown.
S 2001:DB8::10/128
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
2001:DB8::10
loopback 1 1/1
129
2
Miscellaneous options
If you configure a vip-route-mask-length as “96” then when this VIP becomes healthy, an IPv6
subnet route with a mask length of “96” is advertised as shown.
S 2001:DB8::/96
2001:DB8::10
loopback 1 1/1
Where a user configures the vip-route-subnet-mask-length to the same values as the interface
mask length, RHI injects two subnet static routes instead of one. In this situation the user will see
two routes instead of one. For example, if the interface subnet mask length is “64” and the user
configures the vip-subnet-mask-length as “64”, two routes will be advertised as shown below.
S 2001:DB8::/65
S 2001:DB8::80:0:0:0/65
2001:DB8::10
2001:DB8::10
loopback 1 1/1
loopback 1 1/1
Please note the subnet mask length of the above routes. When the user changes the VIP subnet
mask length to and from being equal to the interface subnet mask length, the VIP static route
injected will be corrected between dual routes and a single static route. This dual route extension
was created to accommodate a larger range/number of VIP hosts within a subnet.
NOTE
One exception to the above dual route case is where value of the vip-route-subnet-mask-length
command exceeds 125. In this situation, RHI will only inject host static routes.
NOTE
Use caution while configuring the vip-route-subnet-mask-length command value. Please make sure
that the VIP subnets do not overlap with each other.
VIP RHI with dangling subnets
Normally a VIP with RHI should have an associated interface with an interface address (IPv4 or
IPv6) belonging to the VIP subnet. This means that at least one IP address belonging to the VIP
subnet is consumed by the interface and cannot be used as a public address for the VIP server and
RHI has to depend on having an associated interface.
A user who does not wish to waste one public IP address to the interface can do so without adding
any IP address in the VIP subnet. In this situation the VIP is deemed to be a “dangling VIP” (not
associated with any interface). If the user adds an IP address in the VIP subnet to an interface,
such a VIP is called a “non-dangling VIP”. The Brocade Virtual ADX supports both dangling and
non-dangling VIPs. RHI determines the mode of the VIP at the time when advertise is enabled. The
routes advertised also differ slightly in case of dangling VIPs as described in the following:
• Non-dangling VIPs: RHI will associate with the matching interface and set boundaries for the
VIP route to be advertised. In this case, RHI makes sure that it does not advertise a route
bigger than the size of the associated subnet itself. This also includes advertising of dual
routes. This configuration also allows dynamic-sym-priority to be bound with an associated
interface status.
• Dangling VIPs: RHI will use the VIP-route-subnet-mask-length and blindly advertise a static
route of that size. A user will see static routes with the next hop address as 255.255.255.255
in case of IPv4 VIP and :: (invalid IPv6 address) for an IPv6 VIP. In case of IPv4 the port value of
the route shows “drop” and for IPv6 the port is “null”. In this mode dynamic-sym-priority is not
bound to interface status.
130
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Miscellaneous options
2
The following examples display how the output from the show ip route command will differ for the
same destination address for non-dangling and dangling VIPs. Notice that for dangling VIPs the
“gateway” is specified as a non-valid route (IPv4 and IPv6). Also, the “interface” is specified as
“drop” for IPv4 and “null” for IPv6. Display of these values is normal for dangling VIPs.
Example of non-dangling VIPs
Virtual ADX#show
Total number
Start index:
default
Destination
1
10.1.1.0
ip route
of IP routes: 1
1 B:BGP D:Connected R:RIP S:Static O: OSPF *:Candidate
NetMask
Gateway
255.255.255.0 10.1.1.105
Port
1b1
Cost
1
Type
S
Virtual ADX#show ipv6 route
IPv6 Routing Table - 1 entrie:
Type Codes: C - Connected, S - Static, R - RIP, O - OSPF, B - BGP, D - RA
Typ IPv6 Prefix
Next Hop Router
Interface
Dis/Metric
S
2001:db8::10/128 2001:db8::10
loopback 1
1/1
Example of dangling VIPs
Virtual ADX#show ip route
Total number of IP routes: 1
Start index: 1 B:BGP D:Connected R:RIP S:Static O: OSPF *:Candidate
default
Destination
NetMask
Gateway
Port
Cost
Type
10.1.1.0
255.255.255.0 255.255.255.255
drop
1
S
Virtual ADX#show ipv6 route
IPv6 Routing Table - 1 entrie:
Type Codes: C - Connected, S - Static, R - RIP, O - OSPF, B - BGP, D - RA
Typ IPv6 Prefix
Next Hop Router
Interface Dis/Metric
S
2001:db8::/64
::
null
1/1
Important caveats.
• Order of configuration is important in RHI. A user should choose between the two available
modes (dangling and non-dangling) first and configure the interface and VIP RHI accordingly.
• Changing the interface configuration (for example: adding or deleting an IP address in the VIP
subnet or disabling the interface) while the RHI is active is not recommended.
• To change the mode of the VIP, a user must remove RHI advertise first, change the interface
configuration and then re-enable the RHI configuration. RHI computes the mode only at the
time of enabling the RHI advertise option.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
131
2
Miscellaneous options
VIP RHI and high availability topologies
• Hot Standby topology - VIP RHI is only supported on the Brocade Virtual ADX Router (R)
platform. A Hot Standby topology is not supported for the R code base. Therefore, VIP RHI is not
applicable to Hot Standby topologies.
• Symmetric and sym-active topologies - In both symmetric and sym-active topologies, only the
owner of the VIP (the VIP in the active state) will inject the route. In this topology, the Brocade
Virtual ADX will withdraw the VIP route when a VIP transitions from Active to standby state.
Similarly, the Brocade Virtual ADX will inject the VIP route when a VIP transitions from Standby
to Active, if the VIP is healthy at the time of the transition.
Optionally, you can enable a Brocade Virtual ADX to inject a VIP route inside the routing process
regardless of its VIP ownership status. Enter the following command if you want to enable both
Brocade Virtual ADX devices to inject VIP route regardless of its ownership.
Virtual ADX(config)#server rhi-inject-always
Syntax: [no] server rhi-inject-always
Displaying route type
When VIP RHI is enabled for a virtual server, the VIP host route type is shown as "S:Static". The
reason for doing this is the Brocade Virtual ADX can use redistribute static of routing protocols
(OSPF and RIP for IPv4 and OSPFv3 for IPv6) to advertise the VIP host route.
When the network route advertisement is disabled, the Brocade Virtual ADX shows the route's type
as “D(N).”
The following output of the show ip route command is from a Brocade Virtual ADX with VIP RHI
enabled.
.
Virtual ADX#show ip route
Total number of IP routes: 11
Start index: 1 B:BGP D:Connected R:RIP S:Static O:OSPF *:Candidate
default
Destination
NetMask
Gateway
Port
Cost
1
10.20.1.0
255.255.255.0
0.0.0.0
v2
1
2
10.30.0.0
255.255.0.0
10.40.1.101
v1
2
3
10.40.1.0
255.255.255.0
0.0.0.0
v1
1
4
10.50.1.0
255.255.255.0
0.0.0.0
v4
1
5
10.60.1.0
255.255.255.0
0.0.0.0
v3
1
6
10.60.1.10
255.255.255.255 10.60.1.10
v3
1
7
10.70.1.0
255.255.255.0
0.0.0.0
3/12
1
8
10.70.1.10
255.255.255.255 10.70.1.10
3/12
1
9
10.80.1.0
255.255.255.0
10.20.1.101
v2
2
10
10.90.1.0
255.255.255.0
0.0.0.0
3/12
1
11
10.90.1.10
255.255.255.255 10.90.1.10
3/12
1
132
Type
D
O
D
D(N)
D(N)
S
D(N)
S
O
D(N)
S
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Miscellaneous options
2
The following snap shot of the show ipv6 route command was taken from a Brocade Virtual ADX
with VIP RHI enabled.
Virtual ADX(config)#show ipv6 route
IPv6 Routing Table - 6 entries:
Type Codes: C - Connected, C(N) Connected(Dont-Advertise), S - Static, R - RIP,
O - OSPF, B - BGP, D - RA
Type IPv6 Prefix
Next Hop Router
Interface Dis/Metric
C
2001:db8:2001::/64::
ve 20
0/0
S
2001:db8:3001::/642001:db8:4001::101ve 40
1/1
C
2001:db8:3500::/64::
e 1/11
0/0
C
2001:db8:4001::/64::
ve 40
0/0
C(N)2001:db8:5000::/64::
loopback 1
0/0
C
2001:db8:bbbb::/64::
e 1/9T
0/0
Dob-4U-SI-A(config)#
NOTE
Some administrators might view this approach as a contradiction to the basic definition of a route
type. The route type of a network that is owned by a Brocade Virtual ADX (router) is usually shown as
"D:connected" and a manually added static route type is to be shown as “S:Static.”
Configuration examples
Consider the example where VIP 10.1.1.10 is configured on three Brocade Virtual ADX devices (A, B
and C). The following is the step-by-step VIP RHI configuration for Brocade Virtual ADX A.
1. Ensure a routing protocol is running, such as OSPF.
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADXA(config)#vlan 9
ADXA(config-vlan-9)#untagged ethernet 1
ADXA(config-vlan-9)#router-interface ve 1
ADXA(config-vlan-9)#exit
ADXA(config)#router ospf
ADXA(config-ospf-router)#area 0
ADXA(config-ospf-router)#redistribution static
ADXA(config-ospf-router)#exit
ADXA(config)#interface ve 1
ADXA(config-ve-1)#ip address 10.211.21.11 255.255.255.0
ADXA(config-ve-1)#ip ospf area 0
ADXA(config-ve-1)#exit
2. Configure the interface associated with the VIP.
Virtual
Virtual
Virtual
Virtual
ADXA(config)#interface loopback 1
ADXA(config-lbif-1)#ip address 10.1.1.99 255.255.255.0
ADXA(config-lbif-1)#ip dont-advertise 10.1.1.99 255.255.255.0
ADXA(config-lbif-1)#exit
3. Enable the real servers and ports.
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADXAconf t
ADXAconfig)#server real rs1 10.1.1.20
ADXA(config-rs-rs1)#port http
ADXA(config-rs-rs1)#exit
ADXA(config)#server real rs2 10.1.1.30
ADXA(config-rs-rs2)#port http
ADXA(config-rs-rs2)#exit
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
133
2
Miscellaneous options
4. Set the VIP, bind VIP ports to real server ports, and enable VIP RHI.
Virtual
Virtual
Virtual
Virtual
Virtual
ADXA(config)#server virtual-name-or-ip vip-vadx-A 10.1.1.10
ADXA(config-vs-vip-vadx-A)#port http
ADXA(config-vs-vip-vadx-A)#bind http rs1 http rs2 http
ADXA(config-vs-vip-vadx-A)#advertise-vip-route
ADXA(config-vs-vip-vadx-A)#exit
The configuration is similar for Brocade Virtual ADX B and C (with relevant interface IP addresses).
Both Brocade Virtual ADX sites working in primary mode
FIGURE 22
Primary mode
Site 1 configuration
!
global-protocol-vlan
!
!
server predictor round-robin
server global-advertise-vip-route v4-only
server rhi-active-bindings-threshold 80
134
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Miscellaneous options
2
server port 21
tcp
server port 80
tcp
server port 53
udp
server port 161
udp
server port 25
tcp
server port 443
tcp
server port 8601
tcp
!
!
server real rs1 10.20.1.40
port http
port http url "HEAD /"
port ftp
port smtp
port dns
port dns zone "example9.com"
port snmp
port mms
port rtsp
!
server real rs2 10.20.1.41
port http
port http url "HEAD /"
port ftp
port smtp
port dns
port dns zone "example9.com"
port snmp
port mms
port rtsp
!
server real Web1 10.60.1.40
port 8601
!
server real Web2 10.60.1.41
port 8601
!
server real Web3 10.60.1.42
port 8601
!
server real Web4 10.60.1.43
port 8601
!
server real Web5 10.60.1.44
port 8601
!
server real Web6 10.60.1.45
port 8601
!
server real Web7 10.60.1.46
port 8601
!
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
135
2
Miscellaneous options
server real Web8 10.60.1.47
port 8601
!
server real Web9 10.60.1.48
port 8601
!
server real Web10 10.60.1.49
port 8601
!
server remote-name rem1 10.80.1.40
port 8601
port ftp
port smtp
port ssl
port dns
port dns zone "example9.com"
port snmp
port mms
port rtsp
!
server remote-name rem2 10.80.1.41
port 8601
port ftp
port smtp
port ssl
port dns
port dns zone "example9.com"
port snmp
port mms
port rtsp
!
!
server virtual-name-or-ip vip60 10.60.1.10
port http
bind http Web1 8601 Web2 8601 Web3 8601 Web4 8601
bind http Web5 8601 Web6 8601 Web7 8601 Web8 8601
bind http Web9 8601 Web10 8601
!
server virtual-name-or-ip vip90 10.90.1.10
vip-route-subnet-mask-length 28
port dns
port snmp
port http
port ftp
bind dns rem1 dns rem2 dns
bind snmp rem1 snmp rem2 snmp
bind http rem1 8601 rem2 8601
bind ftp rem1 ftp rem2 ftp
!
server virtual-name-or-ip vip20 10.20.1.10
disable-advertise-vip-route
port http
port dns
port snmp
port ftp
bind http rs1 http rs2 http
bind dns rs1 dns rs2 dns
bind snmp rs1 snmp rs2 snmp
bind ftp rs1 ftp rs2 ftp
136
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Miscellaneous options
2
!
vlan 1 name DEFAULT-VLAN by port
!
vlan 10 by port
untagged ethe 1
router-interface ve 1
!
vlan 20 by port
untagged 2
router-interface ve 2
!
vlan 30 by port
untagged ethe 3
router-interface ve 3
!
hostname Site1-VADX
router ospf
area 0
metric-type type1
redistribution connected
redistribution static
!
interface loopback 1
ip address 10.100.100.100 255.255.255.255
ip ospf area 0
!
interface ve 1
ip address 10.40.1.120 255.255.255.0
ip address 10.40.1.121 255.255.255.0 secondary
ip ospf area 0
!
interface ve 2
ip address 10.20.1.120 255.255.255.0
ip address 10.20.1.121 255.255.255.0 secondary
ip ospf area 0
!
interface ve 3
ip address 10.60.1.120 255.255.255.0
ip dont-advertise 10.60.1.120 255.255.255.0
ip address 10.60.1.121 255.255.255.0 secondary
ip dont-advertise 10.60.1.121 255.255.255.0
!
end
Site 2 configuration
!
global-protocol-vlan
!
!
server predictor round-robin
server global-advertise-vip-route v4-only
server rhi-active-bindings-threshold 80
server port 21
tcp
server port 80
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
137
2
Miscellaneous options
tcp
server
udp
server
udp
server
tcp
server
tcp
server
tcp
!
!
port 53
port 161
port 25
port 443
port 8601
server real rs1 10.120.1.40
port http
port http url "HEAD /"
port ftp
port smtp
port dns
port dns zone "example9.com"
port snmp
port mms
port rtsp
!
server real rs2 10.120.1.41
port http
port http url "HEAD /"
port ftp
port smtp
port dns
port dns zone "example9.com"
port snmp
port mms
port rtsp
!
server real
port 8601
!
server real
port 8601
!
server real
port 8601
!
server real
port 8601
!
server real
port 8601
!
server real
port 8601
!
server real
port 8601
!
server real
port 8601
138
Web1 10.60.1.40
Web2 10.60.1.41
Web3 10.60.1.42
Web4 10.60.1.43
Web5 10.60.1.44
Web6 10.60.1.45
Web7 10.60.1.46
Web8 10.60.1.47
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Miscellaneous options
2
!
server real Web9 10.60.1.48
port 8601
!
server real Web10 10.60.1.49
port 8601
!
!
server remote-name rem1 10.180.1.40
port 8601
port ftp
port smtp
port ssl
port dns
port dns zone "example9.com"
port snmp
port mms
port rtsp
!
server remote-name rem2 10.180.1.41
port 8601
port ftp
port smtp
port ssl
port dns
port dns zone "example9.com"
port snmp
port mms
port rtsp
!
!
server virtual-name-or-ip vip60 10.60.1.10
port http
bind http Web1 8601 Web2 8601 Web3 8601 Web4 8601
bind http Web5 8601 Web6 8601 Web7 8601 Web8 8601
bind http Web9 8601 Web10 8601
!
server virtual-name-or-ip vip90 10.90.1.10
vip-route-subnet-mask-length 28
port dns
port snmp
port http
port ftp
bind dns rem1 dns rem2 dns
bind snmp rem1 snmp rem2 snmp
bind http rem1 8601 rem2 8601
bind ftp rem1 ftp rem2 ftp
!
server virtual-name-or-ip vip120 10.120.1.10
disable-advertise-vip-route
port http
port dns
port snmp
port ftp
bind http rs1 http rs2 http
bind dns rs1 dns rs2 dns
bind snmp rs1 snmp rs2 snmp
bind ftp rs1 ftp rs2 ftp
!
!
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
139
2
Miscellaneous options
vlan 1 name DEFAULT-VLAN by port
!
vlan 10 by port
untagged ethe 1
router-interface ve 1
!
vlan 20 by port
untagged ethe 2
router-interface ve 2
!
vlan 30 by port
untagged ethe 3
router-interface ve 3
!
hostname Site2-VADX
!
router ospf
area 0
metric-type type1
redistribution connected
redistribution static
!
interface loopback 1
ip address 10.100.100.101 255.255.255.255
ip ospf area 0
!
interface ve 1
ip address 10.140.1.120 255.255.255.0
ip address 10.140.1.121 255.255.255.0 secondary
ip ospf area 0
!
interface ve 2
ip address 10.120.1.120 255.255.255.0
ip address 10.120.1.121 255.255.255.0 secondary
ip ospf area 0
!
interface ve 3
ip address 10.60.1.120 255.255.255.0
ip dont-advertise 10.60.1.120 255.255.255.0
ip address 10.60.1.121 255.255.255.0 secondary
ip dont-advertise 10.60.1.121 255.255.255.0
!
!
end
140
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Miscellaneous options
2
Site 1 Brocade Virtual ADX in primary mode and Site 2 Brocade Virtual ADX in backup mode
FIGURE 23
Primary mode and backup mode
Site 1 configuration
!
global-protocol-vlan
!
!
server predictor round-robin
server global-advertise-vip-route v4-only
server rhi-active-bindings-threshold 80
server
tcp
server
tcp
server
udp
server
udp
port 21
port 80
port 53
port 161
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
141
2
Miscellaneous options
server port 25
tcp
server port 443
tcp
server port 8601
tcp
!
!
server real rs1 10.20.1.40
port http
port http url "HEAD /"
port ftp
port smtp
port dns
port dns zone "example9.com"
port snmp
port mms
port rtsp
!
server real rs2 10.20.1.41
port http
port http url "HEAD /"
port ftp
port smtp
port dns
port dns zone "example9.com"
port snmp
port mms
port rtsp
!
server real Web1 10.60.1.40
port 8601
!
server real Web2 10.60.1.41
port 8601
!
server real Web3 10.60.1.42
port 8601
!
server real Web4 10.60.1.43
port 8601
!
server real Web5 10.60.1.44
port 8601
!
server real Web6 10.60.1.45
port 8601
!
server real Web7 10.60.1.46
port 8601
!
server real Web8 10.60.1.47
port 8601
!
server real Web9 10.60.1.48
port 8601
!
server real Web10 10.60.1.49
port 8601
!
142
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Miscellaneous options
2
server remote-name rem1 10.80.1.40
port 8601
port ftp
port smtp
port ssl
port dns
port dns zone "example9.com"
port snmp
port mms
port rtsp
!
server remote-name rem2 10.80.1.41
port 8601
port ftp
port smtp
port ssl
port dns
port dns zone "example9.com"
port snmp
port mms
port rtsp
!
!
!
server virtual-name-or-ip vip60 10.60.1.10
port http
bind http Web1 8601 Web2 8601 Web3 8601 Web4 8601
bind http Web5 8601 Web6 8601 Web7 8601 Web8 8601
bind http Web9 8601 Web10 8601
!
server virtual-name-or-ip vip90 10.90.1.10
vip-route-subnet-mask-length 28
port dns
port snmp
port http
port ftp
bind dns rem1 dns rem2 dns
bind snmp rem1 snmp rem2 snmp
bind http rem1 8601 rem2 8601
bind ftp rem1 ftp rem2 ftp
!
server virtual-name-or-ip vip20 10.20.1.10
disable-advertise-vip-route
port http
port dns
port snmp
port ftp
bind http rs1 http rs2 http
bind dns rs1 dns rs2 dns
bind snmp rs1 snmp rs2 snmp
bind ftp rs1 ftp rs2 ftp
!
vlan 1 name DEFAULT-VLAN by port
!
vlan 10 by port
untagged ethe 1
router-interface ve 1
!
vlan 20 by port
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
143
2
Miscellaneous options
untagged ethe 2
router-interface ve 2
!
vlan 30 by port
untagged ethe 3
router-interface ve 3
!
hostname Site1-VADX
router ospf
area 0
metric-type type1
redistribution connected
redistribution static
!
interface loopback 1
ip address 10.100.100.100 255.255.255.255
ip ospf area 0
!
interface ve 1
ip address 10.40.1.120 255.255.255.0
ip address 10.40.1.121 255.255.255.0 secondary
ip ospf area 0
!
interface ve 2
ip address 10.20.1.120 255.255.255.0
ip address 10.20.1.121 255.255.255.0 secondary
ip ospf area 0
!
interface ve 3
ip address 10.60.1.120 255.255.255.0
ip dont-advertise 10.60.1.120 255.255.255.0
ip address 10.60.1.121 255.255.255.0 secondary
ip dont-advertise 10.60.1.121 255.255.255.0
!
end
Site 2 configuration
!
global-protocol-vlan
!
!
healthck Site1-chk icmp
dest-ip 10.40.1.120
healthck Site1-NOT boolean
not Site1-chk
healthck Web1-8601-chk tcp
dest-ip 10.60.1.40
port 8601
protocol http
protocol http url "HEAD /"
interval 20
retries 4
l7-check
healthck Web2-8601-chk tcp
dest-ip 10.60.1.41
144
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Miscellaneous options
2
port 8601
protocol http
protocol http url "HEAD /"
interval 20
retries 4
l7-check
healthck Web3-8601-chk tcp
dest-ip 10.60.1.42
port 8601
protocol http
protocol http url "HEAD /"
interval 20
retries 4
l7-check
healthck Web4-8601-chk tcp
dest-ip 10.60.1.43
port 8601
protocol http
protocol http url "HEAD /"
interval 20
retries 4
l7-check
healthck Web5-8601-chk tcp
dest-ip 10.60.1.44
port 8601
protocol http
protocol http url "HEAD /"
interval 20
retries 4
l7-check
healthck Web6-8601-chk tcp
dest-ip 10.60.1.45
port 8601
protocol http
protocol http url "HEAD /"
interval 20
retries 4
l7-check
healthck Web7-8601-chk tcp
dest-ip 10.60.1.46
port 8601
protocol http
protocol http url "HEAD /"
interval 20
retries 4
l7-check
healthck Web8-8601-chk tcp
dest-ip 10.60.1.47
port 8601
protocol http
protocol http url "HEAD /"
interval 20
retries 4
l7-check
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
145
2
Miscellaneous options
healthck Web9-8601-chk tcp
dest-ip 10.60.1.48
port 8601
protocol http
protocol http url "HEAD /"
interval 20
retries 4
l7-check
healthck Web10-8601-chk tcp
dest-ip 10.60.1.49
port 8601
protocol http
protocol http url "HEAD /"
interval 20
retries 4
l7-check
healthck Web1-chk boolean
and Site1-NOT Web1-8601-chk
healthck Web2-chk boolean
and Site1-NOT Web2-8601-chk
healthck Web3-chk boolean
and Site1-NOT Web3-8601-chk
healthck Web4-chk boolean
and Site1-NOT Web4-8601-chk
healthck Web5-chk boolean
and Site1-NOT Web5-8601-chk
healthck Web6-chk boolean
and Site1-NOT Web6-8601-chk
healthck Web7-chk boolean
and Site1-NOT Web7-8601-chk
healthck Web8-chk boolean
and Site1-NOT Web8-8601-chk
healthck Web9-chk boolean
and Site1-NOT Web9-8601-chk
healthck Web10-chk boolean
and Site1-NOT Web10-8601-chk
!
server predictor round-robin
server global-advertise-vip-route v4-only
server rhi-active-bindings-threshold 80
server
tcp
server
tcp
server
udp
server
146
port 21
port 80
port 53
port 161
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Miscellaneous options
2
udp
server port 25
tcp
server port 443
tcp
server port 8601
tcp
!
!
!
server real rs1 10.120.1.40
port http
port http url "HEAD /"
port ftp
port smtp
port dns
port dns zone "example9.com"
port snmp
port mms
port rtsp
!
server real rs2 10.120.1.41
port http
port http url "HEAD /"
port ftp
port smtp
port dns
port dns zone "example9.com"
port snmp
port mms
port rtsp
!
server real Web1 10.60.1.40
port 8601
port 8601 healthck Web1-chk
!
server real Web2 10.60.1.41
port 8601
port 8601 healthck Web2-chk
!
server real Web3 10.60.1.42
port 8601
port 8601 healthck Web3-chk
!
server real Web4 10.60.1.43
port 8601
port 8601 healthck Web4-chk
!
server real Web5 10.60.1.44
port 8601
port 8601 healthck Web5-chk
!
server real Web6 10.60.1.45
port 8601
port 8601 healthck Web6-chk
!
server real Web7 10.60.1.46
port 8601
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
147
2
Miscellaneous options
port 8601 healthck Web7-chk
!
server real Web8 10.60.1.47
port 8601
port 8601 healthck Web8-chk
!
server real Web9 10.60.1.48
port 8601
port 8601 healthck Web9-chk
!
server real Web10 10.60.1.49
port 8601
port 8601 healthck Web10-chk
!
!
server remote-name rem1 10.180.1.40
port 8601
port ftp
port smtp
port ssl
port dns
port dns zone "example9.com"
port snmp
port mms
port rtsp
!
server remote-name rem2 10.180.1.41
port 8601
port ftp
port smtp
port ssl
port dns
port dns zone "example9.com"
port snmp
port mms
port rtsp
!
!
server virtual-name-or-ip vip60 10.60.1.10
port http
bind http Web1 8601 Web2 8601 Web3 8601 Web4 8601
bind http Web5 8601 Web6 8601 Web7 8601 Web8 8601
bind http Web9 8601 Web10 8601
!
server virtual-name-or-ip vip90 10.90.1.10
vip-route-subnet-mask-length 28
port dns
port snmp
port http
port ftp
bind dns rem1 dns rem2 dns
bind snmp rem1 snmp rem2 snmp
bind http rem1 8601 rem2 8601
bind ftp rem1 ftp rem2 ftp
!
server virtual-name-or-ip vip120 10.120.1.10
disable-advertise-vip-route
port http
port dns
148
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Miscellaneous options
2
port snmp
port ftp
bind http rs1 http rs2 http
bind dns rs1 dns rs2 dns
bind snmp rs1 snmp rs2 snmp
bind ftp rs1 ftp rs2 ftp
!
!
vlan 1 name DEFAULT-VLAN by port
!
vlan 10 by port
untagged ethe 1
router-interface ve 1
!
vlan 20 by port
untagged ethe 2
router-interface ve 2
!
vlan 30 by port
untagged ethe 3
router-interface ve 3
!
hostname Site2-VADX
router ospf
area 0
metric-type type1
redistribution connected
redistribution static
!
interface loopback 1
ip address 10.100.100.101 255.255.255.255
ip ospf area 0
!
interface ve 1
ip address 10.140.1.120 255.255.255.0
ip address 10.140.1.121 255.255.255.0 secondary
ip ospf area 0
!
interface ve 2
ip address 10.120.1.120 255.255.255.0
ip address 10.120.1.121 255.255.255.0 secondary
ip ospf area 0
!
interface ve 3
ip address 10.60.1.120 255.255.255.0
ip dont-advertise 10.60.1.120 255.255.255.0
ip address 10.60.1.121 255.255.255.0 secondary
ip dont-advertise 10.60.1.121 255.255.255.0
!
!
end
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
149
2
Application-specific SLB considerations
Application-specific SLB considerations
RTSP server load balancing
The Brocade Virtual ADX natively understands protocol RTSP and provides load balancing for it. The
Brocade Virtual ADX can also provide Layer 7 health checks for RTSP. Refer to “RTSP” on page 174
for details on Layer 7 health checks for RTSP.
If RTSP is bound to an unknown port, use the following command to provide RTSP server load
balancing.
Virtual ADX(config)#server rtsp-for-unknown-port
Syntax: [no] server rtsp-for-unknown-port
NOTE
The Brocade Virtual ADX supports RTSP client port values of up to 9999. If the client is using a port
number above 9999, you must configure the client to use a lower port value.
Deletion of UDP data session along with TCP control session
for RTSP
The Brocade Virtual ADX tracks both control and data sessions for RTSP regardless of the
underlying transport layer (TCP or UDP) used by these sessions. When the system deletes an RTSP
control session (TCP based), it also deletes the respective data session (which can be UDP based).
Use the following command to enable this functionality.
Virtual ADX(config)#server rtsp-delete-udp-with-tcp-sess
Syntax: [no] server rtsp-delete-udp-with-tcp-sess
TFTP load balancing
TFTP load balancing is supported with health checks.
The Brocade Virtual ADX can conduct Layer 3 and Layer 4 health checks for TFTP ports.
When you configure a TFTP port and bind it to a Virtual server, the Brocade Virtual ADX does a Layer
3 check, and if this check passes, it does a Layer 4 check.
To check the health of a TFTP port, the Brocade Virtual ADX sends out a request for the SIcheck.txt
file. The Brocade Virtual ADX does not actually interpret the reply packet. As long as it does not get
an "ICMP dest or port unreachable" message, the Brocade Virtual ADX keeps the TFTP port up. If it
gets an "ICMP unreachable" message, the Brocade Virtual ADX brings the TFTP port down.
150
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Show and debug commands
2
Show and debug commands
Refer to Appendix B, “SLB Show and Debug Commands” for a full list of show and debug
commands.
Displaying the BP distribution
To show how traffic is distributed across the multiple barrel processors for a given flow (IP
addresses and L4 ports), use the following syntax:
Syntax: show bp-distribution type-of-traffic source-ip dest-ip source-l4-port dest-l4-port protocol
The type-of-traffic variable can take various values depending on the configuration parameters of
the incoming traffic flow. The keywords for the type-of-traffic variable are listed as follows.
all
Specifies the Catch-ALL entry due to cpu-forward
frag
Specifies the Fragmentation entry
manual-holddown
Specifies the Manual-Holddown entry
real-server
Specifies the Real-Server entry (Reverse-SLB traffic)
source-ip
Specifies the Source-IP entry (Reverse-SLB traffic with Source-NAT)
static-nat
Specifies the Static-NAT entry (Forward Static-NAT traffic)
static-nat-reverse
Specifies the Reverse Static-NAT entry (Reverse Static-NAT traffic)
vip
Specifies the VIP entry (Forward SLB traffic)
vip-protection
Specifies the VIP-Protection entry
The following example shows how to calculate the BP for a reverse-SLB flow coming from
Real-Server (10.1.1.1:80) to Source-NAT-IP (10.5.5.5) and displays which barrel processor the
particular flow is landing on.
Virtual ADX(config)#show bp-distribution source-ip 10.1.1.1 10.5.5.5 80 2048
0 Packets for the specified flow map to: BP 1/1
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
151
2
152
Displaying the BP distribution
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Chapter
Stateless Server Load Balancing
3
Overview
This chapter describes server load balancing configuration options that are “stateless.” Stateless
SLB does not use session table entries for the TCP or UDP sessions between the Brocade Virtual
ADX and clients or real servers.
These configuration options are useful if you want to deploy multiple Brocade Virtual ADX devices
to provide service for the same VIPs or applications, but the network topology cannot ensure that
server responses will pass back through the Brocade Virtual ADX.
NOTE
The Direct Server Return (DSR) feature allows you to deploy a single Brocade Virtual ADX in a
network where the server responses do not pass back through the Brocade Virtual ADX. Compare
the configuration example for Direct Server Return with the examples in this chapter to determine
which type of configuration is applicable to your network. Refer to “Configuring Direct Server Return”
on page 57.
NOTE
The Brocade Virtual ADX does not support Stateless SLB with aliased ports, such as shown in the
following configuration:
server virtual-name-or-ip v3 10.176.7.23
port dns
port dns stateless
bind dns rs1 7777 real-port dns
Stateless TCP and UDP ports
You can configure a TCP application port to be stateless. When an application port is stateless, the
Brocade Virtual ADX does not create session table entries for the port. Configuring an application
port to be stateless results in the following benefits:
• The server responses for the application can use alternate paths back to the client. For
example, the Brocade Virtual ADX and real servers can be connected through a network that
provides multiple return paths to the client. Because the port is stateless, the Brocade Virtual
ADX does not assume that the application is unhealthy if the server’s response does not flow
back through the Brocade Virtual ADX.
• The Brocade Virtual ADX has more session resources available for application ports that need
them.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
153
3
Stateless TCP and UDP ports
NOTE
The Direct Server Return feature also allows server responses to take paths that do not pass back
through the Brocade Virtual ADX. However, Direct Server Return still uses session table resources
because the Brocade Virtual ADX creates a session table entry for the connection from the client to
the real server.
NOTE
The Brocade Virtual ADX supports port translation for stateless SLB. Port translation is useful when
clients connect to real servers directly. Without port translation, if a client connects to a real server
directly, the Brocade Virtual ADX automatically replaces the source IP address to a VIP. When you
configure port translation, the Brocade Virtual ADX overcomes the limitation of performing NAT on
all packets initiated from the real server. NAT does not occur because the Brocade Virtual ADX does
not match the port number.
NOTE
The Brocade Virtual ADX supports stateless SLB for any TCP and UDP application protocols. For a
TCP application, hashing must be enabled on the Brocade Virtual ADX. For a UDP application, you
can enable or disable hashing on the Brocade Virtual ADX.
NOTE
FTP and TFTP services do not maintain a fixed server port for responses. In such cases stateless
mode cannot be used.
How the Brocade Virtual ADX selects a real server
for a stateless port
The Brocade Virtual ADX does not use the standard SLB load-balancing methods when selecting a
real server for a stateless application port. Instead, it uses hash values to select a real server. The
Brocade Virtual ADX calculates the hash value for a given client request based on the request’s
source IP address and source TCP/UDP port.
The Brocade Virtual ADX has up to 8192 hash buckets (the default is 256) and divides the number
of buckets evenly among the real servers. When the Brocade Virtual ADX forwards a client’s
request for a stateless application port to the real server that corresponds to the calculated hash
value, the Brocade Virtual ADX does not change the source address of the client’s request, but
does change the destination address from the requested VIP into the real server’s IP address.
For example, when a Brocade Virtual ADX receives a request for TCP port 80 (HTTP) on VIP
(192.168.4.69) from client 10.161.1.88, the Brocade Virtual ADX calculates a hash value based on
10.161.1.88 and 80, then forwards the request to the real server that has the calculated hash
value. The request packet is in the following format:
•
•
•
•
154
Source IP: Client’s IP address
Source application port: Port number selected by client’s application
Destination IP: Real server’s IP
Destination application port: Port number requested by client
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Stateless TCP and UDP ports
3
If client 10.161.1.88’s Web browser sent the request from TCP port 8080, and the Brocade Virtual
ADX’s hash calculation resulted in selecting real server 10.10.10.2, the packet would have the
following address values:
•
•
•
•
Source IP: 10.161.1.88
Source application port: 8080
Destination IP: Real server’s IP 10.10.10.2
Destination application port: 80
Because the client’s request contains the client’s IP address and application port, the real server
can send the packet back to the client along any valid routing path. The request does not need to
pass back through the Brocade Virtual ADX that forwarded the request. In fact, the Brocade Virtual
ADX that forwards the requests to the transparent VIP does not create session table entries for the
requests.
Because the Brocade Virtual ADX does not maintain state information for the requests for stateless
application ports, the Brocade Virtual ADX does not care whether the server response for a
stateless port passes back through the Brocade Virtual ADX on the way to the client. For a normally
configured VIP, the server’s response passes back though the Brocade Virtual ADX. For a
transparent VIP, the response does not necessarily pass back through the Brocade Virtual ADX.
NOTE
Because the Brocade Virtual ADX does not create session table entries for requests to the stateless
application port, you cannot use Brocade Virtual ADX features that use information from the session
table. For example, you cannot use source NAT, port translation, and similar features.
Configuring the stateless hash table size
You can configure the size of the stateless hash table as shown in the following:
Virtual ADX(config)#server real R1 10.10.10.1
Virtual ADX(config-rs-R1)#server stateless-hash-table-size 1024
Syntax: [no] server stateless-hash-table-size table-size
The table-size variable can be set to any of the following values: 256, 512, 1024, 2048, 4096, or
8192.
The default value is 256.
Configuring a stateless application port
To configure an application port to be stateless, enable the stateless parameter on the port in the
virtual server as shown in the following example.
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server real R1 10.10.10.1
ADX(config-rs-R1)#port http
ADX(config-rs-R1)#exit
ADX(config)#server real R2 10.10.11.1
ADX(config-rs-R2)#port http
ADX(config-rs-R2)#exit
ADX(config)#server virtual-name-or-ip StatelessHTTP 192.168.4.69
ADX(config-vs-StatelessHTTP)#port http stateless
ADX(config-vs-StatelessHTTP)#bind http R1 http
ADX(config-vs-StatelessHTTP)#bind http R2 http
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
155
3
Stateless TCP and UDP ports
Syntax: [no] port tcp/udp-portnum stateless
The tcp/udp-portnum variable specifies the application port you want to make stateless.
Disabling the stateless SLB hashing algorithm for UDP ports
By default, stateless SLB uses a hashing algorithm to select a real server. The Brocade Virtual ADX
calculates a hash value for a given client request based on the request’s source IP address and
source TCP/UDP port. The request is sent to a real server corresponding to this hash value.
For UDP connections consisting of one client packet and one server response packet, you can
disable the stateless SLB hashing algorithm. When the stateless SLB hashing algorithm is disabled
for UDP ports, the Brocade Virtual ADX uses the round-robin load balancing method to select a real
server for the request. In this case, the Brocade Virtual ADX load balances UDP packets destined
for the VIP without creating a session and without calculating hash values based on UDP port
number and source IP address.
DNS is an example of a UDP port where this feature can be used. The advantage of disabling the
stateless SLB hashing algorithm is that a new real server can be selected immediately after it is
brought up.
For example, to disable the stateless SLB hashing algorithm for the DNS port (UDP port 53), enter
commands such as the following:
Virtual ADX(config)#server virtual-name-or-ip Stateless 192.168.4.69
Virtual ADX(config-vs-Stateless)#port dns stateless no-hash
Syntax: [no] port udp-portnum stateless no-hash
NOTES: When this command is applied, in some cases it will not take affect. This occurs if the
sessions are stuck and it requires you to clear the sessions first and then apply the command, as
described in the following.
1. Disable the real server and unbind the VIP.
2. Clear the sessions using the clear server sessions real server name command.
3. Apply the stateless no-hash command, bind the real servers to the VIP and enable the real
server.
Configuring a port to be both stateless and stateful
You can use the stateless option when configuring an application port on a virtual server to make
that port stateless. By default, the port is stateless for both TCP and UDP. You can also specify the
protocol for which you want the port to be stateless. For example, you can configure port DNS to be
stateless for TCP while remaining stateful for UDP, by entering commands such as the following.
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server real R1 10.10.10.1
ADX(config-rs-R1)#port http
ADX(config-rs-R1)#exit
ADX(config)#server real R2 10.10.11.1
ADX(config-rs-R2)#port http
ADX(config-rs-R2)#exit
ADX(config)#server virtual-name-or-ip StatelessDNS 192.168.4.69
ADX(config-vs-StatelessDNS)#port dns stateless tcp
ADX(config-vs-StatelessDNS)#bind dns R1 dns
ADX(config-vs-StatelessDNS)#bind dns R2 dns
Syntax: [no] port tcp/udp-port [stateless [tcp | udp] [no-hash]]
156
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Stateless TCP and UDP ports
3
The tcp/udp-port variable specifies the application port you want to make stateless.
The stateless parameter configures the port to be stateless.
The tcp | udp parameter restricts stateless operation to the specified protocol (TCP or UDP).
The no-hash parameter disables the SLB hashing mechanism for the port (and protocol, if
specified). When hashing is disabled, the Brocade Virtual ADX uses the round-robin load balancing
method to select a real server for each request.
Clearing a virtual port’s stateless hash table
You need to clear the virtual port’s stateless hash table after a specified time interval anytime a
binded real server port becomes active (from a non-active state) in order to incorporate the port
into the stateless hash table. Use the command as shown in the example:
Virtual ADX(config)#server virtual-name-or-ip StatelessDNS 192.168.4.69
Virtual ADX(config-vs-StatelessDNS)#port dns stateless clear-stateless-hash 1000
Syntax: [no] port tcp/udp-port stateless clear-stateless-hash timeout
The timeout variable is specified in number of seconds. Enter an integer from 0 to 65535.
Fragmentation support in the stateless mode
By default, fragmentation is not supported in the stateless server load balancing mode.
Consequently, fragmented packets are dropped. This feature allows you to configure fragmentation
support for a specified port in the stateless mode.
This support is necessary in situations where packets exceed the default size and need to be
fragmented. For example, DNSSEC adds security headers in the DNS response that make the
packet exceed the default packet size (512 Bytes) which causes packet fragmentation. Because of
this, DNSSEC messages will be dropped unless Fragmentation support is enabled.
Configuring fragmentation support in the stateless mode
Using this feature, stateless fragmentation support can be provided for a specified port within a
VIP. To enable fragmentation support in the stateless mode, use the following command.
Virtual ADX(config)#server virtual v1 10.10.10.1
Virtual ADX(config-vs-v1)#port dns stateless frag-support
Syntax: [no] port port-name stateless frag-support
The port-name variable specifies the port in the stateless mode that is being enabled for
fragmentation.
Feature limitations
• One real server cannot be bound to multiple VIPs even for a different service. This means that,
given a real server IP, there is only one VIP that is bound to this real server.
• Fragmented pass-through traffic is not supported.
• For L7 switching for a different port under the same VIP, Brocade highly recommends using
another VIP.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
157
3
Stateless TCP and UDP ports
• Connections originating from real server ports other than the ports configured on the Brocade
Virtual ADX as real server ports are not supported when fragmented.
Example
VIP: 10.11.1.1:80
rs1 10.1.1.1:80 and rs2 10.1.1.2:80
In this configuration, packets from rs1 and rs2 with a source port other than port 80 will exhibit
unpredictable behavior when they are fragmented.
In these cases, configure the virtual server as a statefull virtual server.
158
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Chapter
Health Checks
4
Health checks overview
The Brocade Virtual ADX uses Layer 3, Layer 4, and Layer 7 health checks to verify the availability of
real servers and of applications on the real servers.
When you configure a real server, the Brocade Virtual ADX first sends an ARP request for the real
server and then sends an IP ping to the server, to verify that the Brocade Virtual ADX can reach the
server through the network. The ARP request is sometimes referred to as a Layer 2 health check
because the request is for the real server’s hardware layer address.
Later, when you bind the real server to a Virtual IP (VIP) server, the Brocade Virtual 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 Virtual ADX sends an HTTP Layer
7 health check to bring up the HTTP port on the real server.
The Brocade Virtual ADX performs the health checks described above by default. In addition, you
can enable periodic Layer 4 or Layer 7 keepalive health checks for individual application ports.
After successful bringup of an application port when you bind a real server to a virtual server, the
Brocade Virtual ADX repeats the Layer 4 or Layer 7 keepalive health check to continually verify the
health of the port.
Layer 3 health checks
Layer 3 health checks consist of ICMP-based IP pings and ARP requests. When you configure a real
server on the Brocade Virtual ADX, the Brocade Virtual ADX sends an ARP request and an IP ping to
the real server to verify that the Brocade Virtual ADX can reach the server through the network.
The Brocade Virtual ADX also sends an IP ping to a real server in the following circumstances:
• If the ARP entry for the server times out, the Brocade Virtual ADX uses the IP ping to create a
new ARP entry for the server. The ARP request is sometimes referred to as a Layer 2 health
check because the request is for the real server’s hardware layer address.
• If the time between the last packet sent to the server and the last packet received from the
server increases, the Brocade Virtual ADX uses the IP ping to determine whether the slowed
response time indicates loss of the server. If the server responds to the ping, the Brocade
Virtual ADX then sends a Layer 4 or Layer 7 health check, depending on whether the port’s
application type is known to the Brocade Virtual ADX. The Brocade Virtual ADX sends pings at
an interval of 2 seconds apart, and retries unsuccessful pings up to 4 times by default. You can
change the ping interval and retries if desired. Refer to “Modifying the ping interval and ping
retries” on page 161.
The following Layer 3 health check types are supported:
• ARP Request
• IP Ping
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
159
4
Layer 3 health checks
Table 13 summarizes the Layer 3 health checks.
TABLE 13
Summary of Layer 3 health checks
Type
Description
When performed
ARP request
A standard IP ARP request for the server’s MAC
address, which the Brocade Virtual ADX adds to its
ARP table.
•
When you configure a real server
IP ping
A standard ICMP-based IP ping.
•
•
•
When you configure a real server
If the ARP entry ages out
If the time between the last packet
sent to the server and the last packet
received from the server increases
Disabling Layer 3 health checks
By default, when you add a real server configuration to the Brocade Virtual ADX, the Brocade
Virtual ADX uses a Layer 3 health check (IP ping) to determine the server’s reachability. If the real
server responds to the ping, the Brocade Virtual ADX changes the server’s state to ACTIVE and
begins using the server for client requests.
You can globally disable the Layer 3 health check for local servers or remote servers. You also can
disable the Layer 3 health check on individual real servers. When you disable the Layer 3 health
check, the Brocade Virtual ADX sends an ARP request for the default gateway and makes the
server’s state ACTIVE for as long as the ARP entry remains in the Brocade Virtual ADX’s ARP cache.
To globally disable the Layer 3 health check for all local real servers, enter the following command.
Virtual ADX(config)#server no-real-l3-check
Syntax: [no] server no-real-l3-check
To globally disable Layer 3 health check for all remote real servers or of IP addresses learned
through GSLB, enter the following command.
Virtual ADX(config)#server no-remote-l3-check
Syntax: [no] server no-remote-l3-check
NOTE
The server no-remote-l3-check command also disables Layer3 health checks of IP addresses
learned through GSLB.
To disable the Layer 3 health check on an individual real server, enter the following command.
Virtual ADX(config-rs-R1)#no-l3-check
Syntax: [no] no-l3-check
This command applies to local real servers and remote real servers.
160
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Layer 4 health checks
4
Modifying the ping interval and ping retries
The Brocade Virtual ADX automatically uses a Layer 3 health check, consisting of ICMP echo
requests (pings), to check the health of a real server. Ping is enabled by default. However, you can
modify the ping interval and the number of retries.
To modify the ping interval, enter the following command.
Virtual ADX(config)#server ping-interval 8
Syntax: [no] server ping-interval value
The value variable can be a value from 1 through 10 seconds. The default is 2 seconds.
To modify the number of times the Brocade Virtual ADX will ping a real server before changing the
server state to FAILED, enter the following command.
Virtual ADX(config)#server ping-retries 7
Syntax: [no] server ping-retries value
The value variable can be a value from 2 through 10. The default retry value is 4.
Setting the Periodic ARP Interval
You can configure the periodic ARP interval.The default interval for periodic ARPs is 20 seconds. To
configure the periodic ARP interval, use the following command.
Virtual ADX(config)#server periodic-arp-interval 14400
Syntax: server periodic-arp-interval seconds
The seconds variable specifies the ARP interval. Enter an integer from 10 to 14400.
Layer 4 health checks
When you bind a real server to a virtual server, the Brocade Virtual ADX performs either a Layer 4
TCP health check, a Layer 4 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 Virtual ADX, the Brocade Virtual ADX uses a Layer 4 health check.
Otherwise, the Brocade Virtual 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 Virtual ADX checks the TCP port’s health based on a TCP
three-way handshake:
-
The Brocade Virtual ADX sends a TCP SYN packet to the port on the real server.
The Brocade Virtual ADX expects the real server to respond with a SYN ACK.
If the Brocade Virtual ADX receives the SYN ACK, the Brocade Virtual ADX sends a TCP
RESET, satisfied that the TCP port is alive.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
161
4
Layer 4 health checks
• UDP health check – The Brocade Virtual 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 Virtual ADX
concludes that the port is not alive.
-
If the server does not respond at all, the Brocade Virtual ADX assumes that the port is alive
and received the garbage data. Because UDP is a connectionless protocol, the Brocade
Virtual ADX and other clients do not expect replies to data sent to a UDP port, so a lack of
response indicates a healthy port.
NOTE
The Brocade Virtual ADX assumes that a port is a UDP port unless you configure the port as a TCP
port. To configure a port as a TCP port, add a port profile for the port and specify the port type TCP.
Refer to “Basing a port’s health on the health of another port” on page 220.
After the Brocade Virtual ADX sends an initial packet (TCP or UDP) to the server to bring the port up,
the Brocade Virtual ADX waits one second and then checks for a response from the server. If no
response is received during that time, the Brocade Virtual ADX will send another packet. The time
at which the Brocade Virtual ADX sends the second packet depends on the number of ports being
brought up at that time. The Brocade Virtual ADX will send the second packet after it has sent initial
packets to all the other ports being brought up at that time.
By default, the Brocade Virtual ADX does not repeat the Layer 4 health check after bringing up the
port when you bind the real server to the virtual server. However, you can enable a periodic
keepalive health check for the port. To configure the keepalive health check globally, configure a
port profile for the port. You also can enable or disable the keepalive health check on individual
real servers.
The following Layer 4 health check types are supported:
• TCP
• UDP
162
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Layer 4 health checks
4
Table 14 describes the Layer 4 health check types performance and its description.
TABLE 14
Summary of Layer 4 health checks
Type
When performed
Description
TCP
•
When you bind a TCP application
port on a real server to a TCP
application port on a virtual server
At regular intervals, if keepalive is
enabled for the port and the port
does not have a Layer 7 health
check
The Brocade Virtual ADX attempts to engage in a normal
three-way TCP handshake with the port on the real server:
• The Brocade Virtual ADX sends a TCP SYN packet to the
port on the real server.
• The Brocade Virtual ADX expects the real server to
respond with a SYN ACK.
• If the Brocade Virtual ADX receives the SYN ACK, the
Brocade Virtual ADX sends a TCP RESET, satisfied that
the TCP port is alive.
When you bind a UDP application
port on a real server to a UDP
application port on a virtual server
At regular intervals, if keepalive is
enabled for the port and the port
does not have a Layer 7 health
check
The Brocade Virtual 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 Virtual ADX concludes that the
port is not alive.
• If the server does not respond at all, the Brocade
Virtual ADX assumes that the port is alive and received
the garbage data. Since UDP is a connectionless
protocol, the Brocade Virtual ADX and other clients do
not expect replies to data sent to a UDP port. Thus, lack
of a response is a good outcome.
•
UDP
•
•
Performing Layer 4 UDP keepalive health checks
for the DNS port
You can configure the Brocade Virtual ADX to perform Layer 4 UDP keepalive health checks for the
DNS port (port 53).
To do this globally for the DNS port on all real servers, enter the following commands:
Virtual ADX(config)#server port dns
Virtual ADX(config-port-dns)#udp l4-check-only
NOTE
The l4-check-only command does not apply to the RADIUS protocol.
By default, the Brocade Virtual ADX performs a Layer 4 TCP health check whenever the DNS port on
a real server is brought up.
To configure the Brocade Virtual ADX to perform a Layer 4 UDP health check on the DNS port
whenever it is brought up, add the no tcp keepalive enable command to the DNS port profile as in
the following example:
Virtual ADX(config)#server port dns
Virtual ADX(config-port-dns)#no tcp keepalive enable
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
163
4
Layer 4 health checks
Server response threshold health check
The Brocade Virtual ADX distributes traffic among real servers based on a dynamic weight value
derived from the caculated response time of health check packets. Using the same calculated
response times, the Brocade Virtual ADX can perform Layer 4 and Layer 7 health checks.
The Brocade Virtual ADX calculate Layer 4 and Layer 7 response times and compares those with
the configured response threshold. If the calculated response time is greater than the configured
response threshold, the port is marked DOWN.
The Brocade Virtual ADX calculates Layer 4 and Layer 7 response times differently:
• Layer 4 response times (round trip times) measure the time between the sending of a SYN
packet and receiving a SYN ACK packet.
• Layer 7 response times measure the time between the L7 request and the first response
packet returned to the server. In the case of an LDAP server, this is the time between a bind
request and bind reply. For HTTP servers, this is the time between sending a GET or HEAD
request and the first packet received from server.
The calculated response time is compared to a user-configured response threshold. You can
configure a Layer 4 response threshold, a Layer 7 response threshold, or a combined Layer 4 and
Layer 7 response threshold.
To define the server response threshold, enter commands such as the following.
Virtual ADX(config)#server real r1 192.168.20.43
Virtual ADX(config-rs-r1)#port http response-threshold layer4 200
Virtual ADX(config-rs-r1)#port http response-threshold layer7 800
Syntax: [no] response-threshold {layer4 | layer7 | layer4&7} threshold-value
The layer4 keyword specifies a Layer 4 response threshold. The layer7 keyword specifies a Layer 7
response threshold. The layer4&7 keyword specifies combined Layer 4 and 7 response threshold.
The threshold-value variable is the server response threshold in microseconds. Enter an integer
from 1 to 50,000.
Debugging and testing
The show server real command displays health check counters for the port and all servers which
you can use when you test or debug response threshold health checks.
Syntax: show real server portnum | port-name
164
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Layer 4 health checks
4
To display configuration information and statistics for the real server configured on the Brocade
Virtual ADX, enter the following command:
Virtual ADX(config)#show server real http
HTTP keepalive statistics:
HTTP statistics:
URL replace cs: test = 3, fail = 0, malloc fail = 0
checksum: tested = 1, fail = 0, malloc fail = 0
No free ka port = 0, content match alloc fail = 0
Content match malloc = 0, free = 0
Bring port down = 0, retries = 0
TCP bring up statistics:
send buf alloc fail = 0, tcp send fail = 0
Test ka port index null = 0, Tcp conn ka index null = 0
Server close = 0
Suc: ka port index null = 0
test port index null: suc cb = 0, rec cb = 0, fail cb = 0
TCP keepalive statistics:
tcb alloc = 0, free = 0, fail = 0
tcb free when state: not active = 0, not bind = 0
suc cb : real port null = 0, ka port null = 0, ka port invalid = 0
rec cb : real port null = 0, ka port null = 0, ka port invalid = 0
fail cb : real port null = 0, ka port null = 0, ka port invalid = 0
conn compl cb : real port null=0, ka port null = 0, ka port invalid =0
tcb mismatch: suc cb = 0, rec cb = 0, fail cb = 0, conn compl cb = 0
real port null = 0, ka port mismatch = 0, ka port invalid = 0
send buf alloc fail = 0, tcp send fail = 0
Server close = 0
Real port not match = 0
TCP statistics:
tcp keep alive: close connection 0, remote close 0
tcp connect: connection exist 0, out of tcb 0
tcb: alloc 4, free 0
Slot index 4
Real server name = r1,
Real port Status = NOT BOUND
Slot valid = TRUE
IP: 10.10.10.10
Real port index = 7,
Real port no = 80
Tcp request = 0,
Tcp response = 0
Tcp response timeout = 0,
Keepalive Enabled
HTTP URL = "HEAD /example1.com"
HTTP sent = 0,
Received ok = 0
HTTP received error = 0,
Receive timeout = 0
wait for response = FALSE,
Status code = 0
Server close = 0,
Current sent = 0
Bring port down = 0,
Total retries = 0
TCP RTT = 0 us,
Appl RTT = 0 us
Current TCP RTT = 0 us,
Current Appl RTT = 0 us
Bring port down for RTT= 0
Next slot index = 0
The fields in bold provides the following information:
• The Bring port down for RTT field displays the number of times the port has been marked down
because it has exceeded the configured response threshold. This can be Layer 4, Layer 7, or
combined Layer 4 and 7.
• The Current TCP RTT field displays in microseconds the current TCP round trip time. If this
value exceeds the configured l4 response threshold, the port is brought down.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
165
4
Layer 7 health checks
• The Current Appl RTT field displays in microseconds the current application round trip time. If
this value exceeds the configured l7 response threshold, the port is brought down.
• The TCP RTT field is a smoothed l4 round trip time that is used by the response time predictor.
• The Appl RTT field is a smoothed l7 round trip time that is used by response time predictor.
Displaying health check related error messages
The server debug hc-error command, when enabled, displays health-check related error messages
to the console.
Syntax: server debug hc-error
Layer 7 health checks
For certain TCP and UDP application ports, the Brocade Virtual ADX can send application-specific
health checks to determine the health of the application. For example, the Brocade Virtual ADX can
send user-configurable HTTP requests to real servers to assess the health of the servers.
When you bind a real server to a virtual server using an application port that is known to the
Brocade Virtual ADX, the Brocade Virtual ADX sends a Layer 7 health check to the application on
the real server to bring up the application port.
By default, if a client requests a TCP/UDP port that is not available, the Brocade Virtual ADX does
not send an ICMP “Destination Unreachable” message to the client. For HTTP traffic, you can
configure the Brocade Virtual ADX to send such a message to the client by enabling the ICMP
Message feature for HTTP. Refer to “Sending ICMP Port Unreachable or Destination Unreachable
messages” on page 113 for details.
You can enable a Layer 7 health check globally by configuring a port profile or locally by enabling
the health check on an individual real server. In addition, you can customize some types of Layer 7
health checks for individual real servers. For example, you can specify a URL that the Brocade
Virtual ADX should request on a specific real server when sending the Layer 7 HTTP health check to
that server.
The following Layer 7 health check types are supported:
•
•
•
•
•
•
•
•
•
•
•
•
•
166
“DNS” on page 168
“FTP” on page 169
“HTTP (status code)” on page 169
“HTTP (content verification)” on page 170
“HTTP (status code)” on page 169
“HTTP (content verification)” on page 170
“Scripted (content verification for unknown ports)” on page 170
“IMAP4” on page 171
“LDAP” on page 171
“MMS” on page 172
“NNTP” on page 173
“PNM” on page 173
“POP3” on page 173
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Layer 7 health checks
•
•
•
•
•
•
4
“RADIUS” on page 174
“RTSP” on page 174
“SMTP” on page 175
“SSL (complete)” on page 175
“SSL (simple)” on page 176
“Telnet” on page 176
Application ports
The Brocade Virtual ADX selects a Layer 4 or Layer 7 health check based on whether the
application port is known to the Brocade Virtual ADX. A Layer 4 health check is a TCP or UDP
request and is not related to a specific application. A Layer 7 health check is an application-aware
health check designed for the specific application. The following application ports are known to the
Brocade Virtual ADX. The Brocade Virtual ADX performs Layer 7 health checks for these ports. For
other ports, the Brocade Virtual ADX performs a Layer 4 TCP or UDP health check instead.
• FTP (port 21). Ports 20 and 21 both are FTP ports but on the Brocade Virtual ADX, the name
“FTP” corresponds to port 21.
•
•
•
•
•
•
•
•
•
•
•
HTTP (port 80)
IMAP4 (port 143)
LDAP (port 389)
MMS (port 1755)
NNTP (port 119)
PNM (port 7070)
POP3 (port 110)
RTSP (port 554)
SMTP (port 25)
SSL (port 443)
TELNET (port 23)
UDP ports include the following:
• DNS (port 53)
• RADIUS (port 1812)
• RADIUS-OLD (port 1645), which is used in some older RADIUS implementations instead of port
1812
NOTE
You can add either port 1812 or port 1645 to a given real or virtual server, but you cannot add
both ports to the same server.
The keepalive health checks are disabled by default. To enable a keepalive health check for an
application port, configure a port profile for the port (which automatically enables the keepalive
globally for the port) or enable the keepalive on individual real servers that use the port.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
167
4
Layer 7 health checks
DNS
The Brocade Virtual ADX performs one or both of the following types of DNS health checks:
• Address-based – The Brocade Virtual ADX sends an address request for a specific domain
name. If the server successfully responds with the IP address for the domain name, the server
passes the health check.
• Zone-based – The Brocade Virtual ADX sends a Start-of-Authority (SOA) request for a specific
zone name. If the server is authoritative for the zone and successfully responds to the SOA
request, the server passes the health check.
NOTE
If you configure both types of DNS health check for a server, the server must successfully respond
to both health checks to remain in the server rotation. You enable each type of DNS health check on
a global basis and configure them on an individual server basis.
• If the server replies with the requested IP address or zone name, the Brocade Virtual ADX
considers the server port to be ACTIVE and marks it as such.
• If the server does not reply with the requested IP address or zone name, the Brocade Virtual
ADX retries the health check up to the number of times configured (the default is two retries). If
the server still does not send the requested information, the Brocade Virtual ADX marks the
DNS port on the server FAILED and removes the server from the rotation for DNS services.
NOTE
By default, the health check is non-recursive. If the real server (DNS server) does not successfully
reply to the health check, then the DNS port fails the health check. You can enable the real server
to perform a recursive lookup for the IP address or zone requested by the health check. In this case,
if the real server does not have the requested address or zone, the server can pass the request on
to a DNS server with higher authority. Refer to “Enabling recursive DNS health checks” on page 179.
Performed:
• Immediately following a successful Layer 4 UDP health check
• At regular intervals, if keepalive is enabled for the port
Configuration
To perform a health check on a DNS port, use a configuration such as the following.
Example
Virtual ADX(config-port-dns)#show run | b 53
server port 53
udp keepalive 15 3
tcp keepalive disable
server real rs1 10.2.2.200
port dns
port dns keepalive
port dns addr_query "www.brocade.com"
server virtual-name-or-ip test 10.2.2.222
sticky-age 60
port dns
168
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Layer 7 health checks
4
bind dns linux dns rs1 dns
!
end
NOTE
If the addr_query or zone has a “.” at the end, the Brocade Virtual ADX will return “invalid packet”
for Layer 7 DNS health check.
FTP
The Brocade Virtual ADX waits for a message from the server:
• If the server sends a greeting message with status code 220, the Brocade Virtual ADX resets
the connection and marks the port ACTIVE.
• If the server does not send a greeting message with status code 220, the Brocade Virtual ADX
retries the health check up to the number of times configured (the default is two retries). If the
server still does not send the expected message, the Brocade Virtual ADX marks the server
port FAILED and removes the server from the load-balancing rotation for FTP service.
Performed:
• Immediately following a successful Layer 4 TCP health check
• At regular intervals, if keepalive is enabled for the port
HTTP (status code)
The Brocade Virtual ADX sends HTTP GET or HEAD requests to HTTP servers when using SLB.
The GET or HEAD request specifies a page (identified by the URL, “Universal Resource Locator”) on
the server. By default, the Brocade Virtual ADX sends a HEAD request for the default page, “1.0”.
• If the server responds with an acceptable status code, the Brocade Virtual ADX resets the
connection and marks the port ACTIVE. For SLB, the default acceptable status codes for the
check are 200 through 299 and 401.
• If the server responds with a different status code, the Brocade Virtual ADX marks the HTTP
port FAILED.
• If the server does not respond, the Brocade Virtual ADX retries the health check up to the
number of times configured (the default is two retries). If the server still does not respond, the
Brocade Virtual ADX marks the server port FAILED and removes the server from the
load-balancing rotation for HTTP service.
NOTE
You can change the status code range for individual servers. If you do so, the defaults are removed
and only the status code ranges you specify cause the server to pass the health check.
Performed:
• Immediately following a successful Layer 4 TCP health check
• At regular intervals, if keepalive is enabled for the port
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
169
4
Layer 7 health checks
HTTP (content verification)
The Brocade Virtual ADX sends HTTP GET or HEAD requests to HTTP servers when using SLB.
The GET or HEAD request specifies a page (identified by the URL) on the server. The Brocade Virtual
ADX examines the page and compares the contents of the page to a list of user-defined selection
criteria.
Based on the results of this comparison, the Brocade Virtual ADX takes one of the following actions
with respect to port 80 (HTTP) on the real server:
• If the page meets the criteria for keeping the port up, then the Brocade Virtual ADX marks the
port ACTIVE. This means that the HTTP application has passed the health check.
• If the page meets the criteria for bringing the port down, then the Brocade Virtual ADX marks
the port FAILED.
• If the page meets none of the selection criteria, then the Brocade Virtual ADX marks the port
either ACTIVE or FAILED according to a user-defined setting.
Refer to “Configuring HTTP content matching lists” on page 208 for information on specifying a
page to check and on setting up lists of selection criteria.
Performed:
• Immediately following a successful Layer 4 TCP health check
• At regular intervals, if keepalive is enabled for the port
Scripted (content verification for unknown ports)
After a successful Layer 4 health check, the Brocade Virtual ADX waits for the real server to send
back a packet in response.
The Brocade Virtual ADX looks in the response packet for a user-specified ASCII string, defined in a
matching list. The Brocade Virtual ADX compares the contents of the string to a list of user-defined
selection criteria in the matching list.
Based on the results of this comparison, the Brocade Virtual ADX takes one of the following actions
with respect to the port on the real server:
• If the text in the response meets the criteria for keeping the port up, then the Brocade Virtual
ADX marks the port ACTIVE.
• If the text in the response meets the criteria for bringing the port down, then the Brocade
Virtual ADX marks the port FAILED.
• If the text in the response meets none of the selection criteria, then the Brocade Virtual ADX
marks the port either ACTIVE or FAILED according to a user-defined setting.
• If no response is received within the configured interval (the default is five seconds), the
Brocade Virtual ADX sends a RST and retries the health check. After the configured number of
retries (the default is two retries), if the server still does not respond, the Brocade Virtual ADX
marks the server port FAILED.
Refer to “Configuring scripted health checks” on page 211 for more information.
Performed:
• Immediately following a successful Layer 4 TCP health check
• At regular intervals, if keepalive is enabled for the port
170
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Layer 7 health checks
4
IMAP4
The Brocade Virtual ADX waits for a message from the IMAP4 server:
• If the server sends a greeting message that starts with “* OK”, The Brocade Virtual ADX sends
a Logout command to the IMAP4 port on the real server, resets the connection, and marks the
port ACTIVE.
• If the server does not send a greeting message that starts with “* OK”, the Brocade Virtual
ADX retries the health check up to the number of times configured (the default is two retries). If
the server still does not send the expected message, the Brocade Virtual ADX marks the server
port FAILED and removes the server from the load-balancing rotation for IMAP4 service.
Performed:
• Immediately following a successful Layer 4 TCP health check
• At regular intervals, if keepalive is enabled for the port
LDAP
The Brocade Virtual ADX supports both anonymous and authenticated bonding with LDAP servers.
With anonymous bonding, the Brocade Virtual ADX simply checks the format of the bind response
and marks the LDAP port as active so long as the format of the bind response is correct.
Authenticated bonding requires both the configuration of a username and password for
authentication and the configuration of a base Distinguished Name (DN) for searching the LDAP
directory. With authenticated bonding, the Brocade Virtual ADX marks the LDAP port as active only
after the completion of a successful authenticated bind and search operation.
Anonymous bonding
If a username and password are not configured, the Brocade Virtual ADX sends an anonymous
bind request to the LDAP server and waits for a reply. The bind request includes a configurable
version number, which can be 2 or 3. The default is 3.
• If the server sends a bind reply with a result code of any status (no error), the Brocade Virtual
ADX resets the connection and marks the port ACTIVE.
• If the server does not send a bind reply by the time the LDAP keepalive health check expires,
the Brocade Virtual ADX retries the health check for a user-configured number of retries (the
default is two). If the server still does not respond, the Brocade Virtual ADX marks the server
port FAILED and removes the server from the load-balancing rotation for LDAP service.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
171
4
Layer 7 health checks
Authenticated bonding
If a username and password are configured, the Brocade Virtual ADX sends an authenticated bind
request to the LDAP server that includes three configurable parameters: the version number, the
name of the directory object that the client wants to bind to, and information used to authenticate
the Distinguished Name (DN).
Brocade Virtual ADX then queries the LDAP directory using a user-configured search.
• If the server sends a bind reply with a result code of any status (no error), the Brocade Virtual
ADX resets the connection and marks the port ACTIVE.
• If the result of the query is any error value, the Brocade Virtual ADX marks the server port
DOWN and removes the server from the load-balancing rotation for LDAP service.
Performed:
• Immediately following a successful Layer 4 TCP health check
• At regular intervals, if keepalive is enabled for the port
Brocade Virtual ADX also supports server response threshold health checks for LDAP servers. To
learn more see “Server response threshold health check” on page 164.
MMS
The Brocade Virtual ADX sends an intentionally invalid request to the server:
• If the server replies with a packet containing the value "MMS", the Brocade Virtual ADX marks
the port ACTIVE.
• If the server does not reply with a packet containing the value "MMS", the Brocade Virtual ADX
retries the health check up to the number of times configured (the default is two retries). If the
server still does not respond, the Brocade Virtual ADX marks the server port FAILED and
removes the server from the load-balancing rotation for MMS service.
NOTE
You can view the Brocade Virtual ADX’s invalid request in the MMS server log. The log entry has error
code 400.
Performed:
• Immediately following a successful Layer 4 TCP health check
• At regular intervals, if keepalive is enabled for the port
172
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Layer 7 health checks
4
NNTP
The Brocade Virtual ADX waits for a message from the NNTP server:
• If the server sends a greeting message with status code 200 or 201, the Brocade Virtual ADX
sends a Quit command to the NNTP port on the real server, then resets the connection by
sending a quit and a RESET, one immediately after the other, and marks the port ACTIVE.
• If the server does not send a greeting message with status code 200 or 201, the Brocade
Virtual ADX retries the health check up to the number of times configured (the default is two
retries). If the server still does not send the expected message, the Brocade Virtual ADX marks
the server port FAILED and removes the server from the load-balancing rotation for NNTP
service.
Performed:
• Immediately following a successful Layer 4 TCP health check
• At regular intervals, if keepalive is enabled for the port
PNM
The Brocade Virtual ADX sends a PNM file request that does not have a file name:
• If the server sends a reply containing the value "PNA", the Brocade Virtual ADX marks the port
ACTIVE.
• If the server does not send a reply containing the value "PNA", the Brocade Virtual ADX retries
the health check up to the number of times configured (the default is two retries). If the server
still does not send the expected message, the Brocade Virtual ADX marks the server port
FAILED and removes the server from the load-balancing rotation for PNM service.
Performed:
• Immediately following a successful Layer 4 TCP health check
• At regular intervals, if keepalive is enabled for the port
POP3
The Brocade Virtual ADX waits for a message from the POP3 server:
• If the server sends a greeting message that starts with “+ OK”, the Brocade Virtual ADX sends
a Quit command to the POP3 port on the real server, then resets the connection by sending a
quit and a RESET, one immediately after the other, and marks the port ACTIVE
• If the server does not send a greeting message that starts with “+ OK”, the Brocade Virtual
ADX retries the health check up to the number of times configured (the default is two retries). If
the server still does not send the expected message, the Brocade Virtual ADX marks the server
port FAILED and removes the server from the load-balancing rotation for POP3 service.
Performed:
• Immediately following a successful Layer 4 TCP health check
• At regular intervals, if keepalive is enabled for the port
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
173
4
Layer 7 health checks
RADIUS
The Brocade Virtual ADX sends an authentication request with a user name, password, and key to
the RADIUS server. The account information does not need to be valid for the server to pass the
health check. In fact, to prevent someone from learning account information by observing the
Brocade Virtual ADX RADIUS health check, Brocade recommends you use invalid information.
If the server replies with the result code “ACCEPT” or “REJECT” (or “ACCEPT only”, if required), the
Brocade Virtual ADX considers the port to be fine and marks it ACTIVE.
If the server does not reply or the server sends an ICMP “Destination Unreachable” message, the
Brocade Virtual ADX retries the health check up to the number of times configured (the default is
two retries). If the server still does not reply with “ACCEPT” or ”REJECT” (or “ACCEPT only”), the
Brocade Virtual ADX marks the RADIUS port FAILED and removes the server from the rotation for
RADIUS services.
It is possible to distinguish between the result code of “ACCEPT” or “REJECT” to determine the
health of the RADIUS server. For example, a “REJECT” is considered to indicate a health check fail
condition. This can be done using the following CLI global command:
Virtual ADX(config)#server radius-fail-healthcheck-on-access-reject
NOTE
You can configure a health check either for the well-known RADIUS port number 1812 or port 1645.
You cannot configure a health check for both of these ports on the same server.
Performed:
• Immediately following a successful Layer 4 UDP health check
• At regular intervals, if keepalive is enabled for the port
RTSP
The Brocade Virtual ADX sends a standard RTSP option packet, using sequence number 1:
• If the server responds with an acceptable status code, the Brocade Virtual ADX resets the
connection and marks the port ACTIVE. For SLB, the default acceptable status codes for the
check are 200–299 and 401.
• If the server responds with a different status code, the Brocade Virtual ADX marks the port
FAILED.
• If the server does not respond, the Brocade Virtual ADX retries the health check up to the
number of times configured (the default is two retries). If the server still does not respond, the
Brocade Virtual ADX marks the server port FAILED and removes the server from the
load-balancing rotation for RTSP service.
Performed:
• Immediately following a successful Layer 4 TCP health check
• At regular intervals, if keepalive is enabled for the port
174
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Layer 7 health checks
4
SMTP
The Brocade Virtual ADX waits for a message from the SMTP server:
• If the server sends a greeting message with status code 220, the Brocade Virtual ADX sends a
Quit command to the SMTP port on the real server, then resets the connection by sending a
quit and a RESET, one immediately after the other, and marks the port ACTIVE.
• If the server does not send a greeting message with status code 220, the Brocade Virtual ADX
retries the health check up to the number of times configured (the default is two retries). If the
server still does not send the expected message, the Brocade Virtual ADX marks the server
port FAILED and removes the server from the load-balancing rotation for SMTP service.
Performed:
• Immediately following a successful Layer 4 TCP health check
• At regular intervals, if keepalive is enabled for the port
SSL (complete)
The Brocade Virtual ADX initiates an SSL connection with the server on TCP port 443, a secure link
is negotiated, and encrypted data is transferred across it.
NOTE
SSL Layer 7 health check supports a maximum RSA key bit length of 4096. An RSA key bit length of
8192 is not supported.
After the SSL connection is established, the Brocade Virtual ADX sends the SSL server an HTTP
GET or HEAD request. The GET or HEAD request specifies a page containing the URL of a page on
the server. By default, the Brocade Virtual ADX sends a HEAD request for the default page, “1.0”,
although this can be changed with the port ssl url command:
• If the server responds with an acceptable status code, the Brocade Virtual ADX resets the
connection and marks the port ACTIVE.
• If the server does not respond, the Brocade Virtual ADX retries the health check up to the
number of times configured (the default is two retries). If the server still does not respond, the
Brocade Virtual ADX marks the server port FAILED and removes the server from the
load-balancing rotation for SSL service.
Performed:
• Immediately following a successful Layer 4 TCP health check
• At regular intervals, if keepalive is enabled for the port
It is possible to assign an HTTP content verification health check to the real server for the page
returned by “port ssl url”. The Brocade Virtual ADX examines response by a real server. The
Brocade Virtual ADX searches the text in the HTML file for user-specified selection criteria and
determines whether the SSL 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 attached to one or
more real servers.
NOTE
Reference the topic on “Using SSL health checks in a health check policy” on page 202 and the
“Content match for HTTP” on page 208 for more information.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
175
4
Layer 7 health checks
SSL (simple)
The Brocade Virtual ADX sends an SSL client hello with the SSL SID set to 0:
• If the server responds, then the Brocade Virtual ADX resets the connection and marks the port
ACTIVE.
• If the server does not respond, the Brocade Virtual ADX retries the health check up to the
number of times configured (the default is two retries). If the server still does not respond, the
Brocade Virtual ADX marks the server port FAILED and removes the server from the
load-balancing rotation for SSL service.
Performed:
• Immediately following a successful Layer 4 TCP health check
• At regular intervals, if keepalive is enabled for the port
Telnet
The Brocade Virtual ADX waits for a message from the Telnet server:
• If the server sends a command string that starts with the IAC escape characters (“FF”), the
Brocade Virtual ADX resets the connection and marks the port ACTIVE.
• If the server does not send a command that starts with the IAC escape character, the Brocade
Virtual ADX retries the health check up to the number of times configured (the default is two
retries). If the server still does not send the expected escape character, the Brocade Virtual
ADX marks the server port FAILED and removes the server from the load-balancing rotation for
Telnet service.
Performed:
• Immediately following a successful Layer 4 TCP health check
• At regular intervals, if keepalive is enabled for the port
Port-specific settings for Layer 7 health checks
You can configure the following Layer 7 health check parameters on a real server basis:
•
•
•
•
•
Keepalive health check state (enabled or disabled)
HTTP keepalive method, values, and valid status codes
HTTP content matching lists for HTTP content verification health checks
Scripted health checks (content verification health checks for unknown ports)
DNS keepalive method and values (zone-based or addressed-based check and the zone or
domain name)
• RADIUS keepalive values (user name, password, and encryption key)
• LDAP version (2 or 3)
176
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Layer 7 health checks
4
NOTE
The Brocade Virtual ADX uses its own management IP address or a source IP address configured on
the Brocade Virtual ADX as the source IP address in the health check packets (as opposed to a
virtual IP address). If the real servers are in the same subnet as the Brocade Virtual ADX, then the
health checks can use the Brocade Virtual ADX’s management IP address. Otherwise, the health
checks use a source IP address.
Enabling Layer 7 health check
All Layer 7 health checks are disabled by default. You can enable a health check globally or locally.
NOTE
The Brocade Virtual ADX considers a Layer 7 health check to be disabled only if the health check is
disabled on both the global and local levels. If the health check is enabled globally, locally, or both,
the Brocade Virtual ADX considers the health check to be enabled. Refer to “Configuring a port
profile” on page 188.
To locally enable a Layer 7 health check, enter a command such as the following at the real server
level of the CLI.
Virtual ADX(config-rs-jet)#port http keepalive
Syntax: [no] port port keepalive
If you use the no port command, you are locally disabling the health check. The health checks are
locally disabled by default.
The port variable is the port name or number. Enter one of the following values. If the port is not
one of the following well-known port, specify the port number.
• dns (port 53)
• ftp (port 21). Ports 20 and 21 both are FTP ports but in the Brocade Virtual ADX, the name
“ftp” corresponds to port 21.
•
•
•
•
•
•
•
•
•
http (port 80)
•
•
•
•
•
•
smtp (port 25)
imap4 (port 143)
ldap (port 389)
nntp (port 119)
ntp (port 123)
pop2 (port 109)
pop3 (port 110)
radius (UDP port 1812)
radius-old (UDP port 1645, which is used in some older RADIUS implementations instead of
port 1812)
snmp (port 161)
ssl (port 443)
telnet (port 23)
tftp (port 69)
number
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
177
4
Layer 7 health checks
HTTP
Changing HTTP keepalive method, value, and status codes
The Brocade Virtual ADX supports two kinds of HTTP health checks:
• HTTP status code health checks look at the status code returned in HTTP responses to
keepalive requests.
• HTTP content verification health checks look at the actual HTML contained in HTTP responses
to keepalive requests.
The default URL page for HTTP keepalive requests used in HTTP health checks is “HEAD /1.0”. You
can change the URL that the Brocade Virtual ADX requests on a real server basis.
NOTE
For HTTP content verification health checks, you might want to change the default URL page for HTTP
keepalive requests URL page, since a request for “HEAD /1.0” would not return a response
containing HTML for content verification. You can specify a GET request for a page containing text
that can be searched and verified. Refer to “Configuring HTTP content matching lists” on page 208
for more information.
To configure the HTTP keepalive request to send a GET request for “sales.html”, enter the following
commands.
Virtual ADX(config)#server real zip 10.96.3.251
Virtual ADX(config-rs-zip)#port http url "GET /sales.html"
Virtual ADX(config-rs-zip)#exit
Virtual
Virtual
Virtual
Virtual
ADX(config)#server virtual-name-or-ip shoosh 10.96.4.250
ADX(config-vs-shoosh)#port http
ADX(config-vs-shoosh)#bind http zip http
ADX(config-vs-shoosh)#exit
Syntax: port http url “[GET | HEAD] [/] URL-page-name”
GET or HEAD is an optional parameter that specifies the request type. By default, HTTP keepalive
uses HEAD to retrieve the URL page. You can override the default and configure the Brocade Virtual
ADX to use GET to retrieve the URL page.
The slash (/) is an optional parameter. If you do not set the GET or HEAD parameter, and the slash
is not in the configured URL page, then Brocade Virtual ADX automatically inserts a slash before
retrieving the URL page.
To change the HTTP status codes that the Brocade Virtual ADX considers normal (not indicative of a
failure of the HTTP service), enter the following command.
Virtual ADX(config-rs-zip)#port http status-code 200 201 300 302
Syntax: port http status-code range [range[range[range]]]
The command in the example specifies two ranges (200–201 and 300–302). You can specify up to
four ranges (total of eight values). To specify a single message code for a range, enter the code
twice. For example to specify 200 only, enter the port http status-code 200 200 command.
NOTE
When you change the status code ranges, the defaults are removed. As a result, you must specify
all the valid ranges, even if a range also is within the default ranges. For example, if you still want
codes 200 to 299 to be valid, you must specify them.
178
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Layer 7 health checks
4
DNS
Enabling recursive DNS health checks
By default, a Layer 7 health check for a DNS port sends the query only to the real server (DNS
server). If the DNS server does not reply with the IP address or zone name requested by the health
check, the port fails the health check.
You can enable the real server to perform a recursive lookup for the IP address or zone requested
by the health check. In this case, if the real server does not have the requested address or zone,
the server can pass the request on to a DNS server with higher authority. The real server can
repeat this process until either a DNS server with higher authority successfully replies to the health
check, or the server with the highest authority is unable to successfully reply to the request.
To enable recursive DNS health checks globally at the port profile level for the DNS port, enter
commands such as the following.
Virtual ADX(config)#server port dns
Virtual ADX(config-port-dns)#allow-recursive-search
Syntax: [no] allow-recursive-search
NOTE
This feature applies to Boolean health checks in addition to standard (non-Boolean) health checks.
NOTE
You can enable this feature only on the well-known DNS port (53).
Configuring DNS health check method and values
The keepalive time and number of retries are global parameters. However, you configure the DNS
health checking methods and values on an individual server basis. You can set the following types
of DNS health checks (none configured by default):
• Address-based – The Brocade Virtual ADX sends an address request for a specific domain
name. If the server successfully responds with the IP address for the domain name, the server
passes the health check.
• Zone-based – The Brocade Virtual ADX sends a Start-of-Authority (SOA) request for a specific
zone name. If the server is authoritative for the zone and successfully responds to the SOA
request, the server passes the health check.
To configure the domain name for address-based DNS health checking, enter the following
command.
Virtual ADX(config-rs-zip)#port dns addr_query "example2.com"
Syntax: [no] port dns addr_query "name"
To configure the zone name for zone-based DNS health checking, enter the following command.
Virtual ADX(config-rs-zip)#port dns zone example2.com
Syntax: [no] port dns zone zone-name
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
179
4
Layer 7 health checks
RADIUS
Configuring RADIUS health check values
You can define the RADIUS parameters that the Brocade Virtual ADX sends to a RADIUS application
port during the Layer 7 health check.
The RADIUS health check requires a specific user name, password, and authentication key from
the RADIUS server. To specify these values, use one of the following methods.
To configure the parameters for a RADIUS health check, enter commands such as the following at
the real server level of the CLI.
Virtual ADX(config-rs-rocket)#port radius username evil
Virtual ADX(config-rs-rocket)#port radius password woody
Virtual ADX(config-rs-rocket)#port radius key laser
Syntax: [no] port radius username string
Syntax: [no] port radius password string
Syntax: [no] port radius key string
Dropping failed RADIUS health checks
With a valid response from a RADIUS server (that is, user authentication pass or fail), the Brocade
Virtual ADX marks the RADIUS health check as passed. However, this behavior might not be desired
in some cases. The following enhancement lets the Brocade Virtual ADX mark the RADIUS health
check as FAIL if authentication is received as (PW_ACCESS_REJECT).
Virtual ADX(config-rs-rocket)#server radius-fail-healthcheck-on-access-reject
Syntax: [no] server radius-fail-healthcheck-on-access-reject
LDAP
Configuring Usernames for Authenticated LDAP Bonding
Authenticated bonding with an LDAP server requires the configuration of a username and
password that are sent as parameters in the bind request.
To define the username the Brocade Virtual ADX will use to create an authenticated bind with an
LDAP port on a real server, enter commands such as the following at the real port level of the CLI.
Virtual ADX(config)#server real r1 192.168.20.43
Virtual ADX(config-rs-r1)#port ldap username “cn=Directory Manager”
Syntax: [no] port {ldap | ldaps | port-num} username name
The name variable specifies the name of the Directory object that the Brocade Virtual ADX will bind
as; it is a character string that cannot exceed 128 characters.
Configuring Passwords for Authenticated LDAP Bonding
To define the password the Brocade Virtual ADX will use to create an authenticated bind with an
LDAP port on a real server, enter commands such as the following at the real port level of the CLI.
Virtual ADX(config)#server real r1 192.168.20.43
Virtual ADX(config-rs-r1)#port ldap password “brocade123”
180
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Layer 7 health checks
4
Syntax: [no] port {ldap | ldaps | port-num} password string
The string variable specifies the password for the Directory object that the Brocade Virtual ADX
binds as; it is a character string that cannot exceed 64 characters.
Configuring Base Distinguished Names for Authenticated LDAP Bonding
To configure the base Distinguished Name (DN) used to query the LDAP directory, enter commands
such as the following at the real port level of the CLI.
Virtual ADX(config)#server real r1 192.168.20.43
Virtual ADX(config-rs-r1)#port ldap search-base-dn “ou=groups,dc=brocade,dc=com”
Syntax: [no] port {ldap | ldaps} search-base-dn distinguished-name
The distinguished-name is a character string that cannot exceed 256 characters.
LDAP over SSL
The Brocade Virtual ADX can perform LDAP health checks using a Secure Sockets Layer (SSL)
connection on TCP port 636.
The LDAP over SSL (LDAPS) health check procedure works as follows:
The Brocade Virtual ADX initiates an SSL connection with the server on TCP port 636, a secure link
is negotiated, and encrypted data is transferred across the link. After the SSL connection is
established, the Brocade Virtual ADX sends a bind request to the LDAPS server and waits for a
reply. The bind request includes a configurable version number, either 2 or 3 (by default, version 3).
• If the LDAPS server sends a bind reply with a result code of any status (no error), the Brocade
Virtual ADX resets the connection and marks the port ACTIVE.
• If the LDAPS server does not send a bind reply by the time the LDAPS keepalive interval
expires, the Brocade Virtual ADX retries the health check up to the number of times configured
(by default, two retries). If the LDAPS server still does not respond, the Brocade Virtual ADX
marks the server port FAILED and removes the LDAPS server from the load-balancing rotation
for LDAPS service.
You can configure standard (non-Boolean) LDAPS health checks. Health checking commands
available for other TCP ports are also available for the LDAPS port.
Configuring Non-boolean LDAP health checks
To configure a standard health check for the port ldaps command on real server r1, enter the
following commands.
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server port ldaps
ADX(config-port-ldaps)#tcp keepalive enable
ADX(config-port-ldaps)#exit
ADX(config)#server real r1 10.10.1.101
ADX(config-rs-r1)#port ldaps
ADX(config-rs-r1)#exit
If the no-fast-bringup command is not configured for the LDAPS port, if the l4-check-only command
is configured for the LDAPS port, or if the keepalive health check for the LDAPS port is disabled, the
Brocade Virtual ADX does not establish a secure connection when performing a health check on
port 636. Instead, the Brocade Virtual ADX establishes a regular TCP connection on port 636 and
sends a TCP RESET, using the same method as the LDAP health check.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
181
4
Layer 7 health checks
Configuring Boolean LDAP health checks
To configure a Boolean LDAPS health check, enter commands such as the following.
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#healthck check1 tcp
ADX(config-hc-check1)#dest-ip 10.10.1.101
ADX(config-hc-check1)#port ldaps
ADX(config-hc-check1)#protocol ldaps
ADX(config-hc-check1)#l7-check
A Layer 7 health check must be configured in order for the Brocade Virtual ADX to establish a
secure connection on the LDAPS port. If only a Layer 4 health check is configured, then the
Brocade Virtual ADX establishes a regular TCP connection on port 636.
Simple and compound SSL health checks
The Brocade Virtual ADX supports two kinds of SSL health checking methods:
• The Simple method sends the server an SSL client hello with the SSL SID set to 0. If the server
responds, then the server passes the health check. The Brocade Virtual ADX then resets the
connection and marks the SSL port ACTIVE.
• The Compound method negotiates an SSL connection and sending a GET or HEAD request to
the server once the connection is established. The GET or HEAD request specifies a page
containing the URL of a page on the server. If the server responds with an acceptable status
code, the Brocade Virtual ADX resets the connection and marks the port ACTIVE.
Configuring SSL health checks
To configure the Brocade Virtual ADX to use the simple SSL health check, enter the following
command.
Virtual ADX(config)#server use-simple-ssl-health-check
To use the complete SSL health check, enter the no server use-simple-ssl-health-check command.
Virtual ADX(config)#no server use-simple-ssl-health-check
NOTE
When you configure complete SSL health check on the Brocade Virtual ADX and the server response
is in small TCP segment packets of 5 to 50 bytes, flapping occurs and the Brocade Virtual ADX
displays the following error messages:
SSL interface: ssl_read_data return error !!!
SSL read data: can't find key ???
Syntax: [no] server use-simple-ssl-health-check
Error messages
The following error messages are related to SSL health check, after receiving SSL data while it
cannot find the key to decrypt the data. The key is missing possibly due to a time out.
ssl_receive_data but tcb->ssl is null
SSL cleanup: can't find key ???
SSL interface: ssl_read_data return error !!!
ssl_receive_data but tcb->ssl is null
SSL cleanup: can't find key ???
182
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Layer 7 health checks
4
SSL interface: ssl_read_data return error !!!
ssl_receive_data but tcb->ssl is null
SSL cleanup: can't find key ???
SSL interface: ssl_read_data return error !!!
The Brocade Virtual ADX normally stops processing the rest of the data and releases the SSL
control block data structure. However when the Brocade Virtual ADX does not do that, the Brocade
Virtual ADX finds the SSL data structure is null and prints these messages.
Layer 7 health check for an unknown port
You can use Layer 7 health check parameters for the following known ports to check the health of
unknown ports:
• TCP ports:
• HTTP (port 80)
• FTP (port 21)
• IMAP4 (port 143)
• LDAP (port 389)
• POP3 (port 110)
• SMTP (port 25)
• Telnet (port 23)
• UDP ports:
• DNS (port 53)
Configuring an unknown TCP port to use Layer 7 TCP health checks
You can use the Brocade Virtual ADX’s Layer 7 health check mechanism for the following TCP
applications on any TCP port number:
•
•
•
•
•
•
•
HTTP (port 80)
FTP (port 21)
IMAP4 (port 143)
LDAP (port 389)
POP3 (port 110)
SMTP (port 25)
Telnet (port 23)
The health check mechanisms for these ports are described in “Health checks overview” on
page 159.
To configure an unknown TCP port to use the Layer 7 health check for one of the applications listed
above, enter commands such as the following.
Virtual ADX(config)#server port 999
Virtual ADX(config-port-999)#tcp keepalive protocol smtp
These commands configure port profile parameters for port 999. The second command in the
example makes the port a TCP port and assigns the SMTP Layer 7 health check to the port.
Syntax: [no] server port TCP-portnum
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
183
4
Server and application port states
Syntax: [no] tcp keepalive protocol TCP-port
The protocol TCP-port parameters specify the type of Layer 7 health you want to use for the port.
You can specify one of the following:
•
•
•
•
•
•
ftp or 21
imap4 or 143
ldap or 389
pop3 or 110
smtp or 25
telnet or 23
Configuring an unknown UDP port to use a Layer 7 health check
The Brocade Virtual ADX can perform Layer 7 health checks on the DNS port (UDP port 53).
To configure an unknown UDP port to use the DNS Layer 7 health check:
• Configure the Layer 7 health check on the DNS port (53). For configuration information, refer to
“Configuring DNS health check method and values” on page 179. The unknown port uses the
same health check parameters as the ones you configure for the DNS port. For example, if you
configure an address-based DNS health check for a specific domain name, the Brocade Virtual
ADX requests the same domain name when checking the health of the unknown port.
• Create a port profile for the unknown port and specify dns or 53 as the well-known port whose
Layer 7 health check you want to use.
To configure an unknown port to use a Layer 7 health check, enter commands such as the
following.
Virtual ADX(config)#server port 999
Virtual ADX(config-port-999)#udp keepalive protocol dns
Syntax: server port UDP-portnum
Syntax: udp keepalive protocol UDP-portnum
The protocol UDP-port parameters specify the type of Layer 7 health you want to use for the port.
You can specify dns or 53.
Server and application port states
Server states
The server states only concern up to Layer 3. They do not deal with Layers 4 or Layer 7. In Table 15,
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.
NOTE
Layer 4 refers to making a TCP connection to a port. Layer 7 refers to making an HTTP request and
getting an HTTP reply.
184
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Server and application port states
TABLE 15
4
Server states
State
Description
ENB:enabled
There is no link to the real server. The real server is configured on the Brocade Virtual ADX but
is not physically connected to the Brocade Virtual ADX.
FAL:failed
The real server has failed to respond to repeated Layer 3 health checks (IP pings). Typically, a
real server changes to the FAILED state from the SUSPECT state.
TST: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 Virtual 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 Virtual
ADX will normally send one ICMP echo request. After it gets the ARP reply and before it gets
the ICMP echo reply, the Brocade Virtual ADX will show the real server state as Testing. If you
have a firewall application on the real server so that it responds to ARP queries but not to
ICMP pings, then the real server will show as "Testing" indefinitely.
Use the show server real command to display detailed state information. The show server
bind command is more concise, though it focuses on port status.
SUS:suspect
The Brocade Virtual 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 Virtual 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 Virtual 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.
GDN:grace-dn
The server gracefully shut down. Refer to server force-delete command under the “Enabling
force-delete” section.
ACT:active
A real server will go to active as long as it is reachable at Layer 2 and Layer 3, regardless of
whether its ports are bound to anything, or whether its ports pass tests.
UNB:unbind
Used for ports that have not been bound to a virtual server.
AWU:await-unbind
AWD:
await-shutdown
Both can occur when you're trying to unbind or delete ports. You might not even see them in
anything but a live environment. After you remove real servers from a virtual server or delete
virtual servers or unbind ports, normally the Brocade Virtual ADX or stackable waits until
connections in progress finish their business.
Application port states
Table 16 lists the application port states.
TABLE 16
Application port states
State
Description
ENABLED
There is no link to the server. The server is configured on the Brocade Virtual ADX but is not
connected to the Brocade Virtual ADX. (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.
Typically, an application changes to the FAILED state from the SUSPECT state. Note that if a
application does not pass the Layer 4 health check, the Brocade Virtual ADX does not waste
resources on the Layer 7 health check, because the application clearly is not available. When an
application enters the FAILED state, the state of the real server itself moves to the TEST state
while the Brocade Virtual 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.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
185
4
Server and application port states
TABLE 16
Application port states (Continued)
State
Description
SUSPECT
The Brocade Virtual 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 Virtual ADX sends a Layer 4 health check
to the service. (If applicable, and if the server passes the Layer 4 health check, the Brocade
Virtual ADX then sends a Layer 7 health check to the application.) If the application does not
respond within a specified interval, the Brocade Virtual 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.
Displaying real server state information
To display real server information, enter the following command at any level of the CLI.
Virtual ADX(config)#show server real
Real Servers Info
========================
State - ACT:active, ENB:enabled, FAL:failed, TST:test, SUS:suspect,
GDN:grace-dn, DIS:disabled, UNK:unknown, UNB:unbind,
AWU:await-unbind, AWD: await-shutdown
Name: rs1
Mac: Unknown
SrcNAT: not-cfg, not-op
Port
---default
http
St
-UNB
ENB
Ms
-0
0
Server
Total
State: Enabled
Weight: 1/1
DstNAT: not-cfg, not-op
IP:10.95.7.1:
MaxConn: n/a
Serv-Rsts: 0
1
CurConn
------0
0
TotConn
------0
0
Rx-pkts
------0
0
Tx-pkts
------0
0
Rx-octet
-------0
0
Tx-octet
-------0
0
Reas
---0
0
0
0
0
0
0
0
0
Information about the remaining real servers has been omitted for brevity.
Syntax: show server real
The state information lists the state of the server itself first. Then the states of each of the
application ports configured on the server are displayed.
In this example, the server itself is enabled. The HTTP port is also enabled, but the “default” port (a
port the Brocade Virtual ADX automatically configures on all the real and virtual servers) is
unbound (unbnd). These states are typical of a Brocade Virtual ADX that is configured for
deployment but has not been connected to the real servers.
If information appears under the row for the HTTP application, it shows settings for the Layer 7
health checks for the port. For information about HTTP health checks and other configurable Layer
7 health check parameters, refer to “Port-specific settings for Layer 7 health checks” on page 176.
186
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
4
Port profiles and attributes
Displaying virtual server state information
To display virtual server information, enter the following command at any level of the CLI.
Virtual ADX(config)#show server virtual
Virtual Servers Info
Name: v100
Pred: round-robin
VIP state: Healthy
Rx pkts:
Rx bytes:
Rx PPS:
Rx Throughput:
tcp-conn-rate:
CPS:
Note: The above
Port
State
-------default enabled
http
enabled
Port
---default
http
State: Enabled
ACL-Id: 0
0
0
0
0
Kbps
0
0
statistics lag by
Sticky Concur
------ -----NO
NO
NO
NO
Rx-pkts
------0
0
Tx-pkts
------0
0
IF DWN
Tx pkts:
Tx bytes:
Tx PPS:
Tx Throughput:
udp-conn-rate:
CurrConn:
1 second
Proxy DSR
CurConn
----- --------NO
NO
0
NO
NO
0
Rx-octet
-------0
0
IP:10.157.23.100
TotalConn: 0
0
0
0
0
0
0
TotConn
------0
0
:
4
Kbps
PeakConn
-------0
0
Tx-octet
-------0
0
Information about the remaining virtual servers has been omitted for brevity.
Syntax: show server virtual
In this example, the virtual server and the application ports configured on the server are enabled,
indicating that the server and the application ports are configured on the Brocade Virtual ADX but
the Brocade Virtual ADX is not connected to the real servers bound to this virtual server. Refer to
“Displaying real server state information” on page 186 for descriptions of the server and
application states.
Port profiles and attributes
A port profile is a set of attributes that globally defines an application port. Once defined, the port
has the same attributes on all the real and virtual servers that use the port. Port profiles are useful
if you want to globally change the attributes of a port known to the Brocade Virtual ADX (refer to the
list in “Port-specific settings for Layer 7 health checks” on page 176) or you want to globally define
a port that is not known to the Brocade Virtual ADX. You also can specify or change port attributes
locally, on the real server and virtual server configuration levels.
If you want to enable the keepalive health check for an application port, you must configure a port
profile for the port.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
187
4
Port profiles and attributes
Configuring a port profile
For an application port not known to the Brocade Virtual ADX, the Brocade Virtual ADX assumes
that it is a UDP port. In addition, the Brocade Virtual ADX does not perform keepalive health checks
for it. You can configure a port profile for the port and specify whether the port is TCP or UDP, in
addition to setting keepalive health check parameters for the port.
Even for ports known to the Brocade Virtual ADX, you must configure a profile for the port to
globally configure the port parameters and to configure the keepalive health check. After you add
the port by indicating whether it is a TCP or UDP port, the Brocade Virtual ADX automatically
enables the keepalive health check for the port.
NOTE
Enabling or disabling a keepalive health check does not affect the health check the Brocade Virtual
ADX sends when you bind a real server to a virtual server using the application port. The keepalive
health check state also does not affect the health checks the Brocade Virtual ADX sends if the
server’s response time slows.
The keepalive interval and retry values for each type of TCP/UDP health check are global
parameters. For example, if you change the number of retries for the HTTP health check (TCP port
80), the change applies to all instances of port 80 on all the real servers configured on the Brocade
Virtual ADX.
TABLE 17
Keepalive health check states
State
Effect
Global (entire Brocade
Virtual ADX)
Local (specific real server)
Disabled
Disabled
Health check is disabled
Disabled
Enabled
Health check is enabled
Enabled
Disabled
Health check is enabled
Enabled
Enabled
Health check is enabled
As shown in the Table 17, after a keepalive health check is enabled, to disable it you must do so
both globally and locally. If you want to enable keepalive health checks only on specific real servers
(locally), you can easily do so by making sure the health checks are disabled globally, then enabling
them on individual real servers.
To enable or disable a keepalive health check globally, use one of the following methods. To enable
or disable a keepalive health check locally, refer to “Enabling Layer 7 health check” on page 177.
NOTE
DNS, HTTP, and RADIUS health checks use additional parameters, which you can configure using
separate commands. Refer to “Changing HTTP keepalive method, value, and status codes” on
page 178, “Configuring DNS health check method and values” on page 179, or “Configuring RADIUS
health check values” on page 180.
NOTE
When health checks are enabled for the ports on the VIPs in a host range, the Brocade Virtual ADX
checks the health of the applications on the base IP address only. The Brocade Virtual ADX assumes
that the health of an application is the same for all the VIPs within the host range.
188
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Port profiles and attributes
4
Adding a port and specifying its type
By adding a port, you also automatically enable periodic Layer 4 (and Layer 7, if applicable)
keepalive health checks for the port. If you do not specify the port type (TCP or UDP), the Brocade
Virtual ADX assumes the port type is UDP.
To add a port and specify that it is a TCP port, enter commands such as the following.
Virtual ADX(config)#server port 8080
Virtual ADX(config-port-8080)#tcp
Syntax: server port TCP/UDP-portnum
Syntax: tcp | udp [keepalive [disable | enable]]
Changing a port’s keepalive parameters
To change a port’s keepalive state, enter a command such as the following.
Virtual ADX(config-port-8080)#tcp keepalive disable
To change a port’s keepalive interval and retries, enter a command such as the following.
Virtual ADX(config-port-80)#tcp keepalive 15 5
Syntax: tcp | udp keepalive [interval-in-seconds retries]
You can specify from 1 through 120 seconds for the interval-in-seconds variable. You can specify
from 1 through 5 for the retries variable.
Configuring port profile attributes
Table 18 lists the port attributes you can configure at the port profile level.
TABLE 18
Port profile attributes
Attribute
Description
Port type (TCP or
UDP)
This attribute applies only to ports for which the Brocade Virtual ADX does not already know
the type. For example, if a real server uses port 8080 for HTTP (a TCP port), you can globally
identify 8080 as a TCP port. The Brocade Virtual ADX assumes that ports for which it does
not know the type are UDP ports.
Refer to “Adding a port and specifying its type” on page 189.
NOTE: To display a list of the ports for which the Brocade Virtual ADX already knows the
type, enter the server port ? command at the global CONFIG level.
Keepalive interval
and retries
The number of seconds between health checks and the number of times the Brocade
Virtual ADX re-attempts a health check to which the server does not respond.
Refer to “Changing a port’s keepalive parameters” on page 189.
Keepalive state
Whether the Brocade Virtual ADX’s health check for the port is enabled or disabled.
Recurring Layer 4 and Layer 7 health checks are disabled by default. When you configure a
port profile, the software automatically globally enables the health check for the
application. You also can explicitly disable or re-enable the keepalive health check at this
level.
NOTE: If you are configuring a port profile for a port that is known to the Brocade Virtual
ADX, the keepalive parameters affect Layer 7 health checks. For other ports, the
keepalive parameters affect Layer 4 health checks.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
189
4
Port profiles and attributes
TABLE 18
Port profile attributes (Continued)
Attribute
Description
Keepalive port
By default, the Brocade Virtual ADX bases the health of an application port on the port
itself. You can specify a different application port for the health check. In this case, the
Brocade Virtual ADX bases the health of an application port on the health of the other port
you specify.
Refer to “Basing a port’s health on the health of another port” on page 220.
NOTE: You cannot base the health of a port well-known to the Brocade Virtual ADX on the
health of another port, whether the port is well-known or not well-known.
Source of health for
alias port
By default, the Brocade Virtual ADX performs independent health checks on an alias port
and its master port. You can configure the Brocade Virtual ADX to base the health of an
alias port on the state of its master port.
Refer to “Basing an alias port’s health on the health of its master port” on page 219.
TCP or UDP age
The number of minutes a TCP or UDP session table entry can remain inactive before the
Brocade Virtual ADX times out the entry. This parameter is set globally for all TCP or UDP
ports but you can override the global setting for an individual port by changing that port’s
profile.
Refer to “Overriding the global TCP or UDP age” on page 192.
You can specify a TCP age from 2 through 60 minutes and a multiplier from 2 through 20.
Thus, the maximum configurable TCP age for an individual port is 1200 minutes (20
hours).
NOTE: You cannot specify a multiplier when configuring the global TCP age.
NOTE: Because UDP is a connectionless protocol, the Brocade Virtual ADX does not
remove a UDP session from its session table until the session times out. TCP is a
connection-based protocol. Therefore, for TCP sessions, the Brocade Virtual ADX
removes the session as soon as the client or server closes the session.
NOTE: For DNS and RADIUS UDP load balancing, the age value does not follow the normal
configuration and default value unless udp-normal-age is configured on the port.
The default UDP age will always be 2 minutes unless udp-normal-age is configured.
NOTE: The Brocade Virtual ADX immediately deletes a UDP DNS or RADIUS session table
entry when the Brocade Virtual ADX receives a reply for the application from a real
server. If desired, you can configure the Brocade Virtual ADX to age these ports like
other UDP ports, using the UDP age timer. Refer to “Setting TCP and UDP ages for
VIPs” on page 121.
190
Connection logging
You can enable logging for session table entries created for this port.
Refer to “Syslog for session table entries” on page 240.
Slow start
Configures the Brocade Virtual ADX to control the rate of new connections to the
application port to allow the server to ramp up.
Refer to “Port slow-start mechanism” on page 227.
Smooth factor
If you plan to use server response time as a load-balancing method, you can adjust the
amount of preference the Brocade Virtual ADX gives the most recent response time
compared to the previous response time.
Refer to “Changing the smooth factor on an application port” on page 192.
Recursive DNS
health checks
By default, a Layer 7 health check for a DNS port sends the query only to the real server
(DNS server). If the DNS server does not reply with the IP address or zone name requested
by the health check, the port fails the health check.
You can enable the real server to perform a recursive lookup for the IP address or zone
requested by the health check of the well-known DNS port (53).
Refer to “Enabling recursive DNS health checks” on page 179.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
4
Port profiles and attributes
You also can change port attributes locally, on the real server and virtual server configuration
levels. Port profiles simplify configuration by letting you characterize a port globally. For example, if
many of your real servers use TCP port 80 (the well-known number for HTTP) and you want to
change the keepalive interval for the port, you can do so globally. You do not need to change the
value multiple times on each real server.
The Brocade Virtual ADX knows the port types of some well-known port numbers. If you are using a
port number for which the Brocade Virtual ADX does not know the port type, you can specify
whether the port is TCP or UDP and configure its keepalive values globally. You do not need to
define the port on every server.
NOTE
Unless a port is known to the Brocade Virtual ADX to be a TCP port, the Brocade Virtual ADX assumes
the port is UDP. If you are using a port number that is not known to the Brocade Virtual ADX and the
port type is TCP, you must specify this either globally (using a port profile) or locally (when configuring
the individual real servers and virtual servers). Otherwise, the Brocade Virtual ADX will use a UDP
health check to test the port and the port will fail the health check.
NOTE
If you bind an application port on a real server to the same port on a virtual server, the port on the
real server inherits the attributes of the port on the virtual server.
Displaying the session age of a TCP port
To display the session age of a TCP port, enter a command such as the following. The TCP session
ages are shown in bold type. Notice that the TCP session ages for ports 8082 and HTTP (80) use
multipliers.
Virtual ADX(config)#show server real rs1 detail
Real Servers Info
Name : rs1
Mac-addr: 0003.47bf.bad2
IP:192.168.6.91
Range:1
State:Active
Max-conn: n/a
Least-con Wt:0
Resp-time Wt:0
Src-nat (cfg:op):(off:off)
Dest-nat (cfg:op):(off:off)
Remote server
: No
Dynamic : No
Server-resets:0
Mem:server: 02057999 Mem:mac: 02037cb0
Port
----
State
-----
Ms CurConn TotConn Rx-pkts
-- ------- ------- -------
Tx-pkts
-------
Rx-octet
--------
Tx-octet
--------
Reas
----
failed
0 0
0
0
0
max_conn =
1 sessions =
0
Keepalive(G/L:On/Off):On
Status Code(s): default (200-299, 401)
HTTP URL: "HEAD /"
tcp-age: 60 * 2
default unbnd
0 0
0
0
0
max_conn =
0 sessions =
0
0
0
0
0
0
0
Server
0
0
0
http
Total
0
0
0
0
0
Syntax: show server real name detail
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
191
4
Port profiles and attributes
Overriding the global TCP or UDP age
The TCP and UDP ages specify how many minutes a TCP or UDP session can remain inactive before
the Brocade Virtual ADX closes the session and clears it from its session table. You can set the TCP
or UDP age from 2 through 60 minutes. The default TCP age is 30 minutes, and the default UDP
age is 5 minutes.
Because UDP is a connectionless protocol, the Brocade Virtual ADX does not remove a UDP session
from its session table until the session times out. On the other hand TCP is a connection-based
protocol, so for TCP sessions, the Brocade Virtual ADX removes the session as soon as the client or
server closes the session.
NOTE
The Brocade Virtual ADX immediately deletes a UDP DNS or RADIUS session table entry when the
Brocade Virtual ADX receives a reply for the application from a real server. If desired, you can
configure the Brocade Virtual ADX to age these ports like other UDP ports, using the UDP age timer.
Refer to “Enabling normal UDP aging for DNS and RADIUS” on page 121.
For DNS and RADIUS UDP load balancing, the age value does not follow the normal configuration
and default value unless the udp-normal-age option is configured on the port. The default UDP age
will always be 2 minutes unless the udp-normal-age option is configured.
To change the global default for all TCP or UDP ports, refer to “Configuring TCP age” on page 239 or
“Configuring UDP age” on page 239.
To override the default TCP age and set the age for TCP port 80 to 15 minutes, enter the following
commands.
Virtual ADX(config)#server port 80
Virtual ADX(config-port-80)#tcp 15
Syntax: server port TCP/UDP-portnum
Syntax: tcp | udp age
The default TCP age is 30 minutes. The default UDP age is 5 minutes.
NOTE
The session age is per minute and has a one minute range. For example, if you configured a TCP or
UDP age of three minutes, the age timeout is from two to three minutes.
Changing the smooth factor on an application port
This smooth factor applies to ports that you plan to use with the server response time
load-balancing metric. Refer to “Changing the Load-Balancing Predictor Method” on page 21 and
“Configuring a stateless port” on page 30 for information about the server response time metric
and how the smooth time works.
The Brocade Virtual ADX calculates the server response time value for a real server by regularly
collecting response time samples, then using a calculation to smooth the values of the samples
and derive a single response time value for the real server. The Brocade Virtual ADX collects the
samples around once every 100 milliseconds (about 10 times a second). The sampling rate can
vary slightly depending on the processing the Brocade Virtual ADX is performing.
192
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Port policy
4
To change the smooth factor for an application port, enter a command such as the following.
Virtual ADX(config-port-80)#smooth-factor 50
Syntax: smooth-factor num
Port policy
Port policies
Server port policies help reduce the configuration required for health checks and provide more
flexibility while configuring health checks. Brocade Virtual ADX allows the use of Layer 7 health
check parameters for known ports, such as HTTP, LDAP, SMTP, IMP4, POP3, NNTP, Telnet, FTP, SSL,
RTSP, MMS, PNM, and LDAPS to check the health of unknown ports. The configuration of server
port policies consists of two parts:
• Configuring a port policy
• Binding the policy
Configuring a port policy
Follow the steps given below to configure a port policy.
1. First create a policy by entering a command such as the following.
Virtual ADX(config)#server port-policy p1
Syntax: server port-policy policy-name
Once the policy is named, the CLI changes to the configuration-port-policy level.
2. (Optional) Specify the port that will be checked by the policy.
Virtual ADX(config-port-policy-p1)#port 8080
Syntax: port port-num
3. Specify what protocol will be checked on the traffic that passes through the port.
Virtual ADX(config-port-policy-p1)#protocol http
Syntax: protocol protocol-value
If the protocol is not configured, the policy cannot be bound to a real server port.
For the protocol-value variable, enter a TCP or UDP port name or number. For TCP ports, enter
FTP (port 21), HTTP (port 80), IMAP4 (port 143), LDAP (port 389), LDAPS (port 636), MMS (port
1755), NNTP (port 119), PNM (port 7070), POP3 (port 110), RTSP (port 554), SMTP (port 25),
TELNET (port 23).
NOTE
Ports 20 and 21 both are FTP ports but on the Brocade Virtual ADX, the name "FTP"
corresponds to port 21.
For UDP ports, enter DNS (port 53) or RADIUS (port 1812).
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
193
4
Port policy
4. Configure a keepalive interval under a port policy.
Virtual ADX(config-port-policy-p1)#keepalive-interval 5
Syntax: [no] keepalive-interval seconds
Refer to “Configuring a keepalive interval under a port policy” on page 196 for more details.
5. (Optional) Enter the number of times the policy will be tried before the Brocade Virtual ADX
marks the port as "UP" or "DOWN".
Virtual ADX(config-port-policy-p1)#retries 5
Syntax: retries num
The default is 3 tries.
6. (Optional) Specify the protocol value.
Virtual ADX(config-port-policy-p1)#protocol http url www.example3.com
Syntax: protocol protocol-options
Enter one of the following for protocol-options, specifying the values for the required
parameters:
•
•
•
•
•
•
•
•
•
•
•
•
7.
http status-code min max
http url url
http content-match match-list
dns addr-query value
dns zone value
{ldap | ldaps} username name
{ldap | ldaps} password password
{ldap | ldaps} search-base-dn distinguished-name
radius key radius-key
radius password value
radius nas-ip { ipv4-addr | ipv6-addr }
radius nas-port value
(Optional) Enable the Layer 4 check feature in the policy.
Virtual ADX(config-port-policy-p1)#l4-check
Syntax: l4-check
By default, Layer 7 health check is enabled; however, Layer 4 health check is not. You must
enable Layer 4 health check if you want to use that feature.
194
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Port policy
4
Binding the policy
After the policy is configured, return to the configuration level and bind the policy to a real server
port.
Virtual ADX(config)#server real r1 10.10.1.101
Virtual ADX(config-rs-name)#port 1234 use-port-policy p1
Syntax: server real real-server-name real-server-ip-address
Syntax: [no] port port-num use-port-policy policy-name
For the policy-name variable, enter the name of the policy you created.
Once a policy is bound to a real server port, the Brocade Virtual ADX will use the values configured
in the policy for health checks.
The Brocade Virtual ADX sends a health check to the port configured in the policy; however, if you
do not configure a port number in the policy, the Brocade Virtual ADX sends the health check to the
port to which it is bound.
NOTE
The port policy configuration will take precedence over a port profile.
Example 1:
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server port-policy p1
ADX(config-port-policy-p1)#port 80
ADX(config-port-policy-p1)#protocol http
ADX(config-port-policy-p1)#retries 5
ADX(config-port-policy-p1)#exit
ADX(config)#server real r1 10.10.1.101
ADX(config-rs-r1)#port 1234 use-port-policy p1
ADX(config-rs-r1)#port 1234 keepalive
In Example 1, Port 1234 on Real Server 1 will be marked as “UP”, if the Layer 7 health check on
Port 80 on the server with the IP address of 10.10.1.101 passes.
Example 2:
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server port-policy p2
ADX(config-port-policy-p2)#protocol http
ADX(config-port-policy-p2)#l4-check
ADX(config-port-policy-p2)#exit
ADX(config)#server real r2 10.10.1.102
ADX(config-rs-r1)#port 1234 use-port-policy p2
In Example 2, a port has not been configured for "policy p2," so the Brocade Virtual ADX will use the
port to which the policy is bound. Port 1234 of real server r2 will be marked as "UP" if the health
check to port 1234 on the 10.10.1.101 Server passes the Layer 4 health-check.
Example 3:
In the following example, Port Policy pp1 is configured with a keepalive interval of 5 seconds, while
Port Policy pp2 has a keepalive interval of 30 seconds.
Port Policy pp1 is bound to real server rs1 port 8080 and real server rs2 port 9090; therefore,
these two ports have a 5 second keepalive interval.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
195
4
Port policy
Port Policy pp2 is bound to real server rs3 port 8080 and real server rs4 port 9090. These two
ports have a keepalive interval of 30 seconds.
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server port-policy pp1
ADX(config-port-policy-pp1)#keepalive-interval 5
ADX(config-port-policy-pp1)#protocol http
ADX(config-port-policy-pp1)#protocol http url "GET /abc.html"
ADX(config-port-policy-pp1)#retries 3
ADX(config-port-policy-pp1)#exit
ADX(config)#server port-policy pp2
ADX(config-port-policy-pp2)#keepalive-interval 30
ADX(config-port-policy-pp2)#protocol http
ADX(config-port-policy-pp2)#protocol http url "GET /xyz.html"
ADX(config-port-policy-pp2)#retries 2
ADX(config-port-policy-pp2)#exit
ADX(config)#server real rs1
ADX(config-rs-r1)#port 8080
ADX(config-rs-r1)#port 8080 use-port-policy pp1
ADX(config-rs-r1)#exit
ADX(config)#server real rs2
ADX(config-rs-r2)#port 9090
ADX(config-rs-r2)#port 9090 use-port-policy pp1
ADX(config-rs-r2)#exit
ADX(config)#server#real rs3
ADX(config-rs-r3)#port 8080
ADX(config-rs-r3)#port 8080 use-port-policy pp2
ADX(config-rs-r3)#exit
ADX(config)#server real rs4
ADX(config-rs-r4)#port 9090
ADX(config-rs-r4)#port 9090 use-port-policy pp2
ADX(config-rs-r4)#exit
Configuring a keepalive interval under a port policy
You can specify a health check keepalive interval from under a port-policy definition.
Virtual ADX(config-port-policy-pp1)#keepalive-interval 5
Syntax: [no] keepalive-interval seconds
Enter from 1 through 120 for the seconds variable.
In the following example, real server rs1 port 8080 and real server rs2 port 9090 will have a
keepalive interval of 5 seconds. Also, real server rs1 port 8080 and real server rs4 port 9080 will
have a keepalive interval of 30 seconds.
196
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server port-policy pp1
ADX(config-port-policy-pp1)#keepalive-interval 10
ADX(config-port-policy-pp1)#protocol http
ADX(config-port-policy-pp1)#protocol http url "GET /abc.html"
ADX(config-port-policy-pp1)#retries 3
ADX(config-port-policy-pp1)#exit
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server port-policy pp2
ADX(config-port-policy-pp2)#keepalive-interval 30
ADX(config-port-policy-pp2)#protocol http
ADX(config-port-policy-pp2)#protocol http url "GET /xyz.html"
ADX(config-port-policy-pp2)#retries 2
ADX(config-port-policy-pp2)#exit
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Port policy
4
After configuring the policy, bind it to a real server port. (Refer to “Binding the policy” on page 195
for details.) For example:
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server real
ADX(config-rs-rs1)#port
ADX(config-rs-rs1)#port
ADX(config-rs-rs1)#port
ADX(config-rs-rs1)#exit
rs1
8080
8080 keepalive
8080 use-port-policy pp1
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server real
ADX(config-rs-rs2)#port
ADX(config-rs-rs2)#port
ADX(config-rs-rs2)#port
ADX(config-rs-rs2)#exit
rs2
9090
9090 keepalive
9090 use-port-policy pp1
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server real
ADX(config-rs-rs3)#port
ADX(config-rs-rs3)#port
ADX(config-rs-rs3)#port
ADX(config-rs-rs3)#exit
rs3
8080
8080 keepalive
8080 use-port-policy pp2
Virtual
Virtual
Virtual
Virtual
ADX(config)#server real
ADX(config-rs-rs4)#port
ADX(config-rs-rs4)#port
ADX(config-rs-rs4)#port
rs4
9090
9090 keepalive
9090 use-port-policy pp2
Health check policy for VIP port
Overview of health check policy for VIP port
NOTE
The Brocade Virtual ADX does not support interval configuration under server port policy.
The Brocade Virtual ADX supports the binding of a server port policy on a real server port. Because
multiple real server ports are bound to a single virtual port, the client has requested that the server
port policy be bound to a virtual port. Once bound to a virtual port, the policy takes effect on all the
real server ports that are bound to that virtual port. This method allows the running configuration
to be reduced.
Command line interface
The command to turn on the health check policy feature for VIP port is under virtual server
configuration.
Virtual
Virtual
Virtual
Virtual
ADX(config)#server virtual-name-or-ip v1 10.1.1.1
ADX(config-virtual-server-v1) port 80
ADX(config-virtual-server-v1) bind 80 r1 80 r2 80 r3 80
ADX(config-virtual-server-v1) port 80 use-port-policy policy1
The Brocade Virtual ADX will now use the values configured under server port policy "policy1" to
send out health-checks to ports 80 on R1, R2 and R3.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
197
4
Element health checks
Element health checks
Introduction
The Brocade Virtual ADX allows the creation of a health check that is customized for a given
application server. Such definition is also known as element health check. You can specify the
health check frequency, the number of retrials, and the number of other parameters for server
health check.
Configuring element-action expressions
An element-action expression contains the IP address, protocol (TCP or UDP), and application port
number for an application on an individual real server. If the Brocade Virtual ADX allows you to
customize Layer 7 information for the application, then the element-action expression also can
contain the customized Layer 7 information.
You can also change the following parameters for an application port when configuring an
element-action expression:
• Health check type – For application types that are well-known to the Brocade Virtual ADX, you
can specify whether you want to use the Layer 4 health check or the Layer 7 health check for
the port. By default, the Brocade Virtual ADX uses the Layer 7 health check if the port one of
the types that are well known to the Brocade Virtual ADX.
• Health check interval – By default, the Brocade Virtual ADX performs the health checks every 5
seconds. You can change the interval to a value from 2 through 120 seconds.
• Health retries – By default, if a reply to a health check is not received, the Brocade Virtual ADX
will attempt the health check two more times before concluding that the application has failed
the health check. You can change the number of retries to a value from 1 through 5 retries.
• Health check state – By default, the health check is enabled as soon as you configure it. You
can disable or re-enable the health check from within the element-action expression for the
check.
Specifying the IP address and application port parameters
To configure an element-action expression, enter commands such as the following. The commands
in these examples specify the IPv4 or IPv6 address of the real server and the application port on
the server.
Example for IPv4
Virtual ADX(config)#healthck check1 tcp
Virtual ADX(config-hc-check1)#dest-ip 10.10.10.50
Virtual ADX(config-hc-check1)#port http
Example for IPv6
Virtual ADX(config)#healthck check-v6 tcp
Virtual ADX(config-hc-check-v6)#dest-ip 2001:db8:2000::1
Virtual ADX(config-hc-check-v6)#port http
198
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Element health checks
4
These commands change the CLI to the configuration level for an element-action expression, then
specify the IPv4 or IPv6 address of the real server and the application port on the server. Because
the specified application is well-known to the Brocade Virtual ADX, the Brocade Virtual ADX
automatically associates the default health check parameters for the port with the element-action
expression. In this example, the port is HTTP (80), so the Brocade Virtual ADX associates the
default HTTP health check parameters with the element-action expression. By default, the Brocade
Virtual ADX sends a HEAD request for the default page.
NOTE
You must specify the destination IP address before you can specify other health check parameters.
The software creates the health check policy only after you specify the destination IP address. If you
try to specify another parameter before the destination IP address, the CLI displays an error
message such as the following: Error - check1: Health-check element is undefined.
NOTE
If you do not specify the application port, the Brocade Virtual ADX will list the status of the health
check as FALSE (failed).
To configure an element-action expression for a port number that is not well-known to the Brocade
Virtual ADX, enter commands such as the following.
Example for IPv4
Virtual
Virtual
Virtual
Virtual
ADX(config)#healthck check1 tcp
ADX(config-hc-check1)#dest-ip 10.10.10.50
ADX(config-hc-check1)#port 8080
ADX(config-hc-check1)#protocol http
Example for IPv6
Virtual
Virtual
Virtual
Virtual
ADX(config)#healthck check-v6 tcp
ADX(config-hc-check-v6)#dest-ip 2001:db8:2000::1
ADX(config-hc-check-v6)#port 8080
ADX(config-hc-check-v6)#protocol http
These commands configure an element-action expression for unknown port 8080 and associate
the default health check parameters for port 80 with the unknown port. To customize the Layer 7
health check parameters for a port, add the information with the protocol command, as in the
following example.
Example for IPv4
Virtual
Virtual
Virtual
Virtual
ADX(config)#healthck check1 tcp
ADX(config-hc-check1)#dest-ip 10.10.10.50
ADX(config-hc-check1)#port 8080
ADX(config-hc-check1)#protocol http url "GET /sales.html"
Example for IPv6
Virtual
Virtual
Virtual
Virtual
ADX(config)#healthck check-v6 tcp
ADX(config-hc-check-v6)#dest-ip 2001:db8:2000::1
ADX(config-hc-check-v6)#port 8080
ADX(config-hc-check-v6)#protocol http url "GET /sales.html"
The protocol command in this example changes the Layer 7 health check parameters for this HTTP
port to a GET request for a page named sales.html.
Syntax: [no] healthck string { tcp | udp | boolean | icmp }
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
199
4
Element health checks
This command begins configuration of the element-action expression. The string variable specifies
the name for the expression and can be up to 20 characters long. The tcp | udp parameter
specifies whether you are configuring an expression for a TCP application port or a UDP application
port. There is no default.
Syntax: [no] dest-ip { ipv4-addr | ipv6-addr }
The ipv4-addr variable specifies the IPv4 address of the real server.
The ipv6-addr variable specifies the IPv6 address of the real server.
Syntax: [no] port tcp/udp-port
This command specifies the application port number.
NOTE
If you do not specify the server IP address and the application port, the Brocade Virtual ADX will list
the status of the health check as FALSE (failed).
You can specify any valid number, or one of the following port names well-known to the Brocade
Virtual ADX:
• dns – port 53
• ftp – port 21. (Ports 20 and 21 both are FTP ports but in the Brocade Virtual ADX, the name
“ftp” corresponds to port 21.)
•
•
•
•
•
•
•
•
•
http – port 80
•
•
•
•
•
smtp – port 25
imap4 – port 143
ldap – port 389
nntp – port 119
ntp – port 123
pop2 – port 109
pop3 – port 110
radius – port 1812
radius-old –The Brocade Virtual ADX name for UDP port 1645, which is used in some older
RADIUS implementations instead of port 1812.
snmp – port 161
ssl – port 443
telnet – port 23
tftp – port 69
NOTE
If you enter the no port tcp/udp-port command to remove the port, the Brocade Virtual ADX also
removes the protocol tcp/udp-port command (see below) if the port is well-known to the Brocade
Virtual ADX. The reason is that the Brocade Virtual ADX automatically uses the protocol that matches
the well-known port. For ports that are not well-known types, the Brocade Virtual ADX does not
remove the protocol. You must remove it separately.
Syntax: [no] protocol tcp/udp-port
200
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Element health checks
4
This command specifies a port whose health-check mechanism you want to use for the port
specified by the port command. You need to use this command only if the port specified by the port
command is not one of the ports listed above but the port is the same type as one of the ports
listed above. For example, use this command if you want to use the DNS health-check mechanism
for a port other than 53.
NOTE
You must specify the port using the port command before you enter the protocol command. If the
port command specified a port that is well-known to the Brocade Virtual ADX, the Brocade Virtual
ADX automatically uses the protocol that matches the port; you do not need to specify it and cannot
change it.
NOTE
If you remove the Layer 7 health check information (using a no protocol command), the application
will fail the health check. If you want the Brocade Virtual ADX to use a Layer 4 health check instead,
enter the l4-check command to change the health-check type to Layer 4.
If the port is not well-known to the Brocade Virtual ADX and you do not specify a protocol for the Layer
7 health check, but Layer 7 health checking is enabled for the port, the port will fail the health check.
Refer to the “Changing the health-check type” on page 204.
For some ports, you also can customize the Layer 7 information sent with the health check. Here is
the syntax.
Syntax: [no] protocol http | 80
[url “[GET | HEAD] [/]URL-page-name” |
port http status_code range [range[range[range]]] |
content-match matching-list-name]
This command changes one of the following HTTP health-check parameters. To change more than
one of these parameters, enter a separate protocol http or protocol 80 command for each
parameter.
• url “[GET | HEAD] [/]URL-page-name” – This parameter specifies whether the HTTP health
check performs a GET request or a HEAD request. For GET requests, you can specify the page
that is requested. By default, a GET request asks for page “1.0”.
• port http status_code range [range[range[range]]] – This parameter changes the HTTP status
codes that the Brocade Virtual ADX will accept as valid responses. Each range variable
specifies the low number and high number in a range of status codes. You can specify up to
four ranges (total of eight values). To specify a single message code for a range, enter the code
twice. For example, to specify 200 only, enter the port http status_code 200 200 command.
For SLB, the default status code range is from 200 through 299. If the server’s reply to the
health check contains a status code within this range, the Brocade Virtual ADX considers the
HTTP application to be healthy.
• content-match matching-list-name – This parameter attaches a match list for an HTTP content
verification health check to the real server. An HTTP content verification health check is a type
of Layer 7 health check in which the Brocade Virtual ADX examines text in an HTML file sent by
a real server in response to an HTTP keepalive request. The Brocade Virtual 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
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
201
4
Element health checks
verification is contained in a matching list that is attached to one or more real servers. The
following is an example of the commands used to set up a matching list. For information on
how to configure the match lists, refer to “Configuring HTTP content matching lists” on
page 208.
Syntax: [no] protocol dns | 53 [addr_query "name" | zone zone-name]
This command changes one of the following DNS health-check parameters. To change more than
one of these parameters, enter a separate protocol dns or protocol 53 command for each
parameter.
• addr_query "name" – This parameter specifies a domain name to be requested from the real
server by the Brocade Virtual ADX. If the server successfully responds with the IP address for
the domain name, the server passes the health check. There is no default.
• zone zone-name – This parameter specifies a DNS zone name. The Brocade Virtual ADX sends
a Source-of-Authority (SOA) request for the zone name. If the server is authoritative for the
zone and successfully responds to the SOA request, the server passes the health check. There
is no default.
NOTE
If you do not configure one of these parameters, the DNS port will fail the health check.
Syntax: [no] protocol radius | 1812 [username string] | [password string] | [key string]
This command changes one of the following RADIUS health-check parameters. The health check
requests values that are configured on the RADIUS server. To change more than one of these
parameters, enter a separate protocol radius or protocol 1812 command for each parameter.
• username string – This parameter specifies an authentication username on the server.
• password string – This parameter specifies an authentication password on the server.
• key string – This parameter specifies an authentication key on the server.
Syntax: [no] protocol ldap | 389 [num]
This command changes the LDAP version. The health check sent by the Brocade Virtual ADX differs
depending on the version. You can specify 2 or 3. The default is 3.
Using SSL health checks in a health check policy
When SSL health checks are used in a health check policy, by default the simple SSL health check
is used. The Brocade Virtual ADX sends the server an SSL client hello with the SSL SID set to 0; if
the server responds, it passes the health check. However, if you use the protocol ssl use-complete
command in a health check policy, it causes the Brocade Virtual ADX to negotiate an SSL
connection and send a GET or HEAD request to the server.
For example, the following commands create a health check policy to test IP address 10.10.10.50,
using SSL health checks.
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
202
ADX(config)#healthck check4 tcp
ADX(config-hc-check4)#dest-ip 10.10.10.50
ADX(config-hc-check4)#port ssl
ADX(config-hc-check4)#protocol ssl use-complete
ADX(config-hc-check4)#protocol ssl url "GET /secure.htm"
ADX(config-hc-check4)#protocol ssl status-code 200 200
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Element health checks
Virtual
Virtual
Virtual
Virtual
4
ADX(config-hc-check4)#protocol ssl content-match m1
ADX(config-hc-check4)#l7-check
ADX(config-hc-check4)#enable
ADX(config-hc-check4)#exit
Syntax: [no] protocol ssl use-complete
Changing the health-check interval and retries
By default, the Brocade Virtual ADX performs a health check every 5 seconds. If a reply is not
received, the Brocade Virtual ADX will attempt the health check two more times before concluding
that the application has failed the health check. You can change the number of seconds the
Brocade Virtual ADX will wait for a reply to a health check and the number of retries.
NOTE
The number of retries is the total number of attempts the Brocade Virtual ADX will make. If you use
the default interval and retries values, the Brocade Virtual ADX will send up to three health-check
packets, at 5-second intervals. If a server does not respond within 15 seconds of the time the
Brocade Virtual ADX sent the first health-check packet, the server fails the health check and the
Brocade Virtual ADX concludes that the server is not available.
To change the interval for a health check, enter a command such as the following at the
configuration level for the element-action expression that contains the health check.
Virtual ADX(config-hc-check1)#interval 30
Syntax: [no] interval secs
You can specify from 2 through 120 seconds. The default is 5 seconds.
To change the number of retries for a health check, enter a command such as the following at the
configuration level for the element-action expression that contains the health check.
Virtual ADX(config-hc-check1)#retries 4
Syntax: [no] retries num
You can specify from 1 through 5 retries. The default is 3 retries.
NOTE
You also can globally change the interval and retries for an application port by editing its port profile.
Refer to “Configuring a port profile” on page 188.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
203
4
Element health checks
Changing the health-check type
For TCP application ports, you can change the health-check type between Layer 4 and Layer 7. By
default, the Brocade Virtual ADX performs a Layer 7 health check in the following cases:
• The port is one of the following ports well-known to the Brocade Virtual ADX:
- FTP – port 21. (Ports 20 and 21 both are FTP ports but on the Brocade Virtual ADX, the
name “FTP” corresponds to port 21.)
-
HTTP – port 80
IMAP4 – port 143
LDAP – port 389
MMS – port 1755
NNTP – port 119
PNM – port 7070
POP3 – port 110
RTSP – port 554
SMTP – port 25
SSL – port 443
TELNET – port 23
• The port is not well-known to the Brocade Virtual ADX but you used the protocol command to
specify the protocol of one of the well-known ports. By specifying the protocol, you configure
the Brocade Virtual ADX to use the protocol’s Layer 7 health-check method for the port.
If the TCP port is not one of the ports above or you did not specify a Layer 7 health-check method
(using the protocol command), the Brocade Virtual ADX uses the Layer 4 health check for TCP.
NOTE
Changing the health-check type for UDP application ports has no effect. If the application port is
RADIUS (1812) or DNS (53) or uses the health-check method of one of these ports, the Brocade
Virtual ADX uses a Layer 7 health check. Otherwise, the Brocade Virtual ADX uses the Layer 4 health
check for UDP.
The Layer 7 health-check methods differ depending on the application:
• TCP – The Brocade Virtual ADX attempts to engage in a normal three-way TCP handshake with
the port on the real server:
-
The Brocade Virtual ADX sends a TCP SYN packet to the port on the real server.
The Brocade Virtual ADX expects the real server to respond with a SYN ACK.
If the Brocade Virtual ADX receives the SYN ACK, the Brocade Virtual ADX sends a TCP
RESET, satisfied that the TCP port is alive.
• UDP – The Brocade Virtual ADX sends a UDP packet with garbage (meaningless) data to the
UDP port:
204
-
If the server responds with an ICMP “Port Unreachable” message, the Brocade Virtual ADX
concludes that the port is not alive.
-
If the server does not respond at all, the Brocade Virtual ADX assumes that the port is alive
and received the garbage data. Because UDP is a connectionless protocol, the Brocade
Virtual ADX and other clients do not expect replies to data sent to a UDP port. Therefore,
lack of a response is a good outcome.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Element health checks
4
The l4-check command configures the Brocade Virtual ADX to use the Layer 4 health check for the
application port in the element-action expression. Because the application port in this
element-action expression is HTTP, the Brocade Virtual ADX will use the Layer 4 health check for
TCP.
Virtual ADX(config-hc-check1)#l4-check
Syntax: [no] l4-check | l7-check
Changing the health-check state
Once you configure an element-action expression, the health check in the expression is enabled by
default. To disable the health check, enter the following command at the configuration level for the
element-action expression.
Virtual ADX(config-hc-check1)#disable
Syntax: [no] disable | enable
NOTE
Health checking (keepalive) also must be enabled on the port profile level or the real server level.
Otherwise, the health-check policy is used during initial bringup of the server but is not used for
periodic health checks after the server is brought up.
NOTE
If the health check for an application on a server is disabled, the Brocade Virtual ADX assumes that
the server and application are healthy and continues to send client requests to the server.
NOTE
If you change the health-check state from within the element-action expression, this state overrides
the health-check state configured in the port profile for the application port or in the real server
configuration.
NOTE
You can globally enable or disable all health-check policies. Refer to “Globally disabling all
health-check policies” on page 222.
Attaching a health-check policy to an application port
on a server
After you configure logical expressions, you can attach them to application ports on real servers.
The Brocade Virtual ADX does not begin sending health-check packets until you attach the policy to
a real server port.
To attach a health-check policy to an application port on a server, enter commands such as the
following.
Virtual ADX(config)#server real-name R1 10.10.10.50
Virtual ADX(config-rs-R1)#port 80 healthck “check1”
This command configures the Brocade Virtual ADX to base the health of application port 80 on real
server R1 on the results of the check1 health-check policy.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
205
4
Element health checks
Displaying health-check policies and their status
To display a list of the configured health-check policies and their current status, enter the following
command.
Virtual ADX(config-hc-check1)#show healthck
Total nodes: 6; Max nodes: 128
Name
Value
Enable
Type
Dest-IP
Port
Proto
Layer
-------------------------------------------------------------------------------check1
TRUE
YES
tcp
10.10.10.50
http
http
l4-chk
check2
TRUE
YES
tcp
10.10.10.40
http
http
l7-chk
check3
TRUE
NO
udp
10.10.10.30
http
http
l4-chk
check4
TRUE
NO
udp
10.10.10.40
http
http
l4-chk
httpsrvr
TRUE
YES
and
check1 check2
nested1
N/A
na
and
check1 check2
nested2
N/A
na
or
check3 check4
Syntax: show healthck
Table 19 displays the health-check policy status.
TABLE 19
Health-check policy status
Field
Description
Total nodes
The number of health-check policies in the configuration. The number includes attached and
unattached policies.
Max nodes
The maximum number of health-check policies you can configure.
Name
The element-action expression or policy name.
Value
The current value of the policy. The value can be one of the following:
TRUE – The most recent health check performed using this policy was successful. The
Brocade Virtual ADX received a valid reply to the health check.
• FALSE – The most recent health check performed using this policy was unsuccessful.
• N/B – The health check is not bound to any VIP and thus is not in use.
• N/A (Not Attached) – The policy is not attached to a real server.
•
NOTE: If the policy is disabled, this value is always TRUE, because the Brocade Virtual ADX
assumes a server is healthy unless its health check is enabled and the server has not
responded appropriately to the health check.
Enable
206
The state of the policy, which can be one of the following:
YES – The policy is enabled.
NO – The policy is disabled.
na (not applicable) – This field does not apply to the policy. This value indicates that the
policy is not attached to a real server.
•
•
•
Type
The element-action expression or policy type. For Layer 3 health checks, this information
consists of ICMP and the IP address tested by the health check.
Values can be one of the following:
• tcp – An element-action expression for a TCP application port.
• udp – An element-action expression for a UDP application port.
• and – A policy containing element-action expressions joined by AND.
• or – A policy containing element-action expressions joined by OR.
Dest-IP
For element-action expressions, the IP address of the real server. For policies, this field shows
the element-action expressions in the policy.
The value “ - ”indicates that the IP address has not been specified.
Port
For element-action expressions, the application port. This field does not apply to policies.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Element health checks
TABLE 19
4
Health-check policy status (Continued)
Field
Description
Proto
For element-action expressions, the health-check method to be used for the port.
NOTE: If the value is " - ", the protocol has not been specified and the port is not well-known to
the Brocade Virtual ADX.
Layer
The type of health check, which can be one of the following:
l4-chk – Layer 4 TCP or UDP health check.
l7-chk – Layer 7 application-specific health check.
•
•
Displaying health-check policy statistics
To display health-check policy statistics, enter the following command.
Virtual ADX(config)#show healthck statistics
Ping Statistics:
Sent: 1524
Received: 1524
Invalid Replies: 0
Dropped Replies: 0
Syntax: show healthck statistics
Table 20 displays the health-check policy statistics.
TABLE 20
Health-check policy statistics
Field
Description
Sent
The number of health-check packets sent by bound health-check policies.
Received
The number of replies received. A received reply results in a true condition.
NOTE: Since the Brocade Virtual ADX retries a health check if a reply is not received, a higher
sent count than receive count does not necessarily indicate a problem.
Invalid Replies
The number of replies that were received that had an invalid ID. The Brocade Virtual ADX is
sometimes able to resolve an invalid ID. If the Brocade Virtual ADX cannot resolve the invalid
ID, the device drops the reply and increments the Dropped Replies counter.
Dropped Replies
The number of replies that the Brocade Virtual ADX dropped.
Clearing health-check policy statistics
To clear health-check policy statistics, enter the following command.
Virtual ADX(config)#clear healthck statistics
Syntax: clear healthck statistics
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
207
4
Health check with content match
Health check with content match
Content match for HTTP
Configuring HTTP content matching lists
The Brocade Virtual ADX currently 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.
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
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 the Brocade Virtual 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 Virtual
ADX would mark the port UP, as the default configured is UP.
In the second example above, for match-list m2, Brocade Virtual 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
Virtual ADX examines text in an HTML file sent by a real server in response to an HTTP keepalive
request. The Brocade Virtual 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.
Virtual
Virtual
Virtual
Virtual
ADX(config)#http match-list m1
ADX(config-http-ml-m1)#down simple "404"
ADX(config-http-ml-m1)#down simple "File Not Found"
ADX(config-http-ml-m1)#exit
The first command sets the name of the matching list and enters the HTTP matching list CLI level.
The first down statement looks for the text “404” in the HTML file sent from the real server in
response to an HTTP keepalive request; the second down statement looks for the text “File Not
Found.” If either of these text strings are found in the HTML file, the Brocade Virtual ADX marks
port 80 (HTTP) on the real server FAILED. If neither of the text strings are found, the Brocade Virtual
ADX marks the port ACTIVE.
Syntax: http match-list matching-list-name
Syntax: down I up simple text [log]
The down simple and up simple statements specify the selection criteria in the matching list.
NOTE
There is a limit of 200 selection criteria statements for all HTTP matching lists; that is, the total
number of up and down statements in all HTTP matching lists on the Brocade Virtual ADX must not
exceed 200.
208
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Health check with content match
4
NOTE
The HTTP page file size returned by the server should be less than 100kb.
When an HTML file meets more than one set of selection criteria in a matching list, the Brocade
Virtual ADX takes one of the following actions:
• If the strings that meet the selection criteria are different, the Brocade Virtual ADX takes action
based on the string that comes first in the file. For example:
Virtual
Virtual
Virtual
Virtual
ADX(config)#http match-list m2
ADX(config-http-ml-m2)#down simple "monkey"
ADX(config-http-ml-m2)#up simple "elephant"
ADX(config-http-ml-m2)#exit
The selection criteria in the matching list above would cause the Brocade Virtual ADX to mark
the port FAILED if the text "monkey" is found and ACTIVE if the text "elephant" is found. If the
HTML file has the text "monkey" at the beginning and "elephant" at the end, the Brocade Virtual
ADX would mark port 80 on the real server FAILED, because "monkey" occurs first in the file.
• If a string that meets the selection criteria is a subset of another, the longer string takes
precedence, regardless of where it occurs in the file. For example:
Virtual
Virtual
Virtual
Virtual
ADX(config)#http match-list m3
ADX(config-http-ml-m3)#down simple "elephant"
ADX(config-http-ml-m3)#up simple "elephantine"
ADX(config-http-ml-m3)#exit
In this example, Brocade Virtual ADX would mark the port FAILED if the text “elephant” is found
and ACTIVE if the text “elephantine” is found. If the HTML file has the text “elephant” at the
beginning and “elephantine” at the end, the Brocade Virtual ADX would mark port 80 on the
real server ACTIVE, because “elephantine” is longer than “elephant”.
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.
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
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.
Syntax: down | up compound start end [log]
Syntax: default down | up
In this matching list, the up and down commands include the compound parameter, which allows
you to specify beginning and ending parts of a set of selection criteria. Text that begins with the first
part and ends with the second part meets the selection criteria.
In this example, the up command specifies that if the HTML file sent from the real server in
response to an HTTP keepalive request contains a text string that begins with the text “monkey
see” and ends with the text “monkey do”, port 80 on the real server is marked ACTIVE. The down
commands specify that if the HTML file contains a text string that begins with “500” and ends with
“Internal Server Error” or begins with “503” and ends with “Service Unavailable”, the port is
marked FAILED.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
209
4
Health check with content match
The default command specifies what happens if none of the HTML text in the HTTP response
message meets the selection criteria. You can specify either up or down; the default is up. If the
real server responds to the health check with a RST, the port is marked ACTIVE or FAILED
depending on what was specified in the default statement in the matching list.
The log parameter causes the following warning message to be logged when the selection criteria
is met.
00d00h00m00s:W:HTTP match-list matching-list with compound pattern1 start and pattern2 end
Alert: bring server down and Extract message: text-between-start-and-end-pattern
In the example, at the successful completion of an HTTP content verification health check, the
following message would be logged; that is, if the HTML file sent from the real server in response to
an HTTP keepalive request contains a text string that begins with the text “monkey see” and ends
with the text “monkey do”.
Virtual ADX#show logging
Syslog logging: enabled (0 messages dropped, 0
Buffer logging: level ACDMEINW, 1 messages
level code: A=alert C=critical D=debugging
I=informational N=notification
flushes, 0 overruns)
logged
M=emergency E=error
W=warning
Dynamic Log Buffer (50 entries):
02d04h47m12s:W:HTTP match-list m4 with compound pattern1 "monkey see" and
pattern2 "monkey do" Alert: bring server up and Extract message: This web page is
configured correctly
Displaying HTTP match lists
To display the contents of matching lists configured on the Brocade Virtual ADX, enter the following
command.
Virtual ADX#show http match-list
http match-list m1
down simple "404"
down simple "File Not Found"
http match-list m4
default down
up compound "monkey see" "monkey do" log
down compound "500" "Internal Server Error" log
down compound "503" "Service Unavailable" log
Syntax: show http match-list
Binding the matching list to the real servers
To enable HTTP content verification on the Brocade Virtual ADX, you bind the matching list to one or
more real servers, by entering commands such as the following.
Virtual
Virtual
Virtual
Virtual
ADX(config)#server real-name rs1 192.168.1.1
ADX(config-rs-rs1)#port http content-match m4
ADX(config-rs-rs1)#port http url "GET/monkey.html"
ADX(config-rs-rs1)#exit
Syntax: server real-name real-server-name ip-addr
Syntax: port http content-match matching-list-name
Syntax: port http url “[GET | HEAD] [/]URL-page-name”
210
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Health check with content match
4
In this example, the port http content-match m4 command binds matching list m4 to real server
rs1. HTTP response messages coming from real server rs1 are examined using the selection
criteria in matching list m4.
The port http url command sets the method used for HTTP keepalive requests and the URL of the
page to be retrieved. This command is used in HTTP content verification health checks because the
default method and URL page for HTTP keepalive requests used in HTTP health checks, “HEAD
/1.0”, does not return an HTML file that the Brocade Virtual ADX can search and verify. You can
instead specify the GET method, which does return an HTML file that can be examined using the
matching list.
Content match for non-HTTP ports
Configuring scripted health checks
You can configure scripted health checks (also known as content checking), which are content
verification health checks for ports that do not use one of the well-known port numbers recognized
by the Brocade Virtual ADX. Previous releases supported content verification health checks on port
80 only.
In a scripted health check, the Brocade Virtual ADX opens a connection to a port on a real server by
sending a SYN packet. The Brocade Virtual ADX completes the three-way handshake and then
waits for the server to send a packet containing ASCII strings in response. It then searches for the
configured ASCII string in the received packet. The port on the real server is then marked ACTIVE or
FAILED, based on configuration settings in the matching list. For example, a matching list can be
configured to mark a port ACTIVE or FAILED if the string is found, or mark the port ACTIVE or FAILED
if the string is not found.
If no response is received within the configured interval (the default is five seconds), the Brocade
Virtual ADX sends an RST and retries the health check. After the configured number of retries (the
default is two retries), if the server still does not respond, the Brocade Virtual ADX marks the server
port FAILED.
A scripted health check can also be part of a health-check policy. In this case, the scripted health
check checks the health of a configured port in the policy. The health-check policy can be
evaluated to true or false depending on the response from the server.
Follow the steps given below to configure a scripted health check.
1. Configuring a port profile
2. Configuring a matching list
3. Binding the matching list to the real server
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, because the Brocade Virtual
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.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
211
4
Health check with content match
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 Virtual ADX from
marking a port ACTIVE until it passes both Layer 4 and Layer 7 health checks.
Virtual ADX(config)#server port 12345
Virtual ADX(config-port-12345)#tcp
Virtual ADX(config-port-12345)#no-fast-bringup
Syntax: server port TCP/UDP-portnum
Syntax: tcp | udp [keepalive interval retries]
Syntax: no-fast-bringup
Configuring a matching list
The selection criteria used in a content verification health check is specified in a matching list that
is bound to one or more real servers. The syntax used for creating a matching list for scripted
health checks is the same as that used for creating a matching list for HTTP content verification
health checks.
The following is an example of a matching list that will mark a port ACTIVE if the string “FTP service”
is found in the response from the real server. If this text is not found, the port on the real server is
marked FAILED.
Virtual
Virtual
Virtual
Virtual
ADX(config)#http match-list m1
ADX(config-http-m1-m1)#up simple "FTP service"
ADX(config-http-m1-m1)#default down
ADX(config-http-ml-m1)#exit
In this example, the default down command causes the port on the real server to be marked
FAILED if the selection criteria is not found in the response from the server.
For information on the command syntax, refer to “Configuring HTTP content matching lists” on
page 208.
Binding the matching list to the real server
To enable the scripted health check on the Brocade Virtual ADX, you bind the matching list to one
or more real servers. For example, to bind matching list m1 to real server R, enter commands such
as the following.
Virtual ADX(config)#server real R 10.10.10.50
Virtual ADX(config-rs-R)#port 12345 content-check m1
Syntax: port portnum content-check matching-list-name
The portnum variable specifies a non-well-known port. You cannot specify a well-known port for a
scripted health check.
The matching-list-name variable specifies a previously configured matching list. If the
matching-list-name does not refer to an existing matching list, the port on the real server is marked
FAILED when the health check is performed.
212
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Health check with content match
4
Using a scripted health check in a health-check policy
A scripted health check can be used in a health-check policy. A health-check policy is a group of
one or more health checks attached to a real server port. When the scripted health check checks
the health of a destination port specified in the policy, the health-check policy can be evaluated to
true or false depending on the response from the server.
To use a scripted health check with a health-check policy, you configure a matching list, then
configure the health-check policy.
For example, when the following matching list is used with a health-check policy, it will evaluate the
policy to true if the string “FTP service” is found in the response from the real server. If this text is
not found, the policy is evaluated to false.
Virtual
Virtual
Virtual
Virtual
ADX(config)#http match-list m1
ADX(config-http-m1-m1)#up simple "FTP service"
ADX(config-http-m1-m1)#default down
ADX(config-http-ml-m1)#exit
The default down command causes the policy to be evaluated to false if the selection criteria is not
found in the response from the server. If the real server responds to the health check with an RST,
the policy is evaluated to true or false depending on what was specified in the default statement in
the matching list.
Configuring a health check policy
The following commands create a health check policy for TCP port 1234 on VIP 10.10.10.10.
Matching list m1 is bound to this policy.
Virtual
Virtual
Virtual
Virtual
ADX(config)#healthck check1 tcp
ADX(config-hc-check1)#dest-ip 10.10.10.10
ADX(config-hc-check1)#port 1234 content-check m1
ADX(config-hc-check1)#l7-check
Syntax: [no] healthck element-name protocol
Syntax: [no] dest-ip { ipv4-addr | ipv6-addr }
The ipv4-addr variable specifies the IPv4 address of the real server.
The ipv6-addr variable specifies the IPv6 address of the real server.
Syntax: [no] port portnum content-check matching-list-name
Syntax: [no] l7-check
Note that the dest-ip ipv4-addr or ipv6-addr command must be the first command entered for a
health-check policy. If this is not the first command entered for the policy, an error message is
displayed.
If the matching-list-name variable does not refer to an existing matching list, the policy is evaluated
to false.
The l7-check command is required to ensure that the Brocade Virtual ADX performs a Layer 7
health check. If this command is omitted, the Brocade Virtual ADX performs only a Layer 4 health
check, and not the scripted health check.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
213
4
Health check with content match
Scripted health check enhancement on real servers
When the port port-name command is configured with the content-check send option to send a
string to the server, the Brocade Virtual ADX establishes a TCP connection, and on receiving a
SYN-ACK, sends the configured string to the server. The device then waits for the server to send
ASCII text and then brings the server port up or down, based on the configured match-list policy.
In the following example, the Brocade Virtual ADX sends a SYN packet to server 10.10.1.31, port
1234. On receiving a SYN-ACK from the server, the Brocade Virtual ADX sends a TCP packet with
the data "how are you". The Brocade Virtual ADX then waits for the server. In the data of the TCP
packets sent by the server, the Brocade Virtual ADX will look for the pattern "good". If found, the
Brocade Virtual ADX marks the real server r1 port 1234 as UP; otherwise, it will mark the port as
DOWN.
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server real r1 10.10.1.31
ADX(config-rs-r1)#port 1234 keepalive
ADX(config-rs-r1)#port 1234 content-check m1
ADX(config-rs-r1)#port 1234 content-check send "how are you"
ADX(config-rs-r1)#exit
ADX(config)#http match-list m1
ADX(config-http-ml-m1)#up simple good
ADX(config-http-ml-m1)#default down
Syntax: [no] port port-name content-check match-list-name
Syntax: [no] port port-name content-check send "string"
NOTE
The l7-check command must be enabled in order for the Brocade Virtual ADX to send the script. If
the l4-check command is configured, the Brocade Virtual ADX will establish a TCP connection and
then send an RST.
Binary scripted health check
The scripted health check feature allows the Brocade Virtual ADX to complete 3-way TCP
handshake followed by sending an ASCII string and waiting for an appropriate response before
marking real server health. If the customer is running an application that can not interpret data in
ASCII format, this methodology will not help.
Binary scripted heath check allows the application switch to send binary data (carray format) after
doing a 3-way TCP handshake with the backend server. The Brocade Virtual ADX would then mark
the health of the server as pass or failed depending on the response content match (again in
carray format). This feature is implemented using the content-check-array option within the real
server port command as shown in the following sample configuration.
Virtual
Virtual
Virtual
0xe4”
Virtual
Virtual
Virtual
Virtual
ADX(config)#server real rs1 10.1.1.1
ADX(config-rs-rs1)#port 1111 content-check-carray m1
ADX(config-rs-rs1)#port 1111 content-check-carray send “0xe1,0xe2,0xe3,
ADX(config-rs-rs1)#port 1111 keepalive
ADX(config)#http match-list m1
ADX(config-http-m1-m1)#default down
ADX(config-http-m1-m1)#up simple 0xca,0xcb,0xcd,0xce
Syntax: [no] port port-name content-check-carray match-list-name
The port-name variable defines the port where the binary scripted health check is performed.
214
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Health check with content match
4
The match-list-name variable defines the name of the matching list used in the binary scripted
health check.
Syntax: [no] port port-name content-check-carray send Carray-data
The port-name variable defines the port where the binary scripted health check is performed.
The Carray-data variable defines the binary data in C array format used in the binary scripted
health check. The maximum number of characters supported is 2000.
NOTE
Sending binary data after a 3-way handshake is not mandatory.
Scripted health check for UDP ports
The scripted health check feature enhances the TrafficWorks software to perform customizable
scripted health checks for UDP protocol. in addition to the current TCP protocol, this feature is
available on any out-of-band port and is able to use the existing L7 content check features.
The Brocade Virtual ADX currently supports scripted health-checks on TCP ports. This feature adds
support for scripted health-checks on UDP ports.
When scripted health-check is configured on a UDP port, the Brocade Virtual ADX will send out a
UDP packet with the content-check-send data if configured; otherwise, it will send out a UDP
packet. Then it expects a UDP reply with ASCII content and will do the content-check on the data
received. It will mark the port UP or DOWN according to the configuration in the match-list.
If an ICMP message is received, then the port will be brought down.
Command line interface
There is no new CLI added for this feature. The CLI is the same as that used for scripted
health-checks for TCP ports. Previously the CLI was restricted to TCP ports, while now that
restriction has been removed.
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server real r1 10.10.1.31
ADX(config-rs-r1)#port 1234 keepalive
ADX(config-rs-r1)#port 1234 content-check m1
ADX(config-rs-r1)#port 1234 content-check send "how are you"
ADX(config)#http match-list m1
ADX(config-http-ml-m1)#up simple good
ADX(config-http-ml-m1)#default down
In the above example, the Brocade Virtual ADX will send and UDP packet containing the ASCII string
"how are you." On receiving the reply, Brocade Virtual ADX will search for the string "good." If found,
it will mark port 1234 UP, otherwise it will mark the port DOWN.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
215
4
Boolean health checks
Boolean health checks
Boolean health-check policies
You can configure a group of Layer 4 and Layer 7 health checks as a health-check policy and
associate the group with a specific application port on a real server.1 Health-check policies enable
you to assess the health of any application port using the health-check mechanisms for ports
well-known to the Brocade Virtual ADX. In addition, health-check policies let you use multiple
checks with different parameters and base a port’s health on successful completion of all or any
one of the individual checks in the policy.
Depending on the conditions you specify when you configure a health-check policy, the Brocade
Virtual ADX will bring the application port on a server down in one of the following cases:
• Any one of the servers fails its health check (individual health checks combined using AND
condition) – In this case, all servers in the policy must pass their health checks. Otherwise, the
Brocade Virtual ADX considers all of the servers to have failed the health checks and brings
down the application on all servers that are checked by the policy.
• All of the servers fail their health checks (individual health checks combined using OR
condition) – In this case, an application port remains up as long as at least one of the servers
checked by the policy passes its health check.
For finer control, you can combine OR and AND conditions.
Health-check policy
Health-check policies consist of element-action expressions and logical expressions.
• An Element-action expression consists of the IP address of the server, the Layer 4 protocol
(TCP or UDP), and the application port on the server. For some applications, the element-action
expression can also include Layer 7 application-specific health check information.
• A Logical expression is a set of element-action expressions joined by the Boolean operators
OR, AND or NOT.
-
To create a health-check policy that is successful if at least one of the applications passes
its health check, use OR.
-
To configure a health-check policy that is successful only if the Brocade Virtual ADX
receives a successful reply from all servers and application ports in the policy, use the
operator AND.
-
To configure a health-check policy that is successful if none of the elements responds to
the health check, use the operator NOT.
You can use the same element-action expressions in multiple logical expressions if desired. You
can configure up to 254 health-check policies.
1.
216
Real servers include those added using the server real-name command and those added using
the server remote-name command. Generally, both types of servers are referred to as real
servers. An application port is a port that uses the TCP or UDP protocol. You associate
health-check policies with TCP or UDP ports on the real servers (not with physical ports on the
servers).
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Boolean health checks
4
Follow the steps given below to use a health-check policy.
1. Configure the element-action expressions.
2. Configure the health-check policy using element-action expressions and logical expressions
joined by the operators AND or OR or NOT.
3. Attach logical expressions to application ports on specific real servers. A health check policy
does not take effect until you attach it to an application port on a server.
NOTE
A health-check policy does not take effect (begin sending health check packets) until you
attach the policy to an application port on a real server.
Configuring boolean health check
A health-check policy consists of one or more element-action expressions. When a logical
expression contains multiple element-action expressions, the policy also contains the logical
operator AND or OR or NOT. You can use a health-check policy as an element-action expression in
another policy.
To configure a health-check policy, enter commands such as the following.
Virtual ADX(config)#healthck "httpsrvr" boolean
Virtual ADX(config-hc-httpsrvr)#and "check1" "check2"
These commands configure a health-check policy that uses the element-action expressions
"check1" and "check2". Because the AND operator is used, the real servers in both "check1" and
"check2" must reply successfully for the health check to be successful. If only one of the servers
replies, the health check is unsuccessful and the Brocade Virtual ADX stops using all the server
application ports in the health-check policy "httpsrvr".
Syntax: [no] healthck "policy-name" boolean
Syntax: and | or "element-name" "element-name"
The policy-name variable specifies the name of the health-check policy. The name can be up to
20 characters long. The name cannot contain blanks.
The and or or command specifies a logical operator in the health-check policy. You can enter
two element-action expressions along with the logical operator and, or or not.
• If you specify and, the policy evaluates to true only if all elements (IP addresses) respond to the
health check.
• If you specify or, the policy is true if at least one of the elements responds to the health check.
• If you specify not, the policy is true if none of the elements responds to the health check.
If you are configuring a boolean UDP health check policy, define the static next hop MAC address
along with a VLAN ID for on that link; otherwise, the Brocade Virtual ADX cannot learn the
next-hop-mac-address of that link. Enter commands such as the following to define a static
next-hop-mac-address and a VLAN-ID.
Virtual ADX(config-link-link3)#next-hop-mac-address 00e0.5208.dd8e vlan-id 40
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
217
4
Boolean health checks
The address 00e0.5208.dd8e is the MAC address of Link3's access router interface. The vlan-id
40 is the Brocade Virtual ADX’s interface, that is used to connect Link3's access router is in VLAN
40
Syntax: next-hop-mac-address mac-address vlan-id vlan#
Using a nested health-check policy
If you want to use a single health-check policy to test more than two IP addresses, configure
health-check policies for all the IP addresses, and use them in another health-check policy. For
example, to create a health-check policy that tests four IP addresses, enter commands such as the
following.
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#healthck check1 tcp
ADX(config-hc-check1)#dest-ip 10.10.10.50
ADX(config-hc-check1)#port http
ADX(config-hc-check1)#healthck check2 tcp
ADX(config-hc-check2)#dest-ip 10.10.10.20
ADX(config-hc-check2)#port http
ADX(config-hc-check2)#healthck check3 tcp
ADX(config-hc-check3)#dest-ip 10.10.10.30
ADX(config-hc-check3)#port http
ADX(config-hc-check3)#healthck check4 tcp
ADX(config-hc-check4)#dest-ip 10.10.10.40
ADX(config-hc-check4)#port http
The commands above configure four element-action expressions, one for each of four servers. The
following commands configure two health-check policies, each of which contains two of the
element-action expressions.
Virtual
Virtual
Virtual
Virtual
ADX(config-hc-check4)#healthck nested1 boolean
ADX(config-hc-nested1)#or check1 check2
ADX(config-hc-nested1)#healthck nested2 boolean
ADX(config-hc-nested2)#or check3 check4
The following command creates a health-check policy that contains the two policies configured
above. The result is a single health-check policy for all four IP servers.
Virtual ADX(config-hc-nested2)#healthck checkall boolean
Virtual ADX(config-hc-checkall)#or nested1 nested2
In this example, the OR logical operator is used in all the policies. Therefore, the "checkall" health
check is successful if at least one of the four servers responds. To create more restrictive policies,
you can use the AND logical operator. For example, if the AND operator is used in this configuration
instead of OR, the health check is successful only if all four servers respond.
You also can combine policies that use AND with policies that use OR in nested health-check
policies.
218
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Miscellaneous health check settings
4
Miscellaneous health check settings
Basing an alias port’s health on the health of its
master port
By default, the Brocade Virtual ADX performs health checks for alias ports independently of the
master ports on which they are based. For example, if you configure alias port 8080 and base the
port on port 80 (its master port), the Brocade Virtual ADX checks the health of 80 and 8080
independently.
You can configure the Brocade Virtual ADX to check the health of the master port only and base the
health of the alias ports on the master port.
You can base an alias port’s health on the health of one of the following TCP ports:
• FTP – port 21 (ports 20 and 21 both are FTP ports but on the Brocade Virtual ADX, the name
“FTP” corresponds to port 21)
•
•
•
•
•
•
•
•
•
•
•
HTTP – port 80
IMAP4 – port 143
LDAP – port 389
MMS – port 1755
NNTP – port 119
PNM – port 7070
POP3 – port 110
RTSP – port 554
SMTP – port 25
SSL – port 443
TELNET – port 23
You cannot base an alias port’s health on the health of a UDP port or a port that is not well-known
to the Brocade Virtual ADX.
NOTE
The health checks for the alias ports must be enabled. Otherwise, the Brocade Virtual ADX will not
check the master port’s state, and the alias port will not go down when the master port goes down.
To configure an alias port’s health to be based on its master port’s health, edit the alias port’s
profile by entering commands such as the following.
Virtual ADX(config)#server port 8080
Virtual ADX(config-port-8080)#tcp keepalive use-master-state
Syntax: [no] tcp keepalive use-master-state
The command is entered at the port profile level.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
219
4
Miscellaneous health check settings
Basing a port’s health on the health of another port
You can configure the Brocade Virtual ADX to base the health of a port that is not well-known to the
Brocade Virtual ADX on the health of one of the following ports that are well-known to the Brocade
Virtual ADX:
• DNS (port 53)
• FTP (port 21). Ports 20 and 21 both are FTP ports but on the Brocade Virtual ADX, the name
“FTP” corresponds to port 21.
•
•
•
•
•
•
•
HTTP (port 80)
IMAP4 (port 143)
LDAP (port 389)
POP3 (port 110)
NNTP (port 119)
SMTP (port 25)
TELNET (port 23)
To base a port’s health on the health of another port, enter a command such as the following.
Virtual ADX(config-port-1234)#tcp keepalive port 80
Syntax: tcp | udp keepalive port TCP/UDP-portnum
The command in this example configures the Brocade Virtual ADX to base the health of port 1234
on the health of port 80 (HTTP). If the health of port 80 changes, the Brocade Virtual ADX applies
the change to port 1234.
NOTE
You cannot base the health of a port well-known to the Brocade Virtual ADX on the health of another
port, whether the port is well-known or not well-known.
Reassign threshold
The reassign threshold specifies the number of contiguous inbound TCP-SYN packets a real server
can fail to respond to before the Brocade Virtual ADX changes the application state to FAILED and
the server state to TEST. The server and application states are described in “Server and application
port states” on page 184.
The value of an application's reassign counter is reset to 0 when the Brocade Virtual ADX receives
a TCP SYN ACK from the application. No other type of traffic can clear this field. This reassign
counter can be seen with the show server real name_or_ip detail command where the name_or_ip
variable is the real server's ASCII name or IP address.
If a real server seems to be triggering the reassign threshold too frequently, you can increase the
reassign threshold. The reassign threshold is disabled by default. To modify the reassign threshold
to 215, enter a command such as the following:
Virtual ADX(config)#server reassign-threshold 215
Syntax: server reassign-threshold threshold-value
The range of values for the threshold-value variable is 6 through 4000. If you do not specify a
number, the Brocade Virtual ADX assigns a default threshold value of 20.
220
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Miscellaneous health check settings
4
NOTE
It is possible to take a service down without triggering the reassign threshold. For example, if no new
TCP SYN packets are being sent to a real server that has its application disabled, the real server will
not fail to respond to enough consecutive TCP SYNs to meet the reassign threshold. As a result, the
Brocade Virtual ADX indicates the real server and the service are ACTIVE when in fact they might
have been disabled.
NOTE
The reassign threshold does not apply to servers in Direct Server Return (Direct Server Return)
configurations. The reassign counter is not incremented in such configurations. In a Direct Server
Return configuration, traffic from the real server does not pass back through the Brocade Virtual
ADX. As a result, the Brocade Virtual ADX cannot monitor the TCP SYN ACKs from the server. Refer
to “Configuring Direct Server Return” on page 57.
NOTE
The Brocade Virtual ADX does not try to reassign the client’s request to another server if you
configure the application port to be sticky. The sticky option configures the Brocade Virtual ADX to
override load-balancing and send all client requests for the application to the same server during a
given session.
NOTE
If a real server seems to be triggering the reassign threshold too frequently, you can increase the
reassign threshold. This is a global parameter.
Preventing state flapping
You can prevent state flapping caused by the reassignment counter.
By default, the Brocade Virtual ADX brings an application port down if the port's reassignment
count exceeds the reassign threshold. If an application port's reassign counter exceeds the
reassign threshold, the Brocade Virtual ADX marks the port failed. Once the port is marked failed,
the port can be re-activated as a result of a successful health check on the port.
In some networks, the reassignment counter can cause needless state flapping of application
ports. This occurs if the network conditions cause the counter to frequently reach the threshold
and cause the Brocade Virtual ADX to mark otherwise healthy applications as failed. The
applications will remain unavailable for the amount of time it takes the Brocade Virtual ADX to send
health checks, interpret the results, and activate the application ports in response to successful
results.
NOTE
The reassignment count applies to the total number of contiguous (back-to-back) unanswered SYNs
from all clients who have sent SYNs to the server.
To prevent state flapping caused by the reassignment counter, enter the following command.
Virtual ADX(config)#server no-reassign-count
When you enter this command, the Brocade Virtual ADX will stop incrementing the reassignment
counters for real server applications.
Syntax: [no] server no-reassign-count
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
221
4
Miscellaneous health check settings
Globally disabling all health-check policies
You can easily disable all the health-check policies configured on the Brocade Virtual ADX. To do so,
enter the following command at the global CONFIG level of the CLI.
Virtual ADX(config)#no server l4-check
NOTE
This command also disables the TCP and UDP Layer 4 health checks for all applications that are not
associated with a health-check policy.
Syntax: [no] server l4-check
To re-enable the health-check policies, enter the following command.
Virtual ADX(config)#server l4-check
NOTE
The server l4-check command does not enable a policy if its element-action expressions contain the
disable command. In this case, the policy remains disabled.
Health checking for real servers in other subnets
The Brocade Virtual ADX must be able to receive the real server’s response to a health check in
order to assess the success of the health check. In topologies where reply traffic from a real server
is guaranteed to pass through the Brocade Virtual ADX, the Brocade Virtual ADX is able to receive
replies to the health checks.
However, if the topology is such that the Brocade Virtual ADX and real servers are in different
subnets or the server reply is not guaranteed to pass back though the Brocade Virtual ADX, you
might need to use source NAT and configure a source IP address. Source NAT and source IP
addresses allow the Brocade Virtual ADX to have multiple subnet identities. Generally, the Brocade
Virtual ADX is a member of only one subnet, the subnet that contains the Brocade Virtual ADX’s
management IP address. You can place the Brocade Virtual ADX into up to eight additional subnets
by enabling source NAT and adding source IP addresses to the Brocade Virtual ADX.
Normally, the Brocade Virtual ADX uses its management IP address as the source address for
health check packets. When you enable source NAT and add a source IP address, the Brocade
Virtual ADX uses the source IP address as the source for the health check packets. Thus, when the
real server replies, the reply is addressed to the source IP address instead of the Brocade Virtual
ADX’s management IP address.
Best path to a remote server
NOTE
Brocade recommends that you use this feature whenever the Brocade Virtual ADX is in the direct
path between the remote server and the default gateway.
When the Brocade Virtual ADX sends a health check to a remote server, the Brocade Virtual ADX
sends the health check through the default gateway, because the remote server’s subnet is
different from the subnet of the Brocade Virtual ADX’s management IP address. In some
topologies, the Brocade Virtual ADX’s default gateway is not the most direct path to the remote
server. Figure 24 shows an example.
222
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Miscellaneous health check settings
FIGURE 24
4
Health check of remote server – learned MAC address is not used
In this example, the Brocade Virtual ADX sends the health check through its default gateway. The
default gateway sends the health check back to the Brocade Virtual ADX, because Router R1’s
route to the remote server lists the Brocade Virtual ADX as the next hop. Despite the unnecessary
trip through the default gateway, the health check still reaches the remote server. However, if you
want to eliminate unnecessary hops, you can enable the Brocade Virtual ADX to learn the MAC
address from which the remote server’s health check reply is received, and send subsequent
health checks directly through that MAC address. Figure 25 shows the simplified health check
process.
FIGURE 25
Health check of remote server – learned MAC address is used
To enable the Brocade Virtual ADX to use learned MAC addresses for sending health checks to
remote servers, enter the following command.
Virtual ADX(config-rs-remote1)#use-learned-mac-address
Syntax: [no] use-learned-mac-address
NOTE
This command does not apply to local servers. Because local servers are attached at Layer 2, the
Brocade Virtual ADX does not need to use a gateway or otherwise route the health check to the
server.
Handling traffic initiated from remote server
Under normal conditions, traffic is always initiated from a client and return traffic is processed by
looking up the session table. However, a real server may have to initiate traffic to a client in some
complex protocols such as Active FTP. The Brocade Virtual ADX checks the source MAC to handle
the traffic initiated from the remote server.
To enable the Brocade Virtual ADX to check the source IP instead of source MAC to handle the
traffic from a remote server, enter the following command:
Virtual ADX(config)#server identify-server-by-ip
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
223
4
Miscellaneous health check settings
Syntax: [no] server identify-server-by-ip
Health check of multiple websites on the same real server
If you host multiple websites on the same real server, with each website using a different VIP, you
can perform an independent health check for each VIP.
One method for binding two VIPs to the HTTP port on the same real server, you create an alias for
the HTTP port on one of the VIPs. To create an alias for the HTTP port, you configure the VIP to bind
to an alternate port number on the real server, then disable port translation for that binding. The
Brocade Virtual ADX collects and presents information for the alias port number, but traffic from
both VIPs actually goes to the HTTP port on the real server.
The state of the master port is used for indicating the health of ports aliased to the master port. For
example, if a VIP uses port 81 as an alias for the HTTP port, then the state information reported for
the HTTP port is used as the state information for port 81. If the HTTP port is reported down, then
port 81 is reported down.
When a real server supports multiple websites, tying the alias port's state to the master port's state
can cause incorrect information to be reported. For example, consider a real server hosting VIPs v1
and v2. VIP v1 is bound to the HTTP port on the real server, and VIP v2 uses port 81 as an alias for
the HTTP port. The Layer 7 health check reports state information about the HTTP port. When VIP
v1 is taken down for maintenance, the Layer 7 health check reports that the HTTP port is down.
Because the state information reported for the HTTP port is also used as the state information for
port 81, the Brocade Virtual ADX considers port 81 to be down as well, incorrectly reflecting the
state of VIP v2, which could be functioning normally.
To eliminate this problem, you establish separate health checks for the alias ports. Health checks
for the alias ports will continue to be performed regardless of the HTTP port's status. The following
is an example of this kind of configuration.
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server virtual-name-or-ip v1 192.168.1.160
ADX(config-vs-v1)#port http
ADX(config-vs-v1)#bind http rs32 http
ADX(config-vs-v1)#exit
ADX(config)#server virtual-name-or-ip v2 192.168.1.161
ADX(config-vs-v2)#port http
ADX(config-vs-v2)#port http use-alias-port-state
ADX(config-vs-v2)#no port http translate
ADX(config-vs-v2)#bind http rs32 81
ADX(config-vs-v2)#exit
ADX(config)#server real rs32 10.1.1.32
ADX(config-rs-rs32)#port http
ADX(config-rs-rs32)#port http keepalive
ADX(config-rs-rs32)#port http url "HEAD /"
ADX(config-rs-rs32)#port 81
ADX(config-rs-rs32)#port 81 keepalive
ADX(config-rs-rs32)#port 81 url "GET /81keepalive.htm"
ADX(config-rs-rs32)#exit
In this configuration, two VIPs are bound to a single real server. VIP v2 uses port 81 as an alias for
port 80; information the Brocade Virtual ADX receives about port 81 is attributed to VIP v2. If VIP v1
is taken down for maintenance, the Layer 7 health check done for port 80 fails, and the Brocade
Virtual ADX marks the HTTP port FAILED. However, health checks continue to be performed for port
81. Port 81 (and thus VIP v2) will continue to be reported active as long as it passes its health
check.
224
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Miscellaneous health check settings
4
Minimum healthy real servers under VIP port
The minimum healthy servers feature allows a VIP port to handle traffic only if the a configured
number of real server ports bound to the VIP port are healthy and UP. This would allow virtual
servers to stay down unless they have enough server capacity to handle the load.
Command line interface
The command to turn on minimum healthy servers feature is under virtual server configuration.
Virtual
Virtual
Virtual
Virtual
http
ADX(config)#server virtual-name-or-ip v1 10.1.1.1
ADX(config-virtual-server-v1) port 80
ADX(config-virtual-server-v1) port 80 minimum-servers 2
ADX(config-virtual-server-v1) bind http rs1 http rs2 http rs3 http rs4
The VIP will not answer connections on port http until at least 2 of the real or remote servers bound
to port http are UP.
Server port bring-up enhancement
The Brocade Virtual ADX currently brings a port up after it passes the configured health-check. This
feature allows user to configure retries for bringup, so that the Brocade Virtual ADX brings up a port
only after the configured number of retries have passed. The real server port will need to pass the
configured number of checks before coming up.
Command line interface
The command to turn on server port bring-up enhancement feature is under port profile
configuration.
Virtual ADX(config)#server port 80
Virtual ADX(config-port-80) bringup-retries 10
The Brocade Virtual ADX will now bring port 80 up only after it has passed the number variable of
health-checks. Previously port 80 would have been marked as up after the first time it passes a
health-check.
Slow-start mechanism
When the Brocade Virtual ADX begins sending client requests to a real server that has recently
gone online, it allows the server to ramp up by using the slow-start mechanism. The slow-start
mechanism allows a server (or a port on the server) to handle a limited number of connections at
first and then gradually handle an increasing number of connections until the maximum is
reached.
The Brocade Virtual ADX uses two kinds of slow-start mechanisms:
• The non-configurable server slow-start mechanism applies to a real server that has just gone
online
• The configurable port slow-start mechanism applies to individual TCP application ports that
have just been activated on a real server
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
225
4
Miscellaneous health check settings
Overview
The Brocade Virtual ADX uses the server slow-start mechanism to adjust the maximum number of
connections that can be established for a real server that has just gone online. The Brocade Virtual
ADX begins with a connection limit that is lower than the maximum configured value (which is one
million by default) and gradually increases this connection limit until the maximum configured
value is reached.
The server slow-start mechanism is especially useful when least connections is the distribution
predictor. Without the server slow-start mechanism, a server that is just brought online could
receive all the new connections in a flurry, which could bring the server down. Many servers cannot
handle more than 2,000 new connections per second.
NOTE
The server slow-start mechanism is always applied to all real servers when they are brought online.
Unlike the slow-start mechanism for individual ports, described in the next section, the server
slow-start mechanism is not configurable.
The two graphs in Figure 26 illustrate how the server slow-start mechanism ramps up the
connections for a real server during the 30-second slow-start period. The graph on the left shows
the rate at which the number of connections increases over the slow-start period. The graph on the
right shows how the maximum number of connections that the Brocade Virtual ADX allows for the
real server increases over the slow-start period.
FIGURE 26
Slow-start mechanism for a real server
The graph on the left shows the rate at which the Brocade Virtual ADX allows connections for a
given real server, as follows:
• From the time the real server is brought online from 10 seconds to 20 seconds, the Brocade
Virtual ADX allows a max-connection rate of 10 times the elapsed time. During this period, the
Brocade Virtual ADX increases up to 10 new connections every second on the real server.
226
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Miscellaneous health check settings
4
• At 21 seconds,the Brocade Virtual ADX allows a max-connection rate of 20 times the elapsed
time. The Brocade Virtual ADX increases the connections to 420 and from 22 seconds to 29
seconds, the Brocade Virtual ADX allows up to 20 new connections every second.
• At 30 seconds, the maximum number of connections is reached.
The graph on the right shows how the maximum number of connections allowed for the real server
increases over the 30-second slow-start period.
Table 21 lists the maximum number of connections a real server can have during each second of
the slow-start period.
TABLE 21
Maximum number of connections for a real server
Seconds after going online
Max. connections
Seconds after going online
Max. connections
1
10
16
160
2
20
17
170
3
30
18
180
4
40
19
190
5
50
20
200
6
60
21
420
7
70
22
440
8
80
23
460
9
90
24
480
10
100
25
500
11
110
26
520
12
120
27
540
13
130
28
560
14
140
29
580
15
150
30
Maximum
When the slow-start period ends after 30 seconds, the maximum number of connections a real
server can have is determined by the max-conn setting for the real server and is one million
connections by default.
NOTE
When you disable and re-enable a real server, the Brocade Virtual ADX will go through the slow-start
mechanism for the server if it is not disabled. When you disable and re-enable a real-server port, the
Brocade Virtual ADX does not go through the port level slow-start mechanism.
Port slow-start mechanism
When individual TCP application ports on a real server are activated, they are allocated
connections using the port slow-start mechanism, which works differently from the server
slow-start mechanism described in the previous section.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
227
4
Miscellaneous health check settings
When a port on a real server becomes active, the Brocade Virtual ADX applies the default
slow-start mechanism to regulate how quickly connections for the port are established. In addition,
you can set up a user-configured slow-start mechanism that regulates how quickly connections are
established for specific ports on specific real servers. The following sections explain how the
default slow-start mechanism works, along with how to set up a user-configured slow-start
mechanism and apply it to a port on a real server.
Default port slow-start mechanism
By default, when a port is activated, the Brocade Virtual ADX gives it 60 seconds of warm-up time.
Over this period, the Brocade Virtual ADX gradually increases the number of connections it allows
for the port. The default slow-start mechanism is always applied to all ports when they are first
brought online, unless they are configured to use a user-configured slow-start mechanism.
The two graphs in Figure 27 illustrate how the default slow-start mechanism ramps up the
connections for a port on a real server. The graph on the left shows the rate at which the number of
connections increases over the slow-start period. The graph on the right shows how the maximum
number of connections the Brocade Virtual ADX allows for the port on the real server increases
over the slow-start period.
FIGURE 27
Default slow-start mechanism for a port
The graph on the left shows the rate at which the Brocade Virtual ADX allows connections for a
given port on a real server, as follows:
• At the time the port is activated, the Brocade Virtual ADX allows 10 connections. Then, up to
10 seconds, the Brocade Virtual ADX allows the port up to 10 new connections every second.
• From 10 seconds to 20 seconds, the Brocade Virtual ADX allows up to 20 new connections
every second.
• From 20 seconds to 30 seconds, the Brocade Virtual ADX allows up to 30 new connections
every second.
228
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Miscellaneous health check settings
4
• From 30 seconds to 40 seconds, the Brocade Virtual ADX allows up to 40 new connections
every second.
• From 40 seconds to 50 seconds, the Brocade Virtual ADX allows up to 50 new connections
every second.
• From 50 seconds to 60 seconds, the Brocade Virtual ADX allows up to 100 new connections
every second.
• After 60 seconds, the connection flow control delivered by the slow-start mechanism ends, and
the Brocade Virtual ADX allows up to the maximum number of connections for the port on the
server. The maximum number of allowed connections for a real server is set by the max-conn
command; this maximum is one million connections by default.
The graph on the right shows how the maximum number of connections allowed for the port on the
real server increases over the slow-start period.
Table 22 lists the maximum number of connections a port can have at 10-second intervals.
TABLE 22
Maximum number of connections for a port
Seconds after port activated
Max. connections
10
110
20
310
30
610
40
1,010
50
1,510
60
2,510
When the slow-start period ends after 60 seconds, the maximum number of connections that a
port on a real server can have is determined by the max-conn setting for the real server and is one
million connections by default.
Setting up a user-configured port slow-start mechanism
You can configure how quickly the Brocade Virtual ADX ramps up a particular port on a particular
real server by setting up a user-configured slow-start mechanism. Unlike the default port slow-start
mechanism, which applies to all ports on all real servers, a user-configured slow-start mechanism
is applied to a specific port on a specific real server.
A user-configured slow-start mechanism sets the rate at which the Brocade Virtual ADX allows
connections for a port over two configurable intervals (which comprise the slow-start period), along
with a limit for the total number of connections that the port on the real server can have during the
time the server is active.
Setting up a user-configured slow-start mechanism consists of the following two steps.
1. Setting up a slow-start list for a port
2. Applying the slow-start list to a port on a real server
Setting up a slow-start list for a port
To set up a slow-start list for port 80 (HTTP), enter commands such as the following.
Virtual ADX(config)#server port 80
Virtual ADX(config-port-80)#slow-start 101 10 30 20 30 600
Virtual ADX(config-port-80)#exit
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
229
4
Miscellaneous health check settings
Syntax: slow-start list-id rate1 interval1 rate2 interval2 max-connections
In the slow-start command, the list-id variable specifies the slow-start list. This variable can be a
number from 1 through 1000000. When you apply the slow-start list to a port on a real server, you
refer to the slow-start list by the variable specified here. You can create multiple slow-start lists for
a given port and assign them each an ID number.
The rate1 variable specifies the number of connections per second allowed for the port during the
first interval. This variable can be a number from 1 through 1000000. From the time the port is
activated until the end of the first interval, the Brocade Virtual ADX allows the port on the real
server to receive up to this number of new connections every second.
The interval1 variable specifies the length of the first interval in seconds. This variable can be a
number from 1 through 1000000.
The rate2 variable specifies the number of connections per second allowed for the port during the
second interval. Allowed values are from 1 through 1000000. From the end of the first interval until
the end of the second interval, the Brocade Virtual ADX allows the port on the real server to receive
up to this number of new connections every second.
The interval2 variable specifies the length of the second interval in seconds. This variable can be a
number from 1 through 1000000. The number of seconds in the first interval plus the number of
seconds in the second interval are equal to the slow-start period. In this example, value specified
for the interval1 variable is 30 seconds, and the value specified for the interval2 value is 30
seconds, so the slow-start period is 60 seconds.
The max-connections variable sets a ceiling for the number of concurrent connections allowed for
the port during the time the server is active. This can be a number from 1 through 1000000. No
more than this number of connections can be established for the port on the real server where this
slow-start mechanism is applied.
Applying the slow-start list to a port on a real server
After you have created a slow-start list, you apply it to a port on a real server, by entering
commands such as the following.
Virtual
Virtual
Virtual
Virtual
ADX(config)#server real-name rs1 192.168.1.1
ADX(config-rs-rs1)#port http
ADX(config-rs-rs1)#port http slow-start 101
ADX(config-rs-rs1)#exit
Syntax: port port slow-start list-id
The port http slow-start 101 command binds slow-start list 101 (defined for port 80 above) to port
80 (HTTP) on real server rs1.
230
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Miscellaneous health check settings
4
Using the slow-start list defined above, the two graphs in Figure 28 illustrate how a user-configured
slow-start mechanism ramps up the connections for a port on a real server. The graph on the left
shows the rate at which the number of HTTP connections increases over the slow-start period. The
graph on the right shows how the maximum number of HTTP connections the Brocade Virtual ADX
allows for real server rs1 increases over the slow-start period.
FIGURE 28
Example of a user-configured slow-start mechanism for port 80 (HTTP) on a real server
The graph on the left shows the rate at which the Brocade Virtual ADX allows HTTP connections for
real server rs1, as follows:
• From the time port 80 (HTTP) on real server rs1 is activated until 30 seconds afterwards (until
the end of interval 1), the Brocade Virtual ADX allows the real server up to 10 (rate 1) new HTTP
connections every second.
• From 30 seconds to 60 seconds (until the end of interval 2), the Brocade Virtual ADX allows up
to 20 (rate 2) new HTTP connections every second.
• After 60 seconds (interval 1 plus interval 2), the slow-start period ends, and the Brocade
Virtual ADX allows up to the maximum number of connections for the server set by the
max-connections variable in the slow start list.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
231
4
Miscellaneous health check settings
The graph on the right shows how the maximum number of possible HTTP connections for real
server rs1 increases over the slow-start period:
• Ten seconds after going online, the maximum number of HTTP connections real server rs1 can
have is 300: a maximum of 10 (rate 1) new HTTP connections per second for 30 (interval 1)
seconds equals 300 total HTTP connections for real server rs1.
• After 30 seconds, the maximum number of HTTP connections for real server rs1 increases by
20 (rate 2) connections per second, until 600 HTTP connections (the ceiling specified by the
max-connections variable in the slow-start list) is reached. This ceiling of concurrent 600 HTTP
connections applies for the entire time the server is active; the Brocade Virtual ADX allows the
server no more than this number of concurrent HTTP connections.
Applying a user-configured slow-start mechanism to multiple ports
To apply a user-configured slow-start mechanism to more than one port, create slow-start lists for
each port and apply them to ports on one or more real servers. For example, to configure a
slow-start mechanism for HTTP (port 80) and SSL (port 443), enter commands such as the
following.
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config) #server port 80
ADX(config-port-80)#slow-start 100 10 30 20 30 600
ADX(config-port-80)#slow-start 101 20 30 40 30 1500
ADX(config-port-80)#exit
ADX(config)#server port 443
ADX(config-port-80)#slow-start 101 20 60 40 120 2400
ADX(config-port-80)#exit
ADX(config)#server real-name rs2 192.168.1.2
ADX(config-rs-rs2)#port http
ADX(config-rs-rs2)#port http slow-start 100
ADX(config-rs-rs2)#exit
ADX(config)#server real-name rs3 192.168.1.3
ADX(config-rs-rs3)#port http
ADX(config-rs-rs3)#port http slow-start 101
ADX(config-rs-rs3)#port ssl
ADX(config-rs-rs3)#port ssl slow-start 101
ADX(config-rs-rs3)#exit
The commands create two slow-start lists for port 80 (HTTP) and one for port 443 (SSL). Slow-start
list 100 for port 80 is applied to the HTTP port on real server rs2. Slow-start list 101 for port 80 is
applied to the HTTP port on real server rs3. Slow-start list 101 for port 443 is applied to the SSL
port on real server rs3. Note that slow-start list 101 for port 80 has no relation to slow-start list 101
for port 443.
In this configuration, port 80 on real server rs2 and ports 80 and 443 on real server rs3 are each
subject to a user-configured slow-start mechanism. All other ports on the real servers are subject to
the default slow-start mechanism described in “Default port slow-start mechanism” on page 228.
Globally disabling or re-enabling the slow-start mechanism
You can globally disable the mechanism. When you disable the slow-start mechanism, the Brocade
Virtual ADX can immediately send up to the maximum number of connections specified for the real
server when the server becomes available. Disabling slow-start does not remove the slow-start
configuration information from the real servers.
To re-activate slow-start, globally disable the feature.
Virtual ADX(config)#server no-slow-start
232
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Miscellaneous health check settings
4
To globally re-enable slow-start, enter a command such as the following.
Virtual ADX(config)#no server no-slow-start
Syntax: [no] server no-slow-start
FIN close for server health check
FIN close replaces the RESET close for a TCP health check. To enable FIN close, use the following
command.
Virtual ADX(config)#server keepalive-fin
Syntax: [no] server keepalive-fin
Health-check state
When you attach a health-check policy to a real server’s application port, the Brocade Virtual ADX
uses the health-check policy for periodic health checks and also for the next initial bringup of the
server. When a health-check policy is attached, the Brocade Virtual ADX no longer uses the default
health check methods for initial bringup and periodic health checks.
For the Brocade Virtual ADX to use a health-check policy, you must enable health checking
(keepalive) at either the port profile level or the real server level for the server port. Otherwise, the
state of the policy is FALSE, and the state of the server port remains in the state that it was before
you attached the policy.
NOTE
Use the show healthck command to display the policy state. Use the show server real-name name
command to show the real server port state.
If health checking for a server port is disabled at the port profile level and at the real server level,
the Brocade Virtual ADX will continue to use whichever state is based on the health check during
the initial server bringup. The Brocade Virtual ADX will not be able to update the port’s state if the
state changes.
To enable health checking at the port profile level, enter commands such as the following.
Virtual ADX(config)#server port 80
Virtual ADX(config-port-80)#tcp keepalive enable
These commands enable health checking for TCP port 80.
For a UDP port, enter commands such as the following.
Virtual ADX(config)#server port 53
Virtual ADX(config-port-53)#udp keepalive enable
To enable health checking at the real server level, enter commands such as the following.
Virtual ADX(config)#server real-name R1 10.10.10.10
Virtual ADX(config-rs-R1)#port 80 keepalive
You can enable health checking at the port profile level, at the real server level, or both. Health
checking must be enabled on at least one of these levels for the Brocade Virtual ADX to use the
health-check policy you attach to the port.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
233
4
Miscellaneous health check settings
Enhanced server bringup
Enhanced Server Bringup increases the speed of the bringup process by sending more (up to a
maximum of 50) health-checks at one time.
In previous releases, the Brocade Virtual ADX sent a health check for each real server port in a
configuration, in the process of bringing up all of the ports. As a result, if the configuration
contained many real server ports, the Brocade Virtual ADX would take too much time to bring all of
the ports up, one port at a time. To make the bringup process faster, the Brocade Virtual ADX now
sends more bringup health-checks at a time (up to a maximum of 50). The actual number of
health-checks that the Brocade Virtual ADX sends at any given instance depends on the number of
server ports that are in the testing state. The Brocade Virtual ADX performs Layer 2 and Layer 3
health checks, and if these are successful, it puts the port in a testing state. When it is time to send
out bringup health checks, the Brocade Virtual ADX collects all the server ports that are in the
testing state, and sends them health checks.
The actual number of health checks that are sent out at any given instance also depends on the
number of server ports for which the Brocade Virtual ADX has sent out the health-check request
and is still waiting for response. For example, if there are 75 server ports configured on the
Brocade Virtual ADX, and at the first instance 30 of these have passed the Layer 2 and Layer 3
checks, the Brocade Virtual ADX sends out bringup health-checks to these 30 server ports. In the
next 100 ms, when it is time to send out health-checks again, if only 20 of the above 30 server
ports have responded and are UP, then there are 10 ports that are still in the bringup process.
Assuming that the remaining 45 server ports have all passed Layer 2 and Layer 3 checks, the
Brocade Virtual ADX can send bringup health-checks for 40 server ports, because it is waiting for
response for the 10 previously sent. In the next 100 ms cycle, it is time to send the next round of
health-checks. At this point, if the Brocade Virtual ADX got responses from all the 50 server ports, it
now sends bringup health-checks for the remaining five server ports. The Brocade Virtual ADX can
send 50 bringup health-checks at a time separately for TCP and UDP ports.
Track-Port support under real server for health checks
The feature allows tracking of several secondary ports based on the health of the primary port.
These secondary ports can be TCP or UDP ports.
Overview
When a group of ports are configured as part of a track-port, the Brocade Virtual ADX can track the
health of the master port (the port that is configured as the first port) and the rest of the ports in
the track-port list will follow the state of the master port.
If the master port is down, the remaining ports in the track-port list would have their master state
as down and traffic will not get forwarded to any of the ports on the track-port list, even though
their individual health-checks state might be UP.
Configuration
To turn on this feature, use the hc-track-port which is under the real server configuration as shown:
Virtual
Virtual
Virtual
Virtual
Virtual
234
ADX(config)#server real r1 10.1.1.1
ADX(config-real-server-r1) port 80
ADX(config-real-server-r1) port ftp
ADX(config-real-server-r1) port dns
ADX(config-rsr1) hc-track-port 80 21 53
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Sample show commands
4
The Brocade Virtual ADX now tracks the health status of port 80. If the health-check state of port
80 is DOWN, then all the other ports in the track-port list will have their health-check state as also
DOWN. In this case, FTP and DNS have their master state as DOWN and traffic is not load balanced
on these ports.
Syntax: [no] hc-track-port port ...port
The port variable specifies the secondary ports that will be tracked based on the health of the
primary port. These secondary ports can be TCP or UDP ports.
Show Commands
The output from the show hc-track-port-state command displays when a primary port passed or
failed a health check. Two examples are shown below:
Virtual ADX#show hc-track-port-state
Real Server
track-port
state
rs1
80 21 800 53
ACTIVE
Virtual ADX#show hc-track-port-state
Real Server
track-port
state
rs1
80 21 800 53
DOWN
In the first example above, the primary port passed the health check while in the second example,
the primary port went down because of a failed health check.
NOTE
The output above may be truncated. For a complete output display, use the show hc-track-port-state
detail command.
Syntax: show hc-track-port-state
Sample show commands
Syslog for health status change
The Brocade Virtual ADX generates Syslog messages for changes to the Layer 4 or Layer 7 status of
a real server. To display the Syslog buffer on the Brocade Virtual ADX, enter the following command.
Virtual ADX(config)#show logging
Dynamic Log Buffer (50 entries):
03d02h47m38s:N:L4 server 192.168.1.170 danPC is down
03d02h46m18s:N:L4 server 192.168.1.170 danPC is up
03d02h46m08s:I:Interface ethernet5, state up
This example shows log entries for a real server named "danPC" with IP address 192.168.1.170. In
this example, the real server passed a Layer 4 or Layer 7 health check ("up"), but then failed a
Layer 4 or Layer 7 health check ("down") later.
Syntax: show logging
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
235
4
Sample show commands
NOTE
The log messages do not distinguish between Layer 4 and Layer 7 health checks. When the status
changes based on either type of health check, the Brocade Virtual ADX logs the event as shown in
this example.
Session table parameters
The Brocade Virtual ADX maintains state information for TCP and UDP connections in the session
table. The session table contains an entry for each TCP and UDP session between the Brocade
Virtual ADX and a client or real server. The Brocade Virtual ADX uses the session table entries for
health checks, stateful failover in hot-standby configurations, and other functions.
Each entry in the session table is a session. A session consists of the following:
•
•
•
•
•
Source IP address
Source application port
Destination IP address
Destination application port
Protocol (TCP or UDP)
A connection consists of two sessions, a send session and a receive session. For example, a TCP
connection between a client and a server consists of two sessions, a client-to-server session and a
server-to-client session.
NOTE
"Stateless" features such as stateless application ports and stateless health checks do not use
session table entries.
This section describes how to configure the following session table parameters:
•
•
•
•
•
Maximum number of sessions
Maximum age of TCP session entries
Maximum age of UDP session entries
Clock scale for TCP and UDP session age timers
Logging of session table entries
Configuring the maximum number of active sessions
An active session is a session entry in the Brocade Virtual ADX session table. A UDP or TCP session
that has become idle, but has not yet timed out (according to the UDP or TCP age timer), is an
active session in this table.
To configure the maximum number of active sessions on a Brocade Virtual ADX, use the following
command.
Virtual ADX(config)#server session-asm-limit 50000
Syntax: server session-asm-limit value
The value variable specifies the maximum number of active sessions on a Brocade Virtual ADX.
This value can range from 32768 to 4,000,000. The default value is 2,000,000.
236
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Sample show commands
4
For this change to take effect, you must save the change to the startup-config file, then reload the
software using the following commands.
Virtual ADX(config)#write memory
Virtual ADX(config)#end
Virtual ADX#reload
Configuring fast session aging
The Brocade Virtual ADX supports fast session aging. When fast session aging is enabled with the
server session-max-idle command, the Brocade Virtual ADX can rapidly age out sessions when the
number of available free sessions drops below specified threshold values.
The threshold values are specified as percentages of the maximum number of sessions available
on the Brocade Virtual ADX (the "max-sessions" value). The number of free sessions that trigger
fast session aging is calculated using the following formula.
number of free sessions = (max-sessions * threshold) / 100
For example, if the max-sessions value on the Brocade Virtual ADX is 500,000 sessions, and the
threshold is 30%, then fast session aging is triggered when the number of free sessions reaches
150,000 or fewer; that is (500,000 * 30) / 100.
Two thresholds can be configured for fast session aging: the fast-age threshold and the random
threshold:
• Fast-age threshold—When the number of free sessions drops below the fast-age threshold,
sessions older than a specified time are aged out.
• Random threshold—When the number of free sessions drops below the random threshold,
sessions are aged out randomly, without regard to session age. The random threshold can be
equal to or lesser than the fast-age threshold.
For example, if the fast-age threshold is reached, sessions as old as or older than a specified
amount of time (for example, 5 minutes) are aged out until the number of available sessions climbs
above 150,000. If the random threshold is reached, sessions are aged out at random until the
number of available sessions climbs above 150,000.
Fast session aging is disabled by default. To configure fast session aging, enter a command such
as the following.
Virtual ADX(config)#server session-max-idle 5 30 10
Syntax: [no] session-max-idle max-idle-time [fast-age-threshold random-threshold]
The max-idle-time variable specifies the number of minutes allowed for idle sessions when a
fast-age-threshold variable is configured. When the value specified in the fast-age-threshold
variable is reached, sessions that are the same as and older than the threshold are aged out until
the number of free sessions exceeds the value specified in the fast-age-threshold variable. The
value of the max-idle-time variable can be from 1 through 30 minutes. The default is 0 minutes
(disabled). To enable fast session aging, you must specify a value for the max-idle-time variable
that is greater than 0.
When the number of available sessions drops below the value specified in the fast-age-threshold
variable, sessions older than the value specified in the max-idle-time variable are aged out until the
number of free sessions exceeds the threshold. The value of the fast-age-threshold variable is
expressed as a percentage of the maximum number of sessions available on the Brocade Virtual
ADX. The value specified for the fast-age-threshold can be from 10 through 70 percent. The default
is 33 percent.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
237
4
Sample show commands
When the number of available sessions drops below the value specified for the random-threshold
variable, sessions are aged out randomly, without regard to session age, until the number of free
sessions exceeds the threshold. The value specified for the random-threshold variable is expressed
as a percentage of the maximum number of sessions available on the Brocade Virtual ADX. The
value specified for the random-threshold variable can be from 1 through 30 percent. The default is
0 percent (disabled).
NOTE
Even though the max-idle-time value is not used with the random-age threshold, you must still
specify a value for the max-idle-time variable when configuring the random threshold to enable the
fast session aging feature.
Displaying information about fast aging
Two fields in the output of the show server sessions command display information about the
sessions subject to fast aging.
The following is an example of the output from the show server sessions command. The fields
related to fast session aging are highlighted in bold.
Virtual ADX#show server sessions
Avail. Sessions
=
524282 Total Sessions
=
524288
Total C->S Conn
=
0 Total S->C Conn
=
0
Total Reassign
=
0 Unsuccessful Conn
=
0
Fast-aged : total
=
0 last 60 sec
=
0
Random-aged : total =
0 last 60 sec
=
0
Server State - 1:enabled, 2:failed, 3:test, 4:suspect, 5:grace_dn, 6:active
Real Server
rs1
rs2
State
CurrConn
1
1
0
0
TotConn TotRevConn
0
0
0
0
CurrSess
PeakConn
0
0
0
0
Syntax: show server sessions
If the fast-age threshold is configured, the command displays both the total number of sessions
that were aged out because of the free sessions dropping below the fast-age threshold, and the
number of sessions that were aged out in the last 60 seconds.
If the random threshold is configured, the command also displays the total number of sessions that
were aged out at random because the number of free sessions dropped below the random
threshold, along with the number of sessions that were aged out randomly in the last 60 seconds.
Clearing statistics counters for fast session aging
To clear the statistics counters for fast session aging, enter the following command.
Virtual ADX(config)#clear server fast-age-counters
Syntax: clear server fast-age-counters
This command resets the "Fast-aged : total" counter and corresponding "last 60 sec" counter as
displayed by the show server sessions command.
238
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Sample show commands
4
Clearing statistics counters for sessions that aged out randomly
If the random threshold is configured, you can clear the statistics counters for sessions aged out
randomly, by entering the following command.
Virtual ADX(config)#clear server random-age-counters
Syntax: clear server random-age-counters
This command resets the "Random-aged : total" counter and corresponding "last 60 sec" counter
as displayed by the show server sessions command.
Configuring TCP age
The TCP age specifies how many minutes a TCP server connection can remain inactive before the
Brocade Virtual ADX times out the session.
If you change the TCP age, the change affects only new TCP sessions that start after you make the
change. The maximum age for sessions that are already in the session table does not change.
NOTE
This parameter globally sets the age for all TCP ports. To override the setting for an individual TCP
port, change that port’s profile. Refer to “Overriding the global TCP or UDP age” on page 192.
To modify the server TCP age, enter a command such as the following.
Virtual ADX(config)#server tcp-age 20
Syntax: server tcp-age time
The time variable is a value from 2 through 60 minutes. The default is 30 minutes.
NOTE
The session age is per minute and has a one minute range. For example, if you configured a TCP age
of three minutes, the age timeout is from two to three minutes.
Configuring UDP age
You can modify the aging out parameter for inactive UDP server connections. To modify the server
UDP age to 20 minutes from the default value of 5 minutes, enter a command such as the
following.
Virtual ADX(config)#server udp-age 20
This parameter globally sets the age for all UDP ports. To override the setting for an individual TCP
port, change that port’s profile. Refer to “Overriding the global TCP or UDP age” on page 192.
Syntax: [no] server udp-age minutes
The minutes variable is a value from 2 through 60 minutes. The default is 5 minutes; the default
age for DNS and RADIUS is 2 minutes.
The Brocade Virtual ADX immediately deletes a UDP DNS or RADIUS session table entry when it
receives a reply for the application from a real server. You can configure the Brocade Virtual ADX to
age these ports like other UDP ports, using the UDP age timer. Refer to “Enabling normal UDP aging
for DNS and RADIUS” on page 121.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
239
4
Sample show commands
For DNS and RADIUS UDP load balancing, the age value does not follow the normal configuration
and default value unless the udp-normal-age option is configured on the port, under the virtual
server port definition, the port dns udp-normal-age command. (Refer to “Enabling normal UDP
aging for DNS and RADIUS” on page 121.) The default UDP age will always be 2 minutes unless the
udp-normal-age option is configured.
Setting the clock scale
The Brocade Virtual ADX uses a configurable clock scale for the following session timers:
• TCP age
• UDP age
To adjust the clock scale for configurations that require TCP or UDP timeouts longer than the
maximum configurable value (60 minutes), enter a command such as the following.
Virtual ADX(config)#server clock-scale 2
When you set the clock scale to 2, the TCP and UDP age timer values are multiplied by 2. As a
result, a TCP age of 60 would then be equivalent to 120 minutes instead of 60 minutes.
Syntax: [no] server clock-scale multiplier
The multiplier variable can be a value from 1 through 20. The default is 1.
Syslog for session table entries
You can configure the Brocade Virtual ADX to send a message to external Syslog servers when the
software creates a session table entry. The messages indicate the following information:
•
•
•
•
•
•
•
•
Source IP address
Source TCP or UDP application port
Destination IP address
Destination TCP or UDP application port
Layer 4 protocol (TCP or UDP)
Message time (measured in units of 100 milliseconds, relative to system uptime)
URL (optional)
Cookie (optional)
You can enable TCP/UDP logging on a global basis for all TCP and UDP ports or for individual TCP or
UDP ports.
When you enable TCP/UDP logging, you can specify whether all new session table entries generate
log messages or only the entries that are used for Source NAT.
In addition, you can enable logging for URL or Cookie information. The URL logging option applies
only when URL switching is enabled. The Cookie logging option applies only when Cookie switching
is enabled.
Here is an example of a Syslog message for a session.
src-ip = 192.168.002.032
src-port = 00197
dst-ip = 192.168.002.012
dst-port = 00080
protocol = TCP
time =0000078656
Url = abcdefghijklmnop
Cookie = qrstuvwxyz
240
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Sample show commands
4
The time value in this example is in the format for devices on which the system time add date have
not been set.
NOTE
The feature description and command syntax use the terms “session” and “connection”. A
connection consists of multiple sessions, for the send and receive directions.
NOTE
Because the log messages are generated when the software creates a session table entry, features
that do not use session table entries do not result in log messages. For example, if you configure a
TCP or UDP port to be stateless, the Brocade Virtual ADX does not create session table entries for
the port and therefore does not generate log messages for the port.
Enabling TCP/UDP session logging
When TCP/UDP session logging is enabled, the Brocade Virtual ADX sends a message to the
external Syslog servers when the software creates a session table entry. You can enable session
logging globally for all ports or on an individual basis for TCP or UDP ports.
To globally enable logging for all new session table entries, enter the following command.
Virtual ADX(config)#server connection-log all
To enable logging only for new sessions that are used for Source NAT, enter the following command.
Virtual ADX(config)#server connection-log src-nat
To enable session logging for a specific TCP or UDP port, enter the following command.
Virtual ADX(config)#server port 80
Virtual ADX(config-port-80)#connection-log all url cookie
Syntax: [no] server connection-log all | src-nat [url] [cookie]
The all option enables logging for all sessions.
The src-nat option enables logging only for sessions that are used for Source NAT.
The url option enables logging of URL information for sessions that contain a URL.
The cookie option enables logging of cookie information for sessions that contain a cookie.
NOTE
The URL logging option applies only when URL switching is enabled. The cookie logging option
applies only when cookie switching is enabled.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
241
4
242
Sample show commands
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Chapter
Layer 7 Content Switching
5
Overview
CSW enables Layer 7 application content based traffic direction for non-HTTP protocols such as
Financial Information Exchange (FIX) protocol. This chapter describes the Layer 7 Switching
features in the Brocade Virtual ADX.
• “Layer 7 content switching” on page 243
• “Layer 7 content switching on HTTP response” on page 271
NOTE
Fast session synch is not supported in Layer 7 or TCP-offload configurations.
NOTE
You can define up to 255 policies and 1000 rules system wide. A maximum of 500 rules can be
defined under a single policy.
NOTE
Layer 7 content switching load balancing is not supported where both sticky connections and track
group features are configured.
NOTE
Alias ports should be treated like regular ports and should have the same server ID and group ID.
Layer 7 content switching
Layer 7 switching allows the Brocade Virtual ADX to make forwarding decisions about HTTP traffic
based on information in a URL, or cookie. Advanced Layer 7 content switching allows the Brocade
Virtual ADX to make forwarding decisions about HTTP traffic by analyzing information contained
within the traffic.
The advanced Layer 7 content switching provides an enhancement over the Layer 7 switching
feature available in previous Brocade Virtual ADX releases by allowing you to configure load
balancing based on multiple HTTP header fields and XML content. The Layer 7 switching feature
available in previous releases is limited to load balancing traffic based on hostname, URL, and
cookie fields in the HTTP header.
Specifically, the new Layer 7 content switching feature provides the following functionality:
•
•
•
•
Load balancing based on any specified HTTP header
Load balancing based on XML content
Ability to make complex load-balancing decisions based on multiple HTTP headers or XML tags
Support for redirecting requests to alternate URLs or domains
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
243
5
Layer 7 content switching
• Support for persisting requests to servers, along with simple forwarding actions
• Support for content-rewrite functions, including cookie and HTTP header insertion and deletion
To configure Layer 7 content switching, you define content switching rules and policies. A rule
specifies the content that the Brocade Virtual ADX looks for in the incoming traffic, and a policy
associates rules with one or more actions that specify how the Brocade Virtual ADX handles traffic
matching the rule.
The following sections explain how to configure Layer 7 content switching on a Brocade Virtual ADX
and how to display information about a Layer 7 content switching configuration.
Enabling CSW
To enable Layer 7 content switching, you bind a content switching policy to a virtual server. For
example, to enable Layer 7 content switching on a virtual server called cswVIP, enter commands
such as the following.
Virtual ADX(config)#server virtual-name-or-ip cswVIP 192.168.20.254
Virtual ADX(config-vs-cswVIP)#port http csw-policy p1
Virtual ADX(config-vs-cswVIP)#port http csw
Syntax: [no] port portnum csw-policy policy-name
Syntax: [no] port portnum csw
The policy-name variable is a Layer 7 content switching policy. Refer to “Creating a policy” on
page 250.
Specifying scan depth
To configure actions based on content carried on top of the HTTP protocol (for example, XML
content) you must specify how far into the packet the Brocade Virtual ADX scans for the content.
The Brocade Virtual ADX scans up to the specified limit. If you do not specify a scan depth, then the
Brocade Virtual ADX scans to the end of the packet.
To specify the scan depth for HTTP content, enter commands such as the following:
Virtual ADX(config)#server virtual-name-or-ip cswVIP 192.168.20.254
Virtual ADX(config-vs-cswVIP)#port http csw-scan-depth 128
Virtual ADX(config-vs-cswVIP)#port http csw
Syntax: [no] port portnum csw-scan-depth length
The length variable specifies the number of bytes the Brocade Virtual ADX scans for content in a
packet. You can specify up to 8192 bytes. By default, the Brocade Virtual ADX scans to the end of
the packet.
Enabling CSW load balance
In HTTP 1.1, a client can send multiple requests over the same connection. The current behavior is
that Brocade Virtual ADX regards all requests as independent requests, namely it uses the load
balance predictor to perform server selection for each request. This is true even where the next
request from the client's connection goes to the same server group. After server selection, this
request may go to a different real server within the same server group. This can introduce the extra
delay for the client because it needs to establish a new connection for the new real server. If the
next request from the same client connection is forwarded within the same server group, the
244
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Layer 7 content switching
5
Brocade Virtual ADX will not run the server load balance predictor algorithm to choose a new
server. It will just use the same real server for the current request. If the next request goes to a
different server group, the Brocade Virtual ADX will follow the current code behavior to perform
server section.
The following command enables use of a load balancing predictor.
Virtual ADX(config)#server csw request-load-balance
Syntax: [no] server csw request-load-balance
Use the no option if you have previously enabled the command and want to remove it.
When you configure the server csw request-load-balance command, if the client sends two
requests to the Brocade Virtual ADX in the same connection and these two requests are switched
to the same group, CSW performs server selection based on load balance predictor. If you do not
configure this command, CSW uses the same server used by the first client request for the second
request.
NOTE
The server csw request-load-balance command is only applicable to keep-alive and TCP-offload
mode.
CSW rules
This section describes the rules available for Layer 7 content switching. You can define the
following types of rules:
• HTTP method rules – Cause the Brocade Virtual ADX to make a load balancing decision based
on the HTTP method in an incoming packet. Refer to “Configuring an HTTP method rule” on
page 245.
• HTTP version rules – Cause the Brocade Virtual ADX to make a load balancing decision based
on the HTTP version of an incoming packet. Refer to “Configuring an HTTP version rule” on
page 246.
• URL rules – Cause the Brocade Virtual ADX to make a load balancing decision based on the
contents of the URL string in an incoming packet. Refer to “URL rules” on page 246.
• HTTP header rules – Cause the Brocade Virtual ADX to make a load balancing decision based
on the contents of an HTTP header field in an incoming packet. Refer to “HTTP header rules”
on page 247.
• XML tag rules – Cause the Brocade Virtual ADX to make a load balancing decision based on
the contents of an XML tag in an incoming packet. Refer to “XML tag rules” on page 248.
NOTE
For CSW rules that use the prefix or suffix method, the matching string will be the complete string
and the offset is starts from the matching string.
Configuring an HTTP method rule
To set up an HTTP method rule that causes the Brocade Virtual ADX to make a load balancing
decision based on the HTTP method in an incoming packet, enter a command such as the
following.
Virtual ADX(config)#csw-rule r1 method eq PUT
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
245
5
Layer 7 content switching
This example creates a rule called r1 that matches if an incoming packet contains the PUT method.
Syntax: [no] csw-rule rule-name method eq method-string
The rule-name variable is the name of the rule and can be up to 80 characters in length.
The method-string variable can be GET, HEAD, POST, OPTIONS, PUT, DELETE, TRACE, PROPFIND,
MOVE, CONNECT, BDELETE, PROPPATCH, COPY, LOCK, UNLOCK, MKCOL, BCOPY, BMOVE, POLL,
SUBSCRIBE, SEARCH, BPROPPATCH, RPC_OUT_DATA, or RPC_IN_DATA.
Configuring an HTTP version rule
To set up an HTTP method rule that causes the Brocade Virtual ADX to make a load balancing
decision based on the HTTP version of an incoming packet, enter a command such as the
following.
Virtual ADX(config)#csw-rule r1 version eq 1.1
This example creates a rule called r1 that matches if an incoming packet uses HTTP version 1.1.
Syntax: [no] csw-rule rule-name version eq http-version
The rule-name variable is the name of the rule and can be up to 80 characters in length.
The http-version variable can be 0.9, 1.0, or 1.1.
URL rules
URL rules cause the Brocade Virtual ADX to make a load-balancing decision based on the contents
of the URL string in an incoming packet.
Table 23 lists the URL rules available for Layer 7 content switching.
TABLE 23
246
URL rules for Layer 7 content switching
URL rule
name
Description
Syntax
Example
URL Exists
Matches if a URL
string exists in the
incoming packet.
[no] csw-rule rule-name url
exists
csw-rule r1 url exists
URL Prefix
Matches if the
URL string begins
with the specified
prefix.
[no] csw-rule rule-name url
prefix value
csw-rule r1 url prefix "/home"
URL Suffix
Matches if the
URL string ends
with the specified
suffix.
[no] csw-rule rule-name url
suffix value
csw-rule r1 url suffix ".gif"
URL Pattern
Matches if the
specified pattern
exists anywhere
within the URL
string.
[no] csw-rule rule-name url
pattern value
csw-rule r1 url pattern "test"
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Layer 7 content switching
TABLE 23
5
URL rules for Layer 7 content switching (Continued)
URL rule
name
Description
Syntax
Example
URL Equals
Matches if the
URL string is
equal to the
specified value.
[no] csw-rule rule-name url
equals value
csw-rule r1 url equals
"/home.html"
URL Search
[no] csw-rule rule-name url
Matches if the
search value
URL string
contains any one
of up to five
specified values.
This type of rule
can be used with
the persist action.
csw-rule
csw-rule
csw-rule
csw-rule
csw-rule
r1
r1
r1
r1
r1
url
url
url
url
url
search
search
search
search
search
"srvr1"
"srvr2"
"srvr3"
"srvr4"
"srvr5"
HTTP header rules
HTTP header rules cause the Brocade Virtual ADX to make a load-balancing decision based on the
contents of an HTTP header field in an incoming packet.
In an Layer 7 content switching configuration, you can configure rules for the following HTTP header
fields: Connection, Transfer-Encoding, Content-Length, Host, Cookie, Pragma, and Cache-Control,
as well as up to 10 other HTTP header fields.
Table 24 lists the HTTP header rules available for Layer 7 content switching.
TABLE 24
HTTP header rules for Layer 7 content switching
HTTP header
rule name
Description
Syntax
Example
Header Exists
Matches if the
specified HTTP
header field exists
in the incoming
packet.
[no] csw-rule rule-name
header header-name
exists
csw-rule r1 header "host" exists
Header Prefix
Matches if the
value in the
specified HTTP
header field
begins with the
specified prefix.
[no] csw-rule rule-name
header header-name
prefix value
csw-rule r1 header "host" prefix
"www"
Header Suffix
Matches if the
value in the
specified HTTP
header field ends
with the specified
suffix.
[no] csw-rule rule-name
header header-name
suffix value
csw-rule r1 header "host" suffix
"com"
Header
Pattern
Matches if the
specified pattern
exists anywhere
within the
specified HTTP
header field.
[no] csw-rule rule-name
header header-name
pattern value
csw-rule r1 header "cookie"
pattern "Serverid"
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
247
5
Layer 7 content switching
TABLE 24
HTTP header rules for Layer 7 content switching (Continued)
HTTP header
rule name
Description
Syntax
Example
Header
Equals
Matches if the
contents of the
specified HTTP
header field are
equal to the
specified value.
[no] csw-rule rule-name
header header-name
equals value
csw-rule r1 header "host" equals
"www.example4.com"
Header
Search
Matches if the
specified HTTP
header field
contains any one
of up to five
specified values.
This type of rule
can be used with
the persist action.
[no] csw-rule rule-name
header header-name
search value
csw-rule r1 header "cookie" search
"ServerId1"
csw-rule r1 header "cookie" search
"ServerId2"
XML tag rules
XML tag rules cause the Brocade Virtual ADX to make a load balancing decision based on the
contents of an XML tag in an incoming packet. Rules for up to 200 different XML tags can be
specified in an Layer 7 content switching configuration. In a given policy, you can include rules for
up to 5 XML tags.
Table 25 lists the XML tag rules for Layer 7 content switching.
TABLE 25
248
XML tag rules for Layer 7 content switching
XML tag rule
name
Description
Syntax
Example
XML Tag
Exists
Matches if the
specified XML
tag exists in the
incoming packet.
[no] csw-rule rule-name xml-tag
tag-name exists
csw-rule r1 xml-tag "name"
exists
XML Tag
Prefix
Matches if the
value in the
specified XML
tag begins with
the specified
prefix.
[no] csw-rule rule-name xml-tag
tag-name prefix value
csw-rule r1 xml-tag "name"
prefix "ge"
XML Tag
Suffix
Matches if the
value in the
specified XML
tag ends with the
specified suffix.
[no] csw-rule rule-name xml-tag
tag-name suffix value
csw-rule r1 xml-tag "name"
suffix "ge"
XML Tag
Pattern
Matches if the
specified pattern
exists anywhere
within the
specified XML
tag.
[no] csw-rule rule-name xml-tag
tag-name pattern value
csw-rule r1 xml-tag "name"
pattern "org"
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Layer 7 content switching
TABLE 25
5
XML tag rules for Layer 7 content switching (Continued)
XML tag rule
name
Description
Syntax
Example
XML Tag
Equals
Matches if the
contents of the
specified XML
tag are equal to
the specified
value.
[no] csw-rule rule-name xml-tag
tag-name equals value
csw-rule r1 xml-tag "name"
equals "george"
XML Tag
Search
Matches if the
specified XML
tag contains any
one of up to five
specified values.
This type of rule
can be used with
the persist
action.
[no] csw-rule rule-name xml-tag
tag-name search value
csw-rule r1 xml-tag "name"
search "geo"
csw-rule r1 xml-tag "name"
search "edw"
Case-insensitive match for content switching
With Case-Insensitive Match for content switching (CSW you can optionally specify a CSW-rule or
CSW-policy to be case insensitive and the consequent match ignores case for the input.
The following example shows how to configure a case-insensitive rule.
Virtual ADX(config)#csw-rule r1 url pattern /test/index.html case-insensitive
Syntax: csw-rule rule-name url | header | method | xml-tag pattern pattern-to-match
[case-insensitive]
The case-insensitive option specifies the pattern match to be case insensitive.
The following example shows how to configure a case-insensitive policy.
Virtual ADX(config)#csw-policy p1 case-insensitive
Syntax: csw-policy policy-name [case-insensitive]
The case-insensitive option specifies that this policy is case-insensitive.
NOTE
You cannot mix case-insensitive policy and case-sensitive rules, or vice versa.
Wildcards in CSW rules for URL prefixes
Wildcards in CSW rules for URL prefixes behave as described for the following CSW rule:
csw-rule "pages0" url prefix "/pages/0*"
In this case, "/pages/0*" does not match on " /pages/0". It would only match on URLs such as
"/pages/01" and "/pages/011119011", where the URL is at least one byte longer that the part of
the rule before the asterisk.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
249
5
Layer 7 content switching
CSW policies
A policy specifies the action to take when a rule is matched. You can specify the following actions in
a policy:
• Forward action – Causes the Brocade Virtual ADX to forward packets matching a specified rule
to a specified real server or server group. Refer to “Configuring the forward action” on
page 250.
• Reply-error action – Causes the Brocade Virtual ADX to send a 403 error code page back to the
client when the specified rule is matched. Refer to “Configuring the reply-error action” on
page 253.
• Log action – Causes the Brocade Virtual ADX to write a message to Syslog when the specified
rule is matched. You can optionally customize the format of the Syslog message. Refer to
“Configuring the log action” on page 253.
• Redirect action – Causes the Brocade Virtual ADX to redirect a request to an alternate domain,
URL, or port when the specified rule is matched. Refer to “Configuring redirect” on page 264.
• Persist action – causes the Brocade Virtual ADX to send requests with similar content to the
same server when the specified rule is matched. Refer to “Configuring the persist action” on
page 251.
NOTE
If no rule is matched, traffic is directed to the internet.
NOTE
Alias ports should be treated like regular ports and should have the same server ID and group ID.
Creating a policy
To create a policy for Layer 7 content switching, enter a command such as the following.
Virtual ADX(config)#csw-policy policy1
Syntax: [no] csw-policy policy-name
The policy-name variable can be up to 80 characters in length.
Configuring the forward action
The forward action causes the Brocade Virtual ADX to forward packets matching a specified rule to
a specified real server or server group.
For example, the following command specifies that packets matching rule r1 be forwarded to real
server 1029.
Virtual ADX(config-csw-policy1)#match r1 forward 1029
Syntax: [no] match rule-name forward id [cookie-name name]
The rule-name variable is the name of a previously configured Layer 7 content switching rule.
The id variable refers to a real server or server group ID. An ID between 0 and 1023 indicates a
server group ID, and an is between 1024 and 2047 indicates a real server ID.
250
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Layer 7 content switching
5
NOTE
The real server ID range is limited to 1024-1+the maximum number of real servers that can be
configured on the Brocade Virtual ADX. For example, if the maximum server limit is 16384, then the
valid real server ID range is from 1024 to 1024-1+16384=17407.
If you specify a server group ID, you can optionally specify a cookie name. When you specify a
cookie name, the Brocade Virtual ADX performs cookie switching on packets matching the rule,
which ensures that packets matching the rule go to the same real server within the server group.
Configuring the persist action
The persist action causes the Brocade Virtual ADX to send requests with similar content to the
same server when the specified rule is matched. When a rule is matched, the Brocade Virtual ADX
uses the content that matched the rule, in combination with a specified persistence method, to
select a server or server group to which to send the packet.
When a rule is associated with the persist action, a server or server group is selected as follows.
1. An incoming packet matches a configured CSW rule. For example, a CSW rule matches if an
incoming packet contains a cookie header field with the string “ServerID” as shown in the
following.
Virtual ADX(config)#csw-rule r1 header "cookie" search "ServerId"
The persist action can then be used in conjunction with the above CSW rule.
2. The Brocade Virtual ADX examines the matched content to determine the persist string. The
persist string contains the portion after the matched string that the Brocade Virtual ADX uses,
(along with the persist method) to select a real server (or server group) to which to send the
packet.
For example, in CSW rule r1 defined above, the matched content could be something like:
“ServerID=2”
Then, you can specify that the persist string be a segment of the matched content, starting
from a specified offset from the matched string (ServerID) and lasting for a specified length. In
the example above, if you specify an offset of “1” and a length of “1”, the persist string would
be “2”.
3. The Brocade Virtual ADX uses the persist string along with the configured persist method to
select a real server or group. By default, the Brocade Virtual ADX uses a hash-to-bucket persist
method to select a real server.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
251
5
Layer 7 content switching
The hash-to--bucket persist method is illustrated in the following figure.
FIGURE 29
Hash-to-bucket persist method
For a given rule, you can configure a primary persist action and a secondary persist action. If the
primary persist action does not return a valid persist string, or if the server indicated by the primary
persist string is not available, the Brocade Virtual ADX uses the secondary persist action to direct
packets to a server.
The following commands configure a CSW rule and policy that use the persist action.
Virtual ADX(config)#csw-rule r1 header host exists
Virtual ADX(config)#csw-policy p1
Virtual ADX(config-csw-p1)#match r1 persist offset 0 length 0
In the above example, the csw-rule command creates a rule that matches if an incoming packet
contains an HTTP host header field. The csw-policy command creates a policy called p1. The match
r1 persist command associates the rule with the persist action. As a result, if an incoming packet
has an HTTP host header field, the contents of the host header field are used as the persist string.
The Brocade Virtual ADX uses the persist string along with the default hashing-bucket persist
method to calculate the real server to which to send the packet.
Syntax: [no] match rule-name persist offset offset length length [[persist-method] [secondary]]
or
Syntax: [no] match rule-name persist offset offset terminator string [[persist-method] [secondary]]
The offset variable specifies the offset in bytes from the end of the matched string, matched by the
rule-name to be used as the persist string. If you specify 0 as the offset, the persist string begins
right after the matched string.
The length variable specifies the length in bytes of the persist string. If you specify 0 as the length,
the persist string ends at the end of the matched content.
The string variable specifies the substring with which the persist string ends.
252
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Layer 7 content switching
5
The persist-method variable specifies which of the following persist methods you want to use.
• hash-to-bucket – Hashes the persist string to a hashing bucket, as illustrated in Figure 29. This
is the default.
• hash-to-group-id – Hashes the persist string to a server group ID, instead of to a hashing
bucket.
• group-or-server-id – Translates the persist string to the ID of a real server or server group.
• server-name – Translates the persist string to the name of a real server.
• alias-name – Translates the persist string to the name of an alias.
The secondary keyword indicates that this is a secondary persist action for the rule. If the primary
persist action does not return a valid persist string, or if the server indicated by the primary persist
string is not available, the Brocade Virtual ADX uses the secondary persist action to direct packets
to a server.
NOTE
By configuring both a CSW policy that utilizes the persist action and a TCP or UDP port as sticky, you
can implicitly enable persistence fallback. In this scenario, the CSW policy defines the default
method of defining persistence. However, If no cookie is detected, the Brocade Virtual ADX falls back
to the sticky persistence configured for the address.
Configuring the reply-error action
The reply-error action causes the Brocade Virtual ADX to send a 403 error code page back to the
client when the specified rule is matched.
For example, to cause the Brocade Virtual ADX to send a 403 error code page to a client that sent a
packet that matched rule r1, enter the following command.
Virtual ADX(config-csw-policy1)#match r1 reply-error
Syntax: [no] match rule-name reply-error
Configuring the log action
The CSW match log action only logs to a log server, not the local log of the Brocade Virtual ADX
displayed by the show logging command. You must configure a remote server (per the global
logging ip-addr command) to receive the log. The syslog server cannot be connected to the
management port because CSW log action is processed by the BP, and the management port is
controlled by the MP.
NOTE
The log action requires a primary action forward or persist to be configured.
An example Syslog message follows.
192.168.9.210 80 HTTP Rule matched, Forward
To cause the Brocade Virtual ADX to write a message to Syslog when rule r1 is matched, enter a
command such as the following:
Virtual ADX(config-csw-policy1)#match r1 log
Syntax: [no] match rule-name log [format]
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
253
5
Layer 7 content switching
By default, the format of the Syslog message is as follows.
source-ipaddr source-port protocol Rule matched, action-message
Additionally, you can change the format of the Syslog message using the following tokens:
•
•
•
•
•
•
•
•
$SIP – Source IP address
$DIP – Destination IP address
$SPT – Source port
$DPT – Destination port
$HST – Host name
$URL – URL
$RUL – Rule name
$ACT – Action
For example, the following command specifies an alternate format for the Syslog message:
Virtual ADX(config-csw-policy1)#match r1 log "$SIP:$SPT->$DIP:$DPT,ru $RUL hit
$ACT"
In this example, when a packet matches rule r1, a message such as the following is written to
Syslog.
192.168.9.210:80->10.10.10.10:80, ru r1 hit forward
Inserting a cookie
You can configure the Brocade Virtual ADX to insert a cookie into an HTTP response when a
specified rule is matched. When the rule is matched, a cookie is inserted in the response when any
of the following occur:
• No cookie header is found in the HTTP request, or a cookie header exists but it does not
contain the cookie name specified by the rewrite insert-cookie command.
• The specified cookie name is found in the HTTP request, but the cookie value is out of the
range used for cookie switching. The cookie value must be between 1 and 17407.
• The specified cookie name is found in the HTTP request, but the real server or server group
indicated by the cookie value is not available.
For example, the following command causes the Brocade Virtual ADX to insert the cookie indicated
by the rewrite insert-cookie command into the HTTP response when rule r1 is matched.
Virtual ADX(config-csw-policy1)#match r1 rewrite insert-cookie
Syntax: [no] match rule-name rewrite insert-cookie
Deleting a cookie
Cookie deletion causes the Brocade Virtual ADX to delete the cookies that it set. The Brocade
Virtual ADX removes the cookie from the HTTP request prior to sending the request to the server.
For example, the following command causes the Brocade Virtual ADX to delete the cookie indicated
by the rewrite insert-cookie command from the HTTP response when rule r1 is matched.
Virtual ADX(config-csw-policy1)#match r1 rewrite delete-cookie
Syntax: [no] match rule-name rewrite delete-cookie
254
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Layer 7 content switching
5
Damaging a cookie
Cookie damage consists of altering the cookie header so that it does not contain any cookie that
matches the name of the cookie inserted by the Brocade Virtual ADX.
For example, the following command causes the Brocade Virtual ADX to damage the cookie
indicated by the rewrite insert-cookie command in the HTTP response when rule r1 is matched.
Virtual ADX(config-csw-policy1)#match r1 rewrite destroy-cookie
Syntax: [no] match rule-name rewrite destroy-cookie
Inserting an HTTP header
HTTP header insertion causes the Brocade Virtual ADX to insert a header into the HTTP requests
that it receives on a virtual server or into the HTTP responses that it sends out from a virtual server.
The header is specified within the CSW match command using the request-insert parameter (for
HTTP requests) or the response-insert parameter (for HTTP responses).
To cause the Brocade Virtual ADX to insert a standard HTTP “Via:” header into HTTP requests
matching rule r1, enter the following command.
Virtual ADX(config-csw-p1)#match r1 rewrite request-insert header "Via: Brocade
Virtual ADX"
To cause the Brocade Virtual ADX to insert the header "Brocade Virtual ADX: proto=HTTP+MMS"
into the HTTP responses (matching rule r1) that it sends from the virtual server, enter the following
command.
Virtual ADX(config-csw-policy1)#match r1 rewrite response-insert header "Brocade
Virtual ADX: proto=HTTP+MMS"
Syntax: [no] match rule-name rewrite response-insert header header
The header variable specifies the string that will be inserted.
Inserting an IP address in a header
HTTP Header insertion can direct the Brocade Virtual ADX to insert the Client IP address into the
HTTP requests it receives on a virtual server that matches a CSW rule you define.
This feature can be useful in situations where Source Network Address Translation (source NAT) is
enabled on a Brocade Virtual 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. Servers are then able to identify clients by their original source IP addresses.
To cause the Brocade Virtual ADX to insert the IP address of the connecting client into HTTP
requests matching rule r1, enter the following command.
Virtual ADX(config-csw-policy1)#match r1 rewrite request-insert client-ip
"MyClientIP"
Syntax: [no] match rule-name rewrite request-insert client-ip header
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
255
5
Layer 7 content switching
Configuring Rewrite request-delete
HTTP URL Rewrite allows the Brocade Virtual ADX to delete a string or portion of a string from inside
the incoming client request, as described in the following sections:
•
•
•
•
“Deleting a matched-string” on page 256
“Deleting content at positive offset” on page 257
“Deleting content at negative offset” on page 258
“Deleting a string” on page 259
Deleting a matched-string
To configure a request to delete a matched string in a CSW rule, follow these steps.
1. Define a CSW rule to search for a sub-string in a URL.
Virtual ADX(config)#csw-rule r11 url pattern "-sample"
Syntax: csw-rule rule-name url pattern url-content
2. Define a CSW policy.
Virtual ADX(config)#csw-policy mypolicy
Syntax: csw-policy policy-name
3. Specify a primary action to forward a request to a server with an ID of 1025 when rule r11 is
matched.
Virtual ADX(config-csw-mypolicy)#match r11 forward 1025
Syntax: match rule-name forward server-id
4. Specify a dependent action to delete the sub-string -sample when it is found in the URL.
Virtual ADX(config-csw-mypolicy)#match r11 rewrite request-delete
matched-string
Syntax: match rule-name rewrite request-delete matched-string
5. Specify a dependent log action.
Virtual ADX(config-csw-mypolicy)#match r11 log
Syntax: match rule-name log
6. Specify a default action.
Virtual ADX(config-csw-mypolicy)#default forward 1026
Syntax: default forward server-id
NOTE
The following information assumes you have already completed the previous configuration.
If the Brocade Virtual ADX were to receive a request for URL /abc/xyz-sample/index.html, it would
take the following actions:
• Delete sub-string "-sample" in the URL, which becomes /abc/xyz/index.html.
• Forward the request to Web Server 1.
• Log primary Forward action to the log server.
256
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Layer 7 content switching
5
In this case, "-sample" is the deleted string that CSW rule r11 matches. The request is forwarded to
the server with server ID 1025, which is defined by primary CSW action match r11 forward 1025.
The URLs in the following two HTTP request messages show the difference between the original
request and the rewritten request.
If there is no sub-string "-sample" in the URL of the HTTP request, rule r11 is not hit, the request is
sent to the server with server ID of 1026, which is defined by the default rule default forward 1026.
Example Original HTTP request:
GET /abc/xyz-sample/index.html HTTP/1.1\r\n
Host: www.example5.com\r\n
User-Agent: Mozilla/5.0 Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=brocadenet; userid=12345\r\n
\r\n
Example Rewritten HTTP request:
GET /abc/xyz/index.html HTTP/1.1\r\n
Host: www.example5.com\r\n
User-Agent: Mozilla/5.0 Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=brocadenet; userid=12345\r\n
\r\n
Deleting content at positive offset
NOTE
For more information about offsets, refer to “Explanation of offsets” on page 265.
To configure a request to delete content at a positive offset, follow these steps.
1. Define a CSW rule to search for a prefix "/abc" in URL.
Virtual ADX(config)#csw-rule r12a url prefix "/abc"
Syntax: csw-rule rule-name url prefix prefix-content
2. Define a CSW policy.
Virtual ADX(config)#csw-policy mypolicy
Syntax: csw-policy policy-name
3. Specify a primary action.
Virtual ADX(config-csw-mypolicy)#match r12a forward 1025
Syntax: match rule-name forward server-id
4. Specify a dependent rewrite action.
Virtual ADX(config-csw-mypolicy)#match r12a rewrite request-delete offset 4 2
Syntax: match rule-name rewrite request-delete offset offset length
NOTE
The following information assumes you have already completed the previous configuration.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
257
5
Layer 7 content switching
The URL prefix "/abc" is matched, offset 0 is at the second "/", which is right after the matched
prefix "/abc" in the URL, which is defined in CSW "r12a"; so offset 4 is number "1" which is 4 bytes
away after the letter "c". The result is that the 2 bytes containing "12" are deleted in the URL.
Example Original HTTP request:
GET /abc/xyz12/index.html HTTP/1.1\r\n
Host: www.foo.com\r\n
User-Agent: Mozilla/5.0 Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=brocadenet; userid=12345\r\n
\r\n
Example Rewritten HTTP request:
GET /abc/xyz/index.html HTTP/1.1\r\n
Host: www.foo.com\r\n
User-Agent: Mozilla/5.0 Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=brocadenet; userid=12345\r\n
\r\n
Deleting content at negative offset
NOTE
For more information about offsets, refer to “Explanation of offsets” on page 265.
To configure a request to delete content at a negative offset, follow these steps.
1. Define a CSW rule to search for the suffix ".html" at end of URL.
Virtual ADX(config)#csw-rule r12b url suffix ".html"
Syntax: csw-rule rule-name url suffix content
2.
Define a CSW policy.
Virtual ADX(config)#csw-policy mypolicy
Syntax: csw-policy policy-name
3. Specify a primary action.
Virtual ADX(config-csw-mypolicy)#match r12b forward 1025
Syntax: match rule-name forward server-id
4. Specify a dependent rewrite action.
Virtual ADX(config-csw-mypolicy)#match r12b rewrite request-delete neg-offset
11 6
Syntax: match rule-name rewrite request-delete neg-offset offset length
NOTE
The following information assumes you have configured the previous scenario.
When ".html" is matched, offset 0 is the white space after letter "l", letter "l" is neg-offset 1, letter
"m" is neg-offset 2, letter "t" is neg-offset 3 and so on. As a result, neg-offset 11 is "_". By counting
6 bytes from left to right starting with "_", you can see that "_index" is to be deleted.
258
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Layer 7 content switching
5
Example Original HTTP request:
GET /abc/xyz/default_index.html HTTP/1.1\r\n
Host: www.example5.com\r\n
User-Agent: Mozilla/5.0 Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=brocadenet; userid=12345\r\n
\r\n
Example Rewritten HTTP request:
GET /abc/xyz/default.html HTTP/1.1\r\n
Host: www.example5.com\r\n
User-Agent: Mozilla/5.0 Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=brocadenet; userid=12345\r\n
\r\n
Deleting a string
NOTE
For more information about offsets, refer to “Explanation of offsets” on page 265.
To configure a request to delete a sub-string in a CSW rule, follow these steps.
1. Define a CSW rule.
Virtual ADX(config)#csw-rule r13 url exists
Syntax: csw-rule rule-name url exists
2. Define a CSW policy.
Virtual ADX(config)#csw-policy mypolicy
Syntax: csw-policy policy-name
3. Specify a primary action.
Virtual ADX(config-csw-mypolicy)#match r13 forward 1025
Syntax: match rule-name forward server-id
4. Specify a dependent rewrite action.
Virtual ADX(config-csw-mypolicy)#match r13 rewrite request-delete string "123"
Syntax: match rule-name rewrite request-delete string string-content
NOTE
The following information assumes you have already completed the previous configuration.
The url-exist matches any URL. If found, only string "123" is deleted; if no instance of "123" is found
in the URL, the original URL is sent to the server.
Example Original HTTP request:
GET /abc/xyz123/index.html HTTP/1.1\r\n
Host: www.example5.com\r\n
User-Agent: Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=brocadenet; userid=12345\r\n
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
259
5
Layer 7 content switching
\r\n
Example Rewritten HTTP request:
GET /abc/xyz/index.html HTTP/1.1\r\n
Host: www.example5.com\r\n
User-Agent: Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=brocadenet; userid=12345\r\n
\r\n
Configuring Rewrite request-insert
Content insertion allows the Brocade Virtual ADX to insert any string either right after the matched
string found by the CSW rule, or at any specified offset in the content located by the matched CSW
rule. Use the following procedures to configure a string insert at a positive offset or a negative
offset.
NOTE
For more information about offsets, refer to “Explanation of offsets” on page 265.
Inserting a string at positive offset
To configure a request to insert a string after a CSW rule match, follow these steps.
1. Define a CSW rule for the HTTP prefix of the URL.
Virtual ADX(config)#csw-rule r21 url prefix "/abc"
Syntax: csw-rule rule-name url prefix prefix-content
2. Define a CSW policy.
Virtual ADX(config)#csw-policy mypolicy
Syntax: csw-policy policy-name
3.
Specify a primary action.
Virtual ADX(config-csw-mypolicy)#match r21 forward 1025
Syntax: match rule-name forward server-id
4. Specify a dependent rewrite string.
Virtual ADX(config-csw-mypolicy)#match r21 rewrite request-insert /hello-world
Syntax: match rule-name rewrite request-insert content offset
NOTE
The following information assumes you have already completed the previous configuration.
NOTE
If no offset is defined, the Brocade Virtual ADX will always insert at offset 0.
Offset 0 is at the second "/", which is right after matched prefix "/abc", as defined in CSW "r21".
The result is that the string "/hello-world" is inserted at the default offset 0, which is after letter "c".
The original URL becomes "/abc/hello-world/xyz/index.html".
260
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Layer 7 content switching
5
The highlighted URLs in the following two HTTP request messages show the difference between the
original request and the one after being rewritten.
Example Original HTTP request:
GET /abc/xyz/index.html HTTP/1.1\r\n
Host: www.example5.com\r\n
User-Agent: Mozilla/5.0 Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=brocadenet; userid=12345\r\n
\r\n
Example Rewritten HTTP request:
GET /abc/hello-world/xyz/index.html HTTP/1.1\r\n
Host: www.example5.com\r\n
User-Agent: Mozilla/5.0 Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=brocadenet; userid=12345\r\n
\r\n
Inserting a string at negative offset
To configure a request to insert a string after a CSW rule match, follow these steps.
1.
Define a CSW rule for HTTP URL content.
Virtual ADX(config)#csw-rule r22 url prefix /abc/
Syntax: csw-rule rule-name url prefix prefix-content
2. Define a CSW policy.
Virtual ADX(config)#csw-policy mypolicy
Syntax: csw-policy policy-name
3.
Specify a primary action.
Virtual ADX(config-csw-mypolicy)#match r22 forward 1025
Syntax: match rule-name forward server-id
4.
Specify a dependent rewrite action.
Virtual ADX(config-csw-mypolicy)#match r22 rewrite request-insert /hello-world
neg-offset 5
Syntax: match rule-name rewrite request-insert content neg-offset offset
NOTE
The following information assumes you have already completed the previous configuration.
NOTE
If you want to insert a string at the beginning of a URL, make sure that the string always starts with
a "/", or the server that receives the request returns a response of "bad request." This response
indicates the format is invalid. The assumption is that the URL always starts with a "/".
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
261
5
Layer 7 content switching
The highlighted URLs in the following two HTTP request messages show the difference between the
original request and the rewritten request. Offset 0 is at the first "x," which is right after the
matched prefix "/ abc/," as defined in CSW "r22". Therefore, negative offset 5 is at the first "/,"
which is 5 bytes away from and before the "x." The result is that string "/hello-world" is inserted at
the first "/", which is the beginning of URL "/abc/xyz/index.html". The original URL becomes
"/hello-world/abc/xyz/index.html".
Example Original HTTP request:
GET /abc/xyz/index.html HTTP/1.1\r\n
Host: www.example5.com\r\n
User-Agent: Mozilla/5.0 Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=brocadenet; userid=12345\r\n
\r\n
Example Rewritten HTTP request:
GET /hello-world/abc/xyz/index.html HTTP/1.1\r\n
Host: www.example5.com\r\n
User-Agent: Mozilla/5.0 Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=brocadenet; userid=12345\r\n
\r\n
NOTE
When inserting a string in an HTTP request, make sure the negative offset is correctly specified.
Incorrectly specifying the negative offset (out of range) may result in an improper HTTP request.
Configuring Rewrite request-replace
Content replacement allows you to replace a defined string, or a string that matches a CSW rule.
The following procedures explain both methods.
Replacing a string defined by content rule
To configure a request to replace a string that matches a CSW rule, follow these steps.
1. Define a CSW rule for HTTP URL content.
Virtual ADX(config)#csw-rule r31 url exist
Syntax: csw-rule rule-name url exist
2.
Define a CSW policy
Virtual ADX(config)#csw-policy mypolicy
Syntax: csw-policy policy-name
3. Specify a primary action.
Virtual ADX(config-csw-mypolicy)#match r31 forward 1025
Syntax: match rule-name forward server-id
4.
Specify a dependent rewrite action.
Virtual ADX(config-csw-mypolicy)#match r31 rewrite request-replace
matched-string "/newabc/newxyz/newindex.html"
262
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Layer 7 content switching
5
Syntax: match rule-name rewrite request-replace matched-string new-string
The rule-name variable defines the name of CSW rule.
The matched-string keyword defines the matched string (defined by CSW rule), which is to be
replaced.
The new-string variable defines the new string that replaces the previous string.
NOTE
The following information assumes you have already completed the previous configuration.
The url-exist matches the entire URL, so the matched string is the whole URL
"/abc/xyz/index.html." It is replaced by the new string "/newabc/newxyz/newindex.html."
Example Original HTTP request:
GET /abc/xyz/index.html HTTP/1.1\r\n
Host: www.example5.com\r\n
User-Agent: Mozilla/5.0 Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=brocadenet; userid=12345\r\n
\r\n
Example Rewritten HTTP request:
GET /newabc/newxyz/newindex.html HTTP/1.1\r\n
Host: www.example5.com\r\n
User-Agent: Mozilla/5.0 Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=brocadenet; userid=12345\r\n
\r\n
Replace a defined string
To configure a request to replace a specific string in a CSW rule match, follow these steps.
1. Define a CSW rule for HTTP URL content.
Virtual ADX(config)#csw-rule r32 url pattern "abc"
Syntax: csw-rule rule-name url pattern pattern-content
2. Define a CSW policy
Virtual ADX(config)#csw-policy mypolicy
Syntax: csw-policy policy-name
3.
Specify a primary action.
Virtual ADX(config-csw-mypolicy)#match r32 forward 1025
Syntax: match rule-name forward server-id
4.
Specify a dependent rewrite action
Virtual ADX(config-csw-mypolicy)#match r32 rewrite request-replace string
"xyz" "1234"
Syntax: match rule-name rewrite request-replace string old-string new-string
The rule-name variable defines the name of the CSW rule.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
263
5
Layer 7 content switching
The old-string variable defines the string to be replaced, if it can be found in the URL defined by
the CSW rule. If the old-string variable is not found, the replacement will not happen.
The new-string variable defines the string with which the old string is to be replaced.
NOTE
The following information assumes you have already completed the previous configuration.
Because the URL contains the pattern "abc," rule r32 will be hit. Then a search for string "xyz" also
is positive, so "xyz" will be replaced with string "1234". The following two HTTP request messages
show the difference between the original request and the rewritten request.
Example Original HTTP request:
GET /abc/xyz/index.html HTTP/1.1\r\n
Host: www.example5.com\r\n
User-Agent: Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=brocadenet; userid=12345\r\n
\r\n
Example Rewritten HTTP request:
GET /abc/1234/index.html HTTP/1.1\r\n
Host: www.example5.com\r\n
User-Agent: Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=brocadenet; userid=12345\r\n
\r\n
Configuring redirect
The redirect action causes the Brocade Virtual ADX to redirect a request to an alternate domain,
URL, port, or Uniform Resource Identifier (URI) when the specified rule is matched.
For example, the following command causes the Brocade Virtual ADX to redirect a request to the
domain brocade.com, URL
/home/index.html, and port 8080 when rule r1 is matched.
Virtual ADX(config-csw-policy1)#match r1 redirect "brocade.com"
"/home/index.html" 8080
Syntax: [no] match rule-name redirect domain [url | [port status-code] | [url new-port]]
The rule-name variable can be up to 80 characters in length.
The domain variable can be up to 255 characters.
The url variable can be up to 255 characters.
You can optionally specify * (asterisk) for either the domain or url variables. When you do this, the
redirected request uses the same domain or URL as in the original request.
For the port variable, you can enter any well-known port name or port number. For the status-code
variable, enter any three-digit status code.
For the url new-port variables, enter the new URL and port number to which the request will be
redirected.
264
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Layer 7 content switching
5
HTTP redirect status code
The Brocade Virtual ADX can be configured to use a temporary or permanent move to suit different
application requirements:
• 301 - To redirect the HTTP request to a new, assigned permanent URI.
• 302 (the default) -To redirect HTTP requests to a temporary URI.
To redirect an HTTP request with redirect code 301, enter the following command.
Virtual ADX(config)#csw-policy p1
Virtual ADX(config-csw-p1)#match r1 redirect "brocade.com" HTTP 301
Explanation of offsets
NOTE
The offset or neg-offset keyword indicates that insertion or deletion starts after or before the offset
of the interested content defined in the matched CSW rule.
In this example, the Brocade Virtual ADX receives the following message.
GET /abc/xyz/index.html HTTP/1.1\r\n
Host:www.example5.com\r\n
User-Agent: Mozilla/5.0 Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=brocadenet; userid=12345\r\n
\r\n
The following examples show how the offsets work for various rules.
Prefix matching
csw-rule ruleA url prefix /abc/x
Offset 0 points to "y", which is the next byte after "/abc/x" in the URL.
Suffix matching
csw-rule ruleB header Host suffix com
Offset 0 points to "\r", which is the next byte after "com" in the value of "Host" header
"www.example5.com".
Pattern matching
csw-rule ruleC header Host pattern foo.
Offset 0 points to "c", which is the next byte after "foo." in the value of "Host" header
“www.example5.com”.
Exist matching
csw-rule ruleD1 url exist
Offset 0 points to white space after the letter "l", which is right after the last byte of URL
"/abc/xyz/index.html".
Equal matching
csw-rule rule header "Host" equal "www.example5.com"
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
265
5
Sample configurations
Offset 0 points to "\r", which is the next byte after "www.example5.com" in the value of "Host"
header, "www.foo.com".
Sample configurations
The HTTP URL Rewrite feature allows the Brocade Virtual ADX to dynamically rewrite URL content in
an HTTP request. Also, the HTTP URL Rewrite options allow you to insert, delete, and replace URL
content at any offset in an HTTP request.
Seamlessly integrated with Brocade Virtual ADX content switching (CSW), the HTTP URL Rewrite
can be configured as a dependent action for primary CSW actions. However, only Forwards and
Persists are typically used for HTTP URL Rewrite actions on HTTP requests, because the other
actions do not pass requests to servers.
Before you configure an HTTP URL Rewrite, you should be aware of the following benefits and
restrictions for this feature:
•
•
•
•
•
•
•
You can configure HTTP URL Rewrite and CSW on HTTP, SSL, or any unknown port.
HTTP URL Rewrite supports HTTP 1.1 Keepalive and TCP Offload.
HTTP URL Rewrite is an extension of CSW.
You define HTTP URL Rewrite actions under a CSW policy.
Before you define an HTTP URL Rewrite action, you must define a primary CSW action.
For each matched CSW rule, you can only define one primary action.
An HTTP URL Rewrite action works only with a primary action that passes client requests to the
servers, such as Forward or Persist actions.
• You can define multiple dependent CSW actions that work together with a primary CSW action.
• Dependent CSW actions include HTTP URL Rewrite, log, client-ip insertion, header insertion,
cookie insertion, and deletion.
• HTTP URL Rewrite supports nested CSW rules.
• To enable HTTP URL Rewrite under a VIP, you must enable CSW.
• HTTP URL Rewrite cannot be configured as a default action.
266
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Sample configurations
5
CSW topology
Figure 30 shows a simple CSW network topology.
FIGURE 30
CSW network topology
For the CSW configuration shown in Figure 30, the following rules apply:
• The Brocade Virtual ADX receives incoming traffic on HTTP port, VIP 10.1.1.100.
• The Brocade Virtual ADX is configured with content switching (CSW) rules and policies. Policy 1
is defined to rewrite URL content and forward the request to the Web server 1.
• If a CSW rule is matched, the Brocade Virtual ADX rewrites the HTTP request and forwards it to
Web Server 1 with server ID 1025 and IP address 10.1.1.1.
• If no CSW rule is matched, the Brocade Virtual ADX takes the default action, sending the HTTP
request to Web Server 2 with server ID 1026 and IP address 10.1.1.2.
Request delete configuration
The following sections describe a full configuration process for an HTTP URL Rewrite, and a
configuration process for HTTP URL Rewrite actions.
Request delete configuration example
This section describes how to perform a complete configuration HTTP URL Rewrite, using the
content delete option. This scenario uses all of the required steps to configure HTTP URL Rewrite,
and identifies the steps that are optional.
The configuration process contains the following segments:
•
•
•
•
“Creating a policy with HTTP URL Rewrite” on page 268
“Configuring real and virtual servers” on page 269
“Enabling content switching” on page 270
“HTTP URL Rewrite configuration summary” on page 270
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
267
5
Sample configurations
Creating a policy with HTTP URL Rewrite
To define a CSW rule and create a CSW policy with HTTP URL Rewrite options, follow these steps.
1. Define a CSW rule to match a URL pattern in an HTTP header.
Virtual ADX(config)#csw-rule r11 url pattern /xyz
Syntax: csw-rule rule-name url pattern url-content
2. Define a CSW rule to match a prefix string in an HTTP header.
NOTE
Only one rule is required for configuring HTTP URL Rewrite.
Virtual ADX(config)#csw-rule r12a header Accept-Charset prefix ISO-
Syntax: csw-rule rule-name header header-content prefix prefix-content
3. Define a CSW policy.
Virtual ADX(config)#csw-policy mypolicy
Syntax: csw-policy policy-name
4. Specify a primary action to forward a request to a server ID when a rule is matched.
Virtual ADX(config-csw-mypolicy)#match r11 forward 1025
Syntax: match rule-name forward server id
5. Specify a dependent action and delete the matched string when a rule is matched.
Virtual ADX(config-csw-mypolicy)#match r11 rewrite request-delete
matched-string
Syntax: match rule-name rewrite request-delete matched-string
NOTE
The rewrite request-delete matched-string option is an HTTP URL Rewrite action. For more
detailed command information, refer to “rewrite request-delete” on page 302.
6. Enable logging for this rule.
Virtual ADX(config-csw-mypolicy)#match r11 log
Syntax: match rule-name log
7.
Specify a primary action to forward a request to a server ID when a rule is matched.
Virtual ADX(config-csw-mypolicy)#match r12a forward 1025
Syntax: match rule-name forward server id
8. Specify a dependent action and delete at an offset when a rule is matched.
Virtual ADX(config-csw-mypolicy)#match r12a rewrite request-delete offset 4 2
Syntax: match rule-name rewrite request-delete offset offset length
NOTE
The rewrite request-delete offset option is a HTTP URL Rewrite action.
268
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Sample configurations
5
NOTE
For more information about offsets, refer to “Explanation of offsets” on page 265.
9. Specify default action for client requests that do not match any other rules. Send such
requests to the Web server with ID 1026.
Virtual ADX(config-csw-mypolicy)#default forward 1026
Syntax: default forward server-id
Configuring real and virtual servers
To configure the real and virtual servers, follow these steps.
1.
Define a real server (1) with an IP address.
Virtual ADX(config)#server real web1 10.1.1.1
Syntax: server real real-server ip-address
2. Define a real HTTP port on the real server.
Virtual ADX(config-rs-web1)#port http
Syntax: port http
3. Define a real server (2) with an IP address.
Virtual ADX(config-rs-web1)#server real web2 10.1.1.2
Syntax: server real real-server ip-address
4. Define a real HTTP port on the real server and exit.
Virtual ADX(config-rs-web2)#port http
Virtual ADX(config-rs-web2)#exit
Syntax: port http
Syntax: exit
5. Define a virtual server with an IP address.
Virtual ADX(config)#server virtual-name-or-ip csw-vip 10.1.1.100
Syntax: server virtual-name-or-ip vip-name ip-address
6. Define a virtual HTTP port on the virtual server.
Virtual ADX(config-vs-csw-vip)#port http
Syntax: port http
7.
Bind HTTP ports on real servers web1 and web2 to the virtual port HTTP.
Virtual ADX(config-vs-csw-vip)#bind http web1 http web2 http
Syntax: bind http real-server http vip-name
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
269
5
Sample configurations
Enabling content switching
To enable content switching, follow these steps.
1. Bind the policy to virtual HTTP port on virtual server.
Virtual ADX(config-vs-csw-vip)#port http csw-policy mypolicy
Syntax: port http csw-policy policy-name
2. Enable CSW on the virtual port.
Virtual ADX(config-vs-csw-vip)#port http csw
Syntax: port http csw
HTTP URL Rewrite configuration summary
The following example shows a summary of the configuration steps.
#csw-rule r11 url pattern /xyz
#csw-rule r12a header Accept-Charset prefix ISO#csw-policy mypolicy
#match r11 forward 1025
#match r11 rewrite request-delete matched-string
#match r11 log
#match r12a forward 1025
#match r12a rewrite request-delete offset 4 2
#default forward 1026
#server real web1 10.1.1.1
#port http
#server real web2 10.1.1.2
#port http
#server virtual-name-or-ip csw-vip 10.1.1.100
#port http
#port http csw-policy mypolicy
#port http csw
#bind http web1 http web2 http
270
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Layer 7 content switching on HTTP response
5
Layer 7 content switching on HTTP response
The Brocade Virtual ADX can perform content rewrite on the server responses. In other words, the
Brocade Virtual ADX can not only modify requests in the forward direction, but also the responses
in reverse direction. The HTTP response is divided into the "header" part and the "body" part. The
Brocade Virtual ADX can selectively rewrite the header, body, or both.
Response header rewrite
The response header rewrite feature is typically required in an SSL-Offload environment when the
real servers send redirect messages to the incoming clients. Figure 31 shows such a scenario
when the Real-Server is not aware of the SSL-Offload but sends a redirect using HTTP. The Brocade
Virtual ADX does not change the response and sends it to the client. The Client, as a result, sends
another request using HTTP, and as a result, suddenly moves from a secure HTTPS to HTTP.
FIGURE 31
HTTP response header rewrite
A Brocade Virtual ADX can be programmed to modify such responses and replace "http://" with
"https://". This feature can be applied selectively based on the response code and the embedded
URL. For example, the Brocade Virtual ADX can be programmed to replace only response codes
301 and 302, and only for URLs matching "http://www.example6.com".
In general, this feature is used for modifying the redirect URLs in response codes 301 and 302.
However, it is not limited to modifying redirects and in theory can be configured to modify any other
part of the HTTP-header in any other response code.
Configuring HTTP header response rewrite
To enable response header-rewrite, follow these steps.
1. Create a CSW rule specifying the request rule or response codes to be acted upon.
2. Create a CSW rule specifying the string to be modified.
3. Create a CSW policy.
4. Bind the CSW policy to the virtual server port.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
271
5
Layer 7 content switching on HTTP response
Creating a CSW rule specifying the header response codes
In this step, the header response codes are specified, and a response is inspected only if those
codes are found. For example, to specify the redirect response code, the following configuration is
required.
Virtual ADX(config)#csw-rule r2 response-status-code 200 400
Syntax: [no] csw-rule rule-name response-status-code low_bound high_bound
Creating a CSW rule specifying the string to be modified
In this step, a CSW-Rule is configured that specifies the string to be matched in a given header. For
example, to match the string the redirect messages typically have response codes of 301 or 302,
and the new URL is specified in the header "Location."
For example, to match the redirect location "http://www.example6.com," the following rule is
required.
Virtual ADX(config)#csw-rule r11 response-header "Location" pattern
"http://www.example6.com"
Syntax: [no] csw-rule rule-name response-header header_name pattern pattern_to_be_found
Creating a CSW policy
When the rules have been defined, they need to be added to a CSW policy. The policy type
response-rewrite must be used so as to distinguish the response-rewrite policy from the original
CSW policies, like request-rewrite.
The two rules configured in step 1 and step-2 are added to this policy. The first rule ensures that
the policy acts only on responses with response codes 301 or 302. The second rule matches the
string "http://www.example6.com" and replaces it with "https://www.example6.com." The offset
and length defines the portion of the original match that has to be replaced. The example below
shows the rewriting of the entire string. Alternatively, only the first four characters can also be
modified, in which case the offset would be 0, with length 4, and the new string would be "https."
Virtual ADX(config)#csw-policy "p1" type response-rewrite
Virtual ADX(config-rew-p1)#match "r1" rewrite response-insert header
Virtual ADXconfig-rew-p1)#match "r11" rewrite request-replace string
"https://www.example6.com/" offset 0 length 19
Syntax: [no] csw-policy policy-name type response-rewrite
Binding a CSW policy to the virtual server port
The final step is to apply the CSW policy to the incoming traffic by binding it to a virtual port. This
type of policy is usually applied on port HTTP.
Virtual ADX(config)#server virtual-name-or-ip v1 10.1.1.10
Virtual ADX(config-vs-v1)#port http response-rewrite-policy "p22"
Syntax: port port-type response-rewrite-policy policy-name
272
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Using multiple cookies under virtual server port
5
In this configuration, the Brocade Virtual ADX rewrites the HTTP response. Whenever response
code 301 or 302 appears in the header, together with a redirect URL http://www.example6.com
(signified by the Location header), the Brocade Virtual ADX replaces the URL with
https://www.example6.com. In other words, "Location: http://www.example6.com" becomes
"Location: https://www.example6.com."
csw-rule r1 response-status-code 301 302
csw-rule r11 response-header "Location" pattern "http://www.example6.com"
csw-policy "p1" type response-rewrite
match "r1" rewrite response-insert header
match "r11" rewrite request-replace string "https://www.example6.com/" offset 0
length 19
server real rs1 10.1.1.101
port http
port http url "HEAD /"
Using multiple cookies under virtual server port
Configuring multiple unique cookie insertion with
cookie path
This release adds support for multiple cookies. Based on a URL or any content information
contained in a HTTP request, this feature allows Brocade Virtual ADX to introduce to the client user
agent a unique cookie with different attributes, such as domain, path, and expiration time.
In previous releases, cookie insertion was configured under a VIP. With more customers having
multiple sites hosted per VIP, a single cookie to accommodate all the sites is not sufficient. This
feature extends the current implementation of cookie insertion on Brocade Virtual ADX, so that
multiple cookies for different sites and applications can be inserted.
NOTE
The following commands is configured under a CSW policy.
Configuring cookie insertion when a particular CSW rule is hit
To configure cookie insertion when a particular CSW rule is hit, use the following command.
Syntax: match rule-name rewrite insert-cookie [cookie-name [domain [path [age]]]]
If the server l7-dont-use-gateway-mac command is configured along with a CSW rule for cookie
insertion, the embedded link in a web page on the real server (which could be an image) will not
appear.
The reason is because the fetch request for the image is second request and it has a cookie
embedded. This request does not need insert cookie, so it will go through a normal Layer 7
forwarding path. This will need spoofing to be configured in order to forward the packet.
The first request does not have cookie. So it will go through cookie insertion (content rewrite) code
path. This one can take care of server l7-dont-use-gateway-mac command and does not need
spoofing configured. But for server l7-dont-use- gateway-mac command to work, spoofing is
required.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
273
5
Using multiple cookies under virtual server port
NOTE
Spoofing can be configured with the port port number spoofing command under the virtual server
configuration.
This can also be achieved by configuring l3-default-gateway.
Configuring cookie insertion in default mode (when no CSW rule is hit)
To configure cookie insertion in default mode (when no CSW rule is hit), use the following
command.
Syntax: default rewrite insert-cookie [cookie-name [domain [path [age]]]]
The cookie-name variable specifies the name of the cookie to be inserted.
The domain variable specifies the attribute domain for the cookie to be inserted. If the domain
variable is not configured or it is configured to be "*," the default domain for the cookie inserted in
the HTTP response will be the same as the one in the previous request.
The path variable specifies the attribute path for the cookie to be inserted. If the path variable is
not configured or it is configured to be "*," then "/" is defined for the cookie path.
The age variable specifies how many minutes the browser takes to expire the cookie to be inserted.
If the age variable is not configured, the cookie will expire when the browser is closed. If the age
variable is configured to be 0, the browser will age out the cookie immediately.
NOTE
The cookie-name variable is required, while the path, domain, and age variables are optional.
Specifications
CLI commands on Brocade Virtual ADX have a limitation on the total length of each command,
When a command includes many keywords or values, the attributes of path or domain can be too
long.
The following are the internal system limitations for some attributes introduced by this command:
•
•
•
•
cookie-name: Maximum length is 80 bytes.
path: Maximum length is 255 bytes.
domain: Maximum length is 80 bytes.
age:Integer between 0 and 0x1FFFFFFF.
Configuration guidelines
Cookie insertion is typically configured together with cookie switching. If a specific cookie with valid
value is found and the associated action can be taken, the Brocade Virtual ADX will take action
based on the cookie value; otherwise, it follows other matched rules, in which possibly a cookie
insertion is triggered.
The following are the steps to configure the cookie insertion with cookie switching:
• Configure CSW rules and policy
• Bind the CSW policy to a VIP
• Enable CSW on the VIP
274
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Server passive cookie persistence
5
Example
The Brocade Virtual ADX does cookie switching based on the cookie value of "ServerID" or "biz"
defined in either rule1 or rule2.
If both rule1 and rule2 are not hit but rule3 is hit, it will forward the request to server group 10 and
insert a cookie with name "biz", with path being "business".
If no rule is hit, the Brocade Virtual ADX will take the default action. It will forward the request to
server group 1 and insert a cookie with name "ServerID", which expires in 60 minutes.
csw-rule rule1 header "Cookie" search "ServerID="
csw-rule rule2 header "Cookie" search "biz="
csw-rule rule3 url prefix "/business"
csw-policy policy1
match rule1 persist offset 0 length 0 group-or-server-id
match rule2 persist offset 0 length 0 group-or-server-id
match rule3 forward 10
match rule3 rewrite insert-cookie "biz" "*" "/business"
default forward 1
default rewrite insert-cookie "ServerID" "*" "*" age 60
server virtual-name-or-ip test 10.2.2.222
port default disable
port http
port http csw-policy "policy1"
port http csw
port http keep-alive
bind http rs1 http
server real rs1 10.1.1.1
port http
port http url "HEAD /"
port http server-id 1100
port http group-id 1 1
port 8080
port 8080 server-id 1208
port 8080 group-id 10 10
server virtual-name-or-ip test 10.2.2.2
port default disable
port http
port http csw-policy "policy1"
port http csw
port http keep-alive
bind http rs1 http rs1 8080
NOTE
Make sure that the system time is configured when you configure cookie age.
Server passive cookie persistence
This feature provides connection persistence for flows where a cookie is dynamically injected by the
backend application server. With this feature enabled, the Brocade Virtual ADX monitors the server
reply and looks for a cookie with a specified name. The Brocade Virtual ADX then builds a hash
value based on the content of the cookie. This hash value is then stored in a sticky session
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
275
5
Server passive cookie persistence
together with the real server that is responsible for the cookie. Client requests are then monitored
for the cookie value associated with the server and a hash value is generated. Where this hash
value is equal to the value stored in the sticky session with the real server, client requests are sent
to that real server.
For example in Figure 32, a client sends an initial request to the HTTP port at VIP address:
“10.10.10.1”. The real server at IP address “172.16.0.5”, sends a reply to the client containing a
cookie named “JSESSIONID” with a value of “0123456789abcdefg012345643352256”. The
Brocade Virtual ADX makes a hash value from “0123456789abcdefg012345643352256” and
creates a session table entry. All subsequent requests from the client that contain the
“JSESSIONID” cookie with the value generated by the real server in its reply are assigned to that
real server.
FIGURE 32
Server passive cookie example
Configuring server passive cookie persistence
The server passive cookie persistence feature is implemented by configuring CSW rules and
policies as described in the following:
• “Creating a CSW rule to match the server response”
• “Creating a CSW rule to match the client request”
276
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Server passive cookie persistence
5
• “Creating a CSW rule to match the client request”
• “Specifying a CSW action to create persistence information”
• “Specifying a CSW action to perform persistence lookup and retrieve real server information”
Creating a CSW rule to match the server response
To create a CSW rule to match the server response, use the following command.
Virtual ADX(config)#csw-rule r1 response-header “Set-Cookie” pattern “JSESSIONID”
Syntax: [no] csw-rule rule-name response-header header-name pattern search-string
The rule-name variable can be up to 80 characters in length.
The header-name variable specifies HTTP header field to be matched in an HTTP response from a
real server.
The search-string variable specifies the string within the header-name variable that will be
matched in the HTTP response from a real server.
Creating a CSW rule to match the client request
To create a CSW rule to match the client request, use the following command.
Virtual ADX(config)#csw-rule r2 header “Cookie” pattern “JSESSIONID”
Syntax: [no] csw-rule rule-name header header-name pattern search-string
The rule-name variable can be up to 80 characters in length.
The header-name variable specifies the HTTP header field to be matched in an HTTP request from
a client.
The search-string variable specifies the string within the header-name variable that will be
matched in an HTTP request from a client.
Specifying a CSW action to create persistence information
To specify a CSW action to maintain persistency information, use the following command.
Virtual ADX(config)#csw-policy p1
Virtual ADX(config-csw-policy-p1)#match r1 passive-persist offset 0 length 11
Syntax: [no] match rule-name passive-persist offset persistence-string-offset length
persistence-string-length
The rule-name variable is the name of a previously configured CSW rule that was defined to match
a server response.
The persistence-string-offset variable specifies the number of characters that will be skipped
directly after the search-string variable matched in the specified CSW rule. Normally this value is 0
(zero) which places the start point at the character that is right after the string. As an example, you
can configure a search string to “JSESSIONID” as specified for “r1, with an offset of “0”. Where the
string found is “JSESSIONID=0123456789abcdefg012345643352256", an offset of “0” will
mean that the hash string will start with “=”. If the offset is “7” the string will be parsed beginning
with the integer “6”.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
277
5
Server passive cookie persistence
Once the offset point is set by the persistence-string-offset, the system will parse the search-string
variable matched in the specified CSW rule up-to the number of characters defined by the value of
the persistence-string-length variable. The value of the persistence-string-length variable must be
greater than 0 (zero). If the value of the length variable extends beyond the length of the
search-string variable, the system will look to the end of the string to define the string used for
hashing.
For example: if the search string is “JSESSIONID” and the offset is “0”, the string will be parsed
beginning with the “=”. If the persistence-string-length variable is set to “7”, the string used will be
“0123456”.
Specifying a CSW action to perform persistence lookup and retrieve real server
information
To specify a CSW action to perform persistency information lookup and use stored real server
information to forward requests, use the following command.
Virtual ADX(config)#csw-policy p1
Virtual ADX(config-csw-policy-p1)#match r2 persist offset 0 length 11
passive-persist
Syntax: [no] match rule-name persist offset persistence-string-offset length
persistence-string-length passive-persist
The rule-name variable is the name of a previously configured CSW rule that was defined to match
a client request.
The persistence-string-offset variable specifies the number of characters that will be skipped after
the start point of the search-string matched in the specified CSW rule. Normally this value is 0
(zero) which places the start point at the beginning of the string. For example: if the search string is
“JSESSIONID” as specified in r1, and the offset is “0”, the string will be parsed beginning with the
capital “J” in “JSESSIONID.” If the offset is “7” the string will be parsed beginning with the capital
“N”.
Once the offset point is set by the persistence-string-offset, the system will parse the search-string
matched in the specified CSW rule up-to the number of characters defined by the value of the
persistence-string-length variable. The value of the persistence-string-length variable must be
greater than 0 (zero). If the value of the length variable extends beyond the length of the
search-string, the system will look to the end of the string to define the string used for hashing. For
example: if the search string is “JSESSIONID” as specified in r1, and the offset is “0”, the string will
be parsed beginning with the capital “J” in “JSESSIONID”. If the persistence-string-length is set to
“7”, the string used will be “JSESSIO”.
Example
The following example is similar to the example shown in Figure 32 with the following operation:
1. The Client request the following URL: www.test.com
2. The server responds with a page and performs “Set-Cookie: PSrvrID=1234567”
The page contains several URL such as: href=”test/nextpage.html?PSrvrID=1234567"
278
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Server and server port persistence with CSW nested rules
5
3. The Client clicks on the link: www.test.com/test/nextpage.html?PSrvrID=1234567
If cookies are enabled, the Client sends: “Cookie: PSrvrID=1234567”
If cookies are disabled, NO cookie is sent back.
4. The load balancer analyzes the incoming request as described:
If “cookie” is found in the header (Cookie:), the cookie value is looked up in the session table
for the session bound to the same server.
If no cookie is found, the URL can be analyzed. the cookie name is also found after the “?”
value is found. It is also looked up in the session table for the session bound to the same
server.
Sample configuration
You can use the following configuration for the previous example.
Virtual ADX(config)#csw-rule "response-cookie" response-header "Set-Cookie"
pattern "PSrvrID="
Virtual ADX(config)#csw-rule "uri" url pattern "PSrvrID="
Virtual ADX(config)#csw-rule "forward-cookie" header "Cookie" pattern "PSrvrID="
Virtual ADX(config)#csw-policy "passive1"
Virtual ADX(config-csw-policy-passive1)#match "response-cookie" passive-persist
offset 0 length 7
Virtual ADX(config-csw-policy-passive1)#match "forward-cookie" persist offset 0
length 7 passive-persist
Virtual ADX(config-csw-policy-passive1)#match "uri" persist offset 0 length 7
passive-persist
You must then bind the csw-policy to a virtual server port.
Server and server port persistence with CSW nested rules
This section contains the following sub-sections:
• “Configuring server and server port persistence with CSW nested rules” on page 279
• “Configuring persist on the nested rule” on page 280
• “Configuring persist on the real port” on page 280
NOTE
CSW nested rules are not supported in a csw response rewrite policy.
Configuring server and server port persistence with
CSW nested rules
This section describes the support of CSW rewrite/persist on nested rule and persist on real server
ports.
Currently, CSW supports rewrite or persist action on simple rules. The rewrite or persist action on
nested rules is not supported, because the place of rewrite or persist action can not be decided on
nested rule. This new feature adds a new CLI to specify a base rule within nested one that rewrite
or persist action can be based on.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
279
5
Server and server port persistence with CSW nested rules
Also, the current CSW supports the persistence on the group or server ID. Support of persistence
on the real server port gives you more granular control.
This feature is to be used with persistence on the group or server ID and is useful when the
customer has multiple ports configured on the same group or server, and also wants to direct the
request to a particular port instead of load balancing among all the ports.
Persist or rewrite actions can be performed when a nested rule matches, and the location of
persistence or rewrite string is determined by a master rule within the nested rule.
Configuring persist on the nested rule
To create a csw nested rule, enter a command such as the following.
Virtual ADX(config)#csw-rule r1 url pattern "pweb"
Virtual ADX(config)#csw-rule r2 url pattern "jsession"
Virtual ADX(config)#csw-rule n1 nested-rule "r1&&r2" master-rule r2
Syntax: [no] csw-rule rule-name nested-rule rule-logic-string master-rule rule-name
NOTE
If a master rule is not specified, the default master in the first rule is the nested rule.
NOTE
If a master rule is not present when the nested rule matches, the persist or rewrite action cannot be
performed. It will be treated as nested rule not matched.
Configuring persist on the real port
To specify the real port for a persist action, enter a command such as the following.
Virtual ADX(config)#csw-policy p1
Virtual ADX(config-csw-p1)#match n1 persist offset 22 length 2 group-or-server-id
real-port 10500
Syntax: [no] match rule-name persist offset offset length offset [[persist-method [real-port port
[port-failover | fail-close]]] [secondary]]
NOTE
The real port and the failover modes can only be specified when the persist-method variable is
group-or-server-id.
The three modes when the specified real port is not available are:
• Default: Layer 4 load balancing is performed.
• Port-failover: The Brocade Virtual ADX fails over to the same port number configured on the
virtual port. When there is no real port to be failed over, the client connection is closed.
• Fail-close: The Brocade Virtual ADX immediately closes the client connection.
280
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Server and server port persistence with CSW nested rules
5
Usage example
The customer needs the following request:
•
•
•
•
Two real servers, 192.168.1.100 and 192.168.1.101.
Each server has a different application listening on different ports: 10500 and 10520.
Each server is configured to a different group, 30 and 31.
The request with “pweb” and “jsession=groupid”embedded in the URL is directed to the
specified group.
The configuration is as follows.
• For configuring the real server, enter the following commands:
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server real-name-or-ip rs1
ADX(config-rs-rs1)#port 10500 group-id
ADX(config-rs-rs1)#port 10520 group-id
ADX(config-rs-rs1)#exit
ADX(config)#server real-name-or-ip rs2
ADX(config-rs-rs2)#port 10500 group-id
ADX(config-rs-rs2)#port 10520 group-id
ADX(config-rs-rs2)#exit
192.168.1.100
20 20 30 30
21 21 30 30
192.168.1.101
20 20 31 31
21 21 31 31
• For configuring the CSW rule, enter the following commands:
Virtual ADX(config)#csw-rule r1 url pattern "pweb"
Virtual ADX(config)#csw-rule r2 url pattern "jsession="
Virtual ADX(config)#csw-rule n1 nested-rule "r1&&r2" master-rule r2
• For configuring the CSW policy, enter the following commands:
Virtual ADX(config)#csw-policy p1
Virtual ADX(config-csw-p1)#match n1 persist offset 0 length 2
group-or-server-id real-port 10500
• For configuring the virtual server, enter the following commands:
Virtual
Virtual
Virtual
Virtual
ADX(config)#server virtual-name-or-ip vip1 10.10.10.100
ADX(config-vs-vip1)#bind http rs1 10500 rs1 10520
ADX(config-vs-vip1)#bind http rs2 10500 rs2 10520
ADX(config-vs-vip1)#port http csw-policy p1
The result of the configuration is if the request has the string "pweb" and also string "/jsession=30"
embedded in the url, Then the rule n1 will be matched and the Brocade Virtual ADX will choose to
connect to the rs1 (group 30) and the port 10500
If the port 10500 on rs1 is not available, the client request fails over to the port 10500 on rs2.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
281
5
Displaying CSW information
Displaying CSW information
Displaying header information
To display information about the HTTP headers encountered in a Layer 7 content switching
configuration, enter the following command.
Virtual ADX#show csw-hdr-info
Unknown header list
Name
:Hdr Tab Ind :Ref Co
-----------------------------------------------------------Cookie:
:0
:1
Unknown header count: 1
Known header list
Name
:Hdr Tab Ind
-----------------------------------------------------------Connection:
:10
Transfer-Encoding:
:11
Content-Length:
:12
Host:
:13
Cookie:
:14
Pragma:
:15
Cache-Control:
:16
Known header count: 7
XML tag list
Name
:Tab Ind
:Ref Co
-----------------------------------------------------------banner1
:0
:4
banner2
:1
:1
banner3
:2
:1
banner4
:3
:1
banner5
:4
:1
banner6
:5
:1
banner7
:6
:1
banner8
:7
:1
volume
:8
:9
XML tag count: 9
Syntax: show csw-hdr-info
Table 26 describes the information displayed by the show csw-hdr-info command.
TABLE 26
Output from the show csw-hdr-info command
Field...
Description
Unknown header list
282
Name
The name of each unknown header field encountered.
Hdr Tab Ind
The offset in the header table.
Ref Co
The reference count of the number of rules using this header.
Unknown header count:
The number of unknown headers encountered.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Displaying CSW information
TABLE 26
5
Output from the show csw-hdr-info command (Continued)
Field...
Description
Known header list
Name
The name of each known header field encountered.
Hdr Tab Ind
The offset in the header table.
Known header count:
The number of unknown headers encountered.
XML tag list
Name
The name of each XML tag encountered.
Hdr Tab Ind
The offset in the XML tag table.
Ref Co
The reference count of the number of XML rules using this header.
XML tag count:
The number of XML tags encountered.
Displaying CSW rule information
To display information about the Layer 7 content switching rules configured on the device, enter the
following command.
Virtual ADX#show csw-rule
Rule Count: 24 Rules Allocated: 24
Rule type description:
met: method
ver: version
hdr: header
nes: nested
Rules Deleted: 0
url: url
con:content
Rule Name
|Rule Type |Data
|Data
|Data
|Ref C|Prot
--------------------------------------------------------------------------ban1
|xml-tag
|banner1
|equals
|1
|0
|http
ban2
|xml-tag
|banner1
|equals
|2
|0
|http
ban3
|xml-tag
|banner1
|equals
|3
|0
|http
Syntax: show csw-rule [rule-name]
Table 27 describes the information displayed by the show csw-rule command.
TABLE 27
Output from the show csw-rule command
Field
Description
Rule Count
The number of Layer 7 content switching rules configured on the device.
Rules Allocated
The total number of rules allocated.
Rules Deleted
The total number of rules deleted since the Brocade Virtual ADX was started.
Rule Name
The name of each rule.
Rule Type
The type of rule: HTTP method, HTTP version, HTTP header, URL, or XML tag.
Data fields
The specification for the rule; that is, the content that the rule matches.
Ref C
The number of nested rules and policies using this rule.
Prot
The protocol of the packets matched by the rule.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
283
5
Displaying CSW information
To display detailed information for a specified rule, enter a command such as the following.
Virtual ADX#show csw-rule volume1 detail
Rule Name
:volume1
Rule Type
:xml-tag
Header
:volume
Operator
:equals
Value
:Volume I
case-insensitive:FALSE
Ref cnt
:1
Sub Rule cnt
Sub Rules
:1
:volume1
Before Minterm Reduction
Min term mask :0x00000002
Min terms
:1
After Minterm Reduction
Min term cnt
:1
Minterms
:volume1
Hdr/Meth Ind
:8
Syntax: show csw-rule rule-name detail
The following table describes the information displayed by the show csw-rule detail command.
Table 28 defines the fields shown in the screen display.
TABLE 28
Output from the show csw-rule detail command
Field
Description
Rule Name
The name of the rule.
Rule Type
The type of rule: HTTP method, HTTP version, HTTP header, URL, or XML tag.
Header
The HTTP header matched by the rule.
Operator
The operator used to match the content: exists, prefix, suffix, pattern, equals, or search
Value
The content matched by the rule.
Ref cnt
The number of nested rules and policies using this rule.
Sub Rule cnt
If this is a nested rule, the number of rules referring to this one.
Sub Rules
If this is a nested rule, a list of the rules that refer to this rule.
Before Minterm Reduction
Min term
mask
Number of minterms for the expression.
Min terms
List of minterms.
After Minterm Reduction
284
Min term cnt
Number of minterms for the expression.
Minterms
List of minterms.
Hdr/Meth Ind
Index into the header in the method table.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Displaying CSW information
5
Displaying CSW policy information
To display information about a Layer 7 content switching policy, enter the following command on
the BP.
Virtual ADX#show csw-policy server-sw
Policy Name
:server-sw
Policy Type:Content Switching
Policy Index:4
Reference Count:0
total received packet:0
created session:0total scanned packet:0
no session drop:0no session frag drop:0
send redirect packet:0case-sensitive:FALSE
Action code description:
fwd: forwardrst: reset-clientper: persist
rdr: redirecterr: reply-error got: goto
rwt: rewrite log: log
con: countdrp: droprec: vir-reset
Flag description:
A: insert-cookieB: delete-cookie C: destroy-cookie
D: req-ins-hdrE: req-ins-client-ipF: resp-ins-hdr
G: delete-contentH: insert-content I: modify-content
L: log
Rule Name
|Act|Data1
|Data2
|Data3
|Flags
|Hit Cnt
-----------------------------------------------------------------------------url1024
|fwd|1024
|
|N/A
|_______
|2
url1025
|fwd|1025
|
|N/A
|_______
|3
default
|fwd|1
|
|N/A
|_______
|10
-------------------------------------------------------------------------------
Syntax: show csw-policy server-sw
Table 29 defines the fields shown in the screen display.
TABLE 29
Output from the show csw-policy command
Field
Description
Policy Name
The name of the policy.
Reference Count
Number of VIPs using this policy.
Rule Name
The rules configured under the policy.
Act
The action specified for each rule.
Data fields
The specification for the rule; that is, the content that the rule matches.
Flags
Information about the content-rewrite actions for the rule, if configured.
Hit Cnt
The number of times a rule matched.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
285
5
Displaying CSW information
To display detailed information about a policy, enter a command such as the following.
Virtual ADX#show csw-policy server-sw detail
Policy Name
:server-sw
Policy Type:Content Switching
Policy Index:4
Reference Count:1
total received packet:0
created session:0total scanned packet:0
no session drop:0no session frag drop:0
send redirect packet:0case-sensitive:0
Action code description:
fwd: forwardrst: reset-clientper: persist
rdr: redirecterr: reply-error got: goto
rwt: rewrite log: log
con: countdrp: droprec: vir-reset
Flag description:
A: insert-cookieB: delete-cookie C: destroy-cookie
D: req-ins-hdrE: req-ins-client-ipF: resp-ins-hdr
G: delete-contentH: insert-content I: modify-content
L: log
Rule Name
|Act|Offse|Data1 | Data2|Data3
|Flags
|Hit Cnt
--------------------------------------------------------------url1024
|fwd|0
|1024
|
|N/A
|_______
|0
url1025
|fwd|1
|1025
|
|N/A
|_______
|0
default
|fwd|0
|1
|
|N/A
|_______
|0
--------------------------------------------------------------Total Rule Count
Simple Rule Count
Minterm Count
Database Count
XML Tag Count
Parse Mask
Parse Tags
:1
:1
:1
:1
:0
:0x00020000
:url
Vip Bindings
:10.168.28.150 [80]
Syntax: show csw-policy policy-name detail
In addition to the information shown in Table 29, the show csw-policy detail command displays the
following information.
Table 30 defines the fields shown in the screen display.
TABLE 30
286
Output from the show csw-policy detail command
Field
Description
Offse
The offset into the minterm table.
Total Rule Count
The total number of rules in the policy.
Simple Rule Count
The total number of simple (not nested) rules used in the policy.
Minterm Count
The number of minterms.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Displaying CSW information
TABLE 30
5
Output from the show csw-policy detail command (Continued)
Field
Description
Database Count
The number of search databases.
XML Tag Count
The number of XML tags used in the policy.
Parse Mask
Mask to indicate the parsing information.
Parse Tags
The header or XML tags to be parsed.
Vip Bindings
The list of VIPs and port numbers using this policy.
Displaying the statistics for all HTTP content rewrites
You can use the show l7-rewrite-info command to display the statistics for all HTTP content
rewrites. Using this command on the Management Processor (MP) shows the results of all HTTP
content rewrites for both the MP and the BPs. Using this command on a BP (the web switching CPU)
shows the results for the BP only.
To display the statistics for all HTTP content rewrites, enter a command such as the following.
Virtual ADX#show l7-rewrite-info
HTTP Content Rewrites:
Total Allocated:
Used Now:
9
4
Total Freed:
Allocation Failures:
5
0
Content Rewritings Done in HTTP Requests:
Cookie Deleted:
0
Cookie Destroyed:
1
Header Insertion:
2
Client IP Insertion:
2
Cookie
Cookie
Header
Client
0
0
0
0
Content Rewritings Done in HTTP Responses:
Cookie Inserted:
1
Header Insertion:
0
Cookie Insertion Err:
Header Insertion Err:
Deletion Err:
Destroy Err:
Insertion Err:
IP Insertion Err:
0
0
Total Memory Already Consumed: 64 KB.
Syntax: show l7-rewrite-info
Table 31 defines the fields shown in the screen display.
TABLE 31
Layer 7 Rewrite information
Field
Description
HTTP Content Rewrites
Shows the memory slots used to perform HTTP content rewrites.
Total Allocated
The total number of allocation times of memory slots used to perform content
rewrites.
Total Freed
The total number of freed times of memory slots used for content rewrites.
Used Now
The number of memory slots that are currently used to perform content rewrites.
Allocation Failures
The number of failures that occurred while allocating memory for content
rewrites.
Content Rewritings Done in
HTTP Requests
This section displays information related to cookie deletions, header insertions,
and client IP insertions.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
287
5
Displaying CSW information
TABLE 31
Layer 7 Rewrite information (Continued)
Field
Description
Cookie Deleted
The total number of cookies deleted in HTTP requests.
Cookie Deletion Err
The number of errors that occurred when deleting cookies in HTTP requests.
Cookie Destroyed
The number of cookies destroyed during HTTP requests.
Cookie Destroy Err
The number of errors that occurred while destroying cookies in HTTP requests.
Header Insertion
The total number of headers inserted in HTTP requests.
Header Insertion Err
The number of errors that occurred when inserting headers in HTTP requests.
Client IP Insertion
The total number of client IP headers inserted in HTTP requests.
Client IP Insertion Err
The number of errors that occurred when inserting client IP headers in HTTP
requests.
Content Rewritings Done in
HTTP Responses
This section contains information about cookie and header insertions.
Cookie Inserted
The total number of cookies inserted in HTTP responses.
Cookie Insertion Err
The number of errors that occurred when inserting cookies in HTTP responses.
Header Insertion
The total number of headers inserted in HTTP responses.
Header Insertion Err
The number of errors that occurred when inserting headers in HTTP responses.
Total Memory Already
Consumed
The total amount of memory allocated for HTTP content rewrites.
Displaying Layer 7 switching statistics
To display Layer 7 switching statistics, enter the following command at any level of the CLI.
Virtual ADX#show server proxy
Slot alloc
=
Slot freed
=
Pkt stored
=
Pkt freed
=
Session T/O
=
Session del
=
DB cleanup cnt
=
Serv RST to SYN
=
URL not in 1st pkt
=
URL not complete
=
Sess T/O rev Sess 0 =
Dup SYN Sess diff
=
Curr slot used
=
0
0
0
0
0
0
0
0
0
0
0
0
0
Curr free slot
Slot alloc fail
Max slot alloc
Fwd Stored pkt
Sess T/O pkt free
Sess del pkt free
DB cleanup pkt free
Send RST to C
Cookie not in 1st pk
Cookie not complete
Sess T/O Sess diff
=
=
=
=
=
=
=
=
=
=
=
99999
0
0
0
0
0
0
0
0
0
0
Curr pkt stored
=
0
Syntax: show server proxy
Table 32 defines the fields in the screen display.
TABLE 32
288
Layer 7 Switching statistics
Field
Description
Slot alloc
Number of proxies allocated
Curr free slot
Number of proxies possible
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Usage guidelines
TABLE 32
5
Layer 7 Switching statistics (Continued)
Field
Description
Slot freed
Number of proxies finished
Slot alloc fail
Number of proxy allocation failures
Pkt freed
Number of packets stored by proxy
Max slot alloc
Maximum number of concurrent proxies
Pkt freed
Number of packets freed by proxy
Fwd Stored pkt
Number of stored packets sent to server
Session T/O
Number of session timeouts
Sess T/O pkt free
Number of stored packets freed due to session timeout
Session del
Number of sessions freed by proxy
Sess del pkt free
Number of stored packets deleted when session was freed
DB cleanup cnt
Proxy cleanup count
DB cleanup pkt free
Number of stored packets freed during proxy cleanup
Serv RST to SYN
Number of times the server sent RST to TCP SYN
Send RST to C
Number of times the Brocade Virtual ADX sent RST to client
URL not in 1st pkt
Number of times the URL string was not in the first packet
URL not complete
Number of times the URL string was not complete
Cookie not in 1st pk
Number of times the Cookie header was not in the first packet
Cookie not complete
Number of times the Cookie header was not complete
Sess T/O rev Sess 0
Number of session timeouts with no reverse session
Sess T/O Sess diff
Number of session timeouts, internal proxy error
Dup SYN Sess diff
Number of duplicate SYNs received, internal proxy error
Curr slot used
Number of existing proxies
Curr pkt stored
Current number of packets stored by proxy
Usage guidelines
When you define an offset or negative offset value to insert or delete a string, the value is not
allowed to go beyond the URL value defined by the associated CSW rule. If it does exceed the
boundary of the URL value, the Brocade Virtual ADX adjusts it to align with the beginning or the end
of the URL.
Similarly, the deletion action is not allowed to delete content beyond the URL value defined by its
associated CSW rule. If the string to be deleted does exceed the start or end of the boundary of the
URL or header value content, Brocade Virtual ADX limits the string to be deleted to the part within
the boundary.
Syntax: match rule-name rewrite request-insert string [offset | neg-offset offset]
The rule-name variable defines the name of CSW rule.
The string variable defines the string to be inserted.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
289
5
Miscellaneous Layer 7 switching configurations
The offset variable defines the distance of bytes from the offset 0. By default, offset 0 is right after
the interested string defined by matched CSW rule.
The Keyword offset or neg-offset indicates that the insertion offset starting after or before the
offset 0.
Support for large GET requests
The Brocade Virtual ADX can perform Layer 7 Content Switching on large GET requests (up to
20,000 bytes). Earlier releases supported up to 8,000-byte GET requests.
Miscellaneous Layer 7 switching configurations
Cleaning up all hash buckets
To clean up all hash buckets when a server port comes alive, enter the following command.
Virtual ADX(config)#server l7-hashing-bucket-reassign
Syntax: [no] server l7-hashing-bucket-reassign
This command also allows new connections to be forwarded to the server port that has just come
up.
Layer 7 content buffering options
In an Layer 7 switching configuration, the Brocade Virtual ADX stores client request packets in the
Layer 7 content buffer while it selects a real server to which to forward the request. The Brocade
Virtual ADX buffers the client request up to the end of the HTTP request, or up to a maximum of 20
packets.
The following two Content Buffering Options allow you to optimize the usage of the Brocade Virtual
ADX’s Layer 7 content buffer:
• Modifying the TCP window size so that the client sends fewer packets before waiting for an ACK
• Configuring the Brocade Virtual ADX not to send an ACK to the client after it has received
enough information to select a real server
Changing the TCP window size
The TCP window size in a SYN ACK or ACK packet specifies the amount of data that a client can
send before it needs to receive an ACK from a server. By reducing the TCP window size for SYN ACK
or ACK packets sent by the Brocade Virtual ADX when performing Layer 7 switching, you can
decrease the number of packets a client will send before it waits to receive an ACK from the
Brocade Virtual ADX, thus making more efficient use of the Brocade Virtual ADX’s Layer 7 content
buffer.
To change the TCP window size to 1460 bytes, enter the following command.
Virtual ADX(config)#server l7-tcp-window-size 1460
Syntax: server l7-tcp-window-size window size
290
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Miscellaneous Layer 7 switching configurations
5
The default TCP window size is 8000 bytes. Setting the TCP window size to 1460 bytes causes a
client to send only one packet before waiting for the Brocade Virtual ADX to send an ACK, assuming
a Maximum Segment Size (MSS) of 1460 bytes. This setting applies only to SYN ACK and ACK
packets sent from the Brocade Virtual ADX to the client. The Brocade Virtual ADX does not modify
the TCP window size for traffic sent from real servers to clients by way of the Brocade Virtual ADX.
Preventing the Brocade Virtual ADX from sending an ACK to the client
You can configure the Brocade Virtual ADX not to send an ACK back to the client after the Brocade
Virtual ADX receives enough data from the client to select a real server. For example, if you enable
this feature in a URL switching configuration, and the Brocade Virtual ADX has received the entire
URL in a request, it does not send an ACK to the client after receiving the last packet. Withholding
the ACK prevents the client from sending further data to the Brocade Virtual ADX, increasing the
efficiency of the Layer 7 content buffer.
To cause the Brocade Virtual ADX not to send an ACK to the client after it has received enough
information to select a real server in a Layer 7 switching configuration, enter the following
command.
Virtual ADX(config)#server l7-dont-ack-last-packet
Syntax: server l7-dont-ack-last-packet
HTTP 1.1 support
The Brocade Virtual ADX has HTTP 1.1 support for Layer 7 switching and the Server Connection
Offload (HTTP Connection Proxy) features. These features help reduce TCP connection overhead by
offloading the management of TCP connections from application servers and allowing them to
dedicate resources for handling application transactions. These features significantly increase the
performance and capacity of back-end servers, minimize the number of round trips between users
and servers, reduce the bandwidth cost, and improve the Web experience of users.
HTTP was originally designed for simple text documents with embedded images that contain
hyperlinks to other documents. For each hyperlinked image, HTTP 1.0, by default, creates a
separate TCP connection, even if the images are all on the same server. In comparison, HTTP
version 1.1 allows a TCP connection or keepalive connection to remain open until all consecutive
requests and responses are complete. This technique is called persistent connection.
Persistent connection is enabled by default on HTTP 1.1 but is disabled by default in HTTP 1.0. For
HTTP 1.0, Web browsers must explicitly insert the HTTP header "Connection: keepalive" to enable
persistent or keepalive connections.
This release introduces two modes to support persistent connections: TCP offload mode and
keepalive mode. Both modes try to maintain and reuse keepalive connections on both the client
side and the server side.
TCP offload mode allows a request from one connection on the client side to re-use any established
connection on the server side. TCP offload mode offloads the management of TCP connections
from servers so they can dedicate resources to serving HTTP requests instead of managing
connections.
The re-use of open connections causes the source IP address and port of the request to be
translated from the original connection on the client side to a connection on the server side.
Consequently, a server cannot distinguish between clients simply by the source IP address of the
connections. If servers need to distinguish between clients’ source IP addresses, the keepalive
mode is recommended. It reuses the connections on the server side for application requests from
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
291
5
Miscellaneous Layer 7 switching configurations
clients that originally created the connections. When a client makes a request for content that is
served by a different server, the Brocade Virtual ADX closes the connection to the original server on
the server side before setting up a connection with the new server; however, the connection on the
client side can still be reused if keepalive mode is enabled on the client connections.
Default settings
By default, Brocade Virtual ADX comes enabled with HTTP 1.0 for any Layer 7 switching feature.
However, HTTP 1.0 connections are non-persistent, and therefore persistent connections or
keepalive connections are disabled by default. To support persistent connections, enable TCP
connection offload mode or keepalive mode on a virtual port. These modes are enabled at the
virtual server level.
Enabling the TCP offload mode
TCP offload mode allows a request from one connection on the client side to reuse any established
connection on the server side.
To enable persistent connection in TCP offload mode for the HTTP port on a virtual server named
"vserv1", enter the commands such as the following.
Virtual ADX(config)#server virtual-name-or-ip vserv1
Virtual ADX(config-vs-vserv1)#port http tcp-offload
Syntax: [no] port port tcp-offload [age minutes]
or
Syntax: [no] port port tcp-offload [transactions trans-num]
The age minutes variable specifies how many minutes a connection on the server side can be kept
alive. If it is not specified, by default, the keepalive time will be the same as the session age, which
can be defined globally by entering the server tcp-age minutes command or locally under the
virtual server level by entering the port port-num tcp-age minutes command.
The transactions trans-num variable specifies the maximum number of HTTP transactions that can
be completed on a connection on the server side.
If the age or transaction limit is reached, the connection on the server side is closed and a reset
packet will be sent to the server.
Graceful handling of HTTP pipelined requests
If HTTP is enabled, a client supporting persistent connection can use pipelining by allowing multiple
requests to be sent over the same connection without waiting for a response for each request. By
default, the Brocade Virtual ADX is able to handle HTTP pipelined requests. When it handles the
first of the pipelined requests, it holds the rest of pipelined requests. After the client receives the
response of the first request, the Brocade Virtual ADX handles the next pipelined request.
The Brocade Virtual ADX can be configured to handle the first request of a pipelined request
correctly and optionally send reset to the subsequent requests. This feature helps prevent
performance degradation. Reset can be enabled in keepalive mode or TCP offload mode.
292
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Miscellaneous Layer 7 switching configurations
5
This feature works only when Content Switching is enabled on a virtual server port. if pipelined
HTTP requests are sent in one connection, the Virtual ADX makes the switching decision based on
the first request and forwards only the first request to the real server. When the real server sends a
complete response to the first request, the Virtual ADX will forward the response to the client. After
the client acknowledges the complete response, the Virtual ADX closes the connection by sending
a RST to the client.
NOTE
Resetting the HTTP connection can be done in either the keepalive mode or the TCP offload mode.
To reset a pipelined HTTP request in the keepalive mode, first make sure Content Switching is
enabled on a virtual server port that will be used for the pipeline reset request.
Then, enter commands such as the following.
Virtual ADX(config)#server virtual-name-or-ip VS1 10.10.10.10
Virtual ADX(config-vs-VS1)#port http
Virtual ADX(config-vs-VS1)#port http keep-alive reset-pipeline-request
Syntax: [no] port [portid] keep-alive [reset-pipeline-request]
To reset pipelined HTTP request in the TCP offload mode, enter commands such as the following.
Virtual ADX(config)#server virtual-name-or-ip VS1 10.10.10.10
Virtual ADX(config-vs-VS1)#port http
Virtual ADX(config-vs-VS1)#port http tcp-offload reset-pipeline-request
Syntax: [no] port port tcp-offload [age minutes] [reset-pipeline-request]
or
Syntax: [no] port port tcp-offload [reset-pipeline-request]
Clearing all keepalive connections
To delete all keepalive server side connections on all the applicable virtual servers, enter the
following command on the Brocade Virtual ADX.
Virtual ADX#clear server keep-alive virtual
Syntax: [no] clear server keep-alive [virtual | real] [server-name] [port]
Enter virtual if you want to delete all the keepalive connections associated with the virtual server, or
real if they are to be deleted from the specified real server.
The optional server-name and port variables specify the name or port of the virtual or real server
from where you want to delete the keepalive server-side connections. When you enter this
command, all the keepalive connections will be removed from the reuse pool. The Brocade Virtual
ADX sends reset packets to the real or virtual servers to close any open connections.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
293
5
Miscellaneous Layer 7 switching configurations
Displaying transactions and connections
To display information about the transactions and connections for Layer 7 switching over keepalive
connections, enter the following command.
Virtual ADX4/1#show server session keep-alive
Avail. Sessions
Hash size
=
=
1999972
200001
Total Sessions
=
2000000
Total C->S Conn
=
0 Total S->C Conn
=
0
Total Reassign
=
0 Unsuccessful Conn
=
0
Server State - 1:enabled, 2:failed, 3:test, 4:suspect, 5:grace_dn, 6:active
Real Server
MyServer01
MyServer02
MyServer03
St CltConn:Cur/Tot SerConn:Cur/Tot CurrTrans IdleSerCon
1 11/46
3/5
2
1
1 0/0
0/0
0
0
1 0/0
0/0
0
0
TotTrans
147
0
0
Table 33 specifies the show server session keep-alive command fields and its description
TABLE 33
Fields in the show server session keep-alive display
Field
Description
CltConn:Cur/Tot:
Number of current and total client-side connections on this BP.
SerConn:Cur/Tot:
Number of current and total server-side connections on this BP. When persistent connection
is enabled, the number of current and total server-side connections is typically much less
than the current and total client-side connections, because a server-side connection can be
reused by requests from any client-side connection.
CurrTrans:
Number of busy server side connections that are in the process of serving HTTP transactions.
The difference between number of current client-side connections and CurrTrans indicates
the number of current idle client-side connections.
IdleSerCon:
Number of idle server-side connections that are available to be re-used by new requests made
to the same server. The sum of CurrTrans and IdleSerCon is equal to the number of current
server-side connections.
TotTrans
TotTrans: Total number of HTTP transactions that have been successfully completed for the
server. Because a persistent connection allows multiple HTTP transactions to be done,
TotTrans typically have a much higher value than the total number of both client-side and
server-side connections.
In the example above, MyServer01 has 11 concurrent client-side connections and 3 concurrent
server-side connections to the Real Server MyServer01. Two of the 3 server-side connections are
processing different HTTP transactions and the third one is idle.
In addition, clients made a total of 46 connections to the Brocade Virtual ADX; while the Brocade
Virtual ADX only needs to create a total of 5 server-side reusable keep-alive connections to
MyServer01 to serve all the requests sent on the 46 client-side connections. In those 46 client-side
connections and 5 server-side connections, 147 HTTP transactions have been completed.
Syntax: show server session keep-alive
NOTE
This command only works on the Brocade Virtual ADX.
294
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Miscellaneous Layer 7 switching configurations
5
Layer 7 CSW pseudo stack client-side retransmission
handling
The Brocade Virtual ADX Content Switching (CSW) pseudo stack needs to store HTTP request
packets from the client before it is able to perform server selection. If the stored packets are not
acknowledged by the CSW pseudo stack and these packets get dropped before reaching the
server, they can be retransmitted by the client. However, there are cases when the Brocade Virtual
ADX needs to acknowledge those stored packets before forwarding them to the server. An example
of this is when the client’s HTTP request spans multiple packets, and the client expect an
acknowledgment before transmitting the remaining request packets. Upon receiving all request
packets, the Brocade Virtual ADX performs server selection and transmits all requests packets to
the server. Since the current CSW pseudo stack does not keep the stored packets once they are
sent out, they will never be transmitted if these packets get dropped. If this occurs, the client will
keep retransmitting the request for acknowledgement to the Brocade Virtual ADX, until the TCP
timeout expires. As a result, the client will notice that the HTTP transaction never gets completed.
The Brocade Virtual ADX supports handling of HTTP request retransmission with Layer 7 pseudo
stack. When the Layer 7 CSW pseudo stack retransmission handling is enabled, the Brocade
Virtual ADX acknowledges and stores the client TCP packets, and does not clear its buffer until the
request packets are acknowledged by the server. If the retransmission timer triggers before the
request packets are acknowledged, the Brocade Virtual ADX will resend the stored packets.
The same situation can happen at the server side traffic. If server response headers span multiple
packets, the Brocade Virtual ADX also needs to send the acknowledgment to the server. With this
feature enabled, the server-side retransmission is also supported. The Layer 7 CSW pseudo stack
retransmission handling feature is disabled by default.
Enabling the Layer 7 CSW client-side retransmission handling
To enable Layer 7 CSW pseudo stack retransmission handling feature, enter the command as
follows:
Virtual ADX(config)#server csw enable-retransmission
Syntax: [no] server csw enable-retransmission
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
295
5
Miscellaneous Layer 7 switching configurations
Displaying the Layer 7 CSW client-side retransmission handling information
In order to display information about Layer 7 CSW client-side retransmission handled by the
Brocade Virtual ADX, use the show server proxy keep-alive command. A truncated display is shown:
Virtual ADX#show server proxy keep-alive
Keep-alive connection statistics:
...
Client-side statistics:
In seq. packets
=
412
Out of seq. packets:
Syn_recv
=
Not_complete
=
Reply_sent
=
Retransmit packets:
Syn_sent
Reply_sent
Reset cast to ack
Ack cast to Reset
Dup rev in src nat
=
=
=
=
=
Reset packets received:
Syn_recv
=
Syn_sent
=
Rep_sent
=
Unknown
=
...
Hash Bucket Change:
Current serv is down =
Lower BP wins
=
...
Unexpected data
=
0
0
0
0
Wait_req state
Req_sent state
=
=
=
0
0
0
0
0
0
0
0
Req_sent state
Req_sent state(old)
Fin cast to ack
Dup rev in Syn_sent
=
=
=
=
=
0
0
0
0
0
6
0
0
0
Wait_req
Req_sent
Page_replied
Others
=
=
=
=
0
0
0
0
0
0
Serv exceed max-conn =
=
0
0
Syntax: show server proxy keep-alive
This command displays the HTTP keep-alive connection statistics and also includes the
retransmission counters.
NOTE
The Layer 7 CSW pseudo stack retransmission handling feature does not support High Availability
(HA).
296
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
5
Miscellaneous Layer 7 switching configurations
Layer 7 CSW pseudo stack server-side TCP packet
out-of-sequence handling
With the current Layer 7 Content Switching (CSW) pseudo stack, the Brocade Virtual ADX expects
all TCP packets from the server-side to arrive in-sequence. If the server-side TCP packets are
received out-of-sequence, the Brocade Virtual ADX will silently drop the out-of-sequence TCP
packets and then wait for either the TCP stack timeout to expire, or for the server to retransmit. If
this occurs, the end-user will experience slowness while browsing certain Web pages over the
Internet.
The Brocade Virtual ADX Layer 7 CSW pseudo stack supports handling of packet-drops and
out-of-sequence TCP packets arriving from server-side as well.
Displaying server-side link connections
In order to display information about the server-side out-of-sequence TCP packets handled by the
Brocade Virtual ADX, use the show server proxy keep-alive command. The statistics relevant to the
out-of-sequence TCP packets are shown (in bold) in the following abbreviated output and described
in Table 34.
Virtual ADX#show server proxy keep-alive
Keep-alive connection statistics:
Server-side statistics:
...
TCB status:
Total in mem
=
512000
Allocated from mem
=
301
Allocated from pool =
0
...
Connection unreusable reasons:
Small window
=
0
Not reusable
=
0
Image
=
0
Current in pool
Freed to mem
Freed to pool
=
=
=
0
300
0
No rev sess
Fin/RST received
=
=
=
0
0
0
Curr TCBs in list
=
0
Out of sequence packet buffering:
total stored oos pkt =
3
total timeout drop
=
0
total freed oos pkt
total oversize drop
=
=
3
0
SYN_RECV
NOT_COMPLETE
SYN_SENT
PAGE_REPLIED
WAIT_REQ
REQ_STORED
REQ_SENT
STATE_UNKNOWN
=
=
=
=
0
0
0
0
Delayed ACK list status:
Total TCBs in list
=
Generated ack num
=
12
0
...
=
=
=
=
...
KA DEBUG: URL_MULTI_STATE_FREED [
...
0
0
0
0
31] =
113
Syntax: show server proxy keep-alive
NOTE
This command is available at the Brocade Virtual ADX BP console only.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
297
5
Setting up SSL session ID switching
The fields described in Table 34 provide statistics about out-of-sequence (oos) TCP packets.
TABLE 34
Out-of-sequence TCP packets statistics
Field
Description
Total stored oos pkt
The total number of out-of-sequence packets buffered by
the Brocade Virtual ADX.
Total freed oos pkt
The total number of out-of-sequence packets transmitted
by the Brocade Virtual ADX.
The number variable specifies the number of database entries. This variable can range from 8,192
to 256,000.
Setting up SSL session ID switching
SSL (Secure Sockets Layer) is a protocol for secure World Wide Web connections. The SSL protocol
protects your confidential information with server authentication, data encryption, and message
integrity. SSL is layered beneath application protocols such as HTTP, Telnet, FTP, Gopher, and NNTP,
and layered above the TCP/IP connection protocol. This structure allows SSL to operate
independently of the Internet application protocols. With SSL implemented on both the client and
server, your Internet communications are transmitted in encrypted form, ensuring privacy.
For SSL to work, all the SSL connections between a client and server must reach the same host.
SSL connections come in sequentially on particular ports; only one is open at a time. However,
each must go to the same server.
SSL Session ID switching is the Brocade Virtual ADX’s ability to connect a client to the same real
server to which it had previously established an SSL (Secure Sockets Layer) connection.
SSL provides security in Web transactions. An SSL connection is initiated when a user clicks a
hyperlink that begins with "https" (for example, https://secure.brocadenet.com). The browser
(client) initiates an SSL connection with the server on TCP port 443, a secure link is negotiated,
and encrypted data is transferred across it.
The SSL Handshake Protocol (SSLHP), one of two component protocols of SSL, negotiates the
connection between the client and server. SSLHP establishes security parameters for an SSL
session, including the SSL version number and the method of data encryption to use. One of the
security parameters set by SSLHP is the SSL Session ID, a variable-length value contained in the
session_id field in SSLHP messages. The SSL Session ID indicates whether the client wants to use
the security parameters established in a previous session or establish a completely new
connection.
To set up SSL session ID switching, perform the following tasks:
1. Configure the real servers for SSL.
2. Configure the virtual server for SSL session ID switching.
3. Adjust the age timer in the Brocade Virtual ADX’s database (optional).
4. Adjust the maximum number of session ID to real server associations that the Brocade Virtual
ADX can store in its internal database (optional).
298
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Setting up SSL session ID switching
5
SSL session ID workflow
Figure 33 illustrates how the initial SSLHP messages exchanged between a client and server,
client_hello and server_hello, establish an SSL Session ID.
FIGURE 33
How the SSL Handshake Protocol Establishes a Session ID
If the value in the session_id field that the client sends to the server is non-zero, the Brocade
Virtual ADX can connect the client to the server that originally sent the Session ID value. Figure 34
illustrates how this function, called SSL Session ID switching, works.
NOTE
SSL Session ID switching is supported for SSL v3.0 and higher only. In SSL versions prior to 3.0, the
session ID was established later in the handshaking process, after the client and server had started
exchanging encrypted data. If the session ID is encrypted, the Brocade Virtual ADX cannot make
forwarding decisions based on this information.
If the client source IP address is changed, session persistence based on SSL Session ID does not
work since Session ID information is not copied across Application Processors. If the source IP is
changed, the session may be processed by different Application Processor. The only exception is
SI-1008-1 model with single Application Processor.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
299
5
Setting up SSL session ID switching
FIGURE 34
How the Brocade Virtual ADX uses an SSL Session ID to Select a Real Server
Client sends initial client_hello message
with empty session_id
1
Client
Internet
Remote Access
Router
4
When client wants to resume session, it
sends a client_hello message containing
the session_id it received from the server
5
3
Brocade Virtual ADX stores session_id value
in an internal database that maps
session_id values to real servers
2
Real server rs10 responds with
server_hello message containing
non-zero session_id
Real Server rs10
209.157.22.10
Brocade Virtual ADX looks up session_id
value in its internal database,
sees that this session_id value
maps to real server rs10
6
Brocade Virtual ADX passes client_hello
message to real server rs10
Real Server rs20
209.157.22.20
Figure 34 illustrates the following process.
1. The first time a client attempts to establish an SSL connection to the server, there is no history
of a previous SSL session, so the session_id field in the client_hello message it sends to the
server is empty.
2. The server (in this example, real server rs10) sees that the session_id field in the client_hello
message is empty, indicating the client wants to establish a new SSL session. The server
responds to the client with a server_hello message that contains a session_id field with a
non-zero value.
3. The Brocade Virtual ADX examines the value in the session_id field sent by the server. The
Brocade Virtual ADX adds this value to an internal database, associating it with the real server
that sent it. This association between the session_id value and the real server resides in the
Brocade Virtual ADX’s database for a user-specified amount of time (default 30 minutes), after
which it is aged out. In this example, the Brocade Virtual ADX would map the value in the
session_id field to real server rs10.
4. When the client resumes the SSL connection to the server, it sends a client_hello message
containing the session_id value sent by the server.
5. The Brocade Virtual ADX examines the value in the session_id field sent by the client and looks
it up in its internal database.
6. If the value in the session_id field maps to a real server, the Brocade Virtual ADX initiates a TCP
connection to the server and passes the client_hello message to it. The Brocade Virtual ADX
forwards subsequent packets between the client and server with modifications to the IP and
TCP header for sequence number, acknowledgment number, and checksum adjustment.
300
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Setting up SSL session ID switching
5
Configuration Example
Configuring the real servers for SSL
To configure the real servers for SSL shown in Figure 34, enter commands such as the following.
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server real-name rs10 10.157.22.10
ADX(config-rs-rs10)#port ssl
ADX(config-rs-rs10)#exit
ADX(config)#server real-name rs20 10.157.22.20
ADX(config-rs-rs20)#port ssl
ADX(config-rs-rs20)#exit
Syntax: server real-name real-server-name ip-addr
Syntax: port ssl
The server real-name command defines the names and IP addresses of the real servers.
The port ssl command adds port 443 (SSL) to the real servers.
Configuring the virtual server for SSL session ID switching
The following commands enable SSL Session ID switching on a virtual server called sslVIP.
Virtual
Virtual
Virtual
Virtual
ADX(config)#server virtual-name-or-ip sslVIP 10.157.22.241
ADX(config-vs-sslVIP)#port ssl session-id-switching
ADX(config-vs-sslVIP)#bind ssl rs10 ssl
ADX(config-vs-sslVIP)#bind ssl rs20 ssl
Syntax: port ssl session-id-switching
Syntax: port port-number session-id-switching
Syntax: bind ssl real-server-name ssl
The port ssl session-id-switching command enables SSL Session ID switching on this virtual server.
The bind ssl ssl command binds the virtual server to SSL services on the real servers. In this
example, the commands associate real servers rs10 and rs20 with the virtual server.
NOTE
For clarity, the bindings in the example are shown as two separate entries. Alternatively, you can
enter all the binding information as one command: for example, bind ssl rs10 ssl rs20 ssl.
Adjusting the age timer
By default, the Brocade Virtual ADX keeps the entry associating a session_id with a real server in
its database for 30 minutes. After 30 minutes, the entry ages out of the database. You can change
the length of time the Brocade Virtual ADX keeps the entry in the database,
To change the aging period from its default of 30 minutes to 10 minutes, enter a command such as
the following.
Virtual ADX(config)#server session-id-age 10
Syntax: [no] server session-id-age minutes
The minutes variable is defined in minutes within the range from 2 through 60.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
301
5
Command reference
Adjusting the maximum number of session_id-to-real-server associations
By default, the Brocade Virtual ADX can store in its database 8,192 entries associating a
session_id with a real server.
You can change the maximum number of database entries to any larger value up to 256,000 by
entering a command such as the following.
Virtual ADX(config)#server max-ssl-session-id 256000
Syntax: server max-ssl-session-id number
The number variable specifies the number of database entries. This variable can range from 8,192
through 256,000.
Command reference
This section describes the following HTTP URL Rewrite options. These "options" are part of the
match command.
• “rewrite request-delete”
• “rewrite request-insert”
• “rewrite request-replace”
rewrite request-delete
Use the rewrite request-delete option in the CSW policy configuration mode to delete content, as
shown in the following.
Virtual ADX(config-csw-mypolicy)#match r11 rewrite request-delete offset 4 2
Syntax: match rule-name rewrite request-delete {matched-string | neg-offset offset length |
offset offset length | string ASCII string}
The matched-string parameter specifies the matched-string option for the request to delete a string
defined by a rule.
The neg-offset parameter specifies the negative-offset option for the delete request as defined by
the following variables:
• The offset variable is the value of the deletion offset.
• The length variable is the value of the length of content to be deleted.
The offset parameter specifies the positive-offset option for the delete request as defined by the
following variables:
• The offset variable is the value of the deletion offset.
• The length variable is the value of the length of content to be deleted.
The string parameter specifies the string option for the delete request as specified by the following
variable:
The ASCII-string variable, which specifies the value of the string to be deleted.
302
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Command reference
5
rewrite request-insert
Use the rewrite request-insert option in the CSW policy configuration mode to insert content, as
shown in the following.
Virtual ADX(config-csw-mypolicy)#match r11 rewrite request-insert abc offset 4
Syntax: match rule-name rewrite request-insert {[ASCII-string [neg-offset decimal | offset
decimal]] | client-ip | header}
The ASCII-string variable specifies the value of the string for the offset options, listed below, in the
insert request.
The neg-offset parameter specifies the negative offset option for the insert request as the value
specified in the decimal variable.
The offset parameter specifies the positive offset option for the insert request as the value
specified in the decimal variable.
The client-ip parameter specifies the client IP option for the insert request.
NOTE
The value of the client-ip must be defined under the VIP command.
The header parameter specifies the header option for the insert request.
NOTE
The value of the header must be defined under the VIP command.
rewrite request-replace
Use this option in the CSW policy configuration mode to replace content, as shown in the following.
Virtual ADX(config-csw-mypolicy)#match r11 rewrite request-replace matched-string
Syntax: match rule-name rewrite request-replace {matched-string ASCII string | string
ASCIIstring-old ASCIIstring-new}
The matched-string parameter specifies the matched-string option for the request to replace a
string defined by a rule that is specified by the ASCII string variable.
The string parameter specifies that a string defined by the ASCIIstring-old variable must be
replaced by a string of the ASCIIstring-new variable.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
303
5
304
Command reference
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Chapters the
Hot Standby High Availability
6
Overview
This chapter describes the Hot Standby high availability (HA) feature for the Brocade Virtual ADX. In
Hot Standby HA, two Brocade Virtual ADX devices must be in a network that you configure to serve
as a redundant pair (primary and secondary). One Brocade Virtual ADX is always active while the
other Brocade Virtual ADX is always standby (idle).
If the active Brocade Virtual ADX fails, the idle standby Brocade Virtual ADX assumes the active
duties and becomes the new active device. The active and standby Brocade Virtual ADX devices
remain in their states until one of the following events forces a change in their status:
• An increase or decrease in the count of the router ports plus the server ports on each Brocade
Virtual ADX. The Brocade Virtual ADX with the highest number of active ports is declared the
active device.
• Failure of any BP or MP forcing the Brocade Virtual ADX to reload.
• A reload.
For more information on the failover behavior of Hot-standby HA, refer to the “Hot Standby HA
protocol operations” section.
NOTE
The Hot Standby HA feature is supported for IPV4 and IPv6.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
305
6
Overview
Hot Standby HA protocol operations
Figure 35 illustrates a typical Hot Standby HA configuration.
FIGURE 35
Typical Hot Standby HA
When Brocade Virtual ADX-A initializes in a Hot Standby HA configuration, it is in the standby state.
When it sends Hello messages and no other Brocade Virtual ADX responds to these messages,
Brocade Virtual ADX-A sets itself to the active state. When Brocade Virtual ADX-B initializes, it also
goes through Hello-message processing. When Brocade Virtual ADX-B sends Hello messages,
Brocade Virtual ADX-A responds with an Active status. When Brocade Virtual ADX-B receives this
status, it assumes the Standby status. Then Brocade Virtual ADX-A in the active state performs the
following four stages of synchronization:
•
•
•
•
306
Port map synchronization
MAC table synchronization
Server information synchronization
Session synchronization
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Hot Standby HA configuration modes
6
When the entire synchronization process is completed, Brocade Virtual ADX-B calculates Brocade
Virtual ADX-A router-port plus server-port count.
• If the Brocade Virtual ADX-A count is greater than or equal to Brocade Virtual ADX-B, Brocade
Virtual ADX-A remains in the active state and Brocade Virtual ADX-B remains in the standby
state.
• If Brocade Virtual ADX-A has a lower count of the router port plus the server port, Brocade
Virtual ADX-B forces Brocade Virtual ADX-A to the standby state, and Brocade Virtual ADX-B
sets itself to the active state.
To avoid a loop, the standby Brocade Virtual ADX becomes a dumb device. It is completely isolated
and does not process any SLB traffic. However, while the standby Brocade Virtual ADX is idle, it
performs the following functions:
• Continuously listens to the active Brocade Virtual ADX for failover preparation and receives
session-sync messages from the active Brocade Virtual ADX. The moment a session is created
on the active Brocade Virtual ADX, the active Brocade Virtual ADX synchronizes its session
table on the BPs to match the BPs on the standby Brocade Virtual ADX. Synchronization of a
session involves session creation, session deletion, and age updates. No CLI commands are
required to invoke session synchronization from the active Brocade Virtual ADX to the standby
Brocade Virtual ADX.
• Performs health checks. The active and standby Brocade Virtual ADX devices perform Layer 2,
Layer 3, Layer 4, and Layer 7 health checks independently.
• Processes Hello messages.
If the active Brocade Virtual ADX fails, the standby Brocade Virtual ADX becomes active and
immediately takes over the processing of the SLB traffic. Because the sessions were already
synchronized from the previously-active Brocade Virtual ADX, failover is transparent to users.
Hot Standby HA configuration modes
Hot-Standby HA can be configured in two different modes as follows:
• Non-Promiscuous mode with default non-shared MAC option
• Promiscuous mode with shared MAC option
Non-Promiscuous mode with default non-shared MAC option
By default, the virtual switch is set to non-promiscuous mode. To perform seamless failover in this
mode, the new active Brocade Virtual ADX sends gratuitous ARPs with its interface MAC addresses
to the adjacent switches or hosts, immediately after a fail over.
In this case, if gratuitous ARPs can be honored by the next hop router or directly connected hosts,
enable the non-promiscuous mode (if not enabled by default) on the receiving data ports.
In the Brocade Virtual ADX CLI, you need not configure optional keyword shared-mac in the server
backup ethernet port vlan-id vlan MAC command.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
307
6
Hot Standby HA Configuration Considerations
Promiscuous mode with shared MAC option
When a server does not honor gratuitous ARP, the virtual switch in the ESX hypervisor needs to be
set to promiscuous mode.
This mode is known to the Brocade Virtual ADX based on an optional keyword configured in the
server backup ethernet port vlan-id vlan MAC [shared-mac] command, where MAC is normally one
of the HA sync port MAC out of the two Brocade Virtual ADXs. The new optional keyword
shared-mac indicates if promiscuous mode is “ON”.
Hot Standby HA Configuration Considerations
When configuring Hot Standby HA, consider the following:
• If only one device is present and the Hot Standby HA feature is enabled, the Brocade Virtual
ADX will function in "single-box" mode until the second Brocade Virtual ADX becomes available.
• There are two versions of Hot Standby HA:
• Standard Hot Standby HA - The Brocade Virtual ADX management IP, VIPs, and real servers
are all in the same subnet.
• Source-IP/src-standby-ip Hot Standby HA - The Brocade Virtual ADX management IP and
VIPs are in one subnet. Real servers are in a different subnet. Additional commands are
required for this version.
Configuring standard Hot Standby HA
Figure 36 shows the minimum required configuration for Standard Hot Standby HA.
FIGURE 36
Minimum required configuration for Standard Hot Standby HA
Perform the following steps to enable this configuration.
1. On Brocade Virtual ADX A, place the untagged Hot Standby HA port (sync-link) in its own
port-specific VLAN:
Virtual ADX-A(config)#vlan 999 by port
Virtual ADX-A(config-vlan-999)# untagged ethe 3
Placing the Hot Standby HA port in its own VLAN prevents unnecessary traffic from going over
the backup (sync) link.
308
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Configuring standard Hot Standby HA
6
NOTE
You must use a dedicated port for the HA sync link.
2. Configure the server backup port, shared MAC address between the Brocade Virtual ADX
devices, and any connected router ports:
Virtual ADX-A(config)#server backup ethe 3 000c.290d.e85f vlan-id 999
Virtual ADX-A(config)#server router-ports ethernet 1
Syntax: server backup ethernet portnum mac-addr vlan-id [shared-mac]
The server backup ethernet command must be configured exactly the same on both Brocade
Virtual ADX devices. It has four parameters.
The portnum variable specifies the port where the syn-link is connected. This port connects
this Brocade Virtual ADX to its counterpart. In the example, 3 is the port number.
The mac-addr variable specifies the sync-link interface MAC address of one of the Brocade
Virtual ADX devices. Refer to the show interfaces brief command. This address must be the
same on both Brocade Virtual ADX devices.
The vlan-id variable specifies a VLAN that you want to use. In this example, the sync-link Hot
Standby HA port is in VLAN 999.
The shared-mac option must be set if the virtual switch is in promiscuous mode. For more
information on non-promiscuous and promiscuous modes, refer to the “Hot Standby HA
configuration modes” on page 307.
The server router-ports command enables the Brocade Virtual ADX to count the number of
upstream (or downstream) router ports connected to the ADX. Both Brocade Virtual ADX
devices must use the same router-ports numbers, such as 1 in this example. The reason is the
standby Brocade Virtual ADX is a dummy device that learns nothing, such as MACs, on its own.
3. Save the configuration.
Virtual ADX-A #write memory
.Write startup-config in progress.
.Write startup-config done.
Virtual ADX-A#reload
NOTE
Be sure to reload the software after configuring or changing the server backup command. If
you change the port number of the backup while the Brocade Virtual ADX is load balancing,
clients will not be able to ping the VIP.
4. Configure the second Brocade Virtual ADX (Brocade Virtual ADX-B). On this system, port 3 is
the Hot Standby HA port. Using the same port numbers and MAC address is a requirement.
Notice the MAC address on each Brocade Virtual ADX matches.
Virtual ADX-B(config)#server backup ethe 3 000c.290d.e85f vlan-id 999
Virtual ADX-B(config)#server router-ports ethernet 1
Virtual ADX-B(config)#vlan 999 by port
Virtual ADX-B(config-vlan-999)#untagged ethe 3
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
309
6
Configuring standard Hot Standby HA
Virtual ADX-B#write memory
.Write startup-config in progress.
.Write startup-config done.
Virtual ADX-B#reload
5. Use show server backup and show log to obtain the Brocade Virtual ADX status in the Hot
Standby HA configuration.
The following screen shots display the different stages of reload and show how a Brocade Virtual
ADX comes up in a Hot Standby HA configuration.
Virtual ADX-A#show server backup
Server Backup port = 3 <----------- Sync-link port on this Brocade Virtual ADX
Backup group id = 0
Switch state = Standby
SLB state = 1 <-------------------- Start of the SLB sync. Five stages: 0>1>2>3>4>0
Share MAC = Off <------------------ Indicates whether promiscuous mode is configured.
Peer sync state = 0
SLB Partner MAC valid= 0 <------------- 0 indicates the MAC below is not valid
SLB Partner MAC = 0000.0000.0000 <----- Peer Brocade Virtual ADX MAC
SLB Partner HA sync port MAC = 0000.0000.0000
SLB Partner VLAN ID = 999 <--------- VLAN used to perform heartbeat between Brocade Virtual ADX
SLB Partner port cnt = 0
SLB Backup preference = 0 minutes
SLB Backup timer = 1000 milliseconds
Active attempts = 0
Transitions, activates =
0, standby
=
0
Pdus sent
=
0, Pdus recv
=
0
Null Pdus sent
=
0, Mac pdu sent
=
0
No pdus
=
0, no port maps
=
0
Routers ports
=
0, Partner Routers ports
=
0
Server ports
=
0, Partner Server ports=
0
My Cost = 9, Peer Cost = 10
Brocade Virtual ADX A is running in single-box mode, because Brocade Virtual ADX B is not yet
discovered.
Virtual ADX-A#show server backup
Server Backup port = 3
Backup group id = 0
Switch state = Active <------------ Assumes Active since no peer was detected by sending null PDUs
SLB state = 0<-------------------- State returns to 0
Share MAC = Off
Peer sync state = 0
SLB Partner MAC valid= 0
SLB Partner MAC = 0000.0000.0000<-- Still did not find peer and entry remains all zeros
SLB Partner HA sync port MAC = 0000.0000.0000
SLB Partner VLAN ID = 999
SLB Partner port cnt = 255
SLB Backup preference = 0 minutes
SLB Backup timer = 1000 milliseconds
Active attempts = 0
Transitions, activates =
0, standby
=
0
Pdus sent
=
0, Pdus recv
=
0
Null Pdus sent
=
215, Mac pdu sent
=
0
No pdus
=
0, no port maps
=
0
Routers ports
=
0, Partner Routers ports
=
0
Server ports
=
1, Partner Server ports
=
0
My Cost = 9, Peer Cost = 10
310
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Configuring standard Hot Standby HA
6
Now Brocade Virtual ADX B comes up with Brocade Virtual ADX A already up and running.
Virtual ADX-B#show server backup
Server Backup port = 3
Backup group id = 0
Switch state = Standby
SLB state = 0<------------------------- Goes from 0>1>2>3>4>0
Share MAC = Off
Peer sync state = 0
SLB Partner MAC valid= 0
SLB Partner MAC = 000c.290d.e85f <----- Peer MAC appears when SLB state returns to 0
SLB Partner HA sync port MAC = 000c.290d.e88c
SLB Partner VLAN ID = 999
SLB Partner port cnt = 255
SLB Backup preference = 0 minutes
SLB Backup timer = 1000 milliseconds
Active attempts = 0
Transitions, activates =
0, standby
=
0
Pdus sent
=
0, Pdus recv
=
133<-- From
Null Pdus sent
=
244, Mac pdu sent
=
0
Virtual ADX-A
No pdus
=
0, no port maps
=
0
Routers ports
=
1, Partner Routers ports
=
0
Server ports
=
1, Partner Server ports
=
0
My Cost = 9, Peer Cost = 10
Table 35 describes the information displayed by the show server backup command.
TABLE 35
Field descriptions for show server backup command
Field
Description
Switch state
Indicates whether this Brocade Virtual ADX is the active or the standby Brocade Virtual
ADX. The state can be one of the following:
• Active
• Standby
SLB state
When a Brocade Virtual ADX comes up in the Hot Standby HA configuration, it requests
the following information from the peer Brocade Virtual ADX:
• Port map information
• MAC information
• Server mapping information
• Session information (Fail-over session sync)
After this processing is completed, the Brocade Virtual ADX goes to the "SLB
synchronization complete" state.
This field displays one of the following states during the request for peer information:
• SLB_SYNC_COMPLETE state (Value = 0). All synchronization requests from the local
Brocade Virtual ADX have been sent to the peer Brocade Virtual ADX. This process is
now complete (value = 0).
• SLB_SYNC_REQ_MAP state (Value = 1). Denotes the local Brocade Virtual ADX is
requesting the peer Brocade Virtual ADX for port map information.
• SLB_SYNC_REQ_MAC state (Value = 2). Denotes the local Brocade Virtual ADX is
requesting the peer Brocade Virtual ADX for MAC information.
• SLB_SYNC_REQ_SERVERS state (Value = 3). Denotes the local Brocade Virtual ADX
is requesting the peer Brocade Virtual ADX for Server mapping.
• SLB_SYNC_REQ_L4 state (Value = 4). Denotes the local Brocade Virtual ADX is
requesting the peer Brocade Virtual ADX for session synchronization (fail-over
session sync).
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
311
6
Additional configuration variations
TABLE 35
Field descriptions for show server backup command (Continued)
Field
Description
Share MAC
Indicates whether the shared-mac option through the server backup command is set. The
state is one of the following:
• Off indicates that the virtual switch is set to non-promiscuous mode.
• On indicates that the virtual switch is set to promiscuous mode.
SLB Partner MAC
valid
Indicates whether the SLB partner MAC address listed in the SLB Partner MAC field is
valid. The value can be one of the following:
• 0 – invalid
• 1 – valid
SLB Partner MAC
The MAC address on the other Brocade Virtual ADX, indicating Layer 2 connectivity
between the Brocade Virtual ADX devices. If this field contains all zeros, double-check the
connection between the Brocade Virtual ADXs and verify that both Brocade Virtual ADX
devices are powered on.
SLB Partner HA sync
port MAC
Displays the MAC address of the partner HA interface.
SLB Partner port cnt
The number of ports on the other Brocade Virtual ADX.
Transitions, activates
The number of times this Brocade Virtual ADX has changed from standby to active.
Transitions, standby
The number of times this Brocade Virtual ADX has changed from active to standby.
Pdus sent
The number of Layer 4 synchronization packets this Brocade Virtual ADX has sent to the
other Brocade Virtual ADX.
Mac pdu sent
The number of MAC-layer synchronization packets this Brocade Virtual ADX has sent to
the other Brocade Virtual ADX.
No pdus
The number of missed Layer 4 or MAC-layer PDUs.
no port maps
The number of missed port map PDUs. Port map PDUs are used by the Brocade Virtual
ADX to discover information about the maps on the other Brocade Virtual ADX.
Additional configuration variations
This section provides the following configuration variations:
• “VIP and servers in different subnets”
• “Source-NAT in Hot Standby”
VIP and servers in different subnets
If VIP and servers are in different subnets, configure a standby IP address under the interface or
virtual Ethernet interface that is configured in the same subnet as the servers. The same
standby-ip must be configured on both the Brocade Virtual ADX. On the servers, use this standby-ip
as the default gateway.
Syntax: [no] standby-ip ip-add {ip-mask | prefix length} default-gateway
312
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Additional configuration variations
6
Figure 37 shows a configuration with the VIP and servers in different subnets.
FIGURE 37
VIP and servers in different subnets
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
313
6
Configuring additional HA parameters
Source-NAT in Hot Standby
Figure 38 shows a configuration for seamless failover in Hot Standby when Source-NAT is enabled.
FIGURE 38
Seamless failover in Hot Standby HA when Source-NAT is enabled
Configuring additional HA parameters
This section provides additional configuration parameters for Hot Standby HA:
•
•
•
•
•
•
•
314
“Configuring a backup group ID”
“Setting the backup timer”
“Enabling backup preference”
“Configuring failover based on active VIP count”
“Configuring failover based on the number of active virtual ports”
“Delayed failover”
“Configuring a Brocade Virtual ADX to remain in standby state”
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Configuring additional HA parameters
6
Configuring a backup group ID
Hot Standby HA redundancy enables a Brocade Virtual ADX to serve as an automatic backup for
another Brocade Virtual ADX. Each Hot Standby HA pair consists of two Brocade Virtual ADX
devices. You can configure up to 127 Hot Standby HA pairs within a single L2 broadcast domain. To
enable this support, configure a backup group ID on each of the Brocade Virtual ADX devices. Both
Brocade Virtual ADX devices in a given pair have the same ID. The ID uniquely identifies the pair.
When you configure a backup group ID, both Brocade Virtual ADX devices in a Hot Standby HA pair
use the ID when exchanging backup information. If a Brocade Virtual ADX receives a backup
information packet, but the packet’s backup group ID does not match the Brocade Virtual ADX’s
backup group ID, the Brocade Virtual ADX discards the packet.
If the broadcast domain contains multiple Hot Standby HA pairs, you must configure backup group
IDs on all pairs. If the broadcast domain contains only one Hot Standby HA pair, you do not need to
configure a backup group ID.
To configure a backup group ID, enter the following command.
Virtual ADX(config)#server backup-group 1
Syntax: [no] server backup-group id
The id variable specifies the backup group ID. Enter a number from 1 to 7. The default value is 0.
Enter the same ID on both Brocade Virtual ADX devices in a Hot Standby HA pair. Do not enter the
same ID on a Brocade Virtual ADX that is not one of the Brocade Virtual ADX devices in the Hot
Standby HA pair. This feature is turned on by default.
Use the show server backup command in a Hot Standby HA topology to display the backup ID
information. If there is a group-ID mismatch, both Brocade Virtual ADX devices become active
(instead of one standby and one active).
Setting the backup timer
The standby Brocade Virtual ADX assumes the active role if the it does not receive a Hello message
or Layer 4 session synchronization data from the active Brocade Virtual ADX within a certain
number of seconds since having received the last Hello message or synchronization data.
By default, the standby Brocade Virtual ADX waits one second since having received the last Hello
message or data to receive a new message or data. If the standby Brocade Virtual ADX does not
receive a new Hello message or data within one second, the standby Brocade Virtual ADX assumes
that the active Brocade Virtual ADX is no longer available and takes over the active role.
In some configurations, particularly those in which the active Brocade Virtual ADX is performing a
lot of processing, it is possible for frequent failovers to occur. In this situation, although the active
Brocade Virtual ADX is still available and actively serving load balancing or other requests, the
active Brocade Virtual ADX does not always send the Hello message or synchronization data in time
for the standby Brocade Virtual ADX. As a result, the standby Brocade Virtual ADX takes over the
active role. If similar conditions cause the newly active Brocade Virtual ADX to sometimes miss
sending the Hello messages or synchronization data in time, failover occurs again.
You can prevent unnecessary state flapping between the two Brocade Virtual ADXs by increasing
the backup timer. When you increase the backup timer, the standby Brocade Virtual ADX waits
longer to receive new Hello messages or synchronization data from the active Brocade Virtual ADX.
As a result, flapping is reduced or eliminated.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
315
6
Configuring additional HA parameters
NOTE
The backup timer must have the same value on both Brocade Virtual ADX devices in the HA pair.
To set the backup timer on a Brocade Virtual ADX in an HA pair, enter the following command.
Virtual ADX(config)#server backup-timer 50
This command sets the backup timer to 5 seconds (50 * 100 milliseconds).
Syntax: [no] server backup-timer time
The time variable specifies how long the Brocade Virtual ADX, when it is the backup Brocade Virtual
ADX, will wait for a Hello message or synchronization data from the active Brocade Virtual ADX
before assuming the active Brocade Virtual ADX is no longer available. You can specify a value from
5 (one half second) through 100 (10 seconds), in units of 100 milliseconds each. The default is 10
(one second).
Enabling backup preference
You can configure one of the Brocade Virtual ADX devices in the HA pair to always be the active
Brocade Virtual ADX. When you enable server backup-preference on one of the Brocade Virtual ADX
devices, that Brocade Virtual ADX is always active by default. The only event that can cause the
other Brocade Virtual ADX to be active is unavailability of the default active Brocade Virtual ADX or
its link to the backup Brocade Virtual ADX. To allow graceful insertion, the Brocade Virtual ADX does
not immediately assume the active role, but instead waits for a configurable number of minutes
before taking the active role.
To enable server backup preference, enter the following command.
Virtual ADX(config)#server backup-preference 5
Syntax: [no] server backup-preference wait-time
The wait-time variable specifies how long the Brocade Virtual ADX waits before assuming the active
role. The Brocade Virtual ADX does not immediately become the active Brocade Virtual ADX but
instead waits the number of minutes you specify. You can specify from 5 through 30 minutes. This
variable does not have a default.
Configuring failover based on active VIP count
By default, the HA peer failover is based on router ports and server ports. You can configure the HA
peer to fail over based on router ports and active VIP counts instead of just the router ports. When
this type of failover is configured, the following occurs:
• If neither of the two nodes in the peer has any router ports, the one having more active-VIPs
will be the active node; no status change if the active-VIPs also tie.
• If one node has no router ports, but another has at least one router port, the latter will be the
active node.
• If both nodes have at least one router port, the one having more active-VIPs will be the active
node. If active-VIPs tie, the node with more router ports will be the active node. There is no
status change if both active-VIPS and router ports tie.
316
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Configuring additional HA parameters
6
To enable this feature, enter the following command.
Virtual ADX(config)#server backup-vip-cnt
Syntax: [no] server backup-vip-count
Configuring failover based on the number of active virtual ports
You can configure the HA peer to fail over based on router ports and active virtual ports, instead of
just the router ports (default) or the combination of router ports and virtual servers as described in
“Configuring failover based on active VIP count”. When a failover is configured to be based on the
number of active virtual ports, the following occurs:
• If neither of the two nodes in the peer has any router ports, the one having more active
VIP/VPORT counts will be the active node; no status change if the number active VIP/VPORT
counts ties.
• If one node has no router ports, but another has at least one router port, the latter will be the
active node.
• If both nodes have at least one router port, the one having more active VIP/VPORT counts will
be the active node. If the number of active VIP/VPORT counts tie, the node with more router
ports will be the active node. There is no status change if the number of both active virtual
ports and router ports tie.
To enable this feature, enter the following command.
Virtual ADX(config)#server backup-vport-cnt
Syntax: [no] server backup-vport-cnt
This feature can be configured with or without the server backup-vip-cnt command as described:
• If the server backup-vip-cnt command is not configured, only the number of active virtual ports
is compared. The node with more active virtual ports will be considered to have more
VIP/VPORT counts, and a tie is called if they have an equal number of active virtual ports.
• If both the server backup-vip-cnt and server backup-vport-cnt commands are configured, the
number of active virtual ports will have a higher precedence than the number of active virtual
servers. Consequently, the node with a larger number of virtual ports will always be considered
as having a higher VIP/VPORT count and in the case of a tie on the active virtual port count,
the node with a larger number of active virtual servers will be considered as having a higher
VIP/VPORT count. A tie condition occurs where both nodes have an equal number of both
virtual servers and virtual ports.
NOTE
The server backup-vport-cnt command must be configured on both Brocade Virtual ADX devices in
the pair. To avoid an unnecessary failover during configuration, we suggest that you enable this
feature on the active ADX device first. Also, the feature should be disabled on the standby ADX
device first.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
317
6
Configuring additional HA parameters
Delayed failover
With this feature configured, when a Brocade Virtual ADX device detects a failover condition
because of a VIP/VPORT count change, the failover will be delayed. At the end of the period of
delay, the Brocade Virtual ADX device examines the conditions that led to the failover condition and
performs a failover if the conditions still apply. If they no longer apply, the failover will be cancelled.
To enable this feature, enter the following command.
Virtual ADX(config)#server backup-delay-seconds 20
Syntax: [no] server backup-delay-seconds backup-wait-seconds
The backup-wait-seconds variable specifies the number of seconds that the Brocade Virtual ADX
will wait before performing a failover. Values can be specified from 0 through 1200 seconds.
Specifying 0 disables this feature and causes failover to occur immediately without any delay.
This feature applies only when configuring the server backup-vip-cnt or server backup-vport-cnt
commands.
NOTE
The server backup-delay-seconds backup-wait-seconds command must be configured on both
Brocade Virtual ADX devices in the active/standby pair.
Configuring a Brocade Virtual ADX to remain in standby state
This feature ensures that a Brocade Virtual ADX always remains in the standby state, regardless of
any changes in the system parameters (such as no heart beat, fewer router ports, and other
changes). Use this feature when there is undesirable flapping between active and standby states,
which can occur when the CPU utilization on the standby Management Processor is very high and
causes the standby Brocade Virtual ADX to drop the heart beat messages sent by the active
Brocade Virtual ADX.
To force a Brocade Virtual ADX to remain in the standby state, enter the remain-standby command.
Virtual ADX(config)#server backup-remain-standby
Syntax: server backup-remain-standby
NOTE
Use the remain-standby command with caution because both Brocade Virtual ADX devices can
become standbys; thereby creating traffic loss.
If the Brocade Virtual ADX is active when this command is configured, the Brocade Virtual ADX
transitions to the standby state and remains as the standby until the command is removed. The
transition is logged as "Forced to turn standby.”
After you enter the remain-standby command, every attempt by the Brocade Virtual ADX to go into
the active state is recorded and suppressed. This information is available under the "Active
attempts" field in the show server debug command.
318
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Configuring the forwarding of synchronizing messages
6
Configuring the forwarding of synchronizing messages
In a Hot Standby HA configuration, the active Brocade Virtual ADX and the backup Brocade Virtual
ADX continuously communicate through synchronizing messages. These messages contain Layer 4
–Layer 7 session status information and are only used by the Brocade Virtual ADX devices.
Some of the messages can travel over a non-dedicated private link between the two Brocade
Virtual ADX devices. Another Brocade Virtual ADX can be in the middle of this link, acting as a Layer
2 or Layer 3 Switch passing traffic between the active and backup Brocade Virtual ADX devices.
In this situation, messages sent between the active and backup Brocade Virtual ADX devices can
be intercepted and dropped by the Brocade Virtual ADX in the middle, and not forwarded to the
active or backup Brocade Virtual ADX devices. This could cause loss of synch between the active
and backup Brocade Virtual ADX devices. To prevent this from happening, use the server
fwd-l4-sync command to configure the Brocade Virtual ADX in the middle to simply forward the
synching messages and not intercept them.
To configure the Brocade Virtual ADX in the middle to forward the synchronizing messages, enter
the following command on the Brocade Virtual ADX connecting the active and the backup Brocade
Virtual ADX devices.
Virtual ADX(config)#server fwd-l4-sync
Syntax: server fwd-l4-sync
Configuring synchronization with HA
You can use the config-sync command line utility to synchronize an SLB configuration from the
active Brocade Virtual ADX to the standby Brocade Virtual ADX. For information about the
config-sync command, refer to the "Initiating the Synchronization" section of the "Brocade Virtual
ADX System Management" chapter in the Brocade Virtual ADX Administration Guide.
Hot-standby HA with routing protocols
When the upstream and the downstream routers are on the different VLANs, the routing protocols
like OSPF and BGP should be up and running on both active and standby devices in addition to
static routes. Brocade Virtual ADX learns the routes advertised by the routing protocol as well as
the static routes configured. As soon as a device becomes active, the new active starts allowing the
packets for forwarding. In contrast, though the same learnt and configured routes are present on
the standby device, it does not forward the packets.
With the routing protocols configured, both active and standby devices advertise the routes to the
upstream and downstream routers, including the VIP RHI routes. However Brocade Virtual ADX
automatically adjusts the cost of the advertised routes without any additional configuration,
ensuring that the traffic is always targeted to the active device. This cost alteration by the system is
not be reflected in the running configuration of the Brocade Virtual ADX.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
319
6
Hot-standby HA with routing protocols
NOTE
Manual alteration of the cost or the metric of the routing protocols can affect the traffic forwarding
by the HA pair. For internal BGP (IBGP), you need to enable the compare-med-empty-aspath flag on
the upstream and downstream router for cost and MED to be considered for route selection. The
BGP RFC defines all vendor support.
FIGURE 39
320
HA using routing protocol- Sample network topology
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Hot-standby HA with routing protocols
6
Tie state of virtual link and HA physical link using health checks
The Brocade Virtual ADX virtual interface is unaware of the state of the physical interface and this
result is an inconsistent port state. In HA scenarios, failover cannot be triggered even if the
associated physical interface is down. Hence, the virtual interface state is tied with that of the
physical interface. The existing ICMP Boolean health checks are deployed in these scenarios as
follows:
Virtual ADX(config)#healthck c1 icmp
Virtual ADX(config-hc-c1)#dest-ip 3.3.3.1
Virtual ADX(config)#healthck c2 icmp
Virtual ADX(config-hc-c2)#dest-ip 3.3.3.2
Virtual ADX(config)#healthck c3 boolean
Virtual ADX(config-hc-c3)#or c1 c2
The healthck command is introduced in server router-port command to tie the health checks as
follows:
Virtual ADX(config)#server router-port e 1
healthck c3
NOTE
In a Hot-Standby HA configuration, the server port interface is connected to the external device using
the virtual switch. If the port on the external device is down, the Brocade Virtual ADX does not detect
it because of the presence of the virtual switch in between. The result is that the status of the
server-port is not be marked as down. To overcome this drawback, you can configure the server
backup-vip-cnt or server backup-vport-cnt command while running Hot-Standby HA to perform
failover based on a real-server health check failure.
For more information on configuring OSPF, refer to the Brocade Virtual ADX Switch and Route
Guide.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
321
6
322
Hot-standby HA with routing protocols
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Chapter
SIP Server Load Balancing
7
SIP overview
The Session Initiation Protocol (SIP) is a signaling protocol used by numerous IP communication
products to create session-oriented connections between two or more endpoints in an IP network.
SIP is emerging as the preferred technology for Voice over IP (VoIP) implementations.
Application-aware network switches play a vital role in increasing the uptime and availability of
IP-based services such as VoIP. Many customers rely on this technology to meet mission-critical
application requirements. Together with advanced SIP intelligence, Virtual ADX switches offer a
highly scalable, available, and secure load balancing infrastructure for SIP applications.
SIP is an application-layer protocol that can establish, modify, and terminate multimedia sessions,
such as Internet telephony. In this implementation, Virtual ADX SIP server load balancing balances
SIP requests and responses, based on a Call-ID.
SIP Server Load Balancing is based on a request-and-response transaction model that is similar to
HTTP. Each transaction consists of a request that invokes a particular method on the server, and at
least one response. The method is carried within the request message.
For more information, see SIP: Session Initiation Protocol - RFC 3261.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
323
7
SIP overview
SIP packet flow
Figure 40 demonstrates the basic operation of SIP; location of an endpoint, signal of a desire to
communicate, negotiation of session parameters to establish the session, and tear-down of the
session after completion.
FIGURE 40
SIP packet flow
The example in Figure 40 shows packet exchange between two SIP clients, also known as User
Agent Clients (UACs). In the figure each message is labeled with the letter "F" and a number for
reference. The session established between the two end-clients is facilitated by the SIP proxy
server. User1 "calls" User2 using a SIP identity, a type of Uniform Resource Identifier (URI) called a
SIP URI. The SIP URI is similar to an e-mail address, typically containing a username and a host
name. In this case, it is sip:[email protected], where brocade.com is the domain of User1's SIP
service provider.
324
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
SIP overview
7
SIP is based on an HTTP-like request-and-response transaction model. Each transaction consists of
a request that invokes a particular method, or function, on the server, and at least one response. In
this example, the transaction begins with User1's SIP phone sending an INVITE request addressed
to User2's SIP URI. The INVITE request contains a number of header fields. The fields present in an
INVITE request include a unique identifier for the call (Call-ID), the destination address, User1's
address, and information about the type of session that User1 wishes to establish with User2. The
INVITE (message F1 in Figure 40) would look like the following example:
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP pcuser1.brocade.com;branch=dkDKdkDKdkDK1111
Max-Forwards: 50
To: User2 <sip:[email protected]>
From: User1 <sip:[email protected]>;tag=1122334455
Call-ID: [email protected]
CSeq: 123456 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 142
Because User1's SIP phone does not know the location of User2's SIP phone, it sends the INVITE
message to the SIP proxy server that is serving the brocade.com domain. The address of the
brocade.com proxy server is known to the SIP phone through static configuration or through
Dynamic Host Configuration Protocol (DHCP). The proxy server receives the INVITE request and
sends a 100 (Trying) response back to User1's SIP phone. This response contains the same To,
From, Call-ID, CSeq, and branch parameter in the Via field as the INVITE, which allows User1's SIP
phone to correlate this response to the previously sent INVITE. The proxy server consults a
database, generally called a location service, that contains the current IP address of User2. It then
forwards (or proxies) the INVITE request there. Before forwarding the request, the proxy server adds
an additional Via header field value with its own address (the INVITE already contains User1's
address in the first Via field).
User2's SIP phone receives the INVITE and alerts User2 of the incoming call from User1; that is,
User2's phone rings. User2's SIP phone indicates this by a 180 (Ringing) response, which is routed
back through the SIP proxy server in the reverse direction. When User1's SIP phone receives the
180 (Ringing) response, it passes this information to User1, using an audio ringback tone.
If User2 decides to answer the call (User2 picks up the handset), the SIP phone sends a 200 OK
response to indicate that the call has been answered. The 200 OK contains the Via, To, From,
Call-ID, and CSeq header fields that are copied from the INVITE request, and a message body with
the Session Description Protocol (SDP) media description of the type of session that User2 is willing
to establish with User1. The 200 OK (message F6 in Figure 40) would look like the following
example.
SIP/2.0 200 OK
Via: SIP/2.0/UDP pcproxy.brocade.com
;branch= dkDKdkDKdkDK2222;received=10.1.1.2
Via: SIP/2.0/UDP pcuser1.brocade.com
;branch= dkDKdkDKdkDK1111;received=10.1.1.1
To: User2 <sip:[email protected]>;tag=dkdkdk1
From: User1 <sip:[email protected]>;tag=1122334455
Call-ID: [email protected]
CSeq: 123456 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 131
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
325
7
SIP overview
The 200 OK message is routed back through the SIP proxy server to the User1's SIP phone, which
then stops the ringback tone and indicates that the call has been answered. Finally, User1's SIP
phone sends an acknowledgement (ACK) message to User2's SIP phone to confirm the reception of
the final response (200 OK). This ACK is sent directly from User1's SIP phone to User2's SIP phone,
bypassing the SIP proxy server. This occurs because the endpoints have now learned each other's
IP addresses from the Contact header fields through the INVITE/200 OK exchange, which was not
known when the initial INVITE was sent. This completes the INVITE/200/ACK three-way handshake
used to establish SIP sessions.
The media exchange between User1 and User2 now begins using the format that they have agreed
upon through SDP. In general, the end-to-end media packets take a different path from the SIP
signaling messages. At the end of the call, User2 disconnects (hangs up) the phone and generates
a BYE message. This BYE is routed directly to User1's SIP phone, again bypassing the SIP proxy.
User1 confirms the session termination with a 200 OK response.
SIP client registration
Registration is another common SIP operation. Registration is the means through which the SIP
domain's registrar server learns the current location of SIP clients (UACs). Upon initialization, and at
periodic intervals, the SIP clients send REGISTER messages to the domain's SIP registrar server.
The REGISTER messages associate an individual SIP URI (sip:[email protected]) with the IP
address of the machine which the user is currently logged on. The registrar server writes this
association to a database, called the location service, where it can be used by the SIP proxy server
of the domain. Often, a registrar server and the location service for a domain are co-located with
the proxy server for that domain.
SIP terminology
This section describes terms and concepts that you might find useful when configuring SIP SLB.
• Request-URI: Every SIP user has a URI. One SIP user calls another by setting the SIP URI of the
latter in the request message, also called the request-URI, which appears before all message
headers.
• UAC: A User Agent Client (UAC) is a logical entity that creates a new request. The role of UAC
lasts only for the duration of the transaction.
• UAS: A User Agent Server (UAS) is a logical entity that generates a response to a SIP request.
The response accepts, rejects, or redirects the request.
• Proxy server: A proxy server is an intermediary entity that acts as both a server and a client for
the purpose of making requests on behalf of other clients. A proxy server is primarily a router,
which means its job is to ensure that a request is sent to another entity nearer to the targeted
user. A proxy interprets and, if necessary, rewrites specific parts of a request message before
forwarding it.
• Redirect server: A redirect server is a UAS that generates 3xx responses to requests it receives,
directing the client to contact an alternate set of URIs.
• Registrar server: A registrar server accepts REGISTER requests and places the information it
receives in those requests into the location service for the domain it handles.
326
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
SIP overview
7
SIP message headers
This section describes SIP message headers that you might find useful when making decisions
about SIP server load balancing.
Call-ID
The Call-ID is a header field that appears in all SIP requests and responses. This header field acts
as a unique identifier to group together all messages belonging to the same call. It must be the
same for all requests and responses sent by either the UAC or UAS in a dialog.
Call-ID is generated by the combination of a random string and the host name or IP address of a
particular UAC. There is no length restriction on Call-ID. In the first implementation, a real server is
selected based on the hash value of Call ID (stateless mode) or the value of Call ID (stateful mode).
• Record-Route: The Record-Route header field is inserted by a proxy in a request to force future
requests in the dialog to be routed through the proxy; for example, Record-Route: <sip:
server10.example1.com; 1r>
• From: The From header field indicates the logical identity of the initiator of the request. It
contains a URI and, optionally, a display name. This field must contain a "tag" parameter,
chosen by the UAC.
IP addresses of the host on which the UAC is running should not be used as FROM URIs, as
these are not logical names.
• To: The To header field specifies the desired logical recipient of the request. This might not be
the ultimate recipient of the request. Normally, the initial To field is set to be the value of the
Request-URI. One exception is the REGISTER method.
• Via: The Via header field indicates the path taken by the request so far and indicates the path
that should be followed in routing responses. A Via header field value contains the transport
protocol used to send the message, the client's host name or network address, and possibly
the port number at which it wishes to receive responses. It is a mandatory field for the UAC or
UAS SIP proxies, and guarantees that the responses traverse through the same route as the
requests.
The branch ID parameter in the Via header field value serves as a transaction identifier, and is
used by proxies to detect loops.
• Max-Forwards: The Max-Forwards header field must be used with any SIP method to limit the
number of proxies or gateways that can forward the request to the next downstream server.
The Max-Forwards value is an integer from 1 through 255 indicating the remaining number of
times that a request message is allowed to be forwarded. The recommended initial value is 70.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
327
7
SIP SLB and call persistence
SIP SLB and call persistence
Figure 41 shows an overview of a Virtual ADX SIP server load balancing implementation.
FIGURE 41
Virtual ADX SIP Server Load Balancing implementation
There are three kinds of SIP servers:
• Proxy server
• Redirect server
• Registrar server
In Figure 41, the Virtual ADX SIP SLB uses the Domain-1 VIP to load balance SIP requests from
Client A (user1) or Client B (user2) among Domain 1 proxy servers and registrar servers.
The SIP Server Load Balancing uses the Domain-2 VIP to load balance SIP requests from Client A
(user1) or Client B (user2) among Domain 2 proxy servers and registrar servers.
The Virtual ADX offers support for the following SIP servers in accordance with RFC 3261:
• Proxy
• Redirect
• Registrar
The Virtual ADX supports the following methods in accordance with RFC 3261:
• INVITE
• REGISTER
• ACK
328
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
SIP SLB and call persistence
7
• CANCEL
• BYE
• OPTIONS
Additionally, the following methods are supported:
• SUBSCRIBE
• NOTIFY
• Other proprietary methods
SIP and call persistence specifications
The SIP server load balancing has the following specifications:
• By default, server selection is persistent on Call-ID.
• Pass-through SIP traffic from real SIP servers to SIP clients gets translated. The Virtual ADX
replaces the source IP (SIP server real IP) with Virtual IP (VIP).
• The Virtual ADX does not modify any of the SIP header fields.
• The Virtual ADX does not perform SIP-aware NAT.
• This implementation is based on RFC 3261.
NOTE
The Virtual ADX SIP SLB is not implemented as a SIP proxy server, but rather as a load balancer of
proxy or registrar traffic.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
329
7
SIP SLB and call persistence
Sample deployment topologies
Virtual ADX switches offer application-aware advanced intelligence for SIP server load balancing.
The following sections describe some SIP server load balancing scenarios.
SIP server load balancing with DSR mode
Figure 42 shows an SIP server farm built around Virtual ADX application switches.
FIGURE 42
SIP server farm with DSR mode
Figure 42 demonstrates a typical use case in which the Virtual ADX application switch provides
Call-ID based server persistence for UDP SIP traffic. The Call-ID attribute that uniquely identifies a
SIP call is used to maintain session persistence. Due to the unique call flow requirements of SIP,
most SIP implementations require you to enable Direct Server Return (DSR) mode on the Virtual
ADX switch.
Because User1's SIP phone does not know the location of User2's SIP phone, it initiates a new SIP
session by sending an INVITE request to the SIP proxy server. It also generates a unique identifier
(Call-ID) for the call. Because the SIP proxy server used by User1's SIP phone is actually the virtual
IP address hosted on the Virtual ADX switch, the Virtual ADX switch receives the INVITE request
and, using a server selection mechanism, identifies the best available SIP server for this INVITE.
The Virtual ADX uses the Call-ID attribute value to select one of the SIP servers in either stateless or
stateful mode. For all SIP transactions within a dialog that use the same Call-ID, the Virtual ADX
selects the same SIP server. A new INVITE message with a different Call-ID is again subjected to
server load balancing and may be forwarded to a different SIP server.
330
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
SIP SLB and call persistence
7
The proxy server receives the INVITE request and sends a 100 (Trying) message to User1's SIP
phone. Because the Virtual ADX switch is configured in DSR mode, the response message that is
sourced from the virtual IP address flows directly to User1's SIP phone, bypassing the Virtual ADX.
The proxy server then consults the location service and forwards the INVITE request directly to
User2's SIP phone, again bypassing the Virtual ADX, and is sourced from the proxy server's own IP
address.
NOTE
The proxy server's IP address must be reachable from all SIP clients.
User2's SIP phone receives the INVITE and alerts User2 of an incoming call. User2 replies with a
Ringing message to the proxy server. If User2 answers the call, a 200 OK message is sent to the
proxy server. The proxy server forwards this message to User1's SIP phone. Upon receiving the 200
OK message, User1's SIP phone sends an acknowledgement (ACK) message directly to User2's SIP
phone, bypassing the proxy server. User1 and User2 SIP phones now begin media exchange and,
upon completion, a BYE message closes the call.
Some SIP servers may be configured to use a virtual IP address (VIP) as the source address for all
communications. Figure 43 shows SIP packet flows in this type of configuration.
FIGURE 43
SIP server farm with DSR mode and SIP server using VIP as source address
In this implementation, the SIP proxy server must use the same Call-ID for both legs of
communication (the same Call-ID for message exchange with both SIP clients within a given SIP
dialog). Session persistence and transaction integrity can only be achieved if the proxy server uses
the same Call-ID.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
331
7
SIP SLB and call persistence
SIP server load balancing with non-DSR mode
Figure 44 shows a SIP server farm with proxy servers connected inline (non-DSR mode) with the
Virtual ADX switch.
FIGURE 44
SIP Server Load Balancing with non-DSR mode
To maintain session persistence and transaction integrity, this implementation has the following
requirements:
• The SIP proxy server should use the same Call-ID for both legs of communication (for example,
for message exchange with both SIP clients within a given SIP dialog).
• For all outbound SIP communications, the proxy server should use the same UDP source port
as that used as the destination port for all inbound communications.
NOTE
If the proxy server uses a source port other than the one used as the destination port for inbound
communications, then the packets arriving from the proxy server go untranslated by the Virtual ADX.
The proxy server IP address must be reachable from all SIP clients in such cases.
332
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Configuring SIP SLB
7
SIP server health monitoring
There are two types of SIP servers of particular importance: SIP proxy servers and SIP registrar
servers. The Virtual ADX supports advanced UDP Layer-7 application health checks for both server
types.
Virtual ADX switches can be enabled to send REGISTER or OPTION messages to SIP servers to track
their health. When an error-free response status (default is 200 OK) is received, then the Virtual
ADX marks the SIP server as being available, and starts assigning new SIP sessions to the available
servers.
The switches can also be configured to send health-monitoring messages at user-defined
frequency and retrial attempts. By default, 200 OK is considered a valid response code. Optionally,
you can configure the switch to accept other response codes that indicate a healthy and available
server.
SIP messages with specific SIP methods are switched to the appropriate SIP server. As an example,
REGISTER messages are forwarded only to the SIP registrar server; whereas INVITE messages are
distributed among SIP proxy servers.
Configuring SIP SLB
SIP server load balancing over UDP is available in stateless SLB mode and stateful SLB mode.
SIP SLB over UDP features the following elements in both stateless and stateful modes:
• Persistence parameter can be extended: The persistence parameter can be extended to other
key header fields, such as the VIA header. This applies to both SIP stateful and SIP stateless
modes.
• Support for fragmented UDP support: Applies to both SIP stateful and SIP stateless modes.
The following elements are supported in stateful SLB mode only:
• SIP stateful support: Server selection is based on round-robin persistence on a user-configured
key header, such as Call-ID, and corresponding SIP sessions are created for this purpose.
• Server initiated SIP requests handling: Sessions are created so that subsequent transactions
with the same persistence parameter are directed to the same real server. This applies to SIP
stateful mode only. This enables the Virtual ADX to load balance the back-to-back user agent
(B2BUA) SIP servers.
• A SIP session created in Virtual ADX with multiple barrel processors are synchronized to all
barrel processors (BPs).
• Redundancy support: SIP stateful supports both hot standby HA and symmetric active-standby
HA configuration by synchronizing SIP sessions to peer box. Symmetric Active-Active HA
configuration is not recommended.
SIP SLB over UDP (Stateless SLB mode)
The following sections discuss SIP over UDP.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
333
7
Configuring SIP SLB
Configuring a SIP proxy server and enabling health check
Complete the following steps to configure a real SIP proxy server and its health check.
1. Configure a real server and IP address for a proxy server and enter the real server
configuration mode.
Virtual ADX(config)#server real proxy-server-1 10.1.3.1
Syntax: [no] server real name ip address
2. Specify the SIP port.
Virtual ADX(config-rs-proxy-server-1)#port sip
Syntax: [no] port sip
NOTE
You can specify SIP port number 5060 or the keyword sip.
3. Specify a proxy server and a health check method with options.
Virtual ADX(config-rs-redirect-server-1)#port sip sip-proxy-server
health-check-method options
Syntax: port sip [sip-proxy-server] [health-check-method [ options | register ] ]
[health-check-no-dsr]
•
•
•
•
•
334
sip-proxy-server—Identifies the server as a SIP proxy server.
health-check-method—Specifies the SIP health check method.
options—Enables health check through OPTION messages.
register—Enables health check through REGISTER messages (default method).
health-check-no-dsr—Specifies for health check to be sent to a real server rather than a
virtual server.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Configuring SIP SLB
7
Configuring a SIP registrar server and enabling health check
Complete the following steps to configure a real SIP registrar server and its health check.
1. Configure a real server and IP address for a registrar server and enter the real server
configuration mode.
Virtual ADX(config)#server real registrar-1 10.1.5.1
Syntax: [no] server real name ip_address
2. Specify the SIP port.
Virtual ADX(config-rs-registrar-1)#port sip
Syntax: [no] port sip
3. Specify a registrar server and a health check method with no DSR. In this scenario, health
check messages are sent directly to a real server IP address.
Virtual ADX(config-rs-registrar-1)#port sip sip-registrar health-check-no-dsr
Syntax: port sip [sip-registrar] [health-check-method [ options | register ] ]
[health-check-no-dsr]
•
•
•
•
•
sip-registrar—Identifies the server as a SIP registrar.
health-check-method—Specifies the SIP health check method.
options—Enables health check through OPTION messages.
register—Enables health check through REGISTER messages (default method).
health-check-no-dsr—Specifies for health check to be sent to a real server rather than a
virtual server.
Configuring a SIP proxy plus registrar server and enabling health check
Complete the following steps to configure a real SIP proxy plus registrar server and its health check.
1. Configure a real server name and IP address for a registrar/proxy server and enter the real
server configuration mode.
Virtual ADX(config)#server real registrar-proxy-server-5 10.1.9.5
Syntax: [no] server real name ip_address
2. Specify the SIP port.
Virtual ADX(config-rs-registrar-proxy-server-5)#port sip
Syntax: [no] port sip
NOTE
You can specify SIP port number 5060 or the keyword sip.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
335
7
Configuring SIP SLB
3. Specify a registrar proxy server.
Virtual ADX(config-rs-registrar-proxy-server-5)#port sip
sip-both-registrar-proxy-server
Syntax: port sip [sip-both-registrar-proxy-server] [health-check-method [ options | register ] ]
[health-check-no-dsr]
• sip-both-registrar-proxy-server—Identifies the server as a SIP registrar server or a proxy
server.
•
•
•
•
health-check-method—Specifies the SIP health check method.
options—Enables health check through OPTION messages.
register—Enables health check through REGISTER messages (default method).
health-check-no-dsr—Specifies for health check to be sent to a real server rather than a
virtual server.
Configuring a SIP redirect server and enabling health check
Complete the following steps to configure a real SIP redirect server and its health check.
1. Configure a real server name and IP address for a redirect server and enter the real server
configuration mode.
Virtual ADX(config)#server real redirect-server-1 10.1.1.1
Syntax: [no] server real name ip_address
2. Specify the SIP port.
Virtual ADX(config-rs-redirect-server-1)#port sip
Syntax:
[no] port sip
NOTE
You can specify SIP port number 5060 or the keyword sip.
3. Specify a redirect server and a health check method.
Virtual ADX(config-rs-redirect-server-1)#port sip sip-redirect-server
health-check-method register
Syntax: port sip [sip-redirect-server] [health-check-method [ options | register ] ]
[health-check-no-dsr]
•
•
•
•
•
336
sip-redirect-server—Identifies the server as a SIP redirect server.
health-check-method—Specifies the SIP health check method.
options—Enables health check through OPTION messages.
register—Enables health check through REGISTER messages (default method).
health-check-no-dsr—Specifies for health check to be sent to a real server rather than a
virtual server.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Configuring SIP SLB
7
Configuring a SIP virtual server
Complete the following steps to configure SIP SLB virtual redirect-proxy servers and virtual proxy
domains, and bind real servers to virtual servers.
1. Configure a virtual proxy domain name and IP address for Domain 1 and enter the virtual
server configuration mode.
Virtual ADX(config)#server virtual-name-or-ip proxy-domain-1 10.1.6.9
Syntax: [no] server virtual-name-or-ip name ip address
2. Specify the SIP port and SIP switch.
Virtual ADX(config-vs-proxy-domain-1)#port sip sip-switch
Syntax: [no] port sip sip-switch
This command must be used to enable the SIP switch for the virtual port.
NOTE
You can specify the logical SIP port number 5060 or the keyword sip.
3. Configure a domain and specify a SIP domain name and dummy user.
Virtual ADX(config-vs-proxy-domain-1)#port sip sip-user-name sipuser
domain-name domain-1
Syntax: [no] port sip [sip-user-name user-name [domain-name domain-name]]
NOTE
The domain name is optional. If you do not specify a domain name, the server IP address is
used.
4. Bind the real SIP registrar servers.
Virtual ADX(config-vs-proxy-domain-1)#bind sip registrar-1 sip registrar-2 sip
Syntax: bind sip registrar-name bind sip registrar-name sip
5. Bind the real SIP proxy servers.
Virtual ADX(config-vs-proxy-domain-1)#bind sip proxy-server-1 sip
proxy-server-2 sip
6. Return to global configuration mode.
Virtual ADX(config-vs-proxy-domain-1)#exit
Configuring health check
SIP health check can be performed by either the SIP REGISTER or OPTIONS method. Configure the
method according to your needs. The default method is REGISTER.
To configure SIP health check correctly, you must configure the sip-domain-name and dummy-user
at the virtual port level. SIP health check can be enabled at Layer 7 using UDP as the transport
layer.
NOTE
The Virtual ADX UDP L7 SIP health checks are supported only at regular health checks, i.e. at the
real server configuration. It is not supported at element health check.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
337
7
Configuring SIP SLB
SIP SLB over UDP (stateful SLB mode)
SIP SLB over UDP makes SIP stateful and adds the intelligence needed to handle different Caller-ID
situations.
SIP stateful basic configuration
1. Configure a real server.
Virtual ADX(config)#server real rs 10.2.2.2
Virtual ADX(config)#port sip sip-proxy-server
Virtual ADX(config)#port sip sip-both-registrar-proxy-server
health-check-method register
2. Configure a virtual server.
Virtual ADX(config)#server virtual-name-or-ip sip_vip 10.1.1.1
Virtual ADX(config)#port sip sip-stateful sip-keyfield-call-id
Syntax: [no] port sip sip-stateful [sip-keyfield-call-id | sip-keyfield-via]
3. Configure a SIP stateful port.
Virtual ADX(config)#port sip sip-stateful
Syntax: [no] port sip sip-stateful
4. Bind a virtual server to a real server.
Virtual ADX(config)#bind sip rs sip
338
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Configuring SIP SLB
7
Additional SIP session-specific commands
The following global configuration commands are related to SIP SLB. They will affect all virtual
servers with stateful SIP SLB. The commands will not have any effect on the old stateless SIP SLB.
Stateless SIP SLB will still follow the hash table and ages accordingly.
Configuring the maximum number of SIP sessions
Use the server sip session max-sip-sessions command to configure the maximum entries of SIP
sessions.
Virtual ADX(config)#server sip session max-sip-sessions 1000000
Syntax: [no] server sip session max-sip-sessions sip-sessions
The sip-sessions variable can be from 10 through a maximum of 3,500,000 sessions.
NOTE
This command requires a reload. Removing this configuration using no command will reset the
session to 500,000.
Configuring SIP session age
Use the server sip session session-max-age command to configure the session age in minutes.
Virtual ADX(config)#server sip session session-max-age 50
Syntax: [no] server sip session session-max-age age
The age variable can be from 0 through 60 minutes. The default age is 60 minutes.
Disabling partial SIP support for stateless SIP switching
Use the server sip no-create-forward-l7-session command to configure the Virtual ADX not to create
forward SIP sessions for the second leg of the call initiation by real servers, if the real server is
bound to a SIP switch-enabled virtual server.
Virtual ADX#server sip no-create-forward-l7-session
Syntax: [no] server sip no-create-forward-l7-session
Clearing SIP sessions
Use the clear server sip session command to clear all SIP sessions load balanced to the specified
real-server by setting the age to the maximum age. This command can only be accessed from the
management processor (MP).
Virtual ADX#clear server sip session rs1
Syntax: clear server sip session real-server
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
339
7
Configuring SIP SLB
Show commands for displaying SIP sessions
NOTE
The show sip session command does not count SIP sessions. Use the show sip server command to
display SIP-related real server information.
• “Showing sip session info”
• “show sip server”
Showing sip session info
Use the show sip session info command to display information on SIP session usage.
Virtual ADX#show sip session info
Syntax: show sip session info
Virtual ADX#show sip session info
slot-9 cup-1 Avail. SIP Ses = 0 total Sip Sessi= 0
Show sip server
Use the show sip server command to display real server-related information.
Virtual ADX#show sip server
Syntax: show sip server
Virtual ADX#show sip server
Avail. SIP sessions
=
0 Total SIP sessions
=
500000
Server State - 0: disabled, 1:enabled, 2:failed, 3:test, 4:suspect, 5:grace_dn,
6:active
Real Server
St CurrConn
TotConn
CurrSess
PeakConn
r31
r32
r33
r34
r35
6
6
6
6
6
344489
344505
344549
344596
344702
28723
28722
28722
28722
28723
91687
91632
91951
91566
91870
28723
28722
28722
28722
28723
Debug commands
The following commands and the counters they display are useful for internal debugging purposes.
Showing various SIP counters
Virtual ADX#show sip debug parser
SIP Parser Counters:
PARSER ERR
:1
PARSER MEM ALLOC ERR
:0
PARSER ABNORMAL HDR END
:0
PARSER UNKNOWN PKT
:21
PARSER CSEQ NOT FOUND
:1
340
PARSER
PARSER
PARSER
PARSER
PARSER
PKT CORRUPT
MULTI CALLID
PKT HDR TOO LONG
CONTENT TOO LONG
PACKET MALFORMED
:4
:0
:8
:0
:0
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Configuring SIP SLB
7
Syntax: show sip debug [parser | session| sip-transaction | udp-process]
Debugging SIP sessions
Virtual ADX#show sip debug session
SIP Session Debug Counters
SIP SESSION GET
:4381
SIP SESS FREE LIST CORUPT
:0
SIP SESS FINAL FREE
:84
SIP SESS AGED
:60
SIP SESS CORRUPT
:0
SIP HA AGE SYNC RECV
:0
SIP HA OUT OF IPC BUF
:0
SIP HA SESS CREAT RECV
:0
SIP HA DEL MSG RECV
:0
SIP HA DEL ATTEMPT SENT
:0
SIP HA CREATE EXIST
:0
SIP
SIP
SIP
SIP
SIP
SIP
SIP
SIP
SIP
SIP
SIP
SESSION GET FAILURE
SESS INDEX INVALID
SESS DEALLOC
SESS ERR
HA AGE SYNC ERR
HA AGE SYNC SENT
HA SESS CREAT SENT
HA ASP SENT
HA DEL ATTEMPT RECV
HA DELETE MSG SENT
HA DELETE NON-EXIST
:0
:0
:4179
:0
:0
:0
:0
:0
:0
:0
:3910
Syntax: show sip debug session
Debugging SIP transactions
Virtual ADX#show sip debug sip-tran
SIP Transaction Counters:
TRANSACT ERR
:0
TRANSACT ENTRY CORRUPTED
:0
TRANSACT INDEX INVALID
:0
TRANSACT FROMFLOW NOT FOUND :206
TRANSACT ENTRY AGED
:3533
TRANSACT CONTENT ERR
:5
TRANSACT PKT TOO BIG
:0
TRANSACT CLIENT NOT FOUND
:0
TRANSACT MSG OUTOF BOUND
:0
TRANSACT
TRANSACT
TRANSACT
TRANSACT
TRANSACT
TRANSACT
TRANSACT
TRANSACT
ENTRY GET
ENTRY GET FAIL
FINAL FREED
TOFLOW NOT FOUND
HEADER INCOMPLETE
INVALID SIP HEADER
PKT DROPPED
RESPONSE ENTRY NOT
:10585
:0
:2828
:354
:0
:0
:5
:0
Syntax: show sip debug sip-transaction
Debugging UDP processes
Virtual ADX#show sip debug udp-process
SIP UDP Process Counters:
UDP ERR
:0
UDP NO HEADER
UDP UNKNOWN PKT
:0
UDP PKT TO MP
UDP FWD DROP
:55
UDP REV DROP
UDP NO ACTION
:0
:0
:0
:2
Syntax: show sip debug udp-process
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
341
7
Configuring SIP SLB
Debugging SIP packet traces
The show sip debug packet-trace command shows the packets with the IP address of either
src-or-dest-IP-1 or src-or-dest-IP-2. The output displays packet processing starting from parsing to
forwarding. The command is very useful in debugging; however, it only displays in the BP console
not on rconsole.
Syntax: show sip debug packet-trace src-or-dest-IP-1 src-or-dest-IP-2
The following example is a display of session packet processing shown on a BP console.
Virtual ADX#show sip debug packet-trace 2.0.0.1:5060 1.0.0.2:46763
Top branch id: z9hG4bK-19892-1-0
Top Sent By: 1.0.0.2 Top Sent By Port: 46763
-->Starting parsing SIP UDP packet [2.0.0.1:5060->1.0.0.2:46763]
SIP packet header dump:
Packet type: RESPONSE - 2xx
URI:
version: SIP/2.0 response code: 200
parse completed: 1 num pkts processed: 0 method: INVITE
VIA header: SIP/2.0/UDP 1.0.0.2:46763;branch=z9hG4bK-19892-1-0
Call ID: [email protected]
Cseq: 1 INVITE
Top branch id: z9hG4bK-19892-1-0
Top Sent By: 1.0.0.2 Top Sent By Port: 46763
-->Starting parsing SIP UDP packet [1.0.0.2:46763->1.0.0.100:5060]
SIP packet header dump:
Packet type: ACK
URI: sip:[email protected] version: SIP/2.0 response code: 0
parse completed: 1 num pkts processed: 0 method: ACK
VIA header: SIP/2.0/UDP 1.0.0.2:46763;branch=z9hG4bK-19892-1-5
Max forward: 70
Call ID: [email protected]
Cseq: 1 ACK
Top branch id: z9hG4bK-19892-1-5
Top Sent By: 1.0.0.2 Top Sent By Port: 46763
-->Starting parsing SIP UDP packet [1.0.0.2:46763->1.0.0.100:5060]
SIP packet header dump:
Packet type: BYE
URI: sip:[email protected] version: SIP/2.0 response code: 0
parse completed: 1 num pkts processed: 0 method: BYE
VIA header: SIP/2.0/UDP 1.0.0.2:46763;branch=z9hG4bK-19892-1-7
Max forward: 70
Call ID: [email protected]
Cseq: 2 BYE
Top branch id: z9hG4bK-19892-1-7
Top Sent By: 1.0.0.2 Top Sent By Port: 46763
-->Starting parsing SIP UDP packet [2.0.0.1:5060->1.0.0.2:46763]
SIP packet header dump:
Packet type: RESPONSE - 2xx
URI:
version: SIP/2.0 response code: 200
parse completed: 1 num pkts processed: 0 method: BYE
VIA header: SIP/2.0/UDP 1.0.0.2:46763;branch=z9hG4bK-19892-1-7
Call ID: [email protected]
Cseq: 2 BYE
Top branch id: z9hG4bK-19892-1-7
Top Sent By: 1.0.0.2 Top Sent By Port: 46763
342
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
SIP SLB command reference
7
SIP SLB command reference
This section describes the syntax and usage for each SIP Server Load Balancing command in the
real server configuration mode and the virtual server configuration mode.
Real server configuration mode
Use the port sip command in the real server or virtual server configuration mode to configure a
proxy, redirect, registrar, or registrar-proxy server. These commands are issued from the real server
configuration.
Syntax: port sip {sip-redirect-server | sip-proxy-server | sip-registrar |
sip-both-registrar-proxy-server} [health-check-method [options | register]] |
[health-check-no-dsr]
•
•
•
•
•
•
•
•
sip-redirect-server—Identifies the server as a SIP redirect server.
sip-proxy-server—Identifies the server as a SIP proxy server.
sip-registrar—Identifies the server as a SIP registrar.
sip-both-registrar-proxy-server—Identifies the server as a SIP registrar or a proxy server.
health-check-method—Specifies the SIP health check method.
options—Enables health check through OPTION messages.
register—Enables health check through REGISTER messages (default method).
health-check-no-dsr—Specifies for health check to be sent to a real server rather than a virtual
server.
Virtual server configuration mode
Use the port sip command in the virtual server configuration mode to configure. The commands
are issued from the virtual server configuration.
Syntax: port sip sip-switch | sip-domain-name domain-name
• sip-switch—Enables SIP switching.
• sip-domain-name domain-name—Specifies SIP domain name.
Sample configuration
The following example shows the configuration details for SIP Server Load Balancing.
server real rs1 10.20.20.1
port sip
port sip sip-both-registrar-proxy-server health-check-method register
port sip keepalive
!
server real rs2 10.20.20.2
port sip
port sip sip-both-registrar-proxy-server health-check-method register
port sip keepalive
!
server virtual-name-or-ip vs1 10.10.0.100
port sip
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
343
7
SIP SLB command reference
port sip dsr
port sip sip-switch
bind sip rs1 sip rs2 sip
344
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Chapter
IPv6 Support for Server Load Balancing
8
Overview
NOTE
The Brocade Virtual ADX software release 3.0.00 IPv6 support for SLB applies to IPv6 clients and
IPv6 server communications only.
The commands to configure server load balancing, including configuration of virtual servers, real
servers, VIP groups, health check parameters, and others are the same for IPv6 as they are for
IPv4. The existing commands have been enhanced to accept IPv6 addresses. Other than IPv6
addressing, no new commands are necessary for configuring SLB for IPv6 on the Brocade Virtual
ADX.
The following sections shows the configuration steps for an IPv6 SLB configuration.
1. Defining IPv6 real servers.
2. Defining IPv6 virtual servers.
3. Define port characteristics using port profile.
4. Define IP routes.
5. VLAN and tagging definitions.
6. Miscellaneous.
7.
Saving the configuration.
8. IPv6 configuration example
An example configuration is shown in Figure 45.
Access from the IPv6 client to an IPv6 real server is straight forward and doesn’t require any
special processing from the Brocade Virtual ADX.
FIGURE 45
IPv6 Client access
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
345
8
Defining IPv6 real servers
Defining IPv6 real servers
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server real
ADX(config-rs-rs3)#port
ADX(config-rs-rs3)#port
ADX(config-rs-rs3)#port
ADX(config-rs-rs3)#port
ADX(config-rs-rs3)#exit
rs3 2001:db8::a
http
http
http url "HEAD /"
dns
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server real
ADX(config-rs-rs4)#port
ADX(config-rs-rs4)#port
ADX(config-rs-rs4)#port
ADX(config-rs-rs4)#port
ADX(config-rs-rs4)#exit
rs4 2001:db8::5
http
http
http url "HEAD /"
dns
Defining IPv6 virtual servers
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#server virtual vs2 2001:db8::face
ADX(config-rs-v45)#port http
ADX(config-rs-v45)#port dns
ADX(config-rs-v45)#bind http rs3 http rs4 http
ADX(config-rs-v45)#bind http rs7 http
ADX(config-rs-v45)#bind dns rs5 dns rs6 dns rs7 dns rs3 dns
ADX(config-rs-v45)#bind dns rs4 dns
ADX(config-rs-v45)#exit
Defining port characteristics using port profile
Virtual
Virtual
Virtual
Virtual
ADX(config)#server port 80
ADX(config-port-http)#session-sync
ADX(config-port-http)#tcp
ADX(config)#exit
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)server port 53
ADX(config-port-dns)#session-sync
ADX(config-port-dns)#tcp keepalive disable
ADX(config-port-dns)#udp
ADX(config)#exit
Defining IP routes
Virtual ADX(config)#ipv6 route 2001:db8::/64 2001:db8::212:f2ff:fea8:1400
Virtual ADX(config)#exit
346
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
VLAN and tagging definitions
8
VLAN and tagging definitions
Virtual ADX(config)#vlan 1 name DEFAULT-VLAN by port
Virtual ADX(config-vlan-1)#exit
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#vlan 110 by port
ADX(config-vlan-10)#tagged ethe 1 to 2
ADX(config-vlan-10)#untagged ethe 3
ADX(config-vlan-10)#router-interface ve 10
ADX(config-vlan-10)#exit
Miscellaneous
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(config)#aaa authentication web-server default local
ADX(config)#no enable aaa console
ADX(config)#exit
ADX(config)#telnet server
ADX(config)#username admin password .....
ADX(config)#snmp-server
Saving the configuration
Virtual ADX(config)#write memory
The IPv6 and IPv4 service definitions can co-exist on the same system.You can define IPv4 VIPs
with IPv4 real servers and IPv6 VIPs with IPv6 real servers on the same system.
IPv6 configuration example
An example configuration and SLB session output is shown below.
Example Configuration
!
server source-nat
server source-nat-ip 2001:db8:2::20 120 :: port-range 1
!
server real rs1 2001:db8:2::4
port http
port http url “HEAD /”
!
server virtual vs1 2001:db8:1::10
port http
bind http rs1 http
!
interface ethernet 1
ipv6 address 2001:db8:1::1/120
!
interface ethernet 2
ipv6 address 2001:db8:2::1/120
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
347
8
IPv6 configuration example
Example SLB session output
Virtual ADX# show session all 0
Session Info:
Flags - 0:UDP, 1:TCP, 2:IP, 3:INT, 4:INVD, H:sessInHash, N:sessInNextEntry
Index
=====
0
0
348
Src-IP
=============
2001:db8:2::4
2001:db8:2::3
Dst-IP
=============
2001db8:2::20
2001db8:1::10
S-port
======
80
53366
D-port
======
10241
80
Age
===
32
32
Server
======
rs1
rs1
Flag
==========
oSLB 1 H 6
oSLB 1 H 6
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Appendix
Server-specific Loopback Configurations
A
Overview
You can configure loopback addresses on some common types of real servers.
NOTE
The information in this appendix is based on information from the vendors of these servers. For
more information, please consult your real server vendor.
Solaris
To configure a loopback address on Solaris, enter the following command.
ifconfig lo0:1 vip-addr netmask net-mask up
You might need to “plumb” the interface first. In this case, enter the following commands.
ifconfig lo0:1 plumb
ifconfig lo0:1 vip-addr netmask net-mask up
NOTE
The above specified commands applies to the current running configuration only. To make the
address permanent so that it is reconfigured following a reboot or power cycle, create the file
/etc/hostname.lo0:1.
NOTE
For Hewlett-Packard (HP) version 11.x, use the May 2000 or later patch.
Linux
To configure a loopback interface on Linux, enter a command such as the following.
ifconfig lo:0 vip-addr netmask net-mask up
NOTE
The ifconfig lo:0 vip-addr netmask net-mask up command applies to the current running
configuration only. To make the address permanent so that it is reconfigured following a reboot or
power cycle, go to /etc/sysconfig/network-scripts and make a file called ifcfg-lo:0 using ifcfg-lo as a
template.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
349
A
Windows NT
Windows NT
To configure a loopback interface on Windows NT, you need to configure a new network adapter.
Use the following procedure. This procedure applies to the following products:
•
•
•
•
Microsoft Windows 2000 Professional
Microsoft Windows 2000 Server
Microsoft Windows 2000 Advanced Server
Microsoft Windows 2000 Datacenter Server
NOTE
When you add a loopback interface to Windows NT, it sometimes creates a route that has the same
address as the loopback interface. You need to delete this route. In come cases, the procedure for
deleting the route can include deleting the correct route to the server’s default gateway. When this
is the case, you need to add this route back to Windows NT.
Manual installation
1. Click Start, point to Settings, click Control Panel, and then double-click Add/Remove Hardware.
2. Click Add/Troubleshoot a device, and then click Next.
3. Click Add a new device, and then click Next.
4. Click No, I want to select the hardware from a list, and then click Next.
5. Click Network adapters, and then click Next.
6. In the Manufacturers box, click Microsoft.
7.
In the Network Adapter box, click Microsoft Loopback Adapter, and then click Next.
8. Click Finish.
After the adapter is installed successfully, you can configure its options manually, as with any other
adapter.
NOTE
If the TCP/IP properties are configured to use DHCP (the default), the adapter will eventually use an
autonet address (169.254.x.x/16) because it is not actually connected to any physical media.
Unattended installation
Modify the Unattend.txt file using the following example as a guide to install the Microsoft
Loopback adapter.
[NetAdapters]
Adapter01=Params.Adapter01
[Params.Adapter01]
InfID="*msloop" ; Microsoft Loopback Adapter
ConnectionName = "MS Loopback Adapter"
[NetProtocols]
MS_TCPIP=Params.MS_TCPIP
; TCP/IP parameters
; Use parameter values specific to your network
350
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
A
Windows NT
[Params.MS_TCPIP]
AdapterSections=params.TCPIP.Adapter01
DNS=yes
DNSSuffixSearchOrder=mycorp.com
EnableLMHosts=No
; Adapter Specific TCP/IP parameters
; Use parameter values specific to your network
[params.TCPIP.Adapter01]
SpecificTo=Adapter01
DNSDomain=mycorp.com
DNSServerSearchOrder=192.168.5.251
WINS=no
DHCP=no
IPAddress=192.168.5.10
SubnetMask=255.255.255.0
DefaultGateway=192.168.5.254
Deleting the unwanted routes
In some cases, Windows NT creates a route that has the same address as the loopback interface.
You need to delete this route.
Two methods are shown in this section. If you receive an error message while trying to use the
simple method, you need to use the long method instead.
NOTE
Regardless of the method you use, you must repeat the procedure every time the Windows NT server
is booted. However, you can create a small batch file to enter these commands and add the batch
file to the AT subsystem so that the file runs automatically each time the server is booted.
Simple method
The simple method requires you to delete the route that Windows NT creates when you add the
loopback interface. The route you need to delete is the one that has the same IP address as the
loopback interface.
1. Enter the route print command to display the server’s route table. In this example, the
loopback interface has address 192.168.200.106.
.
C:\>route print
Active Routes:
Network Address
0.0.0.0
10.0.0.0
192.168.200.0
192.168.200.0
192.168.200.106
192.168.200.251
192.168.200.255
224.0.0.0
224.0.0.0
10.255.255.255
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Netmask
0.0.0.0
255.0.0.0
255.255.255.0
255.255.255.0
255.255.255.255
255.255.255.255
255.255.255.255
224.0.0.0
224.0.0.0
255.255.255.255
Gateway Address
192.168.204.254
10.0.0.1
192.168.200.106
192.168.200.251
10.0.0.1
10.0.0.1
192.168.200.251
192.168.200.106
192.168.200.251
192.168.200.251
Interface
192.168.200.251
10.0.0.1
192.168.200.106
192.168.200.251
10.0.0.1
10.0.0.1
192.168.200.251
192.168.200.106
192.168.200.251
192.168.200.251
Metric
1
1
1
1
1
1
1
1
1
1
351
A
Windows NT
2. Delete the route that has the same address as the loopback interface.
C:\>route delete 192.168.200.0 mask 255.255.255.0 192.168.200.106
3. Display the route table again to verify that the unwanted route is gone
.
C:\>route print
Active Routes:
Network Address
0.0.0.0
10.0.0.0
192.168.200.0
192.168.200.106
192.168.200.251
192.168.200.255
224.0.0.0
224.0.0.0
10.255.255.255
Netmask
0.0.0.0
255.0.0.0
255.255.255.0
255.255.255.255
255.255.255.255
255.255.255.255
224.0.0.0
224.0.0.0
255.255.255.255
Gateway Address
192.168.204.254
10.0.0.1
192.168.200.251
10.0.0.1
10.0.0.1
192.168.200.251
192.168.200.106
192.168.200.251
192.168.200.251
Interface
192.168.200.251
10.0.0.1
192.168.200.251
10.0.0.1
10.0.0.1
192.168.200.251
192.168.200.106
192.168.200.251
192.168.200.251
Metric
1
1
1
1
1
1
1
1
1
Long method
The long method, like the short method, requires you to delete the route that Windows NT creates
when you add the loopback interface. However, what makes this method is long is that in some
cases, when the route table has more than one route in the network that contains the loopback
interface, the route delete command deletes the wrong route. In this case, you need to enter the
command again to delete the route that has the loopback address, then re-add the other route.
1. Enter the route print command to display the server’s route table. In this example, the
loopback interface has address 192.168.200.106. Notice that the route table also contains
another route (192.168.200.250) in the same network. The 192.168.200.250 route is the
gateway route and needs to stay in the route table.
.
C:\users\default>route print
Active Routes:
Network Address
0.0.0.0
10.0.0.0
192.168.200.0
192.168.200.0
192.168.200.106
192.168.200.250
192.168.200.255
224.0.0.0
224.0.0.0
10.255.255.255
Netmask
0.0.0.0
255.0.0.0
255.255.255.0
255.255.255.0
255.255.255.255
255.255.255.255
255.255.255.255
224.0.0.0
224.0.0.0
255.255.255.255
Gateway Address
192.168.200.254
10.0.0.1
192.168.200.250
192.168.200.106
10.0.0.1
10.0.0.1
192.168.200.106
192.168.200.250
192.168.200.106
192.168.200.106
Interface
192.168.200.250
10.0.0.1
192.168.200.250
192.168.200.106
10.0.0.1
10.0.0.1
192.168.200.106
192.168.200.250
192.168.200.106
192.168.200.106
Metric
1
1
1
1
1
1
1
1
1
1
2. Enter the route delete command to delete the unwanted 192.168.200.106 route.
C:\users\default>route delete 192.168.200.0 mask 255.255.255.0
192.168.200.106
352
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Windows NT
A
3. Display the route table again to verify the results. In this example, Windows NT deletes the first
192.168.200.x route in the table instead of deleting the route you want to delete. If this occurs
when you are performing this procedure, go to step 4. Otherwise, you are finished with this
procedure.
C:\users\default>route print
Active Routes:
Network Address
0.0.0.0
10.0.0.0
192.168.200.0
192.168.200.106
192.168.200.250
192.168.200.255
224.0.0.0
224.0.0.0
255.255.255.255
Netmask
0.0.0.0
255.0.0.0
255.255.255.0
255.255.255.255
255.255.255.255
255.255.255.255
224.0.0.0
224.0.0.0
255.255.255.255
Gateway Address
192.168.200.254
10.0.0.1
192.168.200.106
10.0.0.1
10.0.0.1
192.168.200.106
192.168.200.250
192.168.200.106
192.168.200.106
Interface
192.168.200.250
10.0.0.1
192.168.200.106
10.0.0.1
10.0.0.1
192.168.200.106
192.168.200.250
192.168.200.106
192.168.200.106
Metric
1
1
1
1
1
1
1
1
1
4. Enter the route delete command again to delete the unwanted route.
C:\users\default>route delete 192.168.200.0 mask 255.255.255.0
192.168.200.106
5. Display the route table again to verify the results. In this example, none of the 192.168.200.x
routes remain in the table.
C:\users\default>route print
Active Routes:
Network Address
0.0.0.0
10.0.0.0
192.168.200.106
192.168.200.250
192.168.200.255
224.0.0.0
224.0.0.0
10.255.255.255
Netmask
0.0.0.0
255.0.0.0
255.255.255.255
255.255.255.255
255.255.255.255
224.0.0.0
224.0.0.0
255.255.255.255
Gateway Address
192.168.200.254
10.0.0.1
10.0.0.1
10.0.0.1
192.168.200.106
192.168.200.250
192.168.200.106
192.168.200.106
Interface
192.168.200.250
10.0.0.1
10.0.0.1
10.0.0.1
192.168.200.106
192.168.200.250
192.168.200.106
192.168.200.106
Metric
1
1
1
1
1
1
1
1
6. Enter the route add command to re-add the gateway route.
C:\users\default>route add 192.168.200.0 mask 255.255.255.0 192.168.200.250
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
353
A
Windows NT
7.
Display the route table again to verify that the table contains the gateway route but does not
contain a route with the loopback address.
C:\users\default>route print
Active Routes:
Network Address
0.0.0.0
10.0.0.0
192.168.200.0
192.168.200.106
192.168.200.250
192.168.200.255
224.0.0.0
224.0.0.0
10.255.255.255
354
Netmask
0.0.0.0
255.0.0.0
255.255.255.0
255.255.255.255
255.255.255.255
255.255.255.255
224.0.0.0
224.0.0.0
255.255.255.255
Gateway Address
192.168.200.254
10.0.0.1
192.168.200.250
10.0.0.1
10.0.0.1
192.168.200.106
192.168.200.250
192.168.200.106
192.168.200.106
Interface
192.168.200.250
10.0.0.1
192.168.200.250
10.0.0.1
10.0.0.1
192.168.200.106
192.168.200.250
192.168.200.106
192.168.200.106
Metric
1
1
1
1
1
1
1
1
1
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Appendix
SLB Show and Debug Commands
B
Using show source-ipsource ip [real-server ip | all]
The show source-ip source-ip command displays the IP information, free ports, owner, start, and
end for port pools for a specific source IP.
The show source-ip source ip real-server-ip command displays the free ports, owner, start, and end
for port pools for the specified source IP addresses and real server.
The show source-ip source ip all command all displays the free ports, owner, start, and end for port
pools for the specified source IP addresses for all real servers.
Virtual ADX#show source-ip source ip [real-server ip | all]
Example
Virtual ADX#show source-ip 10.4.4.101 all
Source IP information
*********************
Source IP: 10.4.4.101
flt: Yes
standby: No
intf ip: No
Real server: real-rs-8.10 (10.8.8.10)
MMS: h: 0 t: 0 m: 23b4fb3c T: 642 f: 642
RTSP: h: 0 t: 0 m: 23b51b54 T: 384 f: 384
NORM: h: 0 t: 0 m: 23b34b24 T: 9216 f: 9216
Real server: real-rs-8.11 (10.8.8.11)
MMS: h: 0 t: 0 m: 23b53b6c T: 642 f: 642
RTSP: h: 0 t: 0 m: 23b55b84 T: 384 f: 384
NORM: h: 0 t: 0 m: 280c1d08 T: 9216 f: 9216
Real server: real-rs-8.12 (10.8.8.12)
MMS: h: 0 t: 0 m: 23b58114 T: 642 f: 642
RTSP: h: 0 t: 0 m: 23b5a12c T: 384 f: 384
NORM: h: 0 t: 0 m: 280dcd20 T: 9216 f: 9216
NOTE
If the show source-ip command displays that the IP is a per-real-srcip, then you should use the show
source-ip source-ipreal-server ip command to view the port allocation and usage information,
because the port allocation will be from the real server pool.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
355
B
Using the show session all command
Using the show session all command
Use the show session command (available at the BP console only) to determine if the sessions
have been created correctly.
Virtual ADX#rconsole 1 1
Virtual ADX1/1#show session all 0
Session Info:
Flags0:UDP, 1:TCP, >:fwdSess, +:userCntFlgSet, D:sessInDelQ, F:fin_setFlg, A:acked
* before age indicates that the static bit is set
Index Src-IP
===== ======
0
10.0.0.5
1
10.0.0.5
2
10.1.1.15
3
10.1.1.15
4
10.1.1.42
5
10.1.1.42
6
10.1.1.15
7
10.1.1.66
Dst-IP
======
10.1.1.36
10.1.1.99
10.1.1.79
10.1.1.79
10.1.1.99
10.1.1.99
10.0.0.1
10.0.0.1
S-port D-port Age Serv
Flags
====== ====== === ==== ==========
5
80
*0
n/a SLB1
5
80
*0
n/a SLB1
80
10242
32 n/a OPT1
80
10242
rest SLB1
1333
80
33 n/a OPT1>
1333
80
rest SLB1>+
1
1
*60 n/a SLB1
1
1
*60 n/a SLB1
#
#
#
A
#
#
#
In the above example, 10.1.1.42 is the client and 10.1.1.99 is the VIP address. The IP address
10.1.15 is the real server and 10.1.1.79 is the source NAT IP.
NOTE
In the reverse session, the port 10242 has been allocated from the pool of real server 10.1.1.15.
You can verify the information by using the show source-ip command.
.
Virtual ADX#show source-ip 10.1.1.79 10.1.1.15
Source IP information
*********************
Source IP: 10.1.1.79
Real server: rest (10.1.1.15)
flt: Yes
standby: No
intf ip: No
port-range: 1
for ssl: No
per-real-srcip: Yes
NORM: h: 3 t: 2 m: 23b33b24 T: 27648 f: 27647
The output shows that of a total of 27648 ports, one port has been allocated and 27467 are still
available.
356
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Using the source-ip-debug command
B
Using the source-ip-debug command
NOTE
This command should only be used for debugging purposes, because enabling it could impact
performance.
You can configure the following command to enable debugging for source IP.
Virtual ADX(config)#source-ip-debug
Syntax: [no] source-ip-debug
Using the debug filter command
The Brocade Virtual ADX debug filter is a packet capture utility that captures packets at the
Brocade Virtual ADX itself based on user-defined filters. The captured packets are stored in a
capture buffer and it is possible to view the packets on-screen or to transfer them to a TFTP server
to have a look at them offline. The Brocade Virtual ADX offers the possibility to store packet
captures in PCAP format. This simplifies the work dramatically due to the fact that users are able to
use PCAP based tools to work with the packet captures taken at the Brocade Virtual ADX.
Using the packet capture utility
You have to do the following to use the Brocade Virtual ADX packet capture utility (debug filter):
1. enter utility
2. configure capture buffer
3. specify packet size to capture
4. specify filters
5. apply filters
6. start capturing process
7.
stop capturing process
8. view captured packets
Enter Utility
To enter the debug filter, enter the following commands:
Virtual ADX> ena
Virtual ADX# debug filter
Virtual ADX(debug-filter)#
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
357
B
Using the debug filter command
Configuring Capture Buffer
You have to specify the size of the capture buffer in kilobytes. To set the buffer size do the following:
Virtual ADX(debug-filter)# buffer-size 1024
Syntax: buffer-size kilobytes
To display the buffer size do the following:
Virtual ADX(debug-filter)# buffer-size 1024
Syntax: buffer-size kilobytes
Virtual ADX(debug-filter)# show buffer-size
Capture buffer size: 1048567 bytes
Specify packet size to capture
You can specify the number of bytes from a captured packet that are getting stored in the capture
buffer. It is also possible to store the entire packet.
To set the amount of bytes to store do the following:
Virtual ADX(debug-filter)# packet-size 128
Syntax: packet-size bytes | whole
The whole variable specifies that the entire packet needs to be stored in the capture buffer.
To show the currently configured packet size:
Virtual ADX(debug-filter)# show packet-size
Max bytes stored from a filtered pkt: 128
Specify filter(s)
You specify the packets to store in the capture buffer by configuring one or more filter IDs. A filter ID
consists of a set of filters that specify the attributes of packets to be stored in the capture buffer.
You can configure up to 16 filter IDs.
Within a filter ID, you can specify filters for Layer 2 - 4 information in a packet. In addition, you can
set up filters to capture packets that contain a specified pattern within the packet.
By default, a filter ID is configured to match any packet. Within a filter ID, all the filters must match
a received packet in order for the packet to be captured. The filters not explicitly configured have
"don't care" values, which are ignored during the matching process.
To specify the filter with ID 1:
Virtual ADX(debug-filter)#specify 1
Virtual ADX(debug-filter-spec-1)#
Syntax: specify filter-id
You are able to specify filter settings at the filter ID configuration level. It is possible as well to
display the current settings.
358
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Using the debug filter command
B
Table 36 displays the Ethernet Filter settings.
TABLE 36
Ethernet Filter Settings
CLI Command
Filter Type
mac bcast
Ethernet broadcast packets
mac dest mac-address
Packets with the specified destination MAC address
mac mcast
Ethernet multicast packets
mac src mac-address
Packets with the specified source MAC address
mac type type-in-hex
Packets of the specified Layer 3 type
Table 37 displays the IP Filter settings.
TABLE 37
IP Filter Settings
CLI Command
Filter Type
ip bcast
IP broadcast packets
ip dest ip-address
Packets with the specified destination IP address
ip mcast
IP multicast packets
ip protocol protocol-in-hex
Packets with the specified Layer 4 protocol
ip src ip-address
Packets with the specified source IP address
Table 38 displays the TCP Filter settings.
TABLE 38
TCP Filter Settings
CLI Command
Filter Type
tcp src port-number
Packets with the specified source TCP port
tcp dest port-number
Packets with the specified destination TCP port
tcp syn
TCP packets with the SYN flag on
tcp reset
TCP packets with the RST flag on
tcp fin
TCP packets with the FIN flag on
tcp ack
TCP packets with the ACK flag on
tcp push
TCP packets with the PSN flag on
tcp urgent
TCP packets with the URG flag on
Table 39 displays the UDP Filter settings.
TABLE 39
UDP Filter Settings
CLI Command
Filter Type
udp src port-number
Packets with the specified source UDP port
udp dest port-number
Packets with the specified destination UDP port
tcp syn
TCP packets with the SYN flag on
tcp reset
TCP packets with the RST flag on
tcp fin
TCP packets with the FIN flag on
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
359
B
Using the debug filter command
TABLE 39
UDP Filter Settings
CLI Command
Filter Type
tcp ack
TCP packets with the ACK flag on
tcp push
TCP packets with the PSN flag on
tcp urgent
TCP packets with the URG flag on
Pattern matching filter settings
You can set up a filter to capture packets that contain a pattern of a specified length, starting from
a given offset from the beginning of the packet.
Example:
Virtual ADX(debug-filter-spec-1)#pattern 24 2 1023
Syntax: pattern offset length pattern-in-hex
The offset variable is the number of bytes from the start of the packet.
The length variable is the length of the pattern in bytes. You can specify between 1 - 32 bytes.
The pattern-in-hex variable is the pattern to match. The length of the pattern must be equal to the
number of bytes specified with the length variable.
Example:
Create a filter to look for every packet from source IP 192.168.8.1 going to destination IP
192.168.8.222 - destination port 80:
Virtual ADX(debug-filter-spec-1)#ip src 192.168.8.1
Virtual ADX(debug-filter-spec-1)#ip dest 192.168.8.222
Virtual ADX(debug-filter-spec-1)#tcp dest 80
To show the currently applied settings for the filter, use the show command:
Virtual ADX(debug-filter-spec-1)#show
Filter-ID: 1
MAC filters:
Src MAC : ANY
Dest MAC : ANY
MAC Type : ANY
IP filters:
Src IP : 192.168.8.1
Dest IP : 192.168.8.222
Protocol : ANY
TCP filters:
Src port: ANY
Dest port: 80
Flags : None
UDP filters:
Src port: ANY
Dest port: ANY
HTTP filters:
Url : ANY
Cookie : ANY
Pattern filters:
Pattern : ANY
360
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Using the debug filter command
B
Syntax: show
Use reset at the filter ID configuration level to restore the filter IDs default settings (match ALL):
Virtual ADX(debug-filter-spec-1)#reset
Syntax: reset
Use exit to leave the filter ID configuration level.
Virtual ADX(debug-filter-spec-1)#exit
Virtual ADX(debug-filter)#
Syntax: exit
It is also possible to display the setting for a filter ID at the "debug filter" level. This is shown in the
following example:
Virtual ADX(debug-filter)#show 1
Filter-ID: 1
MAC filters:
Src MAC : ANY
Dest MAC : ANY
MAC Type : ANY
IP filters:
Src IP : 192.168.8.1
Dest IP : 192.168.8.222
Protocol : ANY
TCP filters:
Src port: ANY
Dest port: 80
Flags : None
UDP filters:
Src port: ANY
Dest port: ANY
HTTP filters:
Url : ANY
Cookie : ANY
Pattern filters:
Pattern : ANY
Syntax: show filter-id
Apply filter(s)
It is possible to define multiple filters like the one shown above - a filter is a set of matching criteria
to select packets. A filter takes effect when you apply it. A filter ID should be applied globally or on
an individual port. You can apply a filter ID so that it filters inbound traffic only, outbound traffic
only, or both.
The following command will apply filter 1 globally for inbound and outbound traffic:
Virtual ADX(debug-filter)# apply 1
Syntax: apply filter-id
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
361
B
Using the debug filter command
You can apply multiple filter IDs and specify an and/or relationship between them. For example, to
apply filter IDs 1 and 2, enter the following command. Packets that match the filters in both filter
IDs are stored in the capture buffer.
Virtual ADX(debug-filter)# apply "1 and 2"
This is useful to create more complex filtering rules. A single filter ID is not able to cover a
communication from host A to host B because it is necessary to cover the "flow" from host A to host
B and the "flow" from host B to host A.
Example:
Create a filter logic to look for every packet of the communication in between the client with IP
192.168.8.1 and the virtual server with IP 192.168.8.222 at port 80:
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
Virtual
ADX(debug-filter)# sp 1
ADX(debug-filter-spec-1)#ip src 192.168.8.1
ADX(debug-filter-spec-1)#ip dest 192.168.8.222
ADX(debug-filter-spec-1)#tcp dest 80
ADX(debug-filter-spec-1)#exit
ADX(debug-filter)#sp 2
ADX(debug-filter-spec-2)#ip dest 192.168.8.1
ADX(debug-filter-spec-2)#ip src 192.168.8.222
ADX(debug-filter-spec-2)#tcp src 80
ADX(debug-filter-spec-2)#exit
ADX(debug-filter)# apply "1 or 2"
The filter ID 1 is going to hit for all packets from the client to the virtual server and filter ID 2 is going
to hit for the return traffic. One of these filter IDs need to be true to be sure it is part of the
communication we are looking for.
It is also possible to create more complex filter expressions as shown below:
To apply filter IDs 1, 2, and 3 so that packets must match the filters in 1 and match the filters in
either 3 or 4, enter the following command:
Virtual ADX(debug-filter)#apply "(1 and (3 or 4))"
To view the currently applied expressions:
Virtual ADX(debug-filter-all-all)#show apply
Filter ID apply expression: ( 1 and ( 3 or 4 ) )
Syntax: show apply
Start Capturing Process
You are able to start the capturing process as soon as you have done all the steps mentioned
above. Once you start the packet capture utility, filtered packets are stored in the capture buffer
and are available for viewing until you restart the utility.
To start the packet capture utility, enter the following command:
Virtual ADX (debug-filter)# start
Syntax: start
The packet capturing process will run until the configured buffer is full or until it is stopped
manually.
362
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Using the debug filter command
B
Stop Capturing Process
You can stop the packet capture utility with the following command:
Virtual ADX(debug-filter)# stop
Number of packets captured: 126
Syntax: stop
View Captured Packets
First of all you have to select one of the places where packets are captured. JetCore based devices
offer two locations:
• MP = Management Processor
• BP = Barrel Processor
Use the view command to select the processor you would like to choose:
To select BP 2 of the WSM module in slot 1:
Virtual ADX(debug-filter)# view bp 1 2
Virtual ADX(debug-filter-1-2)#
To select the MP:
Virtual ADX(debug-filter)# view mp
Virtual ADX(debug-filter-mp)#
Syntax: view [mp | bp slot-number cpu-number]
You now have multiple options and you might want to use the summary command to see a
summary of all packets captured at the chosen location.
Syntax: summary
It is also possible to have a close look at a single packet using the hex-dump or ascii-dump
command:
Syntax: ascii-dump packet-number
Syntax: hex-dump packet-number
The example below includes some example outputs which might help to understand how to use the
commands.
"debug filter" example
Test network:
client (192.168.8.100) ---- port 15 (192.168.8.1) Brocade Virtual ADX (192.168.9.1) port 3 --(192.168.9.101) real server
Virtual server @ Virtual ADX: 192.168.8.222 offering HTTP service
Brocade Virtual ADX real and virtual server configuration:
server real rs101 192.168.9.101
port http
port http url "HEAD /"
!
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
363
B
Using the debug filter command
!
server virtual vs222 192.168.8.222
port http
bind http rs101 http
Task:
Get a packet capture of an HTTP request coming from the client IP 192.168.8.100 to the virtual
server 192.168.8.222 including the packets going to the real server 192.168.9.101.
The source IP of the client request is 192.168.8.100 and the destination TCP port is 80. The
backend traffic is as well using the client IP 192.168.8.100 because we do not have source-nat
configured. The real servers service port is 80 as well. The return/reply traffic is going to use
192.168.8.100 as destination IP and it is using the source TCP port 80.
Filters to configure:
1. from source IP 192.168.8.100 to destination port 80 TCP
2. to destination IP 192.168.8.100 from source port 80 TCP
Interesting traffic will hit the first or second filter.
CLI commands/outputs and comments:
Enter debug filter utility:
[email protected] ADX>ena
No password has been assigned yet...
[email protected] ADX#debug filter
Configure buffer-size and packet-size to store in buffer:
[email protected] ADX(debug-filter)#buffer-size 4096
[email protected] ADX(debug-filter)#packet-size whole
Create filter 1 and filter 2:
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
ADX(debug-filter)#sp 1
ADX(debug-filter-spec-1)#reset
ADX(debug-filter-spec-1)#ip src 192.168.8.100
ADX(debug-filter-spec-1)#tcp dest 80
ADX(debug-filter-spec-1)#exit
ADX(debug-filter)#sp 2
ADX(debug-filter-spec-2)#reset
ADX(debug-filter-spec-2)#ip dest 192.168.8.100
ADX(debug-filter-spec-2)#tcp src 80
ADX(debug-filter-spec-2)#exit
Apply filters using OR as operator:
[email protected] ADX(debug-filter)#apply 1or2
Start capturing process:
[email protected] ADX(debug-filter)#start
SENT REQUEST FROM TEST CLIENT 192.168.8.100 NOW
Stop capturing process:
[email protected] ADX(debug-filter)#stop
364
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Using the debug filter command
B
Check ALL BPs to find the BP responsible for the test client:
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
ADX(debug-filter)#view bp 1 1
ADX(debug-filter-1-1)#sum
ADX(debug-filter-1-1)#view bp 1 2
ADX(debug-filter-1-2)#sum
ADX(debug-filter-1-2)#view bp 1 3
ADX(debug-filter-1-3)#sum
NOTHING SO FAR - CHECK THE NEXT AND LAST PROCESSOR TALKING ABOUT THE ADX1016-4:
[email protected] ADX(debug-filter-1-3)#view bp 1 4
[email protected] ADX(debug-filter-1-4)#sum
Number of packets captured: 20
pkt:1 IN len:112 TCP :3881 ->80 Seq:4047880146 Ack SYN
pkt:2 OUTlen:138 TCP :3881 ->80 Seq:4047880146 Ack SYN
pkt:3 IN len:112 TCP :80 ->3881 Seq:2434401979 Ack:4047880147 SYN ACK
pkt:4 OUTlen:138 TCP :80 ->3881 Seq:2434401979 Ack:4047880147 SYN ACK
pkt:5 IN len:106 TCP :3881 ->80 Seq:4047880147 Ack:2434401980 ACK
pkt:6 OUTlen:132 TCP :3881 ->80 Seq:4047880147 Ack:2434401980 ACK
pkt:7 IN len:152 TCP :3881 ->80 Seq:4047880147 Ack:2434401980 ACK PSH
pkt:8 OUTlen:178 TCP :3881 ->80 Seq:4047880147 Ack:2434401980 ACK PSH
pkt:9 IN len:106 TCP :80 ->3881 Seq:2434401980 Ack:4047880199 ACK
pkt:10 OUTlen:132 TCP :80 ->3881 Seq:2434401980 Ack:4047880199 ACK
pkt:11 IN len:423 TCP :80 ->3881 Seq:2434401980 Ack:4047880199 ACK PSH
pkt:12 OUTlen:449 TCP :80 ->3881 Seq:2434401980 Ack:4047880199 ACK PSH
pkt:13 IN len:106 TCP :3881 ->80 Seq:4047880199 Ack:2434402303 ACK
pkt:14 OUTlen:132 TCP :3881 ->80 Seq:4047880199 Ack:2434402303 ACK
pkt:15 IN len:106 TCP :3881 ->80 Seq:4047880199 Ack:2434402303 ACK FIN
pkt:16 OUTlen:132 TCP :3881 ->80 Seq:4047880199 Ack:2434402303 ACK FIN
pkt:17 IN len:106 TCP :80 ->3881 Seq:2434402303 Ack:4047880200 ACK FIN
pkt:18 OUTlen:132 TCP :80 ->3881 Seq:2434402303 Ack:4047880200 ACK FIN
pkt:19 IN len:106 TCP :3881 ->80 Seq:4047880200 Ack:2434402304 ACK
pkt:20 OUTlen:132 TCP :3881 ->80 Seq:4047880200 Ack:2434402304 ACK
The test client hits BP 1 4 and the summary is showing 20 packets related to the test request.
Packet #1 is the incoming TCP SYN packet, packet #2 is the same SYN packet but it is behind the
Brocade Virtual ADX (going to the real server). Each packet is visible twice because it exists before
and after the Brocade Virtual ADX (before SLB and after SLB).
The client HTTP request is part of packet #7 (after the 3-way handshake):
[email protected] ADX(debug-filter-1-4)#ascii 7
Packet 7 captured at Oct 26 17:00:24 ; Packet size is 152(0x0098) bytes
In port: 15
fpga optimized: No
Ethernet Version II
Address: 0024.81f7.2f8f ---> 021b.ed3c.cb60
Ethernet II Protocol Type: IP
Internet Protocol
Version(MSB 4 bits): 4
Header length(LSB 4 bits): 5 (32-bit word)
Service Type: 0x00
Total length: 92 (Octets)
Fragment ID: 7207
Flags summary: 0x40
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
365
B
Using the debug filter command
0... .... = Reserved
.1.. .... = Do not fragment
..0. .... = Last fragment
Fragment offset(LSB 13 bits): 0 (0x00)
Time to live: 128 seconds/hops
IP protocol type: TCP (0x06)
Checksum: 0x4be2
IP address: 192.168.8.100 ---> 192.168.8.222
No option
Transmission Control Protocol
Port 3881 ---> 80
Sequence Number: 4047880147
Acknowledgement Number: 2434401980
Header Length(MSB 4 bits): 5 (32-bit word)
Reserved(LSB 4 bits): 0
Code: 0x18
RES: 0... ....
CON: .0.. ....
URG: ..0. ....
ACK: ...1 ....
PSH: .... 1...
RST: .... .0..
SYN: .... ..0.
FIN: .... ...0
Window: 64000
Checksum: 0xe90f
Urgent Pointer: 0x0000
Data:
0000:
0010:
0020:
0030:
47
48
32
0d
45
6f
32
0a
54
73
32
0d
20
74
0d
0a
2f
3a
0a
00
20
20
41
00
48
31
63
00
54
39
63
00
54
32
65
00
50
2e
70
00
2f
31
74
00
31
36
3a
00
2e
38
20
00
31
2e
2a
00
0d 0a | GET / HTTP/1.1..
38 2e | Host: 192.168.8.
2f 2a | 222..Accept: */*
| ..............
The packet arrived via port 15 (client facing) and the IP header is showing the following:
• source IP: 192.168.8.100
• destination IP: 192.168.8.222
This is a packet coming from the client to the virtual server. Packet #8 is the same packet BUT on
the way to the real server (after SLB):
[email protected] ADX(debug-filter-1-4)#ascii 8
Packet 8 captured at Oct 26 17:00:24 ; Packet size is 178(0x00b2) bytes
Out port: 3
fpga optimized: No
Ethernet Version II
Address: 001b.ed3c.cb62 ---> 021b.ed3c.cb60
Ethernet II Protocol Type: IP
Internet Protocol
Version(MSB 4 bits): 4
Header length(LSB 4 bits): 5 (32-bit word)
Service Type: 0x00
Total length: 92 (Octets)
Fragment ID: 7207
Flags summary: 0x40
0... .... = Reserved
.1.. .... = Do not fragment
..0. .... = Last fragment
366
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Using the debug filter command
B
Fragment offset(LSB 13 bits): 0 (0x00)
Time to live: 128 seconds/hops
IP protocol type: TCP (0x06)
Checksum: 0x4be2
IP address: 192.168.8.100 ---> 192.168.9.101
No option
Transmission Control Protocol
Port 3881 ---> 80
Sequence Number: 4047880147
Acknowledgement Number: 2434401980
Header Length(MSB 4 bits): 5 (32-bit word)
Reserved(LSB 4 bits): 0
Code: 0x18
RES: 0... ....
CON: .0.. ....
URG: ..0. ....
ACK: ...1 ....
PSH: .... 1...
RST: .... .0..
SYN: .... ..0.
FIN: .... ...0
Window: 64000
Checksum: 0xe90f
Urgent Pointer: 0x0000
Data:
0000:
0010:
0020:
0030:
0040:
0050:
47
48
32
0d
00
00
45
6f
32
0a
00
00
54
73
32
0d
00
00
20
74
0d
0a
00
00
2f
3a
0a
00
00
00
20
20
41
00
00
00
48
31
63
00
00
00
54
39
63
00
00
00
54 50 2f 31
32 2e 31 36
65 70 74 3a
00 00 00 00
00 00 00 00
| ........
2e
38
20
00
00
31
2e
2a
00
00
0d
38
2f
00
00
0a
2e
2a
00
00
|
|
|
|
|
GET / HTTP/1.1..
Host: 192.168.8.
222..Accept: */*
................
................
The packet is leaving via port 3 (real server facing) and the IP header is showing the following:
• source IP: 192.168.8.100
• destination IP: 192.168.9.101
This is a packet coming from the client going to the real server.
Saving captured packets
After you captured packets and viewed them with the summary command, you can save them by
performing the following steps:
Virtual ADX(debug-filter-1-1)#pcap save
ASCII string
file name
<cr>
Virtual ADX(debug-filter-1-1)#pcap save a1
preparing pcap data file, please wait...
.Done
Virtual ADX(debug-filter-1-1)#end
Virtual ADX#
[detached]
[[email protected] ADX]# cd /opt/ADX/pcap
[[email protected] ADX pcap]# ls
a1.cap*
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
367
B
Displaying global Layer 4 Brocade Virtual ADX configuration
Now you can copy the file to a TFTP server. Use one of the following methods:
• From a Linux console:
[[email protected] ADX pcap]# tftp -p -l a1.cap -r z1.cap 10.24.132.85
a1.cap is the local file and z1.cap is the remote file name.
• From the CLI or Management console:
Virtual ADX#copy file tftp 10.24.132.85 b1.cap /opt/ADX/pcap/a1.cap
b1.cap is the remote file name and a1.cap is the local file name.
Helpful tips
It is a good practice to RESET a filter ID as soon as you want to define the filter. Filter ID settings do
survive until the unit is getting rebooted. A reset ensures the filter is back at the default which
implies "match ALL":
[email protected] ADX(debug-filter)#sp 2
[email protected] ADX(debug-filter-spec-2)#reset
The Brocade Virtual ADX is also able to store traces in PCAP format.
The Brocade Virtual ADX offers up to 32 MB of capturing space.
NOTE
To capture ingress and egress packets on the Brocade Virtual ADX using the MAC filter, specify the
internal base MAC instead of the chassis MAC. You can display the internal base MAC by using the
show server debug command.
Displaying global Layer 4 Brocade Virtual ADX configuration
To display global Layer 4 Brocade Virtual ADX configuration information, enter the following
command.
Virtual ADX(config)#show server global
Server Load Balancing - global parameters
Predictor
=
least-conn
Force-deletion
=
0
Reassign-threshold =
20
Reassign-limit
=
3
Ping-interval
=
2
Ping-retries
=
4
TCP-age
=
30
UDP-age
=
5
Sticky-age
=
30
TCP-syn-limit
=
65535
TCP-total conn
=
4233
Unsuccessful conn
=
0
ICMP-message
=
Disabled
Syntax: show server global
368
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Displaying global Layer 4 Brocade Virtual ADX configuration
B
Table 40 lists the displayed information.
TABLE 40
Global layer 4 configuration information
Field
Description
SLB Parameters
Predictor
The load balancing metric in effect on the Brocade Virtual ADX. The
predictor can be one of the following:
• least-conn (least connections)
• round-robin
• weighted-round-robin
• weighted
• enhanced-weighted
• least-local-conn (least local connections)
• least-local-sess (least local sessions)
The default is least-conn.
You can assign these metrics on a global basis and an individual virtual
server basis.
For more information, refer to “Load-balancing predictor” on page 8.
To change the predictor (globally or locally), refer to “Changing the
Load-Balancing Predictor Method” on page 21.
Force-deletion
The state of the force shutdown option. This option immediately shuts
down a server or service instead of waiting for existing connections to
end before shutting the server or service down. The state can be one of
the following:
• 0 – Disabled
• 1 – Enabled
Reassign-threshold
The number of contiguous inbound TCP-SYN packets sent to the server
that the server has not responded to.
The TCP SYN-ACK counter increments only when acknowledgments are
not received. Each time an expected TCP SYN-ACK is received, the
counter is cleared.
The default reassign threshold is 20 unacknowledged TCP SYN-ACKs.
The value can be from 6 through 4000. To change the reassign
threshold, refer to “Reassign threshold” on page 220
NOTE: You can modify this parameter to help minimize vulnerability to
TCP SYN attacks.
Reassign-limit
The number of missed TCP SYN packets the Brocade Virtual ADX will
accept before moving an inbound connection attempt to another server.
Layer 3 Health Check Parameters
Ping-interval
How often the Brocade Virtual ADX sends a Layer 3 IP ping to test the
basic health and reachability of the real servers. When enabled, this
parameter specifies the interval for the pings. To change the interval,
refer to “Modifying the ping interval and ping retries” on page 161.
Ping-retries
The number of times that the Brocade Virtual ADX resends a ping to a
real server that is not responding. Allowed values are from 2 through 10,
and the default is 4. To change this parameter, refer to “Modifying the
ping interval and ping retries” on page 161.
If the server still does not respond after the last retry, the Brocade
Virtual ADX marks the server FAILED and removes it from the load
balancing rotation.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
369
B
Displaying global Layer 4 Brocade Virtual ADX configuration
TABLE 40
Global layer 4 configuration information (Continued)
Field
Description
Global TCP/UDP Parameters
TCP-age
The number of minutes the Brocade Virtual ADX allows a TCP connection
to remain unused before closing the connection. The default is 30. To
change this parameter, refer to “Configuring TCP age” on page 239.
The value shown here is the global value. You can override this value for
an individual TCP/UDP port by modifying its port profile. Refer to
“Overriding the global TCP or UDP age” on page 192.
UDP-age
The number of minutes the Brocade Virtual ADX allows a UDP
connection to remain unused before closing the connection. The default
is 5. To change this parameter, refer to “Configuring UDP age” on
page 239.
The value shown here is the global value. You can override this value for
an individual TCP/UDP port by modifying its port profile. Refer to
“Overriding the global TCP or UDP age” on page 192.
Sticky-age
The number of minutes a sticky server connection can remain inactive
before aging out. The default is 5.
TCP-syn-limit
The maximum number of TCP SYN connections per second the Brocade
Virtual ADX is allowed to send to the real server. The default is 65535.
You can guard against TCP SYN attacks by changing this parameter to a
lower value. Refer to “Limiting the maximum number of TCP SYN
requests” on page 110.
TCP Connections Counters
TCP-total conn
The total number of TCP connections the Brocade Virtual ADX is
currently managing.
Unsuccessful conn
The number of client requests for a TCP port that the Brocade Virtual
ADX could not fulfill because the server was busy or down, or because
the port was not configured on the server.
ICMP Message Feature State
ICMP-message
370
The state of the ICMP message feature. The state can be one of the
following:
• Disabled – The Brocade Virtual ADX does not send ICMP
“Destination Unreachable” messages to a client that requests an
HTTP port that is on a busy or down server or that is not configured
on the server. This is the default.
• Enabled – The Brocade Virtual ADX sends ICMP “Destination
Unreachable” messages to clients when the requested HTTP port is
not available or not configured.
To change the state of this feature, refer to “Sending ICMP Port
Unreachable or Destination Unreachable messages” on page 113.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
B
Displaying real server information and statistics
Displaying real server information and statistics
Using the show server real command
Use the show server real command to view real IP addresses as well as configuration information
and basic statistics for all the real servers configured on the Brocade Virtual ADX.
To display configuration information for a specific real server, enter the show server real command
using its server name or IP address such as in the following example:
Virtual ADX(config)#show server real r6
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
HLD:held-down
Name: r6
State: Active
Cost: 0 IP:400::457:
Mac: 0000.855d.e2cd
Weight: 1/1
MaxConn: n/a
SrcNAT: not-cfg, not-op
DstNAT: not-cfg, not-op
Serv-Rsts: 0
Rx throughput: 190 Kbps
Tx throughput: 340 Kbps
tcp conn rate:udp conn rate = 9:0
Use local conn : No
Port
---default
http
St
-UNB
ACT
Ms
-0
0
Server
Total
1
CurConn TotConn
------- ------0
0
20
970
Rx-pkts
------0
4398
Tx-pkts
------0
4847
Rx-octet
-------0
563498
Tx-octet
-------0
607932
Reas
---0
0
0
4398
4847
563498
607932
0
970
Syntax: show server real server-name | ip-address
The server-name variable specifies the real server by name. Alternatively, the ip-address variable
may be used to specify the real server by its IP address.
Table 41 describes the information returned by the show server real command.
TABLE 41
Real server information
Field
Description
Server State Codes
State (St)
The possible values for the server state. The state of each real server is
shown by the State field, described in this table.
General Server Parameters
Name
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
The name of the real server. This is the name you assigned to the server
when you configured it on the Brocade Virtual ADX.
371
B
Displaying real server information and statistics
TABLE 41
Real server information (Continued)
Field
Description
State
The state of the real server, based on Layer 3 health checks. The state
can be one of the following states, also listed next to "Server State" at
the top of the show server real display:
• ACT: Active
• ENB: Enabled
• FAL: Failed
• TST: Test
• DIS: Disabled
• UNK: Unknown
• UNB: Unbind
• AWU: Await-unbind
• AWD: Await-delete
NOTE: HLD: Held-down. The value in this field is based on the results of
Layer 3 health checks, if enabled. The real server state can also
be seen in the State column in the show server session display.
To display the server state based on Layer 3 health checks, refer
to the State field in the show server session display.
372
Cost
The hop cost to reach the remote or cache server.
Mac
The real server MAC address or next hop MAC address for remote
servers.
Wt
The weight assigned to this server. The weight applies only if the
predictor (load balancing method) is “weighted”. Refer to “Unbinding all
application ports from virtual servers” on page 119.
SrcNAT
The configured and operational states of the source NAT feature. The
two states are separated by a colon (:). The configured state is shown
first, followed by the operational state. Each state can have one of the
following values:
• 0 – Disabled
• 1 – Enabled
DestNAT
The configured and operational states of the destination NAT feature.
The two states are separated by a colon (:). The configured state is
shown first, followed by the operational state. Each state can have one
of the following values:
• 0 – Disabled
• 1 – Enabled
Serv-Rsts
Number of resets sent by the real server for a TCP SYN packet forwarded
by Brocade Virtual ADX.
Rx throughput
Rate at which packets are received expressed in Kbps.
Tx throughput
Rate at which packets are transmitted expressed in Kbps.
tcp conn rate
Rate at which the server receives TCP connections.
udp conn rate
Rate at which a real or remote server receives UDP connections.
Use local conn
Not currently supported/valid for Brocade Virtual ADX.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Displaying real server information and statistics
B
Using the show server real detail command
Use the show server real detail command to view information not only about a specified real server,
but also information about the various ports configured on that server.
Virtual ADX(config)#sh serv real rs1 detail
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
HLD:held-down
Name: rs1
State: Enabled
Cost: 0 IP:192.168.5.3:
1
Mac: Unknown
Weight: 1/1
MaxConn: n/a
SrcNAT: not-cfg, not-op
DstNAT: not-cfg, not-op
Serv-Rsts: 0
Mem: Server: 2e09f26a
Dynamic: No
Fail port exist: Y
Rx throughput: 804 Kbps
Tx throughput: 1810 Kbps
tcp conn rate:udp conn rate = 10:20
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
max_conn = 2000000
fail time =
0, Vir IP 0.0.0.0
tcp conn rate:udp conn rate = 0:0, max tcp conn rate:max udp conn rate =
:0
Rx throughput: 0 Kbps
Tx throughput: 0 Kbps
BP max local conn configured No: 0 0 0 0 0 0
BP max conn percentage configured No: 0 0 0 0 0 0
Use local conn : No
http
ENB 0 0
500
2000
1000
300000
200000
max_conn = 2000000
fail time =
0, Vir IP 192.168.5.1
tcp conn rate:udp conn rate = 10:0, max tcp conn rate:max udp conn rate =
SIP TCP Current Connections = 0
Rx throughput: 144 Kbps
Tx throughput: 566 Kbps
BP max local conn configured No: 0 0 0 0 0 0
BP max conn percentage configured No: 0 0 0 0 0 0
Use local conn : No
Keepalive(G/L:On/Off):On
Table 42 describes the information returned by the show server real detail command. The fields
apply to all the TCP/UDP ports on the real servers.
For DNS, HTTP, and RADIUS ports, the server-specific health check information for the port is listed
under the port’s statistics. For information about the health check parameters, refer to “Changing
HTTP keepalive method, value, and status codes” on page 178.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
373
B
Displaying real server information and statistics
TABLE 42
Real server detail information
Field
Description
Port
The TCP/UDP port name or number. This field can have one of the
following values:
• default
• dns – The well-known name for port 53
• ftp – The well-known name for port 21. (Ports 20 and 21 both are
FTP ports but on the Brocade Virtual ADX, the name “ftp”
corresponds to port 21.)
• http – The well-known name for port 80
• imap4 – The well-known name for port 143
• ldap – The well-known name for port 389
• nntp – The well-known name for port 119
• ntp – The well-known name for port 123
• pop2 – The well-known name for port 109
• pop3 – The well-known name for port 110
• radius – The well-known name for udp port 1812
• smtp – The well-known name for port 25
• snmp – The well-known name for port 161
• ssl – The well-known name for port 443
• telnet – The well-known name for port 23
• tftp – The well-known name for port 69
• number – The port number, if the port is not one of those listed
above
St
The state of the port. The state can be one of the following:
• enabled
• failed
• test
• suspect
• graceful shutdown
• active
• unbnd
NOTE: If the state is unbnd, you have not bound the port to a virtual
server port.
374
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Displaying real server information and statistics
TABLE 42
B
Real server detail information (Continued)
Field
Description
Ms
The master port state. This field applies only to track ports and to ports
to which you have bound other TCP/UDP ports in many-to-one
configurations.
• For track ports, the state of the master port. When a port is
configured to track a master port, the Brocade Virtual ADX sends a
client’s request for the tracking port to the same real server as the
master port. Refer to “Track port group function” on page 44. The
example show real server output shown above assumes that port
500 is tracked by port 600. If port 500’s state changes, port 600’s
state also changes to match.
• For many-to-one TCP/UDP port binding, the state of the port that is
translated in the port binding between the real server and the
virtual server. The ports that are not translated follow the state of
the port that is translated. Refer to “Multiple port binding” on
page 69. In the example show real server output shown above,
assume that port 70 is untranslated and follows the state of port
http. If the http port’s state changes, port 70’s state also changes
to match.
This field can have one of the following values for the types of ports
listed above:
• 1 – Enabled
• 2 – Failed
• 3 – Test
• 4 – Suspect
• 5 – Graceful shutdown
• 6 – Active
For all other types of ports, the value is always 0.
CurConn
The number of client connections currently on the server. A connection
consists of two sessions, the client-to-server session and the
server-to-client session.
TotConns
The number of client connections on the server since the Brocade
Virtual ADX was last booted. A connection consists of two sessions, the
client-to-server session and the server-to-client session.
Rx-pkts
The number of packets the Brocade Virtual ADX has received from the
server.
Tx-pkts
The number of packets the Brocade Virtual ADX has sent to the server.
Rx-octet
The number of octets (bytes) the Brocade Virtual ADX has received from
the server.
Tx-octet
The number of octets (bytes) the Brocade Virtual ADX has sent to the
server.
Reas
The number of times the Brocade Virtual ADX has reassigned the
connection to another server in the rotation because the server that is in
use has not responded to two contiguous TCP SYNs from the client.
When this occurs, the Brocade Virtual ADX directs the client to another
server upon receiving the third SYN from the client.
NOTE: Windows 98 sends two TCP SYNs for each connection attempt.
NOTE: This statistic does not apply to Direct Server Return (Direct
Server Return).
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
375
B
Displaying real server information and statistics
TABLE 42
Real server detail information (Continued)
Field
Description
Rx throughput
Rate at which packets are received expressed in Kbps.
Tx throughput
Rate at which packets are transmitted expressed in Kbps.
Displaying real server keepalive statistics
Use the show server real keepalive command to view real server keepalive statistics:
Virtual ADX#show server real keepalive 8080 rs1
Port index 255
Real Server Name: rs1
Slot valid = TRUE
real port proto = TCP
Keepalive Enabled
TCP request = 3518128
TCP response timeout = 19
HTTP URL = “GET/health.html”
HTTP sent = 318805
HTTP received error = 26394
HTTP wait for response = FALSE
Server close = 10
Bring port down = 9
TCP RTT = 14000 us
Next slot index = 193
Real Port Status = ACTIVE
IP: 135.200.41.63
Real port no = 8080
Keepalive port proto = TCP/8080
TCP response = 318805
Received ok = 292385
Received timeout = 0
Status Code = 200
Current sent = 0
Total retries = 14
Appl RTT = 3300 us
Syntax: show server real keepalive port | server-name
Displaying real server connections per second statistics
Use the show server connection command to view real server connections per second (CPS):
Virtual ADX#show server connection
Avail. Sessions on MP
bp-1
bp-2
bp-3
bp-4
Avail.
Avail.
Avail.
Avail.
Session
Session
Session
Session
=
=
=
=
=
1999868
1999872
1999872
1999868
999888 Total Sessions on MP
Total
Total
Total
Total
Sessions
Sessions
Sessions
Sessions
=
=
=
=
=
2000000
2000000
2000000
2000000
Total C->S Conn
=
97920 Total S->C Conn
=
Total Reassign
=
0 Unsuccessful Conn
=
last conn rate
=
29 max conn rate
=
last TCP attack rate =
0 max TCP attack rate =
SYN def RST
=
0 SYN flood
=
Server State - 1:enabled, 2:failed, 3:test, 4:suspect, 5:grace_dn,
Real Server
rs1
r6
State
1
6
CurrConn
0
240
TotConn
0
97920
CurrRate
0
30
1000000
0
0
0
0
0
6:active
MaxRate
0
40
Syntax: show server connection
376
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Displaying virtual server information and statistics
B
Displaying virtual server information and statistics
Use the show server virtual command to view information about the virtual servers configured on
the Brocade Virtual ADX.
To display configuration information for a specific virtual server, enter the show server virtual
command using its server name such as in the following example:
Virtual ADX(config)#show server virtual v6
Virtual Servers Info
Name: v6
Pred: round-robin
VIP state: healthy
Rx pkts:
Rx bytes:
Rx PPS:
Rx Throughput:
tcp-conn-rate:
CPS:
Note: The above
Port
---default
http
State
----enabled
enabled
Port
---default
http
Rx-pkts
------0
0
State: Enabled IF DWN
ACL-Id: 0
IP:400::456:
TotalConn: 0
0
Tx pkts:
0
Tx bytes:
0
Tx PPS:
0
Kbps
Tx Throughput:
0
udp-conn-rate:
0
CurrConn:
statistics lag by 1 second
Sticky
-----NO
NO
Concur
-----NO
NO
Tx-pkts
------0
0
Proxy
----NO
NO
Rx-octet
-------0
0
DSR
--NO
NO
CurConn
------0
0
0
0
0
0
0
0
TotConn
------0
0
1
Kbps
PeakConn
-------0
0
Tx-octet
-------0
0
Syntax: show server virtual Virtual-server-name|Virtual-server-IP-address virtual-port
The Virtual-server-name variable specifies the virtual server by name. Alternatively, the
Virtual-server-IP-address variable can be used to specify the IP address of the virtual server. The
virtual-port variable can be used to specify a particular port on the virtual server. For more
information, see “Displaying a list of failed servers” on page 380.
Table 43 describes the different types of information that can be viewed using the show virtual
server command:
TABLE 43
Virtual server information
Field
Description
General Server Parameters
Name
State
IP
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
The name of the virtual server. This is the name you assigned to the server when you
configured it on the Brocade Virtual ADX.
The status of the virtual server. The status can be one of the following:
Enabled
Disabled
•
•
The IP address of the virtual server.
If you configured a host range of VIPs on the server, the number following the IP address
(after the colon) is the number of hosts on the server. In the example above, the VIP has
a host range of 4 addresses.
377
B
Displaying virtual server information and statistics
TABLE 43
378
Virtual server information (Continued)
Field
Description
ACL ID
Displays the ID of the Access Control List (ACL) policy bound to the
virtual server
Predictor
The load balancing predictor the Brocade Virtual ADX uses to balance traffic among the
real servers bound to this virtual server. The predictor can be one of the following:
• least-conn
• round-robin
• weighted-round-robin
• weighted
• enhanced-weighted
You can assign these metrics on a global basis and an individual virtual server basis.
For more information, refer to “Load-balancing predictor” on page 8.
To change the predictor (globally or locally), refer to “Changing the Load-Balancing
Predictor Method” on page 21.
Tot-Conn
The number of client connections on the server since the Brocade Virtual ADX was last
booted or restarted. A connection consists of two sessions, the client-to-server session
and the server-to-client session.
VIP state
Displays the health of the virtual server. The health status can be
one of the following:
• Healthy — Indicates the virtual server is healthy.
• Not healthy — Indicates the virtual server is not healthy.
Rx Pkts
Displays the total number of packets received by the virtual server.
Rx bytes
Displays the total number of bytes received by the virtual server.
Rx PPS
Displays the total number of packets per second received by the virtual server.
Rx throughput
The rate of throughput received in Kbps.
Tx Pkts
Displays the total number of packets transmitted by the virtual server.
Tx bytes
Displays the total number of bytes transmitted by the virtual server.
Tx PPS
Displays the total number of packets per second transmitted by the virtual server.
Tx throughput
The rate of throughput transmitted in Kbps.
tcp-conn-rate
The TCP connection rate.
udp-conn-rate
The UDP connection rate.
CPS
The connection rate measured in seconds.
CurrConn
Displays the number of current open connections on the virtual server.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Displaying virtual server information and statistics
TABLE 43
B
Virtual server information (Continued)
Field
Description
TCP/UDP Port Information and Statistics
Port
State
The TCP/UDP port name or number. This field can have one of the following values:
default
dns –The well-known name for port 53
ftp – The well-known name for port 21. (Ports 20 and 21 both are FTP ports but on
the Brocade Virtual ADX, the name “ftp” corresponds to port 21.)
• http – The well-known name for port 80
• imap4 – The well-known name for port 143
• ldap – The well-known name for port 389
• nntp – The well-known name for port 119
• ntp – The well-known name for port 123
• pop2 – The well-known name for port 109
• pop3 –The well-known name for port 110
• radius – The well-known name for udp port 1812
• radiuso – UDP port 1645, which is used in some older RADIUS implementations
instead of port 1812
• smtp – The well-known name for port 25
• snmp – The well-known name for port 161
• ssl – The well-known name for port 443
• telnet – The well-known name for port 23
• tftp – The well-known name for port 69
• number – The port number, if the port is not one of those listed above
•
•
•
The state of the port. The state can be one of the following:
enabled
failed
test
suspect
graceful shutdown
active
unbnd
•
•
•
•
•
•
•
NOTE: If the status is unbnd, you have not bound the port to a real server port.
Sticky
Whether the port is “sticky”. When a port is sticky, the Brocade Virtual ADX uses the
same real server for multiple requests from the same client for the port. For non-sticky
ports, the Brocade Virtual ADX load balances the requests and thus does not
necessarily send them all to the same real server.
This parameter can have one of the following values:
• NO
• YES
Concur
Whether the port is configured for concurrent connections. A port configured to allow
concurrent connections can have more than one connection open to the same client at
the same time.
Proxy
CurConn
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Displays the state of the proxy. The state can be one of the following:
No
Yes
•
•
Displays the state of the concurrent sessions that are additionally
opened. The state can be one of the following:
• No
• Yes
379
B
Displaying a list of failed servers
TABLE 43
Virtual server information (Continued)
Field
Description
DSR
Displays the state of the Direct Server Return (DSR) in the virtual server port. The state
can be one of the following:
• No
• Yes
TotConn
The number of client connections on the server since the Brocade Virtual ADX was
booted. A connection consists of two sessions, the client-to-server session and the
server-to-client session.
PeakConn
The highest number of connections the VIP has had at the same time.
RX-pkts
Displays the number of packets the port as received from
the server.
Tx-pkts
Displays the number of packets the port as transmitted from
the server.
Rx-octet
The number of octets (bytes) the port has received from the server.
Tx-octet
The number of octets (bytes) the port has sent to the server.
Displaying a list of failed servers
Use show server failed to display all servers that are not in Active or Disabled state. Only servers in
the failed state are included in the display.
Example
SLB-Virtual ADX#show server failed
Real servers in Failed state:
Total failed servers: 3
Name: MyServer01 IP:192.168.160.91 State: Enabled
Name: MyServer02 IP:192.168.160.92 State: Enabled
Name: MyServer03 IP:192.168.160.93 State: Enabled
Syntax: show server failed
Displaying a list of failed ports
Use show server port failed to display all server ports that are not in Active or Disabled state. It also
shows the servers to which the ports belong.
Example
SLB-Virtual ADX#show server port failed
Real ports in Failed state:
Total failed servers:3 Total failed ports:7
Name: MyServer01 IP:192.168.160.91 State: Enabled
Port http: Failed
Port 8081: Failed
Port ftp: Failed
Name: MyServer02 IP:192.168.160.92 State: Enabled
Port 8082: Failed
Port http: Failed
380
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Displaying port-binding information
B
Name: MyServer03 IP:192.168.160.93 State: Enabled
Port 8083: Failed
Port http: Failed
Syntax: show server port failed
Displaying port-binding information
Using the “show server bind” command
To display port-binding information, enter the following command.
SLB-Virtual ADX#show server bind
http -------> s43:
s60:
ftp -------> s43:
s60:
70 -------> s43:
s60:
Virtual Server Name: v105,
telnet -------> s60:
ftp -------> s60:
http -------> s60:
dns -------> s60:
tftp -------> s60:
10.157.23.43, http
10.157.23.60, 8080
10.157.23.43, ftp
10.157.23.60, ftp
10.157.23.43, 70
10.157.23.60, 70
IP: 10.157.23.105
10.157.23.60, 300
10.157.23.60, 200
10.157.23.60, 100
10.157.23.60, 400
10.157.23.60, 500
Syntax: show server bind
The display lists the port bindings for each virtual server configured on the Brocade Virtual 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.
In the example, two virtual servers are configured on the Brocade Virtual ADX, v100 and v105. The
first set of rows in the example output is for virtual server v100, with VIP 10.157.23.100.
The rows below the first row list the real servers and ports to which the virtual server’s ports are
bound. The rows are grouped by port type. The first two rows after the first row in the example
above list the port bindings for the virtual server’s HTTP port. In this case, the virtual server is
bound to an HTTP port on two real servers, s43 and s60. The port name or number on the real
server is listed after the real server’s IP address. In this example, the HTTP port to which v100 is
bound on s43 is "http", which is the well-known name for the port. The virtual server’s HTTP port is
bound to port 8080 on real server s60.
Using the “show server session” command
You can also display port-binding information by entering the show server session command.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
381
B
Displaying port-binding information
Virtual ADX#rconsole 1 1
Virtual ADX1/1#show server session
Avail. Sessions
Hash size
=
=
1999998
200001
Total Sessions
=
2000000
Total C->S Conn
=
0 Total S->C Conn
=
0
Total Reassign
=
0 Unsuccessful Conn
=
0
Server State - 0: diasbled, 1:enabled, 2:failed, 3:test, 4:suspect, 5:grace_dn,
6:active
Real Server
St CurrConn
TotConn
TotRevConn CurrSess
PeakConn
rs1
1
0
0
0
0/0/0
0
Syntax: show server session
Table 44 lists the displayed information for bound ports.
TABLE 44
Field descriptions for the show server session command
Field
Description
Global Statistics
Avail. Sessions
The number of sessions that are still available for use. By default, the
Brocade Virtual ADX is configured to allow the maximum number of
sessions it can support. If you need to decrease the number of sessions
supported, refer to “Configuring the maximum number of active
sessions” on page 236.
Total Sessions
The number of sessions that are currently in use.
Total C->S Conn
The number of connections initiated by clients.
Total S->C Conn
The number of connections initiated by servers. Generally this value is 0
unless the client is using FTP or another application that causes the
server to initiate connections.
Total Reassign
The number of unacknowledged TCP SYN-ACKs on all the real servers
combined. When a server reaches the maximum number of
unacknowledged TCP SYN-ACKs allowed by the Brocade Virtual ADX (the
reassign threshold), the Brocade Virtual ADX marks that server FAILED
and removes it from the load balancing rotation.
The TCP SYN-ACK counter increments only when acknowledgments are
not received. Each time an expected TCP SYN-ACK is received from a
real server, the counter is cleared for that server, thus reducing the total
count.
For more information, refer to “Reassign threshold” on page 220.
NOTE: This statistic does not apply to Direct Server Return (Direct
Server Return).
382
Unsuccessful Conn
The number of connection attempts by clients or servers that were
unsuccessful.
Fast-aged: total
If the fast-age threshold is configured, the total number of sessions that
were aged out because the number of free sessions dropped below the
fast-age threshold, in addition to the number of these sessions that were
aged out in the last 60 seconds.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Displaying port-binding information
TABLE 44
B
Field descriptions for the show server session command (Continued)
Field
Description
Random-aged: total
If the random threshold is configured, the total number of sessions that
were aged out at random because the number of free sessions dropped
below the random threshold, in addition to the number of sessions that
were aged out randomly in the last 60 seconds.
Refer to “Configuring fast session aging” on page 237 for more
information on the fast-age and random thresholds.
Statistics for Individual Real Servers
Server State
The possible values for the server state. The state of each real server is
shown by the State field.
Real Server
The name of the real server. This is the name you gave the server when
you configured it.
St
The state of the real server. The state can be one of the states listed by
"Server State" at the top of the display.
NOTE: The value in this field is based on the results of Layer 3 health
checks. To display the server state based on Layer 4 or Layer 7
health checks, refer to the State field in the show server real
display. (Refer to “Displaying real server information and
statistics” on page 371.)
CurConn
The number of client connections currently on the server. A connection
consists of two sessions, the client-to-server session and the
server-to-client session.
TotConn
The number of client connections on the server since the Brocade
Virtual ADX was last booted or restarted. A connection consists of two
sessions, the client-to-server session and the server-to-client session.
Tot RevConn
The total number of connections initiated by the server to a client.
CurrSess
The number of sessions currently open on the Brocade Virtual ADX.
PeakConn
The highest number of simultaneous connections the Brocade Virtual
ADX has managed since it was last booted or restarted.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
383
B
Displaying packet traffic statistics
Displaying packet traffic statistics
In theory, each BP sends its counters to the MP. The MP then aggregates all the counters from each
BP and synthesizes them into tables. However in reality, not all the BP counters are currently
implemented on the MP.
The MP correctly shows most of the commonly used counters. For some counters, including show
server traffic and show server debug, you should use the rconsole command in the BPs and issue
show commands from there.
Use clear server traffic to clear traffic statistics for real and virtual servers.
Virtual ADX#rconsole 1 1
Virtual ADX1/1#show server traffic
Client->Server
=
0 Server->Client
Drops
=
0 Aged
Fw_drops
=
0 Rev_drops
FIN_or_RST
=
0 old-conn
Disable_drop
=
0 Exceed_drop
Stale_drop
=
0 Unsuccessful
SYN def/proxy RST
=
0 Server Resets
Out of Memory
=
0 Out of Memory
last conn rate
=
0 max conn rate
last TCP attack rate =
0 max TCP attack rate
fast vport found
=
0 fast vport n found
Fwd to non-static FI =
0 Dup stale SYN
TCP forward FIN
Fast path FWD FIN
Fast path SLB SYN
Duplicate SYN
TCP ttl FIN recvd
Sessions in DEL_Q
Fwd sess not found
Sess rmvd from delQ
Fragment buf full er
New sess sync sent
L4 msg sent
brocade packet sent
TCP SYN received
TCP SYN to MP
TCP SYN ACK received
TCP pkt received
TCP pkt to MP
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
=
=
=
=
=
=
=
=
=
=
=
=
0
0
0
0
0
0
0
0
0
0
0
0
TCP reverse FIN
Fast path REV FIN
Dup SYN after FIN
Duplicate sessions
TCP ttl reset recvd
Sess force deleted
sess already in delQ
=
=
=
=
=
=
=
0
0
0
0
0
0
0
Incoming TCP cksum e
New sess sync recvd
L4 msg recvd
ipc packet sent
TCP SYN dropped
TCP SYN ACK to MP
TCP SYN ACK dropped
TCP pkt dropped
=
=
=
=
=
=
=
=
0
0
0
8
0
0
0
0
Syntax: show server traffic
Table 45 lists the displayed information for bound ports.
TABLE 45
384
Field descriptions for the show server traffic command
Field
Description
Client->Server
Number of packets sent from clients to servers.
Server->Client
Number of packets sent from servers to clients.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Displaying packet traffic statistics
TABLE 45
B
Field descriptions for the show server traffic command (Continued)
Field
Description
Drops
Number of packets dropped by the Brocade Virtual ADX. This statistic
includes the following:
• TCP Resets – Resets sent by the Brocade Virtual ADX
• Forward Resets – Resets from the client
• Unsuccessful requests – Requests sent to a TCP or UDP port that is
not bound to the request’s destination VIP
Aged
Number of TCP and UDP sessions that the Brocade Virtual ADX closed
because they aged out. A session ages out when the age timer
configured on the Brocade Virtual ADX expires. For more information,
refer to “Configuring TCP age” on page 239 and “Configuring UDP age”
on page 239.
Fw_drops
Number of client-to-server packets the Brocade Virtual ADX has
dropped. If this statistic is high, there might not be a session entry. This
scenario can occur under the following circumstances:
• If the session is terminated normally but the client sends another
RESET.
• If the maximum number of sessions has been reached.
• If all the real servers are down.
Rev_drops
Number of server-to-client packets the Brocade Virtual ADX has
dropped. If this statistic is high, there might not be a session entry. This
can occur for the same reasons as listed for the Fw_drops field.
FIN_or_RST
Number of FINs or RSTs passing through (forward and reverse) a
non-optimized path inside the Brocade Virtual ADX. All traffic is
optimized by default except FTP control, streaming protocol control, and
DNS traffic.
old-conn
fast vport found
Number of successful virtual-port searches using an improved (faster)
method.
Duplicate SYN
When the Brocade Virtual ADX receives a SYN packet for a session that
is already listed in the session table (show server sessions), the Brocade
Virtual ADX has received a Duplicate SYN. The counter is then
incremented by 1.
TCP ttl reset recvd
Total (ttl) number of TCP resets received in both the forward and reverse
direction. This counter applies to both optimized (FPGA assisted) and
non optimized traffic paths.
Disable_drop
Number of packets the Brocade Virtual ADX dropped because they were
sent by a client to a VIP port that is bound to a real server port that is
currently disabled.
Exceed_drop
Number of packets dropped by the Brocade Virtual ADX because the TCP
SYN limit on the real servers had been reached. The TCP SYN limit is a
configurable parameter that allows you to protect servers against TCP
SYN attacks by limiting the number of TCP SYN requests the Brocade
Virtual ADX can send to the server each second.
For more information, refer to “Configuring the maximum number of
active sessions” on page 236.
Stale_drop
Number of TCP SYN packets the Brocade Virtual ADX dropped because
they matched a stale session entry.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
385
B
Displaying configuration information
TABLE 45
Field descriptions for the show server traffic command (Continued)
Field
Description
Unsuccessful
Number of packets that were dropped for one of the following reasons:
A deny filter configured on the Brocade Virtual ADX matched the
packet, causing the Brocade Virtual ADX to drop the packet.
• A client requested a TCP/UDP port that is not bound on the VIP.
•
last conn rate
Rate of TCP traffic per second. This counter includes all TCP traffic,
including TCP SYN DoS attacks.
max conn rate
Peak rate of TCP traffic (per second) encountered on this device
last TCP attack rate
Rate of TCP Dos attacks per second. This rate is delayed by 1 to 2
minutes. This field displays in releases 09.0.00S and later.
max TCP attack rate
Peak rate of TCP DoS attacks (per second) encountered on this device.
This rate is delayed by 1 to 2 minutes.
Displaying configuration information
This section contains the following sections:
•
•
•
•
“Showing aggregate health of tracked ports” on page 386
“Auto repeat of show command output” on page 387
“Clearing all session table entries” on page 387
“Clearing the connections counter” on page 388
Showing aggregate health of tracked ports
If a real server port goes down, none of the track port groups on the real server are considered for
load balancing. To check the health of track-group state, use the following command.
Virtual ADX(config)#show track-group-state
This command displays the state of all configured track groups on the Brocade Virtual ADX, as
shown in the following example.
Virtual ADX#show track-group-state
Virtual Server
track-group
v1
v2
v3
state
80 3030 21
443 80
80 443
SUSPECT
UP
SUSPECT
NOTE
The state can be either UP or SUSPECT, depending on the state of the real server ports that are
bound to track-group ports. The track-group state is never in a DOWN state.
386
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Displaying configuration information
B
Auto repeat of show command output
The repeat-show “cmd-to-show” interval command is a regular show command that is repeated at
periodic intervals. You can issue this command from any mode (user, privileged, or configuration)
from a Telnet session, SSH session, or a console.
To repeat the show command display at specific intervals, use the following command (on MP
only).
Virtual ADX#repeat-show “show server session” 8
This example displays the results of a show server session command every 8 seconds.
Syntax: repeat-show “cmd-to-show” interval
The “cmd to show” variable is the actual command display to be shown repeatedly. The double
quotes allow the command to accommodate white space.
The interval variable specifies the interval for repeated displays (range from 1 to 60 seconds).
To stop the repeat-show command in the current session, use the following command (on MP only).
Virtual ADX#stop-repeat-show
Syntax: stop-repeat-show
NOTE
The stop-repeat-show command stops all the repeat-show commands issued in the session.
The repeat-show commands are very similar to the traceroute and stop-traceroute commands.
When you end a Telnet session, this command cleans up the Telnet session and issues the
stop-repeat-show command.
Clearing all session table entries
To clear all session table entries for a deleted real server, enter the clear server session command.
Syntax: clear server session name [name [name [name]]]
The name variable specifies the name of the real server. You can enter up to four real server
names. It can take up to three minutes for the command to take effect. This command is supported
only on the MP (the main processor management session).
When you delete a real server, the Brocade Virtual ADX attempts to clear all the session entries for
that real server from the session table. The Brocade Virtual ADX requires all the sessions to be
cleared from the table before performing these operations. If you use the force shutdown option
(server force-delete command), the Brocade Virtual ADX ends the sessions within one minute.
Otherwise, the Brocade Virtual ADX allows active sessions to end normally before removing them.
When you enter the command to delete a real server (no server real name), the Brocade Virtual
ADX changes the server’s state to "await_delete". The real server remains in this state until all its
sessions are cleared from the session table. Occasionally, the Brocade Virtual ADX cannot clear all
of a deleted real server’s sessions from the table. When this occurs, to safely delete the real server
from the Brocade Virtual ADX, Brocade recommends the following procedure.
1. Under the real server, disable the application ports.
2. Check to confirm that the current connections in the session come down to zero (in show
server real output).
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
387
B
Displaying configuration information
3. Under VIP, unbind the real server.
4. Delete the real server.
To complete deletion of the server in this case, enter the clear server session name command after
entering the no server real name command.
Example
Virtual ADX(config)#no server real rs1
Virtual ADX(config)#show server real rs1
Real Servers Info
Name : rs1
IP:10.2.3.4
Range:1
State:await_delete
Least-con Wt:0
Resp-time Wt:0
Port
---8080
default
State
----unbnd
unbnd
Ms
-0
0
CurConn
------0
0
TotConn
------0
0
Rx-pkts
------0
0
Mac-addr: Unknown
Max-conn: n/a
Tx-pkts
------0
0
Server Total
0
0
0
0
Virtual ADX(config)#clear server session rs1
Rx-octet
-------0
0
Tx-octet
-------0
0
Reas
---0
0
0
0
0
The no server real command deletes real server "rs1". The show server real command displays the
states of the real servers. Notice that rs1 is still listed as a valid real server, and has the state
"await_delete". If the no server real command does not list the deleted server, the server has been
completely deleted.
If the server continues to be listed with the "await_delete" state after several minutes, enter the
clear server session command to finish deleting the server. The clear server session command
deletes the remaining sessions for rs1, after which the Brocade Virtual ADX can finish deleting the
server. You can enter this command immediately after entering the no server real command. You
do not need to wait for any sessions to end normally.
NOTE
The clear server session real server command is used to clear sessions for a specific real server,
regardless of the server in "await_del" or "await_u" state.
If you execute the clear server all-session real-server command from the MP, it clears all sessions
in the MP and BP. If you use this command from the BP, it clears only the BP sessions.
The real-server variable is optional in the clear server all-session command and specifies the real
server.
Clearing the connections counter
You can clear the counter for real servers only or virtual servers only.
To clear the total connections counter (“Tot-Conn”) in show commands for real and virtual servers,
enter a command such as the following.
Virtual ADX(config-vs-Brocade)#clear server tot-conn virtual
Syntax: clear server tot-conn real | virtual
388
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Appendix
Acknowledgements
C
This appendix presents the acknowledgements for portions of code from various vendors that are
included in the Brocade devices covered in this manual.
OpenSSL license
Copyright (c) 1998-2001 The OpenSSL Project. All rights reserved.
1. Redistribution and use in source and binary forms, with or without modification, are permitted
provided that the following conditions are met:
2. Redistributions of source code must retain the above copyright notice, this list of conditions
and the following disclaimer.
3. Redistributions in binary form must reproduce the above copyright notice, this list of conditions
and the following disclaimer in the documentation or other materials provided with the
distribution.
4. All advertising materials mentioning features or use of this software must display the following
acknowledgment: “This product includes software developed by the OpenSSL Project for use in
the OpenSSL Toolkit. (http://www.openssl.org/)”
5. The names “OpenSSL Toolkit” and “OpenSSL Project” must not be used to endorse or promote
products derived from this software without prior written permission. For written permission,
please contact [email protected]
6. Products derived from this software may not be called “OpenSSL” nor may “OpenSSL” appear
in their names without prior written permission of the OpenSSL Project.
7.
Redistributions of any form whatsoever must retain the following acknowledgment: “This
product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit
(http://www.openssl.org/)”
THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT “AS IS'' AND ANY EXPRESSED OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT
SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY
WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
389
C
Cryptographic software
Cryptographic software
This product includes cryptographic software written by Eric Young ([email protected]). This
product includes software written by Tim Hudson ([email protected]).
Original SSLeay License
Copyright (C) 1995-1998 Eric Young ([email protected])/. All rights reserved.
This package is an SSL implementation written by Eric Young ([email protected]). The
implementation was written so as to conform with Netscape’s SSL.
This library is free for commercial and non-commercial use as long as the following conditions are
adhered to. The following conditions apply to all code found in this distribution, be it the RC4, RSA,
lhash, DES, etc., code; not just the SSL code. The SSL documentation included with this
distribution is covered by the same copyright terms except that the holder is Tim Hudson
([email protected]).
Copyright remains Eric Young's, and as such any Copyright notices in the code are not to be
removed. If this package is used in a product, Eric Young should be given attribution as the author
of the parts of the library used. This can be in the form of a textual message at program startup or
in documentation (online or textual) provided with the package.
1. Redistribution and use in source and binary forms, with or without modification, are permitted
provided that the following conditions are met:
2. Redistributions of source code must retain the copyright notice, this list of conditions and the
following disclaimer.
3. Redistributions in binary form must reproduce the above copyright notice, this list of conditions
and the following disclaimer in the documentation or other materials provided with the
distribution.
4. All advertising materials mentioning features or use of this software must display the following
acknowledgement:
“This product includes cryptographic software written by Eric Young ([email protected])” The
word 'cryptographic' can be left out if the routines from the library being used are not
cryptographic related:-).
5. If you include any Windows specific code (or a derivative thereof) from the apps directory
(application code) you must include an acknowledgement:
“This product includes software written by Tim Hudson ([email protected])”
THIS SOFTWARE IS PROVIDED BY ERIC YOUNG “AS IS'' AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR
OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
390
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Original SSLeay License
C
The license and distribution terms for any publicly available version or derivative of this code
cannot be changed. i.e. this code cannot simply be copied and put under another distribution
license [including the GNU Public License.]
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
391
C
392
Original SSLeay License
Brocade Virtual ADX Server Load Balancing Guide
53-1003247-01
Download
Random flashcards
Pastoralists

20 Cards

Radioactivity

30 Cards

Nomads

17 Cards

Marketing

46 Cards

Create flashcards