53-1003452-01
November 2014
Brocade ServerIron ADX
Server Load Balancing Guide
Supporting Brocade ServerIron ADX version 12.5.02
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: info@brocade.com
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: china-info@brocade.com
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: emea-info@brocade.com
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: china-info@brocade.com
Contents
Preface
Document conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Text formatting conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Command syntax conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Notes, cautions, and warnings . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Brocade resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Contacting Brocade Technical Support . . . . . . . . . . . . . . . . . . . . . . . 15
Brocade customers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Brocade OEM customers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Document feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Chapter 1
Features and Enhancements
Release 12.5.02 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Release 12.5.01a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Release 12.5.01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Release 12.5.00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Release 12.4.00a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Release 12.4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Release 12.3.01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Release 12.3.00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Release 12.2.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Release 12.2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Release 12.1.00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Chapter 2
Server Load Balancing
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
How SLB works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Load-balancing predictor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Sticky connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Application port groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Concurrent connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Remote Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Direct Server Return . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
ServerIron ADX Server Load Balancing Guide
53-1003452-01
1
Configuring basic SLB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Configuration guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Defining the real servers and real application ports. . . . . . . . . 39
Defining a virtual server (VIP) . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Defining a virtual server name . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Binding virtual and real servers . . . . . . . . . . . . . . . . . . . . . . . . . 41
Changing the Load-Balancing Predictor Method . . . . . . . . . . . . . . . 42
Configuring a weighted predictor . . . . . . . . . . . . . . . . . . . . . . . . 43
Configuring dynamic weighted predictor . . . . . . . . . . . . . . . . . . 44
Configuring the smooth factor . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Real server ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Disabling or re-enabling application ports . . . . . . . . . . . . . . . . . 48
Globally disabling application ports . . . . . . . . . . . . . . . . . . . . . . 48
Disabling SLB to a server when an application goes down . . . 49
Slow-start mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Enabling or disabling the keepalive health check . . . . . . . . . . . 50
Configuring a real port as TCP only or UDP only . . . . . . . . . . . . 50
Configuring a stateless port . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Adding a source IP address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Source NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Enabling source NAT globally . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Enabling source NAT on a real server. . . . . . . . . . . . . . . . . . . . . 57
Configuring a shared source IP address for NAT . . . . . . . . . . . . 57
Configuring shared source NAT IP addresses
within a VIP group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Source NAT to packets from specified source IP addresses. . . 58
Client subnet based source NAT . . . . . . . . . . . . . . . . . . . . . . . . . 58
Minimizing source-IP and source-NAT-IP requirements
for large deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
IPv6 Source NAT ACL Support . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Increasing the maximum of source-NAT IP addresses . . . . . . . 62
Remote server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Sticky and concurrent connections . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Configuring sticky ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Configuring stickiness based on client’s subnet . . . . . . . . . . . . 65
Setting the sticky age . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Preserving a sticky session when the health check is down . . 66
Allowing sticky ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Increasing the sticky-age per VIP longer than 60 minutes . . . . 67
Sticky connection return from backup server to primary . . . . . 68
Group sticky: Layer 4 SLB to server group . . . . . . . . . . . . . . . . . 69
Enabling a concurrent port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Configuring virtual source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Application port grouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Tracking primary ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Track port group function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
2
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Primary and backup servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Designating a real server as a backup . . . . . . . . . . . . . . . . . . . . 78
Enabling a VIP to use the primary and backup servers. . . . . . . 78
Configuration example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Designating a real server port as a backup . . . . . . . . . . . . . . . . 80
Per server based real server backup . . . . . . . . . . . . . . . . . . . . . 81
Configuring Direct Server Return . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Configuring L2 Direct Server Return. . . . . . . . . . . . . . . . . . . . . . 85
Configuring L3 Direct Server Return. . . . . . . . . . . . . . . . . . . . . . 90
Displaying server information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Port ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Defining a port range. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Using a port range under a real server definition . . . . . . . . . . . 96
Using a port range under a virtual server definition . . . . . . . . . 96
Binding a port range for virtual ports to a real server. . . . . . . . 96
Defining port profile for port range. . . . . . . . . . . . . . . . . . . . . . . 97
Displaying a list of port ranges . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Multiple port binding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Direct binding of multiple ports . . . . . . . . . . . . . . . . . . . . . . . . . 99
Port aliases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .101
Real server groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105
Defining a real server group . . . . . . . . . . . . . . . . . . . . . . . . . . .105
Associating a real server with a real server group. . . . . . . . . .105
Binding a real server group to a virtual server. . . . . . . . . . . . .106
Showing real server groups. . . . . . . . . . . . . . . . . . . . . . . . . . . .106
Disabling or deleting VIPs and real ports . . . . . . . . . . . . . . . . . . . . 107
Disabling VIPs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Disabling a real server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Disabling or re-enabling an application port . . . . . . . . . . . . . . 107
Globally disabling real and virtual ports. . . . . . . . . . . . . . . . . .108
Deleting a VIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .108
Enabling force-delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109
Real server shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .110
Port holddown timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111
Hash-based SLB with server persistence . . . . . . . . . . . . . . . . . . . .114
Persistent hash table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114
Clear vs reassign mechanisms . . . . . . . . . . . . . . . . . . . . . . . . .114
Enabling persistent hashing . . . . . . . . . . . . . . . . . . . . . . . . . . .115
Enabling the clear-on-change mechanism . . . . . . . . . . . . . . . .115
Enabling the reassign-on-change mechanism. . . . . . . . . . . . .116
Configuring the reassign threshold and duration . . . . . . . . . .116
Reassignment sequence and example . . . . . . . . . . . . . . . . . . 117
Keeping the persistent hash table unchanged . . . . . . . . . . . .119
Real server failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119
Displaying persistent hash table entry and statistics . . . . . . .120
Clearing the hit count for the persistent hash table . . . . . . . .121
Clearing the persistent hash table . . . . . . . . . . . . . . . . . . . . . .121
Reassigning a persistent hash table entry. . . . . . . . . . . . . . . .121
Displaying hash bucket counters . . . . . . . . . . . . . . . . . . . . . . .122
ServerIron ADX Server Load Balancing Guide
53-1003452-01
3
SLB spoofing configuration and support. . . . . . . . . . . . . . . . . . . . .123
Policy-based SLB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123
Miscellaneous options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137
Changing a real server’s IP address . . . . . . . . . . . . . . . . . . . . .137
Adding a description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .138
Configuring a local or remote real server . . . . . . . . . . . . . . . . .138
Defining the maximum number of connections . . . . . . . . . . .138
Setting a logging threshold for connection rate. . . . . . . . . . . .139
Configuring a TCP MSS value at the global level . . . . . . . . . . . 141
Configuring a TCP MSS value for a virtual server . . . . . . . . . . 141
Configuring a TCP MSS value at the virtual server port level .142
Configuring a TCP MSS value at the TCP profile level . . . . . . .142
Support for TCP Window Scale option in TCP header . . . . . . .142
Binding a TCP profile to a virtual port and
response rewrite policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143
Configuring jumbo frame support. . . . . . . . . . . . . . . . . . . . . . .143
Limiting the maximum number of TCP SYN requests . . . . . . .146
Configuring the connection rate . . . . . . . . . . . . . . . . . . . . . . . .146
Configuring hardware forwarding of pass-through traffic . . . . 147
Disabling port translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .148
Traffic distribution among BPs . . . . . . . . . . . . . . . . . . . . . . . . .149
Including the server client port in hash calculations . . . . . . .149
Sending ICMP Port Unreachable or Destination Unreachable
messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .150
Sending a TCP RST to a client that requests unavailable
applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .150
Sending a TCP RST when TCP session entry ages out . . . . . .151
Disabling TCP RST message when a real server goes down
during an open session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .151
Disabling TCP RST message on maximum connections . . . . .152
Decrement counters in deletion queue . . . . . . . . . . . . . . . . . .152
Optimized fast-path SLB processing. . . . . . . . . . . . . . . . . . . . .152
Configuring TCP fast aging . . . . . . . . . . . . . . . . . . . . . . . . . . . .155
Server opt-enable-route recalculation . . . . . . . . . . . . . . . . . . .155
Enabling use of the client MAC address. . . . . . . . . . . . . . . . . .156
Enabling transparent VIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .156
Enabling SYN ACK threshold . . . . . . . . . . . . . . . . . . . . . . . . . . .156
Replacing the source MAC address of the packet. . . . . . . . . .156
Cloning real servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .157
Configuring a host range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .157
Unbinding all application ports from virtual servers . . . . . . . .158
Identifying VIP port as TCP only or UDP only . . . . . . . . . . . . . .159
Enabling fast aging for UDP sessions . . . . . . . . . . . . . . . . . . . .159
Enabling normal UDP aging for DNS and RADIUS . . . . . . . . . .160
Setting TCP and UDP ages for VIPs. . . . . . . . . . . . . . . . . . . . . .160
Configuring session aging behavior . . . . . . . . . . . . . . . . . . . . .161
Configuring DNS CPU-based throttling . . . . . . . . . . . . . . . . . . .161
Configuring UDP DNS count connection . . . . . . . . . . . . . . . . .162
Maximum server, port, and health check count . . . . . . . . . . .162
4
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Policy-based routing for reverse SLB traffic . . . . . . . . . . . . . . .163
Dedicated next hop per VIP for reverse SLB traffic . . . . . . . . .164
Dynamic NAT for real servers using virtual server address . .165
VIP route health injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . .165
VIP RHI with dangling subnets . . . . . . . . . . . . . . . . . . . . . . . . .172
VIP RHI and high availability topologies . . . . . . . . . . . . . . . . . .173
Application-specific SLB considerations . . . . . . . . . . . . . . . . . . . . .199
RTSP server Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . .199
Deletion of UDP data session along with TCP control session
for RTSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200
TFTP load balancing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200
Show and debug commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200
SLB configuration examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200
Displaying the BP distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . .201
Windows Terminal Server with L7 persistence . . . . . . . . . . . . . . . .202
Understanding windows terminal server . . . . . . . . . . . . . . . . .202
Configuring Windows Terminal Server . . . . . . . . . . . . . . . . . . .204
Chapter 3
Stateless Server Load Balancing
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .205
Stateless TCP and UDP ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .205
How the ServerIron ADX selects a real server
for a stateless port. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .206
Configuring the stateless hash table size . . . . . . . . . . . . . . . .207
Configuring a stateless application port . . . . . . . . . . . . . . . . .207
Fragmentation support in the stateless mode. . . . . . . . . . . . .209
Chapter 4
Health Checks
Health checks overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .211
Layer 3 health checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .211
Disabling Layer 3 health checks . . . . . . . . . . . . . . . . . . . . . . . .212
Modifying the ping interval and ping retries. . . . . . . . . . . . . . .213
Server periodic-ARP enhancement. . . . . . . . . . . . . . . . . . . . . .213
Layer 4 health checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .213
Performing Layer 4 UDP keepalive health checks
for the DNS port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .215
Server response threshold health check . . . . . . . . . . . . . . . . .216
ServerIron ADX Server Load Balancing Guide
53-1003452-01
5
Layer 7 health checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .218
Application ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .219
DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .220
FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .221
HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .221
Scripted (content verification for unknown ports) . . . . . . . . . .222
IMAP4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .223
LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .223
MMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .224
NNTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .224
PNM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .225
POP3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .225
RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .226
RTSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .229
SMTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .229
SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .229
Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .231
Configuring port-specific settings . . . . . . . . . . . . . . . . . . . . . . .231
HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .232
DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233
RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .234
LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .235
Simple and complete SSL health checks . . . . . . . . . . . . . . . . .237
Layer 7 health check for an unknown port . . . . . . . . . . . . . . .239
Server and application port states . . . . . . . . . . . . . . . . . . . . . . . . .240
Server states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .240
Application port states. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Port profiles and attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243
Configuring a port profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .244
Configuring port profile attributes . . . . . . . . . . . . . . . . . . . . . .245
Port policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .250
Port policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .250
Configuring a port policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .250
Binding the policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .252
Configuring a keepalive interval under a port policy . . . . . . . .254
Health check policy for VIP port . . . . . . . . . . . . . . . . . . . . . . . .255
Element health checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .255
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .255
Configuring element-action expressions . . . . . . . . . . . . . . . . .255
Attaching a health-check policy to an application port
on a server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .264
Displaying health-check policies and their status . . . . . . . . . .264
Displaying health-check policy statistics . . . . . . . . . . . . . . . . .265
Clearing health-check policy statistics . . . . . . . . . . . . . . . . . . .266
Health check with content match . . . . . . . . . . . . . . . . . . . . . . . . . .266
Content match for HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .266
Content match for non-HTTP ports . . . . . . . . . . . . . . . . . . . . . .270
Binary scripted health check. . . . . . . . . . . . . . . . . . . . . . . . . . .273
6
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Boolean health checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Boolean health-check policies . . . . . . . . . . . . . . . . . . . . . . . . . 274
Health-check policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .275
Configuring boolean health check . . . . . . . . . . . . . . . . . . . . . .275
Miscellaneous health check settings . . . . . . . . . . . . . . . . . . . . . . .277
Basing an alias port’s health on the health of its master port277
Basing a port’s health on the health of another port . . . . . . .278
Reassign threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .279
FastCache. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .280
Globally disabling all health-check policies . . . . . . . . . . . . . . .281
Health checking for real servers in other subnets. . . . . . . . . .281
Best path to a remote server . . . . . . . . . . . . . . . . . . . . . . . . . .281
Handling traffic initiated from remote server. . . . . . . . . . . . . .282
Minimum healthy real servers under VIP port . . . . . . . . . . . . .283
Server port bring-up retries . . . . . . . . . . . . . . . . . . . . . . . . . . . .283
Layer 4 and Layer 7 port bring-up interval . . . . . . . . . . . . . . . .284
Slow-start mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .284
FIN close for server health check . . . . . . . . . . . . . . . . . . . . . . .292
Health-check state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .292
Enhanced server bringup . . . . . . . . . . . . . . . . . . . . . . . . . . . . .293
Track-Port support under real server for health checks . . . . .293
Sample show commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .295
Syslog for health status change . . . . . . . . . . . . . . . . . . . . . . . .295
Health checks for firewall paths . . . . . . . . . . . . . . . . . . . . . . . .295
Session table parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . .297
Configuring TCP age. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .301
Configuring UDP age . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .301
Setting the clock scale. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .301
Syslog for session table entries . . . . . . . . . . . . . . . . . . . . . . . .302
Chapter 5
Layer 7 Content Switching
Layer 7 content switching overview . . . . . . . . . . . . . . . . . . . . . . . . .305
Configuring Layer 7 content switching. . . . . . . . . . . . . . . . . . . . . . .306
Enabling CSW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .306
Specifying scan depth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .306
Enabling CSW load balance . . . . . . . . . . . . . . . . . . . . . . . . . . .307
CSW rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .307
CSW policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .312
Explanation of offsets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .328
Sample configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .329
CSW topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .330
Request delete configuration . . . . . . . . . . . . . . . . . . . . . . . . . .331
Layer 7 content switching on HTTP response . . . . . . . . . . . . . . . . .334
Response header rewrite . . . . . . . . . . . . . . . . . . . . . . . . . . . . .334
Configuring HTTP header response rewrite . . . . . . . . . . . . . . .334
Response body rewrite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .336
Configuring HTTP body response rewrite . . . . . . . . . . . . . . . . .336
ServerIron ADX Server Load Balancing Guide
53-1003452-01
7
Using multiple cookies under virtual server port . . . . . . . . . . . . . .338
Configuring multiple unique cookie insertion with
cookie path. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .338
Specifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .339
Server passive cookie persistence . . . . . . . . . . . . . . . . . . . . . . . . .341
Configuring server passive cookie persistence . . . . . . . . . . . .342
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .344
Server and server port persistence with CSW nested rules. . . . . .344
Configuring server and server port persistence with
CSW nested rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .345
Configuring persist on the nested rule . . . . . . . . . . . . . . . . . . .345
Configuring persist on the real port . . . . . . . . . . . . . . . . . . . . .345
Displaying CSW information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .347
Displaying header information . . . . . . . . . . . . . . . . . . . . . . . . .347
Displaying CSW rule information. . . . . . . . . . . . . . . . . . . . . . . .348
Displaying CSW policy information . . . . . . . . . . . . . . . . . . . . . .351
Displaying the statistics for all HTTP content rewrites . . . . . .353
Displaying Layer 7 switching statistics . . . . . . . . . . . . . . . . . . .354
Displaying the hash-based server selection for CWS policies 355
Displaying hash bucket counters . . . . . . . . . . . . . . . . . . . . . . .357
Usage guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .358
Support for large GET requests. . . . . . . . . . . . . . . . . . . . . . . . .358
TCP/UDP content switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .358
Understanding TCP/UDP content switching. . . . . . . . . . . . . . .359
Configuring TCP/UDP content switching . . . . . . . . . . . . . . . . .359
TCP/UDP content switching commands. . . . . . . . . . . . . . . . . .363
Miscellaneous Layer 7 switching configurations . . . . . . . . . . . . . .366
Changing the maximum number of concurrent
Layer 7 connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .366
Dropping requests on exceeding max-conn per real server . .366
Cleaning up all hash buckets . . . . . . . . . . . . . . . . . . . . . . . . . .367
Layer 7 content buffering options. . . . . . . . . . . . . . . . . . . . . . .367
HTTP 1.1 support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .368
Layer 7 CSW pseudo stack client-side retransmission
handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .372
Layer 7 CSW pseudo stack server-side TCP packet
out-of-sequence handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
Setting up SSL session ID switching . . . . . . . . . . . . . . . . . . . . . . . . 376
Command reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .380
rewrite request-delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .380
rewrite request-insert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .380
rewrite request-replace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .381
Chapter 6
High Availability
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .383
Hot Standby HA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .383
Symmetric Active-Standby HA . . . . . . . . . . . . . . . . . . . . . . . . . .383
Symmetric Active-Active HA. . . . . . . . . . . . . . . . . . . . . . . . . . . .383
8
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Hot Standby HA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .384
Hot Standby HA protocol operations. . . . . . . . . . . . . . . . . . . . .384
Configuring Standard Hot Standby HA . . . . . . . . . . . . . . . . . . .386
Additional configuration variations . . . . . . . . . . . . . . . . . . . . . .391
Sample configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .398
Symmetric Active-Standby HA . . . . . . . . . . . . . . . . . . . . . . . . . . . . .399
Configuring Symmetric Active-Standby HA . . . . . . . . . . . . . . . .399
Additional configuration variations . . . . . . . . . . . . . . . . . . . . . .402
Symmetric Active-Active HA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Difference between Symmetric Active-Active HA versus
Symmetric Active-Standby HA . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Configuring Symmetric Active-Active HA. . . . . . . . . . . . . . . . . . 417
Manual triggering of symmetric HA failover with VRRP-E . . . . . . . . 417
Configuring manual HA failover. . . . . . . . . . . . . . . . . . . . . . . . .418
Upgrade process for the symmetric HA setup using VRRP-E .418
Displaying the current VRRP-E priority status . . . . . . . . . . . . .420
Orchestrating seamless HA failover using VRRP-E pool . . . . . . . . .421
Configuring VRRP-E pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . .423
Guidelines for configuring VRRP-E pools . . . . . . . . . . . . . . . . .423
Maintaining traffic symmetry by adjusting OSPF cost during
HA and VRRP-E switchover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .424
Configuring OSPF cost adjustment during HA and
VRRP-E failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .425
OSPF and route-map configuration . . . . . . . . . . . . . . . . . . . . .426
Additional variations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .426
Multiple high availability SLB pairs in the same VLAN . . . . . .426
NAT in HA environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .427
IP NAT session synchronization in HA configurations . . . . . . .433
Shareable source NAT for high availability . . . . . . . . . . . . . . . .433
Configuring server accelerated-fin-sync command . . . . . . . . .438
Configuring synchronization with HA . . . . . . . . . . . . . . . . . . . .439
Miscellaneous options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .439
Displaying VIP owner in HA setup . . . . . . . . . . . . . . . . . . . . . . .439
Identifying the ports attached to a router . . . . . . . . . . . . . . . .439
Setting VIP failback delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . .439
Chapter 7
IPv6 Support for Server Load Balancing
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .441
Defining IPv6 real servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .441
Defining IPv6 virtual servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .442
Defining IPv4 real servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .442
Defining IPv4 virtual servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .442
Defining port characteristics using port profile . . . . . . . . . . . . . . .442
Defining IP routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .442
VLAN, tagging and trunk definitions . . . . . . . . . . . . . . . . . . . . . . . .443
ServerIron ADX Server Load Balancing Guide
53-1003452-01
9
VRRP-E and VIP group definitions . . . . . . . . . . . . . . . . . . . . . . . . . .443
Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .444
Saving the configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .444
IPv6 to IPv4 gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .444
Features not supported with the IPv6 to IPv4 gateway . . . . . .446
Packet fragmentation with the IPv6 to IPv4 gateway . . . . . . .446
ICMP packet processing for the IPv6 to IPv4 gateway. . . . . . .447
IPv6 to IPv4 gateway high availability support . . . . . . . . . . . . .448
Configuring the IPv6 to IPv4 gateway . . . . . . . . . . . . . . . . . . . .449
Displaying IPv6 to IPv4 gateway information . . . . . . . . . . . . . .450
IPv4 to IPv6 gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .451
Configuring the IPv6 prefix . . . . . . . . . . . . . . . . . . . . . . . . . . . .452
Features not supported with the IPv4 to IPv6 gateway . . . . . .453
Packet fragmentation with the IPv4 to IPv6 gateway . . . . . . .453
ICMP packet processing for the IPv4 to IPv6 gateway. . . . . . .454
IPv4 to IPv6 gateway high availability support . . . . . . . . . . . . .455
Configuring the IPv4 to IPv6 gateway . . . . . . . . . . . . . . . . . . . .456
Displaying IPv4 to IPv6 gateway information . . . . . . . . . . . . . .456
Appendix A
Server-specific Loopback Configurations
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .457
Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .457
Linux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .457
Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .458
Manual installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .458
Unattended installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .458
Deleting the unwanted routes. . . . . . . . . . . . . . . . . . . . . . . . . .459
Appendix B
Basic Configuration Example
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .463
Both ServerIron ADX sites working in primary mode . . . . . . . . . . .464
Site 1 configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .465
Site 2 configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .470
Site-1 ServerIron ADX in primary mode and site-2
in backup mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
Site 1 configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
Site 2 configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .482
Appendix C
SLB Show and Debug Commands
Using show source-ipsource-ip [ real-server-ip | all] . . . . . . . . . . .491
Using the show session all command . . . . . . . . . . . . . . . . . . . . . . .492
Using the source-ip-debug command . . . . . . . . . . . . . . . . . . . . . . .493
10
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Using the debug filter command . . . . . . . . . . . . . . . . . . . . . . . . . . .493
Using the packet capture utility . . . . . . . . . . . . . . . . . . . . . . . .493
"debug filter" example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .500
Helpful tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .504
Emulating tcpdump using the debug filter . . . . . . . . . . . . . . . . . . .504
Displaying global Layer 4 ServerIron ADX configuration. . . . . . . . .505
Displaying real server information and statistics . . . . . . . . . . . . . .508
Using the show server real command . . . . . . . . . . . . . . . . . . .508
Using the show server real detail command . . . . . . . . . . . . . .511
Displaying real server keepalive statistics . . . . . . . . . . . . . . . . 514
Displaying real server connections per second statistics . . . . 514
Displaying virtual server information and statistics . . . . . . . . . . . .515
Displaying a list of failed servers . . . . . . . . . . . . . . . . . . . . . . . . . . .518
Displaying a list of failed ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . .519
Displaying port-binding information. . . . . . . . . . . . . . . . . . . . . . . . .519
Using the show server bind command . . . . . . . . . . . . . . . . . . .519
Using the show server session command . . . . . . . . . . . . . . . .520
Displaying packet traffic statistics . . . . . . . . . . . . . . . . . . . . . . . . . .522
Displaying configuration information . . . . . . . . . . . . . . . . . . . . . . . .524
Showing aggregate health of tracked ports . . . . . . . . . . . . . . .525
Auto repeat of show command output . . . . . . . . . . . . . . . . . . .526
Clearing all session table entries . . . . . . . . . . . . . . . . . . . . . . .526
Simplified Clearing of Server Sessions. . . . . . . . . . . . . . . . . . .528
Clearing the connections counter. . . . . . . . . . . . . . . . . . . . . . .528
Appendix D
SLB Configuration Examples
Web hosting with multiple virtual servers
mapped to one real server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .529
Multiple port binding using port aliases . . . . . . . . . . . . . . . . . . . . .530
TCP/UDP application groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .531
Web hosting with ServerIron ADX and real servers in
different subnets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .534
SLB with ServerIron running Layer 3 image . . . . . . . . . . . . . . . . . .536
Basic SLB with multiple subnets and multiple
virtual routing interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .539
Appendix E
Acknowledgements
OpenSSL license . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .543
Cryptographic software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .544
Original SSLeay License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .544
ServerIron ADX Server Load Balancing Guide
53-1003452-01
11
12
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Preface
Document conventions
The document conventions describe text formatting conventions, command syntax conventions,
and important notice formats used in Foundry technical documentation.
Text formatting conventions
Text formatting conventions such as boldface, italic, or Courier 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
Courier font
Identifies CLI output
Identifies command syntax examples
ServerIron ADX Server Load Balancing Guide
53-1003452-01
13
Command syntax conventions
Bold and italic text identify command syntax components. Delimiters and operators define
groupings of parameters and their logical relationships.
Convention
Description
bold text
Identifies command names, keywords, and command options.
italic text
Identifies a variable.
[]
Syntax components displayed within square brackets are optional.
Default responses to system prompts are enclosed in square brackets.
{ x | y |z }
A choice of required parameters is enclosed in curly braces separated
byvertical bars. You must select one of the options.
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.
14
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Brocade resources
Visit the Brocade website to locate related documentation for your product and additional Brocade
resources.
You can download additional publications supporting your product at www.brocade.com. Select the
Brocade Products tab to locate your product, then click the Brocade product name or image to
open the individual product page. The user manuals are available in the resources module at the
bottom of the page under the Documentation category.
To get up-to-the-minute information on Brocade products and resources, go to MyBrocade. You can
register at no cost to obtain a user ID and password.
Release notes are available on MyBrocade under Product Downloads.
White papers, online demonstrations, and data sheets are available through the Brocade website.
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.
Brocade customers
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:
support@brocade.com
• 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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
15
Document feedback
Brocade OEM customers
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 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
To send feedback and report errors in the documentation you can use the feedback form posted
with the document or you can e-mail the documentation team.
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 documentation@brocade.com
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.
16
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Chapter
1
Features and Enhancements
Release 12.5.02
Enhancement
Description
Documented in the following
books
Increase of GSLB
zones
The ServerIron ADX supports a maximum of 4,000 DNS
zones, hosts, and applications, and a maximum of 8,000
DNS IP addresses.
Book: ServerIron ADX
Global Server Load
Balancing Guide
Secure GSLB using
OpenSSL
The ServerIron ADX supports a maximum of 2,048 bit SSL
key size from the previous maximum of 1,024 bit key size.
Book: ServerIron ADX
Global Server Load
Balancing Guide
OpenScript APIs for
parsing SSL
certificates
The OpenScript module includes a new set of APIs that can
provide insights into an SSL certificate used in establishing
a secure connection between a client and the ServerIron
ADX.
Book: ServerIron ADX
OpenScript API Guide
OpenScript load
balancing based on
HTTP payload
You can define specific OpenScript actions, such as
forward, log, reset, based on specific information available
in the HTTP payload.
Book: ServerIron ADX
OpenScript API Guide
TLS 1.1 and TLS 1.2
The ServerIron ADX supports protocol versions TLS 1.1 and
TLS 1.2.
Book: ServerIron ADX
Security Guide
IPv6 Clients support
for maximum
concurrent
connection
The ServerIron ADX supports IPv6 clients for the maximum
concurrent connection per client feature.
Book: ServerIron ADX
Security Guide
Changing the name of
a virtual server
The new name command allows you to change the name to
a virtual server without having to delete the complete
virtual server configuration.
Book: ServerIron ADX
Server Load Balancing
Guide
Health check: Layer 7
health check for
RADIUS accounting
The ServerIron ADX supports RADIUS accounting health
checks.
Book: ServerIron ADX
Server Load Balancing
Guide
Health check: SSL
health check cipher
suites
This ServerIron ADX supports the following cipher suites as
part of the SSL health checks in simple and complete SSL
health check modes.
• TLS_RSA_WITH_AES_256_CBC_SHA - AES cipher
algorithm using 256 bit key size
• TLS_RSA_WITH_AES_128_CBC_SHA - AES cipher
algorithm using 128 bit key size
Book: ServerIron ADX
Server Load Balancing
Guide
ServerIron ADX Server Load Balancing Guide
53-1003452-01
1
1
Release 12.5.01a
High Availability (HA):
Increase the number
of symmetric HA
groups
The number of symmetric HA groupshas increased to 255.
Book: ServerIron ADX
Server Load Balancing
Guide
High Availability (HA):
Simplified symmetric
HA failover
The new vrrpe standby command forces an active
ServerIron ADX to failover to its backup ServerIron ADX in a
symmetric setup with VRRP-E. Prior to 12.5.02 release, the
ServerIron ADX deployed in a symmetric HA mode, cannot
be upgraded without configuration changes or disabling of
ports.
Book: ServerIron ADX
Server Load Balancing
Guide
Enhancement
Description
Documented in the following
books
IPv6 Host-Range
The host-range definition for servers is now extended to
support IPv6 servers.
Book: ServerIron ADX
Server Load Balancing
Guide
Chapter: Server Load
Balancing
Section: Configuring IPv6
host-range
Simplified Clearing of
Server Sessions
The clear server command is enhanced with additional
options to simplify clearing of server-bound sessions.
Book: ServerIron ADX
Server Load Balancing
Guide
Chapter: SLB Show and
Debug Commands
Section: Displaying
configuration information
Pass-through flow
management
Stateful devices such as firewalls and Deep Packet
Inspection (DPI) devices require visibility into both forward
and reverse traffic flows to process them appropriately.
These devices fail to function if the network handles traffic
asymmetrically.
Using the pass-through flow management feature, the
ServerIron ADX supports stateful handling of network flows
while ensuring that it sends the reverse traffic to the same
device that previously forwarded it.
Pass-through flow management is a standalone feature
and is applicable for TCP and UDP traffic flows only.
Book: ServerIron ADX
Advanced Server Load
Balancing Guide
Chapter: Pass-Through Flow
Management
Certificate Verification
Using Online
Certificate Status
Protocol (OCSP)
OCSP (Online Certificate Status Protocol) is one of two
schemes used for obtaining revocation status of an SSL
certificate. The other method is known as Certificate
Revocation List (CRL). The CRL method involves frequent
download of the CRL list in order to maximize use of the
most current information. OCSP overcomes this chief
limitation of the CRL. In addition, since the OCSP response
contains less information than a typical CRL, OCSP utilizes
networks and client resources more efficiently.
The ServerIron ADX previously supported only the CRL
method. It now also supports OCSP.
Book: ServerIron ADX
Security Guide
Chapter: Secure Socket
Layer (SSL) Acceleration
Section: Creating a
certificate revocation list
Release 12.5.01a
2
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Release 12.5.01a
1
Increasing TRL Limits
for IPv4 and IPv6
The TRL limit is now configurable under the ServerIron ADX
system parameters for both IPv4 and IPv6. With this
feature, you can configure a TRL limit for IPv4 from 1000 to
25000 and for IPv6 from 1000 to 15000, based on the
requirement. If you want to alter the default TRL limit
(15000), you must reload the ServerIron ADX after saving
the configuration.
Book: ServerIron ADX
Security Guide
Chapter: Network Security
Section: Configuring
transaction rate limit for all
rules under all policies
Prioritizing critical IPC
traffic
The IPC traffic between the MP and BP is critical as it is
used to ensure the health of the BP and synchronize
information from the MP to the BP.
The ServerIron ADX in this release reserves dedicated
bandwidth for uninterrupted processing of IPC traffic.
Book: ServerIron ADX
Security Guide
Chapter: Network Security
Section: Prioritization of
Critical System Traffic and
Management Traffic
Securing
Management
Processor through
Traffic Rate Limiting
In this release, ICMP and SNMP attacks to the
management processor can be thwarted by rate limiting
this traffic in the hardware. Administrators can couple this
enhancement with other security features on the
ServerIron ADX to tightly secure their application server
farm.
Book: ServerIron ADX
Security Guide
Chapter: Network Security
Section: Securing
Management Processor
through Traffic Rate Limiting
VIP Level Priority
Threshold
The ServerIron ADX enables administrators to assign
varying priority levels to different service VIPs. The
assignments can be done based on the relative
importance of these applications to business operations.
Book: ServerIron ADX
Security Guide
Chapter: Network Security
Section: Application Traffic
Prioritization
VIP Maximum
Connection Rate
The VIP maximum connection rate feature allows you to
specify the maximum-allowed connection rate for
respective virtual servers, thus providing traffic rate
limiting at the VIP level.
Book: ServerIron ADX
Security Guide
Chapter: Network Security
Section: Prioritization of
Critical System Traffic and
Management Traffic
Ability to assign IPV6
RADIUS address
The ServerIron ADX allows you to assign an IPV6 RADIUS
address.
Book: ServerIron ADX
Administration Guide
Chapter: Secure Access
Management
Section: Identifying the
RADIUS server using its
IPv6 address
Dedicated Default
route for
management
The ServerIron ADX allows you to define a dedicated
default route for management purposes in addition to
specifying a general-purpose default route for processing
data plane traffic.
Book: ServerIron ADX
Administration Guide
Chapter: ServerIron System
Management
Section: Configuring a
dedicated default route for
management
ServerIron ADX Server Load Balancing Guide
53-1003452-01
3
1
Release 12.5.01
Disabling of SNMP v1
The SNMP version 1 has enjoyed unparalleled success as
an extremely useful management tool. However, it has
certain shortcomings, especially its lack of strong
security. In this release, administrators can disable SNMP
v1 and utilize higher versions of SNMP in a highly secure
environment.
Book: ServerIron ADX
Administration Guide
Chapter: ServerIron System
Management
Section: Disabling SNMP
versions
Support for IPv6
sFlow
Support for IPv6 sFlow enables administrators to identify
their sFlow server and RADIUS and TACACS+ server
destinations using an IPv6 address.
Book: ServerIron ADX
Switching and Routing
Guide
Chapter: sFlow
Section: Specifying the
collector
Enhancement
Description
Documented in the following
books
IPv6 Source NAT ACL
support
When an access-list (ACL) is applied to the source-NAT
configuration under real server, then the source-NAT is
restricted to traffic originated from IPv4 addresses
identified using the ACL. With this software release, the
source-NAT ACL feature is enhanced to support source-NAT
for both IPv4 and IPv6 addresses.
Book: ServerIron ADX
Server Load Balancing
Guide
Chapter: Server Load
Balancing
Section: Source NAT, IPv6
Source-Nat ACL support
Source NAT, interface,
and IPv6 address
CAM optimization
A ServerIron ADX running multitenancy mode is now
optimized by default to reduce the number of CAM entries
created for source NAT, interface, and source IPv6
addresses. In earlier releases, the CAM entries are quickly
exhausted because the number of CAM entries per
address are multiplied by the number of addresses per
tenant and the number of tenants. If required, you can
disable this optimization.
Book: ServerIron ADX
Multitenancy Guide
Chapter: System
Maintenance and
Monitoring
Section: Disabling source
NAT, interface, and source
IPv6 address CAM
optimization in
multitenancy mode
DNS TTL modification
under a GSLB
host-level policy
DNS TTL modification is now configurable in a host-level
policy that you apply to specified hosts within GSLB
domains. Previously, you could only configure the DNS TTL
in the GSLB global policy that applied to all hosts
configured under a GSLB zone.
Book: ServerIron ADX
Global Server Load
Balancing Guide
Chapter: Global Server Load
Balancing
Section: Configuring the
parameters for the
host-level policy (Changing
the TTL for DNS records)
Release 12.5.01
4
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Release 12.5.01
1
Increased scale of
distributed GSLB
health checks
In release 12.4.0g and later, each site ServerIron ADX has
the ability to send a maximum of 30 ports per VIP address
in the VIP address list message. Previously, each site
ServerIron ADX could send a maximum of 10 ports for each
VIP address.
Book: ServerIron ADX
Global Server Load
Balancing Guide
Chapter: Global Server Load
Balancing
Section: Configuring the
maximum ports per VIP
address in a VIP address list
message
Selection metric
counters for real
servers
In release 12.4.0g and later, the ServerIron ADX can
display the selection metric counter for real servers or sites
that are hosted on non-Brocade application delivery
controllers when you use the show gslb dns detail
command.
Book: ServerIron ADX
Global Server Load
Balancing Guide
Chapter: Global Server Load
Balancing
Section: Displaying metric
information
Chapter: Global Server Load
Balancing for IPv6
Section: Displaying detailed
DNS information
Preserving IPv6 SLB
path optimization with
GSLB
The ServerIron ADX now provides an optional configuration
that preserves IPv6 SLB path optimization even after the
enabling of GSLB. By default, IPv6 SLB path optimization is
disabled. You can enable this feature before or after you
enable GSLB. If you do not enable this feature, the ADX
directs all IPv6 SLB traffic to the non-optimized path.
In earlier releases, the ServerIron ADX disabled
optimization of IPv6 SLB processing when you enabled
GSLB.
Book: ServerIron ADX
Global Server Load
Balancing Guide
Chapter: Global Server Load
Balancing for IPv6
Section: Enabling the
optimized IPv6 path for
GSLB IPv6 optimization
New Content
Inspection API for
OpenScript
The new OS_PAYLOAD_INSPECT module includes APIs to
inspect unlimited amounts of streaming payload content
from either the client or server side and, when required, to
change the content. These APIs can perform the following
functions:
• Match and replace text strings, binary signatures, and
encoded patterns in HTTP. These APIs also allow you
to define the match criteria for the length of the text
string or binary pattern.
• Generate match events that can be used as triggers
for logging, filtering, and carrying out security policies.
Book: ServerIron ADX
OpenScript API Guide
Chapter: Content Inspection
API Reference
A VRRP-E pool is a group to which you can add all VRRP-E
instances configured within a ServerIron ADX device that is
part of an HA pair. When the ADX devices configured in an
HA pair are subjected to HA failovers, pooling the VRRP-E
instances prevents traffic loss and maintains predictable
traffic flow.
Book: ServerIron ADX
Switch Router Guide
Chapter: Configuring VRRP
and VRRP-E
Section: VRRP-E pool
VRRP-E pool
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Book: ServerIron ADX
OpenScript Programmer’s
Guide
Chapter: OpenScript
Fundamentals
Section: Structure of a
ServerIron ADX Perl script
Chapter: Managing Scripts
on a ServerIron ADX
Section: Displaying script
information
5
1
6
Release 12.5.01
OSPF cost change
followed by VRRP-E
status change
The OSPF cost change functionality applies to an HA
topology in which the server side of ServerIron ADX devices
is configured with VRRP-E and the router side of the
ServerIron ADX devices is configured with OSPF. OSPF
tracks the mastership of the server-side VRRP-E VRID
instances and dynamically controls the cost of the
redistributed static VIP routes, advertised to the upstream
router.
Book: ServerIron ADX
Switch Router Guide
Chapter: Configuring VRRP
and VRRP-E
Section: OSPF cost change
followed by VRRP-E status
change
Configuration
synchronization
feature
enhancements
The configuration synchronization feature:
• Sends a message to the sender device when the
commands are not executed on the receiver device.
• Prints error messages when the configuration is not
synchronised properly.
• Sends messages if incremental synchronization
commands are not successfully executed.
Book: ServerIron ADX
Administration Guide
Chapter: Configuration
Synchronization
Section: Debugging the
configuration
synchronization and
Monitoring the progress of
configuration
synchronization
Tie up of
configuration
synchronization with
High Availability
Configuration synchronization is tied to the existing High
Availability (HA) modes so that the active device is always
the configuration synchronization sender device and the
standby device is always the receiver device.
Book: ServerIron ADX
Administration Guide
Chapter: Configuration
Synchronization
Section: Configuration
synchronization between
the HA pairs
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Release 12.5.00
1
Release 12.5.00
Enhancement
Description
Documented in the following
books
Support for
Multitenant Cloud
Environments
The ServerIron ADX device can now be deployed in a
multitenant mode allowing the provisioning and
management of multiple virtualized instances of the ADX
on the same device. In this mode of operation,
administrators of hosted or private clouds can configure
and manage the ADX device while delegating the
administration of each hosted ADX instance to an
individual tenant. In this context, the ServerIron ADX device
administrator can provide each tenant with dedicated
resources and a completely isolated network, while
providing control of application traffic directly to that
tenant.
Book: ServerIron ADX
Multitenancy Guide.
Increased 2048 Bit
SSL Performance on
Modular ADX
Platforms
Increased 2048 Bit SSL Performance on Modular ADX
Platforms
To assist customers in the offloading of 2048 bit SSL
encryption/decryption, release 12.5 includes significant
enhancements to 2048-bit SSL Transactions per Second
(TPS) - nearly doubling the performance compared to
previous releases. This performance improvement is made
possible through a combination of software and hardware
improvements including updates to the SI-MM-SSL and
SI-AEM-SSL expansion modules for the SI-4000 and
SI-10000 systems.
Book: ServerIron ADX
Installation Guide.
Chapter: Product Overview
Section: SSL Expansion
Module
Chapter: Installing
ServerIron ADX
Section: Installing an SSL
Expansion module onto a
management module
Enhancements to
Configuration
Synchronization
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Book: ServerIron ADX
Administration Guide.
Chapter: Configuration
Synchronization
7
1
8
Release 12.5.00
Enhanced Web-based
GUI
The Brocade ADX Web interface now includes the following
additional capabilities.
• Multitenancy
• Enhanced views for administrators deploying the
ADX in Multitenancy mode
• Dashboard/Monitoring improvements
• Display of historical statistics (up to 24 hours)
that can be exported from the device
• Statistics for IPv6 Interface and Neighbor
• Statistics for Routing Protocols - BGP, OSPF
• Monitoring enhancements for Virtual Server/
Real Server including additional fields for Rx
kbps, Tx kbps, and Connections/sec
• Configuration Improvements
• Configuration wizard for simplified deployment of
server load balancing
• Support for configuration synchronization
• Support for device management - SNMP, Telnet,
SSH
• Support for RADIUS/ TACACS
• Support for SYN Proxy
• Maintenance improvements
• Packet capture utility for improved visibility into
traffic patterns
• Context-sensitive help
Book: ServerIron ADX
Graphical User Interface
Guide
New XML APIs to
support enhanced
third party
management
integration
This release includes XML API enhancements to the
following ADX functional areas:
• Multitenancy
• Device administration
• Tenant provisioning
• Tenant configuration, management and
monitoring
• Device Management
• Packet capture
• Historical statistics and export
• Configuration synchronization
• Device management - SNMP, Telnet, SSH
RADIUS/ TACACS
• Load Balancing
• Enhancements to VIP/real server statistics
(throughput and connections/sec)
• Network management
• Routing configuration and statistics (BGP, OSPF
and IPv6)
• VRRP/e statistics
• Security/Protection
• SYN Proxy
Book: ServerIron ADX XML
API Programmers Guide
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Release 12.4.00a
1
Release 12.4.00a
Enhancement
Description
Documented in the following
books
Additional statistics
for Real and Virtual
Servers
With this release, ServerIron ADX now provides throughput
and connections per second metrics for both real and
virtual servers (VIPs) along with supporting SNMP traps.
Book: ServerIron ADX
Server Load Balancing
Guide
Appendix: SLB Show and
Debug Commands
Book: IronWare MIB
Reference.
Chapter: ServerIron ADX
SLB MIB
Section: Real Server
Statistics Table and Virtual
Server Statistics Table
Intelligent Re-use of
Newly-available
Cache Servers
Starting with release 12.4.00a, the Brocade ServerIron
ADX is powered with a new intelligent algorithm that
minimizes the impact on traffic persistency while allowing
seamless addition of newly-available cache servers.
Book: ServerIron ADX
Advanced Server Load
Balancing Guide.
Chapter: Transparent Cache
Switching
Section: Resilient Hashing
for Maximum Cache
Persistence
SNMP-based Health
Monitoring with
Layer-7 TCS Policy:
The Brocade ServerIron ADX already supported an
advanced SNMP-based health monitoring system for
checking real-time state of Blue Coat CacheFlow servers.
These same capabilities have been extended in this
release to an environment where a Brocade ServerIron ADX
is enabled for cache selection through application-specific
Layer-7 rules.
Book: ServerIron ADX
Advanced Server Load
Balancing Guide
Chapter: Transparent Cache
Switching
Section: Traffic distribution
based on cache server
capacity
Bypassing of
Embedded Protocols
For network environments where non-HTTP protocols such
as FTP and RTSP are masquerading over port HTTP, the
Brocade ServerIron ADX provides network administrator
additional flexibility to bypass such embedded traffic to the
Internet instead of forwarding to cache servers.
Book: ServerIron ADX
Advanced Server Load
Balancing Guide.
Chapter: Transparent Cache
Switching
Section: Bypassing
embedded protocols.
Brocade OpenScript
API Enhancements
The OpenScript dataplane scripting engine now supports
the inspection and rewrite of the HTTP body and has been
extended to include API support for IP, UDP and TCP based
traffic
Book: ServerIron ADX
OpenScript Programmer’s
Guide
Book: ServerIron ADX
OpenScript API Guide
ServerIron ADX Server Load Balancing Guide
53-1003452-01
9
1
Release 12.4.0
Brocade OpenScript
SNMP Trap
Enhancement
An SNMP trap has been added to provide notification when
an OpenScript event occurs.
Book: IronWare MIB
Reference
Chapter: Traps and Objects
to Enable Traps
Section: SLB Real Server
connection traps
Brocade OpenScript
GUI Enhancement
With this release, the ServerIron ADX GUI now supports the
ability to upload/download scripts to and from the local
client.
Book: ServerIron ADX
Graphical User Interface
Guide
Chapter: Traffic Settings
Section: Uploading and
downloading scripts
Enhancement
Description
Documented in the following
books
Hash-based
persistence in TCS for
SSL traffic
In previous releases, SSL traffic could only be distributed
among servers in a cache group using the least connection
method. With this release, SSL traffic uses a hashing
algorithm based on source and destination IP addresses as
its default distribution method. Additionally, you can now
use a command to toggle the traffic distribution method
between the least connection method and the hashing
algorithm for any protocol.
Book: ServerIron ADX
Advanced Server Load
Balancing Guide
Chapter: Transparent Cache
Switching
Section: Assigning web
cache servers to cache
groups
Section: Selecting a method
for server selection within a
cache group
Enabling a ServerIron
ADX SSL to respond
with renegotiation
headers
This feature allows you to configure a ServerIron ADX to
respond with renegotiation headers that tell browsers that
the ServerIron ADX handles renegotiation messages
correctly and stops them from sending a false message
that the ServerIron ADX is vulnerable to renegotiation
attacks.
Book: ServerIron ADX
Security Guide.
Chapter: Secure Socket
Layer (SSL)
Section: Enabling a
ServerIron ADX SSL to
respond with renegotiation
headers.
HTTP 1.1 support for
content aware cache
switching
With this release, keep alive mode for TCS is enabled by
default and TCP offload is supported to allow the
ServerIron ADX to fully support HTTP 1.1.
Book: ServerIron ADX
Advanced Server Load
Balancing Guide
Chapter: Transparent Cache
Switching
Section: HTTP 1.1 support
for TCS CSW
TCS for IPv6
The Transparent Cache Switching feature has been
updated in this release to support IPv6.
Book: ServerIron ADX
Advanced Server Load
Balancing Guide
Chapter: Transparent Cache
Switching
Release 12.4.0
10
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Release 12.4.0
1
IPv6 GSLB
This feature implements GSLB for IPv6 for host name in the
DNS Cache Proxy + DNS override mode. Ins this mode, the
IPv6 addresses for hosts are configured on the ServerIron
ADX GSLB controller. It acts as the authoritative DNS server
the configured zones. It intercepts DNS queries and if
these are AAAA queries for configured hosts, the ServerIron
ADX generates the DNS response by applying configured
GLSB policies on the IPv6 list configured for the hostname.
Book: ServerIron ADX
Global Server Load
Balancing Guide
Chapter: Global Server Load
Balancing
Authenticating RBM
through a AAA server
Beginning with this release, you can authenticate a user for
Role Based Management access through a AAA (Radius or
TACACS+) server.
Book: ServerIron ADX
Administration Guide.
Chapter: Role Based
Management
Section: Integrating RBM
with RADIUS and TACACS+.
IPv4 to IPv6 Gateway
Beginning with software release 12.4, the ServerIron ADX
allows an IPv4 client to send and receive packets to and
from an IPv6 server.
Book: ServerIron ADX
Server Load Balancing
Guide
Chapter: IPv6 Support for
Server Load Balancing
Section: “IPv4 to IPv6
gateway”
Direct Multiple Port
Binding
ServerIron ADX now enables real server port to be directly
bound to multiple virtual ports. Formerly, a real server port
could be bound to multiple virtual ports only by means of
port aliases.
Book: ServerIron ADX
Server Load Balancing
Guide
Chapter: Server Load
Balancing
Section: “Direct binding of
multiple ports”
Real Server Groups
Real server groups facilitate the definition of multiple port
bindings and reduce the size of configurations by enabling
you to associate multiple real servers to a real server group
and then binding that real server group to one or more
virtual servers.
Book: ServerIron ADX
Server Load Balancing
Guide
Chapter: Server Load
Balancing
Section: “Real server
groups”
IPv6 L3 Direct Server
Return
Beginning with this release ServerIron ADX supports TOS
marking and L3 Direct Server Return health checks on IPv6
servers.
Book: ServerIron ADX
Server Load Balancing
Guide
Chapter: Server Load
Balancing
Section: “TOS marking of
SLB and health check
packets”
Enhanced
LDAP-LDAPS Health
Check
Beginning with this release ServerIron ADX supports
authenticated bind operations with LDAP and LDAPS
servers and searches of the directory; ServerIron ADX
marks the port as active only after a successful
authenticated bind and search operation.
Book: ServerIron ADX
Server Load Balancing
Guide
Chapter: Health Check
Section: “LDAP”
Health Check
Response Threshold
The ServerIron ADX compares the calculated response
time and compares that with the configured response
threshold. If the calculated response time is greater than
the configured response threshold, the port is marked
down.
Book: ServerIron ADX
Server Load Balancing
Guide
Chapter: Health Check
Section: “Server response
threshold health check”
ServerIron ADX Server Load Balancing Guide
53-1003452-01
11
1
12
Release 12.4.0
IPsec for OSPFv3
With this release, ServerIron ADX supports the
implementation of Internet Protocol Security (IPsec) for
securing OSPFv3 traffic.
Book: ServerIron ADX
Switch and Router Guide
Chapter: Configuring
OSPFv3
Section: IPsec for OSPFv3
IPv6 IS-IS
Multi-Topology
With this release, ServerIron ADX supports IPv6 IS-IS
Multi-Topology.
Book: ServerIron ADX
Switch and Router Guide
Chapter: Configuring IPv6
IS-IS
Section: IPv6 IS-IS
Multi-Topology.
IPv6 Element Heath
Check
Beginning with this release the ServerIron ADX supports
Element health checks for IPv6 addresses.
Book: ServerIron ADX
Server Load Balancing
Guide
Chapter: Health Checks
Section: “Specifying the IP
address and application
port parameters”
Per-VIP RHI BInding
Threshold
Previous releases allowed you to define the percentage of
bound real server ports that must be healthy in order to
consider the VIP port healthy. With this release, that
percentage can be configured per-VIP.
Book: ServerIron ADX
Server Load Balancing
Guide
Chapter: Server Load
Balancing
Section: “Defining the
health of a VIP port”
IPv6 FWLB
With this release ServerIron ADX supports IPv6 with
Firewall Load Balancing
Book: ServerIron ADX
Firewall Load Balancing
Guide
IPv6 jumbo MTU
support
With this release you can configure a ServerIron ADX to
support an IPv6 MTU size up to 9234 Bytes. IPv6 MTU can
be set globally or per virtual interface.
Book: ServerIron ADX
Server Load Balancing
Guide
Chapter: Configuring IPv6
Addressing
Section: Enabling IPv6
jumbo MTU support
Book: ServerIron ADX
Server Load Balancing
Guide
Chapter: Server Load
Balancing
Section: “Configuring jumbo
frame support”
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Release 12.4.0
1
Layer 7 Performance
enhancement
(backward
compatibility)
The following behavior has changed to support Layer 7
performance improvement and provide backward
compatibility. In version 12.4.00, if the next request from
the same client connection is forwarded within the same
server group, the ServerIron 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
ServerIron ADX will follow the current code behavior to
perform server section. A command is provided that sets
the behavior back to pre-12.4.00 behavior which enables
use of a load balancing predictor
Book: ServerIron ADX
Server Load Balancing
Guide
Chapter: Layer 7 Content
Switching
Section: “Enabling CSW
load balance”
Setting a logging
threshold for
connection rate
With this release, you can set a threshold on the ServerIron
ADX to send a log message for the following connection
rates: the maximum number of sessions the ServerIron
ADX maintains in its session table for all barrel processors
or a real server pool, the maximum number of new TCP
connections per-second allowed on a real server and the
maximum number of UDP connections per-second allowed
on a real server.
Book: ServerIron ADX
Server Load Balancing
Guide
Chapter: Server Load
Balancing
Section: “Setting a logging
threshold for connection
rate”
Assigning a virtual
VRRP-E address in
theIPv6 format
Beginning with release 12.4.00, a global unicast IPv6
address can be configured as the VRID
address in VRRP-E. In previous releases, only link-local
IPV6 addresses were allowed to be
configured as IP address of the VRID.
Book: ServerIron ADX
Switch and Router Guide
Chapter: Configuring
VRRP-E for IPv6
Section: “Assigning virtual
VRRP-E address in IPv6
format”
ServerIron ADX
OpenScript
Brocade OpenScript provides data plane scripting
functionality to manipulate traffic in
real-time.
Book: ServerIron ADX
OpenScript Programmer’s
Guide
Book: ServerIron ADX
OpenScript API Guide
SOAP/XML
Application
Programmatic
Interface (API)
New APIs have been added to increase functionality of the
SOAP/XML Application Programmatic Interface (API)
Book: ServerIron ADX XML
API Programmers Guide
ServerIron ADX Server Load Balancing Guide
53-1003452-01
13
1
Release 12.3.01
Release 12.3.01
14
Enhancement
Description
Documented in the following
books
NAT64 Gateway
Starting with software release 12.3.01, the Brocade
ServerIron ADX adds support for standards-based NAT64
gateway capabilities to provide inter-operation between
IPv4 networks and IPv6 networks. In NAT64 gateway mode,
the ServerIron ADX enables IPv6-only clients to connect to
IPv4-only infrastructure and also maintains state
information for translated flows. It also preserves the
originating client IPv6 address by inserting it into a custom
HTTP header. In addition, the ServerIron ADX enables
communication from IPv4-only devices to IPv6-only
resources in stateless mode, and it also allows for
peer-to-peer communication where traffic can originate
from an end-node running either of the two protocols.
Book: ServerIron ADX
NAT64 Configuration Guide
DNS Attack Protection With this release, the ServerIron ADX also provides
protection against distributed denial of service attacks
such as DNS amplification attacks. A ServerIron ADX can
be configured to forward, drop or rate limit DNS traffic
based on DNS query name, DNS query type, and DNS
recursion flag.
Book: ServerIron ADX
Security Guide.
Chapter: Network Security
Section: DNS Attack
Protection
Multiprotocol BGP
support
With software release 12.3.01, the ServerIron ADX extends
support for Border Gateway routing Protocol (BGP) for IPv4
and IPv6 network prefixes. This gives network
administrators added flexibility for deploying the Brocade
ADX in environments running RIP, OSPFv2, OSPFv3, IS-IS
and BGP routing protocols. The support is also extended to
VIP route health injection with BGP in order to provide
disaster recovery in the event of data center/site failure.
Book: ServerIron ADX
Switch and Router Guide.
Chapter: Configuring BGP4
(IPv4)
Chapter: Configuring BGP4+
Hardware switching
for unknown unicast
traffic
Starting with release 12.3.01, the ServerIron ADX protects
application delivery infrastructures from flood of unknown
Unicast packets by processing them in hardware.
Book: ServerIron ADX
Switch and Router Guide.
Chapter: Configuring Basic
Features
Section: Enabling hardware
switching for unknown
unicast traffic
IPv6 ACL hardware
processing
IPv6 access control lists (ACLs) are now processed in
hardware for high-performance and secure application
delivery. The section referenced here describes how to
switch ACL processing for legacy performance.
Book: ServerIron ADX
Security Guide.
Chapter: Access Control List
Section: How ServerIron
processes ACLs
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Release 12.3.01
1
Transaction Rate
Limiting (TRL) and
SPAM Mitigation
(Policy-based Server
Load Balancing) for
IPv6 Pre
With release 12.3.01, the Brocade ServerIron ADX enables
protection against SPAM attacks and connection attacks
arriving from IPv6 prefixes in addition to IPv4 prefixes.
Book: ServerIron ADX
Server Load Balancing
Guide
Chapter: Server Load
Balancing
Section: “Policy-based SLB”
Book: ServerIron ADX
Security Guide.
Chapter: Network Security
Section: Transaction Rate
Limit (TRL)
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 ServerIron ADX to reject new DNS requests
when CPU utilization goes beyond a configured threshold.
Book: ServerIron ADX
Server Load Balancing
Guide
Chapter: Server Load
Balancing
Section: “Configuring DNS
CPU-based throttling”
ServerIron ADX Server Load Balancing Guide
53-1003452-01
15
1
Release 12.3.00
Release 12.3.00
16
Enhancement
Description
Documented in the following
books
Disaster Recovery
using Global Server
Load Balancing
(GSLB) in DNSSEC
Environments
DNS security extensions (DNSSEC) adds security to the
Domain Name System. DNSSEC validates message
authenticity which is an important component of DNS
security and helps mitigate cache poisoning attacks and
ensures data integrity. Brocade ServerIron ADX is extending
support for global server load balancing (GSLB) in DNSSEC
environments; thereby providing disaster recovery for
mission-critical applications.
In addition, the Brocade ServerIron ADX provides efficient
traffic distribution among DNSSEC servers while operating
in stateful or stateless mode.
Book: ServerIron ADX
Server Load Balancing
Guide
Chapter: Stateless Server
Load Balancing
Section:“Fragmentation
support in the stateless
mode”
SOAP/XML
Application
Programmatic
Interface (API)
The Brocade ServerIron ADX is extending support for an
XML API over SOAP to foster information exchange between
a ServerIron ADX and an external orchestration software or
tool. This enables service provider and enterprise
customers to communicate with a Brocade ServerIron ADX
from their familiar programming environments such as
PERL, JAVA etc, and gain additional control over their
application delivery infrastructures. The following is a brief
summary of control functions available through the
SOAP/XML API:
• Virtual server and port configuration
• Real server and port configuration
• Traffic statistics.
• System resource checks
Book: ServerIron ADX XML
API Programmers Guide
IS-IS support & IS-IS
Route Health Injection
(IPv4 and IPv6
With this release, support is extended for the IS-IS routing
protocol for both IPv4 and IPv6 prefixes:
• Support for level 1, level 2 and level 1+2 router types
• Support for IS-IS peering and related timers
• Support for Hello packet padding
• Support for router priority setting for designated router
(pseudo node) election
• Use of "multicast" MAC for IS-IS packet exchange
(hello, LSA) with peers
• Support for Equal Cost multi-path load balancing
(ECMP)
• Support for peer authentication modes: MD5 and
clear-text
• IS-IS Route filtering - distribute list to deny routes
• Disaster Recovery with IS-IS route health injection
Book: ServerIron ADX
Switch and Router Guide.
Chapter: Configuring IS-IS
(IPv4)
Chapter: Configuring IPv6
IS-IS
Traffic Segmentation
The traffic segmentation capability in release 12.3 allows
customers to implement additional security measures and
meet several PCI compliance guidelines. This functionality
ensures that traffic between SLB domains on the same
ServerIron ADX flows through an upstream layer3 device
such as a firewall instead of switching locally.
Book: ServerIron ADX
Security Guide.
Chapter: Network Security
Section: Traffic
Segmentation
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Release 12.3.00
1
Layer 7 Persistence
based on Server
inserted Cookie
The Brocade ServerIron ADX is adding intelligence to
inspect cookies inserted by application servers and
provides flow persistence based on inserted cookie values.
This greatly simplifies load balancing in certain
environments where persisting based on a server-inserted
cookie is critical to achieve flow integrity.
Book: ServerIron ADX
Server Load Balancing
Guide
Chapter: Layer 7 Content
Switching
Section: “Server passive
cookie persistence”
Jumbo Frame support
The release 12.3 extends support for larger packet sizes
up to 9K bytes in IPv4 server load balancing, transparent
cache switching and firewall load balancing environments.
Book: ServerIron ADX
Server Load Balancing
Guide
Chapter: Server Load
Balancing
Section: “Configuring a TCP
MSS value at the TCP profile
level”
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.
Book: ServerIron ADX
Server Load Balancing
Guide
Chapter: Server Load
Balancing
Section: “Fragmentation
support in the stateless
mode”
Event logging
The Event Logging feature of the ServerIron ADX captures
all of the activity on the MP and BP consoles and saves it in
a file named "eventlog.txt" which is saved on the internal
USB drive. This log captures all of the following information
along with a timestamp:
• Syslog messages when they are logged
• All MP console messages (boot and application)
• All BP console messages on each Core (boot and
application)
• All CLI commands typed by users at the MP and BP
consoles
• All commands typed at the OS prompt
Book: ServerIron ADX
Administration Guide
Chapter: ServerIron System
Management
Section: Event Logging
ServerIron ADX Server Load Balancing Guide
53-1003452-01
17
1
Release 12.2.1
Release 12.2.1
18
Enhancement
Description
Documented in the following
books
VIP Route Health
Injection (RHI) for
IPv6
Brocade ServerIron ADX offers two approaches for
achieving traffic distribution among multiple sites: global
server load balancing (GSLB) and VIP route health
injection. Both methods provide traffic distribution and site
failure protection. Unlike GSLB, VIP route health injection is
independent of the DNS infrastructure. It relies on the
underlying routing infrastructure to achieve load balancing.
Starting with this release, Brocade ServerIron ADX is
extending support for VIP route health injection to IPv6
application services. This allows injection of IPv6 VIP routes
inside the OSPF version 3 routing process meant for
carrying IPv6 routes. Consequently administrators can now
roll-out VIP route health injection based multi-site
redundancy solutions for both IPv4 and IPv6 application
services.
Book: ServerIron ADX
Server Load Balancing
Guide
Chapter: Server Load
Balancing
Section: “VIP route health
injection”
Weighted Round
Robin Static - A New
Load Balancing
Predictor
Predictors or load balancing algorithms play an important
role in achieving traffic distribution among application
servers. Brocade ServerIron ADX supports a variety of
predictors including: least connections, round-robin,
enhanced weighted, dynamic weighted and response time.
Many of these predictors are connection-based which
means that the application servers are picked based on
the current connection load situation. While this is ideal in
most situations, some designs require different treatment
for traffic distribution. To handle such designs, Brocade is
offering a new weighted-round-robin-static predictor that is
completely agnostic of current connection load.
Book: ServerIron ADX
Server Load Balancing
Guide
Chapter: Server Load
Balancing
Section: “Static Weighted
Round Robin predictor”
Auto Enable / Disable
SYN Proxy Attack
Protection
Brocade ServerIron ADX offers one of the best solutions in
the industry for protection against TCP SYN attacks. This
functionality is disabled by default and can be enabled on
a per-interface basis. This release offers additional
intelligence to automatically switch attack protection
on-or-off depending on thresholds that are pre- specified by
the administrator. When the connection rate exceeds a
specified "ON-threshold", the SYN proxy mechanism is
enabled automatically, and when the connection rate drops
below a specified "OFF-threshold", the SYN proxy
mechanism is disabled. This helps minimize connection
establishment latency associated with proxy connections
when infrastructure isn't under attack.
Book: ServerIron ADX
Security Guide
Chapter: Syn-Proxy and DoS
Protection
Section: Syn-Proxy auto
control
Section: Configuring
Syn-Proxy auto control
Passive FTP support
for Transparent Cache
Switching Designs
The Brocade ServerIron ADX provides for optimal
distribution of traffic among cache servers through its
Transparent Cache Switching or Redirection feature. This
feature improves the cache-hit ratio and saves WAN
bandwidth cost. The commonly used File Transfer Protocol
(FTP) can run in either of the two modes: active FTP or
Passive FTP. Previously, ServerIron ADX only offered
support for transparent cache switching with Active FTP.
This release extends transparent cache switching support
to Passive FTP.
Book: ServerIron ADX
Advanced Server Load
Balancing Guide
Chapter: Transparent Cache
Switching
Section: Passive FTP for TCS
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Release 12.2.1
1
Creating a Master
Password for export
of SSL keys
This feature allows you to create a master password that
grants permission to export all SSL keys on a ServerIron
ADX using SCP copy.
Book: ServerIron ADX
Security Guide
Chapter: Secure Socket
Layer (SSL) Acceleration
Section: Creating a Master
Password for export of SSL
keys
Cache Server
Persistence based on
Custom String
In a transparent cache redirection solution, it is critical to
provide cache server persistence to minimize content
duplication, maximize cache-hit ratio and save WAN
bandwidth.
Prior releases of Brocade ServerIron ADX offered cache
persistence based on the following: IP address, requested
URL path, requested URL host name and requested URL
parameters. This release extends this list by offering
persistence based on custom string within a requested
hostname or URL. A common example where this feature
can be helpful is with video streams that users download
from the Internet. Because each of these video streams
has a unique video-id, the cache hit ratio can be
significantly improved by persisting on a unique video-id
string that resides inside requested URL.
Book: ServerIron ADX
Advanced Server Load
Balancing Guide
Chapter: Configuring TCS
Section: Cache Persistence
using hashing on a portion
of the URL
Change to Cache
Persistence using
URL Hashing
In previous versions of the ServerIron ADX software, this
feature was configured using the csw-hash url command
within the server cache-group configuration. With this
release, it is configured as an match option within a CSW
policy configuration. The previous command is no longer
available.
Book: ServerIron ADX
Advanced Server Load
Balancing Guide
Chapter: Configuring TCS
Section: Cache Persistence
using hashing on a portion
of the URL
ServerIron ADX Server Load Balancing Guide
53-1003452-01
19
1
20
Release 12.2.1
ASM4 Product Bundle
Brocade is pleased to announce general availability of a
new ASM4-based ADX 4000 bundle. This bundle extends
the ServerIron ADX 4000 family and offers a new
entry-level, modular application delivery controller
platform. The bundle is delivered pre-configured with:
• one ASM4 application switch module (a
software-restricted flavor of ASM8 module)
• one management module
• one 12-port Gigabit Ethernet fiber line card
• eight Gigabit Ethernet copper SFP connectors
• two AC power supplies
• premium software.
The ASM4 module is enabled for four application cores,
and is upgradeable to eight application cores through the
capacity-on-demand feature of the ServerIron ADX. Using a
simplified, software license-upgrade approach, you can
double application throughput capacity of the ASM4
bundle from 9 Gbps to 17.5 Gbps. If you add a second
ASM8 module, then the performance will increase to 35
Gbps. This ASM4 bundle must run the Brocade ServerIron
ADX software release 12.2.1 or later.
Book: ServerIron ADX
Installation Guide
Chapter: Product Overview
Section: Application Switch
Module (ASM)
Book: ServerIron ADX
Administration Guide
Chapter: Capacity on
Demand
Section: Software-based
licensing overview
Multi-Zone Firewall
Load Balancing
The Brocade ServerIron ADX offers a powerful load
balancing solution for infrastructure devices such as
firewalls. You can distribute traffic load among multiple
low-end or high-end firewalls and achieve flow persistence
using the Brocade ServerIron ADX devices, and thereby
achieve maximum return on your investment.
Previously, the Brocade ServerIron ADX supported firewall
load balancing for up to 3 zones: internal, external and
DMZ zones. With this release, support is extended for up to
8 zones for larger deployments that involve firewall devices
supporting more than 3 zones. The number of firewall
paths has been raised from 32 to 64, while the maximum
supported firewall count is kept at 16.
Book: ServerIron ADX
Firewall Load Balancing
Guide
Chapter: Configuring
Multizone FWLB
Chapter: ServerIron FWLB
Overview
Section: FWLB
configuration limits
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Release 12.2.0
1
Release 12.2.0
Enhancement
Description
Documented in the following
books
TCP/UDP Content
Switching
TCP/UDP content switching allows the ServerIron ADX to
make switching decisions based on the content of TCP and
UDP traffic.
Book: ServerIron ADX
Server Load Balancing
Guide
Chapter: Layer 7 Content
Switching
Section: “TCP/UDP content
switching”
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.
Book: ServerIron ADX
Server Load Balancing
Guide
Chapter: Server Load
Balancing
Section: “Dedicated next
hop per VIP for reverse SLB
traffic”
Increasing TCS Hash
Bucket Count
This feature allows you to increase the TCS hash bucket
count to a higher number to ensure a more reasonable
distribution of excess traffic among remaining cache
servers when a cache server goes down.
Book: ServerIron ADX
Advanced Server Load
Balancing Guide
Chapter: Configuring TCS
Section: Increasing TCS
hash bucket count
Enabling
hardware-based
multicast switching
Where there are high amounts of multicast traffic, this
feature allows you to configure hardware-based multicast
switching on a ServerIron ADX to enable the ingress port to
flood multicast traffic across the VLAN instead of sending it
to the management module.
Book: ServerIron ADX
Switch and Router Guide
Chapter: Configuring Basic
Layer-2 parameters
Section: Enabling hardware
-based multicast switching
Section: Trunking
configured with
Hardware-based Multicast
Switching
Configuring a Real
Port as TCP-only or
UDP-only
This feature allows you to configure a ServerIron 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).
Book: ServerIron ADX
Server Load Balancing
Guide
Chapter: Server Load
Balancing
Section: “Configuring a real
port as TCP only or UDP
only”
ServerIron ADX Server Load Balancing Guide
53-1003452-01
21
1
22
Release 12.2.0
Response time load
balancing
This feature Distributes traffic among real servers based
on a dynamic weight value that is derived from the
response time of health check packets.
Book: ServerIron ADX
Server Load Balancing
Guide
Chapter: Server Load
Balancing
Section: “Server response
time”
Section: “Changing the
Load-Balancing Predictor
Method”
Section: “Configuring the
smooth factor”
Cache Persistence
using URL Hashing
The ServerIron ADX enables traffic distribution among
cache servers in a TCS setup after inspecting and hashing
based on the request URL. This enables cache persistence
based on the requested URL and minimizes duplication of
content among multiple cache servers.
Book: ServerIron ADX
Advanced Server Load
Balancing Guide
Chapter: Configuring TCS
Section: Cache Persistence
using URL Hashing
Default CSW
Forwarding to the
Internet
In previous released, when no rule in a CSW policy was
matched, the traffic was dropped by default. With this
release, when no CSW rule is matched, traffic is forwarded
to the Internet by default.
Book: ServerIron ADX
Server Load Balancing
Guide
Chapter: Layer 7 Content
Switching
Section: “CSW policies”
Display of Layer 7
cache buckets
The show cache-group command has been enhanced to
display the number of Layer 7 cache buckets.
Book: ServerIron ADX
Advanced Server Load
Balancing Guide
Chapter: Configuring TCS
Section: Displaying Cache
Information
Port holddown timer
When configured, this feature prevents a failed port from
being marked active until a configurable time period has
elapsed.
Book: ServerIron ADX
Server Load Balancing
Guide
Chapter: Server Load
Balancing
Section: “Port holddown
timer”
IPv6 to IPv4 Gateway
This feature allows an IPv6 client to send and receive
packets to and from an IPv4 server.
Book: ServerIron ADX
Server Load Balancing
Guide
Chapter: IPv6 Support for
Server Load Balancing
Section: “IPv6 to IPv4
gateway”
Setting a DSCP value
for SIP heath check
This feature allows you to set a DSCP value in the IP header
of SIP health-check packets.
Book: ServerIron ADX
Advanced Server Load
Balancing Guide
Chapter: SIP Server Load
Balancing
Section: Configuring a DSCP
value for SIP health checks
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Release 12.2.0
1
QOS marking of SLB
packets
This feature allow you to configure a ServerIron ADX to set
the DSCP bits to a configured value in all packets sent to
servers bound to a specified VIP. This feature can be used
with Layer-3 DSR servers that are appropriately coded with
additional intelligence to interpret DSCP marked packets
and send them directly to the clients.
Book: ServerIron ADX
Server Load Balancing
Guide
Chapter: Server Load
Balancing
Section: “TOS marking of
SLB and health check
packets”
SNMP-based Cache
Server Load
Balancing
This feature allows you to use SNMP to monitor the load on
cache servers and load-balance the cache servers using
that information.
Book: ServerIron ADX
Advanced Server Load
Balancing Guide
Chapter: Configuring TCS
Section: SNMP-based cache
server load balancing
Enhanced Support for
root and intermediate
CA certificates.
This features provides Support for up to 32 DN names for
all root and intermediate CA certificates.
Book: ServerIron ADX
Security Guide
Chapter: Secure Socket
Layer (SSL) Acceleration
Section: Configuring a CA
Certificate File
Increased certificate
chain depth.
This feature allow you to increase certificate chain depth
within an SSL profile from the default of 4 up to a
maximum of 10
Book: ServerIron ADX
Security Guide
Chapter: Secure Socket
Layer (SSL) Acceleration
Section: Configuring
certificate chain depth
Enhancements to GUI
With this release, two new functions are added to the
Graphical User interface:
• Software Upgrade
• Application Template
Book: ServerIron ADX
Graphical User Interface
Guide
Chapter: Configuring Server
Load Balancing
Chapter: Maintenance
Capacity on Demand
Software and hardware features of both fixed-configuration
(ServerIron ADX 1000 series) and chassis (ServerIron ADX
4000 and 10000) ServerIron ADX application switches can
be obtained at time of purchase or upgraded later through
software-based licensing.
Book: ServerIron ADX
Administration Guide
Chapter: Capacity on
Demand
ServerIron ADX Server Load Balancing Guide
53-1003452-01
23
1
Release 12.1.00
Release 12.1.00
24
Enhancement
Description
Documented in the following
books
SSL Acceleration
(configuration)
With this release, ServerIron ADX supports integrated
hardware-based SSL acceleration. The referenced section
describes how the feature works and how to configure
software for it.
Book: ServerIron ADX
Security Guide
Chapter: Secure Socket
Layer (SSL) Acceleration
SSL Acceleration
(hardware)
This referenced section describes the hardware required
for SSL acceleration and how to install it.
Book: ServerIron ADX
Installation Guide
Boot and FPGA
Automated Upgrade
When you reload your system with version 12.1.00 of the
software, it automatically checks to see if the boot code
and FPGA code on your system are compatible with the
application image being loaded. If you have an older
version of the boot code or FPGA code, it will be displayed
and you will be directed to use the boot upgrader
command to load the appropriate code.
Book: Release Notes for
TrafficWorks Software
Release 12.1.00
Section: Upgrading Boot
and FPGA Code
Track Trunk Port with
VRRP-E
The Track Trunk Port with VRRP-E feature allows the
ServerIron ADX to track the failure of individual ports within
a trunk. When a tracked port within a trunk fails, the VRID
priority value is changed, which changes the failover value.
Book: ServerIron ADX
Switch and Router Guide
Chapter: Configuring VRRP
and VRRP-E
Section: Track Trunk Port
with VRRP-E
Management Port
With this release, the ServerIron ADX supports an Ethernet
port that is designed for managing the device. This port
allows you to provide management access to a ServerIron
ADX on a separate and more secure network than the one
where general network traffic is being passed. This access
is provided through an RJ-45 connector on the front panel
of the ServerIron ADX 1000 platforms or on the
management module for ServerIron ADX chassis products.
Book: ServerIron ADX
Administration Guide
Chapter: ServerIron ADX
System Management
Section: Using the
Management Port
UDLD for Tagged and
Untagged ports
With this release, Uni-Directional Link Detection (UDLD)
support for Tagged and Untagged ports has changed. See
the referenced document for details.
Book: ServerIron ADX
Switch and Router Guide
Chapter: Configuring
Uni-Directional Link
Detection (UDLD)
Section: Configuring UDLD
Single link LACP
This release supports single-link LACP on the ServerIron
ADX. A single instance of link aggregation (single-link LACP)
can be used to provide unidirectional link detection.
Single-link LACP is based on the 802.3ad LACP protocol,
but allows you to form an aggregated link with only one
Ethernet port.
Book: ServerIron ADX
Switch and Router Guide
Chapter: Configuring Trunk
Groups and Dynamic Link
Aggregation
Section: Single link LACP
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Release 12.1.00
1
Any port static/LACP
trunks
In previous versions of the ServerIron ADX, ports in a trunk
had to be in continuous groups. Now you can configure any
eight ports in a static or LACP trunk.
Book: ServerIron ADX
Switch and Router Guide
Chapter: Configuring Trunk
Groups and Dynamic Link
Aggregation
Section: Trunk Group Rules
IPv6
This release supports the IPv6 protocol.
Book: ServerIron ADX
Switch and Router Guide
Chapter: Configuring IPv6
Addressing
Chapter: Configuring IPv6
Dynamic Routing
Book: ServerIron ADX
Server Load Balancing
Guide
Chapter: Server Load
Balancing
Section: IPv6 Support for
SLB
sFlow
This release introduces the sFlow feature to the ServerIron
ADX. sFlow is a system for observing traffic flow patterns
and quantities within and among a set of ServerIron ADX
devices
Book: ServerIron ADX
Switch and Router Guide
Chapter: sFlow
Syn-cookie threshold
trap
This release supports the configuration of a syn-cookie
threshold trap.
Book: ServerIron ADX
Security Guide
Chapter: Network Security
Section: Syn-cookie
threshold trap
Minimum Health
Servers on a VIP port
With this feature, you can configure a VIP port to carry
traffic only when a configured minimum number of real
server ports that are bound to the VIP port are healthy and
in the UP state.
Book: ServerIron ADX
Server Load Balancing
Guide
Chapter: Server Load
Balancing
Section: Minimum healthy
servers on a VIP port
Route Only
The Route Only feature allows one port or all ports in a
system to be configured in a mode where only packets
meant for Layer-3 forwarding are forwarded by the system.
Book: ServerIron ADX
Switch and Router Guide
Chapter: Configuring Base
Layer-3
Section: Disabling Layer 2
switching
Role Based
Management
Role Based Management (RBM) allows a user to view
and/or update configurations, including virtual servers,
real servers, and csw policies, without being able to view or
edit configurations associated with another user.
Book: ServerIron ADX
Administration Guide
Chapter: Role Based
Management
Configuring Failover
based on the number
of Active Virtual Ports
With this feature, you can configure the active-standby peer
to fail over based on the number of router ports and active
virtual ports.
Book: ServerIron ADX
Server Load Balancing
Guide
Chapter: High Availability
Section: Configuring failover
based on the number of
active virtual ports
ServerIron ADX Server Load Balancing Guide
53-1003452-01
25
1
26
Release 12.1.00
Delayed High
Availability Failover
With this feature configured, when a ServerIron ADX switch
detects a failover condition because of a VIP/VPORT count
change, the failover is delayed and re-examined after a
configured time period.
Book: ServerIron ADX
Server Load Balancing
Guide
Chapter: High Availability
Section: Delayed Failover
Syn-cookie with
Packet Buffering
In this release, packet buffering has been increased from
one to six packets.
N/A
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Chapter
Server Load Balancing
2
Overview
The Application Delivery Controllers (ADC) such as Brocade ServerIron ADX help 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 ServerIron application delivery switch, 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 ServerIron ADX.
In addition to offering increased control over server resources, the ServerIron 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, then the ServerIron 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 ServerIron can be
configured to host multiple application services such as web (http), ftp, or DNS under a single
virtual server.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
27
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 ServerIron ADX. All
queries made to this web site arrive at the virtual server. The ServerIron 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 ServerIron 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.
NAT is performed for both directions of the traffic flow. Converting virtual services to real services
requires IP and TCP checksum modifications.
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 ServerIron ADX or locally per
virtual server as described in “Changing the Load-Balancing Predictor Method” on page 42.
28
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Overview
2
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 ServerIron ADX or locally per-virtual
server as described in “Changing the Load-Balancing Predictor Method” on page 42.
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 Server1.
5. The fifth request is sent to Server2.
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 ServerIron ADX or locally
per virtual server as described in “Changing the Load-Balancing Predictor Method” on page 42.
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 ServerIron ADX. Consequently, server selection can be concurrent to better utilize your
system capacity. The following description provides a simple example:
The ServerIron ADX has the following configuration:
• Two BPs are enabled and in an operating state
• Two servers are connected: Server1 with a weight of 4, Server2 with a weight of 2
For BP1, distribution occurs 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 Server1.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
29
2
Overview
5. The fifth request is sent to Server2.
6. The sixth request is sent to Server1.
For BP2, distribution occurs 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 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 ServerIron ADX or
locally per virtual server as described in “Changing the Load-Balancing Predictor Method” on
page 42.
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.
30
ServerIron ADX Server Load Balancing Guide
53-1003452-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 1 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 1.
TABLE 1
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
ServerIron ADX Server Load Balancing Guide
53-1003452-01
31
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 2 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 2.
TABLE 2
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 42.
32
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Overview
2
Dynamic weighted predictor
ServerIron 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 ServerIron retrieves this information (through the SNMP protocol) from MIBs
available on the application servers.
To achieve this capability, a software process in ServerIron, 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 ServerIron. A ServerIron can be configured as both SNMP agent (that allows
management of ServerIron 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
ServerIron.
You can fine-tune how traffic is distributed across these real servers by enabling Dynamic Weighted
Predictor on the ServerIron. SNMP dynamic predictor is presently not supported for IPv6 traffic.
The Dynamic Weighted predictors can be applied globally to apply for the entire ServerIron ADX or
locally per virtual server as described in “Changing the Load-Balancing Predictor Method” on
page 42 and “Configuring dynamic weighted predictor” on page 44.
NOTE
In ServerIron ADX, the global snmp-server command 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 ServerIron 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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
33
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 ServerIron ADX
or locally per virtual server as described in “Changing the Load-Balancing Predictor Method” on
page 42.
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, except for Secure Socket Layer (SSL).
34
ServerIron ADX Server Load Balancing Guide
53-1003452-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 ServerIron 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 ServerIron 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.
Refer to “Multiple port binding using port aliases” on page 530 for an example of this feature.
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.
FIGURE 2
Concurrent connections in operation on an SLB network
A client initiates a session request to the NETPERF 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.
NOTE
The method the server uses to communicate the dynamic port to the client is application-specific.
The ServerIron ADX switches all subsequent connections to S2 to ensure that the NETPERF session
completes successfully.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
35
2
Overview
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 ServerIron.
Direct Server Return
DSR (Direct Server Return) configures the ServerIron ADX to instruct real servers to send client
responses directly to the clients instead of sending the responses back through the ServerIron
ADX. As a result, the clients experience faster response times and the ServerIron ADX is free to
support more sessions to serve more clients.
ServerIron ADX supports both Layer 2 Direct Server Return (L2 DSR) and Layer 3 Direct Server
Return (L3 DSR).
• In an L2 DSR configuration, the ServerIron ADX and the real servers are on the same subnet.
• In an L3 DSR configuration, the ServerIron 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 ServerIron ADX sends client requests
addressed to a VIP to a load balanced real server. However, the ServerIron 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 ServerIron ADX leaves the destination IP address
unchanged. And the ServerIron 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
ServerIron 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 ServerIron 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.
36
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Overview
2
Figure 3 shows an example of a ServerIron ADX deployed in an L2 DSR configuration.
FIGURE 3
ServerIron ADX in an L2 DSR configuration
The example above shows the flow of packets in which the ServerIron ADX and the real servers are
Layer 2 connected.
1. The client sends a packet to an VIP on the ServerIron ADX.
2. The ServerIron 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 85.
Understanding L3 DSR
As with L2 DSR, a ServerIron 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 ServerIron ADX.
But unlike L2 DSR, which requires that the ServerIron 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 ServerIron 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 ServerIron ADX has
additional intelligence to handle health checks response packets. Figure 4 shows an example of a
ServerIron ADX deployed in an L3 DSR configuration.
FIGURE 4
ServerIron ADX in an L3 DSR configuration
In the example, the ServerIron 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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
37
2
Configuring basic SLB
1. The client sends a packet to an L3 DSR VIP on the ServerIron ADX.
2. The ServerIron 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 90.
Configuring basic SLB
To configure basic SLB, perform the following tasks:
• Define the application servers as real servers on the ServerIron ADX. Refer to “Defining the
real servers and real application ports” on page 39.
• Define a virtual server. Refer to “Defining a virtual server (VIP)” on page 40.
• Bind the real servers to the VIP. Refer to “Binding virtual and real servers” on page 41.
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 the example show how to configure the ServerIron ADX in the example using
the CLI.
FIGURE 5
38
Basic SLB configuration
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Configuring basic SLB
TABLE 3
2
Real and virtual server assignments
Domain name
Virtual IP
Port
Real IP
Port
www.alterego.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 98.
• One virtual TCP or UDP port can be bound to one or more real TCP or UDP ports.
NOTE
If you need to map a real server port to multiple VIP ports, you can use the many-to-one TCP or
UDP port binding feature. Refer to “Multiple port binding” on page 98.
• 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.
ServerIronADX(config)#server real Web1 10.95.55.21
ServerIronADX(config-rs-Web1)#port http
ServerIronADX(config-rs-Web1)#port dns
ServerIronADX(config-rs-Web1)#exit
ServerIronADX(config)#server real Web2 10.95.55.22
ServerIronADX(config-rs-Web2)#port http
ServerIronADX(config-rs-Web2)#port dns
ServerIronADX(config-rs-Web2)#exit
ServerIronADX(config)#server real Web3 10.95.55.23
ServerIronADX(config-rs-Web3)#port http
ServerIronADX(config-rs-Web3)#port dns
ServerIronADX(config-rs-Web3)#exit
ServerIron ADX Server Load Balancing Guide
53-1003452-01
39
2
Configuring basic SLB
ServerIronADX(config)#server real Web4 10.95.55.24
ServerIronADX(config-rs-Web4)#port http
ServerIronADX(config-rs-Web4)#port dns
ServerIronADX(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.
ServerIronADX(config)#server real Web1
ServerIronADX(config-rs-Web1)#port ftp
ServerIronADX(config-rs-Web1)#exit
ServerIronADX(config)#server real 10.95.55.21
ServerIronADX(config-rs-Web1)#port ftp
ServerIronADX(config-rs-Web1)#exit
ServerIronADX(config)#no server real Web1
NOTE
If a real server is not reachable from the ServerIron ADX at Layer 2 (does not respond to ARP
requests from the ServerIron), 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 ServerIron 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 ServerIron 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.
ServerIronADX(config-rs-Web4)#server virtual-name-or-ip www.example7.com
10.95.55.1
ServerIronADX(config-vs-www.example7.com)#port http
Syntax: [no] server virtual-name-or-ip name ip-address
Syntax: [no] port tcp/udp-port
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.
ServerIronADX(config)#server virtual-name-or-ip www.example7.com 10.95.55.1
ServerIronADX(config-vs-www.example7.com)#port http
ServerIronADX(config-vs-www.example7.com)#exit
40
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Configuring basic SLB
2
ServerIronADX(config)#server virtual-name-or-ip 10.95.55.1
ServerIronADX(config-vs-www.example7.com)#exit
ServerIronADX(config)#server virtual-name-or-ip www.altergo.com
ServerIronADX(config-vs-www.example7.com)#exit
ServerIronADX(config)#no server virtual-name-or-ip 10.95.55.1
Defining a virtual server name
Use the name command to change the existing name of a virtual server.
ServerIronADX(config)#configure terminal
ServerIronADX(config)#server virtual-name-or-ip www.example7.com 10.95.55.1
ServerIronADX(config-vs-www.example7.com)#name example8
ServerIronADX(config-vs-example8)#
Syntax: name string
The string variable is the new name of the virtual server. Enter an alphanumeric name with a
maximum of 42 characters without spaces or 42 characters including spaces within quotes. You
can include special characters in the name.
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.
ServerIronADX(config-rs-Web4)#server virtual-name-or-ip www.altergo.com
ServerIronADX(config-vs-www.example7.com)#bind http Web1 http
ServerIronADX(config-vs-www.example7.com)#bind http Web2 http
ServerIronADX(config-vs-www.example7.com)#bind http Web3 http
ServerIronADX(config-vs-www.example7.com)#bind http Web4 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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
41
2
Changing the Load-Balancing Predictor Method
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 ServerIron ADX, enter the following
command.
ServerIronADX(config)#server predictor round-robin
To change the load-balancing method used by the ServerIron ADX for virtual server “v1”, enter the
following commands.
ServerIronADX(config)#server virtual-name-or-ip v1
ServerIronADX(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 28.
Selecting the round-robin parameter configures the Round Robin load-balancing method. This
method is described in “Round Robin predictor” on page 29.
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 29.
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 29.
Selecting the weighted parameter configures the Weighted load-balancing method. This method is
described in “Weighted and Enhanced Weighted load balancing” on page 30.
Selecting the enhanced-weighted parameter configures the Weighted load-balancing method. This
method is described in “Weighted and Enhanced Weighted load balancing” on page 30.
Selecting the response-time parameter configures the response time load-balancing method. This
method is described in “Server response time” on page 34. Configuring the response time load
balancing method requires that you configure a smooth factor as described in “Configuring the
smooth factor” on page 46.
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 33. Details about configuring the Dynamic Weighted load-balancing
method as direct or reverse are described in “Configuring dynamic weighted predictor” on page 44.
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 43.
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 28.
42
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Changing the Load-Balancing Predictor Method
2
Configuring a weighted predictor
Several of the Load-Balancing Predictor Methods used on the ServerIron ADX require that weights
be assigned to the real servers. The ServerIron 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 ServerIron 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
ServerIron ADX will assume the weight for that real server is 1.
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.
ServerIronADX(config)#server real rsA
ServerIronADX(config-rs-rsA)#weight 1
ServerIronADX(config-rs-rsA)#exit
ServerIronADX(config)#server real rsB
ServerIronADX(config-rs-rsB)#weight 2
ServerIronADX(config-rs-rsB)#exit
ServerIronADX(config)#server real rsC
ServerIronADX(config-rs-rsC)#weight 3
ServerIronADX(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 parameter 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 ServerIron ADX has for TCP or UDP sessions with the real server. You can
specify a value from 0 through 65000. The default is 1.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
43
2
Changing the Load-Balancing Predictor Method
Configuring the weight for real servers
This parameter 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.
ServerIronADX(config)#server virtual-name-or-ip www.example7.com
ServerIronADX(config-vs-www.example7.com)#predictor weighted
ServerIronADX(config-vs-www.example7.com)#server real Web1 10.95.55.21
ServerIronADX(config-vs-www.example7.com)#exit
ServerIronADX(config)#server real Web1
ServerIronADX(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 ServerIron ADX has for TCP or UDP sessions with the
real server. You can specify a value from 0–65000. The default is 1. This parameter is required.
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 parameter.
If you enter a value for response-time-weight, the ServerIron ADX adds the two weight values
together when selecting a real server. If you specify equal values for each parameter, the ServerIron
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
ServerIron 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 ServerIron 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 44
• “Configuring a virtual server with a dynamic weighted predictor” on page 45
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.
ServerIronADX(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 parameter specifies the snmp-request entry identification, decimal value 1 through 256.
The string parameter specifies the ASCII string ASN.1 format. In this example,
1.3.6.1.2.1.25.3.3.1.2.1.
44
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Changing the Load-Balancing Predictor Method
2
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.
ServerIronADX(config-rs-rs1)#snmp-request community public
Syntax: snmp-request community public port
The port parameter specifies the snmp-request host UDP port (Default: port 161).
You can configure the frequency of the periodic SNMP queries using the following command.
ServerIronADX(config)#server snmp-poll 5
Syntax: server snmp-poll num
The num parameter 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.
Dynamic-weighted direct
To configure a dynamic-weighted reverse predictor, use the following command.
ServerIronADX(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.
ServerIronADX(config-vs-vs1)#predictor dynamic-weighted reverse oid 1 max 50
Syntax: predictor dynamic-weighted reverse oid ID [max value]
DECIMAL
Max value - reverse weight = direct weight
Configuration example
ServerIronADX(config)#server snmp-poll 5
ServerIronADX(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
ServerIronADX(config)#server virtual vs1 10.200.1.1
predictor dynamic-weighted direct oid 1
ServerIron ADX Server Load Balancing Guide
53-1003452-01
45
2
Changing the Load-Balancing Predictor Method
Configuring the smooth factor
This section applies to the server response time load balancing method.
The ServerIron 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 ServerIron 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 ServerIron ADX collects the response time samples for every five
seconds. The sampling rate can vary slightly depending on the processing the ServerIron ADX is
performing.
To smooth the samples out, the ServerIron 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 1–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
default smooth factor 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 ServerIron 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 (the default) to 50, the
calculations shown above have the following results:
46
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Real server ports
2
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
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:
ServerIronADX(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–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 243.
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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
47
2
Real server ports
• Layer 7 health check parameters – For some application ports that are known to the
ServerIron ADX, you can customize the Layer 7 health checks for individual real servers.
NOTE
For the HTTP ports, you also can configure Layer 7 health checks for Transparent Cache
Switching.
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.
ServerIronADX(config)#server real Sy_Borg 192.168.4.69
ServerIronADX(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.
ServerIronADX(config)#server real Sy_Borg 192.168.4.69
ServerIronADX(config-rs-Sy_Borg)#no port http disable
To disable all the application ports on a real server, enter the following command at the
configuration level for the server.
ServerIronADX(config-rs-R1)#port disable-all
To re-enable all the application ports, enter the following command.
ServerIronADX(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 ServerIron 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 ServerIron 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.
ServerIronADX(config)#server port 80
ServerIronADX(config-port-http)#disable real
ServerIronADX(config-port-http)#
To disable all virtual HTTP ports, enter the following commands.
ServerIronADX(config)#server port 80
ServerIronADX(config-port-http)#disable virtual
ServerIronADX(config-port-http)#
48
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Real server ports
2
To disable all real and virtual HTTP ports, enter the following commands.
ServerIronADX(config)#server port 80
ServerIronADX(config-port-http)#disable
ServerIronADX(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 ServerIron 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
ServerIron ADX, the ServerIron 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 ServerIron 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.
When you enable this feature, the ServerIron 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:
ServerIronADX(config)#server virtual vip-test 10.50.1.250
ServerIronADX(config-vs-vip-test)#port http
ServerIronADX(config-vs-vip-test)#port http reset-on-port-fail
ServerIronADX(config-vs-vip-test)#
The previous 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 ServerIron 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 ServerIron 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 284 for more information.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
49
2
Real server ports
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.
ServerIronADX(config)#server real Auto_Plooker 192.168.2.69
ServerIronADX(config-rs-Auto_Plooker)#port http keepalive
To disable the keepalive health check, enter commands such as the following.
ServerIronADX(config)#server real Auto_Plooker 192.168.2.69
ServerIronADX(config-rs-Auto_Plooker)#no port http keepalive
Syntax: [no] port tcp/udp-port keepalive
Configuring a real port as TCP only or UDP only
This feature allows you to configure a ServerIron 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 and 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 port portnum tcp-only and udp-only commands for a real port are configured under the real
configuration mode as shown in the following.
ServerIronADX(config)#server real R1 10.10.10.1
ServerIronADX(config-rs-R1)#port 80 tcp-only
ServerIronADX(config-rs-R1)#exit
ServerIronADX(config)#server real R2 10.10.11.1
ServerIronADX(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 and UDP only.
TCP only and UDP only are mutually exclusive. When the tcp-only keyword is configured, the
udp-only keyword cannot be configured for a port at the same time. The udp-only keyword will be
automatically disabled if the tcp-only keyword is configured, and vice versa.
50
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Real server ports
2
Configuring a stateless port
By default, the ServerIron ADX creates session table entries for sessions between clients and
applications on real servers. The ServerIron ADX uses the session table entries to maintain state
information for the sessions. The ServerIron 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 ServerIron 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.
ServerIronADX(config)#server real R1 10.10.10.1
ServerIronADX(config-rs-R1)#port http
ServerIronADX(config-rs-R1)#exit
ServerIronADX(config)#server real R2 10.10.11.1
ServerIronADX(config-rs-R2)#port http
ServerIronADX(config-rs-R2)#exit
ServerIronADX(config)#server virtual-name-or-ip StatelessHTTP 192.168.4.69
ServerIronADX(config-vs-StatelessHTTP)#port http stateless
ServerIronADX(config-vs-StatelessHTTP)#bind http R1 http
ServerIronADX(config-vs-StatelessHTTP)#bind http R2 http
Syntax: [no] port tcp/udp-portnum stateless
The tcp/udp-portnum variable specifies the application port you want to make stateless.
NOTE
The ServerIron 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 ServerIron ADX automatically replaces the source IP address to a VIP. When you
configure port translation, the ServerIron ADX overcomes the limitation of performing NAT on all
packets initiated from the real server. NAT does not occur because the ServerIron ADX does not
match the port number.
NOTE
The ServerIron ADX supports stateless SLB for any TCP and UDP application protocols. For a TCP
application, hashing must be enabled on the ServerIron ADX. For a UDP application, you can enable
or disable hashing on the ServerIron ADX.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
51
2
Adding a source IP address
Adding a source IP address
You can define source IP addresses on a ServerIron ADX system running switch code to place it in a
multi-netted environment. These source IP addresses can potentially be used as default gateways
for real servers. You can also define source NAT IP addresses while using source NAT.
The additional IP addresses allow you to deploy the ServerIron ADX in multi-netted environments,
including the following examples:
• The ServerIron ADX and real servers are on different subnets.
• The remote access server (RAS) and ServerIron ADX are on different subnets.
• The border access router (BAR) and ServerIron ADX are on different subnets.
Refer to “Web hosting with ServerIron ADX and real servers in different subnets” on page 534 for
an example of the type of configuration in which you need to use this feature.
NOTE
Depending on the configuration, you might also need to enable source NAT. Refer to “Web hosting
with ServerIron ADX and real servers in different subnets” on page 534 for general information
about the NAT operations performed by the ServerIron ADX.
The ServerIron ADX supports a maximum of 64,000 simultaneous connections on each source IP
address. This maximum value is based on the architectural limits of IP itself. As a result, if you add
only one source IP address, the ServerIron ADX can support up to 64,000 simultaneous
connections to the real servers. If you configure 64 source IP addresses, the ServerIron ADX can
support more simultaneous connections.
ServerIronADX(config)#server source-ip 192.168.1.5 255.255.255.0 192.168.1.1
Syntax: [no] server source-ip ip-addr network-mask default-gateway
The default-gateway variable is required. By specifying "0.0.0.0" as a gateway, the system is going
to use the ip default-gateway configuration for the default gateway. The gateway function will not
actually be disabled for the interface.
52
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Adding a source IP address
2
You can configure source IP addresses to enable the ServerIron ADX to communicate with routers
and real servers in different subnets. For example, Figure 6 shows an example of a ServerIron ADX
that uses both public and private source NAT addresses.
NOTE
You can define a combined total of 64 source-ip and source-nat-ip addresses on a ServerIron ADX
running switch code. The source-ip command is not required on ServerIrons running router code.
FIGURE 6
ServerIron ADX configured with public and private source NAT addresses
The ServerIron ADX in this example is configured with three source IP addresses. Two of the
addresses are in the subnets of the real servers and the third address is in the same subnet as the
ServerIron ADX management address.
The software considers any address that is not within the following address ranges to be a public
address. These address ranges are defined as private address ranges in RFC 1918:
• 10.0.0.0 – 10.255.255.255
• 172.16.0.0 – 172.31.255.255
• 192.168.0.0 – 192.168.255.255
You can also use the server source-ip command under a real server to designate the source IP
address for Source NAT.
For example, to specify that traffic from remote real server R1 use 10.77.7.7 as its source IP
address, enter the following commands.
ServerIronADX(config)#server remote R1 10.77.7.2
ServerIronADX(config-rs-R1)#source-ip 10.77.7.7
If the ip-addr variable is not already configured as a source IP address on the ServerIron ADX (with
the server source-ip command), an error message is displayed.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
53
2
Source NAT
The server source-ip configuration is primarily used to provide the ServerIron ADX with source IP
addresses in subnets other than that of the Management IP address. You can configure source IP
addresses in the same subnet as the management IP, and you can configure multiple source IP
addresses within each subnet. This gives you multiple opportunities to specify multiple default
gateways for each subnet. However, the ServerIron uses only one default gateway per subnet. The
ServerIron ADX uses the following rules when using the default gateways you have configured:
1) If the server source-ip configuration is in the same subnet as the Management IP address (M-IP)
then the ServerIron ADX will use the Management IP address (M-IP) default gateway (the IP
address you have configured with the ip default-gateway command) and ignore any other default
gateway that you would have configured at the end of the server source-ip command. In the
following example, the ServerIron will use only 192.168.1.254 as a gateway and will ignore
192.168.1.253.
server source-ip 192.168.1.11 255.255.255.0 192.168.1.253
ip address 192.168.1.10 255.255.255.0
ip default-gateway 192.168.1.254
2) If you configure multiple server source-ip addresses in a subnet different from the Management
IP address's, then the ServerIron ADX will use the gateway that you configure at the end of the first
server source-ip command. In the following example, the ServerIron ADX will use 192.168.1.254 as
the gateway for all packets from 192.168.1.10 and 192.168.1.11 and also uses 192.168.2.254 as
the gateway for all packets from 192.168.2.10 and 192.168.2.11. The ServerIron ADX will ignore
192.168.1.253 and 192.168.2.253.
server source-ip 192.168.2.10 255.255.255.0 192.168.2.254
server source-ip 192.168.2.11 255.255.255.0 192.168.2.253
server source-ip 192.168.1.11 255.255.255.0 192.168.1.253
ip address 192.168.1.10 255.255.255.0
ip default-gateway 192.168.1.254
The server source-ip configuration is only applicable when ServerIron ADX is using the switch code.
If you need to have a different gateway for each destination network (for example, if you have your
remote real servers split between multiple subnets, with each subnet behind a different router, and
each of these routers directly connected to the ServerIron ADX), Brocade recommends that you use
router code instead of switch code.
Source NAT
Source NAT configuration is useful where a ServerIron is connected in one-armed mode; for
example where it is connected to the network infrastructure through an uplink as shown in
Figure 7.
In this situation the ServerIron 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 ServerIron 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 ServerIron ADX replaces the IP address of a client IP with the IP
address of the ServerIron ADX in request packets forwarded to the real server. This action forces
the real server to forward replies to the ServerIron ADX instead of bypassing it.
54
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Source NAT
2
Figure 7 provides an example of what can occur when a real server has a path back to a client that
bypasses a ServerIron ADX without Source NAT enabled as described in the following.
1. A request from the Client arrives at the ServerIron through a Layer 2 switch.
2. The ServerIron translates the VIP IP address to the IP address of the real server and forwards
the request to the real server.
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 ServerIron.
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 7
Scenario without source NAT configured
In Figure 8 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 ServerIron through a Layer 2 switch.
2. The ServerIron 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 ServerIron and replies back
through the Layer 2 switch to the ServerIron.
4. The ServerIron translates the IP address of the real server to the VIP IP address and replies to
the client.
FIGURE 8
Scenario with source NAT configured
ServerIron ADX Server Load Balancing Guide
53-1003452-01
55
2
Source NAT
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”.
Enabling source NAT globally
Source NAT allows the ServerIron 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 ServerIron 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 ServerIron ADX.
To enable source NAT globally, enter the following command.
ServerIronADX(config)#server source-nat
Syntax: [no] server source-nat
On a ServerIron ADX running switch code, you must also configure a source IP address. These
ServerIron ADXs use source NAT to translate the management IP address in the source field of the
IP packet into the source IP address you configure. Refer to “Minimizing source-IP and
source-NAT-IP requirements for large deployments” on page 59. Refer to “Web hosting with
ServerIron ADX and real servers in different subnets” on page 534 for an example of the type of
configuration in which you need to use Source NAT.
By default, you can define a total of 64 source-ip and source-nat-ip addresses on ServerIron ADX
devices running switch code. You can can increase the maximum supported SNAP IP addresses
from 64 to 128 separately for both IPv4 and IPv6. For more information, refer to “Configuring
maximum source-NAT IP addresses.”
The source-ip command is not required on ServerIrons running router code.
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 IP” on page 60 and “Enabling
port allocation per real server for source NAT IP” on page 60 for details.
NOTE
When source NAT is enabled for FTP traffic, the ServerIron ADX only supports one mode for an
established connection. This means that a user cannot toggle between active and passive mode for
an existing FTP connection.
NOTE
For Router (R) code, the ServerIron ADX uses the Interface or VE address to do source NAT by default.
No user action is needed. Optionally, you can define source NAT IP addresses if they are required.
You can define total of 64 Interface or VE and source NAT IP addresses. Interface or VE addresses
do not exist on Switch (S) code.
If you are configuring a pair of ServerIron ADXs for hot-standby (active-standby) HA and you want to
use the same source IP address on each ServerIron ADX, use the server source-nat-ip command
instead.
56
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Source NAT
2
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 ServerIron ADX.
Enabling source NAT on a real server
Source NAT allows the ServerIron ADX to use a source IP address as the source for packets sent to
the real server.
Source NAT allows the ServerIron ADX to be in more than one subnet. If the real server and the
ServerIron 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 56.
To enable source NAT on a real server, enter commands such as the following.
ServerIronADX(config)#server real-name berto
ServerIronADX(config-rs-berto)#source-nat
Syntax: [no] source-nat
Source NAT is disabled by default.
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
ServerIron ADXs. The address is active only on one ServerIron ADX (the ServerIron 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 source IP address for use by the real servers as their default gateway, use the server
source-standby-ip command address instead. The gateway parameter is required.
To configure a shared source IP address, enter the command such as the following.
ServerIronADX(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 default-gateway port-range 1 | 2
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. The peer using the
upper port range is the owner of the source IP address. After you enter this command, ownership of
the source IP address is negotiated between the peers. There must be a Layer 2 connection
between the two ServerIron ADXs.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
57
2
Source NAT
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
Configuring shared source NAT IP addresses
within a VIP group
Use the source-nat-ip command to configure shared source NAT IP addresses within a VIP group for
Symmetric Active-Standby HA. In a Symmetric Active-Standby HA configuration, the shared source
NAT IP addresses track the VRRP state to determine the active ServerIron ADX for a given source
NAT IP address.
To configure a shared source NAT IP address within a VIP group, enter commands such as the
following.
ServerIronADX(config)#server vip-group 1
ServerIronADX(config-vip-group-[1])#source-nat-ip 10.10.10.3
Syntax: source-nat-ip ip-addr
The ip-addr variable is the shared source NAT IP address.
Source NAT to packets from specified source IP addresses
By default, if you configure the ServerIron ADX to apply source NAT for a real server, it is applied to
all traffic for the real server. You can configure the ServerIron ADX to apply source NAT for a real
server to traffic from specified source IP addresses.
To do this, you create an ACL, then specify the ACL in the source NAT configuration of the real
server. When a flow is sent to the VIP, if the ACL specifies a permit action for the flow’s source IP
address, then source NAT is performed on traffic in the flow.
For example, the following commands create an ACL that permits traffic from network
192.168.0.0/16 and denies all other traffic.
ServerIronADX(config)#access-list 1 permit 192.168.0.0 0.0.255.255
ServerIronADX(config)#access-list 1 deny any
In comparison, the source-nat access-list acl-id command configures source NAT on a real server to
be performed on traffic whose source IP address is permitted by ACL 1.
ServerIronADX(config)#server real r1 10.10.10.10
ServerIronADX(config-rs-r1)#source-nat access-list 1
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 ServerIron 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).
58
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Source NAT
2
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 ServerIron 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.
ServerIronADX(config)#server source-nat 192.168.2.10 10.10.6.1
Syntax: server source-nat client-subnet source-ip
Enter the IP address to which the client belongs for client-subnet.
Enter the source NAT IP address of the subnet with which you want to associate the client’s subnet.
The source NAT IP address you enter must be configured on the ServerIron.
Minimizing source-IP and source-NAT-IP requirements
for large deployments
In previous implementations for earlier ServerIron ADX products, when source-ip or source-nat-ip is
defined, the total number of 64K ports (of which some are reserved for internal use) per IP address
are allocated and shared across all real servers. Each real server will only use portion of the entire
port pool. As a result, the number of connections that the system can handle is limited by the
number of source-ip or source-nat-ip defined on the system multiplied by the maximum port pool
per IP.
As global port pool is shared by all real servers, the supply of ports can be quickly exhausted.
Defining of additional source-ip or source-nat-ip may not always be feasible. The release 10.2.01
enhances this functionality and effectively conserves IP addresses.
In this implementation, 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.
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 IPs and source NAT IPs.
NOTE
This enhancement only applies to the server source-ip and server source-nat-ip. It is not applicable
to source-ip and source-nat-ip addresses used for SSL.
NOTE
You need to write memory and reload after you configure this feature.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
59
2
Source NAT
NOTE
If source-ip and source-nat-ip are configured for the same subnet, then the source-nat-ip is given a
higher priority. In the router case, the interface IPs are programmed as source-ips on the BP. The IP
that matches the default gateway is given preference in the router case. As a result, if you configure
the source-nat-ip in a subnet different than the gateway remote servers that are defined on the
ServerIron ADX, then this source-nat-ip must not be used. You should take this into account during
network design.
For example, if you want to keep using the same IP 10.4.4.101 as source-ip, but change old source-ip
feature to new source-ip port-alloc-per-real. You need to perform the following steps in order:
1. Bring traffic that hit 10.4.4.101 to zero.
2. No server source-ip 10.4.4.101 255.255.255.0.0.0.0.0
3. Server source-ip 10.4.4.101 255.255.255.0.0.0.0.0 per-alloc-per-real
To enable this feature, use the port-alloc-per-real keyword along with server source-ip or server
source-nat-ip commands.
• “Enabling port allocation per real server for source IP”
• “Enabling port allocation per real server for source NAT IP”
Enabling port allocation per real server for source IP
To enable port allocation per real server for the source IP address, use the following command:
ServerIronADX(config)#server source-ip 10.157.22.28 255.255.255.0 10.157.22.1
port-alloc-per-real
Syntax: [no] server source-ip ip-addr ip-mask default-gateway [ port-alloc-per-real ]
NOTE
Port allocation per real server cannot be configured if keepalive health checks are enabled for the
virtual server port.
Enabling port allocation per real server for source NAT IP
To enable port allocation per real server for the source NAT IP address, use the following command.
ServerIronADX(config)#server source-nat-ip 10.10.10.5 255.255.255.0 0.0.0.0
port-range 2 portalloc-per-real
Syntax: [no] server source-nat-ip ip-addr ip-mask default-gateway port-range 1|2
[port-alloc-per-real]
NOTE
The ServerIron ADX does not use the source-nat-ip default-gateway variable for remote server health
checks as well as for forwarding SLB traffic to the remote server.
60
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Source NAT
2
NOTE
You should not enable or disable this functionality while the IP addresses are in use by the traffic
flow. You must bring the traffic level to zero using this IP address or remove the command and
redefine it.
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 the no server command and then re-define it.
statement #1: server ... port-range 1
statement #2: server ... port-range 1 port-alloc-per-real
NOTE
The maximum number of configured source-nat-ip addresses that can be supported by the “port
allocation per real server” feature is 16.
Logging port exhaustion message
You can configure the ServerIron to log a message when a source IP or source NAT IP runs out of
ports.
Syntax: [no] source-ip-log
IPv6 Source NAT ACL Support
The ServerIron ADX release 12.4.00e introduces the IPv6 Source-NAT (SNAT) ACL support. This
feature allow users to configure a source NAT access list for a real server by specifying the
acl_name variable of the IPv6 ACL.
By default, if you configure the ServerIron ADX to apply source NAT for a real server, it is applied to
all traffic for the real server. You can configure the ServerIron ADX to apply the source NAT for a real
server to traffic from specified source IP addresses.
To do this, you need to create an access-list (ACL), then specify the ACL in the source NAT
configuration of the real server. When a flow is sent to the VIP, if the ACL specifies a permit action
for the flow’s source IP address, the source NAT is performed on the traffic in the flow.
Starting with the ServerIron ADX release 12.4.00e, the source-NAT access-list feature is available
for IPv6 addresses in addition to IPv4 addresses.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
61
2
Source NAT
Configuring IPv6 Source NAT ACL
To configure the IPv6 Source NAT ACL feature, use the source-nat ipv6 access-list command to add
support to the real servers in the traffic mode as shown below:
ServerIronADX(config)#server real-name rs10
ServerIronADX(config-rs-rs10)#source-nat ipv6 access-list acl_10
Syntax: [no] source-nat ipv6 access-list acl_name
The acl_name variable is the name of the IPv6 access-list.
Example
The following example is the configuration of the IPv6 source NAT ACL feature on the ServerIron
ADX for real server rsv6 with the IPv6 ACL myacl.
ServerIronADX(config)#ipv6 access-list myacl
ServerIronADX(config-ipv6-access-list myacl)# permit ipv6 3000::/64 any
ServerIronADX(config-ipv6-access-list myacl)# exit
ServerIronADX(config)# server real rsv6
ServerIronADX(config-rs-rsv6)# source-nat ipv6 access-list
ASCII string
Access List Name for IPv6
ServerIronADX(config-rs-rsv6)# source-nat ipv6 access-list myacl
ServerIronADX(config-rs-rsv6)# end
NOTE
The CLI will prevent users from configuring IPv6 SNAT access list for IPv4 real servers and IPv4 SNAT
access list for IPv6 real servers.
Increasing the maximum of source-NAT IP addresses
By default, the ServerIron ADX supports a system maximum of 64 addresses. You can increase the
number of address to a system maximum of 128. With an increase to 128 address, the ServerIron
ADX could have an impact in performance. With source-NAT caching per real server, performance
would not be impacted.
Configuring maximum source-NAT IP addresses
By default, the ServerIron ADX support 64 source-nat-ip addresses. You can configure separately a
maximum of 128 source-NAT IP addresses for IPv4 and IPv6. The total number of allowed
source-NAT IPs is the sum of the maximum IPv4 and maximum IPv6 source-NAT IPs configured.
NOTE
You must reboot the ServerIron ADX for the change to take effect.
To increase the maximum number of IPv4 addresses, use the system-max source-ip command.
ServerIronADX(config)# system-max source-ip 100
ServerIronADX(config)# write memory
ServerIronADX(config)# exit
ServerIronADX# reload
62
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Source NAT
2
To increase the maximum number of IPv6 addresses, use the system-max source-ip6 command.
ServerIronADX(config)# system-max source-ip6 100
ServerIronADX(config)# write memory
ServerIronADX(config)# exit
ServerIronADX# reload
Syntax: [no] system-max source-ip max_addresses
Syntax: [no] system-max source-ip6 max_addresses
The max_addresses variable specifies maximum source-NAT IP addresses. Enter a number from 0
to 128. The default maximum value is 64.
NOTE
When you increase the maximum number of source-NAT IP addresses to 128, the ServerIron ADX
looks up to 128 source-NAT IP addresses for every new connection and impacts the ServerIron ADX
performance. To resolve this impact, enable the source-NAT caching feature. For more information,
refer to “Enabling source-NAT caching.”
Use the no form of this command to reset the default value.
Displaying maximum source-NAT IP addresses
To display the maximum source-NAT IPv4 and IPv6 addresses, use the show default values
command.
ServerIronADX(config)# show default values
System Parameters
Default
Maximum
Current
source-ip
64
128
64
source-ip6
64
128
64
Syntax: show default values
Enabling source-NAT caching
By default, source-NAT caching is disabled. The ServerIron ADX performs lookups to the configured
system maximum of source-NAT IP addresses for every new connection to a real server. If you
increase the system maximum number of source-NAT IP addresses to 128, the ServerIron ADX
performance is impacted while looking up to 128 source-NAT addresses for every new connection.
To avoid source-nat IP lookups for the same server every time, enable source-NAT caching. When
caching is enabled, the ServerIron ADX caches the address for the real server and use the address
for subsequent sessions to same server. For every new connection made to the same real server,
the ServerIron ADX uses the same source NAT IP address until it exhausts all the free ports.
To enable the source-NAT caching for all real servers globally, use the server source-nat cache
enable command.
ServerIronADX(config)# server source-nat cache enable
To disable the SNAT caching for all the servers globally and reset the default behavior, use the
server source-nat cache disable command.
ServerIronADX(config)# server source-nat cache disable
Syntax: server source-nat cache enable | disable
ServerIron ADX Server Load Balancing Guide
53-1003452-01
63
2
Remote server
Disabling two-level CAM distribution on IPv6-optimized source-NAT entries
By default, IPv6 source-NAT entries use external Content Access Memory (CAM) lookups based on
port distribution. When IPv6 optimization is enabled on the ServerIron ADX, the IPv6 source-NAT
entries use internal CAM lookups based on two-level CAM distribution.
To disable two-level CAM distribution on IPv6 source-NAT entries when IPv6 optimization is
enabled, and use port-based CAM distribution, use the server source-nat optimized-mode-disable
command.
ServerIronADX(config #server source-nat optimized-mode-disable
Syntax: server source-nat optimized-mode-disable
NOTE
The ServerIron ADX has better performance if IPV6 optimization mode is enabled with two-level CAM
distribution.
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 ServerIron ADX does not include the server in the predictor
(load-balancing method). Instead, the ServerIron 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 name variable is the name of the remote server. Enter an alphanumeric string of up to 42
characters.
This command is used in conjunction with the server load balancing feature on the ServerIron ADX
switch.
Refer to “Unbinding all application ports from virtual servers” on page 158.
Sticky and concurrent connections
Configuring sticky ports
By default, the ServerIron 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 ServerIron 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 73.
64
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Sticky and concurrent connections
2
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”, the ServerIron ADX creates the sticky session for port
default (65535). Any new connection will follow the sticky session for port default. If sticky is
configured for a specific port as well as port default, sticky for the specific port will follow the sticky
session for the specific port regardless of the sticky session for port default.
For a configuration example and more information, refer to “TCP/UDP application groups” on
page 531.
To configure a TCP or UDP port as sticky, use the port sticky command when you add that port to a
virtual server:
ServerIronADX(config)#server virtual-name-or-ip v1 10.157.22.1
ServerIronADX(config-vs-v1)#port 80 sticky
In this example, the commands configure HTTP (port 80) as sticky.
Syntax: [no] port tcp/udp-port sticky
Configuring stickiness based on client’s subnet
The sticky function causes the ServerIron 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 ServerIron 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.
ServerIronADX(config)#server virtual-name-or-ip vs1 10.10.10.10
ServerIronADX(config-vs-vs1)#port http
ServerIronADX(config-vs-vs1)#port http client-subnet-sticky prefix-length 24
Syntax: [no] port portnum client-subnet-sticky { prefix-length prefix-length} |{ 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 port sticky and port client-subnet-sticky commands cannot be configured together on the
same port on the same virtual server.
The SSL port is configured as sticky by default, and the CLI will not allow you to configure port
client-subnet-sticky on an SSL port of a virtual server. As a work around, you must first disable the
sticky function before configuring port ssl client-subnet-sticky on a virtual server.
ServerIronADX(config)#server virtual-name-or-ip vs1 10.10.10.10
ServerIronADX(config-vs-vs1)#port ssl
ServerIronADX(config-vs-vs1)#no port ssl sticky
ServerIronADX(config-vs-vs1)#port ssl client-subnet-sticky prefix-length 24
ServerIron ADX Server Load Balancing Guide
53-1003452-01
65
2
Sticky and concurrent connections
Setting the sticky age
You can age out inactive sticky server connections. A connection is sticky if you configure the
ServerIron 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.
ServerIronADX(config)#server sticky-age 20
To set the sticky age for an individual virtual server, enter commands such as the following.
ServerIronADX(config)#server virtual-name-or-ip v1
ServerIronADX(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.
Preserving a sticky session when the health check is down
By default, the ServerIron ADX removes a sticky session in a session table when the health check is
down. The ServerIron ADX ages out the session within the configured time of the sticky multiplier
after a health check is down. When a health check goes down on the standby ServerIron ADX only,
the standby ServerIron ADX ages out the session within one minute while the active ServerIron ADX
keeps the session. When a HA failover occurs, the new active ServerIron ADX may not have the
sticky session and may forward the packet to a different real server after the health check is up
again.
You can configure the ServerIron ADX to preserve a sticky session in a session table when the
health check is down. This is useful when you have High Availability (HA) configurations and you
want to maintain the session with another available real server.
To preserve a sticky session when the health check is down, use the server allow-sticky
health-check-down command.
ServerIronADX(config)# server allow-sticky health-check-down
Syntax: [no] server allow-sticky health-check-down
This command takes effect immediately. After the command is executed, when the ServerIron ADX
receives a packet that matches the sticky session, the ServerIron ADX updates the sticky session to
the next available real server due to the health check being down.
66
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Sticky and concurrent connections
2
Allowing sticky ports
You can configure the ServerIron 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 ServerIron ADX temporarily places the port
in the aw_unbnd (awaiting unbind) state. If you delete an application port, the ServerIron 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 ServerIron ADX receives a new request associated with a sticky port in the
aw_unbnd state, the ServerIron ADX establishes the session on another real server, not the real
server from which you are unbinding the port.
You can configure the ServerIron 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.
ServerIronADX(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 ServerIron 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 the refresh-age option, the ServerIron 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 ServerIron ADX
establishes a new session on the sticky port, the ServerIron ADX resets the age time for the session
to five minutes. Each time the ServerIron ADX receives another connection request associated with
the sticky session, the ServerIron 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 66. 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.
ServerIronADX(config)#server virtual-name-or-ip vs1 10.10.10.10
ServerIronADX(config-vs-vs1)#sticky-age-multiplier 5
Syntax: sticky-age-multiplier multiplier-value
ServerIron ADX Server Load Balancing Guide
53-1003452-01
67
2
Sticky and concurrent connections
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 ServerIron as described in “Setting the sticky age” on page 66.
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.
Please 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 ServerIron ADX when load balancing client requests for an application. A backup server is used
by the ServerIron 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 ServerIron 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.
ServerIronADX(config)#server virtual-name-or-ip v1 192.168.9.210
ServerIronADX(config-vs-v1)#port dns lb-pri-servers
ServerIronADX(config-vs-v1)#port dns sticky
ServerIronADX(config-vs-v1)#port dns active-primary-overide-sticky
Syntax: port port active-primary-overide-sticky
When the active-primary-overide-sticky keyword 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.
68
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Sticky and concurrent connections
2
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.
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 9
Group sticky sample topology
Figure 9 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.
When a client first enters the system, the ServerIron 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 ServerIron ADX will find all the servers
belonging to the group and will load balance among the servers.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
69
2
Sticky and concurrent connections
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
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.
ServerIronADX(config-vs-v1)#server virtual-name-or-ip vip1 10.40.1.10
ServerIronADX(config-vs-vip1)#predictor round-robin
ServerIronADX(config-vs-vip1)#port http sticky !(or port http
client-subnet-sticky)
ServerIronADX(config-vs-vip1)#port http group-sticky
ServerIronADX(config-vs-vip1)#bind http rs1 http rs2 http Web1 http Web2 http
ServerIronADX(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.
70
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Sticky and concurrent connections
2
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.
ServerIronADX#rconsole 1 1
ServerIronADX 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.
ServerIronADX(config)#server virtual-name-or-ip vip1 10.40.1.10
ServerIronADX(config-vs-vip1)#predictor round-robin
ServerIronADX(config-vs-vip1)#port http sticky
ServerIronADX(config-vs-vip1)#port http group-sticky
ServerIronADX(config-vs-vip1)#port http group-sticky-failover
ServerIronADX(config-vs-vip1)#bind http rs1 http rs2 http rs3 http rs4 http
ServerIronADX(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
The server sticky-age command can also be applied to a sticky group.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
71
2
Sticky and concurrent connections
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 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.
ServerIronADX(config)#server virtual-name-or-ip v1 10.157.22.1
ServerIronADX(config-vs-v1)#port 80 concurrent
Syntax: [no] port tcp/udp-port concurrent
Configuring virtual source
In a typical configuration, a client’s IP address remains the same throughout the client’s session
with a virtual server. However, in some configurations where a proxy is used for the clients before
the client traffic reaches the ServerIron ADX, the client’s IP address can be different for each
request. To configure session persistence in a proxy environment, configure a standard IP ACL
containing the addresses, then use the Virtual Source feature.
When you configure the Virtual Source feature, the ServerIron ADX sends all client traffic from a
specified range of IP addresses to the same real server for the application ports you specify. To
specify the IP addresses, configure a standard IP ACL. Use this command in configurations where a
proxy device allocates IP addresses to client traffic before sending the traffic to the VIP. In some
configurations, the proxy device assigns different IP addresses to traffic from the same client.
Unless you configure the addresses to go to the same real server, the ServerIron ADX might load
balance the client traffic to different servers. This makes applications that require continued
access to the same real server unusable.
To configure the Virtual Source feature, enter commands such as the following.
ServerIronADX(config)#access-list 1 permit 10.157.22.0
ServerIronADX(config)#server virtual-name-or-ip fromproxy 10.1.1.1
ServerIronADX(config-vs-fromproxy)#port 80 sticky-acl 1
Syntax: [no] access-list num deny | permit source-ip | hostname wildcard [log]
or
Syntax: [no] access-list num deny | permit source-ip/mask-bits | hostname [log]
Syntax: [no] port tcp/udp-port sticky-acl num
72
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Application port grouping
2
NOTE
This feature is different from the sticky feature, which you can associate with ports on the virtual
server level. The sticky attribute ensures that subsequent packets from the same client during the
same TCP session go to the same real server. In this case, the ServerIron ADX knows the packets
are from the same client based on the source IP address. When a proxy is used, subsequent packets
from the same client can have different IP addresses.
For standard IP ACL configuration information, refer to the “Configuring Standard ACLs” section in
the “Access Control Lists” chapter of the ServerIron ADX Security Guide.
Application port grouping
The track port and track port group methods of TCP/UDP application grouping are similar. In both
configurations, the ServerIron 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, ServerIron ADX tracking does not
apply.
• In a track port group configuration, the ServerIron 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.
Tracking primary ports
You can configure the ServerIron 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
ServerIron 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” on page 531.
Note that if any service port is down for a real server, any track ports on that real server are not
considered for load balancing.
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 ServerIron ADX does not make the connection sticky. Only after the client requests the
primary port does the ServerIron 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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
73
2
Application port grouping
To configure a TCP or UDP application group, enter the following commands.
ServerIronADX(config)#server virtual-name-or-ip v1 10.157.22.1
ServerIronADX(config-vs-v1)#port 80 sticky
ServerIronADX(config-vs-v1)#port 23 sticky
ServerIronADX(config-vs-v1)#port 69 sticky
ServerIronADX(config-vs-v1)#track 80 23 69
ServerIronADX(config-vs-v1)#bind 80 r1 80 r2 80
ServerIronADX(config-vs-v1)#bind 23 r1 23 r2 23
ServerIronADX(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 ServerIron 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” on page 531.
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.
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:
ServerIronADX(config)#server virtual-name-or-ip v1 10.157.22.1
ServerIronADX(config-vs-v1)#port 80 sticky
ServerIronADX(config-vs-v1)#port 69 sticky
ServerIronADX(config-vs-v1)#port 23 sticky
ServerIronADX(config-vs-v1)#track-group 80 69 23
ServerIronADX(config-vs-v1)#bind 80 r1 80 r2 80
ServerIronADX(config-vs-v1)#bind 23 r1 23 r2 23
ServerIronADX(config-vs-v1)#bind 69 r1 69 r2 69
ServerIronADX(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
ServerIron ADX ensures that all ports in the group are active before granting the connection.
74
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Application port grouping
2
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 ServerIron 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
ServerIron 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
ServerIron 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.
ServerIronADX(config)#server real r1 10.1.1.1
ServerIronADX(config-real-server-r1) port 80
ServerIronADX(config-real-server-r1) port ftp
ServerIronADX(config-real-server-r1) port dns
ServerIronADX(config-rsr1) hc-track-group 80 21 53
In this example, the ServerIron ADX now tracks health status for ports 80, 21, and 53. If any of
these ports is down. the combined health would be marked as failed and the ServerIron 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.
ServerIronADX#show hc-track-group-state
Real Server
track-group
state
rs1
80 21 53
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 .
ServerIronADX#show hc-track-group-state detail
Status of health check track groups
Real Server: rs1
Track-group: 80 8080 8081 8082
State
: DOWN
ServerIron ADX Server Load Balancing Guide
53-1003452-01
75
2
Primary and backup servers
Real Server: rs2
Track-group: 80 8080 8081 8082
State
: ACTIVE
Enabling track ports in a track port group to unbind
By default, when you unbind a port that is the lead port in a track port group, all the ports that track
the lead port also are immediately unbound. This occurs even if a port is still active and has not
completed the AW_unbind (awaiting unbind) state.
To configure the ServerIron 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:
ServerIronADX(config)#server track-group-unbind-wait-all
Syntax: [no] server track-group-unbind-wait-all
NOTE
If a port is the master port of a track group, the port (master port itself) cannot unbound immediately
if there is any outstanding sessions for any ports in that track group.
Primary and backup servers
The ServerIron 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 ServerIron 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 ServerIron 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.
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 ServerIron ADX does not diffentiate 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.
76
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Primary and backup servers
2
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 ServerIron 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
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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
77
2
Primary and backup servers
Designating a real server as a backup
By default, the virtual server uses the locally attached real servers as the primary load-balancing
servers and uses the remotely attached servers as backups.
To designate a real server to be a backup server, enter the following command.
ServerIronADX(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.
ServerIronADX(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.
ServerIronADX(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. The backup-stay-active feature is triggered by health check and works independently on
each BP (i.e., the change in server selection logic of one BP is not reflected in the other BPs).
Effectively, if there are no new connections on a BP during the phase when the Primary Server fails
and recovers, new connections on that BP (after the Primary recovers) will still be forwarded to the
Primary Server. But, if another BP receives new connections while the Primary is failed (and before
it recovers), any new connections from that point on (for that BP) will always be forwarded to the
Backup Server. Consequently, from the end-user perspective (or from MP view), you may see traffic
going to both primary and backup servers (from different BPs).
Prior to the ServerIron ADX release 12.4.00c, selection of backup server was solely dependent on
the timing of incoming client connection and was not tightly coupled with the system-level health of
the primary and backup servers. In some rare events, this results in servicing of traffic by both
primary and backup servers which is undesirable. Starting with the ServerIron ADX release
78
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Primary and backup servers
2
12.4.00c, additional checks are added to ensure that 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 command to see which server is currently active as shown in the following
example.
ServerIronADX(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: [no] show server backup-associated-state [vip-name] [application-port]
Configuration example
The example configures load-balancing shown in Figure 10 on page 77.
To configure the real servers, enter commands such as the following.
ServerIronADX(config)#server real R1 10.10.10.10
ServerIronADX(config-rs-R1)#port http
ServerIronADX(config-rs-R1)#exit
ServerIronADX(config)#server real R2 10.10.10.20
ServerIronADX(config-rs-R2)#port http
ServerIronADX(config-rs-R2)#exit
ServerIronADX(config)#server real R3 10.10.10.30
ServerIronADX(config-rs-R3)#backup
ServerIronADX(config-rs-R3)#port http
ServerIronADX(config-rs-R3)#exit
ServerIronADX(config)#server remote-name R4 10.10.10.40
ServerIronADX(config-rs-R4)#port http
ServerIronADX(config-rs-R4)#exit
ServerIronADX(config)#server remote-name R5 10.10.10.50
ServerIronADX(config-rs-R5)#backup
ServerIronADX(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.
ServerIronADX(config-rs-R5)#server virtual-name-or-ip VIP1 10.10.10.100
ServerIronADX(config-vs-VIP1)#port http lb-pri-servers
ServerIronADX(config-vs-VIP1)#bind http R1 http R2 http R3 http R4 http R5 http
ServerIron ADX Server Load Balancing Guide
53-1003452-01
79
2
Primary and backup servers
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.
ServerIronADX(config)#server virtual-name-or-ip vs1 10.10.10.10
ServerIronADX(config-vs-vs1)#port http
ServerIronADX(config-vs-vs1)#bind http rs1 http rs2 http
ServerIronADX(config-vs-vs1)#port http lb-primary-servers
ServerIronADX(config-vs-vs1)#port ftp
ServerIronADX(config-vs-vs1)#bind ftp rs1 ftp rs2 ftp
ServerIronADX(config-vs-vs1)#port ftp lb-primary-servers
ServerIronADX(config-vs-vs1)#port dns
ServerIronADX(config-vs-vs1)#bind dns rs1 dns rs2 dns
ServerIronADX(config-vs-vs1)#port dns lb-primary-servers
ServerIronADX(config)#server real rs1 10.10.10.1
ServerIronADX(config-rs-rs1)#port http
ServerIronADX(config-rs-rs1)#port ftp
ServerIronADX(config-rs-rs1)#port dns backup
ServerIronADX(config-rs-rs1)#exit
ServerIronADX(config)#server real rs2 10.10.10.2
ServerIronADX(config-rs-rs2)#port http backup
ServerIronADX(config-rs-rs2)#port ftp backup
ServerIronADX(config-rs-rs2)#port dns
ServerIronADX(config-rs-rs2)#exit
Syntax: [no] port port-name backup
80
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Primary and backup servers
2
Per server based real server backup
Overview of 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, you can configure the backup-stay-active option 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 option 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 the backup-stay-alive option is not configured. When B comes up and A stays down
alive, the server is selected from C and B.
Condition 4: if the backup-stay-alive option is configured, when B comes up and A stays down, the
server is selected from C and D.
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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
81
2
Primary and backup servers
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 82
• “Server port backup association” on page 83
• “Display the backup bindings” on page 84
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
Example
To configure the real server R2 as the backup of the real server R1.
ServerIronADX(config)#server real-name R1 10.10.10.10
ServerIronADX(config-rs-R1)#port http
ServerIronADX(config-rs-R1)#exit
ServerIronADX(config)#server real-name R2 10.10.10.20
ServerIronADX(config-rs-R2)#backup R1
ServerIronADX(config-rs-R2)#port http
ServerIronADX(config-rs-R2)#exit
82
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Primary and backup servers
2
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.
ServerIronADX(config)#server real-name R1 10.10.10.10
ServerIronADX(config-rs-R1)#port http
ServerIronADX(config-rs-R1)#exit
ServerIronADX(config)#server real-name R2 10.10.10.20
ServerIronADX(config-rs-R2)#port http
ServerIronADX(config-rs-R2)#port http backup R1 http
ServerIronADX(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
ServerIronADX(config)#server real-name R1 10.10.10.10
ServerIronADX(config-rs-R1)#port http
ServerIronADX(config-rs-R1)#exit
ServerIronADX(config)#server real-name R2 10.10.10.20
ServerIronADX(config-rs-R2)#port http
ServerIronADX(config-rs-R2)#port http R1 http
ServerIronADX(config-rs-R2)#exit
ServerIronADX(config)#server real-name R3 10.10.10.30
ServerIronADX(config-rs-R2)#backup R2
ServerIronADX(config-rs-R2)#port http
ServerIronADX(config-rs-R2)#port http backup R1 http
ServerIronADX(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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
83
2
Configuring Direct Server Return
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
ServerIronADX(config)#server real-name R1 10.10.10.10
ServerIronADX(config-rs-R1)#port http
ServerIronADX(config-rs-R1)#exit
ServerIronADX(config)#server real-name R2 10.10.10.20
ServerIronADX(config-rs-R2)#backup R1
ServerIronADX(config-rs-R2)#port http
ServerIronADX(config-rs-R2)#port http backup R1 http
ServerIronADX(config-rs-R2)#exit
ServerIronADX(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 ServerIron ADX implementations both client-to-server and server-to-client traffic flow
through ServerIron ADX. In such configurations, the ServerIron 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 ServerIron ADX by allowing server responses (server-to-client traffic) to bypass the
ServerIron ADX.
Direct Server Return may be used in many different ServerIron ADX implementations. For example,
it can be used on a single ServerIron ADX supporting a single server farm or applied to multiple
ServerIron ADXs in high availability (HA) scenarios (Hot Standby HA, Symmetric Active-Standby HA,
and Symmetric Active-Active HA).
FIGURE 12
84
Two ServerIron ADXs in an DSR configuration
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Configuring Direct Server Return
2
ServerIron 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 ServerIron ADX and the real servers must be on the same
subnet.
• In an L3 DSR configuration, the ServerIron ADX and the real servers can be connected by a
router.
NOTE
The ServerIron ADX does not support Boolean health checks with DSR.
Configuring L2 Direct Server Return
A ServerIron 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 ServerIron 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 ServerIron ADX leaves the destination IP
address unchanged.
NOTE
In an L2 DSR configuration, you cannot router hop between the ServerIron ADXs. 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.
Enabling L2 DSR on TCP/UDP ports
To configure the ServerIron 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.
ServerIronADX(config)#server virtual-name-or-ip v1 10.157.22.1
ServerIronADX(config-vs-v1)#port 80 dsr
Traffic for other ports still returns through the ServerIron ADX. The ServerIron ADX does not
translate the destination IP address in client requests for the port with L2 DSR enabled. However,
the ServerIron 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
NOTE
For an IPv4 VIP, if there is already an IPv6 server bound, trying to configure the port to be dsr will not
be allowed by the ServerIron ADX CLI.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
85
2
Configuring Direct Server Return
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 ServerIron 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 457 for details.
Health checks with L2 DSR
Normally, the ServerIron ADX can perform health checks on an application port only when a server
replies from that port pass back through the ServerIron ADX. If the ServerIron ADX does not see the
real server’s responses to client requests, the ServerIron 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 ServerIron 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 ServerIron ADX addresses Layer 3 (IP ping) health checks to the real server IP address.
• The ServerIron 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”.
SYN-Defense with L2 DSR
SYN-Defense is a security feature that configures the ServerIron ADX to complete the TCP three-way
handshake on behalf of a connecting client.
ServerIron ADX releases that do not support Layer 3 do not support the SYN-Defense feature in
Direct Server Return configurations. The reason is that the ServerIron ADX does not see the
server’s SYN ACK, and as a result cannot complete the connection. The incomplete connection
resides on the server as a pending connection, a condition the SYN-Defense feature is meant to
eliminate.
TrafficWorks router software enables you to use the SYN-Defense feature in a Direct Server Return
configuration. To do so, configure the server to use the ServerIron ADX as its default gateway.
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.
86
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Configuring Direct Server Return
2
The DSR fast-delete option is enabled by default, starting with 12.4.00 software release. To disable
the option, enter commands as follows:
ServerIronADX(config)#server virtual-name-or-ip vs
ServerIronADX(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 because in DSR setup ServerIron 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 ServerIron ADX implementations including high
availability (HA) scenarios (Hot Standby HA, Symmetric Active-Standby HA, and Symmetric
Active-Active HA). Figure 13 shows an example of an L2 DSR configuration for a high availability
scenario.
FIGURE 13
ServerIron ADXs deployed in Direct Server Return configuration
To implement the configuration shown in Figure 13, configure ServerIron ADXs 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 ServerIron ADX A and on VIP1 on ServerIron 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 98.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
87
2
Configuring Direct Server Return
TABLE 4
DSR configuration example
ServerIron
ADX
Domain name
Virtual IP (VIP)
address
Priority
VIP’s TCP
port
Real IP
address
Real Server’s
TCP port
A
www.abc.com
VIP1:
10.157.22.100
254
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
2
80
2
80
254
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 ServerIron ADXs, and bind the VIPs on each
ServerIron ADX to all the real servers.
NOTE
Brocade recommends that you specify 2 (instead of 1) as a low priority or 254 (instead of 255) as a
high priority. This way, you can easily force failover of the high priority ServerIron ADX to the low
priority ServerIron ADX by changing the priority on just one of the ServerIron ADXs. For example, you
can force a failover by changing the priority on the high priority ServerIron ADX from 254 to 1. Since
the priority on the low priority ServerIron ADX is 2, the low priority ServerIron ADX takes over for the
VIP. Likewise, you can force the low priority ServerIron ADX to take over by changing its priority to
255, since the priority on the high priority ServerIron ADX is only 254.
Configuring ServerIron ADX A
Notice that all four real servers must be configured, and bound to the VIPs, on both ServerIron
ADXs. 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 98.
To configure the real servers, enter the following commands.
ServerIronADXA(config)#server real-name Real_Server_1 10.0.0.1
ServerIronADXA(config-rs-Real_Server_1)#port http
ServerIronADXA(config-rs-Real_Server_1)#port 80
ServerIronADXA(config-rs-Real_Server_1)#exit
ServerIronADXA(config)#server real-name Real_Server_2 10.0.0.2
ServerIronADXA(config-rs-Real_Server_2)#port http
88
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Configuring Direct Server Return
2
ServerIronADXA(config-rs-Real_Server_2)#port 80
ServerIronADXA(config-rs-Real_Server_2)#exit
ServerIronADXA(config)#server real-name Real_Server_3 10.0.1.1
ServerIronADXA(config-rs-Real_Server_3)#port http
ServerIronADXA(config-rs-Real_Server_3)#port 180
ServerIronADXA(config-rs-Real_Server_3)#exit
ServerIronADXA(config)#server real-name Real_Server_4 10.0.1.2
ServerIronADXA(config-rs-Real_Server_4)#port http
ServerIronADXA(config-rs-Real_Server_4)#port 180
ServerIronADXA(config-rs-Real_Server_4)#exit
To configure the VIPs, enter the following commands.
ServerIronADXA(config)#server virtual-name-or-ip VIP1 10.157.22.100
ServerIronADXA(config-vs-VIP1)#port http dsr
ServerIronADXA(config-vs-VIP1)#bind http Real_Server_1 http Real_Server_2 http
Real_Server_3 http Real_Server_4 http
ServerIronADXA(config-vs-VIP1)#sym-priority 254
ServerIronADXA(config-vs-VIP1)#exit
ServerIronADXA(config)#server virtual-name-or-ip VIP2 10.157.22.101
ServerIronADXA(config-vs-VIP2)#port http dsr
ServerIronADXA(config-vs-VIP2)#bind http Real_Server_1 80 Real_Server_2 80
Real_Server_3 180 Real_Server_4 180
ServerIronADXA(config-vs-VIP2)#no http port translate
ServerIronADXA(config-vs-VIP2)#sym-priority 2
ServerIronADXA(config-vs-VIP2)#exit
ServerIronADXA(config)#write memory
Configuring ServerIron ADX B
To configure the real servers, enter the following commands.
ServerIronADXB(config)#server real-name Real_Server_1
ServerIronADXB(config-rs-Real_Server_1)#port http
ServerIronADXB(config-rs-Real_Server_1)#port 180
ServerIronADXB(config-rs-Real_Server_1)#exit
ServerIronADXB(config)#server real-name Real_Server_2
ServerIronADXB(config-rs-Real_Server_2)#port http
ServerIronADXB(config-rs-Real_Server_2)#port 180
ServerIronADXB(config-rs-Real_Server_2)#exit
ServerIronADXB(config)#server real-name Real_Server_3
ServerIronADXB(config-rs-Real_Server_3)#port http
ServerIronADXB(config-rs-Real_Server_3)#port 80
ServerIronADXB(config-rs-Real_Server_3)#exit
ServerIronADXB(config)#server real-name Real_Server_4
ServerIronADXB(config-rs-Real_Server_4)#port http
ServerIronADXB(config-rs-Real_Server_4)#port 80
ServerIronADXB(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.
ServerIronADXB(config)#server virtual-name-or-ip VIP1 10.157.22.100
ServerIronADXB(config-vs-VIP1)#port http dsr
ServerIronADXB(config-vs-VIP1)#bind http Real_Server_1 180 Real_Server_2 180
Real_Server_3 80 Real_Server_4 80
ServerIronADXB(config-vs-VIP1)#no http port translate
ServerIronADXB(config-vs-VIP1)#sym-priority 2
ServerIronADXB(config-vs-VIP1)#exit
ServerIronADXB(config)#server virtual-name-or-ip VIP2 10.157.22.101
ServerIronADXB(config-vs-VIP2)#port http dsr
ServerIronADXB(config-vs-VIP2)#bind http Real_Server_1 http Real_Server_2 http
ServerIron ADX Server Load Balancing Guide
53-1003452-01
89
2
Configuring Direct Server Return
Real_Server_3 http Real_Server_4 http
ServerIronADXB(config-vs-VIP2)#sym-priority 254
ServerIronADXB(config-vs-VIP2)#exit
ServerIronADXB(config)#write memory
Configuring L3 Direct Server Return
In an L3 DSR configuration, the ServerIron 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 ServerIron 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 ServerIron ADX for L3 DSR, the ServerIron 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.
ServerIronADX(config)#server virtual-name-or-ip vip1 10.10.1.151
ServerIronADX(config-vs-vip1)#tos-marking 18
ServerIronADX(config-vs-vip1)#bind http rs1 http
The ServerIron 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 ServerIron ADX will process the health check reply packets
correctly:
ServerIronADX(config)#server virtual-name-or-ip vip1 10.10.1.151
ServerIronADX(config-vs-vip1)#tos-marking 18 hc-l3-dsr
ServerIronADX(config-vs-vip1)#bind http rs1 http
Although the ServerIron 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 ServerIron ADX.
90
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Configuring Direct Server Return
2
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 TCP and UDP real server ports 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 ServerIron 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 ServerIron 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 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 86.
NOTE
For ICMP health checks, the ServerIron ADX does not mark the DSCP field.
L3 DSR configuration example
To enable Layer 3 DSR, you must configure a ServerIron 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 ServerIron 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
ServerIron ADX.
ServerIronADX(config)#server remote-server rs1 10.20.1.31
ServerIronADX(config-rs-rs1)#port http
ServerIronADX(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.
ServerIronADX(config)#server virtual-name-or-ip vip1 10.1.1.151
ServerIronADX(config-vs-vip1)#tos-marking 20 hc-l3-dsr
In this example, ServerIron 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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
91
2
Displaying server information
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 ServerIron ADX configuration” on
page 505.
• show server bind - Refer to “Displaying port-binding information” on page 519.
• show server sessions - Refer to “Displaying port-binding information” on page 519.
• show server traffic - Refer to “Displaying packet traffic statistics” on page 522.
The show server global command gives the output of the show server backup or the show server
symmetric command, depending on which high availability method is in use, plus some additional
configuration information that would have to be shared between a pair of ServerIron ADXs in a high
availability environment.
The following is a sample for a ServerIron using Symmetric Active-Active HA.
ServerIronADX#show server
Server Symmetric port = 2/7
Group_id = 1 Candidate cnt = 1
Port No-rx
2/7 0
Server Load Balancing - global parameters
Predictor
=
round-robin
Force-deletion
=
0
Reassign-threshold = 20
Reassign-limit =
3
TCP-age =
30
UDP-age =
5
Sticky-age =
5
TCP-syn-limit =
65535
msl =
8
TCP-total conn =
0
Unsuccessful conn = 0
NO-RESET-on-max-conn = Disabled
Ping-interval =
2
Ping-retries =
4
Session ID age =
30
92
ServerIron ADX Server Load Balancing Guide
53-1003452-01
2
Displaying server information
Bind info
Virtual server: v
Status: enabled IP:
192.168.199.99
telnet -------> a: 192.168.99.11, telnet (remote) (Active)
b: 192.168.99.12, telnet (remote) (Failed)
http -------> a: 192.168.99.11, http (remote) (Active)
b: 192.168.99.12, http (remote) (Failed)
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
=
4
fast vport n found
=
Fwd to non-static FI
=
0 Dup stale SYN
=
0
0
0
0
0
0
0
0
0
0
11
0
ServerIronADX#show server
Server Symmetric port = 2/7
Group_id = 1 Candidate cnt = 1
Port No-rx
2/7 0
Server Load Balancing - global parameters
Predictor
=
round-robin
Force-deletion
=
0
Reassign-threshold = 20
Reassign-limit =
3
TCP-age =
30
UDP-age =
5
Sticky-age =
5
TCP-syn-limit =
65535
msl =
8
TCP-total conn =
0
Unsuccessful conn = 0
NO-RESET-on-max-conn = Disabled
Ping-interval =
2
Ping-retries =
4
Session ID age =
30
Bind info
Virtual server: v
Status: enabled IP:
192.168.199.99
telnet -------> a: 192.168.99.11, telnet (remote) (Active)
b: 192.168.99.12, telnet (remote) (Failed)
http -------> a: 192.168.99.11, http (remote) (Active)
b: 192.168.99.12, http (remote) (Failed)
ServerIron ADX Server Load Balancing Guide
53-1003452-01
93
2
Port ranges
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
=
4
fast vport n found
=
Fwd to non-static FI
=
0 Dup stale SYN
=
TCP forward FIN
=
0
TCP reverse FIN
=
Fast path FWD FIN
=
0
Fast path REV FIN
=
Fast path SLB SYN
=
0
Dup SYN after FIN
=
Duplicate SYN
=
0
Duplicate sessions
=
TCP ttl FIN recvd
=
0
TCP ttl reset recvd
=
Sessions in DEL_Q
=
0
Sess force deleted
=
Fwd sess not found
=
0
sess already in delQ
=
Sess rmvd from delQ
=
0
New sess sync sent
=
0
New sess sync recvd
=
TCP SYN received
=
0
TCP SYN dropped
=
TCP SYN to MP
=
0
TCP SYN ACK to MP
=
TCP SYN ACK received
=
0
TCP SYN ACK dropped
=
TCP pkt received
=
0
TCP pkt dropped
=
TCP pkt to MP
=
0
PBSLB tftp status
=
Avail. Sessions on MP =
999993
Total Sessions on MP
=
slot-1 cpu-1 Avail. Session =
1999992 Total Sessions =
2000000
slot-1 cpu-2 Avail. Session =
1999992 Total Sessions =
2000000
slot-1 cpu-3 Avail. Session =
1999992 Total Sessions =
2000000
Total C->S Conn
=
0 Total S->C Conn
=
0
Total Reassign
=
0 Unsuccessful Conn
=
0
Server State - 0: disabled, 1:enabled, 2:failed, 3:test, 4:suspect,
5:grace_dn, 6:active
Real Server
State
CurrConn
TotConn TotRevConn
CurrSess
PeakConn
a
6
0
0
0
0
0
b
1
0
0
0
0
0
last conn rate
=
0 max conn rate
=
last TCP attack rate =
0 max TCP attack rate
=
SYN def RST
=
0 SYN flood
=
0
0
0
0
0
0
0
0
0
0
11
0
0
0
0
0
0
0
0
0
0
0
0
0
Not in pro
1000000
0
0
0
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 ServerIron ADX processes client requests destined to ports inside a port range in the same way
it processes connections to individual ports.
94
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Port ranges
2
Defining a port range
Port ranges are identified by their names. A port range can be created as follows.
1. Define the port range
ServerIronADX(config)#port-range pr1
Syntax: [no] port-range port-range-name
2. Identify the ports in the range.
ServerIronADX(config-pr-pr1)#port 8051 to 8100
Syntax: [no] port port-number to port-number
Enter the port’s numerical value for the port-number variable.
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 the system encounters an error while implementing port-range and its associated features, it
will still go ahead and complete the process. It will then log an error message. The system user
must manually remove the port-range config, correct the error, and re-apply the configuration
until it succeeds.
• 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.
• Port ranges can be combined with Layer 4 switching only. They cannot be used with Layer 7
switching.
• Port ranges cannot be used with IPv6 services.
• Some of the other features not supported with port range are: PBSLB, TCS, boolean health
check, scripted health check, track-groups, track-ports, tcp offload, and keepalive.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
95
2
Port ranges
Using a port range under a real server definition
You can define port ranges under a real server definition.
ServerIronADX(config)#server real real1 10.0.0.1
ServerIronADX(config-rs-real1)#port-range pr1
Syntax: [no] port-range port-range-name
Enter the ID of the port range for the port-range-name variable. Refer to the rules in “Defining a
port range” on page 95 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.
ServerIronADX(config)#server real rs1 10.0.0.1
ServerIronADX(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.
ServerIronADX(config)#server virtual-name-or-ip virtual1 10.0.0.1
ServerIronADX(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.
ServerIronADX(config)#port-range pr1
ServerIronADX(config-pr-pr1)#port 8051 to 8100
ServerIronADX(config-pr-pr1)#exit
ServerIronADX(config)#port-range pr2
ServerIronADX(config-pr-pr2)#port 7051 to 7100
ServerIronADX(config-pr-pr2)#exit
ServerIronADX(config)#server virtual-name-or-ip virtual1 10.0.0.1
ServerIronADX(config-vs-virtual1)#bind-range pr1 realserver1 pr1 realserver2 pr2
Syntax: [no] bind-range port-range-name real-server-name port-range-name
96
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Port ranges
2
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.
ServerIronADX(config)#server port-profile port-range pr1
ServerIronADX(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 ServerIron ADX by issuing the
following command.
ServerIronADX(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 ServerIron 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.
ServerIronADX#show port-range
Name
Start
pr2
8090
pr3
8140
pr98
9800
range4
7001
ServerIron ADX Server Load Balancing Guide
53-1003452-01
End
8139
8149
9803
7050
Pending Start
Pending End RefCnt
500
100
4
97
2
Multiple port binding
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.
ServerIronADX(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.
ServerIronADX(config)#show port-range starts-with pr
Syntax: show port-range starts-with prefix
ServerIronADX#show port-range starts
Name
Start
pr2
8090
pr3
8140
pr98
9800
with pr
End
Pending Start
8139
8149
9803
Pending End RefCnt
500
100
4
Table 5 describes the information in the output.
TABLE 5
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.
ServerIron 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 ServerIron 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.
98
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Multiple port binding
2
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.
ServerIronADX(config)#server real rs1 10.0.0.1
ServerIronADX(config-rs-rs1)#port http
2. Create a virtual server.
ServerIronADX(config)#server virtual vs1 10.0.0.101
3. Create an HTTP port on the virtual server.
ServerIronADX(config-vs-vs1)#port http
4. Bind the real port on the real server to the HTTP port on the virtual server.
ServerIronADX(config-vs-vs1)#bind http rs1 http
5. Repeat the steps 2 through 4 for each additional virtual server.
ServerIronADX(config)#server virtual vs2 10.0.0.102
ServerIronADX(config-vs-vs2)#port http
ServerIronADX(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 ServerIron 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 209.
• The virtual port is configured for persistent hashing. For more information, see “Enabling
persistent hashing” on page 115.
When a real port is bound to multiple virtual ports, the following configurations are not allowed:
•
•
•
•
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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
99
2
Multiple port binding
NOTE
The default port (a port the ServerIron 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. 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. By
default, you can create up to 32,000 multiple port bindings. A maximum of 300,000 multiple port
bindings can be configured. 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.
ServerIronADX1000#show server
Server resource usage:
Current
l4-real-server
2
l4-virtual-server
2
l4-server-port
8
l4-multi-binding
1
resource
Maximum
1024
256
2048
32000
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.
ServerIronADX1000#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)
IP: 10.1.2.100
IP: 10.1.2.101
NOTE
When you remove the primary binding in a multiple port binding configuration, the secondary
binding continues to be displayed with the + sign but it does not effect any functionality. To remove
the + sign from the secondary binding, remove and re-add the secondary binding. When you reboot
the ServerIron ADX, the + sign disappears.
100
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Multiple port binding
2
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 ServerIron 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.
ServerIronADX(config)#server real rs1
ServerIronADX(config-rs-rs1)#port 81
ServerIronADX(config-rs-rs1)#port 8081 <- alias port
2. Create a second real server with two ports.
ServerIronADX(config)#server real rs2
ServerIronADX(config-rs-rs2)#port 82
ServerIronADX(config-rs-rs2)#port 8082 <- alias port
3. Create a virtual server.
ServerIronADX(config)#server virtual-name-or-ip vs1
4. Configure an HTTP port on the virtual server.
ServerIronADX(config-vs-vs1)#port http
5. Bind the alias ports to the real servers on the virtual servers.
ServerIronADX(config-vs-vs1)#bind http rs1 81 rs2 82
6. Create a second virtual server with an HTTP port.
ServerIronADX(config)#server virtual-name-or-ip vs2
ServerIronADX(config-vs-vs2)#port http
ServerIron ADX Server Load Balancing Guide
53-1003452-01
101
2
Multiple port binding
7.
Bind the alias ports to the real servers on the virtual servers.
ServerIronADX(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
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 option 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 8081 <---- alias port
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 8081 <------ alias port
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
102
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Multiple port binding
2
Configuration rules
Use the following rules when configuring the ServerIron 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.
ServerIronADX(config)#server real-name r1 10.0.1.5
ServerIronADX(config-rs-r1)#port http
ServerIronADX(config-rs-r1)#exit
ServerIronADX(config)#server real-name r2 10.0.2.200
ServerIronADX(config-rs-r2)#port 180
ServerIronADX(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.
ServerIronADX(config-vs-VIP1)#port http
ServerIronADX(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 ServerIron 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 ServerIron ADX does not perform the
translation for the application port. Instead, the ServerIron 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.
Configuration example
To implement the configuration described above, enter commands such as the following.
ServerIronADX(config)#server real-name r1 10.0.1.5
ServerIronADX(config-rs-r1)#port http
ServerIronADX(config-rs-r1)#port 180
ServerIronADX(config-rs-r1)#exit
ServerIronADX(config)#server real-name r2 10.0.2.200
ServerIronADX(config-rs-r2)#port http
ServerIronADX(config-rs-r2)#port 180
ServerIronADX(config-rs-r2)#exit
ServerIronADX(config)#server virtual-name-or-ip VIP1 10.157.22.88
ServerIronADX(config-vs-VIP1)#port http
ServerIronADX(config-vs-VIP1)#bind http r1 http r2 http
ServerIron ADX Server Load Balancing Guide
53-1003452-01
103
2
Multiple port binding
ServerIronADX(config-vs-VIP1)#exit
ServerIronADX(config)#server virtual-name-or-ip VIP2 10.157.22.99
ServerIronADX(config-vs-VIP2)#port http
ServerIronADX(config-vs-VIP2)#no port http translate
ServerIronADX(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 ServerIron ADX. The no port http translate command is required. This command enables the
ServerIron 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 ServerIron 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 508.
To display statistics for the separate real IP addresses, enter the following command at any
command prompt.
ServerIronADX(config)#show server real
Server State - 1:enabled, 2:failed, 3:test, 4:suspect, 5:grace_dn, 6:active
Name: r1
IP: 10.0.1.5
:
1 State: 3
Wt: 1
Max-conn: 1
000000
Src-nat (cfg:op) = 0: 0 Dest-nat-(cfg:op) = 0: 0
Port State
Ms CurConn TotConns
Rx-pkts
Tx-pkts
Rx-octet Tx-octet Reas
180
enabled 2
0
0
0
0
0
0 0
http enabled 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
000000
Src-nat (cfg:op) =
0
0
IP: 10.0.2.200
0
:
0: 0 Dest-nat-(cfg:op) =
0
1 State: 3
0
Wt: 1
0
0
Max-conn: 1
0: 0
Port State
Ms CurConn TotConns
Rx-pkts
Tx-pkts
Rx-octet Tx-octet Reas
http enabled 2
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
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 ServerIron ADX display distinguishes the traffic for the two
virtual IP addresses.
104
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Real server groups
2
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 ServerIron 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 508.
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 ServerIron 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. ServerIron ADX automatically binds all of the real servers associated with the real
server group to the bound virtual server.
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.
ServerIronADX(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 server group-real command enables you to delete a real server group. If you delete a real
server group that has been bound to a virtual server, the ServerIron 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, ServerIron ADX
automatically binds the newly associated real server to the virtual server.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
105
2
Real server groups
To associate up to four real servers with a real server group, enter a command such as the
following:
ServerIronADX(config-rsg-sg1)#real-server rs1 rs2 rs3 rs4
Syntax: [no] real-server real-server-names
The exit-server-names variable specifies the real servers associated with a real server group.
The no real-server command 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, ServerIron ADX
automatically unbinds the real server. Only those real server bindings that were particular to the
real server group are removed.
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.
ServerIronADX 1000(config)#server virtual name-or-ip v1
ServerIronADX 1000(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
ServerIron 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:
ServerIronADX(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.
106
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Disabling or deleting VIPs and real ports
2
Disabling or deleting VIPs and real ports
This section provides information to disable or delete VIPs and real ports.
Disabling VIPs
You can globally or individually disable VIPs.
To globally disable all virtual servers, enter the following command.
ServerIronADX(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.
ServerIronADX(config)#server virtual-name-or-ip www.foo.com
ServerIronADX(config-vs-www.foo.com)#disable
Use the no disable command to re-enable a virtual server.
Syntax: [no] disable
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.
ServerIronADX(config)#server real rs1 10.1.1.1
ServerIronADX(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.
ServerIronADX(config)#server virtual-name-or-ip Zoot_Allures 10.2.3.4
ServerIronADX(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.
ServerIronADX(config)#server virtual-name-or-ip Zoot_Allures 10.2.3.4
ServerIronADX(config-vs-Zoot_Allures)#no port http disable
ServerIron ADX Server Load Balancing Guide
53-1003452-01
107
2
Disabling or deleting VIPs and real ports
Globally disabling real and virtual ports
You can globally disable a Layer 4 port on the ServerIron 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 ServerIron 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.
ServerIronADX(config)#server port 80
ServerIronADX(config-port-http)#disable real
ServerIronADX(config-port-http)#
To disable all virtual HTTP ports, enter commands such as the following.
ServerIronADX(config)#server port 80
ServerIronADX(config-port-http)#disable virtual
ServerIronADX(config-port-http)#
To disable all real and virtual HTTP ports, enter commands such as the following.
ServerIronADX(config)#server port 80
ServerIronADX(config-port-http)#disable
ServerIronADX(config-port-http)#
Syntax: disable [real | virtual]
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.
ServerIronADX#rconsole 1 1
ServerIronADX1/1#show server real rs1
108
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Disabling or deleting VIPs and real ports
2
ServerIronADX1/1#rconsole-exit
ServerIronADX#rconsole 1 2
ServerIronADX1/2#show server real rs1
ServerIronADX1/1#rconsole-exit
ServerIronADX#rconsole 1 3
ServerIronADX1/3#show server real rs1
ServerIronADX1/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 real-server-name port 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.
Enabling force-delete
SLB and TCS allow the graceful shutdown of servers and services. By default, when a service is
disabled or deleted, the ServerIron ADX does not send new connections to the real servers for that
service. However, the ServerIron 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 110 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.
ServerIronADX(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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
109
2
Disabling or deleting VIPs and real ports
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.
ServerIronADX(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 output of the show server bind
command.
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 ServerIron 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 ServerIron ADX. This option immediately prevents new
connections. To safely delete the real server from the ServerIron, 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 ServerIron ADX allows existing connections to end normally or, if you have enabled the
force shutdown option, the ServerIron ADX ends all connections within two minutes. If you use
this method and later want to re-add the real server to the ServerIron ADX, you must redefine
the real server, then rebind the real server to the appropriate VIP.
110
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Disabling or deleting VIPs and real ports
2
• Shut down the real server itself, rather than change definitions on the ServerIron ADX. When
the real server stops responding to health checks, the ServerIron ADX removes the server from
the SLB. This option is simple because it does not require any configuration changes on the
ServerIron 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 is disabled, a ServerIron 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 is disabled and enabled quickly 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 is disabled and enabled quickly 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.
Table 6 describes the behavior of the ServerIron ADX for a specified action when it is configured
with the server force-delete command, with port hold-down timer, and in a normal scenario without
either configured.
TABLE 6
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.
Existing sessions
continue to exist
through their lifetime.
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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
111
2
Disabling or deleting VIPs and real ports
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.
ServerIronADX(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.
ServerIronADX(config)#server port-holddown
Syntax: [no] server port-holddown
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.
ServerIronADX(config)#server real rs1
ServerIronADX(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.
ServerIronADX(config)#server port http
ServerIronADX(config-port-http)#holddown
Syntax: [no] holddown
112
ServerIron ADX Server Load Balancing Guide
53-1003452-01
2
Disabling or deleting VIPs and real ports
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”.
ServerIronADX(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: 2000000
SrcNAT: cfg, op
DstNAT: not-cfg, not-op
Serv-Rsts: 0
tcp conn rate:udp conn rate = 0:0, max tcp conn rate:max udp conn rate = 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
SIP current TCP connections = 0
Port
---default
http
St
-UNB
HLD
Ms
-0
0
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
The time remaining for the holddown state is displayed by the show server real detail command as
shown in the following.
ServerIronADX(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
SIP TCP Current Connections = 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
…
ServerIron ADX Server Load Balancing Guide
53-1003452-01
113
2
Hash-based SLB with server persistence
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 ServerIron 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
ServerIron 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 ServerIron 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 ServerIron 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
ServerIron 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.
If the client makes another request to the VIP, for example after two days, then the ServerIron 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 ServerIron
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 through the
following options of the port port persist-hash command:
• 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 115.
• reassign-on-change — The default. Whenever a new server comes up, the ServerIron ADX
calculates the number of hash entries allocated to each existing server. The ServerIron ADX
then reassigns some of these entries to the new server. For more information, refer to
“Enabling the reassign-on-change mechanism” on page 116.
114
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Hash-based SLB with server persistence
2
Enabling persistent hashing
To enable the persistent hashing (phash) mechanism for a virtual server port, enter commands
such as the following.
ServerIronADX(config)#server virtual-name-or-ip vs1
ServerIronADX(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.
ServerIronADX(config)#server virtual-name-or-ip vs1
ServerIronADX(config-vs-vs1)#port http persist-hash clear-on-change
ServerIronADX(config-vs-vs1)#end
When the clear-on-change option 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.
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
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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
115
2
Hash-based SLB with server persistence
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
Enabling the reassign-on-change mechanism
To enable the reassign-on-change mechanism, enter commands such as the following.
ServerIronADX(config)#server virtual-name-or-ip vs1
ServerIronADX(config-vs-vs1#port http persist-hash reassign-on-change
When reassign-on-change is enabled (the default), the ServerIron ADX reassigns some of the
existing hash table entries on the introduction of a new server.
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 ServerIron ADX reassigns some
of the persistent hash entries on introduction of a new real server. By default, the ServerIron
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.
ServerIronADX(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 ServerIron ADX will clear the persistent hashing table.
116
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Hash-based SLB with server persistence
2
• Reassign duration — If the number of empty persistent hash entries is below the reassign
threshold, the ServerIron 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.
ServerIronADX(config)#server persist-hash-reassign-duration 5
This global command is applied to all configured VIP ports that are persist-hash enabled. The
ServerIron 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 ServerIron 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 ServerIron ADX does no reassignment.
If the number of empty hash table entries is less than or equal to the persist hash reassign
threshold, the ServerIron 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 ServerIron ADX attempts to reassign X persistent hash entries to the new real server over
the duration specified by the persist-hash-reassign-duration.
The ServerIron 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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
117
2
Hash-based SLB with server persistence
Consider the following reassignment example. Figure 16 shows the hash table before
reassignment.
FIGURE 16
Hash table before reassignment
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 ServerIron 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 ServerIron 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 ServerIron ADX now attempts to reassign some of the
persistent hash entries to the new real server rs3.
The ServerIron ADX then calculates entries per server X as follows.
X = total assigned hash table entries/number of active real servers = 10/3 = 3
The ServerIron 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.
118
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Hash-based SLB with server persistence
2
Figure 17 shows the persistent hash table after the reassignment.
FIGURE 17
Hash table after reassignment
Keeping the persistent hash table unchanged
To configure the ServerIron ADX not to clear the persistent hashing table when multiple servers
come up simultaneously and need reassignment, enter commands such as the following.
SLB-ServerIronADX(config)#server virtual-name-or-ip vs1
SLB-ServerIronADX(config-vs-vs1)#port http no-auto-clear-persist-hash-buckets
If this command is configured and multiple servers need reassignment simultaneously, then the
ServerIron ADX will leave the persistent hash table unchanged.
Syntax: port port no-auto-clear-persist-hash-buckets
Real server failure
If a real server fails, the ServerIron 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
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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
119
2
Hash-based SLB with server persistence
If port HTTP of real server rs1 fails, then the ServerIron 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
The ServerIron ADX does not immediately assign a new server to the cleared hash table entries.
Instead, the ServerIron 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.
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 ServerIron 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 ServerIron 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
Displaying persistent hash table entry and statistics
To display the persistent hash table entry and statistics for a virtual server, use the rconsole
command to get into the BP and enter the following command.
ServerIronADX#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
120
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Hash-based SLB with server persistence
2
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 7 displays the output field description of show server
persist-hash-buckets command.
TABLE 7
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).
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.
ServerIronADX(config)#server virtual-name-or-ip http-vs
ServerIronADX(config-vs-http-vs)#port http clear-persist-hash-statistics
ServerIronADX(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.
ServerIronADX(config)#server virtual-name-or-ip http-vs
ServerIronADX(config-vs-http-vs)#port http clear-persist-hash-buckets
ServerIronADX(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.
ServerIronADX#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
ServerIron ADX Server Load Balancing Guide
53-1003452-01
121
2
Hash-based SLB with server persistence
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.
ServerIronADX#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!
Displaying hash bucket counters
You can display information about hash bucket changes on the ServerIron ADX, through use of the
show server proxy keep-alive command. You can use the hash bucket counter information for
tracing the reason why a persist based on a hash-to-bucket CSW policy failed during traffic flow. A
truncated display is shown with the hash bucket information:
ServerIronADX#show server proxy keep-alive
Keep-alive connection statistics:
...
Hash Bucket Change:
Current serv is down =
Lower BP wins
=
...
1
0
Serv exceed max-con =
0
Syntax: show server proxy keep-alive
Table 8 displays the output field description of show server proxy keep-alive command.
TABLE 8
122
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
The number of times that the current server exceeds the max-conn
configuration.
Lower BP wins
The hash table is sync’ed to all BPs. Where another BP assigns the bucket
to a different server, the lower BP wins.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
SLB spoofing configuration and support
2
SLB spoofing configuration and support
Spoofing is the ServerIron 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 ServerIron 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:
ServerIronADX(config)#server virtual-name-or-ip vip1 10.10.1.100
ServerIronADX(config-vs-vip1)#port http
ServerIronADX(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 (from 12.3.00 release) with the following limitations.
• UDP spoofing will not work if GSLB is configured.
• UDP spoofing will not work if the dns-udp-count-connection command is configured.
• It is not supported for IMCP response traffic originated from the VIP.
Policy-based SLB
Policy-based server load balancing (PBSLB) is the ServerIron ADX’s ability to direct requests to a
server group based on the source IP address (IPv4 or IPv6)of the request.
When policy-based SLB is enabled for a port on a virtual server, the ServerIron ADX examines the
source IP address of each new connection sent to the VIP on the port. The ServerIron 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 ServerIron ADX forwards the request to the associated real server group. If no entry for
the IP address is found, the ServerIron ADX directs the request to a server group specified as the
"default" server group.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
123
2
Policy-based SLB
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.1 with Real Server Group
1, another associating network address 10.20.0.0/16 with Real Server Group 2 and a third.
associating network address 2001:DB8:300::/64 with Real Server Group 4. 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.1 is received on the VIP, the ServerIron ADX forwards
the request to one of the load-balanced servers in Real Server Group 1.
• When a request from network 10.20.0.0/16 is received, it is forwarded to the real server in
group 2.
• When a request from network 2001:DB8:300::/64 is received, it is forwarded to the real server
in group 4.
• 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. Requests for an IPv4 address are sent to the rs4 and requests
for an IPv6 address are sent to rs5.
124
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Policy-based SLB
2
NOTES: Consider the followng:
• 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
ServerIron ADX can have policy-based SLB enabled, while others do not.
• Policy-based SLB can exist on a standalone device or in high-availability
configurations, such as active-standby, symmetric, and active-active configurations.
• Policy-based SLB can coexist with other ServerIron ADX features, including FWLB, NAT,
and TCS.
• 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 for IPv4 using the CLI” and “Creating the policy list for IPv6 using the
CLI.”
• If the number of policies is large, you can download the policy list file from a TFTP server or a
USB flash. Refer to “Creating the policy list file to dynamically download from a TFTP server or
USB flash.”
Creating the policy list for IPv4 using the CLI
The following command can be used to add policies.
ServerIronADX(config)#server pbslb add 10.10.10.1 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 ServerIron ADX.
For the example shown in “Policy-based SLB configuration” on page 124, the policies can be added
as shown in the following.
ServerIronADX(config)#server pbslb add 10.10.10.1 1
ServerIronADX(config)#server pbslb add 10.20.0.0/16 2
Creating the policy list for IPv6 using the CLI
The following command can be used to add policies.
ServerIronADX(config)#server pbslb add 2001:DB8:300::/64 4
Syntax: server pbslb add ipv6-addr prefix [server-group-id]
The ipv6-addr variable can be a complete host address, or a network address followed by IPv6
mask bits specified by the prefix variable.
The server-group-id variable is alphanumeric and refers to one of the real server groups configured
on the ServerIron ADX.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
125
2
Policy-based SLB
For the example shown in “Policy-based SLB configuration” on page 124, the policies can be added
as shown in the following.
ServerIronADX(config)#server pbslb add 2001:DB8:300::/64
Creating the policy list file to dynamically download from a TFTP server or USB flash
To dynamically download a policy list file from a TFTP server or USB flash, 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 ServerIron ADX.
For the example shown in “Policy-based SLB configuration” on page 124, the policies would be
defined as shown in the following.
10.10.10.1 1
10.20.0.0/16 2
2001:DB8:300::/64 4
The policy list file created in the format defined above can be transferred to the ServerIron ADX
from either a TFTP server or through a USB flash drive. A single download file should contain all
IPv4 and IPv6 entries. These entries can be in any order.
NOTE
Downloading a new file overwrites the existing policy list file on a ServerIron 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 or USB flash,” the following command can be used to download the file from a
TFTP server.
ServerIronADX(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 ServerIron 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 ServerIron ADX retries the
download if the first attempt is not successful.
Dynamically downloading a policy list using an external USB flash drive
The following command can be used to download the policy list file from an external USB flash
drive.
ServerIronADX(config)#server pbslb /usb1/policy-list.txt 5
126
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Policy-based SLB
2
NOTE
The filename must begin with /usb1/ when downloading from and external USB flash drive.
When you enter this command, the downloaded policy list file immediately replaces the entries in
the ServerIron ADX’s policy-based SLB configuration.
Syntax: server pbslb usb-filename
The usb-filename variable specifies the name of the policy list file. It must begin with “/usb1/”.
Downloading a policy list using the internal USB flash drive
To be able to download a policy list file form the internal USB drive, you must first download the file
from the external USB drive to the internal USB using the following command.
ServerIronADX#copy usb1 usb0 policy-list.txt policy-list.txt
Syntax: copy usb1 usb0 source-filename destination-filename
The source-filename variable specifies the name of the file that is being copied from the external
USB flash drive to the internal USB flash drive.
The destination-filename variable specifies the name of the file once it is copied to the internal USB
flash drive.
After using the copy usb1 usb0 command to copy the file to the internal USB flash drive, you can
use the following command to download the policy list from the internal USB flash drive.
ServerIronADX(config)#server pbslb /usb0/policy-list.txt
When you enter this command, the downloaded policy list file immediately replaces the entries in
the ServerIron ADX’s policy-based SLB configuration.
Syntax: server pbslb usb-filename
The usb-filename variable specifies the name of the policy list file. It must begin with “/usb0/”.
Redirecting traffic to the default group during download
The ServerIron 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 the following: for IPv4 1,000,000 entries, for IPv6 256,000 entries. A ServerIron 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 over 1,000,000 for IPv4 or 256,000 for IPv4 through 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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
127
2
Policy-based SLB
3. Enable send-to-default-group-during-download.
Creating a PBSLB default group for IPv4
To create a PBSLB default group, enter a command such as the following.
ServerIronADX(config)#server pbslb default-group-id ipv4 4
Syntax: [no] server pbslb default-group-id ipv4 group-id
Creating a PBSLB default group for IPv6
To create a PBSLB default group, enter a command such as the following.
ServerIronADX(config)#server pbslb default-group-id ipv6 2
Syntax: [no] server pbslb default-group-id ipv6 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.
ServerIronADX(config)#server real-name rs1 10.95.7.14
ServerIronADX(config-rs-rs1)#port http group-id 4 4
ServerIronADX(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.
ServerIronADX(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
By default, a policy-based SLB configuration can have up to 25,000 IPv4 and 25,000 IPv6 entries.
You can optionally specify the maximum number of entries allowed for a policy-based SLB
configuration.
For example, to specify 40,000 as the maximum number of IPv4 entries for policy-based SLB, enter
the following command.
ServerIronADX(config)#server pbslb max-entries ipv4 40000
To specify 50,000 as the maximum number of IPv6 entries for policy-based SLB, enter the following
command.
ServerIronADX(config)#server pbslb max-entries ipv6 50000
Syntax: server pbslb max-entries { ipv4 | ipv6 } max-number
The max-number variable specifies the maximum number of PBSLB entries you want to configure.
The maximum number of IPv4 entries that ServerIron ADX supports is 10,000,000. The maximum
number of IPv6 PBSLB entries that ServerIron ADX supports is 1,000,000.
128
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Policy-based SLB
2
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 for IPv4
To delete an entry from the policy list, enter the following command.
ServerIronADX(config)#server pbslb delete 10.10.10.1/24 4
Syntax: server pbslb delete ipv4-addr { netmask | prefix [server-group-id]
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 ServerIron ADX.
Deleting an entry from the policy list for IPv6
To delete an entry from the policy list, enter the following command.
ServerIronADX(config)#server pbslb delete 2001:DB8:300::1/128
Syntax: server pbslb delete ipv6-addr prefix [server-group-id]
The ipv6-addr variable specifies the IPv6 entry that you want to delete from the policy list. You must
specify a prefix.
The server-group-id variable is alphanumeric and refers to one of the real server groups configured
on the ServerIron 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.
ServerIronADX(config)#server pbslb delete all ipv6
The whole IPv6 table of PBSLB has been deleted.
Syntax: server pbslb delete all {ipv6 | ipv4}
The ipv4 keyword directs the ServerIron ADX to delete the entire IPv4 PBSLB list.
The ipv6 keyword directs the ServerIron ADX to delete the entire IPv6 PBSLB list.
Copying a policy list to a file on TFTP server
To copy the currently loaded policy list from the ServerIron ADX to a file on a TFTP server, enter a
command such as the following.
ServerIronADX#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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
129
2
Policy-based SLB
The filename variable is the name the policy list file will be saved as.
Writing the policy list to flash memory
By default, the policy list is not saved to flash memory when you enter the write memory
command.To write the policy list to flash memory, enter the following command.
ServerIronADX(config)#server pbslb enable-config-gen
The next time the ServerIron ADX is booted, the policy list will appear in the running-config.
Syntax: server pbslb enable-config-gen
NOTE
The ServerIron ADX is unable to copy a policy list with more than 1,000 entries to Flash.
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 ServerIron 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.
ServerIronADX(config)#server pbslb default-group-id ipv4 3
Syntax: server pbslb default-group-id { ipv4 | ipv6 } group-id
The ipv4 parameter directs the ServerIron ADX to direct the request to an IPv4 server group.
The ipv6 parameter directs the ServerIron ADX to direct the request to an IPv6 server group.
The server-group-id variable is alphanumeric and refers to one of the real server groups configured
on the ServerIron 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.
For example, to configure real server rs1 in Figure 21 on page 124, enter commands such as the
following.
ServerIronADX(config)#server real rs1 10.95.7.1
ServerIronADX(config-rs-rs1)#port http group-id 1 1
ServerIronADX(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.
130
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Policy-based SLB
2
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.
ServerIronADX(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.
ServerIronADX(config-rs-rs1)#port http group-id 1 5
ServerIronADX(config-rs-rs1)#port http group-id 11 15
The configuration for the remaining real servers in Figure 21 on page 124 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 servers rs4 and rs5 in server group ID = 3.
ServerIronADX(config)#server real
ServerIronADX(config-rs-rs2)#port
ServerIronADX(config-rs-rs2)#exit
ServerIronADX(config)#server real
ServerIronADX(config-rs-rs3)#port
ServerIronADX(config-rs-rs3)#exit
ServerIronADX(config)#server real
ServerIronADX(config-rs-rs4)#port
ServerIronADX(config-rs-rs4)#exit
ServerIronADX(config)#server real
ServerIronADX(config-rs-rs5)#port
ServerIronADX(config-rs-rs5)#exit
ServerIronADX(config)#server real
ServerIronADX(config-rs-rs5)#port
ServerIronADX(config-rs-rs5)#exit
ServerIronADX(config)#server real
ServerIronADX(config-rs-rs5)#port
ServerIronADX(config-rs-rs5)#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
rs5 2001:db8::1
http group-id 3 3
rs6 2001:db8:400::1
http group-id 4 4
rs7 2001:db8:400::2
http group-id 4 4
Enabling PBSLB for a port on a virtual server
To enable policy-based SLB on a VIP for Figure 21 on page 124, enter commands such as the
following.
ServerIronADX(config)#server virtual-name-or-ip mysite 10.157.22.63
ServerIronADX(config-vs-mysite)#port http
ServerIronADX(config-vs-mysite)#port http sw-l4-pbslb
ServerIronADX(config-vs-mysite)#bind http rs1 http rs2 http rs3 http rs4 http rs5
http
Syntax: [no] port port sw-l4-pbslb
ServerIron ADX Server Load Balancing Guide
53-1003452-01
131
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.
ServerIronADX(config)#server pbslb scan-session-table-after-config-change
Syntax: [no] server pbslb scan-session-table-after-config-change
Use the no server pbslb scan-session-table-after-config-change command to disable this feature.
The feature is disabled by default.
PBSLB pool failsafe group
The PBSLB pool failsafe group feature allows a ServerIron 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 ServerIron ADX looks up a group
id for the client to forward the incoming request to. If all the servers in the group fail, the ServerIron
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, and the max-conn limit is not reached, traffic
is load balanced among servers as per predictor.
• If all servers of the group are in a failed state or the max-conn limit is reached, traffic is load
balanced among "failsafe" group servers.
• If all of the servers of the "failsafe" group are in a failed state or the max-conn limit is reached,
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 or the max-conn limit is reached on
all servers, the traffic is load balanced among "failsafe" group servers.
• If all of the servers of the failsafe group are in a failed state or the max-conn limit is reached,
the traffic is denied.
132
ServerIron ADX Server Load Balancing Guide
53-1003452-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.
ServerIronADX(config)#server pbslb failsafe-group-id ipv4 2
Syntax: [no] server pbslb failsafe-group-id { ipv4 | ipv6 } group-id
The ipv4 parameter directs the ServerIron ADX to create an IPv4 failsafe group.
The ipv6 parameter directs the ServerIron ADX to create an IPv6 failsafe group.
The group-id variable is alphanumeric and refers to one of the real server groups configured on the
ServerIron 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.
ServerIronADX(config)#server real-name rs1 10.95.7.1
ServerIronADX(config-rs-rs1)#port http group-id 2 2
ServerIronADX(config-rs-rs1)#exit
Enabling PBSLB on a VIP port
To enable PBSLB on a VIP port, enter commands such as the following.
ServerIronADX(config)#server virtual-name-or-ip mysite 10.157.22.63
ServerIronADX(config-vs-mysite)#port http
ServerIronADX(config-vs-mysite)#port http sw-l4-pbslb
ServerIronADX(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.
ServerIronADX#show pblsb failsafe ipv4
Syntax: show pbslb failsafe { ipv4 | ipv6}
To clear the PBSLB failsafe counter, enter the following command.
ServerIronADX#clear pbslb failsafe
Syntax: clear pbslb failsafe
ServerIron ADX Server Load Balancing Guide
53-1003452-01
133
2
Policy-based SLB
Auto Download of PBSLB list
Policy Based Load Balancing (PBSLB) Auto Download allows you to automatically download a list of
policies to the ServerIron 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 ServerIron on a pre-determined schedule.
NOTE
The server pbslb tftp command must be configured before the server pbslb time-of-day or server
pbslb download-interval command, so the ServerIron 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 ServerIron ADX to download a PBSLB list at a periodic interval, use commands
similar to the following.
ServerIronADX(config)#server pbslb tftp 10.10.1.101 iplist.txt 2
ServerIronADX(config)#server pbslb download-interval 20
Syntax: server pbslb download-interval interval-in-minutes
In this example, the ServerIron 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.
Configuring PBSLB time of day
To configure the ServerIron to download a PBSLB list at a specified time, use commands similar to
the following.
NOTE
The SNTP clock must be set for this command to work.
ServerIronADX(config)#server pbslb tftp 10.10.1.101 iplist.txt 2
ServerIronADX(config)#server pbslb time-of-day 15:30:00 16:00:00
Syntax: server pbslb time-of-day time-in-hh:mm:ss
In this example, the ServerIron ADX downloads the PBSLB list at 3:30 pm and 4:00 pm every day
until the command is reset. You can configure a maximum of five time-of-day parameters.
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.
134
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Policy-based SLB
2
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.
ServerIronADX#show
IP address
2001:db8::1
pbslb 2001:db8::1
Mask
Server Group ID
128
11
Syntax: show pbslb ip-address
The ip-address variable specifies the IPv4 or IPv6 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.
To display multiple entries in the policy list, enter a command such as the following.
ServerIronADX#show pbslb all ipv6 10
Max Count: 1000000
Total Count: 2
IP address
Mask
Server Group ID
2001:db8::1
128
11
2001:db8::2
128
12
Syntax: show pbslb all {ipv4 | ipv6} 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.
The ipv4 parameter directs the ServerIron ADX to display IPv4 entries.
The ipv6 parameter directs the ServerIron ADX to display IPv6 entries.
Displaying PBSLB group entries
You can display IPv6 entries in the currently loaded policy list for a specified group as shown.
ServerIronADX#show pbslb group 11 ipv6 40
IP address
Mask
Server Group ID
2001:db8::1
128
11
Syntax: show pbslb group group-id ipv6 index
The group-id variable is alphanumeric and refers to one of the real server groups configured on the
ServerIron ADX.
The show pbslb group command displays entries in the policy list, starting from the point specified
with the index variable.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
135
2
Policy-based SLB
Packet trace
When a policy list file is downloaded to the ServerIron 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 ServerIron ADX, these messages do not appear on the Telnet or SSH
session. To monitor the download progress on a Telnet session, you need to enable packet trace
using the ptrace term command in the Telnet session.
ServerIronADX#ptrace term
debug output is now sent to this terminal
Syntax: ptrace term
When you enter the ptrace term command on a Telnet session, the ServerIron ADX redirects the log
output for both the debug and ptrace commands to this session.
NOTE
You can only use the ptrace term command on a console or Telnet session. The ptrace term
command is not supported on SSH sessions. To redirect the output back to the console or to a
different Telnet session, enter the ptrace term command in that session.
ServerIronADX(config)#server pbslb tftp 10.1.1.1
pbslb/pbslb2M.txt 1 Download of pbslb config from TFTP server is initiated.
.SLB-telnet@ServerIronADX(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 9
136
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 ServerIron 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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous options
TABLE 9
2
Error messages (Continued)
Message
Description
Full err
The number of times the ServerIron 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 ServerIron 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 ServerIron 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 ServerIron ADX) or when the
network topology has changed.
By default, when you change a server’s IP address, the ServerIron 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 ServerIron 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.
ServerIronADX(config)#server real rs1
ServerIronADX(config-rs-rs1)#ip-address 10.6.7.8
Syntax: [no] ip-address ip-addr [force-shutdown]
The ip-addr variable specifies the real server’s new IP address.
The force-shutdown parameter immediately resets a client’s connection to the IP address when the
ServerIron ADX receives TCP data from the client. By default, the ServerIron ADX allows existing
connections to terminate normally following the address change.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
137
2
Miscellaneous options
Adding a description
You can add a description to a real server, virtual server, firewall, or cache. 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.
ServerIronADX(config)#server real RS20 10.2.3.4
ServerIronADX(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 ServerIron ADX at Layer 2. The ServerIron
ADX uses local servers for regular load balancing.
• Remote – A remote server is one that is connected to the ServerIron ADX through one or more
router hops. The ServerIron 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 76.
Defining the maximum number of connections
You can limit the maximum number of sessions the ServerIron ADX will maintain in its session table
for each barrel processor of a real server. By setting a limit for each barrel processor of a real
server, you can avoid a condition where the capacity threshold of the real server is exceeded.
When a barrel processor of a real server reaches the maximum defined connection threshold, an
SNMP trap is sent. When all the barrel processors of a real server pool reach their maximum
connection threshold, additional TCP or UDP packets are dropped, and an ICMP destination
unreachable message is sent.
Up to one million total sessions are supported on the ServerIron ADX. This is also the default
maximum connection value for real servers.
To modify the maximum connections supported for a specific real server, enter commands such as
the following.
ServerIronADX(config)#server real Web1
ServerIronADX(config-rs-Web1)#max-conn 145000
ServerIronADX(config-rs-Web4)#end
ServerIronADX#write mem
Syntax: [no] max-conn 1-2000000
You can also limit the maximum number of connections for individual application ports on a real
server.
For example, to limit the number of FTP connections on real server Web1 to 10, enter the following
commands.
ServerIronADX(config)#server real Web1
ServerIronADX(config-rs-Web1)#port ftp max-conn 10
138
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous options
2
Syntax: [no] port port max-conn number
NOTE
For FTP (Port 21), the number of current connections is equal to the number of control connections,
plus any data connections opened during the session. For example, logging on to an FTP site (the
control connection) and transferring a file from the FTP site equal two connections. In Passive mode,
the FTP data connection is initiated from the client side. Although there is only one control
connection, additional operations performed while you are logged on can consume all the FTP
connections allowed. In Active mode, the FTP data connection is initiated from the server side. In
Active mode, the server to client connection is not counted towards max-conn value though they are
still counted as current connections on the server. When the current connection counter is higher
than the max-conn value, any new connections from client to real server are dropped as the
max-conn value is reached.
NOTE
If you use the max-conn command for a firewall, the command specifies the maximum permissible
number of connections that can be initiated from this ServerIron ADX's direction on the firewall
paths. The max-conn command does not limit the total number of connections that can exist on the
ServerIron ADX, which includes connections that come from the ServerIron ADXs at the other ends
of the firewall paths. For Firewall Load Balancing (FWLB), the fw-exceed-max-drop command
restricts the total number of connections that can exist on the ServerIron ADX.
Setting a logging threshold for connection rate
You can set a threshold on the ServerIron ADX to send a log message for the following connection
rates:
• The maximum number of sessions the ServerIron ADX maintains in its session table for all
barrel processors or a real server pool. The number is set as described in “Defining the
maximum number of connections” on page 138. This rate is set per real server.
• The maximum number of new TCP connections per-second allowed on a real server. The
number is set as described in “Configuring the connection rate” on page 146. This rate is set
per real server.
• The maximum number of UDP connections per-second allowed on a real server. The number is
set as described in “Configuring the connection rate” on page 146. This rate is set per real
server.
Using the logging threshold feature, you can set a percentage threshold for each of these
connection rates that generates a log message. The rate can be set globally to apply for each real
server or locally to apply to an individual real server. The local real server value has a higher
precedence level than the global value. Also, because there is no default level, a log message will
not be generated unless these thresholds are applied either globally or locally.
Example
The maximum number of connections for real server “Web4” is set to 2000. The global logging
threshold for maximum connections is set to 80 percent and the local logging threshold is set for
“Web4” is set to 70 percent.
When the number of connections at “Web4” reaches 1400 a warning log will be generated. This is
because 1400 is 70% of the 2000 limit set for “Web4”.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
139
2
Miscellaneous options
Setting the logging threshold for maximum connections
You can set a percentage value (either globally or locally per real server) for the percentage of the
value set for maximum connections that causes the ServerIron ADX to send a warning log
message.
The following example sets the value to 70 percent at the global level.
ServerIronADX(config)#server conn-limit send-log-threshold for-max-conn 70
Syntax: [no] server conn-limit send-log-threshold for-max-conn percentage
The following example sets the value to 70 percent at the local level for the “Web1” real server.
ServerIronADX(config)#server real Web1
ServerIronADX(config-rs-Web1)#conn-limit send-log-threshold for-max-conn 80
ServerIronADX(config-rs-Web1)#end
ServerIronADX#
Syntax: [no] conn-limit send-log-threshold for-max-conn percentage
The percentage variable specifies the percentage of the configured maximum number of
connections that causes the log message to be sent. A percentage value from 1 - 100 can be
configured. If both a global and local (per real server) values are configured, the local value has
precedence. If only a global value is configured, it will apply individually to each real server. If no
value is configured either globally or locally, no warning log message is sent.
The no conn-limit send-log-threshold for-max-conn command returns the operation to the default
behavior. If no value is configured either globally or locally, no warning log message is sent.
Setting the logging threshold for the TCP connection rate
You can set a percentage value (either globally or locally per real server) for the percentage of the
value configured for the maximum number of TCP connections-per-second that causes the
ServerIron ADX to send a warning log message.
The following example sets the value to 80 percent at the global level.
ServerIronADX(config)#server conn-limit send-log-threshold for-tcp-conn-rate 80
Syntax: [no] server conn-limit send-log-threshold for-tcp-conn-rate percentage
The following example sets the value to 90 percent for the “Web2” real server.
ServerIronADX(config)#server real Web2
ServerIronADX(config-rs-Web2)#conn-limit send-log-threshold for-tcp-conn-rate 90
ServerIronADX(config-rs-Web2)#end
ServerIronADX#
Syntax: [no] conn-limit send-log-threshold for-tcp-conn-rate percentage
The percentage variable specifies the percentage of the configured rate per second of TCP
connections to a real server that causes the log message to be sent. A percentage value from 1 100 can be configured. If both a global and local (per real server) values are configured, the local
value has precedence. If only a global value is configured, it will apply individually to each real
server. If no value is configured either globally or locally, no warning log message is sent.
Using the no conn-limit send-log-threshold for-tcp-conn-rate command returns the operation to the
default behavior. If no value is configured either globally or locally, no warning log message is sent.
140
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous options
2
Setting the logging threshold for the UDP connection rate
You can set a percentage value (either globally or locally per real server) for the percentage of the
value configured for the maximum number of UDP connections-per-second that causes the
ServerIron ADX to send a log message.
The following example sets the global value to 60 percent.
ServerIronADX(config)#server conn-limit send-log-threshold for-udp-conn-rate 60
Syntax: [no] server conn-limit send-log-threshold for-tcp-conn-rate percentage
The following example sets the value to 80 percent locally for the “Web3” real server.
ServerIronADX(config)#server real Web3
ServerIronADX(config-rs-Web3)#conn-limit send-log-threshold for-udp-conn-rate 80
ServerIronADX(config-rs-Web3)#end
ServerIronADX#
Syntax: [no] conn-limit send-log-threshold for-udp-conn-rate percentage
The percentage variable specifies the percentage of the configured rate per second of UDP
connections to a real server that causes the log message to be sent. A percentage value from 1 100 can be configured. If both a global and local (per real server) values are configured, the local
value has precedence. If only a global value is configured, it will apply individually to each real
server. If no value is configured either globally or locally, no warning log message is sent.
Using the no conn-limit send-log-threshold for-udp-conn-rate command returns command returns
the operation to the default behavior. If no value is configured either globally or locally, no warning
log message is sent.
Configuring a TCP MSS value at the global level
The default TCP MSS value configured on a ServerIron ADX is 1460 Bytes. This value can be
changed globally as shown in the following.
ServerIronADX(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 ServerIron ADX is 1460 Bytes. This value can be
changed per virtual server as shown in the following.
ServerIronADX(config)#server virtual-name-or-ip v1
ServerIronADX(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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
141
2
Miscellaneous options
Configuring a TCP MSS value at the virtual server port level
The default TCP MSS value configured on a ServerIron ADX is 1460 Bytes. This value can be
changed per virtual server port as shown in the following.
ServerIronADX(config)#server virtual-name-or-ip v1
ServerIronADX(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 ServerIron ADX is 1460 Bytes. This value can be
changed per TCP profile as shown in the following.
ServerIronADX(config)#tcp profile tcp1
ServerIronADX(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
Starting with the ServerIron ADX release 12.4.00f, the TCP window scale option in TCP header
feature is supported. This 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.
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 configuration level as shown in the
example:
ServerIronADX(config)# tcp profile sample
ServerIronADX(config-tcp-sample)# tcp-wnd-scale 1
ServerIronADX(config-tcp-sample)# rxbuf-size 3145278
ServerIronADX(config-tcp-sample)# txbuf-size 3145278
142
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous options
2
Syntax: [no] tcp-wnd-scale tcp-wnd-scale
The tcp-wnd-scale variable specifies the TCP window scale factor from 1 to 7, the default is 0.
Syntax: [no] rxbuf-size rxbuf-size
The rxbuf-size variable specifies maximum TCP receive buffer size. Enter an integer from 0 to
3145278. The default is 0.
Syntax: [no] txbuf-size txbuf-size
The txbuf-size variable specifies maximum TCP transmit buffer size. Enter an integer from 0 to
3145278. The default is 0.
For example, to display the TCP profile named sample, enter the following show tcp profile
command:
ServerIronADX# 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-of-TCP-profile
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.
ServerIronADX(config)#server virtual-name-or-ip v1
ServerIronADX(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.
Configuring jumbo frame support
By default, the ServerIron ADX supports an IP Maximum Transmission Unit (MTU) frame size of
1518 bytes. Jumbo frames enable the ServerIron ADX to handle packet sizes of up to 9216 bytes.
Jumbo frames are supported for both IPv4 and IPv6 traffic in server load balancing, transparent
cache switching, and firewall load balancing environments.
IP MTU values can be set globally and at the virtual server level. The frame size configured with
these commands are supported for both pass-through traffic via the Management Processor and
traffic switched within the ServerIron ADX.
You must reboot the ServerIron ADX when support for IPv4 or IPv6 jumbo frames are enabled or
disabled.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
143
2
Miscellaneous options
Configuring jumbo frame support globally
The ServerIron ADX uses the largest MTU configured (IPv4 or IPv6) to calculate the maximum frame
size programmed in hardware.
When a global IP MTU value is configured, it is applied to all physical ports that are part of the
default VLAN and to all virtual (VE) interfaces that are associated with non-default VLANs. While the
global IP MTU value supersedes the default MTU value for the ServerIron ADX, it does not
supercede a value configured for an individual VE interface.
To configure an IPv4 MTU value globally, use the following command.
ServerIronADX(config)#ip global-mtu 9216
Syntax: [no] ip global-mtu ipv4 mtu-value
The ipv4-mtu-value variable can be from 576 to 9216. This variable specifies IP MTU value that will
be applied globally. The sum of this value and 18 bytes (for the Layer-2 header) is used to set the
maximum frame size at the port level. The default IP MTU value is 1500, which results in a default
max frame size of 1518. Configuring an IP MTU value greater than 1798 enables jumbo frame
support on the ServerIron ADX.
To configure an IPv6 MTU value globally, use the following command.
ServerIronADX(config)#ipv6 global-mtu 9216
Syntax: [no] ipv6 global-mtu ipv6-mtu-value
The ipv6-mtu-value variable can be from 1280 to 9216. The sum of this value and 18 bytes (for the
Layer-2 header) is used to set the maximum frame size at the port level. The default IP MTU value is
1500, which results in a default max frame size of 1518.
Configuring jumbo frame support for a VE interface
Configuring an IP MTU value greater than 1798 on any virtual (VE) interface of the ServerIron ADX
running router code enables jumbo frames.
The mtu-value variable specifies IP MTU value that will be applied for the specified VE interface.
Values can be specified for both IPv4 and IPv6 traffic. The ServerIron ADX uses the largest IP MTU
value configured (IPv4 or IPv6) to calculate the maximum frame size programmed in hardware.
To configure an IPv4 MTU value for a VE interface, use the following command.
ServerIronADX(config)#interface ve 3
ServerIronADX(config-vif-3)#ip mtu 9216
Syntax: [no] ip mtu ipv4 mtu-value
For IPv4 traffic, the ipv4-mtu-value variable can be from 576 to 9216. The sum of this value and 18
bytes (for the Layer-2 header) will be used to set the maximum frame size at the port level. The
default IP MTU value is 1500, which results in a default max frame size of 1518.
Use the following command to configure an IPv6 MTU value for a VE interface:
ServerIronADX(config)#interface ve 3
ServerIronADX(config-vif-3)#ipv6 mtu 9216
Syntax: [no] ipv6 mtu ipv6-mtu-value
144
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous options
2
For IPv6 traffic, the ipv6-mtu-value variable can be from 1280 to 9216. The sum of the configured
value and 18 bytes (for the Layer-2 header) defines the maximum frame size at the port level. The
default IP MTU value is 1500, which results in a default max frame size of 1518.
An IP MTU value set with this command supersedes the default MTU value for the ServerIron ADX
as well as any global level that is configured on the ServerIron ADX.
NOTE
Configuring an IP MTU value greater than 1798 on any virtual interface of the ServerIron ADX
running router code enables jumbo frames.
Displaying the IP MTU value
The following commands allow you to view the currently configured IP MTU values on a ServerIron
ADX. These values can be displayed for a physical Ethernet interface or for a virtual interface (VE)
as shown.
To display the IP MTU value for a physical Ethernet interface use the command shown in the
following. The MTU value is displayed as MTU 4000 bytes.
ServerIronADX(config)#show int e 1/1
GigabitEthernet1/1 is down, line protocol is up
Hardware is GigabitEthernet, address is 0004.08a0.4040 (bia 0004.08a0.4040)
Configured speed auto, actual unknown, configured duplex fdx, actual unknown
Member of L2 VLAN ID 1, port is untagged, port state is FORWARDING
STP configured to ON, priority is level0, flow control enabled
mirror disabled, monitor disabled
Not member of any active trunks
Not member of any configured trunks
No port name
MTU 4000 bytes, encapsulation ethernet
IPv6 is disabled
300 second input rate: 0 bits/sec, 0 packets/sec, 0.00% utilization
300 second output rate: 0 bits/sec, 0 packets/sec, 0.00% utilization
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts, 0 multicasts, 0 unicasts
0 input errors, 0 CRC, 0 frame, 0 ignored
0 runts, 0 giants, DMA received 0 packets
0 packets output, 0 bytes, 0 underruns
Transmitted 0 broadcasts, 0 multicasts, 0 unicasts
0 output errors, 0 collisions, DMA transmitted 0 packets
To display the IP MTU value for a virtual (VE) interface use the command shown in the following.
The MTU value is displayed as MTU 7000 bytes.
ServerIronADX(config-vif-6)#show interfaces ve 6
Ve6 is down, line protocol is up
Hardware is Virtual Ethernet, address is 0004.08a0.4040 (bia 0004.08a0.4040)
No port name
Internet address is 192.168.2.1/24, MTU 7000 bytes, encapsulation ethernet
IPv6 is disabled
Syntax: show interface [Ethernet portnum] [ve ve-num]
ServerIron ADX Server Load Balancing Guide
53-1003452-01
145
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 connections to a maximum of 3500 for all Web servers on the network shown in
Figure 5, enter the following command.
ServerIronADX(config)#server syn-limit 3500
Syntax: [no] server syn-limit number
The number is the maximum number of TCP SYN requests per second per server. Enter an integer
from 1 to 65535. The default value is 65535.
Configuring the connection rate
Connection Rate Control (CRC) specifies the maximum number of new TCP, UDP, or individual port
connections per second allowed on the real server.
It enables you to limit the connection rate to a real server for the following:
• All TCP traffic
• All UDP traffic
• Individual TCP or UDP ports
The ServerIron ADX increments the connection counter for real server connections only after the
ServerIron ADX selects a server for the connection. If the ServerIron 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 ServerIron ADX tries another server. If there are
no servers available, the ServerIron 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 ServerIron 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 ServerIron ADX limits
connections to TCP port HTTP to 600 per second.
NOTE
The ServerIron 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 ServerIron 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.
ServerIronADX(config)#server real RS1 10.2.3.4
ServerIronADX(config-rs-RS1)#max-tcp-conn-rate 1000
ServerIronADX(config-rs-RS1)#max-udp-conn-rate 800
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.
146
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous options
2
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.
ServerIronADX(config-rs-RS1)#port http
ServerIronADX(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 hardware forwarding of pass-through traffic
This feature enables the hardware forwarding of pass-through traffic (traffic not meant for Layer 4
processing) generated by a real server.
NOTE
This feature cannot be enabled for real servers that support complex protocols (FTP and streaming
media ports bound). The reason is that these applications negotiate ports for the data channel, on
the fly.
When Syn-Proxy is configured on the ServerIron ADX, it is applied to both pass-through and SLB
traffic. The "Syn-Proxy for PassThrough Traffic" and "Hardware Forwarding of Real Server
PassThrough Traffic" features are mutually exclusive. Therefore, you need to configure Syn-Proxy
only for SLB traffic when the hardware forward feature is enabled. Syn-Proxy for SLB traffic can be
configured using the server security-on-vip-only command.
Hardware forwarding of pass through traffic is enabled under a real server. When you want non-SLB
traffic from a particular real server to be hardware forwarded, enable hardware forwarding for that
real server.
To configure hardware forwarding of pass-through traffic for a specific real server, enter the
following command.
ServerIronADX(config-rs-rs1)#hw-fwd-pass-through-traffic
Syntax: [no] hw-fwd-pass-through-traffic
ServerIron ADX Server Load Balancing Guide
53-1003452-01
147
2
Miscellaneous options
To globally configure hardware forwarding of pass-through traffic for all real servers in the system,
enter the following command.
ServerIronADX(config)#server hw-fwd-pass-through-traffic
Syntax: [no] server hw-fwd-pass-through-traffic
The show cam layer4/7 command has been enhanced to show the new user type, Real server port.
.
ServerIronADX#show cam layer4/7 detail slb
User Type: Real server port
Entry Type: Real server port
Match Srcip: 10.32.5.111 (0x0a20056f)
Mask: 0xffffffff
Srcport : 5050 Mask:
0xffff
16594 - (DestIP & 0xF): 0 to 1
FID: dd03
BP: 3/1
16596 - (DestIP & 0xF): 2
FID: dd02
BP: 3/1
16598 - (DestIP & 0xF): 3
FID: dd06
BP: 3/2
16598 - (DestIP & 0xF): 3
FID: dd06
BP: 3/2
16602 - (DestIP & 0xF): 6 to 7
FID: dd0b
BP: 3/3
16604 - (DestIP & 0xF): 8
FID: dd0a
BP: 3/3
16606 - (DestIP & 0xF): 9
FID: dd02
BP: 3/1
16608 - (DestIP & 0xF): a to b
FID: dd03
BP: 3/1
16610 - (DestIP & 0xF): c
FID: dd07
BP: 3/2
16612 - (DestIP & 0xF): d
FID: dd06
BP: 3/2
16614 - (DestIP & 0xF): e
FID: dd0b
BP: 3/3
16616 - (DestIP & 0xF): f
FID: dd0a
BP: 3/3
Syntax: show cam layer4/7
Disabling port translation
By default, the ServerIron 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 ServerIron 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 ServerIron 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 ServerIron ADX collects and displays
separate statistics for the alias port number associated with each virtual IP address.
For a complete configuration example, refer to “Multiple port binding using port aliases” on
page 530.
To disable translation for an application port, enter commands such as the following.
ServerIronADX(config)#server virtual-name-or-ip v1 10.157.22.1
ServerIronADX(config-vs-v1)#no port 80 translate
Syntax: [no] port tcp/udp-port translate
148
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous options
2
Traffic distribution among BPs
The ServerIron 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 ServerIron switch, 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.
ServerIronADX(config)#server hash-crc32u
Syntax: server [hash-crc32l | hash-crc32u | hash-xori | 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.
Including the server client port in hash calculations
When there are a small number of client IP addresses that connect to a ServerIron ADX switch, 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.
ServerIronADX(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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
149
2
Miscellaneous options
Sending ICMP Port Unreachable or Destination Unreachable messages
NOTE
ICMP messages are disabled by default.
By default, if the ServerIron ADX receives a client request for a specific VIP and UDP port, but the
requested port is not bound to the requested VIP, the ServerIron 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 ServerIron ADX does not include a binding for port 99, the ServerIron ADX drops
the request without sending a message to the client.
You can configure the ServerIron 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 ServerIron ADX does not
send an “ICMP Destination Unreachable message” to the client.
For HTTP traffic, you can configure the ServerIron 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 ServerIron 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.
ServerIronADX(config)#server icmp-message
Syntax: [no] server icmp-message
NOTE
If the server disable-ping-vip-down command is configured, the ServerIron ADX will stop responding
to ICMP echo request when the VIP is down.
Sending a TCP RST to a client that requests unavailable
applications
If a client requests an unavailable application, the ServerIron 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 ServerIron ADX to send a TCP RST to a client, enter the following command.
ServerIronADX(config)#server reset-message
Syntax: [no] server reset-message
150
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous options
2
NOTE
The server reset message overrides the ICMP Destination Unreachable message. If the
configuration contains both, the ServerIron 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 ServerIron ADX to send an ICMP Destination
Unreachable message to a client, refer to “Sending ICMP Port Unreachable or Destination
Unreachable messages” on page 150.
NOTE
The server no-reset-on-max-conn command overrides the server reset-message command. For
more information, refer to “Disabling TCP RST message on maximum connections” on page 152.
Sending a TCP RST when TCP session entry ages out
By default, the ServerIron 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 ServerIron 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.
ServerIronADX(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.
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 ServerIron 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.
ServerIronADX(config)#server no-reset-for-established-session
Syntax: [no] server no-reset-for-established-session
ServerIron ADX Server Load Balancing Guide
53-1003452-01
151
2
Miscellaneous options
By default, sending TCP RST messages is enabled.
Disabling TCP RST message on maximum connections
When a client sends a TCP SYN to a VIP, the ServerIron ADX selects one of the real servers bound to
the VIP for the client's connection. If the ServerIron ADX cannot select a real server (for example, if
the server port is down, or the server port has reached its maximum connection limit), then by
default the ServerIron ADX sends a TCP RST to the client.
You can configure the ServerIron ADX not to send a TCP reset when the maximum connections limit
is reached. The client can then subsequently attempt to establish a connection, by which time a
real server might have fewer connections that its maximum connections limit, and the ServerIron
ADX would be able to select it.
To disable the TCP RST message sent when the maximum connections limit on the real servers is
reached, enter the following command.
ServerIronADX(config)#server no-reset-on-max-conn
Syntax: [no] server no-reset-on-max-conn
NOTE
This command overrides the server reset-message command, which enables the ServerIron ADX to
send TCP RST to clients that request unavailable applications. If the configuration contains both
commands, the ServerIron ADX will not send a TCP RST to a connecting client if the maximum
connections limit on the real servers has been reached.
Decrement counters in deletion queue
On a ServerIron 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.
ServerIronADX(config)#server decrement-counter-when-put-in-delQ
Syntax: [no] server decrement-counter-when-put-in-delQ
Optimized fast-path SLB processing
You can enable the ServerIron ADX to use fast-path processing for stateful or stateless 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.
• Stateless SLB is a form of SLB that does not use session table entries. All packets that go
through stateless ports take an optimized processing path.
When you enable fast-path processing, the ServerIron ADX does not process every TCP or UDP
packet in a given session in detail. Instead, the ServerIron ADX uses information gathered during
setup of the session to forward packets in the session.
152
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous options
2
NOTE
SLB optimization is useful if simple SLB (stateful or stateless) is the primary or sole application on
the device. If you use the ServerIron ADX for other features such as global server load balancing
(GSLB) or Firewall Load Balancing (FWLB), SLB optimization is not useful.
NOTE
Stateful and stateless SLB traffic is optimized by default.
Enabling fast-path processing for stateless SLB
When you enable fast-path processing, the ServerIron ADX does not process every TCP or UDP
packet in a given session in detail. Instead, the ServerIron ADX uses information gathered during
setup of the session to forward packets in the session. All packets that go through stateless ports
take an optimized processing path.
SLB optimization is useful if simple SLB is the primary or sole application on the device. If you use
the ServerIron ADX for other features such as GSLB or FWLB, SLB optimization is not useful.
Fast-path processing applies only to some configurations.
To enable fast-path processing for stateless SLB, enter the following command.
ServerIronADX(config)#server fast-stateless
Syntax: [no] server fast-stateless
Configuration considerations
Consider the following:
• You can use only one type of optimization at a time. You cannot use stateful and stateless
optimization at the same time.
• 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.
The show server stateless command does not display hits.
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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
153
2
Miscellaneous options
• For stateless SLB, optimization is supported only for the following TCP or UDP ports that are
well-known to the ServerIron ADX:
-
154
7 (echo)
9 (discard)
21 (ftp)
22 (ssh)
23 (telnet)
25 (smtp)
37 (time)
49 (tacacs)
53 (dns)
67 (bootps)
68 (bootpc)
69 (tftp)
80 (http)
109 (pop2)
110 (110)
119 (nntp)
123 (ntp)
137 (netbios-ns)
138 (netbios-dgm)
143 (imap4)
161 (snmp)
162 (snmp-trap)
179 (bgp)
195 (dnsix)
389 (ldap)
434 (mobile-ip)
443 (ssl)
517 (talk)
520 (rip)
554 (rtsp)
1755 (mms)
1812 (radius)
1645 (radius-old)
7070 (pnm)
1558 (xing)
12468 (vxstream1)
12469 (vxstream2)
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous options
2
Configuring TCP fast aging
Following a RST from the server, the ServerIron ADX ages out session table entries in the amount of
time specified in the server msl command, by default 8 seconds. You can optionally configure the
ServerIron 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.
ServerIronADX(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.).
To disable TCP fast aging and use the 1- to 2- minute aging time from previous releases, enter the
following command.
ServerIronADX(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 ServerIron ADX does not calculate a reverse route for every packet in a flow.
In this scenario, the ServerIron 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 ServerIron 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 ServerIron 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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
155
2
Miscellaneous options
Enabling use of the client MAC address
By default, the ServerIron 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. This default works well in some
configurations but can cause difficulties in configurations where there are multiple VLANs and
multiple instances of VRRP running in each VLAN on upstream routers.
You can enable use of the client MAC address instead of the default gateway address, by entering
the following command.
ServerIronADX(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 ServerIron ADX to transparently load balance a VIP,
without owning the VIP address. Multiple ServerIron ADXs on which this virtual server is configured
to be transparent can load balance requests for the server. For examples and configuration
information, refer to Chapter 3, “Stateless Server Load Balancing”.
To configure an individual virtual server for the transparent VIP feature, enter a command such as
the following.
ServerIronADX(config-vs-TransVIP)#transparent-vip
Syntax: [no] transparent-vip
Enabling SYN ACK threshold
The SYN ACK threshold specifies the number of contiguous unacknowledged TCP SYN ACKs the
ServerIron 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 279.
Syntax: server reassign-threshold number
The number variable is the threshold. Enter a number from 6 to 4000. If you do not specify a
number, the ServerIron 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 ServerIron ADX MAC address.
ServerIronADX(config)#server source-mac-replacement
Syntax: [no] server source-mac-replacement
156
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous options
2
Cloning real servers
To simplify configuration for large server farms, you can clone real servers. When you clone a real
server, you make a copy of the real server’s configuration information under a new name. The copy
includes the port bindings to the virtual server.
To clone a real server, enter commands such as the following.
ServerIronADX(config)#server real rs1 10.2.3.4
ServerIronADX(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.
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 ServerIron 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 500 contiguous VIPs, enter commands such as the following.
ServerIronADX(config)#server real-name r1 10.4.4.4
ServerIronADX(config-rs-r1)#host-range 500
ServerIronADX(config-rs-r1)#exit
ServerIronADX(config)#server real-name r2 10.4.4.5
ServerIronADX(config-rs-r2)#host-range 500
ServerIronADX(config-rs-r2)#exit
ServerIronADX(config)#server virtual-name-or-ip lotsofhosts 10.157.22.99
ServerIronADX(config-vs-lotsofhosts)#host-range 500
ServerIronADX(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. For a complete
configuration example, refer to “TCP/UDP application groups” on page 531.
To configure a host range on a real server.
ServerIronADX(config)#server real-name r1 10.0.0.1
ServerIronADX(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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
157
2
Miscellaneous options
Syntax: [no] host-range num
Configuring IPv6 host-range
The host-range capability enables the administrator to define a range of servers having contiguous
IPv6 addresses.
NOTE
While binding host-range between virtual servers and real servers, one must use identical
host-range size.
NOTE
Binding of a virtual server having host-range with a real server without having host-range is
permitted.
To configure host-range for both Virtual and Real IPv6 servers, use the following commands.
ADX
ADX
ADX
ADX
1000(config)#server real v6_real 2001:DB8::345:250
1000(config-rs-v6_real)#host-range 4
1000(config-rs-v6_real)#port http
1000(config-rs-v6_real)#exit
ADX
ADX
ADX
ADX
1000(config)#server virtual v6_virtual 2001:DB8::345:1000
1000(config-vs-v6_virtual)#host-range 4
1000(config-vs-v6_virtual)#port http
1000(config-vs-v6_virtual)#bind http v6_real http
Syntax: [no] host-range num
The num variable identifies the host-range. The value ranges from 1 through 4096 for both real
and virtual servers.
NOTE
The IPv6 host-range may not be combined with features such as stateless SLB, IPv6 translation
(SLB664 and SLB446), TCP Syn-Proxy and VIP protection.
Unbinding all application ports from virtual servers
By default, a real server’s 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’s application ports, enter the following command at the configuration level
for the server.
ServerIronADX(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.
158
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous options
2
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:
• Allow "TCP only" or "UDP only" port definitions under virtual server
• Allow similar definitions under real server also
On ServerIron 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 ServerIron 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
Syntax: [no] port port 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 ServerIron ADX to add
an entry to its session table; when a response is detected, the ServerIron 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 “Enabling normal UDP aging for DNS and RADIUS”
on page 160.
When this feature is configured, if the ServerIron 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 ServerIron 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.
ServerIronADX(config)#server virtual-name-or-ip vs1 192.168.1.2
ServerIronADX(config-vs-vs1)#port 1234 udp-fast-age
Syntax: port UDP-portnum udp-fast-age
ServerIron ADX Server Load Balancing Guide
53-1003452-01
159
2
Miscellaneous options
To set the amount of time sessions for ports configured with the udp-fast-age keyword that stays in
the delete queue before being deleted, enter the following command.
ServerIronADX(config)#server msl 2
Syntax: server msl secs
The secs variable can be from 1–40 seconds.
Enabling normal UDP aging for DNS and RADIUS
By default, the ServerIron ADX immediately deletes a UDP DNS or RADIUS session table entry when
the ServerIron ADX receives a reply for the application from a real server. You can configure the
ServerIron 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.
ServerIronADX(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 ServerIron 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 keyword
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 ServerIron 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.
ServerIronADX(config)#server virtual-name-or-ip v1
ServerIronADX(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.
ServerIronADX(config)#server virtual-name-or-ip v1
ServerIronADX(config-vs-v1)#udp-age 26
Syntax: [no] udp-age minutes
160
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous options
2
To set the TCP age for the HTTP port on virtual server v1 to 10 minutes, enter the following
commands.
ServerIronADX(config)#server virtual-name-or-ip v1
ServerIronADX(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.
ServerIronADX(config)#server virtual-name-or-ip v1
ServerIronADX(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 ServerIron ADX. Two
sessions are created for each flow: “foreward” 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,
ServerIronADX(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.
ServerIronADX(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 ServerIron ADX to reject new DNS UDP and TCP SSL
requests when CPU utilization goes beyond a configured threshold.
You can set CPU-based throttling for DNS UDP and TCP SSL traffic as shown.
ServerIronADX(config)#server throttle-on-overload 40
Syntax: [no] server throttle-on-overload cpu-percentage
ServerIron ADX Server Load Balancing Guide
53-1003452-01
161
2
Miscellaneous options
The cpu-percentage specifies the threshold of CPU utilization when the ServerIron ADX will reject
new DNS UDP and TCP SSL requests.
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 ServerIron 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 ServerIron 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 ServerIron 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.
ServerIronADX(config)#server dns-udp-count-connection
Syntax: [no] server dns-udp-count-connection
Maximum server, port, and health check count
Table 10 and Table 11 shows the minimum, maximum and default number of supported real
servers, virtual servers and ports on the ServerIron system.
NOTE
The maximum number of ports with L47 health checks enabled might be lower.
TABLE 10
Port type
Default
Minimum
Maximum
Real Server
4096
64
16384
Virtual Server
1024
64
4096
Server Ports
8192
256
32768
TABLE 11
162
Number of supported real servers, virtual servers, and ports on a ServerIron ADX4000, ServerIron
ADX8000 and ServerIron ADX10000
Number of supported real servers, virtual servers, and ports on a ServerIron ADX1000
Port type
Default
Minimum
Maximum
Real Server
1024
64
4096
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous options
TABLE 11
2
Number of supported real servers, virtual servers, and ports on a ServerIron ADX1000 (Continued)
Port type
Default
Minimum
Maximum
Virtual Server
256
64
1024
Server Ports
2048
256
8192
NOTE
The implicit default port under virtual and real servers are included in the port count.
Policy-based routing for reverse SLB traffic
Policy-based routing (PBR) is supported for reverse SLB traffic on the ServerIron ADX. Policy-based
routing routes traffic based on policies you define. A PBR policy specifies the next hop for traffic
that matches the policy.
To configure PBR, define the policies using IP ACLs and route maps, then enable PBR globally or on
individual interfaces. The device routes traffic that matches the ACLs, according to the instructions
in the route maps.
In a network where clients belonging to different subnet and VLANs are sending traffic to VIPs
belonging to their respective subnet, you can configure PBR to send return traffic back to each
client the way it came, rather than having all the traffic use the default route. To do this, you can
configure ACLs and route maps and apply them either globally or to individual interfaces.
In the following example below, clients belonging to subnets 172.16.0.0/16 and 172.17.0.0/16 are
accessing VIP 192.168.10.1 via Router B, while all other clients access the VIP via Router A. The
next-hop router for 172.16.0.0/16 and 172.17.0.0/16 is 192.168.2.254, while the default route is
used for all other clients.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
163
2
Miscellaneous options
To redirect the return traffic to some specified clients, you can configure the ACL and route map in
either of the following ways:
1. Specify clients subnet address as the destination address in the ACL statement.
ServerIronADX(config)#access-list 101 permit ip any 172.16.0.0 0.0.255.255
ServerIronADX(config)#access-list 101 permit ip any 172.17.0.0 0.0.255.255
ServerIronADX(config)#route-map test-route permit 10
ServerIronADX(config-route-map test-route)#match ip address 101
ServerIronADX(config-route-map test-route)#set ip next-hop 192.168.2.254
ServerIronADX(config-route-map test-route)#exit
ServerIronADX(config)#ip policy route-map test-route
2. Specify VIP host IP address (or IP address range that the VIP belongs) as the source IP address
in the ACL statement.
ServerIronADX(config)#access-list 101 permit ip host 172.168.10.1 any
ServerIronADX(config)#route-map test-route permit 10
ServerIronADX(config-route-map test-route)#match ip address 101
ServerIronADX(config-route-map test-route)#set ip next-hop 192.168.2.254
ServerIronADX(config-route-map test-route)#exit
ServerIronADX(config)#ip policy route-map test-route
Policy-Based Routing (PBR) is handled by Application Cores (also called “Barrel Processors” or
BPs), hence PBR can only normally operate on traffic defined within a “server” function.
In cases where PBR is necessary for non-SLB IP traffic, there are two options available. Use one of
these options and then apply PBR policies normally:
1. Define real server or remote server with the IP addresses in question, so that reverse traffic
will be forwarded to the BPs. Thus the CAM entries for these real/remote entries will forward
traffic to the BPs for processing.
2. Configure “server cpu-forward” globally so that all traffic will be forwarded to the BP. A
“catch-all CAM entry (similar to that used by FWLB) will be created to force all traffic through
the BPs.
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. It is provided as a less cumbersome alternative to the procedure described in “Policy-based
routing for reverse SLB traffic” on page 163. This feature is only available for a ServerIron ADX
running router code.
To configure a virtual server with a next hop gateway use the command shown in the following.
ServerIronADX(config)#server virtual-name-or-ip v1 10.1.1.1
ServerIronADX(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 ServerIron
ADX.
164
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous options
2
You can also configure the virtual server to allow it to fall back to its default gateway as shown in
the following.
ServerIronADX(config)#server virtual-name-or-ip v1 10.1.1.1
ServerIronADX(config-vs-v1)#next-hop-allow-fallback-to-default-gateway
Syntax: [no] next-hop-allow-fallback-to-default-gateway
Dynamic NAT for real servers using virtual server address
A ServerIron ADX can use a virtual server address as a dynamic NAT address for real servers. This
feature enables the use of virtual server IP addresses for outbound connections from real servers.
VIP route health injection
VIP route health injection (RHI) allows the ServerIron ADX to advertise the availability of an IPv4 or
IPv6 VIP address (instead of a real host) throughout the network. Multiple ServerIrons with identical
VIP addresses and services can exist throughout the network. This feature allows the ServerIron
ADX VIP to be used in lieu of the same VIP on other ServerIrons 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 ServerIrons.
Specifically, you can configure a ServerIron 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 ServerIron ADX injects a VIP route into its route table for
the VIP. The ServerIron ADX then advertises the route to other routers using an IGP routing
protocol, such as OSPF or OSFPv3.
• VIP is not healthy. The ServerIron 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 ServerIron ADX will keep advertising the VIP host route.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
165
2
Miscellaneous options
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 ServerIron ADX will check if the real server port is bound to a
VIP port whose VIP has the RHI feature enabled. If so, the ServerIron 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
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 ServerIron 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 ServerIron ADX will delete the VIP route.
Similarly, when a real server port transitions from the failed to the active state, the ServerIron 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 ServerIron 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 ServerIron ADX will declare this VIP port healthy. If you have not configured a
threshold, then the ServerIron 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 ServerIron ADX will check if
all other VIP ports are healthy. If they are, the ServerIron 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:
ServerIronADX(config)#router ospf
ServerIronADX(config-ospf-router)#area 0
ServerIronADX(config-ospf-router)#redistribution static
Syntax: [no] redistribution static
To enable redistribution of static routes for IPv6, enter commands such as the following:
ServerIronADX(config)#ipv6 router ospf
ServerIronADX(config-ospf6-router)#redistribute static
Syntax: [no] redistribute static
166
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous options
2
• Disabling network route advertisement for an interface associated with VIP RHI — The ip
dont-advertise or ipv6 dont-advertise commands configure the ServerIron ADX to block
advertisement of the network on the interface. If you do not block advertisement of the
network, the ServerIron 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 ServerIron ADX
advertises only a host route to the VIP address. Therefore, if the VIP is not healthy, the
ServerIron 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.
ServerIronADX(config)#interface ethernet 4/15
ServerIronADX(config-if-4/15)#ip address 10.1.1.99 255.255.255.0
ServerIronADX(config-if-4/15)#ip dont-advertise 10.1.1.99 255.255.255.0
Syntax: ip dont-advertise ip-addr mask I ip-addr/mask-bits
For IPv6enter commands similar to the following.
ServerIronADX(config)#interface loopback 1
ServerIronADX(config-lbif-1)#ipv6 address 2001:db8::1/64
ServerIronADX(config-if-3/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)”.
ServerIronADX-A(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
ServerIron ADX Server Load Balancing Guide
53-1003452-01
167
2
Miscellaneous options
• 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 172).
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:
ServerIronADX1000(config)#interface loopback 2
ServerIronADX1000(config-lbif-2)#ip address 10.1.152.67/28
ServerIronADX1000(config-lbif-2)#ip dont-advertise 10.1.152.67/28
Enabling or disabling VIP RHI
The ServerIron 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.
ServerIronADX(config)#server global-advertise-vip-route v4-only
To enable VIP RHI feature globally for all IPv6 VIPs, enter commands such as the following.
ServerIronADX(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.
NOTE
Where VIP hosts are classified as healthy, the ServerIron 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.
ServerIronADX(config)#server virtual-name-or-ip vs1
ServerIronADX(config-vs-vs1#advertise-vip-route
Syntax: [no] advertise-vip-route
168
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous options
2
NOTE
Where VIP hosts are classified as healthy, the ServerIron 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.
ServerIronADX(config)#server virtual-name-or-ip vs1
ServerIronADX(config-vs-vs1#disable-advertise-vip-route
ServerIronADX(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.
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.
ServerIronADX(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.
ServerIronADX(config)#server virtual-name-or-ip dns-p1
ServerIronADX(config-vs-dns-p1)#rhi-active-bindings-threshold 30
NOTE
The VIP level configuration applies to all Virtual ports on the configured virtual server.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
169
2
Miscellaneous options
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.
ServerIronADX(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.
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.
ServerIronADXA(config)#server virtual-name-or-ip dns-p1
ServerIronADXA(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.
ServerIronADX(config)#server virtual-name-or-ip vs1
ServerIronADX(config-vs-dns-p1)#port ftp rhi-dont-use-port
170
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous options
2
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.
ServerIronADX(config)#server virt virt-2
ServerIronADX(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.
ServerIronADX(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
2001:DB8::10
loopback 1 1/1
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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
171
2
Miscellaneous options
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 ServerIron 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.
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
ServerIronADX#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
1
10.1.1.0
255.255.255.0 10.1.1.105
1b1
1
S
ServerIronADX#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
172
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous options
2
Example of dangling VIPs
ServerIronADX#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
ServerIronADX#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.
VIP RHI and high availability topologies
• Hot Standby topology - VIP RHI is only supported on the ServerIron 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 ServerIron
will withdraw the VIP route when a VIP transitions from Active to standby state. Similarly, the
ServerIron 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 ServerIron 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 ServerIrons to
inject VIP route regardless of its ownership.
ServerIronADX(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 ServerIron 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 ServerIron ADX shows the route's type as
“D(N).”
ServerIron ADX Server Load Balancing Guide
53-1003452-01
173
2
Miscellaneous options
The following output of the show ip route command is from a ServerIron ADX with VIP RHI enabled.
.
ServerIronADX#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
Type
D
O
D
D(N)
D(N)
S
D(N)
S
O
D(N)
S
The following snap shot of the show ipv6 route command was taken from a ServerIron ADX with VIP
RHI enabled.
ServerIronADX(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 an ServerIron ADX (router) is usually shown as
"D:connected" and a manually added static route type is to be shown as “S:Static.”
174
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous options
2
Configuration examples
Both ServerIron ADX sites working in primary mode
Figure 22 shows both the ServerIron ADXs working in the primary mode.
FIGURE 22
Primary mode
Site 1 configuration
ver 09.3.00b265TD4
!
module 1 bi-0-port-wsm2-management-module
module 2 bi-jc-8-port-gig-module
module 3 bi-jc-16-port-gig-copper-module
module 4 bi-jc-16-port-gig-copper-module
!
ServerIron ADX Server Load Balancing Guide
53-1003452-01
175
2
Miscellaneous options
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
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 remote-name test 10.30.1.40
source-nat
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
!
176
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous options
2
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
!
server real wr1 10.50.1.40
port http
port http url "HEAD /"
!
server real wr2 10.50.1.41
port http
port http url "HEAD /"
!
server real wr3 10.50.1.42
port http
port http url "HEAD /"
!
server real wr4 10.50.1.43
port http
port http url "HEAD /"
!
server real wr5 10.50.1.44
port http
port http url "HEAD /"
!
server real wr6 10.50.1.45
port http
port http url "HEAD /"
!
server real wr7 10.50.1.46
port http
port http url "HEAD /"
!
server real wr8 10.50.1.47
port http
port http url "HEAD /"
!
server real wr9 10.50.1.48
ServerIron ADX Server Load Balancing Guide
53-1003452-01
177
2
Miscellaneous options
port http
port http url "HEAD /"
!
server real wr10 10.50.1.49
port http
port http url "HEAD /"
!
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 vip50 10.50.1.10
port http
bind http wr1 http wr2 http wr3 http wr4 http
bind http wr5 http wr6 http wr7 http wr8 http
bind http wr9 http wr10 http
!
server virtual-name-or-ip vip70 10.70.1.10
port http
port smtp
port ftp
port dns
port snmp
port mms
port rtsp
bind http test http
bind smtp test smtp
bind ftp test ftp
bind dns test dns
bind snmp test snmp
bind mms test mms
bind rtsp test rtsp
!
server virtual-name-or-ip vip90 10.90.1.10
vip-route-subnet-mask-length 28
178
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous options
port
port
port
port
bind
bind
bind
bind
2
dns
snmp
http
ftp
dns rem1 dns rem2 dns
snmp rem1 snmp rem2 snmp
http rem1 8601 rem2 8601
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 2/1 to 2/4
router-interface ve 1
!
vlan 20 by port
untagged ethe 4/1 to 4/16
router-interface ve 2
!
vlan 30 by port
tagged ethe 2/5
untagged ethe 2/8
router-interface ve 3
!
vlan 40 by port
tagged ethe 2/5
untagged ethe 2/6 to 2/7
router-interface ve 4
!
!
hostname Site1-SI
logging buffered 1000
mirror ethernet 4/12
!
server session-debug 100000
auto-cam-repaint
pram-write-retry
!
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
!
ServerIron ADX Server Load Balancing Guide
53-1003452-01
179
2
Miscellaneous options
interface ethernet 2/1
mon ethe 4/12 input
mon ethe 4/12 output
!
interface ethernet 2/2
mon ethe 4/12 input
mon ethe 4/12 output
!
interface ethernet 2/5
mon ethe 4/12 input
mon ethe 4/12 output
!
interface ethernet 3/12
ip address 10.70.1.120 255.255.255.0
ip dont-advertise 10.70.1.120 255.255.255.0
ip address 10.90.1.120 255.255.255.0
ip dont-advertise 10.90.1.120 255.255.255.0
!
interface ethernet 4/1
mon ethe 4/12 input
mon ethe 4/12 output
!
interface ethernet 4/2
mon ethe 4/12 input
mon ethe 4/12 output
!
interface ethernet 4/16
mon ethe 4/12 input
mon ethe 4/12 output
!
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
!
interface ve 4
ip address 10.50.1.120 255.255.255.0
ip dont-advertise 10.50.1.120 255.255.255.0
ip address 10.50.1.121 255.255.255.0 secondary
ip dont-advertise 10.50.1.121 255.255.255.0
!
!
end
180
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous options
2
Site 2 configuration
module 1 bi-0-port-wsm2-management-module
module 2 bi-jc-8-port-gig-module
module 3 bi-jc-16-port-gig-copper-module
module 4 bi-jc-16-port-gig-copper-module
!
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
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.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
!
ServerIron ADX Server Load Balancing Guide
53-1003452-01
181
2
Miscellaneous options
server remote-name test 10.130.1.40
source-nat
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
!
server real wr1 10.50.1.40
port http
port http url "HEAD /"
!
server real wr2 10.50.1.41
port http
port http url "HEAD /"
!
server real wr3 10.50.1.42
port http
port http url "HEAD /"
!
server real wr4 10.50.1.43
port http
port http url "HEAD /"
!
server real wr5 10.50.1.44
port http
182
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous options
2
port http url "HEAD /"
!
server real wr6 10.50.1.45
port http
port http url "HEAD /"
!
server real wr7 10.50.1.46
port http
port http url "HEAD /"
!
server real wr8 10.50.1.47
port http
port http url "HEAD /"
!
server real wr9 10.50.1.48
port http
port http url "HEAD /"
!
server real wr10 10.50.1.49
port http
port http url "HEAD /"
!
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 vip50 10.50.1.10
port http
bind http wr1 http wr2 http wr3 http wr4 http
bind http wr5 http wr6 http wr7 http wr8 http
bind http wr9 http wr10 http
!
server virtual-name-or-ip vip70 10.70.1.10
port http
port smtp
ServerIron ADX Server Load Balancing Guide
53-1003452-01
183
2
Miscellaneous options
port
port
port
port
port
bind
bind
bind
bind
bind
bind
bind
ftp
dns
snmp
mms
rtsp
http test http
smtp test smtp
ftp test ftp
dns test dns
snmp test snmp
mms test mms
rtsp test rtsp
!
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
!
!
vlan 1 name DEFAULT-VLAN by port
!
vlan 10 by port
untagged ethe 2/1 to 2/4
router-interface ve 1
!
vlan 20 by port
untagged ethe 4/1 to 4/16
router-interface ve 2
!
vlan 30 by port
tagged ethe 2/5
untagged ethe 2/8
router-interface ve 3
!
vlan 40 by port
tagged ethe 2/5
untagged ethe 2/6 to 2/7
router-interface ve 4
!
!
hostname Site2-SI
logging buffered 1000
mirror ethernet 4/12
184
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous options
2
!
server session-debug 100000
auto-cam-repaint
pram-write-retry
!
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 ethernet 2/1
mon ethe 4/12 input
mon ethe 4/12 output
!
interface ethernet 2/2
mon ethe 4/12 input
mon ethe 4/12 output
!
interface ethernet 2/5
mon ethe 4/12 input
mon ethe 4/12 output
!
interface ethernet 3/12
ip address 10.70.1.120 255.255.255.0
ip dont-advertise 10.70.1.120 255.255.255.0
ip address 10.90.1.120 255.255.255.0
ip dont-advertise 10.90.1.120 255.255.255.0
!
interface ethernet 4/1
mon ethe 4/12 input
mon ethe 4/12 output
!
interface ethernet 4/2
mon ethe 4/12 input
mon ethe 4/12 output
!
interface ethernet 4/16
mon ethe 4/12 input
mon ethe 4/12 output
!
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
ServerIron ADX Server Load Balancing Guide
53-1003452-01
185
2
Miscellaneous options
!
interface ve 4
ip address 10.50.1.120 255.255.255.0
ip dont-advertise 10.50.1.120 255.255.255.0
ip address 10.50.1.121 255.255.255.0 secondary
ip dont-advertise 10.50.1.121 255.255.255.0
!
end
Site 1 ServerIron ADX in primary mode and Site 2 in backup mode
Figure 23 shows the Site 1 where the ServerIron ADX is in primary mode and in the Site 2 where
the ServerIron ADX is in the backup mode.
FIGURE 23
186
Primary mode and backup mode
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous options
2
Site 1 configuration
The following configuration is only for virtual server vip60 (10.60.1.10).
!
ver 09.3.00b269TD4
!
module 1 bi-0-port-wsm2-management-module
module 2 bi-jc-8-port-gig-module
module 3 bi-jc-16-port-gig-copper-module
module 4 bi-jc-16-port-gig-copper-module
!
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
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
ServerIron ADX Server Load Balancing Guide
53-1003452-01
187
2
Miscellaneous options
port rtsp
!
server remote-name test 10.30.1.40
source-nat
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
!
server real wr1 10.50.1.40
port http
port http url "HEAD /"
!
server real wr2 10.50.1.41
port http
port http url "HEAD /"
!
server real wr3 10.50.1.42
port http
port http url "HEAD /"
!
server real wr4 10.50.1.43
port http
port http url "HEAD /"
!
188
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous options
2
server real wr5 10.50.1.44
port http
port http url "HEAD /"
!
server real wr6 10.50.1.45
port http
port http url "HEAD /"
!
server real wr7 10.50.1.46
port http
port http url "HEAD /"
!
server real wr8 10.50.1.47
port http
port http url "HEAD /"
!
server real wr9 10.50.1.48
port http
port http url "HEAD /"
!
server real wr10 10.50.1.49
port http
port http url "HEAD /"
!
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 vip50 10.50.1.10
port http
bind http wr1 http wr2 http wr3 http wr4 http
bind http wr5 http wr6 http wr7 http wr8 http
bind http wr9 http wr10 http
!
server virtual-name-or-ip vip70 10.70.1.10
ServerIron ADX Server Load Balancing Guide
53-1003452-01
189
2
Miscellaneous options
port
port
port
port
port
port
port
bind
bind
bind
bind
bind
bind
bind
http
smtp
ftp
dns
snmp
mms
rtsp
http test http
smtp test smtp
ftp test ftp
dns test dns
snmp test snmp
mms test mms
rtsp test rtsp
!
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 2/1 to 2/4
router-interface ve 1
!
vlan 20 by port
untagged ethe 4/1 to 4/16
router-interface ve 2
!
vlan 30 by port
tagged ethe 2/5
untagged ethe 2/8
router-interface ve 3
!
vlan 40 by port
tagged ethe 2/5
untagged ethe 2/6 to 2/7
router-interface ve 4
!
!
hostname Site1-SI
logging buffered 1000
190
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous options
2
mirror ethernet 4/12
!
server session-debug 100000
auto-cam-repaint
pram-write-retry
!
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 ethernet 2/1
mon ethe 4/12 input
mon ethe 4/12 output
!
interface ethernet 2/2
mon ethe 4/12 input
mon ethe 4/12 output
!
interface ethernet 2/5
mon ethe 4/12 input
mon ethe 4/12 output
!
interface ethernet 3/12
ip address 10.70.1.120 255.255.255.0
ip dont-advertise 10.70.1.120 255.255.255.0
ip address 10.90.1.120 255.255.255.0
ip dont-advertise 10.90.1.120 255.255.255.0
!
interface ethernet 4/1
mon ethe 4/12 input
mon ethe 4/12 output
!
interface ethernet 4/2
mon ethe 4/12 input
mon ethe 4/12 output
!
interface ethernet 4/16
mon ethe 4/12 input
mon ethe 4/12 output
!
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
ServerIron ADX Server Load Balancing Guide
53-1003452-01
191
2
Miscellaneous options
ip dont-advertise 10.60.1.121 255.255.255.0
!
interface ve 4
ip address 10.50.1.120 255.255.255.0
ip dont-advertise 10.50.1.120 255.255.255.0
ip address 10.50.1.121 255.255.255.0 secondary
ip dont-advertise 10.50.1.121 255.255.255.0
!
end
Site 2 configuration
!
ver 09.3.00b269TD4
!
module 1 bi-0-port-wsm2-management-module
module 2 bi-jc-8-port-gig-module
module 3 bi-jc-16-port-gig-copper-module
module 4 bi-jc-16-port-gig-copper-module
!
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
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
192
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous options
2
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
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
ServerIron ADX Server Load Balancing Guide
53-1003452-01
193
2
Miscellaneous options
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 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.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
!
194
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous options
2
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 remote-name test 10.130.1.40
source-nat
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
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
ServerIron ADX Server Load Balancing Guide
53-1003452-01
195
2
Miscellaneous options
port 8601
port 8601 healthck Web10-chk
!
server real wr1 10.50.1.40
port http
port http url "HEAD /"
!
server real wr2 10.50.1.41
port http
port http url "HEAD /"
!
server real wr3 10.50.1.42
port http
port http url "HEAD /"
!
server real wr4 10.50.1.43
port http
port http url "HEAD /"
!
server real wr5 10.50.1.44
port http
port http url "HEAD /"
!
server real wr6 10.50.1.45
port http
port http url "HEAD /"
!
server real wr7 10.50.1.46
port http
port http url "HEAD /"
!
server real wr8 10.50.1.47
port http
port http url "HEAD /"
!
server real wr9 10.50.1.48
port http
port http url "HEAD /"
!
server real wr10 10.50.1.49
port http
port http url "HEAD /"
!
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
196
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous options
port
port
port
port
2
dns zone "example9.com"
snmp
mms
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 vip50 10.50.1.10
port http
bind http wr1 http wr2 http wr3 http wr4 http
bind http wr5 http wr6 http wr7 http wr8 http
bind http wr9 http wr10 http
!
server virtual-name-or-ip vip70 10.70.1.10
port http
port smtp
port ftp
port dns
port snmp
port mms
port rtsp
bind http test http
bind smtp test smtp
bind ftp test ftp
bind dns test dns
bind snmp test snmp
bind mms test mms
bind rtsp test rtsp
!
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
!
!
vlan 1 name DEFAULT-VLAN by port
!
vlan 10 by port
ServerIron ADX Server Load Balancing Guide
53-1003452-01
197
2
Miscellaneous options
untagged ethe 2/1 to 2/4
router-interface ve 1
!
vlan 20 by port
untagged ethe 4/1 to 4/16
router-interface ve 2
!
vlan 30 by port
tagged ethe 2/5
untagged ethe 2/8
router-interface ve 3
!
vlan 40 by port
tagged ethe 2/5
untagged ethe 2/6 to 2/7
router-interface ve 4
!
!
hostname Site2-SI
logging buffered 1000
mirror ethernet 4/12
!
server session-debug 100000
auto-cam-repaint
pram-write-retry
!
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 ethernet 2/1
mon ethe 4/12 input
mon ethe 4/12 output
!
interface ethernet 2/2
mon ethe 4/12 input
mon ethe 4/12 output
!
interface ethernet 2/5
mon ethe 4/12 input
mon ethe 4/12 output
!
interface ethernet 3/12
ip address 10.70.1.120 255.255.255.0
ip dont-advertise 10.70.1.120 255.255.255.0
ip address 10.90.1.120 255.255.255.0
ip dont-advertise 10.90.1.120 255.255.255.0
!
interface ethernet 4/1
mon ethe 4/12 input
mon ethe 4/12 output
!
interface ethernet 4/2
mon ethe 4/12 input
198
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Application-specific SLB considerations
2
mon ethe 4/12 output
!
interface ethernet 4/16
mon ethe 4/12 input
mon ethe 4/12 output
!
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
!
interface ve 4
ip address 10.50.1.120 255.255.255.0
ip dont-advertise 10.50.1.120 255.255.255.0
ip address 10.50.1.121 255.255.255.0 secondary
ip dont-advertise 10.50.1.121 255.255.255.0
!
end
Application-specific SLB considerations
RTSP server Load Balancing
The ServerIron ADX natively understands protocol RTSP and provides load balancing for it. The
ServerIron ADX can also provide Layer 7 health checks for RTSP. Refer to “RTSP” on page 229 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.
ServerIronADX(config)#server rtsp-for-unknown-port
Syntax: [no] server rtsp-for-unknown-port
NOTE
The ServerIron 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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
199
2
Show and debug commands
Deletion of UDP data session along with TCP control session
for RTSP
The ServerIron 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.
ServerIronADX(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 ServerIron 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 ServerIron 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 ServerIron ADX sends out a request for the SIcheck.txt file.
The ServerIron ADX does not actually interpret the reply packet. As long as it does not get an "ICMP
dest or port unreachable" message, the ServerIron keeps the TFTP port up. If it gets an "ICMP
unreachable" message, the ServerIron ADX brings the TFTP port down.
Show and debug commands
Refer to Appendix C, “SLB Show and Debug Commands” for a full list of show and debug
commands.
SLB configuration examples
Refer to Appendix D, “SLB Configuration Examples” for a full list of configuration examples.
200
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Displaying the BP distribution
2
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 type-of-traffic variable values are listed below.
all
Specifies the Catch-ALL entry due to Dynamic-NAT, FWLB, cpu-forward
cache-vip
Specifies the Cache-VIP entry
frag
Specifies the Fragmentation entry
fwlb
Specifies the FWLB 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)
syn-def
Specifies the Syn-Def entry
syn-proxy
Specifies the Syn-Proxy entry
tcs
Specifies the TCS entry
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).
ServerIronADX(config)#show bp-distribution source-ip
2048 0 Packets for the specified flow map to: BP 1/1
10.1.1.1
10.5.5.5
80
It displays which barrel processor the particular flow is landing on. The command takes IP
addresses in either IPv4 or IPv6 format.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
201
2
Windows Terminal Server with L7 persistence
Windows Terminal Server with L7 persistence
Windows Terminal Server load balancing with persistence allows you to reconnect when
disconnected from an already established connection to the session directory on the Windows
2003 terminal server.
This section contains the following sections:
• “Understanding windows terminal server” on page 202
• “Configuring Windows Terminal Server” on page 204
Understanding windows terminal server
In a load balancing environment, the load balancer needs to be aware of the protocol to redirect
the session to the right server.
Figure 24 shows how Windows Terminal Server load balancing with persistence works in the case
of a new session.
FIGURE 24
New session scenario
When the new connection is made, the ServerIron ADX load balances it to one of the bound
terminal servers. R2 in the example above.
On receiving the client logon, R2 checks with the session directory to see if the username exists in
its database. Because this user had not previously established a session, the logon is established
with R2.
R2 forwards a token to the user with the server IP address. The client now connects to the virtual
server (VIP), and includes the token.
The ServerIron ADX inspects this token and then establishes a connection with the server that the
token identifies.
202
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Windows Terminal Server with L7 persistence
2
Figure 25 shows how Windows Terminal Server load balancing with persistence works in the case
of a disconnected session.
FIGURE 25
Disconnected session scenario
The ServerIron ADX load balances the initial connection to one of its bound servers.
When the user logs on, the terminal server that receives this request, checks with the session
directory to see if there is an established session in its database. The session directory
communicates the same information to the terminal server.
Because the user has an established session with another server, the terminal server forwards a
token to the user with the IP address of the server that it had disconnected from or had a failed
session.
The user now connects to the VIP and uses the token with the server IP to which it needs to be
connected.
After inspecting the token, the ServerIron ADX directs the server to the IP in the token rather than
load balancing the request.
NOTE
This IP port should be one of the servers bound to the VIP. Otherwise, the ServerIron ADX does not
direct the request.
NOTE
The IP address redirection feature on the terminal server session directory needs to be turned OFF
for Windows Terminal Server to work. If IP address redirection is ON, the client tries to establish the
session with the server directly after receiving the token. Only with Windows Terminal Server OFF, is
a routing token for redirection used. The client connects to the VIP of SI and uses the token for
redirection.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
203
2
Windows Terminal Server with L7 persistence
Configuring Windows Terminal Server
Windows Terminal Server is not enabled by default. The following example shows how to configure
Windows Terminal Server.
ServerIron(config)#server virtual-name-or-ip VIP-001 10.10.1.103
ServerIron(config-vs-VIP-001)#port 3389 win-term-serv
Syntax: server virtual-name-or-ip [name] ip-address
Syntax: port num win-term-serv
204
ServerIron ADX Server Load Balancing Guide
53-1003452-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 ServerIron ADX
and clients or real servers.
These configuration options are useful if you want to deploy multiple ServerIron ADXs to provide
service for the same VIPs or applications, but the network topology cannot ensure that server
responses will pass back through the ServerIron ADX.
NOTE
The Direct Server Return (DSR) feature allows you to deploy a single ServerIron ADX in a network
where the server responses do not pass back through the ServerIron ADX. Compare the
configuration example for SwitchBack 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 84.
NOTE
The ServerIron 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
ServerIron 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 ServerIron ADX and real servers can be connected through a network that
provides multiple return paths to the client. Because the port is stateless, the ServerIron ADX
does not assume that the application is unhealthy if the server’s response does not flow back
through the ServerIron ADX.
• The ServerIron ADX has more session resources available for application ports that need them.
For example, if your server farm provides non-secure web content in addition to secured
transaction processing using SSL, you can use the ServerIron ADX to maintain state
information for the SSL connections while allowing the HTTP (web) connections to be stateless.
The SSL connections flow back through the ServerIron ADX, but the HTTP connections use any
available path as determined by a real server’s gateway and other routes back to the client.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
205
3
Stateless TCP and UDP ports
NOTE
The SwitchBack feature also allows server responses to take paths that do not pass back through
the ServerIron ADX. However, SwitchBack still uses session table resources because the ServerIron
ADX creates a session table entry for the connection from the client to the real server.
NOTE
The ServerIron 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 ServerIron ADX automatically replaces the source IP address to a VIP. When you
configure port translation, the ServerIron ADX overcomes the limitation of performing NAT on all
packets initiated from the real server. NAT does not occur because the ServerIron ADX does not
match the port number.
NOTE
The ServerIron ADX supports stateless SLB for any TCP and UDP application protocols. For a TCP
application, hashing must be enabled on the ServerIron ADX. For a UDP application, you can enable
or disable hashing on the ServerIron 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 ServerIron ADX selects a real server
for a stateless port
The ServerIron ADX does not use the standard SLB load-balancing methods when selecting a real
server for a stateless application port. Instead, the ServerIron ADX uses hash values to select a real
server. The ServerIron ADX calculates the hash value for a given client request based on the
request’s source IP address and source TCP/UDP port.
The ServerIron ADX has up to 8192 hash buckets (the default is 256) and divides the number of
buckets evenly among the real servers. When the ServerIron ADX forwards a client’s request for a
stateless application port to the real server that corresponds to the calculated hash value, the
ServerIron 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 ServerIron ADX receives a request for TCP port 80 (HTTP) on VIP
(192.168.4.69) from client 10.161.1.88, the ServerIron 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:
•
•
•
•
206
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
ServerIron ADX Server Load Balancing Guide
53-1003452-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 ServerIron 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 ServerIron ADX that forwarded the request. In fact, the ServerIron ADX that
forwards the requests to the transparent VIP does not create session table entries for the requests.
Because the ServerIron ADX does not maintain state information for the requests for stateless
application ports, the ServerIron ADX does not care whether the server response for a stateless
port passes back through the ServerIron ADX on the way to the client. For a normally configured
VIP, the server’s response passes back though the ServerIron ADX. For a transparent VIP, the
response does not necessarily pass back through the ServerIron ADX.
NOTE
Because the ServerIron ADX does not create session table entries for requests to the stateless
application port, you cannot use ServerIron 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:
ServerIronADX(config)#server real R1 10.10.10.1
ServerIronADX(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.
ServerIronADX(config)#server real R1 10.10.10.1
ServerIronADX(config-rs-R1)#port http
ServerIronADX(config-rs-R1)#exit
ServerIronADX(config)#server real R2 10.10.11.1
ServerIronADX(config-rs-R2)#port http
ServerIronADX(config-rs-R2)#exit
ServerIronADX(config)#server virtual-name-or-ip StatelessHTTP 192.168.4.69
ServerIronADX(config-vs-StatelessHTTP)#port http stateless
ServerIronADX(config-vs-StatelessHTTP)#bind http R1 http
ServerIronADX(config-vs-StatelessHTTP)#bind http R2 http
Syntax: [no] port tcp/udp-portnum stateless
ServerIron ADX Server Load Balancing Guide
53-1003452-01
207
3
Stateless TCP and UDP ports
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 ServerIron 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 ServerIron ADX uses the round-robin load balancing method to select a real
server for the request. In this case, the ServerIron 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:
ServerIronADX(config)#server virtual-name-or-ip Stateless 192.168.4.69
ServerIronADX(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.
ServerIronADX(config)#server real R1 10.10.10.1
ServerIronADX(config-rs-R1)#port http
ServerIronADX(config-rs-R1)#exit
ServerIronADX(config)#server real R2 10.10.11.1
ServerIronADX(config-rs-R2)#port http
ServerIronADX(config-rs-R2)#exit
ServerIronADX(config)#server virtual-name-or-ip StatelessDNS 192.168.4.69
ServerIronADX(config-vs-StatelessDNS)#port dns stateless tcp
ServerIronADX(config-vs-StatelessDNS)#bind dns R1 dns
ServerIronADX(config-vs-StatelessDNS)#bind dns R2 dns
Syntax: [no] port tcp/udp-port [stateless [tcp | udp] [no-hash]]
The tcp/udp-port variable specifies the application port you want to make stateless.
208
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Stateless TCP and UDP ports
3
The stateless option configures the port to be stateless.
The tcp | udp option restricts stateless operation to the specified protocol (TCP or UDP).
The no-hash option disables the SLB hashing mechanism for the port (and protocol, if specified).
When hashing is disabled, the ServerIron 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:
ServerIronADX(config)#server virtual-name-or-ip StatelessDNS 192.168.4.69
ServerIronADX(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. Valid range: 0-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.
ServerIron(config)#server virtual v1 10.10.10.1
ServerIron(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.
• All packets initiated from real server will be NATed.
• One can however, have an association each for IPv6 and IPv4 address of same server to
different VIP (one V6 VIP and one v4 VIP).
• Fragmented pass-through traffic is not supported
ServerIron ADX Server Load Balancing Guide
53-1003452-01
209
3
Stateless TCP and UDP ports
• For L7 switching for a different port under the same VIP, Brocade highly recommends using
another VIP.
• Connections originating from real server ports other than the ports configured on the
ServerIron 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.
210
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Chapter
Health Checks
4
Health checks overview
The ServerIron 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 ServerIron ADX first sends an ARP request for the real server
and then sends an IP ping to the server, to verify that the ServerIron 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 ServerIron 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 ServerIron ADX sends an HTTP Layer 7 health check
to bring up the HTTP port on the real server.
The ServerIron 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
ServerIron 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 ServerIron ADX, the ServerIron ADX sends an ARP request and an IP ping to the real
server to verify that the ServerIron ADX can reach the server through the network.
The ServerIron ADX also sends an IP ping to a real server in the following circumstances:
• If the ARP entry for the server times out, the ServerIron 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 ServerIron 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 ServerIron
ADX then sends a Layer 4 or Layer 7 health check, depending on whether the port’s application
type is known to the ServerIron ADX. The ServerIron 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 213.
The following Layer 3 health check types are supported:
• ARP Request
• IP Ping
ServerIron ADX Server Load Balancing Guide
53-1003452-01
211
4
Layer 3 health checks
Table 12 summarizes the Layer 3 health checks.
TABLE 12
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 ServerIron 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 ServerIron ADX, the ServerIron ADX uses
a Layer 3 health check (IP ping) to determine the server’s reachability. If the real server responds to
the ping, the ServerIron 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 ServerIron 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 ServerIron ADX’s ARP cache.
To globally disable the Layer 3 health check for all local real servers, enter the following command.
ServerIronADX(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.
ServerIronADX(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.
ServerIronADX(config-rs-R1)#no-l3-check
Syntax: [no] no-l3-check
This command applies to local real servers and remote real servers.
212
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Layer 4 health checks
4
Modifying the ping interval and ping retries
The ServerIron 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 and cannot be disabled.
However, you can modify the ping interval and the number of retries.
To modify the ping interval, enter the following command.
ServerIronADX(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 ServerIron ADX will ping a real server before changing the server
state to FAILED, enter the following command.
ServerIronADX(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.
Server periodic-ARP enhancement
To configure the periodic ARP range, use the following command.
ServerIronADX(config)#server periodic-arp-interval 14400
Syntax: server periodic-arp-interval 10-14400
Layer 4 health checks
When you bind a real server to a virtual server, the ServerIron 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 ServerIron ADX, the ServerIron ADX uses a Layer 4 health check. Otherwise, the
ServerIron 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 ServerIron ADX checks the TCP port’s health based on a TCP three-way
handshake:
-
The ServerIron ADX sends a TCP SYN packet to the port on the real server.
The ServerIron ADX expects the real server to respond with a SYN ACK.
If the ServerIron ADX receives the SYN ACK, the ServerIron ADX sends a TCP RESET,
satisfied that the TCP port is alive.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
213
4
Layer 4 health checks
• UDP health check – The ServerIron ADX sends a UDP packet with garbage (meaningless) data
to the UDP port:
-
If the server responds with an ICMP “Port Unreachable” message, the ServerIron ADX
concludes that the port is not alive.
-
If the server does not respond at all, the ServerIron ADX assumes that the port is alive and
received the garbage data. Because UDP is a connectionless protocol, the ServerIron 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 ServerIron 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 278.
After the ServerIron ADX sends an initial packet (TCP or UDP) to the server to bring the port up, the
ServerIron ADX waits one second and then checks for a response from the server. If no response is
received during that time, the ServerIron ADX will send another packet. The time at which the
ServerIron ADX sends the second packet depends on the number of ports being brought up at that
time. The ServerIron 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 ServerIron 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
214
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Layer 4 health checks
4
Table 13 describes the Layer 4 health check types performance and its description.
TABLE 13
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 ServerIron ADX attempts to engage in a normal
three-way TCP handshake with the port on the real server:
• The ServerIron ADX sends a TCP SYN packet to the port
on the real server.
• The ServerIron ADX expects the real server to respond
with a SYN ACK.
• If the ServerIron ADX receives the SYN ACK, the
ServerIron 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 ServerIron ADX sends a UDP packet with garbage
(meaningless) data to the UDP port.
• If the server responds with an ICMP “Port Unreachable”
message, the ServerIron ADX concludes that the port is
not alive.
• If the server does not respond at all, the ServerIron ADX
assumes that the port is alive and received the garbage
data. Since UDP is a connectionless protocol, the
ServerIron 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 ServerIron 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:
ServerIronADX(config)#server port dns
ServerIronADX(config-port-dns)#udp l4-check-only
NOTE
The l4-check-only command does not apply to the RADIUS protocol.
By default, the ServerIron ADX performs a Layer 4 TCP health check whenever the DNS port on a
real server is brought up.
To configure the ServerIron 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:
ServerIronADX(config)#server port dns
ServerIronADX(config-port-dns)#no tcp keepalive enable
ServerIron ADX Server Load Balancing Guide
53-1003452-01
215
4
Layer 4 health checks
Server response threshold health check
ServerIron 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 ServerIron ADX can perform Layer 4 and Layer 7 health checks.
The ServerIron 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 ServerIron 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 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.
ServerIronADX(config)#server real r1 192.168.20.43
ServerIronADX(config-rs-r1)#port http response-threshold layer4 200
ServerIronADX(config-rs-r1)#port http response-threshold layer7 800
Syntax: [no] response-threshold {layer4|layer7|layer4&7} threshold-value in micro-seconds
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 in microseconds variable accepts an integer value range from 1 to 50000.
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
216
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Layer 4 health checks
4
To display configuration information and statistics for the real server configured on the ServerIron
ADX, enter the following command:
ServerIronADX(config)#show server real http
HTTP keepalive statistics:
HTTP statistics:
URL replace cs: test = 3, fail = 0, malloc fail = 0
GSLB HTTP get ka port = 0, GSLB get ka port = 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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
217
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 ServerIron ADX can send application-specific health
checks to determine the health of the application. For example, the ServerIron 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
ServerIron ADX, the ServerIron 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 ServerIron ADX does not
send an ICMP “Destination Unreachable” message to the client. For HTTP traffic, you can configure
the ServerIron 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 150 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 ServerIron
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:
•
•
•
•
•
•
•
•
•
•
•
218
“DNS” on page 220
“FTP” on page 221
“HTTP” on page 221
“Scripted (content verification for unknown ports)” on page 222
“IMAP4” on page 223
“LDAP” on page 223
“MMS” on page 224
“NNTP” on page 224
“PNM” on page 225
“POP3” on page 225
“RADIUS” on page 226
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Layer 7 health checks
•
•
•
•
4
“RTSP” on page 229
“SMTP” on page 229
“SSL” on page 229
“Telnet” on page 231
Application ports
The ServerIron ADX selects a Layer 4 or Layer 7 health check based on whether the application
port is known to the ServerIron 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 ServerIron
ADX. The ServerIron ADX performs Layer 7 health checks for these ports. For other ports, the
ServerIron ADX performs a Layer 4 TCP or UDP health check instead.
TCP ports include the following:
• FTP (port 21). Ports 20 and 21 both are FTP ports but on the ServerIron 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 for authentication, and 1813 for accounting)
• 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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
219
4
Layer 7 health checks
DNS
The ServerIron ADX performs one or both of the following types of DNS health checks:
• Address-based – The ServerIron 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 ServerIron ADX sends a Source-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.
For information on configuring these health checks, refer to “Configuring DNS health check method
and values” on page 234.
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 ServerIron 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 ServerIron 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 ServerIron ADX marks the DNS port
on the server FAILED and removes the server from the rotation for DNS services.
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 233.
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
ServerIronADX(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
bind dns linux dns rs1 dns
220
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Layer 7 health checks
4
!
end
NOTE
If the addr_query or zone has a “.” at the end, the ServerIron ADX will return “invalid packet” for Layer
7 DNS health check.
FTP
The ServerIron ADX waits for a message from the server:
• If the server sends a greeting message with status code 220, the ServerIron ADX resets the
connection and marks the port ACTIVE.
• If the server does not send a greeting message with status code 220, the ServerIron 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 ServerIron 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
The ServerIron ADX supports HTTP status code and content verification health check methods. For
information on configuring HTTP health checks, refer to “HTTP” on page 232.
HTTP (status code)
The ServerIron ADX sends HTTP GET or HEAD requests to cache servers (when using TCS) or 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 ServerIron ADX sends a HEAD request for the default page, “1.0”.
• If the server responds with an acceptable status code, the ServerIron ADX resets the
connection and marks the port ACTIVE. For SLB, the default acceptable status codes for the
check are 200–299 and 401. For TCS, the default acceptable status codes are 100–499.
• If the server responds with a different status code, the ServerIron ADX marks the HTTP port
FAILED.
• If the server does not respond, the ServerIron 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 ServerIron
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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
221
4
Layer 7 health checks
Performed:
• Immediately following a successful Layer 4 TCP health check
• At regular intervals, if keepalive is enabled for the port
HTTP (content verification)
The ServerIron ADX sends HTTP GET or HEAD requests to cache servers (when using TCS) or HTTP
servers (when using SLB).
The GET or HEAD request specifies a page (identified by the URL) on the server. The ServerIron 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 ServerIron 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 ServerIron 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 ServerIron ADX marks the
port FAILED.
• If the page meets none of the selection criteria, then the ServerIron ADX marks the port either
ACTIVE or FAILED according to a user-defined setting.
Refer to “Configuring HTTP content matching lists” on page 266 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 ServerIron ADX waits for the real server to send back a
packet in response.
The ServerIron ADX looks in the response packet for a user-specified ASCII string, defined in a
matching list. The ServerIron 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 ServerIron 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 ServerIron ADX
marks the port ACTIVE.
• If the text in the response meets the criteria for bringing the port down, then the ServerIron
ADX marks the port FAILED.
• If the text in the response meets none of the selection criteria, then the ServerIron 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
ServerIron 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 ServerIron ADX marks
the server port FAILED.
222
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Layer 7 health checks
4
Refer to “Configuring scripted health checks” on page 270 for more information.
Performed:
• Immediately following a successful Layer 4 TCP health check
• At regular intervals, if keepalive is enabled for the port
IMAP4
The ServerIron ADX waits for a message from the IMAP4 server:
• If the server sends a greeting message that starts with “* OK”, The ServerIron 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 ServerIron 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 ServerIron 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
ServerIron ADX supports both anonymous and authenticated bonding with LDAP servers.
With anonymous bonding, ServerIron 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, ServerIron ADX marks the LDAP port as active only after the
completion of a successful authenticated bind and search operation.
For information on configuring LDAP health checks, refer to “LDAP” on page 235.
Anonymous bonding
If a username and password are not configured, the ServerIron 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 ServerIron 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 ServerIron ADX retries the health check for a user-configured number of retries (the default
is two). If the server still does not respond, the ServerIron ADX marks the server port FAILED
and removes the server from the load-balancing rotation for LDAP service.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
223
4
Layer 7 health checks
Authenticated bonding
If a username and password are configured, the ServerIron 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).
ServerIron 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 ServerIron ADX
resets the connection and marks the port ACTIVE.
• If the result of the query is any error value, the ServerIron 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
ServerIron ADX also supports server response threshold health checks for LDAP servers. To learn
more see “Server response threshold health check” on page 216.
MMS
The ServerIron ADX sends an intentionally invalid request to the server:
• If the server replies with a packet containing the value "MMS", the ServerIron ADX marks the
port ACTIVE.
• If the server does not reply with a packet containing the value "MMS", the ServerIron 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 ServerIron ADX marks the server port FAILED and removes
the server from the load-balancing rotation for MMS service.
NOTE
You can view the ServerIron 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
NNTP
The ServerIron ADX waits for a message from the NNTP server:
• If the server sends a greeting message with status code 200 or 201, the ServerIron 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 ServerIron
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 ServerIron ADX marks the server port
FAILED and removes the server from the load-balancing rotation for NNTP service.
224
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Layer 7 health checks
4
Performed:
• Immediately following a successful Layer 4 TCP health check
• At regular intervals, if keepalive is enabled for the port
PNM
The ServerIron ADX sends a PNM file request that does not have a file name:
• If the server sends a reply containing the value "PNA", the ServerIron ADX marks the port
ACTIVE.
• If the server does not send a reply containing the value "PNA", the ServerIron 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 ServerIron 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 ServerIron ADX waits for a message from the POP3 server:
• If the server sends a greeting message that starts with “+ OK”, the ServerIron 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 ServerIron 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 ServerIron 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
ServerIron ADX Server Load Balancing Guide
53-1003452-01
225
4
Layer 7 health checks
RADIUS
By default, the ServerIron ADX performs a RADIUS authentication health check but does not
perform a RADIUS accounting health check. The ServerIron ADX sends an authentication request
with a user name and password to the RADIUS server. However, the account information does not
need to be valid for the server to pass the authentication health check. If you do not enable
accounting heath checks, Brocade recommends that you use invalid information to prevent
someone from learning account information by observing the ServerIron ADX RADIUS health check.
To enable accounting heath check, refer to “Enabling RADIUS accounting health check.”
For additional information of configuring RADIUS health checks, refer to the “RADIUS” on
page 234.
NOTE
If the ServerIron ADX is performing health checks for both RADIUS authentication and RADIUS
accounting, define a Boolean health check for both the ports.
If the server replies with the result code “ACCEPT” or “REJECT” (or “ACCEPT only”, if required), the
ServerIron 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
ServerIron 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
ServerIron 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 by using the server radius-fail-healthcheck-on-access-reject command.
For example, a “REJECT” is considered to indicate a health check fail condition.
ServerIronADX(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
Enabling RADIUS accounting health check
By default, RADIUS accounting health check is disabled on the ServerIron ADX. When you enable
the accounting health check, the RADIUS health check request is sent to the accounting port of the
RADIUS server. The default RADIUS accounting port used for this health check is 1813, unless you
define a port in the configuration. You can define this port on a real server, port policy or Boolean
health check.
The RADIUS accounting response packet is validated against the accounting response and
identifier field.
226
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Layer 7 health checks
4
The following steps describe the validation of the packet and the port state.
1. The ServerIron ADX expects a valid response from the server if the server records and accepts
the accounting request. In the case of a failure, the server drops the accounting request
packet.
2. The server response is validated against the identifier field in the request packet with the
identifier field in the response packet.
3. As part of request accouting packet, the ServerIron ADX sends the authenticator based on the
shared key. The server uses the same key on the request packet to generate the authenticator
field. If it matches, the server sends the accounting response. Otherwise, the server drops the
packet.
4. Depending on the response, the following actions occur:
• If the ServerIron ADX receives a valid response from the server, it marks the port as UP.
• If the ServerIron ADX receives an invalid response from the server, it drops that packet.
• If the ServerIron ADX does not receive any packet within the keepalive time, it performs
retries for the accounting request. After the maximum number of retries, if the ServerIron
ADX does not receive any response from the server, it marks the port as DOWN.
• If the ServerIron ADX receives any ICMP error, it attempts the maximum number of retries.
After reaching the maximum number of retries and receiving an ICMP error, it marks the
accounting port as DOWN.
The requirements for RADIUS accounting health check are as follows.
• The shared key is mandatory for RADIUS accounting.
• The following optional parameters present in the RADIUS accouting request, if configured:
- User-Name
- NAS-Identifier
- NAS-Port
Configuring the RADIUS accounting request on a real server port
To configure a port on a real server to send the RADIUS accounting request, use the port radius
accounting command in real server configuration mode.
ServerIronADX(config)#server real r1 192.168.20.43
ServerIronADX(config-rs-r1)# port radius accounting
Syntax: [no] port radius accounting [port]
The optional port variable defines the real server port. By default, the request is sent on port 1813.
Configuring a RADIUS accounting request on a port policy
To configure a port on a port policy to send the RADIUS accounting request, use the protocol radius
accounting command in port policy configuration mode.
ServerIronADX(config)#server port-policy p1
ServerIronADX (config-port-policy-p1)# protocol radius accounting
Syntax: [no] protocol radius accounting [port]
The optional port variable defines the port on the port policy. By default, the request is sent on port
1813.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
227
4
Layer 7 health checks
Configuring a RADIUS accounting request on a Boolean health check
To configure a specified port on a Boolean health check to send the RADIUS accounting request,
use the protocol radius accounting command in Boolean health check configuration mode.
ServerIronADX(config)#healthck hh boolean
ServerIronADX (config-hc-hh)# protocol radius accounting
Syntax: [no] protocol radius accounting [port]
The optional port variable defines the port on the Boolean health check. By default, the request is
sent on port 1813.
Displaying RADIUS accounting information on a real server
To display the number of RADIUS accounting sent and response packets on real servers or a
specified real server, use the show server real radius command.
ServerIronADX # show server real radius rs1
Slot index 1
Real server name = rs1, Real port Status = FAILED
Slot valid = TRUE
IP: 19.1.1.99
Real port index = 2,
Real port no = 1812
Keepalive Enabled,
Current ID = 57
RADIUS key = "FOUndry123"
RADIUS Accounting sent = 57,
Accounting Response = 52
Last received code = 5,
Last Received id = 52
RADIUS ID not match = 0,
Invalid opcode = 0
RADIUS msg recv: Not wait for response = 0
RADIUS response timeout = 4,
Current sent = 1
RADIUS wait for response = TRUE,
Return code = 0
RADIUS bring port down = 2,
Total retries = 0
Next slot index = 0
Syntax: show server real radius [real_server]
The optional real_server variable is the name of a specific real server.
228
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Layer 7 health checks
4
RTSP
The ServerIron ADX sends a standard RTSP option packet, using sequence number 1:
• If the server responds with an acceptable status code, the ServerIron 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 ServerIron ADX marks the port FAILED.
• If the server does not respond, the ServerIron 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 ServerIron
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
SMTP
The ServerIron ADX waits for a message from the SMTP server:
• If the server sends a greeting message with status code 220, the ServerIron 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 ServerIron 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 ServerIron 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
The ServerIron ADX supports the complete and simple SSL health checking methods. For
information on their supported ciphers and configuration, refer to the “Simple and complete SSL
health checks” on page 237.
SSL (complete)
The ServerIron 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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
229
4
Layer 7 health checks
After the SSL connection is established, the ServerIron 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 ServerIron 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 ServerIron ADX resets the
connection and marks the port ACTIVE.
• If the server does not respond, the ServerIron 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 ServerIron
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 ServerIron ADX examines the text in an HTML file sent by a real
server in response to an HTTP keepalive request. The ServerIron 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 260 and the
“Content match for HTTP” on page 266 for more information.
SSL (simple)
The ServerIron ADX sends an SSL client hello with the SSL SID set to 0:
• If the server responds, then the ServerIron ADX resets the connection and marks the port
ACTIVE.
• If the server does not respond, the ServerIron 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 ServerIron
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
230
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Layer 7 health checks
4
Telnet
The ServerIron 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
ServerIron 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
ServerIron 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 ServerIron 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
Configuring port-specific settings
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)
NOTE
The ServerIron ADX uses its own management IP address or a source IP address configured on the
ServerIron 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 ServerIron ADX, then the health checks
can use the ServerIron ADX’s management IP address. Otherwise, the health checks use a source
IP address. Refer to “Web hosting with ServerIron ADX and real servers in different subnets” on
page 534.
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 ServerIron 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 ServerIron ADX considers the health check to be enabled. Refer to “Configuring a port profile”
on page 244.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
231
4
Layer 7 health checks
To locally enable a Layer 7 health check, enter a command such as the following at the real server
level of the CLI.
ServerIronADX(config-rs-jet)#port dns 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 can have one of the following values:
• dns (port 53)
• ftp (port 21). Ports 20 and 21 both are FTP ports but in the ServerIron ADX, the name “ftp”
corresponds to port 21.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
http (port 80)
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)
smtp (port 25)
snmp (port 161)
ssl (port 443)
telnet (port 23)
tftp (port 69)
number
NOTE
Specify the port number if the port is not one of the well-known names listed above.
HTTP
Changing HTTP keepalive method, value, and status codes
The ServerIron 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 ServerIron ADX requests on a real server basis.
232
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Layer 7 health checks
4
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 266
for more information.
To configure the HTTP keepalive request to send a GET request for “sales.html”, enter the following
commands.
ServerIronADX(config)#server real zip 10.96.3.251
ServerIronADX(config-rs-zip)#port http url "GET /sales.html"
ServerIronADX(config-rs-zip)#exit
ServerIronADX(config)#server virtual-name-or-ip shoosh 10.96.4.250
ServerIronADX(config-vs-shoosh)#port http
ServerIronADX(config-vs-shoosh)#bind http zip http
ServerIronADX(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 ServerIron 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 ServerIron ADX automatically inserts a slash before
retrieving the URL page.
To change the HTTP status codes that the ServerIron ADX considers normal (not indicative of a
failure of the HTTP service), enter the following command.
ServerIronADX(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–299 to be valid, you must specify them.
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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
233
4
Layer 7 health checks
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.
ServerIronADX(config)#server port dns
ServerIronADX(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 ServerIron 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 ServerIron ADX sends a Source-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.
ServerIronADX(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.
ServerIronADX(config-rs-zip)#port dns zone example2.com
Syntax: [no] port dns zone zone-name
RADIUS
Configuring RADIUS authentication health check values
You can define the RADIUS parameters that the ServerIron ADX sends to a RADIUS application port
during the Layer 7 health check.
The RADIUS health check requests a specific user name, password, and authentication key from
the RADIUS server. To specify these values, use one of the following methods.
234
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Layer 7 health checks
4
To configure the parameters for a RADIUS health check, enter commands such as the following at
the real server level of the CLI.
ServerIronADX(config-rs-rocket)#port radius username evil
ServerIronADX(config-rs-rocket)#port radius password woody
ServerIronADX(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 authentication health checks
With a valid response from a RADIUS server (that is, user authentication pass or fail), the
ServerIron ADX marks the RADIUS health check as passed. However, this behavior might not be
desired in some cases. The following enhancement lets the ServerIron ADX mark the RADIUS
health check as FAIL if authentication is received as (PW_ACCESS_REJECT).
ServerIronADX(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 ServerIron 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.
ServerIronADX(config)#server real r1 192.168.20.43
ServerIronADX(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 ServerIron 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 ServerIron 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.
ServerIronADX(config)#server real r1 192.168.20.43
ServerIronADX(config-rs-r1)#port ldap password “brocade123”
Syntax: [no] port {ldap | ldaps | port-num} password string
The string variable specifies the password for the Directory object that the ServerIron ADX binds as;
it is a character string that cannot exceed 64 characters.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
235
4
Layer 7 health checks
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.
ServerIronADX(config)#server real r1 192.168.20.43
ServerIronADX(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 ServerIron 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 ServerIron 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 ServerIron 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 ServerIron
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 ServerIron 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 ServerIron 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 in addition to 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.
ServerIronADX(config)#server port ldaps
ServerIronADX(config-port-ldaps)#tcp keepalive enable
ServerIronADX(config-port-ldaps)#exit
ServerIronADX(config)#server real r1 10.10.1.101
ServerIronADX(config-rs-r1)#port ldaps
ServerIronADX(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
ServerIron ADX does not establish a secure connection when performing a health check on port
636. Instead, the ServerIron ADX establishes a regular TCP connection on port 636 and sends a
TCP RESET, using the same method as the LDAP health check.
236
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Layer 7 health checks
4
Configuring Boolean LDAP health checks
To configure a Boolean LDAPS health check, enter commands such as the following.
ServerIronADX(config)#healthck check1 tcp
ServerIronADX(config-hc-check1)#dest-ip 10.10.1.101
ServerIronADX(config-hc-check1)#port ldaps
ServerIronADX(config-hc-check1)#protocol ldaps
ServerIronADX(config-hc-check1)#l7-check
A Layer 7 health check must be configured in order for the ServerIron ADX to establish a secure
connection on the LDAPS port. If only a Layer 4 health check is configured, then the ServerIron ADX
establishes a regular TCP connection on port 636.
Simple and complete SSL health checks
The ServerIron 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 ServerIron ADX then resets the
connection and marks the SSL port ACTIVE.
• The complete method negotiates an SSL connection and sends 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 ServerIron ADX resets the connection and marks the port ACTIVE.
The simple and complete SSL health checks use cipher suites as part of the SSL Hello sent to the
SSL server, and the server choses the cipher as part of the Hello sent to the ServerIron ADX SSL
client. If the complete SSL method is enabled on the ServerIron ADX, the cipher choosen by the SSL
server is used in additional SSL communications for encryption.
Table 14 lists the cipher suites for the SSL health check methods.
TABLE 14
Cipher suites for simple and complete SSL health check methods
Cipher suite
SSL health check method
TLS_RSA_WITH_AES_256_CBC_SHA
Simple and complete
TLS_RSA_WITH_AES_128_CBC_SHA
Simple and complete
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
Simple
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
Simple
TLS_RSA_WITH_3DES_EDE_CBC_SHA
Simple and complete
TLS_RSA_WITH_IDEA_CBC_SHA
Simple and complete
TLS_RSA_WITH_RC4_128_SHA
Simple and complete
TLS_RSA_WITH_RC4_128_MD5
Simple and complete
TLS_DHE_RSA_WITH_DES_CBC_SHA
Simple
TLS_DHE_DSS_WITH_DES_CBC_SHA
Simple
TLS_RSA_WITH_DES_CBC_SHA
Simple and complete
SSL2_CK_3DES
Simple and complete
SSL2_CK_IDEA
Simple and complete
SSL2_CK_RC2
Simple and complete
ServerIron ADX Server Load Balancing Guide
53-1003452-01
237
4
Layer 7 health checks
TABLE 14
Cipher suites for simple and complete SSL health check methods (Continued)
Cipher suite
SSL health check method
SSL2_CK_RC4
Simple and complete
SSL2_CK_RC464
Simple and complete
SSL2_CK_DES
Simple and complete
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
Simple
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
Simple
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
Simple and complete
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
Simple and complete
TLS_RSA_EXPORT_WITH_RC4_40_MD5
Simple and complete
SSL2_CK_RC2_EXPORT40
Simple and complete
SSL2_CK_RC4_EXPORT40
Simple and complete
Configuring SSL health checks
To configure the ServerIron ADX to use the simple SSL health check, enter the following command.
ServerIronADX(config)#server use-simple-ssl-health-check
To use the complete SSL health check, enter the no server use-simple-ssl-health-check command.
ServerIronADX(config)#no server use-simple-ssl-health-check
NOTE
When you configure complete SSL health check on the ServerIron ADX and the server response is
in small TCP segment packets of 5 to 50 bytes, flapping occurs and the ServerIron 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 an SSL health check after the ServerIron ADX receives
SSL data and 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 ???
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 ServerIron ADX normally stops processing the rest of the data and releases the SSL control
block data structure. However, when the ServerIron ADX does not do that, the ServerIron ADX finds
the SSL data structure is null and prints these messages.
238
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Layer 7 health checks
4
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:
• 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 ServerIron ADX’s Layer 7 health check mechanism for the following TCP
applications on any TCP port number:
•
•
•
•
•
•
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 211.
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.
ServerIronADX(config)#server port 999
ServerIronADX(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
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
ServerIron ADX Server Load Balancing Guide
53-1003452-01
239
4
Server and application port states
• smtp or 25
• telnet or 23
Configuring an unknown UDP port to use a Layer 7 health check
The ServerIron 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 234. 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 ServerIron 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.
ServerIronADX(config)#server port 999
ServerIronADX(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.
TABLE 15
240
Server states
State
Description
ENB:enabled
There is no link to the real server. The real server is configured on the ServerIron ADX but is
not physically connected to the ServerIron 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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Server and application port states
TABLE 15
4
Server states (Continued)
State
Description
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 ServerIron 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 ServerIron ADX will
normally send one ICMP echo request. After it gets the ARP reply and before it gets the ICMP
echo reply, the ServerIron 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 ServerIron 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 ServerIron 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 ServerIron 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.
After receiving the first ping reply, the ServerIron ADX normally switches to periodic ARPs. If
you enable the server l3-health-check command globally, then the ServerIron ADX switches to
using periodic pings instead. The real server still shows the state active. If you enter the no
server l3-health-check command globally, then the ServerIron ADX will switch back to ARP.
After the first ping succeeds, if you do not have Layer 3 health checks enabled, you can add
an ICMP blocking ACL on the real server, and the system will still display "Active". If you re-add
the server l3-health-check command, then the real server state will change from Active to
Suspect and then Failed. This behavior takes place before any ports have been bound to a
virtual server. All these states on a real server have nothing to do with Layer 4 or Layer 7.
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 ServerIron 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 ServerIron ADX but is not connected
to the ServerIron 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 ServerIron 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 ServerIron ADX continually tries to reach the failed application.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
241
4
Server and application port states
TABLE 16
Application port states (Continued)
State
Description
TEST
The server is still reachable at Layer 3, but the application has failed to respond to its Layer 4 (or
if applicable, Layer 7) health check.
SUSPECT
The ServerIron 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 ServerIron ADX sends a Layer 4 health check to the
service. (If applicable, and if the server passes the Layer 4 health check, the ServerIron ADX then
sends a Layer 7 health check to the application.) If the application does not respond within a
specified interval, the ServerIron 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.
ServerIronADX(config)#show server real
Real Servers Info
Server State - 1:enabled, 2:failed, 3:test, 4:suspect, 5:grace_dn, 6:active
Name:rs1
IP:
10.95.7.1:1
State:1
Wt:1
Max-conn:1000000
Src-nat (cfg:op) = 0: 0 Dest-nat-(cfg:op) = 0: 0
Remote server: No
Dynamic: No :Mac-info: ffff
Port State
Ms CurConn TotConns
Rx-pkts
Tx-pkts
Rx-octet Tx-octet Reas
http enabled 0
0
0
0
0
0
0 0
Keepalive(G/L:Off/Off):Off
Status Code(s): default (200-299, 401)
HTTP URL: "HEAD /"
defaulunbnd
0
0
0
0
0
0
0 0
Server Total
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 ServerIron ADX automatically configures on all the real and virtual servers) is unbound
(unbnd). These states are typical of a ServerIron ADX that is configured for deployment but has not
been connected to the real servers.
The information under the row for the HTTP application 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 “Layer 7 health checks” on page 231.
242
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Port profiles and attributes
4
Displaying virtual server state information
To display virtual server information, enter the following command at any level of the CLI.
ServerIronADX(config)#show server virtual
Virtual Servers Info
Server Name: v100
IP : 10.157.23.100 :
4
Status: enabled Predictor: least-conn TotConn: 4233
Dynamic: No
HTTP redirect: disabled
Sym: group = 1 state = 5 priority =
2 keep =
0
Activates =
4, Inactive= 3
Port
State
Sticky Concur
CurConn
TotConn
http
enabled
NO
NO
0
4233
default enabled
NO
NO
0
0
PeakConn
39
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 ServerIron ADX but the
ServerIron ADX is not connected to the real servers bound to this virtual server. Refer to “Displaying
real server state information” on page 242 for descriptions of the server and application states.
NOTE
The number following “state” in the “Sym” row indicates the Symmetric Active-Standby HA state of
this VIP.
Alias port state and master port state definitions
When a virtual port is bound on an alias port, the alias port contains two states: its own alias port
state and the state of the master port. The master port state refers to the health check status of its
master port.
For example, in the following server binding information, the first state (Active) indicates the alias
port state and the second state (Failed) indicates master port state.
Bind info
Virtual server:vs1 Status:enabled IP: 198.51.100.1
http------>rs1: 192.0.2.1, 8080 (Active-Failed)
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 ServerIron ADX (refer to the list
in “Layer 7 health checks” on page 231) or you want to globally define a port that is not known to
the ServerIron 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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
243
4
Port profiles and attributes
Configuring a port profile
For an application port not known to the ServerIron ADX, the ServerIron ADX assumes that it is a
UDP port. In addition, the ServerIron 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 ServerIron 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 ServerIron 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 ServerIron 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 ServerIron 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
ServerIron ADX.
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.
TABLE 17
Keepalive health check states
State
Global (entire ServerIron
ADX)
Local (specific real server)
Effect
Disabled
Disabled
Health check is disabled
Disabled
Enabled
Health check is enabled
Enabled
Disabled
Health check is enabled
Enabled
Enabled
Health check is enabled
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 231.
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 232, “Configuring DNS health check method and values” on page 234, or “Configuring
RADIUS authentication health check values” on page 234.
NOTE
When health checks are enabled for the ports on the VIPs in a host range, the ServerIron ADX checks
the health of the applications on the base IP address only. The ServerIron ADX assumes that the
health of an application is the same for all the VIPs within the host range.
244
ServerIron ADX Server Load Balancing Guide
53-1003452-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 ServerIron
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.
ServerIronADX(config)#server port 8080
ServerIronADX(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.
ServerIronADX(config-port-8080)#tcp keepalive disable
To change a port’s keepalive interval and retries, enter a command such as the following.
ServerIronADX(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 ServerIron 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 ServerIron 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 245.
NOTE: To display a list of the ports for which the ServerIron 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 ServerIron
ADX re-attempts a health check to which the server does not respond.
Refer to “Changing a port’s keepalive parameters” on page 245.
Keepalive state
Whether the ServerIron 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 ServerIron ADX,
the keepalive parameters affect Layer 7 health checks. For other ports, the
keepalive parameters affect Layer 4 health checks.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
245
4
Port profiles and attributes
TABLE 18
Port profile attributes (Continued)
Attribute
Description
Keepalive port
By default, the ServerIron 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 ServerIron
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 278.
NOTE: You cannot base the health of a port well-known to the ServerIron 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 ServerIron ADX performs independent health checks on an alias port and its
master port. You can configure the ServerIron 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 277.
TCP or UDP age
The number of minutes a TCP or UDP session table entry can remain inactive before the
ServerIron 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 248.
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 ServerIron 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 ServerIron 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 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.
NOTE: The ServerIron ADX immediately deletes a UDP DNS or RADIUS session table entry
when the ServerIron ADX receives a reply for the application from a real server. If
desired, you can configure the ServerIron 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 160.
246
Session
synchronization
In Symmetric Active-Standby HA configurations, this attribute provides failover for individual
sessions on the application port. Normally, existing sessions are not carried over from one
ServerIron ADX to another during failover.
Refer to “Enabling session synchronization” on page 249.
Connection logging
You can enable logging for session table entries created for this port.
Refer to “Syslog for session table entries” on page 302.
Slow start
Configures the ServerIron 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 286.
Smooth factor
If you plan to use server response time as a load-balancing method, you can adjust the
amount of preference the ServerIron 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 249.
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 233.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Port profiles and attributes
4
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 ServerIron ADX knows the port types of some well-known port numbers. If you are using a port
number for which the ServerIron 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 ServerIron ADX to be a TCP port, the ServerIron ADX assumes the port
is UDP. If you are using a port number that is not known to the ServerIron 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 ServerIron 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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
247
4
Port profiles and attributes
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.
ServerIronADX(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:1000000
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
---telnet
State
Ms CurConn TotConn Rx-pkts Tx-pkts
------ ------- ------- ------- ------active
0 0
0
0
0
max_conn = 1000000 sessions =
0
Keepalive(G/L:Off/Off):Off
tcp-age: 40
8083
active
0 0
0
0
0
max_conn = 1000000 sessions =
0
Keepalive(G/L:On/Off):On
tcp-age: 40
8082
active
0 0
0
0
0
max_conn = 1000000 sessions =
0
Keepalive(G/L:On/Off):On
tcp-age: 35 * 4
8081
active
0 1
1
10
19
max_conn = 1000000 sessions =
2
Keepalive(G/L:On/Off):On
tcp-age: 53
http
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
Rx-octet
-------0
Tx-octet
-------0
Reas
---0
0
0
0
0
0
0
2280
4380
0
0
0
0
0
0
0
Server
2280
4380
0
Total
1
1
Syntax: show server real name detail
10
19
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 ServerIron 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 ServerIron 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 ServerIron ADX removes the session as soon as the client or
server closes the session.
248
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Port profiles and attributes
4
NOTE
The ServerIron ADX immediately deletes a UDP DNS or RADIUS session table entry when the
ServerIron ADX receives a reply for the application from a real server. If desired, you can configure
the ServerIron 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 160.
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 301 or
“Configuring UDP age” on page 301.
To override the default TCP age and set the age for TCP port 80 to 15 minutes, enter the following
commands.
ServerIronADX(config)#server port 80
ServerIronADX(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.
Enabling session synchronization
In Symmetric Active-Standby HA configurations, if the active ServerIron ADX becomes unavailable,
service for the VIPs that ServerIron ADX was load balancing is assumed by the backup ServerIron
ADX. By default, when a ServerIron ADX with open sessions becomes unavailable, the sessions are
not carried over to the standby ServerIron ADX. Instead, the sessions end and must be
re-established by the clients or servers.
You can configure session failover on an individual TCP or UDP port basis by enabling session
synchronization in the port’s profile.
To enable session synchronization for port 80, enter the following commands.
ServerIronADX(config)#server port 80
ServerIronADX(config-port-80)#session-sync
Syntax: server port TCP/UDP-portnum
Syntax: [no] session-sync
NOTE
In case of port translation, enable session synchronization for both the VIP virtual port and the real
server port.
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 42 and
“Configuring a stateless port” on page 51 for information about the server response time metric
and how the smooth time works.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
249
4
Port policy
The ServerIron 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 ServerIron 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 ServerIron ADX is performing.
To change the smooth factor for an application port, enter a command such as the following.
ServerIronADX(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.
Previously, ServerIron ADX allowed the use of Layer 7 health check parameters for known ports,
such as HTTP, LDAP, SMTP, IMP4, POP3, NNTP, Telnet, and FTP, to check the health of unknown
ports. For example, a configuration such as the following can be entered.
ServerIronADX(config)#server port 999
ServerIronADX(config-port-999)#tcp keepalive protocol smtp
In this release, health checks for SSL, RTSP, MMS, PNM, and LDAPS have been added to check the
health of unknown ports, using the server port-policy command.
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.
ServerIronADX(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.
ServerIronADX(config-port-policy-name)#port 8080
Syntax: port port-num
250
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Port policy
4
3. Specify what protocol will be checked on the traffic that passes through the port.
ServerIronADX(config-port-policy-name)#protocol http
Syntax: protocol protocol-value
If the protocol is not configured, the policy cannot be bound to a real server port.
Enter a TCP or UDP port name or number for protocol-value. 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 ServerIron, the name "FTP" corresponds to port
21.
For UDP ports, enter DNS (port 53) or RADIUS (port 1812).
4. Configure a keepalive interval under a port policy.
ServerIronADX(config-port-policy-pp1)#keepalive-interval 5
Syntax: [no] keepalive-interval seconds
Refer to “Configuring a keepalive interval under a port policy” on page 254 for more details.
5. (Optional) Enter the number of times the policy will be tried before the ServerIron ADX marks
the port as "UP" or "DOWN".
ServerIronADX(config-port-policy-name)#retries 5
Syntax: retries num
The default is 3 tries.
6. (Optional) Specify the protocol value.
ServerIronADX(config-port-policy-name)#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:
•
•
•
•
•
•
•
•
•
•
•
•
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
ServerIron ADX Server Load Balancing Guide
53-1003452-01
251
4
Port policy
7.
(Optional) Enable the Layer 4 check feature in the policy.
ServerIronADX(config-port-policy-name)#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.
Binding the policy
After the policy is configured, return to the configuration level and bind the policy to a real server
port.
ServerIronADX(config)#server real r1 10.10.1.101
ServerIronADX(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 ServerIron ADX will use the values configured in the
policy for health checks.
The ServerIron 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 ServerIron 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:
ServerIronADX(config)#server port-policy p1
ServerIronADX(config-port-policy-p1)#port 8080
ServerIronADX(config-port-policy-name)#protocol ssl
ServerIronADX(config-port-policy-name)#retries 5
ServerIronADX(config-port-policy-name)#exit
ServerIronADX(config)#server real r1 10.10.1.101
ServerIronADX(config-rs-r1)#port 1234 use-port-policy p1
ServerIronADX(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 8080 on the server with the IP address of 10.10.1.101 passes.
Example 2:
ServerIronADX(config)#server port-policy p2
ServerIronADX(config-port-policy-name)#protocol http
ServerIronADX(config-port-policy-name)#l4-check
ServerIronADX(config-port-policy-name)#exit
ServerIronADX(config)#server real r2 10.10.1.102
ServerIronADX(config-rs-r1)#port 1234 use-port-policy p2
252
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Port policy
4
In Example 2, a port has not been configured for "policy p2," so the ServerIron 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.
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.
ServerIronADX(config)#server port-policy pp1
ServerIronADX(config-port-policy-pp1)#keepalive-interval 5
ServerIronADX(config-port-policy-pp1)#protocol http
ServerIronADX(config-port-policy-pp1)#protocol http url "GET /abc.html"
ServerIronADX(config-port-policy-pp1)#retries 3
ServerIronADX(config-port-policy-pp1)#exit
ServerIronADX(config)#server port-policy pp2
ServerIronADX(config-port-policy-pp2)#keepalive-interval 30
ServerIronADX(config-port-policy-pp2)#protocol http
ServerIronADX(config-port-policy-pp2)#protocol http url "GET /xyz.html"
ServerIronADX(config-port-policy-pp2)#retries 2
ServerIronADX(config-port-policy-pp2)#exit
ServerIronADX(config)#server real rs1
ServerIronADX(config-rs-r1)#port 8080
ServerIronADX(config-rs-r1)#port 8080 use-port-policy pp1
ServerIronADX(config-rs-r1)#exit
ServerIronADX(config)#server real rs2
ServerIronADX(config-rs-r2)#port 9090
ServerIronADX(config-rs-r2)#port 9090 use-port-policy pp1
ServerIronADX(config-rs-r2)#exit
ServerIronADX(config)#server#real rs3
ServerIronADX(config-rs-r3)#port 8080
ServerIronADX(config-rs-r3)#port 8080 use-port-policy pp2
ServerIronADX(config-rs-r3)#exit
ServerIronADX(config)#server real rs4
ServerIronADX(config-rs-r4)#port 9090
ServerIronADX(config-rs-r4)#port 9090 use-port-policy pp2
ServerIronADX(config-rs-r4)#exit
ServerIron ADX Server Load Balancing Guide
53-1003452-01
253
4
Port policy
Configuring a keepalive interval under a port policy
You can specify a health check keepalive interval from under a port-policy definition.
ServerIronADX(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.
ServerIronADX(config)#server port-policy pp1
ServerIronADX(config-port-policy-pp1)#keepalive-interval 10
ServerIronADX(config-port-policy-pp1)#protocol http
ServerIronADX(config-port-policy-pp1)#protocol http url "GET /abc.html"
ServerIronADX(config-port-policy-pp1)#retries 3
ServerIronADX(config-port-policy-pp1)#exit
ServerIronADX(config)#server port-policy pp2
ServerIronADX(config-port-policy-pp2)#keepalive-interval 30
ServerIronADX(config-port-policy-pp2)#protocol http
ServerIronADX(config-port-policy-pp2)#protocol http url "GET /xyz.html"
ServerIronADX(config-port-policy-pp2)#retries 2
ServerIronADX(config-port-policy-pp2)#exit
After configuring the policy, bind it to a real server port. (Refer to “Binding the policy” on page 252
for details.) For example:
254
ServerIronADX(config)#server real
ServerIronADX(config-rs-rs1)#port
ServerIronADX(config-rs-rs1)#port
ServerIronADX(config-rs-rs1)#port
ServerIronADX(config-rs-rs1)#exit
rs1
8080
8080 keepalive
8080 use-port-policy pp1
ServerIronADX(config)#server real
ServerIronADX(config-rs-rs2)#port
ServerIronADX(config-rs-rs2)#port
ServerIronADX(config-rs-rs2)#port
ServerIronADX(config-rs-rs2)#exit
rs2
9090
9090 keepalive
9090 use-port-policy pp1
ServerIronADX(config)#server real
ServerIronADX(config-rs-rs3)#port
ServerIronADX(config-rs-rs3)#port
ServerIronADX(config-rs-rs3)#port
ServerIronADX(config-rs-rs3)#exit
rs3
8080
8080 keepalive
8080 use-port-policy pp2
ServerIronADX(config)#server real
ServerIronADX(config-rs-rs4)#port
ServerIronADX(config-rs-rs4)#port
ServerIronADX(config-rs-rs4)#port
rs4
9090
9090 keepalive
9090 use-port-policy pp2
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Element health checks
4
Health check policy for VIP port
Overview of health check policy for VIP port
NOTE
The ServerIron ADX does not currently support interval configuration under server port policy.
The ServerIron ADX currently has support binding 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.
ServerIronADX(config)#server virtual-name-or-ip v1 10.1.1.1
ServerIronADX(config-virtual-server-v1) port 80
ServerIronADX(config-virtual-server-v1) bind 80 r1 80 r2 80 r3 80
ServerIronADX(config-virtual-server-v1) port 80 use-port-policy policy1
The ServerIron 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.
Element health checks
Introduction
The ServerIron 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 ServerIron 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 also can 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 ServerIron 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 ServerIron ADX uses the Layer 7 health check if the port is one of the types
that are well known to the ServerIron ADX.
• Health check interval – By default, the ServerIron ADX performs the health checks every 5
seconds. You can change the interval to a value from 2 through 120 seconds.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
255
4
Element health checks
• Health retries – By default, if a reply to a health check is not received, the ServerIron 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
ServerIronADX(config)#healthck check1 tcp
ServerIronADX(config-hc-check1)#dest-ip 10.10.10.50
ServerIronADX(config-hc-check1)#port http
Example for IPv6
ServerIronADX(config)#healthck check-v6 tcp
ServerIronADX(config-hc-check-v6)#dest-ip 2001:db8:2000::1
ServerIronADX(config-hc-check-v6)#port http
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 ServerIron ADX, the ServerIron 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 ServerIron ADX associates the default HTTP health
check parameters with the element-action expression. By default, the ServerIron 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 ServerIron ADX will list the status of the health check
as FALSE (failed).
256
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Element health checks
4
To configure an element-action expression for a port number that is not well-known to the
ServerIron ADX, enter commands such as the following.
Example for IPv4
ServerIronADX(config)#healthck check1 tcp
ServerIronADX(config-hc-check1)#dest-ip 10.10.10.50
ServerIronADX(config-hc-check1)#port 8080
ServerIronADX(config-hc-check1)#protocol http
Example for IPv6
ServerIronADX(config)#healthck check-v6 tcp
ServerIronADX(config-hc-check-v6)#dest-ip 2001:db8:2000::1
ServerIronADX(config-hc-check-v6)#port 8080
ServerIronADX(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
ServerIronADX(config)#healthck check1 tcp
ServerIronADX(config-hc-check1)#dest-ip 10.10.10.50
ServerIronADX(config-hc-check1)#port 8080
ServerIronADX(config-hc-check1)#protocol http url "GET /sales.html"
Example for IPv6
ServerIronADX(config)#healthck check-v6 tcp
ServerIronADX(config-hc-check-v6)#dest-ip 2001:db8:2000::1
ServerIronADX(config-hc-check-v6)#port 8080
ServerIronADX(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 }
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 or 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 ServerIron ADX will list the
status of the health check as FALSE (failed).
ServerIron ADX Server Load Balancing Guide
53-1003452-01
257
4
Element health checks
You can specify any valid number, or one of the following port names well-known to the ServerIron
ADX:
• dns – port 53
• ftp – port 21. (Ports 20 and 21 both are FTP ports but in the ServerIron 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 ServerIron 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 ServerIron ADX also removes
the protocol tcp/udp-port command (see below) if the port is well-known to the ServerIron ADX. The
reason is that the ServerIron ADX automatically uses the protocol that matches the well-known port.
For ports that are not well-known types, the ServerIron ADX does not remove the protocol. You must
remove it separately.
Syntax: [no] protocol tcp/udp-port
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 ServerIron ADX, the ServerIron ADX
automatically uses the protocol that matches the port; you do not need to specify it and cannot
change it.
258
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Element health checks
4
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 ServerIron 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 ServerIron 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 262.
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 ServerIron 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 ServerIron 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 ServerIron ADX examines text in an HTML file sent by a
real server in response to an HTTP keepalive request. The ServerIron 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 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 266.
Syntax: [no] protocol dns | 53 [addr_query "name" | zone zone-name]
ServerIron ADX Server Load Balancing Guide
53-1003452-01
259
4
Element health checks
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 ServerIron 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 ServerIron 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 ServerIron 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 ServerIron 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 ServerIron 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.
ServerIronADX(config)#healthck check4 tcp
ServerIronADX(config-hc-check4)#dest-ip 10.10.10.50
ServerIronADX(config-hc-check4)#port ssl
ServerIronADX(config-hc-check4)#protocol ssl use-complete
ServerIronADX(config-hc-check4)#protocol ssl url "GET /secure.htm"
ServerIronADX(config-hc-check4)#protocol ssl status-code 200 200
ServerIronADX(config-hc-check4)#protocol ssl content-match m1
ServerIronADX(config-hc-check4)#l7-check
ServerIronADX(config-hc-check4)#enable
ServerIronADX(config-hc-check4)#exit
Syntax: [no] protocol ssl use-complete
260
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Element health checks
4
Changing the health-check interval and retries
By default, the ServerIron ADX performs a health check every 5 seconds. If a reply is not received,
the ServerIron 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 ServerIron 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 ServerIron ADX will make. If you use the
default interval and retries values, the ServerIron 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 ServerIron ADX
sent the first health-check packet, the server fails the health check and the ServerIron 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.
ServerIronADX(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.
ServerIronADX(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 244.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
261
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 ServerIron ADX performs a Layer 7 health check in the following cases:
• The port is one of the following ports well-known to the ServerIron ADX:
- FTP – port 21. (Ports 20 and 21 both are FTP ports but on the ServerIron 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 ServerIron 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
ServerIron 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 ServerIron 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 ServerIron
ADX uses a Layer 7 health check. Otherwise, the ServerIron ADX uses the Layer 4 health check for
UDP.
262
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Element health checks
4
The Layer 7 health-check methods differ depending on the application:
• TCP – The ServerIron ADX attempts to engage in a normal three-way TCP handshake with the
port on the real server:
-
The ServerIron ADX sends a TCP SYN packet to the port on the real server.
The ServerIron ADX expects the real server to respond with a SYN ACK.
If the ServerIron ADX receives the SYN ACK, the ServerIron ADX sends a TCP RESET,
satisfied that the TCP port is alive.
• UDP – The ServerIron ADX sends a UDP packet with garbage (meaningless) data to the UDP
port:
-
If the server responds with an ICMP “Port Unreachable” message, the ServerIron ADX
concludes that the port is not alive.
-
If the server does not respond at all, the ServerIron ADX assumes that the port is alive and
received the garbage data. Because UDP is a connectionless protocol, the ServerIron ADX
and other clients do not expect replies to data sent to a UDP port. Therefore, lack of a
response is a good outcome.
ServerIronADX(config-hc-check1)#l4-check
The command in this example configures the ServerIron 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 ServerIron ADX will use the Layer 4 health check for TCP.
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.
ServerIronADX(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 ServerIron 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 281.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
263
4
Element health checks
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 ServerIron 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.
ServerIronADX(config)#server real-name R1 10.10.10.50
ServerIronADX(config-rs-R1)#port 80 healthck “check1”
This command configures the ServerIron ADX to base the health of application port 80 on real
server R1 on the results of the check1 health-check policy.
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.
ServerIronADX(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
check5
N/A
NO
udp
dns
dns
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
ServerIron 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 ServerIron ADX
assumes a server is healthy unless its health check is enabled and the server has not
responded appropriately to the health check.
264
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Element health checks
TABLE 19
4
Health-check policy status (Continued)
Field
Description
Enable
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.
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 ServerIron 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.
ServerIronADX(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 ServerIron 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 ServerIron ADX is
sometimes able to resolve an invalid ID. If the ServerIron 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 ServerIron ADX dropped.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
265
4
Health check with content match
Clearing health-check policy statistics
To clear health-check policy statistics, enter the following command.
ServerIronADX(config)#clear healthck statistics
Syntax: clear healthck statistics
Health check with content match
Content match for HTTP
Configuring HTTP content matching lists
The ServerIron 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.
ServerIronADX(config)#http match-list m1
ServerIronADX(config-real-server-r1)#down start "404"
ServerIronADX(config-real-server-r1)#default up
ServerIronADX(config)#http match-list m2
ServerIronADX(config-real-server-r1)#up end "found"
ServerIronADX(config-real-server-r1)#default down
The first match list m1 would cause the ServerIron 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 ServerIron ADX
would mark the port UP, as the default configured is UP.
In the second example above, for match-list m2, ServerIron 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 ServerIron
ADX examines text in an HTML file sent by a real server in response to an HTTP keepalive request.
The ServerIron 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.
ServerIronADX(config)#http match-list m1
ServerIronADX(config-http-ml-m1)#down simple "404"
ServerIronADX(config-http-ml-m1)#down simple "File Not Found"
ServerIronADX(config-http-ml-m1)#exit
266
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Health check with content match
4
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 ServerIron ADX marks port 80
(HTTP) on the real server FAILED. If neither of the text strings are found, the ServerIron 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 ServerIron ADX must not
exceed 200.
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 ServerIron
ADX takes one of the following actions:
• If the strings that meet the selection criteria are different, the ServerIron ADX takes action
based on the string that comes first in the file. For example:
ServerIronADX(config)#http match-list m2
ServerIronADX(config-http-ml-m2)#down simple "monkey"
ServerIronADX(config-http-ml-m2)#up simple "elephant"
ServerIronADX(config-http-ml-m2)#exit
The selection criteria in the matching list above would cause the ServerIron 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 ServerIron 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:
ServerIronADX(config)#http match-list m3
ServerIronADX(config-http-ml-m3)#down simple "elephant"
ServerIronADX(config-http-ml-m3)#up simple "elephantine"
ServerIronADX(config-http-ml-m3)#exit
In this example, ServerIron 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 ServerIron 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.
ServerIronADX(config)#http match-list m4
ServerIronADX(config-http-ml-m4)#up compound "monkey see" "monkey do" log
ServerIronADX(config-http-ml-m4)#down compound "500" "Internal Server Error" log
ServerIronADX(config-http-ml-m4)#down compound "503" "Service Unavailable" log
ServerIronADX(config-http-ml-m4)#default down
ServerIronADX(config-http-ml-m4)#exit
ServerIron ADX Server Load Balancing Guide
53-1003452-01
267
4
Health check with content match
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.
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”.
ServerIronADX#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
268
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Health check with content match
4
Displaying HTTP match lists
To display the contents of matching lists configured on the ServerIron ADX, enter the following
command.
ServerIronADX#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 ServerIron ADX, you bind the matching list to one or
more real servers, by entering commands such as the following.
ServerIronADX(config)#server real-name rs1 192.168.1.1
ServerIronADX(config-rs-rs1)#port http content-match m4
ServerIronADX(config-rs-rs1)#port http url "GET/monkey.html"
ServerIronADX(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”
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 ServerIron 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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
269
4
Health check with content match
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 ServerIron ADX. Previous releases supported content verification health checks on port 80
only.
In a scripted health check, the ServerIron ADX opens a connection to a port on a real server by
sending a SYN packet. The ServerIron 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 ServerIron
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 ServerIron 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 ServerIron ADX
assumes any port without a profile is a UDP port, and will perform UDP health checking on the port.
To use a scripted health check on a TCP port, you must create a port profile and explicitly identify
the port as a TCP port.
The following commands configure a port profile for port 12345 and specify that the port is a TCP
port. The no-fast-bringup command is necessary because it prevents the ServerIron ADX from
marking a port ACTIVE until it passes both Layer 4 and Layer 7 health checks.
ServerIronADX(config)#server port 12345
ServerIronADX(config-port-12345)#tcp
ServerIronADX(config-port-12345)#no-fast-bringup
Syntax: server port TCP/UDP-portnum
Syntax: tcp | udp [keepalive interval retries]
Syntax: no-fast-bringup
270
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Health check with content match
4
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.
ServerIronADX(config)#http match-list m1
ServerIronADX(config-http-m1-m1)#up simple "FTP service"
ServerIronADX(config-http-m1-m1)#default down
ServerIronADX(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 266.
Binding the matching list to the real server
To enable the scripted health check on the ServerIron 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.
ServerIronADX(config)#server real R 10.10.10.50
ServerIronADX(config-rs-R)#port 12345 content-check m1
Syntax: port portnum content-check matching-list-name
The portnum variable is a non-well-known port. You cannot specify a well-known port for a scripted
health check.
The matching-list-name variable is 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.
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.
ServerIronADX(config)#http match-list m1
ServerIronADX(config-http-m1-m1)#up simple "FTP service"
ServerIronADX(config-http-m1-m1)#default down
ServerIronADX(config-http-ml-m1)#exit
ServerIron ADX Server Load Balancing Guide
53-1003452-01
271
4
Health check with content match
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.
ServerIronADX(config)#healthck check1 tcp
ServerIronADX(config-hc-check1)#dest-ip 10.10.10.10
ServerIronADX(config-hc-check1)#port 1234 content-check m1
ServerIronADX(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 | 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 ServerIron ADX performs a Layer 7 health
check. If this command is omitted, the ServerIron ADX performs only a Layer 4 health check, and
not the scripted health check.
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 ServerIron 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 ServerIron ADX sends a SYN packet to server 10.10.1.31, port 1234.
On receiving a SYN-ACK from the server, the ServerIron ADX sends a TCP packet with the data "how
are you". The ServerIron ADX then waits for the server. In the data of the TCP packets sent by the
server, the ServerIron ADX will look for the pattern "good". If found, the ServerIron ADX marks the
real server r1 port 1234 as UP; otherwise, it will mark the port as DOWN.
ServerIronADX(config)#server real r1 10.10.1.31
ServerIronADX(config-rs-r1)#port 1234 keepalive
ServerIronADX(config-rs-r1)#port 1234 content-check m1
ServerIronADX(config-rs-r1)#port 1234 content-check send "how are you"
ServerIronADX(config-rs-r1)#exit
ServerIronADX(config)#http match-list m1
ServerIronADX(config-http-ml-m1)#up simple good
ServerIronADX(config-http-ml-m1)#default down
Syntax: [no] port port-name content-check match-list-name
272
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Health check with content match
4
Syntax: [no] port port-name content-check send "string"
NOTE
The l7-check command must be enabled in order for the ServerIron ADX to send the script. If the
l4-check command is configured, the ServerIron ADX will establish a TCP connection and then send
an RST.
Binary scripted health check
The scripted health check feature allows ServerIron 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 ServerIron 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.
ServerIronADX(config)#server real rs1 10.1.1.1
ServerIronADX(config-rs-rs1)#port 1111 content-check-carray m1
ServerIronADX(config-rs-rs1)#port 1111 content-check-carray send “0xe1,0xe2,0xe3,
0xe4”
ServerIronADX(config-rs-rs1)#port 1111 keepalive
ServerIronADX(config)#http match-list m1
ServerIronADX(config-http-m1-m1)#default down
ServerIronADX(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.
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 ServerIron ADX currently supports scripted health-checks on TCP ports. This feature adds
support for scripted health-checks on UDP ports.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
273
4
Boolean health checks
When scripted health-check is configured on a UDP port, the ServerIron 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.
ServerIronADX(config)#server real r1 10.10.1.31
ServerIronADX(config-rs-r1)#port 1234 keepalive
ServerIronADX(config-rs-r1)#port 1234 content-check m1
ServerIronADX(config-rs-r1)#port 1234 content-check send "how are you"
ServerIronADX(config)#http match-list m1
ServerIronADX(config-http-ml-m1)#up simple good
ServerIronADX(config-http-ml-m1)#default down
In the above example, the ServerIron ADX will send and UDP packet containing the ASCII string
"how are you." On receiving the reply, ServerIron ADX will search for the string "good." If found, it will
mark port 1234 UP, otherwise it will mark the port DOWN.
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 ServerIron 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.
NOTE
The ServerIron ADX does not support Boolean health checks with Direct Server Return (DSR).
Depending on the conditions you specify when you configure a health-check policy, the ServerIron
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
ServerIron 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.
1.
274
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).
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Boolean health checks
4
• 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 ServerIron 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.
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.
ServerIronADX(config)#healthck "httpsrvr" boolean
ServerIronADX(config-hc-httpsrvr)#and "check1" "check2"
ServerIron ADX Server Load Balancing Guide
53-1003452-01
275
4
Boolean health checks
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 ServerIron 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 ServerIron 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.
ServerIronADX(config-link-link3)#next-hop-mac-address 00e0.5208.dd8e vlan-id 40
The address 00e0.5208.dd8e is the MAC address of Link3's access router interface. The vlan-id
40 is the ServerIron ADXs 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.
ServerIronADX(config)#healthck check1 tcp
ServerIronADX(config-hc-check1)#dest-ip 10.10.10.50
ServerIronADX(config-hc-check1)#port http
ServerIronADX(config-hc-check1)#healthck check2 tcp
ServerIronADX(config-hc-check2)#dest-ip 10.10.10.20
ServerIronADX(config-hc-check2)#port http
ServerIronADX(config-hc-check2)#healthck check3 tcp
ServerIronADX(config-hc-check3)#dest-ip 10.10.10.30
ServerIronADX(config-hc-check3)#port http
ServerIronADX(config-hc-check3)#healthck check4 tcp
ServerIronADX(config-hc-check4)#dest-ip 10.10.10.40
ServerIronADX(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.
ServerIronADX(config-hc-check4)#healthck nested1 boolean
ServerIronADX(config-hc-nested1)#or check1 check2
276
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous health check settings
4
ServerIronADX(config-hc-nested1)#healthck nested2 boolean
ServerIronADX(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.
ServerIronADX(config-hc-nested2)#healthck checkall boolean
ServerIronADX(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.
Miscellaneous health check settings
Basing an alias port’s health on the health of its master port
Both SLB traffic handling and SLB state computation use the alias port state. 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 ServerIron 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 ServerIron ADX.
NOTE
The health checks for the alias ports must be enabled. Otherwise, the ServerIron ADX will not check
the master port’s state, and the alias port will not go down when the master port goes down.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
277
4
Miscellaneous health check settings
If you want to forward SLB traffic to an alias port only when the master port is ACTIVE, you can
configure the ServerIron ADX to base the alias port state on the master port state. 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.
ServerIronADX(config)#server port 8080
ServerIronADX(config-port-8080)#tcp keepalive use-master-state
Syntax: [no] tcp keepalive use-master-state
The command is entered at the port profile level.
NOTE
When you configure this command, the operational state of the alias port and master port are the
same. However, they can differ if the master port is disabled administratively and the alias port is
not disabled. In this case, no health checks is sent for the alias port and the ServerIron ADX cannot
detect a port failure. This is a misconfiguration and Brocade advises you to disable the alias port
whenever the master port is disabled. The same is true when the master port is unbound or deleted
with the alias port still has the virtual port binding.
NOTE
The SLB state of a virtual port is also referred to as SLB healthy or VIP healthy of virtual ports.
Basing a port’s health on the health of another port
You can configure the ServerIron ADX to base the health of a port that is not well-known to the
ServerIron ADX on the health of one of the following ports that are well-known to the ServerIron
ADX:
• DNS (port 53)
• FTP (port 21). Ports 20 and 21 both are FTP ports but on the ServerIron 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.
ServerIronADX(config-port-1234)#tcp keepalive port 80
Syntax: tcp | udp keepalive port TCP/UDP-portnum
The command in this example configures the ServerIron ADX to base the health of port 1234 on
the health of port 80 (HTTP). If the health of port 80 changes, the ServerIron ADX applies the
change to port 1234.
NOTE
You cannot base the health of a port well-known to the ServerIron ADX on the health of another port,
whether the port is well-known or not well-known.
278
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous health check settings
4
Reassign threshold
The reassign threshold specifies the number of contiguous inbound TCP-SYN packets a real server
can fail to respond to before the ServerIron 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 240.
The value of an application's reassign counter is reset to 0 when the ServerIron 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 name or ip 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:
ServerIronADX(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 ServerIron ADX assigns a default threshold value of 20.
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
ServerIron 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 SwitchBack (Direct Server Return)
configurations. The reassign counter is not incremented in such configurations. In a SwitchBack
configuration, traffic from the real server does not pass back through the ServerIron ADX. As a result,
the ServerIron ADX cannot monitor the TCP SYN ACKs from the server. Refer to “Configuring Direct
Server Return” on page 84.
NOTE
The ServerIron 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 ServerIron 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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
279
4
Miscellaneous health check settings
Preventing state flapping
You can prevent state flapping caused by the reassignment counter.
By default, the ServerIron 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 ServerIron 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 ServerIron ADX to mark otherwise healthy applications as failed. The applications
will remain unavailable for the amount of time it takes the ServerIron 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.
ServerIronADX(config)#server no-reassign-count
When you enter this command, the ServerIron ADX will stop incrementing the reassignment
counters for real server applications.
Syntax: [no] server no-reassign-count
FastCache
In typical TCS configurations, the ServerIron ADX uses cache responses that flow back through the
ServerIron ADX as a means to determine the health of the cache server.
When the ServerIron ADX receives cache responses to client requests sent to the cache by the
ServerIron ADX, the ServerIron ADX knows that the cache server is healthy. However, if the cache
server does not respond to client requests, the ServerIron ADX assumes that the cache server is
down and stops sending client requests to the cache server.
Some configurations might require responses from a cache server to select a path that does not
return through the ServerIron ADX. For example, if a cache server supports only one default path
and that path is to a gateway router, not to the ServerIron ADX, the cache server might send
responses to the clients through the default gateway instead of through the ServerIron ADX. In this
case, the ServerIron ADX assumes that the cache server has stopped responding even though the
cache server is still working normally.
You can override health checking on an individual server basis by enabling FastCache. This feature
allows the ServerIron ADX to continue using a cache server even if the server does not send
responses to client requests back through the ServerIron ADX. When you enable FastCache on a
cache server, the ServerIron ADX continues to send client requests to the cache server even if the
server does not respond through the ServerIron ADX.
280
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous health check settings
4
Globally disabling all health-check policies
You can easily disable all the health-check policies configured on the ServerIron ADX. To do so,
enter the following command at the global CONFIG level of the CLI.
ServerIronADX(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.
ServerIronADX(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 ServerIron 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 ServerIron ADX, the ServerIron ADX is able to receive replies to the
health checks.
However, if the topology is such that the ServerIron ADX and real servers are in different subnets or
the server reply is not guaranteed to pass back though the ServerIron ADX, you might need to use
source NAT and configure a source IP address. Source NAT and source IP addresses allow the
ServerIron ADX to have multiple subnet identities. Generally, the ServerIron ADX is a member of
only one subnet, the subnet that contains the ServerIron ADX’s management IP address. You can
place the ServerIron ADX into up to eight additional subnets by enabling source NAT and adding
source IP addresses to the ServerIron ADX.
Normally, the ServerIron 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 ServerIron 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 ServerIron ADX’s
management IP address.
For an example of how to configure source NAT and source IP addresses, refer to “Web hosting with
ServerIron ADX and real servers in different subnets” on page 534.
Best path to a remote server
NOTE
Brocade recommends that you use this feature whenever the ServerIron ADX is in the direct path
between the remote server and the default gateway.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
281
4
Miscellaneous health check settings
When the ServerIron ADX sends a health check to a remote server, the ServerIron ADX sends the
health check through the default gateway, because the remote server’s subnet is different from the
subnet of the ServerIron ADX’s management IP address. In some topologies, the ServerIron ADX’s
default gateway is not the most direct path to the remote server. Figure 26 shows an example.
FIGURE 26
Health check of remote server – learned MAC address is not used
In this example, the ServerIron ADX sends the health check through its default gateway. The default
gateway sends the health check back to the ServerIron ADX, because Router R1’s route to the
remote server lists the ServerIron 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 ServerIron 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 27 shows the simplified health check process.
FIGURE 27
Health check of remote server – learned MAC address is used
To enable the ServerIron ADX to use learned MAC addresses for sending health checks to remote
servers, enter the following command.
ServerIronADX(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
ServerIron 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 intiated 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 ServerIron ADX checks the source MAC to handle the
traffic initiated from the remote server. The ServerIron ADX may drop the return traffic in some
topologies like VRRP and VRRP-E redundant network topologies.
282
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous health check settings
4
In VRRP, the router may use the source MAC of the physical interface instead of the virtual interface
for the real server initiated traffic. This includes the data connection from the remote server back
to the client, which is an expected behavior for VRRP. However, for the ServerIron ADX to identify
traffic from the remote server, it has to come from the same source MAC as the one installed in the
show arp or show server real server-name output. The ServerIron ADX expects the return traffic
from the same VRRP vip MAC instead of the physical interface MAC, and if this is not the case, it will
drop the return traffic.
To enable the ServerIron ADX to check the source IP instead of source MAC to handle the traffic
from a remote server, enter the following command:
ServerIronADX(config)#server identify-server-by-ip
Syntax: [no] server identify-server-by-ip
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.
ServerIronADX(config)#server virtual-name-or-ip v1 10.1.1.1
ServerIronADX(config-virtual-server-v1) port 80
ServerIronADX(config-virtual-server-v1) port 80 minimum-servers 2
ServerIronADX(config-virtual-server-v1) bind http rs1 http rs2 http rs3 http rs4
http
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 retries
The ServerIron 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 ServerIron 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.
ServerIronADX(config)#server port 80
ServerIronADX(config-port-80) bringup-retries 10
ServerIron ADX will now bring port 80 up only after it has passed num number of health-checks.
Previously port 80 would have been marked as up after the first time it passes a health-check.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
283
4
Miscellaneous health check settings
Layer 4 and Layer 7 port bring-up interval
The ServerIron ADX brings a port up after it passes the configured health-check. The ServerIron
ADX allows you to configure a maximum time interval, during which the ServerIron ADX will wait for
the server to respond before marking the bringup attempt to fail and retrying. The Layer 4 bringup
interval is the maximum time that the ServerIron ADX waits for a SYN-ACK after sending the SYN to
the server. To configure the Layer 4 bring-up interval, use the l4-bringup-interval command.
The Layer 7 bring-up interval is the maximum time that the ServerIron ADX waits for a Layer-7
response from the server over a TCP connection. To configure the Layer 7 bring-up interval, use the
l7-bringup-interval command.
ServerIronADX(config)#server port 80
ServerIronADX(config-port-http)#l4-bringup-interval 10
ServerIronADX(config-port-http)#l7-bringup-interval 10
Syntax: [no] l4-bringup-interval seconds
Syntax: [no] l7-bringup-interval seconds
The seconds variable is the number of seconds for the wait time. Enter a number from 1 to 255.
These commands are also available under port-profile-range configuration mode.
Slow-start mechanism
When the ServerIron 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 ServerIron 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
Overview
The ServerIron 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 ServerIron 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.
284
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous health check settings
4
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 28 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 ServerIron ADX allows for the real
server increases over the slow-start period.
FIGURE 28
Slow-start mechanism for a real server
The graph on the left shows the rate at which the ServerIron 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 ServerIron
ADX allows a max-connection rate of 10 times the elapsed time. During this period, the
ServerIron ADX increases up to 10 new connections every second on the real server.
• At 21 seconds,the ServerIron ADX allows a max-connection rate of 20 times the elapsed time.
The ServerIron ADX increases the connections to 420 and from 22 seconds to 29 seconds, the
ServerIron 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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
285
4
Miscellaneous health check settings
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 ServerIron 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
ServerIron 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.
When a port on a real server becomes active, the ServerIron 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.
286
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous health check settings
4
Default port slow-start mechanism
By default, when a port is activated, the ServerIron ADX gives it 60 seconds of warm-up time. Over
this period, the ServerIron 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 29 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 ServerIron ADX allows for the port on the real server increases over the
slow-start period.
FIGURE 29
Default slow-start mechanism for a port
The graph on the left shows the rate at which the ServerIron ADX allows connections for a given
port on a real server, as follows:
• At the time the port is activated, the ServerIron ADX allows 10 connections. Then, up to
10 seconds, the ServerIron ADX allows the port up to 10 new connections every second.
• From 10 seconds to 20 seconds, the ServerIron ADX allows up to 20 new connections every
second.
• From 20 seconds to 30 seconds, the ServerIron ADX allows up to 30 new connections every
second.
• From 30 seconds to 40 seconds, the ServerIron ADX allows up to 40 new connections every
second.
• From 40 seconds to 50 seconds, the ServerIron ADX allows up to 50 new connections every
second.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
287
4
Miscellaneous health check settings
• From 50 seconds to 60 seconds, the ServerIron 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 ServerIron 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 ServerIron 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 ServerIron 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.
ServerIronADX(config)#server port 80
ServerIronADX(config-port-80)#slow-start 101 10 30 20 30 600
ServerIronADX(config-port-80)#exit
Syntax: slow-start list-id rate1 interval1 rate2 interval2 max-connections
288
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous health check settings
4
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 ServerIron 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 ServerIron 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.
ServerIronADX(config)#server real-name rs1 192.168.1.1
ServerIronADX(config-rs-rs1)#port http
ServerIronADX(config-rs-rs1)#port http slow-start 101
ServerIronADX(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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
289
4
Miscellaneous health check settings
Using the slow-start list defined above, the two graphs in Figure 30 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 ServerIron ADX
allows for real server rs1 increases over the slow-start period.
FIGURE 30
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 ServerIron 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 ServerIron 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 ServerIron 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 ServerIron
ADX allows up to the maximum number of connections for the server set by the
max-connections variable in the slow start list.
290
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous health check settings
4
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 ServerIron 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.
ServerIronADX(config) #server port 80
ServerIronADX(config-port-80)#slow-start 100 10 30 20 30 600
ServerIronADX(config-port-80)#slow-start 101 20 30 40 30 1500
ServerIronADX(config-port-80)#exit
ServerIronADX(config)#server port 443
ServerIronADX(config-port-80)#slow-start 101 20 60 40 120 2400
ServerIronADX(config-port-80)#exit
ServerIronADX(config)#server real-name rs2 192.168.1.2
ServerIronADX(config-rs-rs2)#port http
ServerIronADX(config-rs-rs2)#port http slow-start 100
ServerIronADX(config-rs-rs2)#exit
ServerIronADX(config)#server real-name rs3 192.168.1.3
ServerIronADX(config-rs-rs3)#port http
ServerIronADX(config-rs-rs3)#port http slow-start 101
ServerIronADX(config-rs-rs3)#port ssl
ServerIronADX(config-rs-rs3)#port ssl slow-start 101
ServerIronADX(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 287.
Globally disabling or re-enabling the slow-start mechanism
You can globally disable the mechanism. When you disable the slow-start mechanism, the
ServerIron 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.
ServerIronADX(config)#server no-slow-start
ServerIron ADX Server Load Balancing Guide
53-1003452-01
291
4
Miscellaneous health check settings
To globally re-enable slow-start, enter a command such as the following.
ServerIronADX(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.
ServerIronADX(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 ServerIron 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 ServerIron ADX no longer uses the default health check
methods for initial bringup and periodic health checks.
For the ServerIron 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 ServerIron ADX will continue to use whichever state is based on the health check during the
initial server bringup. The ServerIron 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.
ServerIronADX(config)#server port 80
ServerIronADX(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.
ServerIronADX(config)#server port 53
ServerIronADX(config-port-53)#udp keepalive enable
To enable health checking at the real server level, enter commands such as the following.
ServerIronADX(config)#server real-name R1 10.10.10.10
ServerIronADX(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 ServerIron ADX to use the
health-check policy you attach to the port.
292
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous health check settings
4
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 ServerIron 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 ServerIron 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 ServerIron ADX now sends
more bringup health-checks at a time (up to a maximum of 50). The actual number of
health-checks that the ServerIron ADX sends at any given instance depends on the number of
server ports that are in the testing state. The ServerIron 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 ServerIron 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 ServerIron 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 ServerIron
ADX, and at the first instance 30 of these have passed the Layer 2 and Layer 3 checks, the
ServerIron 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 ServerIron 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 ServerIron ADX got responses from all the 50 server ports, it now sends bringup
health-checks for the remaining five server ports. The ServerIron 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 ServerIron 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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
293
4
Miscellaneous health check settings
Configuration
To turn on this feature, use the hc-track-port command under the real server configuration as
shown:
ServerIron
ServerIron
ServerIron
ServerIron
ServerIron
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
The ServerIron 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:
ServerIronADX#show hc-track-port-state
Real Server
track-port
state
rs1
80 21 800 53
ACTIVE
ServerIronADX#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
294
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Sample show commands
4
Sample show commands
Syslog for health status change
The ServerIron 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 ServerIron ADX, enter the following command.
ServerIronADX(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
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 ServerIron ADX logs the event as shown in this
example.
Health checks for firewall paths
Changing the maximum number of Layer 3 path health-check retries
By default, the ServerIron ADX checks the health of each firewall and router path by sending an
ICMP ping on the path every 400 milliseconds. If the ServerIron ADX receives one or more
responses within 1.2 seconds, it concludes that the path is healthy. Otherwise, the ServerIron ADX
reattempts the health check by sending another ping. By default, the ServerIron ADX reattempts an
unanswered path health check up to three times before concluding that the path is unhealthy.
You can change the maximum number of retries to a value from 3 through 31 (ServerIron ADX
Chassis devices) or 8 through 31 (all other ServerIron ADX models).
To change the maximum number of FWLB path health check attempts, enter a command such as
the following at the firewall level of the CLI.
ServerIronADX(config-tc-2)#fw-health-check icmp 20
Syntax: [no] fw-health-check icmp num
The num variable specifies the maximum number of retries and can be a number from 3 through
31. The default is 3.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
295
4
Sample show commands
Enabling Layer 4 path health checks for FWLB
By default, the ServerIron ADX performs Layer 3 health checks of firewall paths, but not Layer 4
health checks. You can configure a ServerIron ADX in an FWLB configuration to use Layer 4 health
checks instead of Layer 3 health checks for firewall paths. When you configure a Layer 4 health
check, the Layer 3 (ICMP) health check, which is used by default, is disabled.
NOTE
The Layer 4 health check applies only to firewall paths. The ServerIron ADX always uses a Layer 3
(ICMP) health check to test the path to the router.
When you configure a Layer 4 health check for firewall paths, the ServerIron ADX sends Layer 4
health checks and also responds at Layer 4 to health checks from the ServerIron ADX at the other
end of the firewall path.
To configure a Layer 4 health check, specify the protocol (TCP or UDP). Optionally, you also can
specify the port:
• UDP – The ServerIron ADX sends and listens for path health check packets on the port you
specify. If you do not specify a port, the ServerIron ADX uses port 7777 by default. The port
number is used as both the source and destination UDP port number in the health check
packets.
• TCP – The ServerIron ADX listens for path health check packets on the port you specify, but
sends them using a randomly generated port number. If you do not specify a port, the
ServerIron ADX uses port 999 as the destination port by default.
NOTE
You must configure the same Layer 4 health check parameters on all the ServerIrons in the FWLB
configuration. Otherwise, the paths will fail the health checks.
To configure a Layer 4 health check for firewall paths, enter a command such as the following at
the firewall group configuration level.
ServerIronADX(config-tc-2)#fw-health-check udp
The command in this example enables Layer 4 health checks on UDP port 7777. This ServerIron
ADX sends firewall path health checks to UDP port 7777 and listens for health checks on UDP port
7777.
Syntax: [no] fw-health-check udp | tcp [TCP/UDP-portnum num]
The TCP/UDP-portnum num variable specifies the TCP or UDP port. It can be a number in one of
the following ranges:
• For TCP, from 1 through 65535
• For UDP, from 1 through 1032 or 2033 through 65535
NOTE
Do not use a number from 1033 through 2032 for UDP. Port numbers in this range are not
supported for FWLB UDP health checks.
The num variable specifies the maximum number of retries. It can be a number from 1 – 31.
The default is 3.
296
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Sample show commands
4
Disabling Layer 4 health checks for FWLB
When you add an application port to a firewall definition, the ServerIron ADX automatically enables
the Layer 4 health check for that port. You must disable the Layer 4 health check if the firewall is
unable to act as a proxy for the application and respond to the health check. If the firewall does not
respond to the health check, the ServerIron ADX assumes that the port is unavailable and stops
sending traffic for the port to the firewall.
To disable the Layer 4 health check for an individual application on an individual firewall, enter a
command such as the following at the firewall configuration level of the CLI.
ServerIronADX(config-rs-FW1)#port http no-health-check
Syntax: port [port-type | port-number] no-heath-check
The port-type variable specifies the port type that you want to disable from Layer 4 health check. It
can any of the following values:
• dns – This option disables port 53 from health check.
• ftp – This option disables port 21 from health check. Ports 20 and 21 both are FTP ports
but in the ServerIron ADX, the name “ftp” corresponds to port 21.
•
•
•
•
•
•
•
•
•
http – This option disables port 80 from health check.
•
•
•
•
•
smtp – This option disables port 25 from health check.
imap4 – This option disables port 143 from health check.
ldap – This option disables port 389 from health check.
nntp – This option disables port 119 from health check.
ntp – This option disables port 123 from health check.
pop2 – This option disables port 109 from health check.
pop3 – This option disables port 110 from health check.
radius – This option disables UDP port 1812 from health check.
radius-old – This option disables UDP port 1645 from health check. UDP port 1645, is
used in some older RADIUS implementations instead of port 1812.
snmp – This option disables port 161 from health check.
ssl – This option disables port 443 from health check.
telnet – This option disables port 23 from health check.
tftp – This option disables port 69 from health check.
In addition, you can specify a port number in the port-number variable for ports other than
those with name options.
Session table parameters
The ServerIron 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 ServerIron ADX and
a client or real server. The ServerIron 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
ServerIron ADX Server Load Balancing Guide
53-1003452-01
297
4
Sample show commands
• 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 ServerIron 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 ServerIron ADX chassis, use the
following command.
ServerIronADX(config)#server session-asm-limit 50000
Syntax: server session-asm-limit value
For this change to take effect, you must save the change to the startup-config file, then reload the
software using the following commands.
ServerIronADX(config)#write memory
ServerIronADX(config)#end
ServerIronADX#reload
Configuring fast session aging
ServerIron ADX supports fast session aging. When fast session aging is enabled with the server
session-max-idle command, the ServerIron 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 ServerIron 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 ServerIron 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.
298
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Sample show commands
4
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.
ServerIronADX(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 ServerIron ADX.
The value specified for the fast-age-threshold can be from 10 through 70 percent. The default is 33
percent.
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 ServerIron 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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
299
4
Sample show commands
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.
ServerIronADX#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.
ServerIronADX(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.
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.
ServerIronADX(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.
300
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Sample show commands
4
Configuring TCP age
The TCP age specifies how many minutes a TCP server connection can remain inactive before the
ServerIron 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 248.
To modify the server TCP age, enter a command such as the following.
ServerIronADX(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.
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.
ServerIronADX(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 248.
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 ServerIron 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 ServerIron 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 160.
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 160.) The default UDP age will always be 2 minutes unless the
udp-normal-age option is configured.
Setting the clock scale
The ServerIron 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.
ServerIronADX(config)#server clock-scale 2
ServerIron ADX Server Load Balancing Guide
53-1003452-01
301
4
Sample show commands
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 ServerIron 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)
Internet (applies to TCS only)
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
Internet
The "Internet" parameter at the end of the message applies only to TCS, and indicates that the
ServerIron ADX sent the client request to the Internet instead of to a cache server.
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 ServerIron ADX does not create session table entries for the port
and therefore does not generate log messages for the port.
302
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Sample show commands
4
Enabling TCP/UDP session logging
When TCP/UDP session logging is enabled, the ServerIron 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.
ServerIronADX(config)#server connection-log all
To enable logging only for new sessions that are used for Source NAT, enter the following command.
ServerIronADX(config)#server connection-log src-nat
To enable session logging for a specific TCP or UDP port, enter the following command.
ServerIronADX(config)#server port 80
ServerIronADX(config-port-80)#connection-log all url cookie
Syntax: [no] server connection-log all | src-nat [url] [cookie]
NOTE
The all option enables logging for all sessions.
NOTE
The src-nat option enables logging only for sessions that are used for Source NAT.
NOTE
The url option enables logging of URL information for sessions that contain a URL. This option
applies only when URL switching is enabled.
NOTE
The cookie option enables logging of cookie information for sessions that contain a cookie.This
option applies only when cookie switching is enabled.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
303
4
304
Sample show commands
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Chapter
Layer 7 Content Switching
5
Layer 7 content switching overview
Layer 7 switching allows the ServerIron ADX to make forwarding decisions about HTTP traffic based
on information in a URL, cookie, or SSL session ID. Advanced Layer 7 content switching allows the
ServerIron to make forwarding decisions about HTTP traffic by analyzing information contained
within the traffic. CSW also enables Layer 7 application content based traffic direction for non-HTTP
protocols such as Financial Information Exchange (FIX) protocol.
The advanced Layer 7 content switching provides an enhancement over the Layer 7 switching
feature available in previous ServerIron 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
Support for persisting requests to servers, along with simple forwarding actions.
Support for content-rewrite functions, including cookie and HTTP header insertion and
deletion.
NOTE
You cannot use FWLB and the features described in this chapter on the same ServerIron ADX.
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
You cannot enable URL switching and Layer 7 content switching simultaneously on the same virtual
server.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
305
5
Configuring Layer 7 content switching
NOTE
Alias ports should be treated like regular ports and should have the same server ID and group ID
NOTE
If content switching is enabled on the ServerIron ADX, and source-NAT is enabled globally, then the
446 (IPv4 client --> IPv4 VIP --> IPv6 real server) traffic mode is also source natted.
NOTE
If content switching (csw) is enabled and if source-NAT is globally configured, then 446 Layer 7 HTTP
traffic is also source natted. If csw is not enabled and the source-NAT is globally configured, then the
IPv6 prefix for 446 traffic will take precedence.
Configuring Layer 7 content switching
To configure Layer 7 content switching, you define content switching rules and policies. A rule
specifies the content that the ServerIron ADX looks for in the incoming traffic, and a policy
associates rules with one or more actions that specify how the ServerIron ADX handles traffic
matching the rule.
The following sections explain how to configure Layer 7 content switching on a ServerIron ADX
Chassis device 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.
ServerIronADX(config)#server virtual-name-or-ip cswVIP 192.168.20.254
ServerIronADX(config-vs-cswVIP)#port http csw-policy p1
ServerIronADX(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 313.
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 ServerIron ADX scans for the content. The
ServerIron ADX scans up to the specified limit. If you do not specify a scan depth, then the
ServerIron ADX scans to the end of the packet.
To specify the scan depth for HTTP content, enter commands such as the following:
ServerIronADX(config)#server virtual-name-or-ip cswVIP 192.168.20.254
ServerIronADX(config-vs-cswVIP)#port http csw-scan-depth 128
ServerIronADX(config-vs-cswVIP)#port http csw
Syntax: [no] port portnum csw-scan-depth length
306
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Configuring Layer 7 content switching
5
The length variable specifies the number of bytes the ServerIron ADX scans for content in a packet.
You can specify up to 8192 bytes. By default, the ServerIron 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 ServerIron 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. In version 12.4.00, if
the next request from the same client connection is forwarded within the same server group, the
ServerIron 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 ServerIron ADX will follow the current code behavior to perform server section.
The following command sets the behavior back to pre-12.4.00 behavior which enables use of a
load balancing predictor.
ServerIronADX(config)#server csw request-load-balance
Syntax: [no] server csw request-load-balance
Use the no form of this command if you have previously enabled the command and want to remove
it.
Put simply, if the client sends two requests to the ServerIron ADX in the same connection and these
two requests are switched to the same group, with server csw request-load-balance command
configured, CSW will do server selection based on load balance predictor; without this command
configured, CSW will still use the same server used by the first client request for the second one.
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 ServerIron 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 308.
• HTTP version rules – Cause the ServerIron 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 309.
• URL rules – Cause the ServerIron 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 309.
• HTTP header rules – Cause the ServerIron 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 310.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
307
5
Configuring Layer 7 content switching
• XML tag rules – Cause the ServerIron 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 311.
In addition, you can combine rules with logical operators AND, OR, and NOT to create nested rules.
Refer to “Define a nested rule (optional)” on page 363.
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 ServerIron ADX to make a load balancing decision
based on the HTTP method in an incoming packet, enter a command such as the following.
ServerIronADX(config)#csw-rule r1 method eq PUT
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 value 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.
308
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Configuring Layer 7 content switching
5
Configuring an HTTP version rule
To set up an HTTP method rule that causes the ServerIron ADX to make a load balancing decision
based on the HTTP version of an incoming packet, enter a command such as the following.
ServerIronADX(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 value 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 ServerIron 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
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"
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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
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"
309
5
Configuring Layer 7 content switching
HTTP header rules
HTTP header rules cause the ServerIron 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
310
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"
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"
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Configuring Layer 7 content switching
5
XML tag rules
XML tag rules cause the ServerIron 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
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"
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"
ServerIron ADX Server Load Balancing Guide
53-1003452-01
311
5
Configuring Layer 7 content switching
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.
ServerIronADX(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 optional case-insensitive keyword specifies the pattern match to be case insensitive.
The following example shows how to configure a case-insensitive policy.
ServerIronADX(config)#csw-policy p1 case-insensitive
Syntax: csw-policy policy-name case-insensitive
The optional case-insensitive keyword 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.
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 ServerIron ADX to forward packets matching a specified rule to a
specified real server or server group. Refer to “Configuring the forward action” on page 313.
• Reply-error action – Causes the ServerIron 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 316.
• Log action – Causes the ServerIron 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 316.
• Redirect action – Causes the ServerIron ADX to redirect a request to an alternate domain, URL,
or port when the specified rule is matched. Refer to “Configuring redirect” on page 328.
• Persist action – causes the ServerIron 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 314.
312
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Configuring Layer 7 content switching
5
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.
ServerIronADX(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 ServerIron 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.
ServerIronADX(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.
NOTE
The real server ID range is limited to 1024-1+the maximum number of real servers that can be
configured on the ServerIron ADX model. 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 ServerIron 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. Refer to
"Configuring Cookie Switching" in the ServerIron ADX for more information.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
313
5
Configuring Layer 7 content switching
Configuring the persist action
The persist action causes the ServerIron ADX to send requests with similar content to the same
server when the specified rule is matched. When a rule is matched, the ServerIron 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.
ServerIronADX(config)#csw-rule r1 header "cookie" search "ServerId"
The persist action can then be used in conjunction with the above CSW rule.
2. The ServerIron ADX examines the matched content to determine the persist string. The persist
string contains the portion after the matched string that the ServerIron 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 ServerIron ADX uses the persist string along with the configured persist method to select a
real server or group. By default, the ServerIron ADX uses a hash-to-bucket persist method to
select a real server.
The hash-to--bucket persist method is illustrated in the following figure.
FIGURE 31
314
Hash-to-bucket persist method
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Configuring Layer 7 content switching
5
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 ServerIron 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.
ServerIronADX(config)#csw-rule r1 header host exists
ServerIronADX(config)#csw-policy p1
ServerIronADX(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 ServerIron 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 terminator string variable specifies the substring with which the persist string ends.
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 31. 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 ServerIron 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 ServerIron ADX falls back to
the sticky persistence configured for the address.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
315
5
Configuring Layer 7 content switching
Configuring the reply-error action
The reply-error action causes the ServerIron ADX to send a 403 error code page back to the client
when the specified rule is matched.
For example, to cause the ServerIron ADX to send a 403 error code page to a client that sent a
packet that matched rule r1, enter the following command.
ServerIronADX(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 SI (show logging). 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 ServerIron ADX to write a message to Syslog when rule r1 is matched, enter a
command such as the following:
ServerIronADX(config-csw-policy1)#match r1 log
Syntax: [no] match rule-name log [format]
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
$CNT – Matched content, such as the matched method, URL, version, or HTTP header. THis
option is only supported when using TCP/UDP Content Switching.
For example, the following command specifies an alternate format for the Syslog message:
ServerIronADX(config-csw-policy1)#match r1 log "$SIP:$SPT->$DIP:$DPT,ru $RUL hit
$ACT"
316
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Configuring Layer 7 content switching
5
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 ServerIron 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 cookie-insert 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 ServerIron ADX to insert the cookie indicated by
the rewrite cookie-insert command into the HTTP response when rule r1 is matched.
ServerIronADX(config-csw-policy1)#match r1 rewrite insert-cookie
Syntax: [no] match rule-name rewrite insert-cookie
Deleting a cookie
Cookie deletion causes the ServerIron ADX to delete the cookies that it set. The ServerIron removes
the cookie from the HTTP request prior to sending the request to the server.
For example, the following command causes the ServerIron ADX to delete the cookie indicated by
the rewrite cookie-insert command from the HTTP response when rule r1 is matched.
ServerIronADX(config-csw-policy1)#match r1 rewrite delete-cookie
Syntax: [no] match rule-name rewrite delete-cookie
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 ServerIron ADX.
For example, the following command causes the ServerIron ADX to damage the cookie indicated by
the rewrite cookie-insert command in the HTTP response when rule r1 is matched.
ServerIronADX(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 ServerIron 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).
ServerIron ADX Server Load Balancing Guide
53-1003452-01
317
5
Configuring Layer 7 content switching
To cause the ServerIron ADX to insert a standard HTTP “Via:” header into HTTP requests matching
rule r1, enter the following command.
ServerIronADX(config-csw-p1)#match r1 rewrite request-insert header "Via:
ServerIron ADX"
Syntax: [no] match rule-name rewrite request-insert header header
The header variable specifies the string that will be inserted.
To cause the ServerIron ADX to insert the header "SI-ADX: proto=HTTP+MMS" into the HTTP
responses (matching rule r1) that it sends from the virtual server, enter the following command.
ServerIronADX(config-csw-policy1)#match r1 rewrite response-insert header
"SI-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 ServerIron 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 ServerIron 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 ServerIron ADX to insert the IP address of the connecting client into HTTP requests
matching rule r1, enter the following command.
ServerIronADX(config-csw-policy1)#match r1 rewrite request-insert client-ip
"MyClientIP"
Syntax: [no] match rule-name rewrite request-insert client-ip header
Inserting a client certificate into an HTTP request
HTTP Header insertion can direct the ServerIron ADX to insert a client certificate that you specify
into the HTTP requests it receives on a virtual server that matches a CSW rule you define.
The following configuration of CSW policy "p1" directs the ServerIron ADX to insert the entire
certificate chain in HTTP requests it receives on a virtual server that match the "r1" CSW rule and to
set the prefix header to "SSL".
ServerIronADX(config)#csw-policy p1
ServerIronADX(config-csw-p1)#match r1 rewrite request-insert client-cert
entire-chain
ServerIronADX(config-csw-p1)#match r1 rewrite request-insert client-cert
certheader-prefix "SSL"
Syntax: [no] match rule-name rewrite request-insert client-cert entire-chain | leaf-cert |
wellknown-fields | certheader-prefix prefix-header
318
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Configuring Layer 7 content switching
5
The entire-chain parameter directs the switch to insert the entire certificate chain. It is in PEM
format and BASE64 encoded. The header name is Client-cert. Refer to Table 33 for details.
The leaf-cert parameter directs the switch to insert only the leaf certificate in the certificate chain.
It is in PEM format and BASE64 encoded. The header name is Client-cert. Refer to Table 33 for
details.
The wellknown-fields parameter directs the switch to insert only the well-known fields described in
Table 27. These fields are in ASCII format.
The certheader-prefix parameter directs the switch to set the header prefix of the header listed in
Table 26 or Table 27 to the value specified by the prefix-header variable. For example, if you define
the prefix-header variable to the well known prefix "SSL", the "Client-Cert" header becomes
"SSL-Client-Cert".
TABLE 26
Header inserted when entire-chain or leaf-cert is configured
This field
Displays
Client-Cert
The entire client certificate chain or the leaf certificate.
TABLE 27
Header inserted when well-known fields are configured
Field
Displays
Client-Cert-Version
Version of the client certificate.
Client-Cert-Serial
Serial number of the client certificate.
Client-Cert-Start
Date certificate not valid before.
Client-Cert-End
Date certificate not valid after.
Client-Cert-Subject
Subject’s distinguished name.
Client-Cert-Subject-CN
Subject’s common name.
Client-Cert-Subject-Alt-CN
Subject’s alternate name.
Client-Cert-Issuer
Issuer’s distinguished name.
Client-Cert-Issuer-CN
Issuer’s common name.
Client-Cert-Data-Signature-Algorithm
Hashing and encryption method.
Client-Cert-Signature-Algorithm
Certificate signature algorithm.
The following example configures the CSW policy "p1" to insert the entire certificate chain in HTTP
requests it receives on a virtual server and to insert the "SSL" as the certificate header prefix.
ServerIronADX(config)#csw-policy p1
ServerIronADX(config-csw-p1)#match r1 rewrite request-insert header entire-chain
ServerIronADX(config-csw-p1)#match r1 rewrite request-insert header
cert-header-prefix "SSL"
Configuring Rewrite request-delete
HTTP URL Rewrite allows the ServerIron ADX to delete a string or portion of a string from inside the
incoming client request. The following options are described:
• “Deleting a matched-string” on page 320
• “Deleting content at positive offset” on page 321
ServerIron ADX Server Load Balancing Guide
53-1003452-01
319
5
Configuring Layer 7 content switching
• “Deleting content at negative offset” on page 322
• “Deleting a string” on page 323
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.
ServerIronADX(config)#csw-rule r11 url pattern "-sample"
Syntax: csw-rule rule-name url pattern url-content
2. Define a CSW policy.
ServerIronADX(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.
ServerIronADX(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.
ServerIronADX(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.
ServerIronADX(config-csw-mypolicy)#match r11 log
Syntax: match rule-name log
6. Specify a default action.
ServerIronADX(config-csw-mypolicy)#default forward 1026
Syntax: default forward server-id
NOTE
The following section assumes you have already completed the previous configuration.
If the ServerIronADX 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.
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.
320
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Configuring Layer 7 content switching
5
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 328.
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.
ServerIronADX(config)#csw-rule r12a url prefix "/abc"
Syntax: csw-rule rule-name url prefix prefix-content
2. Define a CSW policy.
ServerIronADX(config)#csw-policy mypolicy
Syntax: csw-policy policy-name
3. Specify a primary action.
ServerIronADX(config-csw-mypolicy)#match r12a forward 1025
Syntax: match rule-name forward server-id
4. Specify a dependent rewrite action.
ServerIronADX(config-csw-mypolicy)#match r12a rewrite request-delete offset 4
2
Syntax: match rule-name rewrite request-delete offset offset length
NOTE
The following section assumes you have already completed the previous configuration.
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
ServerIron ADX Server Load Balancing Guide
53-1003452-01
321
5
Configuring Layer 7 content switching
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 328.
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.
ServerIronADX(config)#csw-rule r12b url suffix ".html"
Syntax: csw-rule rule-name url suffix content
2.
Define a CSW policy.
ServerIronADX(config)#csw-policy mypolicy
Syntax: csw-policy policy-name
3. Specify a primary action.
ServerIronADX(config-csw-mypolicy)#match r12b forward 1025
Syntax: match rule-name forward server-id
4. Specify a dependent rewrite action.
ServerIronADX(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 section 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.
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
322
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Configuring Layer 7 content switching
5
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 328.
To configure a request to delete a sub-string in a CSW rule, follow these steps.
1. Define a CSW rule.
ServerIronADX(config)#csw-rule r13 url exists
Syntax: csw-rule rule-name url exists
2. Define a CSW policy.
ServerIronADX(config)#csw-policy mypolicy
Syntax: csw-policy policy-name
3. Specify a primary action.
ServerIronADX(config-csw-mypolicy)#match r13 forward 1025
Syntax: match rule-name forward server-id
4. Specify a dependent rewrite action.
ServerIronADX(config-csw-mypolicy)#match r13 rewrite request-delete string
"123"
Syntax: match rule-name rewrite request-delete string string-content
NOTE
The following section 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
\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
ServerIron ADX Server Load Balancing Guide
53-1003452-01
323
5
Configuring Layer 7 content switching
Configuring Rewrite request-insert
Content insertion allows the ServerIron 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 328.
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.
ServerIronADX(config)#csw-rule r21 url prefix "/abc"
Syntax: csw-rule rule-name url prefix prefix-content
2. Define a CSW policy.
ServerIronADX(config)#csw-policy mypolicy
Syntax: csw-policy policy-name
3.
Specify a primary action.
ServerIronADX(config-csw-mypolicy)#match r21 forward 1025
Syntax: match rule-name forward server-id
4. Specify a dependent rewrite string.
ServerIronADX(config-csw-mypolicy)#match r21 rewrite request-insert
/hello-world
Syntax: match rule-name rewrite request-insert content offset
NOTE
The following section assumes you have already completed the previous configuration.
NOTE
If no offset is defined, the ServerIronADX 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".
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
324
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Configuring Layer 7 content switching
5
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.
ServerIronADX(config)#csw-rule r22 url prefix /abc/
Syntax: csw-rule rule-name url prefix prefix-content
2. Define a CSW policy.
ServerIronADX(config)#csw-policy mypolicy
Syntax: csw-policy policy-name
3.
Specify a primary action.
ServerIronADX(config-csw-mypolicy)#match r22 forward 1025
Syntax: match rule-name forward server-id
4.
Specify a dependent rewrite action.
ServerIronADX(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 section 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 "/".
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
ServerIron ADX Server Load Balancing Guide
53-1003452-01
325
5
Configuring Layer 7 content switching
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.
Replacingf 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.
ServerIronADX(config)#csw-rule r31 url exist
Syntax: csw-rule rule-name url exist
2.
Define a CSW policy
ServerIronADX(config)#csw-policy mypolicy
Syntax: csw-policy policy-name
3. Specify a primary action.
ServerIronADX(config-csw-mypolicy)#match r31 forward 1025
Syntax: match rule-name forward server-id
4.
Specify a dependent rewrite action.
ServerIronADX(config-csw-mypolicy)#match r31 rewrite request-replace
matched-string "/newabc/newxyz/newindex.html"
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 section 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
326
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Configuring Layer 7 content switching
5
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.
ServerIronADX(config)#csw-rule r32 url pattern "abc"
Syntax: csw-rule rule-name url pattern pattern-content
2. Define a CSW policy
ServerIronADX(config)#csw-policy mypolicy
Syntax: csw-policy policy-name
3.
Specify a primary action.
ServerIronADX(config-csw-mypolicy)#match r32 forward 1025
Syntax: match rule-name forward server-id
4.
Specify a dependent rewrite action
ServerIronADX(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.
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 section 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
ServerIron ADX Server Load Balancing Guide
53-1003452-01
327
5
Configuring Layer 7 content switching
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 ServerIron 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 ServerIron ADX to redirect a request to the domain
brocade.com, URL
/home/index.html, and port 8080 when rule r1 is matched.
ServerIronADX(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 url new-port, enter the new URL and port number to which the request will be redirected.
HTTP redirect status code
The ServerIron 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.
ServerIronADX(config)#csw-policy p1
ServerIronADX(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 ServerIron 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
328
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Sample configurations
5
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 ruleE header "Host" equal "www.example5.com"
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 ServerIron 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 ServerIron 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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
329
5
Sample configurations
• 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.
CSW topology
Figure 32 shows a simple CSW network topology.
FIGURE 32
CSW network topology
For the CSW configuration shown in Figure 32, the following rules apply:
• The ServerIron receives incoming traffic on HTTP port, VIP 10.1.1.100.
• The ServerIron 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 ServerIron 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 ServerIron takes the default action, sending the HTTP request to
Web Server 2 with server ID 1026 and IP address 10.1.1.2.
330
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Sample configurations
5
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 331
“Configuring real and virtual servers” on page 332
“Enabling content switching” on page 333
“HTTP URL Rewrite configuration summary” on page 333
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.
ServerIronADX(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.
ServerIronADX(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.
ServerIronADX(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.
ServerIronADX(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.
ServerIronADX(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 380.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
331
5
Sample configurations
6. Enable logging for this rule.
ServerIronADX(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.
ServerIronADX(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.
ServerIronADX(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.
NOTE
For more information about offsets, refer to “Explanation of offsets” on page 328.
9. Specify default action for client requests that do not match any other rules. Send such
requests to the Web server with ID 1026.
ServerIronADX(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.
ServerIronADX(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.
ServerIronADX(config-rs-web1)#port http
Syntax: port http
3. Define a real server (2) with an IP address.
ServerIronADX(config-rs-web1)#server real web2 10.1.1.2
Syntax: server real real-server ip-address
332
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Sample configurations
5
4. Define a real HTTP port on the real server and exit.
ServerIronADX(config-rs-web2)#port http
ServerIronADX(config-rs-web2)#exit
Syntax: port http
Syntax: exit
5. Define a virtual server with an IP address.
ServerIronADX(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.
ServerIronADX(config-vs-csw-vip)#port http
Syntax: port http
7.
Bind HTTP ports on real servers web1 and web2 to the virtual port HTTP.
ServerIronADX(config-vs-csw-vip)#bind http web1 http web2 http
Syntax: bind http real-server http vip-name
Enabling content switching
To enable content switching, follow these steps.
1. Bind the policy to virtual HTTP port on virtual server.
ServerIronADX(config-vs-csw-vip)#port http csw-policy mypolicy
Syntax: port http csw-policy policy-name
2. Enable CSW on the virtual port.
ServerIronADX(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
ServerIron ADX Server Load Balancing Guide
53-1003452-01
333
5
Layer 7 content switching on HTTP response
#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
Layer 7 content switching on HTTP response
The ServerIron ADX can perform content rewrite on the server responses. In other words, the
ServerIron 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 ServerIron
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 33 shows such a scenario
when the Real-Server is not aware of the SSL-Offload but sends a redirect using HTTP. The
ServerIron 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 33
HTTP response header rewrite
A ServerIron 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 ServerIron 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.
334
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Layer 7 content switching on HTTP response
5
3. Create a CSW policy.
4. Bind the CSW policy to the virtual server port.
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.
ServerIronADX(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.
ServerIronADX(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."
ServerIronADX(config)#csw-policy "p1" type response-rewrite
ServerIronADX(config-rew-p1)#match "r1" rewrite response-insert header
ServerIronADXconfig-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 SSL, but can also be applied on port HTTP.
ServerIronADX(config)#server virtual-name-or-ip v1 10.1.1.10
ServerIronADX(config-vs-v1)#port ssl response-rewrite-policy "p22"
Syntax: port port-type response-rewrite-policy policy-name
ServerIron ADX Server Load Balancing Guide
53-1003452-01
335
5
Layer 7 content switching on HTTP response
In this configuration, the ServerIron 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 ServerIron 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 /"
Response body rewrite
The response body rewrite feature can be used in multiple scenarios. The most commonly used
scenario is when a web-site wants a seamless upgrade to SSL-Offload. Before this release, the
Real-Servers had to change embedded links using SSL to be replaced from "http://" to "https://",
but now instead of making all these changes on the real-servers, they can be made on the
ServerIron.
NOTE
Response body rewrite only works for uncompressed contend delivered from the real servers.
Configuring HTTP body response rewrite
To enable response-header-rewrite, follow these steps:
1. Creating a CSW-Rule specifying the response codes to be acted upon.
2. Creating a CSW-Rule specifying the URLs to be modified.
3. Creating a CSW-Policy.
4. Binding a CSW-Policy to the virtual-server port.
Creating a CSW rule identifying requests whose responses must be modified
In this step, the requests are identified, and responses to the requests are eligible for response
modifications. To specify all requests with responses that need to be modified, use the following
command.
ServerIronADX(config)#csw-rule r2 url exists
Syntax: csw-rule rule-name url exists
336
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Layer 7 content switching on HTTP response
5
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 the response body.
For example, if you intend to modify http://www.example6.com to https://www.example6.com, use
the following command.
ServerIronADX(config)#csw-rule r21 response-body pattern
"http://www.example6.com/"
Syntax: no] csw-rule rule-name response-body pattern pattern to be found
Creating a CSW policy
After you define the rules, you must add the rules to a CSW policy. The policy type response-rewrite
must be used to distinguish the response-rewrite policy from the original CSW policies such as
request-rewrite.
When the two rules configured in step 1 and step 2 are added to this policy, the first rule ensures
that the policy acts on all HTTP requests. The second rule matches the string
"http://www.example6.com" in the response body 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 be modified. in this case, the offset would have been 0 with length 4
and the new string "https."
ServerIronADX(config)#csw-policy "p22" type response-rewrite
ServerIronADX(config-rew-p22)#match "r2" response-body-rewrite
ServerIronADX(config-rew-p22)#match "r21" rewrite response-body-replace
"https://www.example6.com/" offset 0 length 19
Syntax: 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 on the incoming traffic by binding it to a virtual port. This
type of policy is usually applied on port SSL, but can also be applied on port HTTP.
ServerIronADX(config)#server virtual-name-or-ip v1 10.1.1.10
ServerIronADX(config-vs-v1)#port ssl response-rewrite-policy "p22"
Syntax: port port-type response-rewrite-policy policy-name
Using show commands
To show statistics of this feature, enter a command such as the following on the BP console.
ServerIronADX#show csw-policy p1
Syntax: show csw-policy policy-name
ServerIron ADX Server Load Balancing Guide
53-1003452-01
337
5
Using multiple cookies under virtual server port
Configuration example
This configuration replaces all references to http://www.example6.com with
https://www.example6.com in all response data. In other words, the data
"href='http://www.example6.com/index.html" becomes
"href=https://www.example6.com/index.html".
csw-rule r2 url exists
csw-rule r21 response-body pattern http://www.example6.com/
csw-policy "p1" type response-rewrite
match "r2" response-body-rewrite
match "r21" rewrite response-body-replace "https://www.example6.com/" offset 0
length 19
server real rs1 10.1.1.101
port http
port http url "HEAD /"
server real rs2 10.1.1.102
port http
port http url "HEAD /"
server virtual-name-or-ip v1 10.1.1.10
port ssl
port ssl response-rewrite-policy p1
bind ssl rs1 http rs2 http
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 ServerIron 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 ServerIron, 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 cookie-insert [cookie-name [domain [path [age]]]]
If l7-dont-use-gateway-mac 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.
338
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Using multiple cookies under virtual server port
5
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 l7-dont-use-gateway-mac command and does not need spoofing
configured. But for l7-dont-use- gateway-mac command to work, spoofing is required
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 ServerIron 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 ServerIron will take action based on the
cookie value; otherwise, it follows other matched rules, in which possibly a cookie insertion is
triggered.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
339
5
Using multiple cookies under virtual server port
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
Example
The ServerIron 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, ServerIron 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.
340
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Server passive cookie persistence
5
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 ServerIron ADX monitors the server reply
and looks for a cookie with a specified name. The ServerIron ADX then builds a hash value based
on the content of the cookie. This hash value is then stored in a sticky session 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 34, 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
ServerIron 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 34
Server passive cookie example
ServerIron ADX Server Load Balancing Guide
53-1003452-01
341
5
Server passive cookie persistence
Configuring server passive cookie persistence
The server passive cookie persistence feature is implemented by configuring CSW rules and
policies as described in the following:
•
•
•
•
Create a CSW rule to match the server response
Create a CSW rule to match the client request
Specify a CSW action to create persist
Specify 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.
ServerIronADX(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.
ServerIronADX(config)#csw-rule r2 header “Cookie” pattern “OutlookSession”
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.
ServerIronADX(config)#csw-policy p1
ServerIronADX(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 is the name of a previously configured CSW rule that was defined to match a server
response.
342
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Server passive cookie persistence
5
The persistence-string-offset variable specifies the number of characters that will be skipped
directly after the search-string 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”.
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 described in the preceding chapter, and the
offset is “0”, the string will be parsed beginning with the “=”. If the persistence-string-length 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.
ServerIronADX(config)#csw-policy p1
ServerIronADX(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 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
“OutlookSession” as specified in r1, and the offset is “0”, the string will be parsed beginning with
the capital “O” in “OutlookSession”. If the offset is “7” the string will be parsed beginning with the
capital “S” in “Session”.
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 “OutlookSession” as specified in r1, and the offset is “0”, the string
will be parsed beginning with the capital “O” in “OutlookSession”. If the persistence-string-length is
set to “7”, the string used will be “Outlook”.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
343
5
Server and server port persistence with CSW nested rules
Example
The following example operates in a configuration much like the example shown in Figure 34 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"
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
The following can be used to configure the previous example.
ServerIronADX(config)#csw-rule "response-cookie" response-header "Set-Cookie"
pattern "PSrvrID="
ServerIronADX(config)#csw-rule "uri" url pattern "PSrvrID="
ServerIronADX(config)#csw-rule "forward-cookie" header "Cookie" pattern
"PSrvrID="
ServerIronADX(config)#csw-policy "passive1"
ServerIronADX(config-csw-policy-passive1)#match "response-cookie" passive-persist
offset 0 length 7
ServerIronADX(config-csw-policy-passive1)#match "forward-cookie" persist offset 0
length 7 passive-persist
ServerIronADX(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 345
• “Configuring persist on the nested rule” on page 345
• “Configuring persist on the real port” on page 345
NOTE
CSW nested rules are not supported in a csw response rewrite policy.
344
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Server and server port persistence with CSW nested rules
5
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.
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.
ServerIronADX(config)#csw-rule r1 url pattern "pweb"
ServerIronADX(config)#csw-rule r2 url pattern "jsession"
ServerIronADX(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.
ServerIronADX(config)#csw-policy p1
ServerIronADX(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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
345
5
Server and server port persistence with CSW nested rules
The three modes when the specified real port is not available are:
• Default: Layer 4 load balancing is performed.
• Port-failover: The ServerIron 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 ServerIron immediately closes the client connection.
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:
ServerIronADX(config)#server real-name-or-ip rs1
ServerIronADX(config-rs-rs1)#port 10500 group-id
ServerIronADX(config-rs-rs1)#port 10520 group-id
ServerIronADX(config-rs-rs1)#exit
ServerIronADX(config)#server real-name-or-ip rs2
ServerIronADX(config-rs-rs2)#port 10500 group-id
ServerIronADX(config-rs-rs2)#port 10520 group-id
ServerIronADX(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:
ServerIronADX(config)#csw-rule r1 url pattern "pweb"
ServerIronADX(config)#csw-rule r2 url pattern "jsession="
ServerIronADX(config)#csw-rule n1 nested-rule "r1&&r2" master-rule r2
• For configuring the CSW policy, enter the following commands:
ServerIronADX(config)#csw-policy p1
ServerIronADX(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:
ServerIronADX(config)#server virtual-name-or-ip vip1 10.10.10.100
ServerIronADX(config-vs-vip1)#bind http rs1 10500 rs1 10520
ServerIronADX(config-vs-vip1)#bind http rs2 10500 rs2 10520
ServerIronADX(config-vs-vip1)#port http csw-policy p1
The result is as follows:
• If the request has the string "pweb" and also string "/jsession=30" embedded in the url, Then
the rule n1 will be matched and SI 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.
346
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Displaying CSW information
5
Displaying CSW information
You can display the CSW information as described in the following sections.
•
•
•
•
•
•
“Displaying header information”
“Displaying CSW rule information”
“Displaying CSW policy information”
“Displaying the statistics for all HTTP content rewrites”
“Displaying Layer 7 switching statistics”
“Displaying the hash-based server selection for CWS policies”
Displaying header information
To display information about the HTTP headers encountered in a Layer 7 content switching
configuration, enter the show csw-hdr-info command.
ServerIronADX#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
ServerIron ADX Server Load Balancing Guide
53-1003452-01
347
5
Displaying CSW information
Table 28 describes the information displayed by the show csw-hdr-info command.
TABLE 28
Output from the show csw-hdr-info command
Field
Description
Unknown header list
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.
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
show csw-rule command.
ServerIronADX#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
banner1
|xml-tag
|banner1
|exists
|
|1
|http
volume3
|xml-tag
|volume
|equals
|Volume III|1
|http
volumex
|xml-tag
|volume
|equals
|xyz
|1
|http
volxyz
|xml-tag
|volume
|suffix
|xyz
|1
|http
Syntax: show csw-rule [rule-name]
348
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Displaying CSW information
5
Table 29 describes the information displayed by the show csw-rule command.
TABLE 29
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 ServerIron 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.
To display detailed information for a specified rule, enter the show csw-rule detail command, as
follows.
ServerIronADX#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
ServerIron ADX Server Load Balancing Guide
53-1003452-01
349
5
Displaying CSW information
Table 30 defines the information displayed by the show csw-rule detail command.
TABLE 30
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
350
Min term cnt
Number of minterms for the expression.
Minterms
List of minterms.
Hdr/Meth Ind
Index into the header in the method table.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Displaying CSW information
5
Displaying CSW policy information
To display information about a Layer 7 content switching policy, enter the show csw-policy server-sw
command on the BP.
ServerIronADX#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 mirror ip packet:0send mirror packet:0
send redirect packet:0case-sensitive:FALSE
Action code description:
fwd: forwardrst: reset-clientper: persist
rdr: redirecterr: reply-error got: goto
rwt: rewritemir: mirrorlog: log
con: countdrp: droprec: vir-reset
red: cont-redmlp: mirror-ipunk: unknown
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 31 defines the fields shown in the screen display.
TABLE 31
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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
351
5
Displaying CSW information
To display detailed information about a policy, enter the show csw-policy detail command, as
follows.
ServerIronADX#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 mirror ip packet:0send mirror packet:0
send redirect packet:0case-sensitive:0
Action code description:
fwd: forwardrst: reset-clientper: persist
rdr: redirecterr: reply-error got: goto
rwt: rewritemir: mirrorlog: log
con: countdrp: droprec: vir-reset
red: cont-redmlp: mirror-ipunk: unknown
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 31, the show csw-policy detail command displays the
fields as defined in Table 32.
TABLE 32
352
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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Displaying CSW information
TABLE 32
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 the show l7-rewrite-info command.
ServerIronADX#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 33 defines the fields shown in the screen display.
TABLE 33
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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
353
5
Displaying CSW information
TABLE 33
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 show server proxy command at any level of the CLI.
ServerIronADX#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 34 defines the fields in the screen display.
TABLE 34
354
Layer 7 Switching statistics
Field
Description
Slot alloc
Number of proxies allocated
Curr free slot
Number of proxies possible
Slot freed
Number of proxies finished
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Displaying CSW information
TABLE 34
5
Layer 7 Switching statistics (Continued)
Field
Description
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 ServerIron 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
Displaying the hash-based server selection for CWS policies
To display the hash-based server selection for CWS policies that are configured with CWS rules
which have content that can be hashed, use the show server hash command from the BP console.
ServerIronADX#rconsole 1 1
ServerIronADX1/1 #show server hash vip108
Virtual port Hash Buckets:
Virtual Server <vip108>, Virtual Port <80>:
Bucket: Server
Hit
Bucket: Server
Hit
Syntax: rconsole slot# BP#
Syntax: show server hash [virtual-server-name]
The optional virtual-server-name variable is the name of a specific virtual server. If you do not
specify a virtual server, the show server hash command displays the hash bucket information for all
virtual servers.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
355
5
Displaying CSW information
Table 35 describes the information displayed by the show server hash command.
TABLE 35
Output from the show server hash command
Field
Description
Virtual Server
The name of the virtual server.
Virtual Port
The virtual port number.
Bucket
The bucket number in which the real server is. The same real server can be in multiple buckets.
There are a total 256 buckets.
Server
The name of the real server.
Hit
The number of requests that select the real server in this bucket.
Example
Based on the following configuration, if an HTTP request has the lidl-shop-persist cookie which is a
four-digit number, the number is hashed to match a real server that has already been hashed to
the buckets (a total of 256).
csw-rule "persist-cookie" header "Cookie" search "lidl-shop-persist="
csw-policy "test"
match "persist-cookie" persist offset 0 length 4
server real rsXP 100.1.1.7
port http
port http group-id 1 10
server real rsXP1 100.1.1.71
port http
port http group-id 1 10
!
server real rsXP2 100.1.1.72
port http
port http group-id 1 10
server virtual vip108 100.1.1.108
port http
port http csw-policy "test"
port http csw
port http keep-alive
bind http rsXP http rsXP1 http rsXP2 http
In this example, four requests are sent that match the cookie, each with a different four-digit
number. The cookie number of the first request is hashed and goes to real server rsXP in hash
bucket 74, and its current bucket total hit number is 1, as displayed by the show server hash
command.
ServerIronADX1/1 #sh server hash vip108
Virtual port Hash Buckets:
Virtual Server <vip108>, Virtual Port <80>:
Bucket: Server
Hit
Bucket: Server
74: rsXP
1
356
Hit
ServerIron ADX Server Load Balancing Guide
53-1003452-01
5
Displaying CSW information
The cookie number of the second request is hashed and goes to real server rsXP1 in hash bucket
243. Its current bucket total hit number is 1.
ServerIronADX1/1 #sh server hash vip108
Virtual port Hash Buckets:
Virtual Server <vip108>, Virtual Port <80>:
Bucket: Server
Hit
Bucket: Server
74: rsXP
1
243: rsXP1
Hit
1
The cookie number of the third request is hashed and goes to real server rsXP1 in hash bucket
246. Its current bucket total hit number is 1.
ServerIronADX1/1 #sh server hash vip108
Virtual port Hash Buckets:
Virtual Server <vip108>, Virtual Port <80>:
Bucket: Server
Hit
Bucket: Server
74: rsXP
1
243: rsXP1
246: rsXP2
1
Hit
1
The cookie number of the fourth request is hashed and goes to real server rsXP in hash bucket 32.
Its current bucket total hit number is 1.
ServerIronADX1/1 #sh server hash vip108
Virtual port Hash Buckets:
Virtual Server <vip108>, Virtual Port <80>:
Bucket: Server
Hit
Bucket: Server
32: rsXP
1
74: rsXP
243: rsXP1
1
246: rsXP2
Hit
1
1
Displaying hash bucket counters
The hash bucket counters can provide useful information for tracing the reason why a persist
based on a hash-to-bucket CSW policy failed during traffic flow. To display the hash bucket
counters, use the show server proxy keep-alive command. The following truncated output displays
the hash bucket counters:
ServerIronADX#show server proxy keep-alive
Keep-alive connection statistics:
...
Hash Bucket Change:
Current serv is down =
Lower BP wins
=
...
1
0
Serv exceed max-con =
0
Syntax: show server proxy keep-alive
ServerIron ADX Server Load Balancing Guide
53-1003452-01
357
5
Usage guidelines
Table 36 describes the hash bucket counter fields of show server proxy keep-alive command.
TABLE 36
Output hash bucket counter fields of show server proxy keep-alive command
Field
Description
Current serv is down
The current server is down.
Serv exceed max-conn
The number of times that the current server exceeds the max-conn
configuration.
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.
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 ServerIron 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, ServerIron 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.
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 offset or neg-offset keyword indicates that the insertion offset starting after or before the
offset 0.
Support for large GET requests
The ServerIron 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.
TCP/UDP content switching
This section contains the following subsections:
• “Understanding TCP/UDP content switching” on page 359
• “Configuring TCP/UDP content switching” on page 359
• “TCP/UDP content switching commands” on page 363
358
ServerIron ADX Server Load Balancing Guide
53-1003452-01
TCP/UDP content switching
5
Understanding TCP/UDP content switching
TCP/UDP content switching allows the ServerIron ADX to make switching decisions based on the
content of TCP and UDP traffic. It allows you to make forwarding decisions by analyzing content
anywhere within a TCP or UDP packet.
TCP/UDP content switching provides the following benefits:
•
•
•
•
Extends the current prefix-suffix-pattern matching function to generic TCP and UDP content.
Provides load balancing based on any content specified in the configuration.
Adds multiple levels to the policy search function.
Allows you to provide a sub-string for the next level of policy matching, depending on the policy
matching result at the current level.
• Supports forwarding action, reset action (TCP only), and persisting request to server action.
• Supports content rewrite action, including insertion, deletion, and replacement.
• Supports pattern matching.
Specifications
TCP/UDP content switching has the following specifications:
• Cannot be used with legacy content switching. You must activate csw.
• Does not work with fragmented packets.
• No cookie insert, rewrite, or delete; no request or respond insert; no client-ip insert; no tcp
off-load; no keepalive.
• No out of sequence packets.
• All content matches must be ASCII; no hex match are allowed.
Configuring TCP/UDP content switching
To configure TCP/UDP content switching, you must first define TCP/UDP content switching rules
and policies.
A rule specifies the content that the ServerIron ADX looks for in the incoming traffic. A policy
associates rules with one or more actions that specify how the ServerIron ADX handles the traffic
that matches the rules.
To enable TCP/UDP content switching, you must bind the policy to a virtual server.
The following required and optional tasks are used for configuring TCP/UDP content switching:
•
•
•
•
•
•
•
“Define a TCP/UDP rule (required)”
“Define a policy (required)”
“Configure a forward action (required)”
“Configure a persist action (optional)”
“Configure a log action (optional)”
“Configure a reset-client action (optional)”
“Configure a rewrite action (optional)”
ServerIron ADX Server Load Balancing Guide
53-1003452-01
359
5
TCP/UDP content switching
• “Configure a goto action (optional)”
• “Enable TCP/UDP content switching (required)”
Define a TCP/UDP rule (required)
A TCP/UDP rule causes a ServerIron ADX to make a load balancing decision based on the TCP/UDP
content in an incoming packet, depending upon the port type. You can define up to 520 unique TCP
or UDP rules.
Use the following procedure to configure a rule called rulea that matches any TCP packet with the
string abcd between offset 10 and 40.
1. Enable privileged EXEC mode.
ServerIronADX> enable
2. Enable global configuration mode.
ServerIronADX#configure terminal
3. Configure a “tcp-content” rule and enter the csw-rule configuration mode.
ServerIronADX(config)#csw-rule rulea tcp-content pattern abcd case-insensitive
Syntax: [no] csw-rule rule-name tcp-content [ prefix | pattern ] string [case-insensitive]
This rule (rulea) specifies tcp-content of the pattern “abcd” and is case insensitive.
4. Set the parameter to specify the offset from where to begin scanning. depth specifies the
depth of the content.
ServerIronADX(config-csw-rulea)#offset 10 depth 30
5. Return to global configuration mode.
ServerIronADX(config-csw-rulea)#exit
Define a policy (required)
A policy specifies the action to take when a rule is matched. Use the following procedure to create a
TCP/UDP content switching policy.
1. Enable privileged EXEC mode.
ServerIronADX> enable
2. Enable global configuration mode.
ServerIronADX#configure terminal
3. Configure a policy name and enter the csw-policy configuration mode.
ServerIronADX(config)#csw-policy policy1 protocol any
ServerIronADX(config-csw-policy1)#
Syntax: [no] csw-policy policy-name protocol any
After you create a policy-name, you can specify the following kinds of actions in a policy:
• Forward action
• Persist action
• Log action
360
ServerIron ADX Server Load Balancing Guide
53-1003452-01
TCP/UDP content switching
5
• Reset-client
• Rewrite action
• Goto action
Configure a forward action (required)
A forward action causes a ServerIron ADX to forward packets that match a specified rule to a
specified real server or server group.The following example specifies that packets matching rule
rule1 be forwarded to real server 1029.
To configure a forward action for a TCP/UDP content switching policy, use the match forward
command in the policy configuration mode.
ServerIronADX(config-tca-policy1)#match r1 forward 1029
Syntax: [no] match rule-name forward id
NOTE
You must have previously created a real-server and assigned server-id 1029 to it.
Configure a persist action (optional)
A persist action causes a ServerIron ADX to send requests with similar content to the same server
when the specified rule is matched. When a rule is matched, the ServerIron ADX uses the content
that matched the rule to select a server or server group to send the packet to.
To configure a persist action for a TCP/UDP content switching policy, use the match persist
command in the policy configuration mode.
ServerIronADX(config-csw-policy1)#match rulea persist offset 10 length 10
hash-to-bucket
Syntax: [no] match rule-name persist offset offset-value [length length | terminator string]
[hash-to-bucket]
The length variable specifies the length in bytes of the string to be hashed.
The offset-value variable specifies the start of the hash string.
NOTE
If you specify 0 as the offset, the string starts at the beginning of the matched content.
Configure a log action (optional)
A log action causes the ServerIron ADX to write a message to Syslog when the specified rule is
matched. You can optionally customize the format of the Syslog message.
To configure a log action for a TCP/UDP content switching policy, use the match log command in
the policy configuration mode.
Syntax: [no] match rule-name log log_format
The following values can be used for the log_format variable:
• $SIP—Source IP
• $DIP—Destination IP
ServerIron ADX Server Load Balancing Guide
53-1003452-01
361
5
TCP/UDP content switching
•
•
•
•
•
$SPT—Source Port
$DPT—Destination Port
$RUL—Rule name
$ACT—The action taken e.g forward
$CNT—Content (The pattern that has been matched)
Example
ServerIronADX(config-csw-policy1)#match rulea log "source-ip = $SIP, dest-ip =
$DIP, rule = $RUL matched"
NOTE
The log rule is a secondary rule that assumes an action rule is already specified. It only logs the
action taken.
Configure a reset-client action (optional)
The reset-client action causes the ServerIron ADX to send a tcp reset to the client, which abruptly
terminates the connection.
To configure a reset-client action for a TCP/UDP content switching policy, use the reset-client
command in the policy configuration mode.
ServerIronADX(config-csw-policy1)#match rulea reset-client
Syntax: [no] match rule-name reset-client
Configure a rewrite action (optional)
The rewrite action causes the ServerIron to rewrite the matched string with a pattern that you
specify. For instructions on how to use the rewrite action within a CSW policy, see the following
sections:
• “Configuring Rewrite request-delete” on page 319
• “Configuring Rewrite request-insert” on page 324
Configure a goto action (optional)
The goto action causes the matched pattern to be forwarded to another policy as input and an
evaluation to be performed. The goto action leads to another policy matching. The input string for
the new policy matching is defined by the search result of the current policy matching result.
The matching starts from the first byte after the current policy matching result and goes to the end
of the current policy input string.
The current matched rule must be a non-nested rule; otherwise, the goto action is not allowed.
To configure a goto action, use the match goto command in the policy configuration mode.
ServerIronADX(config-csw-policy1)#match r1 goto policy5
Syntax: [no] match rule-name goto policy-name
362
ServerIron ADX Server Load Balancing Guide
53-1003452-01
TCP/UDP content switching
5
Define a nested rule (optional)
After you have defined the basic, standalone, rules, you can optionally bind them together to create
more complex, nested, rules.
You can combine rules with logical operators to create nested rules. Up to four rules can be
combined in a single nested rule. The following operators are supported.
&&
AND operator.
||
OR operator
!
NOT operator.
The following procedure describes how to configure a nested rule.
1. Enable privileged EXEC mode.
ServerIronADX> enable
2. Enable global configuration mode.
ServerIronADX#configure terminal
3. Configure a nested rule name and a rule called nestedrule1 that combines three other rules:
ruleA, ruleB, and ruleC.
ServerIronADX(config)#csw-rule nestedrule1 nested-content-rule ruleA
Syntax: [no] csw-rule rule-name nested-content-rule expression
NOTE
The nested rule is matched when an incoming packet matches ruleA, and either matches ruleB or
does not match ruleC.
Enable TCP/UDP content switching (required)
To enable TCP/UDP content switching, you must first bind a TCP/UDP content switching policy to a
virtual server. The following example shows how to enable TCP/UDP content switching on a virtual
server called cswVIP:
ServerIronADX(config)#server virtual-name cswVIP 192.168.20.254
ServerIronADX(config-vs-cswVIP)#port http csw-policy p1
ServerIronADX(config-vs-cswVIP)#port http csw
Syntax: [no] server virtual-name virtual-name ip-address
Syntax: [no] port http csw-policy policy-name
Syntax: [no] port http csw
TCP/UDP content switching commands
This section describes the syntax, semantics, and usage for each TCP/UDP content switching
command. This section contains the following sections:
• csw-rule
• csw-policy
ServerIron ADX Server Load Balancing Guide
53-1003452-01
363
5
TCP/UDP content switching
•
•
•
•
•
•
•
•
•
match
begin-delimitor
end-delimitor
forward
goto
log
persist
reset-client
rewrite
csw-rule
Use the csw-rule command in the global configuration mode to configure a content switching rule
for TCP/UDP content switching.
Syntax: [no] csw-rule rule-name nested-content-rule expression | tcp-content [prefix | pattern]
tcp-content| udp-content [prefix | pattern] udp-content| case-insensitive
csw-rule
Content switching rule command.
rule-name
Specifies the name of the rule. Can be up to 80 characters in length.
nested-content-rule
Specifies a nested content rule (compound rule).
expression
Within the expression, you can include up to four rules, linked with logical operators. The
following logical operators are supported:
• && = AND
• || = OR
• ! = NOT
A nested rule cannot be specified within the expression of another nested rule. The
expression must refer to more one rule, unless the ! (logical NOT) operator is used.
tcp-content
Specifies TCP content for load balancing.
tcp-content
Specify content to be matched.
udp-content
Specifies UDP content for load balancing.
udp-content
Specify content to be matched.
case-insensitive
Turns on the case-insensitive condition in the search.
Usage Guidelines
The following options are available after you create a rule and enter the content switching rule
configuration mode.
offset offset depth depth
Specify the offset from where to begin scanning depth specifies the depth
of the content. max-offset can be 65535 max-depth can be 32768 (or
65535).
Command Modes
• Global configuration mode.
• CSW configuration mode.
364
ServerIron ADX Server Load Balancing Guide
53-1003452-01
TCP/UDP content switching
5
csw-policy
Use the csw-policy command in the global configuration mode to configure a content switching
policy for TCP/UDP content switching.
Syntax: [no] csw-policy policy-name protocol any | case-insensitive
csw-policy
Content switching policy.
policy-name
Policy name can be up to 80 characters in length.
protocol any
protocol any must be entered or the legacy content switching policy is used.
case-insensitive
Turns on the case-insensitive condition in the search.
Usage Guidelines
After you create a policy and enter the TCP/UDP content switching policy-configuration mode, you
must set a rule with the match sub-command.
match
Syntax: [no] match rule-name begin-delimitor | end-delimitor | forward ID| goto policy-name| log
log_format| {persist offset value [length length | terminator string] [hash-to-bucket]} |
reset-client | rewrite
match
Specifies match sub-command.
rule-name
Specifies the rule to be matched.
begin-delimitor
Specifies to set this rule to be the beginning delimitor.
end-delimitor
Specifies to set this rule to be the ending delimitor.
forward
Specifies to forward the packets.
id
Group ID is from 0 to 1023. Server ID is from 0 to 5119.
NOTE: The real server ID range is limited to 1024-1+the maximum number of real
servers that can be configured on the ServerIron ADX model. For example, if the
maximum server limit is 16384, then the valid real server ID range is from 1024
to 1024-1+16384=17407.
NOTE: Layer 4 Load Balancing takes place only if a valid server is not selected and a
default csw-policy action is not configured.
goto
Specifies to go to the next level.
policy-name
Name of the policy.
log log_format
The log_format can be a string that uses the following variables:
$SIP—Source IP
$DIP—Destination IP
$SPT—Source Port
$DPT—Destination Port
$RUL—Rule name
$ACT—The action taken e.g forward
$CNT—Content (The pattern has been matched)
•
•
•
•
•
•
•
persist
Specifies the persist action for packets.
offset
Specifies offset of content to hash.
offset-value
Value for offset.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
365
5
Miscellaneous Layer 7 switching configurations
length
Specifies the length in bytes of the string to be hashed. If you specify 0 as the length,
the string ends at the beginning of the matched content.
length
Value for length.
terminator
Specifies the terminator for the search string.
string
Value of the terminator.
hash-to-bucket
Specifies to persist by hashing.
reset-client
Specifies to send a reset message to a client.
rewrite
For instructions on how to use the rewrite action within a CSW policy, see the following
sections:
• “Configuring Rewrite request-delete” on page 319
• “Configuring Rewrite request-insert” on page 324
Miscellaneous Layer 7 switching configurations
Changing the maximum number of concurrent
Layer 7 connections
By default, the ServerIron ADX allows a maximum of 100,000 concurrent Layer 7 switching
connections.
To change the maximum number of concurrent Layer 7 switching connections from 100,000 to
160,000, enter a command such as the following.
ServerIronADX(config)#server max-l7-connections 160000
Syntax: [no] server max-l7-connections number
On ServerIron ADX Chassis devices, the number of concurrent Layer 7 switching connections can
range from 100,000 to 512,000.
Dropping requests on exceeding max-conn per real server
Dropping the requests after exceeding the maximum number of connections
In an Layer 7 switching configuration, policies direct HTTP requests to real servers in load-balanced
real server groups. When all the real servers in a server group have reached their maximum
number of connections (by default, 1,000,000 connections or a threshold set with the max-conn
command), HTTP requests that would normally go to the server group are instead sent to one of the
other real servers bound to the VIP. The ServerIron ADX uses its load-balancing metric to select
another real server to which it directs the request. If there are no other real servers bound to the
VIP besides the ones in the server group, the request is dropped.
You can change the default behavior so that instead of being sent to a real server bound to the VIP,
the requests are dropped. To do this, enter commands such as the following on each real server in
the server group.
ServerIronADX(config)#server real-name server1 10.95.7.1
ServerIronADX(config-rs-server1)#exceed-max-drop
366
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous Layer 7 switching configurations
5
In this example, if Server1 reaches its maximum-connection threshold, and if all the real servers in
the server group to which Server1 belongs also reach their maximum-connection thresholds, HTTP
requests that would normally go to Server1’s server group are dropped.
Syntax: [no] exceed-max-drop
Dropping the requests when servers are unavailable
By default, if a policy is configured to direct an HTTP request to a server group, but none of the
servers in that server group are available, the HTTP request is directed to one of the other server
groups bound to the virtual servers service. You can change this default behavior so that the HTTP
request is dropped rather than directed to another server group. To do this, enter the following
commands.
ServerIronADX(config)#server virtual-name-or-ip vip1 192.168.1.234
ServerIronADX(config-vs-vip1)#port http no-group-failover
Syntax: port http no-group-failover
Cleaning up all hash buckets
To clean up all hash buckets when a server port comes alive, enter the following command.
ServerIronADX(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 ServerIron ADX stores client request packets in the Layer
7 content buffer while it selects a real server to which to forward the request. The ServerIron 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 ServerIron 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 ServerIron 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 ServerIron 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 ServerIron ADX,
thus making more efficient use of the ServerIron ADX’s Layer 7 content buffer.
To change the TCP window size to 1460 bytes, enter the following command.
ServerIronADX(config)#server l7-tcp-window-size 1460
Syntax: server l7-tcp-window-size window-size
ServerIron ADX Server Load Balancing Guide
53-1003452-01
367
5
Miscellaneous Layer 7 switching configurations
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 ServerIron 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 ServerIron ADX to the client. The ServerIron ADX does not modify the TCP
window size for traffic sent from real servers to clients by way of the ServerIron ADX.
Preventing the ServerIron ADX from sending an ACK to the client
You can configure the ServerIron ADX not to send an ACK back to the client after the ServerIron
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 ServerIron 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 ServerIron ADX, increasing the efficiency of the
Layer 7 content buffer.
To cause the ServerIron 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.
ServerIronADX(config)#server l7-dont-ack-last-packet
Syntax: server l7-dont-ack-last-packet
HTTP 1.1 support
The ServerIron 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
368
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous Layer 7 switching configurations
5
clients that originally created the connections. When a client makes a request for content that is
served by a different server, the ServerIron ADX switch 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, HTTP 1.0 is the version of HTTP that comes enabled on ServerIron ADXs 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.
ServerIronADX(config)#server virtual-name-or-ip vserv1
ServerIronADX(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 command server tcp-age minutes or locally under the
virtual server level by entering the command port port-num tcp-age minutes.
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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
369
5
Miscellaneous Layer 7 switching configurations
Graceful handling of HTTP pipelined requests
If either HTTP, SSL terminate, or SSL Proxy 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. (Refer to the Secure Socket Layer (SSL) Acceleration
chapter of the ServerIron TrafficWorks Security Guide for details on SSL terminate and SSL Proxy.)
Before software release 11.0.00, ServerIronADX did not support pipelining because most web
browsers have this feature disabled by default. However, if the Web browser supports pipelining
and Layer 7 switching is enabled on the ServerIronADX, then ServerIronADX does the following:
• If the pipelined HTTP requests are within the same packet, ServerIronADX will make the
switching decision based on the first request and direct all the subsequent pipelined requests
to the same server to which the first request was directed. Pipelining will disable Layer 7
switching on subsequent requests.
• If a client sends pipelined HTTP requests in separate packets before the ServerIronADX can
send a response for the first request, ServerIronADX makes Layer 7 switching decisions based
on the first request. All subsequent pipelined requests will be dropped until the response for
the first request is successfully received by the client. This scenario can cause degradation,
resulting in poor end-user experience.
• If the tcp-offload or keepalive option is enabled under the virtual server port, when a reply
comes back from a real server in response to the pipelined request, the ServerIron drops this
reply; therefore, the end-client does not receive the response.
Beginning with release 11.0.00, ServerIron 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.
This feature works only when Content Switching is enabled on a virtual server port. if pipelined
HTTP requests are sent in one connection, the ServerIronADX 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 ServerIronADX will forward the response to the
client. After the client acknowledges the complete response, one of the following occurs:
• For HTTP traffic, the ServerIronADX closes the connection by sending a RST to the client.
• For SSL-terminate or SSL-proxy, the ServerIronADX closes the connection by sending a FIN 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.
ServerIronADX(config)#server virtual-name-or-ip VS1 10.10.10.10
ServerIronADX(config-vs-VS1)#port http
ServerIronADX(config-vs-VS1)#port http keep-alive reset-pipeline-request
Syntax: [no] port [portid] keep-alive [reset-pipeline-request]
370
ServerIron ADX Server Load Balancing Guide
53-1003452-01
5
Miscellaneous Layer 7 switching configurations
To reset pipelined HTTP request in the TCP offload mode, enter commands such as the following.
ServerIronADX(config)#server virtual-name-or-ip VS1 10.10.10.10
ServerIronADX(config-vs-VS1)#port http
ServerIronADX(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 ServerIron ADX.
ServerIronADX#clear server keep-alive virtual
Syntax: [no] clear server keep-alive [virtual | real] [server-name] [port]
Enter the virtual option if you want to delete all the keepalive connections associated with the
virtual server, or the real option 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 ServerIron ADX
sends reset packets to the real or virtual servers to close any open connections.
Displaying transactions and connections
To display information about the transactions and connections for Layer 7 switching over keepalive
connections, enter the following command.
ServerIronADX4/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
ServerIron ADX Server Load Balancing Guide
53-1003452-01
St
1
1
1
CltConn:Cur/Tot SerConn:Cur/Tot CurrTrans IdleSerCon
11/46
3/5
2
1
0/0
0/0
0
0
0/0
0/0
0
0
TotTrans
147
0
0
371
5
Miscellaneous Layer 7 switching configurations
Table 37 specifies the show server session keep-alive command fields and its description.
TABLE 37
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 on WSM CPU ServerIron4/1 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 ServerIron; while the ServerIron 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 ServerIron ADX.
Layer 7 CSW pseudo stack client-side retransmission
handling
The ServerIron 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 ServerIron 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 ServerIron 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 ServerIron ADX, until the TCP timeout
expires. As a result, the client will notice that the HTTP transaction never gets completed.This issue
becomes more relevant when the ServerIron ADX Layer 7 Transparent Cache Switching (TCS)
feature bypasses HTTP traffic to the Internet server over an unrealiable WAN link.
372
ServerIron ADX Server Load Balancing Guide
53-1003452-01
5
Miscellaneous Layer 7 switching configurations
Starting with software release 12.4.00c, the ServerIron ADX supports handling of HTTP request
retransmission with Layer 7 pseudo stack. When the Layer 7 CSW pseudo stack retransmission
handling is enabled, the ServerIron 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 befor the request packets are acknowledged, the ServerIron ADX will resend th
stored packets.
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:
ServerIronADX(config)#server csw enable-retransmission
Syntax: [no] server csw enable-retransmission
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
ServerIron ADX, use the show server proxy keep-alive command. A truncated display is shown:
ServerIronADX 1000#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
=
...
ServerIronADX 1000#
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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
373
5
Miscellaneous Layer 7 switching configurations
NOTE
The Layer 7 CSW pseudo stack retransmission handling feature does not support High Availability
(HA). If HA is configured for active symmetric mode and this feature is enabled, the ServerIron ADX
that is receiving the client request will send and free the stored packets and will not do
retransmission handling.
NOTE
The Layer 7 CSW pseudo stack retransmission handling feature supports IPv6.
Layer 7 CSW pseudo stack server-side TCP packet
out-of-sequence handling
With the current Layer 7 Content Switching (CSW) pseudo stack, the ServerIron 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 ServerIronADX 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.
This issue becomes especially evident when the ServerIron ADX Layer 7 Transparent Cache
Switching (TCS) feature bypasses HTTP traffic to the Internet server over a slow WAN link. Starting
with release 12.4.00c, the ServerIron ADX Layer 7 CSW pseudo stack will support handling of
packet-drops and out-of-sequence TCP packets arriving from server-side as well.
NOTE
The Layer 7 CSW pseudo stack TCP packet out-of-sequence handling feature supports IPv6.
374
ServerIron ADX Server Load Balancing Guide
53-1003452-01
5
Miscellaneous Layer 7 switching configurations
Displaying server-side link connections
In order to display information about the server-side out-of-sequence TCP packets handled by the
ServerIron 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 38.
ServerIronADX 1000#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
ServerIronADX 1000#
Syntax: show server proxy keep-alive
NOTE
This command is available at the ServerIron ADX BP console only.
The fields described in Table 38 provide statistics about out-of-sequence (oos) TCP packets.
TABLE 38
Out-of-sequence TCP packets statistics
Field
Description
Total stored oos pkt
The total number of out-of-sequence packets buffered by
the ServerIron ADX.
Total freed oos pkt
The total number of out-of-sequence packets transmitted
by the ServerIron ADX.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
375
5
Setting up SSL session ID switching
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 ServerIron 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 ServerIron ADX’s database (optional).
4. Adjust the maximum number of session_id-to-real-server associations that the ServerIron ADX
can store in its internal database (optional).
376
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Setting up SSL session ID switching
5
Configuration example
Figure 35 illustrates how the initial SSLHP messages exchanged between a client and server,
client_hello and server_hello, establish an SSL Session ID.
FIGURE 35
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 ServerIron ADX
can connect the client to the server that originally sent the Session ID value. Figure 36 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 ServerIron 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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
377
5
Setting up SSL session ID switching
FIGURE 36
How the ServerIron ADX uses an SSL Session ID to Select a Real Server
Figure 36 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 ServerIron ADX examines the value in the session_id field sent by the server. The
ServerIron 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
ServerIron ADX’s database for a user-specified amount of time (default 30 minutes), after
which it is aged out. In this example, the ServerIron 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 ServerIron 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 ServerIron ADX initiates a TCP
connection to the server and passes the client_hello message to it. The ServerIron 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.
Configuring the real servers for SSL
To configure the real servers for SSL shown in Figure 36, enter commands such as the following.
ServerIronADX(config)#server real-name rs10 10.157.22.10
ServerIronADX(config-rs-rs10)#port ssl
ServerIronADX(config-rs-rs10)#exit
ServerIronADX(config)#server real-name rs20 10.157.22.20
ServerIronADX(config-rs-rs20)#port ssl
ServerIronADX(config-rs-rs20)#exit
Syntax: server real-name real-server-name ip-addr
378
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Setting up SSL session ID switching
5
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.
ServerIronADX(config)#server virtual-name-or-ip sslVIP 10.157.22.241
ServerIronADX(config-vs-sslVIP)#port ssl session-id-switching
ServerIronADX(config-vs-sslVIP)#bind ssl rs10 ssl
ServerIronADX(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 ServerIron 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 ServerIron 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.
ServerIronADX(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.
Adjusting the maximum number of session_id-to-real-server associations
By default, the ServerIron 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.
ServerIronADX(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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
379
5
Command reference
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.
ServerIronADX(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 specifies the value of the string to be deleted.
rewrite request-insert
Use the rewrite request-insert option in the CSW policy configuration mode to insert content, as
shown in the following.
ServerIronADX(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.
380
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Command reference
5
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.
ServerIronADX(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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
381
5
382
Command reference
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Chapter
High Availability
6
Introduction
This chapter describes the high availability feature in ServerIron.
NOTE
In high availability configurations, with Brocade hardware-based SSL acceleration in either SSL
Termination or SSL Proxy mode, synchronization of proxied or terminated SSL sessions is not
supported.
High availability (HA) for server load balancing (SLB) consists of three ServerIron ADX services: Hot
Standby HA, Symmetric Active-Standby HA, and Symmetric Active-Active HA.
Hot Standby HA
One ServerIron ADX is always active while the other ServerIron ADX is always standby. Hot Standby
is supported on both stackable and chassis systems. On chassis systems, Hot Standby is
supported only in Switch (S) code, not Router (R) code. Refer to “Hot Standby HA” on page 384.
Symmetric Active-Standby HA
Both ServerIron ADXs can receive SLB traffic, but only the active VIP handles the L4-7 SLB, while
the standby VIP functions as a standby. The VIP with the highest configured sym-priority handles
the flow. Symmetric Active-Standby HA is supported in both Switch (S) code and Router (R) code.
Refer to “Symmetric Active-Standby HA” on page 399.
Symmetric Active-Active HA
Active-active is also called as true active-active. Both ServerIron ADXs can receive SLB traffic, and
both are active for the same VIP. Configuring Symmetric Active-Active HA and sym-priority on the VIP
enables a device to process traffic. Refer to “Symmetric Active-Active HA” on page 416.
With Direct Server Return (DSR), return traffic is not processed by the ServerIron ADX. Instead, the
real server sends return traffic directly to the client. You can apply DSR to each of the HA scenarios
(Hot Standby HA, Symmetric Active-Standby HA, and Symmetric Active-Active HA).
NOTE
When a device is active, it responds to Address resolution Protocols (ARP) and processes all traffic
for the VIP. When a device is acting as standby, it performs no processing functions for the specified
VIP (other than session syncing with the active device, if enabled).
ServerIron ADX Server Load Balancing Guide
53-1003452-01
383
6
Hot Standby HA
Hot Standby HA
Because Hot Standby HA is an HA feature, there must be two ServerIron ADXs in the network. If only
one device is present and the Hot Standby HA feature is enabled, the ServerIron ADX will function
in "single-box" mode until the second ServerIron ADX becomes available.
There are two versions of Hot Standby HA:
• Standard Hot Standby HA - The ServerIron ADX’s management IP, VIPs, and real servers are all
in the same subnet.
• Source-IP/src-standby-ip Hot Standby HA - The ServerIron ADX’s management IP and VIPs are
in one subnet. Real servers are in a different subnet. Additional commands are required for
this version.
For Hot standby HA, one ServerIron ADX is always active while the other ServerIron ADX is always
standby (idle).
Hot Standby HA allows you to configure two ServerIron ADXs to serve as a redundant pair (primary
and secondary). If the active ServerIron ADX fails, the idle standby ServerIron ADX assumes the
active duties and becomes the new active device.
Hot Standby HA is the only HA service counting the number of available router-ports and server
ports for failover behavior. The ServerIron ADX with the highest number of active ports is declared
the active device. In addition to port-count loss, a system reload or crash triggers a failover.
Hot Standby HA protocol operations
Figure 37 illustrates a typical Hot Standby HA configuration.
FIGURE 37
384
Typical Hot Standby HA
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Hot Standby HA
6
When ServerIron ADX A comes up in a Hot Standby HA configuration, it comes up in standby state.
When it sends Hello messages and sees that no other ServerIron ADX is responding to those Hello
messages, ServerIron ADX A assumes the active state. When ServerIron ADX-B comes up, it also
goes through Hello-message processing. When ServerIron ADX B sends Hello messages, ServerIron
ADX A responds to ServerIron ADX B with ServerIron ADX A's Active Status. ServerIron ADX B
assumes Standby status. ServerIron ADX A in the active state performs the following four stages of
synchronization:
•
•
•
•
Port map synchronization
MAC table synchronization
Server information synchronization
Session synchronization
When the entire synchronization process is complete, ServerIron ADX B calculates to see if
ServerIron ADX A has a higher router-port plus server-port count or if ServerIron ADX B has the
higher count. If the count is equal for both ServerIron ADX A and ServerIron ADX B, then ServerIron
ADX B continues in the standby state. If ServerIron ADX A has a lesser count of router-port plus
server-port, ServerIron ADX B forces ServerIron ADX A to go to standby state, and ServerIron ADX B
assumes the active state. From this point on, ServerIron ADX A will be in the active state and
ServerIron ADX B will be in the standby state until some event forces a change in their status.
Events leading to change can include:
• An increase or decrease in the count of router-port plus server-ports
• Failure of one BP forcing all BPs to fail
• A reload
While standby ServerIron ADX B is idle, it continuously listens to Active ServerIron ADX A for fail-over
preparation. ServerIron ADX A synchronizes its session table on the BPs to match the BPs on
Standby ServerIron ADX B. This action occurs the moment a session is created on Active ServerIron
ADX A. Synchronization of a session involves session creation, session deletion, and age updates.
No CLI commands are required to invoke session synchronization from Active ServerIron ADX A to
Standby ServerIron ADX B. ServerIron ADX A and ServerIron ADX B perform Layer 2, Layer 3, Layer
4, and Layer 7 health checks independently. To avoid a loop, ServerIron ADX B becomes a dumb
device in Standby. All it does is receive session-sync messages from Active, perform health checks,
and process Hello messages. ServerIron ADX B is completely isolated and does not process any
SLB traffic. If ServerIron ADX A fails, ServerIron ADX B becomes Active and immediately takes over
the processing of SLB traffic. Because the sessions were already synchronized from ServerIron ADX
A when it was Active, failover is transparent to users.
Despite the stability of this solution, having an inactive device (ServerIron ADX B) with all its VIPs in
standby state can be viewed as a limitation. For this reason, Brocade created a new HA feature
called Symmetric Active-Standby HA (refer to “Symmetric Active-Standby HA” on page 399).
ServerIron ADX Server Load Balancing Guide
53-1003452-01
385
6
Hot Standby HA
Configuring Standard Hot Standby HA
Figure 38 shows the minimum required configuration for Standard Hot Standby HA.
FIGURE 38
Minimum required configuration for Standard Hot Standby HA
Follow these steps to enable the minimum required configuration shown in Figure 38. Client
connections and server connections must be on the same interfaces on both ServerIron ADXs.
1. On ServerIron ADX A, place the untagged Hot Standby HA port (sync-link) in its own
port-specific VLAN and disable STP:
ServerIronADX-A(config)#vlan 2 by port
ServerIronADX-A(config-vlan-2)#untagged ethe 2/1
ServerIronADX-A(config-vlan-2)#no spanning-tree
Placing the Hot Standby HA port in its own VLAN prevents unnecessary traffic from going over
the backup (sync) link. Note that the backup link does not have to be directly connected. There
could be a layer 2 switch between two ServerIron ADX application switches in the HA pair as
long as the latency is reasonably low, e.g, under 10ms and packets are delivered reliably
between the ServerIron ADX application switches.
2. To avoid system conflicts, globally disable spanning-tree on VLAN 1:
ServerIronADX-A(config)#vlan 1 name DEFAULT-VLAN by port
ServerIronADX-A(config-vlan-1)#no spanning-tree
386
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Hot Standby HA
6
3. Configure the server backup port, shared chassis-MAC address between the ServerIron ADXs,
and any connected router-ports:
The server backup ethernet command must be configured exactly the same on both ServerIron
ADXs. It has three parameters.
Syntax: server backup ethernet portnum mac-addr vlan-id
The portnum variable specifies the port where the syn-link is connected. This port connects
this ServerIron ADX switch to its counterpart. In the example, 2/1 is the port number.
The mac-addr variable specifies the chassis-MAC address of one of the ServerIron ADXs. Be
sure to use a chassis MAC from one of the two devices, not the MAC of one of the backup
ports. Use the show chassis command to locate the chassis MAC. If both devices already have
the same chassis MAC (because of a manufacturing error), then one of them must change.
The vlan-id variable specifies a VLAN that you want to use for Symmetric Active-Standby HA
synchronization traffic. In this example, the sync-link Hot Standby HA port is in VLAN 2.
The server router-ports command enables the ServerIron ADX to count the number of
upstream (or downstream) router ports connected to the switch. Both ServerIron ADXs must
use the same router-ports numbers, such as 2/3 in this example. The reason is the standby
ServerIron ADX is a dummy device that learns nothing, such as MACs, on its own.
4. Save the configuration.
ServerIronADX-SLB-A #wr mem
.Write startup-config in progress.
.Write startup-config done.
ServerIronADX-SLB-A#reload
NOTE
Be sure to reload the software after configuring or changing the server backup port number or
MAC address. If you change the port number of the backup while the ServerIron ADX is load
balancing, clients will not be able to ping the VIP.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
387
6
Hot Standby HA
5. Configure the second ServerIron ADX (ServerIron ADX-B). On this system, port 2/1 is the Hot
Standby HA port. Using the same port numbers and MAC address is a requirement. Notice the
chassis-MAC address on each ServerIron ADX matches.
ServerIronADX-B#server backup ethe 2/1 00e0.5201.0c72 vlan-id 2
ServerIronADX-B#server router-ports ethernet 2/3
ServerIronADX-B#server router-ports ethernet 2/4
ServerIronADX-B(config)#vlan 1 name DEFAULT-VLAN by port
ServerIronADX-B(config-vlan-1)#no spanning-tree
ServerIronADX-B(config-vlan-1)#vlan 2 by port
ServerIronADX-B(config-vlan-2)#untagged ethe 2/1
ServerIronADX-B(config-vlan-2)#no spanning-tree
ServerIronADX-B#write memory
.Write startup-config in progress.
.Write startup-config done.
ServerIron ADX-B#reload
NOTE
If you plan to configure real servers to use a source IP address configured on the ServerIron
ADX as a default gateway, use the source-standby-address or source-nat-address command
rather than the source-ip or source-nat command.
6. Use the show server backup and show log commands to obtain a clear picture of the
ServerIron ADX’s status in the Hot Standby HA configuration.
The following screen shots display the different stages of reload and show how a ServerIron ADX
comes up in a Hot Standby HA configuration.
388
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Hot Standby HA
6
ServerIron ADX A is running in single-box mode, because ServerIron ADX B is not yet discovered.
Now ServerIron ADX B comes up. ServerIron ADX A is already up and running.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
389
6
Hot Standby HA
Table 39 describes the information displayed by the show server backup command.
.
TABLE 39
390
Field descriptions for show server backup command
Field
Description
Switch state
Indicates whether this ServerIron ADX is the active ServerIron ADX or the standby. The
state can be one of the following:
• Active
• Standby
SLB state
When a ServerIron ADX comes up in the Hot Standby HA configuration (supported using
switch images only), it requests the following information from the peer ServerIron ADX:
• Port map information
• MAC information
• Server mapping information
• Session information (Fail-over session sync)
After this processing is completed, the ServerIron ADX goes to the "SLB synchronization
complete" state.
The "SLB State" field in the show server backup command denotes which of the above
states the ServerIron ADX is in:
• SLB_SYNC_COMPLETE state (Value = 0). All synchronization requests from the local
ServerIron ADX have been sent to the peer ServerIron ADX. This process is now
complete (value = 0).
• SLB_SYNC_REQ_MAP state (Value = 1). Denotes the local ServerIron ADX is
requesting the peer ServerIron ADX for port map information.
• SLB_SYNC_REQ_MAC state (Value = 2). Denotes the local ServerIron ADX is
requesting the peer ServerIron ADX for MAC information.
• SLB_SYNC_REQ_SERVERS state (Value = 3). Denotes the local ServerIron ADX is
requesting the peer ServerIron ADX for Server mapping.
• SLB_SYNC_REQ_L4 state (Value = 4). Denotes the local ServerIron ADX is
requesting the peer ServerIron ADX for session synchronization (fail-over session
sync).
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 chassis MAC address on the other ServerIron ADX, indicating Layer 2 connectivity
between the ServerIron ADXs. If this field contains all zeros, double-check the connection
between the ServerIron ADXs and verify that both ServerIron ADXs are powered on. Also
verify that Spanning Tree is disabled on both ServerIron ADXs. Spanning Tree interferes
with Hot Standby HA.
SLB Partner port cnt
The number of physical ports on the other ServerIron ADX.
Transitions, activates
The number of times this ServerIron ADX has changed from standby to active.
Transitions, standby
The number of times this ServerIron ADX has changed from active to standby.
Pdus sent
The number of Layer 4 synchronization packets this ServerIron ADX has sent to the other
ServerIron ADX.
Mac pdu sent
The number of MAC-layer synchronization packets this ServerIron ADX has sent to the
other ServerIron 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 ServerIron ADX to
discover information about the maps on the other ServerIron ADX.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Hot Standby HA
6
Additional configuration variations
VIP and servers in different subnets
Figure 39 shows a configuration with the VIP and servers in different subnets.
FIGURE 39
VIP and servers in different subnets
ServerIron ADX Server Load Balancing Guide
53-1003452-01
391
6
Hot Standby HA
Source-NAT in Hot Standby HA
NOTE
The status of the source NAT IPs is not updated for Hot Standby HA topology (since it is active on the
ServerIron ADX which is Active/Standby and vice versa), and the show server source-nat-ip
command will always show their status as enabled. The status of the source NAT IPs is relevant for
Symmetric Active-Standby HA and Symmetric Active-Active HA topologies and will be displayed
appropriately as Symmetric Active-Standby HA in these topology types.
The server source-nat command is added to the following configuration on both ServerIron ADXs.
However, seamless failover cannot be achieved here. Refer to “Seamless failover in Hot Standby HA
when Source-NAT enabled” on page 393
FIGURE 40
Source-NAT enabled in Hot Standby HA
.
392
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Hot Standby HA
6
Seamless failover in Hot Standby HA when Source-NAT enabled
FIGURE 41
Seamless failover in Hot Standby HA when Source-NAT enabled
Configuring a backup group ID
You can configure up to 127 Hot Standby HA pairs within a single L2 broadcast domain. To enable
this support, use the server backup-group command to configure a backup group ID on each of the
ServerIron ADXs, so that both ServerIron ADXs in a given pair have the same ID. The backup group
ID uniquely identifies the pair.
When you configure a backup group ID, both ServerIron ADXs in a Hot Standby HA pair use the ID
when exchanging backup information. If a ServerIron ADX receives a backup information packet,
but the packet’s backup group ID does not match the ServerIron ADX’s backup group ID, the
ServerIron 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.
ServerIronADX(config)#server backup-group 1
Syntax: [no] server backup-group id
The id variable specifies the backup group ID, which can be a number from 1 to 7. The default value
is 0. Enter the same ID on both ServerIron ADXs in a Hot Standby HA pair. Do not enter the same ID
on a ServerIron ADX that is not one of the ServerIron ADXs in the Hot Standby HA pair.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
393
6
Hot Standby HA
Setting the backup timer
The standby ServerIron ADX assumes the active role if the it does not receive a Hello message or
Layer 4 session synchronization data from the active ServerIron ADX within a certain number of
seconds since having received the last Hello message or synchronization data.
By default, the standby ServerIron ADX waits one second since having received the last Hello
message or data to receive a new message or data. If the standby ServerIron ADX does not receive
a new Hello message or data within one second, the standby ServerIron ADX assumes that the
active ServerIron ADX is no longer available and takes over the active role.
In some configurations, particularly those in which the active ServerIron ADX is performing a lot of
processing, it is possible for frequent failovers to occur. In this situation, although the active
ServerIron ADX is still available and actively serving load balancing or other requests, the active
ServerIron ADX does not always send the Hello message or synchronization data in time for the
standby ServerIron ADX. As as result, the standby ServerIron ADX takes over the active role. If
similar conditions cause the newly active ServerIron 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 ServerIron ADXs by increasing the
backup timer. When you increase the backup timer, the standby ServerIron ADX waits longer to
receive new Hello messages or synchronization data from the active ServerIron ADX. As a result,
flapping is reduced or eliminated.
NOTE
The backup timer must have the same value on both ServerIron ADXs in the Symmetric
Active-Standby HA pair.
To set the backup timer on a ServerIron ADX in a Symmetric Active-Standby HA pair, enter the
following command.
ServerIronADX(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 ServerIron ADX, when it is the backup ServerIron ADX, will
wait for a Hello message or synchronization data from the active ServerIron ADX before assuming
the active ServerIron 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 ServerIron ADXs in the Symmetric Active-Standby HA pair to always be
the active ServerIron ADX. When you enable server backup-preference on one of the ServerIron
ADXs, that ServerIron ADX is always active by default. The only event that can cause the other
ServerIron ADX to be active is unavailability of the default active ServerIron ADX or its link to the
backup ServerIron ADX. To allow graceful insertion, the ServerIron 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.
ServerIronADX(config)#server backup-preference 5
Syntax: [no] server backup-preference wait-time
394
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Hot Standby HA
6
The wait-time variable specifies how long the ServerIron ADX waits before assuming the active role.
The ServerIron ADX does not immediately become the active ServerIron 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 Symmetric Active-Standby HA peer failover is based on router ports and server
ports. You can configure the Symmetric Active-Standby 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.
To enable this feature, enter the following command.
ServerIronADX(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 Symmetric Active-Standby 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.
ServerIronADX(config)#server backup-vport-cnt
Syntax: [no] server backup-vport-count
ServerIron ADX Server Load Balancing Guide
53-1003452-01
395
6
Hot Standby HA
This feature can be configured with or without the server backup-vip-cnt command as described:
• If the server backup-vport-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 ServerIron ADX switches in the
pair. To avoid an unnecessary failover during configuration, we suggest that you enable this feature
on the active switch first. Also, the feature should be disabled on the standby switch first.
Delayed failover
With this feature configured, when a ServerIron ADX switch 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
ServerIron ADX switch 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.
ServerIronADX(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 ServerIron 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
command.
NOTE
The server backup-delay-seconds backup-wait-seconds command must be configured on both
ServerIron ADX switches in the active/standby pair.
396
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Hot Standby HA
6
Configuring a ServerIron ADX to remain in standby state
This feature is specific to Hot Standby HA configurations. The feature lets you ensure that a
ServerIron always remains in 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’s Management Processor is very high and causes the standby to drop the heart
beat messages sent by the active ServerIron.
NOTE
Use the remain-standby command with caution because both ServerIrons can become standbys;
thereby creating traffic loss.
If the ServerIron is active when this command is configured, the ServerIron transitions to a backup
state and remains as backup until the command is removed. The transition is logged as "Forced to
turn standby" (remain-standby command.).
Once the remain-standby command is entered, every attempt the ServerIron makes to go into
active state is recorded and suppressed. This information is available under the "Active attempts"
field in the show server debug command.
To force a ServerIron to remain in the standby state, enter the following command.
ServerIronADX(config)#server backup-remain-standby
Syntax: server backup-remain-standby
Configuring the forwarding of synching messages
In a Hot Standby HA configuration, the active ServerIron ADX and the backup ServerIron ADX
continuously communicate synching messages. These synching messages contain Layer 4 –Layer
7 session status information and are only used by the ServerIron ADXs.
Some of the messages can travel over a non-dedicated private link between the two ServerIron
ADXs. Another ServerIron 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 ServerIron ADXs.
In this situation, messages sent between the active and backup ServerIron ADXs can be
intercepted and dropped by the ServerIron ADX in the middle, and not forwarded to the active or
backup ServerIron ADXs. This could cause loss of synch between the active and backup ServerIron
ADXs. To prevent this from happening, use the server fwd-l4-sync command to configure the
ServerIron ADX in the middle to simply forward the synching messages and not intercept them.
To configure the ServerIron ADX in the middle to forward the synching messages, enter the
following command on the ServerIron ADX connecting the active and the backup ServerIron ADXs.
ServerIronADX(config)#server fwd-l4-sync
Syntax: server fwd-l4-sync
ServerIron ADX Server Load Balancing Guide
53-1003452-01
397
6
Hot Standby HA
Sample configuration
Suppose you want to configure a second switch, ServerIron ADX2, to serve as the backup or
standby switch for ServerIron ADX1. Each switch will be configured with the same SLB
configuration, supporting the following TCP/UDP ports: HTTP, SSL, FTP, and Telnet.
The private link, which provides the connection between the active and standby switches, will be
configured as a trunk group with ports 13 and 14 as members.
ServerIronADX#config term
ServerIronADX(config)#trunk server ethernet 13 to 14
For non-HA trunk links connected to other Layer 2 switches, use the default trunk switch. For
non-HA trunk links connected to Dual-NIC servers, use the trunk server command.
On ServerIron ADX devices, if you configure a trunk group, use the trunk switch command if the
traffic flowing through the trunk requires Layer 4-7 processing. Only use the trunk server command
if the traffic flowing through the trunk does not require Layer 4-7 processing. For traffic that does
not require Layer 4-7 processing on ServerIron ADX devices, the trunk type can be switch or server.
ServerIronADX(config)#vlan 2
ServerIronADX(config-vlan-2)#untag ethernet 13 to 14
ServerIronADX(config-vlan-2)#no spanning-tree
ServerIronADX(config-vlan-2)#exit
ServerIronADX(config)#server real web1 10.96.22.100
ServerIronADX(config-rs-web1)#port http
ServerIronADX(config-rs-web1)#port ssl
ServerIronADX(config-rs-web1)#port ftp
ServerIronADX(config-rs-web1)#port telnet
ServerIronADX(config-rs-web1)#server real web2 10.96.22.101
ServerIronADX(config-rs-web2)#port http
ServerIronADX(config-rs-web2)#port ssl
ServerIronADX(config-rs-web2)#port ftp
ServerIronADX(config-rs-web2)#port telnet
ServerIronADX(config-rs-web2)#server virtual-name-or-ip www.example7.com
10.96.6.254
ServerIronADX(config-vs-www.example7.com)#port http
ServerIronADX(config-vs-www.example7.com)#port ssl sticky
ServerIronADX(config-vs-www.example7.com)#port ftp
ServerIronADX(config-vs-www.example7.com)#port telnet
ServerIronADX(config-vs-www.example7.com)#bind http web1 http web2 http
ServerIronADX(config-vs-www.example7.com)#bind ssl web1 ssl web2 ssl
ServerIronADX(config-vs-www.example7.com)#bind ftp web1 ftp web2 ftp
ServerIronADX(config-vs-www.example7.com)#bind telnet web1 telnet web2 telnet
ServerIronADX(config-vs-www.example7.com)#exit
To identify the router port, configure the trunk group, assign ports 13 and 14 as the backup ports,
assign round robin as the predictor (load balancing metric), and disable Spanning Tree, enter the
following commands.
ServerIronADX(config)#server router-ports 11
ServerIronADX(config)#server backup ethernet 13 00e0.5201.0c72
ServerIronADX(config)#server predictor round-robin
ServerIronADX(config)#no span
ServerIronADX(config)#exit
ServerIronADX#write memory
ServerIronADX#reload
398
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Symmetric Active-Standby HA
6
The MAC address assigned is a MAC address that is resident on either ServerIron ADX1 or
ServerIron ADX2. Notice that because port 13 is the lead port for the trunk group, you do not need
to configure any other ports within that group.
Symmetric Active-Standby HA
Both ServerIron ADXs handle traffic, but the active VIP handles the L4-7 and the standby VIP serves
only as a standby. Each ServerIron ADX is the active ServerIron ADX for a specific set of VIPs, while
the other ServerIron ADX is the backup for the same set of VIPs.
In Symmetric Active-Standby HA, you determine which ServerIron ADXs are active and backup for a
VIP by associating the sym-priority command with the VIP. You assign a different priority to the
same VIP on each ServerIron ADX. The ServerIron ADX on which the VIP has the highest priority is
the active ServerIron ADX for that VIP, and the others are standbys. When all ServerIron ADXs and
associated links are available, the ServerIron ADX with the highest priority for the VIP services the
VIP.
Symmetric Active-Standby HA does not require any changes to the Spanning Tree configuration in
the network. Regardless of whether the network is using Spanning Tree, Symmetric Active-Standby
HA provides redundancy for the VIPs and allows all the ServerIron ADXs configured for Symmetric
Active-Standby HA to actively perform server load balancing.
In addition, you do not need to dedicate ServerIron ADX links to Symmetric Active-Standby HA.
Symmetric Active-Standby HA works within the network’s topology.
NOTE
You cannot have a router hop between the ServerIron ADXs. They must have Layer 2 connectivity.
Additionally, you cannot use Hot Standby HA and Symmetric Active-Standby HA features on the same
ServerIron ADX.
NOTE
If a ServerIron ADX is running software with a router image and the ServerIron ADXs are in an
active-active configurations, you need to enable VRRP or VRRP-E on these ServerIron ADXs;
otherwise, FTP, RTSP, and MMS protocols might not work. Also, configure the IP address of the real
server’s default gateway IP address in VRRP-E configuration and the "owner" IP address in VRRP
configuration. It is important that the default gateway should be defined. If it is not defined, then SI
does not send the Gratuitous ARP immediately after the VRRP and VRRPE switchover.
NOTE
The ServerIron ADX does not support Symmetric Active-Standby HA with shared source NAT IPs. The
reason is that the VIP and the source IP might not be active on the same ServerIron ADX, and as a
result, the ServerIron ADX does not know how to forward return traffic. Configure Symmetric
Active-Active HA as a workaround.
Configuring Symmetric Active-Standby HA
In Figure 42, two upstream routers are connected to two different ISPs. This setup allows clients to
access the ServerIron ADXs from different directions. Clients coming from ISP1 want an active VIP1
(on ServerIron ADX-A). The same VIP1 accessed by ISP2 is on standby (on ServerIron ADX-B). On a
per-ServerIron ADX basis, some VIPs are active while others are on standby. In contrast, all VIPs per
ServerIron ADX are either active or standby in a Hot Standby HA scenario.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
399
6
Symmetric Active-Standby HA
To configure Symmetric Active-Standby HA, configure the sym-priority value command on each
active and standby VIP. The higher the value, the higher the preference (priority). The range is from
0 through 255. You also can configure the priority to dynamically adjust to changes in the health of
applications on the VIP.
In Figure 42, ServerIron ADX-A’s VIP1 has a priority of 10. ServerIron ADX-B’s VIP1 has a priority of
5. Therefore, ServerIron ADX-A is active. When traffic comes to VIP1, ServerIron ADX-A creates the
session. When VIP1 on ServerIron ADX-A goes down, VIP1 on ServerIron ADX-B becomes active.
Only the active VIP owner responds to ARP, traffic, session synching, and so on. The Symmetric
solution provides granular control of the VIPs.
FIGURE 42
Common Symmetric configuration
Enabled by default, any Layer 2 link can be used for automatic session synchronization between
the ServerIron ADXs. Unlike Hot Standby HA, the ServerIron ADXs need not be directly connected.
To specify a specific port (optional), use the session-sync server subcommand on both devices.
Refer to “Configuring VLAN option for active-active links” on page 411.
400
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Symmetric Active-Standby HA
6
NOTE
To correctly handle the return traffic in this scenario, apply Source-NAT or DSR to a Symmetric
Active-Standby HA configuration. Enable one or the other (not both) for a real server.
Figure 43 shows another common Symmetric topology, where the real servers are directly
connected to the ServerIron ADXs.
FIGURE 43
Common Symmetric configuration
NOTE
To see the session sync, go to the BP and issue the show session all 0 command.
Failover conditions
Both ServerIron ADXs are active with Symmetric Active-Standby HA. Therefore, failover depends on
which device has ownership of the VIP. If a link is broken, both ServerIron ADXs are still active. In
general, the only time a VIP can fail over is during a reload or system crash. VIPs can fail over if they
meet the conditions described on “VIP failover following a link failure” on page 409. Use the show
log command to gather failover information.
Enabling session synchronization on a port
For each port you use for load balancing, you must define the session-sync command and port
number to enable session synchronization.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
401
6
Symmetric Active-Standby HA
NOTE
The session-sync command must to be enabled for all defined virtual and real ports.
As an example, to enable session synchronization for port 80 (HTTP), enter the following
commands.
ServerIronADX(config)#server port 80
ServerIronADX(config-port-80)#session-sync
Syntax: server port TCP/UDP-portnum
Syntax: [no] session-sync
NOTE
Issuing the no server port 80 command with the session-sync enabled command does not stop the
session synchronization for port 80 (HTTP).
NOTE
In case of port translation, enable session synchronization for both the VIP virtual port and the real
server port.
Additional configuration variations
Configuring the interval and wait time for Symmetric Active-Standby HA discovery
packets
A ServerIron ADX in an Symmetric Active-Standby HA configuration uses discovery packets to
request Symmetric Active-Standby HA information from the other ServerIron ADXs. Symmetric
Active-Standby HA discovery packets are proprietary Layer 2 broadcast packets and are sent on all
ports in all port-based VLANs. Use the server sym-pdu-rate command to change the interval and
wait time for Symmetric Active-Standby HA discovery packets.
By default, a ServerIron ADX in a Symmetric Active-Standby HA configuration sends discovery
packets at 200-millisecond intervals while the default wait time interval is twice the send interval
at 400-milliseconds. In other words, Symmetric Active-Standby HA discovery packets are sent at
every 200 milliseconds, but a recipient checks once in every 400 milliseconds to see whether the
packets are received. The ServerIron ADX waits up to 20 equivalent intervals to receive a discovery
packet from another ServerIron ADX. If the ServerIron ADX does not receive a discovery packet from
the other ServerIron ADX within 20 intervals, the ServerIron ADX concludes that its partner
ServerIron ADX is unavailable and assumes control of the VIPs being managed by that ServerIron
ADX. For example, if the interval for sending Symmetric Active-Standby HA discovery packets is 200
milliseconds (the default), the ServerIron ADX waits 20 X 400 milliseconds (eight seconds) to
receive a discovery packet from another ServerIron ADX.
You can change the send interval multiplier and the wait time multiplier.
• The send interval is equal to 200 milliseconds multiplied by the send interval multiplier. The
default send-interval multiplier is 1, so the default send interval is 200 milliseconds. You can
specify a multiplier from 1–60.
• The total wait time interval is equal to 400 milliseconds multiplied by the wait time multiplier.
The default wait time multiplier is 20; therefore, the default wait time is eight seconds (20 x
400 milliseconds).
402
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Symmetric Active-Standby HA
6
The Symmetric Active-Standby HA timer affects the rate at which the ServerIron ADX sends
Symmetric Active-Standby HA protocol packets to its Symmetric Active-Standby HA partners. The
timer does not affect client or server traffic to or from a VIP.
All the ServerIron ADXs in your configuration must use the same Symmetric Active-Standby HA send
interval and wait time. If you change the interval and wait time on one ServerIron ADX, make the
same change on all the other ServerIron ADXs in the Symmetric Active-Standby HA configuration.
To configure the interval and wait time for Symmetric Active-Standby HA discovery packets, enter a
command such as the following.
ServerIronADX(config)#server sym-pdu-rate 2 30
This command does the following:
• Changes the default send interval (200 ms) and wait interval (400 ms) by a factor of 2
• Increases the wait time multiplier from the default 20 to 30
In effect, this command:
• Changes the interval at which the ServerIron ADX sends Symmetric Active-Standby HA
discovery packets to once every 400 milliseconds
• Changes the wait interval for discovery packet to once every 800 milliseconds
• Changes the maximum amount of time the ServerIron ADX will wait for a Symmetric
Active-Standby HA discovery packet from another ServerIron ADX to 24 seconds (30 x 2 x 400
milliseconds).
Syntax: [no] server sym-pdu-rate send-wait-multiplier wait-time-multiplier
The send-wait-multiplier variable specifies the multiplier for the Symmetric Active-Standby HA send
and wait interval. You can specify a multiplier from 1–60. The default is 1.
The wait-time-multiplier variable specifies how many multiples of the wait interval the ServerIron
ADX will wait for a Symmetric Active-Standby HA discovery packet. You can specify a multiplier from
1–60. The default is 20.
Enabling synchronization link for Symmetric Active-Standby HA
You can specify a dedicated link (port and VLAN ID) for symmetric packets such as, session
synchronization packets and VIP sym-priority packets. When you enable this feature and the
dedicated link goes down, the ServerIron ADX will automatically detect this and revert back to the
dynamic detection of communication links.
To enable this feature, enter a command such as the following.
ServerIronADX(config)#server symmetric-port ethernet 1/2 vlan-id 101
Syntax: [no] server symmetric-port slot num/port num vlan ID
Enabling backup trunk port
For Hot Standby HA, the number of available ports in a trunk is counted in number of router or
server ports. If both ServerIron ADXs have 4-port trunks as router ports, for example, the router port
count is now 4 (it was 1). If one port of the trunk in ServerIron ADX-1 is down and ServerIron ADX-1
is active, ServerIron ADX-2 will become active, and ServerIron ADX-1 will become standby.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
403
6
Symmetric Active-Standby HA
Use the server backup-trunk-port-cnt command to enable this functionality, as shown in the
following.
ServerIronADX(config)#server backup-trunk-port-cnt
Syntax: [no] server backup-trunk-port-cnt
Setting Symmetric Active-Standby HA priority
If you are configuring a pair of ServerIron ADXs to provide redundancy for individual VIPs, you must
specify an SLB priority on each ServerIron ADX for each of the VIPs. The ServerIron ADX with the
higher priority for a given VIP is the default active ServerIron ADX for that VIP. The other ServerIron
ADX is the default standby for the VIP.
To specify the priority, enter a command such as the following.
ServerIronADX(config)#server virtual-name-or-ip noi-is-cool 10.2.3.4
ServerIronADX(config-vs-noi-is-cool)#sym-priority 254
Syntax: sym-priority num
You can specify from 0 through 255. If you specify 0, the priority setting is removed.
NOTE
Brocade recommends that you specify 2 (instead of 1) as a low priority or 254 (instead of 255) as a
high priority. This way, you can easily force failover of the high priority ServerIron ADX to the low
priority ServerIron ADX by changing the priority on just one of the ServerIron ADXs. For example, you
can force a failover by changing the priority on the high priority ServerIron ADX from 254 to 1.
Because the priority on the low priority ServerIron ADX is 2, the low priority ServerIron ADX takes over
for the VIP. Likewise, you can force the low priority ServerIron ADX to take over by changing its priority
to 255, because the priority on the high priority ServerIron ADX is only 254.
Configuring dynamic priority
The software automatically adjusts a VIP application’s symmetric priority to a lower value if a given
application fails a health check. With this enhancement, the symmetric priority provides failover for
the individual application even if the ServerIron ADX and the application’s VIP are both still active.
The priority determines which ServerIron ADX becomes the active one for the VIP and application by
default. The priority is static and does not change if the status of the VIP’s application changes. As
a result, it is possible for Symmetric Active-Standby HA to continue trying to use a real server farm
that is no longer responding, instead of failing over to the other ServerIron ADX to load balance
requests for the VIP and application.
You can configure a decrement value for the Symmetric Active-Standby HA priority. If an application
on a VIP that is enabled for Symmetric Active-Standby HA fails a health check, the ServerIron ADX
decrements the VIP’s symmetric priority by the amount you specify for the decrement. If the priority
value becomes lower than the VIP’s priority on the other ServerIron ADX, the software fails the VIP
over to the other ServerIron ADX.
NOTE
When you configure a decrement value, the value takes effect only if all the application’s ports on
the real servers fail their health checks. Thus, if the application is still available on at least one of
the real servers bound to the VIP, the software does not decrement the priority.
404
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Symmetric Active-Standby HA
6
NOTE
When you configure the decrement value, do not specify a value that will make the VIP’s priority 0.
For example, if the VIP’s symmetric priority is 10, do not specify 10 as the decrement value. Specify
a lower number. Priority value 0 disables Symmetric Active-Standby HA, in which case the VIP
becomes active on both ServerIron ADXs.
Figure 44 shows an example of a Symmetric Active-Standby HA configuration that uses the default
priority handling (not the dynamic priority handling).
FIGURE 44
Symmetric Active-Standby HA without dynamic priority
Using the default priority handling, the software fails over a VIP to the other ServerIron ADX only of
the entire VIP or the ServerIron ADX itself becomes unavailable. If an application on the VIP
becomes unavailable on all the real servers bound to the VIP, but the VIP itself is still available, the
software continues using the same ServerIron ADX for the VIP. As a result, clients are unable to
access the unavailable application even if the application is available through the other ServerIron
ADX.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
405
6
Symmetric Active-Standby HA
Figure 45 shows an example of a configuration that uses dynamic Symmetric Active-Standby HA
priority.
FIGURE 45
Symmetric Active-Standby HA with dynamic priority
In this configuration, a ServerIron ADX fails over a VIP to the other ServerIron ADX if more than one
application on the VIP becomes unavailable. If one application becomes unavailable, the software
reduces the VIP’s priority by 9 (the decrement value), in this case to 21. At this point, the ServerIron
ADX that is active by default for the VIP still has the higher priority, so failover does not occur.
However, if a second application becomes unavailable, then the priority becomes 12, which is less
than the priority for the VIP on the other ServerIron ADX (20).
When an application becomes available again (and passes a health check), the ServerIron ADX
increments the VIP’s priority by the decrement amount, thus replacing the priority amount that the
software removed when the application failed. If the increment makes the VIP’s priority higher than
the priority on the other ServerIron ADX, the software fails back over to the ServerIron ADX that
originally had the higher priority for the VIP.
If more than one ServerIron ADX has the highest priority for a VIP, the ServerIron ADX that has the
highest value for the lowest four bytes of its base MAC address becomes the active ServerIron ADX
for the VIP.
NOTE
If all the applications that are configured for Symmetric Active-Standby HA on the VIP become
unavailable, the software sets the symmetric priority for that VIP to 1 (the lowest value).
The following commands configure the symmetric priority parameters for the configuration in
Figure 45.
406
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Symmetric Active-Standby HA
6
Setting the symmetric MAC address
On a ServerIron ADX, the MAC address for the VIPs, source-nat ips and IP NAT ips is derived from
the first three bytes of the chassis MAC address. For instance, if the chassis MAC address is
000c.db12.1234, the MAC address for VIPs and NAT ips would be based on 000c.db00.0000.
In Symmetric/Symmetric Active-Active HA, this is known as the symmetric mac and both the boxes
need to derive the MAC address for VIPs and NAT ips from the same base MAC address.
In the event that an HA pair share the same first 3 bytes of the chassis MAC address, the
symmetric mac will be the same on both the boxes. In the event that the HA pair do not share the
same first 3 bytes of the chassis MAC address, the higher of the two chassis MAC addresses is
automatically chosen as the symmetric mac. For example, if Box A has a chassis MAC address of
000c.db12.1234 and Box B has a chassis MAC address of 001b.db12.2345, symmetric mac
would be automatically set to 001b.db00.0000, when both the boxes are brought up.
Alternatively, symmetric mac can be manually configured based on one of the box's chassis MAC
addresses. Use the sym-mac command to configure a symmetric mac as shown in the following.
ServerIronADX#configure terminal
ServerIronADX(config)#sym-mac 001b.db00.0000
Syntax: sym-mac sym-mac-address
The sym-mac-address variable specifies the first 3 bytes of the chassis MAC address of one of the
boxes in the HA setup.
Considerations when using this command
Consider the following when using the sym-mac command.
• Addition or deletion of this command requires a reload. Once configured, it is required to write
memory and reload the box in order for the command to take effect.
• When manually configuring symmetric mac, it is required to configure the same sym-mac
command on both the devices in the HA setup.
• Manual configuration of symmetric mac overrides the auto detection. When manually
configured, the symmetric mac used will be the configured value only.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
407
6
Symmetric Active-Standby HA
Displaying the symmetric mac
The show server virtual command can be used to view the symmetric mac that the boxes use to
derive the VIP and NAT IP MACs. The display from this command includes a field named symmetric
mac, as shown in the following.
ServerIronADX#show server virtual
Virtual Servers Info
Name: vip441
State: Enabled
IF UP
IP:10.1.1.200:
Pred: least-conn
ACL-Id: 0
TotalConn: 240
Sym: group = 1 state = 5 priority = 200 keep = 0
dyn priority/factor = 200/ 0
Activates =
1, Inactive= 1 sym-active = 1 Sym Priority = Enabled
Symmetric VIP state: Owner
Symmetric MAC: 748e.f800.0000
Best-standby-mac: 748e.f800.245a
VIP state: healthy
Port
----
State
-----
Sticky
------
Concur
------
Proxy
-----
DSR
---
CurConn
-------
TotConn
-------
PeakConn
--------
default
http
dns
ftp
enabled
enabled
enabled
enabled
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
0
13
0
64
0
22
22
196
0
14
0
156
1
Configuring delay reactivation
Use the server delay-symmetric command to delay the reactivation of a failed ServerIron ADX in a
Symmetric Active-Standby HA configuration following the ServerIron ADX’s recovery. By delaying
reactivation of a recovered ServerIron ADX, you provide time for sessions created by the standby
ServerIron ADX to terminate normally.
When you enable session synchronization in a ServerIron ADX Symmetric Active-Standby HA
configuration, the active ServerIron ADX for a VIP sends session synchronization information to the
standby ServerIron ADX. If the VIP’s active ServerIron ADX becomes unavailable, the open sessions
for the VIP fail over to the other ServerIron ADX, which provides uninterrupted service for the
sessions.
The active ServerIron ADX sends session synchronization information to a VIP’s standby ServerIron
ADX when the session is created. Following a failover, when the standby ServerIron ADX for a VIP
has taken over, the standby ServerIron ADX can create new sessions for the VIP. However, because
the ServerIron ADX with the higher priority for the VIP is unavailable, the standby ServerIron ADX
cannot send synchronization information for the newly created sessions. As a result, when the
other ServerIron ADX becomes available again, it resumes service for the VIP but cannot continue
the sessions that were created by the standby ServerIron ADX.
You can minimize interruption to sessions created on the standby ServerIron ADX by configuring
each ServerIron ADX to delay reactivation following its recovery after a failover. By delaying
reactivation of a recovered ServerIron ADX, you provide time for sessions created by the standby
ServerIron ADX to terminate normally.
408
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Symmetric Active-Standby HA
6
To configure delay reactivation, enter the following command.
ServerIronADX(config)#server delay-symmetric
Syntax: [no] server delay-symmetric [mins]
The mins variable specifies the number of minutes you want the recovered ServerIron ADX to wait
before becoming active again. You can specify from 1 through 120 minutes. The default is 60
minutes. You must enter the same command using the same number of minutes on both
ServerIron ADXs in the configuration.
NOTE
The server delay-symmetric command will only take effect when the ServerIron ADX is reloaded after
it has been configured for the first time.
NOTE
The server delay-symmetric command will not take effect when sym-priority is changed manually.
NOTE
The ServerIron ADX delay reactivation feature using the server delay-symmetric command was
introduced because "fast session sync" was not yet supported. Currently, the ServerIron now support
fast session sync to synchronize all the sessions when any of the ServerIron ADX reloads.
VIP failover following a link failure
In an active-active SLB configuration, each VIP is managed by one of the ServerIron ADXs by
default. The other ServerIron ADX is a backup for the VIP.
If the interface that has the VIP’s subnet becomes unavailable on the default active ServerIron ADX
for the VIP, the ServerIron ADX changes the symmetric priority for that VIP to 1 to cause a failover to
the other ServerIron ADX. Once the unavailable link is restored, the ServerIron ADX changes the
symmetric priority back to the value you configured.
NOTE
Failover occurs only if the entire link becomes unavailable. If the link is a trunk group or a virtual
routing interface residing on multiple ports, failover occurs only if all the ports become unavailable.
Under Layer 2 switching code, interfaces do not belong to individual subnets. As a result, under
Layer 2 switching code Symmetric Active-Standby HA VIP failover can only happen in the case of a
reload or system crash.
NOTE
On the current VRRP-e backup, the current sym-priority of all VIPs listed in a VIP group will become
1, and their sym-priority values will display as “Disabled”. This is normal behavior and ownership of
these VIPs will follow the VRRP-e master.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
409
6
Symmetric Active-Standby HA
Configuring VIP failover in VRRP extended with Symmetric Active-Standby HA
In Symmetric Active-Standby HA and Symmetric Active-Active HA configurations with VRRP-E, when
the device switches from the Master router to a Backup router, there is a CLI command that
guarantees simultaneous VIP failover in the event VRRP-E fails over to a Backup router. To enable
this feature, first define a VIP group that includes VIP addresses, then bind the VIP group to a
Virtual Router ID (VRID).
NOTE
Before defining and binding VIP groups, ensure that the standby VIP priority (sym-priority command)
is not set to 1. This value is reserved for internal use.
NOTE
In Symmetric Active-Standby HA, the VIP is active on both ServerIron ADXs if there is no default
gateway configured, even though all clients, servers, and ServerIron ADXs are on the same subnet.
To enable the VIP failover in VRRP extended with Symmetric Active-Standby HA, enter commands
such as the following.
1. Define a VIP group.
ServerIronADX(config)#server vip-group 1
ServerIronADX(config-vip-group-[1])#vip 10.10.1.100
ServerIronADX(config-vip-group-[1])#exit
2. Bind the VIP group to a VRID.
ServerIronADX(config)#router vrrp (-extended)
ServerIronADX(config)#interface e 1/2
ServerIronADX(config-if-e100-1/2)#ip vrrp vrid 1
ServerIronADX(config-if-e100-12-vrid-1)#vip-group 1
NOTE
Each virtual IP address can belong to only one VIP group. Also, each VIP group can have only one
VRID associated with it.
Enhanced VIP group support
The ServerIron VIP Group feature helps grouping of several virtual server addresses and
associating them with the VRRP-E tracking mechanism.
Syntax: [no] server vip-group number
The number variable is the VIP group number from 1 through 100.
Syntax: [no] vip ip address
The ip address variable is the Virtual IP address to be included in the VIP group. There is not limit to
the number of Virtual IP addresses in a VIP group; however, each virtual IP address can belong to
only one VIP group.
Syntax: [no] vip-group number
The number variable is the VIP group number (from 1 through 100) that you are binding to the
VRID. Note that each VIP group can have only one VRID associated with it.
410
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Symmetric Active-Standby HA
6
Configuring VLAN option for active-active links
Active-active SYN-Guard and NAT configurations use the server active-active-port ethernet portnum
command to identify the port that connects the ServerIron ADX to its active-active partner. The port
you specify must be in its own port-based VLAN.
To use a tagged port, specify the VLAN ID for the active-active link when you specify the port. When
you specify the VLAN ID, the ServerIron ADX forwards active-active traffic on the specified VLAN
only. The traffic is not sent to the other VLANs of which the port is a member.
To configures the active-active link, enter the command such as the following.
ServerIronADX(config)#server active-active-port ethernet 3/5 200
This command configures the active-active link on port 3/5 on VLAN 200 only. The active-active
traffic is not forwarded to the other VLANs that port 3/5 is in.
Syntax: [no] server active-active-port ethernet portnum [vlan-id]
NOTE
In ServerIron ADX device, you don't need to configure static-mac-address for active-active-port.
Allowing pass-through traffic to a VIP
In a symmetric-active SLB configuration, the ServerIron ADX intercepts SYN packets to a VIP if the
destination MAC address is not the VIP's MAC address.
The server allow-pass-through-vip-traffic command causes the ServerIron ADX to ignore SYN
packets addressed to a symmetric VIP IP address if the destination MAC address is not the
symmetric VIP MAC address.
To allow pass-through traffic to a VIP, enter the following command.
ServerIronADX(config)#server allow-pass-through-vip-traffic
Syntax: [no] server allow-pass-through-vip-traffic
Fast session synchronization with VRRP
ServerIron ADXs in symmetric high-availability configuration will support the fast session
synchronization. Fast session synchronization applies to symmetric and symmetric-active
topologies. With the fast session synchronization, if a software reload occurs in one ServerIron
ADX, the other ServerIron ADX in the symmetric high-availability pair synchronizes all existing
sessions with the newly reloaded ServerIron ADX. This process ensures that multiple failovers for
symmetric high-availability ServerIron ADXs occur seamlessly and without loss of traffic.
Fast session synchronization is enabled by default. There are no CLI commands to enable or
disable this feature. However, if VRRP is configured on your ServerIron ADXs you need to configure
a primary and secondary IP address on the VRRP interface of the VRID owner. The secondary IP
address must be associated with the VRID.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
411
6
Symmetric Active-Standby HA
FIGURE 46
Fast session synchronization with VRRP
NOTE
Associating the secondary IP with the VRID and other configuration mentioned above is a
requirement only for VRRP. There is no such requirement for VRRP-E in order to support fast session
synchronization feature.
The following configuration examples below show how to configure the VRRP owner and backup
with the primary and secondary IP addresses.
412
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Symmetric Active-Standby HA
6
VRRP-E track port increase
You can configure sixteen track ports with priority for a VRRP-E instance. Prior to this release, you
could only configure eight track ports.
The following example shows how to configure VRRP-E with priority.
ServerIronADX(config)#interface ve 2
ServerIronADX(config)#ip address 172.20.1.222 255.255.255.0
ServerIronADX(config)#ip vrrp-extended vrid 2
ServerIronADX(config)#backup
ServerIronADX(config)#ip-address 172.20.1.221
ServerIronADX(config)#track-port e 4/9 priority 09
ServerIronADX(config)#track-port e 4/10 priority 10
ServerIronADX(config)#track-port e 4/11 priority 11
ServerIronADX(config)#track-port e 4/12 priority 12
ServerIronADX(config)#track-port e 4/13 priority 13
ServerIronADX(config)#track-port e 4/14 priority 14
ServerIronADX(config)#track-port e 4/15 priority 15
ServerIronADX(config)#track-port e 4/16 priority 16
ServerIronADX(config)#track-port e 4/17 priority 17
ServerIronADX(config)#track-port e 4/18 priority 18
ServerIronADX(config)#track-port e 4/19 priority 19
ServerIronADX(config)#track-port e 4/20 priority 20
ServerIronADX(config)#track-port e 4/21 priority 21
ServerIronADX(config)#track-port e 4/22 priority 22
ServerIronADX(config)#track-port e 4/23 priority 23
ServerIronADX(config)#track-port e 4/24 priority 24
Syntax: [no] track-port interface priority value
Tracking trunk ports with VRRP-E
The ServerIron ADX allows you to configure trunk ports to provide the higher bandwidth required by
many application switching network designs. If, however, an individual port within a trunk fails the
expected throughput will fall but failover in a VRRP-E track port configuration will not occur unless
all of the ports in the trunk fail.
The Track Trunk Port with VRRP-E feature allows the ServerIron ADX to track the failure of individual
ports within a trunk. When a tracked port within a trunk fails, the VRID priority value is changed as
described in the following:
• If all ports in the trunk are up, the VRID priority value is unchanged.
• If none of the ports in the trunk are up, the Track Priority is subtracted from the backup priority
to determine the current VRID priority value.
• If any of the ports in the trunk fail, the following formula is used.
• A new Track Priority value is determined by the following formula: track priority x (number of
configured ports in trunk - the number of active ports in trunk) ÷ number of configured ports in
trunk
• The new Track Priority value is subtracted from the backup priority value to determine the
current VRID priority.
Syntax: [no] track-trunk-port ethernet slot/port
ServerIron ADX Server Load Balancing Guide
53-1003452-01
413
6
Symmetric Active-Standby HA
Configuration considerations
The following must be considered when configuring the Track Trunk port feature:
• This feature only applies to VRRP-E.
• Only ports that are members of a static trunk or are LACP enabled can be configured as track
trunk ports.
• If a port that is not a member of a trunk group or LACP is configured as a track trunk port, it will
behave like a track port.
• If different ports with the same trunk group are configured as track port and track trunk port,
they will all behave as if configured as track trunk ports.
• Before removing a static trunk or LACP configuration, a port should be removed from the track
trunk port list.
• Co-existence of track-port and track-trunk-port within the same trunk should be avoided.
• Co-existence of track-trunk-port and track-port ve with in the same trunk should be avoided.
• If you are using track-trunk-port, it is preferable to configure all the ports with in the trunk as
track-trunk-ports.
• Where Track-trunk-port and Track-port VE pertaining to same trunk exists, the ServerIron ADX
takes both into consideration when calculating VRRP-E Master and Backup selection. Add
"track-port" before you add "track-trunk-port" for the same trunk.
Configuring tracking trunk ports with VRRP-E
To configure the tracking ports with the VRRP-E, enter the following commands.
ServerIronADX(config)#trunk switch e 4/9 to 4/10
Trunk will be created in next trunk deploy.
ServerIronADX(config-)#trunk deploy
ServerIronADX(config)#int ve 1
ServerIronADX(config-vif-1)#ip vrrp-extended vrid 1
ServerIronADX(config-vif-1-vrid-1)#backup priority 200 track-priority 100
NOTE
The backup priority must be a decimal of 6 through 255 for vrrp-extended. The track-priority must
be a decimal from 1 through 254.
ServerIronADX(config-vif-1-vrid-1)#track-trunk-port e 4/9
NOTE
Optionally, you can specify track priority for the track-port. This overrides the track-priority specified
in "backup priority x track-priority y".
ServerIronADX(config-vif-1-vrid-1)#track-trunk-port e 4/9 priority 80
NOTE
The track-port and track-trunk-port must be trunk primary, otherwise an error will be prompted.
ServerIronADX(config-vif-1-vrid-1)#track-port e 4/10
Error - track port must be the first port of a trunk.
ServerIronADX(config-vif-1-vrid-1)#track-trunk-p e 4/10
Error - track trunk port must be the trunk primary.
414
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Symmetric Active-Standby HA
6
Sample configuration
ServerIronADX#sh run | i trunk
trunk server ethe 4/1 to 4/4
trunk server ethe 4/5 to 4/6
trunk switch ethe 4/9 to 4/10
ServerIronADX#sh run int ve 1
!Building configuration...
!Current configuration : 346 bytes
interface ve 1
ip address 10.2.2.21 255.255.255.0
ip vrrp-extended vrid 1
backup priority 200 track-priority 100
advertise backup
ip-address 10.2.2.30
vip-group 1
track-trunk-port e 4/1
track-port e 4/5
track-trunk-port e 4/5
track-port e 4/9
track-trunk-port e 4/9
enable
To remove the track-port, track-trunk-port needs to be removed first.
ServerIronADX(config-vif-1-vrid-1)#no track-port e 4/9
You must disable track-trunk-port before the track-port.
ServerIronADX(config-vif-1-vrid-1)#
NOTE
To remove trunk, track-trunk-port must be removed first.
ServerIronADX(config-vif-1-vrid-1)#no trunk swi e 4/9 to 4/10
You must remove the track-port in the VRRP-E configuration first. To configure this feature, follow
these steps.
1. The following command can ONLY be configured for trunk primary.
ServerIronADX(config-vif-13-vrid-1)#track-trunk-port ethernet 4/34
Error - track trunk port must be the trunk primary.
ServerIronADX(config-vif-13-vrid-1)#
2. Add "track-port" before adding "track-trunk-port" for the same trunk.
ServerIronADX(config-vif-13-vrid-1)#track-trunk-port ethernet 4/33
Must track-port this trunk before track-trunk-port the same trunk
ServerIronADX(config-vif-13-vrid-1)#
3. Add "no track-trunk-port" before adding "no track-port" for the same trunk.
ServerIronADX(config-vif-13-vrid-1)#no track-port e 4/33
Must disable track-trunk-port before track-port
ServerIronADX(config-vif-13-vrid-1)#
Sample configuration
In the following configuration, both SI-A and SI-B share a trunk with a FastIron switch. The trunk has
two ports (e4/33-34) and the primary trunk is e4/33. VRRP-E vrid 1 is configured in interface
e4/17.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
415
6
Symmetric Active-Active HA
Symmetric Active-Active HA
Symmetric Active-Active HA is a true active-active. Both ServerIron ADXs handle traffic
(active-active), and both ServerIron ADXs are active for the same VIP on both ServerIron ADXs.
Difference between Symmetric Active-Active HA versus
Symmetric Active-Standby HA
The difference is minimal. For Symmetric Active-Active HA, the difference is that Symmetric
Active-Active HA is configured on the VIP to enable the standby box to process traffic. The load and
CPU processing per VIP is equally shared between both ServerIron ADXs, as shown in the Figure 47.
FIGURE 47
Comparing Symmetric Active-Active HA with Symmetric
When Symmetric Active-Active HA is enabled on both ServerIron ADXs, both boxes handle traffic
equally for each VIP. A box with Symmetric Active-Active HA configured is enabled to process and
forward traffic to and from the client, regardless of an assigned lower VIP priority.
416
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Manual triggering of symmetric HA failover with VRRP-E
6
Configuring Symmetric Active-Active HA
To enable the Symmetric Active-Active HA on each VIP, enter commands such as the following.
ServerIronADXA(config)#server virtual-name-or-ip VIP1 10.1.1.1
ServerIronADXA(config-vs-VIP1)#port 80
ServerIronADXA(config-vs-VIP1)#sym-priority 69
ServerIronADXA(config-vs-VIP1)#sym-active
This example configures VIP1 by adding port 80, enabling Symmetric Active-Standby HA, then
enabling Symmetric Active-Active HA. With Symmetric Active-Active HA, you still need to configure
the sym-priority command. Whichever ServerIron ADX has the higher priority will own the VIP
address, MAC, and ARP responses. If someone pings the VIP for example, only the active VIP will
reply.
Syntax: [no] sym-active
NOTE
Source-NAT and DSR are usually not applied a Symmetric Active-Active HA configuration. The return
traffic is correctly handled in this scenario. The active and standby ServerIron ADXs are constantly
sharing information.
NOTE
When using a pair of ServerIrons in an HA setup, configure Symmetric Active-Active HA in addition
to Symmetric Active-Standby HA, VRRPE, and VIP groups. This is because VRRPE failover and
Symmetric Active-Standby HA failover are two separate events. First, VRRPE failover occurs, followed
by Symmetric Active-Standby HA failover. Configuring Symmetric Active-Active HA allows the
ServerIron to cope with the miniscule window between those two events.
Manual triggering of symmetric HA failover with VRRP-E
The ServerIron ADX allows you to manually trigger a failover in a symmetric HA configuration with
VRRP-E. This feature is useful when upgrading the active ServerIron ADX software or
troubleshooting the ServerIron ADX. The ServerIron ADX transitions from active to standby
seamlessly and no longer handles any traffic before the upgrade or troubleshooting process.
This feature uses VRRP-E to trigger the failover by lowering the VRRP-E priority to 1. When VRRP-E
failover occurs, the ownership of all VIPs that are bound to a VIP group associated with a VRRP-E
interface is transferred to the standby ServerIron ADX for the handling of all traffic.
NOTE
This feature works with VRRP-E only. You must configure all VIPs under a VIP group, and associate
the VIP group to a VRRP-E interface.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
417
6
Manual triggering of symmetric HA failover with VRRP-E
Configuring manual HA failover
To configure manual failover to the standby ServerIron ADX by dynamically setting the VRRP-E
priority to 1 for all VRRP-E configurations on the active ServerIron ADX, use the vrrp-e standby
command in EXEC or global configuration mode.
NOTE
For the VIPs to failover with the VRRP-E interface, you must configure all VIPs under a VIP group or
groups and you must associate the group with the VRRP-E interface.
Example in global configuration mode
ServerIronADX(config)# vrrp-e standby
Syntax: [no] vrrp-e standby
In the case of an upgrade, when ServerIron ADX reboots, the original priority is restored and the
ServerIron ADX becomes the active ServerIron ADX again. To reboot the ServerIron ADX with a
VRRP-E priority set to 1 and to remain as the standby ServerIron ADX, use the write memory
command before rebooting it to preserve the vrrp-e standby command. For more detailed
information, refer to the “Upgrade process for the symmetric HA setup using VRRP-E” section.
Use the no form of the command to manually restore the priority to the original value and the
ServerIron ADX becomes the VRRP-E owner.
Example in EXEC mode
ServerIronADX # vrrp-e standby
Syntax: vrrp-e standby [disable]
The disable option restores the original priority and transfers ownership to the ServerIron ADX with
the highest priority.
NOTE
In EXEC mode, the vrrp-e standby command cannot be saved across reboots.
Upgrade process for the symmetric HA setup using VRRP-E
The upgrade process that uses VRRP-E to trigger a failover works only if VRRP-E is configured on
the symmetric HA setup. You must configure all VIPs under a VIP group and bind the VIP group to a
VRRP-E instance.
The configuration can have multiple VIP groups, but all VIPs must be under the VIP groups and the
VIP groups must be bound to a VRRP-E instance. The following is a sample configuration.
server vip-group 1
vip 20.20.20.100
vip 20.20.20.101
server vip-group 99
vip 20.20.20.102
vip 20.20.20.103
vip 20.20.20.104
vip 20.20.20.105
interface ve 10
ip address 10.10.10.2 255.255.255.0
418
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Manual triggering of symmetric HA failover with VRRP-E
6
ipv6 address 2001:10::2/64
ip vrrp-extended vrid 10
backup priority 99
advertise backup
ip-address 10.10.10.254
vip-group 1
track-trunk-port e 1/1
enable
!
interface ve 11
ip address 11.11.11.2 255.255.255.0
ip vrrp-extended vrid 11
backup priority 99
advertise backup
ip-address 11.11.11.254
vip-group 99
track-trunk-port e 1/1
track-port e 1/5
track-port ve 20
track-port ve 21
enable
After you enable VRRP-E and all VIPs are bound to a VRRP-E instance using the VIP-group
configuration, you can use the vrrp-e standby command on the active ServerIron ADX to trigger the
manual failover of the VRRP-E and the failover of all traffic to the standby ServerIron ADX, which
becomes the active device. Then you can upgrade the current standby ServerIron ADX without
affecting the traffic flow. The following table provides the upgrade process.
TABLE 40
Upgrade process for symmetric HA failover with VRRP-E
ServerIron ADX A
ServerIron ADX B
ServerIron ADX A is the active device and the VRRP-E master.
ServerIron ADX B is the standby device and the
VRRP-E backup.
1
Since this ServerIron ADX is the standby and
is not taking any traffic, upgrade the image
on it without affecting any traffic.
2
After the upgrade is complete, verify that you
have the correct image and configuration.
3
4
5
Configure the vrrp-e standby command at global
configuration mode and execute the write memory
command.
Dynamically all VRRP-e instances reduce to backup
priority to 1, causing ServerIron ADX B to take ownership.
ServerIron ADX A becomes the standby device.
VIP ownership is also transferred, as all VIPs are bound
to the VRRP-e instance using the VIP group.
Upgrade the code and reload with new image.
On reload, ServerIron ADX A comes up as VRRP-E backup
with the backup priority of all VRRP-E instances still at 1
and remains the standby device.
Verify that the image and configuration are correct.
Configure the no vrrp-e standby command at global
configuration mode and execute the write memory
command again.
The VRRP-E backup priority is restored, and ServerIron ADX A
becomes the VRRP-E master and the active device. It now
receives all traffic.
ServerIron ADX B becomes the active device and
the owner for all VIPs, and starts handling traffic.
6
ServerIron ADX Server Load Balancing Guide
53-1003452-01
ServerIron ADX B becomes the VRRP-E backup
and the standby device.
419
6
Manual triggering of symmetric HA failover with VRRP-E
NOTE
The write memory command is used to save the vrrp-e standby command in the
startup-configuration. Upon reload when the device comes up, all VRRP-E instances remain in the
Backup state.
Displaying the current VRRP-E priority status
To display the current VRRP-E priority status, use the show ip vrrp-extended command.
ServerIronADX# show ip vrrp-e
Total number of VRRP-Extended routers defined: 1
Interface ethernet v10
auth-type no authentication
VRID 10
state initialize
administrative-status enabled
standby enabled
priority 100
current priority 1
hello-interval 1 sec
dead-interval 0 sec
current dead-interval 3.600 sec
preempt-mode true
virtual ip address 10.10.10.254
advertise backup: enabled
master router 10.10.10.2 expires in 00:00:02
VRRP-e MAC address: 02e0.52a0.c00a
ServerIronADX# show ip vrrp-e bri
Total number of VRRP-Extended routers defined: 1
Standby enabled
Interface VRID CurPri
v10
10
1
P State Master addr Backup addr VIP
P Backup 10.10.10.2 Local
10.10.10.254
Syntax: show ip vrrp-extended [brief]
The brief option displays the VRRP-E status summary.
Table 41 describes the VRRP-E priority status fields for the show ip vrrp-extended command.
TABLE 41
Priority status displayed by the show ip vrrp-extended command
Field
Description
Standby enabled
Whether the ServerIron ADX is enabled as the standby by the vrrp-e standby
command.
Priority
The configured backup priority. This field is not available with the brief option.
Current Priority or CurrPri The current priority of the ServerIron ADX. If you configure the vrrp-e standby
command, this field displays a setting of 1.
420
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Orchestrating seamless HA failover using VRRP-E pool
6
Orchestrating seamless HA failover using VRRP-E pool
In symmetric HA modes, a VIP group combined with VRRP-E tracking is used to achieve symmetric
traffic flow. However, in certain failover situations where VRRP-E non-preemption is enabled, traffic
symmetry may get disturbed, resulting in traffic loss.
FIGURE 48
HA pair configuration
In the network topology shown in Figure 48, the ADX-1 and ADX-2 devices are configured as a High
Availability (HA) pair. VRID-1 is running upstream of ADX, while VRID-2 and VRID-3 are running
downstream of ADX. These VRID instances are also configured to track any failure of interface
ports. In addition, non-preemption is enabled on ADX-1.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
421
6
Orchestrating seamless HA failover using VRRP-E pool
In the beginning, the two systems are configured so that ADX-1 owns all the VIPs and is the master
of all three VRRP-E VRID instances. A failure of the link between ADX-1 and an upstream Layer 3
router results in HA failover, and ownership of all VIPs and VRID instances is transferred to ADX-2
accordingly. Because non-preemption is configured on ADX-1, ADX-2 continues to retain ownership
even after recovery of the failed link.
At this stage, both forward and reverse SLB traffic is processed by ADX-2.
If the link between ADX-2 and the upstream Layer 3 router fails, ADX-1 assumes ownership of VRID
1, while ADX-2 retains the ownership for VRID 2 and VRID 3. The forward traffic is now directed to
ADX-1, while reverse traffic is directed to ADX-2. Although the traffic continues to flow uninterrupted
at this stage, it is asymmetric, which may be undesirable in some installations.
The VRRP-E pool mitigates the asymmetry by grouping VRID instances and tracking their ownership
states together. In Figure 48, if the VRRP-E pool is configured to include VRID 1, VRID 2, and VRID
3, then, upon link failure between ADX-2 and the upstream Layer 3 router, the ownership for all
three VRID instances is switched over to ADX-1 regardless of the non-preemption setting on ADX-1.
This maintains traffic symmetry.
NOTE
If a VRRP-E pool has at least one VRID enabled for non-preemption mode, then all the other VRIDs
within the same pool will also assume the non-preemption mode of operation.
The VRRP-E VRID pool ensures that all instances within the pool that are in the backup state
override the non-preemption setting if one of the following situations occurs:
• The unit that has high VRRP-E priority receives an advertisement with lower priority and the
VRRP-E pool to which it belongs to has at least one master (similar to the interface failure
scenario described previously).
• The unit receives consecutive advertisements with reducing priorities, and all the tracked ports
are up.
NOTE
Aggregation is applicable to both track-ports and track-trunk ports and are propagated topeer VRIDs
within the same pool.
422
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Orchestrating seamless HA failover using VRRP-E pool
6
Configuring VRRP-E pools
To configure a VRRP-E pool and add member VRID instances, use the following commands.
Brocade (config)# ip vrrp-extended pool 7
Brocade (conf-vrrpe-pool)# vrid 3
Syntax: ip vrrp-extended pool pool-id
The pool-id variable identifies the pool with the specified ID. The ID ranges from 1 through 8.
Syntax: vrid vrid # | all
The vrid # variable identifies the specified instance. The all option adds all the configured VRIDs to
the pool at once rather than one by one.
NOTE
When the vrid all command is used, you must ensure that there is only one VRRP-E pool in the in the
ServerIron ADX device.
Use the show ip vrrp-extended pool command to display VRRP-E pool details.
Brocade # show ip vrrp-extended pool
Total number of pools: 1
Pool 1
Mode : Preempt
Tracked Ports :ethernet 1
ethernet 2
ethernet 3
ethernet 4
Member VRIDs : 20 [MASTER]
10 [MASTER]
Guidelines for configuring VRRP-E pools
• Configure all VRID instances to track the same set of interface ports.
• If track port priority is defined, then it must be same across all VRID instances.
• If a virtual interface (VI) consists of more than one physical interface port, the VRID must track
each of these physical ports individually.
• If a VRRP-E is configured on a virtual interface, you must add the virtual interface as well as
the member ports as track-ports for VRRP-E pool configuration.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
423
6
Maintaining traffic symmetry by adjusting OSPF cost during HA and VRRP-E switchover
Maintaining traffic symmetry by adjusting OSPF cost during
HA and VRRP-E switchover
In many HA deployments, the administrator maintains symmetry of the traffic flow by adjusting SYM
priorities, VRRP-E track priorities, and routing protocol costs to favor one device over the other.
During HA failover, the non-owner ServerIron ADX device takes over control of service VIPs by
adjusting the SYM priority values. The VRRP-E ownerships are also shifted by adjusting the VRRP-E
track priority. In addition, the ServerIron ADX device provides a mechanism to adjust OSPF cost to
maintain traffic symmetry.
FIGURE 49
424
Adjusting OSPF cost - Sample network topology
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Configuring OSPF cost adjustment during HA and VRRP-E failover
6
In the network topology shown in Figure 49, the downstream is configured with VRRP-E while the
upstream is configured with OSPF. The definition of VIP groups with VRRP-E tracking is leveraged to
associate VIP ownership with VRRP-E ownership. The routes for VIP subnets will be propagated by
OSPF from ADX to Layer 3 router.
If the VIP Route Health Injection (VIP RHI) feature is not enabled, both the ServerIron ADX devices
advertise the route for the VIP subnet through OSPF. The router upstream of the ServerIron ADX
devices observe two paths to reach the VIP route and distribute the traffic between the two,
breaking the overall symmetry of traffic flow.
The ServerIron ADX devices in the HA pair can be programmed to advertise a lower OSPF cost from
the device that holds ownership for VIP and VRRP-E. With the OSPF cost adjustment feature
enabled, the OSPF cost from the non-owner device is incremented by a preconfigured value. The
upstream router thus prefers the ServerIron ADX device that owns all VIPs and VRRP-E for
forwarding client traffic. During HA failover, the advertised OSPF costs are adjusted again to
maintain traffic symmetry.
NOTE
If VIP Route Health Injection (VIP RHI) feature is enabled on ADX, then only the owner ServerIron ADX
device advertises the VIP route. The OSPF cost adjustment in such deployments becomes
unnecessary.
Configuring OSPF cost adjustment during HA and
VRRP-E failover
The route map configuration has been enhanced by including the set track-vrrp-e command for
tracking a VRRP-E instance. Additional VRRP-E instances may be tracked by repeating the
command with a different sequence ID.
To track a VRRP-E instance, use the following command.
Brocade (conf)# set track-vrrp-e vrid 7 incremental-cost 110
Syntax: set track-vrrp-e vrid vrid incremental-cost cost
The vrid variable identifies the VRID instance. The cost variable specifies the incremental cost
value and ranges from 1 through 255. The default is 200.
The OSPF cost for the advertised VIP route from the non-owner ServerIron ADX unit is increased by
the value specified for cost. The OSPF cost from the owner ServerIron ADX device is not changed.
The show route-map command has been enhanced to display details of the tracked VRRP-E
instances.
Example:
ADX(config)#router ospf
ADX(config)#redistribution static route-map rm1
ADX(config)#route-map rm1 permit 10
ADX(config-routemap rm1)# match ip address 1
ADX(config-routemap rm1)# set metric-type type-1
ADX(config-routemap rm1)# set track-vrrp-e vrid 1 incremental-cost 250
ADX(config)# route-map rm1 permit 20
ADX(config-routemap rm1)# match ip address 2
ADX(config-routemap rm1)# set metric-type type-1
ADX(config-routemap rm1)# set track-vrrp-e vrid 1
ServerIron ADX Server Load Balancing Guide
53-1003452-01
425
6
Additional variations
OSPF and route-map configuration
ServerIronADX 1000# configure terminal
ServerIronADX 1000(config)# router ospf
ServerIronADX 1000(config)# redistribution static route-map rm1
Configuring track VRRP-e with an incremental cost
ServerIronADX
ServerIronADX
ServerIronADX
ServerIronADX
250
1000(config)# route-map rm1 permit 1
1000(config-routemap rm1)# match ip address 2
1000(config-routemap rm1)# set metric-type type-1
1000(config-routemap rm1)# set track-vrrp-e vrid 1 incremental-cost
Configuring track VRRP-E with default incremental cost
ServerIronADX
ServerIronADX
ServerIronADX
ServerIronADX
1000(config)#route-map rm1
1000(config-routemap rm1)#
1000(config-routemap rm1)#
1000(config-routemap rm1)#
permit 2
match ip address 4
set metric-type type-1
set track-vrrp-e vrid 1
Additional variations
Multiple high availability SLB pairs in the same VLAN
Hot Standby HA topology
Hot Standby HA redundancy enables a ServerIron ADX to serve as an automatic backup for another
ServerIron ADX. Each Hot Standby HA pair consists of two ServerIron ADXs.
You can configure up to 127 Hot Standby HA pairs within a single broadcast domain in a Hot
Standby HA topology. To do this, configure a backup group ID on each of the ServerIron ADXs. Both
ServerIron ADXs in a given pair have the same ID. The ID uniquely identifies the pair.
When you configure a backup group ID, both ServerIron ADXs in a Hot Standby HA pair use the ID
when exchanging backup information. If a ServerIron ADX receives a backup information packet but
the packet's backup group ID does not match the ServerIron ADX's backup group ID, the ServerIron
ADX will not process this packet for Hot Standby HA.
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.
426
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Additional variations
6
Configuring a backup-group ID
Use the server backup-group id command to configure a backup-group ID. Enter the same ID on
both ServerIron ADXs in a Hot Standby HA pair. Do not enter the same ID on a ServerIron ADX that
is not one of the ServerIron ADXs in the Hot Standby HA pair. The default value is 0. This feature is
turned on by default.
To configure a backup-group ID, enter the following command.
ServerIronADX(config)#server backup-group 1
Syntax: [no] server backup-group id
The id variable specifies the backup-group ID and can be a number from 0 through 7.
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 ServerIron ADXs will become active (instead of
one standby and one active).
Symmetric topology
Symmetric Active-Standby HA increases performance and simplifies a redundant topology. It
provides these benefits by allowing you to implement redundancy on an individual VIP basis. Unlike
a conventional Hot Standby HA configuration, you can actively use all the ServerIron ADXs in a
Symmetric Active-Standby HA configuration simultaneously.
You can configure up to 255 Symmetric Active-Standby HA pairs within a single broadcast domain
in a symmetric topology. To do this, configure a symmetric group ID on each of the ServerIron ADXs.
Both ServerIron ADXs in a given pair must have the same ID. The ID uniquely identifies the pair.
When you configure a symmetric group ID, both ServerIron ADXs in a Symmetric Active-Standby HA
pair use the ID when exchanging symmetric protocol information. If a ServerIron ADX receives a
symmetric protocol information packet but the packet's symmetric group ID does not match the
ServerIron ADX's symmetric group ID, the ServerIron ADX discards the packet.
If the broadcast domain contains multiple symmetric pairs, you must configure symmetric group
IDs on all pairs. If the broadcast domain contains only one symmetric pair, you do not need to
configure a symmetric group ID.
Configuring a symmetric group ID
To configure a symmetric group ID, enter the following command.
ServerIronADX(config)#server symmetric-group 2
Syntax: [no] server symmetric-group id
The id variable specifies the symmetric group ID and can be a number from 1 through 255. The
default value is 1 and this feature is enabled by default. Enter the same ID on both ServerIron ADXs
in a symmetric pair. Do not enter the same ID on a ServerIron ADX that is not one of the ServerIron
ADXs in the symmetric pair.
NAT in HA environments
The ServerIron ADX supports NAT in high availability (HA) environments using VRRP or VRRP-E.
Inside source NAT translates the private source IP address of a host into a public IP address before
forwarding the host’s packet onto a public network.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
427
6
Additional variations
VRRP and VRRP-E
NOTE
ServerIronADX supports VRRP-E for IPv4 and IPv6.
Virtual Router Redundancy Protocol (VRRP) and a Brocade-enhanced implementation of VRRP
called VRRP Extended (VRRP-E) enable a pair of ServerIron ADXs in a high-availability configuration
to provide redundant support for an IP address. If one of the ServerIron ADXs becomes unavailable,
the redundant IP address continues to be available on the other ServerIron ADX. For example, you
can use VRRP-E in an active-active SLB configuration to provide redundancy for a ServerIron ADX IP
address used as clients or servers connected to the ServerIron ADXs as their default gateway.
You can use either VRRP or VRRP-E in your redundant configurations. The primary difference
between the two protocols is that VRRP requires the backed up address to be owned by one of the
devices. This means the address is physically configured on one of the interfaces used for the
backed up address. VRRP-E does not have this requirement.
NOTE
The following examples assume the ServerIron ADX is in the same subnet as the source and
destination address of the translated traffic.
VIP-group for NAT pools
The following commands enable the two ServerIron ADXs in a redundant configuration to negotiate
the ownership of NAT pools.
Use the ip-nat-pool command to specify the NAT pool under a server VIP group.
ServerIronADX(config)#server vip-group 1
ServerIronADX(config-vip-group-[1])#ip-nat-pool pool1
Once NAT pools are defined as members of a VIP group, the VIP group must be added to a VRRP-E
configuration, under the VRID. It must be added to the outside interface (the interface configured
with the ip nat outside command).
interface eth x/x
ip vrrp-extended vrid n
vip-group n
428
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Additional variations
6
Configuration example: active-active inside source NAT with VRRP-E
Figure 50 shows an example of a topology of inside source NAT configuration that also uses
VRRP-E. Each ServerIron ADX is configured with the same source NAT information. In addition, each
ServerIron ADX is configured as a VRRPE backup for the IP addresses of the interfaces to the
routers.
FIGURE 50
Inside source NAT with VRRP-E
The ServerIron ADXs are each configured to translate the source IP addresses of clients in the
private network (10.10.10.x) into IP addresses in the external network (10.10.20.x). For simplicity,
this example uses another private subnet as the external subnet. However, the external IP
addresses would normally be Internet addresses.
To provide additional redundancy, each ServerIron ADX is connected to the Layer 2 switches by four
ports. The ports are all members of the same VLAN and share a virtual routing interface. As a
result, if an individual port becomes unavailable, the link remains intact. If the entire link becomes
unavailable, VRRP-E fails over to the ServerIron ADX, to maintain availability of the backed up IP
address.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
429
6
Additional variations
The IP addresses that are backup by VRRP-E are the addresses used by the hosts in the 10.10.10.x
and 10.10.20.x sub-nets as their default gateways. For example, VRRP-E is configured on both
ServerIron ADXs to back up IP address 10.10.20.1, which is used by the hosts in 10.10.20.x as the
default gateway.
Notice that each backed-up address is configured on a virtual routing interface, which is associated
with all the ports connecting the ServerIron ADX to the address’ subnet. Normally, an IP address
can be associated with only one physical port. To associate the address with all the ports in the
trunk group, this configuration places all the ports into a separate port-based VLAN, adds a virtual
routing interface to the VLAN, then configures the backed up IP address on the virtual routing
interface.
By default, the ServerIron ADX on which you configure the higher VRRP-E priority for the backed up
IP address is the master for the address and handles the routing for the address. The other
ServerIron ADX is a backup. If the master ServerIron ADX is unable to continue routing for the
address, the backup ServerIron ADX performs the routing for the address.
ServerIron ADX-A configuration
ServerIronADX> enable
ServerIronADX#configure terminal
ServerIronADX(config)#hostname ServerIron ADXA
The following commands configure two virtual interfaces, for the ServerIron ADX’s interfaces with
the internal and external networks. Each interface is configured on a port-based VLAN consisting of
four ports. Notice that an IP address is configured on each virtual routing interface. VRRP and
VRRPE require the interface on which you configure a virtual router ID (VRID) to have an IP interface
that is in the same subnet as the VRID address. In this example, virtual routing interface 1 has IP
address 10.10.20.1 and its VRID address (configured later in this example) is 10.10.20.10. Virtual
routing interface 2 has IP address 10.10.10.1 and VRID address 10.10.10.10.
ServerIronADXA(config)#vlan 100
ServerIronADXA(config-vlan-100)#untagged ethernet 1/1 to 1/4
ServerIronADXA(config-vlan-100)#router-interface ve 1
ServerIronADXA(config-vlan-100)#exit
ServerIronADXA(config)#interface ve 1
ServerIronADXA(config-ve-1)#10.10.20.1 255.255.255.0
ServerIronADXA(config-ve-1)# exit
ServerIronADXA(config)#vlan 200
ServerIronADXA(config-vlan-200)#untagged ethernet 1/5 to 1/8
ServerIronADXA(config-vlan-200)#router-interface ve 2
ServerIronADXA(config-vlan-200)#exit
ServerIronADXA(config)#interface ve 2
ServerIronADXA(config-ve-2)#10.10.10.1 255.255.255.0
ServerIronADXA(config-ve-2)#exit
The following commands configure the source NAT parameters. The access-list command
configures a standard IP ACL to identify the source IP addresses that are eligible for translation.
These are the addresses of the hosts on the internal network. The ip nat pool command configures
an IP address pool for use during translation. The source IP address of an internal host’s packet will
be translated to one of the addresses in the pool before being forwarded to the external network.
The ip nat inside source command enables inside source NAT and identifies the ACL containing the
source addresses to be translated and the pool containing the translation addresses. The ip nat
outside command on virtual routing interface 1 indicates that this is the NAT interface connected to
the external network. Likewise, the ip nat inside command on virtual routing interface 2 indicates it
is the NAT interface connected to the inside network.
430
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Additional variations
6
ServerIronADXA(config)#access-list 1 permit 10.10.10.0 0.0.0.255
ServerIronADXA(config)#ip nat pool actnat 10.10.20.10 10.10.20.20 prefix-len 24
ServerIronADXA(config)#ip nat inside source list 1 pool actnat
ServerIronADXA(config)#interface ve 1
ServerIronADXA(config-ve-1)#ip nat outside
ServerIronADXA(config-ve-1)#exit
ServerIronADXA(config)#interface ve 2
ServerIronADXA(config-ve-2)#ip nat inside
ServerIronADXA(config-ve-2)#exit
The following commands configure the active-active link between the ServerIron ADX devices. The
port used for the link must be in its own port-based VLAN, separate from the other ports.
The server active-active-port command specifies the active-active port and the VLAN used to
perform the session SYNC for the SYN-Guard and the NAT traffic.
ServerIronADXA(config)#vlan 13
ServerIronADXA(config-vlan-13)#untagged ethernet 1/13
ServerIronADXA(config-vlan-13)#exit
ServerIronADXA(config)#server active-active-port ethernet 1/13 vlan-id 13
The following commands configure the VRRP-E parameters. For each virtual routing interface, the
address indicated by the ip-address command is the address that will be backed up by VRRP-E. The
track-port commands identify the interfaces on the other side of the ServerIron ADX that complete
the link for the VRID. For example, traffic that is addressed to VRID 1 enters the ServerIron ADX
through virtual routing interface 1 and leaves the ServerIron ADX through virtual routing interface
2. Normally, if virtual routing interface 2 goes down, VRID 1 remains active. When you track
interfaces for a VRID, if the state of one of the tracked interfaces changes, the software associates
the change with the VRID interface. For example, if virtual routing interface 2 goes down, the
software associates this state change with VRID 1 and causes VRRP-E to fail over the VRID to the
other ServerIron ADX. For each virtual routing interface, the track-port commands in this example
configure the other virtual routing interface and all the physical ports in the VLAN on which the
other virtual routing interface is configured as track ports.
ServerIronADXA(config)#router vrrp-extended
ServerIronADXA(config)#interface ve 1
ServerIronADXA(config-ve-1)#ip vrrp-extended vrid 1
ServerIronADXA(config-ve-1-vrid-1)#backup
ServerIronADXA(config-ve-1-vrid-1)#ip-address 10.10.20.10
ServerIronADXA(config-ve-1-vrid-1)#enable
ServerIronADXA(config-ve-1-vrid-1)#track-port ethernet 1/5
ServerIronADXA(config-ve-1-vrid-1)#track-port ethernet 1/6
ServerIronADXA(config-ve-1-vrid-1)#track-port ethernet 1/7
ServerIronADXA(config-ve-1-vrid-1)#track-port ethernet 1/8
ServerIronADXA(config-ve-1-vrid-1)#track-port ethernet ve 2
ServerIronADXA(config-ve-1-vrid-1)#exit
ServerIronADXA(config-ve-1)#exit
ServerIronADXA(config)#interface ve 2
ServerIronADXA(config-ve-2)#ip vrrp-extended vrid 2
ServerIronADXA(config-ve-2-vrid-2)#backup
ServerIronADXA(config-ve-2-vrid-2)#ip-address 10.10.10.10
ServerIronADXA(config-ve-2-vrid-2)#enable
ServerIronADXA(config-ve-2-vrid-2)#track-port ethernet 1/1
ServerIronADXA(config-ve-2-vrid-2)#track-port ethernet 1/2
ServerIronADXA(config-ve-2-vrid-2)#track-port ethernet 1/3
ServerIronADXA(config-ve-2-vrid-2)#track-port ethernet 1/4
ServerIronADXA(config-ve-2-vrid-2)#track-port ethernet ve 1
ServerIronADXA(config-ve-2-vrid-2)#exit
ServerIronADXA(config-ve-2)#exit
ServerIron ADX Server Load Balancing Guide
53-1003452-01
431
6
Additional variations
ServerIron ADX-B configuration
The following commands configure ServerIron ADX-B. Notice the NAT and VRRP-E configurations
are the same as the ones on ServerIron ADX-A.
ServerIronADX#configure terminal
ServerIronADX(config)#hostname ServerIronADXB
ServerIronADXB(config)#vlan 100
ServerIronADXB(config-vlan-100)#untagged ethernet 1/1 to 1/4
ServerIronADXB(config-vlan-100)#router-interface ve 1
ServerIronADXB(config-vlan-100)#exit
ServerIronADXB(config)#interface ve 1
ServerIronADXB(config-ve-1)#10.10.20.3 255.255.255.0
ServerIronADXB(config-ve-1)#exit
ServerIronADXB(config)#vlan 200
ServerIronADXB(config-vlan-200)#untagged ethernet 1/5 to 1/8
ServerIronADXB(config-vlan-200)#router-interface ve 2
ServerIronADXB(config-vlan-200)#exit
ServerIronADXB(config)#interface ve 2
ServerIronADXB(config-ve-2)#10.10.10.3 255.255.255.0
ServerIronADXB(config-ve-2)#exit
ServerIronADXB(config)#access-list 1 permit 10.10.10.0 0.0.0.255
ServerIronADXB(config)#ip nat pool actnat 10.10.20.10 10.10.20.20 prefix-len 24
ServerIronADXB(config)#ip nat inside source list 1 pool actnat
ServerIronADXB(config)#interface ve 1
ServerIronADXB(config-ve-1)#ip nat outside
ServerIronADXB(config-ve-1)#exit
ServerIronADXB(config)#interface ve 2
ServerIronADXB(config-ve-2)#ip nat inside
ServerIronADXB(config-ve-2)#exit
ServerIronADXB(config)#vlan 13
ServerIronADXB(config-vlan-13)#untagged ethernet 1/13
ServerIronADXB(config-vlan-13)#exit
ServerIronADXB(config)#server active-active-port ethernet 1/13 vlan-id 13
ServerIronADXB(config)#router vrrp-extended
ServerIronADXB(config)#interface ve 1
ServerIronADXB(config-ve-1)#ip vrrp-extended vrid 1
ServerIronADXB(config-ve-1-vrid-1)#backup
ServerIronADXB(config-ve-1-vrid-1)#ip-address 10.10.20.10
ServerIronADXB(config-ve-1-vrid-1)#enable
ServerIronADXB(config-ve-1-vrid-1)#track-port ethernet 1/5
ServerIronADXB(config-ve-1-vrid-1)#track-port ethernet 1/6
ServerIronADXB(config-ve-1-vrid-1)#track-port ethernet 1/7
ServerIronADXB(config-ve-1-vrid-1)#track-port ethernet 1/8
ServerIronADXB(config-ve-1-vrid-1)#track-port ethernet ve 2
ServerIronADXB(config-ve-1-vrid-1)#exit
ServerIronADXB(config-ve-1)#exit
ServerIronADXB(config)#interface ve 2
ServerIronADXB(config-ve-2)#ip vrrp-extended vrid 2
ServerIronADXB(config-ve-2-vrid-2)#backup
ServerIronADXB(config-ve-2-vrid-2)#ip-address 10.10.10.10
ServerIronADXB(config-ve-2-vrid-2)#enable
ServerIronADXB(config-ve-2-vrid-2)#track-port ethernet 1/1
ServerIronADXB(config-ve-2-vrid-2)#track-port ethernet 1/2
ServerIronADXB(config-ve-2-vrid-2)#track-port ethernet 1/3
ServerIronADXB(config-ve-2-vrid-2)#track-port ethernet 1/4
ServerIronADXB(config-ve-2-vrid-2)#track-port ethernet ve 1
ServerIronADXB(config-ve-2-vrid-2)#exit
432
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Additional variations
6
IP NAT session synchronization in HA configurations
IP NAT sessions created by the active ServerIron ADX in an Symmetric Active-Standby HA
configuration are synchronized to the standby ServerIron ADX. When failover occurs, the standby
ServerIron ADX will be able to use the IP NAT session information created by the active ServerIron
ADX.
IP NAT session synchronization is performed automatically. No configuration is necessary.
Shareable source NAT for high availability
You can configure both peer ServerIron ADXs in a high-availability configuration to share the same
source NAT IP address. In addition, the source NAT sessions are synchronized between the peers.
Shareable source NAT IP addresses were supported only for Hot Standby HA configurations, and
source NAT sessions were not synchronized.
In a high-availability configuration, an address configured as a source IP address serves the
following purposes:
• It provides the real servers with a default gateway address.
• The ServerIron ADX uses the address for source NAT. To keep track of the flows for which
source NAT has been performed, the ServerIron ADX allocates a “port” to each flow. For each
source IP address, up to 54,000 ports can be allocated to flows.
In a Hot Standby HA configuration, the active ServerIron ADX “owned” the source NAT IP address,
responding to ARP requests and performing source NAT with the configured source IP address.
When failover occurred, the standby ServerIron ADX, also configured with the same source NAT IP
address, took over these duties. However, the source NAT sessions were not synchronized between
the peers.
In a Symmetric Active-Standby HA configuration, where both peer ServerIron ADXs are active for the
same application port and VIP at the same time, it was not possible for both peer ServerIron ADXs
to perform source NAT using the same source IP address, because a conflict could occur if both
ServerIron ADXs allocated the same port to different flows.
You can divide the ports used for source NAT for a given source IP address into two equal groups, or
port ranges. One peer controls the “lower” port range, and the other peer controls the “upper” port
range. When performing source NAT, each peer allocates ports belonging only to its port range,
thus avoiding port conflicts.
In Symmetric Active-Standby HA configurations, ownership of the source IP address is based on the
port range. The peer controlling the upper port range for the source IP address is the owner of the
address and responds to ARP requests. If the owner of the source IP address fails, the peer takes
over ownership of the source IP address. When this feature is enabled, the two ServerIron ADXs
report and receive the ownership of the source IP address using a variation of the Symmetric
Active-Standby HA protocol. When the ports used for source NAT for a given source IP address are
divided in this way, it allows the same source IP address to be configured on both peers in all
supported high-availability configurations, including Symmetric Active-Standby HA and Symmetric
Active-Active HA.
In Hot Standby HA configurations, the active ServerIron ADX is the owner of the source IP address.
However, you must still define each ServerIron ADX’s port range in order to prevent port conflicts
between different flows.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
433
6
Additional variations
NOTE
The ServerIron ADX does not support Symmetric Active-Standby HA with shared source NAT IPs. The
reason is because the VIP and the source IP may not be active on the same ServerIron ADX, and as
a result, the ServerIron ADX will not know how to forward return traffic. Configure Symmetric
Active-Active HA as a workaround.
Router configuration example
Figure 51 illustrates a sample Symmetric Active-Active HA configuration that uses shared source IP
addresses.
FIGURE 51
Sample Symmetric Active-Active HA configuration using shared source IP addresses
ServerIron ADX-A configuration
The following commands configure ServerIron ADX-A in Figure 51.
ServerIronADX-A(config)#ip address 10.10.1.1 255.255.0.0
ServerIronADX-A(config)#ip default-gateway 10.10.1.254
ServerIronADX-A(config)#server port 80
ServerIronADX-A(config-port-http)#session-sync
ServerIronADX-A(config-port-http)#tcp
ServerIronADX-A(config-port-http)#exit
ServerIronADX-A(config)#server port 21
ServerIronADX-A(config-port-ftp)#session-sync
ServerIronADX-A(config-port-ftp)#exit
ServerIronADX-A(config)#server port 23
ServerIronADX-A(config-port-telnet)#session-sync
ServerIronADX-A(config-port-telnet)#exit
434
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Additional variations
6
ServerIronADX-A(config)#server source-nat-ip 10.10.1.10 255.255.0.0 0.0.0.0
port-ra 1
ServerIronADX-A(config)#server source-nat-ip 10.10.1.11 255.255.0.0 0.0.0.0
port-ra 1
ServerIronADX-A(config)#server source-nat-ip 10.10.1.12 255.255.0.0 0.0.0.0
port-ra 1
ServerIronADX-A(config)#server router-ports ethernet 3/1
ServerIronADX-A(config)#server real
ServerIronADX-A(config-rs-rs1)#port
ServerIronADX-A(config-rs-rs1)#port
ServerIronADX-A(config-rs-rs1)#port
ServerIronADX-A(config-rs-rs1)#port
ServerIronADX-A(config-rs-rs1)#port
ServerIronADX-A(config-rs-rs1)#exit
rs1 10.10.1.30
http
http url "HEAD /"
ftp
rtsp
telnet
ServerIronADX-A(config)#server real
ServerIronADX-A(config-rs-rs2)#port
ServerIronADX-A(config-rs-rs2)#port
ServerIronADX-A(config-rs-rs2)#port
ServerIronADX-A(config-rs-rs2)#port
ServerIronADX-A(config-rs-rs2)#port
ServerIronADX-A(config-rs-rs2)#exit
rs2 10.10.1.31
http
http url "HEAD /"
ftp
rtsp
telnet
ServerIronADX-A(config)#server real
ServerIronADX-A(config-rs-rs3)#port
ServerIronADX-A(config-rs-rs3)#port
ServerIronADX-A(config-rs-rs3)#port
ServerIronADX-A(config-rs-rs3)#port
ServerIronADX-A(config-rs-rs3)#exit
rs3 10.10.2.30
http
http url "HEAD /"
ftp
telnet
ServerIronADX-A(config)#server real
ServerIronADX-A(config-rs-rs4)#port
ServerIronADX-A(config-rs-rs4)#port
ServerIronADX-A(config-rs-rs4)#port
ServerIronADX-A(config-rs-rs4)#port
ServerIronADX-A(config-rs-rs4)#exit
rs4 10.10.2.31
http
http url "HEAD /"
ftp
telnet
ServerIronADX-A(config)#server virtual-name-or-ip test 10.10.1.100
ServerIronADX-A(config-vs-test)#sym-priority 200
ServerIronADX-A(config-vs-test)#sym-active
ServerIronADX-A(config-vs-test)#port http
ServerIronADX-A(config-vs-test)#port ftp
ServerIronADX-A(config-vs-test)#port telnet
ServerIronADX-A(config-vs-test)#bind http rs1 http rs2 http rs3 http rs4 http
ServerIronADX-A(config-vs-test)#bind ftp rs1 ftp rs2 ftp rs3 ftp rs4 ftp
ServerIronADX-A(config-vs-test)#bind telnet rs1 telnet rs2 telnet rs3 telnet rs4
telnet
ServerIronADX-A(config-vs-test)#exit
ServerIron ADX Server Load Balancing Guide
53-1003452-01
435
6
Additional variations
ServerIron ADX-B configuration
The following commands configure ServerIron ADX-B in Figure 51. The commands are identical to
those for ServerIron ADX-A except for the ServerIron ADX’s IP address.
ServerIronADX-B(config)#ip address 10.10.1.2 255.255.0.0
ServerIronADX-B(config)#ip default-gateway 10.10.1.254
ServerIronADX-B(config)#server port 80
ServerIronADX-B(config-port-http)#session-sync
ServerIronADX-B(config-port-http)#tcp
ServerIronADX-B(config-port-http)#exit
ServerIronADX-B(config)#server port 21
ServerIronADX-B(config-port-ftp)#session-sync
ServerIronADX-B(config-port-ftp)#exit
ServerIronADX-B(config)#server port 23
ServerIronADX-B(config-port-telnet)#session-sync
ServerIronADX-B(config-port-telnet)#exit
ServerIronADX-B(config)#server
port-ra 2
ServerIronADX-B(config)#server
port-ra 2
ServerIronADX-B(config)#server
port-ra 2
ServerIronADX-B(config)#server
source-nat-ip 10.10.1.10 255.255.0.0 0.0.0.0
source-nat-ip 10.10.1.11 255.255.0.0 0.0.0.0
source-nat-ip 10.10.1.12 255.255.0.0 0.0.0.0
router-ports ethernet 3/1
ServerIronADX-B(config)#server real
ServerIronADX-B(config-rs-rs1)#port
ServerIronADX-B(config-rs-rs1)#port
ServerIronADX-B(config-rs-rs1)#port
ServerIronADX-B(config-rs-rs1)#port
ServerIronADX-B(config-rs-rs1)#port
ServerIronADX-B(config-rs-rs1)#exit
rs1 10.10.1.30
http
http url "HEAD /"
ftp
rtsp
telnet
ServerIronADX-B(config)#server real
ServerIronADX-B(config-rs-rs2)#port
ServerIronADX-B(config-rs-rs2)#port
ServerIronADX-B(config-rs-rs2)#port
ServerIronADX-B(config-rs-rs2)#port
ServerIronADX-B(config-rs-rs2)#port
ServerIronADX-B(config-rs-rs2)#exit
rs2 10.10.1.31
http
http url "HEAD /"
ftp
rtsp
telnet
ServerIronADX-B(config)#server real
ServerIronADX-B(config-rs-rs3)#port
ServerIronADX-B(config-rs-rs3)#port
ServerIronADX-B(config-rs-rs3)#port
ServerIronADX-B(config-rs-rs3)#port
ServerIronADX-B(config-rs-rs3)#exit
rs3 10.10.2.30
http
http url "HEAD /"
ftp
telnet
ServerIronADX-B(config)#server real
ServerIronADX-B(config-rs-rs4)#port
ServerIronADX-B(config-rs-rs4)#port
ServerIronADX-B(config-rs-rs4)#port
ServerIronADX-B(config-rs-rs4)#port
ServerIronADX-B(config-rs-rs4)#exit
rs4 10.10.2.31
http
http url "HEAD /"
ftp
telnet
ServerIronADX-B(config)#server virtual-name-or-ip test 10.10.1.100
436
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Additional variations
6
ServerIronADX-B(config-vs-test)#sym-priority 100
ServerIronADX-B(config-vs-test)#sym-active
ServerIronADX-B(config-vs-test)#port http
ServerIronADX-B(config-vs-test)#port ftp
ServerIronADX-B(config-vs-test)#port telnet
ServerIronADX-B(config-vs-test)#bind http rs1 http rs2 http rs3 http rs4 http
ServerIronADX-B(config-vs-test)#bind ftp rs1 ftp rs2 ftp rs3 ftp rs4 ftp
ServerIronADX-B(config-vs-test)#bind telnet rs1 telnet rs2 telnet rs3 telnet rs4
telnet
ServerIronADX-B(config-vs-test)#exit
Enabling VRRP and binding a VIP group to a virtual router ID
To enable VRRP and bind a VIP group to a Virtual Router ID (VRID), enter commands such as the
following.
ServerIronADX(config)#router vrrp
ServerIronADX(config)#interface e 1/2
ServerIronADX(config-if-e100-1/2)#ip vrrp vrid 1
ServerIronADX(config-if-e100-12-vrid-1)#vip-group 1
Syntax: [no] router vrrp | vrrp-extended
Syntax: [no] ip vrrp vrid vrid number
Syntax: [no] vip-group number
The number variable is the VIP group number (from 1 through 10) that you are binding to the VRID.
Note that each VIP group can have only one VRID associated with it.
Each virtual IP address can belong to only one VIP group. Also, each VIP group can have only one
VRID associated with it.
Use these commands with the server vip-group command to guarantee simultaneous VIP failover in
the event VRRP-E fails over to a Backup router.
IP NAT session synchronization in high-availability configurations
IP NAT sessions created by the active ServerIron ADX in an Symmetric Active-Standby HA
configuration are synchronized to the standby ServerIron ADX. When failover occurs, the standby
ServerIron ADX will be able to use the IP NAT session information created by the active ServerIron
ADX.
IP NAT session synchronization is performed automatically. No configuration is necessary.
Shareable source NAT for high availability
You can configure both peer ServerIron ADXs in a high-availability configuration to share the same
source NAT IP address. In addition, the source NAT sessions are synchronized between the peers.
Shareable source NAT IP addresses were supported only for Hot Standby HA configurations, and
source NAT sessions were not synchronized.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
437
6
Additional variations
In a high-availability configuration, an address configured as a source IP address serves the
following purposes:
• It provides the real servers with a default gateway address.
• The ServerIron ADX uses the address for source NAT. To keep track of the flows for which
source NAT has been performed, the ServerIron ADX allocates a “port” to each flow. For each
source IP address, up to 54,000 ports can be allocated to flows.
In a Hot Standby HA configuration, the active ServerIron ADX “owned” the source NAT IP address,
responding to ARP requests and performing source NAT with the configured source IP address.
When failover occurred, the standby ServerIron ADX, also configured with the same source NAT IP
address, took over these duties. However, the source NAT sessions were not synchronized between
the peers.
In a Symmetric Active-Active HA configuration, where both peer ServerIron ADXs are active for the
same application port and VIP at the same time, it was not possible for both peer ServerIron ADXs
to perform source NAT using the same source IP address, because a conflict could occur if both
ServerIron ADXs allocated the same port to different flows.
You can divide the ports used for source NAT for a given source IP address into two equal groups, or
port ranges. One peer controls the “lower” port range, and the other peer controls the “upper” port
range. When performing source NAT, each peer allocates ports belonging only to its port range,
thus avoiding port conflicts.
In Symmetric Active-Standby HA configurations, ownership of the source IP address is based on the
port range. The peer controlling the upper port range for the source IP address is the owner of the
address and responds to ARP requests. If the owner of the source IP address fails, the peer takes
over ownership of the source IP address. When this feature is enabled, the two ServerIron ADXs
report and receive the ownership of the source IP address using a variation of the Symmetric
Active-Standby HA protocol. When the ports used for source NAT for a given source IP address are
divided in this way, it allows the same source IP address to be configured on both peers in all
supported high-availability configurations, including Symmetric Active-Standby HA and Symmetric
Active-Active HA.
In Hot Standby HA configurations, the active ServerIron ADX is the owner of the source IP address.
However, you must still define each ServerIron ADX’s port range in order to prevent port conflicts
between different flows.
NOTE
The ServerIron ADX does not support Symmetric Active-Standby HA with shared source NAT IPs. The
reason is because the VIP and the source IP may not be active on the same ServerIron ADX, and as
a result, the ServerIron ADX will not know how to forward return traffic. Configure Symmetric
Active-Active HA as a workaround.
Configuring server accelerated-fin-sync command
In an HA setup, the ServerIron ADX that created a new connection will synchronize the connection
information to the partner ServerIron ADX. For a TCP connection, the synchronization message to
create a session is sent when the client SYN is received (and a server is selected). During the
connection, the messages are sent periodically across both the partnered ServerIron ADX. Both
ServerIron ADX will age the session independently. When both FINs are received, the session is
placed in delete-queue to be purged after 8 seconds (or the configured server msl command). By
default, there is no sync message here. Once the session is purged from delete-queue, a sync
438
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Miscellaneous options
6
message is sent to remove the session from the other ServerIron ADX. This default behavior of the
ServerIron ADX might result in displaying different server usage statistics on both ServerIron ADXs,
or may result in the rejection of new connections on the new Active ServerIron ADX after a failover
for a brief amount of time if clients reuse TCP source ports.
With the server accelerated-fin-sync command, if configured, results in a sync message for the
second FIN so that the partner ServerIron ADX can put the session in delete-queue right away to be
purged after 8 seconds (or the configured server msl command).
Configuring synchronization with HA
The config-sync command is explained in the "Initiating the Synchronization" section of the
"ServerIron System Management" chapter in the ServerIron ADX Administration Guide.
Miscellaneous options
Displaying VIP owner in HA setup
The show server bind command display the "owner" for active VIP in HA configuration.
NOTE
This command shows the Owner for sym_state=5, non-Owner for sym_state=3, or nothing for others.
ServerIronADX#show server bind
Syntax: show server bind
Identifying the ports attached to a router
If the ServerIron ADX is attached to multiple routers or to a single router configured for VRRP, FSRP,
or HSRP, you need to identify the ports on the ServerIron ADX that are attached to the router.
Explicitly identifying the ports enables the ServerIron ADX or switch to handle Layer 4 traffic
correctly.
To identify port 8 as a router port, enter the following command.
ServerIronADX(config)#server router-port 8
Syntax: [no] server router-port portnum
To define multiple router ports on a switch, enter the port numbers, separated by blanks. You can
enter up to eight router ports in a single command line. To enter more than 8 ports, enter the server
router-port command again with the additional ports.
Setting VIP failback delay
When a primary ServerIron ADX reloads and it boots up, even when all services are up and the
health checks are fine, you may need an additional delay for the VIP to take traffic. Setting a VIP
failback delay ensures that the standby ServerIron ADX continues taking traffic until the primary
ServerIron ADX is ready to take over.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
439
6
Miscellaneous options
To set the VIP failback delay, enter the following command in global configuration mode.
ServerIronADX(config)#server vip-failback-delay 10
Syntax: [no] server vip-failback-delay value
The value variable is the delay in seconds. Enter an integer from 1 to 255.
NOTE
The server vip-failback-delay command is only applied in router code.
440
ServerIron ADX Server Load Balancing Guide
53-1003452-01
Chapter
IPv6 Support for Server Load Balancing
7
Overview
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 either IPv6 or IPv4 addresses. Other
than IPv6 addressing, no new commands are necessary for configuring SLB for IPv6 on the
ServerIron.
The following sections shows the configuration steps for an IPv6 SLB configuration.
1. Defining IPv6 real servers.
2. Defining IPv6 virtual servers.
3. Defining IPv4 real servers.
4. Defining IPv4 virtual servers.
5. Define port characteristics using port profile.
6. Define IP routes.
7.
VLAN, tagging and trunk definitions.
8. VRRP-E and VIP group definitions.
9. Miscellaneous.
10. Saving the configuration.
Defining IPv6 real servers
ServerIronADX(config)#server real
ServerIronADX(config-rs-rs3)#port
ServerIronADX(config-rs-rs3)#port
ServerIronADX(config-rs-rs3)#port
ServerIronADX(config-rs-rs3)#port
ServerIronADX(config-rs-rs3)#exit
rs3 2001:db8::a
http
http
http url "HEAD /"
dns
ServerIronADX(config)#server real
ServerIronADX(config-rs-rs4)#port
ServerIronADX(config-rs-rs4)#port
ServerIronADX(config-rs-rs4)#port
ServerIronADX(config-rs-rs4)#port
ServerIronADX(config-rs-rs4)#exit
rs4 2001:db8::5
http
http
http url "HEAD /"
dns
ServerIron ADX Server Load Balancing Guide
53-1003452-01
441
7
Defining IPv6 virtual servers
Defining IPv6 virtual servers
ServerIronADX(config)#server virtual vs2 2001:db8::face
ServerIronADX(config-rs-v45)#port http
ServerIronADX(config-rs-v45)#port dns
ServerIronADX(config-rs-v45)#bind http rs3 http rs4 http
ServerIronADX(config-rs-v45)#bind http rs7 http
ServerIronADX(config-rs-v45)#bind dns rs5 dns rs6 dns rs7 dns rs3 dns
ServerIronADX(config-rs-v45)#bind dns rs4 dns
ServerIronADX(config-rs-v45)#exit
Defining IPv4 real servers
ServerIronADX(config)#server real
ServerIronADX(config-rs-v41)#port
ServerIronADX(config-rs-v41)#port
ServerIronADX(config-rs-v41)#exit
ServerIronADX(config)#server real
ServerIronADX(config-rs-v42)#port
ServerIronADX(config-rs-v42)#port
ServerIronADX(config-rs-v42)#exit
v41 10.31.31.10
http
http url "HEAD /"
v42 10.31.31.11
http
http url "HEAD /"
Defining IPv4 virtual servers
ServerIronADX(config)#server virtual-name-or-ip v4-v 10.31.31.250
ServerIronADX(config-vs-v4-v)#sym-priority 200
ServerIronADX(config-vs-v4-v)#sym-active
ServerIronADX(config-vs-v4-v)#port http
ServerIronADX(config-vs-v4-v)#bind http v41 http v42 http v43 http v45 http
ServerIronADX(config-vs-v4-v)#exit
Defining port characteristics using port profile
ServerIronADX(config)#server port 80
ServerIronADX(config-port-http)#session-sync
ServerIronADX(config-port-http)#tcp
ServerIronADX(config)#exit
ServerIronADX(config)server port 53
ServerIronADX(config-port-dns)#session-sync
ServerIronADX(config-port-dns)#tcp keepalive disable
ServerIronADX(config-port-dns)#udp
ServerIronADX(config)#exit
Defining IP routes
ServerIronADX(config)#ip route 0.0.0.0 0.0.0.0 10.40.40.5
ServerIronADX(config)#ipv6 route 2001:db8::/64 2001:db8::212:f2ff:fea8:1400
ServerIronADX(config)#exit
442
ServerIron ADX Server Load Balancing Guide
53-1003452-01
VLAN, tagging and trunk definitions
7
VLAN, tagging and trunk definitions
ServerIronADX(config)#vlan 1 name DEFAULT-VLAN by port
ServerIronADX(config-vlan-1)#exit
ServerIronADX(config)#vlan 110 by port
ServerIronADX(config-vlan-10)#tagged ethe 3/3 to 3/4
ServerIronADX(config-vlan-10)#untagged ethe 3/7
ServerIronADX(config-vlan-10)#router-interface ve 10
ServerIronADX(config-vlan-10)#spanning-tree
ServerIronADX(config-vlan-10)#exit
ServerIronADX(config)#trunk switch ethe 3/3 to 3/4
ServerIronADX(config)#exit
VRRP-E and VIP group definitions
ServerIronADX(config)#interface ethernet 3/1
ServerIronADX(config-if-3/1)#ip address 10.40.40.1 255.255.255.0
ServerIronADX(config-if-3/1)#ipv6 address 2001:db8::/64 eui-64
ServerIronADX(config)#interface ve 10
ServerIronADX(config-ve-10)#ip address 10.31.31.1 255.255.255.0
ServerIronADX(config-ve-10)#ipv6 address 2001:db8::/64 eui-64
ServerIronADX(config)#router vrrp-extended
ServerIronADX(config)#router vrrp-extended-ipv6
ServerIronADX(config)#server vip-group 1
ServerIronADX(config-vip-group-[1])#vip 2001:db8::face
ServerIronADX(config-vip-group-[1])#vip 10.31.31.250
ServerIronADX(config-vip-group-[1])#exit
ServerIronADX(config-ve-10)#ipv6 vrrp-extended vrid 1
ServerIronADX(config-ve-10-vrid-1)#backup
ServerIronADX(config-ve-10-vrid-1)#ip address 2001:db8:fe80::35
ServerIronADX(config-ve-10-vrid-1)#track-port e 3/1 priority 15
ServerIronADX(config-ve-10-vrid-1)#enable
ServerIronADX(config-ve-10-vrid-1)#exit
ServerIronADX(config-ve-10)#exit
ServerIronADX(config-if-3/1)#ipv6 vrrp-extended vrid 4
ServerIronADX(config-if-3/1-vrid-5)#backup
ServerIronADX(config-if-3/1-vrid-5)#ip address 2001:db8:fe80::36
ServerIronADX(config-if-3/1-vrid-5)#vip-group 1
ServerIronADX(config-if-3/1-vrid-5)#enable
ServerIronADX(config-if-3/1-vrid-5)#exit
ServerIronADX(config-if-3/1)#exit
ServerIronADX(config-ve-10)#ip vrrp-extended vrid 3
ServerIronADX(config-ve-10-vrid-3)#backup
ServerIronADX(config-ve-10-vrid-3)#ip-address 10.31.31.3
ServerIronADX(config-ve-10-vrid-3)#track-port e 3/1 priority 15
ServerIronADX(config-ve-10-vrid-3)#enable
ServerIronADX(config-ve-10-vrid-3)#exit
ServerIron ADX Server Load Balancing Guide
53-1003452-01
443
7
Miscellaneous
ServerIronADX(config-if-3/1)#ip vrrp-extended vrid 5
ServerIronADX(config-if-3/1-vrid-5)#backup
ServerIronADX(config-if-3/1-vrid-5)#ip-address 10.40.40.3
ServerIronADX(config-if-3/1-vrid-5)#enable
ServerIronADX(config-if-3/1-vrid-5)#exit
Miscellaneous
ServerIronADX(config)#aaa authentication web-server default local
ServerIronADX(config)#no enable aaa console
ServerIronADX(config)#exit
ServerIronADX(config)#telnet server
ServerIronADX(config)#username admin password .....
ServerIronADX(config)#snmp-server
Saving the configuration
ServerIronADX(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 to IPv4 gateway
The ServerIron ADX allows an IPv6 client to send and receive packets to and from any of the
following real servers:
• An IPv6 real server
• An IPv4 real server
• A combination of IPv4 and IPv6 real servers
444
ServerIron ADX Server Load Balancing Guide
53-1003452-01
IPv6 to IPv4 gateway
7
These configurations are shown in Figure 52.
FIGURE 52
IPv6 Client access
Access from the IPv6 client to an IPv6 real server is straight forward and doesn’t require any
special processing from the ServerIron ADX. For an IPv6 client to access an IPv4 server however
requires intervention from the ServerIron ADX as shown in Figure 53.
FIGURE 53
IPv6 client to IPv4 server access
As shown in this example, the IPv6 client sends its request to the ServerIron ADX with it’s own IPv6
address as the source address. The destination address is an IPv6 address assigned in the VIP
configuration of the ServerIron ADX. Layer 4 - 7 processing is then applied to the packets. After
processing, IP source NAT is used to exchange the source and destination IPv6 addresses for IPv4
addresses configured for the ServerIron ADX. The packets are then forwarded to the IPv4 server.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
445
7
IPv6 to IPv4 gateway
The packet flow of how the IPv4 server replies to the IPv6 is shown in Figure 54. In this example,
the IPv4 server sends its IPv4 address as the source address and the destination address is the
IPv4 address specified in the IP NAT configuration for the VIP. IP source NAT is used to exchange the
source and destination IPv4 addresses for the IPv6 source address configured for the VIP and the
destination address of the IPv6 client.
FIGURE 54
IPv4 server to IPv6 packet flow reply
Features not supported with the IPv6 to IPv4 gateway
•
•
•
•
•
•
•
•
•
•
NAT
TRL
VIP Protection
Client-subnet-sticky
Client-subnet base source-nat
Real server hardware DSR
Rule-based ACLv6 (only flow-based ACLs are supported)
Source-nat ACLs
Full-stack applications (SSL termination, etc.)
FTP and other complex protocols
Packet fragmentation with the IPv6 to IPv4 gateway
Reverse packets from the IPv4 server to the IPv6 client can be too large and need to be split into
two IPv6 packets. The following describes the criteria for judging that packets are too large:
Regular packets – IP total length greater than 1480 bytes
Fragmented packets – IP total length greater than 1480 + 8 bytes
If the packets exceed these limitations, one of the following actions will be taken:
1. If the frag-664-reverse-full-sized-pkt command is configured, the packet will be split and
no further actions will be performed.
2. If the condition in step 1 isn’t met, and the DF bit is set at the server, the “fragment
needed” ICMP error message will be sent.
3. If the conditions in steps 1 and 2 aren’t met, the packet will be split.
The frag-664-reverse-full-sized-pkt command is configured as shown in the following.
ServerIronADX(config)#frag-664-reverse-full-sized-pkt
446
ServerIron ADX Server Load Balancing Guide
53-1003452-01
IPv6 to IPv4 gateway
7
Syntax: [no] frag-664-reverse-full-sized-pkt
ICMP packet processing for the IPv6 to IPv4 gateway
Because the client is running IPv6 and the real server is running IPv4, ICMPv6 and ICMP error
messages must be processed as described in the following:
• ICMPv6 error messages from the client side are translated to ICMP messages and sent to the
server
• ICMP error messages from the server are translated to ICMPv6 messages and sent to the
client
• ICMP and ICMPv6 echo request messages are processed by the management module (MP)
Client side ICMP packet translation
ICMPv6 error messages are translated to equivalent ICMP error messages as shown in Table 42.
TABLE 42
ICMPv6 to ICMP error message translation
ICMPv6 error message type
ICMP error message type
Destination Unreachable (Type 1)
Destination Unreachable (Type 3)
* no route (code 0)
* host Unreachable (code 1)
* admin prohibited (code 1)
* admin prohibited (code 10)
* not neighbor (code 2)
* route fail (code 5)
* address unreachable (code 3)
* host unreachable (code 1)
* port unreachable (code 4)
* port unreachable (code 3)
Packet Too Big (Type 2)
Destination Unreachable (Type 3)
* fragment needed (code 4)
Time Exceeded (Type 3)
Time exceeded (Type 11)
* code remains the same from ICMPv6
Parameter Problem (Type 4)
* next header
Type – Dest Unreachable
code – protocol unreachable
* any other param problem
Type – param prob
code – 0
ServerIron ADX Server Load Balancing Guide
53-1003452-01
447
7
IPv6 to IPv4 gateway
Server side ICMP packet translation
ICMPv6 error messages are translated to equivalent ICMP error messages as shown in Table 43.
TABLE 43
ICMPv6 to ICMP error message translation
ICMP error message type
ICMPv6 error message type
Destination Unreachable (Type 3)
Destination Unreachable (Type 3)
* net unreachable (code 0)
* no route code (code 0)
* host unreachable (code 1)
* no route code (code 0)
* protocol unreachable (code 2)
* type – param prob, code – 0
* port unreachable (code 3)
* no port (code 4)
* fragment needed (code 4)
* type – packet too big, code – no route
* route fail (code 0)
* not neighbor code (code 1)
* unknown dest network (code 1)
* no route code (code 0)
* unknown dest host (code 2)
* no route code (code 0)
* source host isolated (code 3)
* no route code (code 0)
* dest network admin prohibited (code
4)
* admin prohibited (code 1)
* dest host admin prohibited (code 0
* admin prohibited (code 1)
* network unreachable for tos (code 1)
* no route code (code 0)
* host unreachable for tos (code 2)
* no route code (code 0)
* admin prohibit (code 3)
* admin prohibited (code 1)
* host precedence violated (code 4)
* admin prohibited (code 1)
* precedence cutoff in effect (code 4)
* admin prohibited (code 1)
Time Exceeded (Type 3)
Time exceeded (Type 11)
* code remains the same from ICMPv6
Parameter Problem (Type 4)
* next header
* any other param problem
Type – Dest Unreachable
code – protocol unreachable
Type – param prob
code – 0
IPv6 to IPv4 gateway high availability support
Hot standby, Symmetric Active-Standby, and Symmetric Active-Active HA configurations are
supported for the IPv6 to IPv4 gateway with the following considerations:
• The format for all HA messages that do not contain IP address remain the same for IPv4 and
IPv6 (for example, hot-standby heart beat).
• Session synchronization messages (which contain IP addresses) send IPv6 addresses for the
forward sessions and IPv4 addresses for the reverse sessions for IPv6 traffic.
448
ServerIron ADX Server Load Balancing Guide
53-1003452-01
IPv6 to IPv4 gateway
7
Configuring the IPv6 to IPv4 gateway
Although the IPv6 to IPv4 gateway doesn’t require any special commands, you must perform the
following configurations:
•
•
•
•
Enable Source NAT (either globally or on the IPv4 real servers)
Configure IPv4 Source NAT IP address
Configure an IPv4 real server
Configure an IPv6 VIP
Sample configuration
The following example provides a sample configuration for the ServerIron ADX in Figure 53 and
Figure 54.
The following commands enable Source NAT globally and configure an IPv4 Source NAT IP address.
ServerIronADX(config)#server source-nat
ServerIronADX(config)#server source-nat-ip 10.130.130.5 255.255.255.0 0.0.0.0
port-range 2
The following commands configure an IPv4 real server.
ServerIronADX(config)#server real rs1 10.130.130.1
ServerIronADX(config-rs-rs1)#port http
ServerIronADX(config-rs-rs1)#exit
The following commands configure an IPv6 VIP.
ServerIronADX(config)#server virtual-name-or-ip vip664 2001:db8:30::1
ServerIronADX(config-vs-vip664)#port http
ServerIronADX(config-vs-vip664)#bind http rs1 http
ServerIronADX(config-vs-vip664)#exit
ServerIron ADX Server Load Balancing Guide
53-1003452-01
449
7
IPv6 to IPv4 gateway
Displaying IPv6 to IPv4 gateway information
You can use the show session all and show ipv6 map-statistics commands to display information
about an IPv6 to IPv4 gateway.
The show session all command displays sessions created for the IPv6 to IPv4 gateway traffic. The
forward sessions has IPv6 addresses and the reverse sessions have IPv4 addresses.
In this example the IPv6 to IPv4 gateway configuration has the following IPv4 and IPv6 addresses:
•
•
•
•
IPv6 Client IP address: 2001:db8::1
IPv6 VIP: 2001:db8::4
IPv4 Server IP: 10:30:30:1
IPv4 Source NAT IP: 10.30.30.5
ServerIronADX#rconsole 1 1
ServerIronADX1/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
Dst-IP
S-port D-port
Age
Server
Flags
==========================================================================
0
2001:db8::1 2001:db8::4 53421
80
34
rs1-ipv4
SLB1 H
1
10.30.30.1
10.30.30.5 80
17430
34
rs1-ipv4
SLB1 H
The show ipv6 map-statistics command displays the number of client and real server packets. The
following example displays memory mapping statistics for an IPv6 to IPv4 gateway (IPv6-6-4)
forward (Client packets) and reverse (real server packets).
ServerIronADX#rconsole 1 1
ServerIronADX1/1 #show ipv6 map-statistics
************************
V6-V4 Gateway STATISTICS
*************************
Memory Allocation Statistics:
----------------------------Tables memory(bytes) = 16799984
Static map memory (bytes) = 448
IPv6-6-4:
664 fwd = 25
664 rev = 55
450
ServerIron ADX Server Load Balancing Guide
53-1003452-01
IPv4 to IPv6 gateway
7
IPv4 to IPv6 gateway
The ServerIron ADX allows an IPv4 client to send and receive packets to and from any of the
following real servers:
• An IPv6 real server
• An IPv4 real server
• a combination of IPv4 and IPv6 real servers
No special processing by the ServerIronADX is required for an IPv4 client to access an IPv4 real
server.
Accessing an IPv6 real server from an IPv4 client, however, requires ServerIronADX to convert an
IPv4 client address to an IPv6 client address using a user-defined unicast prefix. The
ServerIronADX prepends this prefix to IPv4 source IP addresses in translated packets for IPv4 to
IPv6 traffic and strips it away for IPv6 to IPv4 traffic.
Figure 55 shows how the ServerIron ADX constructs an IPv6 address using a user-defined
IPv4-to-IPv6 prefix and the client IPv4 address.
FIGURE 55
IPv6 address using user-defined IPv4-to-IPv6 prefix and client IPv4 address
The ServerIron ADX uses the upper 64 bits of a package for the IPv4 to IPv6 prefix, the middle 32
bits for CAM (Content Addressable Memory) programming (to ensure that the package is correctly
addressed), and the lower 32 bits for the client IPv4 address.
Figure 56 shows how the IPv4 client sends its request to the ServerIron ADX with its own IPv4
address as the source IP address. ServerIron ADX prepends a user-defined IPv6 prefix to the IPv4
client address to convert the IPv4 client address into an IPv6 address. The packets are then
forwarded to the IPv6 server.
FIGURE 56
IPv4 client request converted to an IPv6 address
ServerIron ADX Server Load Balancing Guide
53-1003452-01
451
7
IPv4 to IPv6 gateway
Figure 57 shows how the IPv6 server replies to the IPv4 client. In this example, the ServerIron ADX
strips the IPv6 prefix from the IPv4 address.
FIGURE 57
IPv6 server reply converted to an IPv4 address
NOTE
Source NAT is not supported for the IPv4 or IPv6 gateway. Source NAT configured globally or on a real
server do not take effect for a IPv4 VIP. If Source NAT is enabled for an IPv6 real server bound to an
IPv4 VIP, a notification message will appear informing the user that source NAT will not take effect
for the real server for the IPv4 VIP.
Configuring the IPv6 prefix
An IPv6 unicast prefix must be configured on the ServerIron ADX to convert IPv4 client addresses to
IPv6 client addresses. This prefix is prepended to IPv4 source addresses in translated packets for
IPv4 to IPv6 traffic and stripped away for IPv6 to IPv4 traffic. Furthermore, the prefix must be
routed towards the ServerIron ADX on the IPv6 network.
NOTE
The IPv6 prefix must be in a dangling subnet.
The server ipv6 prefix is used to configure the IPv6 prefix that the ServerIron APX uses to convert
IPv4 client addresses into IPv6 client addresses when sending packets from an IPv4 client to an
IPv6 real server.
ServerIronADX(config)#server ipv6 prefix 2001:db8::/64 slb-446
Syntax: [no] server ipv6 prefix prefix length feature-list [inject-static-route]
The prefix variable defines the IPv6 gateway prefix; it must be configured in a dangling subnet.
The length variable defines the maximum length of the prefix. ServerIron ADX supports a prefix
length of up to 64 bits.
The feature-list variable identifies a prefix that can be used to translate IPv4 addresses to IPv6
addresses by various ServerIron APX features. In the current implementation, only the “slb-446”
parameter is supported.
452
ServerIron ADX Server Load Balancing Guide
53-1003452-01
IPv4 to IPv6 gateway
7
The [inject-static-route] parameter can be used to inject a route using a protocol. This option can be
used on the router platform.
The ipv6 prefix command is used to add a prefix to a vip-group. The prefix can be added to one
vip-group at a time and is only applicable to the router platform.
ServerIronADX(config)#server vip-group 1
ServerIronADX(config-vip-group-[1])#ipv6 prefix 2001:DB8::1/64
Syntax: [no] ipv6 prefix prefix/length
NOTE
In an SLB-446 setup, if another IPv6 VIP is defined such that the last 64 bits are the same as the
IPv6 prefix, traffic will fail for that VIP. You need to configure the IPv6 prefix such that this is not the
case.
Features not supported with the IPv4 to IPv6 gateway
•
•
•
•
•
•
•
•
•
•
•
•
NAT
TRL
VIP Protection
Client-subnet-sticky
Client-subnet base source-nat
Real server hardware DSR
Rule-based ACLv6 (only flow-based ACLs are supported)
Source-nat ACLs
Full-stack applications (SSL termination, etc.)
FTP and other complex protocols
One arm HA switch with Symmetric Active-Standby HA /Symmetric -Active-Active HA
One arm standalone switch code
Packet fragmentation with the IPv4 to IPv6 gateway
Packets sent from the IPv4 client to the IPv6 server can be too large and might need to be split into
two IPv6 packets.
The ServerIron ADX uses the following criteria to assess whether packets are too large and need to
be split:
Regular packets – IP total length greater than (IPv6 MTU -20) bytes
Fragmented packets – IP total length greater than (IPv6 MTU -20 +8) bytes for fragment
header
If the packets exceed these limitations, the ServerIron ADX takes one of the following actions:
1. If the ipv6 frag-full-4to6 command is configured, the packet will be split and no further
actions will be performed.
2. If the condition in step 1 isn’t met and the DF bit is set by the client, the “fragment
needed” ICMP error message will be sent.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
453
7
IPv4 to IPv6 gateway
3. If the conditions in steps 1 and 2 aren’t met, the packet will be split.
The ipv6 frag-full-4to6 command is configured as shown in the following.
ServerIronADX(config)#ipv6 frag-full-4to6
Syntax: [no] ipv6 frag-full-4to6
ICMP packet processing for the IPv4 to IPv6 gateway
Because the client is running IPv4 and the real server is running IPv6, ICMP and ICMPv6 error
messages must be processed as described in the following:
• ICMP error messages from the IPv4 client side are translated to ICMPv6 messages and sent to
the IPv6 server
• ICMPv6 error messages from the IPv6 server are translated to ICMP messages and sent to the
IPv4 client
• ICMP and ICMPv6 echo request messages are processed by the management module (MP)
Client side ICMP packet translation
ICMP error messages are translated to equivalent ICMPv6 error messages as shown in Table 44
TABLE 44
ICMP to ICMPv6 error message translation
ICMP error message type
ICMPv6 error message type
Destination Unreachable (Type 3)
Destination Unreachable (Type 1)
* net unreachable (code 0)
* no route (code 0)
* host unreachable (code 1)
* no route (code 0)
* protocol unreachable (code 2)
* type - param prob, code - next header
* port unreachable (code 3)
* no port (code 4)
* fragment needed (code 4)
* type - packet too big, code - no route
* route fail (code 0)
* not neighbor code (code 1)
* unknown dest network (code 1)
* no route code (code 0)
* unknown dest host (code 2)
* no route code (code 0)
* source host isolated (code 3)
* no route code (code 0)
* dest network admin prohibited (code 4)
* address prohibited (code 1)
* dest host admin prohibited (code 0)
* address prohibited (code 1)
* network unreachable for tos (code 1)
* no route code (code 0)
* host unreachable for tos (code 2)
* no route code (code 0)
* admin prohibit (code 3)
* admin prohibited (code 1)
* host precedence violated (code 4)
* admin prohibited (code 1)
* precedence cutoff in effect (code )
* admin prohibited (code 1)
Destination Unreachable (Type 3)
* fragment needed (code 4)
454
Packet Too Big (Type 2)
ServerIron ADX Server Load Balancing Guide
53-1003452-01
IPv4 to IPv6 gateway
TABLE 44
7
ICMP to ICMPv6 error message translation (Continued)
ICMP error message type
ICMPv6 error message type
Time Exceeded (Type 3)
Time Exceeded (Type 11)
* code remains the same from ICMPv6
Parameter Problem (Type 4)
* next header
* Type - Dest Unreachable, code protocol unreachable
* Type - param prob, code - 0
* any other param problem
Echo Request (Type 8)
Echo Request (Type 128)
Echo Request (Type 0)
Echo Request (Type 129)
Server side ICMP packet translation
ICMPv6 error messages are translated to equivalent ICMP error messages as shown in Table 45.
TABLE 45
ICMPv6 to ICMP error message translation
ICMPv6 error message type
ICMP error message type
Destination Unreachable (Type 1)
Destination Unreachable (Type 3)
* no route code (code 0)
* host unreachable (code 1)
* admin prohibited (code 1)
* admin prohibited (code 10)
* not neighbor (code 2)
* route fail (code 5)
* address unreachable (code 3)
* host unreachable (code 1)
* port unreachable (code 4)
* port unreachable (code 3)
Packet Too Big (Type 2)
Destination Unreachable (Type 3)
* frament needed (code 4)
Time Exceeded (Type 3)
Time Exceeded (Type 11)
* code remains the same from ICMPv6
Parameter Problem (Type 4)
* next header
* any other param problem
* Type - Dest Unreachable, code protocol unreachable
* Type - param prob, code - 0
Echo Request (Type 128)
Echo Request (Type 8)
Echo Request (Type 129)
Echo Request (Type 0)
IPv4 to IPv6 gateway high availability support
Hot standby, Symmetric Active-Standy, and Symmetric Active-Active high availability (HA)
configurations are supported for the IPv4 to IPv6 gateway with the following considerations:
• The format for all high availability messages that do not contain IP address remain the same
for IPv4 and IPv6 (for example, hot-standby heart beat).
• In a one-armed typology, the Symmetric Active-Standby HA and Symmetric Active-Active HA
configuration are not supported for the IPv4 to IPv6 gateway. The Hot Standby HA configuration
is supported.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
455
7
IPv4 to IPv6 gateway
Session synchronization messages (which contain IP addresses) have added intelligence to handle
IPv4 to IPv6 sessions that have IPv4 addresses for the forward sessions and IPv6 addresses
(including destination IP constructed using the SLB 446 prefix) for reverse sessions.
Configuring the IPv4 to IPv6 gateway
To configure the IPv4 to IPv6 gateway, you must define a unicast IPv6 prefix. ADX uses this prefix to
convert IPv4 client addresses to IPv6 client addresses when sending packages from an IPv4 client
to an IPv6 real server. You must perform the following configurations:
•
•
•
•
Configure the IPv6 prefix for converting an IPv4 client IP to an IPv6 client IP
Configure an IPv6 real server
Configure an IPv4 VIP
Bind port http of IPv4 VIP to port http of IPv6 real server
Sample configuration
The following example provides a sample configuration for the ServerIron ADX in Figure 56 and
Figure 57.
The following command configures the unicast IPv6 prefix:
ServerIronADX (config) #server ipv6 prefix 2001:db8:1::/64 slb-446
The following commands configure an IPv6 real server:
ServerIronADX (config)#server real rs1 2001:db8:2::1
ServerIronADX (config-rs-rs1)#port http
ServerIronADX (config-rs-rs1) port http url "HEAD /"
ServerIronADX (config)#server real rs2 2001:db8:2::2
ServerIronADX (config-rs-rs2)#port http
ServerIronADX (config-rs-rs2)#port http url "HEAD /"
The following command configures an IPv4 VIP:
server virtual v4-vip 10.100.100.1 port http
The following command binds the IPv4 VIP application port to the IPv6 real server application port.
bind http rsl http rs2 http
Displaying IPv4 to IPv6 gateway information
You can use the show session all and show ipv6 map-statistics commands to display information
about an IPv4 to IPv6 gateway. These commands work just as described in “Displaying IPv6 to IPv4
gateway information” on page 450.
The show ipv6 client-4to6 command displays the IPv6 client address generated for an IPv4 client
address using the IPv4 to IPv6 gateway.
ServerIronADX#rconsole 1 1
ServerIronADX1/1#show ipv6 client-4to6 10.100.100.1
456
ServerIron ADX Server Load Balancing Guide
53-1003452-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 pervious specified commands apply 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.
ServerIron ADX Server Load Balancing Guide
53-1003452-01
457
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
458
ServerIron ADX Server Load Balancing Guide
53-1003452-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
ServerIron ADX Server Load Balancing Guide
53-1003452-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
459
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.